Почему я думаю, что я называюсь бизнес-аналитик?

17.11.2009 at 19:55 4 комментария

Я начала работать в 1971г, конечно тогда ни о каких таких бизнес-аналитиках никто и не слыхивал. Но во всех организациях, занятых проектированием и внедрением информационных систем, была такая функция, или как теперь принято говорить «роль», постановщик задач.

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

Структура работ конечно была не такая как сейчас. Не было продаж, маркетинга,  были свои особенности  работы. Но наличие постановщика в любом проекте было обязательным. Более того, никому и в голову не могло придти, что можно делать проект без постановщика. Почему? Да потому что была другая вычислительная техника и другие методы программирования. И соответственно – другие программисты. В самом начале –в 70-е годы – у них даже дисплеев не было. Я очень хорошо помню, какой это был огромный прорыв, когда программисты сели к терминалам и смогли сами (без операторов) работать с текстами своих программ. Но и тогда они еще работали в машинных залах, и им выделяли «машинное время». А большую часть времени они – великие и недоступные – сидели как и мы – за письменными столами и рисовали ручками на бумажке. Они писали программы на языках высокого уровня, а на вход им должна была быть подана информация в очень четком виде: формы ввода данных, печатные формы для вывода, описание алгоритма. Понятно, что программисты бы долго смеялись, если бы их спросили о том, как они общяются с конечными пользователями. Всю подготовительную работу для программиста делали  постановщики задач. Все работали на основе ГОСТов, тогда была серия Гостов 19, а также активно использовались «новые» инженерные госты – ЕСКД и ЕСТД (конструкторские и технологические).

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

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

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

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

С одной стороны, появились персональные ЭВМ. То, что потом их поколения менялись как кадры в кинофильме, это не принципиально. Важен именно момент, когда   пользователь получил возможность остаться один на один со своим компьютером, со своей задачкой. У такого пользователя появляется партнер – программист, умеющий делать для его персональной ЭВМ программы, рисовать на экране кнопочки (проектировать интерфейс – по нынешнему). Таким образом было создано море так называемых АРМов. Там, где это пришлось на «старую структуру организации работ», еще удавалось сохранить системность подхода, какую-то стандартизацию элементов и т.д.  Я об этом знаю не понаслышке – работала все в том же своем НИИ последние годы (1988-1990) начальником лаборатории проектирования АРМов на персональных ЭВМ. И мы делали довольно большую комплексную задачку «Поддержка ведения договорной работы в отделе заказов» на очень большом заводе (ПО Уралмаш – там еще в то время около 40 тыс. работающих было).

Но в это же время  случилась «экономическая революция» — сначала, примерно с 1987г, появились кооперативы. Большая часть занимались поставкой этих самых персональных компьютеров, но многие занялись и разработкой софта – мелких АРМов. И вот тут возникла иллюзия, что никакие постановщики не нужны: садятся 2 человека рядом, пользователь и программист, и быстренько, за небольшие деньги создается АРМ. Причем именно в это время возникло то, что теперь является основой умных методологий – возможность очень быстро показать пользователю кусочек уже работающей программы – прототип. А это позволяет улучшить диалог между разработчиком и пользователем и делать действительно работающую и по тем временам очень не плохую систему.

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

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

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

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

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

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

Я постараюсь внести свой вклад в это обсуждение, но пока пример своего профессионального пути:

1971г -1988г – должности – м.н.с. и с.н.с., роль – постановщик задач и/или исследователь, ответсвенность (как тогда это было в науке): исполнитель, ответственный исполнитель, руководитель НИР.

1988г-1990г – должность – зав. Лабораторией, роль – руководитель проектов и постановщик задач, ответственность – руководитель НИР, ответственный исполнитель

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

Именно в это время прикатилась волна с Запада, все больше фирм называют своих постановщиков аналитиками (кто бизнес, кто системными).

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

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

И тем не менее, деляю уверенные выводы:

  1. постановщики советских времен (те что сохранили профессию, а не убежали в бухгалтера и маркетологи) были совсем не плохо подготовлены для работы аналитиками (кто бизнес, а кто и системными) в новых условиях (конец прошлого века и первое десятилетие нынешнего).
  2. для работы бизнес-аналитиком (вот тут – именно бизнес-…, если есть возможность функции бизнес-аналитика и системного аналитика в команде разделить) лучше иметь образование, которое я обобщенно назову «экономическое».

Более подробно на многих задетых здесь вопросах надеюсь остановиться позже.

 

Реклама

Entry filed under: Бизнес/аналитик, Мемуары. Tags: , , .

Как становятся бизнес-аналитиками. Мои ссылки

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

  • 1. businessanalyst2009  |  30.09.2010 в 19:03

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

  • 2. Helen Danis  |  30.09.2010 в 13:25

    Здравствуйте.

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

    Немного о себе.
    Тоже работаю аналитиком. Именно как Business Analyst. Есть опыт сотрудничества с 3 компаниями и 3 успешно завершенных проекта.
    Не так уж много, но это только начало.

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

    В таком ключе бизнес-анализ предполагает более отличное знание предметной области, чем опыт с постановкой задач. По-поводу постановки — это отличное знание и полезный скил… но это знание менеджера. Не аналитика.

    В любом случае, спасибо что затронули тему.
    Развивайте ее в следующих постах.

  • 3. businessanalyst2009  |  22.11.2009 в 21:50

    Это здорово, что молодым аналитикам это интересно. Пока я только разворачиваюсь со своим блогом, Вы можете задавать вопросы — что вас интересует из опыта. Я с удовольствием поделюсь, если будет чем

  • 4. Галина  |  22.11.2009 в 18:51

    Спасибо за столь подробный рассказ-экскурс в историю. Жаль, что нас, «молодых» аналитиков, получается, как-то выдергивают из контекса — сразу показывают, что есть сейчас, но не показывают, с чего все начиналось. 🙂

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

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

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