Кошмар программистов или эффективный менеджмент: вышел выпуск подкаста «Магнитное поле» про 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 — что «Магнит» делает с вашими (и не только) данными

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

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

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

0
20 комментариев
Написать комментарий...
Bo.G

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

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

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

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

Ответить
Развернуть ветку
Павел Краснов

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

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

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

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

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

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

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

Ответить
Развернуть ветку
Maksim Nikitzov

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

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

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

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

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

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

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

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

Ответить
Развернуть ветку
Bo.G

вы же понимаете, что утопия она потому и утопия, что недостижима. это как идеи коммунизма. но все идеи разбиваются о суровую объективную реальнось. все эти "человек важнее" заканчиваются лишь лозунгами. на деле любой бизнес это про прибыль. Человек там лишь заменяемый инструмент

Ответить
Развернуть ветку
Maksim Nikitzov

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

Ответить
Развернуть ветку
Bo.G

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

Ответить
Развернуть ветку
Нет

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

Ответить
Развернуть ветку
Павел Краснов

Извините за резкость, но это детский сад. Слишком утопично. И не эффективно. А контраргументы далеки от реальности. Как если бы сказать, что все люди должны уважать старших, быть гуманными и честными к окружающим. Утопия.
А ещё вы не поняли комментариев разработчика, тут нужен опыт. Например, о документации - половина методов не работает, но это не говорит что продукт не рабочий. Методы были переписаны, а документацию не обновили. Сам продукт ещё как работает. Это типичный кейс, итог подхода, правое важнее левого. Да документация важна, но не так как продукт, верно? Но видите ли в чем дело, важно ещё ответить на дополнительный вопрос - для кого важнее? Для владельца продукта, для клиента, для пользователя - да, верно, это важнее. А для разработчика? У которого это уже 6-й проект за последний год? Ему важнее, чтобы документация была хорошая. Потому что если будет плохой, то задачи будут долго делаться, или ошибок много будет. И "эффективные" менеджеры поставят его квалификацию под сомнение. Так и работу потерять не долго. И теперь представьте, что у вас половина, если не вся команда из таких коллег? Представили? Задумайтесь! Не каждый разработчик это продуктовик, многие выполняют роль квалифицированного "рабочего" 22-го века, занимаясь разработкой как на конвейере, под вывеской "разработка на заказ". И таких работяг - многие тысячи!

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

Ответить
Развернуть ветку
Нет

Некоторые проекты продают API. Для них документация - это вообще must have. Другими словами, приоритеты пляшут от того что мы продаем (с чего получаем профит).

Ответить
Развернуть ветку
Нет

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

Ответить
Развернуть ветку
Аккаунт заморожен

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

Ответить
Развернуть ветку
Нет

Это параллельные вещи.

Ответить
Развернуть ветку
Павел Краснов

Это одна из веток аджайла. Это же собирательное название, гибкие методологии. Туда и канбан входит, например, и скрам и много чего еще

Ответить
Развернуть ветку
Corwin

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

Ответить
Развернуть ветку
Mike Platonov

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

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

Ответить
Развернуть ветку
Михаил

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

Ответить
Развернуть ветку
Maksim Nikitzov

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

Ответить
Развернуть ветку
Аккаунт заморожен

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

Ответить
Развернуть ветку
Alexey

«Магнит» - это чудовищная забюрократизированная контора, переплюнувшая по степени бюрократического идиотизма госкорпорацию. Работал и там и там- есть с чем сравнить.
И подобные тексты в контексте применимости к «Магниту» звучат как анекдот. «Хрупкое звено - люди» - хахаха, да срать там хотели на людей. Что на сотрудников магазина, что на ИТ, что на аджайл. Вы попробуйте сначала там получить хоть маломальский бюджет на ИТ-проект, а потом выбрать поставщика на тендере из 100500 человек ничего не понимающих в ИТ, но имеющих особое мнение, потом мы поговорим за аджайл. Если не свалите раньше в диком ужасе, расплескивая смузи по дороге

Ответить
Развернуть ветку
Нет
Хрупкое звено системы — люди

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

Ответить
Развернуть ветку
17 комментариев
Раскрывать всегда