Оценка проекта

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

Данный материал — мой субъективный взгляд на экспертное оценивание IT-проектов.

Бизнес Идея

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

Для проверки бизнес идеи я использую следующую формулу:

Примеры:

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

Бывали конечно случаи, что “без NDA вы идею нашего ноу-хау не услышите”, но это легко решаемо, хотя и слегка затягивало оценку. А вот куда как чаще сталкивался с тем, что заказчик уже думает, куда потратить заработанное, а не то, какую проблему пользователей будет решать его детище ¯\_(ツ)_/¯.

Гипотезы

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

Простой пример требования без конкретики:
— Нужна авторизация через социалки

Естественно, вы захотите запросить список тех самых социалок, но ответы будут «завтра», а оценка нужна «на вчера». Поэтому что нам остаётся делать? Выдвигаем гипотезу, делаем по ней оценку, и формируем список вопросов:

гипотеза	оценка	вопрос
авторизация посредством Facebook и Twitter	24ч	уточнить список социалок

Гипотезы, предположения, примерные расчёты — используйте всё, чтобы дать оценку. Ведь даже такая оценка лучше, чем отмазки вида «ничё непонятно» или «подождём, что ответит заказчик».

Давайте рассмотрим ещё один пример:
– Во сколько мне обойдётся хранилище S3 для моего фотоблога?

Формулируем гипотезу:
— Размер 12mpx фото в JPG ~10mb
— В день ~10 фото
— В месяц +300 фото, пусть +3Gb
— Открываем калькулятор AWS S3 и прикидываем сумму

И уже потом можно уточнить какого размера фотографии, и сколько фотографий планирует публиковать автор блога

Данный подход можно использовать и не в IT:
— Сколько ступенек в 9-ти этажке?

Мои размышления:
— 1 этаж ~3 м
— 1 ступенька ~20 см
— ~> 15 ступенек на этаж, т.к. лестничные пролёты делают из одинаковых элементов, то пусть 2 пролёта по 8 ступеней на этаж
— + 1 пролёт до 1-го этажа
— Итого 2 х 8 х 8 + 8 = 136 ступенек

Можно начать уточнять детали, найти ГОСТы, рекомендации, готовые изделия и прочее. И останется лишь внести небольшие правки в расчёт. Но уже сейчас я уверен, что порядок цифр назвал правильно.

Одно время в списке “вопросов Гугла на собеседовании” фигурировал вопрос:
— Сколько шариков для гольфа поместится в школьный автобус?

Мне кажется, на этот вопрос вы уже сможете дать ответ, оставляйте его в комментариях ;)

Вопросы

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

Связанные вопросы стоит задавать сразу, а не ждать следующей серии вопросов-ответов:

• вам нужна поддержка мобильных устройств?
• какие разрешение мобильных устройств мы должны поддерживать?

Не нужно задавать вопросы, ответы на которые не влияют на оценку, оставьте это уже для следующих этапов:

• какую палитру вы хотите использовать для сайта?
• сайдбар будет слева или справа?

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

• какой фреймворк лучше выбрать? Angular, React или VueJS?
• для управления состояниями мы будем использовать MobX, вы не против?

Не задавайте вопросы, на которые не хотите услышать неправильный ответ (да, это такая вот манипуляция):

• мы можем получать данные с сайта посредством платного API или мы сможем написать парсер
• мы можем кешировать ответы сервера, чтобы влезть в лимиты на запросы или будем использовать TOR для обхода проверки по IP

Приходите к заказчику как к шефу — с ответами, а не вопросами:

• для вашего проекта в качестве облачной платформы мы рекомендуем использовать AWS, по сравнению с Azure у него такие-то преимущества для нашего проекта
• для вашей нагрузки мы рекомендуем взять вот такой хостинг, и проблем не будет, и цена не самая высокая

И если уже говорить о том, что ещё стоит спросить, то вот вам список, который можно и нужно расширять:

• уточните ещё раз ЦА проекта
• есть ли требования по a11y?
• согласуйте список поддерживаемых устройств и браузеров (приходите с готовым ответом, у вас должен быть готов список и % покрытие по выбранной ЦА)
• нужна ли поддержка мультиязычности, какие языки планируется поддерживать
• есть ли дополнительные требования типа GDPR, CCPA, или HIPAA? (часто это понятно по требованиям, но не всегда явно)
• что с SEO? что будем продвигать и что анализировать?
• какая ожидается нагрузка, сколько зарегистрированных пользователей и сколько онлайн; на сегодня и через год
• может есть предпочтения по техническим аспектам — любимые языки или фреймворки? (вопрос, на который иногда не хочешь знать ответ)
• уже есть какие-то наработки? дизайн, POC, MVP?

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

Точность оценки

Точность оценки зависит от трудозатрат и растёт логарифмически:

По моему опыту, если вы уделите оценке хотя бы 2 часа, то вы уже попадёте в порядок цифр. Если потратите полдня, то можно ожидать, что погрешность в оценке не вылезет за 4х. А вот 100% попадание оценок вам никто и никогда не сможет гарантировать, мало того, даже по мере работы над проектом у вас будут случаться достаточно весомые расхождения оценки от фактических трудозатрат.

Фиче-лист и таски

Про то, как правильно декомпозировать проект на таски, можно написать целую книгу. Про то, как оценивать таски — несколько наблюдений и один мем :)

Чем более декомпозирована задача, тем больше будет оценка.

Давайте сравним вот такую задачу:
— REST API для сущности – 8 часов

С вот таким набором тасков:
— endpoint для создания сущности – 4ч
— endpoint для редактирования – 4ч
— endpoint для получение – 2ч
— endpoint для удаления – 2ч
— и описать всё посредством OpenAPI ещё часик

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

Так что не делите на составные части то, что логично было бы разрабатывать, выливать и тестировать как один кусок функционала. Идеально, если один таск будет соответствовать одному feature branch.

Декомпозируйте задачи с оценкой более 80 часов

А вот что обязательно следует декомпозировать, так это фичи, на которых оценка переваливает за 2 недели! Потому что оценка 80+ с девелоперского переводится как «я не знаю как это делать, но две недели должно хватить»…

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

42

Старайтесь избегать оценок вида:
— «сделаю тасочку за 7 часов» – судьба часа, который остался до конца рабочего дня вызывает во мне сомнения
— «9 часов» – день делал таск, на следующий день пришёл, кофе с утра и перекур, вот час и прошёл
— «42 часа» – красивая цифра, но она тут неуместна :)

Вот ряд оценок который мне близок:

часы   — 1 2 4 8 12
дни    — 16 24 32 40 64 
недели — 80 120 160 200 240 
месяцы — 320 400 480 520 640 800 1000 1200 1600

Отделу продаж оценка в месяцах вполне подходит.

Если кому вдруг интересно, то у меня есть статья с примером фиче-листа, которой уже более десятка лет — Оцениваем проекты :)

Проверь себя

У меня тут есть чек-лист оценщика, такая напоминалка самому себе, что не забыть включить в оценку на фичу и проект:

Проверка оценки

У нас есть практика, когда от оценщиков мы просим проставлять оценку в фиче-листе двумя цифрами – минимум и максимум, где минимум — это сколько часов потребуется, если всё пойдет гладко, а максимум, если всё будет как обычно. Это чем-то похоже на трёхкратный метод, да только мы просим разработчиков worst case превратить в вопросы, которые помогут избежать данный сценарий развития событий.

Нормально, если разбежность порядка 10-15%, или час-два, значит:
— документацию прочитал и понял
— представляет себе как будет делать
— уже был аналогичный опыт
— разница обусловлена незначительными факторами

Если 20-100%:
— документацию изучил, но не понял
— пока слабо представляет как будет делать
— нет опыта

Если разбежность более 100%, то тут тоже возможны варианты:
— у человека в голове несколько гипотез, и оценка дана сразу на все и сразу
— оценщик видит риски, и надо лишь попросить их озвучить, и оценить отдельно
— оценщику не хватает экспертизы, и соответственно нужно привлечь более опытного человека

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

Ещё у меня есть «magic» формула, которую я использую для проверки часов, которые заложены на разработку:

Опять же, это не формула для оценки проекта, я использую её только для проверки и последующего анализа.

Пример для сайта новостей с платным доступом:
— гость, читатель, автор, админ
— пользователь, статьи, категории, теги, подписки
— платёжка

Получаем где-то 320 часов на разработку.

Сравниваем с оригинальной оценкой:
— для статей нужен WYSIWYG с замороченным функционалом, поэтому заложили больше
— платёжка Нигерии, тут не 32 часа надо, а все 80
— требования по производительности ещё «+»
— поддержка IE ещё «+»

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

Проверь других

Оценка не зависит от технологии, а оценщики могут быть тех-стек-агностиками
Оценка проекта практически не зависит от выбранной технологии, при условии, что технология выбрана правильно. Например, если вам нужен REST API для SPA, то на условном PHP/NodeJS/Python/Ruby вы получите оценки одного порядка.

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

Митинг всех оценщиков
Если у вас в оценке участвует несколько отделов, то я настоятельно рекомендую провести sync-митинг всех оценщиков. Это необходимо, чтобы исключить ситуации когда бек переложил функционал на мобилки, а мобилки на бек, или наоборот, оба отдела оценили один и тот же функционал.

Что по итогу?
Финальный этап проверки оценки это сопоставить бизнес-идею с результирующей оценкой:

Как это работает? Вот простой пример:

— Нужен магазин на десяток электронных товаров с разделом новостей.

Смотрим на оценку, а она уже перевалила за $50k, и чтобы не упустить клиента стоит поискать варианты:
— может стоит предложить готовые решения?
— или хотя б частично использовать готовые?
— показать не одну, а две или три оценки, и рассказать о плюсах и минусах?

А ещё не стоит забывать, что заказчики ведь не всегда технически подкованы!
И когда говорят, что хотят видеоредактор для сайта своего магазина, не спешите давать оценку в 100-500 часов, может оказаться, что они просто будут встраивать видео с YouTube, и редактировать там же.

Точная оценка

Как ещё можно улучшить качество оценки? Что мы можем предложить для этого?

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

Что там у вас, AWS? Берите cloudcraft и рисуйте схему:

В системе будет API? Распишите endpoint’ы (я использую apiary.io):

Ну и структуру базы данных тоже можете прикинуть (например dbdiagram.io):

После такой подготовки можно рассчитывать, что погрешность не будет превышать 50%, но это не точно :)

Estimation на Estimation

Бывают ситуации, когда для оценки какой-то фичи не хватает знаний, а сроки поджимают. Медленный вдох и выдох. Это простая задачка — нужно оценить время, сколько потребуется на то, чтобы изучить всю необходимую документацию и (или) проверить гипотезу:

— на данный момент мы не знаем как это сделать, нам потребуется пару дней для поиска решений данной проблемы
— с данным API мы не работали, и мы не знаем позволит ли оно сделать задуманное, для изучения документации и примеров потребуется часа четыре
— мы не уверены можно ли реализовать данный функционал, надо сделать прототип для проверки, это займёт не меньше недели

А вот если вам предложат «а можно как-то побыстрее», тут главное устоять, и не обещать невозможное :)

Estimation на Duration

Ещё один острый вопрос — как оценивать сроки? Этот вопрос уже ближе к менеджменту, и ответ можно поискать в критическом пути на диаграмме Ганта, но это же статья для оценщиков, так что тут только простые советы, и вот вам алгоритм для расчёта сроков «на коленке»:

• выделяем таски, которые блочат начало разработки: архитектура, дизайн, енвайронменты, CI/CD и прочие
• прикидываем сроки разработки на 1-го разработчика по каждой из технологий (бек, фронт, мобильная разработка)
• + время на планируемые релизы и демки
• + время на митинги
• ~> эффективное время разработчика сократится где-то до 36 часов в неделю
• добавляем второго разработчика
• + время на митинги и синхронизацию
• + время на простой
• ~> эффективное время 2х разработчиков примерно 70 часов в неделю
• добавляем третьего разработчика (если возможно)
• + время на простой
• ~> эффективное время 3х разработчиков примерно 90 часов в неделю

Тут естественно не учтено много факторов, так что если хотите повысить точность — диаграмма Ганта вас ждёт.

Образы в моей голове

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

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

Сталкивался со следующей ситуацией:
— Заказчик на созвонах увлечённо рассказывал о проекте, и как-то себе его представлял
— Аналитик, который переводил на язык требований, представлял другое, и методично это документировал
— Разработчик читал кусками, и делал согласно требований в JIRA

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

К сожалению, такие случаи не единичны, так что стоит поучиться на чужих ошибках.

По этой причине я предпочитаю документацию, в которой больше картинок чем текста. С помощью мокапов вы практически исключите возможные ошибки в интерфейсе. А добавьте сюда капельку текста в виде хорошо оформленных use cases и user stories — и всё, можно садиться разрабатывать архитектуру.

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

Можно рисовать на листочке, а потом запихнуть ваше творчество в inVision:

Можно в diagrams:

Выбор инструментов достаточно большой:

• balsamiq – $9/месяц — мультяшный стиль
• Axure RP – $29/месяц — позволяет рисовать динамические прототипы
• figma – $12/месяц — бесплатно – 3 проекта и 2 редактора
• draftium – $99/год — Бесплатно – 3 прототипа и 20 шаблонов

И да, это было в Симпсонах я по этому поводу уже когда-то писал статью ТЗ для web-разработчика

Что ещё хотел сказать

Я тут прикинул, а ведь за последние 15 лет я участвовал в оценке более 2 тысяч проектов… это получается… каждую неделю я делал по три оценки О_о

P.S.

Порекомендую для ознакомление статью «Оценка трудоемкости проектов разработки» в двух частях — часть 1 и часть 2.