🥇 Как мы прошли первую стадию MVP за один месяц
Не так давно я вам рассказывал, что перешел на новую работу и тут же сходу получил в работу большую задачу с кучей вопросов: «Создание фреймворка для обработки данных различных IN/OUT протоколов».
Первыми шагими были:
1️⃣ Формирование команды
2️⃣ Сбор требований
3️⃣ Создание первого прототипа
4️⃣ Демонстрация
Если кратко свалиться в ретроспективу, то эти шаги необходимо было выполнить более года назад.
Но все застопорилось на сборе требований и создании прототипа. Всё потому, что разработчик отвечавший за проект взялся за реализацию прототипа предварительно не собрав требования и не разработав на их основе минимальный дизайн будущего прототипа.
Когда я пришел в команду, то увидел с какой неистовастью выполнялись попытки реализации "thing". Так приложение называл разработчик отвечающий за судьбу проекта, каждый раз призывая на митингах к действиям в стиле: "Let's make the thing somehow working" или "Let's make a crapy thing and then will improve it". НЕ подумайте неправильно, разработчика о котором идет речь никто не намеревается оскарблять или критиковать. Напротив, он очень крутой разработчик, просто задача организации производственных процессов не его конёк. Он скорее отличный реализатор четко определенных вещей.
Не знаю за какие заслуги, но условное шефство над проектом передали мне и уже через месяц мы показали первый результат в виде демонстрации первого прототипа. Работы предстоит еще много, но заказчики (или stakeholder) наконец-то выдохнули и сказали: "Отлично! Так бы сразу! Приступайте к следующему этапу прототипирования. Совсем скоро хотим запустить это в пилотном режиме на реальном проекте."
Что понадобилось для такого молнеиносного успеха:
1️⃣ Коммуникация с шарющими разработчиками.
Это дало возможность понять, что нам технически необходимо для реализации такого проекта
2️⃣ Сбор требований.
Плотное общение со стейкхолдерами или близкими к ним людьми, позволило в краткие сроки собрать требования
и донести их до команды разработчиков
3️⃣ Предоставление "карт-бланша" разработчикам.
Поскольку я новичек, то нет смысла свои монастыри строить.
Пусть ребята с экспертизой в компании и её продуктах сами создают ПО, необходимо лишь держать руку на пульсе.
Баланс контроля и доверия - наше всё.
4️⃣ Забить на все царемонии которые неинтересны стейкхолдеру.
Мы смело остановили все работы над CI\CD. Объективно это нам вообще не нужно было, поскольку если бы не состоялся проект, то и автоматизация проекта не потребовалась бы. К слову, требования к исходному коду выдвигаемые автоматическими проверками, очень велики. Это круто, это правильно. Но для нас было помехой в силу отсутствия времени. Доведение кода до технического идеала уже определено в MVP v2-3
5️⃣ Мы не забили на тестирование.
Это позволило разработать стабильный функционал, который станет костяком фреймворка.
⬇️ А как бы ты создавал проект при лимитах времени и отсуствием терпения у заказчика? Пиши в комментариях.
👍 Поставь лайк этому посту, если тебе нравятся наш контент.
Респект,
Макс Добрынин
Не так давно я вам рассказывал, что перешел на новую работу и тут же сходу получил в работу большую задачу с кучей вопросов: «Создание фреймворка для обработки данных различных IN/OUT протоколов».
Первыми шагими были:
1️⃣ Формирование команды
2️⃣ Сбор требований
3️⃣ Создание первого прототипа
4️⃣ Демонстрация
Если кратко свалиться в ретроспективу, то эти шаги необходимо было выполнить более года назад.
Но все застопорилось на сборе требований и создании прототипа. Всё потому, что разработчик отвечавший за проект взялся за реализацию прототипа предварительно не собрав требования и не разработав на их основе минимальный дизайн будущего прототипа.
Когда я пришел в команду, то увидел с какой неистовастью выполнялись попытки реализации "thing". Так приложение называл разработчик отвечающий за судьбу проекта, каждый раз призывая на митингах к действиям в стиле: "Let's make the thing somehow working" или "Let's make a crapy thing and then will improve it". НЕ подумайте неправильно, разработчика о котором идет речь никто не намеревается оскарблять или критиковать. Напротив, он очень крутой разработчик, просто задача организации производственных процессов не его конёк. Он скорее отличный реализатор четко определенных вещей.
Не знаю за какие заслуги, но условное шефство над проектом передали мне и уже через месяц мы показали первый результат в виде демонстрации первого прототипа. Работы предстоит еще много, но заказчики (или stakeholder) наконец-то выдохнули и сказали: "Отлично! Так бы сразу! Приступайте к следующему этапу прототипирования. Совсем скоро хотим запустить это в пилотном режиме на реальном проекте."
Что понадобилось для такого молнеиносного успеха:
1️⃣ Коммуникация с шарющими разработчиками.
Это дало возможность понять, что нам технически необходимо для реализации такого проекта
2️⃣ Сбор требований.
Плотное общение со стейкхолдерами или близкими к ним людьми, позволило в краткие сроки собрать требования
и донести их до команды разработчиков
3️⃣ Предоставление "карт-бланша" разработчикам.
Поскольку я новичек, то нет смысла свои монастыри строить.
Пусть ребята с экспертизой в компании и её продуктах сами создают ПО, необходимо лишь держать руку на пульсе.
Баланс контроля и доверия - наше всё.
4️⃣ Забить на все царемонии которые неинтересны стейкхолдеру.
Мы смело остановили все работы над CI\CD. Объективно это нам вообще не нужно было, поскольку если бы не состоялся проект, то и автоматизация проекта не потребовалась бы. К слову, требования к исходному коду выдвигаемые автоматическими проверками, очень велики. Это круто, это правильно. Но для нас было помехой в силу отсутствия времени. Доведение кода до технического идеала уже определено в MVP v2-3
5️⃣ Мы не забили на тестирование.
Это позволило разработать стабильный функционал, который станет костяком фреймворка.
⬇️ А как бы ты создавал проект при лимитах времени и отсуствием терпения у заказчика? Пиши в комментариях.
👍 Поставь лайк этому посту, если тебе нравятся наш контент.
Респект,
Макс Добрынин