Проблемы оценки ИТ-Проектов

Данная статья написана по материалам доклада, прочитанного автором на Конференции Инфостарта IE 2014 29-31 октября 2014 года.
В статье три части. 
•    Первая часть посвящена тем методам оценки, которые встречаются на практике, в том числе, которые я использую. 
•    Во второй части мы разберем наиболее часто встречающиеся ошибки при оценке проектов. Их много, и я собрал десяток наиболее важных.
•    И в третьей части мы поговорим об оценке рисков.

В чем заключается проблема оценки проекта?

Для начала нужно понять, в чем заключается проблема оценки проекта? Откуда она вообще берется?

Все знают классический треугольник – стоимость, функциональность и сроки. Как заказчик и исполнитель взаимодействуют с этими понятиями на практике?

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

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

Методы оценки проектов

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

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

Я эти подходы расположил по порядку увеличения сложности, точности и частоты использования.

Первый метод – я его называю «Три П». Это такой полушуточный метод, который, несмотря на то, что он полушуточный, достаточно часто встречается.

Что же это за метод? Тут нарисована подсказка – пол, палец, потолок.Это вроде как смешно, но такой метод очень часто используется, особенно тогда, когда люди просто не знают, какую стоимость назвать: «а давай скажем вот так».

Что в этом методе хорошего?

• То, что не надо мозг напрягать, можно все сделать быстро и просто.
• Еще этот метод иногда используется, когда заказчик хочет с нами работать, а мы не хотим. И мы, чтобы его отпугнуть, береми называем цифру «с потолка» – это такой простой способ избавиться отклиента (заведомо завышенная сумма).

Правда, есть существенные недостатки:

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

И второй момент – если заказчик спросит, как мы получили эту стоимость, то объяснить будет очень тяжело: «просто у нас такие цены» – больше сказать будет нечего.

Следующий подход – это оценка по аналогии.

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

Что в нем хорошего?

• Если у нас есть такая база, мы можем провести оценку достаточно быстро.
• Это действительно дает определенное обоснование стоимости проекта: во-первых, для себя, ну и для заказчика в том числе.

Но на самом деле, недостатков в таком подходе еще больше.

• Потому что построить подобную базу с адекватной информацией – это очень сложно.

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

• К тому же, меняются технологии: платформа меняется, конфигурации меняются, появляются  новые технологии, которые ни разу не использовались. И если мы, скажем, смотрим на реализацию какого-то требования, а оно было выполнено совершенно другими способами, чем предполагается в этом проекте, то полагаться на такую оценку тоже сложно.
• Также на результат предыдущих работ очень сильно влияют компетенции тех специалистов, которые в них участвовали. Например, если в предыдущей команде у нас были очень компетентные специалисты, которые все сделали быстро и эффективно, а сейчас таких нет, то это также может вызвать трудности в реализации в части соблюдения аналогичных сроков и стоимости.
• В результате получается, что реальная точность оценки «по аналогии» невысока.
• Дополнительно возникает риск наследования явно сделанных ошибок. К примеру, мы тот проект действительно сделали в срок, но у нас три месяца команда работала вообще без выходных, без отпусков, с множеством переработок, а мы этого уже не помним и считаем, что тоже самое можно опять сделать за то же время. Тем самым мы заведомо закладываем для себя подобный режим работы. Это как пример, подобных причин можно назвать множество.

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

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

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

Какие тут достоинства?

• Если человек, который оценивает компетенции команды, достаточно опытен, то точность оценки получается довольно высокая. По крайней мере, я, пользуясь таким подходом, ни разу существенно не ошибался.
• Оценка достаточно быстрая;
• И, что самое главное, такая оценка получается конкурентной по сравнению с промышленными подходами, когда мы сначала проект оценили, его продали, а потом уже будем думать, кто и как это будет реализовывать (процессы оценки и подбора исполнителей разделены). Соответственно, при использовании метода«Экспертно по компетенциям» будет получена более вероятная оценка, потому что здесь ты знаешь не только то, что нужно сделать, но также и точно знаешь компетенции участников команды, знаешь, что эти люди есть и действительно смогут выполнить задачи в определенные сроки.

Но есть и недостатки:

• Потому что в распоряжении руководителя проекта здесь появляется уже определенная фиксированная команда. Но команда – это люди, «человеческий фактор» никто не отменял. Есть риск, что могут возникнуть сложности (заболеть, уволится). Поэтому нужно закладывать какой-то запас ресурсов на этот случай.
• Также могут возникнуть сложности в обосновании полученной оценки заказчику, особенно если это госструктуры, которые начинают задавать вопросы: распишите структуру цены, как вы это получили и т.д. Это сделать можно, но уже придется разъяснять.

Следующий подход я назвал «За сколько купят». Он тоже встречается.

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

• Следовательно, даже если нам самим эта сумма кажется недостаточной для реализации такого проекта, мы все равно можем быть уверены, что если наша оценка приблизительно попадет в эту цифру, то, скорее всего, заказчик будет доволен.
• А уже потом, предварительно поработав с ним, поговорив, объяснив некоторые вещи, мы сможем повлиять на его ожидания и скорректировать требования.
• Фактически, мы можем сразу же делать заказчику предложение по реализации такого проекта, который бы заведомо вписывался в этот бюджет – достаточно велика вероятность, что мы угадаем, и ему это понравится.

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

Из недостатков:

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

• Следующий подход – я его назвал «Сметный».

• Очень часто крупные компании и государственные заказчики требуют предъявить обоснование оценки, и тогда этот подход очень удобен.
• Также такой подход часто применяют для случаев, когда компания одновременно ведет много проектов, то есть – есть общий пул проектов, для которых процессы оценки и выполнения разделены (одни люди оценивают, другие – выполняют). Здесь уже оценка проекта на команду особо не завязана.
• Суть подхода заключается в том, что мы строим некую математическую модель (как правило, в Excel). Получается достаточно простая табличка:
  • встроках максимально подробно расписываются возможные виды работ;
  • в колонках– загрузка специалистов (по ролям);
  • и в ячейках, соответственно, процент загрузки специалистов для каждого вида работ.
• Соответственно, все связывается формулами, и в результате, оперируя процентом загрузки и зная часовую ставку специалиста, можно рассчитать бюджет и показать заказчику, что на проекте будет задействовано столько-то программистов, аналитиков, архитекторов и т.д. на такой-то срок, при такой-то загрузке. Сюда же можно заложить различные коэффициенты дополнительных затрат в виде командировок, рисков и пр.
• Получается достаточно универсальная оценка стоимости, которую потом можно передать руководителю проекта на реализацию.

• Достоинств у такого подхода больше, чем минусов, но минусы, тем не менее, есть:

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

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

  Это, конечно, идеальный вариант, и он наиболее прост в оценке. Здесь предполагается, что предварительно перед проектом:

• Либо было проведено обследование, которое позволило собрать детальные требования.
• Либо было реализовано моделирование системы, которое выявило отклонения от типового функционала.
• Или даже уже было выполнено проектирование системы – выявлено, какие конкретно доработки будут выполняться, составлен подробный перечень работ, чтобы потом по каждому пункту можно было сделать оценку.

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

• Точность при этом получается достаточно высокая. В общем-то, все стороны спокойны, потому что уже известно, что нужно будет делать и сколько это стоит.
• Ну и для заказчика тоже – все понятно, все наглядно.

• А из недостатков:

• Этот подход можно применять только при поэтапной оценке работ.
• К тому же, поскольку на начальном этапе мы все-таки еще не можем быть на 100% уверены, что все пойдет именно так, как мы запланировали (так, как мы хотим), соответственно при реализации проекта могут выясниться ошибки проектирования (например, что-то с методологией не сошлось).

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

• 

• Дальше –несколько слов о научных методах. Их всего три:

• PERT;
• Метод функциональных точек;

• Подробно рассказывать обо всех не буду. Все методы западные, появились достаточно давно, в 50-80х годах. Эти методы предназначены для оценки программных проектов, но, на мой взгляд, применять их на практике в нашей жизни очень сложно. И, хотя в Профкейсе от 1С метод PERT и метод функциональных точек упоминаются (там даже предлагается некая методология по обоснованию их применения), но я об этом сейчас рассказывать не буду, потому что я ни разу не видел применимости этих методов в реальной жизни. Мне кажется, что даже если попробовать их применить для проектов на 1С, то для их адаптации явно придется провести очень серьезную работу.

• И COCOMO (ConstructiveCostModel) – конструктивная стоимостная модель.

Читайте продолжение: Типичные ошибки при оценке ИТ-Проектов. Оценка рисков