Самая основная проблема заключается в том, что менеджер включает в план только “безопасные даты” и забывает, что плановые даты были другими. То есть менеджер забывает, что релиз должен быть готов не через 6.5 месяцев, а через 6. Заказчик тоже этого не знает. Поэтому, когда релиз выходит через 6.5 месяцев (по плану!), то ни менеджер, ни заказчик не осознают, что проект запаздывает на две недели.
Точнее, нормально, что это не осознаёт заказчик, но вот менеджер должен следить не только за “внешними” датами, но и за плановой скоростью реализации функционала. Я настойчиво рекомендую вставлять “настоящие” даты в свой план проекта, который заказчик может и не видеть.
Но менеджеру всё равно не так легко объяснить заказчику, что на проекте проблемы. Заказчик же видит, что всё идёт по плану. Тут можно достать этот “внутренний” план и объяснить, когда релиз должен был быть закончен на самом деле. Заказчики очень спокойно относятся к заложенным буферам, а особенно к буферам в виде сдвига дат. Ведь они им ничего не стоят!
Но надо понимать, что иногда такие “бесплатные” буферы стоят реальных денег для заказчика. Например, вы заложили в план, что API внешней системы будет готов на месяц раньше, чем он вам реально нужен. Так вот иногда заказчику оказывается гораздо дороже сделать этот API в срок, чем задержать его до того времени, когда он вам реально понадобится.
И здесь начинаются сложности, потому что вы можете пойти навстречу заказчику и согласиться получить API на месяц позже. Но тогда вы берёте на себя дополнительные риски. Если этот API будет с ошибками, или недостаточно документирован, или у вас будут проблемы с доступом – ваш проект будет терпеть убытки. Но с другой стороны, если дать заказчику больше свободы, то есть больше шансов, что API будет качественным.
В такой ситуации бесплатный буфер внезапно начинает стоить денег и уже нужно определять, кто эту цену платит и на каких условиях.
Я придерживаюсь стратегии, что если мы говорим о ранних сроках реализации проекта и оговоренные условия пойдут в контракт, то мы должны давать только “безопасные” даты. Чем безопасней, тем лучше. А вот если проблемы выплывают ближе к запланированной дате, то уже можно проявлять гибкость и сдвигать даты по договорённости с заказчиком, уменьшая “бесплатный” буфер. Но нужно быть очень прямым и объяснить заказчику в том числе и в письменном виде, что любые уменьшения буферов увеличивают риски. Тогда можно избежать расплаты за использования “бесплатных” буферов.
История про проведение ретроспективы
На одном из соседних проектов было очень много проблем. Релизы откладывались, даты срывались, а качество приложения было низким и неуклонно падало. В результате, несмотря на все усилия, проект закончился полным провалом, наша компания серьёзно подвела заказчика.
Чтобы понять, почему так произошло, организовали ретроспективу. Руководитель проекта, в лучших традициях скрама, давал всем высказаться и выписывал на доску длинный список всех проблем, которые команда называла. Опять же в лучших традициях ретроспектив, сперва давали высказываться junior-ам, чтобы более опытные члены команды не давили своим авторитетом. Самым последним слово досталось лиду разработки, очень опытному архитектору, Петру. Пётр был краток:
– Вы вот все много разных причин назвали, но самую главную упустили. Очевидно, что проект завалился только из-за одного: тестировщики нашли слишком много багов. Из-за них-то мы и не смогли в срок выпустить приложение.
Команда тестирования, не веря своим ушам, дружно стала возмущаться, но Пётр поднял руку, призывая всех к тишине.
– Я вижу, что не все согласны с моей точкой зрения. Давайте придерживаться регламента. Все названные командой проблемы выписаны, так что давайте просто проголосуем.
Команда разработки была примерно в два раза больше команды тестирования. Они все дружно проголосовали вслед за Петром за названную им “проблему”. На этом ретроспектива была закончена. По её результатам причиной провала проекта считалось, что “тестировщики нашли слишком много ошибок”. Половина тестировщиков после такой ретроспективы пылала гневом, другая половина была, как в воду опущенная.
Хотя я к тому проекту не имею отношения, но мне до сих пор стыдно перед теми тестировщиками. Мои соболезнования, коллеги. Мне очень жаль, что такие истории случаются в реальности.
Раздел 5. Становление менеджера