{"id":14293,"url":"\/distributions\/14293\/click?bit=1&hash=05c87a3ce0b7c4063dd46190317b7d4a16bc23b8ced3bfac605d44f253650a0f","hash":"05c87a3ce0b7c4063dd46190317b7d4a16bc23b8ced3bfac605d44f253650a0f","title":"\u0421\u043e\u0437\u0434\u0430\u0442\u044c \u043d\u043e\u0432\u044b\u0439 \u0441\u0435\u0440\u0432\u0438\u0441 \u043d\u0435 \u043f\u043e\u0442\u0440\u0430\u0442\u0438\u0432 \u043d\u0438 \u043a\u043e\u043f\u0435\u0439\u043a\u0438","buttonText":"","imageUuid":""}

Про проекты, которые готовы на 90%

В особенно сложном положении сейчас те, кто остался без команды с почти готовым к запуску продуктом. Казалось бы, основной объем работы выполнен, осталось каких-то 10% финализации, нужен всего-то небольшой рывок на пару недель, ну месяц максимум. К сожалению, это иллюзия.

Том Каргилл из лаборатории Белла в свое время сформулировал шутливое правило 90-90:

Создание 90% кода ПО занимает 90% заложенного времени разработки. Оставшиеся 10% – ещё 90% времени.

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

Проект застревает на этапе feature-complete и никак не переходит в состояние production-ready.

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

Советы тем, кто лишился команды

Сейчас многие резко остались без разработчиков: за неделю мы получили четыре таких обращения. Не стану разбирать причины, думаю и так понятно. Особенно уязвимы оказались клиенты, которые полностью аутсорсили IT и остались без внутренних компетенций.

Самое неправильное в этой ситуации это рассчитывать запуститься в те сроки, которые обсуждались с предыдущей командой и требовать этого от нового исполнителя. Если кто-то возьмется за проект на таких условиях, то только по неопытности. Дальше произойдет следующее — исполнитель быстро перестанет справляться, но будет искренне верить, что все под контролем и и до последнего обещать запуск завтра. У вас испортятся отношения и вы решите найти более опытного исполнителя. Проект в лучшем случае останется на тех же 90% готовности, а в худшем его отбросит назад. Цикл повторится.

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

Это опыт накопленный индустрией. К нам часто приходят с такими проблемами и, не услышав пустых обещаний, покупают только на второй или третий раз, теряя месяцы и годы на преодоление этих «10% до запуска». Нет никаких 10%. Это иллюзия. В реальности есть только неготовый продукт.

0
Комментарии
-3 комментариев
Раскрывать всегда