Как бороться с частыми изменениями требований?

Я имею дело с довольно стрессовой (на мой взгляд) ситуацией на моем нынешнем рабочем месте.

Мы начали разработку нового проекта, получили некоторые требования, реализовали его и затем показали кому-то, кого вы можете назвать «бизнес-консультантом» (человеком, который знает бизнес-требования, но не будет использовать программу). Этот человек должен оценить приложение с точки зрения клиентов, протестировать его и т. Д.

Вот как выглядит «процесс»:

1. бизнес-консультант разговаривает вечером с моим боссом час или два на Windows Messenger
2. На следующий день я получаю письмо с копией этого разговора. Я должен выбирать задачи из этого, проверять сообщения об ошибках (которые часто не являются ошибками, просто плохое тестирование и забывать о прошлых учреждениях)
3. Я внедряю изменения, реализация принимается, и затем через неделю или две оказывается, что они не хотят, чтобы они хотели (они поговорили с каким-то потенциальным клиентом, который видел программное обеспечение в течение 5 минут, и он предложил изменения) - я должен сделать новые изменения

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

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

Я прошу у вас совета, как справиться с этой ситуацией? Это нормальная ситуация, и я просто чувствителен к этому?

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

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

Карты истории

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

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

Кажется, что самая большая проблема здесь - это особый способ управления изменениями. У вас есть то, что Agile / Scrum считает «владельцем продукта», который дает обратную связь, но процесс плохо документирован и плохо продуман.

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

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

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

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

После того, как они одобрят, отправьте им свое расписание, когда элементы будут готовы для тестирования, и попросите их выделить время для тестирования / утверждения завершения.

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

Отталкивать. Ответственным лицам необходимо узнать, сколько стоят эти запросы.

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

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

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

После того, как будут определены достаточно важные требования, попросите человека, который исполняет Project Ownerроль, подписать их и заблокируйте на неделю, пока вы их строите. Распределите достаточно работы для себя там, где вы будете заняты, и дайте полномочия знать о вашем распределении. То есть, если в неделю вы можете получить работу в 16 баллов, а у вас есть 16 баллов, то вы полностью используете эту неделю. (Понятие очков происходит из гибкого рабочего потока)

Если в середине недели произойдут изменения, произнесите эти волшебные слова:

Я могу сделать [эту новую функцию], [это новое изменение], [и т. Д.], Но что вы не хотите делать ?

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

Если требования меняются чаще, возможно, вам придется договориться о большей стабильности в вашей среде.

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

1. Стремление руководства сделать конечного пользователя счастливым как можно быстрее и показать быстрый прогресс.

2. Отсутствие детального анализа. Помните, что аналитикам нужно задавать вопросы о том, почему не только что. Аналитики должны «думать» с конечным пользователем о «решении», а не только принимать заказы.

3. Отсутствие формального процесса проверки и подтверждения требований с последующим утверждением.

4. Попросить неправильного человека выполнить одну или несколько ролей, для которых они необязательно обучены, например, роли бизнес-аналитика или системного аналитика.

5. Ограниченное прототипирование.

6. Предположение / страх, что это должно быть сделано быстро, а если нет, то виноваты.

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

Я думаю, что вы должны подходить к этому с нескольких направлений:

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

2. Формализуйте требования / пользовательские истории, оценивая каждый из них:
   a. Приоритет (срочность / важность)
   b. Срок погашения (насколько он определен - понимается и согласовывается большинством заинтересованных сторон *)
   c. Сложность (приблизительная оценка)
   
   При выборе того, какое требование / пользователь должен работать над следующим, учитывались все три фактора. Если требование имеет низкий срок погашения, добавьте перед ним исследовательскую миссию, в которой вы свяжетесь со всеми заинтересованными сторонами, выясните причины этого требования и лучше определите требование (напишите сценарии использования и / или создайте каркасные структуры и представьте их), прежде чем действовать на него.

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

4. Попробуйте адаптировать процесс быстрой разработки, например, SCRUM или Kanban - это предоставит вам инструментарий для разработки продукта с изменяющимися требованиями.

Вам также следует подумать о том, чтобы попросить модераторов перенести этот вопрос на PM.stackexchange.com (пометив его), поскольку, хотя этот вопрос подходит и здесь, он бы подошел лучше.

(*) Держатели долей за соглашение: бизнес, маркетинг, управление проектами, развитие и обеспечение качества.