Процесс изготовления продукта
Данный материал о том, как выстроить процесс изготовления продукта, что и как происходит в подразделении компании и кто за что ответственен. Вектор данной статьи это фраза Ицхака Адизеса: "Успех - когда клиенты возвращаются (спросите себя, если бы у человека был выбор, вернулся бы он). Концепция изготовления продукта - продукт должен быть актуален минимум в течении 30 лет.
Информация
В компании/подразделении должен быть использован инструмент для ведения документации по изготовлению продукта (например confluence). В данном инструменте должны быть разделы:
Стимулы к развитию продукта
Например ... активно формирующаяся (в России) потребность рынка в ...
Цели и критерии успеха
Сделать использование продукта стандартом для малого и среднего бизнеса. Критерии успеха: 1. ...
Целевой рынок и сегменты
Тут описываются потребители продукта, и какую проблему для указанного потребителя решает продукт (лучше с иерархией, вплоть до должностных позиций в компании потребителя).
Анализ конкурентов
Список конкурентов с подразделами, в которых описываются интересные особенности, которые, возможно хотелось бы тоже иметь.
Карты эмпатии и проблемы пользователей
Здесь нужно описать роли своих пользователей и согласно ролям ответить на следующие вопросы:
- Роль
- Что конкретно делает этот человек в течении дня
- Что он видит и слышит вокруг себя из разных источников
- Что он делает и на что тратит больше всего времени
- Какие его основные переживания
- Каковы его боли и страхи
- В чем он нуждается
- Что делает его счастливым
- Что он говорит на публике
Функционал продукта
Обязательный функционал (минимум для выхода продукта на рынок и его работы).
• Функционал А
- Требование 1 (имеет версионирование)
- Идея (User Stories)
- Диаграммы UML (схемы)
- Реализация (список эпиков/задач в таск-трекере, и статусы этих задач)
- Требование 2 (имеет версионирование)
- ... и т.д.
• Функционал Б
• ... и т.д.
Инновационный функционал
Дополнительный функционал, обычно то, чем продукт отличается от продукта конкурентов, по структуре повторяет раздел "Функционал продукта".
Идеи
Цель идея не планирование, а фантазии, это то, что нужно делать "сегодня", чтобы быть готовым к "завтрашнему" дню.
Как распознать талантливую идею - задайте себе такие вопросы:
- ахнул ли я от удивления, когда впервые увидел ее воплощенной
- сожалею ли, что это не я придумал
- оригинальна ли сама идея
- сможет ли она прожить тридцать лет
Идеи - 100% нереализованный функционал.
Данный раздел состоит из подразделов:
- Исследование - раздел с идеями, описание которых оказалось недостаточным (новые идеи тоже тут).
- Принятые - раздел с идеями, обоснование и описание которых достаточно для реализации.
- Отклоненные - раздел с идеями, которые возникали, но которые было решено не воплощать. Раздел нужен для того, чтобы была история о том, почему идею отвергли или отложили до лучших времен.
Каждый подраздел это список вида:
- Идея 1
- Идея 2
- ... и т.д.
Релизы (Release)
• Год 20..
- Месяц 1
- Sprint 1
- Sprint 2
- ... и т.д.
- Месяц 2
- ... и т.д.
• Год 20..
• .. и т.д.
Далее я хочу рассказать про то, как продукт изготовляется (про процесс).
Описание процесса производства
Основные этапы цикла разработки
* обратите внимание, что на этот этап попадают как задачи по реализации нового функционала/доработок (Task), так и задачи по исправлению ошибок (Bug).
Проработка идеи (первый желтый блок в схеме выше)
Процесс заведения и работы с идеями, а так же роли, участвующие в процессе, приведены на схеме ниже.
Инициализация
Идеи для развития сервиса может предлагать любой сотрудник компании. Достаточно сформулировать Идею и кратко описать ее в соответствующем разделе, ответив на следующие вопросы:
- Для кого
- Какая проблема решается
- Ценность решения
- Подробное описание
- Статус
- Важность
- Срочность исполнения
- Если это идея клиента, то готов ли клиент заплатить за реализацию
Аналитика
В рамках каждой идеи PM (Project Manager) проводит:
• Исследование идеи (при участии маркетинга) выполняется тщательный сбор информации, и описывает функциональность (составление ТЗ)
- Макеты экрана. Все всплывающие окна и прочие элементы должны быть нарисованы. Каждый экран должен иметь версии различных состояний (Подробнее о состояниях):
- Пустое состояние. Это стартовое состояние экрана, которое видит пользователь.
- Промежуточное состояние. Эта версия экрана, которая показывает частичное заполнение полей или использования других видов элементов управления.
- Ошибки. Эта версия экрана должна отражать все возможные варианты ошибок и реакции системы на них
- Активное состояние. Эта версия экрана отражает состояние, при котором система обрабатывает данные и демонстрирует пользователю, что процесс идет, а не повис.
- Идеальное состояние. Эта версия показывает экран при идеальном его использовании, когда нет ошибок, сбоев и пользователь в 1 клике от кнопки «Ок», «Сохранить» или чего-то подобного, что приведет к идеальному переходу задачи на следующий экран или к успешному завершению работы сценария.
- Таблица с описанием полей. В строке таблицы должны располагаться следующие данные: название поля, тип поля, ограничение на ввод данных (логические проверки и т.д.), роли пользователей, которым доступно чтение/редактирование поля. Если поле расчетное – то необходимо указывать формулу для расчета значения.
- Таблица с описанием действия кнопок экрана. В строке таблицы должны содержаться данные о названии кнопки, описание действия при клике и путях перехода, если щелчок по кнопке предполагает переход на другой экран, роли пользователей, которым доступно действие.
• Подготавливает презентацию идеи (PP - planning purpose) (при участии дизайнеров создание дизайна/мокапов/прототипов) и оценивает (при участии сотрудников отдела разработки)
• Проверяет зависимости (кого нужно будет привлеч для реализации идеи)
Ответственным за выполнение задачи на протяжении всего этого этапа остается PM, он же выступает координатором между всеми участниками работ данного этапа.
Идея принята, дальше директор:
- Выставляет приоритет идеи
- Выполняет проработку требований (проработка описания будущей функциональности)
- Создание задачи в таск-трекере (согласно требованию)
Требования/проектирование (второй желтый блок в схеме выше)
Неважно, задача поставлека как фича или ошибка в каком-то функционале, результат — создание задачи в таск-трекере и исполнитель - TeamLead. В описании задачи обязана быть указана ссылка на страницу требований (включающей версию требований) или описание бизнес-требовании (это нужно делать обязательно, чтобы четко обозначить требования на текущий момент). Плюс, PM добавляет в раздел Реализация, номер и имя задачи, которую только что создал.
Разработка (первый зеленый блок)
TeamLead переводит задачу с языка бизнес-требований на язык разработки, проектирует архитектуру нового функционала, определяет прогнозы по срокам, а так же приоритет задач. TeamLead может декомпозировать задачу (разбить на подзадачи, если это нужно). Далее я опишу 3 вида задач:
EPIC - задача с подзадачами, для достижения запланированного результата.
Task - обычная задача, доработка, дополнение или улучшение, связанные функционалом сервиса (не ошибка).
Bug - ошибка в функционале продукта, обычная задача, которая может стать EPIC-ом, если ее разобьют на подзадачи.
После проработки технических нюансов, задача готова для переключения на конкретного ответственного исполнителя и вносится в план разработки. После завершения работ задача передается в тестирование.
Приоритеты задач
Абсолютно любой задаче перед постановкой необходимо задать приоритет выполнения. Возможны следующие приоритеты задач (от наивысшего к менее приоритетным):
- Blocker. Задача требует немедленного вмешательства Developer-a
- Critical. Критично для работы сервиса, но не так чтобы все рушится
- Major. Повышенный приоритет для выделения внутри плановых задач
- Minor. Пониженный приоритет для выделения внутри плановых задач
- Trivial. Косметические изменения, можно отложить до тех пор, пока все остальные задачи не будут выполнены
Отличие флоу у эпика и задачи:
| Цикл жизни EPIC | Кто выставляет статус | Цикл жизни Task / Bug | Кто выставляет статус | |
| OPEN | Project Manager | OPEN | Team leader, или Reporter | |
| READY FOR DESIGN | Project Manager | READY FOR DESIGN | Team leader | |
| IN DESIGN | Team leader | IN DESIGN | Team leader или Developer | |
| DESIGN CHECK | CTO (при отсутствии CTO - Team leader) | DESIGN CHECK | Team leader или Developer | |
| READY FOR DEV | CTO (при отсутствии - Team leader) | READY FOR DEV | Team leader | |
| IN DEV | Team leader | IN DEV | Developer | |
| TO REVIEW | Developer | |||
| IN REVIEW | Developer | |||
| READY FOR TESTING | Developer | |||
| IN TESTING | QA | |||
| READY FOR DEPLOY | QA | |||
| ON PROD | ||||
| WAIT FOR DEMO | Team leader | WAIT FOR DEMO | Team leader или Developer | |
| IN DEMO | Project Manager | |||
| CLOSED | Project Manager | CLOSED | Project Manager | |
| ON HOLD | Сотрудник у которого возник вопрос к другому сотруднику/отделу или сотрудник который ответил на вопрос. | ON HOLD | Любой из выше перечисленных |
Цикл жизни Task / Bug
Если задача не связана с написанием кода/не требует деплоя (например, написание документации), то она может сразу же перейти в статус CLOSED.
Переход задачи в статусы: IN TESTING, READY FOR DEPLOY, CLOSED отслеживаются ответственными за каждый из этапов (с помощью фильтров таск-трекера) и выполняют требуемые действия.
Изменения статусов Task, Bug и EPIC происходят по следующей схеме:
* на схеме можно заметить статус RESOLVED - это устаревший эквивалент статуса WAIT FOR DEMO.
Таск-трекер
Стоит рассказать про некоторые моменты в нем.
Release / Sprint - некий список задач, который планируется выполнить к определенной календарной дате. Данные списки создаются в таск-трекере.
По результатам выполнения Спринтов, составляются отчеты, в которых можно посмотреть запланированные задачи и сколько из них было выполнено. Кроме плановых, в отчете содержится список "внеплановых" задач - те которые вклинились в план без очереди (обычно это критичные баги).
BackLog - список задач не вошедший ни в один Release / Sprint