Скоуп фичи — ключевой фактор для ускорения разработки 🍒
Всем знакома ситуация, когда продукт/бизнес говорит: «хотим ABC», а разработка им в ответ «сделаем за X мес.». Дальше начинается игра в ужимание-разжимание сроков, где обе стороны пытаются отжать максимум.
🔪 Эта игра может закончиться успешно только когда в ней обсуждается скоуп, чтобы кратно сократить объём фичи. 🦄 Ни одно срезание работ в части разработки не даст столь же большое ускорение, как грамотно выделенный скоуп. 🤯 В прошлом у меня был интересный случай, где срезали 6 мес. до 1 строчки кода. Погнали за деталями: Ключевой инструмент в компании — телефония. И это прям мега-крутой SaaS комбайн, который умеет очень интересные штуки. В какой-то момент у вендора начались регулярные проблемы со стабильностью, и мы задумались про резервную телефонию. Но вот незадача: на рынке никто не предлагает даже близко похожий комбайн. За первый подход команда супер-верхенеуровнево насчитала 6 мес. работ: проработать, собрать свой комбайн на 60% из 4 SaaS продуктов и ещё 40% inhouse разработки, подружить 2 комбайна и обучить операторов. Дальше ужали до 2 мес. срезав возможности резерва, но сохранив 60% эффективности от текущего комбайна. ИМХО: очень чёткое решение. 😒 Но и 2 мес. для бизнеса было прям очень дорого. Помним, что это резервная телефония, да?) В бэклоге есть супер-выгодные фичи, но и «простаивать» не хочется… Пошла эскалация в меня. Собрались на звонке. В какой-то момент у тимлида и продакта кончились аргументы, почему быстрее не выйдет.
🥷🏻 Я решил пойти чуток другим путём и задал вопрос: «С., а зачем вообще тебе эта резервная телефония?». 🎖️ Спустя 10 минут мини-брейншторма у нас появилось решение ценой почти в 1 строчку кода:
1. Сделать телефон кликабельным в нашей CRM — та самая 1 строчка кода 2. Установить на компьютеры операторов приложение от нового вендора, которое умеет открывать tel: ссылки 3. 0 интеграций с вендором 🚀 Через пару дней всё уже работало. PROFIT, все довольны. И впоследствии мы запустили всё то, что хотели сделать за те самые 2 мес., что повысило ценность всего решения. Как-то так из 6 мес. мы сделали почти 1 строчку кода. Всё за счёт грамотного срезания скоупа и общения друг с другом 😏
Подробно о том, как декомпозировать фичи на кусочки, я рассказывал в статье для Zen Hills: https://zenhills.ru/articles/feature-slicing/setka 😉
#agile #продуктовыйподход #продукт #декомпозиция #планирование
· 06.08.2024
Просто не было чёткого тз, и это как всегда привело к тому что сроки не нравятся ни кому. Правильное ТЗ 80% успеха. Если тут по ТЗ сразу бы определили что требуется резервная звонилка то и проблемы бы не было)
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
коммент удалён
· 08.08.2024
ТЗ ещё предстояло написать. Наш процесс предполагает обсуждение фичи с командой/ТЛ до того, как ТЗ будет написано/финализировано.
Всё же без компетенций команды/ТЛ сложновато оценивать объёмы и обоснованно что-то срезать.
После встречи, где мы срезали до 1 строчки кода, дальше родилось порядка 3-х ТЗ под разные инкременты. Которые постепенно докатывали.
0
ответить
коммент скрыт — часть юзеров считает его токсичным или некорректным
ответ удалён