Разные разные пользователи (продолжение)

18.12.2009 at 11:15 4 комментария

А теперь на дворе год 2003

Меня пригласили на уже начатый проект. Пользователи –  финансовая организация довольно высокого уровня (отвечает за бюджет  области).

Этап разработки технического задания завершен, денежки все получены и естественно потрачены. Идет стадия  разработки, и уже пришло время эту разработку закончить и сдать. И уже десант разработчиков и аналитиков высадили прямо в офис Заказчика (благо все происходит в одном городе).   Ан до выхода на руководство для сдачи Системы и подписания актов дело никак не доходит.

Начинаю разбираться. И вот какие характеристики этого проекта:

  1. Проект выполняют  внешние разработчики. 
  2. Разработка  заказная – и с  точки зрения пользователя,  и для разработчика.
  3. Система должна была быть разработана для всей организации, но под конкретную функцию. Причем в реализации этой функции участвуют как значительная часть работников собственно финансовой организации, так и сотрудники других организаций (на отдельных этапах) и их много.
  4. Инициатором разработки АС являлись сотрудники отдела АСУ  финансовой организации. 
  5. В этой организации на тот момент разве что курьеры и уборщицы не сидели за компьютерами – а так все были охвачены. Использовалось несколько разных информационных систем, и очень активно задействованы возможности MS Office.

Теперь в повествовательном ключе

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

К 2001г учетные функции и функции исполнения бюджета (а для финансистов «исполнение бюджета» — это как бы «производство», оперативное управление) уже так или иначе автоматизированы, а вот планирование осуществляется в EXCELe.

И уже сотрудники отдела АСУ выжали из этого EXCEL-я все, что можно, обеспечивая поддержку хотя бы иллюзии коллективной работы.  Но это привело к тому, что процесс частично переместился из отделов финансовых, в отдел АСУ.

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

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

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

Что было в начале

Начали  разработку.  Обследование провели преимущественно методом анкетирования. А беседы вели в основном с инициаторами разработки – сотрудниками отдела АСУ. Техническое задание было принято без особых проблем, из чего я делаю вывод, что пользователи-финансисты его не читали, а тоже делегировали решение АСУшникам.

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

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

Что пришлось предпринять

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

Сначала, аналитик ходил к тем из конечных пользователей, кто был наиболее лоялен к проекту (всегда есть кто-то, кому более чем другим интересно всем новым заниматься). 

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

То есть, в данном случае, то, что процесс проектирования и взаимодействия с пользователями не удалось с самого начала «выстроить по науке», не пошло проекту на пользу. НО! Если бы разработчики поставили процесс во главу угла, они бы этот проект потеряли (именно потому, что инициирован он был АСУшниками).

Что удалось предпринять: мы  — компания разработчик – погрузились в предметную область по уши, установили контакты с вышестоящими финансовыми структурами и с несколькими консалтинговыми фирмами (одной было бы мало, чтобы нас не обвинили в лоббировании интересов именно этой фирмы в части методологии), стали участниками  совещаний и конференций по вопросам бюджетной реформы (а какая-то реформа у нас всегда есть). Это позволило нам придти к пользователям нужного нам уровня не с вопросами, а со знаниями, идеями, конкретными  предложениями, которые в свою очередь реализовывались  в системе вариантами настройки. И вот тогда они увидели Систему, оценили ее и нас, и начали  с нами разговаривать по-другому.

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

Вывод у меня такой

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

Реклама

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

Достаточно гибкости? Варианты использования вариантов использования

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

  • 1. Евгения  |  27.12.2009 в 21:14

    Для этого нужен очень высокий уровень аналитика. Интересно, много ли их, таких?
    Даже в наши времена племя «постановщиков» было не слишком многочисленным. Считалось, что программисты вполне могут напрямую работать с пользователями.
    Так и сейчас бизнес-аналитиков, в данной трактовке, тоже не сильно много. И вопрос — понять, как их готовить, какое должно быть образование…
    Наш Нииоргпром, конкретно наш отдел, вырастил таких специалистов, в Уралсистеме были люди…
    А вот а еще примеры есть?

  • 2. businessanalyst2009  |  27.12.2009 в 10:13

    Ну а насчет «когнитологов» — это из области теории, и мне кажется, термин не прижился.
    А вот быть «переводчиками» между конечным пользователем и программистами, «вытскивать» из пользователей их знания и технологии и переложить их на язык технического задания для программистов — это и есть работа аналитика. Какой это аналитик — системный, бизнес, еще какой-то — это есть предмет спора и обсуждения.
    И я думаю, это будет как раз основным содержанием моего блога.
    Но сразу возвращаюсь к своей мысли — часто надо не из пользователя вытаскивать, а работать вместе с пользователем или предлагать — то есть генерить аналитикам самим.

  • 3. businessanalyst2009  |  27.12.2009 в 09:54

    В компании-разработчике случилось главное — руководитель эту позицию принял и определенные шаги к тому, чтобы экспертов предметной области стало больше, были сделаны.
    Один из них — приглашение на работу специалиста, причем очень грамотного и высокого уровня, из одной из организаций-пользователей. Но, к сожалению, этот конкретный шаг оказался неудачным. Но я думаю, что они не правильно договорились. Второй шаг — обучение своих специалистов. Здесь конечно успехи лучше, когда специалисты НЕ программисты. а финансисты, экономисты и т.д., в крайнем случае инженеры. Это дольше, но надежнее. Сейчас есть молодые ребята, которые успевают за время учебы получить 2 высших образования — второе экономическое (первое — у нас это был радиофак УПИ). Это тоже не 100-процентная гарантия, что может вырасти в эксперта, но иногда может получиться.
    Еще один шаг — об этом я писала — плотное сотрудничество с консалтинговыми фирмами — не мы после них, а вместе, в одном проекте.
    Ну и наконец, в этой компании есть еще один специалист, имеющий то же образование (даже чуть лучше — со специализацией АСУ) и прошедший тот же путь, что и я.
    Поэтому выдерживать эту линию — быть для пользователей помощниками, советчиками, партнерами — пока получается.
    Но для справедливости надо сказать — компания специализируется в одной предметной области и для этой сферы деятельности предлагает специализированный продукт — конструктор. Так что для них стать экспертами — реально.

  • 4. Евгения  |  26.12.2009 в 20:56

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

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

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

Логотип 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 такие блоггеры, как: