Демонстрации: ахиллесова пята гибкой разработки

Сторонники Agile-разработки рекомендует проводить частые демонстрации - например, после каждого этапа разработки или шага - которые гарантируют соответствие хода разработки пожеланиям заказчиков.[1] Проблема здесь в том, что рекомендации по гибкой разработке не конкретизируют методы проведения демонстраций, объем работ, связанных с подготовкой и проведением демонстраций, и не указывают аудиторию, которой они должны быть представлены. Но еще хуже то, что эти рекомендации исходят из предположения, что программа разрабатывается для одного заказчика или одной организации. А что если вы разрабатываете программу для коммерческого распространения или для крупной и сложной организации с широким диапазоном подчас даже конкурирующих интересов?

Несмотря на утверждение Манифеста гибкой разработки, что мы ставим "сотрудничество с заказчиком выше условий договора", откровенно говоря, многие группы гибкой разработки куда меньше контактируют с заказчиком, чем должны бы.[2]

Какие же рекомендации даются по демонстрации гибких проектов? Почти никаких. Например, на многие подобные вопросы в сообществе Scrum отвечают фразой: "на усмотрение команды". Но как быть, если у вас многочисленная команда или она состоит из нескольких групп, либо и то, и другое? Как такая команда может принять решение об эффективном способе демонстрации или, что еще важнее, как собрать поступающие отзывы? Сообщество XP отстаивает понятие "местного заказчика". Интересно, что хорошего выйдет из того, что пользователи будут месяцами жить бок о бок с командой разработчиков? Предположим даже, что вы отыщите таких энтузиастов, но сможет ли местный заказчик представлять интересы всех других заказчиков, приобретающих коммерческую программу, или широкие противоречивые интересы большой и сложной организации?

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

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

В этой статье я подробно остановлюсь на каждом из этих вопросов.

Кто мой заказчик?

Этот вопрос может показаться глупым. Тем не менее, он очень важен, поскольку не все заказчики одинаковы - существуют разные категории заказчиков, и это нужно учитывать. И более того, поскольку вас интересует мнение не одних лишь заказчиков (в чем нас пытается убедить Манифест гибкой разработки), я расширю это понятие до группы заинтересованных лиц . Заинтересованных лиц можно разделить на четыре категории, которые я и буду использовать в дальнейшем:[3]

• Директора - люди, которые готовы платить за вашу программу для достижения определенных коммерческих целей и которые, вероятно, оказывают решающее влияние на принятие решения о покупке.
• Конечные пользователи - люди, которые будут пользоваться вашей программой для выполнения части или даже всей своей работы.
• Партнеры - люди, которые будут пользоваться вашей программой, чтобы помочь другим в достижении их коммерческих целей. Примером таких партнеров могут быть деловые партнеры (например, выполняющие установку, сопровождение или развертывание вашей программы на территории заказчика) или, например, ИТ-отдел некоторого заказчика. ИТ-отдел, скорее всего, не будет покупать вашу программу и даже не будет ею пользоваться, но он будет способствовать ее успешному запуску, чтобы ею могли воспользоваться конечные пользователи.
• Посвященные лица - люди, работающие в вашей собственной организации и имеющие мнение о том, какой должна быть эта программа. Это могут быть представители отдела продаж, маркетологи, управленцы, штатные и прочие разработчики - в общем, все, с кем вы работаете и кто имеет собственное мнение о том, каким должен быть ваш продукт или как его создавать.

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

Как я собираюсь получать отзывы на демонстрации?

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

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

Дифференциация отзывов заинтересованных лиц

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

Рисунок 1: Интервалы получения отзывов в ходе исполнения проекта

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

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

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

• По завершению этапа 3 мы должны провести демонстрацию перед деловыми партнерами. Особенно это важно для разработчиков коммерческих программ, поскольку деловые партнеры могут помочь в продаже, развертывании, диагностике, настройке программы и в обучении пользователей. В результате, мнение таких партнеров зачастую подкрепляется отзывами многих пользователей вашего ПО, и его трудно переоценить. Более того, если не учесть мнения таких партнеров, это может подтолкнуть их к сотрудничеству с другими поставщиками, с которыми они достигнут большего взаимопонимания. Учитывая важность удовлетворения деловых партнеров для поддержания собственных потоков прибыли, такие демонстрации не просто желательны, но и необходимы. К сожалению, такие демонстрации организуются слишком редко.⁵

• По завершению этапа 4, безусловно, необходимо и уместно продемонстрировать программу конечным пользователям. Многие команды гибкой разработки исходят из неверного предположения о том, что эта демонстрация заключается в отправке программы одному или нескольким заказчикам, которые должны ее установить и затем высказать разработчикам свое мнение (подобно бета-тестированию). И хотя для некоторых команд частый выпуск бета-версий может оказаться полезным, и такой вариант тоже должен рассматриваться, можно провести онлайновую демонстрацию с участием одного или нескольких конечных пользователей через Web-конференцию или иной интерактивный Web-инструмент, что позволит получать отзывы в ходе диалога между разными конечными пользователями. Зачастую, в ходе таких демонстраций конечные пользователи будут "корректировать" крайние мнения о том, что должно быть в проекте и как должна работать та или иная функция.[6]

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

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

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

Принятие решений по отзывам заинтересованных лиц

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

Рисунок 2: Интервалы получения отзывов по идеализированному проекту

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

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

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

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

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

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

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

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

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

• В ходе трансплантационной проверки объекты клиента трансплантируются в вашу испытательную среду в попытке наилучшим образом моделировать использование клиентами вашей программы. На первый взгляд может показаться, что этот процесс сложен и запутан. Но, с другой стороны, учтите "следы", которые может оставить ваша программа в системе клиента: файлы настроек, журналы, массивы данных, конфигурационные файлы, остаточные файлы - всего и не перечислишь. А что вы скажете о производительности вашей программы в среде клиента? Существуют ли периоды пиковой нагрузки? Какие потоки входят в вашу систему и выходят из нее? Чем точнее вы смоделируете рабочую среду своих клиентов, тем больше информации вы получите о реальном способе применения вашей программы.

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

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

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

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

Мысли на прощание

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

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

1. Для некоторых термин "Agilista", то есть сторонник гибкого подхода, имеет негативный оттенок. Я же считаю, что это призыв к действию, и с гордостью ношу его как титул.
2. Манифест гибкой разработки можно найти на сайте http://agilemanifesto.org/.
3. Эти категории предложены Карлом Кесслером (Carl Kessler) и Джоном Свейтзером (John Sweitzer) в книге Outside-in Software Development ("Разработка программ изнутри и снаружи") (Аппер Садл Ривер, Нью-Джерси: IBM Press/Pearson, 2008 г.). Кроме того, интересное мнение высказал Скот Селхорст (Scott Sehlhorst) в статье http://tynerblain.com/blog/2007/10/11/stakeholder-goals/.
4. Эта иллюстрация позаимствована из книги Outside-in Software Development и использована с позволения авторов.
5. Не забывайте, что категория партнеры шире, чем просто деловые партнеры. Сотрудники ИТ-отдела, которые заняты развертыванием вашей программы, определенно могут считаться партнерами - они не покупают программу, но вынуждены ее устанавливать, настраивать, сопровождать, обновлять и т.д., так же, как это делал бы деловой партнер. Следует также отметить, что многие организации уже заключили юридические соглашения с деловыми партнерами, что тоже потенциально может предотвратить проблемы с интеллектуальной собственностью, которые могут возникнуть во время других демонстраций.
6. Обратите внимание, что демонстрации конечным пользователям могут потребовать заключения юридических соглашений об интеллектуальной собственности. Если вам кажется, что в этом примере я уделяю слишком много внимания юридическим казусам, не забывайте, что вы можете утратить всю интеллектуальную собственность, проводя демонстрации за пределами своей компании без принятия соответствующих мер предосторожности.
7. Я уже писал и говорил об этих трех подходах, разработанных совместно с сотрудниками IBM® Адамом Тейтом (Adam Tate) и Скотом Уиллом (Scott Will), в нескольких статьях и на разных конференциях. Совсем недавно эти подходы были описаны и дополнены Карлом Кесслером (Carl Kessler) и Джоном Свейтзером (John Sweitzer) в вышеупомянутой книге Outside-in Software Development .