Tue 8 Aug 2006
О вреде излишнего планирования
Posted by Alex Lebedev under менеджмент
‘Plans are useless - but planning is essential’ - General Eisenhower
Регулярно сталкиваюсь с желанием того или иного руководства составить подробный план работ и строго следовать ему. Зачем это нужно? Никакой объем планирования не может ускорить работу. Может, подробный план нужен для оценки примерного срока завершения работы? Да, но оцениваемый срок имеет мало общего с реальной датой завершения. Может быть, нужно строже контролировать соблюдение сроков?
Контроль соблюдения сроков Здесь, как и в квантовой механике, факт измерения влияет на измеряемый показатель. Отслеживая и контролируя сроки выполнения работ, вы получите совсем не ту производительность, что при отсутствии измерений. Многие, вероятно, думают, что производительность в случае контроля сроков будет выше; возможно, это еще одна причина, по которой руководство любит подробные планы работ. По-моему, это не так. Постоянный контроль улучшает производительность только на небольшой период времени. Потом происходит привыкание и снижение производительности ниже исходного уровня.
Что делать, если вашим разработчикам нужен постоянный контроль? Либо вы себя обманываете и контроль не нужен, либо у вас плохие разработчики. Если второе, то не стоит пытаться тщательно контролировать их работу. Да, вы получите большую отдачу от раздолбаев но одновременно сделает жизнь хороших разработчиков менее комфортной. Это плохая сделка. Если вам важен результат, не пытайтесь получить отдачу от раздолбаев. Увольте их, добейтесь перевода на другой проект или изолируйте от остальной команды и займите чем-нибудь второстепенным. Это позволит получить лучшие результаты от хороших разработчиков, которые у вас есть.
О дисциплине
Года два-три назад я был большим сторонником тщательного планирования, контроля сроков, упорядоченных процессов разработки… Сейчас я, скорее ,противник всего этого. Почему? Потому что теперь у меня есть опыт реального управления, который показал - это дерьмо не работает. Когда работа только начинается, до окончания срока пара месяцев, у тебя на руках подробный план работ - это успокаивает. Но знаете что? Нет ни малейшего основания успокаиваться. Основная часть работы впереди. Проблемы, которые позже пустят ваш план ко дну, пока еще не видны. Есть о чем побеспокоиться, не так ли? Так, может, лучше заняться действительно важными вещами, а не составлением подробного плана?
Часто бывает, что активное стремление навести порядок и укрепить возникает из-за страха браться за самые важные проблемы, стоящие перед командой. Эти проблемы, как правило, сложны и непонятны. Укреплять дисциплину намного проще - все понятно и нет ответственности на тебе как на менеджере. Даже мозги не нужны большую часть времени. Я стараюсь обращать внимание на такие нотки в своей мотивации при принятии решений, это помогает делать меньше глупостей.
Работающая модель планирования
Скажу несколько слов о том, как, по моему мнению, надо планировать. Эти принципы показали себя более-менее применимыми на практике. Всегда имейте максимально полный и актуальный список работ. Расставляйте приоритеты и работайте в первую очередь над высокоприоритетными вещами. Оценивайте трудоемкость работ и примерные даты окончания. Только не пытайтесь зафиксировать сроки и взвалить ответственность за их соблюдение на разработчиков. Да, быть может, проще сказать “чтоб к 1 числу все было готово!” чем решать, какая задача приоритетнее, заниматься мониторингом текущего состояния, выбирать компромиссы между датой выпуска и функциональностью продукта. Но это плохой путь. Не стоит перекладывать свои менеджерские проблемы на разработчиков.
Еще немного о сроках
Есть одна интересная закономерность. Неважно как точно вы оцениваете срок выполнения запланированных работ, ваш план все равно потеряет всякую связь с действительностью, как только выяснится, что надо обязательно сделать работу X, которой в плане не было. Согласно статистике (ДеМарко, Листер, “Управление рисками в проектах по разработке программного обеспечения”), именно непредусмотренные планом работы являются основной причиной изменения сроков.
Вы все еще думаете что вам нужен подробный план работ?

August 8th, 2006 at 12:35 pm
Да, все хорошо. У меня только есть пара вопросов.
Что делать, если ты не самый-самый главный менеджер в организации, а подробных планов и регламента от тебя требует руководство или там корпоративная культура? Делать двойную работу, составляя два плана или пытаться “убедить руководство”, что так планировать неправильно?
Другой вопрос - назначена точная дата выпуска (по-разным причинам - заказчики, потребители требуют), так как выпустить наиболее функциональный и наименее глючный продукт к определенному сроку?
August 8th, 2006 at 5:19 pm
Никто из нас не самый главный менеджер, это нормально. Нужно осознавать, что определенное неудобство от инициатив вышестоящего руководства всегда будет исходить. У руководства свои цели, которые никогда полностью не совпадают с нашими целями. Что делать если начальство требует подробный план, добавить в проект никому не нужных Васю и Петю, портировать все на Java, быть телепатом, стоять на голове по утрам (нужное подчеркнуть)? Есть много вариантов:
- Реконструировать то, чего пытается добиться руководство и предложить менее болезненный способ.
- Принимать удар на себя и ограждать разработчиков. Спорить, делать липовые отчеты, изолировать Васю и Петю на второстепенном участке проекта.
- Подчиниться и пофилософствовать на тему того что мир не идеален.
- Если это совсем невыносимо, свалить из проекта или компании. Я уже писал про то, что разгребание последствий чужих ошибок - вещь неблагодарная и малополезная для профессионального роста.
Еще один момент - качество работы менеджера зависит от того, как хорошо сработала команда, а не от того сколько раз вы сказали “да” дурацким идеям руководства. Об этом стоить помнить при принятии решений. Получается типичная задача на оптимизацию - получить максимальный результат, не испортив при этом отношения с руководством. Как именно это сделать - смотри по ситуации.
Чтобы выпустить наиболее функциональный и наименее глючный продукт нужно обеспечить разработчикам спокойную обстановку и четкие приоритеты. Если срок близко, то можно усилить на неделю-две интенсивность работы, иногда это оправданно. Насколько возможно, экранировать плохие идеи руководства и другие источники раздражения. Не отвлекать текущими проблемами у заказчиков всех разработчиков, а начинать с одного. В общем, делать все то же, что нужно делать и при создании хорошего процесса разработки. И быть готовым творчески подходить к функциональности продукта и срокам выпуска.
August 29th, 2008 at 5:08 pm
Хм, во всех этих размышлениях есть небольшая неточность. Ни в одной книге либо документации по проджект менеджменту вы не найдете слов - создали план - засуньте его под стекло и руководствуйтесь только им. И в классике PMBOKи у Ройса - везде вы найдете среди обязательных процесов один самый важный - внесение изменений во все планы, которые вы создали для данного проэкта в соответствии с теущим положением вещей. Без четкого планирования можно упустить контроль за изменениями и, фактически, не фиксировать для себя качественно и количественно эти самые изминения.
August 29th, 2008 at 5:21 pm
To Ian Kyrychenko:
Да, постоянное исправление планов согласно происходящим изменениям разумно. Начиная от определенного размера проекта (ИМХО, человек 10-12) начинает становиться еще и оправданным, то есть приносит пользы больше, чем забирает усилий.
Но писал я не про это. Писал я про илюзию того, что если план составить, то события магическим образом будут этому плану соответствовать:
September 4th, 2008 at 2:28 pm
Ну, тут возразить нечего)