#рецепт
Отчет по Jira любой команды без выгрузок и геморроя через Claude. Ну почти

Здравствуй, ai-совместимый менеджер!

Про это не сказал уже только ленивый, что Atlassian подключил Claude к Jira через beta MCP сервер (в комментарии оставил ссылки почитать что это такое на всякий). Теперь отчёты и задачи создаются простым промптом. Так заявляется

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

В комментариях на форумах заметили очевидные нюансы:

1. Claude иногда неточно интерпретирует промпты, нужны максимально конкретные запросы. С промтами в MCP всегда была беда

2. Не всегда подходит для сложных и очень многошаговых задач

Подробности и обсуждение:
https://community.atlassian.com/forums/Atlassian-Platform-articles/Using-the-Atlassian-Remote-MCP-Server-beta/ba-p/3005104
https://www.atlassian.com/platform/remote-mcp-server

P.S. У меня оно не завелось вообще, так как много проектов team managed в jira и оно просто отказывается с ними работать. Если кто еще попробовал, поделитесь, как оно. Я привык уже на коленке собирать скрипты на питоне и выгружать все что мне нужно по Rest

#рецепт
Формула конфликта

Здравствуй, наблюдательный читатель!

Давай сегодня разберём одну занятную теорию, которую утащил с курса от Стратоплана.

Формулу конфликта: КНС = К – КС – (КФГ). На словах все прозаично: если вычесть из любого конфликта (К) саму конфликтную ситуацию (КС) и весь этот эмоциональный груз” (КФГ) - останется КНС, то есть конструктив. КНС - это и есть тот полезный остаток, который позволяет выйти из любого спора сильнее чем прежде и без перегара

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

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

Позитивное намерение - еще одна полезная концепция

Звучит чуть мудрено, а на деле - это то, ради чего мы вообще вступаем в спор. И это почти всегда что-то хорошее, просто часто скрытое даже от самих себя.
Например:
- Агрессия? На самом деле человек хочет защитить себя или восстановить справедливость;
- Робость? Хочет быть замеченным;
- Сопротивление изменениям? Боится облажаться и хочет сохранить уверенность;
- Ложь? Иногда - просто избежать разрушения отношений.

У меня бывает, что спорю до хрипоты, а на самом деле просто боюсь, что проект завалится и мне потом разбирать завалы

Смысл здесь - научиться видеть, какое позитивное намерение скрыто за поведением человека. Даже если она кажется стремным. И озвучить это (хотя бы для себя), чтобы не упереться в эмоции

Последовательность решения через 3 К

1) Контакт - спокойно признаём, что есть проблема, и зовём её обсудить (“Коллеги, у нас периодически переносятся релизы, что влияет на наши совместные цели - давайте поймём, почему и чем мы вам можем помочь”)

2) Коммуникация - выясняем, как видит ситуацию оппонент, чего он реально хочет (часто тут проявляется как раз то самое позитивное намерение). Проговариваем и своё (“Я вижу, что у команды перегруз, и мне важно, чтобы мы не выгорели”)

3) Консилиация - договариваемся, кто готов на какие изменения, и фиксируем это. Можно устно, можно даже письменно. А еще радуемся что не перес**лись

Если обе стороны честно участвуют, появляется шанс выйти на конструктив, а не скатиться в позиционку

Конечно есть но.
Был у меня случай с C-level в крупной телеком-компании. Все условия для конфликта (КС) - на месте: сложные процессы, закрытые правила, куча скрытых ожиданий. Конфликтогены (КФГ) - регулярно: “вы тут гости”, “у нас свои порядки”, колкости через раз. И вроде бы я держался за конструктив, вытаскивал на контакт, озвучивал позитивные намерения (“Я правда хочу, чтобы процессы были прозрачнее для всех - не для галочки, мы строим квартальное планирование чтобы повышать предсказуемость”). Но человек не хотел даже обсуждать, если ты не из его круга, а любые мои предложения - только злили. Итог - никакой КНС, только выгорание. Формула работает, если обе стороны хотя бы формально хотят договариваться и строить партнерские отношения, а если нет - хоть разбирай конфликт на атомы, конструктив не вытащишь

P.S. Сам до сих пор учусь видеть за поведением не только конфликтогены, но и позитивные намерения, честно говоря, для меня это один из самых сложных навыков. Но точно стоящий

#полезности
🔥 Эфир “Gen AI и LLM в работе менеджера: правда и мифы”

🤖 Мы всё чаще слышим о Gen AI и LLM: кто-то закупает GPT-o3 и Cursor, кто-то строит RAG-ассистентов или включает в процессы Jira AI и tl;dv. Но где реальная польза для PM, а где - очередной хайп и пустые спекуляции?

🗓 В следующий понедельник, 23.06, в 19:30 по мск у нас пройдет честный AMA (Ask Me Anything) без воды и слайдов в самом большом ру-сообществе поиска работы для менеджеров Project Jobs . Только практические кейсы и откровенные ответы на любые вопросы!

👥 Участники эфира:

- Стас Беляев - Lead Tech PM, Microsoft, автор Meet Deadlines

- Артем Арюткин - Руководитель проектного офиса Яндекса, автор Плохой Project

- Артем Летюшев - Senior PM, Twinby, автор Junior PM

Также к нам заглянет @Danil_Silantyev как DS/AI-инженер, чтобы технически углубить ответы

🎯 Что обсудим как минимум:

- Как "AI" инструменты мы используем и что из них реально помогают в управлении

- Какие решения заходят,а от каких мало толку

- Что еще недостаточно развито чтобы давать отдачу

- Какие нужны условия для адекватной работы LLM

📊 P.S. Мы активно погружаемся в рынок обучения AI для менеджеров и удивляемся шуму вокруг инструментов. Через контент и лендинг mysummit.school тестируем спрос на грамотное и структурированное обучение

🚀 Подключайтесь 23 июня в 19:30 в Projects Jobs и не стесняйтесь задавать вопросы!

#кейс_стади
Задача на подумать для менеджера

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

Ты - Project Manager отдела DigitalOps в компании «Доставичкофф», с недавнего времени крупный игрок B2B-логистика и мультимодальной доставки. Ваш развивает делает клиентский портал, API-интеграции и мобильный трекер. Раньше за всём стоял Excel или бесплатные версии инструментов, но после успеха маркетинга поток заказов удвоился, и три команды уже не справляются с запросами бизнеса

Собственник дал карт-бланш на закупку любых нужных сервисов, те же HR на радостях пересели в хантфлоу, а по всей компании запустили обучение OKR и цифровым навыкам. CTO, бывший Head of AI в Lamoda и большой фанат прозрачного репортинга и автоматизации, с его подачи начались масштабные реформы в компании

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

– введёт единые delivery-ритмы,
– согласует приоритезацию и бэклог между командами,
– организует прозрачную отчётность по OKR/KPI,
– подружит разработку с маркетингом и бизнес-заказчиками

#полезности

Запись эфира
https://www.youtube.com/watch?v=UIzlZVUu8Ys&sttick=0

Для удобства, вот еще транскрипция этого видео, чтобы посмотреть только интересные вам темы (уважаем ваше время)
https://300.ya.ru/v_C3GZquhD. Там много забавных неточностей, но увы такова транскрибация яндекса

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

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

Собственно продолжаем нашу эпопею с проверкой гипотезы о том что рынку нужны хорошие курсы по Gen AI для менеджеров https://mysummit.school/

#иное
Как наверное заметили я тут мастрячу курс по Gen AI для менеджеров

И как раз в рамках этого приходится много информации в интернете перепроверять. Даже не представляете, сколько там спекуляций и передёргиваний. Но хватает и просто забавного. В рамках контент-маркетинга я пилю как квизы, так и структурированные соцопросы, за которыми стоит большая работа. Если вдруг хочется проверить, насколько вы распознаёте текст от AI или узнать, действительно ли вас заменит ИИ через пару лет, можете пройти пару таких опросов - в лучших традициях тестов ВКонтакте

https://tally.so/r/w4DZoO - Проверка способности отличать сгенерированный текст от человеческого

https://tally.so/r/w2YeOV - Адекватный ответ, заменит ли тебя ИИ

#кейс_стади
Задача на подумать для менеджера

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

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

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

Судя по моему курсу для руководителя отдела тут у нас классическая адхократия по Минцбергу: задачи сложные, конфликтов полно, а культура интегратора только начинает рождаться. Просто сильный PM тут с одной стороны избыточен и ему будет сложнее включиться, придется переучиваться под CTO, а джун с Qwen-13B не справится. AI все это усилитель компетенций, а не костыль вместо софта

А еще почти никто не заметил что от Qwen-13B толку особо не будет, слишком слабая модель, как и от n8n в 75% кейсов. Тут я откровенно ловушку на внимательность поставил

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

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

#полезности
Вайбкодинг эволюционировал в вайб-менеджмент

Здравствуй, практикующий экспериментатор AI-тулов!

Когда-то все радовались моде на vibe coding и то как легко и просто теперь писать простые автоматизации, восторгались от n8n и мануса. А тут какой-то умник сделал Vibe Kanban - не про канбан-доски, а чисто про управление бригадой AI-агентов (Claude, Gemini, Codex, Amp) в одном локальном окне

Что там происходит
Распределяешь задачи между агентами, переключаешь их на лету, смотришь, кто решает задачи быстрее, а кто просто уходит в философский рефакторинг. Доступны легкие оркестрационные паттерны вроде upstairs/debate agents. Всё запускается у тебя локально - никакой внешней аналитики, за приватность уже не переживай, сбор e-mail и имён с GitHub пофиксили (комьюнити умеет отстаивать свои права)

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

Открытый исходник: https://github.com/BloopAI/vibe-kanban
Полные доки: https://www.vibekanban.com/

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

Мой скепсис как обычно
Скажу честно - это не crew.ai, и до production здесь ещё далеко. По отзывам на HN https://news.ycombinator.com/item?id=44533004 и редите https://www.reddit.com/r/ClaudeCode/comments/1luv8iq/claude_code_meets_kanban/ народ хайпует, но при этом активно жалуется: то агенты зависают, то код не меняется, то авторизация требует слишком много разрешений. Ну да, гринфилд опенсурс, как обычно

P.S. Если твои агенты поссорятся из-за формата кавычек или внезапно решат перевести всё на TypeScript - добро пожаловать в вайб-менеджмент
P.P.S. Для затравки демка: https://www.youtube.com/watch?v=NCksand7Iwo

#иное
Воркшоп по вайбинжинирингу

Здравствуй, уставший от демо-песочниц менеджер!

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

В этот раз будет по-взрослому. Без хороводов вокруг prompt’ов, без фейковых IDE и без философии "ну тут Claude сам всё придумал"

27 июля, 20:30 (МСК) - прямой эфир от MySummit School на YouTube (курс который я мастрячу несколько в убыток блогу и лету)
Вот ссылка, не потеряй: https://mysummit.school/event/ai-for-engineers-27-07-2025

Что будет?

- фуллпайплайн продакшн-разработки AI-first приложения, от PoC до боевого интерфейса;
- ICE-промптинг, кодогенерация без боли и semantic task markup;
- оркестрация нескольких агентов с retry-логикой и LLM-пригодным логированием;
- UI-дизайн с AI-дизайнерами, которые не тупят на кнопках отмена" и отменить отмену;
- как самовалидировать вывод, ловить фейлы и не сойти с ума от реколлов fix it, fix it...

Всё это добро грамотно покажет техлид и AI-инженер из ведущей технологической компании (пока из-за проволочек название компании под NDA)

Формат непосредственный: живая разработка, реальные ошибки, честные ответы на вопросы вроде "а почему оно вообще работает?"

Короче, если хочешь понять, как встраивать AI в SDLC на уровне 1 команды - велком

P.S. Говорят, после каждого эфира как минимум десяток человек идет читать гайды вроде AI Fluency

#рецепт
Манифест вайбинжиниринга: что надо делать, чтобы не ловить фейспалмы (часть 1)

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

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

1️⃣ Чёткое проектирование: Формализуй архитектуру, схемы БД, правила именования и OpenAPI с первого дня, минимизируя семантическую энтропию;

2️⃣ Монорепозиторий и единая БД: Используй один репозиторий и одну БД с разделением на схемы. Даже не пытайся делать в отдельных репозиториях, это ужасно;

3️⃣ Семантическая разметка: Веди anchors в коде и документации, минимизируй интерференцию, связывай через graph-обход;

4️⃣ Три линтера: Именование (snake_case, kebab-case), семантическая разметка, OpenAPI/события — запускай с первого коммита;

5️⃣ Юнит-тесты: Покрывай все API, очереди, интеграции с первого дня, пиши простые тесты;

6️⃣ Логирование: Раздели на public (для Grafana) и dev (с файлами/строками), структурируй в JSON с trace_id, user_id;

7️⃣ Безопасность: Храни креды только в auth-схеме, передавай через защищённые каналы, не индексируй в git. ЖЕСТКО ОПИШИ ЭТО ПРАВИЛАМИ и желательно покрой тестами;

8️⃣ Документация на английском: Веди строго структурированную, с anchors, синхронизируй с кодом. К сожалению, на русском больше чудит любая модель и любой сервис;

9️⃣ OpenAPI и REST: Полные схемы request/response, CRUDL, описание ошибок для каждого endpoint'а;

🔟 Внешние сущности: Для каждой сущности — external_id, external_name, external_value_id, id (UUID) в clean-схеме;

1️⃣1️⃣ Docker-compose: Единый для всех сервисов, БД, BI (Metabase), с поддержкой локального/VPS деплоя;

1️⃣2️⃣ Мониторинг и телеметрия: С первого дня интегрируй Grafana/Prometheus для публичных логов и метрик;

1️⃣3️⃣ Self-hosted флоу: Поддерживай установку локально/VPS, админка для настройки интеграций, выбор проектов/параметров;

1️⃣4️⃣ Технофашизм: Жёстко следи за правилами, линтерами, тестами и документацией, чтобы код не превратился в хаос;

1️⃣5️⃣ На полную пользоваться всё-таки git, особенно github flow, потому что его придумали не просто так. И в случае вайб-инжиниринга больше всего работает именно он. И вырабатывать привычку атомарных коммитов, прям на уровне “меняю хоть что-то — коммит”, и все фичи, любые маломальские изменения — всегда в отдельных бранчах;

1️⃣6️⃣ Не писать самостоятельно промпты вообще никогда, ни в коем случае. Всегда, если тебе нужно сделать что-то новое, сперва излагай свои мысли в каком-нибудь Google AI Studio, в каком-нибудь Gemini 2.5 Pro. И только после этого копируй этот промпт на английском, когда он учитывает все моменты, когда он тебя поспрашивал, когда ты воспользовался действительно полным флоу устранения галлюцинаций и критическим мышлением;

P.S. Я по сути не инженер и не разработчик, но за 9 месяцев вайбкодинга и перманентного обучения уже могу писать +- продакшн код на уровне junior + <-> middle - и вступать в осознанные архитектурные дискуссии, которые помогают компании. Ну и просто очень быстро учусь

#рецепт
Манифест вайбинжиниринга: продолжение (часть 2)

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

1️⃣7️⃣ Забить агрегат на все эти прикольные механики из разряда prompt engineering, context engineering, потому что в большинстве случаев это полный bullshit, и они никак не помогают. А prompt-схемы вида COSTAR или CLEAR вообще вредны, потому что добавляют слишком много онтологической дрожи и вообще противоречат друг другу. Слишком дохрена противоречивых инструкций;

1️⃣8️⃣ Можно использовать шотган-механики для больших проектов, но в большинстве случаев они совершенно не нужны, абсолютно достаточно как раз-таки той вменяемой документации, которую ты ведёшь, и твоих правил, overview проекта, архитектуры и так далее;

1️⃣9️⃣ Перед тем как решать какую-то задачу — поискать на гитхабе её решение, хотя бы агента с вебсерчем. В 95% случаев то, как вы решаете задачу — это недостаток вашего кругозора, и это уже делали;

2️⃣0️⃣ Во все промпты инъектить команду ограничивать изменения решением задачи и не менять сопутствующие файлы, лишь бы было хорошо. Все LLM крайне плохо воспринимают принцип бойскаута и часто специально настроены, чтобы жечь больше токенов;

2️⃣1️⃣ Естественно хранить документацию в том же репозитории хотя бы в .md, и всегда её проверять на непротиворечие другой документации;

2️⃣2️⃣ Не использовать для полностью автономной работы агентов. Пока они сырые. Максимум доверять бойлерплейты и простые вещи в бекграунде;

2️⃣3️⃣ Все сервисы писать максимально автономные. Пока что модели, к сожалению, плохо справляются с учетом того, что не вся картина у них под носом

На будущее
присмотром. Но в будущем лучше делать ставку именно на небольшие автономные сервисы в рамках большой системы и микро-репы
2️⃣4️⃣ Сделать какую-то кастомную настройку, чтобы в каждом забросе ограничивать количество коллов и проходов, чтобы сервис не уходил в death loop. Скажем, делать максимум 20 правок и максимум вызовов 10 апишки. Не ходить в слишком большое количество файлов и ни в коем случае не ходить в файлы за пределами запроса и не менять всё подряд. Провайдеры LLM и API крайне любят, когда твой запрос сожрал крайне много токенов и выставит тебе большой счет. Как-то это инъектировать в каждый промпт, в каждую задачу, каждый запрос, чтобы не было избыточного количества изменений, которые не сдались;

2️⃣5️⃣ Настроить какую-то интеграцию для того, чтобы если после промота появились ошибки и сервис не перезапускается, он автоматически, делал повторный запуск и автоматически исправлял. Естественно с критериями death loop-а и не оптимального решения задачи

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

#мнение
Почему весь этот AI появился в блоге

Я прекрасно понимаю что это может быть похоже на щит луп про AI всех заменит и тд. Однако я не продаю свои услуги, не кидаю ссылки на секретные практики и прочее. Тут скорее совпало несколько моментов:

- Я заинтересован и вдохновлен, а я всегда писал про то что у меня в фокусе и вызывает у меня живой интерес, скажем так от балды;

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

- С командой энтузиастов мы в ***е от количества воды и спекуляций на теме AI в купе с пренебрежительным отношением к новым инструментам в СНГ, поэтому тестируем курс сосредоточенный на прикладных вещах;

- Я сам вайбкожу сервис. Который все-то позволяет по токену пользователя вытаскивать данные из любых корпоративных систем и складывать это структурно в базу данных с пристегнутым арсеналом BI-инструментов. Чтобы абсолютно любой менеджер мог поставить себе диструбитив на комьютер или какой-угодно сервер и там из под коробки была выгрузка скажем из джиры и дашборд с правильными метриками от lead time до dora и всяким срезами велосити/капасити. И все это расширяемо, стабильно, независимо и бесплатно

#рецепт
Болючий карьерный рост

Здравствуй, дорогой читатель. Давно не виделись. Я немного вынырнул из курса Статоплана, перегруза, и принес немного своих мыслей. Часто вдохновляюсь в последнее время этим курсом и периодически пересматриваю материалы. Так вот:

Чем дольше я работаю менеджером, тем сильнее убеждаюсь, что карьерный рост это не всегда благо. Есть старый добрый Принцип Питера, гласящий что специалист растёт до тех пор, пока не упирается в потолок собственной некомпетентности. Он либо ее осознает и пробивает, либо растекается по нему этакой кляксой и начиет всячески защищать. И вот он уже не лучший пайтон инженер, а слабый руководитель

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

Причина в том, что условно:
мотивация 8 + навыки 5 = эффективность всё равно 5
мотивация 9 + навыки 2 = эффективность 2

В итоге всегда побеждает минимум. Эта история хорошо визуализируется через Skill–Will Matrix

Я для себя это называю хребет руководителя. Забавное название, но оно точно отражает суть: стержень, навыки и мотивация должны расти вместе. Иначе проект складывается. В One Piece кстати есть схожая концепция → королевская воля

Личный опыт? По моей статистике примерно половина инженеров, которых я пробовал тащить в лиды, либо не прям хотели, либо не могли быть руководителями. И это нормально. Кто-то сильнее как эксперт, и его ценность именно там. Поэтому я всё больше за то, чтобы держать альтернативные карьерные треки и экспертный, и менеджерский. Если компания не может предложить ни то ни другое? У вас бомба с детонатором. Держите ее пока таймер не истечет, но не забывайте на него поглядывать

Что это значит для нас с тобой:
– смотри на людей в двух координатах сразу, мотивация и компетенции;
– давай пробные роли, прежде чем повышать (тут хорошо про опыт Фигмы);
– уважай выбор тех, кто хочет расти как эксперт, а не как начальник

P.S. Я всё чаще думаю: настоящий тест готовности к лидерству это понимание решений своего руководителя. Если причинно-следственные связи наверху кажутся туманом, значит твой собственный soft skill принятие решений ещё сыроват. Решения могут быть с твоей точки зрения не лучшими, но понимать почему они такие мастхэв

📚 Если хочется копнуть глубже - вот ещё одно исследование HBR
про то, почему лучших исполнителей не стоит автоматически делать менеджерами

#рецепт
Надо рубить с плеча

Здравствуй, нетираничный читатель!

Проджекты любят говорить, что наша суперсила, строить долгосрочные отношения. Но вот нелегкая правда, часто надо уметь расставаться. Даже некрасиво. Как можно раньше

Не всегда это история про плохих людей. Может быть отличный аналитик, прекрасный человек, но… не метч, либо он был, но перестал. Человек пропадает, разбивается о задачи, не вытягивает темп команды. Ты можешь долго объяснять это через СДВГ, личные обстоятельства, надо помочь, но иногда это как третья нога, которая идет под другим углом, тормозит все тело. Пора отпускать

У меня есть три дурацких принципа, которые помогают:

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

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

Принцип книжечки
Если чуйка говорит какая несуразица пошла, -> заведи книжечку. Записывай ситуации, делай скрины, отмечай сбои. Потом это не просто твое субъективное ощущение, а база для честной обратной связи и взвешенного решения

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

Немного пользительного чтива:
- Искусство увольнять: офбординг как часть employee lifecycle
- Как разойтись с сотрудником «по-хорошему»
- «Уволить нельзя оставить»: 7 шагов спокойного и юридически аккуратного увольнения

P.S. Поделись, сколько тебе потребовалось времени чтобы привыкнуть к тому что кого-то оставляешь без работы?

#полезности
Путь системного аналитика

Здравствуй, мой аналитичный читатель
В свое время передо мной был перк аналитика, но почему-то я выбрал менеджера, иногда даже скорблю. Однако с опытом я начинаю обрастать смежными компетенциями, любая профессия в ИТ не стоит на месте, и бизнес-/системный анализ особенно. Недавно познакомился с Оксаной, она уже больше 10 лет в теме, начинала бизнес-аналитиком, а теперь топовый системный аналитик и ведёт классный канал Business | Systems analyst

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

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

Там в канале знатный кладезь: от шпаргалок по UML и BPMN до гайдов по работе с Kafka, Event Sourcing, API и базами данных. Плюс у неё серия постов про собеседования, и реальные тестовые задания, и разбор вопросов, и комментарии, что меняется в найме. Сейчас она ещё пишет мини-курс по техскиллам системного аналитика

#мнение
Почему мой карьерный трек такой странный

Это будет немного сумбурный пост в стиле давайте познакомимся. Только я не буду описывать, какой я классный путь прошёл и т. д

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

Во-вторых, я не считаю себя экспертом, примером для подражания и поэтому редко пишу о себе

К чему пост? Как многие ранее замечали: Артём, а где, собственно, твой карьерный рост? И почему ты постоянно туда-сюда метёшься. Объясняю

Нулевой карьерный свитч

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

Первый карьерный свитч
Сперва я пожалел, что стал идти по стезе проджекта, я вообще из мелкого локального питерского аутсорса. Работа в agima, 65aps или вау в Epam!! представлялась мне вершиной. Но там стеклянный потолок в 300 000 рублей в 2020-м, да и вокруг все аджайл-коучи зарабатывают на старте спокойно соизмеримо. К тому же я обнаружил отсутствие у себя эмпатии и EQ

А аджайл-коучи как раз в этом хорошо прошарены. Смотрю опросы Антона Бевзюка (не смог найти) и вижу цифру 250к для мидла скрам-мастера и множество возможностей - пошёл туда. Кто ж знал, что после февраля 2022-а в СНГ резко упадёт тренд на Agile

Второй карьерный свитч
К этому времени меня позвали за рубеж не на какую-то позицию, а на Head of Projects (правда, я скорее рулил не всеми, а только четырьмя проджектами и их пятью стримами). В бытность аджайл-лидом в МТС я всё равно активно включался в обучения, менторинг, организацию всяких воркшопов и вообще тянул гильдию аджайла. Поэтому опыт +- был, и я радостно переключился на позицию руководителя менеджеров. К тому же в компании любили канбан, а я давний ученик и поклонник Леши Пименова — этакий деливери-лид проджектов вышел. Но потом, спустя время, произошли перестановки в компании, и я стал просто руководителем стрима нативной разработки, да, это 50 человек в управлении, но всего с одним проджектом, и то в полуподчинении. А моими начальниками стали люди, которых я увольнял, ещё будучи хедом проджектов.

Третий карьерный свитч
Ситуация после начала 2022 года затягивалась, оказалось, что рынку не прям чтоб очень требуются чистые управленцы, зарплаты не шибко растут, как и возможности. А вот запрос на достаточно инженерных и классических проджектов - problem solverов - достаточно высок. Я стал активно возобновлять знания по компьютер саенс, проектировать и включаться в техничку. Правда, я с иронией смотрел на тех, кто переобувается в AI, и думал, что возможностей там не особо много: что умеет этот GPT-3.5? Да он же Т9 на максималках, тупорезик. Оказалось, AI-инструментам есть куда расти, и рынок начал меняться резко, и я понял, насколько я ошибся

Четвёртый карьерный свитч
Я вернулся к тому, с чего начал. Я универсальный обычный проджект, и, кажется, у нас выходит славный метч с Twinby. Я могу в инженерку, могу потащить любой проект, от экстра-сжатых сроков в неделю до пары лет. Могу везти на себе 4–5 команд, самостоятельно погружаться в любую предметную область, и в целом я интергратор-терминатор. С достаточно глубоким погружением в AI и вайбкодингом в свободное от задач или встреч время

Кто я сейчас? Универсальный менеджер, разве что слабо потяну тимлида и не буду выдающимся продактом. Я не лучший коммуникатор и развил эмоц. интеллект только механически, так и не оброс эмпатией. Мой руководитель, СOO вообще зовет меня бездушной машиной. Мой карьерный трек продукт случайностей. Но всё же хочется верить, что я хороший руководитель, и у меня есть чему поучиться

😎 Управление проектами в IT — всё, что вы хотели знать, но боялись спросить

23–24 сентября, Москва. Большая конференция для руководителей диджитал-агентств BOOST. И отдельный поток, посвященный только управлению проектами.

Целых два дня будем обсуждать всё, что касается IT-процессов. Рассмотрим нашу сферу со всех сторон, поделимся наболевшим, поддержим друг друга и сообща поищем решения.

В секции выступят эксперты из AGIMA, Red Collar, Imaga, Яндекс Трекера, Kaiten, Weeek, Notamedia.Agency и еще десятка крутых компаний.

В программе:

→ как работать со сложными заказчиками, чтобы команда не уволилась;

→ как управлять проектами по дизайну и креативными командами;

→ как импортозаместить таск-трекер, если появилась такая необходимость;

→ как найти грамотного и знающего проджект-менеджера.

И это только начало списка. Еще мы проведем панельную дискуссию с заказчиками, выясним, с кем они работают годами. Также нас ждет F*ckUp Night — стендам-сессия о провалившихся проектах.

Подытожим. Впереди два дня интенсивного нетворкинга и обмена опытом. Встречаемся 23–24 сентября в Сколково. Будет хорошо!

→ Билеты и подробная программа здесь: https://boostconf.ru/projects

Реклама ООО «Партнерс», ИНН 7707435200
Erid: 2W5zFK2d3bN