Планируем сроки, оцениваем риски
Методов планирования много. Не ошибусь, если скажу, что самый распространенный — это старый добрый метод планирования «сверху».
Выглядит он так: собирается совещание директоров (акционеров, главных менеджеров, больших начальников и т.п.) На нем Самый Главный Директор, стуча по столу кулаком (трубкой, туфлей и т.п.), орет: «Я не могу руководить в информационном вакууме (без консолидированного бюджета, кадровой системы, портала и т.п.)».
Кто отвечает за выход Самого Главного Директора из информационного вакуума? Конечно, директор по ИТ. Когда директор по ИТ сможет внедрить информационную систему, которая позволит Самому Главному Директору выйти из информационного вакуума? Директор по ИТ не знает.
Чтобы выдать самую верхнеуровневую оценку, ему нужно провести анализ задачи и запросить информацию у своих специалистов из управления вакуумных систем. Но отвечать нужно сейчас. Прямо сейчас.
Менеджерская интуиция подсказывает директору по ИТ, что год — это минимум. Самый минимум. Но директор по электрификации, попросивший год на выход компании из сумрака, в этот самый сумрак и ушел.
Помня об этом печальном опыте, директор уверенно произносит: «Полгода».
«Вы что» — орет Самый Главный Директор, брызгая слюной. — «Я задыхаюсь в вакууме, а вы говорите полгода???».
ИТ-директор на лету проводит оперативное перепланирование: «Три месяца...».
«Два,» — милостиво соглашается Самый Главный Директор.
Всё, в принципе, план готов. Можно даже спрогнозировать результат — через два месяца никакой системы не будет, а директор по ИТ будет заменен на нового — более эффективного, который, впрочем, повторит судьбу своего предшественника.
Хотя, если менеджерское счастье в этот раз на стороне директора по ИТ, то возможен и удачный исход: на этапе проектирования системы неожиданно выяснится, что Самому Главному Директору просто нужен доступ к социальным сетям, который отрубил администратор. Повезло, бывает.
Выше описан обычный, ставший практически стандартным подход к планированию. А дальше я расскажу про «необычный» метод планирования «снизу», который основывается на оценках, которые дают исполнители. Метод классический, однако, и он далеко не идеален.
Самая главная ловушка такого планирования — это игнорирование рисков. Над столом любого менеджера должен висеть плакат с законом Мерфи:
«Если есть вероятность того, что какая-нибудь неприятность может случиться, то она обязательно произойдет».
В процессе планирования менеджер должен быть реалистом, а менеджеров-оптимистов нужно расстреливать. Менеджер, который врет самому себе, что на протяжении всего проекта никто не заболеет, железо будет работать идеально, все согласования будут проходить точно в срок, а все участники проектной команды будут вести себя рационально и не совершать профессиональных и административных ошибок, этот менеджер даже не дурак, этот менеджер — клинический идиот.
Нужно помнить, что самый оптимистичный взгляд на сроки всегда принадлежит программистам, причем феномен ничем необоснованной оптимистичности разработчиков ученые пока не разгадали.
Впрочем, если у вас есть под рукой живой Программист, вы можете сами провести небольшое эмпирическое исследование. Поставьте Программиста в точку А, а сами переместитесь в точку Б, находящуюся на расстоянии 2 километров от точки А (расстояние должно быть Программисту известно, транспортные средства не доступны).
После этого позвоните Программисту и спросите: «Ты когда сможешь подойти ко мне?». Ответ с вероятностью 90% будет варьироваться в интервале 5 до 15 минут. При этом, Программист не собирается бежать — он действительно планирует прийти через
Программисты умеют считать, умеют оценивать задачи, но обладают абсолютно необъяснимым, практически детским оптимизмом по поводу сроков. На практике достаточно сложно постоянно придумывать наводящие вопросы, поэтому придерживайтесь простого правила — оценку программиста умножайте на 2. А лучше на 3.
Когда у вас есть оценка сроков, попытайтесь получить оценку рисков «снизу» и учтите их в плане. Не факт, что у вас это получится — в силу своей врожденной оптимистичности разработчики стараются о «плохом» не задумываться. Здесь больше будет полезен ваш личный опыт и опыт ваших коллег. Закладывайте эти риски в план — неделю на традиционный «майский запой» администратора, 5 дней на «роды хомячка» бизнес-заказчика и т.п. И не забудьте про отпуска — почему-то именно в них сотрудники обычно уходят. Впрочем, в огромном количестве планов не учитывают даже официальные праздники и выходные дни.
Планируя, помните, что если в прошлый раз систему ставили 2 недели («какие-то траблы непонятные были»), и причины проблемы не устранены, не нужно планировать, что в этот раз ее поставят за 2 дня. «Траблы» иногда саморассасываются, но совсем необязательно в этот раз. Помните: «если есть вероятность того, что какая-нибудь неприятность может случиться, то она обязательно произойдет».
Впрочем, нужно всегда помнить, что чрезмерный пессимизм и учет всех возможных рисков, включая падение метеорита, ведет в другую ловушку, описанную в законе Паркинсона: «Работа заполняет все время, отпущенное на нее».
Нужно помнить, что члены вашей команды — люди увлекающиеся. Если у разработчика есть две недели на написание функции x*y + z, то он обязательно прикрутит возможность 3D-визуализации, перепишет ее на Ассемблере и разработает «простенький интерфейс в виде инженерного калькулятора». У всех этих возможностей будет только один недостаток — они никак не соотносятся с целями проекта.
Пытаться обойти эту ловушку путем создания отдельного «плана для разработчиков» (а еще одного — для руководства, и еще одного для себя), ни к чему хорошему не приводит. В какой-то момент планы начнут фатально расходиться, и управление проектом будет утеряно.
Единственный верный путь при планировании — это реализм и честность перед бизнес-заказчиком, руководством и проектной командой. Ну, и перед собой, естественно.
А вы сталкивались на практике с планированием «сверху» или «снизу»? Как вы управляли процессом?
Алексей Леонтьев
