Я провел последние 3 месяца в исчерпывающей и исчерпывающей фазе сбора требований крупного проекта и узнал, прежде всего, о том, что не существует единого решения, подходящего для всех . Нет процесса, нет секрета, который будет работать в каждом случае. Анализ требований - это подлинный навык, и как только вы думаете, что наконец-то все поняли, вы попадаете на совершенно другую группу людей и вынуждены выбросить все, что вы знаете, в окно.
Разные заинтересованные стороны думают на разных уровнях абстракции.
Легко сказать «говорить на бизнес - уровне, не технический», но это не обязательно , что легко сделать . Система, которую вы разрабатываете, - это слон, а ваши заинтересованные стороны - слепые, проверяющие ее . Некоторые люди настолько глубоко погружены в процессе и рутине , что они даже не понимают , что это бизнес. Другие могут работать на том уровне абстракции, который вы хотите, но быть склонным делать преувеличенные или даже ложные заявления или заниматься желаемым за действительным.
К сожалению, вам просто нужно узнать всех людей как личностей и понять, как они думают, научиться интерпретировать то, что они говорят, и даже решить, что игнорировать.
Разделяй и властвуй
Если вы не хотите, чтобы что-то было сделано, отправьте это в комитет.
Не встречайтесь с комитетами. Сделайте эти встречи как можно меньше. YMMV, но по моему опыту, идеальный размер - 3-4 человека (включая вас) для открытых сессий и 2-3 человека для закрытых (то есть, когда вам нужен конкретный вопрос, на который дан ответ).
Я стараюсь встречаться с людьми, которые имеют схожие функции в бизнесе. Там действительно очень мало что можно выиграть и очень много потерять, если бросить маркетологов в комнате со счетчиками бобов. Найдите людей, которые являются экспертами по одному предмету, и попросите их рассказать об этом.
Встреча без подготовки - это встреча без цели.
Несколько других ответов / комментариев ссылались на технику соломенного чучела, которая является превосходной для тех хлопотливых людей, от которых вы просто не можете получить никаких ответов. Но не полагайтесь на соломенных-мужчинах слишком много, или иначе люди начнут чувствовать , что вы их железнодорожные перевозки . Вы должны мягко подтолкнуть людей в правильном направлении и позволить им самим придумать специфику, чтобы они чувствовали, что владеют ими (и, в некотором смысле, они владеют ими).
Вам нужно иметь какую-то мысленную модель того, как, по вашему мнению, работает бизнес и как должна работать система . Вы должны стать экспертом в области , даже если вы не являетесь экспертом в конкретной компании. Проводите как можно больше исследований своего бизнеса, его конкурентов, существующих на рынке систем и всего остального, что может быть даже удаленно связано.
Однажды я обнаружил, что наиболее эффективно работать с высокоуровневыми конструкциями, такими как сценарии использования, которые, как правило, нравятся всем, но все же важно задавать конкретные вопросы. Если вы начинаете с «Как вы выставляете счета своим клиентам?» Вас ждет очень долгая встреча. Задавайте вопросы, которые подразумевают процесс, а не обостряют процесс на начальном этапе: каковы позиции? Как они рассчитываются? Как часто они меняются? Сколько существует различных видов продаж или контрактов? Где они печатаются? Вы поняли идею.
Если вы пропустите шаг, вам обычно скажут. Если никто не жалуется, то похлопайте себя по спине, потому что вы просто неявно подтвердили процесс.
Отложите не по теме обсуждения .
Как аналитик требований, вы также играете роль фасилитатора, и, если вам не нравится проводить все свое время на собраниях, вам нужно найти способ следить за ходом событий. Как ни странно, этот вопрос становится наиболее пагубным , когда вы , наконец , действительно заставить людей говорить. Если вы не будете осторожны, это может сорвать поезд, на который вы потратили так много времени, прокладывая пути.
Однако - и я усвоил этот трудный путь давным-давно - вы не можете просто сказать людям, что проблема не имеет значения . Это очевидно относится к ним , иначе они бы об этом не говорили. Ваша работа состоит в том, чтобы заставить людей говорить «да» как можно больше и ставить такой барьер, который просто сбивает вас с толку «нет».
Это тонкий баланс, который многие люди могут поддерживать с помощью «элементов действий» - в основном это общая очередь обсуждений, к которым вы обещали вернуться когда-то , обычно помеченные именами тех заинтересованных сторон, которые считают это действительно важным. Это не только ради дипломатии, но и ценный инструмент, помогающий вам вспомнить, что происходило во время встреч, и с кем можно поговорить, если вам понадобятся разъяснения позже.
Разные аналитики обращаются с этим по-разному; некоторым нравится публичная доска объявлений или флип-чарт, другие тихо подключают его к своим ноутбукам и осторожно переходят к другим темам. С чем бы вы ни чувствовали себя комфортно.
Вам нужна повестка дня
Это, вероятно, верно для почти любого вида собраний, но вдвойне верно для совещаний по требованиям. По мере того, как дискуссии затягиваются, умы людей начинают отвлекаться, и они начинают задаваться вопросом, когда вы доберетесь до того, что им действительно важно. Наличие повестки дня обеспечивает некоторую структуру, а также помогает вам определить, как упоминалось выше, когда вам нужно отложить обсуждение, которое становится не по теме.
Не входите туда, не имея четкого представления о том, что именно вы хотите освещать и когда . Без этого у вас нет возможности оценить свой собственный прогресс, и пользователи будут ненавидеть вас за то, что вы всегда бегаете долго (при условии, что они уже не ненавидят вас по другим причинам).
Издеваться
Если вы используете PowerPoint или Visio в качестве инструмента для макета, вы будете страдать от проблемы, которая выглядит слишком отточенной . Это почти странная долина пользовательских интерфейсов; люди будут чувствовать себя комфортно с рисунками салфеток (или сгенерированными компьютером рисунками, которые выглядят как рисунки салфеток, используя такой инструмент, как Balsamiq или Sketchflow ), потому что они знают, что это не настоящая вещь - по той же причине, по которой люди могут смотреть персонажей мультфильмов. Но чем больше он начинает выглядеть как настоящий пользовательский интерфейс, тем больше людей захочет выбирать и лапать его, и тем больше времени они будут тратить на споры о деталях, которые в конечном итоге незначительны.
Поэтому определенно делайте макеты, чтобы проверить ваше понимание требований ( после начальных этапов анализа) - это отличный способ получить очень быструю и детальную обратную связь - но держите их в покое и не спешите насмехаться, пока вы не ' Вы уверены, что встречаетесь со своими пользователями.
Имейте в виду, что макет не результат , это инструмент, помогающий в понимании. Точно так же, как вы не ожидаете, что будете удерживать себя в плену при разработке дизайна пользовательского интерфейса, вы не можете предполагать, что дизайн в порядке просто потому, что они дали вашему макету большой палец вверх. Я видел насмешки, используемые как опору, или, что еще хуже, повод полностью обойти требования; убедитесь, что вы этого не делаете. Вернитесь и превратите эту насмешку в настоящий набор требований.
Потерпи.
Многим программистам трудно в это поверить, но для большинства нетривиальных проектов нельзя просто один раз сесть и выработать полную функциональную спецификацию. Я не просто говорю о терпении во время одной встречи; Анализ требований является итеративным, как и код. Группа A что-то говорит, а затем Группа B говорит то, что полностью противоречит тому, что вы слышали от Группы A. Затем Группа A объясняет несоответствие, и оказывается, что Группа C забыла упомянуть. Повторить 500 раз и у вас есть что - то грубо напоминающее правду .
Если вы не разрабатываете какое-то крошечное приложение CRUD (в таком случае зачем вообще беспокоиться о требованиях?), То не ожидайте получить все необходимое за одно собрание, два, пять. Вы будете много слушать, много говорить и много повторяться. Заметьте, это не страшно; это шанс установить взаимопонимание с людьми, которые неизбежно подпишутся на вашем результате.
Не бойтесь менять свою технику или импровизировать.
Различные аспекты проекта могут фактически требовать различных методов анализа. В некоторых случаях классический UML (Use Case / Activity chart) прекрасно работает. В других случаях вы могли бы начать с бизнес-KSI, или провести мозговой штурм с картой ума, или погрузиться прямо в макеты, несмотря на мое раннее предупреждение.
Суть в том, что вам нужно самим разбираться в предметной области и выполнять домашнее задание, прежде чем тратить чужое время. Если вы знаете, что конкретный отдел или компонент имеет только один вариант использования, но он безумно сложен, пропустите анализ вариантов использования и начните говорить о рабочих процессах или потоках данных. Если вы не будете использовать один и тот же инструмент для каждой части реализации приложения, то зачем вам использовать один и тот же инструмент для каждой части требований?
Держите ухо на земле.
Из всех советов, которые я прочитал для анализа требований, это, вероятно, тот, который чаще всего упускается из виду. Я, честно говоря, думаю, что узнал больше о подслушивании и периодическом сбое разговоров о кулере, чем о запланированных встречах.
Если вы привыкли работать в изоляции, постарайтесь найти место, где происходит действие, чтобы вы могли услышать болтовню. Если вы не можете, то просто делайте частые обходы, на кухню, в ванную или куда угодно. Вы узнаете много всего интересного о том, как на самом деле работает бизнес, слушая, что люди хвастаются или жалуются во время перерывов на кофе и перекуры.
Наконец, читайте между строк .
Одна из моих самых больших ошибок в прошлом была настолько сосредоточена на конечном результате, что я не удосужился услышать, что на самом деле говорят люди . Иногда - в большинстве случаев - может показаться, что люди ни о чем не спорят или о какой-то процедуре, которая звучит для вас совершенно бессмысленно, но если вы действительно сконцентрируетесь на том, что они говорят, вы поймете, что на самом деле требование похоронено там - или несколько.
Как бы банально и безвкусно это ни звучало, Five Whys - действительно полезная техника. Всякий раз, когда у вас возникает такая «глупая» реакция коленного рефлекса (не то, чтобы вы когда-либо произносили это вслух), остановитесь и задайте вопрос: почему? Почему эта информация четыре раза перепечатывается, затем печатается, фотокопируется, сканируется, снова печатается, прикрепляется к ДСП, снимается на цифровую камеру и, наконец, отправляется по электронной почте менеджеру по продажам? Там есть причина , и они могут не знать , что это такое, но это ваша работа , чтобы выяснить. Удачи с этим. ;)