Эффективным может быть лишь целостное изменение системы, а не улучшение ее отдельных элементов. (Закон Бира)
Скотт Уилл - менеджер по управлению качеством компании Tivoli Systems Software. Отвечает за несколько программных продуктов, предназначенных для управления системами и сетями. Получил степень магистра делового администрирования в Wayland Baptist University.
Тэд Ривера - менеджер по разработке программных продуктов компании Tivoli Systems Software. Руководит работами по обеспечению качества нескольких групп исполнителей, отвечающих за системные проверки продуктов, их испытания на производительность и масштабность, за комплексные испытания, документальное обеспечение и за возможность применения продуктов в глобальных масштабах. Получил степень магистра теологии в Юго-Восточной баптистской теологической семинарии.
Адам Тейт - менеджер по управлению качеством компании Tivoli Systems Software. Руководит командой, разрабатывающей предложения по развитию и совершенствованию работы компании. Получил степень бакалавра экономики в University of Texas.
Разработанная программа предусматривает посещение компании как уже существующими, так и будущими покупателями, где им гарантируется свободный доступ в лаборатории по проверке разработанных программ. Покупатели имеют возможность с помощью инженеров компании и на ее аппаратах испытать предварительные версии тех программных продуктов, которые их интересуют. Предполагается, что при этом будущие пользователи будут работать с программами так, как они применяли бы их на практике. Основной целью данной программы является повышение уровня удовлетворенности покупателей с одновременной и более полной проверкой разработанных программных продуктов.
Некоторые компании не привлекают своих покупателей к процессу разработки программных продуктов, что служит причиной последующего разочарования производителей доходами от приобретенных программ. Такая ситуация характерна для значительной части сообщества разработчиков программных средств. Но в современных рыночных условиях все большее число компаний начинает осознавать необходимость более внимательного отношения к своим покупателям в целях сохранения своих позиций на рынке. Корпорация IBM имеет значительный опыт заботы о потребителях, особенно заметной в подразделениях, занимающихся сбытом и послепродажным сервисом ее продукции. Тем не менее IBM постоянно ищет пути усиления взаимодействия с покупателями и развития интерактивных подходов к разработке своей продукции.
Интерактивная разработка начинает получать все более широкое распространение в среде создателей программных продуктов. Этот подход обеспечивает разработку программных продуктов с участием конкретных пользователей, которые будут применять их для решения своих специфических задач. При этом разработчики программ посещают заказчиков, проводят интенсивные собеседования с существующими и потенциальными пользователями, после чего создают программы, рассчитанные на конкретного, а не на некоего абстрактного потребителя. Более того, сегодня проектная документация разрабатываемых программ содержит биографические данные их предполагаемых пользователей. Это помогает разработчикам сопротивляться оказываемому на них давлению и не включать в программы разные лишние "штучки", которые не соответствуют их назначению. Теперь разработчик всегда может связаться с будущим пользователем и доказать ему, что, например, элемент программы, на включении которого тот настаивает, будет бесполезен при решении стоящих перед ним задач. Интерактивная разработка способствует также тому, что будущий пользователь лучше понимает проблемы, возникающие в процессе работы. Эти проблемы он может решить с использованием тех программных продуктов, к отработке которых он сам приложил руку.
Итак, интерактивная разработка представляет собой значительный шаг вперед в повышении уровня участия будущего пользователя в создании программных продуктов. Несомненно, уровень удовлетворенности потребителей растет. Но все же одного этого недостаточно. Если не предпринимать никаких других действий, кроме участия пользователя в создании программных продуктов, то ситуация будет подобна той, когда заказчик дома ни разу не видел его до окончания строительства и был ознакомлен только с чертежами.
Возникает вопрос: а как же быть с так называемыми бета-программами2 и им подобными? Разве они не предназначены специально для того, чтобы привлекать заказчиков к участию в завершающих стадиях разработки программных продуктов? Очевидно, что эти программы очень важны, но у них есть свои недостатки. В частности:
- обычно бета-коды устанавливают в лабораторных условиях, а не в условиях полномасштабного производства;
- инженеры компании осуществляют поддержку только тех версий продуктов, которые доступны любым покупателям. Если же у потребителей возникают проблемы с продуктами, снабженными бета-кодами, они вынуждены обращаться к разработчикам и испытателям, чтобы разрешить возникшую ситуацию. Обычно это оказывается затруднительным, если проблема возникает на завершающих стадиях цикла разработки программных продуктов.
Программа вовлечения заказчиков в процесс создания программных средств призвана преодолеть указанные недостатки бета-программ.
Выбор заказчиков
Для того чтобы вовлечение заказчиков в процесс создания программных продуктов приносило максимальный результат, необходимо, чтобы у компании уже существовали установившиеся связи с ее потребителями. Эти связи не обязательно должны быть официально оформлены или долгосрочны. Просто должен быть достигнут некоторый начальный уровень взаимопонимания, позволяющий заказчику чувствовать себя комфортно, принимая предложение компании об участии в разработке заказанной им продукции. Если это программные продукты, при создании которых компания применяет интерактивный подход, то у нее, как правило, уже должен быть в наличии готовый перечень заказчиков. Если же такой подход прежде не использовался, то разработчику следует продумать основные параметры нового продукта, оценить, каких заказчиков могут они заинтересовать, и приступить к общению с ними.
Среди привлекаемых к сотрудничеству покупателей могут быть те, работа с которыми сулит значительные доходы, или те, которые уже используют разработанные компанией программные продукты или интегрированные с ними продукты других компаний. В числе потребителей, которых также полезно делать соучастниками разработки программных продуктов, можно указать:
- недовольных клиентов;
- потребителей, уже знакомых с продуктами компании, использующих заложенный в них потенциал целиком и даже более того;
- потребителей, которые мало знают о продуктах компании и их возможностях для решения деловых проблем. Решая, кого из потребителей следует пригласить в лаборатории компании, необходимо также учитывать, какие цели она ставит перед собой в связи с предлагаемыми программными продуктами. В принятии решений могут оказаться полезными ответы на следующие вопросы:
Предназначен ли продукт для крупного, сложного предприятия?
Требуются ли от пользователя специальные навыки для применения продукта, например, навыки администрирования баз данных?
Будет ли данный продукт сочетаться с другими программами, разработанными компанией или приобретенными на стороне у других поставщиков?
Требуется ли значительная подготовительная работа для установки программы и ее развертывания, или для этого достаточно просто вставить CD в дисковод?
Ищет ли компания пользователей, не требующих поддержки, располагающих собственными грамотными системными администраторами и настройщиками, или она предпочитает пользователей - "мастеров на все руки" типа мелких семейных предприятий?
Какие пользователи получат наибольшие выгоды от интенсивного общения с командой разработчиков продукта?
Какие потребители наиболее выгодны для самой компании?
Следует начинать с малого. Например, посмотреть, какие потенциальные клиенты имеются поблизости, пригласить их провести один день в лабораториях компании, и это уже немало. По крайней мере обходится дешевле, чем оплачивать клиентам из другого города транспортные расходы, гостиницу, обед в хорошем ресторане и нести другие неизбежные в таких случаях расходы.
Предположим, что уже имеется перечень потребителей, выразивших желание сотрудничать с компанией. В таком случае возникает вопрос:
что можно им пообещать?
Необходимо сразу уведомить их о том, что их ожидает напряженная совместная работа. Они могут рассчитывать на ознакомление с проектами документации и использование этой документации при установке, конфигурировании и развертывании программных продуктов. Потребители также ожидают, что у них будет возможность подробно обсудить с разработчиками условия применения продуктов, которыми они располагают, как они намерены его использовать, какими возможностями продукта они воспользуются в первую очередь, а какими - в последнюю и т.д. Если потребители пожелают большего, то разработчики должны иметь свободу для реализации предложений пользователей.
Необходимо помнить о том, что компания приглашает к себе клиентов для знакомства с продуктами, еще находящимися на стадии отработки. Такая работа является эффективным способом непосредственного общения разработчиков, испытателей, высших руководителей, менеджеров по маркетингу и обслуживающего персонала с будущими пользователями. При этом у них возникает возможность получения ценной информации от потребителей, которая играет роль обратной связи, проявить добрую волю по отношению к клиентам и непосредственно повлиять на уровень их удовлетворенности компанией.
Другим способом общения с потребителями является командирование к ним работников компании. Хотя посещение представителями предприятий заказчиков имеет свои положительные стороны, все же визиты пользователей в компанию обладают тем преимуществом, что они общаются со всем персоналом. Безусловно, оплата командировочных расходов двух трех инженеров и, порой, одного менеджера или руководителя обойдется значительно дешевле, чем посылать к потребителю целую команду собственных специалистов. При этом обмен информацией при посещении компании-разработчика будущими пользователями происходит эффективнее, чем при других способах ознакомления с продуктами. Посетители реже отвлекаются на звонки по телефону, вызовы к начальству или обращения к ним коллег, когда они работают вдали от собственных офисов. Они могут уделить общению все свое внимание точно так же, как и работающие с ними представители компании. Они имеют возможность непосредственно задавать интересующие их вопросы инженерам компании и тут же получать на них ответы. Проще выявляются имеющиеся недостатки продукта, а необходимые доработки программ или документации могут быть проведены очень быстро. Посетители имеют возможность проверить, как были устранены дефекты продукта, выявленные при прошлых встречах, и пообщаться с сотрудниками службы сопровождения продуктов компании.
Для того чтобы ожидания клиентов и самой компании были воплощены в жизнь, необходимо не забывать следующие основные правила:
Компания обязана сама оплачивать командировки представителей заказчиков, включая их питание, проживание, транспортные расходы и т.д. Единственным исключением из этого правила является взаимодействие с представителями заказчиков из числа государственных учреждений. Здесь действуют особые правила, и заказчик, и юридическая служба компании должны помочь ей избежать возможных ошибок.
Визит представителей заказчика должен быть рабочим, и компании необходимо предупредить их о том, что им не следует рассчитывать на легкий режим работы, предусматривающий, например, демонстрацию продуктов в десять часов утра, ланч с одиннадцати до часа и посещение гольф-клуба с двух часов дня. Нечто подобное может быть предусмотрено один раз за время командировки, но предполагается, что большую часть времени представители заказчика посвятят напряженной совместной работе.
Необходимо детально продумать, какое оборудование будет использоваться, особенно в тех случаях, когда компания не в состоянии предложить посетителям нечто эквивалентное тому, чем они располагают на своих предприятиях.
Следует изучить, кто конкретно посетит компанию, или заранее уведомить заказчика, кого бы компания предпочла видеть в числе посетителей. Если требуется, чтобы компанию посетили люди, которым предстоит повседневно работать с ее продуктами, а вместо них появятся исполнительный директор компании заказчика со своими помощниками, то при этом неизбежно возникнут определенные проблемы.
Необходимо, чтобы посетители сознавали, что продукты, с которыми им предстоит работать, при всем своем качестве остаются еще не готовыми к реализации. Поэтому они, возможно, обнаружат в них некоторые дефекты, но выявление и устранение этих дефектов является взаимовыгодной для обеих сторон задачей.
Посетители должны быть снабжены детальным планом работ, которые предполагается выполнить за время их визита, перечнями исполнителей, с которыми они будут взаимодействовать, и всем необходимым материально-техническим обеспечением. Все это позволит посетителям лучше донести информацию о выгодах общения с компанией до других сотрудников их организаций.
Должно быть четко определено, предоставления каких материалов следует ожидать посетителям и в какие сроки они им будут предоставлены.
К моменту прибытия представителей заказчика в компанию она должна располагать четким планом работы с ними, ясно устанавливающим, чего она желает достичь в результате совместной работы. Поскольку число возможных ситуаций, определяемых типами программных продуктов компании и видами потребителей ее продукции, может быть весьма большим, то ниже приводятся лишь некоторые рекомендации по составлению таких планов, которые могут оказаться полезными для разработчиков и испытателей программных средств.
Необходимо задаться вопросом, способны ли заказчики привезти с собой данные, полезные для разработчиков. К ним относятся базы данных, конфигурационные файлы, использование которых позволит создать в лаборатории условия, максимально приближенные к тем, что существуют у заказчика.
Следует выявить те области, в которых у пользователей продукта возникают трудности, и предусмотреть в плане их пребывания в компании углубленное рассмотрение этих областей. Пользователи должны будут подтвердить, что в этих областях достигнут прогресс, достаточный для устранения существующих проблем, или указать, над чем еще предстоит поработать.
Компания должна представлять, как заказчики планируют использовать разрабатываемый продукт. Тщательное изучение способов применения продукта пользователями позволит правильнее спланировать будущие испытания продукта. Кроме того, такое изучение представляет собой отличный способ убедиться в том, что дефекты продукта, выявленные при испытательных прогонах, устранены должным образом. Если продукт содержит функции, отсутствовавшие в его прежних версиях, в плане должно быть предусмотрено время на практическое ознакомление пользователей с новыми возможностями продукта. Тем самым будет установлена обратная связь, позволяющая оценить, как используются эти новые функциональные возможности продукта, узнать, что в них нравится пользователям, а что не нравится и какую информацию они пожелают сообщить о них другим пользователям.
Необходимо, чтобы пользователи глубоко проанализировали всю сопроводительную документацию к продукту и указали содержащиеся в ней неточности, неясности или даже прямые ошибки. Своевременное исправление ошибок в документации позволит компании сэкономить средства за счет сокращения обращений пользователей в службу поддержки. Это также повысит уровень удовлетворенности пользователей поставленным продуктом и позволит им быть более самостоятельными в его применении.
Необходимо предусмотреть в плане время для широкого общения представителей заказчика с персоналом компании. Например, в Tivoli принято знакомить посетителей со всеми службами, включая работников отдела маркетинга, планового отдела, с программистами, испытателями и сотрудниками отдела поддержки. Компания предоставляет посетителям возможность обсудить с ее сотрудниками особенности условий применения поставленных ею продуктов, рассказать, что их в этих продуктах удовлетворяет и что не нравится, поучаствовать в сеансах вопросов и ответов. Подобные встречи дают возможность всем сотрудникам компании непосредственно пообщаться с пользователями ее продуктов и доказывают им заинтересованное отношение со стороны компании Tivoli и корпорации IBM в целом.
Необходимо добиться того, чтобы менеджеры среднего звена и высшие руководители компании нашли время пообщаться с представителями заказчиков и поблагодарить их за совместную работу. По возможности в неформальных встречах должно участвовать как можно большее число менеджеров компании. Это нужно для того, чтобы заказчики имели возможность обсудить проблемы, решение которых относится к более высокому уровню компетенции исполнителей.
Итак, взаимодействие разработчиков программных продуктов с пользователями в процессе создания новых проектов может происходить в форме интерактивной разработки, бета-программирования и вовлечения пользователей в процесс создания и проверок нового программного продукта. Если опять обратиться к аналогии со строительством нового дома, то интерактивное проектирование можно уподобить обсуждению проекта нового дома, которое проектировщик проводит с заказчиком, пользуясь чертежами. Бета-программирование напоминает тот случай, когда строительная компания регулярно, например раз в месяц, высылает заказчику по электронной почте видеозапись хода строительства, а тот имеет возможность высказывать свои замечания на основании увиденного. Вовлечение же заказчика в процесс создания нужного ему продукта подобно регулярному его присутствию на строительной площадке, где он имеет возможность прямо и непосредственно высказать свои замечания и пожелания проектировщику и строителям.
-------------------------------------------
Компания Tivoli Systems Software является отделением корпорации IBM.
Бета-программа - ознакомительная версия программы.
По материалам журнала "Quality Progress", ноябрь 2003
Опубликовано в Журнал "Европейское качество"
quality.eup.ru - один из самых старых в рунете ресурсов, посвященных менеджменту качества во всем его разнообразии.
Нам более 7 лет, и все это время ресурс пополняется новыми и новыми материалами, почти ежедневно. Если вы ищете информацию о менеджменте вообще и управлении качеством в частности, скорее всего, вы найдете эту информацию здесь.
Кроме отличной и действительно большой подборки статей, действует живой форум по менеджменту качества.
Добавить в "Избранное"