Процессы надо менять для сотрудников…а не для отчетов наверх

Есть простой способ понять, ради чего затевалась очередная «оптимизация процессов» – просто посмотреть, кому после нее стало легче.

Тем, кто в этих процессах работает, или тем, кто смотрит на них сверху.

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

Это, между прочим, подтвержденная мировая статистика, а не только мое ворчание😄. Atlassian (создатели Jira) в 2025-м опросили 3500 разработчиков и менеджеров: 90% теряют больше 6 часов в неделю на организационных неэффективностях, половина – больше 10. Целый рабочий день, у каждого так-то.
Причем сам кодинг в топ пожирателей времени не входит вообще – время съедают поиск информации и прыжки между инструментами. Ровно то, что процессы и должны были чинить.

🟢Теперь почему это не чинится.
Оттуда же: 63% разработчиков считают, что руководство не понимает их реальных проблем (год назад было 44%). Но дело далеко не только в непонимании – часть руководителей конечно все прекрасно понимают.

Просто признать, что выстроенное тобой не работает, значит подставиться.

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

🟢А это все огромные ресурсы.
Деньги, на которые можно было убрать половину реального трения в командах, уходят на постановку спектакля.

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

А вот если рутины столько же, но отчеты похорошели – поздравляю, вы заплатили за декорации.

Если решения у вас вязнут месяцами – починить легко

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

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

Лечится это тремя вещами, и внедрить их можно хоть на ближайшей встрече.

🟢Первое – на каждый висящий вопрос назначьте одно имя. Не отдел, не «пусть команда решит», а конкретного человека с правом финального слова. Остальные высказываются, но решает он. Тогда хотя бы понятно, с кого спрашивать, если тормозит.

🟢Второе – поставьте дедлайн и договоритесь, что молчание к этой дате означает «да». Больше всего времени съедает не спор, а ожидание, пока все соизволят высказаться. Если возражений с аргументами к сроку не поступило – вопрос закрыт, едем дальше.

🟢Третье, и это чаще всего главное – перестаньте гонять все подряд через тяжелую процедуру. Решение, которое легко откатить, владелец принимает сам за минуту.

Через обсуждения и согласования пускайте только то, что дорого разворачивать назад.

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

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

А вот если чувствуете, что увязли, но не поймете, где именно, – пишите.

«Команда не вывозит» – сначала посчитайте, сколько всего запустили разом

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

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

🔴Чего не стоит делать: полировать процессы внутри, пока сверху висит два десятка открытых инициатив. Доски, ретро, перетасовка ролей – все впустую, если корень выше.

🟢Что работает: подняться на уровень портфеля и честно свести, сколько компания ведет параллельно против реальной пропускной способности.
Почти всегда открыто вдвое больше, чем реально закрыть. И дальше не разгонять, а резать – оставить то, что важно сейчас, довести, потом брать следующее.

🔖Ограничение числа параллельных проектов дает больше доведенного, чем героические попытки тащить все разом.

Вещь очевидная, но на ней спотыкаются постоянно:

закрытый проект приносит ценность, пятнадцать недоделанных – ноль.

Запускать легко, а закрывать и говорить «нет» новому тяжело – особенно когда сам же наобещал наверх, чтобы выслужиться.

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

Экосистема проджекта: управляй проектами, как профи

Мы с коллегами запускаем масштабный проект – постоянно доступный каталог каналов для всех, кто управляет проектами, командами.
Это не временная активность на неделю, как все привыкли, в каталог может попасть любой желающий, имеющий блог об управлении процессами!

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

Вот кого мы совершенно точно хотели бы видеть в дальнейшем внутри каталога:

🔹 Project Managers (IT, производство, маркетинг и смежные сферы)

🔹 Delivery Directors и PMO Heads

🔹 Agile-коучи и Scrum-мастера

🔹 Авторы, пишущие про методологии (PMBOK, Scrum, Kanban), управление рисками, бюджетирование, таск-трекеры и soft skills!

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

Обязательно забирайте каталог себе в подписки, он будет пополняться: https://xn--r1a.website/addlist/MWhJqnu1PYA4NDZi

Делитесь постом со своими друзьям и коллегами. Так мы вместе сможем сделать его еще более крутым!

P.S. Если вы ведете экспертный канал по проектному менеджменту, автоматизации или фасилитации и хотите приносить пользу комьюнити – напишите @LuneaPR. Она расскажет подробнее об условиях участия! ❤️

OKR – удобный способ спросить с команды за то, что сам же и завысил

Гроува, как водится, не послушали…
OKR прижились и почти сразу стали тем, чем меряют, спрашивают и наказывают – ровно тем, от чего он предостерегал.

И дело не в том, что OKR подменяют жестким планом – формально они и остаются OKR. Крутят уже норму их выполнения, как выгодно в моменте.
Растяжимая цель и не должна закрываться на 100%, семьдесят уже успех, недобор вшит в саму идею. Вот на этой растяжимости и играют…

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

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

Свою ответственность аккуратно спустили на исполнителей.

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

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

Часть 1.
Флаг над Macintosh: что происходит с командами, которые работают не как все

В январе 83-го Джобс собрал команду Macintosh и выдал им три установки.
Одна звучала так: «лучше быть пиратом, чем идти служить во флот».
Потом над их зданием подняли черный флаг с черепом, только вместо повязки на глазу – радужное яблоко (нарисовала Сьюзан Кэр, сшил программист из команды). Позже флаг умыкнули ребята из соседнего проекта Lisa.

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

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

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

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

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

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

❓А вот идея «пусть у всех будет одинаково», между прочим, даже не менеджмент…это тейлоризм, 1911 год.
И штука эта в нашем контексте совершенно не рабочая.

Расскажу в продолжении…

Часть 2.
Управление по секундомеру: почему «пусть у всех будет одинаково» – идея столетней давности

Фредерик Тейлор был инженером на сталелитейном производстве и решал понятную задачу: как выжать больше из физического повторяемого труда.
Ходил с секундомером, замерял каждое движение рабочего и выводил тот самый «единственно верный способ» делать операцию.

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

Думать теперь положено наверху, внизу – исполнять по инструкции.

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

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

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

Но это, видимо, слишком смелое пожелание. Вот и получается: человек интуитивно чувствует, что если у всех одинаково – значит, порядок. Интуиция ровно столетней давности, зато своя.

А еще в 60-е Фидлер, за ним Лоуренс с Лоршем и Томпсон построили фундамент теории организаций – контингентную теорию.
📌Единственно правильного способа организовать работу не существует, все зависит от контекста: какие задачи, какие люди, какая среда.
Команда, которая пилит инфраструктуру, и команда, которая проверяет продуктовые гипотезы, по своей природе работают по-разному. Загнать под один процесс – сломать обеих.

Это и посчитано: в мета-анализе 85 исследований, почти 11 тысяч команд, результат выше там, где команда сама решает, как ей работать и где проходят ее границы.

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

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

🧭Рубрика: перевод с рабочего

«Дай оценку хотя бы примерно, надо прикинуть…»

Переводится так: мне нужно число, которое я через час назову руководству как срок.

Слово «примерно» не переживет пересказ, а число переживет.
Через неделю оно вернется к вам в формулировке «вы же сами говорили, 2 недели».

💡Отвечайте вилкой и условием: от 2 до 5 недель, точнее скажу, когда посмотрим интеграцию.

Если вилку не принимают и требуют одно число – вы уже знаете, зачем оно нужно.

Половину сломанных процессов чинить не надо

Непопулярное мнение для человека, которого зовут чинить процессы: часто я советую ничего не трогать.

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

У наведения порядка есть цена, и она регулярно выше потерь от беспорядка.

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

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

Вопрос перед любой переделкой один: что получим и когда это окупится.

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

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

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

🧭Рубрика: симптом

Четыре квартала без срывов, а на итогах года вашу команду не назвали ни разу

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

Ровный квартал/полугодие историю не производит. Организация в итоге платит за аварии и исправно их получает:

спокойная работа выглядит как отсутствие работы.

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

💡Что делать: собирайте сводку сами – релизы без отката и месяцы, в которые ни один срок не переехал. Раз в квартал «кладите» ее руководителю на стол без всякого повода.

Ровная работа наверх сама не доезжает, ее туда надо заносить.

Разберу вашу ситуацию постом

Я обычно пишу про то, с чем сталкивался сам, но своя практика не бесконечная (да и проблемы часто повторяются).
Так что если у вас на работе есть история, которая никак не распутывается – присылайте, разберу в канале (анонимно).

🔍Подойдет абсолютно все, где вы уперлись:

🟢«Год работаю с проектом, который никто не заказывал. Спрашиваю, зачем он – каждый кивает на соседа.»
🟢«Руководитель пообещал заказчику срок, не спросив команду. Теперь это мой срок и, судя по всему, мой провал.»
🟢«Начальник правит наши оценки вручную. Команда перестала оценивать честно и закладывает запас на будущий торг.»
🟢«Формально команда моя, фактически люди слушают функционального руководителя. Я как бы менеджер, но без права голоса.»
🟢«У нас награждают тех, кто героически чинит по ночам. Те, у кого ничего не ломается, невидимы.»

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

❗️Это не консультация: одна история – один разбор, без сопровождения. Но направление, куда смотреть и с чего начать, вы получите.

Публикую анонимно, детали меняю

⚡️Жду ваших историй по ссылке