Просто о сложном: как нарушаются принципы и законы систем в проектах ИТ. Часть 4

Продолжение

Рекомендуется предварительное ознакомление со статьями, указанными ниже в разделе «Смотрите также».

О том, как ломаются системы

Я вообще не сторонник позиции «я знаю, что должно быть только так, у меня опыта X лет в [], и — точка». Я за здравый смысл, гибкость и за постоянное расширение границ области своих познаний.

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

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

Как менеджер, например, я однажды руководила проектом, на котором требований не было вообще (кроме структуры задач в Jira), зато стабилизация превышала почти в два раза запланированный на нее бюджет (вместо «классических» 25-30% от бюджета разработки спринта расходовалось около 50-55%), а заказчик по-прежнему не воспринимал доводов за бизнес-анализ. Постоянный аргумент с его стороны заключался в том, что для двух разработчиков на таком простом проекте нет необходимости писать и анализировать требования, да и ввод еще одного человека или роли для менеджера увеличит число коммуникаций и повысит загруженность представителей заказчика (то, что они по этим же вопросам взаимодействуют с двумя разработчиками во время стабилизации совсем не считается как и то, что разработчики занимаются на фазе стабилизации не совсем тем, что входит в их компетенцию). Но альтернативное мнение до заказчиков было доведено, выбор остался за ними, и он был не в пользу бизнес-анализа.

Но как быть в распространенной ситуации, когда заказчик «хочет машину, требования изложил для реактивного самолета, а финансов у него в лучшем случае — на самокат»? При этом он ничего не понимает в технологиях (и таких заказчиков 50-70%; в оценке исхожу сугубо из своего опыта). Что делать разработчику? Должен ли он разбираться с реальностью заказчика? Ответ очевиден. Как и роль бизнес-анализа в данной ситуации. Ежегодные потери (в процессе разработки и внедрения ПО) во всем мире в размере 250 миллиардов долларов связаны с плохими требованиями и непониманием потребностей и проблем бизнеса заказчика.

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

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

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

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

Вместо заключения…

Autobiography in five short chapters by Portia Nelson

I
I walk down the street.
There is a deep hole in the sidewalk
I fall in.
I am lost … I am helpless.
It isn’t my fault.
It takes me forever to find a way out.

II
I walk down the same street.
There is a deep hole in the sidewalk.
I pretend I don’t see it.
I fall in again.
I can’t believe I am in the same place
but, it isn’t my fault.
It still takes a long time to get out.

III
I walk down the same street.
There is a deep hole in the sidewalk.
I see it is there.
I still fall in … it’s a habit.
my eyes are open
I know where I am.
It is my fault.
I get out immediately.

IV
I walk down the same street.
There is a deep hole in the sidewalk.
I walk around it.

V
I walk down another street.

Продолжение следует…

Смотрите также:

  1. Системный подход и системное мышление. Зачем?
  2. Просто о сложном: основы системного подхода. Часть 1.
  3. Просто о сложном: основы системного подхода. Часть 2.
  4. Просто о сложном: системный взгляд на проект ИТ. Часть 3.

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

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

Логотип WordPress.com

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

Фотография Twitter

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

Фотография Facebook

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

Google+ photo

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

Connecting to %s