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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Реклама

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

Как становятся бизнес-аналитиками (продолжение) Ссылка: АП КИТ

2 комментария Add your own

  • […] И этот тезис –  необходимость умения работать с заказчиком так, чтобы он был удовлетворен (независимо от того, на какую сумму заключен контракт), но и при этом владеть инструментами убеждения заказчика в случаях, когда он своими замечаниями может нанести вред проекту – полностью совпадает с моими подходами. […]

  • 2. bas  |  07.12.2009 в 12:15

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

Добавить комментарий

Заполните поля или щелкните по значку, чтобы оставить свой комментарий:

Логотип WordPress.com

Для комментария используется ваша учётная запись WordPress.com. Выход / Изменить )

Фотография Twitter

Для комментария используется ваша учётная запись Twitter. Выход / Изменить )

Фотография Facebook

Для комментария используется ваша учётная запись Facebook. Выход / Изменить )

Google+ photo

Для комментария используется ваша учётная запись Google+. Выход / Изменить )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed


Подписка на новости сайта

Подпишитесь на новости сайта (RSS)

RSS

Архивы

Рубрики

Главные книги аналитика

Современные методы описания функциональных требований к системам | Алистер Коберн
 Разработка требований к программному обеспечению |Карл И. Вигерс, Джой Битти

Требования для программного обеспечения: рекомендации по сбору и документированию |Илья Корнипаев
Анализ требований к автоматизированным информационным системам | Юрий Маглинец
Пользовательские истории. Гибкая разработка программного обеспечения |Майк Кон


%d такие блоггеры, как: