Почему гибкие подходы убивают стратегию, когда их начинают применять ко всему

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

Гайд по увольнениям для руководителей среднего звена

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

Почему долгоиграющие планы в ИТ больше не работают и что использовать вместо них

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

 Атрибуты качественного процесса

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

Как оценивать эффективность команды без слежки: закон Гудхарта и показатели результата

Еще одна статья о том, почему время — деньги количество часов за компьютером почти ничего не говорит о полезности работы. Да, есть важные метрики — скорость прохождения задач, количество завершенной работы, соблюдение сроков и возвраты на доработку. Но дальше становится интереснее: любой такой показатель тоже можно испортить, если сделать его единственной целью. Начали гнаться за скоростью — упало качество; за количеством задач — задачи внезапно стали мельче. Поэтому каждому показателю нужен противовес и поиск “бутылочных горлышек”.

Уровень специалиста — это не три года опыта

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

Не начинайте разработку, пока не разберетесь с проблемой пользователя

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

Как технический директор понял, что наконец-то управляет отделом

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

Как выглядел бы большой проект 2020 года с инструментами 2026-го

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

Почему пять месяцев исследования до требований — это правильно

Кейс Альфа-Банка про лотерейный сервис, где команда почти пять месяцев не писала окончательные требования. И это было не безделье) За внешне простым «купить билет — узнать результат» обнаружились налоги, законодательные ограничения, выплаты, идентификация победителя и вообще довольно сложный путь пользователя после покупки. Поэтому вместо того, чтобы сразу зафиксировать собственные догадки в красивом задании, команда сначала разбиралась, как вся эта штука должна работать. И классный вывод: иногда раннее техническое задание не снижает неопределенность, а просто прячет ее под документом. Предпроектное исследование дорого, но разработка ненужного решения обычно дороже.

Ретро без рутины: куда на самом деле уходит час командной встречи

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

Все аутстафф-подрядчики одинаковы, пока не случился инцидент

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

Когда один инженер может сделать работу целой команды

Еще один текст про то, как ИИ меняет не столько отдельные операции, сколько устройство команды. Сильный инженер с хорошими инструментами теперь способен выполнить объем работы, для которого раньше требовалось несколько человек. Но есть и обратная сторона: если один в поле воин может за короткое время поменять половину системы, то и ошибиться он теперь может с куда большим размахом. Значит, особенно важными становятся автоматические проверки, безопасное внесение изменений и т.д.. И уже нельзя автоматически считать размер команды через привычное «вот объем работ, значит нужно еще пять разработчиков». Важнее не сколько людей, а насколько хорошо устроена сама среда, в которой они работают.

Практика эмоциональной профилактики в IT: заметить раньше, чем проблема станет очевидной

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

Как мы пошли строить агентскую разработку, а перестроили себя

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

Почему вас заменит ИИ-агент (и как этого избежать)

Про то, какую работу в компании действительно можно отдавать ИИ (господи, спасибо, что пока не всю!). Автор предлагает начинать с разбора через ИИ самого процесса: какие действия выполняются по понятным правилам, где известен ожидаемый результат, а где приходится принимать решение в неоднозначной ситуации. Проверить документ, найти сведения, разобрать типовую заявку — пожалуйста. А вот там, где цена ошибки велика, кожаных пока лучше не убирать. Заодно становится понятнее, какая работа у людей действительно останется (самое сложное, черт побери, ну почему).

Один разработчик, 14 агентов, восемь месяцев: личный опыт Tiny Teams и что из этого вышло

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

Кто будет учить джунов, если нейросети забрали всю рутину

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

До ChatGPT когнитивным долгом управляли начальники. Теперь — все

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

Спасибо, что были с нами! Расширенные дайджесты, новости, обзоры книг и курсов для РП и аналитиков — в канале «Проектный дайджест».