Уговаривать требования деловых людей?

Какие методы, кажется, работают лучше всего, чтобы выманить требования у нетехнических деловых людей? Я работаю с командой, которая пытается собрать спецификацию для проекта. Каждый раз, когда мы встречаемся, и это сводится к ожиданиям следующей встречи, мы просим деловых людей вернуть свои требования. Обычно они отвечают примерно так: «Ну, как вы думаете, ребята, вы могли бы создать прототип, чтобы мы могли увидеть, что нам понравится на следующей неделе ... вы знаете, не с какими-либо данными или чем-то еще, поскольку это прототип, просто функциональность». это проект на 6 месяцев плюс, так что он, очевидно, недостижим (нам нужно было бы разработать всю вещь!), и мы даже не знаем, что делать прототипом без какой-либо спецификации. Честно говоря, я думаю, что, как и большинство людей, у них есть представление о том, чего они хотят, они просто не думают об этом целенаправленно, чтобы соблюсти истинные требования. В качестве альтернативы, просто говоря им, «Дайте нам то, что вы хотите, или мы не можем / не будем выполнять какую-либо работу» (мы хотим, чтобы они были довольны результатами), есть ли способы помочь им решить, чего они хотят? Например, мы могли бы сказать им:

«Нарисуйте несколько экранов (в Powerpoint, на салфетке и т. Д.), На которых показан желаемый пользовательский интерфейс со всеми данными, которые вы хотите видеть, и описание функциональности на полях. Исходя из этого, мы улучшим его и создадим бэкэнд на основе этого набора требований к поведению ».

ИЛИ

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

Имеет ли смысл какой-либо из этих альтернативных подходов, чтобы деловые люди сосредоточились на том, что они хотят? Есть ли альтернативы, которые вы видели в действии?

Я провел последние 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 - действительно полезная техника. Всякий раз, когда у вас возникает такая «глупая» реакция коленного рефлекса (не то, чтобы вы когда-либо произносили это вслух), остановитесь и задайте вопрос: почему? Почему эта информация четыре раза перепечатывается, затем печатается, фотокопируется, сканируется, снова печатается, прикрепляется к ДСП, снимается на цифровую камеру и, наконец, отправляется по электронной почте менеджеру по продажам? Там есть причина , и они могут не знать , что это такое, но это ваша работа , чтобы выяснить. Удачи с этим. ;)

Если вы не можете что-то извлечь из них, напишите что-нибудь и одобрите. Нетехническим людям гораздо проще сказать «нет, мне это не нравится», чем «это то, как вы должны это делать».

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

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

Что касается прототипов, сделайте макеты экрана и объясните, как все будет работать вместо этого. Опять же, видеть что-то помогает им визуализировать происходящее. Возьмите с собой новые макеты экрана для встреч и получите ответы.

В прошлом я фактически открывал FireBug и добавлял изменения, которые заказчик запросил прямо перед ними, чтобы они могли видеть, как он будет выглядеть. Они дали свои отзывы, я сделал снимок экрана, затем внес изменения. Им действительно нравилось видеть, как будут выглядеть изменения, и мне понравилось, потому что это было быстро, и я получил ответ на этой встрече ... а не на следующей.

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

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

Посмотрите, есть ли у них какие-либо отчеты, которые они в настоящее время используют или хотят использовать. Очевидно, что вы не сможете создать отчет, если не соберете данные должным образом. Они должны что-то делать, если это не то направление бизнеса, которое они еще не начали.

У многих есть такие общие понятия, что вы программист, так что вы знаете, как создавать все программы. Сайты электронной коммерции все одинаковы, верно?

Начните с малого. К сожалению, пока вы не получите что-то перед ними, процесс просто не регистрируется. Если вам нечего пройти, просто подделайте это.

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

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

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

• Убедительные демонстрации Что важнее для завоевания клиентов? Какие части программы или функции должны выделяться и должны быть полностью отшлифованы? Можете ли вы предоставить мне макет, используя заметки, картонные коробки или другие резервные копии, которые вы хотели бы использовать?

• Рыночная / конкурентная информация Что мы делаем для каждой пользовательской истории, которая похожа на наших конкурентов? Другой? Какую историю рассказывают наши конкуренты, и мы пытаемся копировать / подражать / улучшать / вводить новшества / целенаправленно отличаться?

• Открытые вопросы Что из требований и дизайна является информацией, в которой вы уверены, и что такое эксперимент? Где мы собираемся попробовать альтернативы, чтобы увидеть, какой из них работает? Если вы смотрите на несколько вариантов, и вы сказали нам только один, какие другие вы рассматриваете?

Затем нарисуйте некоторые границы:

• Пожалуйста, не устанавливайте технические ограничения на меня . Деловой человек не должен говорить вам «используйте окна, потому что это лучше, чем Linux». Они могут, однако, предоставить инструкции в соответствии с тем, что «все наши целевые рынки используют окна, наше приложение должно будет работать на окнах, чтобы добиться успеха»

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

• Запишите решения. Желательно встраивайте их в контракты или другие обязательства, которые вы принимаете. Помните, однако, что решение, которое клиент не понимает, не стоит той бумаги, на которой оно написано. Клиент, подписывающий "приложение будет работать на порту 1521", не стоит столько, сколько клиент, подписывающий "приложение, будет работать на настраиваемом настраиваемом порту, для которого может потребоваться специальная настройка брандмауэра и безопасности при развертывании "

С вашей точки зрения, чтобы процесс продолжался:

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

• Обеспечьте содержательное общение. Укажите вопросы, которые у вас есть, и дополнительную информацию, которую вы обнаружили или ищете, с точки зрения информации, которая была вам предоставлена. «Мы идем с Linux», вероятно, является плохо написанным отзывом, в то время как «наши тесты показывают, что приложение работает более плавно, если оно размещено на машинах Linux и доступно с помощью IE в Windows», может быть более подходящим.

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

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

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

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

ДОБАВЛЕНО: Если вы попытаетесь навязать документ с требованиями клиентам, у которых нет необходимого опыта, это может быть огромный красный флаг, указывающий на приближающуюся катастрофу.

Не спрашивайте о требованиях к пользовательскому интерфейсу или данным, спрашивайте о функциональных требованиях.

Спросите их о том, что они хотят, чтобы приложение делало. Пусть они пройдут, как они хотели бы использовать приложение. Для начала оставьте такие детали, как пользовательский интерфейс, данные и т. Д.

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

Как только вы это сделаете, сделайте быстрый макет (мне нравится Balsamiq ). Просто предположите, каким будет пользовательский интерфейс / данные, и не тратьте на это много времени. Затем отнесите этот макет обратно Клиенту. Оттуда они могут сказать вам «нам не нужны эти поля» или «Нам действительно нужен список телефонных номеров, а не только один», или «это должен быть выпадающий список, а не список».

Когда у вас есть отправная точка, гораздо проще выделить данные и пользовательский интерфейс, и я считаю, что определение функциональности - лучшая отправная точка.

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

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

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

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

Я бы сказал им, что вы будете развивать функцию программы за функцией. До следующей встречи, скажем, через 1-2 недели вы собираетесь работать по ряду функций. Это может быть 1, 2, 3 или более.

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

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

Повторно используя предыдущий пример, клиент может сказать вам, что он проверяет карту пользователя или вносит депозиты и т. Д. Затем попросите их определить его для вас. Не бойтесь задавать много вопросов, даже наивных, если это будет необходимо.

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

Через 1-2 недели снова встретитесь с клиентом, чтобы представить ему, что вы сделали, и узнать его мнение. Представьте это клиенту и получите их информацию, если что-то нужно изменить или добавить.

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

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

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

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

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

Я предполагаю, что у программистов есть лучшая способность представлять, как будет выглядеть программа, прежде чем она будет построена. Бумажное прототипирование может быть эффективным методом преодоления этого. Бумажные прототипы относительно дешевы в сборке. Проводя своих клиентов по простому бумажному прототипу, вы демонстрируете необходимость думать «целенаправленно, чтобы соблюсти истинные требования». И это дает конкретный способ сосредоточиться: на самом деле пытается использовать приложение, которое у вас в голове!

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

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

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

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

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