Проекты разработки срываются предсказуемо. Причины повторяются от проекта к проекту, и почти все они видны заранее — если знать, куда смотреть.
Ниже — признаки, по которым срыв виден на старте, и то, что с ними делать обеим сторонам.
Чем позже найдена проблема, тем дороже
Это единственный закон, который объясняет большинство срывов. Ошибка в требованиях, найденная на этапе требований, стоит разговора. Та же ошибка, найденная на приемке, стоит переделки половины системы.
Признаки, видные до начала работ
- Смета названа без вопросов. Задача, которую можно оценить без единого уточнения, либо тривиальна, либо не понята. Второе вероятнее.
- Нет ответа на вопрос «что считается готовым». Если критерии приемки не описаны до старта, спор о них произойдет в конце, когда деньги уже потрачены.
- У заказчика нет человека, принимающего решения. Проект, где каждый вопрос идет на согласование к трем руководителям, будет идти со скоростью согласований.
- Проект без этапов. Пять месяцев работы без промежуточной сдачи — это пять месяцев вслепую для обеих сторон.
- Исполнитель ни разу не сказал «нет». Подрядчик, который соглашается на все, либо не понимает объем, либо планирует добрать на дополнительных работах.
- Требования собраны только от руководства. Те, кто будет работать в системе, не участвовали. На приемке выяснится, что так никто не работает.
Признаки, что проект уже поехал
- Демонстрации перестали быть регулярными. «Пока нечего показать» две недели подряд означает, что работа идет не туда или не идет.
- Сроки сдвигаются по чуть-чуть. Неделя, еще неделя. Сдвиг на месяц одним куском честнее и лечится, а серия мелких сдвигов означает, что плана нет.
- Растет список «доделаем потом». Если он длиннее того, что сделано, проект превратился в накопление долга.
- Обсуждения ушли в переписку. Когда вместо получасового разговора стороны обмениваются письмами по три абзаца, значит, доверие кончилось.
- Появилось слово «архитектура». В смысле «надо переделать архитектуру, чтобы двигаться дальше». Иногда это правда, чаще — признак, что сроки поплыли.
Самый надежный индикатор здоровья проекта — возможность в любой момент увидеть работающую версию с последними изменениями. Если ее нет, любые отчеты о прогрессе — это слова.
Что делать заказчику
- Требовать этапы с рабочим результатом. Не «сделан бэкенд», а «можно завести заявку и увидеть ее в списке». Этап, результат которого нельзя потрогать, — не этап.
- Смотреть демонстрацию раз в одну-две недели. Двадцать минут, на живой версии, с участием тех, кто будет работать в системе.
- Выделить одного человека с правом решать. Без этого скорость проекта равна скорости самого медленного согласования.
- Фиксировать изменения письменно. Каждое с оценкой влияния на срок, даже если оценка нулевая.
- Держать доступ к коду и данным у себя. Репозиторий и серверы должны быть ваши. Это не про недоверие, а про возможность продолжить с другими людьми.
Что делать исполнителю
Если вы по эту сторону, симметричный список короче.
Говорить о проблеме в день, когда она появилась, а не когда стало поздно. Показывать работающее, а не рассказывать о прогрессе. Отказываться от задач, которые не укладываются в срок, вместо того чтобы соглашаться и сдвигать. И задавать неудобные вопросы до сметы, а не после.
Где здесь ИИ
Инструменты ускорили написание кода, и это поменяло структуру рисков, но не убрало их.
Механическая часть перестала быть узким местом. Типовые экраны, формы, выгрузки и тесты собираются в разы быстрее. За счет этого стало возможно раньше показывать работающие куски — а это как раз то, что снижает главный риск, потому что неудобные вопросы всплывают на первых неделях.
Но доля, которая не ускорилась, осталась прежней: понять задачу, договориться о данных, развести противоречия между отделами, спроектировать структуру, которая переживет второй год. Проекты срываются именно здесь, и ни один инструмент этого не закрывает.
Побочный риск стоит назвать прямо: скорость сборки создает иллюзию прогресса. Быстро сделанный интерфейс поверх непродуманной модели данных выглядит как готовый продукт и разваливается на втором месяце эксплуатации.
Что должно быть в договоре
Договор не спасает проект, но определяет, чем закончится плохой сценарий. Минимальный набор пунктов.
- Этапы с отдельной приемкой и оплатой. Чтобы можно было остановиться в любой точке и остаться с работающим результатом.
- Критерии приемки по каждому этапу. Ссылка на ТЗ или список проверок. Без этого приемка превращается в переговоры.
- Сколько итераций правок входит. Обычно две-три на этап. Дальше — по отдельной оценке. Иначе правки становятся бесконечными, и это плохо для обеих сторон.
- Права на код и передача. Код принадлежит заказчику, репозиторий и доступы передаются по этапам, а не в конце.
- Порядок изменений. Как оформляется дополнительная задача и кто оценивает ее влияние на срок.
- Что происходит при расторжении. Что передается, в какой срок, кто оплачивает незавершенный этап.
Пункт про передачу кода по этапам важнее, чем кажется. Если репозиторий у подрядчика и передается «по завершении», то на середине проекта у заказчика нет ничего, кроме оплаченных счетов.
Что делать, если проект уже сорвался
Три варианта, и их стоит рассматривать именно в этом порядке.
Сузить объем. Часто можно выделить работающую часть и запустить ее, а остальное перенести. Это лучше, чем ничего, и дает основу для продолжения.
Сменить порядок работ. Иногда проект стоит не из-за подрядчика, а из-за того, что делается не то. Пересборка плана вокруг одного процесса помогает чаще, чем кажется.
Сменить команду. Крайний вариант, и он стоит дорого: передача занимает недели. Реально возможен только если код и данные у вас, а не у подрядчика.
Посмотрим на проект со стороны
Если проект идет тяжело или только начинается и есть сомнения — опишите ситуацию. В ответ — разбор, где именно риск, что можно сузить и какой минимальный работающий кусок имеет смысл вытащить первым.
Разбор — отдельная работа, она не обязывает продолжать с нами.