Проблема оценки проектов

Главная проблема проектной работы – ошибки в оценках. Речь идет и про сроки и про бюджет в проектах по разработке программного обеспечения. Мобильных приложений, сайтов, сервисов и систем.

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

[sendpulse-form id=”278″]

Для чего нужна оценка?

Нужно ли планировать? Можно просто работать как работается и брать за это деньги. Но это не нормальная проектная работа, а продажа людей по часам. Проектная работа, это когда клиент ждет результат за который он платит, а не когда он получает T часов на разработку продукта и N разработчиков.

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

Порядок оценки

Есть сложившийся стереотип о порядке оценки. Клиент говорит, что он хотел бы получить, подрядчик дает оценку.

Рассмотрим ситуацию на двух примерах.

Пример №1. Банк организует тендер на разработку веб-приложения, с помощью которого клиенты смогут самостоятельно выполнять финансовые операции. Готовится тендерная документация, которая описывает требования к приложению, рассылается потенциальным подрядчикам. Клиент ожидает, что на основании задания подрядчики дадут подробную оценку, составят план, предложат концепцию продукта. После чего банк сможет выбрать лучшее предложение.

Пример №2. В компанию по разработке ПО напрямую обращается новостное издание с задачей разработать для них сайт с адаптивной версткой. Какого-либо технического задания нет, в качестве постановки предлагается посмотреть на текущую версию сайта, а задача проекта формулируется как сделать более удобную для пользователей версию.

В обоих примерах заказчик рассчитывает, что потенциальный исполнитель сможет сразу оценить работу и сроки.

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

В чем причина ошибки при оценке

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

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

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

Отличие проектной работы от покупки/продажи в магазине

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

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

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

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

Убрать неопределенности

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

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

О том как правильно сделать предпроектную работу я рассказывал в статьях о предпроектном анализе (Часть 1, Часть 2, Часть 3). Поэтому сейчас поговорим о более простом способе – проектировании.

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

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

Типы проектов

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

И тут мы подходим ко второй ошибке. Проекты бывают разных типов и степень неопределенности, а значит и подход к организации проекта в целом, зависит от типа проекта. Дэвид Майстер, в своей книге “Управление фирмой, оказывающей профессиональные услуги”, описывает три типа проектов — “Мозги”, “Седина” и “Процедуры”. В зависимости от того типа проекта, на котором вы специализируетесь, у вас формируется соответствующий формат работы с клиентом.

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

“Мозги”

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

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

“Седина”

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

“Процедуры”

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

Ошибка идентификации

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

Вместо заключения

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

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