Принципы работы с требованиями к ПО. Леффингуэлл (2002) (1186169), страница 38
Текст из файла (страница 38)
нулся с проблемами при управлении требованн<п<и. Когда мы затронули вопрос о лидере про. дукта, в комнате воцарилась тишина Мы спросилн 25 присутствующих, среди которых были разработчики и ружзводнтели отделов проектирования и маркетинга, как в их органиэации принимались эти сложные решения. Выяснилось, что никто не принимал этих решений. То, что описали присутствующие, являлось так называемым "групповыл< нащупыванием", когда предложения прибывают и убывают как волны прилива. Никою не брал на себя ответственность за жесткие реп<ения.
Никто не рев<ал, когда уже стоит остановиться. В конце концов, команда оглядывалась на исполнительного директора по маркетингу, ожидая от него ответов, возможно, потому, что этот человек был наиболее активен. Он сказал: "Вь< знаепи, что больте всего беспокоит меня в этой кол<анде< Я в любое ау<сия могу по. ну<осипян чтобы была добавлена некая новая б>ункция, и ннкпю никогда не скажет мне "нет".
Как же мы можем надва ть<я хоть когда нибудь отгрузип<ь пу<одукп<7'. Из этого заявления можно сделать вывод, что время потрачено, а заказчику все не удается получить готовый продукт. Понятно также, что осознание этого факта для него весьма болезненно. Компания развивалась от традиционных информационных технологий и со временем подошла к предоставлению услуг в интерактивном режиме. Понятие Глава 18. Лидер продукта 187 Организация группы программирования подразделения автоммизации домашнего освещения юмпании О«п«епаюпз, 0б. Эмили, вице-президент и генеральный директор Эрик, директор по юркетингу Брук, директор по разработке Пит, менеджер по рвзраоотке щххрвмм«кжо обеспечения Джек, пи«шоки«ель ~руины осеспечвнш качества Майш системный аркитектор Кэти, менеджер продукта Джон, руководитель группы разработки программного обеспе мнив Русс, руководитель ц«уппи разработки програпеюго обеспечения Майк, рукОВоднтвль группы разработки программного обеспечения Луиза, руководитель отдаю документи- рования Группа тестирования Рюработчики Рыс.
«8.«. Рабочий пример«си«рук«аура иамаидь«, разрабажьиюмжаб иро«раэлмнее обеспечение Как же распределить роли и ответственность в среде с множеством требований, технологий, заказчиков и разработчиковт Представим себе следующий диалог, возникший на ранней стадии работы некой новой органиэации, которая занималась распределением ролей.
Менеджер продукта (лидер)т Меиедикер разработки: Менеджер продукта: Продукт должен иметь функции А,В и С, и вы должны создавать его, используя технологию Х. Я думаю, он должен иметь функцию П, а не С, и основываться на технологии т'. А я говорю, что он должен иметь функции А, В и С. В котще концов, я отвечаю эа достижение квоты сбыта и поэтому должен удовлетвортпь потребности моих клиентов. Если вы хотите отвечать за бизнес- приложения как ярофзмм««ого продухиш являлось новым. Члены команды не имели опы. та, которым могли бы руководствоваться в процессе работы. Хотя не существует единого рецепта выдвижения лидера продукта, возможно, нам удастся кое-что предложить в результате рассмотрения нашего рабочего примера.
В конце концов, мы создавали этот пример, моделируя реальную успешно работающую команду проекта. На рис. 18.1 роль лидера выполняет Кэти. меиедшлу«тфодухша. Залтетилт, что в даннолт случае менеджер продукта отвечает за маркетинг, а не за техническую сторону. Это достаточно типично для компаний, создающих программные продукты, так как, по крайней мере в теории, менеджер продукта ближе всех находится к закаэчику, определяющему конечный успех или неудачу проекта. Более важная причина заключается в том, что именно маркетинг в конечном счете определяет "Итог", т.е.
доход, связанный с выпуском продукта. Так и должно быть, ведь маркетинг отвечает за продажи и, соответствен. но, должен отвечать за принятие трудных рептений. 188 Часть 3. Определение системы результат, вы можете добавить функцию 1), если при этом сщс сможете вписаться в график. Х-м-м (раздумывая о том, что означает дяя него помогать команде в достизяении квоты). Я не уверен, что это хорошая мысль. Мы действительно сделаем А, В и С. Но готовы ли вы отвечать эа то, будет ли программа работать на самом деле? (представляя себе, что в гюсеедуюгяие 48 часов вмесгпо подгтгювхи к выходу на рынок с новым товаром он будет учипгься тому, кан ниюепня нод) Ну что же, вы можете создавать программу, используя любую наиболее подходящую технологию.
Решено. Вы принимаете ренгения о функциях, а мы выбираем технологию; пусть каждый отвечает за то, в чем лучше разбирается. Договорились. Менеджер разработки: Менеджер продукта: Менеджер разработки: Менеджер продукта: Этот сценарий подчинен обычному здравому смыслу, однако зачастую (как и в случае упоминаемого провайдсра интерактивных услуг) по. добнос распределение ответственности произвести пс удастся, В некотором смысле для независимых производителей программного обеспечения (1$Ч) ситуация несколько проще. Клиент является внешним по отношению к организации-разработчику.
Как правило, с) шествуют достаточно серьезные маркетинговые ор~анизации, которые можно привлечь к выявлению требований и определению того, кто бу. дст отвечать за сбалансированность всех конфликтующих потребностей. Клиент, потребности которого не удовлетворяются, просто не будет пРи. обреааеь продукпь Хотя это, может, и не очень хорошо, по по крайней мере клиенты не ~таят нал душой со своими вопросами.
Лидер продукта в отделе информационных технологий и систем (1буу/1Т) В подразделении предприятия, занимающеьюя асс!Т, ситуация совершенно иная. Здесь нет отдела маркетинга, все ваши клиенты работают вместе с вами, и опи неизбежно будут толпиться вокруг после реализации, чтобы сообщить о своих ощущениях. Как искать лидера в такой среде? Давайте снова рассмотрим пример. В одном подрал; дслсцпц разрабатывалась новая система, чтобы обеспечить глобальный кр)тлосуточный доступ к загншям о клиентах для поддержки продаж и управления лицензированием. В процессе анализа проблемы бьии выявлены следующие заиптересованныс стороны: отдел маркетинга корпорации, отдел удаленных продаж, отдел лицензирования и поддержки, отдел маркетинга предприятия, финансовое руководство предприятия, отдел вьщолнсння заказов. Каждый из этих отделов достаточно активно отстаивал свои п<» требности, хотя было ясно, что не все потребности удастся удовлетворить.
Вопрос: "Кто отвечает за документ-концепцию?" имел подтекст, "Кто захочет сделать весьма опасный для карьеры шаг, ввязавшись в управление данным проектом?". Глава 18. Лидер продукта 189 После анализа ситуации стало ясно, что никто из руководителей команды разработчиков не имеет необходимого авторитета для принятия столь сложных решений, но, тем не менее, лидера нужно было назначить. Команда выбрала Трейси, занимавшую долж.
ность руководителя проекта, и уполномочила ее вынвлять и организовывать требования. Она владела документом-концепцией. Кроме того, оиа интервьюировала пользователей, устанавливала их относительные приоритеты и фиксировала данные в функциопазьноориентнрованном формате. Но одновременно был также создан специальный управ. лающий комитет, или совет по контролю за изменениями проекта (рго)ее! сЬапбе соплго! боагд, ССВ). В его состав вошли три представителя руководства, каждый из которых имел свои функциональные обязанности. Сначала Трейси упростила процесс приинтия решений, предложив ССВ задать относительные приоритеты в исходной версии. С этого времени ССВ (и ннмьхо ССг!) имел право добавлять или удалять функции согласно рекомендациям, поступающим от лидера продукта. Таким образом, был только один лидер, Трейси.
Результаты выявления функций и концепция проекта находились в ее голове и в документе-концепции, ио ответственность за трудные решения была передана ССВ. Илсенно ССВ отвечал за принятие жестких решений. Лидер "только" следил, чтобы принятые функции были надлежащим образом проработаны и доведены до команды разработчиков. После того как Трейси была уполномочена вести процесс и был создан принимавший наиболее сложные решения ССВ, в который вошли члены вышестоящего руководства, проект развивался успешно н использовался позднее в качестве организационной модели для новых проектов.