Кого винить в срыве сроков разработки?

Если честно, я был бы рад ответить - никого. Все же no-blame policy - это важная часть психологической безопасности в любой организации. К тому же, мы все с вами - взрослые люди и прекрасно понимаем, что обычно не очень важно, кто виноват в срыве сроков, но очень важно понимать, что теперь делать, чтобы из трудной ситуации выкарабкаться.

Но также не менее важно понимать, кто что мог сделать, чтобы такого больше не допускать. Не с целью обвинить, а с целью сделать выводы и больше не повторять.

Поэтому, для понимания инструментов, доступных для управления сроками, я этот неприятный и конфликтный вопрос все же затрону.

Дисклеймер: к сожалению, на эту тему менеджеры всех уровней обычно редко глубоко задумываются, потому что, как говорится, тут "главное, в ходе следственных действий не выйти на самих себя". Поэтому даже не надейтесь, что встретите понимание в глазах начальника, если решите с ним обсудить этот вопрос после прочтения этого поста. Я вас предупредил.

Начнём с самого низа и до самого верха.

1. Разработчик.

Отдельный разработчик может стать причиной срыва сроков разработки: на некоторые задачи мы, бывает, можем вместо пары дней потратить пару недель. Это так-то в пять раз больше, чем могли бы.

Как правило, это происходит, когда разработчик:
- не понимает, как ему сдвинуться с мёртвой точки;
- потерял мотивацию и прокрастинирует;
- увлёкся и городит какой-то космолёт;
- просто, по своей природе, работает сильно медленнее остальных.

Также разработчик может делать все по красоте, но просто элементарно не вывезти объём работ.

Виноват ли будет в таких случаях в срыве сроков разработчик? Моё мнение - нет, во всех этих вариантах должен правильно действовать именно тимлид. Это обязанность именно тимлида - увидеть, что разработчик упёрся в стену и больше не движется. Это его обязанность - знать, с какой скоростью, кто работает. И именно тимлид должен примерно оценивать, успеет ли разраб в срок или нет.

Есть ли у тимлида тут инструменты? Конечно! Увлекшегося - осадить, упершегося - поддержать, прокрастинирующего - разгрузить и увлечь другой задачей, медленного - поставить на не срочные задачи, а перегруженного - усилить.

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

2. Тимлид и команда.

Лидер команды или сама команда могут стать причиной срыва сроков.

Обычно причины тут такие:
- разрабы тормозят (см. п. 1)
- неправильно расставили приоритеты и делали не то;
- погрязли в багах и легаси;
- просто не вывезли объём работ.

Виноваты ли в этом команда или лид? Если по-честному, то в первых трёх случаях - да.

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

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

Виновата ли команда в том, что они не вывезли нагрузку? Только если они не просигнализировали заранее о том, что объём работ превышает их возможности. Если сигналы были, а реакции не было, то вряд ли у команды были какие-то инструменты решить эту проблему.

Сама по себе, обычно, команда не управляет ни объёмом работ, ни сроками, ни ресурсами, а, значит, ничего с избыточной нагрузкой сама сделать не сможет: какой-то частью работ команде придётся пожертвовать ради другой.

3. Топ-менеджмент.

Очевидно, что за срыв сроков топ-менеджмент отвечает всегда. И отвечает головой. Но всегда ли он виноват? Какие есть инструменты у топ-менеджмента?