Как я могу побудить коллегу сообщать о проблемах и описывать их, но не предлагать решения?

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

Я добился большого успеха в том, чтобы вести разговор, чтобы достичь моих собственных целей. Моя цель: (1) подтвердить и прояснить проблему (2) уточнить критерии решения (3) проверить подход, ведущий к окончательному ответу

Подтвердить проблему

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

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

• Что вы увидели неправильного/плохого?
• Были ли это данные или способ, которым они были представлены?
• Что вы делали, когда это произошло?
• Что это мешает вам сделать?
• Бывает ли это в другое время? Вы можете сделать это снова? Можете ли вы дать мне шаги, чтобы я мог сделать это снова?
• Что здесь в приоритете? (должно быть несколько согласовано с «что это мешает вам делать?»)

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

Это должно оставаться на правильном пути, но когда вы дойдете до вопроса «что вы пытались сделать?» и «что вы не можете сделать с этой проблемой?» - позвольте ему уйти немного в мир аналитика. Хотя вы не можете решить проблему «по-ихнему», вам нужно решить проблему таким образом, чтобы это работало на них, а это значит, что вам нужно знать больше, чем немного, о том, что они пытаются сделать. Это мягкое пространство — вы можете проводить здесь бесконечное количество времени, и умные люди ОБОЖАЮТ говорить о том, что они делают — так что есть некоторая работа, направляющая разговор на эти темы.

Уточнение требований к решению

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

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

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

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

Как это?

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

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

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

Вывод

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

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

Все дело в том, как вы распределяете вопросы и какие из них задаете.

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

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

(Полное раскрытие — я очень старший аналитик данных.)

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

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

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

Я часто видел, как разработчики проектируют на короткий срок, рассматривая только то, что будет быстрее и проще для меня. При доступе к данным это проигрышная стратегия, потому что плохие данные или плохая производительность базы данных гораздо важнее. Часто разработчики приложений не видят реальных проблем с производительностью и данными, потому что им не нужно создавать отчеты с тысячами записей. Им не нужно объяснять клиенту плохие данные. То, что кажется хорошим решением, когда вы смотрите только на ввод одной записи за раз или извлекаете 15 записей, которые вы хотите отобразить на экране, не является хорошим решением для людей, которым позже придется использовать набор данных who.

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

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

1. Непонимание вашего процесса
2. Путаница в отношении ролей/навыков разных команд и/или членов команды

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

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

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

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

В инструменте отчетности дайте им два поля:

Please Describe The Issue in Detail
[                                         ]

If you desire, please add a suggested fix
[                                         ]

Затем просто игнорируйте второе поле в бэкэнде.

;)

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

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

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

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

Убедитесь, что вы предоставили объяснение решения, которое вы внедрили. Вам не нужно описывать все возможные сценарии, но вы можете упомянуть что-нибудь об их предложениях. Для большинства проблем они должны быть в состоянии понять, почему вы должны были сделать это по-своему. Если нет, то вам придется уточнить.

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

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

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

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

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

2. Инвестируйте в инструменты/методы, которые установят некоторую дистанцию ​​между вами и аналитиками (по крайней мере, JIRA). Расстояние/разъединение способствует некоторой степени инкапсуляции между вовлеченными сторонами. Когда большая часть отслеживания/отчетности о проблемах происходит на форуме, таком как JIRA, IMO, репортер по проблемам сочтет менее удобным подшучивать/обсуждать возможные решения (учитывая правильное определение ролей в системе). Ваша команда может в основном уделять внимание важным элементам любой конкретной JIRA и не обращать внимания на пустые обсуждения.

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

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

Я не считаю, что это полный или лучший ответ, конечно, но он слишком длинный для комментария!

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

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

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

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

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

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

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