2009-02-11 3 views
4

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

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

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

+0

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

ответ

4

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

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

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

1

Просто несколько идей:

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

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

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

+0

Ничего страшного в том, чтобы поставить некоторый код мониторинга в прототипе, пока вы говорите пользователям. –

+0

Код мониторинга не говорит вам всего о том, как они используют программу, но дает вам достаточно ограниченный обзор конкретной телеметрии. – Uri

+0

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

1

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

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

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

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

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

1

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

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

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

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

6

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

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

клиент имеет два важных обязательства по проворным:

  1. доступные отвечать на вопросы своевременно
  2. не передумают/приоритеты во время итерации

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

Итог: без обязательства клиента, проворный не будет работать.

+0

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

1

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

3

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

3

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

1

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

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

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

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

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

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

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

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

0

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

 Смежные вопросы

  • Нет связанных вопросов^_^