Сбор минимальных требований к трению
Как наша команда может собирать требования от нашего "Владельца продукта" с минимальным трением, но при этом с максимальной эффективностью?
Теперь вот рекомендации: нет сообщений о том, что это невозможно сделать или что бизнес должен принять решение о том, что он заботится о качестве, яда яда. Продукт, для которого я работаю, является небольшой группой, которая была успешной в течение многих лет. Я просто хочу помочь им подняться на ступеньку выше.
По сути, я работаю в команде из 6 или 7 человек с одним владельцем продукта. Она отлично справляется, но выполняет несколько разных ролей (как я полагаю, часто встречается в очень маленьких командах). Обычно требования предъявляются время от времени (встречи по электронной почте, личные встречи, встречи и т. Д.). Они никогда не вводятся в систему, и иногда это приводит к тому, что функции пропускают релиз, или релиз отодвигается назад, так как все забыли о необходимой функции.
Если вы находитесь в подобной ситуации, но вы нашли способ преодолеть это, я хотел бы услышать это. Я рад написать код, который поможет облегчить эту ситуацию, но это не может быть веб-сайт, на который владелец продукта должен зайти, чтобы что-то сделать. Она очень занята, и нам нужен какой-то способ совместной работы, чтобы собрать эти требования.
В настоящее время я думаю о чем-то вроде этого: разработчики и члены команды собирают требования, обсуждаемые на личных встречах, и пишут краткие заметки о функциях, обсуждаемых на вики-странице. Владелец продукта получает уведомление всякий раз, когда эти страницы обновляются, и тогда он становится ответственным за обеспечение точности.
Плюсы: у нас будет некоторая запись функций. Минусы: разработчики берут на себя ответственность за то, чего обычно не делают. Я в порядке с этим здесь. Я думаю, что в этой ситуации это командная работа.
Конечно, как только мы сделаем это, мы увидим, что у владельца продукта, вероятно, недостаточно времени для обеспечения точности функций. В конечном счете, она перегружена, и я думаю, что это поможет продемонстрировать этот факт, но мне просто нужно сначала обратить на это внимание.
Так какие-нибудь предложения?
PS ее время крайне ограничено, поэтому считается необоснованным ожидать от нее необходимости вводить требования после обсуждения. У нее есть только время, чтобы обсудить их один раз и двигаться дальше.
3 ответа
Хотя понятие "владелец продукта" для меня несколько двусмысленно, я думаю, что я работаю в очень схожих обстоятельствах: клиент чрезвычайно занят и всегда является узким местом в разработке требований.
На первый взгляд, то, что мы пытаемся сделать в этой ситуации, довольно очевидно и, казалось бы, просто: мы стараемся убедиться, что клиент задействован в режиме "только для чтения / только для разговора". Нет записи. Минимальное чтение. В основном разговариваю.
Дьявол, конечно, в деталях. Итак, вот некоторые особенности нашего процесса (в произвольном порядке):
Мы часто начинаем с записи постановок задач, которые являются основными источниками требований. На самом деле, иногда постановка проблемы - это все, что мы записываем изначально, просто чтобы убедиться, что оно не потеряно.
NB. Важно отличать формулировки проблемы от требований. Хотя формулировка проблемы иногда явно подразумевает какое-то требование, в общем случае одна формулировка проблемы может привести к целому ряду требований (каждое из которых имеет свою серьезность и приоритет); Более того, иногда данное требование может определить решение (обычно частичное) нескольких проблем.
Одна из основных причин записи формулировок проблемы (и это очень важно для вашего вопроса!) Заключается в том, что семантически они несколько "ближе к шкуре клиента" и более стабильны, чем требования, вытекающие из них. Я полагаю, что эти формулировки проблем значительно облегчают и ускоряют представление клиента в надлежащем контексте, когда у него есть время для обратной связи с командой разработчиков.
Мы записываем все требования (и прослеживаем их до формулировок проблем) независимо от того, когда мы собираемся их реализовать. Приоритеты определяют порядок выполнения требований. Конечно, они также регулируют порядок, в котором клиент рассматривает незаконченные требования.
Примечание: единый жирный документ, содержащий все требования, является абсолютным нет-нет! Все требования помещаются в "базу данных отслеживания проблем" вместе с отчетами об ошибках. (Ошибка - это частный случай проблемы в нашей книге.)
Мы всегда стараемся сделать все возможное, чтобы минимизировать количество итераций, необходимых для "завершения" каждого требования (или группы связанных требований). В идеале, клиент должен рассмотреть требование только один раз.
Всякий раз, когда первый отзыв оказывается недостаточным (происходит постоянно) и рассматриваемое требование является достаточно сложным, чтобы потребовать много текста и / или иллюстраций, мы гарантируем, что клиент не должен перечитывать все из царапина Все важные изменения / добавления / удаления со времени предыдущей обновленной версии выделены.
В то время как проблема или требование остаются в незавершенном состоянии, все открытые вопросы (в основном вопросы клиенту) встраиваются в документ и выделяются. В результате, когда у клиента есть время для пересмотра требований, ему не нужно созывать собрание и запрашивать вопросы у группы; Вместо этого заказчик может сначала открыть любой незаконченный документ, посмотреть, что именно от него ожидается, а затем решить, как лучше и в какое время (для него) решить любой из открытых вопросов. Иногда клиент предпочитает написать электронное письмо или добавить комментарий непосредственно к проблемному документу.
Мы делаем все возможное, чтобы создать и поддерживать официальный словарь домена (даже если он разбросан по всей документации). Самое главное, что мы практически заставляем клиента придерживаться этого словарного запаса.
NB. Это одна из самых сложных частей процесса, и клиент пытается время от времени "бунтовать". Тем не менее, в конце концов все согласны с тем, что это единственный способ сделать драгоценные встречи с клиентом максимально эффективными. Если вы когда-нибудь посещали одночасовые встречи, где 30 минут были потрачены только на то, чтобы все были на одной странице (снова), я уверен, что вы были бы признательны за наличие словарного запаса.
NB. Когда это возможно, любые изменения в официальном словаре отражаются в следующем выпуске программного обеспечения.
Иногда данную проблему можно решить несколькими способами, и правильный выбор не очевиден без консультации с клиентом. Это означает, что клиенту будет доступно "меню требований". Мы документируем такие "меню", а не только окончательно выбранное требование.
Это может показаться спорным и выглядеть как ненужные накладные расходы. Тем не менее, этот подход экономит много времени, когда клиент (обычно несколько недель или месяцев) внезапно сталкивается с вопросом типа: "Какого черта мы сделали это так, а не так?" Кроме того, не так уж сложно скрыть "отклоненные ветви", используя правильную организацию / форматирование документации требований. Скучно, но выполнимо.:-)
NB. При составлении "меню требований" очень важно не переусердствовать с ними. Слишком много вариантов или слишком много уровней вложенности - и следующий обзор может потребовать гораздо больше времени клиента, чем необходимо. Само собой разумеется, что время, потраченное на разработанные ветви, может быть полностью потрачено впустую. Да, здесь трудно найти какой-то баланс (это во многом зависит от способности клиента всегда спешить продумывать два или более шагов вперед и делать это быстро). Но что я могу сказать? Если вы действительно хотите хорошо выполнять свою работу, я уверен, что через некоторое время вы найдете правильный баланс.:-)
Наш клиент очень "визуальный" парень. Поэтому всякий раз, когда мы обсуждаем какие-либо важные элементы пользовательского интерфейса, макеты экрана (или даже облегченные прототипы) часто оказываются чрезвычайно полезными. Иногда экономит время!
Примечание: мы делаем макеты экрана исключительно для клиентов, только для того, чтобы облегчить обсуждение. Они также могут использоваться разработчиками, но ни в коем случае не заменяют спецификации интерфейса пользователя! Чаще всего есть некоторые очень важные детали пользовательского интерфейса, которые указываются в письменном виде (сейчас - в первую очередь для разработчиков).
Нам повезло, что у нас есть клиент с очень техническим опытом. Поэтому мы не стесняемся использовать диаграммы UML в качестве вспомогательного средства для обсуждения. Все виды UML-диаграмм - при условии, что они помогут клиенту быстрее войти в нужный контекст и оставаться там.
Разумеется, я говорю об UML-диаграммах уровня требований. Не об уровне реализации. Я считаю, что даже не очень технические люди рано или поздно начнут копать UML-диаграммы уровня требований; Вы просто должны быть терпеливы и знать, что поставить на диаграмме.
Очевидно, что стоимость такого процесса в значительной степени зависит от аналитических и письменных навыков команды, и, конечно, от инструментов, которыми вы располагаете. И я должен признать, что в нашем случае этот процесс выглядит довольно дорогим и медленным. Но, принимая во внимание очень низкий уровень ошибок и низкий уровень "паровых характеристик"... Я думаю, что в конечном итоге мы получим очень хорошую окупаемость.
FWIW: Согласно хорошей классификации программных продуктов Джоэла, этот проект является "внутренним". Таким образом, мы можем позволить себе быть настолько гибкими, насколько может справиться наш клиент.:-)
Вы можете быть осторожны с HiPPO в комнате. Мнение самого высокооплачиваемого человека не всегда хорошее. Мы стремились уделять больше внимания предоставлению отличных инструментов и поддержки для разработчиков. Эти вещи, сделанные правильно, снимают с себя некоторые хлопоты, так что это становится быстрее и веселее. Разработчики становятся более гибкими в плане своей рабочей нагрузки и более склонны к последним изменениям.
Тестирование и развертывание в один клик - пара хороших для начала; Убедитесь, что каждый разработчик может запустить свой собственный программный стек за несколько секунд и попробовать свои идеи напрямую. После этого разработчики могут быстро вносить изменения или искать пути, которые им кажутся интересными, и эти пути зачастую являются наиболее успешными. Под успешным я подразумеваю измеренный успех, основанный на реальных показателях, собранных прямо в системе и сделанных легкодоступными для всех заинтересованных сторон. После этого владелец может установить метрики, которые, вероятно, его интересуют, а не требования, о которых они либо не заботятся, либо не имеют опыта их определения.
Конечно, это зависит от владельца и вашей конкретной ситуации, но мы обнаружили, что метрики легче обсуждать, чем требования, и что разработчики довольно хорошо их интерпретируют. Типичная проблема может заключаться в том, что покупатели, кажется, тратят много времени на заполнение своих корзин, но не переходят к оформлению заказа.
1) Маркетинговое требование может состоять в том, чтобы сделать кнопку оформления заказа больше и краснее. 2) Требование генерального директора может состоять в том, чтобы доставить клиента прямо к кассе, поскольку генеральный директор в любом случае покупает только один товар за раз. 3) Требование дизайнера пользовательского интерфейса может заключаться в том, чтобы поместить вторую корзину в верхней части корзины, а также существующую в нижней части. 4) Требованием разработчика может быть некоторый виджет AJAX Web 2.0, который следует за указателем мыши по экрану. Кто прав?
Кому интересно... покупатель, наверное, увидел смешную стоимость доставки и убежал. Но переопределите проблему как метрику, а не как требование, и разработчик внезапно заинтересуется. Разработчику не нужно делать 10 раундов с CMO, какого цвета должна быть красная кнопка. Он может играть со своим Web 2.0 всю неделю, а затем в понедельник утром спешить с другими 3 решениями. Каждый из них развертывается в режиме реального времени в течение 48 часов, а скорость доставки из корзины измеряется и сообщается мгновенно. Ничто из этого не имеет значения, но разработчик должен выполнить свою работу, и бизнес переключает свое внимание на дрянные продукты, которые они продают, и цену, которую они оценивают при доставке.
Ну, хорошо, так что пример надуманный. Там много работы, чтобы убедиться, что проект небольшой, команда опытная, быстрое развертывание простое, предусмотрен мгновенный откат, и что все на борту. То, к чему мы хотели прийти, - это состояние, при котором весь потенциал разработчика не теряется, поэтому они участвуют не только с самого начала, но и в успехе. Начните с такой проблемы, как количество кликов во время регистрации, слишком большое, пропустите ее через комитет по проектированию, и мы обнаружили, что количество кликов в спецификации дизайна фактически возросло. Это был наш опыт в любом случае. Но предоставьте разработчику некоторую свободу, чтобы просто уменьшить количество кликов, и вы можете получить запатентованное решение, как и мы. Не то, чтобы разработчик заботился о патентах, но это имело смысл - и никаких кликов!
"Разработчики и члены команды собирают требования, обсуждаемые на личных встречах, и пишут краткие заметки"
Начни с этого. Если вы не делаете заметок, просто внесите одно небольшое изменение. Записывать. Позже вы можете опубликовать их в вики, создать список невыполненных функций или начать использовать Scrum, bugzilla или что-то еще.
Однако сначала внесите небольшие изменения. Записывать вещи звучит как то, что вы не делаете, так что просто сделайте это и посмотрите, что улучшится и что вы можете сделать дальше. Будь проворным. Работать постепенно.