Письменная спецификация требований к разработке
Другой крайностью является старт проектирования и разработки только по окончании детальной проработки требований, оформленных и согласованных письменно, в виде документа.
Называться он может по-разному, в зависимости от принятых у заказчика или разработчика стандартов. Это могут быть и бизнес-требования, и требования к системе, и программная спецификация – перечень не полный, встречаются разные креативные варианты.
Первое ощущение, которое возникает при описании такого подхода – долго, нудно и, скорее всего, дорого. И это ощущение имеет под собой реальную почву. Так почему же и в каких случаях имеет смысл использовать такой подход?
Что дает нам письменная согласованная специалистами заказчика спецификация требований (пропустим про спокойный сон руководителя проекта, поскольку у него юридически ограничены рамки проекта, хотя это тоже есть)?
Хорошая спецификация дает нам предварительно построенную достаточно детальную и непротиворечивую картину, что же мы должны построить.
При этом еще и определены приоритеты, как это строить, проработаны и сняты основные нестыковки, с которыми при построении решения столкнется разработчик.
То есть, хорошая спецификация существенно повышает шансы достигнуть цель разработки в плановые сроки и бюджет. Также проще планировать путь и ресурсы исполнения проекта.
Здесь важно отметить, что речь идет о хорошей спецификации, а не о томах сказок и легенд, которые нередко выдаются за бизнес-требования. Только согласованные, достоверно отражающие реальность, однозначно толкуемые, проверяемые и непротиворечивые требования, определяющие искомую цель автоматизации и изложенные в спецификации обладают названными достоинствами.
Некоторые недостатки подхода очевидны – сравнительно долго и трудозатратно – нужно время, чтобы формализовать замысел, записать и оформить требования, согласовать их. Это явно дольше, чем просто рассказать.
Из неочевидного – если разработчик неправильно поймет спецификацию или она по содержанию не несет в себе требований, то может возникнуть опасная иллюзия, что все под контролем и работа идет к цели по плану, хотя на самом деле разработка ведется даже не «со слов», а из предположений разработчика как это могло бы быть в спецификации.
Письменные спецификации требований характерны для сложных проектов с широким охватом бизнес-процессов, интеграционными взаимодействиями, длительным жизненным циклом решения и, соответственно, сроком сопровождения. Применяются чаще в крупных организациях, склонных к тяжелым, например, водопадным, методологиям внедрения.
Еще один момент – время разработки спецификации. Мир сейчас меняется быстро, и бизнес-среда тоже, поэтому время создания решения, в том числе требований к нему, часто критично.
Проработка хорошей спецификации требований требует времени, которого может и не быть – это следует сопоставить с бизнес-окружением, конкурентами, сроком жизни разрабатываемого решения и вовремя остановиться с детализацией.
Случаи, когда требования к моменту завершения их подготовки уже устарели – увы, обычная история в современном корпоративном мире.
Поэтому хорошая спецификация требований – отличное подспорье проекту разработки ИТ-решений, но нужно чтобы она была действительно хорошей и завершалась до того момента, когда ее содержание устареет.
Agile-подход
Нужны ли письменные спецификации в Agile? Недальновидные поклонники методологии думают, что ее придумали, как отказ от документирования. Гуру указывают, что они такого не замышляли, и вот почему. Посмотрим на Agile манифест, широко известный в русском переводе, где говорится, что:
– Люди и взаимодействие важнее процессов и инструментов.
– Работающий продукт важнее исчерпывающей документации.
– Сотрудничество с заказчиком важнее согласования условий контракта.
– Готовность к изменениям важнее следования первоначальному плану.
То есть, не отрицая важности того, что справа, мы всё-таки больше ценим то, что слева.
Все заявления затрагивают требования, попробуем понять, как.
«Люди и взаимодействие важнее процессов и инструментов» говорит нам о том, что нужно выбирать тот объем и характер взаимодействия специалистов заказчика и разработчика, который позволил бы им максимально быстро и комфортно сформировать единое мнение о том, какое ИТ-решение нужно разработать. Для хорошо сыгранной команды и простого решения это может быть разработка «со слов», для множества распределенных команд и сложной корпоративной системы – объемная согласованная стандартизованная документация. Именно выбор людьми команды подходящего ситуации инструмента и процесса декларируется здесь.
«Работающий продукт важнее исчерпывающей документации» не отрицает документирование, а лишь указывает на ее вторичную, поддерживающую роль. Пока продукт работает корректно и не развивается, принцип может трактоваться как отсутствие документации. Как только заходит речь о поддержке и развитии – сразу требуется наличие минимально необходимой документации, в которую обычно входят и бизнес-требования «для чего и почему именно так мы действуем».
«Сотрудничество с заказчиком важнее согласования условий контракта» говорит о готовности к изменениям даже если законтрактованы жесткие требования. Увы, жизнь сложнее и многообразнее любой спецификации требований, однако контрактные рамки позволяют цивилизованно и к обоюдной выгоде разрешать такие отклонения. Документирование требований, в частности, являющееся приложением к контракту, эти рамки создает.
«Готовность к изменениям важнее следования первоначальному плану» указывает, как и предыдущее, что изменения неизбежны и к ним нужно быть готовыми. Тем не менее, чтобы изменить первоначальный план, его нужно сначала выстроить. А если изменять планы и не отслеживать (документировать) отклонения, вполне возможно начать ходить по кругу, зациклиться в изменениях, и цель не будет достигнута.
Таким образом, Agile придерживается позиции постоянной готовности к изменениям ради движения к цели в целом, и, для обеспечения этого, предлагает использование разумного объема документирования, исходя из текущей ситуации (и этот объем может меняться по ходу работ вместе с ситуацией).
Agile позволяет совместить преимущества ранее описанных подходов «со слов» и письменной спецификации, устранив часть недостатков.
Однако, существенным ограничением применения Agile является существование факторов, влияющих на него, которые невозможно изменить в ходе проекта. Это могут быть как внутренние ограничения, например, размер бюджета или нормативные акты внутри компании, так и внешние, например, требования законодательства.
Выявление таких требований на поздних этапах разработки может привести к необходимости начать ее полностью или в значительной части с начала, что никак не приближает к цели, поэтому «полный Agile», исключающий такие факторы из рассмотрения может быть успешен лишь на небольших обособленных задачах.
Наш опыт свидетельствует, что оптимальным является подход письменной спецификации общей структуры решения с последующими Agile итерациями в реализации отдельных задач. В этом случае минимизируется риск не учета в требованиях существенных факторов, влияющих на процесс, но сохраняются преимущества и гибкость Agile подхода при решении частных задач.
Когда же разумно начинать разработку?
Привести формальный критерий начала разработки и просто, и сложно одновременно. Кажется, что чем быстрее начнем разработку, тем быстрее придем к цели.
И это было бы верно, если бы путь к цели был фиксирован, а его длительность и затраты не зависели от исходной постановки требований. Увы, зависимость есть, и она не линейна. Вплоть до того, что при существенных неточностях можно двигаться кругами сколь угодно долго.
Поэтому нужен какой-то критерий. Сформулировать его нам поможет представление о рисках проекта, которое поверхностно сводится к тому, что:
– выполняя какую-то работу для снижения рисков, мы тратим дополнительно ресурсы и время, но верим, что возможные затраты ресурсов и времени на ликвидацию последствий срабатывания риска существенно выше, а вероятность срабатывания не позволяет риском пренебречь.
– не делая ничего для снижения риска, мы понимаем и принимаем необходимые затраты ресурсов и времени на устранение последствий срабатывания риска с учетом его вероятности и готовы в случае срабатывания эти затраты понести или смириться с тем, что проект не достигнет цели. Причины могут быть самые разные, начиная от реальной невозможности что-то сделать и до обычной лени и самоуверенного игнорирования риска, но важен результат – не делаем.
Начать разработку означает «начать что-то делать» для снижения риска «не разработать никогда, потому что не начали», а этот риск реален. Для проекта этот риск выглядит скорее с временным ограничением – «не успеть разработать вовремя».
Не начать разработку, но уточнять требования, означает «делать что-то» для снижения риска «разработать не то, что нужно, но потратить ресурсы и время».
В каждый момент можно оценить эти риски, оценить затраты ресурсов и времени на выполнение шага «начать разработку» и шага «не начинать пока, продолжить уточнение требований» и принять вполне взвешенное решение, пора или еще нет.
Интересный факт состоит в том, что по мере разработки и погружения в детали оба риска будут меняться в своих оценках. Натыкаясь на «грабли» по ходу разработки будет вырастать риск «не успеть разработать вовремя», а риск «разработать не то» от приостановки и уточнения будет снижаться. Наоборот, если все оказалось вполне понятно, риск «не успеть разработать вовремя» не будет расти по ходу разработки. Таким образом, оба риска стоит переоценивать по ходу проекта и, если выявляются неясности, принимать взвешенные решения, вплоть до приостановки разработки до уточнения требований, если вероятность «разработать не то» становится угрожающе высокой.
Таким образом, точкой начала разработки является такой момент, когда затраченные на ближайший шаг разработки время и ресурсы приемлемы по результату и ожидаемой его полезности для достижения цели. При этом полезность может быть разная, например:
– Получение части функций решения (непосредственно приближает к цели);
– Получение прототипа или макета для обсуждения и принятия более обоснованных требований (приближает к цели, но часть затрат может оказаться «выброшенной» – придется переделать, речь идет о прототипах и макетах, но полученная информация приближает проект к цели быстрее и точнее альтернативных вариантов);
– Апробация технологических решений (снижает технологические риски не достижения цели, уточняет возможность и соответствие показателям назначения используемых технологических решений, алгоритмов, методик).
Рекомендация по моменту начала разработки может быть сформулирована так: как можно раньше, но, когда уже осознана и формализована польза для достижения цели от ближайшего шага разработки, взвешены, соизмерены с этой пользой и приняты затраты ресурсов времени на этот шаг.
Ясно, что такой подход наводит на мысль о целесообразности начинать с малых по затратам шагов, дающих максимальное продвижение.
И это действительно так – пока неопределенность высока, лучше быстрыми короткими продвижениями уточнить потребности по ходу разработки, чем завязнуть в сложных деталях, имея большой риск переделки.
Глава 3. Зачем бизнес-требования?
Строить или перестраивать?
Мне нравится подход, восходящий к ТРИЗ (Теория решения изобретательских задач, разработанная Г.Альтшуллером в середине 20 века), который предполагает, что идеальное решение задачи, когда она сама себя решает. В рамках этого подхода при появлении любого нового компонента стоит спросить себя, а зачем он? Нельзя ли прийти к цели без него?
Зададим этот вопрос к бизнес-требованиям. Нельзя ли получить решение без них? И правильный ответ будет «да, это возможно».
Так зачем же нам тратить усилия на них? Все дело в затратах и вероятности. Как и в когда-то популярной вероятностной задаче о вероятности того, что обезьяна, сидящая за пишущей машинкой, напечатает роман «Война и Мир», в нашем ответе также нужно указать вероятность того, что полученное решение без требований совпадет с задачей.
Вероятность эта может быть разной. Например, в случае типового отраслевого решения совпадение с задачей весьма вероятно даже без детальной постановки. В случае же достаточно уникального и сложного процесса такое совпадение маловероятно.
Еще важным фактором является желание и способность бизнеса изменить свои процессы под имеющееся ИТ-решение. Если бизнес проявляет существенную гибкость в этом, то вполне возможен вариант использования типового решения с типовыми его настройками и «натягиванием» на него, как на каркас, бизнес-процессов.
Такое решение обычно существенно дешевле по стоимости внедрения, но может нести риски потери части бизнес-процессов, ухода персонала при переучивании на новые процессы (изменения не всем по душе) и утрате каких-то важных «ноу-хау», запрятанных в процессе и составлявших конкурентные преимущества.
Таким образом, требования тем более нужны, чем сильнее нам требуется отступить от имеющегося типового решения. Фактически, при использовании типового решения, мы соглашаемся с требованиями, заложенными в нем (даже если они формально не описаны или мы о них не знаем), и не разрабатываем свои.
Вопрос, нужны ли требования, еще и сводится к тому, хотим ли мы максимально быстро построить целевое решение, или готовы постепенно и последовательно приближаться к целевому, перестраивая и перестраивая?
Вы спросите: «Будет ли кто-то в здравом уме подписываться на многократную перестройку решения без уверенности в достижении цели?» – и будете правы, что это странный выбор. Но есть обстоятельства, когда такой выбор разумен:
– это исследования и уточнения требований, когда в некоторый момент можно просто остановиться, сказать себе «стоп, теперь нам все понятно» и приступить к разработке решения с понятными требованиями или просто получить необходимые выводы и остановиться (например, CusDev прототипы);
– когда задача кратковременна и ее как-нибудь, но удается решить, а требования собрать равносильно решению задачи (часто так выглядят задачи миграции данных из долго эксплуатируемых, существенно измененных и не очень задокументированных систем).
Завершая этот раздел, отметим, что требования нужны и есть они всегда. Они могут быть уже готовы до нас и «упакованы» в типовое решение, или разработаны нами с разной степенью детальности. Совсем без них не получится, надо же знать, какую цель мы хотим достичь.
Проект или прототип?
Любое дело (конечно, не приводящее к разрушениям) можно делать, по крайней мере, двумя способами: