Возможно, прочитав эту статью, вы поймаете себя на мысли, что я пишу о банальных вещах, которые всем известны. Но за 10 лет я сменила всего лишь 3 IT-компании, в двух из которых эти «банальные» практики не использовались в полной мере, от этого процесс разработки ПО сильно страдал. Помимо моего личного опыта, на написание статьи меня подвигли рассказы знакомых аналитиков, которые работают в сфере IT и практически все сталкиваются с проблемами организационного и коммуникационного характера, которые нужно и можно решать.

Последние 3 года я работаю системным аналитиком в группе компаний InfoWatch и в этой статье я хочу поделиться с вами практиками работы с требованиями, которые мы используем. Компания занимается разработкой Enterprise-продуктов для снижения рисков информационной безопасности, защиты и анализа корпоративных данных. К таким продуктам выдвигаются высокие требования, касающиеся их надёжности, производительности, отказоустойчивости, а так же требования для сертификации. В силу особенностей рынка информационной безопасности наши решения не являются облачными, а устанавливаются on-site у клиента. Поэтому мы работаем в режиме выпуска больших релизов несколько раз в год. Чтобы прийти к назначенной цели и сократить сроки релиза, мы работаем по принципам, заложенным в методологии Agile. Для старта разработки мы не готовим абсолютно детальные системные требования, а начинаем с высокоуровневого описания самых важных аспектов новой функциональности. То есть, принимаем решения, которые больше всего влияют на объем и сложность доработок и дают команде разработки необходимую информацию для старта работ по проектированию архитектуры и написанию кода (для небольших фич). Затем, по ходу разработки, постепенно детализируем требования и доводим их до уровня детализации, достаточного для написания подробных тест-кейсов. Такой подход позволяет не тратить много времени на старт работ и снизить риски того, что требования придется значительно перерабатывать, если выявятся какие-то новые технические ограничения.

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

Требования к разрабатываемому продукту — основная зона ответственности системного аналитика. Практики, описанные ниже, направлены на упрощение работы с требованиями и, как следствие, на упрощение процесса разработки продукта:

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

Документирование и версионирование требований

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

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

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

Мы используем Confluence — это удобный инструмент, который можно немного «подкрутить» под себя. О нашем опыте использования Confluence подробно рассказывает мой коллега в своей статье «Как мы используем Confluence для разработки требований к продукту». Интересно то, что у многих IT-компаний этот инструмент есть, но не все используют его для документирования требований к продукту.

Оповещение об изменениях в требованиях

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

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

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

• реализация может не соответствовать требованиям;
• ожидаемый результат тестирования может не соответствовать требованиям и реализации;
• документация может не соответствовать реализации.

До недавнего времени наша команда аналитиков оповещала всех заинтересованных об изменениях в требованиях следующим образом: после внесения изменений в требования, оставляли комментарий к задаче, отправляли письмо, которое содержит ссылку на задачу, ссылку на требования и краткое описание изменений. В конце прошлого года мы автоматизировали этот процесс: доработали issue-tracker (используем JIRA) и теперь после внесения изменений в требованиях мы в задаче, в рамках которой эти изменения были внесены, нажимаем кнопку «Оповестить об изменениях», выбираем заинтересованные команды и делаем краткое описание изменений:

Скриншот №1


Письмо, которое автоматически генерируется после нажатия на кнопку «Отправить оповещение», имеет следующее представление и содержит всю необходимую информацию:

Скриншот №2


Помимо письма в задаче остается комментарий с аналогичной информацией.

Ревью новых требований

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

Для этого мы так же доработали issue-tracker, добавили отдельный тип задачи «Ревью», которая запускается ответственным аналитиком по каждой фиче на всех руководителей команд. Руководители самостоятельно или, делегируя своим подчиненным, делают вычитку требований, задают вопросы или вносят уточнения через комментарии и согласовывают внесенные изменения.

Скриншот №3

Митинги/собрания/статусы

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

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

Обсуждение/решение открытых вопросов

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

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

Поэтому я предпочитаю решать вопросы в дискуссии «голосом», то есть созвониться и обсудить, о чем-то договориться. Звонок поможет выяснить, правильно ли вы поняли контекст, сразу задать вопросы и получить ответы. Голос передает интонацию, позволяет расставить правильные акценты, обратить внимание на то, что действительно важно. Плюс, общение голосом экономит время всех участников и позволяет сконцентрироваться на конкретной теме, так как общение голосом (а не в чате), требует проявить участие и понимание для решения вопроса.

Протоколирование обсуждений

Для всех абсолютно привычно и обязательно фиксировать обсуждения решений с заказчиком, в виде ТЗ, которое неоднократно вычитывается «до запятой» и согласовывается всеми заинтересованными сторонами. Я хочу обратить внимание на то, что помимо официальной документации в разработке ПО, письменная фиксация договоренностей может быть полезна не только в рамках общения «заказчик – разработчик», но и внутри компании/команды.

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

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

Валидация нового функционала

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

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

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

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

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

Если у вас есть вопросы или вы хотите поделиться своим опытом, пожалуйста, оставляйте свои комментарии.

Автор: Венера Аббясова AbbyasovaVenera

* Все картинки для статьи взяты из открытого доступа в сети Интернет.