Сбор минимальных требований к низкому трению [закрыто]

Question

Как наша команда может собрать требования от нашего «владельца продукта» максимально простым, но при этом удобным способом?

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

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

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

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

Плюсы:У нас будет некоторая запись о функциях.Минусы:Разработчики берут на себя ответственность за то, за что обычно не стали бы.Меня здесь все устраивает.Я думаю, что в данной ситуации это командная работа.

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

Итак, есть предложения?

P.S.ее время крайне ограничено, поэтому считается неразумным ожидать, что ей придется вводить требования после обсуждения.У нее есть время обсудить их только один раз и двигаться дальше.

Answer 1

Хотя понятие «владелец продукта» для меня немного двусмысленно, я думаю, что работаю в очень похожих обстоятельствах:Заказчик чрезвычайно занят и всегда является узким местом в разработке требований.

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

Дьявол, конечно, кроется в деталях.Итак, вот некоторые подробности нашего процесса (в произвольном порядке):

• Мы часто начинаем с запись формулировок проблем, которые являются конечными источниками требований.Фактически, иногда формулировка задачи — это все, что мы записываем изначально, просто чтобы убедиться, что она не потеряется.

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

  Одна из основных причин записи формулировок задач (и это очень относится к вашему вопросу!) заключается в том, что семантически они несколько «ближе к коже заказчика» и более стабильны, чем вытекающие из них требования.Я считаю, что такие формулировки проблем позволяют гораздо проще и быстрее поместить клиента в правильный контекст, когда у него есть время предоставить обратную связь команде разработчиков.

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

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

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

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

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

• Мы стараемся изо всех сил, чтобы создавать и поддерживать официальный словарь предметной области (даже если они разбросаны по документации).Самое главное, мы практически заставляем клиента придерживаться этого словаря.

  Примечание: Это одна из самых сложных частей процесса, и клиент время от времени пытается «бунтовать».Однако, в конце концов, все согласны с тем, что это единственный способ сделать ценные встречи с клиентом максимально эффективными.Если вы когда-нибудь посещали одночасовые встречи, на которых 30 минут тратилось только на то, чтобы все были на одной волне (снова), я уверен, что вы бы оценили наличие словарного запаса.

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

• Иногда данную проблему можно решить несколькими способами, и правильный выбор не очевиден без консультации с заказчиком.Это значит, что будет «меню требований», из которого клиент может выбрать.Мы документируем такие «меню», а не только окончательно выбранное требование.

  Это может показаться спорным и выглядеть как ненужные накладные расходы.Тем не менее, этот подход экономит много времени, когда клиент (обычно несколько недель или месяцев спустя) внезапно запускается с таким вопросом, как «Почему, черт возьми, мы делали это так, а не так?» Кроме того, не так уж важно скрывать «отклоненные филиалы», используя надлежащую организацию/форматирование документации требований.Скучно, но осуществимо.:-)

  Примечание: При составлении «меню требований» очень важно с ними не переусердствовать.Слишком много вариантов или слишком много уровней вложенности вариантов — и следующий просмотр может потребовать от клиента гораздо больше времени, чем действительно необходимо.Излишне говорить, что время, потраченное на проработанные ветки, может быть потрачено впустую.Да, здесь сложно найти какой-то баланс (он во многом зависит от умения вечно спешащего клиента думать на два и более шагов вперед и делать это быстро).Но что я могу сказать?Если вы действительно хотите хорошо выполнять свою работу, я уверен, что через какое-то время вы найдете правильный баланс.:-)

• Наш клиент очень «визуальный» парень.Поэтому всякий раз, когда мы обсуждаем какие-либо важные элементы пользовательского интерфейса, макеты экрана (или даже облегченные прототипы) часто оказываются чрезвычайно полезными.Реальная экономия времени иногда!

  Примечание: Делаем макеты экранов исключительно для клиента, только для облегчения обсуждения.Они также могут использоваться разработчиками, но они никоим образом не заменяют спецификации пользовательского интерфейса!Чаще всего какие-то очень важные детали пользовательского интерфейса оговариваются письменно (сейчас — в первую очередь для разработчиков).

• Нам повезло, что у нас есть клиент с очень техническим образованием.Поэтому мы, не колеблясь, используйте диаграммы UML в качестве средства обсуждения.Все виды UML-диаграмм — при условии, что они помогают клиенту быстрее попасть в нужный контекст и оставаться в нем.

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

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

Кстати:В соответствии с Хорошая классификация программных продуктов Джоэла, этот проект является "внутренним".Таким образом, мы можем позволить себе быть настолько гибкими, насколько это возможно для наших клиентов.:-)

Answer 2

«Разработчики и члены команды собирают требования, обсуждаемые на личных встречах, и пишут краткие заметки»

Начни с этого.Если вы не делаете заметок, просто внесите одно небольшое изменение.Делать заметки.Позже вы можете опубликовать их в вики, создать список функций или начать использовать Scrum, bugzilla или что-то еще.

Однако сначала внесите небольшие изменения.Записывайте вещи, которые кажутся чем-то, чего вы не делаете, так что просто сделайте это и посмотрите, что улучшится и что вы можете сделать дальше.Будьте гибкими.Работайте постепенно.

Answer 3

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

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

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

1) Маркетинговым требованием может быть сделать кнопку оформления заказа больше и краснее.2) Требование генерального директора может заключаться в том, чтобы направить покупателя прямо к кассе, поскольку генеральный директор в любом случае покупает только один товар за раз.3) Требованием дизайнера пользовательского интерфейса может быть размещение второй кнопки оформления заказа вверху корзины, а также существующей внизу.4) Требованием разработчика может быть какой-нибудь виджет AJAX Web 2.0, который следует за указателем мыши по экрану.Кто прав?

Какая разница...заказчик наверняка увидел смешную стоимость доставки и убежал.Но если переопределить проблему как метрику, а не как требование, и разработчик внезапно заинтересуется.Разработчику не нужно 10 раундов с директором по маркетингу о том, какого оттенка красного должна быть кнопка.Он может всю неделю играть со своей штукой Web 2.0, а в понедельник утром срочно приступить к остальным трем решениям.Каждый из них развертывается в реальном времени на 48 часов, а скорость от корзины до оформления заказа измеряется и сообщается мгновенно.Ничто из этого не имеет никакого значения, но разработчик должен выполнять свою работу, и бизнес переключает свое внимание на дрянные продукты, которые они продают, и цену, которую они оценивают при доставке.

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