#манагерское #книжное

Уже писал, что "требований" как вещи-в-себе не существует.

Ибо нет человека, который точно знает: если (не) сделать Х, то мы получим такой-то профит / урон. Бизнес всегда оперирует неопределенностью и вероятностями. Исключениями могут быть:

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

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

Что тогда приносят стейкхолдеры, продакты, бизнес-эксперты? Да что угодно: боли, хотелки, потребности, готовые решения, поток сознания - причем никогда не угадаешь, что они принесли в этот раз. Тогда что делать? Разбираться в людях и контексте.

Мне в этом плане нравится книга The Mom Test / Спросите вашу маму

Кратко суть:
 • все люди врут
 • люди врут потому, что вы их провоцируете постановкой вопросов
 • как разговаривать с людьми, чтобы извлечь полезную инфу

Кому стоит прочитать:

 • Продакту и заказчику - чтобы понять контекст и проблемы клиентов / пользователей

 • Аналитику и тимлиду - чтобы понять, зачем эта фича нужна заказчику

 • Разрабу и QA - чтобы понять, зачем аналитик запихал этот метод в апи

 • Владельцу внутренней платформы типа ESB, CI/CD и т.п. - чтобы заранее планировать развитие ваших сервисов

Хорошо поворачивает сознание в сторону нужд ваших потребителей, и их потребителей, и их потребителей. Даже если не занимаетесь всякими кастдевами.

#конференции

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

У меня все. Встречаемся завтра.

Недавно выкладывал задание в симуляторе Кафки. Добавил шаги по работе с ключами и перераспределением партиций при падении брокера.

Забирайте и проходите, если еще не. Штука не только полезная, но и залипательная - успокаивает лучше рыбок.

Ультимативный гайд по софтам

Делюсь сакральным знанием о коммуникациях, оставленным атлантами в недрах Тибета. Использовать на коллегах, руководителях, партнерах.

1. Не давайте коммитов, пока полностью не поймете задачу. Если не понимаете - сообщите об этом и задайте вопросы.

2. Когда начинаете работать над задачей, дайте знать об этом заинтересованной стороне.

3. Если не можете взять задачу сразу или в оговоренные сроки - сразу сообщите об этом.

4. Если вы столкнулись с проблемой, и не можете ее решить - сообщите об этом.

5. Но перед этим попробуйте решить ее самостоятельно. Хотя бы подумайте над вариантами. Никто не любит тех, кто на каждый чих бежит паниковать.

6. Если понимаете, что не успеете в сроки - сообщите об этом сразу. Это никому не понравится, но отрулить будет на порядок проще, чем в последний момент.

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

8. Если на встрече у вас нет ответа на вопрос, так и скажите: пока не могу ответить, беру в работу. Буллшит-импровизации и попытки увильнуть видны почти всегда.

Поздравляю! Вы адекватнее ~83,57% людей на рынке.

#коммуникации #манагерское

#интеграция #API

Пережили конфу, в субботу начнем десятый поток курса по проектированию API.

С одной стороны, это Yet Another REST API Course для джунов-миддлов, чего вы там не видели? Люди знакомятся c HTTP, учатся делать типичный REST API, тестить и документировать сервиcы.

С другой - все чаще вижу на занятиях сеньоров и лидов. Зачем им это?

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

“Делать правильно” никому не нужно. Важно спроектировать API, которое не превратится через полгода в нечитаемое месиво, а под каждую доработку не нужно будет втыкать костыли на каждой стороне. Для этого мы разбираем уровни зрелости REST API, их границы применения, и когда стоит использовать RPC API.

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

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

Так что приходите за обязательной базой или расширением горизонтов. 5-23 апреля, рега тут.

План конференций на апрель:

— 11 апреля StormConf, о которой уже писал. Кто вживую собирается?

— 12-13 апреля Systems Design Online с большой секций по архитектуре

— 25 апреля DUMP в Екатеринбурге, буду рассказывать про API как продукт

— 26 апреля открытый Flow в олнайне, там вещаю про фейлы, которые собрали при проектировании этого API

Как бы еще везде успеть и выжить, пожалуйста.

Вот да

🔥 Снижай драматизм: уроки от Slack

Давайте сразу: проект провалился. Все, расходимся, жизнь кончена?! Да хрен там плавал!

Вот история Slack, который вырос из игры Glitch. Если по-простому: ребята несколько лет делали онлайн-игру, вбухали кучу денег и сил, но все никак. Игрушка не взлетела. Что, плакать и расходиться? Нет, они закрыли проект без лишних слез и заметили, что внутри команды круто работают их же внутренние чаты. И сделали пивот в корпоративный мессенджер. Теперь весь мир знает Slack.

Вспомнил себя, когда делали стартап: один релиз отложили — и все, истерика, как будто мир рухнул. Да-да, тоже бил кулаком по столу и вопил, что это «вопрос жизни и смерти». А зачем? Чем выше накал, тем меньше мозгов остается на поиск нормальных решений. Проверено лично.

Где логика в том, чтобы загонять команду в панику и драматически орать «мы горим!»? Это тупик, господа.

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

А у вас бывали пивоты в карьере или проекте, которые внезапно «выстреливали»?

Карьера продакта

Кто о чем, а мы о сисдизайне

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

Стрим с Филом Дельгядо о сисдизайне на интервью

Несколько тезисов:

— Секция сисдизайна не показывает, может ли человек проектировать системы в рамках своих задач - внезапно, да?

— Многие кандидаты приходят со знаниями из книг по интервью. Причем интервьюеры тоже.

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

— Единообразие и прозрачность обычно противоречат эффективности. В том числе в найме.

— Отдать найм в команды, может быть намного эффективнее, чем делать его централизованным.

В целом рекомендую его выступления - живое руководство по критическому мышлению.

А вот доклад Александра Поломодова, как и почему проводят сисдизай секции в ТБанке

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

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

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

Если конкретнее, мы берем реальные задачи из разных доменов и проходим весь путь проектирования решения: от выявления требований к декомпозиции системы на сервисы, выбору технологий, проектированию апи и модели данных. Никаких книжных ютубов, url-shortner’ов и key-value хранилищ, с которыми вы никогда в жизни не встретитесь.

Вот примеры некоторых кейсов: выпуск и доставка карты, умная лента заказов для маркетплейса, система A/B-тестов, риалтайм доска “миро-заменитель”.

В субботу пилим онлайн-чат со службой поддержки. Фича, которую вы можете встретить почти в любом своем приложении. Будем работать с высокой нагрузкой, думать о масштабировании, выбирать read / write модели и типы хранилищ, сравнивать способы интеграции с точки зрения реализации НФТ.

Суббота, в 10:00 мск, рега тут

#оффтоп

Не пускайте детей в интернет, он от этого тупеет - предупреждали нас в старых злобных рунетах.

Интересно, понимал ли автор, на сколько точно его фраза будет отражать реальность эпохи LLM?

У нас постепенно распространяется роль техпродакта, но пока нет единого мнения, что это за зверь. Поэтому сегодня делаем стрим с Леной Царьковой - техпродактом из Авито, в прошлом СА.

Сегодня в 19:00 мск, рега тут.

И думаю, он будет не последним.

#образование

Галлюцинации LLM - это не баг, а мега фича для образования.

Общался с несколькими людьми, как они используют LLM для обучения. Паттерн примерно один - задаю вопросы, делаю уточнения, прошу прямые цитаты и ссылки, дальше иду проверять спорные места в гугл. Запрос - диалог - фактчекинг.

Почему этот же паттерн не срабатывает при обучении у других людей?

Есть мировые авторитеты, условные Ричардсон, Ньюман, Фаулер, еще кто. У них большой опыт разработки, огромный в консалтинге, тысячи часов размышлений над темой. Значит ли, что их предпосылки и выводы всегда верны? Значит ли, что их опыт переносим в вашу сферу?

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

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

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

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

Галлюцинирую - значит, существуют

Сейчас не особо слежу за около аналитическими каналами, но один из тех, что читаю - Системный сдвиг от Юрия Куприянова. Как по мне, самое ценно там - это комплексный взгляд на создание it-решений: от продукта и бизнеса, до архитектуры и технических деталей. Т.е. мышление аналитика здорового человека, а не “дайте требования, я вам апи и сиквенсы нарисую”.

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

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

Примеры интересного:

— инфографика с основными способами интеграции

— чек-лист стандартов в области интеграции и API

— 10 техник проверки полноты требований

— скрытая работа по проектированию систем, которую выполняет системный аналитик

— применение ChatGPT в работе системного аналитика: раз и два

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

#конференции

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

С какого-то момента междисциплинарные конференции стали куда интереснее за счет знакомства и общения с людьми из смежных ролей - их боли, проблемы, мысли дают куда больше инсайтов, чем очередной спич на профильной конфе. Поэтому если вы скучающий сеньористый сеньор, то попробуйте сгонять на подобное событие. Где еще вы будете обсуждать с ML-лидом использование ТРИЗ на собесах в 4 утра?

От себя выделю доклады:

 • Наталья Потемина - о противостоянии продукт vs коммерция-маркетинг. Рыдал, когда слушал, ибо вот прям все болячки из доклада собрали на последнем проекте.

 • Александра Брызгалова - еще один взгляд со стороны теории ограничений на “эффективность”, личную и командную. Что это такое, и почему больше и быстрее - не значит лучше.

 • Даниил Смирнов - как продакты убивают бизнес, или почему критично важно участвовать в продажах, если вы работаете в b2b.

Краткая мораль
Если вы избегаете продаж, то вы не продакт, а товаровед (с) Саша Брызгалова

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

Спасибо DUMP и до встречи через год ❤‍🔥

Жертвы Шторма

Есть у технологий ранние последователи, есть и ранние жертвы. У меня такое случилось с Event Storming.

2017 год, зима, летим к заказчику делать интеграцию на микросервисах. Тогда со всех сторон кричали, что MSA - это новый ESB высшая ступень эволюции, DDD познавали по Вернону, а об Event Storming’е перешептывались в углах избранные. Вот и мы наслушались шепотов.

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

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

На выходе осталась некоторая недосказанность:

- Как запихнуть гигантский ватман в самолет, чтобы не отвалились стикеры?

- Что нам теперь с этим делать?

- Как объяснить заказчику, ради чего мы потратили столько времени и денег?

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

2025 год, весна, жду вебинар об Event Storming, на котором будем обсуждать боли и проблемы внедрения техники, каких результатов можно добиться за счет ее использования. Во имя комплексности и системности пригласили гостей из разных ролей:

• Екатерина Пантелей - системный аналитик

• Ольга Бугаева - руководитель продукта

• Евгений Асламов - архитектор

Приходите, сэкономите на ватманах.

📆 13 мая, 18:00 мск, рега тут

Профит Шторма

Справедливости ради, профита Event Storming принес больше, чем боли и страданий. Чем помогал лично мне:

• быстро вкатиться в новый проект или предметку

• познакомиться и наладить контакты со стейкхолдерами и командой

• выявить конфликты и разночтения между бизнес подразделениями - внезапно, представители бизнеса часто имеют разное представление о реальных процессах

• разобраться в работе системы, когда совсем нет документации

Т.е. штука-то полезная, но нужно практиковаться и экспериментировать. На NextConf Катя Пантелей провела ознакомительный воркшоп - участникам зашло, поэтому решили сделать полную версию в формате тренинга.

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

😱 Если хочется просто поговорить о проблемах Event Storming, то приходите сегодня в 18:00 мск на вебинар.

Как же AI может заменить аналитика, если нужно работать с заказчиком, который не знает, чего хочет? Да вот так.

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

Как должно работать:

1. Даете доступ к своей базе знаний

2. Подрубаете сервис ко всем каналам связи с заказчиком

3. На основе встреч и переписки сервис генерит требования и проверяет их на полноту и противоречия. Если что-то не так - сигнализирует об этом

4. Формирует доки: BRD, C4, что-то еще

5. Создает таски и трекает корректность реализации - тут я не понял, как

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

Да, сомнительно с точки зрения безопасности. Да, больше заточено под типовую разработку и внедрение. Уверен, работает раз в 10 хуже, чем обещают. И все равно нужен будет живой эксперт.

Но все это неважно. Пройдет 3-5 лет, ребята дотюнят модели, выпустят on-premise версию, а корпораты начнут экспериментировать со своими ассистентами по требованиям. И вот зачем толпа аналитиков продакту, проджекту или техсейлзу с таким инструментом - большой вопрос.

Кстати, Александра подогнала расшифровку своего доклада. Очень советую почитать: https://bryzgalova.ru/effectiveness

А Катя собрала классную подборку шаблонов для Event Storming

Подборка шаблонов для EventStorming
Если вы планируете сессию или просто хотите разобраться в подходе — вот несколько полезных шаблонов и инструментов:

🔶 Unidraw — инструмент не плохой, но после внимательного изучения шаблона у меня остались вопросы. Интересно, кто пользовался — как вам?
🔶 Miro — классика. Именно с неё я начинала и до сих пор люблю за стабильность и адаптивность.
🔶 Excalidraw — скорее пример, чем шаблон. Но для старта может быть очень полезен — просто, быстро, понятно.
🔶 Figma — забавно, как чётко расписаны первые 4 шага. Но вот когда речь доходит до Process Modeling — тишина. Хотя в целом шаблон зачетный.
🔶 GitHub — настоящая сокровищница. Много полезностей в одном месте, и видно, что автор явно читал ту самую книгу по EventStorming. Советую заглянуть!

💾 Сохраняйте в закладки — даже если сейчас ES вам не нужен, уверена, тренды от международных коллег до нас точно дойдут. А шаблоны пригодятся 😉

Свой шаблон тоже сделала, ими поделюсь немного позже отдельным постом для 3 инструментов)

#eventstorming #шаблоны #аналитика #системныйаналитик #itинструменты