Мы занимаемся заказной разработкой ПО уже 20 лет. И, конечно, в нашей работе и в обсуждениях с коллегами по рынку регулярно всплывают истории о том или ином проекте, который или вообще не стартовал, или испытывал проблемы, а то и вообще завершился неудачно.

Эта статья — часть серии статей, в которых хочется поделиться с сообществом полученным опытом. Скоуп этой статьи — заказная разработка ПО при объёме проекта от 10 до 100 млн руб. в год.

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

Сегодня поговорим об одной из самых, наверное, неприятных проблем — качественной недооценке масштаба проекта заказчиком. Не уровня 20%, а в два-три раза.

Я буду описывать тему с позиции «заказчик — исполнитель» в формате аутсорса, то есть — мы имеем два отдельных не аффилированных юрика и попытку законтрактовать проект по фикспрайсу.

Практически всё это в не меньшей степени применимо и к инхаусу (отношения функциональный заказчик — отдел разработки) и к T&M проектам — в них всё равно есть общее бюджетирование и кратная недооценка объёма проекта всё равно ведёт к провалу.

Начну с конца. Способ избежать проблемы есть, и он известен с середины прошлого века. Это жуткий и ужасный вотерфолл. Если действительно специфицировать задачи и действительно написать план проекта по RUP-у (то есть — не mind map на 20 пунктов, а реальный план пунктов на 400), то точность предсказания взлетает до… до какого числа? Мой опыт говорит, что детальное планирование поднимает точность оценки до +-30% (хотя — кого мы обманываем? до +10…+40%, если честно), и управляемость резко возрастает.

Цена этому удовольствию — порядка 20% от результирующей стоимости. Отсюда, кстати, можно вывести достаточно простое бюджетное правило о выборе проектной методологии. Если проект имеет небольшой масштаб и риск возрастания его бюджета в три раза для экономики заказчика не является существенным, аджайл применять можно и нужно. Если увеличение бюджета втрое убивает или проект, или даже заказчика — заплатить 20% за спокойстиве будет более разумно. Тем более, что и в эджайле эти деньги всё равно будут так или иначе потрачены на детализацию постановки задачи, только уже внутри проекта.

Тут уместны два комментария. Во-первых, работа не по эджайлу это уже забытое искусство, мало кто владеет, и надо выбирать подрядчика с умом. (Если вы обязаны пользоваться инхаусом — всё сложнее. Можно потребовать, чтобы инхаус нанял правильного руководителя проекта.) Во-вторых, опытный аналитик должен формировать требования (или ТЗ, по старо-русски) путём последовательной детализации.

Это значит, что уже затратив 10% от суммы проекта вы должны иметь полностью покрывающие проект, но менее подробные требования. Такие требования позволят оценить масштаб затрат с низкой точностью, но, всё же, с достаточной, чтобы вообще понять, реалистичен ли этот проект финансово, или вообще нет.

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

Случай «я в детстве писал на бейсике, там нет ничего сложного»

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

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

При этом партнёр был всё время убеждён в том, что систему можно было сделать в разы дешевле. По двум причинам.

1. Один из инженеров в команде партнёра непрерывно озвучивал незатейливую мысль — «я когда-то программировал, они вам врут, всё это очень просто, точно говорю». И ему верили.

2. Ну и — у финансового директора был опыт заказа веб-сайтов, и с его точки зрения если работа программиста не видна на экране в виде новой копочки или лампочки — программист ничего не сделал.

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

И это ещё не худший случай!

• У меня сын соседа программирует, он сказал — там нет ничего сложного. (Заказчик с оборотом в 2 млрд)

• (Слили сотрудники дирекции) Директор показал жене, она у него из айти. Она сказала — очень дорого.

• Соседи по рынку делали аналогичный проект, получилось в 4 раза меньше. (Соседи купили готовый продукт и изменили процессы в компании под него. Кстати, итоговые затраты, с учётом изменения процессов, никто толком не считал.)

Бывают и совсем уже странные случаи — один заказчик отказался от внедрения готового продукта, на 90% подходящего под задачу, потому что «разработать с нуля будет дешевле«. Конечно, не будет.

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

Лекарство от этой болезни, конечно, совершенно очевидно — нужно провести конкурентную оценку проекта потенциальными исполнителями, которые имеют опыт успешной реализации проектов подобного масштаба. Но тут нас опять настигает злой вотерфолл, потому что без детализированного ТЗ это нереально. Сравнение   двух оценок по майндмепу на страничке А4 — это профанация, и смысла иметь не будет.

При этом, безусловно, само написание ТЗ — непростая работа. Впрочем, есть известный лайфхак.

1. Напишите ТЗ как умеете. Просто соберите все требования в кучу и свалите их в один документ.

2. Раздайте потенциальным исполнителям. Попросите сделать брейкдаун объёма работ.

3. Запросите у исполнителей риски проекта.

4. Сведите полученные материалы в новое ТЗ и уже его раздайте исполнителям на реальную оценку.

Случай «ядро системы стоит три копейки, интеграция — три рубля»

Мы разрабатывали мобильное приложение и веб-интерфейс для клиентов одной из крупнейших компаний России. Компании с огромным количеством клиентов-физиков. Разработка прошла успешно и система была развёрнута в боевом режиме. Все праздновали победу (проект действительно большой и значимый, и для нас, и для заказчика), и проект перешёл в стадию «развитие функциональности». В рамках базового проекта мы уложились в сроки и стоимость, а развитие всегда категорически менее рискованная часть, чем основная разработка, так что менеджмент с обоих сторон выдыхал и уже не боялся внезапно поседеть.

А зря. В какой-то момент критическая часть пользовательского интерфейса легла в ноль. Мы проверили последний релиз и отрапортовали клиенту, что на нашей стороне никаких масштабных ошибок не допущено — проблема там, внутри, в ландшафте, в одной из систем, с которой мы интегрированы.

Тут надо отметить, что мы для заказчика были новым партнёром, а «та система, с которой мы интегрированы» у них стояла, наверное, уже лет 10, и делал её очень известный на рынке поставщик, продуктовая компания, которая только «той системой» и занимается. И ответ от них был прост: «у нас всё работает«.

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

Мы бросили всё, распределили людей в смены по 8 часов и начали круглосуточное расследование инцидента.

Что выяснилось. Крутой поставщик крутого продукта накатил новую версию сервера SOAP API. Сервер был кластеризован, и на одну ноду кластера обновление выложили, а на вторую — нет. Ноды отвечали через балансировщик случайным образом.

Причём WDSL (спецификацию API) чаще выдавал один узел, а на сами запросы чаще отвечал второй.

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

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

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

Случай «интеграция с движущейся целью»

Чего уж говорить про самый классический случай — «у нас там стоит система А, но мы уже меняем её на систему Б, так что интегрируйтесь сразу с системой Б, только она пока не готова, но там замечательные ребята, они вам всё сделают«.

Надо ли говорить, что в таком случае исполнитель оказывается в совершенно трешовой ситуации? Нет, система Б не будет готова ни к сроку, ни через год. Нет, замечательные ребята никакого коннектора не сделают, у них его просто нет в ТЗ, и никто его туда не добавит, потому что это новый бюджет, а его нет. А если сделают по доброте душевной, то он устареет через месяц, да и вообще — к моменту, когда вы будете сдавать проект они свой проект не сдадут, и ничего у вас не заработает, и да, виноваты будете именно вы, а кто же? Пушкин?

У грамотного руководителя проекта в этой ситуации есть несколько вариантов.

1. Честный. Написать в плане — «интеграция с системой А, доработки интеграции по мере развития системы А, интеграция с системой Б (за рамками данного проекта)«, и пытаться это согласовать.

2. Опасный. Своевольно сделать интеграцию с А и в конце проекта подписать изменение ТЗ, потому что Б не готова. Если Б будет готова, то исполнитель попал на деньги.

3. Оппортунистический. Не делать ничего, в конце продавить выкидывание интеграции, потому что Б не готова. В реальности не сработает — интеграции редко бывают опциональными.

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

Теоретически можно зафиксировать API интеграции в ТЗ и таким образом исполнитель снизит свои риски, но мы же говорим не о рисках исполнителя, а о бюджете проекта. Любая интеграция — дыра в оценке бюджета. Две интеграции — катастрофа. Три — нереально оценить вообще, особенно если они связаны.

Кто виноват и что делать: выявить в проекте MVP, который заработает с минимальными интеграциями. Добавлять интеграции по одной отдельными субпроектами. Да, это не всегда возможно. Но любой вменяемый исполнитель увидев в проекте три интеграции во внутреннем обсуждении проекта в этом месте обведёт пункт ТЗ красным и добавит туда минимум +100% к любой вменяемой оценке.

Случай «Пётр Петрович в отпуске, зам не может вас принять»

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

У нас были проекты, которые запускались неделю (пришёл партнёр, принёс задачу, я слетал 6-го января к клиенту на дальний восток чтобы согласовать детали, а выйдя из новогоднего отпуска сотрудники уже приступили к проекту) и были запуски по три года.

Надо ли говорить, что в первом случае все согласования занимали день-два, а во втором — месяц-два?

Если вы полгода готовите тендер и полгода его проводите, то все потенциальные исполнители во все свои проектные планы пишут (но вам не показывают) блоки «клиент задерживает подписание ТЗ«, «клиент не находит времени посмотреть на релиз«, «клиент не успевает выделить сервера под продакшен» и прочие «клиент не успевает«.

Теоретически команду проекта в это время можно было бы задействовать где-то ещё, практически если удастся сделать это на 10% — ура, у нас праздник. Поэтому все блоки «клиент не успевает» пойдут в простой команды, который оплатит клиент. А кто ещё? Пушкин?

Нет, конечно, опытный менеджер проекта постарается распланировать параллельные работы так, чтобы неторопливость клиента в одном потоке не останавливала другие, но бесследно это всё равно не проходит. Полностью исключить простои не получится, да и переключение команды с одной части проекта на другую стоит времени == денег.

Опытный подрядчик обязательно пропишет в контракте (или хотя бы в уставе проекта) ответственность со стороны заказчика и сроки реакции, но это ничего не изменит в реальности — если компания заказчика неповоротлива, то никакие контракты и штрафы это не изменят.

Проект станет дороже, и всё тут.

Случай «да чего там деплоить»

— Мы готовы к передаче проекта на вашу площадку
— Отлично, передавайте
— Куда? Кто принимает?
— Гм, надо подумать. А, ну вот — Василий
— Василий, куда нам выкладывать?
— На сервер…
— Дайте доступ, Василий!
— А… я не умею.

Конечно же при старте проекта мы согласовали с заказчиком технологии, требования к железу и уточнили, что заказчик будет сам эксплуатировать систему и знает, как это делать. В итоге пришлось физически выезжать на площадку заказчика, чтобы настроить на сервере sshd. Способных на это местных специалистов не оказалось.

Естественно, за этим последовал совершенно незапланированный объём работ по разворачиванию и базовой поддержке проекта на площадке заказчика.

Административную часть проекта легко недооценить. Тестовые и продакшен сервера, домены, сертификаты, тоннели и настройки файерволла для взаимодействия компонент, процедуры разворачивания, бекап, апдейт работающей системы — всё это целый блок в плане работ. Причём, что неприятно, именно на малых проектах импакт от всей этой деятельности в процентном отношении  максимален. То есть — сильнее всего влияет на цену.

Впрочем, и в больших проектах бывают очень ощутимые по затратам работы в области девопс. Для одной mission critical системы мы спроектировали механизм апдейта сервиса, который включал в себя кластер тестирования на нашей стороне (тестирование в процессе подготовки релиза), отдельный и независимый кластер тестирования на стороне заказчика (его очищали в ноль, проводили на нём сборку и чистый тест релиза перед деплоем) и разделённый на две половины боевой кластер. В часы наименьшей нагрузки половину этого кластера останавливали, накатывали на него новую версию, потом переключали на него боевую нагрузку на час. Через час успешной работы накатывали апдейт на вторую половину кластера.

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

Добавление девятки в надёжность системы запросто может стоить добавления нуля в её стоимость.

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

Конечно. Только сразу умножайте стоимость проекта на два. И это не шутка. Пятница — показ, день убит. Четверг — внутренний прогон перед показом и срочный багфикс. Мы же не покажем сырой билд! Среда — слияния веток и подготовка релиза. Ну — полсреды ещё получится поработать.

On the other side, реже раза в месяц тоже нельзя. Никак.

Случай «Письмо дяди Фёдора из Простоквашино»

Мы собираемся делать новую систему на заказ. Крутую, которая решит все наши проблемы.

Отдел маркетинга составил ТЗ, отдел продаж дописал хотелки, директор по развитию вспомнил все свои мечты начиная с 13 лет, практиканты Петя и Коля вставили отрывок из школьного сочиения «как я хотел провести лето» а помощница босса Людочка показала мужу, он у неё сисадмин. Он тоже кое-что дописал. Пять девяток и микросервисную архитектуру, а фиг ли.

Ну а как же — один раз живём, всё надо вписать в ТЗ.

На эту тему, конечно, надо написать отдельный материал, и, наверное, я это сделаю.

А здесь скажу просто. Против каждого блока функциональности в ТЗ надо написать, сколько денег это принесёт компании в следующие пять лет, и как именно. И поставить подпись того, кто за это отвечает.

Если говорить более конкретно, то ПЕРЕД ТЗ должен существовать документ, который имеет явные признаки бизнес-плана, то есть расписывает бизнес-цели, методы их достижения и доходную часть мероприятия.

Подрядчик за такой документ вас просто расцелует. И да, в процессе его написания выяснится, что из письма дяди Фёдора можно (нужно!) выкинуть 90%. Это снизит стоимость проекта и резко повысит шансы успешной его реализации.

Подводя итоги

Может показаться, что в эпоху ИИ что-то из вышесказанного изменилось. Нет.

ИИ не будет отвечать за невменяемый и нереалистичный бизнес-план, не знает, насколько хороши ваши сисадмины и не будет ревьюить за вас документы. То есть — будет, но за результат всё равно придётся отвечать кому-то с руками и ногами.

Что важно: подрядчик не менее вас заинтересован в том, чтобы проект состоялся. Вообще-то даже более.

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

И все эти риски подрядчик знает. И точно готов их с вами обсудить и минимизировать. Контактируйте с ним.

Он поможет. Мы — так уж точно.