Позволить пользователям собирать требования самостоятельно или вести их вместе?

Я уверен, что все испытали что-то подобное. Вы идете на встречу с клиентом, у которого есть проект. У них нет / мало требований в уме и смутное понимание того, что они хотят / нуждаются. На данный момент, кажется, есть два варианта:

1) Скажите пользователям: «Хорошо, поэтому я не могу построить что-то для вас, если вы еще не можете даже описать это. Почему бы нам не собраться вместе через несколько недель, когда вы знаете, чего хотите».

2) Встречайтесь с пользователями несколько раз и помогите им понять, чего они хотят, проведя их с помощью хорошего метода Сократа. «Вам нужно отслеживать X?», «Как насчет Y?», «Вам нужна функциональность Z?»

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

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

Я должен признать, что иногда я выбираю вариант 3)

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

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

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

Так, иногда приятно принимать клиентов видение , применить приличную дозу программистами-здравого смысла, и построить что - то , что соответствует их потребностям.

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

Во многом та же проблема, что и упомянутая выше (# 3), и та, которая заставляет вас делать № 2 в любом случае.

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

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

ДОБАВЛЕНИЕ: этот процесс называется «системный анализ и проектирование», иначе говоря, «Консалтинг», и его никогда нельзя делать бесплатно.

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

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

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

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

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

Это можно рассматривать как «дополнительные» усилия, которые не окупаются, однако я предпочитаю рассматривать их как инвестиции по двум причинам:

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

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

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

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

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

В любом случае: переписывание части кода никогда не перевешивает переписывание части требований.

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

Определенно вариант 2, если ваши пользователи не разработчики (даже тогда может потребоваться вариант 2).

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

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

Вы не хотите переходить к варианту № 2, когда они едва могут сформулировать то, что они хотят, поскольку это сделает весь процесс более медленным и более расстраивающим (если у них уже нет четкого представления о том, чего они хотят, когда они приходят к вам, но по моему опыту это очень редко). Заставьте их собрать свои идеи вместе. Попросите их написать что-нибудь на бумаге, по возможности описать, что они хотят с точки зрения существующих систем (например, «нам нужен веб-сайт, такой как blahblah.com, но с этими различиями ... нам нужен инструмент, который выполняет задачу А, например, продукт X»). , но пользовательский интерфейс должен также выполнить задачу B ... "). Тогда самое время приступить к уточнению того, что они хотят, в соответствии с очень специфическими требованиями, которые вы можете использовать для построения системы.

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

Чтобы спроектировать то, что будет соответствовать их потребностям, вы должны определить эти потребности, и для этого кому-то придется удерживать клиента и извлекать эти потребности. Если никто не может сделать это, то вы должны. (Если кто-то думает, что может, вам, возможно, придется сесть с ними и извлечь реальные потребности позже ...)

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

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

Вариант 1 - отличный способ избежать некоторой работы. Я использовал его, когда полагал, что работа ненужна или у меня были более важные дела.

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

Во-вторых, пользователи не обязательно знают, что им нужно, и обычно не знают, чего они хотят, в каком-либо практическом смысле.

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

Единственный способ дать пользователям то, что им нужно, так, как им нравится, - работать с ними самостоятельно.