Интересный вопрос задал Дима Безуглый @Cless75 в обсуждении способности GPT рисовать архитектуру и другие промежуточные артефакты — а нужны ли они? То есть, когда их делает проектировщик или команда — это способ последовательного продумывания деталей решения, чтобы ничего не забыть. А ИИ может и не надо так, если он сразу всё у себя "в голове" продумал. Зачем эти промежуточные шаги, если они не код? Можно же кратко поставить задачу, и пусть идёт код сразу пишет, всё. Ошибется — переделает, это быстро.

Зачем нам нужны промежуточные проектные артефакты, и нужны ли они при генерации кода ИИ?

1 апреля (и это не шутка!) меня можно послушать на TechTrain, где-то между рассказами про Agile в ML и искусственным интеллектом в садоводстве.

#доклады

Что еще расскажут про искусственный интеллект на бесплатном фестивале TechTrain 2023 Spring?

— Юрий Куприянов из Systems.Education попробует использовать ChatGPT как помощника при анализе и проектировании небольшой ИТ-системы.

— Артемий Малков и Юлия Рубцова из Data Monsters расскажут, как победить запредельную неопределенность в управлении ИИ-проектами.

— ИТ-садовод Александр Дмитриев из hh.ru расскажет, как построить умную теплицу и привнести в садоводство воспроизводимость результатов.

Подробнее — в дайджесте.

Бесплатная регистрация на фестиваль — на сайте.

#chatGPT #agile_в_ml #it_садоводство

Вчера зашел на совместный митап Альфы и jug.ru. Выглядело это как мини-конференция из трёх докладов, и вот что меня немного напугало. В двух из трёх докладов обсуждали управление задачами (в одном докладе — про оформление задач в виде кода на Kotlin, положенного в git и поставленного под ci/cd для сборки итоговых doc и pdf для рассылки заказчикам и внешним согласующим; в другом — использование линейного программирования для выбора задач из бэклога в спринт).

Так вот что меня напугало. В обоих случаях никого абсолютно не волнует содержимое и смысл этих задач! Ну как будто нужно бревна перекидать, или там детальки обточить. В истории с линейным программированием докладчик так и сказал — оптимизируем загрузку членов команды, исходя из их личной ёмкости (т.е., не capacity всей команды, а capacity отдельного фронтендера, бэкендера или аналитика). Ну чисто завод и станки!

Да даже Голдратт на примере завода показывает, что думать нужно не о том, что проще (загруженность станков членов команды), а о том, что выгодно бизнесу (поставленную за спринт ценность). Но нет, даже мысли такой не возникает. На входе у нас сам собой магическим образом возникает идеально приоритизированный бэклог, и остается только загрузить постановку задачи в "исполнителя". Вот уж кого ИИ заменит — если вам не важно, что на входе, и какие именно задачи имеет смысл делать, а не просто загружать промты в Головы Послушных Технарей (сокращенно GPT).

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

Или можно просто брать таску сверху, и сразу её делать? И получается что-то осмысленное?

Запись доклада про ChatGPT на TechTrain доступна (после регистрации). В основном отзывы положительные, но есть те, кто говорит, мол, ничего нового, всё это уже было в статье на Хабре.

Ну, я хотел как раз показать что-то новое, видимо, не сделал это явным. Что было новым для меня:

1. Проход по модели C4. Вообще, я хотел в принципе уйти в system design, но меня попросили сделать больше обзорный доклад, а не у ходить в детали. Возможно, стоит отдельно записать видео и почелленджить GPT на тему проектирования. С C4 обнаружилась такая проблема: если её запрашивать для PlantUML, ChatGPT подтягивает старые версии библиотек и путается в иконках для AWS. Это можно полечить, если подсказать ему — какие версии использовать, но быстрее получилось через mermaid, она сама по себе поддерживает нотацию.

В С4 ChatGPT немного путает уровень контейнеров и компонент, но это и люди путают, и вообще контейнеры в C4 это что-то такое про деплой, хотя чисто для деплоймента в C4 есть отдельная диаграмма, не входящая в Context-Containers-Components-Code, в общем, легко запутаться. Я сам на проектах обычно рисую контекстную диаграмму + раскладку по функциональным блокам (которые иногда переходят в физические подсистемы 1:1, а иногда нет — одна система может поддерживать несколько разных блоков функциональности; в конце концов, монолит — это когда у нас вообще одна система на всё).

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

3. Новой идеей для меня оказалось детальное описание того, что я хочу иметь на выходе. Тут нужно ещё поэкспериментировать, но уже видно, что если формат вывода не оговорить — можно получить странное, типа диаграммы классов в ASCII :) Буду продолжать исследования.

4. Попытка залезть в управление проектом: требования к команде, график работ — этого раньше не было. Нужно ещё покопать в эту сторону, кажется, для ПМа ChatGPT тоже может решить много задач.

В общем, я нашел много точек для further research, so stay tuned for news and updates! Ставьте лайк, нажимайте на unmute! :)

Редко попадаются хорошие статьи на русском — то конкретики нет, то уровень не выдержан, то вообще творчество копирайтера или "редактора блога", где все термины перепутаны, "волны перекатывались через мол и падали вниз стремительным домкратом". 80% статей я вообще не могу читать, такая там чушь. Читаю поэтому в основном стандарты, первоисточники и научные статьи.

И вот на этом фоне встречаются настоящие жемчужины, грех про них не рассказать. Вот, например, статья Яндекса про идемпотентность вызовов API на примере приложения такси. Тут всё прекрасно: и сторителлинг, и погружение в нюансы на понятном примере, и упаковка разных тем в одной статье. Потому что это она только называется "об идемпотентности" (то есть — об идентичных ответах API при нескольких идентичных вызовах), а на самом деле там говорится:
✅ про собственно идемпотентность
✅ про возможные ошибки связи (сервер не отвечал, сервер тормозил и случился таймаут, из-за разрыва связи не пришел ответ сервера и т.п.)
✅ про гонку параллельных запросов к БД
✅ про коды ошибок http (для чего применять не только 200, 403 и 404, но и другие, например, 410)
✅ про дубли (ошибка) и двойные заказы с одного адреса (нормальное поведение)
✅ про проксирование в запросах (и как это связано с идемпотентностью)
✅ про обработку таймаутов сервера и БД
✅ про то, как сделать POST идемпотентным и при чем тут токены
✅ про использование пользовательских сценариев для проектирования и проверки логики API
✅ про подсматривание хороших решений в других API (насмотренность при проектировании API очень важна!)
✅ про идемпотентность операций изменения и удаления
✅ про взаимодействие с внешними сервисами
✅ и даже немного про очереди сообщений и стратегии доставки ("как минимум один раз" или "как максимум один раз")

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

Пятничный анекдот. Зашел тут в одной дискуссии разговор про дэшборды: как их проектировать, что на них нужно показывать, особенно топ-менеджерам. Про это у меня есть прохладная былина, как мы в одном банке еженедельно перемалывали 1.5 млн. записей и выводили из них 2 (два) числа, потом печатали их 56 шрифтом на листе А4 📋, в нужный момент в нужном коридоре вставал сотрудник с этим листочком 👨‍💼, и когда по этому коридору пробегал зампред этого банка 🤴🏼, наш сотрудник пристраивался к нему на бегу 🏃 и показывал этот листок.

Эти два числа описывали состояние всего банка — хорошо ли ему, или что-то не в порядке :) Если вы следили за ситуацией с банкротством Silicon Valley Bank 🏦, подозреваю, что в SVB не было такой практики, поэтому они так и навернулись (шутка). В основном зампред кидал на листок короткий взгляд, кивал и бежал дальше. Но иногда он останавливался, и задавал вопрос: почему так⁉️ На что сотрудник доставал второй листок, на котором был график 📈, а на графике была отмечена точка, и подписано что-нибудь вроде "погашение второго транша займа Росгосгазнефти, 36 миллионов миллиардов USD". Ага, понятно, кивал зампред, и бежал дальше по своим делам.

В целом, оно так и работает: если у вас есть монитор с дэшбордом — то вы не такой уж крутой топ. Реальным топам референты приносят два листка с цифрами и одним графиком. А если вы мониторите какой-то там дэшбоард, ну это пониже уровнем работа. У начальника казначейства уже был свой дэшборд с 7-10 показателями, ну а у рядовых трейдеров обычно по 4-6 мониторов — на один вся информация не влезает. Чем "топовее" сотрудник, тем меньше показателей ему нужно отслеживать, тем более они агрегированные, и реже меняются. Люди в высшем руководстве определяют стратегию, а не реагируют на операционные моменты. Чем ближе "к полям" — тем чаще меняется информация, и тем быстрее на неё нужно реагировать.

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

Жена-психолог посмотрела, как я веду занятие по составлению user story и user story map, и сказала, что под видом системного анализа мы учим вообще мышлению :)

Ну что, в связи с последними новостями новую актуальность приобретает тема релокации. Что с перспективами IT в РФ — вообще непонятно. Пока выглядит так, что IT схлопывается до круга окологосударственных проектов, банков и очень крупных продуктовых компаний, а небольшие бодрые стартапы стараются стартовать сразу где-то вовне. С другой стороны, с нашей профессией не так-то просто понять — где именно она нужна. Вроде бы, например, Бюро занятости США числит профессию Computer Systems Analyst среди 100 самых востребованных, но при этом непонятно, что под этим подразумевается. Смотришь вакансии - и там то System Security Analyst, то специалист по настройке и внедрению SAP Hana. Как-то ни туда, ни туда не хочется. Я тоже про релокацию думаю — в первую очередь с точки зрения перспектив для себя и для детей. Но вот это непонятное позиционирование профессии смущает. Поэтому для себя пока продумываю вариант со стартапом — например, есть идеи в части применения ChatGPT в помощь аналитикам, PO и архитекторам. В общем, изучаю сейчас все эти моменты: и куда можно, как выбрать страну, и как запустить стартап.

И вот на эту тему есть гениальный канал, который меня вдохновляет - @kyrillic. Во-первых, автор - Кирилл Куликов - ведет жизнь цифрового кочевника уже больше 10 лет, и пожил (а не просто посетил!) в куче стран, и делится своим опытом по выбору страны, зачастую -- с очень неочевидных позиций, про которые сам не подумаешь, ну и по-человечески, а не в стиле копирайтера на зарплате. Видно, что человек знает, о чем пишет, и лично набил шишки и видел подводные камни. Ну а во-вторых, Кирилл - основатель стартапа Beau, проходил акселерацию в YC, и про развитие стартапа и опыт акселерации тоже рассказывает. Две пользы в одном канале! В общем, если ещё не читаете - всячески рекомендую, я читаю регулярно и про выбор стран (и в частности, про Испанию, про которую думаю сейчас) и про нюансы стартапов и выбор тем для них.

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

Я довольно часто на тренингах, да и в работе, сталкиваюсь с тем, что людям сложно разложить деятельность на составные части. Например, в случае 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, добавил себе в арсенал ещё оно возможное задание для собеседования аналитика (в том числе — для проверки диаграмм процессов): перечислить — а лучше нарисовать — последовательность событий в каком-то процессе.

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

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

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