Еее! 2000 подписчиков на канале! Спасибо, друзья! 🎉🍾🏅


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

В опросе многие отметили, что хотят больше материалов по архитектуре. Принял к сведению!

А вот вам пока воркшоп сразу по трем темам, имеющим отношение к архитектуре: проектирование структур данных в реляционных и нереляционных БД, языки запросов у ним и микросервисы!

Давно искал такую шпаргалку. И для себя, и участникам тренингов показывать. Например, после выделения сервисов в Event Storming, чтобы принять предварительные архитектурные решения. Правда, говорят, правую часть можно смело заменить на Postgres, Postgres, Postgres,..., Mongo, Elastic, FileStorage, и на этом успокоиться :)

Завершил сегодня очередной поток курса "Основы проектирования интеграций ИТ-систем", понял, что одно из самых важных умений, которым мы учим — способность аналитика понимать фразы типа:

"Решение на основе семантики «at most once» с использованием мультипроцессингового пула в условиях неидемпотентности запросов и возможности организации обратной связи между консюмером и продюсером даёт следующие возможности: <...>“

— и не просто понимать, а уметь эти решения обсуждать и оценивать. То есть, фактически, переходить от systems analysis к systems design.

Очень интересно, насколько часто возникает вопрос про сравнение REST, SOAP, GraphQL, gRPC и лучший выбор одного или другого в конкретных условиях. При этом REST — это архитектурный стиль или набор принципов, SOAP — стандартизированный протокол, GraphQL — язык запросов, а gRPC — программный фреймворк :))

Вопрос получается типа: "что лучше выбрать для работы: Agile Manifesto, ГОСТ 34, Jira или UML?" 🤦🏼‍♂️

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

Интересная картинка сравнения возможностей проприетарных и открытых моделей. По кодингу и умениям делать выводы GPT-4 пока впереди, а вот по написанию "просто текстов" и по гуманитарным вопросам Викуна уже практически сравнялась.

Ну и собственно самое главное.

По этому бенчмарку видно, насколько существенна разница в разных группах вопросов между моделями. Самый большой отрыв в Reasoning и Coding, там просто нет моделей, хотя бы приближающихся по уровню к GPT-4.

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

Ну и минорное - авторы выпустили новые модели Vicuna v1.3 размерами от 7 до 33 миллиардов параметров. Веса забирать здесь.

ProductSense и Нетология выпустили очередное исследование про менеджеров продуктов, а так как я как раз он, любопытно было взглянуть на коллег и настроения в отрасли. Из интересного: 37 человек (из 1121) таки назвали себя Technical Product Manager, я уж думал их в РФ совсем нет. Вместе с Platform PM (11%) — это интересная смежная роль, куда могут переходить системные аналитики, если хотят больше влиять на развитие своих систем (в принципе, это похоже на мой карьерный путь).

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

Интересный показатель -- размер компании. Почти половина всех продактов работает в крупных компаниях (от 1000 сотрудников, 28% — от 5000 сотрудников). Выглядит так, что в управление продуктом играют только те, кто может себе это позволить, а остальные как-то так обходятся. При этом в маленьких компаниях легче получить должность Head of Product или CPO (ну да, я в своё время просто попросил, чтобы должность называлась директор по продуктам, и так стал CPO 🤷🏼‍♂️).

По индустриям: банки, edTech, доставка еды и маркетплейсы. Именно в таком порядке! Даже не знаю, какой из этого сделать вывод. Как говорила Алиса у Кэрролла, наводит на мысли, только неясно, на какие. Ну, кроме того, что я классно выбираю отрасли: 10 лет в финтехе, и вот скоро будет 10 лет как в эдтехе, самый топ. Ну и можно представить себе, как человек берет кредит, тратит его на обучение, заказывает еду, чтобы не отрываться от просмотра видео, а потом распродает вещи, чтобы этот кредит вернуть. И идёт работать продактом, очевидно.

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

В общем, если нанимаете продактов или хотите стать продактом — рекомендую, любопытное чтение!

Если вы затрудняетесь в оценке полезности вашего документа и его уровня JBGE (Just Barely Good Enough) — воспользуйтесь формулой CRUFT[1]:

Полезность документа = C*R*U*F*T,

где
C — correct — доля корректной информации в документе,
R — read — вероятность того, что документ вообще будут читать,
U — understood — %% информации в документе, которую поймут его читатели,
F — followed — шанс, что требованиям и указаниям, содержащиеся в документе, будут следовать,
T — trusted — вероятность того, что документу будут доверять.

Если по формуле у вас получаются низкие значения, то выходит не документ, а CRUFT, то есть "хлам" в переводе.

Обратите внимание, что в формуле перемножаются вероятности, то есть ценность документа падает очень быстро (снижение каждого показателя на 20% приводит к итоговой общей ценности документа в районе 32%).

Для оценки корректности и полноты требований в случае применения BRUF-подхода (Big Requirements Up Front, попытки разработки всех требований в начале проекта) можно взять 45% — средний показатель доли начальных требований, действительно реализованных в итоговом продукте (по данным Chaos Report).

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

[1] https://www.drdobbs.com/architecture-and-design/dr-dobbs-agile-modeling-newsletter/201001273

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

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

Почему-то аналитики раньше были обделены митапами. У программистов они были, у UX-еров, у тестировщиков, а у аналитиков как-то не особо.

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

Ну и после пандемийного безальтернативного онлайна пошёл откат — люди хотят встречаться вживую. И начались аналитические митапы! В Москве, а теперь и в Питере — можно прийти, посмотреть на коллег, задать вопросы и обменяться опытом 🙂

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

Попробовал на одной картинке показать — на каком уровне работают разные методы групповой работы по выявлению требований и идей — Impact mapping, User story mapping, Event Storming.

Получилось похоже на водопад, но это не он. Тут скорее как в JBGE — максимум пара недель на начальное моделирование, а потом уже в цикле по итерациям, корректируя более высокие уровни. IM и ES как раз по несколько часов занимают.

Небольшой опрос: с какой проблемой вы сталкивались или сталкиваетесь сейчас в работе, но эта проблема не описана ни в одной книге или стандарте, и непонятно, как её решать?

Напишите в комментах 👇

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

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

То есть, по сути, менеджерские задачи: по самоменеджменту и по менеджменту других людей (кто сказал — это не задача аналитика? А стейкхолдеров и разработчиков за вас кто менеджерить будет, чтобы они включались в работу над требованиями?..). По первому пункту крайне рекомендую книги и выступления Максима Дорофеева — главное, конечно, не просто послушать, а пробовать сделать. Кратный буст к числу выполненных задач с одновременным снижением тревожности — это впечатляет. Ну и технику "12-недельный год" — тоже очень крутая тема.

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

Привет! Если вы меня потеряли — я ушел в творческий отпуск :) Но совсем отключиться не получилось — буквально в чистом поле меня поймали организаторы подкаста FlowLive и записали со мной выпуск про создание образовательных продуктов для аналитиков: https://www.youtube.com/watch?v=wGGwncJSMcM (выходит завтра, поставьте колокольчик, чтобы не пропустить!). Поговорили про то, какие темы востребованы, и что главное в учебном курсе. Enjoy! Ну и жду вопросов и обсуждений 🙏🏻