Под катом небольшой поток сознания под впечатлением от плохих воспоминаний, которые всплыли в памяти при просмотре видео с докладом Антона Уткина. Про довольно простой прием по планированию, который далеко не все готовы использовать.
В недавнем прошлом было несколько эпизодов, когда мне приходилось на пальцах рассказывать вышестоящему руководству о таком незамысловатом приеме, как планирование в обратную сторону.
Т.е. у нас есть время Ч, когда проект/продукт должен быть запущен. В худшем случае этот срок спущен свыше и изменить его никак нельзя (день выборов, день вступления в силу какого-то закона, срок окончания гарантийных обязательств и т.д.). Нужно спланировать работу по проекту так, чтобы уложиться в этот срок.
Причем планировать нужно в самом начале, когда общие контуры проекта имеют весьма смутные очертания. Объем работ еще толком не понятен. Что именно нужно делать мало кто представляет. О том, как все будет сделано вообще никто не знает. Но распланировать работу нужно уже сейчас.
Методика очень простая. Нужно идти не от сегодняшнего дня вперед, делая предположения о том, сколько времени нам потребуется, чтобы написать ТЗ. Потом о том, сколько уйдет на проектирование. Потом о том, сколько на кодирование. Потом о том, сколько на тестирование и документирование. Потом на развертывание для опытной эксплутации. Потом о том, сколько для перевода в бой.
Идти нужно от времени Ч в обратную сторону. Сколько времени потребуется для запуска в бой? Две недели? Ok. Значит время для всех остальных этапов сокращается на две недели. Теперь у нас есть метка (Ч-2н). Сколько времени непрерывной опытной эксплуатации потребуется для того, чтобы принять решение, что можно идти в бой? Неделя? Ok, появляется следующая метка (Ч-3н). Сколько времени потребуется для запуска в опытную эксплуатацию? Месяц? Ok, фиксируем следующую метку (Ч-7н). И т.д, и т.п.
Метод крайне простой и очень отрезвляющий. Особенно, если сроки на запуск в эксплуатацию, прохождение ПСИ, тестирование и документирование называют не программисты/архитекторы, не бизнес- или системные-аналитики, и уж тем более не высокопоставленные менеджеры. А люди "от сохи", т.е. инженеры из внедрения и эксплуатации. Эти смотрят на жизнь намного более здраво. И имеют в загашниках столько поучительных историй о просирании всего и вся, что их оценкам доверять гораздо безопаснее, чем мнению неисправимых оптимистов, коими являются программисты.
Когда откладываешь временные метки от часа Ч в обратную сторону, то быстро выясняется, что на согласование ТЗ, проектирование и разработку остается, скажем, всего 3-4 месяца. При этом конь не то, что еще не валялся, а его еще никто в глаза не видел. Тут уж желание раздувать объем проекта, давать какие-то смелые обещания заказчиками или вышестоящим менеджерам, моментально улетучивается. Впрочем, как и изобретать велосипеды или заниматься исследовательской деятельностью с непонятным результатом.
Но главный фокус этого метода в том, чтобы иметь два набора временных меток. Первый набор строится при первом проходе от Ч к сегодняшнему моменту. Он показывает идеальный сценарий развития проекта. К этому набору не мешало бы еще построить второй набор -- набор контрольных точек, в которых нужно проверить состояние дел. Цель второго набора в обозначении моментов, когда еще можно предпринять какие-то героические усилия, чтобы исправить ситуацию, если что-то пошло не так (c). Например, если перевод в бой стартует в момент (Ч-2н), то где-то в момент (Ч-7д) нужно проверить статус перевода. И если становится понятно, что на горизонте или где-то ближе маячит большая Ж, то остается еще семь рабочих дней на то, чтобы все исправить. Причем, чем толковее расставлены эти контрольные точки, чем чаще происходит корректировка плана проекта по ходу дела, тем проще получить приемлемый результат. Что, имхо, должно быть очевидно.
Рассказывал я о таком подходе, как минимум, раза два. И каждый раз у меня складывалось ощущение, что рассказываю какую-то крамолу или ересь, настолько равнодушно, а иногда и откровенно снисходительно реагировали слушатели. Теперь же, когда до меня доходят слухи о "достижениях" этих многоопытных "эффективных менеджеров", теплое чувство от осознания собственной правоты, к сожалению, не греет.
Тем не менее, способ действенный. Проверено в безнадежных проектах. На людях. Но формальные процессы и KPI идут лесом, да. Так что действенным этот способ будет не для всех.
Комментариев нет:
Отправить комментарий