 | Уровень сложности: простой IBM developerWorks, IBM developerWorks, IBM
04.2008 Полное руководство по внедрению
Формирование и поддержание обратной связи с клиентами
Какова финансовая выгода от обратной связи с клиентом? Потратить месяцы или
годы на создание продукта, потратить большую часть этого времени на планирование внедрения, торжественно выпустить продукт – и все это только для того, чтобы в ответ на наше добро клиенты, один за другим, присылали нам замечания, жалобы и предложения для следующей версии. Если бы не клиенты, жить было бы гораздо проще, правда?
А вот и нет. Ничего подобного. Клиенты – единственная причина существования компании. Так как же соединить их требования и реальный опыт в процессе создания продукта? Возможно, ваши клиенты относятся к вашей же компании.
Независимо от этого ваша способность удовлетворять их запросы не менее важна, чем удовлетворение запросов внешних клиентов.
Многие из нас могут рассказать слишком уж знакомую историю об одиноком менеджере проекта, который сидит у клиента на другом конце страны и ждет, пока ему позвонит поставщик программного обеспечения, чье приложение интегрировано в созданную систему, и при этом должен отвечать на вопросы клиента о функции, которая не работает, как это описано в документации. Пока менеджер проекта ждет телефонного звонка, его мысли блуждают, и он начинает представлять себе некую технологию телепортации, которая позволила бы ему пробраться по
телефонным проводам и отвесить оплеуху тому, кто имел наглость сказать «ну… мы здесь, кажется, не можем воспроизвести проблему. А ты не мог бы сказать еще раз, в чем она заключается?».
Как часто мы слышим подобные ответы от наших ИТ-отделов или какого-нибудь сотрудника службы технической поддержки? Полное непонимание того, с чем сталкивается выездная группа поддержки и клиент.
Итак, поставщик, наконец, позвонил менеджеру проекта и дал вполне ожидаемый ответ: «Не могли бы вы помочь нам уяснить проблему? Что хочет сделать ваш пользователь? Мы не можем воспроизвести проблему и нам нужно больше
информации». После тяжелого перелета из Калифорнии на восточное побережье с последующим шестичасовым обучением пользователей и питанием плохо разогретой пищей из фастфуда наш менеджер проекта оказывается на грани срыва.
И менеджер проекта, и поставщик старались рассматривать проблему логически? но, очевидно, с разных точек зрения. Поставщик мог мыслить следующим образом: «Просто дайте мне больше информации, и я запущу несколько тестовых скриптов. Мы постараемся выяснить, что происходит». С другой стороны, менеджер проекта думает так: «Если он вообще не понимает, в чем проблема, как он может говорить, что не может ее воспроизвести? Какую проблему он пытается решить?».
Именно здесь лежит основной разрыв между клиентами, компаниями, которые предоставляют им услуги, и организациями, входящими в цепь поставщиков. Идет кажущееся бесконечным переругивание между менеджерами по продуктам,
разработчиками и вовлеченными в этот процесс сотрудниками, и все пытаются определить, что точно нужно клиенту, и что команда разработки может ему предложить. Большинство из нас предполагает, что есть какой-то «процесс» обработки информации, передаваемой между разными организациями, вовлеченными в цепь поддержки. Однако в большинстве компаний такой «процесс» – это просто
электронное письмо или отчаянный телефонный звонок в службу поддержки.
Глаза рекомендуется защищать
И, конечно, такой знакомый всем сценарий запускает эффект домино.
Случайное электронное письмо или звонок в службу поддержки редко дает клиенту возможность почувствовать себя услышанным. Клиент, который считает, что его сообщение не получило достаточного внимания, часто общается еще с одним-двумя сотрудниками компании. В некоторых случаях специалист по продажам может ввести запрос клиента в базу средства слежения за ошибками/усовершенствованиями, и это же могут сделать другие люди, с которыми общается клиент (например, представитель отдела сервисного обслуживания). Специалисты из
группы контроля качества видят два запроса, поступившие от двух разных людей и заставляют команду разработки отреагировать на оба.
Конечно, эти запросы выглядят сходным образом, но, в конечном счете, хотя они поступили от одного клиента, они обозначаются как две разных проблемы. Тем временем специалист по продажам обсуждает проблему с менеджером по продуктам и со своим другом из
отдела сервисного обслуживания, а тот представитель отдела сервисного обслуживания, который общался непосредственно с клиентом, делится этой информацией со вторым менеджером по продуктам (вы еще не запутались?)
Поскольку все эти взгляды на проблему сформированы в ходе разных обсуждений, теперь специалист по продажам, два сотрудника отдела сервисного обслуживания и менеджеры по продуктам имеют разное представление о проблеме.
Один из менеджеров по продуктам добавляет данную проблему в план следующего обзорного семинара, а второй менеджер по продуктам направляется прямо к разработчикам и обсуждает с ними краткосрочное решение этой проблемы. На основе этого обсуждения разработчики добавляют небольшое исправление в план будущего выпуска. Три дня спустя специалист по продажам входит в систему управления ошибками/усовершенствованиями и ищет там обновление. Не найдя обновления, он обращается к кому-нибудь из группы контроля качества, которые
отсылают его к разработчикам, от которых он узнает, что исправление вносится в очередной выпуск. Затем он звонит клиенту и сообщает ему хорошие новости.
Через неделю выпуск подготовлен, еще через две недели группа контроля качества утверждает новую версию и клиент, наконец, входит в новую систему. И обнаруживает, что проблема, о которой он сообщал, все еще здесь.
Ой!
Ладно, данная ситуация во многом драматизирована, но проблема плохого взаимодействия между различными уровнями компании весьма реальна. Некоторые прекрасные, неплохо организованные команды попадались в эту ловушку. Совершенно понятно, что чтобы избежать этого, необходима автоматизация.
Это просто инструменты
Вода течет по пути наименьшего сопротивления. Наш опыт говорит, что это относится и к взаимодействию между группами, работающими с клиентами, и командами разработчиков. Мы все не любим признавать это, но когда дело доходит
до решения сложных программных проблем или реакции на подробный запрос клиента на добавление функциональности, разработчики обычно делают все от них зависящее, чтобы поскорее сплавить продукт подальше, даже если это означает игнорирование конкретных запросов клиента с осознанием того, что к этим проблемам придется возвращаться позже. С финансовой точки зрения такое решение весьма рискованно. Соблюдение графика разработки и обратная связь с клиентами (с доведением до клиентов информации) не должны быть взаимоисключающими вещами.
Ключ к решению данной проблемы – это знание. Знание приходит от понимания первопричины проблемы. Чтобы понять первопричину проблемы, нужно понимать бизнес-прецедент использования, к которому относится выявленная проблема, а для этого необходима хорошая документация и надежная цепь обратной связи между клиентом, группой работы с клиентами и организацией, занятой разработкой программного обеспечения. Ключ – это документация.
Характеристики хорошей документации понятны: она должна быть ясной, четкой, соответствующей продукту и, что наиболее важно, все это должно давать ожидаемые результаты. Данный момент необходимо подчеркнуть: одно дело создать документацию, соответствующую техническим требованиям, но совершенно другое – создать документацию, в которой предвидятся вопросы и предлагаются решения
1
.
Конечно, в Интернете можно найти ряд бесплатных инструментов, и многие компании, у которых много лишнего времени и денег, создали свои собственные решения. Однако мы предлагаем нечто более надежное, чем условно-бесплатные программы и доморощенные версии. Зачем? Например, безопасность. Большинство готовых решений обеспечивают лучший контроль над правами доступа,
ролями, областями ответственности и безопасностью данных. Кроме того, большинство готовых решений имеет разнообразные возможности для интеграции и поддержки.
На рис. 1-1 показано упрощенное решение для выездной группы, взаимодействующей с клиентами и командой конкретного продукта. Документ маркетинговых требований (Marketing Requirements document, MRD), как правило, представляет собой первый вариант регистрации пользовательских бизнес-требований, и он может включать в себя простые диаграммы рабочего процесса и логический
поток данных для основных систем.
Рис. 1-1. Упрощенная модель коммуникации
В любой реализации шаги, которые необходимо предпринять, должны быть очевидны для каждого, кто вовлечен в цепь обратной связи. Повторим, что данная модель является упрощенной, но она поможет вам понять различные варианты, имеющиеся у вас при работе с ClearQuest.
- Шаг 1. Клиент обращается к соответствующему представителю отдела сервисного обслуживания со своей проблемой или предложением. Мы предлагаем обучить всех сотрудников так, чтобы у них вошло в привычку указывать на
ошибку или пользовательское предложение тому члену команды, который имеет доступ к ClearQuest, или же сделать так, чтобы доступ к инструменту
имел тот, кто непосредственно общается с клиентом, чтобы у вас был единый процесс ввода данных обо всех проблемах. Хотя сотрудники организации, повидимому, не будут возражать против перекладывания этой ответственности на кого-то еще, наилучшей стратегией для вас будет снабдить учетной записью каждого сотрудника организации.
- Шаг 2. Представитель заказчика документирует проблему или предложение, вводит информацию в соответствующую систему отслеживания проблем, которая, в свою очередь, автоматически заносит ее в хранилище и получает идентификационный номер. При тесной интеграции между ClearQuest и системой отслеживания проблем (которую обычно использует и поддерживает отдел сервисного
обслуживания), представитель данного отдела может в любое время обратиться к системе и получить информацию о состоянии проблемы. Можно настроить систему отслеживания проблем так, чтобы при каждом редактировании данных о проблеме (через обратную связь) она получала обновление или уведомление по электронной почте, которое можно послать напрямую представителю заказчика.
(Примечание. Хотя немногие компании желают, чтобы представители заказчика имели прямой доступ к системе отслеживания запросов на технические изменения, ClearQuest все же можно применять таким образом).
- Шаг 3. Проблемы отсылаются в отдел контроля качества, а запросы на улучшения отправляются менеджерам по продуктам. Вы не обязаны настраивать систему подобным образом, но в нашей модели мы хотим, чтобы члены команды управления продуктами (отдел исследований и разработки) отвечали за все запросы на улучшения, с той целью, чтобы они были близко знакомы с использованием продукта клиентами.
- Шаг 4. Производится детальный анализ проблемы/улучшения (имеет ли запрос смысл?), квалификация (допустим ли такой запрос?), определение его приоритета (какое место он должен занимать среди текущих задач?) и консолидация
(не было ли уже подобных запросов в системе?). Затем соответствующая информация вносится в ClearQuest, который в данной модели автоматически
уведомляет об этом представителя заказчика, который вводил информацию. Опять же, вы не обязаны настраивать систему так, чтобы она уведомляла представителя заказчика при каждом изменении, но вы, возможно, решите, что
обслуживание заказчика будет осуществляться лучше, если он будет знать обо всех изменениях, связанных с проблемой. Иначе пришлось бы входить в систему по десять раз в день.
- Шаг 5. На основании обновления соответствующая команда разработчиков получает запрос и встраивает его в свое расписание. Команды разработчиков не получают запрос на доработку/исправление пока менеджер продукта или
группа обеспечеия качества не направят его им. Вы найдете такую возможность очень полезной. В предшествующих системах любой подключившийся к системе, включая разработчика или внешнего поставщика, имел доступ к любому запросу на доработку или исправление, венсенному в систему. Но не теперь. Теперь они видят только то, что вы хотите им показать.
- Шаг 6. Подразделение разработчиков совместно с группой обеспечения качества работают над тестированием нового кода. Сборка, тестирование. – Сборка, тестирование.
- Шаг 7. Утвердив изменения, группа обеспечения качества заносит информацию об изменениях в ClearQuest. Еще одно хорошее свойство ClearQuest: работа над проблемой не завершена, пока группа обеспечения качества (и только она одна) не решит, что она завершена.
- Шаг 8. Представитель заказчика уведомляется о том, что работа над проблемой завершена. Хорошо делать это по электронной почте.
- Шаг 9. Представитель заказчика сообщает о завершении работы над проблемой. Как и любой другой инструмент, ClearQuest не может решить все проблемы, но если у вас еще нет подобной системы, вы прекрасно сможете начать с ClearQuest.
Поскольку данный инструмент интегрирован со всей платформой IBM Rational Software Delivery Platform, он является одним из самых мощных инструментов из имеющихся на рынке.
План работы с ClearQuest
Основываясь на нашей простой модели, мы сформируем план для успешной работы с ClearQuest.
-
Поймите, что информация приносит пользу бизнесу. Ваш продукт или услуга – это то, ради чего живет ваш бизнес, а информация от клиентов – кровь в жилах вашего продукта. От того, как вы впишите требования клиента в новую версию, зависит, будет это версия 2 или списанный за ненадобностью продукт.
-
Обучите ваших сотрудников, работающих с клиентами, правильно регистрировать информацию. Станьте проповедником документации в своей команде или компании. Выступайте за фиксацию требований распространеннымипредложениями, а не урезанными фрагментами, которые часто принимают за письменный язык. Убеждайте вашу команду разделять каждую проблему на логические части и тщательно фиксировать шаги, а также ожидаемые результаты. Если вы документируете запрос на внесение улучшений, включите в документацию детальные прецеденты использования, объясняющие, как клиент будет использовать новую функциональность, и объяснения, почему данный запрос
важен. Это имеет большое значение при расстановке приоритетов. Детальное описание переведет проблему в верхнюю часть списка, уж поверьте нам.
-
Автоматизируйте механизм ввода информации. Нам приходилось использовать и доморощенные решения, и бесплатное ПО из Интернета (Bugzilla), но мы предпочитаем ClearQuest, поскольку он имеет больше возможностей и большую гибкость, а также то, что он надежно интегрируется с ClearCase и другими инструментами, используемыми в жизненном цикле разработки.
Внедрите этот инструмент так, чтобы персонал мог легко обращаться к информации и совместно ее использовать. Все должно быть очевидным: войти в систему, определить нужный компонент, установить приоритет информации и оставить информацию. Чем проще все это будет, тем больше вероятность, что это будет использоваться.
-
Сформируйте процесс расшифровки информации. Когда информация есть, что мы с ней будем делать? Одно дело создать автомат для фиксации и документирования информации, полученной от клиента, а совсем другое – заставить команду разработчиков продукта отреагировать, чтобы группа продаж смогла вовремя что-нибудь сообщить клиенту. Сделайте ClearQuest частью ежедневного/еженедельного/ежемесячного процесса обзора проблем и запросов на улучшения. Возложите на какого-нибудь менеджера по продуктам ответственность за поддержание данных в хранилище в актуальном состоянии.
-
Назначайте задания соответствующим техническим руководителям. Команда продукта отреагировала, и соответствующий технический руководитель – либо входящий в вашу внутреннюю команду разработки, либо в стороннюю
организацию, занимающуюся разработкой – автоматически получает уведомление. Фактически для большинства команд управления продуктами это будет серьезным стимулом. Они отчетливо понимают, что чем скорее они отреагируют, тем скорее проблема будет передана разработчику и уйдет из их собственной ответственности. Неплохая мотивация? Теперь не глава группы разработки будет получать уведомления обо всех проблемах, приходящих в команду данного продукта, а система сможет организовывать и распределять работу на основе компонентов, и даже на основе серьезности проблемы.
-
Обновляйте информацию в хранилище на каждом этапе. На каждом этапе разрешения указанных пользователем проблем хранилище обновляется. Представитель клиента имеет доступ к этой информации, и уведомления посылаются автоматически. Это очень важно для чистоты всего процесса: вместо того, чтобы публиковать в организации один отчет за другим, упрощайте, упрощайте и еще раз упрощайте. Используя четко определенный процесс и единый инструмент для управления информацией, вы получаете одну версию истины.
-
Обучайте сотрудников, работающих с клиентами, заходить в систему и сообщать новости клиентам. Каждое утро в понедельник, начиная рабочую неделю, вы знаете, что можете войти в систему и получить информацию о любой проблеме или запросе на улучшение, которые были введены на предыдущей неделе. Сколько возможностей, не правда ли?
Управление проблемами – это центр успешной системы управления конфигурациями программного обеспечения, а ключ к управлению проблемами – это правильное формирование коммуникационных каналов между вашей командой и клиентом.
Целью этой главы было объяснить на общем уровне пользу ClearQuest для бизнеса, и мы надеемся, что этой цели мы достигли. Теперь мы готовы к тому, чтобы погрузиться в данную программу и показать вам, как получить от нее максимум выгоды.
Примечания
1 Christian Buckley and Darren Pulsipher, «Destroying the Tower of Babel: Communication Through
Documentation,» Rose Architect Magazine, January 1999:60–65.
Об авторе | | | команда developerWorks работает над созданием полезных материалов для разработчиков |
Выскажите мнение об этой странице
| |
