Представьте, что у нас проект, в котором результат привязан к какому-то понятному и не сдвигаемому дедлайну. И фиксированному бюджету.
Например, запускаете сервис для футбольной лиги — нужно успеть до начала предсезонной подготовки. Если не успеем, то следующий шанс на внедрение этого продукта появится через год, в следующее предсезонное окно.
И вот с этим ограничением мы должны запустить продукт. Работоспособный, завершенный, после запуска которого выделят еще бюджет на развитие и никого из команды не уволят :)
То есть у нас нет варианта перенести срок запуска и нет варианта увеличить бюджет. Мы не можем себе позволить сказать: «ага, вот эту фичу мы берем и сдвигаем срок запуска на 1 месяц».
Мы должны здесь и сейчас решить, что мы делаем, а что не делаем.
Да, вы правы, отказываться от фич больно, грустят не только заказчики, но и команда разработки.
Но в то же время отказаться от фичи в FFF это не значит убить ее безвозвратно. Это значит, что в данной итерации продукта ее не будет. Ну вот вообще никак. Зато эту фичу мы заботливо положим в беклог и договоримся вернуться к ней в следующих итерациях.
Важный момент: в реальности на проектах редко бывает, что команда отказывается от фич. Обычно мы либо упрощаем реализацию или заменяем фичу на более простую, но с той же функцией. В том же примере из проекта мы не отказались от фичи Календаря. Мы упростили ее — не стали делать годовое отображение. А недельный и месячный сделали.
А про SCRUM: да, возможно немного некорректное прямое сравнение его с FFF. Для меня в SCRUMе среди всех его артефактов и мероприятий не хватает как раз указаний, что делать, когда команда понимает, что не успевает к намеченному сроку. Как будто бы в нем мы можем только за этим наблюдать, а что делать — непонятно :)
FFF с заморозкой фич перед стартом — это обычный водопад с фиксированием всего.
Давайте на примере моста.
Вот строим мы мост по проекту с фиксированным бюджетом, сроками. Типовой мост, тысячу таких построено. Шанс ошибиться с оценками — минимальный, поэтому и фичи зафризим и получим MVP1.
В процессе вы узнаёте, что геологи накосячили с расчетами грунта. Тех свай, которые у вас в проекте уже закуплены, не достаточно чтобы мост просто стоял.
В этот момент объем фич резко изменился и появился MVP2. Вместо установки 10 свай надо 15.
Что делать? Терпеть, стараться уложиться в сроки и бюджет, идти пересогласовывать, двигать сроки, игнорировать это, забить 10 свай и молиться что не упадёт?
При реализации проекта постоянно будут возникать MVPn+1. Фризинг фич подразумевает то, что мы просто игнорируем этот факт? Или что мы должны сделать в такой ситуации?
А если строительство моста пройдет без проблем, так и получим мы то, что изначально планировали, без всяких изначальных фризов.
Поэтому смысл фиксации фич я так и не понял, извините :)
Пример, кстати, реальный, только вместо моста был жилой многоэтажный дом.
FFF здесь ни при чем — он не отвечает на вопрос что взять в MVP, а что не взять. Он говорит нам что мы можем сделать, когда такое происходит. А такое происходит на каждом проекте.
В нашем кейсе классическая история разработки продуктов: когда мы на проектировании отталкиваемся от гипотез и расставляем приоритеты, многие фичи считаются важными и нужными. Когда на разработке мы сталкиваемся с реальностью и приобретаем новый опыт — приоритеты задач могут меняться. В данном случае «годовой календарь» это не ненужная фича. Она нужна и классная, просто появилась новая задача, у которой приоритет больше. Поэтому пришлось перестраивать объем задач.
И здесь мы говорим не о недостатке FFF, а об его преимуществе. Если бы не он, то мы бы не могли контролировать такие ситуации: появляются новые важные задачи, старые остаются — скоуп работ растет, сроки плывут, бюджет пухнет. Для каких-то проектов и команд это окей, для нас — нет.
Если серьезно, то в разработке ПО менеджер проекта это довольно устаканившаяся роль, с четкими понятными ожиданиями и с определенным набором скиллов. ПМ, в моем понимании этой роли, выступает как исполнитель — то есть не погружен глубоко в бизнес, цели и метрики. Он на входе получает задачу, декомпозирует ее, передает в разработку и следит за ее выполнением. Продюсер в этой концепции делает почти все тоже самое, но больше погружен в бизнесовую составляющую продукта. То есть на входе он может получить не уже оформленную задачу, а гипотезу и дальше дотащить ее до реализации. Этакий сплав продакта и проджекта.
Вот поэтому решил ввести другой термин, чтобы сходу обозначить разницу. Ну и забайтить немножко :)
Возможно я не совсем правильно спозиционировал статью. Я не утверждаю, что цели должны ставить обычные исполнители. Цели ставит команда, а в команде, по крайней мере у нас, всегда есть менеджерские роли ответственные за это. И да, клиент играет в постановке целей главную роль. Мы, как команда, просто помогаем ему с формулированием этих целей и определением задач, которые помогут этих целей достичь. Цели транслируются исполнителям в виде задач и приоритетов. Но это не значит, что исполнители просто бездумно работают по ТЗ, они в любом случае погружены в цели продукта и двигаются к ним.
Я так же считаю, что рынок сломан подходом «Без ТЗ результат ХЗ». Мне больно видеть ситуации, когда крутые продукты проваливаются просто потому, что обе стороны не договорились на берегу зачем мы что-то делаем и как. И потом возникают конфликты — клиент дурак, потому что не поставил нормально задачу, а разработчики плохие, потому что сделали не то, что я хотел. И все как будто бы согласны, что это нормально. Я так не считаю.
Поэтому, вместо того, чтобы ждать пока клиент наймет себе продакт оунера или научится сам формулировать задачи для разработчиков, я предлагаю проактивную позицию. Да, такой подход требует чуть больше погружения от исполнителей. Не все исполнители готовы переходить на такой уровень и это нормально. Они просто могут хорошо программировать/тестировать/дизайнить и оставаться востребованными.
Ну и по моему опыту клиент готов платить больше денег за такой подход. И это хорошие новости :)
А когда наступает это самое нужно и кто это определяет?
Я не против классической версии, мы от нее не сильно отошли на самом деле, а модернизировали:
Проблема классического подхода в том, что список не детализированных юзер сторей в самом начале проекта не особо помогает команде и бизнесу понять зачем мы все это делаем и как. Это похоже на список покупок в магазине. Можно предположить какой салат у нас получится из этих ингридиентов, но не зная результата, можем забыть что-то важное без чего блюда не получится.
А еще юзер стори без уточнения просто невозможно объективно приоритезировать. Что самое важное, что сделать проще всего и это даст максимальный результат.
Поэтому вместо юзер сторей в самом начале мы всегда определяем цели и формулируем гипотезы по их достижению. Гипотезы тоже можно формулировать в виде юзер сторей, если вам так удобней. Но мне здесь больше нравится декларативный подход — сделать интерфейс создания тренировки. Он понятней, точнее и в виде задачи, которую надо решить. На этом этапе мы приоритезируем — выделяем основные гипотезы, с которыми надо работать в первую очередь.
Потом эти гипотезы перевариваются в документ. Документ это тоже набор сценариев. Сначала они в виде заголовка, например «Тренер создает тренировку». Детализируем сценарии для того, чтобы: 1. Синхронизировать ожидания бизнеса и команды. 2. Разобраться как сценарии будут дружить друг с другом. Это, кстати, решает основную, на мой взгляд, проблему разработки через юзер стори без глубокой проработки — часто сценарии противоречат друг другу и мы в будущем можем очень много проблем из-за этого получить. 3. Определить риски, объем работ, получить новые идеи по реализации, новые гипотезы. 4. Понять какая архитектура продукта будет. 5. Оценить объем работ, выделить версии релизов и сроки, запланировать работу команды.
Ну а финальный USM, который мы собираем после этого — просто удобный способ визуализации всего, что мы проделали до этого.
Здесь важно уточнить еще, что наш подход хорошо ложится на запуск новых продуктов или глубокую модернизацию существующих. Если мы занимаемся развитием продукта и команда на проекте стабильная, то классическая версия проектирования через юзер стори очень хорошо работает и мы ею пользуемся.
До того как мы внедрили такой процесс часто не хватало понимания что то, что мы делаем на самом деле влияет на цели пользователей и продукта, а не просто наши галлюцинации.
То что вы внедрили возможность такой модели в свой продукт заслуживает только уважения :)
Представьте, что у нас проект, в котором результат привязан к какому-то понятному и не сдвигаемому дедлайну. И фиксированному бюджету.
Например, запускаете сервис для футбольной лиги — нужно успеть до начала предсезонной подготовки. Если не успеем, то следующий шанс на внедрение этого продукта появится через год, в следующее предсезонное окно.
И вот с этим ограничением мы должны запустить продукт. Работоспособный, завершенный, после запуска которого выделят еще бюджет на развитие и никого из команды не уволят :)
То есть у нас нет варианта перенести срок запуска и нет варианта увеличить бюджет. Мы не можем себе позволить сказать: «ага, вот эту фичу мы берем и сдвигаем срок запуска на 1 месяц».
Мы должны здесь и сейчас решить, что мы делаем, а что не делаем.
Да, вы правы, отказываться от фич больно, грустят не только заказчики, но и команда разработки.
Но в то же время отказаться от фичи в FFF это не значит убить ее безвозвратно. Это значит, что в данной итерации продукта ее не будет. Ну вот вообще никак.
Зато эту фичу мы заботливо положим в беклог и договоримся вернуться к ней в следующих итерациях.
Важный момент: в реальности на проектах редко бывает, что команда отказывается от фич. Обычно мы либо упрощаем реализацию или заменяем фичу на более простую, но с той же функцией.
В том же примере из проекта мы не отказались от фичи Календаря. Мы упростили ее — не стали делать годовое отображение. А недельный и месячный сделали.
А про SCRUM: да, возможно немного некорректное прямое сравнение его с FFF. Для меня в SCRUMе среди всех его артефактов и мероприятий не хватает как раз указаний, что делать, когда команда понимает, что не успевает к намеченному сроку. Как будто бы в нем мы можем только за этим наблюдать, а что делать — непонятно :)
FFF с заморозкой фич перед стартом — это обычный водопад с фиксированием всего.
Давайте на примере моста.
Вот строим мы мост по проекту с фиксированным бюджетом, сроками. Типовой мост, тысячу таких построено. Шанс ошибиться с оценками — минимальный, поэтому и фичи зафризим и получим MVP1.
В процессе вы узнаёте, что геологи накосячили с расчетами грунта. Тех свай, которые у вас в проекте уже закуплены, не достаточно чтобы мост просто стоял.
В этот момент объем фич резко изменился и появился MVP2. Вместо установки 10 свай надо 15.
Что делать? Терпеть, стараться уложиться в сроки и бюджет, идти пересогласовывать, двигать сроки, игнорировать это, забить 10 свай и молиться что не упадёт?
При реализации проекта постоянно будут возникать MVPn+1. Фризинг фич подразумевает то, что мы просто игнорируем этот факт? Или что мы должны сделать в такой ситуации?
А если строительство моста пройдет без проблем, так и получим мы то, что изначально планировали, без всяких изначальных фризов.
Поэтому смысл фиксации фич я так и не понял, извините :)
Пример, кстати, реальный, только вместо моста был жилой многоэтажный дом.
FFF здесь ни при чем — он не отвечает на вопрос что взять в MVP, а что не взять. Он говорит нам что мы можем сделать, когда такое происходит. А такое происходит на каждом проекте.
В нашем кейсе классическая история разработки продуктов: когда мы на проектировании отталкиваемся от гипотез и расставляем приоритеты, многие фичи считаются важными и нужными.
Когда на разработке мы сталкиваемся с реальностью и приобретаем новый опыт — приоритеты задач могут меняться. В данном случае «годовой календарь» это не ненужная фича. Она нужна и классная, просто появилась новая задача, у которой приоритет больше. Поэтому пришлось перестраивать объем задач.
И здесь мы говорим не о недостатке FFF, а об его преимуществе. Если бы не он, то мы бы не могли контролировать такие ситуации: появляются новые важные задачи, старые остаются — скоуп работ растет, сроки плывут, бюджет пухнет.
Для каких-то проектов и команд это окей, для нас — нет.
поэтому и переименовали ))
Если серьезно, то в разработке ПО менеджер проекта это довольно устаканившаяся роль, с четкими понятными ожиданиями и с определенным набором скиллов.
ПМ, в моем понимании этой роли, выступает как исполнитель — то есть не погружен глубоко в бизнес, цели и метрики. Он на входе получает задачу, декомпозирует ее, передает в разработку и следит за ее выполнением.
Продюсер в этой концепции делает почти все тоже самое, но больше погружен в бизнесовую составляющую продукта. То есть на входе он может получить не уже оформленную задачу, а гипотезу и дальше дотащить ее до реализации. Этакий сплав продакта и проджекта.
Вот поэтому решил ввести другой термин, чтобы сходу обозначить разницу. Ну и забайтить немножко :)
пропагандирую разработку через цели и метрики :)
Возможно я не совсем правильно спозиционировал статью. Я не утверждаю, что цели должны ставить обычные исполнители. Цели ставит команда, а в команде, по крайней мере у нас, всегда есть менеджерские роли ответственные за это. И да, клиент играет в постановке целей главную роль. Мы, как команда, просто помогаем ему с формулированием этих целей и определением задач, которые помогут этих целей достичь. Цели транслируются исполнителям в виде задач и приоритетов. Но это не значит, что исполнители просто бездумно работают по ТЗ, они в любом случае погружены в цели продукта и двигаются к ним.
Я так же считаю, что рынок сломан подходом «Без ТЗ результат ХЗ». Мне больно видеть ситуации, когда крутые продукты проваливаются просто потому, что обе стороны не договорились на берегу зачем мы что-то делаем и как. И потом возникают конфликты — клиент дурак, потому что не поставил нормально задачу, а разработчики плохие, потому что сделали не то, что я хотел. И все как будто бы согласны, что это нормально. Я так не считаю.
Поэтому, вместо того, чтобы ждать пока клиент наймет себе продакт оунера или научится сам формулировать задачи для разработчиков, я предлагаю проактивную позицию. Да, такой подход требует чуть больше погружения от исполнителей. Не все исполнители готовы переходить на такой уровень и это нормально. Они просто могут хорошо программировать/тестировать/дизайнить и оставаться востребованными.
Ну и по моему опыту клиент готов платить больше денег за такой подход. И это хорошие новости :)
А когда наступает это самое нужно и кто это определяет?
Я не против классической версии, мы от нее не сильно отошли на самом деле, а модернизировали:
Проблема классического подхода в том, что список не детализированных юзер сторей в самом начале проекта не особо помогает команде и бизнесу понять зачем мы все это делаем и как. Это похоже на список покупок в магазине. Можно предположить какой салат у нас получится из этих ингридиентов, но не зная результата, можем забыть что-то важное без чего блюда не получится.
А еще юзер стори без уточнения просто невозможно объективно приоритезировать. Что самое важное, что сделать проще всего и это даст максимальный результат.
Поэтому вместо юзер сторей в самом начале мы всегда определяем цели и формулируем гипотезы по их достижению. Гипотезы тоже можно формулировать в виде юзер сторей, если вам так удобней. Но мне здесь больше нравится декларативный подход — сделать интерфейс создания тренировки. Он понятней, точнее и в виде задачи, которую надо решить.
На этом этапе мы приоритезируем — выделяем основные гипотезы, с которыми надо работать в первую очередь.
Потом эти гипотезы перевариваются в документ.
Документ это тоже набор сценариев. Сначала они в виде заголовка, например «Тренер создает тренировку».
Детализируем сценарии для того, чтобы:
1. Синхронизировать ожидания бизнеса и команды.
2. Разобраться как сценарии будут дружить друг с другом. Это, кстати, решает основную, на мой взгляд, проблему разработки через юзер стори без глубокой проработки — часто сценарии противоречат друг другу и мы в будущем можем очень много проблем из-за этого получить.
3. Определить риски, объем работ, получить новые идеи по реализации, новые гипотезы.
4. Понять какая архитектура продукта будет.
5. Оценить объем работ, выделить версии релизов и сроки, запланировать работу команды.
Ну а финальный USM, который мы собираем после этого — просто удобный способ визуализации всего, что мы проделали до этого.
Здесь важно уточнить еще, что наш подход хорошо ложится на запуск новых продуктов или глубокую модернизацию существующих. Если мы занимаемся развитием продукта и команда на проекте стабильная, то классическая версия проектирования через юзер стори очень хорошо работает и мы ею пользуемся.
До того как мы внедрили такой процесс часто не хватало понимания что то, что мы делаем на самом деле влияет на цели пользователей и продукта, а не просто наши галлюцинации.
То что вы внедрили возможность такой модели в свой продукт заслуживает только уважения :)