...

воскресенье, 30 марта 2014 г.

[recovery mode] Жизнь управленца, кадр 7, Как мы добиваемся выполнения сроков

Всем привет,

Выяснилось, что я все таки спринтер, а не стаер, и писать длинные умные тексты у меня не очень получается. Нет времени, не хватает усидчивости. Поэтому перейду ка я на систему очень четких и явных списков того, как мы решаем конкретные проблемы.


Сегодня я хочу рассказать как мы добиваемся выполнения сроков, т.е. что нужно делать тимлиду, чтобы приблизиться к точному выполнению проектов в срок.


Принцип 1. В срок, не будет никогда.


Первое, что вы должны уяснить это то, что в срок, вам ваши разработчики никогда не сдадут удовлетворяющий вас функционал. Плохо ли это? Да. Виноваты только разработчики? Конечно нет. Неясная задача, новые аспекты, проблема с которой раньше не сталкивались, срочные решения багов, плохое настроение, жена, футбол, причин миллиард. Вывод один. Вам никогда в срок, задачу не сдадут.


Принцип 2. Срок, сроку рознь. Метод подушки.


Так как вы реалист, и знаете что в срок вы не получите задачу, вы должны сразу закладывать подушку. Т.е. разработчики должны сдавать продукт вашему руководителю проектов в срок, гораздо более ранний, чем сдача проекта Заказчику. Конкретный объем подушки приходит с опытом, но я рекомендую закладывать 30-45%.


Принцип 3. Одна голова хорошо, но Змей Горыныч рулит.


Отличные разработчики есть, но мало. Хороших больше, но их еще поискать. Основная масса, средний уровень разработчика, не гений, но и не дурак. В таком случае при оценке тикета, вы должны использовать метод Змея Горыныча.



  • Голова 1. Ведущий разработчик дает «эталонную» оценку. За сколько задачу разработает он.

  • Голова 2. Разработчик сам дает оценку. В зависимости от квалификации оценка будет дольше на 20-70%.

  • Голова 3. Тимлид и РП (руководитель проекта) совместно обсуждают оценку, и делают табличку сроков в тикете. Где видно кто, когда и как оценил


Принцип 4. Внутренний срок сдачи должен быть выдержан.


Через пару сдач, все разработчики просекут что у них есть подушка, которую вы заложили. Но ваша задача заставить их понимать, что для них ее нет. Поэтому надо наказывать за то, что сроки не выдерживаются. НО. Наказание не должно подрывать мораль сотрудников. Поэтому лучше всего наказывать следующим:



  • Прилюдное порицание

  • Лишить «переработок» (за любую переработку мы даем соответствующие отгулы)

  • Доп. нагрузка. Дежурство, общественные работы


Если люди все время срывают сроки, и не задумаются о том, как выдерживать сроки, увольняйте. Ошибаться можно, но гордиться ошибками, и говорить, что в принципе все ок, нельзя.


Принцип 5. Вы в одной лодке.


Деньги платят всем, кому то больше кому то меньше. Поэтому не бойтесь открыто обсуждать с тимлидами, РП, ваши страхи за сроки. И думайте вместе, и работайте вместе с ними. Не надо бросать своих менеджеров, но и не лезьте к разработчикам, пусть все знают, что когда наступит главная «жопа» в проекте, всегда будет тот, кому можно поплакаться, и вы должны стать эдакой скалой, которая является безопасной гаванью для решения любых проблем.


Принцип 6. Упреждайте а не предупреждайте


По окончании проекта, когда будут профуканы сроки, легко сказать я предупреждал. Мы таких вот деятелей, увольняем сразу. Как только видите проблему, сразу, сразу, говорите об этом. Не бойтесь собирать людей когда вы боитесь. Лучше начать решать проблему тогда, когда она в зачаточном состоянии.


Принцип 7. Будьте всегда готовы.


Даже если вы все сделали правильно, сроки будут сорваны. Поэтому заранее готовьте некие «ништяки» для клиента, которыми вы воспользуетесь. При этом важно понимать, что вы должны работать с клиентом еще до фактического заказа. И вы как нормальный руководитель заложите подушки не только внутри компании но и у самого клиента, и он будет о них знать. Но для вас сорванный срок, всегда сорванный срок. Поэтому, когда вы сорвали срок, звоните клиенту и встречайтесь. Расскажите почему, как, и расскажите что вы предлагаете такое решение, и так как ваш клиент самый лучший на земле то вы еще сделаете бесплатно то и то.


Предыдущие статьи:


Жизнь управленца, кадр 1, не надейтесь на понимание

Жизнь управленца, кадр 2, жесткая воля

Жизнь управленца, кадр 3, коммуникации

Жизнь управленца, кадр 4, Планирование — Постановка задачи

Жизнь управленца, кадр 4-1, Планирование — Разбор задач

Жизнь управленца, 5, Управление изменениями

Жизнь управленца, кадр 6, Ответственный и ответственность


This entry passed through the Full-Text RSS service — if this is your content and you're reading it on someone else's site, please read the FAQ at http://ift.tt/jcXqJW.


Комментариев нет:

Отправить комментарий