Часто во время фазы предложения по проекту я получаю требования к системе программного обеспечения от наших потенциальных клиентов в очень неструктурированном формате из различных источников [электронная почта, текстовые документы, Excel]. Обычно это «разработчики продукта» со стороны клиента, которые придумывают эти «предлагаемые решения» проблем бизнеса, которые у них есть. Хотя они и являются экспертами в области бизнеса, часто они не имеют правильных решений.
Это приводит к
- несколько версий одного и того же требования
- смешивание двух требований в одно
- несколько версий требования позже по ходу, требования, которые были объединены вместе, снова разделены, каждая из которых берет с собой некоторые новые дополнения
Как вы работаете с такими требованиями, поступающими и разбирающими их в надлежащие варианты использования и до начала разработки? Какие инструменты мы можем использовать для отслеживания истории конкретного требования, с момента его первого зачатия до момента его кристаллизации в надлежащий вариант использования? Оценка работы по требованиям, полученным таким образом, - это кошмар, который приводит к ошибкам в правильном понимании требования и правильной оценке усилий по его выполнению.
После того, как мы выиграем проект, заказчики еще больше подумают о своих требованиях и смогут правильно их сформулировать. В этом случае происходит то, что некоторые функциональные возможности теряются, некоторые улучшаются, некоторые принимают совершенно новый оборот. Это в основном может свести на нет некоторые оценки рабочего элемента, которые были сделаны до того, как проект был выигран. Мне было бы интересно узнать, существует ли какая-либо система, с помощью которой мы можем построить дерево с определенным требованием и как каждая ветвь привела к разной оценке.
Какие-нибудь советы, инструменты, уловки, чтобы сделать эту деятельность более управляемой? Я просто пытаюсь получить представление от кого-то более опытного, чем я в области управления требованиями и оценки усилий.
Ответы:
Требования будут расти и меняться. Я не думаю, что кто-то может утверждать это.
Как собирать и обрабатывать входящие запросы .
По моему опыту, это помогает при сборе требований, если существует одна или очень небольшая группа клиентов, выступающая в качестве фильтра для предоставления новых или обновленных требований небольшой группе планировщиков разработки. Любой с их стороны может предложить или написать их, но доставка должна быть осуществлена лишь очень немногими. Чем меньше людей вовлечены в обмен с одной стороны на другую, тем лучше.
Цель фильтрации через меньший набор людей состоит не в том, чтобы отбрасывать или уменьшать усилия и информацию, которые вкладывают другие, даже если они дублируют или кажутся неважными на поверхности, а в том, чтобы ограничить точки отказа: потерянная или неправильно обработанная информация. Это следует принципу, аналогичному цели инкапсуляции и интерфейсов: защищать личные данные и устанавливать общий протокол для обработки похожих запросов. Позвольте мне повторить: представление дубликатов в порядке. Как планировщик, мне важно то, о чем они говорят или предлагают. Сохраните или запишите все.
Как отслеживать и организовывать требования
В краткосрочной перспективе, перейти на низкие технологии
Очевидно, что существуют низкотехнологичные решения, которые могут быть в значительной степени эффективны при организации и отслеживании входящих требований: доски объявлений, стикеры, плакаты, что у вас есть. Это может быть отлично подходит для краткосрочного планирования. Они хорошо видны, принимают обозначения произвольной формы и их легко «перенастраивать».
В долгосрочной перспективе используйте программный инструмент с возможностью поиска, сортировки и ссылки
Для более дальних усилий, какое-то программное обеспечение будет полезным. Существуют специализированные инструменты управления требованиями: Doors, Clearcase / Clearquest и многие другие. Эти узкоспециализированные инструменты хороши в том, что они делают, но часто излишни. Иногда даже простая старая таблица более чем адекватна. Лично я нахожу общие системы отслеживания проблем довольно полезными для достижения этой цели, и сейчас мой любимый - redmine, но другие, я уверен, тоже подойдут.
С помощью системы отслеживания проблем каждый, кого вы разрешите, может создать «новую проблему» или требование и добавить любую информацию, которую он сочтет целесообразной для включения. Они могут наблюдать за проблемой и давать отзывы о любых действиях, предпринимаемых вами. Вы можете переклассифицировать его, скорректировать приоритет, переписать текст, добавить дополнительную информацию, связать ее с другими «проблемами», перейти к более высокоуровневой функции или «сценарию использования» или истории или любой другой терминологии, подходящей для вашей системы, до тошноты. Другими словами, вы можете многое сделать, чтобы создать прослеживаемый, сортируемый, расставленный по приоритетам, связанный с историей, связанный список требований через проблемы. Кроме того, будучи достаточно настраиваемым из коробки и с открытым исходным кодом, если инструмент не совсем то, что мне нужно или нужно в какой-то момент, я могу изменить его довольно легко, чтобы лучше соответствовать потребностям моего процесса.
Последнее замечание об инструментах: некоторые люди, с которыми я говорил, добились большого успеха, используя простые старые текстовые файлы в системе управления изменениями и управления версиями. Они явно получают преимущества исторических версий. Они также используют базовую операционную систему и дополнительные инструменты для поиска, связывания и каталогизации требований. Они не могут добавить столько структурированной, связанной метаинформации, но не чувствуют, что им это нужно, и их усилия не приносят достаточной пользы. Это может или не может иметь место для вас. Преимущество заключается в том, что в вашем стеке разработки потенциально есть несколько единиц программного обеспечения для управления и обслуживания.
Постконтрактные присуждения / стартовые требования разработки проекта
Последний аспект вопроса - как управлять требованиями после начала работы. Я думаю, что есть две основные мысли по этому поводу, и часть того, как вы справляетесь с ними, зависит от характера ваших отношений с клиентом: во-первых, если по контракту с фиксированной стоимостью, требования, которые вступают в силу после присуждения контракта, могут быть включены. Подразумевается, что они могут изменить объем усилий, поэтому ставка или счет будут выше, когда эти дополнительные предметы будут доставлены и приняты; если эквивалентное количество усилий не будет удалено из принятого предложения. Если происходит изменение в объеме, вы должны убедиться, что клиент понимает и принимает последствия, в противном случае эти запоздалые представления должны быть представлены.
Во-вторых, для новых требований, возникающих после присуждения контракта, и контракт ориентирован больше на временные и материальные усилия (все, что нужно для выполнения основной работы), вы можете и должны быть немного более гибкими, если клиент настаивает на том, чтобы включить его во время этой конкретной поездки Вам будут платить независимо от того, включите вы это или нет, если все, что вы скажете, будет делать.
Если вы не знакомы с ними, вы можете взглянуть на подход Kanban и Agile методы. Эти методы могут помочь сосредоточить внимание на насущных проблемах, не упуская из виду долгосрочные цели развития.
Представьте варианты в виде сценариев «что если» и предоставьте клиенту выбор и решение
В любом случае, оценка «что если» - это хорошая стратегия для ведения переговоров с клиентом и вашей командой. Постройте параллельное сравнение задач, их затрат и графика в соответствии с планом, с колонкой, показывающей ту же информацию для альтернативных подходов. Microsoft Project, вероятно, является хорошим кандидатом для этого, так как вы можете построить различные оценки, основанные на сходном наборе задач.
Однако даже базовая электронная таблица часто столь же эффективна для демонстрации того, как конкретные изменения или включения могут повлиять на стоимость и график. Список в этом случае, вероятно, столь же эффективен, как и дерево, для демонстрации различий. Инструмент и метод, который вы выбираете для построения этих сценариев, во многом зависят от размера проекта и персонала (но даже у трехкратного программного обеспечения, такого как MS Project, есть свои пределы полезности и возможностей).
Рассмотрите эти сценарии типа «что если» как внутренние рабочие элементы и сохраните их на время проекта. Они были критически важными демонстрациями в процессе принятия решений и ведения переговоров. Возможно, вам также придется вернуться к ним или повторить их для последовательного раунда «что если».
При подготовке сценариев типа «что если» дополнительное объяснение «за» и «против» с технической точки зрения или с точки зрения реализации (в упрощенном виде) может быть полезным для обоснования того, почему одна альтернатива будет иметь такое значительное влияние.
источник
Я бы посмотрел на это как на итеративный процесс. Шаг 1 - собрать требования. Шаг 2, чтобы отсортировать их. Шаг 3 - расставить приоритеты. Шаг 4 - это разбиение каждого на достаточно маленькие кусочки, чтобы оценить усилия. Шаг 5 - объединить эти биты в общую корзину усилий (скажем, 84 человеко-дня). Шаг 6 состоит в том, чтобы сопоставить усилия с ресурсами (84 человеко-дня / 2 разработчика = 42 дня).
Итак, прямо сейчас вы застряли между этапами 1 и 2. У вас есть требования, но у вас их нет в той форме, которая вам нужна.
Скажем, у вас есть несколько версий одного и того же требования. Это по сути то же самое? Если так, выберите то, что кажется самым ясным, и используйте его. Если они различаются в деталях, выберите то, что кажется наиболее логичным, и используйте его. Затем отправьте клиенту сообщение с просьбой подтвердить требование. Возможно, вам придется идти туда-сюда и несколько раз, чтобы правильно выполнить требование. Не сдавайся и не унывай. Многие проекты провалились из-за плохих требований.
Используйте проект Microsoft, чтобы синхронизировать работу и график с меняющимися требованиями. Если клиент запрашивает изменение, укажите дополнительную работу, подключите ее к своей модели и сообщите им о новой дате. Не впадайте в заблуждение, что вы можете просто вызывать новых разработчиков через случайные промежутки времени, чтобы преодолеть слабость. Ваше расписание должно учитывать время нарастания при добавлении нового ресурса. Вы сможете правильно смоделировать это, только если будете уделять внимание каждому проекту и учиться на нем. Скажем, вы привели Боба на борт проекта X после того, как он работал в течение 4 месяцев. Насколько продуктивным он был в 1-м месяце? 3-й?
Вам следует пересматривать модель проекта еженедельно, внося обновления в любое время. Ведите исторический учет изменений. Это поможет вам предоставить более точные оценки в будущем.
Дуг
источник