Все начинается с ошибки

Все началось с того, что я ошибся. И ошибся я очень дорого - неправильно оценил трудоемкость разработки программного продукта, которым занималась моя компания. Ошибка составила более 100%. Мне не помог даже мой 30-ти летний опыт в ИТ и большое количество выполненных проектов различного уровня сложности. Вместо 10 человеко-месяцев я оценил проект в 4. Последствия для нашей небольшой компании были весьма болезненными, мы справились, но боль запомнилась надолго.

Как оказалось, я не единственный человек в мире, который может так ошибаться. Если верить отчету The Chaos Report, собранному по состоянию на 2015 год, лишь 36% проектов завершаются в заданные сроки, 45% - с опозданием и 19% - полностью провалились.

При этом авторы отчета сообщают, что для получения этих показателей им пришлось переосмыслить понятие успешности проекта. Для целей данного отчета проект считается успешным, если его результаты признаются заказчиком “удовлетворительными”. Получается, что если использовать классические характеристики проекта On time, On value и On target, то процент проектов, завершенных вовремя, придется значительно уменьшить.

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

Разработка системы TAURUS, которая была задумана как электронная торговая платформа для UK Stock Exchange, была остановлена в 1993 году. Проект имел множество проблем, связанных, например с ростом требований, что привело к непредвиденному перерасходу средств. В конечном итоге TAURUS обошелся в 75 миллионов фунтов стерлингов.

Проект разработки программного обеспечения для "Экспедиционной системы боевой поддержки" ВВС США был отменен. Несмотря на первоначальные планы, проект выполнялся с большими задержками и ростом стоимости, которая превысила 1,1 миллиарда долларов. В итоге было принято решение о прекращении проекта.

Проект информационных технологий Национальной службы здравоохранения Великобритании (NHS) по созданию централизованной электронной системы медицинских записей, начатый в 2007 году, стал одним из крупнейших ИТ-проектов в мире. Однако проект столкнулся с серьезными проблемами, включая нереалистичные сроки выполнения, недооценку сложности задач и частые изменения в спецификациях. В результате он завершился провалом с суммой затрат около 11,4 миллиарда фунтов стерлингов.

В 2012 году компания Knight Capital из-за жестких сроков существенно сократила этап тестирования своего нового программного продукта. Как следствие возникла критическая ошибка, которая привела к потере 440 миллионов долларов за первые 30 минут торговли.

В чем корни проблемы оценки проектов разработки программных продуктов?

С моей точки зрения, проблема состоит из двух частей: политической и технической.

Политическая составляющая

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

Например: 
- Сколько потребуется времени, чтобы сделать лендинг?
- Не уверен, ну скажем… пару дней, надо подумать.  

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

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

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

Техническая составляющая

Как вообще можно оценить трудоемкость проекта? Мы сейчас говорим не о методах, которые приняты в Agile (покер, очки, футболки и т.п.), речь идет об оценке проекта достаточно большого объема. При этом оценка проводится до начала проекта и, зачастую, на слабо определенном объеме. Хорошо, если есть функциональные или тендерные требования, часто приходится руководствоваться просто описанием задачи.

Методы оценки можно условно разделить на следующие группы:

1. Экспертная оценка (например, метод Дельфи);

2. Оценка по аналогии (например, сравнение с прошлым проектом);

3. Параметрические оценки (например, COCOMO II);

4. Функциональные оценки (например, подсчет функциональных пунктов, анализ сценариев использования, оценка снизу вверх).

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

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

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

Function Point Analysis (FPA) или метод подсчета функциональных пунктов‑ это метод оценки трудоемкости программного обеспечения, который измеряет объем функциональности системы с точки зрения конечного пользователя. Основная идея FPA заключается в том, чтобы оценить систему на основе ее функциональных компонентов, а не строки кода или используемых технологий.

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

Оценку с помощью анализа сценариев использования решили не делать, но надеемся к ней когда-нибудь вернуться.

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

В системе мы будем использовать восходящий метод оценки трудоемкости и стоимости работ. Этот метод рекурсивный. Если у нас есть задача, трудоемкость которой мы не можем оценить, мы разбиваем ее на подзадачи и пытаемся оценить их. И так до тех пор, пока дробление не приведет нас к понятной задаче. Это очень похоже на то, как выполняется планирование в MS Project, однако как подход, так и результаты будут отличаться.

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

Система Project Calc

Для оценки трудоемкости и стоимости проектов мы разработали систему, которая называется Project Calc. Система позволяет выполнять анализ проекта и помогает с принятием решений. Project Calc работает online - нужен только браузер. Регистрация простая, денег за использование online версии мы не берем. Здесь лендинг с презентаций projectcalc.ru, здесь сама система app.projectcalc.ru.

Давайте посмотрим, как она устроена. В системе 5 основных компонентов.

Задачи

Прежде всего нам нужно разбить проект на задачи, задачи на подзадачи и так далее. Каждую задачу мы описываем прежде всего с точки зрения трудоемкости, а точнее, двух значений трудоемкости, которые условно можно назвать “от” и “до”. На самом деле, все чуть-чуть сложнее.

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

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

Здесь я хочу процитировать Стива Макконнелла, автора книги “Сколько стоит программный продукт?”:  “Если не 100%, то сколько? Это один из центральных вопросов в области оценки программных проектов”. Стив Макконнелл в своей книге предлагает считать, что за верхнюю оценку трудоемкости следует принимать такую трудоемкость, которой будет достаточно для реализации задачи с вероятностью в 90%. Иными словами, в 9 случаях из 10 задача будет выполнена в срок. Зачастую, эту формулу довольно сложно рассчитать и допускается упрощение, что задача при такой трудоемкости скорее всего будет выполнена.

Однако если и такой подход к оценке не является для вас понятным и приемлемым, автор книги предлагает вернуться к обычной формулировке: “по нашей оценке трудоемкость этой задачи составит от 2 до 3 человеко-дней”.

Помимо трудоемкости в задаче может быть указана дополнительная стоимость. Это, например, средства на оплату лицензий или покупку оборудования. И, конечно же, задаче желательно назначить исполнителя.

Исполнители

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

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

Документы

Следует отметить, что часто при оценке проекта возникают так называемые “белые пятна в исходных требованиях”. Это требования, по которым не были сформированы задачи. Иными словами эти требования не были учтены при оценке проекта. Можно выделить три основные причины возникновения таких пробелов:

1. Согласно исследованиям, разработчики обычно точно оценивают требования, которые им хорошо понятны. Однако до 30% неясных или плохо сформулированных требований могут быть пропущены, что в итоге приводит к ошибкам в оценке на 20-30%. 

2. Кроме того, “белые пятна” возникают, когда оценку требований выполняют разные подразделения или исполнители. Зачастую, исполнители перекладывают работы друг на друга, что приводит к выпавшим требованиям, которые не взял на себя ни один исполнитель.

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

Для того чтобы бороться с “белыми пятнами”, в системе Project Calc предусмотрен ряд механизмов.

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

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

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

Модификаторы

Модификаторы это переменные, значения которых влияют на состав проекта. По сути модификаторы отвечают на вопрос “А что если?”. Например, “А как изменятся трудоемкость и стоимость проекта, если мы добавим в него авторизацию через Госуслуги (ЕСИА)?”. 

Модификатор выступает как свойство задачи. Задача без модификатора всегда входит в состав проекта. Задача у которой в свойствах есть модификатор, может как учитываться при расчете проекта, так и не учитываться в зависимости от того, какое значение примет модификатор.

Модификаторы бывают 2 типов:

1. Вкл/Выкл (по сути работает как checkbox). Например “Поддержка на сайте темной темы”. Изначально такой модификатор выключен и задача, отмеченная таким модификатором, не входит в состав проекта. При анализе проекта модификатор можно “включить” и посмотреть, как изменится трудоемкость и стоимость проекта.

2. Набор значений (по сути работает как radio button). Например “Способ реализации фронтальной части проекта” может быть следующим: 

   1. Делаем на React;

   2. Делаем на Vue;

   3. Делаем на HTML + JS.

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

Анализ проекта

Когда задачи и исполнители определены, а модификаторы настроены, настало время для анализа проекта. В системе Project Calc большое значение мы придаем механизму визуализации потоков значений - так проще понять в каком соотношении делятся затраты (такие как трудоемкость и стоимость) и откуда они возникают.

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

Далее вы можете изменить конфигурацию проекта - заставить модификаторы принять нужные вам значения. Например, включить модификатор “Поддержка на сайте темной темы” и посмотреть измененную трудоемкость проекта. Одновременно можно переключить модификатор “Способ реализации фронтальной части проекта” с React на Vue и система тут же покажет, как это скажется на проекте. 

Одновременно с этим вы можете выбрать интересующего вас исполнителя, роль или подразделение. Таким образом, с помощью системы можно ответить на вопрос “Какая нагрузка ляжет на команду разработки, если мы делаем проект на Vue и при этом будет реализована поддержка темной темы”.

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

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

Напомню еще раз, лендинг можно посмотреть здесь projectcalc.ru, система здесь app.projectcalc.ru. Для работы в системе предусмотрена простая регистрация, денег за работу в системе не просим, но есть ограничения, например, на число проектов или размер загружаемых документов.

На этом всё, напишите пожалуйста в комментариях:

1. Были ли у вас крупные ляпы при оценки трудоемкости и сроков выполнения проекта?

2. Что вы думаете по поводу такой системы?

3. Насколько бы подобная система помогла их избежать?