Ваш процесс может покрывать (а может не покрывать) мелкие исправления после демо. Но он точно не покрывает случайные “мелкие улучшения” разных кусков системы. Здесь очень хорошо помогает навык менеджера организовывать процесс. Добавить тикет на это улучшение, убедить заказчика, что лучше подкопить изменения и вернуться потом к этому экрану, подгадать изменение к регрессионному тестированию, чтобы не создавать дополнительной работы для тестировщиков – это всё часть работы менеджера по управлению скоупом.
Важно помнить, что кроме явных затрат на разработку есть ещё другие трудозатраты, и что риски являются такой же частью бюджета, как и работы.
В бюджет проекта всегда так или иначе включены так называемые “накладные расходы”: затраты на коммуникацию, отчётность и т.д. Важной особенностью этой области является то, что менеджер очень сильно может снизить эти затраты.
Например, сейчас все понимают, что требования должны быть готовы и одобрены до начала разработки. Если разработчик начнёт писать код и через час споткнётся о неясность, то ему придётся уточнять вопрос у заказчика (или ещё кого-то), а самому переключаться на какую-то другую задачу, отвлекать тимлида или менеджера с просьбой эту задачу дать. В результате отвлекается не один человек, а несколько.
Многие задачи разработчика требуют полного погружения на длительное время (час, два, иногда больше). Если разработчика в течение часа “дёрнуть” раза четыре, то его производительность за этот час будет околонулевой.
Иногда менеджеры вынуждены отвлекать разработчиков со срочными вопросами, но часто эти вопросы вполне могут подождать. Имеет смысл задавать такие вопросы в почте с припиской, что можно ответы дать вечером, или завтра, или в течение недели. Можно подсказать разработчикам, что мессенджер можно отключать на время ответственных работ, и самому с пониманием относиться к такому.
Я очень большой сторонник общения лицом к лицу и считаю, что менеджеру нужно почаще разговаривать со своей командой. Но у менеджера должно хватать такта и умения своё общение не превращать в отвлечение. Возьмите самую свою большую кружку для кофе, улыбнитесь разработчику, который в это же время наливает кофе себе, и расскажите какую-нибудь забавную ситуацию, связанную с проектом, которая вылезла у вас на беседе с заказчиком или вашим менеджментом. Та часть команды, которая в этот момент ждёт выгрузки репозитория или сборки проекта, поучаствует в беседе и вынесет для себя что-то полезное, а та часть, которая погружена в отладку, не заметит происходящего, если не сильно шуметь.
Если вы видите, что одна команда бегает “в мыле” и постоянно решает срочные вопросы, а другая спокойно сидит, не спеша набирая код, то можно быть уверенным в том, что вторая команда гораздо производительнее первой. И если вы не можете обеспечить вашей команде нормальные условия работы, то это снизит производительность и, следовательно, раздует бюджет.
Не нужно забывать, что в ваш бюджет входит очень много косвенных затрат. Тогда не будет удивления, что, например, значительное падение скорости сети ведёт к значительному росту оценок вашей команды.
История про самую распространенную причину провала проекта
Как-то, проходя мимо переговорки, я заметил большую толпу заходящего туда народа и коллегу-менеджера, Макса. Я остановился и спросил, что происходит.
– Да вот ретроспективу своего проекта проводить буду. Должно быть интересно. Мы проект завалили, в полтора раза дольше делали, чем это планировалось. Заказчик крайне недоволен да и наше руководство тоже.
– А почему завалили-то?
– Ты знаешь, Константин, я сам понять не могу. Вроде, всё по плану шло, ничего беды не предвещало. А в самом конце вдруг выяснилось, что не успеваем закончить вовремя и так вот и потянулось дальше: то одно, то другое, и все сроки откладываются и откладываются.
Я пожелал Максу удачи, а сам про этот случай вспоминаю периодически. Я очень благодарен коллеге, что он честно ответил “не знаю”, а не стал прикрываться обычными “команда слабая”, “заказчик сложный”, “сроки были нереальные” и т.д. Если менеджер не знает, почему его проект провалился, то стоит в этом признаться и себе, и другим.
А с другой стороны такая ситуация для меня – это самый главный критерий провала менеджмента. Когда менеджер не видел проблем, а проект в результате провалился, это значит, что проект был фактически неуправляем.