Лучшие практики вовлечения клиентов в Agile-разработку?[закрыто]

https://stackoverflow.com/questions/535314

22-08-2019
|

Вопрос

Нам необходимо вовлекать наших партнеров по развитию клиентов в процесс разработки.Мы более или менее следуем методологиям Agile.Некоторые партнеры-клиенты находятся удаленно, другие — ближе.Нам необходимо минимизировать транспортные расходы.

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

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

Решение

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

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

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

Другие советы

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

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

У клиента есть два важнейших обязательства в отношении Agile:

готовы оперативно ответить на вопросы
не менять свое мнение/приоритеты во время итерации

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

Нижняя граница:без обязательств перед клиентами, гибкий не будет работать.

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

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

Всего несколько идей:

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

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

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

Вы рассматривали что-то вроде Войти.

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

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

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

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

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

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

Удивительно, какие положительные отзывы вы можете получить от клиентов, когда привлекаете их.

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

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

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

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

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

Как долго длятся ваши итерации?Насколько сложно планировать итерации?Может быть, проще пойти на более длительные итерации и реже планировать больше, или сократить продолжительность итерации и перейти к меньшим, но более частым сеансам планирования?Участвуют более одного клиента

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

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

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

Я давно не заглядывал в него, но, учитывая, что в списке авторов есть Бек и Фаулер, в нем должно быть что-то полезное. Планирование экстремального программирования.

На своей предыдущей должности @drchrono.com я собирал данные/обратную связь/запросы на итерацию от 20 000 врачей со всей страны.Лучший способ сделать это — пропагандировать такой сайт, как uservoice.com.Я проводил «ежедневные онлайн-демонстрации» с участием иногда от 50 до 100 врачей (врачи регистрировались прямо с нашего сайта).В этих демонстрациях я демонстрировал наш текущий продукт и пропагандировал мнение пользователей, чтобы превратить их отзывы в полезный инструмент для нашей команды разработчиков.Все это было сделано удаленно и привело к общему увеличению регулярного роста доходов на 1400%.

Лицензировано под: CC-BY-SA с атрибуция

Не связан с StackOverflow