Права и обязанности заказчика
Коротко Вигерс и Битти перечисляют десять прав, на которые заказчики могут рассчитывать в работе с аналитиками и разработчиками, и десять ответных обязанностей, которые заказчики берут на себя. Если обсудить их в начале проекта вместе с явными правилами принятия решений и разумным пониманием того, что означает подпись, они снимут большую часть трений вокруг требований.
По материалам: К. Вигерс, Дж. Битти, «Разработка требований к программному обеспечению», 3-е изд., гл. 2.
На этой странице
Главные идеи#
Разрыв ожиданий#
Разрыв ожиданий (expectation gap) — расстояние между тем, что заказчикам на самом деле нужно (а это со временем меняется), и тем, что разработчики создают, исходя из понимания на старте. Без контакта разрыв продолжает расти. Каждая точка контакта (интервью, рассмотрение требований, демонстрация прототипа, отзыв на работающий инкремент) частично его закрывает, после чего он снова начинает расти. Частые точки контакта делают итоговый разрыв намного меньше.
Заинтересованные стороны и заказчики#
Заинтересованная сторона (stakeholder) — любой человек, группа или организация, которые участвуют в проекте, испытывают его влияние или могут на него повлиять. Заказчики — их подмножество: те, кто запрашивает продукт, платит за него, выбирает его, определяет требования к нему, пользуется им или получает результаты его работы. Юристы, аудиторы, поставщики, подрядчики и инвесторы — заинтересованные стороны, но не заказчики.
Книга делит возможные заинтересованные стороны на три круга: команда проекта, разрабатывающая организация в целом (маркетинг, поддержка, обучение, руководство) и люди за её пределами (прямые и косвенные пользователи, покупатели, отдел закупок, регулирующие органы, органы сертификации, эксперты в предметной области, бета-тестировщики, общественность). Там же рассказана история о налоговом отделе, о котором никто не знал до поздней проверки процесса; проект задержался на месяцы. Начинайте с широкого списка и потом сужайте его.
Права и обязанности парами#
В книге права и обязанности даны двумя отдельными списками по десять пунктов. Если свести их в пары, как ниже, ими проще пользоваться в разговоре: «у вас есть такое право, а вот соответствующая обязанность».
| Заказчик имеет право… | …и обязан… |
|---|---|
| Работать с аналитиками, которые говорят на его языке и не жалеют времени, чтобы изучить его бизнес и цели | Знакомить аналитиков со своим бизнесом и тратить время, нужное для уточнения требований |
| Получить требования, записанные в подходящей форме, и пояснения к рабочим продуктам требований | Выражаться конкретно и точно; помечать TBD («подлежит определению») настоящие открытые вопросы, а не уходить так от трудных |
| Узнавать о вариантах и альтернативах, включая повторное использование, которое может ускорить поставку | Уважать оценки стоимости и осуществимости, которые дают разработчики («в пределах 50 миллисекунд» осуществимо, а «мгновенно» — нет), и вместе с ними устанавливать реалистичные приоритеты |
| Конкретно описать характеристики, которые сделают продукт удобным в работе | Рассматривать требования, оценивать прототипы и определять критерии приёмки |
| Изменять свои требования, понимая, что у изменений есть цена | Своевременно сообщать об изменениях и уважать процесс работы с требованиями |
| На взаимное уважение | Своевременно принимать решения, когда его об этом просят |
| Получить систему, которая отвечает его ожиданиям по функциональности и качеству | Выполнять всё перечисленное выше: это право зависит от выполнения обязанностей |
Договоритесь, как принимаются решения#
На проекте приходится принимать много решений по требованиям. Заранее договоритесь, кто их принимает и по какому правилу. Вигерс и Битти приводят шесть правил принятия решений по Эллен Готтесдинер: руководитель решает единолично — с обсуждением или без; голосование большинством; единогласное голосование; консенсус, когда все обязуются поддержать результат; делегирование решения названному человеку; групповое решение, при котором у одного участника есть право вето. Ни одно правило не подходит всегда. Важно выбрать правило до первого значимого решения.
Что должна означать подпись#
Базовая версия требований (requirements baseline) — снимок требований, согласованных на определённый момент. Вигерс и Битти предостерегают от двух неверных толкований подписи. Заказчики могут считать её формальностью и подписывать не читая. Руководители разработки могут использовать её как оружие: «Вы подписали — значит, никаких изменений». Лучше понимать подпись так: это наше лучшее общее понимание на сегодня; будущие изменения пройдут через согласованный процесс изменений; изменения могут потребовать новых оценок стоимости, ресурсов и сроков.
Если согласия добиться не удаётся (часто потому, что люди боятся, что после утверждения ничего нельзя будет изменить), запишите это как риск, продолжайте работу, считая текущие требования базовой версией, и ясно сообщите об этом несогласным сторонам.
В гибких проектах#
Формальной подписи обычно нет. Владелец продукта и команда на планировании согласуют истории на итерацию, исходя из приоритета и скорости команды (velocity — её измеренного темпа работы); этот набор на итерацию фиксируется, а новые изменения уходят в следующие итерации. Настоящая подпись — приёмка протестированного работающего ПО в конце. В одном случае, описанном в книге, заказчик настаивал на формальной подписи даже в гибком проекте. Команда переопределила её смысл: «на данный момент нет известных пропущенных требований или серьёзных проблем», а не вечная заморозка.
Как применять#
- На стартовой встрече пройдите парную таблицу с ключевыми заказчиками и адаптируйте её.
- Запишите, кто принимает решения по требованиям и по какому правилу.
- Запланируйте точки контакта на весь проект.
- Используйте формулировку подписи из шаблона ниже для каждой базовой версии.
- Когда возникают трения, возвращайтесь к таблице.
Шаблон#
Подтверждение базовой версии требований — <проект>, версия <x.y>, <дата>
Подтверждаю, что этот набор требований отражает наше лучшее общее
понимание потребностей проекта на эту дату. Я понимаю, что будущие
изменения будут проходить через согласованный процесс изменений
и что изменения могут потребовать новых оценок стоимости, ресурсов
и сроков.
ФИО / роль / подпись
Пример#
На стартовой встрече проекта «Мастерской», вымышленной сети веломастерских, аналитик проходит парную таблицу с владельцем и двумя управляющими мастерскими. Они договариваются о трёх правилах принятия решений: границы проекта определяет владелец после обсуждения; детали процессов управляющие решают консенсусом; споры о раскладке экранов делегируются стороннику продукта от стойки приёма. Точки контакта — демонстрация раз в две недели. При первой базовой версии один из управляющих не решается подписать, боясь оказаться «связанным по рукам»; аналитик показывает формулировку подписи и процесс изменений, и управляющий подписывает.
Источники и что почитать#
- K. Wiegers, J. Beatty. Software Requirements, 3rd ed. Microsoft Press, 2013. Рус. изд.: К. Вигерс, Дж. Битти. Разработка требований к программному обеспечению, 3-е изд. М.: Русская редакция; СПб.: БХВ-Петербург, 2014. Гл. 2.