Если вы хотите изучить новые слова и выражения на английском, попросите ChatGPT написать вам рекомендации для LinkedIn.

Мне пришлось через фразу лезть в оксфордский словарь! Хотел бы я знать, на каком курсе все эти фразы можно изучить (чтобы звучать, как нейтив). Я выделил курсивом слова и обороты, которые до этого, кажется, вообще нигде не встречал, ну или не придумал бы использовать в таком контексте:

"[Your Name] has consistently demonstrated a remarkable ability to seamlessly blend profound architectural insights with a visionary product perspective. Their unique aptitude for comprehending product strategies, UX design, and user satisfaction truly set them apart. With a keen eye for detail and a deep understanding of both technical and product domains, [bla-bla...] From understanding product strategy to UX design and user satisfaction, [Your Name] excels across the board. I want to highlight his unique ability to blend a deep understanding of software architecture with a product-centric vision, coupled with a knack for understanding user needs and designing intuitive user interfaces. I wholeheartedly recommend them for roles like Head of Product, where his expertise would undoubtedly shine."

Ну и если вам вдруг стало грустно, или вы почувствовали "синдром самозванца" -- почитайте хвалебную оду себе, насколько вы прекрасны! Всех с пятницей! 😜

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

А вы проходили оценку навыков? Как впечатления? Что думаете по этому поводу? Была ли польза? Видели какие-нибудь классные инструменты для оценивания?

Upd: что-то тема не вызывает отклика, вас что, на работе и при приеме не оценивают?!

Уфф, закончилась онлайн-часть Flow. Кстати, сегодня был community day, записи доступны бесплатно (после регистрации).

Я сам почти ничего не смог послушать — сначала вел интервью с Максимом Цепковым про DDD, и как обходиться на проекте без требований, а потом был экспертом на докладе Кати Гончаровой про применение AI инструментов в повседневной работе бизнес-аналитика (там ещё потом интересная дискуссия была).

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

Stay tuned!

Во-первых, хочу написать про доклад-иинтервью с Максимом Цепковым про DDD и работу без требований. Сам формат интересный, можно задать вопросы и направлять этим рассказ, а не идти в логике докладчика. Хотя 45 минут — это очень мало, понимаю теперь, почему у Дудя интервью по 2-3 часа длятся.

Что я вынес из разговора с Максом:

1️⃣ Словом требования называют разные по назначению сущности. Первая - это требования внешних стейкхолдеров, которые вообще-то не говорят о том, как система должна быть устроена внутри, а выражают некоторые пожелания или ограничения по её свойствам и возможностям. Вторая — требования как постановка задачи архитекторам и разработчикам, промежуточный артефакт внутри процесса производства ПО. То есть, бизнес-аналитики строят модель предметной области (бизнес-модель, модель использования системы, концепцию операций...) а системные аналитики и архитекторы строят модель самой системы. И заголовок интервью — про вторые требования, без них можно жить, если использовать единую модель. Забегая вперед, идея пересекается с моим докладом про скрытое проектирование, и с работами Пола Ральфа, который первый вид требований предлагает называть "desiderata", чтобы не путаться. Ну или попросту "хотелки" 😆

2️⃣ И вот если мы меняем способ общения между людьми внутри проекта, нам не нужен "переводчик" с языка заказчика на язык разработки, как часто называют аналитика. У нас общий язык! Ubiquitous language, одна из ключевых идей DDD. Не нужно фиксировать отдельно бизнес-требования, а отдельно их превращать в функциональные требования (спецификации), тексты в тексты. Нужно построить модель, которую поймут все - и заказчики, и разработчики, причем это должна быть одновременно модель бизнеса, и она же - модель системы.

3️⃣ Таким образом, DDD - это, в первую очередь, про способ общения, про коммуникацию между людьми. (Да что там, всё наше производство софта - это на 2/3 про коммуникацию - от сбора требований до проектирования архитектуры, развертывания и мониторинга.)

4️⃣ Соответственно, модель должна быть понятной и разработчикам, и стейкхолдерам. И тут нужно разделять модель и диаграмму - как некоторое представление модели (или одного из аспектов модели). Модель - формализованное упрощенное представление системы. Диаграмма или описание -- представление одного из аспектов модели (Максим показывал расположенные рядом диаграмму активности и диаграмму состояний - довольно наглядно, что на каком шаге происходит). Тут, конечно, бооольшой вопрос - как такую модель построить, и что это за средства и формализмы для её построения. В практике у нас тут в ИТ используются в подавляющем большинстве эвристические модели, то есть умозрительные - кто что придумал, как смог представить, так и ладно. Математических моделей у нас, как правило, нет. Пожалуй, единственная математически строго обоснованная модель -- это реляционная, да и то там есть проблема с 5НФ, которая на практике не решается чисто математически, без понимания бизнес-правил.

Тут подключился Денис Бесков, и мы немного поговорили про нотацию моделирования: у Макса в примерах UML, а Денис говорил про Event Storming. Я, со своей стороны, тоже склоняюсь к ES - и именно в контексте понимания - кажется, она гораздо лучше понимается и стейкхолдерами, и разработчиками, и содержит почти всё необходимое.

5️⃣ Имея единую модель системы, мы можем оценивать "хотелки" стейкхолдеров в отношении этой модели, не заглядывая в саму систему (если гарантировано, что система имплементирует именно эту модель). Так можно, а так нельзя, а вот это будет сложно сделать. Тут мы поговорили про нефункциональные требования (которые всё-таки внешние, зависят от сценариев использования, или, в широком смысле, от операционной концепции - см. ConOps и OpsCon). Про сценарии использования Максим таки проговорился, что они всё же есть, но "это просто текстовые описания" :) Вот тут, кстати, Event Storming дает фору, так как включает сценарии (через реакции актора на события).

6️⃣ Ограниченные контексты. Создать такую единую модель для всего предприятия, да и просто для большой системы - дело неподъемное. И на практике не нужное. DDD освобождает нас от необходимости объять необъятное, и разрешает строить изолированные модели для отдельных областей и думать больше о том, как их связать (и тут есть разные паттерны).

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

Что осталось за кадром, но о чем хочется ещё поговорить:
➡️ как, всё-таки, строить именно модель, а не отдельные диаграммы?
➡️ как научить стейкхолдеров читать модели и согласовывать именно их, а не многостраничные тексты (TAGRI, They Ain't Gonna Read It)
➡️ как работать с изменениями модели
➡️ как воплощать модель в код

Попробовал распознать запись дискуссии через гугл документы (запустил на телефоне и положил рядом с микрофоном). Получился бредок, но! ChatGPT это понимает и выдает нормальное summary.

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

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

1. Главная идея заключается в важности технического ассессмента системных аналитиков для самооценки и определения их места на рынке труда.

2. Участники подчеркивают необходимость построения системы оценки и карты компетенций, которые помогли бы аналитикам определить свои навыки, цели развития и потенциал карьерного роста.

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

4. Один из главных аспектов внутреннего ассессмента аналитика заключается в его нынешнем уровне компетенции и его развитии на текущей позиции внутри компании. Это позволяет руководителям и аналитикам прозрачно оценить его профессиональное развитие.

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

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

В целом-то всё по делу распознал :)

Рассказал на Flow про скрытую работу по проектированию систем, которую выполняет системный аналитик. Хотя какая там скрытая! Вполне даже явная, в половине вакансий написано: проектировать интерфейсы пользователя, Figma; проектировать REST API, разрабатывать спецификацию в OpenAPI; знать Kafka и RabbitMQ, уметь на собеседовании объяснить разницу между AMQP и MQTT; знать SQL, уметь профилировать и оптимизировать запросы, разрабатывать физическую модель; уметь нарезать монолит на микросервисы. И аналитики такие: ЧТОА?

В общем, ловите презентацию, там есть немного ссылок по темам.

Отличный конспект Максима Цепкова выступления про EventStorming

#flowconf Денис Бесков. Радикальное ускорение аналитических работ методикой Event Storming. Доклад из двух частей: проблемы классического подхода и Event Storming как метод решения этих проблем. Проблемная лично часть для меня - достаточно понятно и давно известна. Тем не менее, классические постановки по цепочке бизнес - модель бизнеса - требования - модель системы - система по-прежнему широко используются, потому что именно они положены в основу многих методологий. Именно поэтому фокусировка на этих проблемах - ценная часть доклада. Проблемы таковы.
1) Длинная цепочка преобразований, которая идет с искажением информации, особенно когда ситуация в бизнесе меняется в ходе проекта и надо изменить уже проработанные постановки.
2) Интервью с заказчиком дают противоречивую информацию, выявление противоречий и согласование - непросто и небыстро, особенно если интервью параллельно ведут несколько специалистов.
3) Описания бизнес-процессов в формальных нотациях (ARIS, IDEF0, BPMN, UML) непонятны заказчикам, они не могут их верифицировать, при этом создается ложное ощущение полноты информации. То же касается структур данных - диаграмм классов и ER-диаграмм. Впрочем, я лично тут не до конца согласен: да. полные нотации действительно непонятны, но если использовать ограниченные нотации и вести коммуникацию, то верификацию можно получить.
4) Требования часто скрытым образом содержат частные проектные решения, выработанные конкретным аналитиком, и неясно, что в них обусловлено предметной областью, а что - доопределено им произвольно. При этом решения являются фрагментарными, локальными.
5) Функциональные требования дают плохую основу для декомпозиции системы, так как не дают представления о структуре системы.

Как эти проблемы решает Event Storming? Прежде всего, он заменяет длительную распределенную коммуникацию краткой синхронной, на встречу собирают представителей бизнеса и разработчиков вместе. Получается общее видение предметной области на общем языке, который разработчики узнают от бизнеса.

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

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

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

Применение начать лучше внутри команды, для синхронизации контекстов и онбординга новичков. А далее можно попробовать с лояльным клиентом на небольшом проекте. получить опыт и расширять использование, делиться с коллегами. Event storming хорошо применим для большинства проектов. В нем нет необходимости для простых систем с CRUD операциями и слабой бизнес-логикой. Для отчетных систем есть модификация model storming - там нужен фокус на данных и их обработке.

Источники на русском - Сергей Баранов и Евгений Пешков, на английском - Брандолини и khononov (в процессе перевода).

Максим Цепков написал отчет о конференции Flow, очень хороший, с конспектами докладов (и моим тоже): https://mtsepkov.org/%D0%91%D0%BB%D0%BE%D0%B3:%D0%9C%D0%B0%D0%BA%D1%81%D0%B8%D0%BC%D0%B0_%D0%A6%D0%B5%D0%BF%D0%BA%D0%BE%D0%B2%D0%B0/2023-09-17:_Flow_-_%D0%BA%D0%BE%D0%BD%D1%84%D0%B5%D1%80%D0%B5%D0%BD%D1%86%D0%B8%D1%8F_%D0%B0%D0%BD%D0%B0%D0%BB%D0%B8%D1%82%D0%B8%D0%BA%D0%BE%D0%B2_%D0%BE%D1%82_JUGru_-_%D1%85%D0%BE%D1%80%D0%BE%D1%88%D0%B8%D0%B9_%D1%81%D1%82%D0%B0%D1%80%D1%82

Кажется, нам (я был в этом году членом ПК Flow) удалось затащить в программу довольно много архитектурных докладов, что, с моей точки зрения, крайне полезно для системных аналитиков. Вслед за Максимом хочу отметить доклады Дениса Цветцих про C4 (это уже, кажется, вместе с DDD и ES становится азбукой в ИТ, которую нужно знать всем) и Святослава Котусева про Enterprise Architecture — что архитектура — это не диаграммы рисовать, а поддерживать постоянную коммуникацию с бизнесом, строить дорожные карты развития, инициировать проекты и вообще обеспечивать развитие ИТ в соответствии с потребностями развития бизнеса.

В общем, раскрываю интригу предыдущих картинок. ТЗ на самом деле было в двух вариантах: одно детальное, другое верхнеуровневое.

Детальное ТЗ:
Нарисуйте прекрасный летний луг, на котором расположены:
* 10 синих цветов с 5 лепестками каждый
* 5 синих цветов с 6 лепестками каждый
* 12 красных цветов с 6 лепестками каждый
* 2 коровы с 3 чёрными пятнами на боку
* 1 корова с 5 чёрными пятнами на боку
* 3 летящих птицы в левом верхнем углу
* 2 птицы посередине
* 1 солнце с 5 лучами в правом верхнем углу

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

Что получилось — можете увидеть в предыдущем посте 😆
В принципе, несомненно, у всех что-то получилось, Что можно отметить:

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

2) Команда с летающими коровами пошутила уже надо мной: "несколькими коровами и птицами в небе", вот что неаккуратный союз "и" в требованиях делает!

3) Заказчик не проверил заранее наличие необходимых компетенций в команде! Ну не умеют люди рисовать коров, это не проблема людей, это проблема заказчика, который не провел предварительную квалификацию участников тендера.

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

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

Вот такое получилось забавное упражнение. С точки зрения чистоты эксперимента научности в нём нет никакой, но как иллюстрация — явно наводит на мысли 🤔

Когда я разбираю идеи некоторых продуктов — предлагаемых или, к сожалению, уже реализованных, — я частенько вспоминаю отрывок из книги про Винни-Пуха, когда он ловил Слонопотама:

...Первое, что пришло Пуху в голову,— вырыть Очень Глубокую Яму, а потом Слонопотам пойдёт гулять и упадёт в эту яму, и...

— Почему? — спросил Пятачок.

— Что — почему? — сказал Пух.

— Почему он туда упадёт?

Пух потёр нос лапой и сказал, что, ну, наверно, Слонопотам будет гулять, мурлыкая себе под нос песенку и, поглядывая на небо — не пойдёт ли дождик, вот он и не заметит Очень Глубокой Ямы, пока не полетит в неё, а тогда ведь будет уже поздно.

Пятачок сказал, что это, конечно, очень хорошая Западня, но что, если дождик уже будет идти?

Пух опять почесал свой нос и сказал, что он об этом не подумал. Но тут же просиял и сказал, что, если дождь уже будет идти, Слонопотам может посмотреть на небо, чтобы узнать, скоро ли дождь перестанет, вот он опять и не заметит Очень Глубокой Ямы, пока не полетит в неё!.. А ведь тогда будет уже поздно.

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

Почему он вообще к нам придёт и почему он будет делать то, что мы хотим — вообще обычно не анализируют. Вот прямо сейчас у меня в работе очередной проект с идеей "мы создадим ресурс с информацией по теме X, к нам придут пользователи, прочитают про X, будут обсуждать X, пройдут опросы по теме X, а мы будем их исследовать и продавать о них информацию всем, кто заинтересуется отношением общества к теме X". Чувствую себя немного Пятачком, очень хочется задать сакраментальный вопрос: — Почему он туда упадёт?

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

Так же обстоит дело и с другими продуктами и сервисами — никто просто так в них не упадёт и делать просто так ничего не будет, если не понимать мотивацию и цели пользователя. На этот счёт есть много техник: от простых user story и относительно простого Impact mapping, до сложных диаграмм типа Motivation Layer в Archimate. А уж теорий под этим ещё больше! И SDT (Self Determination Theory), и Behavioral Design с Behavioral Studies, и какой-нибудь Octalysis (не уверен в его эмпирических основаниях) или Bartle taxonomy of player types (которая как раз основана на массированном исследовании мотивации пользователей онлайн-игр)...

А вы используете какой-нибудь инструмент для проектирования поведения пользователей или анализа реалистичности спроектированного пути пользователя?

Вот интересно, в очередной раз столкнулся: люди в программирование умеют, а в написание документов совсем не умеют. Не могут ни структуру документа построить, ни обеспечить логику чтения, ни проконтролировать полноту и целостность. Не знают — о чем нужно писать, о чём нет; не понимают — в какой раздел вставить информацию.

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

Всё точно так же, как с системой. Но почему они могут тогда что-то запрогать, но не могут это описать?! Позвольте, а как же они тогда служили в очистке программируют-то?