Похоже, последнее время теория ограничений начинает просачиваться в массы. Будь моя воля, я бы насильно заставлял изучать ее всех аналитиков и манагеров. Проблема в том, что делать это самостоятельно и без практики - занятие крайне неблагодарное, поэтому после книги Детмера пошел искать, учат ли где такому.

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

В общем, мне курс дико зашел, жду продолжения. А вы пока можете попасть на второй поток.
Описание инструментов: https://news.1rj.ru/str/AABryzgalova/35

Пара стримов с демо-версией инструментов:
• Про НЖЯ: https://www.youtube.com/live/QLtTNRYorzY
• Про негативную ветвь: https://www.youtube.com/watch?v=CX99u3ysG8w

#ненависть #оффтоп
Последний год наблюдения за “обучающим контентом” для сисаналитиков приводят в какой-то хтонический ужас. Такое ощущение, что большая часть постов, статей и стримов создается по принципу: автор прочитал пару статеек или посмотрел видосик в сети, наслушался рассуждений разрабов и пошел нести свет в массы. О том, что сам толком в детали не погружался и на практике с ними не работал, беспокоиться не стоит - нужно красиво оформить и убедительно говорить, менее опытная аудитория проблем не увидит.

Причем вскрываются фактические ошибки понимания общедоступных технологий: http, soap, устройство kafka и прочее, где доступны все исходные спецификации. Но не читать же их, в конце концов. Приходишь в личку, указываешь на проблемы, скидываешь материалы - спасибо, ваше мнение очень важно для нас. Дальше ничего не меняется. Последний случай доставил особо - автор генерит в блог откровенную дичь с помощью ChatGPT и после прямо заявляет об этом. Аплодирую стоя.

И ладно бы на этом история заканчивалась, так эти же гуру потом идут продавать свои сакральные знания, выдавая их за “образовательный” продукт. И, конечно, обещают обучить профессии за 2-3 месяца, без образования, регистрации и смс. В такие моменты жалею, что нет процедуры принудительной аттестации любой образовательной деятельности.

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

#продуктовое
Продуктовая идея, для желающих войти в волшебный мир it-образования. По мотивам прошлого поста.

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

Например:
• Даем продактам базовое введение в технику, и разработка перестает смотреть на них как на инопланетян
• Учим аналитиков основам проектирования систем, и архитекторы с техлидами начинают воспринимать их не только как записную книжку
• Знакомим лидов разработки с основами работы с продуктовыми метриками и приоритезацией беклога, и вот уже ваш бизнес сияет от счастья

В чем профит?
1. Никто не предъявит выпускникам за неточности и поверхностное понимание темы - от них этого никто не ждет
2. Коммуникации со смежными ролями становятся проще, поэтому выпускники искренне благодарны вам

Главное - не нужно глубоко изучать предмет или нанимать экспертов. В идеале вообще собрать материалы популярного эксперта, дообучить на них гпт-модельку и генерить обучающий контент. Дополнить p2p обучением с активными нетворкингом и затраты на экспертов вообще станут минимальными.

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

WIN-WIN-WIN. Не благодарите.

«Важно самому разбираться в теме, которую делегируешь»

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

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

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

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

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

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

7. В общем, искусство делегирования держится на трёх китах — а) умение разбираться в людях, б) умение описывать желаемые результаты на языке бизнеса и в) умение дождаться результата, каким бы он ни оказался.

💪 Ещё больше инсайтов — в моих ежедневных разборах интересных стартапов на fastfounder.ru/news

#интеграция #api
Я как-то писал, что внешнее обучение дает профит, когда уже появилась привычка самостоятельно копать тему. Если вы ждали повода, чтобы начать - вот он: https://news.1rj.ru/str/nextway_news/86

#оффтоп
Смотрю на новости и скандалы о том, как ленивые студенты и школьники делают дипломы-домашки в ChatGPT, не хотят сами думать и работать.

Проблема, конечно, страшная. Уже несколько веков человечество непрерывно тупеет:
• сначала люди разучились самостоятельно ориентироваться на местности, добывать огонь и пищу в дикой природе
• разучились делать серьезные вычисления без калькулятора
• отвыкли читать книги и запоминать информацию, гугл с тиктоками всем подавай

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

#интеграция
- Как системному аналитику выбрать технологию интеграции?
- Никак

Потому что аналитик мыслит и работает вообще в другой плоскости. При выборе в первую очередь придется отвечать на вопросы:
• На сколько решение привязывает к конкретным фреймворкам и реализациям?
• На сколько развиты сопутствующие инструменты разработки и инфры?
• Умеет ли команда работать с технологией?
• Сможем нанимать нужных людей?
• Кто развивает, на сколько распространена, какое комьюнити вокруг?

Дополнить это великолепие аналитик может за счет НФТ, и отсекая откровенную дичь в духе “SOAP для мобилки”. Правда, редкое НФТ относится к интеграции, а не к системе, а со второй задачей опытный инженер справится всяко лучше.
Вероятно, полезнее сосредоточиться на изучении конкретной технологии-протокола, его влиянии на поведение и ограничения системы, чем погружаться в метафизику и изучение абстрактных критериев, алгоритмов, чек-листов выбора решения в вакууме.

В ходе конференции ЛАФ сделал наблюдение, которое, на мой взгляд, заслуживает отдельного обсуждения. У многих аналитиков неявно есть "учебный" взгляд на работу. Что я имею ввиду? Когда вы учились в школе и, позднее, в институте, ко всем учебным заданиям существовала инструкция, как его сделать, чтобы получить хорошую оценку. Понятно, что задания могли быть разные, предполагать творчество, например, сочинение, учебный проект или диплом, но это творчество касалось определенных элементов и по их поводу инструкция тоже в некотором виде. А еще критерием успеха являлась именно полученная оценка, которую поставит преподаватель, и эта оценка "по умолчанию" считалась верной, изменить ее требовало очень больших усилий. И дальше все это проявляется и на конференции и в работе: от докладов ждут, что там будет такая инструкция, по которым можно выполнять свою работу. А оценкой работы считают мнение принимающего твой документ, а применимость документа для следующего шага. И неявно предполагают, что оценка зависит именно от следования правилам.

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

Чтобы перейти от такого подхода к реальной работе на достижение результата надо менять мышление. Такие тренинги есть для руководителей, это переходе понимания ответственности от responsibility к accountability, но вот для аналитиков таких материалов нет, этому не учат, и вообще тема не находится в фокусе внимания. И, возможно, стоит подумать в этом направлении при подготовке конференций. Впрочем, я могу ошибаться и переоценивать значимость проблемы. Что думаете?

#конфа
Семь раз отложи и запости в последний день. Мы в NextWay делаем двухдневную конфу, которая начнется уже завтра. Будет два акта: открытый день докладов в субботу, и четыре воркшопа в воскресенье, уже по билетам.
Большая часть докладов рассчитана на аналитиков уровня junior-middle, а воркшопы должны хорошо зайти для специалистов middle+.

Кто о чем, а я снова о проектировании, поэтому от себя выделю активности:

Работа с НФТ - первый шаг на пути проектирования, чтобы задавать правильные вопросы.

ETL-интеграции без валидола. Проектируем вместе - когда интеграция не только про ресты, но и про данные.

Как Кэти Перри сломала Twitter. Проектируем архитектуру высоконагруженных приложений - для тех, кто ищет опыта в system design.

Kafka Fuckup Stories - несколько историй о том, как (не) выстрелить себе в ногу, если вы уже работали с кафкой.

BA in English: Mission (Im)possible? - воркшоп по работе с требованиями на английском. Просто злободневненько.

Для желающих попасть на день воркшопов промик на 10% - NWC23API

#оффтоп

- У нас в компании Event Driven Architecture
- Помойка сообщений в одной очереди?
- Все так

#продуктовое
Пока копал тему хорошего UX для чекаутов и форм оплат, нашел ресурс с кучей классных гайдов по построению UX в ecommerce и около.

Утащил себе несколько для работы:
• Проблемы и лучшие практики для формы оплаты картой
• Обзор форм оплаты маркетплейсов на мобилках
• Пейволлы в мобильных приложениях: часть 1 и часть 2
• Офрмление доставки на чекауте

#конференции
Во понедельник-вторник пройдет оффлайн часть FlowConf, где буду вещать про кафку и ее устройство. Действо в формате воркшопа, будем говорить, рисовать и думать, почему оно все так устроено. Приходите, говорящей головы будет минимум.
Ах да, записи не будет.

И вообще, кто еще пойдет на Flow?

Не люблю все эти блохерские истории с партнерскими постами, но тут не могу пройти мимо. Тем более, сам читаю периодически.

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

Плюс регулярно появляются приятные полезняшки. Например, я себе утащил:

• Классная подборка открытых API на любой вкус и цвет: REST-like, GraphQL, WebSockets, JSON-RPC, etc.

• Материалы по нефункциональным требованиям - как бы аналитики не сопротивлялись

• Интересно и просто о балансировке

• Подборка по БД и SQL - от первого знакомства до глубокого погружения

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

#архитектура

Много букв про НФТ
Глубокая статья Евгения Скорикова о нефункциональных требованиях атрибутах качества системы.
Автор предлагает методику проработки и обеспечения качества системы с большим набором примеров. Но интересно другое, через всю статью проходит две важные мысли:

1. Реальные значения технических метрик, которые мы ждем от системы, исходят из нужд бизнеса/продукт

2. Сами по себе нефункциональные требования не имеют смысла, если мы не понимаем, как они будет обеспечены на уровне системы

Если проще, то выявление и обеспечение НФТ - это непрерывный поиск компромиссов между “продуктом” и “техникой”.

С одной стороны, нам нужно глубоко понимать бизнес и продукт:
• текущие цели бизнеса: заработок, привлечение пользователей, поддержка экосистемы или еще что-то
• модель монетизации продукта
• ключевые продуктовые метрики, что нужно растить, чем можно пренебречь
• UX, поведение и потребности пользователя

С другой - понимание архитектуры системы, причем полного цикла:
• компоненты системы и используемые архитектурные паттерны
• принципы проектирования распределенных систем
• подходы к обеспечению производительности, отказоустойчивость, масштабируемости и т.д.
• способы интеграции
• хранилища данных
• методики и инструменты тестирования
• сети, железо, инфра, CI/CD

И это все еще нужно уметь оценить по сложности разработки и стоимости.

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

Таким образом нефункиональные требования определяют не только архитектуру системы, но и влияют на функциональные требования к ней. Причем то, что для системы является НФТ, для ее компонентов выливается в ряд вполне конкретных ФТ.

Становится понятно, почему аналитики так неохотно думают про НФТ.
У подавляющего большинства нет кругозора и практического опыта работы с “глубокой техникой”. Редкий аналитик погружается дальше вопросов интеграции и хранилищ данных. При этом оценка и обоснование НФТ с бизнесовой точки зрения - это исследовательский и трудноформализуемый процесс, который не слишком укладывается в массовый интерес к архитектуре. Мне он во многом напоминает процесс исследования рынка - такой же неопределенный и творческий.

Морали здесь не будет. Рекомендую медленно и вдумчиво прочитать статью.
А еще видосик про оценку некоторых технических метрик.

Написал и понял, почему не принимаю инженерию требований как вещь в себе. Не может сферический Requirements Engineer без технического беграунда и понимания внутренностей системы проектировать адекватные реализуемые нефункциональные требования. Т.е. все равно придется идти разбираться с бизнесом, продуктом, пользователями и договариваться о финальном решении.
А портянку требований почитают, согласуют пару раз и спрячут, чтобы разработчика не травмировать. Может к контракту приложат, для спокойствия юристов и сейлзов.

Less is more

Удивительно, насколько менеджеры любят решать проблемы умножением сущностей вместо их уменьшения. Медленно идёт проект? Добавим людей! Сомневаемся, что продукт полезен аудитории? Добавим фичей! Программисты катят в прод фигню? Сделаем ручное тестирование!

Гораздо проще добавить на проект человека, чем найти проблему в коммуникации и, наоборот, удалить парочку лишних. К тому же не придётся принимать дополнительную ответственность — попробуй объяснить бизнесу, что команда из 5 человек работает быстрее, чем команда из 8.

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

Или представьте себе тусовку владельцев бизнеса, где кто-нибудь жалуется, что не может найти правильного CPO? Конечно он получит сочувствие — каждый руководитель хоть раз был в похожй ситуации. А если честно рассказать, что не понимаешь, как управлять своим продуктом, не можешь уделить время анализу глубоких метрик и найти время на разговоры с пользователями? Скорее всего просто не поймут.

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

Кажется, что не делать вещи может быть гораздо ценнее, чем делать.

Есть кто на TeamLead Conf?
Заглядывайте на чаек

#ненависть #оффтоп
Величайшее изобретение человечества в IT - это годовые премии.
Под конец каждого отчетного периода просыпаются манагеры и бросаются усиленно изучать свои OKR и KPI, чтобы на хлебушек было что намазать. И начинается безудержное новогоднее веселье: здесь нужно срезать скоуп и запилить невнятный MVP на 10 человек, там напихать костылей в надежде когда-нибудь это отрефакторить, запустить сервис без мониторинга и адекватной инфры, а критичные процессы оставить на ручном приводе. Пей, релизь, молись.

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

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

Прекрасное про стили организации работы и времени.

- У вас есть планы на 5, 10 лет? Кем вы видите себя через это время?
- Идите нафиг со своим планированием. Оно мне всю радость жизни портит.

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

И это нормально, Карл!

Нужно сделать лишь одну вещь:

1. Представителям порядка принять, что люди разные, устроены они по-разному, и использовать их нужно по-разному.

2. Представителям хаоса принять свою природу, и перестать себя мучать успехосоветами и магиями утра, максимально делегировать рутину и создать вокруг себя подходящую среду для работы.

Познай себя, “человек-иррационал”.

Я несколько раз писал, что аналитик не может всерьез выбирать технологии интеграции, в том числе из-за нехватки знаний о сетях.

Поэтому держите небольшую шпаргалку-введение в работу и устройство сетей. Если интересно занырнуть глубже HTTP, но не готовы к Таненбауму.

Еще у подолдки интересные подкасты были:
https://podlodka.io/239 - часть 1, про интернет
https://podlodka.io/249 - часть 2, больше про железо