Практика формирования требований в ИТ проектах от А до Я. Часть 7. Передача требований в производство. Заключение

XI Специфицируем требования

Требование — всего лишь временный посредник для решения проблемы реального мира.
«Фабрики разработки программ» [8]

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

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

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

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



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

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

XII Воплощаем требования в целевой продукт

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

1. Передаем требования в процесс реализации их в целевом продукте

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

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

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

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

1. Передавать требования на разработку можно только конкретному сотруднику, который имеет соответствующие полномочия и может нести ответственность за его выполнение. В противном случае ставить руководство в известность, об отсутствии у Вас возможности качественно выполнять свои функций. Это правило поможет сэкономить время на бесполезные беседы «по кругу».
2. Явно оговорить с исполнителем, какой конечный результат необходимо получить при реализации каждого требования, а также способы выполнения задания. Желательно убедиться, что Вас понимают правильно и видят результат работы таким же, каким видите его Вы. Это позволит избежать коммуникационного искажения информации.
3. Определить приоритеты реализации требований, с учетом функций: обязательных и желательных к исполнению. Это позволит увеличить вероятность получения работоспособных модулей, пожертвовав некоторой функциональностью.
4. Договориться, что при возникновении затруднений у исполнителей с реализацией требований, необходимо сразу же обращаться к Вам для уточнения, разъяснения или изменения требования.
5. Регулярно проводить анализ хода выполнения работ и обсуждать проблемы, возникающие в процессе реализации требований.
6. Улучшайте и развивайте процесс передачи требований в разработку, для того, чтобы постепенно уменьшать интенсивность контроля и упрощать разъяснения и саму процедуру.
7. Утвердить график сдачи готовых решений.

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

2. Передаем разработанный продукт заказчику

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

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

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

XIII Решаем проблему изменений требований при эксплуатации целевого продукта

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

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

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

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

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

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

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

2. Вносим изменения в требования только через заявки на изменения

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

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

XIV Заключение

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

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



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