Заметка: оценки высокоинтеллектуальных продуктов

Вот уже больше 10 лет я работаю в высокоинтеллектуальной сфере, в веб-разработке, и все это время вижу проблему в оценках подобной работы. Любой заказчик таких продуктов хочет видеть рамки в деньгах и сроках. Это и понятно, бизнес нужно считать в понятных величинах, а не в черных ящиках. А любой исполнитель точно не может оценить 80-90% такой работы, в лучшем случае может очертить примерные рамки, да и то, если у него был опыт построения подобных систем раньше. И чем больше проект, тем сложнее его оценить. Это все равно, что оценивать трудозатраты на изобретение лекарства от рака: вроде бы цель ясна, а как это сделать никто не знает точно и потому не может оценить.

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

Я считаю, что проблемы возникают из-за ряда причин: 1. Все проекты уникальные, нет понятия «делал такое же», в лучшем случае это будет что-то близкое, но все равно его делать нужно заново, а значит, времени и денег в новом проекте будет другое количество 2. Высокоинтеллектуальные продукты имеют тысячи граней и даже опытный специалист не сможет учесть все 3. Очень немногие заказчики предоставляют подробную техническую документацию, чаще всего задание звучит в формате: «Сделайте мне интернет-магазин по типу Амазона» — то есть это просьба оценить классический черный ящик. 4. Любая команда при оценке старается перестраховаться и берет оценку с запасом. 5. Многие разработчики стараются занижать оценку по времени, чтобы выиграть тендер. 6. Многие продажники сознательно умалчивают о ряде сложностей проекта, которые не видит заказчик, но о котором знает подрядчик 7. В процессе работы 99% проектов изменяют требования, а потому меняется оценка времени и бюджета и т.д.

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

Есть несколько важных пониманий, как для заказчика, так и для исполнителя.

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

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

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

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

Так что же делать-то!? Выхода тут два: либо оценивать бюджет и сроки фиксировано, но множить оценку в несколько раз, чтобы точно не выйти за бюджет, либо делать проект мелкими этапами, которые можно заранее оценить. Более правильный для проекта – второй, мелкими этапами. И пока, за всю мою карьеру в ИТ, я не видел более успешного подхода по соотношению конечного бюджета, сроков и качества.