В чем заключается проблема оценки проекта?
Для начала нужно понять, в чем заключается проблема оценки проекта? Откуда она вообще берется?
Все знают классический треугольник – стоимость, функциональность и сроки. Как заказчик и исполнитель взаимодействуют с этими понятиями на практике?
Естественно, заказчик хочет, чтобы было сделано как можно больше функциональности за как можно меньшую стоимость. И, соответственно, настаивает на своем. А исполнитель, разумеется,заинтересован в том, чтобы бюджет был как можно больше, а функциональность как можно меньше. Для него это идеальный вариант, потому что он борется за рентабельность. И в результате они либо приходят к согласию, либо нет.
Вообще правильнее оценивать не некий процесс выполнения проекта, а конечный результат –тогда проект будет стоить столько, сколько стоит его результат. Но поскольку результата, как известно, всегда можно достигать разными путями, то мы, меняя путь выполнения проекта, применяя какие-то особые методологии управления проектом и т.д., можем весьма существенно влиять на конечную стоимость. И, если исходить из этого, то получается, что практически любой проект можно сделать за любой бюджет. В частности, маленький проект можно сделать за колоссальный бюджет – это очень просто. А большой проект можно сделать за маленький бюджет (что гораздо сложнее). Вопрос только в том, как к этому подходить. Например, в качестве одного из инструментов по уменьшению стоимости проекта может быть перенос какой-то части работ и ответственности на самого заказчика. И, соответственно, двигая эту планку уровня ответственности между исполнителем и заказчиком, можно очень существенно влиять на этот процесс.
Методы оценки проектов
Поэтому для начала мы поговорим о тех подходах к оценке проектов, которые встречаются на практике. Когда я проанализировал все свои проекты за последние годы (в том числе и те, которые я выполнял с другими командами), у меня получилось всего 9 подходов.
Шесть из них наиболее простые и часто встречаются в практике. Остальные три – это научные западные подходы, которые в реальной жизни я сам не использую, и никогда не видел, чтобы кто-то их использовал. Поэтому я их просто назову, возможно, они покажутся вам интересными.
Я эти подходы расположил по порядку увеличения сложности, точности и частоты использования.
Первый метод – я его называю «Три П». Это такой полушуточный метод, который, несмотря на то, что он полушуточный, достаточно часто встречается.
Что же это за метод? Тут нарисована подсказка – пол, палец, потолок.Это вроде как смешно, но такой метод очень часто используется, особенно тогда, когда люди просто не знают, какую стоимость назвать: «а давай скажем вот так».
Что в этом методе хорошего?
- То, что не надо мозг напрягать, можно все сделать быстро и просто.
- Еще этот метод иногда используется, когда заказчик хочет с нами работать, а мы не хотим. И мы, чтобы его отпугнуть, береми называем цифру «с потолка» – это такой простой способ избавиться отклиента (заведомо завышенная сумма).
Правда, есть существенные недостатки:
- Угадать какой-то реалистичный бюджет в этом случае, скорее всего, не получится. Это лотерея, в которую играть лучше не стоит, потому что можно очень сильно ошибиться.
И второй момент – если заказчик спросит, как мы получили эту стоимость, то объяснить будет очень тяжело: «просто у нас такие цены» – больше сказать будет нечего.
Следующий подход – это оценка по аналогии.
Это очень распространенный метод, его рекомендуют использовать многие специалисты. Он заключается в том, что мы оцениваем текущий проект по аналогии с теми, которые были у нас в прошлом. Для этого, конечно, у нас должна быть база данных, в которой хранится информация по реализованной функциональности, как ее оценивали, как ее выполняли.
Что в нем хорошего?
- Если у нас есть такая база, мы можем провести оценку достаточно быстро.
- Это действительно дает определенное обоснование стоимости проекта: во-первых, для себя, ну и для заказчика в том числе.
Но на самом деле, недостатков в таком подходе еще больше.
- Потому что построить подобную базу с адекватной информацией – это очень сложно.
Если только вы не занимаетесь одинаковыми типовыми проектами, допустим,внедряете какие-то одинаковые конфигурации – я, все-таки, имею в виду оценку работ с более сложной спецификой.
- К тому же, меняются технологии: платформа меняется, конфигурации меняются, появляются новые технологии, которые ни разу не использовались. И если мы, скажем, смотрим на реализацию какого-то требования, а оно было выполнено совершенно другими способами, чем предполагается в этом проекте, то полагаться на такую оценку тоже сложно.
- Также на результат предыдущих работ очень сильно влияют компетенции тех специалистов, которые в них участвовали. Например, если в предыдущей команде у нас были очень компетентные специалисты, которые все сделали быстро и эффективно, а сейчас таких нет, то это также может вызвать трудности в реализации в части соблюдения аналогичных сроков и стоимости.
- В результате получается, что реальная точность оценки «по аналогии» невысока.
- Дополнительно возникает риск наследования явно сделанных ошибок. К примеру, мы тот проект действительно сделали в срок, но у нас три месяца команда работала вообще без выходных, без отпусков, с множеством переработок, а мы этого уже не помним и считаем, что тоже самое можно опять сделать за то же время. Тем самым мы заведомо закладываем для себя подобный режим работы. Это как пример, подобных причин можно назвать множество.
Тем не менее, этот метод живет, его используют – все при оценке, так или иначе, полагаются на свой предыдущий опыт, к чему надо относиться с осторожностью.
Дальше идет мой самый любимый метод. Я назвал его «Экспертно по компетенциям». В большинстве случаев именно им и пользуюсь. Правда, нельзя сказать, что этот метод можно порекомендовать всем, потому что к нему нужно сначала привыкнуть, к тому же он применим только при командном подходе.
В чем суть метода? В том, что руководитель проекта прикидывает, сколько времени уйдет на реализацию такого-то проекта при уже имеющейся команде (здесь предполагается, что состав и компетенции участников команды известны заранее). Соответственно, исходя из предположения, что эти люди будут задействованы только на этом проекте, можно прикинуть конечные сроки реализации и рассчитать ФОТ участников команды (плюс у всех компаний есть свои нюансы – свои накладные расходы, своя норма прибыли). Так или иначе, собрав всю эту информацию, можно получить общий бюджет. Ну а сроки проекта, естественно, нужно будет потом скорректировать, потому что сроки складываются не из непрерывной загрузки, а следует закладывать в них также перерывы на согласование и прочие вещи (отпуска, переключение на срочные задачи и т.п.).
Какие тут достоинства?
- Если человек, который оценивает компетенции команды, достаточно опытен, то точность оценки получается довольно высокая. По крайней мере, я, пользуясь таким подходом, ни разу существенно не ошибался.
- Оценка достаточно быстрая;
- И, что самое главное, такая оценка получается конкурентной по сравнению с промышленными подходами, когда мы сначала проект оценили, его продали, а потом уже будем думать, кто и как это будет реализовывать (процессы оценки и подбора исполнителей разделены). Соответственно, при использовании метода«Экспертно по компетенциям» будет получена более вероятная оценка, потому что здесь ты знаешь не только то, что нужно сделать, но также и точно знаешь компетенции участников команды, знаешь, что эти люди есть и действительно смогут выполнить задачи в определенные сроки.
Но есть и недостатки:
- Потому что в распоряжении руководителя проекта здесь появляется уже определенная фиксированная команда. Но команда – это люди, «человеческий фактор» никто не отменял. Есть риск, что могут возникнуть сложности (заболеть, уволится). Поэтому нужно закладывать какой-то запас ресурсов на этот случай.
- Также могут возникнуть сложности в обосновании полученной оценки заказчику, особенно если это госструктуры, которые начинают задавать вопросы: распишите структуру цены, как вы это получили и т.д. Это сделать можно, но уже придется разъяснять.
Следующий подход я назвал «За сколько купят». Он тоже встречается.
Допустим, у нас есть какая-то инсайдерская информация, и мы знаем, что у заказчика на проект потенциально заложен такой-то бюджет.
- Следовательно, даже если нам самим эта сумма кажется недостаточной для реализации такого проекта, мы все равно можем быть уверены, что если наша оценка приблизительно попадет в эту цифру, то, скорее всего, заказчик будет доволен.
- А уже потом, предварительно поработав с ним, поговорив, объяснив некоторые вещи, мы сможем повлиять на его ожидания и скорректировать требования.
- Фактически, мы можем сразу же делать заказчику предложение по реализации такого проекта, который бы заведомо вписывался в этот бюджет – достаточно велика вероятность, что мы угадаем, и ему это понравится.
Честно говоря, этот метод очень редко применим, потому что мы почти никогда не знаем, какой потенциальный бюджет действительно выделен на проект – это, как правило, информация конфиденциальная, и ее никому не говорят.
Из недостатков:
- Конечно же, заказчик может захотеть, чтобы за тот маленький бюджет, который он выделяет, мы сделали чрезмерно много (столько, сколько физически сделать невозможно) и договариваться он не хочет – тогда, скорее всего, в такой проект уже лучше не вписываться.
Следующий подход – я его назвал «Сметный».
- Очень часто крупные компании и государственные заказчики требуют предъявить обоснование оценки, и тогда этот подход очень удобен.
- Также такой подход часто применяют для случаев, когда компания одновременно ведет много проектов, то есть – есть общий пул проектов, для которых процессы оценки и выполнения разделены (одни люди оценивают, другие – выполняют). Здесь уже оценка проекта на команду особо не завязана.
- Суть подхода заключается в том, что мы строим некую математическую модель (как правило, в Excel). Получается достаточно простая табличка:
- встроках максимально подробно расписываются возможные виды работ;
- в колонках– загрузка специалистов (по ролям);
- и в ячейках, соответственно, процент загрузки специалистов для каждого вида работ.
- Соответственно, все связывается формулами, и в результате, оперируя процентом загрузки и зная часовую ставку специалиста, можно рассчитать бюджет и показать заказчику, что на проекте будет задействовано столько-то программистов, аналитиков, архитекторов и т.д. на такой-то срок, при такой-то загрузке. Сюда же можно заложить различные коэффициенты дополнительных затрат в виде командировок, рисков и пр.
- Получается достаточно универсальная оценка стоимости, которую потом можно передать руководителю проекта на реализацию.
Достоинств у такого подхода больше, чем минусов, но минусы, тем не менее, есть:
- Как я уже говорил, при неумелом подходе такая оценка может оказаться несколько завышенной.
- К тому же, там все-таки есть доля субъективизма. Если говорить о госзаказах, на данном этапе требования к задачам еще не выявлены, а без детализации требований распланировать, сколько нам нужно специалистов на тот или иной этап, достаточно сложно. Но, поскольку другой информацией мы, как правило, не располагаем, то приходится применять такой метод.
Ну и последний из тех методов, которые наиболее часто встречаются на практике, – это оценка по детальному перечню работ.
Это, конечно, идеальный вариант, и он наиболее прост в оценке. Здесь предполагается, что предварительно перед проектом:
- Либо было проведено обследование, которое позволило собрать детальные требования.
- Либо было реализовано моделирование системы, которое выявило отклонения от типового функционала.
- Или даже уже было выполнено проектирование системы – выявлено, какие конкретно доработки будут выполняться, составлен подробный перечень работ, чтобы потом по каждому пункту можно было сделать оценку.
Сложность подобного подхода состоит в том, что на предпродаже такого уровня детализации достичь невозможно – для того, чтобы иметь на руках детализированные требования, нужно какой-то этап проекта уже выполнить. И здесь всегда возникает дилемма, что либо эти большие затраты нужно произвести за свой счет, либо этот этап работ все-таки нужно как-то предварительно продать сам по себе. Например, объяснить заказчику, что на выходе будет у нас уже реалистичная достоверная оценка, и там будет понятно, как потом в дальнейшем реализовывать этот проект.
- Точность при этом получается достаточно высокая. В общем-то, все стороны спокойны, потому что уже известно, что нужно будет делать и сколько это стоит.
- Ну и для заказчика тоже – все понятно, все наглядно.
А из недостатков:
- Этот подход можно применять только при поэтапной оценке работ.
- К тому же, поскольку на начальном этапе мы все-таки еще не можем быть на 100% уверены, что все пойдет именно так, как мы запланировали (так, как мы хотим), соответственно при реализации проекта могут выясниться ошибки проектирования (например, что-то с методологией не сошлось).
Также возможны изменения требований, несмотря на то, что будущие детализированные требования вроде бы уже прописаны.
Это, кстати, к вопросу о необходимости дополнительного использования гибких методологий разработки.
Дальше –несколько слов о научных методах. Их всего три:
- PERT;
- Метод функциональных точек;
- И COCOMO (ConstructiveCostModel) – конструктивная стоимостная модель.
Подробно рассказывать обо всех не буду. Все методы западные, появились достаточно давно, в 50-80х годах. Эти методы предназначены для оценки программных проектов, но, на мой взгляд, применять их на практике в нашей жизни очень сложно. И, хотя в Профкейсе от 1С метод PERT и метод функциональных точек упоминаются (там даже предлагается некая методология по обоснованию их применения), но я об этом сейчас рассказывать не буду, потому что я ни разу не видел применимости этих методов в реальной жизни. Мне кажется, что даже если попробовать их применить для проектов на 1С, то для их адаптации явно придется провести очень серьезную работу.
Типичные ошибки при оценке
Дальше я расскажу об основных ошибках при оценке, которые встречаются. Я выделил10 самых главных ошибок. Первые три связаны с требованиями.
Итак, первая ошибка заключается в том, что, как я уже говорил, правильно оценить проект без понимания требований в принципе невозможно.
- Нужно постараться приложить как можно больше усилий для того, чтобы перед ответом на вопрос «Сколько это будет стоить?» сначала понять, что же конкретно мы должны сделать. Очень большая ошибка - вписываться в проект, требования к которому слишком общие, потому что правильно оценить его практически нереально (либо нужно заведомо закладывать большие риски).
- При этом нужно обязательно учитывать, знаем ли мы те технологии, которые предполагается использовать в проекте. Допустим, если результат должен опираться на какие-то новые технологии, которые мы ни разу не использовали, но нам кажется, что они работают – это вовсе не означает, что все будет так просто, как мы хотим.
Ну и, как я уже говорил, по возможности нужно давать оценку хотя бы после какого-то предварительного обследования. Не сразу по перечню требований, которые влезают на один листик, как это иногда случается.
Вторая ошибка – это полагаться при оценке только на сформулированные заказчиком требования.
Часто случается, что на уровне руководства согласовываются некие требования, и нам говорят, что нужно сделать вот это. Но только по факту там может быть очень много нюансов и ошибок, потому что эти требования составляли совсем не те люди, которые потом будут пользоваться или принимать эту систему. И когда мы потом начинаем делать проект, то оказывается, что все совсем не так, либо то, что нам изначально дали – это какая-то малая доля, которая никогда не будет достигнута, пока мы не сделаем еще в 10 раз больше других необходимых работ. Поэтому нужно стараться выявлять требования непосредственно у тех людей, которые будут потом пользоваться системой.
Третья ошибка заключается в том, что, если у компании не заложено никакого процесса по управлению изменениями требований на стадии реализации, то сам процесс оценки заведомо будет ошибочным, потому что мы, все-таки, всегда оцениваем в проекте какие-то границы и рамки.
Если мы при реализации проекта не сможем управлять изменениями (ограничивать возникающие новые требования и т.д.), то мы все равно выйдем за границы, а этого нужно стараться не допустить.
Также часто встречается ситуация, когда оценка делается только силами менеджеров по продажам. Например, на одной из конференций (на партнерском семинаре 1С) выступал коммерческий директор одной из крупных фирм-франчайзи 1С, который говорил, что ему не нужны руководители проекта для оценки, он сам лучше них может все оценить и продать.
Да, он продать может, причем хороший менеджер по продажам продаст не только заказчику, но еще и убедит свое руководство и проектную команду в том, что он все правильно оценил. Однако совсем не факт, что это действительно будет так – все выяснится во время реализации.
И обратная ситуация – когда оценка ведется только силами технических специалистов.
Дело в том, что, как правило, программисты склонны переоценивать свои возможности, и это, скорее всего, будет недооценка. А руководитель отдела разработки, наоборот, склонен закладывать в оценку слишком большие риски, перестраховываться – может получиться переоценка. Поэтому здесь правильнее создавать симбиоз менеджера по продажам с техническими специалистами. Кстати, есть такая статистика - чистое время программиста, которое ему требуется для реализации задачи можно помножить на 3-3,5 раза. Получится реальная трудоемкость от постановки задачи до ее передачи пользователю (куда войдет тестирование, обучение и пр.).
Следующая ошибка – это отсутствие процесса оценки как такового. Чтобы правильно оценить проект, процесс оценки в компании должен быть хоть как-то построен. Он может быть простым или сложным, но это должен быть выделенный процесс оценки – должны быть расписаны конкретные шаги процесса, его начало и окончание. Не должно быть такого, что разные люди в разное время и разными способами хаотично оценивали проекты, иначе постоянно будет какой-то вероятностный фактор – результат вообще будет непонятен.
Еще одна ошибка – применение излишне формальных подходов к оценке. Допустим, мы выработали некий метод оценки, и постоянно ему слепо следуем – этого нужно стараться избегать.
- Нужно учитывать ошибки и находить для себя наиболее подходящий вариант.
- Лучше применять те методы, которые давали хороший результат.
- Излишнюю бюрократию тоже устраивать не нужно.
Еще важный момент: бывает, что в проект изначально закладывают новую технологию – допустим, вышло какое-то новое решение от 1С, или вышла новая платформа, появились новые возможности. К подобным экспериментам всегда нужно относиться с осторожностью:
- Нет никакой гарантии, что если новые возможности задекларированы, они в этом проекте заработают.
- Вполне возможно, что это будет не так, и, соответственно, могут возникнуть очень большие проблемы
Также весьма большую трудоемкость в проекте могут занимать сами процессы согласования результатов работ и различного рода документации. Часто этот момент просто игнорируют: оценили стоимость разработки, стоимость внедрения – и все.
- Причем, чем больше заказчик, тем таких моментов больше.
- Особенно, если это госструктура – там до 50% времени может занять только процесс управления бумажками и прочей бюрократией. И к этому нужно тоже относиться внимательно.
Ну и последняя ошибка – это при расчете сроков проекта заложить, что вся команда будет работать полный рабочий день, по 8 часов в день.
- Команда не будет так никогда работать, потому что, во-первых, все люди – они могут потеряться, уволиться и т.д.
- Есть вынужденные перерывы, например, когда заказчику может потребоваться время на осознание и согласование каких-то промежуточных этапов. Все это будет растягивать процесс.
- Даже если программисты будут работать в штатном режиме, вряд ли они будут программировать все 8 часов. Поэтому не рекомендуется закладывать на выполнение какой-то конкретной работы более 60% рабочего времени.
- Нельзя просто так – если вы, допустим, посчитали трудоемкость 100 часов, перевести это в рабочие дни и сказать, что проект будет выполняться столько. Ну не будет он столько выполняться.
Как говорится, в проектном управлении есть такая маленькая шутка – следствие закона Мерфи: «Если в проекте что-то может пойти не так, оно обязательно пойдет не так».
Оценка рисков
По итогам проектов нужно стараться накапливать базу потенциальных рисков, которые вообще могут возникнуть. На начальном этапе можно сесть и вспомнить все проблемы, которые возникали в последних проектах (неважно, по каким причинам), и выписать весь этот перечень.
Пример проблемы: необходимость наличия удаленного доступа. Заказчик пообещал, что у вас будет удаленный доступ, чтобы было проще работать. Вы подписали контракт, но этого нигде не указали. А когда к нему пришли, он сказал: «оказывается, у нас служба безопасности это запрещает, и у вас не будет удаленного доступа». Соответственно, вам теперь приходится каждый раз ездить к нему, и ваши затраты сразу резко возрастают.
- Следовательно, у вас должен быть где-то зафиксирован перечень тех проблем, которые могут возникнуть.
- А когда вы беретесь за новый проект, вы просматриваете весь этот перечень возможных рисков, накладывая его в уме на текущую ситуацию, и анализируете, что из этого может быть актуально конкретно в данном проекте. Получается уже некий более узкий перечень из тех проблем, которые мы хотим решить непосредственно здесь.
- И, по сути, каждое такое опасение нужно проработать, постараться примерно оценить его для себя в деньгах. Если вы считаете, что в данном проекте конкретная проблема ничтожно мала, и если она и случится, то у вас ничего страшного не произойдет – ее можно игнорировать. Но если проблема действительно существенна, то, по крайней мере, ее надо как-то задокументировать. То есть, вы озвучиваете заказчику, что у вас есть такое опасение – и тогда возможны два варианта:
- Первый вариант – это когда заказчик берет ответственность на себя и говорит: «если это случится, я проблему решу». Тогда вы фиксируете в договоре, что заказчик берет эту ситуацию на себя.
- И второй вариант – когда он говорит: «нет, я этого не решу, но этого не случится».Тут уже вы можете заложить риск в бюджет как некий оцененный, как опасение, что такая проблема может произойти, и это уже может проходить у вас как определенное обоснование цены.
Заключение
В заключение скажу о необходимости непрерывного совершенствования процедуры оценки.
- После каждого проекта обязательно нужно сравнить планируемую оценку с реальными затратами: посчитали по факту, какие работы выполнялись, какие трудозатраты на это пошли – сравнили их с планом.
- Это позволит сделать выводы для внесения уточнений в саму процедуру оценки, чтобы ее непрерывно совершенствовать. Потому что если оценка окажется хаотична – значит, никакого процесса оценки как такового не было.
Также очень важно, чтобы при проведении такого анализа учитывалась эффективность управления проектом. Потому что для одной и той же задачи может оказаться, что один руководитель проекта может ее выполнить успешно, а другой ее полностью завалит, либо понесет большие убытки. И в данном случае неуспех не означает, что оценка была изначально сделана неправильно (она, может быть, была и правильной) – просто нужно всегда учитывать наличие ошибок в управлении.
***************
Приглашаем вас на новую конференцию INFOSTART EVENT 2019 INCEPTION.
