Размышления бизнес-аналитика

12.10.2010 at 08:58 8 комментариев

На размышления, из которых вырос этот пост, меня натолкнула статья Армена Базияна «Модель будущего при проектировании IT-систем»  31.08.2010
Автор – бизнес аналитик (как бы в разное время не называлась его должность) компании «Вымпелком».

Ведя уже почти год блог бизнес-аналитика, я до сих пор не подступилась к теме, которую считаю главной в этом блоге: «А кто же такой бизнес-аналитик в ИТ, и что он делает (должен делать) при проектировании, внедрении, сопровождении ИТ систем.

Меня все-время что-то удерживает от того, чтобы выложить на бумагу (ой, на экран..) весь тот рой мыслей, который копился в моей голове значительно дольше, чем этот «блоговский» год. За последнее время я прочла, мне кажется, все, что написано на эту тему в русскоязычном Интернете, и кое-что на английском. И у меня все время возникает чувство какого-то неудовлетворения, несогласия – желание сопротивляться. Но выразить – что именно «не так», получается не очень.

Что я уже для себя поняла – мне как-то кажется не очень правильным, обоснованным, может быть точнее «не моим» — полная сосредоточенность работы бизнес-аналитиков и  системных аналитиков на сущности «требования» .
Я пока не готова четко и аргументированно объяснить «что и почему», но точно знаю, что до 1990г – когда мы работали на больших машинах, да и в перид 1990-2000гг – мы делали все примено тоже самое (были другие компьютеры и инструменты, а соответственно и выход), но понятие «требование» хотя и существовало,  не было как сейчас  — «нашим все».
Может быть потому, что пользователи, которые в глаза никаких компьютеров не видели, никаких вообще требований не могли формулировать, ну и задача так не стояла (если сравнивать, то на теперешних пользователей и заказчиков грех жаловаться).
Ну и еще видимо потому, что у нас не было никаких книг и учебников ( а теперь есть Вигерс, Коберн, Леффингуэлл).

И вот читаю статью. Автор называет свои идеи: «Новый подход к проектированию»…Ну сейчас чуть – что – сразу «новый подход» (а все, что делалось и писалось больше чем 5-10 лет назад вроде как и не существовало никогда). Ну да ладно, я не об этом.

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

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

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

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

В статье коротко описываются 3 стиля, которыми пользуется автор, при этом он не претендует на полноту (перечисленые стили проектирования он определяет как «лишь некоторые из возможных»).

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

И очень короткое Заключение: «Система, неспособная поддержать изменения или тормозит бизнес или умирает. Грамотное комбинирование стилей проектирования в различных частях системы рождает неповторимое произведение проектировщика – модель, красоту которой можно оценить сразу, а можно — лишь со временем…»

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

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

Реклама

Entry filed under: Бизнес/аналитик, Копилка Мастерской, Обзоры, Термины. Tags: , .

Итоги реформы высшего образования – мнение профессора Сухомлина В.А. Обсуждение закона «Об образовании» – создадут специальный сайт

8 комментариев Add your own

  • 1. businessanalyst2009  |  08.07.2011 в 16:45

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

  • 2. Юрий  |  07.07.2011 в 15:04

    1. Максимально стоит придерживаться профессиональной этики (ИМХО).
    2. Завтра действительно будут выигрывать команды, продукты работы которых максимально быстро адаптируются изменениям и минимизируют стоимость владения продуктом.

  • 3. businessanalyst2009  |  25.10.2010 в 07:43

    Рада, что вам интересно. Заходите, читайте, можете и в обсуждении принять участие

  • 4. reonodori  |  25.10.2010 в 03:00

    отличный у вас сайт. Не жалко потраченного времени. Бродил по интернету, и случайно зашел.
    Теперь буду постоянным читателем.

  • 5. businessanalyst2009  |  17.10.2010 в 21:43

    И Вам спасибо за рекомендации

  • 6. A.Samarin  |  17.10.2010 в 21:22

    Затронутая правильная проблематика, а предлагаемые решения недостаточны. Здесь нужно идти от корпоративной архитектуры (enterprise architecture) и правильно использовать всевозножные современные BPM, SOA, etc. Попытки через ИТ-моделирование будут упираться в проектные ограничения.

    Thanks,
    AS

  • 7. businessanalyst2009  |  17.10.2010 в 14:10

    О, вот компромисс — это действительно «наше все», ключевое слово. Но это же совсем не противоречит тому, что я пишу. Понимать что и как надо делать, и делать реально — это совсем не одно и тоже. Тут как раз одним из ключевых моментов и является бюджет.

  • 8. bas  |  17.10.2010 в 12:44

    Просто Аналитик находится всегда м\у молотом и наковальней:
    1. Широта требований Заказчика
    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 такие блоггеры, как: