Аналитики больше не нужны. Пакуем чемоданы и расходимся?

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

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

Эти люди умеют находить нестыковки. Умеют коммуницировать. Они даже умеют держать в голове целостную картину. Но это картина "чужого" решения. Они не синтезируют решение, они поддерживают тех, кто синтезирует.

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

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

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

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

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

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

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

Причины происходящего кроятся в истоках нашей профессии.

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

Эта проблема создавала пропасть во взаимопонимании бизнеса и ИТ. Как следствие, всего лишь 20 - 30% проектов заказной разработки заканчивались успешно.

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

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

При этом требования к системе определялись как к черному ящику, т.е. максимально инвариантно к способам их реализации. Почему ящик должен был быть чёрный? Это был предмет договоренности. Он должен был быть понятен бизнесу, т.е. не должен был содержать непонятные вещи. Но при этом должен был быть понятен разработчику и должен стать отправной точкой для технического проектирования.

На тот момент черный ящик был приемлемым результатом функционального проектирования.

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

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

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

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

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

Но чтобы внедрить в бизнес эти возможности, надо понимать драйверы этих возможностей – технологии.

И тут на первое место в проектировании выходят архитекторы - люди, которые прекрасно знают технологии.

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

Но как же системный анализ? Он же вроде как процветает?

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

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

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

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

Строго говоря, это не анализ. Это скорее технический дизайн.

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

В итоге вышло то, что вышло.

Бизнес-аналитики, не грузившиеся в технологии, оказались в западне - не понимая технологий и принципов проектирования систем, они снизошли до проработки отдельных вопросов, возникающих у архитектора или продукт овнера - т.е. по сути работают "на подхвате".

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

Т.е. аналитик как специалист утратил свою ключевую роль в проектировании системы. Он оказался на обочине процесса.

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

Системные аналитики (которые технические дизайнеры) вроде как процветают. Они востребованы. У них хорошие зарплаты.

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

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

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

Есть ли в этом смысл? Думаю, что нет. Бесполезно бороться с эволюцией. Она всё равно победит. Аналитик в тех видах, в которых он существовал и к которому мы привыкли, скоро станет совсем не нужен.

Хорошо это или плохо? Я думаю, что хорошо, поскольку эволюция открывает новые возможности.

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

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

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

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

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

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

Где взять таких людей?

Это не архитекторы, эти люди не должны смотреть на систему на глубоком техническом уровне. Но они должны понимать принципы архитектурного проектирования. И повторюсь - должны знать паттерны архитектурного проектирования в своем бизнес-домене.

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

Наверное это бизнес-архитекторы информационных систем или дизайнеры корпоративных решений.

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

Дизайнер технических решений - он имеет шанс развиваться в бизнес-архитектора. Но это не будет развитие по принципу "профессиональнее делаю, то что делаю, больше знаю, лучше разбираюсь в том, что делаю". Он должен сделать качественный скачок. Человек должен выйти на уровень, когда он сможет дизайнить и систему, и бизнес, в который эта система будет интегрирована.

Похоже, это должна быть новая специальность, которой надо учить. Как, к примеру, учат девелоперов в архитекторы.