При умении общаться и вести переговоры совместная разработка приложений ведет к согласию между разработчиками и пользователями, а в результате рождается новая система
Страховая компания Provident Mutual Life Insurance (Ньюарк, шт. Делавэр), как и многие другие корпорации, оказалась в свое время в полосе боев, когда дело дошло до разработки приложений. Эксперты из отдела информационных систем (ИС), справившись со сложной средой мэйнфрейма, столкнулись с не слишком грамотными запросами пользовательской общественности. В результате таких столкновений сотрудники ИС часто разрабатывали приложения в вакууме.
Напряжение разрядилось благодаря JAD (Joint Application Development - совместная разработка приложений). И сегодня, спустя десять лет и пятьдесят проектов, страховой гигант может послужить примером мирного сотрудничества пользователей и программистов в процессе создания совершенного приложения. Компания Provident преодолела все препятствия, встающие на пути совместных разработок, в том числе языковой барьер между технологами и бизнесменами, конфликт, создаваемый политиками офиса, и мелкие пакости, творимые склонным к мелочной опеке начальством.
Распределение ролей
Как считает Дениз Сильвер, менеджер компании по бизнес-системам, один из важнейших уроков, которые Provident сумела извлечь из своего опыта, - это ограничение числа наблюдателей и четкое распределение ролей. “Один из наших первых проектов относился к приведению в порядок имущества обанкротившихся фирм, и в него оказался вовлечен менеджер по информатизации. А команда JAD может заехать бог знает куда, если в ее работу вмешиваются наблюдатели, у которых нет определенных обязанностей”, - сказала она.
Обычная JAD-команда состоит из бизнес-спонсора - руководителя того отдела, в котором приложение будет использоваться, и нескольких руководителей проекта, программистов и конечных пользователей, обычно в соотношении три бизнесмена и один техник. В идеальной команде совместной разработки должно быть не более 15 человек.
Спонсор может принимать, а может и не принимать реальное участие во встречах команды совместной разработки, но он открыто поддерживает проект, распределяет время участников и выносит окончательные решения. Руководит проектом и ведет заседания (на них письменно документируются принятые решения) нейтральный координатор (facilitator) либо из служащих компании, либо приглашенный извне.
Команда JAD дает “упряжке” разработчиков некоторый каркас, который пользователи впоследствии могут модифицировать для своих целей. “Способ JAD намного лучше традиционных последовательных методов разработки приложений, - считает Дуг Смит, главный финансовый сотрудник консалтинговой компании American Management System (Фэрфакс, шт. Виргиния). - Тут все держатели акций собираются вместе, приходят к согласию и вырабатывают общую точку зрения на дальнейший путь”.
Психотест
При достаточной величине компании руководство проектом совместной разработки часто ложится дополнительным бременем на персонал отдела ИС. Согласно наблюдению Дениз Сильвер из Provident и Джейн Вуд (соавторы книги “Совместная разработка приложений”) над 750 членами группы координаторов, 89 процентов из них отчитываются перед отделом информационных систем, 7 процентов докладывают группе пользователей и оставшиеся 4 процента докладывают группе, независимой как от отдела ИС, так и от пользователей.
Как бы ни называлась их должность, координаторы должны быть обучены своей работе. “Мы обучили около трех дюжин координаторов и присоединились к сообществу координаторов в Хартфорде и Бостоне, - сообщил Рич Д’Адарио, старший аналитик компьютерных систем в компании Prudential Insurance (Холмдел, шт. Нью-Джерси), использовавшей JAD примерно в двух дюжинах проектов. - Координаторы обучаются навыкам консультанта, чтобы помочь отобрать людей для команды и определить, какую работу они лучше всего будут выполнять. Здесь очень много зависит от личностных качеств и очень важна психологическая совместимость”.
Как говорят аналитики, большинства трудностей можно избегнуть при правильном подборе людей. “Бывают настоящие зануды и угрюмые типы, которые не умеют разговаривать с людьми, и таких людей не следует привлекать” - таково мнение Джулии Ханке, директора по корпоративным службам Hurwitz Consulting Group (Ньютон, шт. Массачусетс). “Не следует также привлекать пользователей, не знающих технологии. Нужны люди, открытые новым идеям”, - считает она.
Еще один ключевой момент - подготовка. “Подготовка - это девяносто процентов успеха”, - заявил Билл Барбур, глава консалтинговой группы IBM в Нью-Йорке. Он использует способ JAD с 1984 г. и недавно закончил проект JAD, в котором IBM разрабатывала пакет управления парковкой и движением для Университета штата Огайо. Координатор после общения с участниками и определения их ролей создает для команды черновой вариант документа, который очерчивает образ действия проекта и в дальнейшем служит руководством для участников проекта.
Штат работников ИС должен сосредоточить внимание на передаче своего опыта, в частности в области методологии проектирования, выбранной для приложений. “Сотрудники отделов ИС слишком уклоняются в сторону техники и стараются поглубже закопаться в то, что они делают, в то время как их больше должны интересовать бизнес-процессы, с которыми они работают”, - сообщила Джой Мэтьюз, соосновательница и вице-президент службы обучения и консультаций фирмы Pierson Application Development (Стемфорд, шт. Коннектикут).
Мэтьюз добавила, что в сфере знаний о том, как работает бизнес, ключевая роль принадлежит пользователям. “От них ожидается описание их текущих дел, какие процессы должны происходить и что они хотят от новой системы”, - пояснила Мэтьюз.
Многое из положительного опыта в компании Provident появилось в процессе обмена опытом, который начался с первым проектом JAD и продолжается до сего дня. Согласно мнению Элеанор Бреслин, супервизора компании по работе с клиентами, пользователи помогли успешной разработке системы работы с держателями полисов.
“В течение двух недель мы занимались мозговым штурмом и спроектировали экраны мэйнфрейма на доске и на бумаге, - пояснила Бреслин. - Еще через две недели работники ИС вернулись с прототипом, а это было все, что нам нужно, до последней детали. Когда мы в конце работы заполнили анкету, где спрашивалось наше мнение о JAD, оно оказалось положительным”.
Говорите на одном языке
Суть работы координатора состоит в управлении не только проектом, но и людьми. “Координатор удерживает группу на нужном направлении, сдерживает тех, кто хочет доминировать и заставляет говорить застенчивых” - так охарактеризовала его работу Дениз Сильвер, с чьей помощью в компании Provident был создан специальный отдел для управления проектами JAD, назначения координаторов и организации связи между бизнес-отделами и отделом ИС.
Сильвер объяснила, что координатор на сессиях группы должен приводить ее к консенсусу, в результате которого должны быть определены модели для бизнес-процессов и данных, а также построен прототип, если это возможно. Сессии могут продолжаться от одного дня до недели. За это время протоколы документируют лишь те моменты, когда группа достигает консенсуса, а детальные заметки не ведутся.
В зависимости от проекта координатор и программисты могут выбрать любые инструментальные средства: от пера и бумаги до средств быстрого построения приложений типа Visual Basic корпорации Microsoft или PowerBuilder фирмы PowerSoft. Кроме того, они могут использовать технологии проведения встреч вроде программного обеспечения StoryBoard компании Vision Software - дополнения к Visual Basic, которое запоминает спецификации и требования к проектированию и генерирует документы и материалы для обучения.
Хотя выгоду от JAD трудно квалифицировать, аналитики верят, что этот метод логически приводит к более быстрому и более точному построению приложений. И если он выполняется правильно, то в этом случае пользователь сам участвует в проектировании для себя программного обеспечения и не нужно строить мост через пропасть, отделяющую работников отделов ИС от пользовательской общественности.
“Пользователь получает возможность переформулировать свои требования на языке, который понимают системщики, а сами работники информационных отделов получают возможность говорить с пользователями на понятном тем языке”, - делает вывод Клейтон Эшби, один из руководителей производственной компании Trane (Кларксвиль, шт. Теннесси), которому довелось участвовать в 15 проектах JAD.
Энн Ноулз
ЧТОБЫ ЭТО РАБОТАЛО
Факторы для успешной работы групп JAD
- Поддержка высших руководителей
- Правильный отбор участников
- Беспрепятственное выделение необходимого времени
- Достаточная подготовительная работа
- Реалистичный объем работы группы
- Хорошо спланированная цель рабочей группы, область охвата и цели
- Физическая среда
- Дипломированный беспристрастный координатор
Качества участника группы JAD
- Понимание текущих и перспективных потребностей бизнеса
- Хороший уровень знания своего дела
- Стремление к созданию качественной системы
- Умение и право принимать решения
- Умение описать процессы, потребности и проблемы бизнеса
- Коммуникабельность
- Умение работать, независимо от ранга
- Понимание возможностей, порождаемых автоматизацией
Источник: фирма Pierson Application Development
Подробнее о JAD
ВЫ заинтересованы в JAD? Вот вам для начала некоторые источники.
Книги:
“Fusion - Integrating IE, CASE and CAD”, Дорин Эндрюс и Наоми Левенталь
“Joint Application Design”, Дениз Сильвер и Джейн Вуд
“Inside RAD”, Джуди Огест
Источник: фирма Pierson Application Development
