Кошмар программистов или эффективный менеджмент: вышел выпуск подкаста «Магнитное поле» про Agile

Составили успокаивающий конспект для тех, кто вздрагивает, услышав про этот подход.

Кошмар программистов или эффективный менеджмент: вышел выпуск подкаста «Магнитное поле» про Agile

Материал подготовлен при поддержке Magnit IT

«Завтракаст» опубликовал пятый выпуск «Магнитного поля» — подкаста о технологиях и процессах в ИТ, который он делает совместно с командой ритейлера «Магнит». Гость выпуска — Agile lead «Магнита» Всеволод Сыров — руководит командой коучей, которые внедряют гибкие подходы разработки в компании.

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

Мы послушали подкаст и выделили самые интересные моменты.

Не методология, а способ мыслить

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

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

  • Люди важнее процессов и инструментов.
  • Работающий продукт важнее исчерпывающей документации.
  • Взаимодействие с заказчиком важнее согласований условий контракта.
  • Готовность к переменам важнее следования первоначальному плану.

Саботаж — обычное явление

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

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

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

Например, сотрудник понимает, что все перешли на BI-отчётность, а его команда до сих пор отправляет руководству файлы в Excel. Ему не хочется выглядеть хуже — привычное поведение становится некомфортным. Человек меняет подход, а затем подтягиваются и остальные участники команды.

Agile вообще мало кому нужен

Менеджер Microsoft Дэйв Сноуден предположил, что среда, в которой мы существуем, делится на четыре типа: простую, сложную, запутанную и хаотическую. Для каждой из них — свои способы решения проблем.

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

Компании не нужны гибкие методологии, если она может действовать по инструкции, — допустим, когда строит типовые дома. И если всё вокруг горит, то Agile не нужен тем более.

Собираться на стендап или ретроспективу, когда у вас упал сервер со всей базой и нет бэкапа, — так себе идея.

Хрупкое звено системы — люди

Подходы Agile можно изучить по книжкам и курсам, но важные навыки получится освоить только на практике. Если менеджеру не хватает опыта взаимодействия с людьми, то маловероятно, что он сможет поменять систему.

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

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

Никто не застрахован от появления Илона Маска

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

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

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

В подкасте «Магнитное поле» разбираются, как устроены разные направления ИТ и зачем они нужны. Вот о чём рассказывали в предыдущих выпусках.

В выпуске №1 — какие технологии для доставки использует крупнейший ритейлер России

В 2022 году рынок сервисов доставки еды вырос в 2,5 раза по сравнению с годом ранее. Успевает за таким темпом «Магнит» за счёт различных технологий: «под капотом» машинное обучение и много аналитики. Как всё это устроено, рассказал Евгений Николаев — «ответственный за выручку» в компании.

В выпуске №2 — про наём и организацию рабочего быта в условиях неопределённости

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

В выпуске №3 — как устроена ИТ-инфраструктура, с которой взаимодействуют десятки миллионов пользователей

Чтобы сохранять гибкость, «Магнит» вкладывается в автоматизацию процессов, а также старается снизить затраты — в том числе с помощью ресурсов облачных технологий вместо аппаратного обеспечения. В планах компании на 2023 — запустить бизнес-юниты полностью на облачных технологиях. Технический директор Юрий Мисник и директор по архитектуре и инфраструктуре Татьяна Коваль рассказали об этом и других планах подробнее.

В выпуске №4 — что «Магнит» делает с вашими (и не только) данными

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

Подробности — в подкасте «Магнитное поле».

АО «Тандер», Реклама

1313
20 комментариев

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

- Работающий продукт важнее исчерпывающей документации.
А как вы понимаете, что он "работаюший"? Ведь документации акиуальной нет. Докоучились до того уже, что вот сейчас приходится маяться с сервисом у которого "документация" для галочки. половина указанных методов не работают, примеров нет только километры непонятной спецификации и тд и тп

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

- Готовность к переменам важнее следования первоначальному плану.
Вот вот... Постоянные скачки. Сегодня бежим туда завтра сюда. Ведь только менеджеры и коучи понимабт смысл работы. Программисты это так.. аналог чатгпт... ввёл новый промпт и вуаля..
ну и шляпа.

8
Ответить

Как PM полностью с вами согласен. Здесь работает принцип "заставь дурака богу молиться - он лоб расшибет".

Чтобы какой-нибудь скрам эффективно заработал в команде, надо очень много допущений иметь.

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

Скачки туда сюда или готовность к переменам. Ха, не каждому разработчику, даже если он в продуктовой разработке, можно объяснить что такое эмпирический подход в бизнесе, когда постоянно приходиться экспериментировать, чтобы нащупать верные бизнесовые решения. И это конечно отражается и на разработке. Сегодня пилим одно, завтра отказались от этого, пилим другое. Команда подгорает из-за сжатых дедлайнов и резких изменений в перечнях задач. И тут речь не про то, что задачи каждый день меняются, а скорее про то, что уже описанный и реализованный функционал приходиться переделывать, раз за разом. А если новый владелец продукта ещё придет....это вообще ахтунг! Тут надо понимать, что решения владельцев продуктов не всегда профессиональны, а мнение команды может и не учитываться.

Люди важнее процессов. Конечно, если это продуктовая команда, где каждый участник чуть ли не универсал в компетенциях. Где приходит владелец продукта и говорит, что ему надо, а все остальное решает команда сообща. При этом владелец продукта прислушивается к команде и даёт ей достаточно самостоятельности. Много ли вы таких команд знаете? Где разработчик сам задачу опишет, а потом закодит ее, и протестит если надо? А если у тебя за полгода состав команды уже второй раз обновился? (спецов перетасовыают внутри компании, кто-то увольняется, новые приходят). Это ещё цепляет следующий постулат про документацию, когда работающий продукт важнее. А ведь продукты и команды могут быть немаленьким, состоят из сотен человек.

Без нормальной документации новые разработчики будут тыкаться наугад. Решать задачи в 3-5 раз дольше, чем могли бы, сроки погружения в проект вырастут кратно и т.д.


В общем, нельзя сказать что гибкие методологии это плохо. Отдельные методики и ритуалы очень полезны. И они не новы! Дейли - это те же летучки на советском производстве с утра, ретроспектива - это собрание по наболевшим вопросам и т.д. В СССР в свое время тоже свой аджайл придумывали, типа НОД - научная организация труда.
Поэтому, я считаю, что все это лишь новояз. Который нельзя слепо копировать. Нельзя в это фанатично верить. И применять стоит очень осторожно. Только то, что действительно помогает. Есть академические теории управления, которые куда богаче и глубже описывают многие важные вещи. У тех же японцев можно многому научится (tps, кайдзен), голдрата почитать. В профессиональном мире скрам выглядит как игрушка

2
Ответить

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

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

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

Суть "гибкости" эджайла не в смене приоритетов хоть каждый час, а в умении подстраиваться под изменения (рынка, понимания ЦА и её требований, бюджетных ограничений) и делать хороший продукт. Это "ловкость" и "проворность". Но никак не "сумбурность" и "хаотичность". Эджайл — это про здравый смысл, а не дикость.

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

Суть идей эджайла в том, что не отрицается важность того, что справа. Речь про более высокий приоритет того, что слева. Например идея "работающий продукт важнее исчерпывающей документации". Документация не "не важна". Важнее появление работающего продукта.

В вашем примере "сейчас приходится маяться с сервисом у которого "документация" для галочки. половина указанных методов не работают, примеров нет только километры непонятной спецификации", кажется, продукт не рабочий. Какой смысл в документации, если половина методов не работает? Документация должна соответствовать тому, что есть и работает. Нужно в целом делать "хорошо и качественно". Это в двух словах не объяснить. Вы бы апеллировали к некачественной или отсутствующей документации, если бы сервис, который вы приняли в работу, работает как часы, спроектирован интуитивно, понятно, код его чистый и сам себя документирует?

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

1
Ответить

Аджайл - это кошмар программистов.

3
Ответить

Комментарий недоступен

Ответить

Сами 4 принципа нормальные, как мне кажется, то во что это превратили сейчас - жопа. Всё из разряда "хороший тамада и конкурсы интересные" с коучами, а не нормальная работа.

Ответить

1. Скрам и в какой то степени аджайл - это набор проектов длиною в спринт. А все про проекты уже описано и изучено. В случае с аджайлом просто не применяется ничего с лозунгом: "мы же гибкие". Хуибкие.
2. Проблемы в менеджерах. Не умеют управлять проектами в целом, не важно какими. Нужно ТЭО, бизнес анализ, rnd/НИОКР, эти вещи всегда будут в том или ином виде, а недоменеджеры просто перекладывают все это на разработчика: "программировай, дальше разберемся" разбираться надо до кодинга и не разработчику.

Мое мнение: можно итерациями, можно гибко, можно как угодно, но проект надо вести как проект. И у аджайла в этом ловушка - там не написано как поступать эффективно.

2
Ответить