Продукт – команда разработки – тимлид

Новый продукт – новая команда разработки – новый тимлид

У меня довольно большой опыт взаимодействия с разными командами разработки ИТ продуктов – и молодых, и ровесников, из производства, из ритейла, из консалтинга… Но, до сих пор, у них всех был примерно одинаковый подход: • сначала мы обсуждаем какую систему хотим сделать в светлом будущем (в зависимости от сложности, через 1 или через 3 года), • потом делим это на более короткие, более «земные» периоды, • потом определяем MVP и начинаем разработку

Чаще всего на первом этапе лиды, архитекторы и просто опытные разработчики задают миллион бесячих вопросов из серии «а если то - а если вот это», «а если так – а если вот так». Обычно они это делают для того, чтобы понять какой фундамент какую архитектуру нужно заложить в начале разработки, чтобы со временим не было мучительно больно развивать систему и не потребовалось все переписывать.

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

А сейчас, в одном из новых продуктов, у нас тех-лид с диаметрально противоположным мышлением: он работает настолько «по agile», что, на вид кажется, что это даже чересчур. Его подход – делать микрозадачи. 1 задача – 1 user story, и эта сторя просто микроскопическая.

Не могу привести внутренние примеры, но в постах публичных релизов hrtech решений это выглядит, например, так: • «подраздел «Группы назначения» переезжает из раздела «Настройки» в раздел «Пользователи» • «теперь всю информацию о вебинарах и тренингах можно найти в разделе «Мероприятия». Больше не нужно переключаться между разными вкладками» • «кандидатов из откликов и поиска теперь можно фильтровать по ключевым словам»

С другими командами мы часто принимали это как само собой разумеющийся улучшайзинг и не фиксировали как значимые достижения. Но может быть успех именно в таких микро шагах? 🤔