Я разработчик программного обеспечения, работаю в консалтинговой компании, которая выполняет множество проектов в самых разных областях. Проекты обычно имеют относительно короткий срок реализации (например, несколько месяцев).
Я обнаружил, что у клиентов-экспертов в области есть привычка не совсем правильно, полно или лаконично отвечать на мои вопросы как по электронной почте, так и по телефону/лично. Это расстраивает меня, потому что обычно у меня не так много времени на выполнение работы, и я чувствую, что должен продолжать гоняться за клиентами, поскольку они лишь частично отвечают на мои вопросы и часто вводят меня в замешательство.
Вопросы, которые я обычно задаю, довольно открытые, например
Я не понимаю требование X, не могли бы вы объяснить, что означает «что бы то ни было»?
Или:
Я столкнулся с -некоторой проблемой-, вот несколько предложенных способов ее решения, что вы думаете?
Обычно это общие или неочевидные вопросы, на которые нужно немного подумать, чтобы ответить.
Одна общая проблема, с которой я сталкиваюсь, заключается в том, что эксперты в предметной области склонны предполагать, что я знаю, о чем они говорят, когда они используют специальные термины или обсуждают определенные вещи в их предметной области. Они также могут начать говорить о чем-то совершенно другом, например, о другом требовании. Иногда я получаю в ответ подробный ответ, который может отвечать только на часть вопроса и требует серьезного разбора, чтобы получить нужную мне информацию, или разглагольствования о чем-то косвенно связанном.
Я обнаружил, что когда я прерываю и прошу разъяснений, результаты действительно зависят от человека; иногда что-то может проясниться, но в других случаях они в основном повторяют то, что уже сказали, и некоторые из них могут проявлять нетерпение и снисходительность. Даже если они объясняют, что означают некоторые термины, я все равно не являюсь экспертом в предметной области, поэтому у меня все еще есть лишь поверхностное понимание того, о чем они говорят, и трудно понять, какие части имеют значение, а какие нет.
Вот надуманный, фальсифицированный пример:
Вопрос: Вы упомянули, что хотите, чтобы рецепторы PGA отображались в виде списка — каждый PGA содержит много данных, поэтому я думаю, как его отобразить. Это выглядит нормально для вас?
Ответ: Нам нужен способ показать появление рецепторов PGA в режиме реального времени. В настоящее время мы не знаем, откуда они берутся, поэтому было бы неплохо, если бы у нас был список, показывающий каждый из их номеров и информацию. Затем приходит QXT2 и обрабатывает эти цифры — можем ли мы получить для этого экран? Прямо сейчас требуется много времени, чтобы ввести все значения P для данных, но я не уверен, как лучше всего это сделать. Текущая система была создана давным-давно, и с тех пор мы добавили множество различных типов LFG, каждый со своей собственной системой бонго, которую необходимо ввести в отдельную электронную таблицу и загрузить до запуска приложения. Я думаю, что список PGA должен отображаться на главном экране и содержать столько элементов, сколько было загружено из файла. Это может быть не лучший способ сделать это, но он будет работать на данный момент. Просто имейте в виду, что система бонго для PGA должна быть в формате .xml, поэтому я не знаю, сколько информации вы хотите отображать для каждого из них. Нам нужно, чтобы каждый из них вычислял значения T с течением времени.
Мои мысли, увидев что-то подобное, заключаются в том, что это как бы ответило на вопрос, но также открыло много других вопросов и полно двусмысленности, которая может быть или не быть актуальной. У меня может быть поверхностное понимание того, что такое, например, «PGA», но больше ничего, поэтому я не знаю, стоит ли спрашивать и пережевывать больше времени.
Я неясно формулирую свои вопросы или мне следует сформулировать их по-другому, чтобы получить лучшие ответы, например, они слишком открыты? Обычно я стараюсь не ограничивать возможные ответы, потому что хочу, чтобы клиенты думали о проблеме и/или решении, а не просто «выбирали А или Б».
Вы не задаете открытых вопросов. Вы задаете краткие, направленные вопросы для получения конкретной важной информации, относящейся к задаче или проекту, который их волнует или в котором они заинтересованы.
Люди здесь не для того, чтобы учить вас.
Помогите им (ответив на вопрос) помочь вам.
Не стоит, повторяю, не ожидать, что люди будут рады (или ждут) помочь вам (даже если они так говорят). У каждого есть свои обязанности, о которых нужно позаботиться, и помощь вам может не входить в их список приоритетов (в большинстве случаев).
Если вы задаете вопросы, на которые следует ответить в учебном пособии/погуглить или вам нужен сеанс мозгового штурма, весьма вероятно, что ваш вопрос будет проигнорирован/оставлен без ответа. Задавайте объективные, прямые и актуальные вопросы и добавляйте всю необходимую информацию в сам вопрос. Кроме того, при письменном общении не отправляйте одно электронное письмо нескольким получателям, держите его очень целенаправленным — максимум одному или двум. Если у вас есть проблема, на которую нужно ответить нескольким людям, разбейте их на отдельные вопросы и направьте каждый из них соответствующему человеку.
Несколько быстрых советов, как лучше задать вопрос и увеличить вероятность получения ответа:
"Как мне это сделать" ?
Покажите свои усилия до времени. Сказать:
«Я пытался сделать X, поэтому оценил P и Q, и вот список плюсов и минусов. По моему мнению / анализу, P поможет нам лучше, вы видите то же самое? Есть ли лучший вариант, который я пропустил ?"
"Это не работает, как заставить это работать?" .
Просить:
«Пытался заставить его работать, настроив P, настроив Q и пройдя через R, но в конце концов он показал ошибку, говорящую «hubaa dubba do!». Быстрый поиск в Google показывает, что мне нужно импортировать G и H, чтобы решить эту проблему, пробовал но сообщение изменилось на "Хо-хо-хо!". Приложены примеры конфигураций, которые я использовал, и сведения о среде для работы. Приветствуются любые быстрые мысли, и если вы считаете, что потребуется сеанс отладки, дайте мне знать, я настроить один"
Итог: чем проще вы облегчите им ответ, тем больше вероятность, что вы получите ответ. Сохраните открытые вопросы для тренинга/учебной сессии.
И последнее, но не менее важное: вот хороший справочник о том, как задавать хорошие вопросы. цитирую автора
«Ради удобства — и поскольку Stack Overflow так популярен — я предполагаю, что вопрос будет задан на Stack Overflow или аналогичном сайте Stack Exchange. Большая часть поста на самом деле не зависит от этого, но если вы спрашиваете в другом месте, возможно, вам придется немного изменить совет».
Я думаю, что это будет непопулярным....
Что касается программного обеспечения на моей работе, мы нанимаем FIRST для предметной экспертизы, легче научить C и ассемблеру (да, и основам разработки встраиваемых систем с небольшим ядром), чем научить рабочему процессу в прямом эфире и грубым проблемам, с которыми приходится сталкиваться операционистам. иметь дело иногда.
Нормальный программист, который понимает, как работает предметная область, по нашему опыту, НАМНОГО полезнее, чем блестящий программист, который может только следовать спецификации и не знает, какие биты могут быть вырваны (а кто не признает глупость в спецификации, там вообще какой-то).
То же самое касается разработки бизнес-процессов и работы с такими вещами, как CRM-системы. Сначала изучите бизнес, если вам нужно выполнить рейд по переполнению стека, чтобы узнать, как его закодировать, это меньшая проблема, чем непонимание на довольно глубоком уровне, чего на самом деле должна достичь вещь.
Наш менеджер по продукту является экспертом в предметной области, но знаете что? Как и некоторые из нашей команды разработчиков (и это НЕ разработка программного обеспечения).
У этого есть довольно явное преимущество, эксперты говорят на одном языке, и, хотя они могут не соглашаться, в этой борьбе обычно получается решение, которое ЛУЧШЕ, чем то, что изначально было предложено одним из них.
Эксперт в команде разработчиков распространяет знания среди остальной команды и не отвечает на множество глупых вопросов, поэтому внешнего парня спрашивают только о вещах, на которые нет четкого ответа, и спрашивают на его языке. . Парень из команды разработчиков также активно занимается архитектурой, потому что у малого и среднего бизнеса обычно есть хотя бы представление о том, куда может пойти данный продукт.
Даже для «обезьяны кода» контекстуальное понимание гораздо важнее, чем технические навыки, иначе я выберу язык более высокого уровня и позволю компилятору управлять моим кодом за меня (Дешевле, меньше ошибок и не нужно платить пенсию)!
Если ваш единственный SME находится на вершине компании, у вас есть проблема, потому что ее время тратится впустую, SME раздражен, и люди работают по спецификациям, которые они НЕ понимают доводы, лежащие в основе, это не приводит к хорошим или даже очень полезным результатам.
Наймите кого-нибудь в команду разработчиков, кто говорит на языке любой предметной области и немного разбирается в разработке программного обеспечения, это того стоит.
Когда я работаю с экспертами в предметной области на моей текущей работе по разработке программного обеспечения, я обычно готовлю вопросы «да/нет», которые я собираюсь задать, давая контекст того, почему я задаю себе вопрос, например, ссылка на связанную проблему / билет / задачу, что я сделал вывод из это, спрашивая, правильно ли я понимаю или какой из двух моих сценариев является правильным.
Точно так же, если мне нужны разъяснения по требованию, я, скорее всего, предпочел бы разговор в чате, по телефону или лично, чтобы я мог оставить отзыв о том, соответствует ли разъяснение сути или нет, а если нет, то уточнить, что я спрашивал или спрашивал. дальнейшие вопросы.
Если вам нужна подготовка, чтобы понять экспертов в предметной области, это совсем другая проблема. Знания должны течь в вашей компании, чтобы вы понимали, в чем заключается ваша сфера деятельности, и это в основном ответственность вашего руководства, чтобы вы обладали современными знаниями аббревиатур, акронимов и т. д. и я бы даже сказал, в идеале даже усваивали некоторые знания предметной области, чтобы вы могли сразу понять, когда вам будет представлена спецификация.
Заманчиво полагать, что более открытый вопрос даст экспертам в предметной области больше возможностей для перехода прямо к их требованию, но обычно это приводит только к тому, что они тратят время на объяснение того, что вы уже знаете, перефразируя без уточнения или даже полностью упуская суть.
В любом случае я бы избегал открытых формулировок о «мыслях» или «вводах» по расплывчатой теме, поскольку они будут неудовлетворительными, поскольку вам требуется конкретная информация для написания части рабочего кода.
Открытые вопросы отлично подходят для интервью. Они не являются правильным инструментом для сбора требований.
Когда вы спрашиваете: «Что вы думаете о X?», в лучшем случае эксперт думает: «О, вау, я занимаюсь X уже 20 лет, а этот человек спрашивает о моих мыслях? С чего мне начать? ". В худшем случае они либо предполагают, что вы знаете почти столько же, сколько они, либо предполагают, что вы не можете узнать достаточно, чтобы делать то, что необходимо.
Вместо этого запросите подтверждение. «Я думаю, что X работает так же, как Y, верно?». Или «покажи мне, как ты делаешь Z». Это неизбежно оставит пробелы, так как будут вещи, о которых вы не знаете, о которых вам нужно спросить. Вот почему вам нужно как можно скорее передать в их руки первую итерацию программного обеспечения (даже в форме прототипа) и быстро работать над следующей итерацией, которая отвечает на отзывы от первой. Подготовьте своих экспертов к этому.
Я обнаружил, что самый простой способ получить полезную информацию от экспертов в предметной области — это создать программное обеспечение, которое делает то, что вы считаете правильным , а затем посмотреть, что они думают о нем. Чтобы взять ваши примеры:
Вместо того, чтобы сказать это:
Вы упомянули, что хотите, чтобы рецепторы PGA отображались в виде списка — каждый PGA содержит много данных, так что вот как я думаю отобразить его. Это выглядит нормально для вас?
сделай это:
Поскольку на прошлой неделе вы сказали, что хотите, чтобы рецепторы PGA были показаны в списке, вот макет того, над чем я работаю. [приложить скриншот] Идея в том, что он показывает вам mondo bongo PGA в списке, но вы можете щелкнуть маленькую иконку, чтобы открыть более подробную информацию. Это будет готово на следующей неделе, когда Стив загрузит фигурки из Скуби-Ду.
Это означает, что если есть что-то действительно проблематичное, у них будет что-то конкретное, из чего можно построить: «О, эй, это прекрасно, но можете ли вы убедиться, что PGA как-то подсвечивается, если фактор дыма больше 74%? Также мы должны увидеть Значение R также в списке, и нам нужно иметь возможность фильтровать, где R < 4 или R > 4».
Я передал программное обеспечение и сказал, что это пробная версия, экспериментальная вещь, поэтому не доверяйте ее результатам. И тогда пользователям было предложено попробовать это. Когда они это делают, их опытный глаз часто может увидеть, где что-то выглядит немного не так, и сможет диагностировать проблему. И скажите: это неправильно в случае, когда X выполняется, потому что тогда это происходит, и нам нужно учитывать блегбод.
Так что не используйте электронные письма и разговоры, чтобы сообщить о требованиях к программному обеспечению. Используйте программное обеспечение для этого. Используйте такие вещи, как демонстрации, сценарии UAT, макеты и т. д. Так вам будет намного проще сказать: «Вы это имеете в виду?». Таким образом, предприятиям малого и среднего бизнеса гораздо проще сказать «это правильно» или «нет, это неправильно, потому что Х».
Конечные пользователи могут поделиться с вами полезной информацией помимо «правильной и неправильной». Они могут быть не в состоянии увидеть проблемы, которые у них есть, и сказать: «Послушайте, требуется семь кликов, чтобы перейти к экрану, который я использую чаще всего, а затем мне нужно снова ввести ту же информацию, а затем подождать, пока она загрузится, все время, пока клиент нетерпеливо разговаривает по телефону». Но если у вас есть возможность сидеть с ними и следить за ними, такие вещи будут для вас очевидны. Если вы не можете, подумайте об использовании чего-то вроде пользовательских историй и карт процессов.
Если бы у вас была история пользователя, она могла бы сказать что-то вроде: «Как сантехник PGA, мне нужно перечислить рецепторы отдельно для низких и высоких значений R, чтобы я мог сразу увидеть, где фактор дыма превышает допустимый порог». . Тогда вы бы знали заранее, что нужно реализовать, потому что знали бы, зачем вы это делаете.
Если бы у вас была карта процесса, было бы ясно, что пытается выполнить сантехник PGA и как ему помочь.
Хорошей отправной точкой является понимание того, что ваши «эксперты» в первую очередь выбираются за их компетентность в выполнении своей работы, а не в объяснении или передаче содержания этой работы другим.
Люди (которых можно было бы назвать «студентами», и именно так я собираюсь охарактеризовать вашу роль здесь), которые в целом не разделяют образование, обучение или негласный опыт, которыми обладают эксперты, конечно, склонны ценить открытое общение. от экспертов о том, что включает в себя их работа во всех отношениях. Но обладание такими явными навыками понимания и общения в качестве эксперта с целью воспроизведения этого опыта является прерогативой профессионального педагога.
Эти ваши «эксперты» не являются педагогами по профессии и обычно не будут академиками или интеллектуалами по натуре, поэтому с ними не следует априори обращаться как с людьми, которым можно просто задавать вопросы и от которых можно ожидать хорошего связного ответа.
Стандартный способ воспроизводства бизнес-экспертов из неспециалистов заключается, во-первых, в превращении неспециалистов в учеников профессиональных педагогов (т. информация медленно передается осмосом (обычно в течение многих лет), и, в-третьих, просто позволяя неспециалистам выполнять экспертную работу до тех пор, пока они не разберутся в ней сами (потенциально допуская ошибки на этом пути, опять же обычно в течение многих лет).
То, что вы делаете, это то, что вы ожидаете, что ваши бизнес-эксперты примут на себя роль профессионального педагога, чтобы соответствовать роли, которую вы приняли как студент.
Но вы неявным образом переводите бизнес-экспертов в этот третий способ обучения, когда они должны научиться (теперь уже сами не являясь экспертами) тому, как стать профессиональными педагогами, проделывая это для себя как можно лучше. Как правило, это не освобождает их от их основной работы.
Если вы обнаружите, что такой подход причиняет вам боль, вы знаете, что врач скажет: «Тогда не делайте этого». Другие ваши альтернативы получению знаний об этих ролях могут включать в себя курс формального обучения с настоящим педагогом или ваш работодатель может посадить вас выполнять эту работу на некоторое время, чтобы набраться опыта (что может, по крайней мере, дать вам общий словарный запас и общий здравый смысл с экспертами, чьи мозги вы пытаетесь ковырять).
Если вы продолжите свой существующий метод, просто задавая вопросы на расстоянии, вы просто должны признать, что это часто будет несколько случайным и разочаровывающим по своей природе из-за несоответствия между ролью, которую вы отводите эксперту, и ролью. воспитателя - и их собственно деловая роль, которая обычно ничем не отличается.
Я обнаружил, что когда я прерываю и прошу разъяснений
Избегайте прерывания. Обычно это грубо, и они говорят «слишком много» только потому, что вы задали неправильный вопрос. Задавайте лучше вопросы.
Вы никогда не должны задавать МСП открытые вопросы, если вы не общаетесь. Обычно есть разные уровни экспертов по теме, начиная от людей в вашем собственном отделе и заканчивая людьми из других отделов/сторонних компаний, поднимаясь вверх до эксперта высшего уровня, с которым вы имеете дело. Избегайте задавать много вопросов эксперту высшего уровня. Сначала получите ответы на как можно больше вопросов от людей более низкого уровня, прежде чем отвечать на те, на которые никто другой не может ответить, человеку высшего уровня. Не принимайте чье-либо время как должное. Иногда они настолько заняты, что могут встретиться с вами только раз в пару недель. Никогда не думайте, что у вас будет возможность занять еще час их времени. Но они будут более восприимчивы, чем более уважительно вы относитесь к их времени, когда имеете дело с ними.
Помните: они являются экспертами в предметной области, а вы (!) являетесь экспертом в области программного обеспечения, которое вы разрабатываете или создаете. (Который может быть разработан для обслуживания пользователей в этой области знаний [которой у вас также нет].)
Более того – «вся причина этого, конечно, в равной степени разделяемая обеими сторонами», имеет очень конкретную цель. Ваша общая(!) цель состоит в том, чтобы добиться «своевременного создания отличной программы». Однако только вы (скажем ...) являетесь «экспертом в предметной области» по конкретной задаче создания программного обеспечения.
— Итак, вы оба здесь.
Сформулируйте большинство вопросов как можно конкретнее с точки зрения того, что ваше программное обеспечение должно делать и/или предоставлять. Возможно, подготовьте несколько сценариев использования («пользовательские истории», как их часто называют в наши дни) для комментариев и предложений.
Я был по обе стороны этой конкретной ситуации, и вот несколько вещей, которые я узнал.
Мое основное эмпирическое правило заключается в том, что на конкретные вопросы можно получить конкретные ответы, а на открытые общие вопросы — открытые общие ответы . Проблема с открытыми вопросами заключается в том, что не очевидно, когда вы на самом деле ответили на весь вопрос. Всегда есть больше, чем вы могли быговорите на эту тему, но в какой-то момент вам кажется, что этого достаточно, и вы перестаете писать. На самом деле это не проблема в разговоре лицом к лицу, потому что вы можете задавать дополнительные вопросы для дальнейшего изучения. Асинхронная связь, такая как электронная почта, значительно усложняет эту задачу. Если вам нужно задать общие, открытые вопросы, лучше сделать это лично или по телефону. Бессвязные ответы обычно являются признаком того, что вопрос изначально не был очень конкретным. Сеть Stack Exchange на самом деле является достойным примером для этого. Подумайте о том, на какие конкретные, сфокусированные вопросы можно быстро получить качественные ответы, а какие на вопросы, которые закрываются как «Слишком общие» или «Не знаете, что вы спрашиваете».
Жаргон, отраслевые аббревиатуры и внутренние кодовые имена всегда являются проблемой. Ваш МСП почти всегда работает с группой людей, у которых есть общие знания, которых нет у вас. Ваш МСП также может совершенно не знать, что эти термины и понятия вам незнакомы или что термин может означать что-то совершенно другое в других контекстах. Обычно я отвечаю следующим сообщением: «Я новичок в вашей команде/компании/индустрии и не знаком с некоторыми из этих терминов. Можете ли вы определить, что означает термин «BFG» в данном контексте?» Это конкретный вопрос, на который следует ответить одним-двумя короткими предложениями. Это также дает понять читателю, что вы, возможно, не понимаете всего их жаргона, и что им следует быть немного осторожнее с будущими сообщениями.
Кроме того, помните, что весь этот процесс симметричен. Вы оба являетесь малым и средним бизнесом с обширными знаниями по интересующей вас теме и лишь поверхностным знакомством с темой другой стороны. Когда вы задаете вопросы о деталях реализации (например, ваш пример «вот несколько способов, которыми я думал о решении этой проблемы»), другой человек, скорее всего, сочтет ваш вопрос таким же запутанным и трудным для понимания, как и вы находите его ответ. Люди, которые не являются программистами, как правило, лучше реагируют, когда вы задаете свой вопрос с точки зрения эскиза или макета графического интерфейса (например, «какой из этих двух интерфейсов выглядит проще в использовании»). Если вы начинаете говорить о вещах слишком далеко за уровнями графического интерфейса, непрограммисты, как правило, либо не понимают вас полностью, либо им все равно. Если какой-то аспект вашего внутреннего устройства действительно требует участия SME для правильной работы, постарайтесь сформулировать вопрос таким образом, чтобы либо свести к минимуму, либо исключить все, что связано с программным обеспечением. Не пытайтесь заставить их «думать о проблеме и/или решении»; они уже сделали это однажды, и их решение состояло в том, чтобы нанять вас. Они хотят отдать на аутсорсинг как можно больше мыслей.
Мне очень нравится приведенный вами пример, и я думаю, что он действительно «ответит» на вопрос. Это не то, что вы ожидали, но они сами не знают "правильно и лаконично ответить". Я мог бы сделать при случае что-то подобное вашим экспертам.
Вы упомянули, что хотите, чтобы рецепторы PGA отображались в виде списка — каждый PGA содержит много данных, так что вот как я думаю отобразить его. Это выглядит нормально для вас?
Вы спрашиваете об управлении интерфейсом. Это может выглядеть как простой вопрос с разделителями. На самом деле, если у них есть четкое представление о том, как должно работать программное обеспечение, это может быть так. Однако...
Нам нужен способ показать рецепторы PGA, поступающие в режиме реального времени.
Им не нужен "список". Их фактическим требованием является каким-то образом показать рецепторы PGA в режиме реального времени.
В настоящее время мы не знаем, откуда они берутся, поэтому было бы неплохо, если бы у нас был список, показывающий каждый из их номеров и информацию.
Хотя список сортов, вероятно, оправдан.
Затем приходит QXT2 и обрабатывает эти цифры.
Здесь они упоминают свой поток
можно у нас есть экран для этого?
что добавляет еще одно требование. Однако важно учитывать, что из этого списка должен быть дополнительный экран.
Прямо сейчас требуется много времени, чтобы ввести все значения P для данных, но я не уверен, как лучше всего это сделать.
Текущая система была создана давным-давно, и с тех пор мы добавили множество различных типов LFG, каждый со своей собственной системой бонго, которую необходимо ввести в отдельную электронную таблицу и загрузить до запуска приложения.
Исторические данные.
Я думаю, что список PGA должен отображаться на главном экране и содержать столько элементов, сколько было загружено из файла.
Некоторая идея, которая может быть мудрой или нет.
Это может быть не лучший способ сделать это, но он будет работать на данный момент. Просто имейте в виду, что система бонго для PGA должна быть в формате .xml, поэтому я не знаю, сколько информации вы хотите отображать для каждого из них.
Несколько полезных советов смешались.
Нам нужно, чтобы каждый из них вычислял значения T с течением времени.
Плюс объяснение данных, которые вам нужно будет обработать с бонго.
На самом деле, я думаю, вы объяснили это довольно хорошо:
это как бы ответило на вопрос, но также открыло много других вопросов, которые могут быть или не быть актуальными
У вас проблема с дизайном. Если бы это было развитие водопада. На ранней стадии будет разработан проект, а затем закреплен на камне. «Здесь есть экран 2.6.4 со списком, полным PGA, и тремя кнопками».
Я думаю, вы работаете с набором неполных требований. Я не уверен, какова ваша точная роль в этом проекте, кто будет отвечать за сбор всех реквизитов и их оформление. Если это кто-то другой, вам, возможно, придется передать это ему, чтобы он понял (с помощью вашей команды?), что нужно сделать.
Ответ эксперта действительно открывает ряд вопросов (если только они не были известны ранее). Прежде чем набрать строку кода, должен быть дизайн . Для этого может понадобиться симпатичная программа для графического дизайна, карандаш и бумага, или даже полностью в вашей голове, но необходимо понимать, что нужно и (примерно) как это сделать. Возможно, среди всех этих слов что-то разберется само собой, что-то потребует помощи команды разработчиков или экспертов. Я бы, вероятно, встретился с экспертом в предметной области, чтобы рассмотреть этот экран и то, как его спроектировать. Также не редкость, что из полученного там ввода команда разработчиков создает предложение, которое затем возвращается...
Короче говоря, в этом поддельном примере вы сосредоточились на какой-то очень конкретной части, в то время как вокруг нее есть много важных частей, плохо определенных, на которых нужно сосредоточиться в первую очередь.
(обратите внимание, что, наконец, вы сможете ответить на такое электронное письмо, объясняя, как PGA, бонги и LFG помещаются на этом экране)
Здесь много отличных ответов, поэтому я сделаю это кратко, чтобы добавить что-то еще не рассмотренное. Это стратегия, которую я обычно использую в крайнем случае, когда другие методы не работают.
Подготовьте что-то, что, как вы знаете , неправильно. Предпочтительно неправильно в явной форме, специфичной для того, о чем вы хотите спросить. Затем рассмотрите это. Скорее всего, вы получите ответную критику, которая поможет вам.
Опять же, сначала попробуйте другие методы. Но я обнаружил, что некоторые эксперты и капризные лидеры реагируют на этот подход гораздо полезнее, чем на любой другой, и это может стать шагом к более конструктивным отношениям. Да, вам, возможно, придется какое-то время смириться с ощущением, что вы производите впечатление идиота, но очень скоро вы узнаете их мнение, и они уйдут на пенсию или иным образом уйдут, и тогда вы сами узнаете, что это все равно, что отвечать на такие вопросы.
Краткий ответ: если вы можете понять, как это сделать, пожалуйста, сообщите нам всем, потому что разработчики программного обеспечения боролись с этим с самых первых дней существования профессии.
Но при этом несколько полезных советов, которые я могу передать:
Большинство профильных экспертов, с которыми я работал, ОБОЖАЮТ возможность объяснить свою работу. Вы сталкиваетесь с некоторыми, которые придерживаются позиции: «Все должны это знать. Если вы этого не знаете, вы, должно быть, какой-то пускающий слюни идиот». Но большинству нравится считать себя гениями за то, что они овладели этой сложной областью, в которой никто другой не разбирается, и они рады объяснить всю мудрость, которую они приобрели за годы опыта, любому, кто будет слушать.
И когда вы только начинаете работать с новым доменом, это может быть очень удобно для вас. Вы можете найти людей, которые подробно расскажут все о домене.
Но — и вот огромное «но» — они, вероятно, ничего не знают о разработке программного обеспечения. Они ничего не знают о том, как на самом деле работают компьютеры. И поэтому попытка перевести их знания в требования к программному обеспечению — сложный процесс.
Один пример, который я видел снова и снова: я говорю SME: «Хорошо, вы объяснили, что делать в случаях X и Y. Что должен делать компьютер в случае Z».
И он скажет: «О, не беспокойтесь об этом, такого почти никогда не бывает».
А я говорю: «Если этого ПОЧТИ никогда не бывает, значит ли это, что иногда это случается?»
И он говорит: «О, конечно, иногда. Но если это случается, просто сделай что-нибудь разумное».
Такого рода инструкции прекрасно работают, когда вы имеете дело с людьми. Конечно, вы могли бы сказать достаточно умному человеку: «Если деталь выходит из станка, обрезанной неправильно, положите ее в корзину для брака. что вы можете исправить их ". И это было бы хорошо для человека. Но, как я уверен, вы знаете, если вы разработчик программного обеспечения, вы не можете просто сказать компьютеру «сделай что-нибудь разумное» или «сделай все возможное, чтобы это исправить». Вы должны дать конкретные инструкции.
У меня было много разговоров, в которых SME явно раздражались на меня, потому что я продолжал требовать от них подробных инструкций о том, что компьютер должен делать в странных случаях, когда они УЖЕ ГОВОРИЛИ МНЕ, что такие ситуации случаются редко, и компьютер должен просто делать то, что он может справиться с этим правильно.
Точно так же спросите любого автомеханика, как он диагностирует проблему с автомобилем. Очень немногие скажут, что они выполняют тест 1, а затем, в зависимости от результатов, выполняют либо тест 2, либо тест 3 и т. д. Вместо этого они скажут что-то вроде: «Я открываю капот и ищу что-то, что не соответствует действительности». верно." И да, по-человечески, если вы открываете капот машины и видите пар, вырывающийся из протекающего шланга, вы не говорите: «Хорошо, тест №1, проверьте, есть ли искра в цилиндре 1. " Вы переходите прямо к очевидной проблеме. Но, конечно, компьютер так не работает.
Итак, я хочу сказать, что работа разработчика часто состоит в том, чтобы взять расплывчатые заявления малого и среднего бизнеса о «использовании своего интеллекта» и превратить их в конкретные шаги. В какой-то степени я пытаюсь объяснить это малым и средним предприятиям, и иногда они это понимают, а иногда нет. Но обычно я провожу большую часть своего времени, пытаясь уяснить их нечеткие концепции. Например: «Вы говорите: «Посмотрите, что не так». Хорошо. Можете ли вы сказать мне, что может быть не так? Приведите мне несколько примеров. Откуда вы знаете, что это А, а не Б?» И т. д.
Как только вы начинаете прибивать их, вы часто обнаруживаете пробелы. Как я помню, однажды просматривал требования и обнаружил, что они сказали, что делать для местных экспресс-доставок; для дальних, стандартных (не экспресс) отправлений; а на дальние расстояния - экспресс-доставки. Но они никогда не говорили, что делать с местными стандартными поставками, которые, как я полагаю, составляют самую большую группу. Очевидно, МСП просто пропустили общий случай и сразу перешли к особым случаям. Ваша работа как разработчика — выяснить, где находятся дыры, и задать вопросы, чтобы заполнить их.
Как кто-то еще упомянул, обычно более продуктивно собрать предложенное решение и попросить SME выявить недостатки, чем просто задавать открытые вопросы о том, «как мне это решить?» Потому что если бы они знали, как реализовать это на компьютере, ты был бы им не нужен. Если вы дадите им что-то конкретное, они могут сказать: «Ой, подождите, это не сработает, когда фвакбар не работает» или что-то в этом роде. Если вы просто зададите открытый вопрос, они, скорее всего, будут блуждать повсюду.
Сформулируйте список письменных, коротких и по существу вопросов
Я работаю с требованиями от людей, которые, как правило, даже не являются экспертами в предметной области, и часто бывает так, что заказчик не знает, чего он хочет . Даже с экспертами могут возникнуть недоразумения и путаница, поэтому вопросы должны быть краткими и максимально узкими.
Например:
Я видел, как X делает A, но в требованиях говорится, что X должен делать B. Вы предпочитаете, чтобы он делал A или B?
Я заметил, что C, кажется, дает сбои, я могу исправить это с помощью U или J. Я предпочитаю U, но мне интересно, что вы думаете.
Если вы получите в ответ «Я не знаю» или любое выражение замешательства, вы можете принять это за то, что они не знают. Вы можете попытаться найти кого-то другого или, по своему усмотрению, вести заметки о том, почему вы выбрали такой образ действий.
Экспертам очень трудно перевести свои знания в формат компьютеризированного программного обеспечения, поэтому они часто не могут напрямую ответить на какие-либо вопросы, связанные с программным обеспечением, если только вы не сформулируете их.
Закрытые вопросы часто лучше переводятся на двоичный выбор, который делают компьютеры. Открытые более полезны для получения общего обзора.
Если они все еще не понимают, вам, возможно, придется
Используйте аналогии
Поэтому, имея дело с людьми, не разбирающимися в технологиях, я часто пытаюсь упростить вопрос до аналогии.
Я заметил случай, когда человек H не регистрируется в системе из-за программного сбоя XYZ.
Что за глюк XYZ?
Что ж, скажем, человек H входит в систему, и как только он нажимает «Подчиниться», питание мгновенно выходит из строя; человек Н все еще зарегистрирован или все его данные утеряны?
Даже если они неправильно понимают аналогию, вы можете просто адаптировать ее:
Ну перебои с электричеством случаются редко.
Отключение электричества здесь может означать многое, например, кто-то выдернет кабель, ветер сломает кабель, начнется пожар. Пациент Н все еще зарегистрирован или нам нужна система, чтобы справиться с этим?
Вместо того, чтобы говорить «форма может потерять данные из-за сбоя программного обеспечения», что непостижимо для тех, кто не разбирается в технологиях, я преобразовал это в реальный пример того, как данные могут быть физически потеряны аналогичным образом, что обычно предлагает достаточно близкий комментарий или предложение, которое может быть адаптировано к программному обеспечению.
Ваши вопросы и методики должны адаптироваться к конкретному человеку. Забрасывание открытыми вопросами сделает неуверенных еще более неуверенными, и поэтому они часто возвращаются к вещам, которые уже рассказали вам.
Поэтому, чтобы избежать какой-либо неопределенности, дайте им наименьшее количество информации, необходимой для работы.
Главная проблема здесь в том, что вас просят стать бизнес-аналитиком.
Различие между разработчиком и аналитиком существует не просто так. Опрос малых и средних предприятий и превращение их ответов в понятные и полные требования — это задача бизнес-анализа, а не задача разработки программного обеспечения. У них разный набор навыков и разные методы.
Если клиент платит разработчику почасовую ставку за то, чтобы вы искали ответы, которые должны были быть задокументированы (менее дорогим) бизнес-аналитиком еще до того, как вы начали выставлять счет за время, затраченное на проект, клиент плохо обслуживается, а проект рушится. плохо управляемый со стороны вашей команды.
Если в проект не встроена роль бизнес-аналитика — возможно, потому, что номинально это скрам-проект, и вы должны прорабатывать его по мере продвижения — тогда вы должны достаточно тесно сотрудничать с малыми и средними предприятиями, чтобы эти неуклюжие, прерывистые и двусмысленный обмен электронной почтой не является проблемой; вы должны быть в постоянном контакте с ними и иметь множество возможностей постепенно получать разъяснения.
Похоже, что вашей консалтинговой компании не хватает по крайней мере одного уровня коммуникации.
У вас есть руководитель команды/проекта или менеджер проекта? Вот как должен работать поток:
Теперь, когда у вас есть этот рабочий процесс, человек, который является экспертом по проекту, не является клиентом; это руководитель проекта. Менеджер проекта должен иметь представление о том, как должен выглядеть конечный продукт, а также о том, как должна выглядеть каждая промежуточная часть проекта по мере его доставки заказчику, потому что именно они организовали разбиение проекта на небольшие, сдаваемые билеты. Поэтому они должны иметь лучшую картинку; вы должны задать им любой вопрос. Затем, если они не знают, они пойдут к клиенту и попросят разъяснений; ожидается, что SME на стороне клиента сможет передать любые второстепенные соображения, такие как те, которые вы описали, менеджеру проекта гораздо проще, чем они могли бы сделать это разработчику, такому как вы.
DarkCygnus
глубокий64синий