Привет! Меня зовут Герман Лышков, я руковожу проектами в диджитал-продакшене Далее. Если вам когда-то приходилось оценивать разработку сферического коня в вакууме, это статья для вас. Я расскажу, как это сделать и дам пару советов из личного опыта.
Далее работает по модели fixed price — бюджет проекта мы рассчитываем заранее, независимо от сроков. Перед разработкой в договоре проекта прописываем объем, содержание работ и техзадание, сроки реализации и стоимость. Это предсказуемая модель, которая удобна и для заказчика, и для вендора.
Но часто бывает так, что информации о проекте мало. Например, есть только список страниц и общее описание того, как это должно выглядеть. Тогда оценить по fixed price сложно, потому что непонятно, стоимость каких работ нужно рассчитывать. Ситуация со звездочкой, но справиться с ней можно.
Сначала была декомпозиция
Первый вопрос, который нужно задать, — «Каких данных не хватает для оценки?». Чтобы найти ответ, декомпозируйте проект по методу иерархической структуры работ.
Структурная декомпозиция работ или Work Breakdown Structure — это метод планирования, когда большие задачи делят на мелкие по принципу иерархии. Например: проект → этапы → задачи → подзадачи |
Разбейте проект на логические этапы от общего к частному и нарисуйте их в Miro или Draw.io. Должна получиться многоуровневая древовидная схема с детальным описанием всех блоков работ. Ваша цель — проанализировать ее и найти, какой информации не хватает на каждом уровне.
Пример: декомпозиция для разработки интернет-магазина
Уровень 1 — общая структура проекта. Определяем основные разделы: Главная, Каталог, О компании, Корзина, Личный кабинет.
Уровень 2 — структура страниц. Разбираем, какие блоки должны быть на каждой странице: карточки товаров, формы, баннеры.
Уровень 3 — функциональные элементы. Декомпозируем каждую страницу по тому, как работает фильтрация, как отображаются карточки товаров, какие кнопки и формы нужны.
Уровень 4 — логика взаимодействий. Определяем, какие блоки взаимосвязаны, где потребуется динамика и сложные сценарии.
Когда ясна задача проекта и примерный план, следующий шаг — понять, как нужно выполнить работы. На каркас из схемы нужно добавить «мясо».
Убираем все абстрактное
Разработка сайта или любого другого продукта — технический процесс с четкими требованиями. Например, одну административную панель можно написать сотней разных способов и программисты должны понимать, какой из этих вариантов ждет клиент. Если не выяснить это заранее, на проект уйдет больше времени, а для fixed price это — убытки.
Берегите нервы команды и заказчика — сразу убирайте слепые зоны и заменяйте все абстрактные описания на конкретные.
В каких ситуациях нужна конкретика
#1. Размытая формулировка, которую каждый понимает как хочет. «Сделайте красиво», «разработайте, чтобы не падало» — все это относительные пожелания.
Было | Уточняем | Стало |
Нужен удобный интерфейс | Удобный для кого? По каким UX-паттернам? | Нужен сайт для аудитории 60+ с адаптацией для слабовидящих |
#2. Список функций без описания логики их работы. Это не гуд, потому что от количества фич зависят сроки разработки, а следовательно и стоимость проекта в целом.
Было | Уточняем | Стало |
Сделать каталог товаров с фильтрацией | По каким критериям идет фильтрация? Как работает сортировка? | Разработать фильтрацию по названию бренда, полу и возрасту, цене товара |
#3. Нет описания ролевой модели и пользовательских сценариев. Непонятно, сколько ролей нужно создать в админпанели и какие права будут у юзеров.
Было | Уточняем | Стало |
Разработать систему управления заказами | Кто будет использовать? Администратор, клиент, менеджер? | Создать систему с ролевой моделью: - Менеджер, который обрабатывает заказ |
#4. Скудное описание интеграций и технологий для реализации проекта. Без технических требований программисты просто не смогут выполнять свою работу.
Было | Уточняем | Стало |
Написать интеграцию с Microsoft Dynamics AX | Какая будет версия ERP-системы? Какой вариант интеграции: SOAP или REST? Какие данные нужно передавать? Есть ли среда для тестирований передачи данных? | Разработать интеграцию со следующими требованиями: Версия — 9.1.0.4050 Передача по SOAP протоколу Данные для передачи: остатки товаров на складах, скидки на товары, информация о заказах |
Если заказчик охотно и подробно отвечает на вопросы, вы сорвали джекпот, поздравляем. Так происходит всего в 10% случаев.
Обычно разработкой со стороны клиента занимается продакт-менеджер или продакт-оунер, он и так разрывается от количества текущих задач. Новый запуск для него — еще одна головная боль, которую хочется свести к минимуму. Он часто сам ждет предложений от подрядчика и смутно представляет результат. Сколько бы встреч вы ни назначали, сколько бы писем ни слали в почте, есть шанс увидеть вместо требований перекати-поле.
Требуем сами от себя
Когда перспективы туманны, описывайте проект сами по здравому смыслу и опыту. Если второго мало, советую такой план: делаете свой вариант декомпозиции —> просите у руководителя посмотреть —> идете к исполнителям за оценкой реализации.
Примеры блоков и элементов можно подглядеть у конкурентов. Все-таки в любом продукте есть каркас базовых элементов: страниц, блоков, форм, кнопок. Например, интернет-магазин обычно состоит из главной страницы, страницы товара, корзины, страницы профиля, страниц авторизации и оплаты. Возьмите этот список за основу и адаптируйте под свою ситуацию.
Всегда обсуждайте проект с дизайнерами и разработчиками — это база. Ведь именно исполнители знают все нюансы реализации. Например, только программист подскажет, нужно ли обновлять версию языка или пока нет. Только дизайнер оценит, сколько уйдет на «сайт как у Apple». |
Изучаем важные связи между элементами и прорисовываем взаимодействие тех, что не учтены, но типичны.
Например, для сайта с каталогом стоит учитывать уровни вложенности, возможные фильтры или блоки сопутствующих товаров — это часто не указано в ТЗ, но всегда нужно.
Какая структурная схема должна получиться
В идеале такая, чтобы глобальных вопросов по реализации проекта не осталось. После грамотной декомпозиции вы должны знать архитектуру проекта, примерные трудозатраты и зоны риска, а еще спланировать возможности для оптимизации.
Пройдитесь по этому чек-листу для проверки декомпозиции на адекватность.
Архитектура
Описаны разделы продукта, страницы и блоки на них.
Описаны все функции.
Есть список повторяющихся элементов.
Трудозатраты
Есть оценка по времени для всех типов работ.
Описаны этапы, которые могут идти параллельно.
Есть список боттлнеков, когда уйдет больше времени на разработку.
Зоны риска
Указано, если требования размытые.
Описаны модули с непонятной реализацией, которые возможно придется корректировать.
Возможности для оптимизации
Есть план, как сократить время на разработку через шаблонные решения.
Описаны работы, которые можно сделать быстрее по аналогии с другими проектами.
Если поставили плюсик напротив всех пунктов, поздравляю. Можно выдохнуть — самое сложное позади. Объем работы зафиксировали, сроки и этапы спланировали. Осталось только все посчитать.
Отвечаем на главный вопрос: ну, что там с деньгами?
Чем больше деталей вы учли во время структурной декомпозиции работ, тем точнее будет смета по проекту. Вы не пропустите разработку фичи или этап релиза и потом не потратите еще месяц на оформление допсоглашений.
Что обязательно добавить в смету
#1. Трудозатраты
Исходя из количества часов, посчитайте общую стоимость каждого этапа работ. Обязательно учтите технические сложности — время на них и стоимость устранения.
#2. Время на коммуникацию
Все встречи по проекту, согласования макетов, уточнения и правки повлияют на сроки и стоимость релиза. Заложите все это в смету заранее и добавьте запас времени, чтобы не просрочить запуск из-за 30 итераций макета для главной.
#3. Итоговая оценка
Посчитайте финальную сумму и посмотрите, укладывается ли она в рыночные ориентиры. Если речь не о тендере, то я иногда предлагаю клиенту несколько вариантов сметы с разным наполнением и стоимостью реализации.
Вывод
Декомпозиция — спасение для проектов по разработке сферических коней в вакууме:
а) вам не будут сниться кошмары о костылях, которые пришлось впихнуть в проект в последний момент.
б) ни у кого в команде не будет приступа атаческой паники от того, что нужно делать непонятно что непонятно когда.
в) в глазах заказчика вы профессионал и надежный партнер, у которого все схвачено.
г) вы с командой сделаете качественный и классный проект, которым можно гордиться.