1.9
Команда внутреннего продукта
Поймем кто нужен в команду и как ее запустить
Содержание урока
1. Анализ необходимых компетенций
2. Мероприятие "запуск команды"
3. Итерационно-инкрементальная разработка
4. Главная мысль урока.
5. Домашнее задание
1. Анализ необходимых компетенций.

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

В результате выполнения заданий урока 6 у вас появился верхнеуровневый беклог вашего продукта. Он содержит перечень полезных клиенту функций (будем называть их "фичи", независимо от того, делаете вы ИТ-продукт или нет) Очень важно, чтобы это был не список задач (что нужно сделать), а список фич (что получится в результате ваших действий). Идеально, если ваши фичи сформулированы в формате Job Story

Расположите фичи от самой важной и полезной вашему клиенту до дополнений и улучшательств, без которых на первом этапе можно и обойтись

Service Blueprint, который вы построили ранее, поможет вам разобраться какие компетенции понадобятся, чтобы выполнить любую фичу вашего беклога от начала и до конца (от проектирования до передачи в пользование клиенту). Это предельно важно, провести такой анализ, вы должны четко понимать кто должен принять участие в разработке, коммуникации, обучении, настройке справочников, рабочих мест ваших клиентов вплоть до момента, когда он придет на рабочее место, включит компьютер и начнет выполнять свою задачу новым способом при помощи вашего решения. Чтобы соотнести фичи и компетенции, мы рекомендуем инструмент Feature Map (карта фич).

Карта фич Feature Map
Когда карта построена, можно заняться анализом нижней строки. У вас есть следующие опции:
- нанимать внутри компании или заключать договоры с подрядчиками снаружи
- общаться с подрядчиком через техническое задание или нанять его сотрудников на условиях договора time material
- нанимать команду на полную или частичную занятость. Здесь принять решение как раз поможет Feature Map. Ваша команда может состоять из постоянно действующего "ядра" и ряда привлеченных экспертов на условиях частичной занятости. В примере, приведенном на рисунке выше видно, что компетенции 1,2 и 3 стоит нанимать на условиях полной занятости (они вовлечены в создания большинства фич), а компетенцию 4 можно разово привлечь на условиях частичной занятости в качестве эксперта


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

Мы всегда рекомендуем разработку собственной командой, выделенной на 100%, потому что только такую команду можно замотивировать на движение к цели и клиентоориентированность, но бюджетные и организационные ограничения также надо учитывать



2. Мероприятие "Запуск команды"

Когда вы определились с составом команды, будет отлично, если вы соберете всех причастных к вашему продукту на мероприятие, которое называется "Запуск команды".
Цель этого мероприятия - выровнять понимание задач разработки, определиться с подходом к работе, договориться о метриках и результатах, участниках, регулярных мероприятиях и отчетности, которой вы будете обмениваться по ходу работы.
Ожидаемый результат: полное вовлечение в задачи разработки продукта всех причастных к нему лиц, что повысит эффективность вашей работы (не придется каждый раз убеждать людей дать вам информацию, помочь с ресурсами или потестировать ваш продукт, всем будет понятно что, для кого и зачем вы делаете)

Обязательные участники запуска

- Владелец продукта
- Стейкхолдеры
- Представители клиентских сегментов
- команда разработки или представители подрядчика/вендора
- эксперты

Продолжительность - до 4 часов с двумя перерывами

Дизайн мероприятия

1 этап: Владелец продукта рассказывает:

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

На этом этапе можно отпустить стейкхолдеров и клиентов, так как далее будет работать команда

2 этап: Команда, Владелец продукта и приглашенные эксперты совместно:

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

Рекомендуемые критерии:
- ценность фичи (степень влияния реализации данной фичи на метрики продукта. Чем сильнее фича влияет на результат, тем выше ее ценность)
- сложность выполнения фичи: трудозатраты, готовность реализовать эту фичу прямо сейчас, наличие ресурсов, понимание что именно и кому надо делать.
Совокупность ценности и сложности дает нам представление о приоритете. Берем за основу принцип: сначала самая ценная кратчайшая работа (weightest shortest job first) и из всего беклога выбираем задачи имеющие наибольшую ценность, которые при этом быстрее всего сделать.

2.2 Описывают путь одной фичи от взятия ее из беклога до передачи клиенту для использования в работе (важно! не передача на тестирование, а передача клиенту в работу)

2.3 Определяют явные политики передачи фичи с этапа на этап или из статуса в статус (например, при каких условиях мы будем считать, что бизнес-аналитик закончил свою работу и может передать задачу в разработку)

2.4 Договориться о регулярных мероприятиях, времени и месте их проведения (рекомендуется договориться о длине итерации, планировании, регулярных коротких, но частых "летучках" по выяснению статуса, демонстрации результатов итераций клиентам и стейкхолдерам)

2.5 Выделить функции для минимального жизнеспособного продукта (с чего начнем разработку и что передадим пользователям в первую очередь. Здесь же решаются задачи, которые часто бывают нужны на старте нового продукта: заполнение справочников, настройка сред разработки и тестирования, разворачивание серверов, организация рабочих мест и прочие подготовительные мероприятия.
Результатом тут должен стать проработанный план на первую итерацию работы команды.

3 этап. Финализация запуска

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

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

2. Итерационно-инкрементальная разработка

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

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

1 этап (1-3 месяца): Разработка минимального жизнеспособного продукта. То есть разработка такого продукта, который будет обладать минимально возможным функционалом, но уже будет решать самые важные для клиента задачи, может быть не в финальном для него виде. Этап заканчивается получением обратной связи от клиентов, уже поработавших с продуктом, и уточнением беклога продукта на основе выводов.

2 этап: разработка функционала. Вы приоритизируете беклог, исходя из задач ваших клиентов и новой информации от них и делите весь этап разработки продукта на отрезки (итерации). Не так важно, чтобы эти отрезки были равной длинны, как важно, чтобы каждый из них заканчивался выдачей готовой фичи в пользование вашему клиенту и сбором обратной связи от него (в любой форме). Отдали фичу, собрали обратную связь, обсудили в команде. Идеально, если за каждой фичей у вас закреплена конкретная метрика, которая должна измениться после того, как сотрудник начал выполнять задачу новым способом. Например, вы автоматизировали какой-то отчет, который должен сократить время на обработку информации сотрудником какого-то отдела. У вас есть замеры времени при выполнении этой задачи старым способом, вы передаете фичу, производите замеры сколько теперь времени занимает подготовка отчета и оцениваете выполнение метрики. Тогда вы еще и будете видеть как постепенно улучшаются показатели всего процесса и это будет дополнительно мотивировать команду, так как ваша работа приносит реальный результат.
Типичные ошибки формирования и запуска команды:
1. Недостаточный анализ компетенций на основании неполного беклога продукта может привести к тому, что посредине этапа разработки вы останетесь без нужных людей и будете вынуждены остановить процесс
2. Избыточное количество (более 10) узкоспециализированных участников вашей команды приведет вас к ненужным затратам на их бесконечную координацию замену, информирование. Даже собрать этих людей вместе хотя бы раз в неделю будет для вас большой проблемой. Поощряйте обучение внутри команды, когда каждый участник имеет одну базовую компетенцию и несколько не таких глубоких, тогда люди в вашей команде будут взаимозаменяемы
3. Пренебрежение мероприятием "запуск команды" приведет к потерям времени на вовлечение в работу каждого эксперта и стейкхолдера по отдельности
Главная мысль урока
Компетенции вашей команды должны быть напрямую связаны с полным беклогом продукта.

Команда может состоять как из сотрудников компании, так и из сотрудников вендора/ подрядчика. Очень важно чтобы ядро команы было выделено на проект с загрузкой 100% Это повысит скорость вашей разработки в разы

Важно провести процедуру запуска команды для выравнивания ожиданий всех участников

Если вы хотите заниматься действительно клиентоориентированной разработкой, значит вам нужно организовать работу так, чтобы в конце относительно коротких промежутков времени (до одного месяца) вы могли бы отдавать клиенту новую функциональность вашего продукта, чтобы как можно чаще получать от него обратную связь.
Задание
Разработайте и приложите Feature Map вашего продукта с принятыми решениями по внешней/внутренней разработке и загрузке участников команды
E-mail
Задание
форма для отправки
Комментарии