Как не запутаться при реализации ТЗ

Введение

Как не запутаться при реализации ТЗ

В предыдущий раз, мы успешно подготовили ТЗ и дали ему предварительную оценку, определили выгоды (я считаю определение выгод, ключевая часть ТЗ – это наш маяк, не тифту ли мы делаем). Вот и настал радостный миг перехода в производственный ад.

Постоянные встречи, обсуждения, реализация, тестирование, написание документации, вывод в продуктовую среду, сопровождение и всё это нас ждёт на производстве, такой puerperium mobile. Нам важно не утонуть в пучине событий и не погрузить в унынье команду реализации, нельзя допускать цейтнот.

Постановка задачи

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

Суть подхода

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

Шаг 1 Структура задач

Я предлагаю взять them, epic, story, task (их рассмотрим в шаге 2) – данные обозначения большинству из Вас известны, я лишь предлагаю наполнить их данными из нашего дерева целей и ТЗ. Лишь позволю себе напомнить, у каждого процесса обязательно должны быть параметры входа и выхода, без это хаос вернется в ваш backlogJ

Them – это глобальная цель проекта/продукта. Можно применять, когда у вас несколько не связанных с собой продуктов

Epic – принимаем, что это сквозной бизнес процесс. Т.е. процесс, который обеспечивает взаимодействие с Пользователем от точки входа, до выхода, т.е. удовлетворения его потребностей

Story – бизнес процесс, который отвечает за определенную часть Epic

Пример 1: Them – домашний быт (тема прям необъятная). Возьмем Epic «Приготовление пищи». Замечу, с точки зрения процесса не имеет значения, для чего мы готовим пищу завтрак, обед, полдник, ужин, званный ужин(!) с точки зрения реализации он сквозной.

Epic включает в себя набор Story

  • Определение типа приёма пищи
  • Выбор меню
  • Оценка потребностей в продуктах для приготовления
  • Заказ продуктов
  • Приемка продуктов (процесс необходим, в противном случае оценку потребностей в продуктах будет сделать невозможно)
  • Выдача продуктов (например, из холодильника)
  • Приготовление пиши
  • Сервировка стола
  • Приём пищи

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

Шаг 2 Обозначение обязательных задач

Для полноценного инструмента, нам необходим определенный набор task ов, который позволит нам всё связать в единые цепочки с деревом целей, ТЗ и построением обратной связи

Пример 2: Список задач я опишу с минимальным количеством артефактов, прошу учитывать, что это лишь мое видение, которое позволяет сформировать инструмент по непопаданию в производственный ад, на сам подход или распределение ролей это никак не влияет. Нам необходимы следующие задачи, в скобках примеры артефактов:

  • Бизнес анализ (CJM, Макеты, Use Case, Описание бизнес процесса)
  • Системный анализ (ER диаграмма, Sequence диаграмма, Описание методов взаимодействия)
  • Инфраструктурные работы (разворачивание стендов и ПО на них)
  • Разработка DB
  • Разработка Back
  • Разработка Front
  • Тестирование
  • Документирование (Руководство Пользователя, Руководство Администратора)
  • Приемка (прием функционала и его последующая демонстрация)

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

Шаг 3 Необходимые связи и смыслы

Данный шаг позволит скрепить все наши задачи с деревом целей и ТЗ. При внесении изменений данный шаг нам позволит с минимальной корректировкой данных подготовить обновленную документацию. На каждом этапе мы используем одни и те же Use Case именно они являются источником данных для бизнес-анализа, описания диаграммы последовательностей (sequence), тестирования (на основе use case тестировщик проверяет работоспособность функционала), документирования, демонстрации.

Именно use case отражает последовательность действий

Шаг 4 Построение обратной связи

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

Так же данный подход позволит оценить качество организации производственного процесса, но и качество реализации. Это отдельный многогранный вопрос, который не является предметом рассмотрения в данной статье.

Выводы

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

Таким образом мы избежим производственного ада, и каждый участник команды будет понимать, что происходит.

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

Глоссарий:

По выгодой понимается любая полезность для достижения целей проекта/продукта, как финансовая, так и не финансовая

puerperium mobile (лат.) – вечный двигатель

Цейтнот – в партии в шахматах, шашках или иных пошаговых играх — недостаток времени для обдумывания ходов.

33
Начать дискуссию