Оценка разработки. Участники и основные артефакты

Ранее: Оценка разработки. Декомпозиция, Оценка разработки. Неопределенности и «вилка»

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

Участники

1. Руководитель проектного офиса. Тот, кому «больше всех надо». Локальный проджект-раннер, который собирает всех и менеджерит процесс подготовки сметы

2. Проджект-менеджер. Генерирует ресурсный и календарный плана на основании артефактов от других участников

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

4. Аналитик. Делает бОльшую часть работы по подготовке сметы: детально изучает входящие материалы, старается сократить неопределенность в требованиях (или, как минимум, подсветить места, где она есть), готовит подробную функциональную декомпозицию, помогает осознать детали требований другим участникам процесса

5. Тимлиды. Валидируют оценки от архитектора, помогают осознать чисто технические риски по тем или иным элементам сметы. Надо сказать, что часто оценка делается тимлидами совместно с архитектором


Артефакты

1. Функциональная декомпозиция с оценкой. В одном из постов про оценку уже писал, что мы делаем функциональную декомпозицию, где каждый пункт подразумевает комплексную экспертизу (фронт, бэк, QA, UI/UX etc). Каждый пункт имеет оценку по всем компетенциям, текущий уровень неопределенности и, собственно, вилочную стоимости. Это — основа для всех остальных артефактов

2. Календарный план. На основе декомпозиции, оценок и предварительного разбиения разработки на релизы формируется примерный календарный план. Обычно планирование идет на уровне недель, иногда на уровне месяцев

3. Ресурсный план. Про это многие забывают и/или пренебрегают, но мы его делаем для любой оценки. Указываем, какие именно люди будут задействованы и моделируем график их аллокации в FTE прямо по месяцам. Очень важно, чтобы функциональная оценка не противоречила ресурсной оценке проекта (!)

4. Архитектурные решения. Базовые схемы того, как мы видим будущую архитектуру и как разрабатываемый продукт вписывается в текущий ландшафт

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

6. Презентация. Она же «КП». Приводятся основные данные по бюджету, основные риски, архитектурное решение, UI, календарный и ресурсный план, ссылки на все остальные артефакты

В следующий раз напишу про процесс оценки (хотел тут, но ТГ не дает из-за ограничений)

Где в России айтишнику жить хорошо?

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

Малая часть:
«
Я регулярно езжу в командировки по городам России, объехал очень многие города европейской части: Екатеринбург, Казань, Нижний Новгород, Владимир, Уфа, Тольятти, Тюмень, Челябинск, Ижевск, Ульяновск, Самара, Саратов, Волгоград, Ростов-на-Дону, Краснодар, Сочи, — и могу с уверенностью сказать, что Пермский край и Пермь в топе по комфорту и развитости инфраструктуры.
»

Статья: https://habr.com/ru/companies/netologyru/articles/887850/

Программный Комитет Ural Digital Weekend 2025 начал работу!

Ура, сегодня была первая встреча ПК Ural Digital Weekend, а это значит, что мы начинаем сезон активной подготовки к конференции и наши супер-люди вот-вот начнут обрабатывать заявки и связываться с потенциальными спикерами.

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

Ну и конечно, покупайте билеты!

Ссылка на CFP, если хотите заявиться с докладом: https://docs.google.com/document/d/1V3sFRGSQ6tGwIrqJJdw63phSLQ-N-Id3q2aNlV410Oo/edit?tab=t.0#heading=h.pww5c6lc8kv

Сайт конференции: https://ural-digital-weekend.ru/

Руководитель, помни строго –
Метрики — твоя дорога!
Вовремя в таблицу вбей,
Не тяни же, не робей.

Сроки, выручка, расходы –
Цифры скажут, где невзгоды.
Без контроля — полный мрак,
А с таблицей — всё ништяк! 😃

Новый выпуск «Подкаст-Подкаста» смонтирован в 4K и согласован. Через неделю на ваших экранах.

В гостях Елена Козлова, директор центров разработки Т-Банка на Урале и в Сибири.

Многие знают про IT-хабы Т-Банка, что их много (23), но зачем они? Как появились? Как устроены? Как работают и управляются?

Золото в каждом ответе ☝️

P.S. Где лучшие джависты? У нас в клубе Узнаете 27 марта😉

Оценка разработки. Этапы оценки

Ранее: Декомпозиция, Неопределенности и «вилка», Участники и основные артефакты

Описание процесса, учитывающее специфику Spectr — мы оцениваем разработку по запросам наших клиентов

1. Изучение входящих материалов. Изучают все, но каждый погружается в детали в разной степени. В результате генерируется существенный пул вопросов к клиенту. Часто сразу подсвечиваются ключевые риски

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

3. Аналитик делает детальную функциональную декомпозицию. В процессе он определяет уровни неопределенности для разного функционала и подсвечивает сложности/риски в комментариях. Если было принято решение о подготовке UI для основных интерфейсов — ставится соответствующая постановка дизайнеру

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

5. Планирование релизов. На основе входящих требований и опыта команды, весь скоуп группируется на релизы. Важно, чтобы каждый релиз нес самостоятельную ценность и был проверяем (все тот же инкрементальный подход)

6. Коммерция. Рук-ль ПО принимает решение о том, какой процент закладывать на тестирование, аналитику, как закладывать и презентовать риски, по каким рейтам и какие специалисты будут нужны для реализации

7. Подготовка календарного и ресурсного плана. На основе сделанного ранее, проджект-менеджер составляет предварительный план проекта

8. Подготовка КП. Все материалы собираются и упаковываются в презентацию

9. Встреча и презентация клиенту. Мы отправляем смету заранее, но во время встречи все равно очень подробно ее показываем, объясняем и рассказываем про нашу методику. Во время презентации демонстрируем и остальные артефакты (архитектура, ключевые интерфейсы )

Весна в Сочи

Второй год подряд приезжаем весной в Сочи переждать Уральско-весеннюю слякоть-грязь.

Из плюсов. Вчера работал на балконе с таким видом

Из минусов. Замерз ❄️

Позади — неделя в ритме огня:
Дедлайны, релизы с утра до утра.
Задачи горели, продакшн кипел —
Но ты всё успел, сдюжил, сумел!

✨ С пятницей! Всем мощного отдыха в выходные!

Популярные посты за март 2025

Микро-дайджест постов, которые набрали больше всего просмотров и репостов за последний месяц.

Программный Комитет Ural Digital Weekend 2025 начал работу!
Ссылка: https://news.1rj.ru/str/release_it/155

Подкаст-Подкаст #3. B2B-маркетинг в Enterprise: как и что продавать крупным клиентам
Ссылка: https://news.1rj.ru/str/release_it/159

Подкаст-Подкаст #4. Как устроены центры разработки Т-Банка
Ссылка: https://news.1rj.ru/str/release_it/165

Трудозатраты на долгие оценки и пресейлы

По мотивам постов про оценку: Декомпозиция, Неопределенности и «вилка», Участники и основные артефакты, Оценка разработки. Этапы оценки

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

Трудозатраты
Данные по пресейлам за последние полгода.
— Аналитик. От 7 часов до 40 часов. Но при этом был пресейл, где трудозатраты 101 час (но это не типичная история для нас)
— Архитектор. 3 часа минимум (для чего-то простого, где мы не готовим архитектурных схем и где только самые необходимые встречи). Типично ±8-10 часов. Самое большое, что я нашел - 42 часа
— Тимлиды обычно тратят времени немного, в пределах 4 часов (изучение материалов + встреча по оценке), типичное значение - 2 часа
— Время менеджеров мы не трекаем, тут статистики нет, к сожалению

Сроки
Если горит и надо очень быстро, можем уложиться за 3 дня. По-умолчанию, берем себе ±неделю.
Тут речь про время, которое мы берем на оценку и подготовку КП «внутри себя». После подготовки КП и презентации почти всегда есть длинный хвост из встреч/уточнений/согласований, которые ведут к изменению сметы и могут длиться месяцами.

Держу вас в курсе про работу Программного Комитета Ural Digital Weekend. Знаю, вы ждали

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

Спикеры из Ozon, СпортМастер, Битрикс24, Cloud, Т-Банка — программа, как всегда, будет крутой (прямо как наш Программный Комитет)!

Покупайте билеты, а то цены растут: https://ural-digital-weekend.ru/

Ответы на вопросы

Решил попробовать новый формат в канале — разбор реальных кейсов и вопросов из вашей практики. Вы анонимно присылаете мне вопрос или ситуацию — я публично её разбираю, вы при этом остаетесь анонимным.
Формат подсмотрел в канале у Фёдора Борщева.

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

Карьерное
— Старт карьеры в разработке, поиск и работа с менторами
— Как расти, куда развиваться, что учить
— Формирование и мотивация команды
— Взаимоотношения внутри команд
— Сложные и конфликтные рабочие ситуации
— Как растить свою ценность для бизнеса и команды

Бизнесовое
— Финансовый и управленческий учет
— Где взять деньги (не про инвестиции, а про кредиты/займы/факторинги)
— Автоматизация учета
— Метрики, KPI и вот это все
— ИИ для оптимизации процессов
— Переговоры
— B2B-продажи, B2B-маркетинг, PR
— Отговорить от организации конференций

Продуктово-проектное и управленческое
— Тестирование гипотез без разработки
— Быстрая разработка прототипов и MVP
— Структура команды разработки, методологии управления
— Анализ рынка, поиск инсайтов и инструменты для этого
— Плохие/хорошие практики
— Требовательность к себе и окружающим
— Работа с ожиданиями заказчиков (как внутренних, так и внешних)

(темы буду дополнять)

Присылайте ваши рабочие ситуации и вопросы на man@spectr.dev или в ТГ @aleks_tsykarev — буду отвечать на самые интересные в канале

#вопросответ

Про кредитование бизнеса в 2025

Один банк дает оборотный кредит под ±30% годовых и это считается «хорошими» условиями. Другой банк дает факторинг под 48% годовых.

Интересно, о чем я буду думать, глядя на этот пост через 5 лет

В B2B-маркетинге много специфики, а информации мало. А если речь заходит про продвижение B2B-цифровых продуктов — то информации вообще практически нет.

Если вы развиваете B2B-цифровой продукт и очень хотите, чтобы его нашли ваши потенциальные клиенты, заглядывайте в канал Светланы Берегулиной. Светлана - Ex-CMO Битрикс (12 лет), VK (тогда это был Mail.Ru), МШУ Сколково, inSales (в экосистеме Сбер). Вошла в Топ-100 лучших директоров по маркетингу рейтинга Коммерсант в 2021 году. Автор книги "Системный ИТ-маркетинг: от ценности до коммуникации", которая стала хитом продаж на Литресе.

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

Вот топ-5 популярных постов, чтобы начать знакомиться с каналом:
▫️ Путь клиента в B2B
▫️ Четыре уровня маркетинговых проблем
▫️ Вебинарные воронки в B2B-IT
▫️ Лучшие книги про Продуктовый маркетинг
▫️ Карта компетенций Продуктовых маркетологов

Загляните и почитайте:))

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

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

Чтобы сделать процесс доставки стабильным и предсказуемым есть множество устоявшихся инженерных практик, инструментов, фреймворков и подходов.
— Вся разработка строго через Git (банально? да! Но удивительно, все еще не везде так)
— Весь процесс деплоя строго через CI/CD
— Автотесты
— Внедренды всевозможные статические анализаторы кода
— Активно эксплуатируются практики DevSecOps
— Все структурные изменения строго через миграции
— Процесс написания документации является неотъемлемой частью пайплайна разработки
— QA, тест-менеджемент и актуальная тестовая документация
— Всевозможные мониторинги, алерты
— ... еще многое

Проблема в том, что каждый пункт при его отсутствия в ДНК команды будет требовать существенных затрат на внедрение: время и нервы команды, преобретение недостающей экспертизы. С внедрением каждого пункта будут неизбежно расти издержки и трудозатраты на внедрение каждой новой фичи, будет расти время доставки фичи. Будет теряться привычная скорость и гибкость работы команды: если раньше фича могла выкатиться день-в-день сразу по готовности, то теперь вам придется ждать ближайшее релизное окно (которое может быть, например, «в следующую пятницу»). Команда станет сильно больше, в ней появится много новых ролей, «незаменимость» отдельных людей будет снижаться. И всем этим надо будет управлять и строить новую систему управления и в процессе будет казаться что все становится только хуже.

В конечном итоге все точно станет более предсказуемо и надежно. Но точно будет дороже и медленней. И самое главное — даже самый крутой и супер-избыточный процесс не застрахует на 100% от ошибок и сбоев.

Сравните текущие потери бизнеса от сбоев с затратами на перестройку. Если оно оправдано — действуйте.
Если нет, то вероятно стоит принять текущее положение дел и оставить все как есть для legacy-части ваших продуктов. А вот когда перед бизнесом будут стоять задачи по разработке чего-то принципиально нового и по запуску новых направлений — там уже с первых дней все делать «как надо».

Присылайте ваши рабочие ситуации и вопросы на man@spectr.dev или в ТГ @aleks_tsykarev — буду отвечать на самые интересные в канале