Тупик в проекте: как найти выход?
Каждые два года исследовательская группа Standish Group публикует отчет по проектной деятельности в разработке софта под названием CHAOS Report (Comprehensive Human Appraisal for Originating Software) — все про человеческий фактор в проектах.
В отчете обычно проекты разделены на три типа:
👉 «Успешный» — проект, завершенный в срок и в рамках бюджета;
👉 Проект «с проблемами» — проект завершен, но его сроки и бюджет в несколько раз выше заявленного;
👉 «Неудачный» — это тот проект, который отменяется в процессе разработки. Что интересно таких проектов больше 60%.
Факторов когда команда заходит в тупик и проект тормозится даже не дойдя до релиза обычно много. Опишу с чем столкнулся лично и какие выходы нашел:
1. Несогласованность действий каждого участника проекта. Если бы один человек работал над проектом: разрабатывал решение, отвечал за реализацию, документировал процесс, то и управление было бы простым. На практике над проектом работают 4-7 человек, и у каждого сотрудника свои приоритеты. Изначально это не доставляет неудобств, но если в таком темпе двигаться полгода, то проект останется на той же стадии.
2. Долгое принятие и тестирование решений. Чтобы улучшить состояние проекта на 25%, нужно научиться быстро принимать решения. Группа Стендиш предлагает прикольную эмпирическую метрику: проект порождает одно решение на тысячу долларов проектных трудозатрат. Если в проекте на одно решение приходится не одна, а две тысячи трудозатрат — значит, решения принимаются дольше, чем это возможно.
3. Чем меньше проект тем, проще им управлять. Понятно, что в один проект хочется внести сразу несколько фичей, которые могут принести пользу клиентам. Но чем, больше ответвлений появляется у проекта, тем сложнее контролировать команду и процесс разработки.
Что делать, если чувствуете, что проект зашел в тупик?
Первый шаг, который стоит сделать — оценить текущее состояние проекта: что уже реализовано, что в процессе, найти артефакты проекта, понять какие процессы задокументированы.
Второй шаг — задокументировать и автоматизировать процессы. Пусть сотрудники сохранят в вики нужную информацию для работы, автоматизируют коммуникацию в команде, создадут дашборд с процессами.
Если после аудита и структурирования процессов станет ясно, что проект по-прежнему находится в тупике, оптимальным решением будет его закрыть. Проект, завершённый на 95%, но застрявший в развитии, может потребовать ещё несколько лет на доработку архитектуры и устранение ошибок. Однако даже после этого так и не дойти до этапа релиза.
Есть советы, как справляетесь с проектами, которые зашли в тупик?
