Your Agile Hub

Вы путаете корпоративную культуру с корпоративным театром. Фальшивые улыбки и плакаты на стенах, это не культура, это карго-культ.

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

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

Цифры и коэффициенты, это круто для планирования бюджета на найм, но это борьба с симптомами, а не с болезнью.

Когда мы закладываем стратегический запас по воронке в 30%, мы заранее подписываемся под тем, что в компании дырявое ведро вместо процессов. Вместо того чтобы латать дыры в удержании (Retention) и культуре, бизнес просто привыкает заливать пожар новыми людьми.

Иван, бюджет когда высокооплачиваемые инженеры тратят утро на пересказ тикетов из Jira. Это самая дорогая и бессмысленная планерка в вашем календаре.

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

База. Главная беда корп-обучения не в софте, а в подходе «push» (толкай), когда знания впихивают в людей насильно ради галочки в KPI.

В Agile мы топим за формат «pull» (тяни): когда обучение это инструмент решения конкретного затыка здесь и сейчас. Микрообучение и асинхрон как раз про это. Если сотруднику нужно 5 минут, чтобы закрыть задачу, он не будет смотреть часовой вебинар он пойдет и найдет шпаргалку.

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

Иван, можно выкопать яму на 140% плана, но если там должен был стоять дом, вы просто сожгли деньги.

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

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

Иван, позиция понятная, но это классическое управление на пожарах. Можно впихивать задачи хоть ногами, но пропускная способность команды это ведь физика, а не вопрос лояльности. Если в трубу диаметром 100 мм лить 200 мм воды, она не потечет быстрее, ее просто разорвет.

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

Согласен, в идеальном мире планирования это так и выглядит. Но на практике 100% загрузка (даже с учетом обучения) создает систему с нулевой отказоустойчивостью.

По теории систем, чем ближе загрузка к 100%, тем экспоненциально выше время ожидания (Wait Time) любой новой задачи. Если прилетает критический баг, его либо не делают сразу, либо ломают весь остальной план, который тоже важен.

Справедливый вопрос. Давайте по пунктам:

Про исправление багов: Конечно, это занятость. Но проблема в том, что при 100% загрузке на фичи у разработчика не остается времени на качественный багфикс здесь и сейчас. Баги копятся в бэклоге, превращаясь в технический долг, который потом душит проект.

Про 3 недели на кнопку: Это классический пример закона Мерфи в ИТ. Когда вся команда забита под завязку, любая мелкая правка встает в очередь. Пока согласуют, пока освободится разраб, пока проверят... В итоге делов на пять минут растягивается на недели. Это не фантазии, а суровая реальность многих энтерпрайз-проектов.

Откуда взяли: Это база теории очередей (Queueing Theory).

А про ИИ, забавно, но законы логики и управления проектами работают одинаково, хоть в коде, хоть в жизни.

Слушайте, это самая популярная ловушка в управлении. Логика понятна: кажется, что если человек не стучит по клавишам, работа стоит. Но разработка — это не конвейер на заводе, а система передачи знаний.

Давайте на примере: если вы выедете на шоссе, которое загружено на 100%, вы будете стоять в глухой пробке. Чтобы машины ехали быстро, шоссе должно быть свободно хотя бы на 20-30%.

В IT то же самое: когда разработчик загружен на 100%, у него нет времени на код-ревью коллег, на обсуждение архитектуры или исправление мелких багов. В итоге задачи стоят в очереди, а ваш Time-to-Market (время от идеи до выпуска) растет. Вы экономите копейки на простоях программиста, но теряете миллионы из-за того, что продукт выходит на месяц позже.

Так что 70% загрузки — это не убытки, это запас мощности для того, чтобы работа действительно текла, а не стояла в пробках из-за микроменеджмента

Справедливое замечание. Если Agile внедрять для галочки, он именно в это и превращается — в пустую болтовню и сокрытие хаоса. Собственно, об этом я и пишу в статье: имитация процессов (тот самый Fake Agile) убивает эффективность.

Но есть нюанс: Waterfall идеален, когда вы строите мост. А когда вы делаете ИТ-продукт, где требования меняются трижды за неделю, жесткий план на полгода, это прямой путь к тому, чтобы выпустить продукт, который уже никому не нужен.