Обещал написать, какими вопросами можно зацепить функции для робота-пылесоса.

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

Я пользуюсь набором простых вопросов (иногда в уме, иногда в явном виде — для сложных проектов) для каждого действия (сценария).

Вопросы:
* Для чего? (Вариант: что будет дальше?)
* Какое обратное действие?
* Кто? (роль; есть ли дополнительные признаки и условия?)
* Когда? (ограничения на допустимые состояния; триггеры автоматического запуска)
* Где? (какое устройство? что вокруг?)
* С кем? Кто рядом?
* Сколько? (любой численный показатель, который может описывать процесс)
* Как? (какие есть альтернативные способы выполнения действия и какие ограничения?)
* Какой? (особенности, классификаторы и состояния объекта)
* Что нужно/может быть до начала действия? (в описании use case это нужно писать в "предусловия", но мало кто пишет)
* Что уменьшается/увеличивается в процессе? (например, при записи на курс уменьшается число свободных мест; у робота тратится заряд и увеличивается убранная площадь)
* Чем заканчивается действие? (Постусловия, что будет создано? что поменяется? есть ли триггер на прерывание длительного действия?)
* Что может помешать выполнить действие?
* Что будет, если каких-то объектов 0,1,N? (Например, один студент записывается на курс. Может ли на курс записаться N студентов одним действием? А N студентов параллельно?)

Можно добавить вопросы безопасности:
* Чем система может навредить при выполнении действия?
* Какую информацию нельзя показывать/изменять при выполнении действия?
* Что может сделать злоумышленник при выполнении действия?

На фичу из предыдущего поста могут навести вопросы "Кто рядом?" (дети, домашние животные), "Что было до?" (что от них могло остаться на полу?), "Что может помешать?", "Чем система может навредить?"

Пятничный пост (не очень серьезный)

Набор вопросов из предыдущего поста можно обобщить и использовать для рассмотрения системы в целом.
Интересно, что список вопросов можно взять примерно тот же, что используется коучами для самоопределения людей :)

Вот, например, пирамида Дилтса (не путать с Маслоу и Минто!).

Её уровни:

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

2. Поведение. Это функции системы. Что система делает, как ведёт себя в зависимости от реакции пользователя/внешней среды.

3. Способности (capabilities) — возможности системы. Что система потенциально может делать (и что ей сделать будет трудно). Тут связь с архитектурой.

4. Ценности и принципы. Продуктовые параметры. Что для нас, хорошо, и что — плохо? На что мы никогда не пойдем? Что мы будет поддерживать изо всех сил? Что для нас ценно, а что неважно? (Важны ли данные пользователя, или их можно потерять? Важна ли безопасность? Важна ли социальная составляющая, и какие именно взаимодействия мы хотим поддерживать? Исходя из чего мы выбираем, что делать?)

5. Идентичность — вот эта система, она кто? Ведь обычно система представляет опосредованное взаимодействие людей (вы могли бы пойти в банк и общаться с операционистом, но используете банковское приложение). И вот эта система для пользователя — кто? Помощник? Советник? Контролер? Наставник? Диджей? Экспертный продавец? И т.п. Например, для одной школьной системы мы пришли к выводу, что система, которую задумывали, как дневник, на самом деле должна вести себя как тьютор — не ругать за ошибки, а спрашивать про настрой и мягко вести к цели.

6. Миссия — зачем мы делаем систему? Какое влияние хотим оказать на мир?

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

Вопрос "кем является система" для меня связан с вопросом "какие социальные взаимодействия поддерживает система"?

Проще говоря, как у вас люди общаются друг с другом через систему.

В российской практике профессиональной ориентации очень часто применяют типологию профессий Е.А.Климова: вот эти вот ЧЕЛОВЕК-ПРИРОДА, ЧЕЛОВЕК-ТЕХНИКА, ЧЕЛОВЕК-ЗНАКОВАЯ СИСТЕМА, ЧЕЛОВЕК-ЧЕЛОВЕК. Вы, возможно, помните из школы. За пределами пост-советских стран такая типология, правда, не встречается.

Так вот — работа с информационными системами, это, конечно, ЧЕЛОВЕК-ЗНАКОВАЯ СИСТЕМА, но в современных реалиях это почти всегда ЧЕЛОВЕК-ЗНАКОВАЯ СИСТЕМА-ЧЕЛОВЕК. Вы через систему взаимодействуете с другими людьми опосредовано. Система может вам помогать это делать, а может мешать или диктовать свои способы взаимодействия, часто неестественные.

У Джоела Спольски, которого я считаю одним из лучших авторов по проектированию интерфейсов, есть книга: User Interface Design For Programmers, в русском переводе Руководство по UI дизайну для программистов (тут сразу pdf).

Это 2001 год, а примеры там вообще из 90-х. Но принципиально ничего не поменялось... в интерфейсах. А вот в проектировании поменялось — теперь мы почти всегда проектируем социальные системы. Джоел написал об этом в 2004: It’s Not Just Usability, перевод: Не юзабилити единым, а ещё раньше в 2003: Building Communities with Software, перевод не нашел.

Один из примеров — интерфейс Napster (если вы помните такое приложение, кхе-кхе). Интерфейс был ужасен. Программа работала только на Windows. Это было одно из самых популярных приложений в мире. В 2000 году Napster создавал от 40 до 60% трафика в частных сетях и в сетях университетов.
Если вы делаете то, что нужно людям — они будут мириться с любым интерфейсом. Сейчас, наверное, можно привести в пример красноглазые интерфейсы в области крипты.

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

Есть масса приложений с красивыми интерфейсами, совершенно не учитывающими — как именно люди общаются и взаимодействуют в каком-то процессе. Школьные дневники. Запись ко врачу и хранение истории приемов. Социальные сети (нечеловеческий LinkedIn чего стоит!). Системы приема докладов на конференции. Системы управления задачами и документацией.

Джоел приводит в пример свой FogBugz — багтрекер, в котором люди действительно работали над исправлением дефектов, в отличие от других систем, которые "was never getting used, because it did not align with the way people wanted to work together" (кстати, не доверяйте переводам, там эта фраза переврана до противоположного смысла). Про FogBugz не знаю, не видел, а Trello, разработанная в той же компании, конечно, почти эталонная по интерфейсу легковесная система управления задачами.

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

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

Примеры социальных функций в приложениях и сложностей с ними:

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

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

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

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

2) баны. В одном сообществе были личные баны — один пользователь мог забанить другого и не видеть его постов и комментариев. В какой-то момент забаненному перестали показывать комментарии забанившего, а стали показывать плейсхолдер <здесь комментарий от пользователя, который вас забанил>. Что тут началось! Люди обнаружили, что кем-то забанены, начинают выяснять — кем? Кто меня забанил? Ах, этот! Вот ведь гад!

Сообщество бурлит, число взаимных банов (в ответ) растёт, связность падает, кто-то решил вообще удалиться... А всего-то маленькая функция!

Джоел упоминает множество non-features, функций, которых нет в продукте. Для аналитика это очень странно — некоторые стандарты даже напрямую запрещают писать "отрицательные требования" — чего не должно быть в системе. А вот с точки зрения требований к социальной системе это может быть критически важно!

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

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

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

Это "китайская классификация" по Борхесу; мне, например, сложно понять, почему CQRS — это "архитектура", а хореография — "обмен сообщениями". В любом случае, паттерны интересные, а ещё есть анти-паттерны, как делать не надо — тоже полезно знать при проектировании решения; и архитектурные принципы. Повторюсь, что это довольно общие вещи, относящиеся не только к продуктам на основе Azure — они в том или ином виде реализованы и в AWS, и в других системах.

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

Итак, паттерны:

* Асинхронный запрос-ответ.
В общем, простая идея про запросы, длительность обработки которых на сервере может занять больше, чем 100 мс, а очереди/брокера у вас нет или вы не хотите их использовать — и вы используете поллинг. Первым запросом запускаете процесс на сервере, а сервер возвращает 202 (Accepted) и ссылку, которую нужно поллить. Клиент регулярно ходит по этой ссылке и проверяет — выполнился ли запрос. Пока он не выполнен — сервер возвращает 200 (OK). Когда результат готов — 302 (Found) и переадресует на место, где лежит результат.
Как вариант, тут можно было бы использовать WebHook, но далеко не все клиенты поддерживают вызовы к ним — технически или по соображениям безопасности.

* Квитанция (claim-check).
Если вы собираетесь передавать большой объем данных, имеет смысл не загружать систему передачи (например, брокера или очередь), а выслать "квитанцию" с токеном, по которому клиент сможет забрать ответ из хранилища статических данных. Также паттерн можно использовать, когда нужна дополнительная защита, чтобы чувствительные данные не проходили через брокер/очередь/прокси и т.п. Ну и в принципе неплохо бы защищать статику каким-нибудь токеном, чтобы не было ситуаций с утечкой документов, доступных по прямым адресам без всякой проверки — про это следующий паттерн.

* Valet Key — не знаю, как перевести на русский, видел автоматический перевод "ключ камердинера", но не встречал такого употребления в живой среде. Это как раз токен из предыдущего паттерна: когда вы получаете статический ресурс, если он не должен быть общедоступным — защищайте его токеном. То есть, клиент сначала запрашивает ресурс у приложения, приложение отдает ссылку на ресурс + токен (либо токен зашит прямо в URL), и передает токен хранилищу. Хранилище обрабатывает запрос к ресурсу только с токеном — так гарантируется, что запросивший клиент — именно тот, кому выдали разрешение, а ещё можно ограничить действие токена по времени.
Этот паттерн также описан в книге O'Reilly 'Cloud Architecture Patterns' — хотя остальные паттерны в ней в основном низкоуровневые.

Где можно использовать эти паттерны? Например, при запросе большого отчета, который относительно долго формируется. "Заказать" формирование мы можем через асинхронный запрос и поллинг, либо через очередь запросов, потом получим "квитанцию" с токеном доступа, а сам сформированный отчет ляжет в файловое хранилище. Файловое хранилище отдаст готовый отчет только клиенту, предъявившему квитанцию с токеном. Про истечении времени жизни токена отчет будет удален.

UML умер, но никто этого не заметил?

Один знакомый сейчас идет работу в Европе. Он продакт, CPO. Вы, возможно, слышали, а может и сами сталкивались с поисками работы вне России — внезапно сейчас в ИТ довольно сложно. Очень много соискателей, очень много интервью проходит впустую.

Вот и он так же: ходит на множество собеседований. И вот на одном интервью заходит речь про UML. Соискатель напрягается, и аккуратно выясняет — а не российские ли корни у компании? Оказывается, да, основатели из России, программисты, учились в российских институтах. Потому что никто, кроме российских программистов, UML при разработке продуктов давно уже не использует 😂
(Ну, по крайней мере, на верхнем уровне проработки. Такой опыт у моего знакомого.)

Как, в его опыте, обычно устроено управление продуктовыми требованиями:
🔸 Job Stories для формулировки продуктовой проблемы (кажется, фактически этот формат победил User Stories во многих проектах).
🔸 сценарии работы пользователя (не в виде юскейсов, а менее формально)
🔸 критерии приемки в виде BDD-сценариев.

Возможно, UML появляется где-то внутри в команде разработки — в основном в виде диаграмм классов, последовательности/активности и иногда состояний. Он этого не знает, это внутренний язык общения разработчиков друг с другом.

Слухи о смерти UML циркулируют ещё с 2010-х годов. Из последнего — много обсуждений вызвала статья Эрнесто Гарбарино 'Has UML Died Without Anyone Noticing?'.
Впрочем, встречаются и мнения, что "UML не мог умереть, потому что он никогда не был живым".

Интересными мне показались два поинта в статье:

1. UML — это формальный графический язык. Элементы в нём зафиксированы в стандарте. Но бизнес-заказчикам такой язык не нужен! Им нужны диаграммы, которые показывают то, что им нужно увидеть здесь и сейчас. И если на диаграмму нужно добавить описание персон — нужно его добавить. Возражение "в UML это не предусмотрено" не принимается.

2. А проиcходит так потому, что на организационном уровне разработка программных систем больше не является инженерной практикой. Где-то в глубине — да, разработчики всё ещё являются инженерами (а ещё более ими являются инженеры по надежности, которые даже иногда используют тервер и математическое моделирование!), но на уровне бизнеса — больше нет.

Принцип fail fast, fail often (and fail cheap) убил практику инженерии требований, бизнес-анализа и проектирования. UML просто умер вместе с ними. Программирование фокусируется на том, чтобы быстро накодить что-то, а потом быстро переделать. Инженерам нужен язык для общения друг с другом, для проектирования и анализа моделей, а кодерам — нет, им нужны фреймворки, библиотеки, low-code и copilot.

В прекрасном новом мире нет бизнес-анализа и детализированных моделей бизнес-процессов. Всё очень легковесно: DDD и Event Storming вместо сложных моделей, JTBD для интерфейсов, C4 для архитектуры.

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

А вы применяете UML? Насколько часто, и что именно из него?

Пост про "смерть UML" оказался очень неоднозначным и спорным. Поэтому я бы хотел провести опрос, чтобы иметь какие-то количественные оценки. В 2014 году исследователи из Трирского университета проводили опрос про использование диаграмм, эскизов и набросков при разработке и проектировании ПО в Германии и США. Я взял их опросник и перевел на русский: https://forms.gle/zU7PncWsWc9u3cXZ6

Я был бы вам очень благодарен, если бы вы прошли его. Это займет буквально 5-7 минут. В опросе у германских исследователей приняло участие 350 респондентов, и я надеюсь, мы сможем собрать не меньшее по мощности исследование. В результате мы точно узнаем — кто и как использует диаграммы при разработке ПО.

Если у вас есть возможность — отправьте опросник своим коллегам и знакомым, в том числе программистам; так мы обеспечим представительство большего числа профессий в ИТ. Результаты опубликую в канале. И тогда мы узнаем — кто, где и как использует диаграммы и UML!

Промежуточные итоги по опросу:

164 ответа (надеюсь, наберем ещё)
47% — системные аналитики, 24.4% — архитекторы, 16.5% — бизнес- или фуллстеки.
Почти все из средних (37,2%) или крупных (48,8) компаний, почти все из России.
По отраслям: 38,4% — финтех(!), 11,6% — ритейл, 11% — госпроекты, 9,1% — автоматизация производства.
Проекты в основном крупные: от 11 человек и выше (суммарно 58,5%), и 33,5% — от 4 до 10 человек.

Теперь самое интересное:
🔹 67,1% составляли диаграммы буквально на днях или в этом месяце, 10,4% — прямо в течение дня, когда проходили опрос.
🔹 88,4% вносили несколько изменений в диаграмму после создания(!)
🔹 Суммарно потраченное время на диаграмму: несколько часов (43,3%) или даже дней! (11,6%). За час уложились 34,8%.
🔹 При этом в основном над диаграммой работает 1-3 человека (51,2% работают в одиночку).
🔹 Срок жизни диаграммы в основном около года (34,8%) или больше (25,6%), и здесь впервые значимая величина ответов "не знаю" (10,4%)

Диаграммы в основном скорее формальные, но не идеально формальные.
Чисто UML-ных диаграмм около трети, с некоторыми элементами — больше половины. Совсем без UML — 18,4%

Для чего рисуют (только ответы >50%):
➡️ Зафиксировать требование
➡️ Презентовать решение
➡️ Объяснить задачу
➡️ Спроектировать архитектуру
➡️ Проанализировать требования

Что чаще всего описывает диаграмма:
➡️ Архитектуру
➡️ API / интеграцию

Понятно, что с большим отрывом лидирует Sequence Diagram: более 70% ответов, следующие за ней — Use Case (45,7%) и State Machine (43,9%). Совсем не используют UML 6,7%.


Средний возраст респондентов — 35 лет, средний стаж — 5 (правда, есть выбросы на 20, 25 и 30 — видимо, на таких сроках уже пятилетками считают, детали смазываются 😂).

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

Ещё очень интересные комментарии — спасибо огромное всем, кто развернуто написал!


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

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

⭐️ UML жив, тут даже сомнений нет. Но жив он частично. И используется совсем не так, как был придуман. От всего UML осталась диаграмма последовательности (и она ого-го как используется!), диаграмма вариантов использования (вот это меня удивило, думал, её мало кто использует) и диаграмма состояний. При этом сиквенс в основном фиксирует уже спроектированное решение — тут, конечно, нужен корреляционный анализ, но пока кажется это так.

⭐️ С другой стороны, почти 20% живут без всякого UML, и им норм.

⭐️ Лично меня удивила популярность диаграммы юскейсов — правда так много людей её используют? А зачем?

В чём результаты опроса сошлись с экспертами индустрии:
Sequence diagrams, the only good thing UML brought to software development. Это статья от создателя mermaid.js. Там и про смерть UML с разных позиций, и про пользу сиквенсов, и про то, как их использовать. С цитатами типа "The reward of the clarity of sequence diagrams is worth the pain and boredom of learning all the others at university" и "Sequence diagrams are the only type of diagrams I use anymore."

Статья классная, попробую перевести её, как будет время.

А итоговый вывод: UML — как латынь для некоторых наук. Мёртв-не мёртв, а лучше знать хотя бы основы и понимать, как его правильно применять сейчас. Lingua Franca для разработки.

Хм. Почему-то отвалился чат. Если хотите обсудить диаграмму робастности — комментируйте это сообщение.

Что я делаю с ChatGPT прямо сейчас (и это выглядит как чертова магия!)

В ChatGPT теперь можно вставлять файлы и скриншоты. И если вставить скриншот таблицы, то можно попросить сделать SQL-стейтмент для создания этой таблицы в БД, и INSERT INTO со всеми значениями из таблицы!!!1

Скреппинг данных никогда не был таким простым.

Upd: это мне в бесплатный аккаунт раскатили модель 4o, возможно, вы про неё слышали. Это сейчас самый топ, она по всем показателям пока впереди других LLM.

Как правильно отмечают в комментариях к посту про  Robustness Diagram, в UML её нет отдельно, потому что её можно сделать, например, из Communication Diagram.

Ранее она называлась Collaboration — как, собравшись вместе, части системы решают задачу. В конце концов, это просто объекты и стрелочки. Такую диаграмму можно и сейчас собрать в каком-нибудь PlantUML, хотя её нет в списке диаграмм, которые он поддерживает. Но стереотипы для Entity, Control и Boundary есть, и стрелки тоже.

Забавно, что Ивар Якобсон в расширении UML, описывающем Entity-Control-Boundary подход — у него он назывался Objectory — имел в виду скорее диаграмму классов. Собственно, он ведь какую задачу решал? Как правильно выявить структуру классов в приложении при использовании объектно-ориентированных языков. Это был 1992 год, ОО-языки уже появились, а методологии их применения — ещё нет. И дискуссия про пользу ОО-подхода против структурированного программирования стояла очень остро.

Ивар Якобсон и придумал Use Case'ы, как способ проектирования структуры классов. Методически это выражалось как последовательность:
1) реестр юскейсов (взгляд на систему с точки зрения задач пользователя) — диаграмма юскейсов;
2) шаги юскейса, и необходимые для них интефейсы, сущности и логика — диаграмма устойчивости;
3) классы, реализующие выявленные интерфейсы, сущности и логику — диаграмма классов.

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

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

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

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

Я долго задавался вопросом — почему диаграмма робастности? Ведь в статистике, электротехнике, инженерии и ML робастность — свойство сохранения работоспособности при резких и странных изменениях внешних параметров (выбросы, помехи). Так вот потому и робастности, говорит Якобсон: свойство системы сохранять работоспособность и целостность при поступлении неожиданных и странных требований!

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

Сколько информации в ваших требованиях? Сложный пост с математическим уклоном.

Задача аналитика — снизить неопределенность при проектировании системы, чтобы выйти на ограниченный набор возможных решений. Важное слово здесь — "ограниченный", потому что чем больше неопределенность (непонятно, что нужно), тем больше вариантов решений. Фактически, речь идёт об энтропии — числе способов, которыми можно расположить и связать компоненты системы.

А это напрямую связано с количеством информации, описывающей систему. Не сильно вдаваясь в математические модели, можно сказать, что энтропия — это разница между новой информацией, содержащейся в сообщении, и хорошо известной информацией (о которой, может, и говорить-то не стоит). Например, хорошо известно, что любая сущность в системе должна быть создана и предъявлена/прочитана/использована. С большой вероятностью она должна быть удалена или архивирована. С некоторой вероятностью — изменена. Это обычный CRUD, которым можно контролировать полноту, но который почти ничего нового не сообщает об устройстве системы: можно было бы просто перечислить список сущностей, и завести CRUD для каждой. А вот когда мы начинаем задавать вопросы — когда и кем создается сущность? кому, когда и для чего её показывать? зачем и кто её изменят? — мы можем извлечь дополнительную информацию, передать в требованиях что-то, что не очевидно с самого начала. Таким образом снизив энтропию — уменьшив количество вариантов и рассказав что-то интересное.

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

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

Требования должны быть неожиданными! И требования должны быть разными! Помните, как работает архиватор? Он выбирает одинаковые последовательности и заменяет их одним символом — повторение не несет информации. Если вы видите, что в ваших требованиях постоянно что-то повторяется: формулировка, обоснование, решение — остановитесь и задумайтесь. Не пропускаете ли вы здесь важную информацию? Стоит покопать поглубже, и получше разобраться? Или это хорошо известная информация? тогда и повторять её не имеет смысла, нужно упаковать в более компактный вид.

А сколько у вас в документе неожиданных требований? Знаете, как в шахматной нотации ставят ! и !! и иногда !? Хороший ход, отличный ход, и неожиданный ход (возможно, ловушка).

Скольким требованиям в документе вы может поставить такие значки?

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

А вот что меня натолкнуло на написание предыдущего поста. Это из таблицы с бизнес-требованиями, столбец с обоснованием требования.

Фактически, ответ на вопрос "Зачем мне, как <роли> это нужно?". Это работа аналитика-стажера, но я видел такое и у штатных аналитиков. Это мощный сигнал! Если вы видите такое — это повод разобраться, что тут происходит. Простое повторение не несет новой информации. Если несколько требований нужны для одного и того же — может быть, это одно требование и оно зря разбито на несколько? А может быть, обоснование взято слишком высокоуровневое, пропущен уровень один рассмотрения.

В любом случае, так быть не должно, это недоработка.

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

Но если вам вдруг интересно, что мне интересно и что я читаю каждый день — я создал отдельный канал https://news.1rj.ru/str/yksdailylinks.

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

В общем, если вам вдруг любопытны ссылки от меня — welcome!

Я редко делаю репосты, но тут просто огненная тема! Ну и Киру в принципе рекомендую, если интересуетесь процессами найма и HR.

Для аналитиков, о чем можно рассказать, помимо примеров в посте, и что меня бы, например, интересовало при собеседовании аналитиков (кстати, меня, если что, можно звать на собеседования, чтобы оценить кандидата):

⭐️ пример автоматизации бизнес-процесса или отдельной функции (сквозное описание: от выявления требований до технических решений и тестирования, если было);

⭐️ пример участия в проектировании технической архитектуры (или выбора способа реализации, выбора готового решения с учетом технических требований);

⭐️ пример задачи описания требований для проектирования интеграции систем или API;

⭐️ пример решения какой-то сложности в проекте — когда было непонятно, что делать, или заказчик не мог сформулировать требования, или когда требования были противоречивые; в общем — когда вы пришли и поправили всё, спасли бизнес и/или команду разработки;

⭐️ пример применения какой-то техники бизнес- или системного анализа (например, того же DDD или Impact Mapping) — с обязательным указанием, в чем была польза, в чем положительный эффект;

⭐️ пример организации управления требованиями: как фиксировали, как согласовывали, как управляли версиями, как передавали в работу, как принимали выполненную работу.

В идеале, всё это нужно раскладывать по методу STAR: Ситуация — Задача — Действие — Результат, прямо так и рассказывать. Я рекомендую при подготовке к интервью составить себе несколько таких примеров, расписанных по STAR, заучить и при случае вставлять. Рекрутеры сами по этому STAR работают, им зайдет. (то есть, если вы нанимаете людей, вы из спрашивать можете в той же логике!)

Как вариант, можно использовать метод PARLA: Проблема — Действие — Результат — Опыт — Применение. Последние два — это Learned и Applied: что вы вынесли из этой ситуации, чему научились, и как теперь это применяете. В принципе, даже без задачи подготовки к собеседованию это хорошие вопросы для ретроспективы любого проекта или его этапа.

Главное слово кандидата на собеседовании: «НАПРИМЕР»

📌 Никто не телепат. К сожалению, если вы не будете приводить примеры из своего опыта, нанимающий менеджер не сможет оценить, насколько вы действительно реализовывали те задачи, про которые говорите.

Сравните:

❌ Я закрывала сложные вакансии быстро и качественно.

✅ Я закрывала сложные вакансии быстро и качественно.
Например, однажды нам в компании срочно потребовался ещё один разработчик баз данных, а подходящих кандидатов на рынке не было, сроки поджимали. В итоге я лично опросила всех имеющихся в команде разработчиков баз данных и попросила рекомендаций на их бывших коллег, получила контакты 10 кандидатов, с каждым связалась и нашла троих, кто был готов не только рассмотреть нашу вакансию, но и выйти в короткие сроки. Всех трёх мы отсобеседовали за 2 дня, выбрали одного, который вышел сразу после согласования оффера. Весь процесс занял у меня неделю.

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

Пример:

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

✅ Я откликнулась на вашу вакансию, потому что мне очень нравится ваш банк, я давно хотела работать в финтехе, потому что у вас сложные и интересные задачи.
Например, я вижу в вашей вакансии, вы решили внедрить Confluence в качестве единой базы знаний. У меня есть похожий опыт в предыдущей компании, где я, в качестве бизнес-аналитика, помогала внедрять эту систему в команду из 3000 человек. Я хорошо знаю плюсы и минусы этой системы, например, у Confluence есть проблемы с производительностью и я знаю, как их решать.

📌 Любое утверждение становится весомее и понятнее, если вы подкрепляете его примером.

Например:

❌ Что я больше всего не люблю в работе? Когда внутренний заказчик возвращается с правками 🙁

✅ Что я больше всего не люблю в работе?
Расскажу пример: мы работали как внешний подрядчик и я, как проджект, очень много внимания уделил брифингу клиента, выявлению потребности и формированию полного ТЗ, которое полностью устроит клиента. Каждые 2 недели мы сверялись с клиентом по процессу, чтобы сразу же выявлять проблемные места. Всё шло гладко, мы резво двигались по плану, клиент вносил минорные правки и мы уже подошли к финалу проекта. И тут, когда до дедлайна оставался месяц, на стороне клиента поменялся руководитель, который остановил весь процесс, а потом кардинально поменял ТЗ и потребовал, чтобы мы уложились в изначальные сроки. Я очень не люблю такие ситуации. Хорошо, что я внимательно документировал каждый шаг и мы были документально защищены от такой ситуации. В итоге, я смог наладить контакт с новым руководителем, обсудить с ним его пожелания и наши возможности. Мы сформировали новый план действий и смогли реализовать то, что клиенту было необходимо.

👉 Быстрый совет: напишите на бумажке слово «НАПРИМЕР», приклейте возле экрана на время собеседования, чтобы почаще использовать это слово и подкреплять свои слова наглядными примерами 🙏

Опубликовали статью по мотивам выступления на Flow'2023 (вот тут в формате видео https://www.youtube.com/watch?v=HzynqWGKehQ)