Как хорошему разработчику не стать плохим менеджером - [35]

Например, вы руководите проектом на 12 месяцев с довольно большой командой в 30 человек. И вы решили сделать промежуточный релиз, который будет содержать основную функциональность в приличном качестве. Заказчик готов посадить своих специалистов на проверку системы. Вы получите дополнительное тестирование, а заказчик сможет провалидировать свои требования. Если окажется, что ему нужна немного не такая система, как ему казалось, то ещё будет время что-то исправить.

Предположим, вы оценили этот релиз и получилось, что он будет готов через 6 месяцев. Так вот тут очень важно запланировать дату этого релиза на неделю (а может и на две) дальше. Этот буфер заказчику не будет стоить ничего, потому что на объём работ он не влияет. Но вам и команде будет гораздо проще жить.

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

Другой вид бесплатных буферов – это когда вы подстраховываетесь от действий других. По вашему плану нужно, чтобы требования были готовы 10 июня? Сообщите заказчику, что вы ждёте требования 1 июня. Тогда у вас хотя бы будет шанс не понести потери, когда вы получите требования плохого качества или с задержкой.

Или вам нужно интегрироваться с ещё не разработанным сервисом, который будет готов в декабре. Сообщите заказчику, что вам нужна документация по API хотя бы в ноябре. Явно она уже должна быть готова. Если вы не получите документацию в ноябре, то самой системы в декабре вы точно не получите. Ну и, конечно, даже если заказчик очень уверен, что это API будет готово 1го декабря, то никак нельзя ставить задачи, зависимые от него на 2е декабря. Обязательно нужен  такой же “бесплатный” буфер в плане, который подстрахует вас от неудачи другой команды.

Привычка раскидывать везде такие буферочки должна стать постоянным рефлексом любого менеджера. Если разработчик говорит мне, что уже сделал задачу и осталось только проверить, то я говорю, что задача будет сделана завтра (или сегодня, если повезёт). Если разработчик уверенно говорит, что задача будет сделана завтра, то я говорю заинтересованным лицам, что она будет готова послезавтра.

Если вы видите, что не можете добавить запас по времени в ваш план, то это повод записать в свой реестр новый риск. Это показатель хрупкости плана. Скорее всего, у вас проблемы и надо начинать их решать уже сейчас.

Цена бесплатных буферов

Хотя я и называю сдвиг промежуточных дат в плане “бесплатным” буфером, но менеджер прекрасно знает, что за всё надо так или иначе платить. Где подвох с бесплатными буферами?

Самая основная проблема заключается в том, что менеджер включает в план только “безопасные даты” и забывает, что плановые даты были другими. То есть менеджер забывает, что релиз должен быть готов не через 6.5 месяцев, а через 6. Заказчик тоже этого не знает. Поэтому, когда релиз выходит через 6.5 месяцев (по плану!), то ни менеджер, ни заказчик не осознают, что проект запаздывает на две недели.

Точнее, нормально, что это не осознаёт заказчик, но вот менеджер должен следить не только за “внешними” датами, но и за плановой скоростью реализации функционала. Я настойчиво рекомендую вставлять “настоящие” даты в свой план проекта, который заказчик может и не видеть.

Но менеджеру всё равно не так легко объяснить заказчику, что на проекте проблемы. Заказчик же видит, что всё идёт по плану. Тут можно достать этот “внутренний” план и объяснить, когда релиз должен был быть закончен на самом деле. Заказчики очень спокойно относятся к заложенным буферам, а особенно к буферам в виде сдвига дат. Ведь они им ничего не стоят!

Но надо понимать, что иногда такие “бесплатные” буферы стоят реальных денег для заказчика. Например, вы заложили в план, что API внешней системы будет готов на месяц раньше, чем он вам реально нужен. Так вот иногда заказчику оказывается гораздо дороже сделать этот API в срок, чем задержать его до того времени, когда он вам реально понадобится.

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

В такой ситуации бесплатный буфер внезапно начинает стоить денег и уже нужно определять, кто эту цену платит и на каких условиях.

Я придерживаюсь стратегии, что если мы говорим о ранних сроках реализации проекта и оговоренные условия пойдут в контракт, то мы должны давать только “безопасные” даты. Чем безопасней, тем лучше. А вот если проблемы выплывают ближе к запланированной дате, то уже можно проявлять гибкость и сдвигать даты по договорённости с заказчиком, уменьшая “бесплатный” буфер. Но нужно быть очень прямым и объяснить заказчику в том числе и в письменном виде, что любые уменьшения буферов увеличивают риски. Тогда можно избежать расплаты за использования “бесплатных” буферов.