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

Я довольно часто на тренингах, да и в работе, сталкиваюсь с тем, что людям сложно разложить деятельность на составные части. Например, в случае User Story Map, нужно сначала выявить деятельность — верхний уровень, его формулировку можно так и проверить, добавив слово "деятельность": "деятельность по управлению аккаунтом", "деятельность по формированию заказа" и т.д. Если слово "деятельность" не подставляется, кажется излишне громким ("деятельность по авторизации") — значит, с уровнем что-то не то, мелковат.

Следующий шаг — отдельное действие. "Добавить товар в корзину", "Оформить заказ", "Оплата".

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

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

Вот прямо как сочинение в школе: "Я грела молоко в бутылочке, чтобы покормить Васёну, которая лежала тут же на кухне в своем шезлонге. Тут пропикал телефон. Я не могла его сразу посмотреть, потому что одновременно сработал таймер у подогревателя. Потом я дала бутылочку доче, она занялась, а я посмотрела на телефон. Это было уведомление от нового приложения, которое про здоровье. Я переживаю, чтобы всё было хорошо, и стараюсь следить. Мы родились зимой, и мне кажется, Василисе не хватает солнечного света и витамина D. В роддоме при выписке посоветовали, и я поставила. Пока непонятно, но я стараюсь записывать прибавку Васеньки в росте и весе.
Я нажала на уведомление, это была новая статья про прогулки и промокшие ноги. Мы пока гуляем в лежачей коляске, так что не очень актуально, я посмотрела заголовок в уведомлении и смахнула, не стала читать. Может, осенью будет актуально, когда пойдём" — вот такого типа. (Приложение для трекинга здоровья детей, область — "чтение статей", шаг "получить уведомление о новой статье").

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

Выступил вчера на AnalystDays'16. На этот раз постарался выдать максимум шаблонов и цепочек промптов, чтобы можно было сразу брать и применять. Держите презентацию!

Очень часто прилетает вопрос про безопасность и конфиденциальность данных при работе с ChatGPT. Прочитал для вас условия использования сервисов OpenAI:

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

Так что тексты ваших запросов не станут автоматически доступны другим пользователям. Но они сохраняются где-то внутри ChatGPT (не в самой модели, а в её "обвеске"), и могут быть доступны сотрудникам OpenAI для анализа — скорее всего, в обобщенном виде (то есть, именно из вашего промпта возьмут только часть) и с отфильтрованной персональной информацией. Цитата: "When we fine tune our models using user-submitted data, we also use PII filtering techniques to reduce the amount of personal data used. We also only use a small sampling of data per customer for our efforts to improve model performance."

Если и в этом тоже не хотите участвовать и вы юридическое лицо, вы можете в явном виде запретить использовать ваши промпты, указав ID компании в системе OpenAI (ссылка на форму отписки есть в документе). Частным лицам отказаться не получится.

Но! Это всё касается только ChatGPT (и DALL-E). Политики OpenAI в явном виде разделяют API content и non-API content (и API consumers и non-API consumers); первый не используется для дообучения и файнтюнинга без специального заявления его владельца, второй — может использоваться. То есть, при доступе через официальный API к GPT-3.5 или GPT-4 ваш контент не будет доступен никому; сохранность и приватность его примерно такая же, как и других облачных сервисах — сама модель GPT-3.5 работает на основе Azure.

Подробнее вот тут: https://help.openai.com/en/articles/5722486-how-your-data-is-used-to-improve-model-performance

С коллегами из Systems.Education
сделали группу поддержки для всех, кто применяет генеративный ИИ в работе аналитика и проектировщика информационных систем: https://news.1rj.ru/str/genai4AnD (не только от OpenAI, но и другие модели)

В связи с распространением генеративных интеллектуальных агентов, очень актуальным станет навык проверки и оценки адекватности различных артефактов — неважно, созданных человеком или ИИ. Коллеги из Яндекс.Практикума дают возможность в этом потренироваться: набирают ревьюверов на курс по системному анализу, ещё и денег заплатят:

Пошел искать источник цитаты "Architecture is a stuff that's hard to change" ("Архитектура — это всякие штуки, которые потом трудно изменить", приписываемой Мартину Фаулеру, обнаружил, что, как это часто бывает, во-первых, и фраза не его, а Ральфа Джонсона (паттерны проектирования и XP), а, во-вторых, полностью звучит так: "One of the differences between building architecture and software architecture is that a lot of decisions about a building are hard to change.", то есть:

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

— в общем, как обычно, исходная цитата имеет совершенно противоположный смысл! (отсюда: https://martinfowler.com/ieeeSoftware/whoNeedsArchitect.pdf)

Сам Мартин Фаулер топит за то, что хорошая архитектура как раз допускает широкий диапазон изменений и хороший архитектор уменьшает архитектуру на проекте (по-английски звучит красивее: a good architect reduces architecture).

Отличная картинка у Маска в твиттере:
— Мы используем людей вместо тенденциозного ИИ
— На чем вы их обучали?

Провёл несколько сессий Event Storming, добавил себе в арсенал ещё оно возможное задание для собеседования аналитика (в том числе — для проверки диаграмм процессов): перечислить — а лучше нарисовать — последовательность событий в каком-то процессе.

А то тут оказалось, что люди очень интересные события фиксируют:
— разовые события, которые вообще привели к старту проекта ("компания решила открыть новое направление", "потребовалась замена иностранного ПО");
— события, которые происходят в голове у пользователя ("пациент решил обратиться ко врачу")
— события интерфейса приложения ("установлен фильтр запчастей")
— "события", которые на самом деле процессы ("проходит консультация")
— хитрая штука: события, которые система не может проверить ("пользователь ознакомился с правилами сайта")

В общем, и угол рассмотрения интересный, и ошибки новые, свежие :)

Коллеги собрали папку каналов по системному анализу, как это сейчас модно. А вы какие каналы читаете по нашей теме?

Подборка классных каналов про системный и бизнес-анализ

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

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

Можно подписаться сразу на все или выборочно. Каналы сложатся в отдельную папку SA. Потом можно отменить подписку или размьютить, как и с другими каналами, но мы рекомендуем следить за актуальными темами отрасли!

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

У Григория Добрякова классный (и очень холиварный, ух как у многих от него пригорело!) пост про шины и брокеры: как вы их используете — как шину данных, или как шину сообщений? Процитирую самую суть:

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

1. Событийный брокер (кафка, раббит) с честным потоком событий.

2. Событийный брокер, в который все ходят как в БД (клиенты работают выборкой по хранящимся сообщениям в произвольном доступе).

3. Симбиоз событийного брокера и БД с трансформациями, когда вы кладёте в шину данные в одном виде, а достаёте их в другом (например, в денормализованном или наоборот в компактифицированном).

4. Просто тупо одна большая БД, в которой хранится абсолютно каждый объект в его последнем состоянии. То есть shared state, который все читают и все меняют, ага.

5. Некий http-шлюз, в который ты посылаешь данные post-запросом, а он проксирует этот запрос в целевую систему. Ну или наоборот get-ом так же получаешь данные.

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

7. Всевозможные мостики-трансляторы из http в хранимую процедуру в БД.

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

Предназначение событийной шины — пересылать события о данных, А НЕ сами данные. Если у вас, например, заказ перешёл в статус «оплачен», то это событие, ценной информации в котором фактически только два поля — это id заказа и наименование статуса.

[...]

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

Поэтому передают объекты целиком. "

Пост, как я уже говорил, максимально провокационный (на самом деле там даже три поста и куча обсуждений). Но заставляет много о чем задуматься. В первую очередь — о трезво принятых решениях и о решениях, которые просто так появились, без анализа и оценки. У архитекторов есть такая практика — ADR, Architecture Decision Records, журнал принятых архитектурных решений, с обоснованиями, развилками и компромиссами, или Trade-Offs — что мы выигрываем, а что теряем при каждом решении. Аналитики обычно такие записи не ведут, а очень зря — так принятые решения проходят мимо анализа, "ну потому что всегда так делается же", и приводят иногда к неожиданным отдаленным последствиям.

Вот как в случае с Кафкой — ну поставили, а как вы её дальше используете? По какому из описанных выше паттернов? Какие trade offs были при этом учтены, и к чему всё это может привести? (Отдельно замечу, что вопрос "как правильно" вообще не имеет смысла в этом случае. Правильно так, как максимально полезно в имеющихся и возможных в будущем условиях).

Интересную тут штуку заметил и сформулировал: хотя у ChatGPT есть известная проблема с вычислениями (он трактует числа как текст, разбивая их так же "на слоги", токенизируя), он удивительно хорошо прикидывает.

Например, я несколько раз просил оценить сроки проекта — получалось очень близко к экспертной оценке. Я решил проверить, и взял методику оценки от московского ДИТа — она публично доступна. Методика использует метод функциональных точек с весами и поправочными коэффициентами. Она довольно сложная, и я не стал рассчитывать коэффициент совмещения для должностей, то есть взял максимальную оценку сверху — получилось 38 человеко-месяцев. ChatGPT по описанию проекта дал оценку 6 человек и 4-6 месяцев, то есть 36 человеко-месяцев.

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

В случае же с оценками сроков — тут можно объяснить точность самим принципом работы языковой модели — она ведь подставляет статистически вероятный токен, ну вот на базе собранных публикаций эти сроки и есть наиболее вероятные! :)

Свежая статистика по зарплатам в вакансиях. Вчера как раз зарубились на эту тему на круглом столе на конференции "Анализ & Управление в ИТ проектах" – специализированная конференция 1С-аналитиков, куда меня позвали рассказать про ChatGPT. У 1С сейчас бум – во-первых, проекты стали сложнее, и запросов от бизнеса больше – и на интеграции, и на анализ данных, и на более дружелюбные интерфейсы; во-вторых – многие компании ищут замену SAP. При этом раньше массово такой роли, как аналитик, в 1С не было, а сейчас это очень горячая тема, и ребята активно осваивают все методы, существующие в других областях.

Вчера как раз был круглый стол на тему "откуда брать аналитиков" и чему их учить. Интересно, что разработчиков 1С сейчас гораздо больше, чем аналитиков, и спрос на них меньше, такой вот парадокс. Так что передайте своим знакомым 1С-программистам, пусть приходят к нам учиться методам системного и бизнес-анализа :)

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

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

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

Вообще, с точки зрения бизнеса, мне кажется, основная ответственность аналитика — уменьшение двух рисков: 1) что мы сделаем не то, что нужно; 2) что мы не сделаем того, что нужно. Я об этом уже когда-то писал. И метрикой тут становится почти шуточное "количество раз, когда заказчик или архитектор воскликнули: О! Об этом мы как-то не подумали!..". Если, конечно, вы оцениваете этот риск, как высокий, и вообще собираетесь что-то с ним делать. Правда, такой анализ влечет увеличение объема проекта (от 30% до 300% иногда!), но лучше об этом узнать заранее.

Другая распространенная история, когда аналитик транслирует требования в постановки. По сути, делает непонятное понятным. Было непонятно, что делать, теперь стало понятно. Тут возникает неясность: насколько подробной и исчерпывающей должна быть постановка задачи? Нужно ли программисту максимально четко написать, что делать, или достаточно описать общую потребность, а дальше программист уже сам решит? Такие обсуждения тоже были, но ответ обычно "это зависит от многих параметров". От чего конкретно зависит, правда, мало кто говорит. Ну, от опыта программиста зависит. Тут происходит интересная подмена: если аналитик ставит задачу детально, то он уже не аналитик, а проектировщик — он принял решение по тому, как система должна быть сделана, а не по тому, что можно делать при помощи системы. Это происходит незаметно, поэтому и оценить это сложно. И это меня сильно тревожит, так как сутевая часть работы заметается под ковер.

Так-то за 130 лет ничего и не изменилось 😁 "Слушайте слова мудрости, которые несёт вам ChatGPT фонограф!"

И даже сравнение с попугаем точно такое же :)