Мастерская бизнес-анализа

О пользователе замолвлю слово

05.12.2009 at 18:28 3 комментария

Поторопиться с этими записками подтолкнул меня сайт «Первая конференция, посвященная работе с требованиями в ИТ-проектах Req Labs 2009» (2019г — архив конференции доступен только с 2012г). Это отлично, что случилась такая конференция. Здорово, что можно посмотреть бОльшую часть презентаций (спасибо организаторам, очень интересно). Но я здесь о другом. Среди эпиграфов, красиво сменяющих друг друга в верхней части сайта, есть и такой: «Классика требований заказчика: «Пойди туда, не знаю куда. Принеси то, не знаю что…» Похожие высказывания есть и в докладах конференции, и в других выступлениях аналитиков на конференциях и семинарах. Причем говорится об этом и всерьез, и в шутку (например: «Заказчик никогда не может сказать точно, чего он хочет, ибо ему хочется всего сразу, много и на халяву»).

Вообщем, чувствуется, что у аналитиков наболело.

Я совершенно не случайно начала эту тему со статьи Фрэнка  Хэйеса    «Что пользователи ждут от ИТ?».  И в первую очередь, мне кажется правильной терминология этого автора – главное лицо  нашего (ИТ специалистов) партнера – пользователь.  Заказчиком он становится при определенных условиях, но в контексте работы аналитика (а не маркетолога), буду  говорить о пользователе.

А Пользователь — посмотрим определение в словаре – «это лицо или организация, которое использует действующую систему для выполнения конкретной функции. В частности, Пользователь автоматизированной системы — АС — лицо, участвующее в функционировании автоматизированной системы или использующее результаты её функционирования».

Итак, зададимся несколькими вопросами:

1. Пользователь АС (в общем и наиболее часто встречающемся случае) является специалистом в области ИТ?
2. Конкретные функции, которые  выполняет Пользователь АС , связаны с разработкой, функционированием,  развитием этой АС?
3. Пользователь АС получает зарплату за участие в разработке, функционировании,  и развитии этой АС?
4. Пользователю АС его руководители выделяют специальное время для участия в разработке, функционировании,  и развитии этой АС?

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

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

И мы никогда не должны забывать, что  «любая программа – это просто инструмент…».

Как я понимаю, существующая теория проектирования АС, выстроенная в основном на переводах западной литературы, хотя и подчеркивает важность фазы выявления требований к АС, исходит из предположения, что цели, желаемое состояние объекта автоматизации, а значит — требования к АС, известны будущему пользователю  до начала проекта. Разработчику необходимо сформулировать, зафиксировать и одобрить их у пользователя в ходе системно-аналитического обследования предприятия.

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

Разработчик АС ведет себя в соответствие с принципом «чего изволите», выполняя АС проект так, как будто участники выработали согласованное, точное и определенное понимание его целей. И разработчик АС проводит опросы, выявляет и анализирует требования пользователя, которые с высокой вероятностью не отвечают его бизнес целям (или другим главным целям, если объект – это «не бизнес»). Не здесь ли лежат причины скептических замечаний части топ менеджеров о бесполезности АС, о нечестных и корыстных информационщиках, только и думающих о том, как бы побольше заработать на плохо разбирающихся в особенностях информационных технологий руководителях?

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

Для этого надо создать  систему построения взаимодействия с пользователем, которая предусматривает:

1. Доступ разработчиков АС к высшему руководству компании заказчика, которое потенциально является «носителем» знания о целях и реальных проблемах своего бизнеса (или, в случае «маленькой разработки» — доступ к руководителю, стоящему над  подразделением, для которого ведется разработка). Договариваться  надо не с начальником отдела ИТ, который свой человек, а с высшим руководителем,  для которого знания ИТ не являются первым приоритетом деятельности.

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

3. Компетентность специалистов разработчика АС – их способность переводить  задачи предметной области в цели проекта автоматизации.  Ключевой момент успешного взаимодействия с пользователем  – понять что нужно пользователю  на самом деле,  и как он это собирается получить. 90% проблем случаются из-за элементарного недопонимания. Пользователь  и ИТ специалист  говорят практически на разных языках – и это нормально, иначе они не были бы нужны друг другу.  Поэтому наша, аналитиков, задача, договариваясь с пользователем,  понять что нужно пользователю на самом деле. Иногда даже надо объяснить пользователю, что ему надо, и может быть даже  убедить его в этом, говоря при этом  на его языке.

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

Или,  как там было у Хэйеса: «ИТ-специалисты сами должны быть в состоянии сформулировать  требования пользователей, наблюдая за тем, как они работают».

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

1. Являемся мы внешним разработчиком или работаем в качестве ИТ специалистов в той же компании.
2. С точки зрения пользователя — делается заказная разработка или приобретается готовое решение (разработчик-то может и заказную разработку из своих же готовых кирпичиков собрать).
3. На каком уровне производственной деятельности будет использоваться разрабатываемая система (для всей организации, для отдельного подразделения).
4. Кто является инициатором разработки (или модернизации существующей) АС: высшее руководство, конечные пользователи или ИТ специалисты.

В продолжении этой темы приведу конкретные примеры.

Entry filed under: Пользователь и ИТ-специалист. Tags: ИТ специалист, Информационная система, Пользователь.