#конференции
В начале недели провел воркшоп на Flow - новая конфа для аналитиков от jug.ru. Как слушатель посмотреть успел немного, зато изнутри все было очень лампово.

С одной стороны, новых спикеров и свежего контента было не так много. С другой - конфа фокусируется на технике и хардах для middle+ уровня, поэтому нет тонны докладов про выгорание, карьеру и т.п. И это прекрасно.

Еще из приятного comday - часть активностей сразу транслируется в онлайне. Что понравилось из открытого:
• Никита Харичкин и PlantUML
• Юрий Куприянов и User Story Splitting

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

#манагерское
Сколько же раз я ругался с hrами и руководством на тему KPI, 360 и прочих ассессментов.

“Как только вы вводите систему KPI, вы ставите перед сотрудником интересную инженерную задачу: как с минимальными усилиями получить максимальный результат” - Максим Цепков.

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

Так вот, на канале у Дорофеева прошел классный эфир с Александрой Брызгаловой о проблемах KPI с оглядкой на теорию ограничений. Хочется посоветовать всем фанатам метрик для размышлений хотя все равно никто слушать не станет

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

Быстрое знакомстов с кэшами. В первой части статьи:
• Когда использовать
• Уровни кэширования
• Основные стратегии

Во второй части немного о масштабируемости кэшей и отказоустойчивости системы.

У нас тут вечером намечается стрим на тему работы продакта в кровавом b2b с Михаилом Грековым. Я как-то делился его постом об особенностях продуктовой работы в b2b, который заинтриговал меня рассуждениями о том, что в b2b продакт - это больше системный бизнес аналитик + РП, нежели классический руководитель продукта в b2c. Сегодня попробуем раскрыть эту тему.

И в целом канал у него интересный, например рассуждения о UX-долге в энтерпрайзе, и как его можно отдавать. В общем, заглядывайте сегодня в 18 по мск: https://nextway.timepad.ru/event/2264354

Ожидания от руководителя

Однажды на собеседовании меня попросили сформулировать: какие качества руководителя важны для меня (это было уже не первое собеседование в компанию).

У меня получилось вот так:

▫️Умение доверять. Если руководитель не умеет доверять, то он завязывает процессы на себя и делает хуже общему делу. А во-вторых, не доверяет = не верит в тебя = демотивация.

▫️Умение слушать. Если ты выделил время для встречи с сотрудником — удели 100% внимания этой встрече. Ужасно бесит, когда во время встречи руководитель отписывает в чатах или ещё какие-то дела делает.

▫️Уважение к чужому времени. Бывает разное, но когда босса ждут 10 человек — фигня. Или когда босс начинает переписку посреди ночи — тоже фигня.

▫️Умение соблюдать баланс work-life. С трудоголиками частенько тяжело работать: они либо в делах по уши, либо раздражённо-уставшие. Я бы хотел, чтобы мой босс умел грамотно распоряжаться своим временем.

▫️Желание получать и давать обратную связь. Круто, когда есть периодические 1-1 с руководителем.

▫️Умение не обещать лишнего. Будет меньше разочарований от несбывшихся обещаний.

Приятные мелочи:

▫️Чувство юмора. Нельзя же всё время на серьёзных щах быть :)

▫️Редкое применение статуса при принятии решений. Типа: “Сделай так, как я сказал(а)!”.

#кактотак из давно опубликованного

#оффтоп
Прекрасное рядом.
Смотрим боевое апи, которое держит ничотак нагрузку и зарабатывает 100500 денег в секунду:
- Для чего нужно поле unknown_shit_id?
- А это для диплома Дамира нужно было, можете выпиливать
- *обнимаемся и плачем*

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

Вот бы еще сами аналитики это понимали.

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

В команду входит бэкенд разработка, веб-фронт, и sdk для мобилок. Сейчас мы активно ищем:

Python tech/team lead
Главная задачи на ближайшие полгода-год - рулить технической частью команды:
⁃ Проектировать внутреннюю архитектуру сервисов команды, включая взаимодействия с фронтами
⁃ Вместе с архитектором проектировать взаимодействия с партнерами и смежными командами
⁃ Обеспечивать надежность, развитие и техническую зрелость решений

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

Senior/Lead QA
Глобальная задача - затащить процессы обеспечения качества:
⁃ Нужно будет полностью понимать цепочкуи проведения платежей от живого пользователя до банков и кредитных организаций
⁃ Анализировать, где-что-как может сломаться и разрабатывать сценарии тестирования
⁃ На старте не бояться протестить руками все, что нужно: потыкать UI, подергать API, покрутить мобилки
⁃ По мере развития автоматизировать кейсы, которые этого требуют

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

Удаленка есть, деньги есть. Все вопросы можно в личку: @and_burakov
Буду бесконечно счастлив и благодарен, если перешлете пост знакомым, которых он может заинтересовать.

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

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

Работал как-то с Владом. Влад не любил микрить, правда половину времени я тратил на планирование, у меня было три-четыре вида синков, встречи возникали ВНЕЗАПНО за полчаса до начала, и я должен был уметь отвечать, что делает каждый сотрудник в любой момент времени. Порывался уйти несколько раз и в итоге жалел лишь об одном: зря не сделал это сразу.

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

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

Как бы не доставал Влад, всегда можно было плюнуть, и делать то, что он требует. А результат? А что я могу сделать, мне все равно не дают работать. Удобно же.

Что если микроменеджмент - это не вопрос уровня или культуры менеджмента, а взаимовыгодная модель сотрудничества. Одни постоянно тушат пожары и считают себя Д’Артаньянами на фоне полчищ содомитов, другие жалуются на руководителя-тирана.
Один наслаждается своим героизмом, другие избавляются от отвественности. Win - Win.

И тут вопрос: если руководитель перманентно микрит, зачем его терпят?
Не потому ли, что работать с Владом удобно? Ответственность на нем, можно с чистой совестью работать от рассвета и до обеда, work-life balance и все такое. Для удаленки на Бали вообще выглядит отличным вариантом.

Вместо эпилога оставлю Правило Влада:
⁃ уходи сразу и без сомнений, лучше не будет
⁃ либо пойми и прими себя, перестань ныть и начни радоваться жизни, она всего одна

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

Senior System Business Analyst
Ищем аналитика, который будет заниматься анализом, а не писать ТЗ. Идеальный кандидат - сильный технарь, который хочет поработать с продуктом.

Типичные задачи:
• Есть API провайдера рассрочки. Понять, что из него мы можем использовать, как укладывается в пользовательский путь и архитектуру. Накидать с архитектором драфт схемы взаимодействий и контекстную диаграмму, отдать на дальнейшую техническую проработку.
• Подключаем крупного клиента. Понять его бизнес-процессы и потребности, предложить, как лучше встроить в него наш сервис.
• Мы решили добавить на платежную форму новую фичу. Понять, как это повлияет на пользовательский путь и конверсию в оплату.
• Вы обнаружили неявный корнер-кейс. Оценить вероятность и риски его появления в реальности, подумать, можно ли проигнорировать.

Что важно:
• Мощные техскиллы по интеграции
• Умение выявлять потребности партнеров и моделировать бизнес-процессы - важны не нотации, а способность так думать
• Готовность участвовать в анализе и проектирования UX с оглядкой на продуктовые метрики - тут со всем поможем, было бы желание
• Повышенная инициативность и умение договариваться. “Написали им три дня назад, мяч на их стороне” - не наша история. Если нужно добыть инфу из могилы, мы берем лопату.

Что интересного:
• Возможность подключиться на старте к продукту, который с вашей помощью сожрет новый рынок
• Будете прямо влиять на судьбу продукта и видеть результаты своей работы
• Развитие в архитектуру или управление продуктом

System Analyst
Аналитик в команду процессинга карточных платежей. Куча интеграций с разными платежными системами и финансовыми организациями. Для тех, кто любит архитектуру и технику.

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

Что интересного:
• Увидеть изнутри работу платежных систем: от МИРа и Visa до телеграма и прочей экзотики
• Развивать процессинг, через который работает один из крупнейших маркетплейсов в России и не только - кто хотел хайлоада?
• Возможность развиваться в архитектуру

Деньги есть, удаленка есть. Резюме и вопросы кидайте в личку: @and_burakov
Ну и репост же!

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

Две недели назад закончил первый поток курса Саши Брызгаловой по базовым инструментам мышления 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
- Помойка сообщений в одной очереди?
- Все так