Часть 1 Проблемы оценки ИТ-Проектов

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

Итак, первая ошибка заключается в том, что, как я уже говорил, правильно оценить проект без понимания требований в принципе невозможно.

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

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

Вторая ошибка – это полагаться при оценке только на сформулированные заказчиком требования.

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

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

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

Также часто встречается ситуация, когда оценка делается только силами менеджеров по продажам. Например, на одной из конференций (на партнерском семинаре 1С) выступал коммерческий директор одной из крупных фирм-франчайзи 1С, который говорил, что ему не нужны руководители проекта для оценки, он сам лучше них может все оценить и продать.

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

И обратная ситуация – когда оценка ведется только силами технических специалистов.

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

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

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

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

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

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

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

• Причем, чем больше заказчик, тем таких моментов больше.
• Особенно, если это госструктура – там до 50% времени может занять только процесс управления бумажками и прочей бюрократией. И к этому нужно тоже относиться внимательно.

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

• Команда не будет так никогда работать, потому что, во-первых, все люди – они могут потеряться, уволиться и т.д.
• Есть вынужденные перерывы, например, когда заказчику может потребоваться время на осознание и согласование каких-то промежуточных этапов. Все это будет растягивать процесс.
• Даже если программисты будут работать в штатном режиме, вряд ли они будут программировать все 8 часов. Поэтому не рекомендуется закладывать на выполнение какой-то конкретной работы более 60% рабочего времени.
• Нельзя просто так – если вы, допустим, посчитали трудоемкость 100 часов, перевести это в рабочие дни и сказать, что проект будет выполняться столько. Ну не будет он столько выполняться.

Как говорится, в проектном управлении есть такая маленькая шутка – следствие закона Мерфи: «Если в проекте что-то может пойти не так, оно обязательно пойдет не так».

Оценка рисков

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

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

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

Заключение

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

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

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