Junior AI PM

#почтовый_ящик
Бомбардировка задач. Часть 3

1. Стать сервисным партнёром, а не конторой-подрядчиком
Гораздо круче работать с заказчиком на партнёрских условиях. Скажи открыто: «Команда загружена, но если это очень важно, мы можем увеличить команду под эту задачу». Честность тут будет большим плюсом. Постепенно заказчики поймут, что вы не просто код пишете, а помогаете им достигать бизнес-целей

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

P.S. Поверь, и я когда-то думал, что иначе работать нельзя. Но можно. И нужно. Особенно, если тебе нравится быть живым, а не вечно загнанным в угол «заложником ситуации»

#почтовый_ящик
Бомбардировка задачами. Часть 2

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

Ты, как молодой менеджер, наверняка ощущаешь вину за то, что не справляешься, начинаешь работать до восхода солнца и заканчиваешь за полночь, а сверху всё прилетает и прилетает. И тут дело не в тебе, а в самой системе — это как наливать 15 литров воды в 10-литровое ведро и удивляться, что почему-то льется через край

У меня был похожий случай: таскал 11 проектов одновременно, и кажется, тоже жил на работе. Чем это закончилось? Выгоранием, просадкой по здоровью и потерей мотивации. Тогда-то я и понял, что вся эта гонка не имеет смысла без адекватного ресурсного и портфельного планирования

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

— Что будет, если оставить всё как есть?

— Чего не будет, если оставить всё как есть?

— Что будет, если ты начнешь что-то менять?

— Чего не будет, если ты начнешь что-то менять?

Теперь что можно сделать прямо сейчас (краткосрочно):

Во-первых, начни постепенно вводить частичную прозрачность. Я понимаю, руководство требует лукавить, что команда занимается исключительно задачами заказчика, но тебе нужно научиться договариваться иначе: «Чтобы качественно выполнить задачу, команде нужно вот столько времени». Это не «вышибалы», а честность, которая, к слову, является основой нормальных отношений с заказчиком. Лучше сказать реальный срок сразу, чем потом оправдываться за срыв

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

Долгосрочные решения:

1. Внедрить ресурсное планирование
Тебе нужно четко понимать доступность и емкость сотрудников хотя бы на месяц вперед. Для начала можешь использовать простую Excel-таблицу:

— Зафиксируй сотрудников и их доступность (часы или дни) на период, включая дейоффы, праздники, отпуска и тд;

— Учти запланированные встречи, регулярные активности и резерв на непредвиденные ситуации или риски;

— Аллоцируй сотрудников на задачи с учетом последовательности;

— Выравнивай ресурсы по задачам, соблюдая баланс между нагрузкой и приоритетностью задач;

— Это поможет тебе аргументированно говорить руководству и заказчикам о том, что ресурсы ограничены и задачи нужно планировать с учетом реальной загруженности, а не «тяп-ляп»

2. Начать управлять портфелем проектов
Проекты должны оцениваться и приоритизироваться с учетом бизнес-показателей:

— Регулярно анализируй и оценивай проекты по ROI, маржинальности, обороту и стратегической важности для компании;

— Составь карту портфеля и выяви пересечения проектов по срокам, ресурсам и задачам;

— Учти влияние проектов на финансовые потоки (cash flow) компании, чтобы руководство видело прозрачную картину и понимало важность более качественного и планового подхода;

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

3. Начать вести прозрачный диалог внутри компании
Тебе нужно показать руководству, что честность и предсказуемость важны клиентам. Вместо того, чтобы скрывать загрузку команды, предложи фокусироваться на долгосрочных контрактах и понятной аллокации ресурсов. Это снизит количество «пожаров» и повысит доверие к вам как к профессионалам

#почтовый_ящик
Бомбардировка задачами. Часть 1

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

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

“

Ситуация реальная, сам хз как решить, в данный момент ищу варианты

Я джун РМ в it компании, у мебя под крылом 8+ проектов, 5+ заказчиков и на все 1 команда (1 бэк, 2 фронта, 1 дизайнер, 1 QA, 1 content manager). Каждый заказчик думает, что команда занимается только его проектом. 7 проектов на этапе поддержки(развития), 1 из проектов пилится с нуля, сейчас на этапе отрисовки прототипов.

Я как РМ выступаешь в роли BA, SA и РМ соответственно

Методология: хз, какая, но похоже на канбан.

В данный момент задачи поступают следующим образом:
Клиент приходит, ставит задачу не понимая до конца что он хочет, РМ обрабатывает её, передает на оценку команде, после согласовывает оценку с клиентом и берем в работу.

Задачи сыпятся с неба астроидами на бедные головы команды, я как РМ не успеваю их обрабатывать (технической подкованности не хватает, следовательно не высокая скорость работы. Пока разберусь что от меня хотят). Из-за этого снижается качество проработки каждой задачи мной как РМом и командой (баги наше всё)
*сказать заказчику нельзя, что есть другие проекты по мимо его.

Как мне РМу выстроить свою работу и работу команды таким образом, чтобы:

- повысить удовлетворенность клиента,
- повысить качество проработки задач,
- повысить скорость работы

Вместо 8 часов работаю 10-14.
Если сможешь мне чем то подсказать или закинуть это в канал для обсуждения будет прекрасно иначе я скоро повешусь в петле задач)))

“

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

#полезности
Симулятор PMP

В догонку сообщению выше. Тут PMI релизнули GPT-s с симулятором экзамена. Вполне себе рабочая штука!

https://chatgpt.com/g/g-elRZlGQcX-pmi-infinity-pmp-exam-simulator

#мнение
Аджайл — это не фреймворк и вообще не про гибкость. Часть 2

Отсюда вывод: хотелось бы вместо притягивания за уши модных слов вроде «аджайл» слышать в профессиональном сообществе разговоры о конкретных инструментах, которые вы использовали в тех или иных сферах своей работы. Использовали адаптивность? Отлично! На каких этапах строительства и с помощью каких инструментов? Пусть вас при этом не удивляет, что что-то подобное использовали многие другие, включая тех, кто про аджайл даже не слышал. Для успешного применения адаптивности знать про аджайл совсем не обязательно.

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

Эмпирический подход, сюрприз, тоже отчасти про то, на что напирали создатели аджайл-манифеста. Нам нужно наводить прозрачность, чтобы проводить инспекцию. А её мы проводим, чтобы адаптироваться (вот у нас и вылез опять тот самый Adaptive). Необходимость адаптироваться к текущей ситуации — вещь довольно очевидная, и она не означает, что мы используем аджайл или скрам.

Скрам придуман из необходимости адаптироваться к БЫСТРО меняющейся среде. Если ваша среда меняется не быстро, то вполне вероятно, вы сможете хорошо адаптироваться к ней и без всякого скрама. И вполне адаптивным решением будет НЕ использовать скрам.

Все копья вокруг скрама, как правило, ломаются именно вокруг этого самого вопроса. Эмпирический процесс может привести нас к тому, что каркас скрама нам не нужен, но критики скрама задают хороший вопрос: а может ли скрам привести нас к тому, что скрам не нужен? Ведь он основан на эмпирическом подходе. Вот тут и возникает противоречие, в котором каркас создаёт нам условия для адаптивности, но сам каркас (с его обязательным набором артефактов, мероприятий и зон ответственности) совсем не гибок, а значит не может обнулить сам себя.

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

P.S. Если я скажу здесь словечко «собачка», которое, казалось бы, гораздо проще «аджайл» или «скрам», то, поверьте, все представят в голове совершенно разные вещи (от собак разных пород и размеров до «@» и молнии на ширинке). И наши споры вокруг этих слов вызваны тем, что в головах разные картинки. Ценности доказать кому-то, что твоя картинка более правильная, мало. А вот от рассказа о том, что именно ты используешь в работе и каким образом (к какому бы умному слову ты это ни причислял), довольно много

#мнение
Аджайл — это не фреймворк и вообще не про гибкость. Часть 1

Здравствуй, задумчивый читатель! В очередной раз поиграю в капитана фанатастика с длиннопостом. Частично утащил у https://t.me/fenix_xx

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

Называется это дело «Manifesto for Agile Software Development». Тут, наверное, снова сюрприз. Речь велась именно про разработку программного обеспечения, то есть говоря о строительстве, например, и применяя словечко «аджайл», мы уже как будто бы что-то не туда натягиваем.

Теперь о главной проблеме. Создатели манифеста, применив слово Agile, создали ещё одну проблему. Особенно для русскоязычного мира, который стал переводить «аджайл» как «гибкость». Но если прочитать манифест, то внезапно выяснится, что он про адаптивность, а не про гибкость. Собственно, слово Adaptive и было основным претендентом для названия манифеста, поскольку лучше всего раскрывало суть, но не было использовано (по слухам, из-за того, что у одного из подписантов уже была книга с таким названием)

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

Адаптивность призывает нас прежде всего признавать реальность и её изменчивость, и исходя из контекста принимать решения. На момент подписания манифеста хорошим решением для многих контекстов разработки программного обеспечения (много инноваций и постоянная изменчивость требований бизнеса) была определённая гибкость, что и вылилось в призыв в виде манифеста

Важной мыслью является то, что адаптивность не равно гибкость. Для того, чтобы делать качественно и выигрывать конкурентную борьбу, нам зачастую приходится проявлять не гибкость, а твёрдость. То есть адаптация к текущим условиям вполне может привести нас к жёсткой иерархии со всеми вытекающими отсюда последствиями. Или, например, мы можем проявлять гибкость в некоторой части нашего процесса (например, команда разработки), но при этом быть несгибаемыми в бизнесовой части и за счёт этого утирать нос всем нашим конкурентам. Как тут иногда справедливо замечают, гибкость бизнеса и гибкость разработки — это вообще про разное

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

Например, строительство. Как нам тут помогает адаптивность? Она, например, может нам сказать, что нужна некая гибкость во взаимодействии с заказчиком на этапе проработки архитектурного или дизайн-решения. Но при этом нам нужна твёрдость в реализации готового на бумаге проекта. Если мы начнём использовать гибкость тут, то с вероятностью 99% это негативно скажется на качестве результата и сроках реализации проекта, и ещё больше проблем мы можем словить при вводе здания в эксплуатацию (гибкость может обнулить заложенные в изначальный проект требования безопасности и соблюдение строительных регламентов)

Отсюда вывод: хотелось бы вместо притягивания за уши модных слов вроде «аджайл» слышать в профессиональном сообществе разговоры о конкретных инструментах, которые вы использовали в тех или иных сферах своей работы. Использовали адаптивность? Отлично! На каких этапах строительства и с помощью каких инструментов? Набегающая волна? Сюда!

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

На мой взгляд, оптимальным решением в данной ситуации является использование подхода CRISP-DM https://www.datascience-pm.com/crisp-dm-2/. Сейчас расскажу, почему именно этот фреймворк отвечает на вызовы проекта и почему стандартные agile-методики тут не работают

Во-первых, погружение в бизнес-контекст
Проект по автоматизации техподдержки – это не просто набор задач, а целая экосистема: речь идёт о speech-to-text, построении RAG на основе существующей документации, декодировании ответов. Данных здесь много, они слабо структурированы, конфигурация постоянно меняется из-за текучки саппорт-специалистов и различных инцидентов, а требования бизнеса зачастую расплывчатые. Поэтому важно начать с глубокого анализа и систематизации информации для последующего эффективного тестирования гипотез

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

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

В-четвёртых, особенности циклов Data Science
Подходы вроде Data Science Cycle и HADI предполагают параллельное внедрение изменений, что позволяет гибко реагировать на постоянно меняющийся поток данных и расплывчатые бизнес-требования. Да и результаты обучения не стабильны. В отличие от последовательных циклов PDCA или I&A, такой подход помогает быстрее выявлять инсайты и корректировать курс проекта

В-пятых, почему стандартные agile-методики не подходят
Классические agile-фреймворки (Scrum, Kanban и др) ориентированы на фиксированные итерации и гарантированный инкремент – небольшое улучшение, которое можно предъявить заказчику. Однако в DS-проектах изменения затрагивают систему целиком, а результат эксперимента может быть неопределённым. Такой подход больше похож на красивую презентацию, чем на реально эффективное решение

В-шестых, почему CRISP-DM – оптимальный выбор
CRISP-DM позволяет начать с глубокого погружения в бизнес-проблему, структурировать большой объём слабоструктурированных данных и адаптироваться к изменчивости процессов. Да и заложенный подход с экспрериментами короче бордербокса итерации и даже одного дня критически необходим

Сцепка Data Preparation <-> Modelling и более крупный Business Understanding <-> Evaluating дает больше циклов для обратной связи, не привязываясь к текущей орг. структуре. Она помогает не просто тестировать гипотезы, а связывать их с реальными бизнес-целями – например, снижением нагрузки на саппорт и повышением качества ответов. Такой подход особенно актуален, когда требования бизнеса расплывчатые, а данные требуют тщательного анализа

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

P.S. Как ты считаешь, насколько критично правильно выстроить такой специфический процесс при работе с данными или работа по классике (для меня scrum/kanban уже классика) и так работает в такого рода кейсах?

#полезности
17 фундаментальных метрик для IT команд

Здравствуй, наблюдательный читатель! Ниже тебя ждёт краткое, но точное описание 17 метрик, разбитых на три группы — Crawl, Run, Walk — как в оригинальном списке от одной очень забавной компании, занимающейся ERP II трансформациями. Каждая метрика расскажет тебе, как лучше понимать скорость релизов, качество разработки, безопасность, а также ценность для пользователей и бизнеса. В конце — пользительные ссылки

CRAWL (базовые метрики существования)
Deployment Frequency (DORA)
Частота поставки нового кода в продакшен или конечным пользователям. Показывает регулярность релизов и помогает увидеть узкие места процесса

Lead Time for Changes (DORA)
Время от коммита до развертывания. Если оно слишком велико, значит вы теряете адаптивность

Change Failure Rate (DORA)
Доля изменений, после которых требуется откат или срочное исправление. Чем выше, тем больше говорит о проблемах качества

Time to Restore Service (DORA)
Сколько уходит на восстановление работы после инцидента. Чем быстрее, тем выше устойчивость и меньше потерь

Time Between Failures
Средний промежуток между сбоями. Позволяет оценить, насколько надёжным стал продукт

RUN (стандартные метрики операционной эффективности)
Flow Time
Сколько занимает полный цикл задачи от идеи до продакшена. Выявляет «заторы» — длинные очереди или медленное ревью.

Flow Velocity
Сколько задач в итоге доводится до завершения за единицу времени. Позволяет отслеживать «пропускную способность» команды.

Flow Efficiency
Какую долю всего времени работы задача реально «делается», а не лежит в очереди. Низкий процент сигнализирует о больших простоях

Flow Distribution
Распределение по типам задач (фичи, баги, техдолг и т.д.). Избегает перекосов: не забывайте о балансе между новыми функциями и качеством

Team Health
Условный барометр морального состояния команды, её атмосферы и удовлетворённости. Мотивированная команда работает эффективнее и стабильнее

Mean Time to Detect
Через какое время обнаруживаются неполадки или дефекты. Если долго, уязвимости могут «жить» в системе, создавая риски

Number of Vulnerabilities
Сколько уязвимостей найдено в коде/инфре. Чем оперативнее закрываются критические дыры, тем безопаснее продукт и спокойнее сон

WALK (зрелые метрики фокуса на ценности)
Customer NPS
Индекс лояльности: показатель, насколько пользователи готовы рекомендовать продукт другим. Если NPS падает — звоночек, что люди недовольны

Time to Value
За какое время клиенты получают реальную пользу от новой фичи. Быстрая выгода = довольные пользователи и рост продукта

Service Level Indicators
Метрики, отражающие качество сервиса (доступность, время ответа, процент ошибок). Задают SLO и смотришь, укладываетесь ли в эти цели

Development Costs
Все расходы, связанные с разработкой: зарплаты, инструменты, инфраструктура. Мониторинг затрат нужен, чтобы понимать ROI и не прожигать бюджет

Product Adoption
Насколько активно и регулярно пользователи пользуются новой фичой или продуктом. Высокое adoption = проверка ценности на практике

Полезные ссылки
https://www.aha.io/roadmapping/guide/agile/agile-metrics
https://www.gitclear.com/popular_software_engineering_metrics_and_how_they_are_gamed
https://queue.acm.org/detail.cfm?id=3454124
https://martinfowler.com/articles/measuring-developer-productivity-humans.html
https://kaiten.ru/blog/f4p-framework/

Отдельно выделю: unidraw.io/app/board/b05a2ae081007f362709 — где проделана замечательная работа по канбан-метрикам от деливери-менеджеров Т-банка

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

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

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

У тебя есть друг Алекс, Senior PM в компании CloudSolve. Уже десять лет ребята успешно продают облачные решения для бизнеса: виртуалки, хранилища, инфраструктуру под ключ. Но рынок устал от «просто облаков», конкуренты демпингуют, а клиенты требуют, чтобы «всё работало само, без звонков в саппорт». Время пришло всерьёз заняться ML и Data Science, и начали они с автоматизации техподдержки 1-го и 2-го уровня

Недавно в курилке Алекс рассказал тебе, что деньги на проект дали серьёзные, и набрали лучших из лучших: физтеховцы, олимпиадники, пара аспирантов — вся команда сияет умом, но ни дня не работала над реальным продуктом. Алекс с ужасом осознаёт, что в CloudSolve нет никого, кто хотя бы примерно представляет, как управлять таким проектом. Зато сразу набежала толпа энтузиастов: «Давайте по Agile! Скрам! Ну что там может пойти не так?»

Ты же уже знаешь, что обычный Scrum для дата-саенса — это прекрасный способ красиво слить бюджет и уверенно провалиться. Потому что DS — это не веб-разработка с понятными задачами, тут одни эксперименты, которые могут закончиться ничем, гипотезы, которые то срабатывают, то нет, и бизнес-заказчики, которые говорят только: «ну чтоб умненько было и расходы на саппорт резко упали». PDCA, любимый многими менеджерами, тоже не поможет — разница между экспериментом и простой итерацией огромная. Если Алекс попытается управлять дата-саенс командой стандартными подходами, то скоро обнаружит себя одиноким, грустным и виноватым перед высшим руководством

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

Какой совет по подходу к управлению ты бы дал Алексу?

#рецепт
Как я усилил свой план погружения и вывел его на новый уровень

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

Представь, что ты приходишь на новое место работы, решаешь кризисный проект или берёшь что-то капитально новое под своё крыло. Казалось бы, всё просто: получил вводные, вник — и вперёд

Но мой опыт показал, что обычного «ознакомления по верхам» недостаточно: иногда корни проблем уходят куда глубже. Поэтому я с годами выработал свой «план погружения» (он же расширенный онбординг), а недавно, после одного модуля на курсе руководителя отдела от стратоплана, прокачал его ещё сильнее

В основе лежал мой старый рецепт включения в новое место. А теперь я дополнил его более системным аудитом. Вкратце:

1. Люди
Начинаю с 1–1 разговоров с руководителями (CTO, CIO, CPO, PM) — минут по 45. Пытаюсь понять их фокусы, проблемы, приоритеты. Затем иду к тимлидам (включая Lead QA, Lead DS): тут планирую около часа, беру сведения у HR, выясняю мотивацию и психотип. После этого говорю с каждым участником команды (30 минут на человека), а заодно со смежниками (DevOps, саппорт, дизайнеры, маркетинг, продажи) — ведь часто затыки именно на стыках. На этом этапе рождаются «карточки сотрудников» и общее понимание «кто есть кто»

2. Производство
Чтобы увидеть реальную картину, провожу Value Stream Mapping (VSM), изучаю Jira, устраиваю, если получится, короткий воркшоп STATIK. Ищу узкие места — «бутылочные горлышки», провисание задач, перегрузы. Иногда открываются просадки, о которых даже лиды не подозревали. В итоге получаем «карту производства» со всеми входами/выходами, правилами и важными метриками

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

4. Метрики
Когда уже понимаю общую канву процессов и команд, подключаю анализ метрик. Смотрю дашборды в Jira, прогоняю доски через инструменты вроде Nave (чтобы найти аномально долгие задачи или сбой в SLA). Но этим не ограничиваюсь:

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

5. Финальный свод
Все найденные «артефакты», «проблемы» и «риски» укладываю в структуру «Оперативный план – Стратегический план». Сразу становится видно, что горит и что ждёт более глобальных правок. За счёт такого подхода это не формальный аудит, а именно погружение: люди видят, что ты не боишься вникать в их детали, а значит, охотно рассказывают о настоящих болях.

P.S. Это занимает порядка двух недель фулл, кажется долго. Но зато, когда доходишь до выводов, у тебя в руках не набор «бумажек», а реальное понимание, что происходит и как это чинить. Такой онбординг проще объяснить и своей команде, и руководству: «Мы не только почитали регламенты, но и прожили их рутину, вот почему план сработает»

#почтовый_ящик
Пять ПМов сидели в баре… и спорили, кто из них вообще работает

Здравствуй, читатель, который думает что он ненастоящий ПМ
Ты задал мне вопрос “Могу ли я себя считать вообще настоящим проджектом, если я не умею писать ТЗ и ни разу не видел бюджета, да и полномочий увольнять никого нет?” Попробую ответить историей

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

Первый — из маленькой аутсорс-студии, а до этого стартапа. Он дергается, весь вечер с телефоном: то клиент, то фрилансер, то договор не подписан:
— Я и за ТЗ, и за приемку, и за дизайн. Только кофе мне пока не поручали

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

Третий — продуктовый. Он говорит словами «value», «roadmap», «action item»:
— А задачи — это не так важно. Главное, чтобы скрам-команда была зрелой

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

Пятый — с больших проектов автоматизации вроде SAP и 1C:
— Я не лезу в таски. Работаю с архитекторами, интеграторами, подрядчиками. Отчитываюсь напрямую гендиру

ПМ не управляет бюджетом

1. Я примерно знаю, сколько уходит в деньгах, с меня вест спрос;
2. У нас есть финансовый менеджер. Моя задача — не выйти за лимиты;
3. Бюджет у продакта. Я влияю через приоритезацию;
4. Бюджет спущен сверху. Я просто вписываюсь;
5. Я собираю сметы от всех потоков, обосновываю, защищаю.

Нужно ли ПМу портфолио

1. Да. Без кейсов меня ж не наймут;
2. Да. Особенно если хочешь новый проект или контракт;
3. А зачем? Метрики, влияние на продукт — это и есть портфолио;
4. Нет. Главное — стаж и знакомства;
5. Обязательно. Без кейсов ты просто «ещё один менеджер».

ПМ должен писать ТЗ

1. Ну есть ТЗ от клиента так то;
2. Часто да, если БА нет, кто-то должен;
3. Не обязан, но часто вовлечён на уровне проведения груминга;
4. Для этого есть аналитики, я тут при чем?;
5. Нет, для этого есть лиды и аналитики где-то там. Я координирую и согласовывая большие мазки.

ПМ должен заводить задачи

1. Да. Без меня доска пустая;
2. Да. Сам создаю и выставляю по ним акты;
3. Нет, команда сама умеет джирой пользоваться;
4. Нет. Это делает координатор или постановщик.
5. Нет. Я работаю с руководителями направлений, вы чего.

ПМ должен оценивать сроки

1. Да. Клиенту надо понимать объём и косты;
2. Часто нет, но мы с теми кто шарит оценим;
3. Нет. Это устаревшая практика, у нас спринты и релизы;
4. Мне их уже спустили сверху;
5. Собираю оценки от команд, согласовываю по верхам.

У ПМа есть подчинённые

1. Да, отвечаю за всех;
2. Отчасти, сильная матрица, функциональное подчинение;
3. Зачем мне, я за процессы;
4. Бывает по структуре, но решений ты не принимаешь;
5. Мои тимлиды и есть подчиненные.

ПМ может уволить

1. Да, без проблем;
2. Не напрямую. Пишу фидбек, дальше — HR или владелец ресурса;
3. Увольнение — не моя зона, но инициировать процесс могу при негативном фидбэке;
4. Это долгий процесс. Я могу только подать заявку на ротацию;
5. Могу снять с проекта, но не уволить из компании.

P.S. Если ты думаешь, что во всём этом немножко есть и ты — значит, ты точно ПМ.

P.S. Кто из них тебе наименее понятен и так не бывает?

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

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

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

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

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

В-четвёртых, даже если подозрения подтвердятся, важно не торопиться «наказывать» или увольнять, а сначала разобраться в деталях: что именно он делал, какие сервисы использовал (Claude, ChatGPT, Copilot, Eleven Labs, HeyGen, Synthesia и т.д.), и какие именно риски это несёт для компании. Это поможет и с пониманием того, какие процессы нужно улучшить и какие барьеры безопасности поставить, чтобы не пострадала бизнес-логика или персональные данные

Почему не другие варианты?

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

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

Конфиденциально обсуждать с HR или руководством без предварительного разговора с Сашей — тоже не лучший путь, пока нет хоть каких-то фактов. Руководство ждёт от тебя решений, а не просто эскалации сомнений

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

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

P.S. Как ты думаешь, насколько скоро мы начнем с ним сталкиваться?

#полезности
PSM I: сертификат, который может пригодиться (а может и нет). Часть 2

Где и как готовиться к PSM I:
- Начинаешь с Scrum Guide 2020** (это важно, старые версии не годятся):
- Оригинал (англ.) https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-US.pdf#zoom=100
- Перевод (рус.) https://scrumguides.org/docs/scrumguide/v2020/2020-Scrum-Guide-Russian.pdf
- Изучи Scrum Glossary (терминологию):
- Scrum Glossary от Scrum.org https://www.scrum.org/resources/scrum-glossary
- Полезно ознакомиться с Nexus и Evidence-Based Management (EBM), которые могут мелькать в вопросах:
- Nexus Guide https://www.scrum.org/resources/nexus-guide
- Evidence-Based Management https://www.scrum.org/resources/evidence-based-management
- Смотри поясняющие видео на YouTube:
- Хороший плейлист с разбором Scrum Guide https://youtube.com/playlist?list=PLKIWQ-FbTWhz9we1Z04L59JyVac7e-1LE
- Лучшие тренажёры и тесты для подготовки (делать их лучше по кругу и первых 2 вполне достаточно):
- Официальный Scrum Open Assessment https://www.scrum.org/open-assessments/scrum-open – покрывает около 10-12% реальных вопросов.
- Тренажёр Михаила Лапшина https://mlapshin.com/index.php/scrum-quizzes/sm-real-mode/ – хороший, но местами устарел (аккуратнее с модальными глаголами).
- Techagilist Practice Exam https://www.techagilist.com/practice-exams/psm-i-practice-test/psm-practice-exam-real-mode-questions/ – неплохой набор вопросов с пояснениями.
- Тренажёр с The Scrum Master https://www.thescrummaster.co.uk/quizzes/professional-scrum-master-i-psm-i-practice-assessment/
- Тренажёр на Internet80](https://internet80.com/psm-i-exam-simulator-1/
- Для любителей курсов Udemy:
- Complete Professional Scrum Master Training & Exam Simulator https://www.udemy.com/course/complete-professional-scrum-master-training-exam-simulator/
- Scrum Master Certification Prep (Mock Exams) https://www.udemy.com/course/scrum-master-certification-preparation-mock-exam-questions-psm-i) — подробный, но «ванильный» пересказ гайда с акцентами и тренажёрами.
- Дополнительные полезности:
- Scrum Reference Card https://scrumreferencecard.com/scrum-reference-card/
- Suggested Reading от Scrum.org https://www.scrum.org/resources/suggested-reading-professional-scrum-master

Как понять, что ты готов?

Делаешь тесты по кругу до тех пор, пока стабильно не начнёшь выбивать 90-95%. Как только смог пройти тесты на 80 вопросов за 10-15 минут с результатом выше 90% — считай, готов

Но имей в виду: это сертификат, который не сделает из тебя профи. PSM I подтверждает только то, что ты прочитал и запомнил Scrum Guide. PSM II — куда более кейсовый и непростой. А PMP и вовсе отдельная сложная история

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

P.S. Возможно, после получения сертификата у тебя возникнет ощущение, что «это всё шиза какая-то». Но даже в этом случае ты будешь увереннее говорить: «Да, я в курсе, как должен работать Scrum. У меня есть сертификат, если что».

#полезности
PSM I: сертификат, который может пригодиться (а может и нет). Часть 1

Здравствуй, задумавшийся читатель!

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

Но тут возникает вопрос: а нужен ли он тебе вообще? В России всё просто: сертификаты знают плохо. PMP ещё как-то слышали, PSM I почти никому не нужен, а про остальные говорят примерно как про сетевые диаграммы — кто-то что-то слышал, но никто толком не знает, зачем они были нужны

Однако всё сильно меняется, как только начинаешь смотреть на глобальный рынок (или хотя бы международные компании с офисами в РФ). Тут уже сертификат по Scrum — это весьма частый гость на собеседованиях и в требованиях к вакансиям. Когда я собеседовался вне России или на позиции, чуть дальше от классического проджекта, каждый 5-й раз возникал вопрос про наличие сертификатов вроде PSM, KMP, SAFe и им подобных

Тогда возникает вопрос номер два: если делать, то какой? Ответ простой: самый быстрый, простой и эффективный вариант, если ты хочешь подтвердить знание Scrum и быстро добавить что-то весомое в резюме — это PSM I от Scrum.org

Почему именно PSM I?

Во-первых, с ним относительно просто. PSM I — это не про реальные кейсы или сложные ситуации на проекте. Он проверяет, что ты действительно внимательно прочитал Scrum Guide, понимаешь его терминологию и различаешь нюансы в формулировках (внимание на модальные глаголы: should, must и could!)

Например, может ли Scrum-команда состоять из 11 человек? Да! Потому что Scrum Guide говорит, что команда должна быть (should be) не более 10 человек, а не обязана (must be). Вот такие детали могут решить исход экзамена. В целом если не знаешь английский, встроенный переводчик в браузер или расширение браузера в помощь

Во-вторых, он доступен и финансово, и организационно: из РФ/СНГ сдаётся онлайн, нужна только стабильная связь и карта для оплаты. Сложностей с этим обычно не возникает

В-третьих, его ценность в соотношении затраченных усилий и результата почти идеальна. Для сравнения: PMP — более замороченный и кейсовый экзамен, подготовка требует много времени и опыта. PSM I — совсем другая история. 15-20 часов суммарной подготовки вполне хватит для уверенного прохождения

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

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

Ты работаешь tech PM в компании, разрабатывающей платформу автоматизации документооборота и согласований для среднего и крупного бизнеса. Рынок у вас высококонкурентный, постоянно гонитесь за новыми фичами и удобством, стараясь опередить конкурентов. Внутренние процессы классический Scrum: двухнедельные спринты, регулярные ревью, еженедельные ретро и оживленные обсуждения задач на дейликах

Твоя команда небольшая, но сыгранная: два синьора-бэкендера, два фронтендера (мидл и синьор), два мидла Python-разработчика, тестировщик, аналитик, дизайнер и devops-инженер. Команда открытая, с живым общением и дружеской атмосферой

Около полугода назад к вам присоединился Python-разработчик уровня middle — Саша. Парень интересный, хоть и немного интровертный, увлекается шахматами, много рассказывает о походах в горы и любит философствовать на ретро, мол, «жизнь — это непредсказуемый алгоритм с хаотичными данными». Коллегам он понравился, однако рабочие моменты поначалу складывались сложно: на ревью его коммиты прилетали с опозданиями, код был неаккуратным и метался от camelCase к snake_case. Комментарии к задачам в Jira были очень скромные, приходилось вытягивать детали и постоянно напоминать ему о лучших практиках

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

Однажды ты обсуждал с Сашей задачу по внедрению фичи автоматического архивирования документов, и он на твой вопрос ответил настолько чётко и структурно, что это вызвало эффект дежавю. Через пару минут ты понял, откуда ноги растут: пару дней назад ты сам задавал очень похожий вопрос Claude и получил практически идентичный ответ

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

Недавно проблемы с интернетом, на которые Саша постоянно ссылался, решились, и он стал активнее общаться голосом и иногда даже включать видео на созвонах. Казалось бы, всё наладилось, но тут появилось новое ощущение, ещё более жутковатое — тот самый эффект «зловещей долины». Ты замечаешь, что движения его лица и губ на видео как будто немного неестественны, иногда чуть запаздывают или опережают слова. Голос ровный и глубокий, но словно слишком «идеальный». Ты начинаешь подозревать, что дело дошло до использования AI не только в тексте, но и голосом и видео с помощью инструментов вроде Eleven Labs, Synthesia, HeyGen или DID. Возможно, перед тобой вовсе не Саша, а его дипфейк-аватар

Ты стоишь перед выбором: принять ситуацию или срочно действовать?

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

Лучшим выбором для тебя будет именно «галера» (второй вариант), и вот почему

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

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

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

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

Почему не другие варианты?

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

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

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

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

#мнение
Четыре ипостаси Delivery Manager-а

Здравствуй, вопрошающий читатель!

Давай поговорим о самом таинственном звере в джунглях IT — Деливери Менеджере. И если ты думал, что здесь всё просто, то нет, у меня плохие новости. Тут также как ПМ-ами (удивлен что скрам-мастеры избежали такой судьбы) : на вид одинаково, а вот начинка может удивить. Итак, разбираем по полочкам

1. Agile-коуч здорового человека (новый канбан-толк)

Представь себе Деливери менеджера как опытного терапевта, который лечит не симптомы, а систему. Он смотрит на команду как на чёрный ящик, повышая её стабильность, прозрачность и предсказуемость. Это не про планирование релизов и задач, а про создание условий, чтобы у команды как сервиса ушли препятствия для выполнения работы. В таких ролях DM часто встречается в HH, МойСклад и Спортмастере, Банк СПб. Вообще в больших банках иногда любят запускать с ними эксперименты

2. Тимлид с приставкой «системный» (старый канбан-толк)

Эта трактовка уже ближе к жизни большинства команд. Деливери здесь — это менеджер, который в одной руке держит планирование, ожидания заказчиков и KPI команды, а в другой — отвертку и молоток, которыми подкручивает процессы и системы внутри команды. Он не боится быть агентом изменений, даже если официально такой лычки у него нет. По сути, это Тимлид, ПМ или даже Engineering Manager, который попутно делает жизнь команды проще, эффективнее и результативнее. Часто его можно встретить в продуктовых командах, которые работают в режиме постоянного потока

3. Начальник ПМ-ов (аутсорс и геймдев)

Здесь уже всё бюрократичнее. Деливери менеджер — это почти генерал, который следит за тем, чтобы ПМ-ы не наделали бед и всё отгружалось заказчику по внутренним стандартам качества и срокам. Он же подключается, когда запахло жареным, и начинает тушить пожары, спасая от разборок с клиентом. Короче, процессный менеджер и кей-аккаунт в одном лице, который заботится о репутации компании и сохранении клиентов. EPAM, DataArt и им подобные любят такой подход

4. Data-driven менеджер изменений (управление изменениями как функция организации)

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

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

P.S. Прежде чем пойти на собеседование, спроси у рекрутера:
"У вас Деливери больше про метрики и прозрачность, про эффективность и лидершип, про работу с заказчиками или вообще про изменения?"

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

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

Ты — кандидат в проектные менеджеры, настолько зелёный, что у тебя даже студенты синергии вызывают чувство зависти. Последние пол года ты был эдаким «эникейщиком» в стартапе у друга: чуть-чуть потестил, повёрстал лендинги на Тильде, написал пару десятков статей в блог на vc ru, немного поадминил Jira, отсидел все возможные митинги и даже попытался провести ретроспективу, на которой вся команда молчала так, будто ты был у неё денег в долг просить

Внутренне ты считаешь, что менеджер — это больше про общение и процессы, чем про технические детали. Ты уверен, что подход «любой ценой, но лишь бы горело» — это плохо, Agile бывает только в книжках, а планирование нужно хотя бы для того, чтобы было что потом корректировать. Мечтаешь получить работу мечты в компании на букву «Я», но они почему-то тебя пока не зовут

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

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

Вторая компания — жестокая галера, о которой ходят страшные слухи. Процессы там прописаны с точностью до миллисекунды, но никто их не соблюдает, зато все соблюдают «главное правило компании»: «Ты виноват по умолчанию, даже если был в отпуске». Каждое твое движение нужно зафиксировать в таймшите Jira и еще в системе внутреннего контроля, о которой даже системные админы говорят с трепетом. На работе нужно появляться строго к 9:00, за опоздание на минуту надо писать объяснительную на имя замдиректора по кадрам, которому 73 года и он тебя искренне не уважает. Но зато есть ДМС, йогурты по пятницам и ежегодный корпоратив на природе в Карелии

Третья компания — мутнейший аутсорс-оффшор, чей офис формально в Москве, но разработка — в Индии, QA — в Пакистане, а клиент — в Нью-Йорке. Из-за разницы часовых поясов тебе нужно работать в формате 24/7, а таски обычно звучат как «Сделайте ASAP, красиво и бесплатно». Культура общения отсутствует как явление, PM-ы выгорают и увольняются примерно через 4 месяца, а в документации индийского техлида тебя ждет хинглиш и что-то подозрительно похожее на мантры чтобы работало. Зато международный опыт

Четвёртая компания — крупная госконтора, монструозная структура, где слово «цифровая трансформация» означает заменить бумажную почту на скан и отправить его факсом. IT-проекты тут выглядят как «закупить 3000 лицензий и согласовать их через восемь отделов», а слово «инициатива» приравнивается к опасному преступлению. Рабочий день до минуты регламентирован, с 8 до 19 ты ведешь телефонные переговоры, заполняешь служебки и пытаешься найти крайнего в бюрократической паутине. Зато у тебя будет официальная запись «Руководитель проекта» и зарплата чуть выше рынка

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

Куда пойдёшь?