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

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

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

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

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

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

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

#полезности
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. Поделись, что из этого ты уже измеряешь? Какие метрики на твой взгляд буллщит?

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

На мой взгляд, оптимальным решением в данной ситуации является использование подхода 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 уже классика) и так работает в такого рода кейсах?

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

“

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

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

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

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

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

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

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

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

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

“

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

#рецепт
Секретное оружие: ресурсное планирование

Здравствуй, дорогой читатель. Ты не поверишь, но многие начинающие менеджеры в последнее время совсем забывают про важнющую штуку — ресурсное планирование. Главное помни правило клуба - НИКОГДА НЕ НАЗЫВАЙ РЕСУРС РЕСУРСОМ ПРИ РЕСУРСЕ (профессионализмы могут быть странными и непогруженных могут обидеть)

Классическая логика планирования

В водопадном подходе план идёт от требований к расписанию. Подробнее смотри у Селиховкина:
https://drive.google.com/file/d/1uCV7cu_1JgVGYk9pXP-LFCv1E1EdNF3m/view?usp=sharing

1. Формируем матрицу требований (матрицу трассировки), чтобы связать каждый запрос заказчика с конкретными результатами: https://habr.com/ru/articles/831922/;
2. Далее — WBS, декомпозиция проекта на мелкие задачи (чтобы сразу было понятно, что за чем идёт):https://kaiten.ru/blog/model-wbs/;
3. Потом строим сетевую диаграмму, чтобы увидеть зависимости между задачами: https://forpm.ru/сетевой-график);
4. На основе WBS и сети определяем ресурсы, причём есть неплохая статья про это: https://probusiness.io/master_class/529-chto-nado-znat-pro-raspredelenie-resursov-chtoby-ne-zagubit-dazhe-khoroshiy-plan-proekta.html;
5. А параллельно оцениваем трудоёмкость/продолжительность — и в итоге получаем календарный план (диаграмму Ганта).

Основные этапы ресурсного планирования

1. Оценка доступности: учитываем, кто у нас вообще есть в команде, загружен ли кто-то другой работой, не ушёл ли в отпуск и тд.;
2. Оценка ёмкости: определяем, сколько времени реально может выделить каждый человек (FTE, часы и т.д.). Планировать 100% загрузку — наивно; оставь буфер на форс-мажор и обязательные митинги;
3. Предварительный прогноз качества ресурсов*: если задача сложная, то нужны опытные люди (например, только синьору можно);
4. Аллокация: распределяем, кто что делает. Связываем ресурс с задачей на диаграмме Ганта, в Excel таблице или таск-трекере;
5. Переоценка задач: смотрим, не вышло ли так, что один спец назначен сразу на три фронта. Если что — меняем план, ищем дополнительные руки;
6. Выровнивание ресурсов: обрезаем перегрузки, двигаем задачи, включаем автоматику (Microsoft Project и др.), чтобы не было «двойного бронирования»;
7. Актуализация и контроль: постоянно проверяем, как загрузка сходится с реальностью, ведь у нас могут уйти люди, или задачи сдвинулись.

И да, если у менеджера нет формальных подчинённых, часто помогают тимлиды и руководители отделов: они же владельцы «ресурсов». В итоге получаем документ (или диаграмму, или таблицу) — там расписано, кто и когда участвует в проекте. Без этого велик риск перегрузить команду и потом делать ночные овертаймы

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

P.P.S А у тебя на работе есть ресурсное планирование? Поделись, как оно организовано!

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

Ты проджект менеджер в компании Целестиал и вызрабатываете аналог Scopify, движок для интернет-магазинов. У вас в компании ПМ являются частью продуктового офиса, подчинаются CPO и больше работают в формате сервис деливери менеджеров.

В рамках работы ты присматриваешь за двумя фича-командами в яркой манерой, Паладины (обожают вов) и Десантинками (фаны вахи). Обе питаются входящими задачами от единой команды системных аналитиков, которой передают требования стейкхолдеры, часто напрямую продакты. Часть аналитиков пишет лаконичные требования в формате бизнес концепций и критериев приемки, а другая считает, что надо рисовать UML-диаграммы и расписывать юзкейсы, их постановки соответствующие

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

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

Какую сторону ты займешь? Как выйдешь из этой ситуации?

В последнее время очень сильно упало число просмотров, реакций и в целом вовлеченность. Что то поменялось в контенте, формате и вам стало менее интересно? Или я что-то упускаю?

#рецепт
Как правильно работать с капасити и велосити

Здравствуй неутомимый читатель! Я услышал твою обратную связь и пришел с более практическим, менее AI-вылизанным и менее частым контентом

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

- Начни с простого: объяви команде, что капасити и велосити — это один и тот же «спидометр»

- Велосити считай по трём самым удачным спринтам, когда «звёзды легли». Если вдруг текущий результат ниже 50 %, смело говори: «Метрика сомнительная и плавающая, не обращайте внимания”

- Длина итераций — тема для творчества. На этой итерациии сделай спринт на 10 дней, в следующей — на 15. Аргументируй “под гибкость рынка” и “неотменимостью запросов продактов”

- Спишишь? Перезапусти спринт на середине. Всё, что недоделано, выкинь из истории: «Мы же итерируемся, ребята!». Исторические данные как бы ничего не говорят

- На планировании подмигни команде и скажи: «Учёные доказали: story points чудесно складываются — 2 + 5 = 7, главное верить». Сошлись на центральную предельную теорему — большинство перестанет задавать вопросы после слов «агрегация» и «мода»

- Капасити? Планируй под единственный возможный сценарий: «никто не болеет, отпусков нет, встреч нет. инцидентов нет». Аргумент: «Scrum‑гайд про февральские простуды молчит, значит их не бывает»

P.S. Вторая порция в комментариях. Следуй этим приёмам регулярно и ваш скрам точно будет достоин рассказа на конференции
P.P.S. Чего на твой взгляд еще не хватает в списке?

#артефакты
Тренажёр постановки задач на коленке

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

Я встал в легкий ступор, особенно после последней обратной связи на посты. Мне нравится давать контент, который можно утащить и переиспользовать, а не просто прочитать слегка задуматься. И тут я застрял, а чего бы такого написать из того что мне нравится, ибо давать шаблон условной матрицы требований, если условный Grok это сделает лучше. Хороший статей не особо много именно про то как ставить задачи, а не писать ТЗ и так родился этот пост

Я собрал на коленке Task-Setting Trainer — GPT-S https://chatgpt.com/g/g-68088b1d1b648191845465ffe163f8c1-gpt-s-task-setting-trainer, который учит формулировать постановку на разработчика чуть сложнее чем User Story

Когда я задумал Trainer, первая идея была: реализовать всё на Google AppScripts — дергай данные из гугл табличек, сохраняй инструкции в Drive, строй UI прямо в браузере. Но быстро я осознал, что OAuth, квоты и тонны boilerplate-кода превратят прототип в эпопею, а чтобы ты горел как я с вайб-код генерации я не хочу. Поэтому я свернул AppScripts и остановился на JSFiddle: чистый HTML+JS, мгновенный запуск и минимум геморроя

Второй мой просчёт — я забыл, что у многих нет GPT-Plus или Team. Чтобы не оставить тебя без тренажёра, я прикладываю в комментариях все файлы с инструкциями и канвой работы. Копируй их в DeepSeek или любой аналог n8n — и твоя копия бота заработает без ChatGPT

P.S. Жду твоих идей и новых сценариев для тренажёра!

#мнение
Здравствуй, упорный читатель! Я рад что ты меня не отписываешься в моменты тишины

Ты, наверное, заметил, что меня здесь давненько не было, и подумал: “Куда пропал Артём?”. Я, как обычно, немного перегнул палку и загрузил себя по полной: кроме управления четырьмя командами (кстати, одна из них DS Core с интересными задачками по AI), я в ещё включился в операционку OKR и внедрение инцидент-менеджмента и прочего по ITIL

К этому счастью сверху свалились консультации стартапа по операционным процессам на старте, параллельное менторство, программный комитет и поездка в Ташкент на конференцию asiconf.uz, а также создание курса «Gen AI на пальцах» для менеджеров в digital (потом как-нибудь анонс)

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

Я даже сделал систему координат XYZ от 0 до 3 по каждой оси:

- 0 - не обнаружено;
- 1 - что-то есть, но надо поднажать;
- 2 - нормально, но есть куда расти;
- 3 - молодца, вопросов нет!

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

Настоящий руководитель для меня начинается от стержня - 2, навыков - 1 и мотивации - 1. Если что-то по 0 - для меня это алярм. Со своими подчиненными или чаще «подшефными» (часто лиды как бы мои, но наделе у них свой руководитель) я выбираю простые стратегии воздействия: учить, лечить или мочить. Именно в таком порядке:

- Учить - если у человека нормальная мотивация, есть стержень, но не хватает конкретных навыков или опыта. Тогда я помогаю ему расти и закрывать пробелы. И не важно они в софтах или хардах. Применяю например для Н - 1, М -1, С - 2;
- Лечить - когда навыки и стержень на месте, но мотивация проседает. Здесь уже разговоры, поддержка и поиск того, что именно драйвит человека, что его мотивирует и почему сейчас нет огня в глазах;
- Мочить - звучит жёстко, но это неизбежно, если нет и стержня, и мотивации. Я могу помочь научиться или устранить препятствия, но не сломать психику об колено. С такими людьми лучше расставаться или ротировать их от ответственности, чтобы не тормозить команду и не тратить ресурсы на бесконечные попытки улучшения

Это и есть моя простая и категоричная формула управления, основанная на моём личном опыте и стиле

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

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

Был запрос на личное - рассказываю персональный кейс

В основном я работаю ровно столько, сколько указано в контракте. Без лукавства и без фанатизма - восемь часов в день, мне все таки уже не 20 и есть в жизни вещи кроме работы. За исключением, конечно, редких ситуаций, когда "всё совсем горит ***ть" или когда лично обещал что-то C-lvl

Но вот что интересно: в эти восемь часов с течением времени стало влезать всё больше тяжёлых задач и они едят больше энергии. Раньше было условно так: 3 встречи , 3-4 задачки по часу и операционка на часик + по мелочи. А теперь: плотная подготовка к встречам, куча синхронизаций с кем-то, продолжительные задачи на изменения процессов или подготовку новых релизов. Хронометраж плотнее, задачи глубже, решений ждут быстрее. И всё это - при тех же 8 часах. Но в целом особо ничего не изменилось за последние 3 года в плане типов вопросов, которые я решаю. Я работаю стабильно примерно с 35-50 человеками и 4-5 командами через их тимлидов в продуктовом контуре

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

Если есть советы — с удовольствием послушаю. Если не хватает какого-то контекста

P.S. Спорт в жизни есть, периодический хайкинг, перерывы на гантели/скакалку каждый час и даже 10 тыс. шагов (гуляю по округе и фотографирую котов)

P.P.S. Периодически ощущаю себя как этот встреченный мной свежепомытый кот на ободранном диване