#delivery_management — Public Fediverse posts

Убрали Story points и бизнес ослеп. Прозрачность доставки без театра оценок

Под моей прошлой статьёй ( про Scrum, который натягивают на всё подряд ) читатель описал ситуацию, от которой у меня знакомо заныло под ложечкой. Пересказываю по памяти и анонимно: «У нас под предлогом адаптации отвалились оценки и демо. Команда называет это гибкостью. И теперь нечем показать бизнесу, что разработка вообще работает». Если убрать эмоции, это самый частый вопрос, который я слышу после «какой фреймворк выбрать»: чем доказывать, что разработка работает, когда привычную витрину (оценки, графики сгорания, демо) разобрали? Я тогда пообещал в комментариях, что следующая статья будет об этом. Выполняю. И сразу договоримся на берегу, чтобы не было ложных ожиданий. Это не манифест «долой story points». Скорее наоборот: я story points люблю , пользуюсь ими и на нескольких местах работы сам же их и внедрял. Но люблю я их как инструмент с понятной задачей , а не как подорожник, который прикладывают к любой ране в надежде, что само заживёт. Разговор впереди вообще не про оценки. Он про прозрачность : что видит бизнес, когда смотрит на вашу разработку. И почему «мы стали гибкими» так часто на деле означает «нас теперь не видно». Прошлая статья была про структуру ( как собрать несколько команд вокруг одного продукта) , чтобы они не мешали друг другу. Эта — про видимость: что показывать бизнесу вместо театра оценок, чтобы вашему слову верили. Потому что оно сбывается. Всё из практики: департаменты до восьми команд, квартальные обещания, свои шишки. Цифры в примерах иллюстративные: честность мне дороже красивого графика.

https://habr.com/ru/articles/1066402/

#story_points #метрики_разработки #dora #прозрачность #delivery_management

Scrum — не серебряная пуля. Почему «натянутый» Scrum на несколько команд ломает продукт — и что работает вместо него

Есть фраза, от которой у меня до сих пор дёргается глаз: «Да там ничего сложного — просто раскатим Scrum на все команды». Обычно её уверенно произносит человек, который пару недель назад сходил на двухдневный курс, получил красивый сертификат — и теперь искренне считает, что понял, как устроена разработка. Пятнадцать лет в профессии, путь от инженера до директора разработки, до восьми команд над одним продуктом одновременно — и за это время я видел этот сценарий десятки раз. Приходит свежий «эксперт», и Scrum начинают натягивать на всё подряд: на поддержку, на исследования, на команду из трёх человек, на департамент из ста. По одному лекалу. «Потому что так правильно». Сразу оговорюсь: проблема не в Scrum. Scrum — хороший инструмент, я сам его люблю и использую. Проблема в том, что его продают и покупают как серебряную пулю — универсальное лекарство от всех болезней доставки. А потом искренне недоумевают, почему на нескольких командах, которые пилят один продукт, всё превращается в хаос из зависимостей, интеграционного ада и созвонов ради созвонов. Ниже — три вещи, на которых я набил шишки лично: (1) откуда взялся миф о всемогущем Scrum и почему сам Scrum Guide с ним не согласен; (2) почему «голый» Scrum, натянутый на несколько команд с одним продуктом, — это заявка на провал; (3) что реально работает в этом контексте — от LeSS до Team Topologies — и как в эпоху AI выбор смещается в сторону лёгких, потоковых, адаптивных подходов. Без хайпа, с источниками и из практики.

https://habr.com/ru/articles/1061124/

#scrum #less #team_topologies #масштабирование_команды #delivery_management #предсказуемость #управление_разработкой #оргдизайн #scrum_of_scrums #kanban

Как мы пересобрали роль Delivery Manager’а в условиях ограниченных ресурсов и растущих требований

Меня зовут Дианова Анастасия, я — Lead Delivery Manager в Lenta Tech («Группа Лента»). Я отвечаю за скорость поставки новых фич в приложение для заказа продуктов онлайн. В статье расскажу, как мы переосмыслили роль Delivery Manager’а, когда столкнулись с жесткими ограничениями.

https://habr.com/ru/companies/lentatech/articles/1051430/

#agile #kanban #управление_проектами #управление_разработкой #управление_командой #менеджмент #деливерименеджмент #delivery_manager #delivery_management

Как вытащить ИТ из кризиса перегрузки, если найм запрещён

Команда начинает тонуть не в тот момент, когда задач становится много, а когда поток работы перестаёт соответствовать реальной пропускной способности разработки. В статье — разбор ситуации, знакомой многим IT‑командам: дедлайны не двигаются, найм заморожен, техдолг растёт, инциденты множатся, а люди постепенно выгорают. На примере условного «ФинТеха» автор показывает, почему попытка «ускориться ещё сильнее» обычно только усугубляет кризис и как двухнедельный Stop the Line может вернуть управляемость процессам без расширения штата.

https://habr.com/ru/companies/otus/articles/1032730/

#выгорание_команды #перегрузка_разработчиков #технический_долг #WIP #lead_time #управление_ITкомандой #инциденты_в_проде #Stop_the_Line #операционная_эффективность #delivery_management

Управление тимлидами: не контроль, а системное лидерство

Управлять тимлидами — это не раздавать задачи и проверять сроки. Это выстраивать среду, где сильные технические лидеры могут проявить себя без микроменеджмента. В статье разберем какие ошибки совершают 90% руководителей, почему контроль убивает инициативу, и как перейти к системному лидерству с помощью OKR, DORA-метрик и роли Delivery Manager. Без воды, с конкретными кейсами и схемами!

https://habr.com/ru/companies/otus/articles/1022168/

#управление #управление_тимлидами #delivery_management #лидерство_в_IT #OKR #метрики_доставки #карьера_в_IT #управление_разработкой

PBR в Sugar CRM: как мы заменили скучные лекции на живые воркшопы и перестали срывать спринты

Личный опыт лидера команды по переходу от формального "зачитывания требований" к совместному созданию понимания. Простые шаги, которые помогли нам победить "иллюзию понятных задач" и в разы сократить количество срочных доработок в середине спринта. Прошел год с тех пор, как наша команда Sugar CRM совершила прыжок из уютного водопада в бурные воды Agile. Мы пережили мучительные получасовые, а иногда и часовые дейлики вместо 15-минутных, прошли через «гадание на кофейной гуще» на планировании спринтов и вроде бы обжились. Но одна проблема упорно не сдавалась, грозя похоронить все наши agile-начинания. Мы вроде делали всё по книжке: проводили Product Backlog Refinement (PBR), оценивали задачи в Story Point (SP), обсуждали задачи, писали чек-листы и выходили с встреч с чувством выполненного долга. А потом начинался спринт. И всё шло под откос.

https://habr.com/ru/companies/uralsib/articles/988252/

#трансформация #pbr #agile #продукт_менеджмент #продуктовая_разработка #управление_разработкой #delivery_management #продуктивность #управление_командой #системный_анализ

[Перевод] Роковая ошибка управленца: избыток лидерства и недостаточно менеджмента

По сравнению с управлением лидерство носит некоторый налёт мистичности. Но мистика не помогает выполнить работу. «Он менеджер, а не лидер», — объяснял мне мой собеседник, говоря об ИТ-директоре в пренебрежительном тоне. Я провел ещё несколько десятков интервью методом оценки 360 градусов, иными словами, поговорил с большим количеством разных людей — и подтвердил диагноз. За исключением одного: внимание ИТ-директора к управлению было, выражаясь техническим языком, «благим делом». Потому что в бесконечных спорах о разнице лидерства и менеджмента часто упускается из виду тот момент, что менеджмент нацелен на выполнение работы. Лидерство представляет собой важный набор методов, который менеджеры используют для того, чтобы замотивировать людей в компании принять направление, которое они пытаются задать. А это действительно помогает выполнять работу. Это важный фактор, но не главный.

https://habr.com/ru/companies/otus/articles/828872/

#delivery_management #лидерство #управление

Метрики для оценки эффективности команд на удаленке и не только

В далёкие славные времена мы все работали в офисе и оценка эффективности команды решалась постоянными вербальными контактами. В те времена вовлеченность команды оценивались не столько по цифровым показателям, сколько по времени нахождения всех участников разработки в одном помещении… В 2020 году мы, как и все, перешли на удаленку. Логично, что через некоторое время у менеджмента возник вопрос — насколько мы там эффективны? И второй, вытекающий из первого: что мы, как менеджмент, делаем для управления этой самой эффективностью? Для ответов одних бизнес-показателей, очевидно, недостаточно, — они не отвечают на вопрос на сколько эффективно мы растем в ИТ. Нам нужны были метрики производства с учетом методологий и процессов применяемых в организации. В конце концов, мы же хотим понять — эффективна удаленка или нет?

https://habr.com/ru/companies/alfa/articles/781654/

#эффективность_разработки #delivery_management #метрики_производительности #итерационная_разработка #управление_проектом