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

© Джон Риз

Информация далее рассчитана не на технических специалистов, а на управленцев и заказчиков, принимающих стратегические решения по разработке. Поэтому ничего наподобие «спринт», «покер-планинг», «бэклог» и т.п. разбираться не будет.

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

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

Водопад vs аджайл: четкие требования заказчика и неизменность обстоятельств

На текущий момент можно определить два основных подхода к разработке инструментов автоматизации бизнес-процессов, следовательно, и к оценке сроков и стоимости. Первый и более привычный метод — это водопад (каскад). Придуманный еще в 1970 году он плотно засел в практику. Второй метод более новый, формально закрепленный в 2001 году — это метод гибкой разработки (agile).

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

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

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

Но что происходит в нашей сфере? Сфера включает информационные технологии, рекламу, связи с общественностью и другие компоненты, которые имеют высокую скорость развития и высокую степень изменчивости. То есть, например, разрабатывая систему, направленную на интеграцию с определенной рекламной площадкой для применения заданной рекламной стратегии, можно столкнуться, во-первых, с тем, что рекламная стратегия сработает не так, как ожидалось на начальном этапе, а во-вторых, может случиться так, что к моменту окончания разработки рекламная площадка просто перестанет существовать (так, например, произошло с инструментом «Чат для бизнеса» в результатах поисковой выдачи Яндекса). При таком негативном раскладе проект можно будет отправить в мусорку, а бюджет записать в убытки. А все потому, что обратная связь по проекту поступает слишком поздно: только тогда, когда проект уже практически готов. И это никак не перенести на более ранний этап, т.к. зачастую на раннем этапе водопада смотреть просто нечего. Для конкретики, обычный нешаблонный интернет-магазин у нас запускается за 3-6 месяцев — можно ли было в октябре 2019 года предположить, что в конце марта 2020 года будет объявлен месяц нерабочих дней, а это в свою очередь повлияет на перераспределение финансовых потоков вплоть до государственного федерального уровня? Хотели бы вы не потерять деньги, вложенные в разработку и получить рабочий продукт даже в подобных непредвиденных условиях?

Таким образом, четкие бюджет, сроки и результаты проекта в подобных обстоятельствах оказываются не так уж точны в реальности. А значит риски придется либо разделить на всех, либо кому-то взять на себя.

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

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

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

Экономика проекта: почему не нужна стоимость, и что действительно важно?

Что действительно важно для проекта? Во-первых, это возврат инвестиций (ROI). А во-вторых, критичность потери инвестиций вследствие провала проекта.

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

Что касается второго аспекта, то вне зависимости от методологии разработки при удачном проекте не возникает каких-либо сложностей. Но если проект по какой-либо причине оказывается неудачным, то возникает вопрос минимизации потерь. А для этого надо понимать, в какой момент можно определить «удачность» проекта, и сколько это стоит.

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

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

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

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

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

Лидеры мнений

Ниже приведены две выдержки из статьи с портала РБК. В цитатах управленцев крупных компаний явно прослеживается тенденция.

«Те, кто не освоит Agile сегодня в куче бизнес-процессов, будут лузерами завтра» — такое грозное предупреждение сделал глава крупнейшего российского банка Герман Греф на Гайдаровском форуме в январе 2016 года.

«Здесь очень важны сроки разработки продуктов: если будешь долго делать, то либо конкуренты опередят, либо спрос может пропасть», — рассказывает директор центра инноваций МТС Владимир Хренков. — «Поменялся подход к производству: оказалось выгоднее не сосредоточиваться на долгой разработке больших и сложных продуктов, а в сжатые сроки выпускать так называемый минимально жизнеспособный продукт (MVP) и тут же начинать улучшать его, получая обратную связь от клиентов».

Итог

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

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