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

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

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

В этот момент нам на помощь придет метод проведения JAD-сессий.

Что такое JAD? Это аббревиатура от Joint Application Development. И в русскоязычных источниках чаще всего фигурирует под видом термина «совместная разработка приложений». Что подразумевается под этим термином? Под ним подразумевается проведение серии совещаний, в которых участвуют как представители заказчика, так и представители разработчика.

Что такое JAD-сессия? Это единичное совещание, посвященной совместной разработке приложений, как самостоятельное, так и являющееся одним из серии таких совещаний.

Немного истории

Отправной точкой использования JAD-сессий была мысль о том, что для успешного внедрения программного обеспечения следует сделать так, чтобы будущие пользователи были вовлечены в работу еще на стадии его разработки. Впервые этот подход был применен Арни Линдом в середине 1970-х годов: пилотный проект был предложен правительству провинции Саскачеван для организации неотложной помощи. В разработке приняли участие медсестры и администраторы неотложной помощи. Проект включил в себя недельную серию JAD-сессий, после обработки результатов которых, процесс написания кода занял меньше месяца. По сравнению с традиционными, на тот момент, 18 месяцами разработки, такие сроки были просто революцией. После внедрения пилотного проекта корпорация IBM способствовала развитию и использованию методологии JAD.

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

Для чего используются сессии JAD? Для того, чтобы специалисты взаимодействовали с будущими пользователями системы наилучшим способом, а разработанные решения – действительно работали и соответствовали особенностям деятельности именно этой компании.

Цель проведения JAD-сессий это определение границ проекта, разработка решения и контроль проекта до его завершения совместно с будущими пользователями системы.

Как именно проводить JAD-сессии

Главные рекомендации по проведению сессий касаются того, как правильно их организовать.

Все, что относится к проведению JAD-сессий основано на таких простых постулатах:

1. Наилучшее представление о работе имеют люди, которые непосредственно выполняют эту работу.

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

3. Возможность совместной партнерской работы первых и вторых дает оптимальный результат.

4. Бизнес-процессы могут охватывать работу не только одного участка работы (отдела), но и смежные. Это должно находить отражение в информационных системах и, соответственно, в составе участников сессий.

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

При проведении JAD-сессий участников рекомендуется разделить, в соответствии с ролями.

Основные роли во время проведения JAD-сессий:

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

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

Ведущий — человек, который проводит встречу и управляет обсуждением (иногда роль ведущего называется «модератор»). Ведущий должен понимать значение проекта для организации, обладать основательным знанием предметной области проекта (при этом может не обладать глубокими знаниями в разработке ПО). Он должен быть объективным, чувствительным к проблемам и настроениям внутри группы, способным разговорить и узнать мнение самых молчаливых членов группы, при этом не позволяя одному или нескольким участникам доминировать в обсуждении.

Секретарь — человек, который фиксирует ход JAD-сессии, составляет протоколы, подтверждает их у представителей Клиента, и, при необходимости, редактирует.

Разработчики — это системные аналитики, бизнес-аналитики и другие члены проектной бригады. Эти участники почти не принимают участие в обсуждении — они присутствуют на совещании для понимания фактического положения дел.

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

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

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

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