Я — Максим Цепков приветствую Вас на своем сайте
|
Я буду рад любым комментариям и обсуждениям. Авторизоваться для этого можно, регистрируясь на сайте или через OpenID. При желании, вы можете размещать здесь свои материалы по тематике сайта. MaksWiki содержит 672 статей IT-тематики. | |
Обо мнеМоя основная работа — проектирование корпоративных и банковских систем. Я верю, что автоматизация — дает новые возможности развития, поэтому создавая автоматизированные системы мы открываем путь прогрессу и делаем мир лучше. Я делаю это, работая главным архитектором дирекции развития решений компании CUSTIS. Я верю в эффективность командной работы, эффективность профессиональных сообществ. И я участвую в жизни ИТ-сообщества - через работу в программных комитетах конференций SECR AnalystDays и просто в коммуникациях на разных площадках. А еще я люблю путешествовать, об этом и о других идеях вне профессиональной деятельности я пишу в своем ЖЖ. |
Я в сетиhttp://www.facebook.com/mtsepkov http://www.linkedin.com/in/mtsepkov http://www.slideshare.net/mtsepkov/ e_mail M.Tsepkov@custis.ru |
Последний постВ пятницу был на 20 конференции AgileDays. Основной вывод: Agile-методы получили очередной теоретический импульс осмысления. Те практики организации команд, которые складывались в последние годы, были осмыслены и сформированы в конструкции. Основное их отличие от традиционных — это высокая динамика команд и их разнообразие. Начало этому положила книга Team Topologies, которая рассматривала разнообразие команд и их взаимодействия. А далее, на основе этого возник фреймворк unFIX (там русский перевод) и другие. И это, на мой взгляд, существенное продвижение, которого не происходило уже достаточно давно. Team Topologies я смотрел, эти фреймворки тоже буду смотреть. Отдельных докладов по новым фреймворкам не было, они пока в процессе освоения. Было два обзорных доклада о развитии Agile — Асхата Уразбаева и Ильи Павличенко. Они различаются позиционированием нового: Асхат считает, что такие методы точнее называть пост-agile, а Илья считает это дальнейшим развитием. Мне точка зрения Ильи ближе, но принципиальной разницы тут нет: вопрос в позиционировании и маркетинге, а не сути. Подробнее я прокомментирую в конспектах докладов. А пока отмечу, что на моей памяти все это уже было, и в отчете AgileDays-2013 я писал про конференцию разочарованных, и анализировал это подробнее. Можете посмотреть отчет. А потом — был новый импульс развития. Обоим спикерам задавали вопрос про Integral Agile, о котором они не слышали. Мне стало интересно, я посмотрел. Авторы говорят, что обычные методы agile-трансформации компании легко распространяют процесс, но часто не достигают результата, и предлагают в качестве основы для процесса трансформации использовать интегральный подход Уилбера в качестве системного взгляда через четыре квадранта: mindset и поведение личности, культура и конструкция организации. Наверное, было бы интересно, если бы они провели реальный синтез, а его нет. Я посмотрел их сайт (требуется vpn), там интегральный подход — отдельно, agile — отдельно, при чем в форме простого scrum, как он был в первых версиях на user story, agile-манифест и принципы вообще не рассмотрены. Так что, по-моему, это попытка консультантов интегрального подхода ответить на запрос рынка. Еще был крайне интересный доклад Павла Алферова о влиянии культурных различий разных стран на применение Agile-методов. Павел много лет работает над созданием light-версии проектного подхода, которая бы вобрала бы достижения Agile-методов и у него получается хороший результат. И одна из важных составляющих его работы — адаптация проектного подхода к российской культуре, о влиянии национальных особенностей у него было несколько докладов. А тут он увидел статью португальских agile-коучей о том, почему Agile-методы плохо работают в Германии. И решил глубже посмотреть исследования о культурных отличиях. И в докладе очень много интересного, там не только про Германию, но и про Бразилию, ЮАР, Японию, Китай и Индию. Часть проблем объясняются моделями культурных различий, Павел опирается на The Culture Map Эрин Мейер, но часть работ показывают национальные особенности, не отражаемые в этой модели напрямую, а связанные с местными традициями. И это — очень интересно. Как обычно, на конференции было много нетворкинга. Уже несколько раз она проходит в гибридном формате: online день был в начале недели, а в пятницу — очная часть. Online-часть включала три трека докладов и три трека воркшопов, а очная — три трека докладов, четыре трека очных воркшопов и еще один трек online-воркшопов. К сожалению, работа не позволила мне быть на online-дне, надеюсь, получится найти время и посмотреть доклады в записи, хотя бы Анну Обухову. А офлайн-часть включала много очень содержательных докладов и громадное количество нетворкинга. И это — прекрасно. Два очных дня, конечно, были бы еще лучше, но такой формат — тоже хорошо. Так что громадное спасибо организаторам. А я перехожу к обзору докладов в том порядке, в котором я их слушал. Константин Воронин. Приручить хаос: как создавать устойчивые системы при непредсказуемых руководителяхДоклад о взаимодействии с руководителями, про которые кажется, что они вносят хаос, меняя решения и принимая их из странных соображений. Он говорил о топах, но применимо и для других уровней. Весь доклад — из позиции того, кто несет в компанию изменения. В чем проблема? Хаотическое поведение первых лиц ведет к выгоранию ключевых сотрудников — они больше взаимодействуют с топами. Ощущение тушения пожаров, а не планомерная работа. Ограниченность творчества: первое лицо замыкает на себя все решения. И решения — не прозрачные. Многие компании говорят, что data-driven, дашборды. А решения топ принимает по-своему. Как с этим работать? Дальше есть принципы работы с первыми лицами. 1. Результаты первого лица важнее личных качеств. Надо это принять. Не все лидеры одиозные, есть много эмпатичных. Есть хуже: (а) есть эмпатичные, классно общающиеся, но за закрытыми дверьми — жесткие, и тогда агрессивными кажутся подчиненные; (б) есть те, кто вообще не фильтруют. Первые лица такие, потому что у него очень мало времени. Они мыслят стратегией, у них часто нет времени вникнуть в вашу задачу, потому что она по приоритетам мала. Есть классные ситуации — когда первое лицо надолго погружается. Но это не из-за задачи часто, а потому что хочет понять мышление сотрудника. Первые лица, большинство — на своем месте. Драйвят компанию, ведут вперед. Иногда его босс говорит какие-то вещи, кажется «чушь» — а оно работает. Видимость, обладание информацией sensitive, видение рынка. Когда-то он наивно возмущался «я бы на его месте» — но нашлись люди, которые сказали — но ты-то не на его месте, и не можешь полноценно оценить, почему он принимает такие решения. МТС-банк. Рейтинг продуктов — влияние продукта на стратегические цели. Смотрели на хвост — продукты в конце рейтинга — что сделать? Закрыть? Однажды попалось два продукта, первое лицо решило дать шанс — и реально через 1.5-2 года вышли в топ. 2. Влияние топ-менеджмента важнее ваших (больше) усилий по изменениям (внедрение фреймворков, стандартов и так далее). Три категории подчиненных первого лица.
3. Гибкие процессы и инструменты важнее стабильности (стабильных agile-процессов). Что нужно? Гибко и быстро переключаться в ответ на внешние воздействия — включая воздействия первого лица. Если есть слишком много влетов от первого лица, которые не соответствуют стратегии — значит проблемы со стратегией. Первый инструмент — прозрачность. Это — база. Первая задача — опрозрачить все что происходит: команды, цели, результаты. И это — первый шаг, например, чтобы показать почему много разработчиков. Но! Прозрачность ради прозрачности никому не нужна. Она должна давать проекты решений, подтверждать или опровергать интуитивные представления. Big room meeting. Бывает, что первое лицо участвует и вовлекается. Или хотя бы топы ходили. Например, PI-планинг. Но! Суетунов — не звать, там будет демотиванция. Может, даже инструмент надо поменять. Учитывайте контекст организации. Есть компания, где цикл — 2 недели. Но этого мало, часто все равно нужен hotfix. И они часть мощности резервируют под срочные запросы. Или можно делать команду спецназа. Ищите варианты оптимизации коммуникаций. Есть много проектов, где заключили с местными госуслугами, надо сделать ивент за месяц, и это на контроле первого лица. И вы не знаете что делать. Соберите всех экспертов. Была ситуация flow, сделали за месяц и сделали. Мозгоштурмом сделали путь. И самое главное транслировать сотрудникам, что это такой процесс. 4. Управление ожиданиями важнее быстрых ответов. Первые лица ставят задачи очень быстро. CEO ругается «зачем приходят к 10, а в 18 стоят в очереди». И HR принес инфу о проходах. Это CEO не нужно, ему надо знать, что менеджеры управляют. Даже если все горит — менеджеры управляют этим пожаром. Когда топ дает запрос — думайте в чем боль, и какая бизнес-проблема за этим. И когда он спрашивает «где» — не отвечайте «в разработке», ему важен не статус, а когда будет готово. 5. Выстраивание процесса важнее изменений лидера. Не надо изменять лидера. Вы попробуете на него повлиять, изменить его — а наткнетесь на агрессию. Или он просто станется таким же. И даже если вы сильный психолог выбьете почву — компания, скорее, пойдет вниз. Потому как первое лицо держит. Первое лицо меняется с компанией. Не быстро. Они будут меняться, не надо давить. 6. Отношения важнее всего. Конкретный момент ничего не значит. Вы думаете — он похвалили и запомнил, а это был проходной момент. И наоборот. Надо приподняться над моментом и понять, на что первое лицо обращает внимание. 7. Как не выгореть самому. Мы все в найме. Первые лица нам платят зарплату. Можно менять компанию. Потоv следующую. Но если вы меняете компании — то вам же не нужно тихое место. Смотрите на ситуацию как на вызов. Лидеры могут не измениться, но в наших силах выстроить систему, которая выдержит их давление, и будет работать синергично с ними. Карина Хашина. Управление командами на основе культурного кода и спиральной динамикиЭто доклад — о работе с командой в токсичной корпоративной среде интригующих одиночек, о том, как вести ее в светлое будущее. Именно так описана стартовая ситуация: вас назначили руководителем незнакомой команды, и тут пошли проблемы.
Собственно, такой корпоративный мир хорошо показан в книге «Лидер и племя», одному из авторов которой, Джону Кингу, и принадлежит модель культурного кода из пяти уровней, также используемая в книге. Впрочем, Карина в докладе книгу не упоминала, а Джон Кинг — распространенное имя, так что могу ошибаться. Но описания уровней — очень похожи. Итак, уровням соответствуют такие картины мира.
Основная масса сотрудников — 2 и 3 уровень. В презентации была ссылка на тестирование по культурному коду, это не тест, а инструкция по проведению беседы. Другая используемая модель — спиральная динамика, но не как модель личного развития, а в виде (кем-то) построенной на ее основе модели мотивации.
У меня к такой интерпретации есть возражения, но я не буду их разбирать подробно, так как модель была рассказана очень быстро и, возможно, что детальный разбор покажет, что разница не слишком значительная. Я в свое время разбирал мотивацию в модели спиральной динамики в статье Вовлеченность: от зарплаты за компетентную работу к драйву и счастью на работе, а в статье Лидерство: от единоличного в индустриальном мире к переходящему в цифровом разбирал эволюцию лидерства. Карина сопоставила обе модели между собой линейным образом. На мой взгляд, это не совсем корректно, потому что модель Кинга включает дихотомию позитивного-негативного отношения к миру, которая в спиральной динамике не рассматривается, поэтому уровни смешаны иным образом, я это немного разбираю в своем отзыве на книгу Лидер и племя). Но это — тоже детали. Поскольку в корпоративном мире люди разобщены, и они находятся на разных уровнях. Поэтому для развития нужна индивидуальная работа. Общие сообщения не будут восприниматься: для одних это будет детский сад, а другие — могут просто не понять, так как не знакомы с концептами, а в сообщении не будет слов-сигналов принадлежности группе. Для начала руководитель должен стать в группе своим. Как? Надо знать языки и привычки всех пяти уровней. И отслеживать, кто из членов команды на каком языке говорит и общаться соответственно. А дальше — поднимаем их до четвертого уровня по Кингу, но последовательно.
В ответах на вопросы был затронут вопрос о применении спиральной динамике к организациям. Карина в этом сомневается, так ка Дон Бек развивал модель как прохождение пути людьми, и это заняло тысячелетия. А мы засовываем прохождение в путь корпорации, и есть вопрос о том, насколько это обосновано. Я тут хочу прокомментировать. Во-первых, Дон Бек и Крис Кован в своей книге «Спиральная динамика», явно говорят о применении модели к организациям, и, более того, выделяют различные способы ответа организации на внешние вызовы в виде сдвига вверх, вниз или в пределах одного уровня. Во-вторых, представления, соответствующие разным уровням, уже сформировались в обществе. Правда, не совсем так, как полагал Дон Бек, детали я разбираю в статье Формирование , но это не очень важно. Важно, что большинство представлений знакомы всем людям: школа дает практические представления о конструкции синего уровня, обучая выполнять правила, и теоретические об оранжевом и зеленом. Ну а в ходе дальнейшего развития теории Марк Розин сформулировал культуры, соответствующие организациям разных уровней, и продолжает развивать концепцию. И независимо от Марка это же сделал Фредерик Лалу. который тоже опирался на спиральную динамику и интегральный подход в своей книге, он явно об этом пишет. При этом в большой организации есть разнообразие культур, у Марка есть хороший образ змеи, ползущей по спирали. Если кого интересуют подробности, то есть моя статья Культуры компаний в модели Спиральной динамики, мой конспект мой конспект книги Лалу и разбор книги Марка Восхождение по спирали. Я даю отзыв на свои материалы, так как они в открытом доступе. Хотя стоит читать книги-первосточники. Еще в ответах на вопросы был кейс. Карина была на НМЛК. Приходит на батарею коксохим, громадные двери, там работает дверевой, их открывает. Вот дверевой, через 10 лет выйдет на пенсию, если доживет. Он загребает кокс, 1300 градусов. Зарабатывает 100 тысяч. И Карина говорит: он на втором уровне, он не видит работу курьером как альтернативу. Я с такой оценкой не согласен категорически. Люди видят работу курьером. Но сознательно остаются на тяжелой работе, из-за сопричастности в достойному делу, как они его понимают — работе завода. которые делает полезное стране, а не доставляет продукты ленивым зажравшимся людям, не способным сходить в магазин. В классификацию Кинга это не укладывается, в ней такой mindset реально отсутствует. А по спиральной динамике это — нормальный синий уровень. Еще в вопросах обсуждали ситуацию, когда ты говоришь Василию «ты крутой», а кто-то еще, например. HR или вышестоящее руководство, его обесценивает. Ответ: у тебя должен быть авторитет, ты должен быть лидером, чтобы Василий слушал тебя, а не кого-то еще. Ее команда приходит к ней, она и мама и папа. Василий Савунов. Copy-Paste в менеджменте: Почему менеджмент — это не доказательная медицинаДоклад показывал, в общем, вполне известные вещи: доказательств эффективности методов и практик Agile-менеджмента нет, и для классического менеджмента — тоже. А в результате ты переносишь практику в другое окружение — и оно не работает. В доказательной медицине есть уровни доказательств, в которых внизу экспертное мнение, а дальше идут отчет о наблюдениях, исследование типа кейс-контроль, когортные исследования и клинические исследования с опытной и контрольной группой. Большинство практик обоснованы лишь экспертным мнением или наблюдением за конкретными кейсами, где метод сработал. Откуда знаем, что Spotify — эффективно? Потому что Spotify придумал модель, там работал Книберг написал статьи, они завирусились, реализовал ING, потом Сбер — пошло в народ. Story point придумал Майк Кон, чтобы отвязать от сроков, написал книгу — и пошло в народ. В скрам-гайде написано что стабильная команда — эффективно, он попробовал найти научные исследования — всего три, и они лишь показали корреляции, а не причинно-следственные связи. А ведь корреляция может быть обусловлена лишь тем, что пробовали сохранить хорошо работающую команду, или другими причинами. Если взять Scrum Book — то там 94 практики, и большинство обоснованы экспертным мнением. Правда, есть исключения, были ссылки на исследования эффективности парного программирования и еще практик XP? там прям был контролируемый эксперимент. Ну и заключение доклада: не принимайте на веру, не переносите механически, а экспериментируйте. В целом доклад понятен. Но я бы не апеллировал к доказательной медицине. Тем более, что с доказательствами в медицине сейчас много проблем. Вообще строительство команд и организаций — инженерная деятельность. Если бы инженеры ждали сопромата, то первые появились бы в конце 19 века. Так что использование эвристик, эффективность которых не доказана — вполне нормально. К этому надо так и подходить, не париться научным доказательствами. А эксперименты и пилоты — правильно. Кстати, букинг проводил реальный эксперимент — насколько команде нужен тимлид, в нем участвовало более сотни команд из нескольких сотен, результаты сравнивались. Результат эксперимента — выяснили, какие процессы проседают, а какие — работают. Что интересно, операционка — работает, проседает развитие сотрудников. И дальше они тимлидов вернули, но начали ихз фокусировать на том, что важно, и не работает без тимлида. Подробности Георгий Могелашвили на TeamleadConf-2018, и есть мой конспект. В комментариях к конспекту доклада на моем канале — интересная цитата Георгия Петровича Щедровицкого от Александра Бындю:
Так что, возможно, не страшно, что Agile не обмерил ученый. От этого техническое знание ничего не потеряло. Максим Фролов. Как снять организационное изменение с ручника. Руководство агенту измененийВ докладе — фокусы внимания при проведении изменений и инструменты для этого. Дисклеймер: это — личный опыт и инструменты, ваш контекст применения будет отличаться. Основное: помните о цели изменения, используйте воображение чтобы ее достичь. Без чего изменение не поедет? Цель изменения, спонсор изменений (кто-то на достаточно высоком уровне драйвит) и видение результата. Цель — зачем, видение результата — как оно будет выглядеть. Без видения легко можно начать, но потом оно остановится. Как понять, что что застряло? Читайте и смотрите документы, записи встреч, тикеты, файлы. Общайтесь с участниками: топ, мидл, стейкхолдеры. И сопоставляйте с документами. Измеряйте численно — ADKAR и другие системы метрик. ADKAR меряет принятие изменений по уровням Понимание — Желание — Знание — Способность — Закрепление. Какие бывают тормоза и как их снимать?
Согласование ресурсов. Ресурсы любят тишину: люди, деньги. Из ничего сделать ничего нельзя. Если чего-то не хватает — надо фасилитировать и принимать непростые решения. Чаще всего людям наплевать. Вы говорите «ходите на дейлики» — может быть наплевать, или ясно скажут: можно написать в чате. Операционка всегда давит. Как способ: топ должен сказать, что работа важна, один раз, но на всех. Переработка затронутых процессов. Если изменение что-то трогает — нельзя это игнорировать. Процессы связывают разных людей, и если вы их ломаете — она сопротивляется. При этом процессы — они между людей, к ней нельзя придти, вызвать на ковер. Пример. Есть система мотивации и оценка. Если вы оцениваете людей — вы не оцениваете команды. Поэтому команда не будет работать. В ответ сказали: ты не знаешь корневую причину. При этом каждый отдельно говорил «надо менять», а все вместе «тут все в порядке». Перебрендирование. Если был провал OKR — нельзя второй раз внедрять, это кино уже было. Делали орг.изменение — его обозначили как первый шаг в давно существовавшем проекте — отношение изменилось. Что-то достаточно поменять косметически. Важно: образ результата и явная работа над ошибками. Вообще предыдущие провалы можно признать успехом, просто частичным, и объявить, что идем дальше. Поиск конфликтов ответственности. Надо всегда описывать дельту ответственности. И если вы делаете хуже — это ваша проблема. Если у руководителей забирают подчиненных, то люди уйдут, и половина команды может уйти за ним. Показали, что проблема реальная, начали обсуждать. И нашли способы решения. Сопротивление мидлов решается на уровне топов. Но топы не хотят встревать в такие конфликты. Вести такие разговоры тяжело. Коридорная политика. Если вы закончили презентацию и видите, что люди шушукаются — они шушукаются о вас. Надо быть в курсе. Когда внедряли подход по целеполаганию — люди все равно думают, что будут пинки под зад при провале целей. И потому цели будут ставить мало. С этим страхом работали повсеместно, в коридорах, на публичных встречах, просили топов явно опровергать. Сообщества и авторитет. Создавайте их для поддержки изменений. И надо помогать объединиться. Кейс — были люди, которые в ходе изменений начали терять подчиненных, и они начали говорить «новая роль для идиотов». Они создали крутое закрытое сообщества для тех, кто перешел в новую роль, и от него был профит. Сообщество стало магнитом, в которые пошли люди. Но для этого нужны инфлюенсеры, которые начали втягивать. Еще инструменты
Есть скептики во всем. Может быть, был прошлый опыт. А может, им просто скучно. Таких надо вовлекать внутрь команды изменений. Что он может сделать. И даже когда будет отказ, он изменится. И когда директор не может нормально управлять и блокировать критику позовет в команду — он может сменить отношения. Но это — тяжело, человек уже стал врагом, а надо встречаться и вовлекать. Но вовлекать надо на своих условиях, в рамках — чтобы не получить саботаж внутри команды. Рабочие группы. Если есть спонсоры двое, и вы встречаетесь по одному — может быть провал. У спонсоров календарь забит. Но 30 минут еженедельно — многое меняют. Вовлеченность. Доклады не работают, нужен интерактив. Если делаете целеполагание — то посадите в миро, пусть сделают карточками цели. Да, люди будут сопротивляться, но ресурс сопротивления — ограничен. И если максимум вытаскиваете на старте, во время воркшопа — тем легче будет потом. Еще инструменты.
И не забывайте о себе:
Асхат Уразбаев. Аджайл умер! Да здравствует пост-аджайл!После того, как основные конструкции Agile-методов, сформировались в нулевых, произошли три крупных изменения, существенно влияющих на ИТ-разработку. Это современный стек, включая технические возможности continuous delivery, распределенная работа команд и AI. B доклад — попытка анализа, как же они повлияли на разработку, и можно ли результат назвать agile-методами, или это уже пост-аджайл. Сразу скажу: Асхат склоняется ко второму, а я не вижу для этого оснований. Но начался доклад не с анализа объективных изменений, а с обзора субъективных тезисов о смерти аджайл. Для начала — тезис, что cкрам ужасен, расстраивает, убивает продуктивность, убивает продуктивных инженеров. Этот тезис я знаю, я полгода назад в чате тимлида с этими инженерами спорил. И мое личное мнение в том, что скрам на своих равноправных встречах снимает с инженеров корону, которой они очень дорожат. А раз так — его надо дискредитировать, чтоб даже мыслит не возникало его применить. Его продолжает тезис, что аджайл — для лузеров. И статьи типа «пять вещей, которые не навижу про скрам». В общем, перекликается с предыдущим. Следующий тезис — о догмах. Алистер Коберн: «Кто-то сказал, что аджайл превратился в религию — нет она начиналась как культ, и стала мошенничеством». Асхат говорит, причина — догматичное отношение к Agile-методам на Западе, которое в России не очень заметно. Там есть вера, что правильный путь — один. Поэтому если любишь и внедряешь less — ты обязан ненавидеть SAFe, это часть job description. И это — не новое веяние, я помню, что в начале 2010-х время оказалось: сообщество AgileRussia не может нормально ассоциироваться с западными, потому что у нас Scrum и Kanban жили вместе. а там сообщества были раздельными и смешение не допускалось. И тут мы выходим на проблему mindset. Подход concept-based говорит, что есть единственный правильный способ. А context-based — что единственного правильного нет, все зависит от ситуации. И если у вас в проекте работает водопад, или какой-то полускрам, и результаты устраивают, то исправлять не надо, если нет проблем. C этим, кстати, и в России есть проблемы, желание непременно сделать одинаково и по инструкции очень распространено, и agile-коучей часто нанимают именно для этого. Например, команда не заканчивает спринты завершением задач, и тебя отправляют разобраться. потому что в гайде — написано. А ты смотришь и понимаешь, что болит P&L, что разработка вообще не приносит value. Но это — вне твоей зоны ответственности, ты — agile-коуч, вот и занимайся своими спринтами. Ты идешь, занимаешься — и по вечерам начинаешь выгорать. Или идешь в другую компанию. Я отмечу, что это — частный пример бюрократизации. свойственной любым большим организациям, их бюрократическое вырождение в 1960-х детально изучал Крозье. Сейчас появляются новые фреймворки: ShareUp, unFIX, Dual Traсk Agile, но они не противоречат agile-манифесту. А есть ли современный подход, который кардинально меняет отношение к работе, говорит, что надо выкинуть ценность или принцип из аджайл-манифеста? Тут сложно. Потому что, если взять, например, итерации и поставки, то скрам формировался в то время, когда в норме были многомесячные релизы, и идея демо и поставки каждый 2-недельный спринт была революционной. В манифесте сроков нет, но соответствующие принципы — есть. Современный стек приводит к тому, что поставка может происходить по каждому коммиту. И принципы надо переформулировать с учетом этого. Впрочем, для части разработки редкие релизы — по-прежнему данность. Сейчас фокус сместился с TTM на Productivity. Впрочем, это — жаргон. Поясняя тезис, Асхат сказал, что речь теперь важно не сделать быстро фичу по заданию, а реализовать идею от момента возникновения. И борьба идет с тем, что несмотря на непрерывную выкатку, срок от идеи до реализации по-прежнему долгий, 3-9 месяцев. И это — правда. Добавлю, что часто половина, а то и две трети этого срока аналитики согласуют с бизнесом, что все-таки надо сделать. Потому что бизнес занят. А еще потому что прорабатывать надо все задачи, а не выкидывать ненужное и брать нужное. С чего, собственно, и начинается планирование и в Скрам и в Канбан: вы берете в работу то, что реально нужно, а не все подряд. А если брать все подряд, то будет то, что наблюдается. Еще критика скрам касается встреч. Инженеры не отличают груминг от планирования, не понимают смысла ретро или демо. Для них все встречи заключаются в том, что собирают в кучу людей, которые не любят говорить и мало терпят друг другу, и заставляют говорить два часа. И мемы появились «надоело работать — собери встречу». Я тут хочу отметить, что такой подход — свидетельство о том, что те, кто организует встречи, не понимают их смысла, относятся как к формальному ритуалу. И не умеют работать без встреч, по переписке. Я помню, как таск-трекеры в конце нулевых сильно облегчили асинхронную работу, устранив необходимость встреч. Просто не все умели этим пользоваться. А еще я помню слова Джеффа Паттона, которыми он начинал тренинге product owner: «Многие думают, что collaboration, совместная работа — это про постоянные разговоры и обсуждения. Это неверно. Collaboration — это когда люди вместе делают одно дело. Желательно — молча.» По-прежнему менеджмент не умеет работать при отсутствие личной ответственности. Не хвалить никого, приписывать успехи команде они научились хорошо. А вот за провалы — прилетает. Хотя проблемы — в организации. Но это — вечная проблема. Которую сильно усугубил remote work, удаленные команды. Сейчас огромное количество компаний требуют возвращения людей в офис. Даже Sergey Brin сменил риторику: начинается гонка с ИИ, каждый должен работать в офисе 60 чесов. А ведь именно он говорил — 20 % времени можешь работать над своим. И 80 % разработчиков, естественно, возвращаться в офис не хотят. А в офисе все снова сидят в зуме — потому что встречи, которые половина людей оценивает как бесполезные. Я тут хочу сказать, что ситуация очень простая. За отсутствие удаленной работы надо платить. И, я думаю, 30-50 % к рыночной зарплате тут будет мало, надо двукратно, а часть специалистов не вернешь за любые деньги. Если компания может себе это позволить — пусть делает работу в офисе, ее выбор. А если говорить про тренд, то есть сдвиг в асинхронный формат работы. Меньше встреч — больше фокуса. Команда работает без обсуждений. И документация вместо устных обсуждений. Гибкость и удаленность графика: каждый работает в удобное время, без привязки к часовым поясам. Изменение принятия решений: на встречах самый громкий — прав, а кричат некомпетентные, и без документирования. Теперь асинхронно, через письменные предложения. Медленно есть время подумать. Консент: предложил, нет возражений — и ок. Об этом появились книги: Slow productivity и Asynk-first playbook. Надо будет посмотреть. Впрочем, как я отмечал, для меня это — повторение конца нулевых, когда появились таск-трекеры и обеспечили асинхронное общение, наблюдаемое всей командой, в отличие от icq. ИИ-помощник. Он подрывает работу организации. ИИ поднимает личную эффективность. И надо отойти от концепции, что есть ответственный за ИИ, которому ставят задачу. Надо каждого обучить — как Excel. А еще он помогает выстраивать потоки информации. Транскрибаторы встреч. Meeting Minutes не нужны примерно никому — потому что разным людям нужны разные срезы информации. Архитектору — решения ADR, Scrum — блокеры, Security — риски, PO — фичи, принятые в работу и так далее. И можно не ходить на встречи команд, на бесконечные синки, а получать информацию через такие резюме с нужным фокусом. ИИ может сделать живые регламенты. Пусть есть статья «практики планирования», и команда решила делать иначе — и статья должна сама обновиться, по транскрибу встречи. Можно, например, проверять acceptance criteria, или зависший code review, пропущенные ветки — об этом можно напомнить. Получается новый слой информации. Работает не на уровне информационной системы или данных, а на уровне контекста. И все это можно получать не в устном общении, а через ИИ. Если у вас транскрипты — возникает вопрос безопасности команды. Например, команда публично обсуждает PO соседней команды перед стендапом. ИИ должен это проверить, и рекомендовать не включать. Или увольнения. Итого
Будущее в том, что ИИ даст новый буст нашей профессии, context engineering. По эффективности ИИ. Персональную эффективность померяли на классах задач. И там она разная, от нулевой до огромной. А по коллективной — не меряли. и не очень понятно — как измерять. Вопрос. Что станет со скрам-мастером или продут-оунерами?
Вопрос. Скрам взлетел благодаря простоте. Будет ли что-то в асинк?
Вопрос. Чем будет отличаться ИИ от естественного, когда придет к пределам.
Завершая конспект. вернусь к началу. Асхат так и не показал нарушение ценностей и принципов Agile-манифеста. Новые тренды ему не противоречат и, более того, на мой взгляд, повторяют прежние. Илья Павличенко. Слухи о смерти Agile сильно преувеличеныИлья выпустил книгу «Дизайн Agile-организаций». Несколько лет назад у него была книга в соавторстве на английском, из-за СВО перевести на русский ее не успели, поэтому он выпустил новую. Она сильно тоньше английской. Потому что исключена теоретическая часть, оставлена практика. При этом практическая часть актуализирована и дополнена. Для начала — история, положенная на кривую Мура.
Я отмечу, что это — не совсем точно. Потому что это — взгляд из текущей ситуации. Как я вспоминал, в отчете AgileDays-2013 я писал про конференцию разочарованных. Почему? Потому что scrum и kanban в существовавшем тогда виде выбрали свое потенциал и область применения. А потом — пошел очередной импульс развития за счет новых фреймворков. Если использовать не кривую Мура, а S-кривую инноваций, и фиксировать там волны. которые дает очередной импульс — то это достаточно четко видно. И да, сейчас период паузы перед очередным импульсом. В общем, это подтверждается и дальнейшим докладом. Да, есть приметы разочарования. Тезис «скрам не работает» подтверждается динамикой рынка труда: снижается количество сертификаций скрам-мастеров, снижается количество вакансий. Сворачивают SAFe. Но! Это нормальный ход событий. Agile стал нормой. В 2014 у Ильи полтренинга было про сторипойнты, сейчас — всем известно. Про кроссфункциональные команды — никого не надо убеждать. Впрочем, тут я не соглашусь, по-прежнему в большом количестве компаний разработку организуют на функциональных отделах. В том числе, когда создают отделы инхауз-разработки там, где ее не было. Старые схемы — живучи, потому что функциональное деление привычно тем, кто привык к классическим схемам управления. И они берут не работоспособные. зато знакомые конструкции. ВпрочеМ, они не очень виноваты. Разобраться, как устроен Scrum поиском по публичным материалам — не реально, инте забит совсем другими материалами. И, что важно, тренинги начального уровня тоже не дают представления, потмоу что ориентированы на объяснение членам команд. начинающим пользоваться, а не менеджерам высокого уровня, конструирующим организацию. Есть такая проблема. Поэтому я, когда читаю лекции по современному менедджменту, регулярно конструкцию скрама рассказываю, и часто слышу обратную связь «так вот как оно устроено, теперь мне понятно». Если говорить про конкретные кейсы, которые Илья делал, то в Райффайзене выход продукта ускорили в 4 раза. В СБП ускорились в 10 раз, хотя в статье написали про 5, чтобы не дразнить читателей. Так что все работает. А еще есть маркетинговые трюки:
И спорить — бесполезно, трудно заставить человека что-то понять, если его зарплата зависит от того, чтобы он не понимал. Статьи на хабре — ни одной статьи, где бы автор не разбирался в концепциях того, что хает. Так что доверяйте сертифицированным тренерам и коучам, их много. Только для человека снаружи есть проблема — как отличить профессионала. Потому что ведь те, кто вокруг друг другу замечательно выписывают сертификаты. Есть известная продуктовая компания, которая говорит «у нас ничего не изменилось от скрама». Он посмотрел:
Понятно, что если так внедрять скрам, то ничего не меняется. Мода меняется. Вчера было одно, сейчас — другое. Ищут серебряную пулю. Называют по-разному. Принципы: системное мышление, теория сложности, бережливое мышление и так далее — они не меняются. И ему все равно, что будет после скрама, если принципы сохранятся. Эпоха коробочных решений, готовых фреймворков подходит к концу. Есть запрос на кастомизированые решения. Эпоха консультантов, которые показывают одну и ту же презентацию и всем это внедряют — прошла. 70-95 % трансформаций проваливаются. В том числе — потому, что пытаются взять решение как коробку, без учета контекста. Не только agile, все трансформации. Сейчас он не продает коробочное решение, он узнает стратегический фокус и подбирает решение. Крутые компании никогда не берут целиком, посмотрите описание кейсов. Они могут взять часть, и адаптировать под себя. Как найти свой фреймворк.
Есть новые фреймворки, ориентированные на кастомизацию. сборку нужного из практик: unFIX Юргена Апелло, HEXI — там есть паттерны. Итак, agile жив, он просто стал нормой. Критика — маркетинг или непонимание. Принципы сохраняются независимо от названий. И нужна кастомизация. Кстати, на тех тренингах, которые я проходил в свое время — у Книберга, у Джеффа Паттона — они именно так и говорили: сначала надо действовать по гайду, просто чтобы исключить возврат к старым привычкам. А потом, как поймете новую конструкцию — начинайте адаптировать. Scrum — не комадный фреймворк, это продуктовый фреймворк. И гайде написано: если команда становится большой, подумайте о реорганизации вокруг продукта. И, что интересно, у вас получится less, сразу. Про unFIX. Звездная модель оргдизайна — там стратегия, а оттуда дизайн, нарграды, политики и так далее. И они различаются, они для этого. А Юрген Апелло провел работу — он систематизировал много паттернов, и можно подобрать то, что нужно вашей команде или компании. Павел Алферов. Национальные мутации или 5 причин почему Agile не работает в ГерманииПавел когда-то работал в Международном Олимпийском Комитете, участвовал в организации Олимпиады в Сочи, и смотрел схемы управления олимпиад в России, Китае, Японии и так далее — системы управления различаются. Причина — в национальной культуре. Что такое культура? Культура — о том, как ведем, когда отвернулся начальник. Аузан говорит: Культура — это ценности и поведенческие установки, разделяемые сообществом и медленно меняющиеся со временем. Он смотрел на особенности русской культуры, когда пересобирал проектное управление для России. Чтобы получить репрезентативный срез, опросил 7000 человек, более 200 сессий. Результат — книга «Как правильно делать правильные вещи». А название доклада — из статьи с исследованиями, которая зацепила год назад: «5 причин, почему agile не работает в Германии». Статью написал португалец, который приехал в Германию внедрять agile-методы. По культуре есть модель Эрин Мейер The Culture Map. Эта модель — точно про деловых людей. Там 8 осей предпочтений, на слайде были профили России и США. Профили по разным странам можно получить у них на сайте за небольшую денежку. И дальше был разбор, хотя не по всем осям. Позиции я указываю примерно по слайду презентации, от −1 до 1.
соблюдается. Творческий подход. Еще две оси Павел не разбирал, но приведу для справки.
В последнем исследовании не просто использовали модель, а выписали культурные скрипты, которые способствуют или конфликтуют с agile-практиками, собрали поведение Agile-команд, посмотрели конфликты и собрали практики для предотвращения проблем.
Национальные особенности сильно влияют на практику работы, включаЯ, естественно, Agile-методы. В некоторых культурах конкретные практики встраивается естественно, в других — требуется изменять. Ключевые элементы: коммуникации, принятие решений, статус и лидерство. Работа с культурой — очень длительный процесс. Национальная культура сильно влияет на корпоративную, полная матрешка выглядит так: Национальная — Отраслевая — Организации — Команды. Но если говорить про Россию, то культура ИТ-отрасли ближе к западной по некоторым осям, чем страна в целом, что объясняется корнями в инженерном сообществе, и это объясняет относительный успех Agile. Netflix. Никаких правил. Они поняли, когда выходить из США — взяли модель Эрин Мейер. И сделали анализ своей культуры, наложили на страны, поняли где будут проблемы и решили, что будут делать. И в заключении раскрыта интрига доклада, причины про Германию.
По модели Эрин Мейер мы близки к Германии, но у них линейное время, а у нас — гибкое. В свое время он в архивах МОК нашел книгу «Как работать с русскими», сильно нового не прочел, но многое было забавно. Несколько лет назад надо было в Корею, и он попросил книгу. Ему говорят «нет такой». Спросил «как так, с русскими есть, с корейцами нет?», и получил ответ «а с чего вы взяли?» Понял, что ему она попалась случайно. Так вот, в этой книге была инструкция: всегда убеждайтесь в том, что вы понимаете, кто принимает решения с той стороны, и не обсуждайте решения без него. Когда ведет курсы по проектному управлению в разных странах — начинает с разборки с национальными особенностями. Если правильно поставить вопрос, люди откликаются. |
Блоги друзей |
