Требования будут расти и меняться. Я не думаю, что кто-то может утверждать это.
Как собирать и обрабатывать входящие запросы .
По моему опыту, это помогает при сборе требований, если существует одна или очень небольшая группа клиентов, выступающая в качестве фильтра для предоставления новых или обновленных требований небольшой группе планировщиков разработки. Любой с их стороны может предложить или написать их, но доставка должна быть осуществлена лишь очень немногими. Чем меньше людей вовлечены в обмен с одной стороны на другую, тем лучше.
Цель фильтрации через меньший набор людей состоит не в том, чтобы отбрасывать или уменьшать усилия и информацию, которые вкладывают другие, даже если они дублируют или кажутся неважными на поверхности, а в том, чтобы ограничить точки отказа: потерянная или неправильно обработанная информация. Это следует принципу, аналогичному цели инкапсуляции и интерфейсов: защищать личные данные и устанавливать общий протокол для обработки похожих запросов. Позвольте мне повторить: представление дубликатов в порядке. Как планировщик, мне важно то, о чем они говорят или предлагают. Сохраните или запишите все.
Как отслеживать и организовывать требования
В краткосрочной перспективе, перейти на низкие технологии
Очевидно, что существуют низкотехнологичные решения, которые могут быть в значительной степени эффективны при организации и отслеживании входящих требований: доски объявлений, стикеры, плакаты, что у вас есть. Это может быть отлично подходит для краткосрочного планирования. Они хорошо видны, принимают обозначения произвольной формы и их легко «перенастраивать».
В долгосрочной перспективе используйте программный инструмент с возможностью поиска, сортировки и ссылки
Для более дальних усилий, какое-то программное обеспечение будет полезным. Существуют специализированные инструменты управления требованиями: Doors, Clearcase / Clearquest и многие другие. Эти узкоспециализированные инструменты хороши в том, что они делают, но часто излишни. Иногда даже простая старая таблица более чем адекватна. Лично я нахожу общие системы отслеживания проблем довольно полезными для достижения этой цели, и сейчас мой любимый - redmine, но другие, я уверен, тоже подойдут.
С помощью системы отслеживания проблем каждый, кого вы разрешите, может создать «новую проблему» или требование и добавить любую информацию, которую он сочтет целесообразной для включения. Они могут наблюдать за проблемой и давать отзывы о любых действиях, предпринимаемых вами. Вы можете переклассифицировать его, скорректировать приоритет, переписать текст, добавить дополнительную информацию, связать ее с другими «проблемами», перейти к более высокоуровневой функции или «сценарию использования» или истории или любой другой терминологии, подходящей для вашей системы, до тошноты. Другими словами, вы можете многое сделать, чтобы создать прослеживаемый, сортируемый, расставленный по приоритетам, связанный с историей, связанный список требований через проблемы. Кроме того, будучи достаточно настраиваемым из коробки и с открытым исходным кодом, если инструмент не совсем то, что мне нужно или нужно в какой-то момент, я могу изменить его довольно легко, чтобы лучше соответствовать потребностям моего процесса.
Последнее замечание об инструментах: некоторые люди, с которыми я говорил, добились большого успеха, используя простые старые текстовые файлы в системе управления изменениями и управления версиями. Они явно получают преимущества исторических версий. Они также используют базовую операционную систему и дополнительные инструменты для поиска, связывания и каталогизации требований. Они не могут добавить столько структурированной, связанной метаинформации, но не чувствуют, что им это нужно, и их усилия не приносят достаточной пользы. Это может или не может иметь место для вас. Преимущество заключается в том, что в вашем стеке разработки потенциально есть несколько единиц программного обеспечения для управления и обслуживания.
Постконтрактные присуждения / стартовые требования разработки проекта
Последний аспект вопроса - как управлять требованиями после начала работы. Я думаю, что есть две основные мысли по этому поводу, и часть того, как вы справляетесь с ними, зависит от характера ваших отношений с клиентом: во-первых, если по контракту с фиксированной стоимостью, требования, которые вступают в силу после присуждения контракта, могут быть включены. Подразумевается, что они могут изменить объем усилий, поэтому ставка или счет будут выше, когда эти дополнительные предметы будут доставлены и приняты; если эквивалентное количество усилий не будет удалено из принятого предложения. Если происходит изменение в объеме, вы должны убедиться, что клиент понимает и принимает последствия, в противном случае эти запоздалые представления должны быть представлены.
Во-вторых, для новых требований, возникающих после присуждения контракта, и контракт ориентирован больше на временные и материальные усилия (все, что нужно для выполнения основной работы), вы можете и должны быть немного более гибкими, если клиент настаивает на том, чтобы включить его во время этой конкретной поездки Вам будут платить независимо от того, включите вы это или нет, если все, что вы скажете, будет делать.
Если вы не знакомы с ними, вы можете взглянуть на подход Kanban и Agile методы. Эти методы могут помочь сосредоточить внимание на насущных проблемах, не упуская из виду долгосрочные цели развития.
Представьте варианты в виде сценариев «что если» и предоставьте клиенту выбор и решение
В любом случае, оценка «что если» - это хорошая стратегия для ведения переговоров с клиентом и вашей командой. Постройте параллельное сравнение задач, их затрат и графика в соответствии с планом, с колонкой, показывающей ту же информацию для альтернативных подходов. Microsoft Project, вероятно, является хорошим кандидатом для этого, так как вы можете построить различные оценки, основанные на сходном наборе задач.
Однако даже базовая электронная таблица часто столь же эффективна для демонстрации того, как конкретные изменения или включения могут повлиять на стоимость и график. Список в этом случае, вероятно, столь же эффективен, как и дерево, для демонстрации различий. Инструмент и метод, который вы выбираете для построения этих сценариев, во многом зависят от размера проекта и персонала (но даже у трехкратного программного обеспечения, такого как MS Project, есть свои пределы полезности и возможностей).
Рассмотрите эти сценарии типа «что если» как внутренние рабочие элементы и сохраните их на время проекта. Они были критически важными демонстрациями в процессе принятия решений и ведения переговоров. Возможно, вам также придется вернуться к ним или повторить их для последовательного раунда «что если».
При подготовке сценариев типа «что если» дополнительное объяснение «за» и «против» с технической точки зрения или с точки зрения реализации (в упрощенном виде) может быть полезным для обоснования того, почему одна альтернатива будет иметь такое значительное влияние.