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

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

Давно искал такую шпаргалку. И для себя, и участникам тренингов показывать. Например, после выделения сервисов в 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! Ну и жду вопросов и обсуждений 🙏🏻

Если бы я попал на необитаемый остров, и мог бы взять с собой только одну книгу по системному анализу и разработке требований, я бы взял Руководство по написанию требований от INCOSE (Международный совет по системной инженерии). Что удивительно, это руководство есть в переводе на русский язык, я даже немного участвовал в его создании (настолько немного, что я не упомянут среди команды переводчиков и рецензентов).

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

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

Концепция эксплуатации (Operational Concept, OpsCon), в свою очередь, описывает систему, которая реализует стратегию или её часть. То есть, это когда мы уже приняли решение, что у нас вот тут будет какая-то система, и описываем, как мы собираемся с ней работать. Уже из этой концепции мы, путем формальных преобразований, можем прийти к анализу потребностей и, наконец, к требованиям. Всё это звучит довольно заумно, но в Руководстве есть отличная история, живо показывающая всю цепочку (я прямо узнал все свои проекты, и вздрогнул, а также вспомнил анекдот про японскую бензопилу):

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

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

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

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