Как правильно оценивать проекты

Май, 2017

#Тезисы

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

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

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

Забегая вперед скажу, что Agile не панацея, но об этом в следующих материалах.

Кроме текстового варианта есть видеоролик

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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