СТАТЬЯ

06.12.02

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

© Дин Леффингвелл (Dean Leffingwell )
Переведено БНТП по заказу Interface Ltd.

• Роль менеджера по продукту
  
• Основные действия менеджера по продукту
  
  • Как создаётся представление
    
  • Маршрутная карта продукта
    
  • Определение общего плана продукта
    
  • Участие в разработке модели сценариев использования
    
  • Тестирование концепции продукта
    
• Как не испортить впечатление пользователя
  
  • Определение коммерческих условий
    
  • Позиционирование и формулирование посылов
    
  • Помощь сотрудникам
    
  • Название и эмблема продукта
    
  • Материалы для обучения конечных пользователей
    
  • Демонстрация продукта
    
  • Обеспечение сбыта и маркетинга
    
• Большая работа, большие результаты
  

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

Чтобы группы разработчиков гарантированно выдавали хорошее программное обеспечение (ПО), многие компании применяют такие стандартные процессы как Rational Unified Process (RUP) компании Rational Software, который представляет собой полный набор лучших в отрасли методов и правил по разработке приложений. Применяя сценарии использования (иногда называемые прецедентами) и другие методы выявления требований, процесс RUP помогает группам разработчиков понимать потребности пользователей и создавать нужное рынку ПО. Комплексные методы создания архитектуры, проектирования, написания и тестирования программ также помогают разработчикам правильно создавать правильное ПО, обеспечивать надёжность, масштабируемость и приспособляемость решения к изменяющимся потребностям клиентов.

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

Роль менеджера по продукту

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

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

Рис. 1. Формула успеха менеджера по продукту

Основные действия менеджера по продукту

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

Участник процесса Rational Unified Process (RUP) играет в разработке ПО назначенную ему роль по правилам, которые определяют его действия и те артефакты, которые он должен создать на пути к успеху. Если распространить RUP на роль менеджера по продукту, получится нечто подобное тому, что изображено на рис. 2. Далее мы кратко обсудим все эти действия, чтобы лучше понять роль группы или отдельного лица.

Рис. 2. Действия менеджера по продукту, выраженные в конструкциях RUP1

Как создаётся представление

Как однажды сказал бывший президент США, "правильное представление" - не такая уж легкая вещь. Очевидно, вы должны его иметь, но как его получить? Представление о продукте является не исходной, а заключительной информацией, которая вырабатывается в процессе синтеза в единое целое требований, ограничений, необычных идей и технологических возможностей. Источники данных на входе процесса показаны на рис. 3.

Рис. 3. Исходные данные, на основе которых вырабатывается представление о продукте

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

Маршрутная карта продукта

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

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

Рис. 4. Простая маршрутная карта продукта

Определение общего плана продукта

Мы описали роль, которую менеджер по продукту играет в разработке и ведении документа с изложением представления о продукте и маршрутной карты. Хотя представление о продукте излагается всесторонне, этот документ может быть небольшим. Очень важно уметь удерживать объем документа в пределах двадцати-сорока страниц, потому что заинтересованные лица вряд ли прочтут и поймут документ большего объёма. Но как бы полно ни было представление о продукте, такой документ недостаточен для полного определения всего решения по продукту, о котором упоминалось ранее. Общее решение включает сам продукт и все, что к нему относится, всё, что позволяет людям успешно им использоваться.

Вот некоторые наводящие вопросы:

• Какие услуги ваша компания будет предоставлять клиентам, чтобы помочь им успешно пользоваться вашим продуктом?
  
• Какую роль будет играть ваша служба поддержки клиентов в обеспечении успешного использования вашего продукта?
  
• Существует только одна конфигурация продукта, либо доступны несколько конфигураций его приобретения?
  
• Автономен ли ваш продукт, либо клиентам понадобится приобрести к нему программное обеспечение другой компании?
  
• Требуется ли для вашего продукта особое оборудование, высокоскоростные линии связи, защищённый доступ и прочие подобные ресурсы?
  
• Какую цену клиенты готовы платить за ваш продукт, в какие сроки?

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

• Сам продукт.
  
• Сопутствующие услуги и поддержка.
  
• Коммерческие условия, определяющие отношения между вами и клиентами.
  
• Документация к продукту, которая должна помочь клиентам добиться успеха.

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

Рис. 5. Шаблон для подготовки общего плана по продукту

Участие в разработке модели сценариев использования

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

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

Тестирование концепции продукта

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

Таблица 1. Тестирование концепции продукта

Как не испортить впечатление пользователя

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

Таблица 2. Артефакты, влияющие на мнение пользователей

Определение коммерческих условий

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

Таб. З. Коммерческие условия и роль менеджера по продукту

Позиционирование и формулирование посылов

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

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

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

Джефри Мур (Geoffrey Moore)2 рекомендует в качестве отправной точки следующий организационный метод.

Если Вы и ваши коллеги совместно выработаете такую постановку цели, то вам будет легче построить основательную платформу посылов.

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

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

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

Помощь сотрудникам

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

Название и эмблема продукта

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

Материалы для обучения конечных пользователей

В большинстве приложений применяется тот или иной новый метод. Будь то процесс перевода продукта на другие языки, новый метод объектно-ориентированного проектирования или работы завода с сокращённым запасом, вероятнее всего пользователям придётся освоить как метод, так и продукт. Предпосылкой успеха продукта является компетентность пользователей, поэтому менеджер по продукту должен помогать советами разработчикам материалов для обучения пользователей, а, кроме того, может участвовать в поиске и привлечении специалистов в предметной области.

Демонстрация продукта

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

Обеспечение сбыта и маркетинга

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

Большая работа, большие результаты

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

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

Примечания

1 Этот рисунок разработан автором и не является официальной частью RUP.

2 Geoffrey A Moore, Crossing the Chasm: Marketing and Selling Technology Products to Mainstream Customers (Джефри Ф. Мур, Преодоление пропасти: маркетинг и технология сбыта для основных клиентов). HarperCollins, 1991.

Дополнительная информация

• Подробнее о Rational Unified Process
  
• Статьи по программным продуктам Rational Software
  
• Консалтинг по использованию продуктов Rational и технологии создания ИС
  
• Учебные курсы по продуктам Rational Software
  
• Приобретение продуктов Rational Software в электронном магазине ITshop.ru

За дополнительной информацией обращайтесь в компанию Interface Ltd.

Обсудить на форуме Borland

INTERFACE Ltd. Телефон/Факс: +7 (495) 925-0049 Отправить E-Mail http://www.interface.ru

Ваши замечания и предложения отправляйте редактору По техническим вопросам обращайтесь к вебмастеру Дата публикации: 06.12.02