В нескольких обсуждениях ценности системного аналитика проскользнул аргумент "один системный аналитик обеспечивает работой 5-6 разработчиков, а то и 8", — поэтому, получается, такое разделение труда выгодно.

Я сам в таких проектах был; ну 8 — это уже как-то много, а 4-6 — легко, вполне верю. Но тут я начал у всех выяснять — а какое у них соотношение? И большинство ответов пока — 1:2, а то и 1:1‼️

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

А какое у вас соотношение? Сколько приходится разработчиков на одного аналитика?

Пост про виды документов оказался самым комментируемым за всё время ведения канала!

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

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

Между тем почти все книги и стандарты у нас родом из 90-х, когда такой проблемы в принципе не было — системы в основном создавались с нуля, ну или переписывались целиком (тот же "Мифический человеко-месяц" — про переписывание системы).

А у нас сейчас в основном либо интеграция существующих систем, либо развитие существующих систем, либо надстраивание и конфигурирование коробочных решений и фреймворков (говоря языком ГОСТов — сборка и адаптация).
А эта тема так хорошо не отрефлексирована и не проработана. Не будешь же на каждую доработку расписывать полный пакет документов бизнес-уровня, да с анализом всех влияний и альтернатив! Быстрее просто сделать.

Интересная мысль, надо поискать целенаправленно именно такие книги/статьи/исследования.

На прошлой неделе был на конференции Infostart Tech Event. Это одна из крупнейших конференции по 1С. Сообщество 1С сейчас развивается с потрясающей скоростью, там много интересного. Но меня в основном интересовали доклады, не относящиеся напрямую к технологии, а рассказывающие про процессы и организацию работы. Посмотреть удалось не очень много, но вот что я для себя отметил:

1. Удивительно ёмкий доклад Павла Алферова про кризисные проекты. Я вообще не очень люблю рассказы про проектное управление, потому что, во-первых, работа над ИТ-продуктами это не проектная деятельность (а если её подгоняют про проект, то это зачастую ведёт к нехорошим последствиям); а, во-вторых, очень часто проектные ребята совершенно не учитывают содержание проекта и особенности выполнения работ.

Но мимо темы кризисных проектов я не мог пройти — я в принципе много работаю с кризисными проектами.
И тут Павел меня приятно порадовал. Начал он с исследований Standish Group — Chaos Report — с перспективой от 1994 до 2018 годов. Там 46% всех проектов challenged (то есть, были реализованы с отклонениями от начальных сроков, бюджетов или объемов), 19% вообще не были выполнены (это в 2018, в 1994 проваливались 35% проектов). Тут у меня сразу возник вопрос про обусловленность такого успеха — Standish это объясняет распространением практик Agile☝🏻.

Дальше вводится типология кризисных проектов: 1) в которых всё шло хорошо — то есть, проектные усилия были адекватны внешним условиям, но потом случилось что-то катастрофическое и внешние условия резко изменились; 2) в которых проектные усилия мееедленно расходились с внешней средой, и в какой-то момент стало уже поздно; 3) в которых проектные усилия никогда и не находились в соответствии с внешней средой (то есть, изначально обреченные проекты).

Был пример проекта внедрения 1С, в котором по отдельности все подсистемы работали, а вместе никак не соединялись, и вариантов выхода из него. Вариант, на удивление, был "перешли на работу по scrum", кто бы мог подумать-то, а! Про варианты спрашивали у зрителей, предлагая разные варианты действий. База таких вариантов и инструментов есть у автора. (прямо набор практик, как в OMG Essence!)

Проект, естественно, был из разряда "вроде всё шло хорошо, а потом оказалось, что ж*па". И дальше было обсуждение — а как же это на ранних стадиях выявить. Тут интересны две вещи: во-первых, пока заказчик проекта не осознает расхождение между проектными усилиями и внешней средой — бесполезно с ним разговаривать, не поймёт. В примере — если бы заказчику сразу предложили работать по scrum, он бы не согласился: вы же взяли на себя обязательства, ну вот и делайте, зачем ещё мне с вами каждую неделю встречаться и работу вашу проверять?! Дел других нет. То есть, признание руководства, о котором во всех проектных гайдах пишут, это ещё и признание, что проект находится в кризисе, и уже нужно что-то делать. Во-вторых, нужна система контрольных точек (сформулированных в форме объективно наблюдаемого и проверяемого состояния мира), и — вот это новое! — регулярный опрос ключевых вовлеченных в проект лиц по их оценке вероятности достижения следующих контрольных точек в срок. Ну просто как светофор: насколько вы уверены, что в такой-то срок доедем до такой-то точки? Верю, сомневаюсь, совсем не верю. И если будущие точки начали краснеть — это признак подбирающегося кризиса. Более детально метод описан здесь. Инструмент выглядит очень здраво, я сам таким светофором пользовался в одном из проектов ещё лет 15 назад (правда, не задумался тогда, что это что-то необычное и стоит про это рассказывать на конференциях).

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

Тут мнение докладчика таково, что не всегда можно сразу "продать" agile (ну да, заказчик сначала настроен оптимистично и не хочет сильно вкладываться), и что не всем проектам agile подходит, а вот есть радар выбора подходов к управлению проектами от PMI. Ну, я заодно нашел отличный сайт с картинками: https://www.pmillustrated.com/2-13-determine-project-approach/ , там есть картинка про выбор подхода, на основе трех областей и 9 показателей:

✅ команда (компактность, опыт, доступность клиентов/пользователей),
✅ проект (вероятность изменений первоначальных требований, безопасность проекта, возможность частичной поставки),
✅ культура (готовность заказчика к agile, доверие между стейкхолдерами и командой, готовность заказчика передать часть решений команде).

В зависимости ответов на эти вопросы строится "паутинка" - и по её виду можно понять, какой подход вам более подойдёт -- agile, плановый, или гибридный. Сам автор как раз предлагает на впадать в крайности и ориентироваться на гибридные подходы, но это уже за рамками доклада.

2. Доклад Евгения Мазуренко из Ozon Tech "Как управлять проектами и не терять связь с заказчиком". Рассказ про устройство процесса, люблю такое.

У них это сделано так: на каждый домен (почти продукт, но это внутренняя разработка; в общем — то, что решает определенный набор задач бизнеса) имеется технический комитет, собранный из представителей бизнес-заказчиков. ИТ-шники тоже в нём участвуют, но в роли наблюдателей и консультантов. А вот представители заказчиков между собой определяют приоритеты задач, предварительно оцененных разработкой. То есть, задачи могут прилетать от разных заказчиков, но всё равно все рассматриваются через техком, и никак иначе в работу не попадают. Для рассмотрения на техкоме задачи оцениваются по значимости — по системе влияния на метрики с весами метрик. Каждый техком формирует набор таких метрик самостоятельно, силами представителей заказчиков. Метрики стараются приводить к деньгам. Чтобы уровнять фичи с коротким сроком окупаемости и с длинным, берут оценку денег в расчете на 3 года.

Сложность задач команда оценивает в "майках" — от XS до XXXL, которым соответствуют человеко-дни. Задачи размера XS на техкоме не приоритизируются, просто берутся в работу, когда есть окно. Кроме того, у команды есть зарезервированное время на погашение техдолга и на поддержку. Фичи, рассмотренные на техкоме, то есть проекты, связываются с задачами в Jira. Сами заказчики в Jira не ходят, отслеживают записи техкомов, для этого есть специальный софт. В этом софте видны статусы всех проектов. Разработчики должны обновлять статус проекта каждые две недели. Если ничего не изменилось -- пишут, почему ничего не изменилось (например, более срочные задачи или ждут другой домен). Так бизнес всегда в курсе, что происходит.

Теперь самое интересное: где тут аналитики (это я потом в кулуарах спрашивал, в докладе этого нет). А аналитики тут в самом начале! То есть, приходит заказчик с запросом, и аналитик прорабатывает этот запрос до такого состояния, чтобы команда могла его оценить. Если техком собирается раз в две недели, у аналитиков есть две недели на то, чтобы разобраться с новыми запросами. Число аналитиков разное в зависимости от домена, но их много, 1/2-1/3.

В общем, процесс выглядит очень разумно. Записей докладов с Infostart Tech Event пока нет, но я нашел запись того же доклада с недавнего митапа: https://www.youtube.com/watch?v=E7mOy2vr2hc&t=1080s

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

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

Вот из недавнего: чуть ли не в каждой статье про важность soft-skills (особенно от HR-ов или edTech-ов) встречается фраза, причём дословно:
"Ученые из Гарварда, Стэнфорда и Фонда Карнеги выяснили, что «гибкие навыки» — это 85% успеха человека в профессии, жесткие составляют только 15%."

Её, кажется, первым запустил РБК, а потом все стали друг у друга перепечатывать.

Интересно, что такое исследование действительно существует! Но есть нюанс — это исследование 1918 года! Не опечатка — 1918, более 100 лет назад. В исследовании американским инженерам задавали вопрос: что им больше всего помогает при выполнении проектов? И они отвечали, что твердость характера. Такой вот софт-скилл. Другие упоминаемые качества: ясность суждений, производительность, понимание людей и широта знаний. Такой набор, а не то, что сейчас под софт-скиллами понимается — типа, быть милым, эмпатичным и поддерживать нетворкинг.

То есть, с одной стороны, любопытно, что исследования эти ведутся ещё с XIX века (в том журнале есть ссылки и на исследования 1880-х годов), но неужели нет более свежих работ? И правда ли мы сейчас собираемся опираться на опыт американских инженеров времён Первой мировой? Впрочем, качества-то перечислены полезные.

Немного об интеграциях:

— У нас на проекте Кафка.
— Для маршрутизации сообщений?
— ...
— Для маршрутизации сообщений, верно ведь?..

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

🔥 Подборка материалов от телеграм-канала Системный Аналитик

📚 20 лучших книг для развития аналитика — можно скачать бесплатно

📨 Брокеры сообщений: Kafka и RabbitMQ, сравнение Kafka vs Rabbit

🏭 PlantUML с нуля

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

▶️ Подборка бесплатных вебинаров по основам интеграции систем

📎 Подборка материалов по изучению REST

🖇 Подборка бесплатных материалов про асинхронную интеграцию и очереди сообщений

🌐 HTTP. Что нужно знать аналитику

⚙️ Интеграция через API. Кратко

🤓 Задачник для системных аналитиков от Тинькофф

🧿 Виртуализация, контейнеризация и оркестрация

💪 Карта навыков системного аналитика

🧮 Про нефункциональные требования

🆚 Сравнение REST vs SOAP, gRPC vs REST, GraphQL vs REST

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

И уже есть запись: https://www.youtube.com/live/uRQuVT1xxMY?si=Xfnojsa0GGl05kHx

Вначале там выступление Анастасии Тарасовой из Самоката про аналитика как координатора кросс-доменных проектов, потом Жени Скорикова из AWG про подход к разработке нефункциональных требований (что бессмысленно просто давать какие-то значения доступности или надежности, а нужно предлагать бизнесу баланс значений и затрат на их обеспечение — ну, там у Жени целая методика).

А потом, с 2:18:50 — наш круглый стол.

Сформулировал в одной дискуссии положения про метрики API:

1⃣ Есть три уровня метрик: инфраструктурные (что с железом и каналами) , прикладные (что с запросами и ответами, токенами и т.д)
и продуктовые/бизнесовые (что с качеством данных, бизнес-процессами, клиентами).

2⃣ С точки зрения измерений, что меряем:
- производительность/ресурсы (CPU/память/IO/сеть), RPS;
- скорость/задержки (latency: среднее, максимальное, 95 перцентиль, 99 перцентиль),
- число ошибок (4xx, 5xx);
- консистентность ответов (соответствие структуры, полнота, отсутствие дублей, соответствие размера/распределения ответа ожидаемому).

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

Соответственно, настраиваем мониторинг и алерты этих показателей на выход за установленные пределы или на приближение к пределам (например, при определенном числе фейлов перепосылок за какое-то время).

Вот неплохая статья про метрики открытого API: https://www.moesif.com/blog/technical/api-metrics/API-Metrics-That-Every-Platform-Team-Should-be-Tracking/

А вот ещё одна, более техническая: https://learn.microsoft.com/en-us/azure/architecture/best-practices/monitoring (не смотрите, что про Azure, там метрики универсальные).

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

Делюсь с вами алгоритмом, по которому я обычно думаю, когда сталкиваюсь с интеграциями:

1. Анализ бизнес-потребности. Зачем нам интеграция? Какие бизнес-процессы или юскейсы она будет поддерживать?
2. Какие системы участвуют в интеграции? В каких системах есть данные, и в каких системах они в результате интеграции должны оказаться?
3. Детализированные функциональные требования: какая система в какой ситуации должна показать или использовать данные из другой системы; сделать запрос; передать данные по своей инициативе. Тут мы предварительно можем прикинуть, ну или хотя бы обсудить: кто является инициатором обмена? Синхронный или асинхронный обмен? Какой стиль интеграции мы можем использовать? (Передача файлов, общую БД, синхронные вызовы/веб-хуки/сокеты, асинхронный обмен через промежуточную среду/очередь). Какой паттерн управления обменом используем: оркестрацию или хореографию?
4. Регламент обмена данными в виде таблицы: | система источник | система приёмник | расписание или событие, по которому стартует передача | что именно передается: один объект, набор объектов, по какому признаку отфильтрованы? Какие поля объектов: все; явно перечисленные; только изменившиеся?.. Нужна ли агрегация или расчеты? | — это стараемся писать точки зрения бизнеса.
5. Количественные показатели интеграции: ожидаемая интенсивность (частота передач), ожидаемый объем (одной порции данных), это разовая передача или потоковая, перспективы роста интенсивности и объемов, число систем-клиентов - тут мы пытаемся понять, есть у нас где-то хайлоад, или всё так просто. Если какой-то показатель вылезает за миллионы или тысячи/сек., то дальше уже всё проектируем гораздо аккуратнее. Результат можно зафиксировать в виде НФТ или показателей качества, добавив требования к доступности, настраиваемости и безопасности.
6. Детальная спецификация данных. Тут нужно выявить — в каких системах в каком виде данные лежат, кто является мастер-источником для каких данных, что именно нужно передавать, какие использовать идентификаторы(!), откуда берем и как синхронизируем справочники.
7. Преобразования и мэппинги. Поняв структуры данных, описываем их преобразования и как они друг на друга маппируются. (Часто всё проектирование интеграций только к этому пункту сводится, а остальные аспекты игнорируются и реализуются как придётся, без анализа).
8. Способы взаимодействия: синхронное/асинхронное, прямое/через промежуточную очередь, оркестрация/хореография, что вообще интегрируемые системы могут, а то может там только файловый обмен возможен. Как обеспечиваем требования безопасности, нужно ли шифрование/хэширование/маскирование/обезличивание, как устроена аутентификация и проверка полномочий.
9. Детальный сценарий обмена (диаграмма последовательности + текстовый сценарий).
10. Общие требования к обработке ошибок, журналированию, мониторингу. Где-то тут, когда начинаем думать про ошибки, возникают вопросы про гарантию доставки, идемпотентность и хранение переданных ранее данных. По обработке ошибок по сути у нас два решения: а) система, обнаружившая ошибку (кстати, кто может обнаружить ошибку?), пытается её исправить; б) система оповещает людей, которые уже сами пытаются решить проблему. Эти решения не взаимоисключающие. Кроме того, нужно зафиксировать ошибку в журнале (в каком? что именно записать? и т.п.).
11. Выбираем уже окончательно стиль интеграции и конкретную технологию или решение.
12. Проходим пункты 7-10 ещё раз, фиксируя конкретные и детальные решения, связанные с выбранной технологией. Дальше уже проект интеграции дробится на требования к каждой отдельной системе, участвующей в интеграции.

Вот, кстати, отличная статья Анны Овзяк про проектирование интеграций: https://habr.com/ru/companies/alfa/articles/770184/

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

Попал вчера аж в Центральный дом ученых на разговор про современное образование.

И вот какая там мысль проскочила (в связи с ИИ, куда же без него): формула образования — KSA, knowledge-skills-attitudes, знания-навыки-отношение (чувства, эмоции, убеждения, ценности). Причем attitude — это не soft-skills, это вообще не skills. Это то, что мотивирует человека применять тот или иной skill. (Поэтому я не очень люблю разговоры про софт-скиллы, они замещают разговор о ценностях и выборе поведения). Я про эту тройку уже как-то писал в канале — какие качества нужны аналитику.

Так вот в связи с ИИ высказывалось предположение, что знания человек может получить опосредовано — например, из книг или видео. Навык может быт натренирован частым повторением (тут дело быстрее идёт, когда тебя корректируют, но корректировать необязательно должен человек — если вам знакома зелёная сова, то она отлично с этим справляется при изучении языков), а вот сформировать ценности и убеждения в нас могут только другие люди: родители, друзья, среда, наставники в профессии. И вот эту среду ни ИИ, ни цифровые технологии нам организовать пока не могут. Поэтому цифровое обучение вполне эффективно при формировании knowledge и skills и почти не способно сформировать attitudes (т.к. не образует среды и образца поведения).

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

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

Давно не писал про ChatGPT. Но и новостей особо нет, работает привычно-штатно. Бросить в него алгоритм взаимодействия, построить диаграмму последовательности — уже на автомате. Кстати, он теперь сам начал подсказывать, куда её вставить (почему-то рекомендует PlantText.com)

Из нового: попробовал составлять руководство пользователя. Отлично получается.
Что можно делать:
➡️ преобразовывать в ГОСТовскую структуру неформальное описание (например, разработчик, как смог, описал; или из требований сделать руководство).
➡️ составлять руководство на основе кода или скриншотов(!) — а вот это новое, правда, доступно только в 4 версии.

Запрос:

Я создал интернет-сайт на тему <...>. На сайте размещены статьи по разным аспектам этой темы, пользователи могут регистрироваться, проходить опросы и добавлять комментарии под статьями.

Мне нужно составить руководство модератора по следующей структуре:
1 Введение
1.1 Область применения
1.2 Краткое описание возможностей
1.3 Уровень подготовки пользователя
1.4 Перечень эксплуатационной документации
2 НАЗНАЧЕНИЕ И УСЛОВИЯ ПРИМЕНЕНИЯ
2.1 Виды деятельности, функции
2.2 Программные и аппаратные требования к системе
3 ПОДГОТОВКА К РАБОТЕ
3.1 Запуск системы
4 ОПИСАНИЕ ВЫПОЛНЕНИЯ ОТДЕЛЬНЫХ ОПЕРАЦИЙ
4.1. Наименование операции
4.2 Условия выполнения операции
4.3 Подготовительные действия
4.4 Основные действия
5 АВАРИЙНЫЕ СИТУАЦИИ

Ответь мне на это сообщение словом "Понял". В следующем сообщении я дам тебе неформальное описание функций модератора (или: описание требований к функциям модератора) - приведи их к указанной выше структуре.

Генерация руководства по коду страницы:

На странице сайта есть комментарии. Вот код страницы с комментариями: <html-код, сколько влезет в промпт>
Напиши инструкцию модератора для работы с комментариями.

Результат:

4.4.9. Управление комментариями

4.4.9.1 Наименование операции: Управление комментариями.

4.4.9.2 Условия выполнения операции: Модератор имеет доступ к административной зоне сайта.

4.4.9.3 Подготовительные действия: Модератор переходит на страницу с комментариями.

4.4.9.4 Основные действия:
- Просмотр комментариев:
Модератор просматривает все комментарии на странице, обратив внимание на текст, авторов, дату и рейтинг комментариев.

- Редактирование комментариев:
Если необходимо внести изменения в комментарий, модератор выбирает соответствующий комментарий и нажимает на кнопку "Редактировать." Затем модератор вносит необходимые изменения в текст комментария и сохраняет изменения.

- Удаление комментариев:
Если какой-либо комментарий нарушает правила сайта или несет в себе ненадежную информацию, модератор выбирает этот комментарий и нажимает на кнопку "Удалить." Комментарий будет удален.

- Ответ на комментарии:
Модератор может отвечать на комментарии, нажав на ссылку "Ответить" под комментарием. После этого модератор может написать ответ в текстовом поле, и ответ будет опубликован после сохранения.

4.4.9.5 Описание блока комментариев
Блок комментариев представляет собой прямоугольную область на странице под статьей или записью.
Верхняя часть блока содержит заголовок "Комментарии" и количество комментариев (например, "2" в данном случае).

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

Каждый комментарий имеет следующие элементы:
- Аватар (изображение пользователя).
- Имя пользователя.
- Текст комментария.
- Дата и время добавления комментария.
- Действия с комментарием (ответить, редактировать, удалить).
- Рейтинг комментария (положительный и отрицательный).

Ниже списка комментариев расположена форма для добавления нового комментария. Форма включает следующие элементы:
- Поля для ввода имени пользователя и email (возможно скрыты).
- Текстовое поле для написания нового комментария.
- Кнопки "Сохранить" и "Отменить" для отправки или отмены добавления комментария.

А вот это уже интересно: составление описания и инструкции пользователя по скриншоту экрана! Доступно только в платной подписке GPT 4, но зацените уровень "чтения" картинки.

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

А вот генерация интерактивных прототипов из... да из всего генерация! хоть из мокапа, хоть из диаграммы состояний