Чему меня научило управление платформой, которая распределяет 90 000 встреч в день

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

Стоит ли писать ТЗ на разработку в 2026 году и зачем

Автор спорит с тезисом «мы работаем гибко, поэтому ТЗ нам не нужно». Но, слава богу, воскресить трехсотстраничный документ по ГОСТу он тоже не предлагает. Предлагает “минимальный общий образ результата”: термины, роли, основные сценарии, границы первой версии, связи с другими системами, ограничения и критерии приемки. А дальше требования вполне можно уточнять по ходу работы. В целом, норм, потому что гибкость хоть и отменяет попытку заранее описать вообще весь проект, но отнюдь не отменяет необходимость договориться, что именно мы собираемся строить.

Вы выбираете не решение. Вы выбираете его будущие проблемы

Ситуация: нашли несколько норм вариантов для проекта, - и как выбрать правильный? У каждого своя цена, ограничения и будущие проблемы. Автор предлагает сравнивать не только стоимость и сроки внедрения, но и дальнейшее сопровождение, обратимость решения, организационные изменения и последствия возможного отказа от него. Из важных тезисов: 1) таблицы с баллами - да, они полезны, пока помогают увидеть различия, но потом становятся вредны, ибо позволяют сказать «ну вот таблица и выбрала». 2) проблема с разделением ответственности: специалисты должны показать варианты и рекомендовать, а решение должны принимать те, кому потом жить с ним и платить за них. 3) пока крупное решение не принято, не обязательно останавливать весь проект; достаточно не делать работу, которая необратимо заталкивает его в один из вариантов.

Перестаньте делать фичи, которые никому не нужны

Узнали? Любимая ловушка: идея кажется настолько хорошей, что команда начинает доказывать ее ценность сама себе и бегом тащит в разработку. А потом она просто не востребована… Автор разбирает несколько способов принятия решений по фичам — от подробного сравнения вариантов до быстрого выбора при недостатке времени и данных. Конечно же, он против интуиции: это не какое-то шестое чувство, а накопленный опыт, который совсем не обязан совпадать с поведением реальных пользователей. Значит, до начала разработки полезно доказать не только, что решение выглядит разумным, но и что проблема вообще существует, а люди действительно захотят что-то менять ради ее решения.

Первый опыт управления IT-командой: три вывода, которые я сделал

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

Как за 5 минут аннигилировать завод

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

Как сохранить историю сварного шва на 60 лет, не построив ещё одно озеро данных

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

Депеши, карточки и паранойя: мой опыт скрещивания Waterfall и Agile в проекте для РЖД. Часть вторая

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

Миф о талантах или еще один пример ошибки выжившего

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

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

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

Двадцать цифр с фото: как контрольные суммы убирают человеческую ошибку из возврата денег

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

Гайд Anthropic по AI-native SDLC

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

Кто на самом деле пишет ваш проект

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

Два года я был прав — и это ничего не меняло

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

Куда уходит время: вот уже девять месяцев я трекаю работу и почти всю жизнь

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

Почему коммерческие инициативы застревали между функциями

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

Куда уходят деньги, или Когда управление проектами начинает «съедать» бюджеты компании

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

Почему мои оценки сроков всегда ошибались в одну сторону

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

Мы не смогли выбрать таск-трекер и написали свой за два дня. Канбан прожил два с половиной часа

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

Что проще: спроектировать мост или внедрить таск-трекер? Делюсь опытом команды

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

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