Процесс изготовления продукта

В данной статье я делюсь своими размышлениями из опыта работы. Данная статья болше будет полезна для руководителя отдела разработки (технический директор), но так же рекомендую ее к изучению менеджеру по продукту (человеку принимающему задачи от бизнеса), ведущему разработчику и даже разработчику, для понимания, что и как происходит в компании и кто за что ответсвенен.

В компании должен быть использован инструмент для ведения документации по изготовлению продукта (например confluence). В данном инструменте должны быть разделы:

Стимулы к развитию продукта

Например ... активно формирующаяся (в России) потребность рынка в ...

Цели и критерии успеха

Сделать использование продукта стандартом для малого и среднего бизнеса. Критерии успеха: 1. ...

Целевой рынок и сегменты

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

Анализ конкурентов

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

Карты эмпатии и проблемы пользователей

Здесь нужно описать роли своих пользователей и согласно ролям ответить на следующие вопросы:

  • Роль
  • Что конкретно делает этот человек в течении дня
  • Что он видит и слышит вокруг себя из разных источников
  • Что он делает и на что тратит больше всего времени
  • Какие его основные переживания
  • Каковы его боли и страхи
  • В чем он нуждается
  • Что делает его счастливым
  • Что он говорит на публике

Функционал продукта

Обязательный функционал (минимум для выхода продукта на рынок и его работы).

• Функционал А

  • Требование 1 (имеет версионирование)
    • Идея (User Stories)
    • Диаграммы UML (схемы)
    • Реализация (список эпиков/задач в таск-трекере, и статусы этих задач)
  • Требование 2 (имеет версионирование)
  • ... и т.д.

• Функционал Б
• ... и т.д.

Инновационный функционал

Дополнительный функционал, обычно то, чем продукт отличается от продукта конкурентов, по структуре повторяет раздел "Функционал продукта".

Идеи

Идеи - 100% нереализованный функционал, по структуре повторяет раздел "Функционал продукта".

• Новые

  • Идея 1
  • Идея 2
  • ... и т.д.

• Исследование - сюда попадают идеи, описание которых оказалось недостаточным 

• Принятные

• Отклоненные

Релизы (Release) 

• Год 20..

  • Месяц 1
    • Sprint 1
    • Sprint 2
    • ... и т.д.
  • Месяц 2
  • ... и т.д.

• Год 20..

• .. и т.д.


Далее я хочу рассказать про то, как продукт изготовляется (про процесс).

Описание процесса производства

Основные этапы цикла разработки

Процесс изготовления продукта

* обратите внимание, что на этот этап попадают как задачи по реализации нового функционала/доработок (Task), так и задачи по исправлению ошибок (Bug).

Проработка идеи (первый желтый блок в схеме выше)

Процесс заведения и работы с идеями, а так же роли, участвующие в процессе, приведены на схеме ниже.

Процесс изготовления продукта

Инициализация

Идеи для развития сервиса может предлагать любой сотрудник компании. Достаточно сформулировать Идею и кратко описать ее в соответствующем разделе, ответив на следующие вопросы:

  1. Для кого
  2. Какая проблема решается
  3. Ценность решения
  4. Подробное описание
  5. Статус
  6. Важность
  7. Срочность исполнения
  8. Если это идея клиента, то готов ли клиент заплатить за реализацию 

Аналитика

В рамках каждой идеи PM (Project Manager) проводит:

• Исследование идеи (при участии маркетинга) выполняется тщательный сбор информации, и описывает функциональность (составление ТЗ)

  • Макеты экрана. Все всплывающие окна и прочие элементы должны быть нарисованы. Каждый экран должен иметь версии различных состояний (Подробнее о состояниях):
    • Пустое состояние. Это стартовое состояние экрана, которое видит пользователь.
    • Промежуточное состояние. Эта версия экрана, которая показывает частичное заполнение полей или использования других видов элементов управления.
    • Ошибки. Эта версия экрана должна отражать все возможные варианты ошибок и реакции системы на них
    • Активное состояние. Эта версия экрана отражает состояние, при котором система обрабатывает данные и демонстрирует пользователю, что процесс идет, а не повис.
    • Идеальное состояние. Эта версия показывает экран при идеальном его использовании, когда нет ошибок, сбоев и пользователь в 1 клике от кнопки «Ок», «Сохранить» или чего-то подобного, что приведет к идеальному переходу задачи на следующий экран или к успешному завершению работы сценария.
  • Таблица с описанием полей. В строке таблицы должны располагаться следующие данные: название поля, тип поля, ограничение на ввод данных (логические проверки и т.д.), роли пользователей, которым доступно чтение/редактирование поля. Если поле расчетное – то необходимо указывать формулу для расчета значения.
  • Таблица с описанием действия кнопок экрана. В строке таблицы должны содержаться данные о названии кнопки, описание действия при клике и путях перехода, если щелчок по кнопке предполагает переход на другой экран, роли пользователей, которым доступно действие.

• Подготавливает презентацию идеи (PP - planning purpose) (при участии дизайнеров создание дизайна/мокапов/прототипов) и оценивает (при участии сотрудников отдела разработки)

• Проверяет зависимости (кого нужно будет привлеч для реализации идеи)

Ответственным за выполнение задачи на протяжении всего этого этапа остается PM, он же выступает координатором между всеми участниками работ данного этапа.

Идея принята, дальше директор:

  • Выставляет приоритет идеи
  • Выполняет проработку требований (проработка описания будущей функциональности)
  • Создание задачи в таск-трекере (согласно требованию)

Требования/проектирование (второй желтый блок в схеме выше)

Неважно, задача поставлека как фича или ошибка в каком-то функционале, результат — создание задачи в таск-трекере и исполнитель - TeamLead. В описании задачи обязана быть указана ссылка на страницу требований (включающей версию требований) или описание бизнес-требовании (это нужно делать обязательно, чтобы четко обозначить требования на текущий момент). Плюс, PM добавляет в раздел Реализация, номер и имя задачи, которую только что создал.

Разработка (первый зеленый блок)

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

EPIC - задача с подзадачами, для достижения запланированного результата.

Task - обычная задача, доработка, дополнение или улучшение, связанные функционалом сервиса (не ошибка).

Bug - ошибка в функционале продукта, обычная задача, которя может стать EPIC-ом, если ее разобьют на подзадачи.

После проработки технических нюансов, задача готова для переключения на конкретного ответственного исполнителя и вносится в план разработки. После завершения работ задача передается в тестирование.

Приоритеты задач

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

  • Blocker. Задача требует немедленного вмешательства Developer-a
  • Critical. Критично для работы сервиса, но не так чтобы все рушится
  • Major. Повышенный приоритет для выделения внутри плановых задач
  • Minor. Пониженный приоритет для выделения внутри плановых задач
  • Trivial. Косметические изменения, можно отложить до тех пор, пока все остальные задачи не будут выполнены

Workflow задачи

Прежде чем начать ознакомление с рабочим потоком, давайте разберемся с ролями:

  • CTO (Chief technical officer) - руководитель отдела разработки (технический директор)
  • PM (Project Manager) - менеджер по продукту (принимает задачи от бизнеса)
  • Team leader - ведущий разработчик
  • Developer - разработчик

У каждой задачи есть цикл жизни, который определяется последовательной сменой статусов задачи в таск-трекере.

Цикл жизни EPIC Кто выставляет статус Кто занимается задачей   Цикл жизни Task / Bug Кто выставляет статус Кто занимается задачей
 OPEN Project Manager Project Manager    OPEN

Team leader, или Reporter

Team leader,Reporter

 READY FOR DESIGN Project Manager Team leader    READY FOR DESIGN Team leader Developer
 IN DESIGN Team leader Team leader    IN DESIGN Team leader или Developer Team leader или Developer
 FOR DESIGN CHECK Team leader CTO (при отсутсвии CTO - Team leader)     FOR DESIGN CHECK Team leader или Developer Team leader
 READY FOR DEV CTO (при отсутсвии - Team leader)  Team leader    READY FOR DEV Team leader Developer
 IN DEV Team leader Team leader    IN DEV Developer Developer
         CODE REVIEW Developer Developer
         READY FOR DEPLOY Developer Team leader
         IN TESTING Team leader Developer
 WAIT FOR DEMO Team leader Project Manager    WAIT FOR DEMO Developer Project Manager
 CLOSED Project Manager никто    CLOSED Project Manager никто
 ON HOLD Любой из выше перечисленных Сотрудник компании, который может поспособствовать переходу задачи на следующий статус    ON HOLD Любой из выше перечисленных  Сотрудник компании, который может поспособствовать переходу задачи на следующий статус

Теперь стоит описать каждый статус.  

Статус

Расшифровка

Описание

OPEN Новая задача

Постановщик задачи создает задачу в таск-трекере, указывает приоритет и описывает бизнес-требования.

READY FOR DESIGN Задача готова к декомпозиции

Задача на этом этапе готова к декомпозиции.

IN DESIGN На декомпозиции

Выполняется декомпозиция задачи (задача описывается так, чтобы ее понял разработчик, если нужно задача разбивается на подзадачи).

FOR DESIGN CHECK Задача готова к проверке декомпозиции

Задача переводится на Руководителя проекта (данный статус может быть пропущен, если Руководителя проекта нет или в компании доверяют TeamLead-у. На данном этапе проверяется полнота требований, и все ли необходимые материалы приложены к задаче.

READY FOR DEV Задача готова для начала разработки

Задача на этом этапе готова к разработке (при необходимости декомпозирована на Task-и и приоритеты расставлены, конечные исполнители назначены).
Проверена полнота требований, все необходимые материалы приложены.

IN DEV Поступила в разработку Реализация задачи. Статус проставляется, когда конечный исполнитель начинает работу над Task.
CODE REVIEW Проверка кода Перевод задачи в этот статус означает готовность к проверке качества выполнения задачи.
Это может быть как Code Review кода задачи, так и проверка написанной документации, тестов и т.п.
READY FOR DEPLOY Задача готова к выкладке После проведения Code Review и отсутствия замечаний, задача считается решенной и готовой к тестированию.
Задача вливается в ветку от которой была ответвлена и продукт выливается на test-сервер.
IN TESTING Задача в тестировании После проведения деплоя и прохождения авто-тестов, задача считается готовой к всесторонему тестированию.
WAIT FOR DEMO Ожидает демонстрации

Задача выполнена, выложена на test-сервер и готова к проведению демо. После успешного тестирования, задача готова к деплою на один из конечных серверов:
production или beta (в зависимости от типа задачи).

После проведения демо по задаче возможно создание ряда доработок (заведение Task).

CLOSED Задача выполнена Статус проставляется, если закрыты и приняты на демо все задачи, включенные в EPIC.
REOPENED Задача требует доработки/исправления ошибок Переоткрытие происходит, если после проведения демо найдены недоработки. Статус REOPENED задача может получить со стадий разработки CODE REVIEW и IN TESTING, если найдены недоработки. После получения этого статуса, цикл работы над задачей возобновляется по обычному сценарию.
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


Оцени публикацию:
  • 0,0
Оценили человек: 0

Похожие статьи:


Предложения и пожелания:
Ваше имя:
Ваш E-mail:
Сколько будет Οдин + Τри
Главная
X

youtube.com/watch?v=7hFivbgIEqk

При полном или частичном использовании материалов данного сайта, ссылка на сайт "yapro.ru" обязательна как на источник информации.
Автоматический импорт материалов и информации с сайта запрещен.
Copyrights © 2007 - 2017 YaPro.Ru

Главная » Веб-мастеру » Интересное »