2018-05-03: AnalystDays — очередной шаг спирали развития аналитиков

Из ленты: MaksWiki — Блог:Максима Цепкова [ru]

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

Взгляд из позавчера

Тезис-Антитезис-Синтез.svg

Эту мысль надо пояснить подробнее. На рисунке справа изображены два такта спирали диалектического развития, которую марксизм взял у Гегеля и назвав законом «отрицания отрицания» (подробности в википедии). Тезис — исходное состояние, некоторое справедливое утверждение. В ходе развития (из закона единства и борьбы противоположности) оно неизбежно приходит к своему отрицанию, получается антитезис. А на следующем такте — возникает их синтез, который, впрочем, находится ближе к тезису относительно некоторой середины — маятник развития качается.

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

Теперь применим все это к работе аналитиков. Тезисом, отправной точкой тут будут стандарты работы с требованиями, сформировавшиеся великими классиками, и в рамках водопадного процесса разработки. Антитезисом, принципиально изменившим картину мира — приход Agile с его методами и форматами итеративной разработки и аналитической работы, в частности, user story, больше пригодными для небольших проектов. Сейчас, по мере развития Agile происходит усложнение проектной и аналитической работы и синтез. Результат которого людьми старой школы воспринимается как возврат к правильным традициям, которые должны были в конце концов восторжествовать :)

AnalystDays8-Loenhoud-1.jpg

И дальше возникают такие интересные картины, как в докладе Hans van Loenhoud на слайде справа — я это описывал в своем посте.

Пост FB Hans van Loenhoud «We use waterfall», и классическая картинка из википедии. Это реплика выдвигающим тезис, будто водопад — никогда не существовавшая система, и потому agile борется с ветряными мельницами. Нет, он — есть, и они его не просто использовали, а продолжают использовать. Но при этом сам водопад сейчас сильно изменился, и это тоже есть — переход от old school к новым практикам.

Во-первых, design и все последующее — погружено в циклы Agile Storm, и этот шторм плавает в окружении Analyze. Во-вторых, на входе нет требований, есть задача помочь клиенту (clients ask for help), мы анализируем ситуацию, предлагаем решения, реализуем и проверяем, что ситуация действительно решена. И это — часть общего перехода from digitalization to digital transformation: from IT-supported to IT-enabled, from Engineered to Designed, from Descriptive to Creative. С выходом в Design thinking.

В коментах к посту была интересное обсуждение с Юрой Солоницыным про методологии и их развитие.

Пост FB Roland Gareis Perceiving Business Analysis as a Set of Services. Уход от проектной организации, когда аналитик — член такой команды, в представление BA как сервиса. Только вот из доклада совершенно непонятно, чем такая организация отличается от возврата к старой функциональной структуре. Ну, кроме названия: сервис вместо отдела. Потому что рассказ идет по старому процессу, сформированному под функциональный водопад, слова про SLA — не звучат… И вообще дихотомия: сервис или набор процессов. То есть он и проектную команду воспринимает через призму функционального деления, которое является доминирующей призмой восприятия. Которая просто отсекает все новое, или считает его несущественным.

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

Пост FB Giancarlo Duranti в докладе Best Practices from a Business Analysis Telco Project попробовал дать полный путь классического бизнес-анализа, начиная от бизнес-потребностей и стейкхолдеров (план доклада на 10 пунктов). Да еще на примере большого проекта DigitalTelco — transformation program for traditional telco operations. К сожалению, теория получилась достаточно общей, а слайды с примерами — почти пропускались — а они самые интересные :( И все равно времени не хватило. Кое-что интересное было.

Business Analysis is a bridge between strategy to tactic. Capability enabler: from the problem now to the solution in future. BA plan and manage the changes on this way.

Cycle of elicitation activities: elicit — structure — document — validation

Пост FB Roger Burlton. The Road to Business Agility. Трое гуру поняли, что надо стать современными написали busagilitymanifesto.org. Среди них — Захман, автор того самого захман фреймворк. А манифест обещает полное счастье — вы будете не подвержены катастрофическим рискам, гибкими, масштабируемыми, сотрудники не уйдут, будут правила, они будут изменяться, будет корпоративная память и скоординированная работа. За все хорошее против всего проблемного! Слушаем :)

Пост FB Roger Burlton. The Road to Business Agility — старые схемы в новой обертке. Надо быть динамичными, знать свои value chain и перестраивать, и на всех этапах — взаимодействовать и сотрудничать со стейкхолдерами — теми же самыми (supplier, regulator, owner, staff, customer), просто стрелка по-другому названа. И в основе, конечно Business Architecture (Захман — гуру). Именно с ее помощью ищут ресурсы. 4 уровня strategic context — business design — business change — business operate, на каждом — свои циклы. Сценарное планирование и SWOT-анализ и так далее…

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

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

Остальные доклады

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

Пост FB Анна Чуркина. От ПО к Сервисам — кейс карт процессинга, который как сервис предоставляется банкам. Расширение рамки проекта от разработки софта до полноценного предоставления сервисам банков, с учетом потребностей конечных потребителей, которым уже банк предоставляет продукт через их сервис. И в этой широкой рамки — появилось много активностей ранней аналитической работы, в результате многие аспекты вскрываются и дорабатываются не на этапе внедрения, а на этапе проработки продукта. Очень полезно, и, кстати, созвучно моему докладу.

А эта фраза понравилась особо: «Своевременно задаешь вопрос эксперту — и не надо переделывать, это просто магия!»

Пост FB Ольга Самарина. У нас VUCA-мир. Я — сторонник хорошо продуманных проектов с качественным менеджментом и четкими требованиями к результату. Увы, и в больших и в небольших и в малых проектах с этим — проблемы.

Пост FB На докладе Ольги Самариной вопрос залу: какой признак большого проекта? Ответы: от заказчика прилетает «тут все просто» или «сделайте как там, только чуть-чуть поменяйте».

Пост FB Ольга Самарина. Приметы рождения большого проекта. Проблема: берешь задачку на пару недель, выкапываешь слона на три года. При подготовке доклада Ольга проводила опросы и выделила признаки большого проекта, за которыми надо следить. Что я понял — эти признаки очень напомнили мне проекты, которым посвящена классическая книга Эдварда Йордана «Смертельный марш», которая была написана про такие проекты. Появившимися и активно распространенными в IT задолго до современного VUCA-мира. При этом, как отмечает Йордан, каждое следующее поколение инженеров и менеджеров заявляло, что «ну, уж мы-то недопустим таких провалов прошлого» — а история повторялась. И Йордан пишет, зачем в таких проектах может быть интересно участвовать и как себя вести. И интересно сопоставить тот опыт с тем, что Ольге рассказали в ходе ее исследований.

А здесь пост Ольги, где она опубликовала ссылку на результат исследований, послуживших основой доклада.

Пост FB Divna Simeunovic. Beyond Brainstorming рассказывает модель творчества из книги Грэм Уоллес (Graham Wallis) Искусство мышления, 4 стадии: preparation (исследование) — incubation (отстранение) — illumination (озарение) — verification (проверка). Суть в том, что загрузив контекст в мозг, вы отстраняетесь от проблемы, позволяя подсознанию в фоне собрать паззл и создать решение, которое придет как озарение. Не очень понятно, почему это Beyond Brainstorming: книга была написана в 1926, сильно раньше чем Осборн придумал мозговой штурм. Может быть потому ,что мозговой штурм стал слишком популярным как коллективное решение проблем, для которых не смогли найти индивидуального решения, и в результате индивидуальным поиском стали пренебрегать, сразу устраивая мозговой штурм, иногда даже без исследований — с соответствующим печальным результатом. Вот и идет возвращение к истокам :) Но в целом — интересно.

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

Игорь Беспальчук Ну, вообще еще не видно, почему сразу супермозг. Команда разработки направляет свой объем внимания на то, что разрабатывает, т.е. детальные решения. Архитектор — на архитектурные. При определенных размерах системы это совершенно стандартная и рабочая конструкция. Что не так?
Максим Шаломович Да, такая мысль и была. Мы потом целый день очень активно общались с посетителями-аналитиками уже в деталях, и там везде примерно такие же выводы и были. Кстати, Игорь, реверанс в Вашу строну — в презентации дал ссылку на Ваш доклад про естественную и искусственную природу архитектуры и использовал слегка как опору для тезисов об архитектуре)
Максим Цепков Игорь, все так, но именно в докладе я такого акцента — не услышал, а соответствующих ему схем — не увидел. У тебя в докладе явно были выделены корневые архитектурные решения, но может быть и другая модель, где уровни абстракции как-то по-другому выделяются, и даются средства с помощью которых архитектор это целостное видение выдерживает. А без этого получается, что просто супермозг.

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

Отмечу, что слайды с конференции уже опубликованы.

Источник