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

Содержание

• Определение границ итерации

• Изменения — это нормально

  • Изменения пользовательских и функциональных требований

  • Изменения нефункциональных требований

• Измеримость бизнес-целей

• Не разработкой единой

• Заключение

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

На этой стадии происходит:

• создание базы знаний и архива документации;

• анализ извлечённых уроков;

• оценка результатов проекта;

• принятие решений о закрытии проекта или переходе к следующим этапам.

Как определить момент завершения проекта, этапа проекта или итерации разработки?

Определение границ итерации

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

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

• помечают как выполненные истории, реализованные в прошлой итерации,

• при необходимости добавляют новые,

• удаляют истории, реализация которых больше не требуется,

• проставляют приоритет реализации,

• детализируют описание историй с высоким приоритетом.

Истории с высоким приоритетом передаются команде разработки для оценки трудоёмкости реализации и назначения исполнителей.

В ходе итерации команда не только добавляет новые функции, но и устраняет обнаруженные ранее ошибки, а также закрывает технический долг. Количество историй, которое может быть реализовано, зависит от длины итерации (обычно  2–4 недели) и трудоёмкости каждой истории.

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

Можно сказать, что каждая итерация — это мини-проект, который также проходит через стадии:

• инициации — актуализация бэклога;

• планирования — оценка историй и назначение исполнителей;

• реализации — написание кода;

• контроля — тестирование;

• завершения — демонстрация результатов итерации.

Но есть нюанс. Одна история, реализованная в отрыве от бизнес-процесса (Epic), не представляет ценности ни для конечного пользователя, ни для бизнес-заказчика. Кроме того, на стадии контроля мы выяснили, что  невозможно провести полноценное тестирование функционала, не оценив его влияние на связанные требования.

Если мы возьмём в итерацию по одной истории из нескольких Epic’ов и реализуем их абсолютно верно и точно в срок, результаты итерации будут идеальны с точки зрения следования методологии и абсолютно бесполезны для бизнес-заказчика. 

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

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

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

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

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

Изменения — это нормально

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

Изменения пользовательских и функциональных требований

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

Пример необоснованного расширения требований

Представим, что в процессе демонстрации результатов первой итерации…

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

Однако не стоит торопиться с расширением требований и включать новые истории в следующую итерацию. Во-первых, это расширение не поможет проверить верность нашей гипотезы. Во-вторых, помимо доработки кодовой базы (что займёт не так много времени), потребуется разработать и согласовать новые шаблоны договоров для работы нескольких лиц с кредитными счетами. Это уже значительно более длительный процесс. Ещё стоит подумать, может ли пользователь давать доступ к кредитным средствам другим людям, без возможности установки лимита на траты. И кто будет нести ответственность за погашение кредита?

Как оценить необходимость изменения требований?

• Если без вновь выявленных требований проверка гипотез и достижение бизнес-целей невозможны, их следует включить в работу в рамках установленного лимита на изменения. Если лимит исчерпан, а проверка гипотез всё ещё невозможна, необходимо изменить границы проекта (увеличить сроки, бюджет или пожертвовать качеством продукта). Или закрыть проект, признав его неудачным.

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

Изменения нефункциональных требований

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

Пример обоснованного сокращения требований 

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

1. Поиск пользователя.

2. Отправка приглашенияе пользователю.

3. Просмотр статусов приглашений владельцем счёта.

Поиск пользователя производится по номеру телефона. А в списке приглашений отражается номер телефона и PAM-фраза, включающая в себя имя и первую букву фамилии пользователя. 

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

Представим, что в процессе детализации требований выяснилось: хотя сочетание номера телефона и PAM-фразы не позволяет однозначно идентифицировать пользователя, эти данные всё же относятся к персональным. К персональным данным предъявляются особые требования по хранению и обработке.

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

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

У нас есть три варианта решения  проблемы.

1. Изменить архитектурное решение, усилив меры защиты сервиса «Общий счёт». Для этого потребуется привлечение DevOps-специалистов, экспертов по информационной безопасности, а также ряд организационных мер по ограничению доступа к инфраструктуре и кодовой базе. Естественно, это займёт время.

2. Доработать подсистему «Ядро», добавив возможность хранения информации о приглашениях, отправленных пользователям общих счетов, и их последующую передачу по запросу в клиентское приложение. Поскольку «Ядро» уже надежно защищено, не нужно тратить время на выполнение требований регулятора. В то же время, «Ядро» — это самая загруженная часть экосистемы банка, которая участвует почти во всех бизнес-процессах. То есть в её бэклоге больше всего задач в очереди на реализацию. И её доработка несёт самые большие риски. Поэтому доработка и тестирование занимают значительно больше времени, чем доработка узкоспециализированных сервисов. И если гипотезы, на основе которых началась разработка «Общего счёта», окажутся неверными, это время будет потрачено впустую.

3. Отказаться от функционала просмотра информации об отправленных приглашениях в клиентском приложении владельца счёта. 

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

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

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

Могли ли мы избежать этих изменений, проведя более точный анализ при составлении карты пользовательских историй? 

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

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

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

Пример обоснованного расширения требований

При описании варианта использования «Списание с общего счёта»…

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

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

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

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

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

Могли ли мы избежать этих изменений, проведя более точный анализ при составлении API-контрактов? 

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

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

Таким образом, если в процессе тестирования была выявлена необходимость доработки дополнительных проверок API-контрактов, это говорит о том, что тестировщик отлично справился со своей задачей. А расширение требований в данном случае — это ещё одна плата за гибкость в процессах.

Пример необоснованного изменения нефункциональных требований

Представим, что после реализации требований всех Epic’ов первого этапа…

проекта функционал «Общего счёта» был передан на финальное тестирование. Оно прошло успешно: на ста одновременно работающих пользователях не было найдено ни одной ошибки. Однако при одновременной работе 101 пользователя начали проявляться проблемы с быстродействием. А когда количество пользователей достигло 1 000, серверная часть системы «падала», как будто подверглась DDoS-атаке.

Команда разработки «Общего счёта» сообщила, что так и было задумано. В лучших традициях гибких методологий они создали MVP (Minimum Viable Product, «минимально жизнеспособный продукт»), который позволяет продемонстрировать принципы работы с «Общим счётом» конечным пользователям. Если продукт получит положительный отклик, команда займётся оптимизацией системы. По их оценкам, для обеспечения корректной работы системы со 100 000 одновременно работающих пользователей потребуется изменить тип API, оптимизировать способ хранения данных и добавить серверных мощностей. Они предполагают, что оптимизация займёт в два раза больше времени, чем разработка MVP, но это лишь предварительная оценка — сроки могут увеличиться, если изменение типа API не даст ожидаемых результатов.

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

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

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

Чтобы минимизировать вероятность возникновения такого недопонимания между стейкхолдерами, по итогам стадии инициации команде разработке были переданы:

• верхнеуровневое архитектурное решение, включающее в себя рекомендованный стек технологий;

• измеримые  показатели эффективности, на основании которых можно определить минимальное и максимальное количество одновременно работающих пользователей.

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

Измеримость бизнес-целей

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

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

Для оценки успешности проекта используются различные типы показателей эффективности (KPI). Вот основные из них:

1. Финансовые показатели. Отражают экономическую эффективность проекта.

Примеры: рентабельность инвестиций (ROI), срок окупаемости проекта, сокращение операционных затрат.

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

Примеры: полнота реализации требований, отсутствие критических ошибок в работе системы, время бесперебойной работы, удовлетворённость пользователей (например, по шкале NPS), соответствие стандартам и нормам безопасности.

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

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

Не стоит путать бизнес-цели с идеологическими установками или маркетинговыми лозунгами.

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

Стал мир лучше или хуже — это субъективное ощущение отдельного человека. Непонятно, в сравнении с чем нужно производить оценку уровня инновационности банка. То, что похожего функционала нет у конкурентов, ещё не значит, что он нужен пользователям.

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

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

• заказчики не могут определить бюджет, график поставки продукта;

• пользователи рискуют получить решение, которое не отвечает их реальным потребностям.

Не разработкой единой

Вспомним, какие цели проекта «Общий счёт» были определены на этапе инициации проекта.

Обратите внимание, создание функционала «Общего счёта» — это задача, а не цель проекта. Бизнес-цель должна предоставлять реальную ощутимую пользу бизнес-заказчику или пользователю продукта. Им по большому счёту всё равно, каким именно способом обеспечивается сохранность конфиденциальных данных и средств на счетах. Это может быть сервис «Общий счёт», антифрод-система (от англ. anti-fraud — «борьба с мошенничеством») или использование криптографии для подтверждения прав владельца средств. Пользователю неважно, как была спроектирована архитектура, сколько интеграций при этом было описано или какие технологии использовались. Важно лишь, может ли он эффективно решать свои задачи с помощью приложения или нет.

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

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

2. Произвести выкладку и первоначальную настройку нового функционала. Функционал должен быть корректно развёрнут в production-среде, протестирован на предмет работоспособности и интегрирован с существующими системами.

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

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

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

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

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

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

Бытует мнение, о том, что если пользователю нужно читать руководство, значит, качество интерфейса оставляет желать лучшего и UI/UX-дизайнеры плохо справились со своей работой.

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

Но есть нюанс. Чтобы чат-бот мог отвечать на вопросы пользователей, его необходимо обучить — создать базу знаний с ответами на часто задаваемые вопросы . Аналогично, сотрудники службы поддержки должны быть обучены принципам работы системы, чтобы оперативно помогать клиентам.

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

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

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

Заключение

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

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

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

Риски, связанные с неверно выявленными требованиями, обычно всплывают на завершающих этапах проекта, когда бюджет уже исчерпан, а сроки давно сорваны. Именно на этапе завершения приходит осознание, что даже плохо написанные требования — это лучше, чем их полное отсутствие. Гораздо быстрее и дешевле прочитать и уточнить требования, какими бы объёмными они ни были, до начала реализации, чем создавать ненужную систему, а затем переделывать её с нуля.

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

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

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