Кошмар программистов или эффективный менеджмент: вышел выпуск подкаста «Магнитное поле» про 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 — что «Магнит» делает с вашими (и не только) данными
«Магнит» заказывает товар у поставщика, тот его отгружает, товар перемещается между складами, а потом его заказывает магазин и продаёт (иногда — по карте лояльности). Каждое событие в этой цепочке — новые строчки в базе данных. И это только логистика одного товара. А у такого крупного ритейлера, как «Магнит», около шести сотен информационных систем, которые генерируют данные о подобных событиях. Хранить и обрабатывать такие объёмы информации непросто — как умудряются справляться с этой задачей, объяснил «ответственный за работу с данными» Павел Шорохов.
Подробности — в подкасте «Магнитное поле».
- Люди важнее процессов и инструментов.
если так, то оставье программистов в покое. пусть планово работают по уже утверждённым стандартам и выпускают качественный продукт, а не скачут по веткам изменений. зачем вы их убеждаете программистов не сопротивляться изменениям? Вы как оцениваете затраты на переходные процессы при изменении подходов?
- Работающий продукт важнее исчерпывающей документации.
А как вы понимаете, что он "работаюший"? Ведь документации акиуальной нет. Докоучились до того уже, что вот сейчас приходится маяться с сервисом у которого "документация" для галочки. половина указанных методов не работают, примеров нет только километры непонятной спецификации и тд и тп
- Взаимодействие с заказчиком важнее согласований условий контракта.
Конечно. Посадим аккаунт менеджера, который будет вместо решений проблем тянуть кота за что-то.. и при каждом конфликтном случае ссылаться на пункт договора. Весьма удобно.
- Готовность к переменам важнее следования первоначальному плану.
Вот вот... Постоянные скачки. Сегодня бежим туда завтра сюда. Ведь только менеджеры и коучи понимабт смысл работы. Программисты это так.. аналог чатгпт... ввёл новый промпт и вуаля..
ну и шляпа.
Как PM полностью с вами согласен. Здесь работает принцип "заставь дурака богу молиться - он лоб расшибет".
Чтобы какой-нибудь скрам эффективно заработал в команде, надо очень много допущений иметь.
Дух договора выше буквы? Расскажите это клиентам, которые теряют любые ограничения в своих хотелках, принимая лояльность партера за слабость, и которые при этом последствия своих неудачных решений сваливают на исполнителей. Дух договора должны обе стороны соблюдать, чтобы это работало. Да и то, втихаря подглядывая на договор, чтобы не отходить от него в вольных интерпретациях его пунктов.
Скачки туда сюда или готовность к переменам. Ха, не каждому разработчику, даже если он в продуктовой разработке, можно объяснить что такое эмпирический подход в бизнесе, когда постоянно приходиться экспериментировать, чтобы нащупать верные бизнесовые решения. И это конечно отражается и на разработке. Сегодня пилим одно, завтра отказались от этого, пилим другое. Команда подгорает из-за сжатых дедлайнов и резких изменений в перечнях задач. И тут речь не про то, что задачи каждый день меняются, а скорее про то, что уже описанный и реализованный функционал приходиться переделывать, раз за разом. А если новый владелец продукта ещё придет....это вообще ахтунг! Тут надо понимать, что решения владельцев продуктов не всегда профессиональны, а мнение команды может и не учитываться.
Люди важнее процессов. Конечно, если это продуктовая команда, где каждый участник чуть ли не универсал в компетенциях. Где приходит владелец продукта и говорит, что ему надо, а все остальное решает команда сообща. При этом владелец продукта прислушивается к команде и даёт ей достаточно самостоятельности. Много ли вы таких команд знаете? Где разработчик сам задачу опишет, а потом закодит ее, и протестит если надо? А если у тебя за полгода состав команды уже второй раз обновился? (спецов перетасовыают внутри компании, кто-то увольняется, новые приходят). Это ещё цепляет следующий постулат про документацию, когда работающий продукт важнее. А ведь продукты и команды могут быть немаленьким, состоят из сотен человек.
Без нормальной документации новые разработчики будут тыкаться наугад. Решать задачи в 3-5 раз дольше, чем могли бы, сроки погружения в проект вырастут кратно и т.д.
В общем, нельзя сказать что гибкие методологии это плохо. Отдельные методики и ритуалы очень полезны. И они не новы! Дейли - это те же летучки на советском производстве с утра, ретроспектива - это собрание по наболевшим вопросам и т.д. В СССР в свое время тоже свой аджайл придумывали, типа НОД - научная организация труда.
Поэтому, я считаю, что все это лишь новояз. Который нельзя слепо копировать. Нельзя в это фанатично верить. И применять стоит очень осторожно. Только то, что действительно помогает. Есть академические теории управления, которые куда богаче и глубже описывают многие важные вещи. У тех же японцев можно многому научится (tps, кайдзен), голдрата почитать. В профессиональном мире скрам выглядит как игрушка
На самом деле вы и правы, и неправы одновременно. В ваших примерах много боли от неграмотного управления. Я вас понимаю.
Менять надо всё: и подход к управлению, и мышление инженера и его отношение к ограничениям.
"Постоянные скачки. Сегодня бежим туда завтра сюда. Ведь только менеджеры и коучи понимабт смысл работы" — пример нездоровой работы. Менять приоритеты каждый день — это не эджайл. Это противоречит нормальному процессу создания качественного продукта. Так и подрывающиеся жопы членов команды — это проблема. Люди важнее процессов. Людям должно быть комфортно, и они должны понимать одинаково, что выбранные приоритеты и приципы принятий решений и их пересмотра не мешают создавать качественный продукт, а наоборот способствует этому.
Суть "гибкости" эджайла не в смене приоритетов хоть каждый час, а в умении подстраиваться под изменения (рынка, понимания ЦА и её требований, бюджетных ограничений) и делать хороший продукт. Это "ловкость" и "проворность". Но никак не "сумбурность" и "хаотичность". Эджайл — это про здравый смысл, а не дикость.
"Посадим аккаунт менеджера, который будет вместо решений проблем тянуть кота за что-то.. и при каждом конфликтном случае ссылаться на пункт договора". Это как раз и противоречит идее "взаимодействие важнее согласования условий контракта". Если менеджер не способен заблаговременно выявить потребности клиента или в процессе понять, что он ошибся на старте, и перестроиться в том числе по условиям работы, это не лучший менеджер, и ему нужно развиваться как управленцу.
Суть идей эджайла в том, что не отрицается важность того, что справа. Речь про более высокий приоритет того, что слева. Например идея "работающий продукт важнее исчерпывающей документации". Документация не "не важна". Важнее появление работающего продукта.
В вашем примере "сейчас приходится маяться с сервисом у которого "документация" для галочки. половина указанных методов не работают, примеров нет только километры непонятной спецификации", кажется, продукт не рабочий. Какой смысл в документации, если половина методов не работает? Документация должна соответствовать тому, что есть и работает. Нужно в целом делать "хорошо и качественно". Это в двух словах не объяснить. Вы бы апеллировали к некачественной или отсутствующей документации, если бы сервис, который вы приняли в работу, работает как часы, спроектирован интуитивно, понятно, код его чистый и сам себя документирует?
На самом деле, идеи эджайла — это картина идеального мира, некая утопия, к которой неплохо стремиться. Но достигнуть её непросто, если не невозможно. Чтобы соответствовать этим идеям, нужно много слушать, думать и доверять. С этим много проблем как у команд и руководителей, так и у заказчиков, спонсоров и их менеджеров.
вы же понимаете, что утопия она потому и утопия, что недостижима. это как идеи коммунизма. но все идеи разбиваются о суровую объективную реальнось. все эти "человек важнее" заканчиваются лишь лозунгами. на деле любой бизнес это про прибыль. Человек там лишь заменяемый инструмент
Да, я понимаю, что идеальность недостижима. Но при этом приближаться к ней можно. Ну и нет отрицания важности зарабатывать. Делать это можно по-разному с разной удовлетворённостью людей вокруг бизнеса. В конце концов, именно от удовлетворённости людей эта прибыль и зависит. Довольные потребители продукта принесут больше денег. А как делать этот хороший продукт то? Удовлетворённый подходом и отношением к себе и коллегам инженер будет более продуктивен и лоялен, сделает больше и лучше. Это же не методология и не фреймворк. Эджайл — это про ценности, жизненные и профессиональные принципы. Если разговоры об этом в определённой компании заканчиваются лишь лозунгами, тогда как реальность остаётся в формате постоянных скачек и тянущих кота за яйца аккаунтов, упирающихся в контракты, значит кто-то балабол или что-то не так понимает в благоприятной культуре разработки.
надо начинать с правилтного. Для вас это религия и способ заработка. Я ничуть не преуменьшаю Ваши способности и умения вдохновнно продавать идеи. Ведь без истовой веры не продать это все топ менеджменту. не поверят, почуют фальш.
в отличие от рабочих, инженеров и тех же программистов коуч не производит "продукт" который приносит прибыль. вы можете самозабвенно рассказывать про корпоративные эзотерические практики, но, если продукта нет, то с вашей помощью он и не появится. вот приведите хоть какую нибудь статистику по стартапам, в которых появился продукт благодаря тому что пришел коуч и...
в советское время была вообще плановая экономика и что же. людей в космос запустили без аджайла.
да вот. третьего дня была статья человека который сам (!) без всяких "ценных срветов" как ему правильно что то делать реализовал полный спектр НИОКР в разных областях: конструкторской, дизайнерской, схемотехнической, программерской и тд и тп.
не каждое предприятие это сможет сделать.
всё в этом мире уже было придумано и перепробовано тысячи раз. работает лишь один набор правил:
- понятные условия работы и вознагражление соразмерное вложенным знаниям и усилиям
- адекватность и обязательность заказчика
(работодателя)
а все остальное лишь приходит и уходит
Насчет стремления к идеалу - спорный момент. Потому что есть разные подходы, которые по разному работают. Называя что-то идеалом, мы автоматически называем нечто "серебрянной пулей" или "священным граалем", который начинаем упорно искать и стремиться. Выходит так, что в погоне за "эффективностью" постулаты аджайла начинают пониматься буквально. И уже продукт уходит на второй план, потому что есть более интересное занятие: играться в аджайл.
Извините за резкость, но это детский сад. Слишком утопично. И не эффективно. А контраргументы далеки от реальности. Как если бы сказать, что все люди должны уважать старших, быть гуманными и честными к окружающим. Утопия.
А ещё вы не поняли комментариев разработчика, тут нужен опыт. Например, о документации - половина методов не работает, но это не говорит что продукт не рабочий. Методы были переписаны, а документацию не обновили. Сам продукт ещё как работает. Это типичный кейс, итог подхода, правое важнее левого. Да документация важна, но не так как продукт, верно? Но видите ли в чем дело, важно ещё ответить на дополнительный вопрос - для кого важнее? Для владельца продукта, для клиента, для пользователя - да, верно, это важнее. А для разработчика? У которого это уже 6-й проект за последний год? Ему важнее, чтобы документация была хорошая. Потому что если будет плохой, то задачи будут долго делаться, или ошибок много будет. И "эффективные" менеджеры поставят его квалификацию под сомнение. Так и работу потерять не долго. И теперь представьте, что у вас половина, если не вся команда из таких коллег? Представили? Задумайтесь! Не каждый разработчик это продуктовик, многие выполняют роль квалифицированного "рабочего" 22-го века, занимаясь разработкой как на конвейере, под вывеской "разработка на заказ". И таких работяг - многие тысячи!
А про аккаунта вы тоже не поняли, это был сарказм. Нанимают аккаунта, чтобы выстраивать отношения, а по факту вешают на него ещё кучу прочих активностей, вплоть до активных продаж. У такого аккаунта времени не остаётся на "отношения", и а порой и квалификации не хватает. Поэтому при конфликте они сразу лезут в договор. Чтобы в случае чего прикрыться нужным пунктом.
Некоторые проекты продают API. Для них документация - это вообще must have. Другими словами, приоритеты пляшут от того что мы продаем (с чего получаем профит).
Аджайл - это кошмар программистов.
Комментарий недоступен
Это параллельные вещи.
Это одна из веток аджайла. Это же собирательное название, гибкие методологии. Туда и канбан входит, например, и скрам и много чего еще
Сами 4 принципа нормальные, как мне кажется, то во что это превратили сейчас - жопа. Всё из разряда "хороший тамада и конкурсы интересные" с коучами, а не нормальная работа.
1. Скрам и в какой то степени аджайл - это набор проектов длиною в спринт. А все про проекты уже описано и изучено. В случае с аджайлом просто не применяется ничего с лозунгом: "мы же гибкие". Хуибкие.
2. Проблемы в менеджерах. Не умеют управлять проектами в целом, не важно какими. Нужно ТЭО, бизнес анализ, rnd/НИОКР, эти вещи всегда будут в том или ином виде, а недоменеджеры просто перекладывают все это на разработчика: "программировай, дальше разберемся" разбираться надо до кодинга и не разработчику.
Мое мнение: можно итерациями, можно гибко, можно как угодно, но проект надо вести как проект. И у аджайла в этом ловушка - там не написано как поступать эффективно.
"например, у специалиста есть удобный инструмент для автоматизации рутины, и ему кажется, что новый подход всё сломает."
Любопытно, что дальше рассмотрение идёт только в ключе "как бы теперь этого специалиста убедить сменить инструмент". Почему не рассматривается вариант, что agile-коуч был неправ и это ему надо сменить внедряемый инструмент на тот, которым пользуется специалист? Проявить гибкость :)
Хороший разбор. Правда слишком много перекоса в то, что саботируют эджайл программисты. Но и руководителям тоже нужно понимать его суть.
Комментарий недоступен
«Магнит» - это чудовищная забюрократизированная контора, переплюнувшая по степени бюрократического идиотизма госкорпорацию. Работал и там и там- есть с чем сравнить.
И подобные тексты в контексте применимости к «Магниту» звучат как анекдот. «Хрупкое звено - люди» - хахаха, да срать там хотели на людей. Что на сотрудников магазина, что на ИТ, что на аджайл. Вы попробуйте сначала там получить хоть маломальский бюджет на ИТ-проект, а потом выбрать поставщика на тендере из 100500 человек ничего не понимающих в ИТ, но имеющих особое мнение, потом мы поговорим за аджайл. Если не свалите раньше в диком ужасе, расплескивая смузи по дороге
Система строится из людей, а остальное - это каркас. Это все равно что сказать - в производстве меда хрупкое звено - пчелы. Это точно, но мед и есть пчелы. Ты можешь произвести что угодно без пчел, но это уже не будет называться медом и иметь те же вкусовые качества. Например, можно произвести "искуственное мясо", но все равно оно будет уступать по вкусовым характеристиками той же курятине.