+7 499 350 77 10
+7 499 322 88 70
+7 499 322 88 70
Постановка задачи в ИТ-проектах
- Денис БогдановВедущий эксперт YouTube-канала «ЦифраБуква»12-летний опыт работы в IT в качестве разработчика, аналитика, руководителя проектов, методолога системного анализа
Опыт работы в энергетике,
разработке государственных информационных систем
(контрольно-надзорные органы, образование),
транспортной логистике - Михаил МаксимовРезидент Клуба мышления Санкт-Петербурга
Ведущий эксперт YouTube-канала «ЦифраБуква»Автор и ведущий курсов по архитектуре предприятия и
управлению проектами в ВУЗах (СПб ГУТ, СПб ГУАП)
Опыт в IT 5 лет в качестве аналитика,
методолога бизнес/системного анализа
Выпускающие редакторы статьи — Анна Гасраталиева и Денис Бесков
Что такое постановка на реализацию в IT?
Техническое задание — это не то же самое, что и постановка на реализацию. Техническое задание — это результат обработки исходных (организационных, бизнес-) требований, их уточнения и перевода на системный/технический уровень.
Постановка задачи на реализацию — это описание способа реализации исходных требований, технического задания, архитектурного решения, изложение требований к устройству спроектированного решения (на этом этапе исходные требования уже обработаны).
Постановка задачи на реализацию — это описание способа реализации исходных требований, технического задания, архитектурного решения, изложение требований к устройству спроектированного решения (на этом этапе исходные требования уже обработаны).
Место постановки на реализацию
в процессе создания IT-продукта
в процессе создания IT-продукта
Постановка на реализацию (розовый блок на рисунке) выполняется в рамках проектирования (светло-зеленый) перед реализацией.
Процесс реализации ИТ-проекта от инициации идеи до внедрения и эксплуатации готового ИТ-решения
Техническое задание разрабатывается на этапах Инициации и Определения метода решения бизнес-задачи. Здесь мы говорим про выявление проблемы, сбор исходных требований, формирование какого-то запроса на решение этой проблемы.
Далее на этапе Определения метода решения мы занимаемся Уточнением требований. Здесь уже появляется структура функций, ИТ-продуктов будущего проекта. А постановка на реализацию описывает, как мы эти функции и продукты будем реализовывать.
Постановка описывает конкретную функцию, модуль, что-то максимально локализованное. Объектами постановки могут быть отдельные компоненты, модули или функции – в зависимости от того, как мы декомпозировали функциональную структуру системы/решения в техническом задании.
Далее на этапе Определения метода решения мы занимаемся Уточнением требований. Здесь уже появляется структура функций, ИТ-продуктов будущего проекта. А постановка на реализацию описывает, как мы эти функции и продукты будем реализовывать.
Постановка описывает конкретную функцию, модуль, что-то максимально локализованное. Объектами постановки могут быть отдельные компоненты, модули или функции – в зависимости от того, как мы декомпозировали функциональную структуру системы/решения в техническом задании.
Зачем нужна постановка на реализацию?
Постановка помогает:
- Определить границы, защититься от их изменений
- Зафиксировать критерии успешного результата
Кто пишет постановку на реализацию?
- Менеджер проекта / менеджер продукта
- Аналитик
- Тимлид разработки, например, когда аналитика на проекте нет. Тогда менеджер верхнеуровнево описывает необходимые функции, а команда разработки сама пишет для себя постановки и задачи.
Кому нужна постановка на реализацию?
- Менеджеру проекта (или продукта). Для менеджера постановка на реализацию выполняет защитную функцию: он понимает, что часть функциональности описана, все понимают что делать, границы реализации защищены.
- Аналитику. Сама по себе постановка – это способ документирования, к ней всегда можно вернуться, чтобы посмотреть как функция была реализована. Постановка – это хороший способ отслеживать свой результат.
- Команде. Именно в постановке есть описание того, что нужно делать. В постановке описывается некий облик решения, который позволяет команде разработать продукт не только в соответствии с требованиями, но и в соответствии с теми решениям, которые были приняты на верхнем уровне.
- Заказчику. Так, например, технический заказчик может активно участвовать в технических решениях. Бизнес-заказчик может согласовывать отдельные разделы постановки – ниже мы поговорим о том, что может быть ему интересно. Участие заказчика позволяет определить перечень требований, которые нужно реализовать в рамках этой постановки. Оно необходимо, чтобы понимать, что будет на выходе после реализации.
Основные разделы постановки на реализацию
Постановка на реализацию может содержать разделы:
- Контекст задачи
- Ключевые источники информации
- Заинтересованные стороны
- Критерии приемки результата
- Нефункциональные требования и ограничения
- Описание решения
Разделы постановки на реализацию
Рассмотрим эти разделы на примере:
Предположим, компания занимается продажей товаров через интернет (e-commerce). В целях привлечения новых клиентов и удержания существующих, компании требуется предоставить клиентам возможность получать дополнительную информацию при заказе товара.
Необходимо разработать сервис по расчету и предоставлению клиенту плановых сроков доставки заказа. Считаем, что до этого мы никаких сроков потенциальному клиенту не озвучивали.
Необходимо разработать сервис по расчету и предоставлению клиенту плановых сроков доставки заказа. Считаем, что до этого мы никаких сроков потенциальному клиенту не озвучивали.
Давайте пройдемся по разделам постановки и попробуем понять, какую информацию стоит в них отражать.
Раздел 1. Контекст задачи
Контекст задачи – это краткая информация о ситуации и проблемах, из-за которых возникла стоящая перед вами задача по автоматизации. Данная часть постановки – это, по сути, срез бизнес-требований, которые были собраны бизнес-аналитиком на предыдущем этапе.
Контекст задачи помогает:
Также данный раздел может содержать:
Приведём пример описания контекста бизнес-языком:
Контекст задачи помогает:
- сформировать «мостик» между заказчиком и исполнителем,
- минимизировать риск того, что решение будет оторвано от реалий будущего использования,
- разработчикам придумать лучшее решение,
- тестировщики могут разработать максимально приближенные к реальному использованию тест-кейсы,
- команде погрузиться в предметную область и прокачать экспертизу в предметной области,
- аналитику в трассировке требований на проблемы бизнеса.
Также данный раздел может содержать:
- Описание функций бизнес-языком
- Описание бизнес-процесса
- Бизнес-требования
- Перечень проблем бизнеса
Приведём пример описания контекста бизнес-языком:
“
Кейс: возможность предоставления клиенту плановых сроков доставки заказа
Компания не имеет собственных средств доставки грузов.
Базовые сроки доставки предоставляются сервисами компаний-перевозчиков, далее в них учитываются сроки подготовки заказа и риски, которые может учесть компания.
Дорабатываем систему Self Care в части отображения клиенту сроков доставки товара при оформлении заказа. Необходимо разработать АРМ для оператора call-центра, которому звонят с запросом сроков доставки.
Компания не имеет собственных средств доставки грузов.
Базовые сроки доставки предоставляются сервисами компаний-перевозчиков, далее в них учитываются сроки подготовки заказа и риски, которые может учесть компания.
Дорабатываем систему Self Care в части отображения клиенту сроков доставки товара при оформлении заказа. Необходимо разработать АРМ для оператора call-центра, которому звонят с запросом сроков доставки.
Для чего этот бизнес-контекст разработчикам?
Ведь решение уже есть, для чего давать исходные данные в виде контекста? Дело в том, что в некоторых случаях описание решения может быть менее конкретным. Риски по формированию детального решения можно переложить на команду. Если члены команды являются экспертами в предметной области, понимают как пользователь и бизнес будут этими функциями пользоваться, то они сделают более качественное решение.
Ведь решение уже есть, для чего давать исходные данные в виде контекста? Дело в том, что в некоторых случаях описание решения может быть менее конкретным. Риски по формированию детального решения можно переложить на команду. Если члены команды являются экспертами в предметной области, понимают как пользователь и бизнес будут этими функциями пользоваться, то они сделают более качественное решение.
“
Пример из практики:
Делали систему для компании, где работали операторы 24 часа в сутки. Специфика работы компании заключалась в том, что ночью было принято работать без света. Если не знать этой специфики, можно было бы сделать какой-то вырвиглазный интерфейс, в котором ночью работать было бы невозможно. А зная и понимая это, проектировщик интерфейсов разработал такие интерфейсы, которые позволяют работать одинаково удобно и днём, и ночью.
Делали систему для компании, где работали операторы 24 часа в сутки. Специфика работы компании заключалась в том, что ночью было принято работать без света. Если не знать этой специфики, можно было бы сделать какой-то вырвиглазный интерфейс, в котором ночью работать было бы невозможно. А зная и понимая это, проектировщик интерфейсов разработал такие интерфейсы, которые позволяют работать одинаково удобно и днём, и ночью.
Итого, контекст задачи в постановке нужно описывать, потому что:
- Мы можем делать постановку на разном уровне детализации.
- Чем выше уровень детализации постановки, тем больше места для маневра команды разработки. Это позволяет выбрать лучший вариант для решения поставленной бизнесом задачи.
Раздел 2. Ключевые источники информации
В этом разделе постановки речь идёт о едином перечне источников информации, описание которых снижает риск использования недостоверной информации.
Во-первых, это, конечно, глоссарий. Он необходим, чтобы заказчик, бизнес и команда оперировали одними и теми же согласованными терминами. Глоссарий должен быть приложен как один из источников информации.
Другие примеры ключевых источников информации:
Во-первых, это, конечно, глоссарий. Он необходим, чтобы заказчик, бизнес и команда оперировали одними и теми же согласованными терминами. Глоссарий должен быть приложен как один из источников информации.
Другие примеры ключевых источников информации:
- Описание внешнего или ранее реализованного API (например, API компании-перевозчика). Разработчик не должен сам искать в интернете какую-то версию, т.к. она может оказаться не последней и не согласована с архитектором.
- HLD (high-level design, описание архитектуры)
- Стандарты заказчика, если речь идет про передачу листинг кода, а также когда есть свои определенные стандарты его оформления
- Ссылка на памятку по чтению постановки. В некоторых случаях формат постановки может быть достаточно объемным и в нем могут использоваться артефакты, которые не всегда будут понятны человеку со стороны (или даже разработчику команды, который может воспринять постановку неправильно). Поэтому ссылка, например, на соглашение о моделировании вполне может быть источником информации.
Раздел 3. Заинтересованные стороны
Заинтересованные стороны (далее ЗС) — это перечень людей, которые будут влиять на принятие решений и от которых зависит успех реализации.
Чем помогает перечень заинтересованных лиц:
Чем помогает перечень заинтересованных лиц:
- Определение принадлежности реализуемых в рамках постановки на реализацию требований к ЗС.
- Позволяет проверить, что все необходимые ЗС выявлены и привлечены.
- Дает понимание о том: кто принимает решения, с кем можно коммуницировать при реализации, кто будет в ходе испытаний принимать решение согласно критериям приемки.
- Можно использовать этот перечень при согласовании и демо.
Роли заинтересованных сторон
Разница между проектными ролями и бизнес-ролями ЗС
Существуют разные роли, в которых выступают заинтересованные стороны по отношению к постановке. Например, бизнес-роли и проектные роли.
Мы можем смотреть на то, кем является заинтересованная сторона в конкретном проекте и кем она является в рамках бизнес-процессов, которые мы автоматизируем.
Например, у нас есть директор по развитию. На проекте он является куратором (улаживает какие-то вопросы и проблемы) — это его проектная роль. В качестве бизнес-роли он никем не выступает (строка №1).
Проектная роль директора по взаимодействию с подрядчиками — это заинтересованная сторона от какой-нибудь службы по взаимодействию с подрядчиками.
Но как у человека этой области бизнеса у него есть компетенции, которые позволяют ему выступать от лица менеджера по работе с клиентами. То есть директор по взаимодействию с подрядчиками может грамотно сформулировать требование от лица менеджера, понимает, как менеджер работает, может ответить на все необходимые вопросы — это бизнес-роль (строка №2).
Маркетолог также может иметь и проектную, и бизнес роль. Т.к. маркетолог смотрит на то, как готовым продуктом будут пользоваться, то можно сказать, что он является клиентом компании и может диктовать требования от имени клиентов компании — это его бизнес-роль (строка №2).
Существуют разные роли, в которых выступают заинтересованные стороны по отношению к постановке. Например, бизнес-роли и проектные роли.
Мы можем смотреть на то, кем является заинтересованная сторона в конкретном проекте и кем она является в рамках бизнес-процессов, которые мы автоматизируем.
Например, у нас есть директор по развитию. На проекте он является куратором (улаживает какие-то вопросы и проблемы) — это его проектная роль. В качестве бизнес-роли он никем не выступает (строка №1).
Проектная роль директора по взаимодействию с подрядчиками — это заинтересованная сторона от какой-нибудь службы по взаимодействию с подрядчиками.
Но как у человека этой области бизнеса у него есть компетенции, которые позволяют ему выступать от лица менеджера по работе с клиентами. То есть директор по взаимодействию с подрядчиками может грамотно сформулировать требование от лица менеджера, понимает, как менеджер работает, может ответить на все необходимые вопросы — это бизнес-роль (строка №2).
Маркетолог также может иметь и проектную, и бизнес роль. Т.к. маркетолог смотрит на то, как готовым продуктом будут пользоваться, то можно сказать, что он является клиентом компании и может диктовать требования от имени клиентов компании — это его бизнес-роль (строка №2).
В контексте постановки в большей степени важна будет проектная роль, потому что она определяет отношение заинтересованной стороны и ее полномочия. Например, куратор имеет максимально широкий спектр полномочий, в том числе в части согласования.
Бизнес-роль важна прежде всего на уровне сбора требований, т.к. отвечает за содержательную их часть. Бывает и так, что требования дособирают на этапе постановки, потому что иногда все то, что было наработано в техническом задании, к моменту реализации уже не совсем актуально, потому что бизнес меняется, и это нормально.
Наличие в постановке реестра заинтересованных сторон позволяет команде разработки на этапе выполнения задачи понимать, с какой из заинтересованных сторон нужно коммуницировать по какой конкретной части решения.
Бизнес-роль важна прежде всего на уровне сбора требований, т.к. отвечает за содержательную их часть. Бывает и так, что требования дособирают на этапе постановки, потому что иногда все то, что было наработано в техническом задании, к моменту реализации уже не совсем актуально, потому что бизнес меняется, и это нормально.
Наличие в постановке реестра заинтересованных сторон позволяет команде разработки на этапе выполнения задачи понимать, с какой из заинтересованных сторон нужно коммуницировать по какой конкретной части решения.
Раздел 4. Критерии приемки результатов. Уровень детализации критериев приемки
Критерии приемки результатов — критерии, выполнение которых может говорить о том, что решение реализовано (definition of done постановки).
В широком смысле критериями приемки могут выступать:
Чем помогают критерии приемки:
Примеры требований, которые могут служить критериями приемки:
В широком смысле критериями приемки могут выступать:
- перечень исходных требований, реализуемых решением,
- сформированный перечень функций решения и результатов их выполнения,
- user story,
- и т.д.
Чем помогают критерии приемки:
- дают понимание границ реализации,
- обеспечивают полноту реализации,
- выступают чек-листом приемки (аналитиком при авторском надзоре и заказчиком)
Примеры требований, которые могут служить критериями приемки:
- Необходимо учитывать время технологических операций по сбору заказа, хранению и транспортировке с производства до терминалов компаний-перевозчиков.
- Информация по срокам доставки конкретных компаний – перевозчиков должна рассчитываться в момент оформления заказа
- Перечень доступных для выбора компаний-перевозчиков должен формироваться с учетом возможности доставки компанией-перевозчиком по указанному адресу доставки
Раздел 5. НФТ и ограничения решения
Нефункциональные требования — требования к видам обеспечения и ограничений реализации. НФТ нужны, чтобы их учитывать при принятии решения в рамках постановки.
Ошибки при их проработке в последствии могут привести к очень серьезным проблемам и полной неработоспособности решения
К наиболее важным требованиям относятся:
Необходимо также учитывать:
Примеры НФТ и ограничений:
В состав поставки могут также входить ключевые требования на систему в целом, если это необходимо.
Ошибки при их проработке в последствии могут привести к очень серьезным проблемам и полной неработоспособности решения
К наиболее важным требованиям относятся:
- производительность (использование в нескольких филиалах) ,
- доступность (24/7),
- масштабируемость (количество сотрудников).
Необходимо также учитывать:
- требования к видам обеспечения - документация и юридические аспекты,
- переходные требования - требования, позволяющие без потерь перейти к новой версии автоматизации.
Примеры НФТ и ограничений:
- Время расчета срока не должно превышать 1 секунду
- Необходимо предусмотреть возможность подключения в дальнейшем неограниченного количества компаний — перевозчиков
- Сервис расчета сроков должен быть доступен 24/7
- Расчет срока возможен только при online-доступности
В состав поставки могут также входить ключевые требования на систему в целом, если это необходимо.
Раздел 6. Описание решения
Описание решения — это основная часть постановки, описывающая способ и границы реализации
Может содержать:
Диаграммы для UseCase ограничены, т.е. фиксируют конкретный набор функциональности, который, в свою очередь, помогает:
Важно понимать, что команда разработчиков должна уметь читать эти диаграммы.
Может содержать:
- Сценарии использования (UseCase)
- Информационные модели
- Статусные модели
- Алгоритмы
- Макеты интерфейсов (UX/UI)
- Компонентные схемы
- Описание интеграций
Диаграммы для UseCase ограничены, т.е. фиксируют конкретный набор функциональности, который, в свою очередь, помогает:
- аналитику ничего не забыть,
- разработчику реализовать данный сценарий,
- заказчику увидеть сценарий его будущего взаимодействия с системой,
- тестировщикам создать тест кейсы.
Важно понимать, что команда разработчиков должна уметь читать эти диаграммы.
Объем документирования
При определении объема документирования важно:
Постановка отвечает на вопрос «что нужно сделать?», а техническая документация — «как это сделано / как это работает?». Стоит заметить, что грамотно сформированная классификация постановок в терминах UML может стать частью документирования. Это может помочь, когда на проекте отсутствует отдельный процесс документирования.
Конкретика
Документацию необходимо писать просто, кратко и точно, применяя лексику, понятную пользователям, во избежание расхождений в интерпретации артефактов и фраз в постановке.
Команда
Переиспользование артефактов
Чтобы была возможность переиспользовать артефакты, необходимо подумать об их:
Счастливая команда – залог успеха
Счастливый менеджер понимает, что:
Счастливые разработчики понимают, что написано в постановке, у них нет необходимости просматривать справочники по нотациям моделирования для понимания артефактов.
Счастливые тестировщики понимают, какие есть пользовательские сценарии использования продукта, внутренних алгоритмов
Счастливые тимлиды понимают, как можно разбить задачу между исполнителями
- Включать только необходимый набор артефактов.
- Разделять постановку и документирование ИТ-решения.
Постановка отвечает на вопрос «что нужно сделать?», а техническая документация — «как это сделано / как это работает?». Стоит заметить, что грамотно сформированная классификация постановок в терминах UML может стать частью документирования. Это может помочь, когда на проекте отсутствует отдельный процесс документирования.
Конкретика
Документацию необходимо писать просто, кратко и точно, применяя лексику, понятную пользователям, во избежание расхождений в интерпретации артефактов и фраз в постановке.
Команда
- Учитывайте формат, особенности и традиции работы команды.
- Учитывайте необходимость брать на себя описание артефактов и документирование, а также наличие компетенций для этого.
Переиспользование артефактов
Чтобы была возможность переиспользовать артефакты, необходимо подумать об их:
- Кодировании
- Классификации
- Хранении и обеспечении быстрого доступа
- Доступности для модификации и совместной работы
- Версионировании (т.к. видоизмененный в новой постановке артефакт, при отсутствии версионирования, не позволит доработать предыдущую версию артефакта по замечаниям от разработчика, например)
Счастливая команда – залог успеха
Счастливый менеджер понимает, что:
- в постановке описаны только те артефакты, которые реально необходимы для конкретной задачи
- артефакты, которые можно переиспользовать, перед используются
- время (деньги) потрачено с умом
Счастливые разработчики понимают, что написано в постановке, у них нет необходимости просматривать справочники по нотациям моделирования для понимания артефактов.
Счастливые тестировщики понимают, какие есть пользовательские сценарии использования продукта, внутренних алгоритмов
Счастливые тимлиды понимают, как можно разбить задачу между исполнителями
Как понять, какие разделы постановки нужны?
Давайте рассмотрим факторы, влияющие на выбор того, какие разделы постановки нужны:
- Квалификация того, кто пишет постановку
- Квалификация того, для кого пишется постановка (команда)
- Квалификация Заказчика (для тех случаев, когда заказчик читает и согласовывает постановку)
- Необходимость формальных процедур согласования (внутри команды или с заказчиком)
- Сложность решаемой задачи
- Специальные требования к оформлению документации
Матрица состава разделов постановки
Матрица состава блоков постановки
Если команда имеет опыт и экспертов в предметной области, то для выполнения простой задачи ей будет достаточно:
Для команды, не имеющей экспертов, помимо основных разделов, будут также необходимы критерии приемки.
А для неопытной команды будут необходимы все разделы.
Баланс в команде может достигается за счет сочетания опытной команды и неопытного аналитика или наоборот, опытного аналитика и неопытной команды.
- контекста задачи,
- ключевых источников,
- заинтересованных сторон,
- НФТ.
Для команды, не имеющей экспертов, помимо основных разделов, будут также необходимы критерии приемки.
А для неопытной команды будут необходимы все разделы.
Баланс в команде может достигается за счет сочетания опытной команды и неопытного аналитика или наоборот, опытного аналитика и неопытной команды.
Внедрение нового формата постановки
При внедрении нового формата необходимо подумать о том, что:
Если аналитик хочет формализовать работу с постановкой, последовательность его действий может быть разная. Предположим, что с постановкой есть проблема, аналитик видит ее в части некачественных решений или скорости принятия/реализации решений. Чтобы улучшить деятельность, аналитик может попытается внедрить постановку в рамках своей команды, т.е. сделать MVP, поработать с этой постановкой внутри команды, а после ее тиражировать.
Стоит заметить, что вопросы по внедрению процессов в компании, инициации этих изменений, могут благоприятно влиять на карьеру аналитика, поэтому их не стоит бояться.
- любые изменения — стресс, большинство будет против
- если это еще не сделано, возможно, кроме вас никто не видит решение
- нужны сторонники, необходимо определить и заручиться поддержкой лидеров мнений
- важно показывать, почему сейчас плохо? как новый формат поможет в будущем?
- необходимо заручиться поддержкой руководства
- сначала лучше договориться с командой и показать руководству что-то уже работающее, а не концепт
- подразумевает риски, т.к. всего не предусмотреть. Будут исключения и задачи, на которые эта постановка не будет ложиться, и это нужно учитывать
Если аналитик хочет формализовать работу с постановкой, последовательность его действий может быть разная. Предположим, что с постановкой есть проблема, аналитик видит ее в части некачественных решений или скорости принятия/реализации решений. Чтобы улучшить деятельность, аналитик может попытается внедрить постановку в рамках своей команды, т.е. сделать MVP, поработать с этой постановкой внутри команды, а после ее тиражировать.
Стоит заметить, что вопросы по внедрению процессов в компании, инициации этих изменений, могут благоприятно влиять на карьеру аналитика, поэтому их не стоит бояться.
Вопросы и ответы
- Вопрос:Как должен выглядеть шаблон постановок и ТЗ?Ответ:Шаблоны ТЗ — ГОСТовский шаблон (в ГОСТ есть перечень разделов, которые могут входить в ТЗ). Приходите на курс, там подробно разбираем шаблон ТЗ.
Шаблон постановки может состоять из 3х основных частей:- заголовочная (общее описание, термины и определения, ссылки),
- раздел для заказчика (критерии приёмки, бизнес-контекст),
- раздел для разработчиков (НФТ, описание постановки).
- Вопрос:В чем разница между постановкой задачи и описанием постановки задачи?Ответ:Постановка задачи — это управленческое решение, назначение кого-то ответственным за выполнение конкретной задачи.
Описание постановки — это приложение к поставленной задаче, конкретное описание, как необходимо выполнить данную задачу. - Вопрос:Какие наиболее удобные средства ПО для ведения/написания постановки?Ответ:Если речь идет непосредственно о самих артефактах, то необходим Sparx Enterprise Architect, в котором можно будет этот артефакт спроектировать и нарисовать.
Это могут быть как простые инструменты без репозитория самих элементов: visio, плагины для Confluence, онлайн-инструменты. Так и более сложные, например Sparx, где есть свой репозиторий, версионирование и возможность совместной работы.
В части оформления документа можно использовать любое ПО, которое имеет возможность экспорта. Например, Confluence или Word. - Вопрос:Как лучше оформлять change request (запросы на изменения)?Ответ:Если инициатором изменений является заказчик, то сперва вносятся изменения в ТЗ и согласовываются с заказчиком, только после этого вносятся изменения в постановки разработчикам.
Если инициатором изменения является сама команда разработки, тогда:- если правки не влияют на требования заказчика, то ТЗ можно оставить без изменений, а вот постановку необходимо поправить,
- если требования затрагивают ТЗ, то необходимо сначала внести изменения в постановку, а после пересогласовать изменения в ТЗ с заказчиком.
- Вопрос:Есть ли шаблоны постановки задач? Отличаются ли эти шаблоны для Backend и Frontend?Ответ:Если говорить про набор артефактов, то, например, для Backend макеты UI не будут полезны, также, как и базы данных для Frontend.
О глобальном различии шаблонов говорить не приходится, т.к. имеет место одна общая постановка, которая логически разбита на компоненты (в данном случае Backend и Frontend), а артефакты будут сгруппированы внутри.
Важно, что наиболее подходящий шаблон, для каждой конкретной задачи, может создать только тот специалист, который который непосредственно работает в команде. Попытка навязать формат постановки под все технологические стеки может привести либо к игнорированию общего формата, либо к более тяжелым последствиям. - Вопрос:Стоит ли ставить на команду ограничения по времени на обработку одного запроса? Например, на анализ не более 24 часовОтвет:Жесткие ограничения — это плохо. Однако, стоит обратить внимание на декомпозицию и не тратить на 1 задачу более недели.
- Вопрос:Jira или Confluence?Ответ:Jira — это таск-менеджмент, управление задачами. С помощью нее можно поставить задачу на конкретного исполнителя и прикрепить уже оформленный вариант постановки.
Confluence — контент-менеджмент, он как раз позволяет писать и грамотно оформлять постановку задачи. - Вопрос:Какой должен быть минимум в постановке опытного системного аналитика? Как аналитик может показать свою высокую компетенцию через постановку?Ответ:Минимум в постановке зависит от сложности конкретной задачи, от отдельно взятой команды.
Показать свою компетенцию аналитик может, закладывая низкие трудозатраты при планировании, обеспечивая при этом высокое качество работы. Т.е. отводя 10 часов на разработку, вы не закладываете еще 20 часов на постановку. Также показателем компетентности будет являться количество замечаний, полученных на доработку постановки. - Вопрос:Михаил, что за клуб мышления резидентом которого ты являешься?Ответ:Клуб мышления — это федеральная сеть, сообщество неравнодушных людей, которые обмениваются идеями и мыслями. В этом клубе есть шанс встретить людей с очень разными взглядами. Меня привлекает, что самые, казалось бы, неожиданные, но имеющие основания мнения могут быть выслушаны.
Попасть туда можно, написав лидеру этого клуба. Каких-то особых требований на вступление в клуб не предъявляется. - Вопрос:Насколько важно вести документацию? Какие виды документации вы создавали ранее?Ответ:Описание артефактов может быть в виде описанных алгоритмов, макетов UI, сценарии использования, информационные модели расписанные на разных уровнях (интеллектуальном, логическом, физическом).
В рамках одного проекта необходимо принять общее соглашение о моделировании. С одной стороны это ограничивает свободу в выборе, например, каких-то элементов на UML диаграмме, но с другой стороны, это дает возможность понимать схемы коллег и концентрироваться на сути, не тратя время на понимание формы. - Вопрос:Как документировать, чтобы все изменения были видны?Ответ:Вы можете использовать постановку в сравнении версий, т.е. в предыдущей версии постановки выделяете все вносимые изменения.
В Confluence есть штатная опция — сравнение версий, где можно создать новую версию и передать разработчику уже сравнение версий. - Вопрос:Постановка задач не равна user story?Ответ:User story — это формат сбора требований, а постановка — это описание решений, а не формат требований. User story может выступать в качестве описания бизнес-контекста. Также критерии приемки могут быть описаны в этом формате.
- Вопрос:Как использовать Epic в Jira?Ответ:Если есть декомпозиция продуктов проекта, когда есть отдельная спецификация требований, то атомарные функции, которые мы выделили – это эпики (epic). Это функция, которую можно зарелизить, показать заказчику. И живет эта функция не в течении всего проекта, а только в рамках текущей реализации. То есть доработка в следующем релизе будет иметь новый эпик. Не стоит делать эпик сквозным, не надо тянуть его через весь проект
- Вопрос:Как тогда отслеживать в Jira все изменения в одном разделе на протяжении жизни системы?Ответ:Документация на систему живет вне задач и проектных требований, т.е. это постоянно существующий артефакт, который постоянно дорабатывается в рамках проектных активностей.
Если включать в постановку элементы документирования (то есть спецификацию), то получается, что мы берем это из общей базы знаний, которая на самом деле не должна зависеть от проектов.
Другими словами, у нас нет необходимости отслеживать изменения через задачи в Jira, потому что у нас есть перманентно существующая документация и версионирование на систему или на модуль системы. По идее это дает нам возможность откатиться к предыдущей версии.
Всегда имеет место декомпозиция продуктов и работ, которая синхронизирована с Jira или Confluence (там, где лежат постановки). Если различные функции представлены в виде компонентов, эпиков и задач в Jira, то, скорее всего, есть какая-то похожая структура в базе знаний, в пространстве в Confluence, в виде папок на Google-диске. И все эти изменения мапятся.
Error get alias