Must have артефакты для разработки ПО

Привет! Меня зовут Сергей Алексеев, в IТ я уже 9-й год и в последнее время зачастил на DOU со своими статьями. Это обусловлено тем, что я хочу передать сообществу свои знания. В этот раз я решил написать статью, в которой будет много примеров артефактов, без которых либо невозможно сделать программное обеспечение, либо из-за их отсутствия увеличивается срок разработки ПО. Или еще хуже — будет реализовано совершенно не того, что было задумано изначально.

Я хочу, чтобы статья помогла разным командам увеличить свою производительность и профессионализм. Надеюсь, что этот материал прочтут сотрудники, которые отвечают за IТ в госслужбах и других непрофильных компаниях. Возможно, люди начнут внедрять у себя лучшие практики, что позволит компаниям стать более эффективными. Я не хочу обидеть никого, но для всех нас не секрет, что профессиональный уровень специалистов в этих структурах на порядок ниже, чем в лидирующих IТ-компаниях страны, но всегда есть исключения. Такими компаниями я бы назвал МХП, НП, «Розетка», ДТЭК. Возможно, их больше. Напишите в комментариях об этих организациях.

В последние годы я побывал в разных компаниях, работал с командами разной структуры, количества сотрудников и опыта, был вовлечен во множество бизнес-доменов. Благодаря накопленным знаниям я смог составить перечень минимального набора необходимых артефактов, без которых команды разработки не работают эффективно, особенно на fixed price проектах. Эффективность работы команды для меня подтверждают следующие показатели: скорость разработки, количество созданных багов, технического долга, изменений и переделок за свой счет. На все эти показатели очень влияет сплоченность команды. Только что сформированная команда сеньоров будет менее продуктивна, чем работающая уже год команда мидлов, но, конечно же, это только поначалу. Дальше сеньоры победят в этой схватке метрик.

На картинке ниже я специально выделил область в процессе «бэклог менеджмент», в которой происходит декомпозиция требований и создание большинства артефактов. Лично я использую rolling waves подход во всех проектах, чтобы сбор и описание требований прошли более спокойно.

Процесс декомпозиции feature

Чем же является feature (далее фича) в мире ПО? Фича — это часть функциональности в программном обеспечении, которую необходимо реализовать в определенном объеме и последовательности. Например, «Find friends» в Facebook, «Stories» в Instagram, «New incognito tab» в Chrome.

Вот так вот выглядит процесс декомпозиции feature на практике:

Важно: список задач не отсортирован по приоритетности выполнения во время процесса. Список фич появляется только после того, как были выявлены основные сценарии, которые необходимо автоматизировать, изменить, оптимизировать.

ЭтапЗадачаКомментарий
АнализПолучить видение, объем и границы фичи

Оформляйте это в виде простых требований типа:

  • Пользователь должен иметь возможность делать «Х».
  • Система должна предоставлять возможность делать «У».
  • Необходима реализация интеграции с системами «A» и «B».
В идеале это должно было быть сделано на этапе «Discovery», где аналитик готовит документ под названием «Vision & Scope», в котором есть список фич. Если у фичи есть определенная логика расчетов, обязательно напишите о ней. Пытайтесь писать по максимуму все, что знаете, но не расписывайте это очень детально на данном этапе.
АнализОпределить и описать роли

Понимание ролей необходимо как минимум для того, чтобы построить модель доступа к интерфейсам и данным ПО. Роли также понадобятся в момент описания use cases.

Я выделяю два типа ролей (бизнес и системные):

  • Бизнес-роль — это должности в организационной структуре компании. Для бизнес-роли будет описан перечень бизнес-операций без привязки к какому либо ПО.
  • Системная роль — роль, которая будет использоваться в приложении, для описания доступного функционала в ПО.

Пример колл-центра: есть 2 бизнес-роли (супервайзер и оператор), у каждой из этих ролей есть свои обязанности и метрики, за которые они несут ответственность.

В программном обеспечении вы можете создать 2 системные роли и каждому из пользователей будет назначена своя роль. Тем самым вы делаете границу между UI & Data по ролям. Но в случае, когда оператору нужно расширить возможности в ПО, ему могут назначить дополнительную роль «Супервайзер» для расширения полномочий в самом ПО, а не в реальном мире (один из возможных вариантов реализации).

АнализПонять основные кейсы использования фичиЛюбая фича реализовывается для того, чтобы поддерживать минимум один сценарий взаимодействия пользователя/системы с ПО и приносить пользу. Вам необходимо выявить как можно раньше и больше сценариев, которые имеют отношение к определенной фиче. Это даст возможность понять объем работ, рамки реализации и спланировать разработку. Тут вам помогут «use case» диаграммы.

Пример колл-центра: основные сценарии для оператора — принять звонок, зафиксировать обращение, осуществить звонок и так далее.
АнализПонять основные сущности фичи

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

Пример колл-центра: клиент, который звонит в колл-центр; пользователь, который принимает звонок; звонок, заявка и так далее. Эту задачу помогут решить ERM диаграммы.

ДизайнОпределить основной сценарий

На этапе дизайна я всегда рекомендую показывать «happy path», чтобы команда и клиенты понимали сценарий, как это будет выглядеть от начала и до конца (end2end).

Пример колл-центра: успешное формирование заявки по входящему звонку — интерфейс карточки звонка, интерфейс карточки клиента, интерфейс заявки.

ДизайнСоздать дизайнНеобходимо показать выбранный сценарий или несколько на самих мокапах. Желательно делать интерактивный мокап.
ДизайнСоздать артефактыПока создаются дизайны и выясняются требования, вы создаете артефакты (перечислены ниже по тексту) для всех участников процесса разработки ПО.
УтвердитьПрезентовать клиенту/сотрудникамДля того, чтобы утвердить требования и сделать решение окончательным на этой итерации, вам необходимо его презентовать клиенту или же коллегам, если это продуктовая компания.
УтвердитьЗакрыть открытые вопросыСобрать всю необходимую информацию для закрытия/решения вопросов после проведенной одной или или нескольких встреч. Утверждение требований как отдельный процесс стоит рассмотреть подробнее позже.
УтвердитьПодтвердить дизайн и требованияПосле презентации у вас либо будет утверждено решение, либо будут открытые вопросы, которые необходимо закрыть.

В основе декомпозиции любой фичи лежит принцип итеративности. Он позволяет вам с каждым разом понимать клиента все больше и четче. Так что не бойтесь практиковаться и делать ошибки.

Практика

Я решил взять за основу общий сценарий, чтобы было более понятно. Если у вас будут конкретные вопросы по вашим кейсам, пишите их в комментариях или мне лично.

Epic: Account management

Features: log in / log out / password recovery

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

В это перечень входят:

  • Meeting Notes;
  • Use cases;
  • Flows;
  • ERM;
  • State Machine;
  • Design;
  • User Stories;
  • Mock Data.

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

Meeting Notes

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

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

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

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

Use Cases

Зачем. Использование use cases позволяет осознать и показать максимальную картину того, что будет входить в разрабатываемую фичу или целый продукт. Используя эту технику, вы легко можете отображать и прослеживать зависимости взаимодействия между пользователем и системой. Хорошо видны границы функциональности или продукта. Use case диаграмма также очень удобна при декомпозиции требований. Почитать детально.

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

Когда. Поскольку информация по кейсам меняется достаточно редко, я ее рисую в самом начале разбора продукта/фичи. Это не занимает много времени — 2-3 часа от силы.

Личное мнение. Использование use cases очень помогает в структурировании информации. Я практически всегда использую этот тип диаграмм в проектах, где много ролей и сценариев.

Process flow diagram

Зачем. Чтобы упростить согласование бизнес-логики между всеми участниками процесса разработки ПО. В своей практике я использую «Activity Diagrams» или «Cross functional flow charts» для решения 99% задач. Мне не нужны сложные и комплексные нотации типа BPMN / IDF0 и прочие. Бесспорно, некоторые клиенты, особенно на постсоветском пространстве, любят эти нотации, но в большинстве случаев мне не приходилось их задействовать и работа шла успешно. Почитать детально.

Как. Прежде всего, вам необходимо понять, как работают процессы в данный момент, если это уже существующий бизнес. Если же это что-то новое, тогда вам необходимо подумать, как будет выглядеть тот или иной процесс. Используя паттерн AS IS / TO BE, я всегда делаю зарисовки процессов AS IS на бумаге в виде схем / слов / кракозябликов, а вот процессы TO BE я уже отрисовываю в программном комплексе, используя определенную нотацию и тип диаграммы.

Когда. Итеративно, по мере поступления новой информации. Процессы могут зависеть друг от друга.

Личное мнение. Ваша задача — не рисовать красивые диаграммы по всем канонам определенной нотации, а делать классный работающий продукт быстро, в сроки и качественно. Пытайтесь декомпозировать процессы на более мелкие. Это позволит улучшить читабельность диаграмм.

Entity Relationship Model

Зачем. ERM позволяет показать взаимоотношения бизнес-сущностей между собой. Если вы сможете это сделать в самом начале разработки своего продукта, тогда это упросит техническим специалистам понимание того, как правильно строить архитектуру самого приложения и базы данных. Используя такие диаграммы в процессе разработки ПО, вы снижаете риск того, что нужно будет переделать приложение.

P. S. Даже если разработчики говорят: «Мы используем NoSQL базы данных и мы можем меняться на ходу», — не верьте им :) Этот трюк работает только вначале, пока продукт молодой и зеленый, и нет ни нагрузок, ни сложной бизнес-логики... Так что пускай не ленятся и задумываются над архитектурой.

Как. Чтобы понять, как использовать эти диаграммы, я рекомендую почитать о реляционных базах данных. На каких принципах они построены, какие связи есть и зачем все это необходимо.

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

Личное мнение. Я использую этот подход при разработке новой фичи или модуля, все зависит от знаний домена и сложности связей. Если простые связи и мало сущностей, тогда можно обойтись без ERM. В противном случае я рекомендую рисовать и доносить разработчикам. Она необходима в начале проекта, пока все участники процесса не будут знать сущности и взаимосвязи между ними.

State Machine

Зачем. Чтобы понять, какие существуют состояния/статусы и какие триггеры на это влияют. У каждой сущности есть свой life cycle. У некоторых из них он достаточно короткий и состоит из 2-3 статусов. Но также бывают и сложные сущности, где уйма разных состояний и факторов, которые влияют на их изменение. Хороший пример сущности со сложной структурой — это заявка в службу поддержки, где есть несколько уровней служб, и заявке иногда приходится пройти 3-4 уровня, с рассмотрением и переадресацией этой заявки в другие службы. О том, как определять статусы и состояния сущностей, вы можете посмотреть в моем видео. Такого типа диаграммы помогают backend разработчикам в реализации бизнес-логики.

Как. Я использую диаграмму «state machine» в нотации UML. Вам необходимо понять, в какой момент сущность создается, какие сущности влияют на состояние текущей сущности. Это все вам поможет более детально продумать ваше приложение.

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

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

Design

Зачем. Если вы делаете программное обеспечение, которое предназначено для использования человеком посредством визуальных интерфейсов, тогда вам не обойтись без дизайна вашего ПО. Дополнительное объяснение, зачем необходим дизайн на проекте, считаю лишним.

Как. Развернутый ответ о том, как может быть построена коммуникация с дизайнером, вы можете посмотреть в этом видео.

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

Личное мнение. Все дизайны должны отображать основные сценарии работы с приложением. Должны быть отображены реальные примеры данных, имен, фотографий и так далее. Всегда делайте интерактивные прототипы. Это сократит вам время на согласование требований и даст команде понимание того, как это все должно работать, с первого раза.

User Story

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

Очень важный момент: user story не является todo-листом. Не пишите туда, что должен сделать разработчик (создать сервис, получить что-то при помощи webhook, залить данные и так далее).

Как. Работая бизнес-аналитиком, основную часть времени я тратил на описание user stories. Я не только описывал поведение, но и делал перегруппировку требований, прослеживал зависимости и выставлял приоритеты. Это то, чем должен заниматься аналитик на проектах в текущих реалиях бизнеса.

Итеративная работа над user stories — это must have навык аналитика! Обсудили требования с клиентом => написали user story => обсудили с командой => внесли изменения => обсудили с клиентом => изменили юзер стори => обсудили с командой => внесли изменения. И так до тех пор, пока клиент не будет доволен требованиями, а команда не сможет дать оценку этой пользовательской истории.

Когда. После встреч с клиентом/командой.

Личное мнение. Пользовательские истории должны быть независимыми, тестируемым и должны нести ценность клиенту.

Mock Data (тестовые данные)

Зачем. Это тщательно подготовленные данные, которые должны использоваться разработчиками во время проектирования/разработки системы. QA специалисты должны использовать их как эталонные данные при тестировании.

Как. Я предоставляю данные команде в Excel-файле. Если в разработку user story входит использование нескольких зависимых сущностей (например, товар, склад, производитель и т. д), тогда я в файле добавляю несколько вкладок, на которых находится информация по каждой из сущностей. В таких задачах очень помогает функция (ВПР или VLOOKUP) — рекомендую почитать кейсы ее использования.

Когда. Данные по определенной user story должны быть предоставлены команде до начала разработки этой user story. Иначе есть риск задержать разработку и тестирование.

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

Личное мнение. Я считаю, что данные должен готовить бизнес-аналитик, а не разработчик или тестировщик. Если аналитик не может предоставить данные команде, значит он не до конца понимает ту задачу, которую необходимо сделать. Это ведет к тому, что команда может сделать не то, что хотел конечный заказчик по вине аналитика.

Выводы

Некоторые из вас сразу скажут, что подход к работе на ваших проектах совершенно другой: заказчик хочет видеть что-то другое или привык к ТЗ (техническому заданию) на 100 500 страниц в формате *.docx. Мой ответ прост: если вы хотите меняться и расти, вам придется найти способы изменить подходы к работе с клиентами и дать им четкое понимание плюсов и минусов разных подходов. Вам придется выстроить прозрачные и доверительные отношения, если вы хотите расти вместе со своим клиентом. Вам нужно помнить, что это вы специалисты по разработке ПО, а не ваш клиент! Вы должны его учить и помогать ему, а не он вам! Вы всему голова в данном контексте, а клиент всего лишь должен быть счастливым потребителем ваших сервисов!

Если вы считаете, что я что-то упустили или неправильно описал, буду благодарен за комментарии. Также вы можете поделиться своим опытом или задать вопросы другим специалистам в профильном чате.

LinkedIn

27 комментариев

Подписаться на комментарииОтписаться от комментариев Комментарии могут оставлять только пользователи с подтвержденными аккаунтами.

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

Отличная статья, спасибо!
Особенно порадовал пример с АС и ссылки на диаграммы.

Отличная статья!
Из того что бы изменил:
— убрал бы про примеры хороших и плохих компаний и отраслей.

Из того что сильно оказалось полезным:
— Ссылки на примеры что почитать (UML)
— Пример user story и acceptance criteria
— Ссылка на видео про взаимодействие с дизайнером.

Сохранил в избранное.

— Ссылки на примеры что почитать (UML)

И вообще лучше про RUP еще почитать. UML — это всего-лишь графический язык рисования разных взаимосявязей от уровня бизнеса до программинга.
По мне так каждый менеджер должен знать плюсы и минусы водопада, RUP и остального гибкого современного. Более того есть проекты для которых водопад будет много эффективнее гибких, а есть в которых наоборот.

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

Спасибо большое за статью! Сюда бы еще немного о тулзах которые помогают решать эффективно данные задачи и цены не было бы. Отличный и вместительный обзор.
Для маленькой команды я использую :
— Jira cloud + Confluence (проtкт / ставить задачи) . ~20$p.m
— lucid charts 5$ p.m
— figma (UI prototyping) , almost free
— aws codestar ( ci/cd ) $1 p.m
— trello ( save something quickly)

отличная статья, спасибо !

делать классный работающий продукт быстро, в сроки и качественно.

Тут, очевидно, описка — або швидко, або в строки.

Спасибо интересно было. Мое мнение что перебор с количеством диаграмм. Если есть Активити, делать диаграму состояний это чересчур. очень время затратное дело

Спасибо.
Эти диаграммы решают разные задачи.

Сергей, очень полезная статья. Спасибо. В моей работе есть только элементы БА, но развиваться хочу, и ваша статья помогла увидеть картину с другой стороны.
Одно замечание: начало немного затянуто, и выделяя конкретные компании, которые, по Вашему мнению, молодцы, вы смещаете фокус статьи на размышления, а почему эти молодцы, а другие нет. Потом чтобы влиться в полезную площадь статьи, надо время, чтобы переключиться. Может, конечно, это только у меня так, как не у профи-аналитика :)

Спасибо за комментарий.
Я не Лёв Толстой или Пушкин, хотелось как-то разбавить краски, по этому и написал :)
Рад, что статья помогает

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

Спасибо за комментарий Максим.
Не совсем понял фразу про единорогов и бабочек. Немогли бы более детально объяснить?

Мне понравилась статья, нет, правда. В ней описано все так, как оно должно быть. Но, к сожалению, лицо мое мокро от слез из-за несовпадения этого всего прекрасного с суровой реальностью, данной мне в субъективных ощущениях.

Максим, печально это слышать! Потому что пару моих знакомых БА работают в Ciklum и там целый департамент, который занимается развитием БА в компании. Хоть и head уже перешел в другую компанию...
Думаю этот комментарий, будет для них сигналом, что им что-то нужно менять или как минимум подтянуть хвосты на вашем проекте!

Желаю вам успехов :)

Спасибо )
Дело не в проектах (я уже прислушиваюсь, не шаги ли это внутренней полиции), их я за свою долгую дорогу в дюнах насмотрелся этих проектов немало, дело в том, что в жизни все не так, как на самом деле. Иногда все есть — БА, UML, смоук тесты и энвайрменты, спринты, груминги и все-все-все, но проект умирает не дожив до коммерческого использования. А иногда в чик-чик-продакшен уходит такое, что при одном воспоминании хочется выпить пузырек валерьянки.

Еще раз спасибо за статью. Сохранил в избранном в качестве швейцарского ножа.

Много взял для себя полезного на самом деле, даже в описании Story, нужно будет свои корректировать

Спасибо, рад слышать, что статья стала полезной.

Спасибо за статью. Отлично всё описано )

P. S. Даже если разработчики говорят: «Мы используем NoSQL базы данных и мы можем меняться на ходу», — не верьте им :) Этот трюк работает только вначале, пока продукт молодой и зеленый, и нет ни нагрузок, ни сложной бизнес-логики... Так что пускай не ленятся и задумываются над архитектурой.

Жестоко и жирно плюсую!!!!

Подписаться на комментарии