Как тимлиду выжить в масштабируемом скраме и сохранить контроль за качеством кода

    Технический директор ivi Евгений Россинский (eross) хорошо знаком участникам наших конференций по докладам о технической стороне стриминга. Но сегодня пред вами расшифровка доклада Евгения на TeamLead Conf о том, как отражается Agile-трансформация на лидерах команд.



    Не так давно в ivi прошли Agile-трансформацию и получили от неё хороший профит в плане:

    • бизнеса,
    • скорости разработки,
    • time to market;
    • других интересных метрик.

    Но последствия этого креативного решения довольно серьёзно ударили по лидерам команд. Доклад как раз о том, как с этим справляться, и какие применять инструменты.


    До трансформации


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

    Разработка в ivi идет под пять крупных платформ:

    • iOS,
    • Android,
    • Web,
    • Smart TV,
    • Windows + Xbox.

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



    Ребята, которые знают, к примеру, Swift или Objective C:

    • сидят в одном помещении;
    • получают задачи от менеджеров продукта;
    • работают над ними и производят результат.

    Вроде бы все хорошо, но есть одна проблема — платформы очень серьёзно отличаются с точки зрения продукта и потребления пользователем контента.

    Это значит, что в каждой команде стал появляться свой backlog и свои приоритеты. Например, пользователи web-приложения не очень любят платить, и потребление контента осуществляется посредством рекламной модели. Фичи, которые нужны для этой платформы, естественно появляются в backlog. Smart TV характеризуются тем, что на них хорошо покупают, и проявляются особенности платной модели.

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

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



    Гениальный продуктовик приносит идею, а разработчики на разных платформах воспринимают её довольно недружественно, за исключением бекенда, которому в целом не принципиально, что писать.

    Итак, поскольку в компании было достаточно компетенций относительно того, что такое гибкие методологии, мы договорились с бизнесом, что нам нужно убрать барьер между:

    • продуктом,
    • бизнесом,
    • технологиями,

    продуктивно взаимодействовать, и делать одно общее дело.

    После трансформации


    Это вылилось в архитектуру с выделенными Value Stream, в которой каждая команда занимается конкретным бизнес-направлением.



    Чтобы сформировать новую структуру мы:

    • провели несколько тренингов;
    • определили, какие для нашего бизнеса главные направления;
    • в добровольно-принудительном разбили людей на value stream;
    • приступили к внедрению.

    Правда перед этим мы сделали одну такую команду, на примере которой провели показательные выступления, запилив одну фичу на всех платформах с отличным time-to-market.

    К тому же фича была выбрана очень удачно и оказалась успешной на всех платформах. Таким образом у нас был пример, который показывал, что всё можно делать быстрее и лучше. Это позволило все команде разработки из 130–140 человек понять, что можно работать по-другому.

    Когда мы определили value stream, встал вопрос, что делать с тимлидами. Раньше они были основой всему в своём направлении, а теперь появись value stream и большее влияние бизнеса. Что мы сделали? Мы в каждый value stream собрали людей разных компетенций, как минимум по одному:

    • iOS-разработчику,
    • Android-разработчику,
    • JavaScript-разработчику,
    • специалисту по Smart TV,
    • верстальщику,
    • тестировщику.

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

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

    Концепции


    Мы приняли несколько базовых концепций:



    У нас появились команды value stream и команды платформ. В value stream ребята реализуют конкретную фичу, а в платформах находится тимлид — центр компетенций. Внутри платформ тоже могут разрабатывать какие-то фичи, но это больше архитектурный взгляд на разработку программного обеспечения.

    Мы ввели понятие «Гильдии». Разместив тех же самых iOS-разработчиков по разным комнатам, нам нужно было дать им формальный признак и даже неформальный, что они остались теми самыми iOS-разработчиками, а не только участниками value stream рекламного продукта, например. А дальше с этой гильдией нужно что-то делать и как-то учить людей общаться внутри.

    Следующий вопрос состоял в том, что делать с релизными циклами. На тех платформах, где можно выкатываться по мере того, как фича готова, вопросов никаких нет. А в случае с iOS или Android, когда в силу специфики получения approve от Apple, невозможно два раза в день отправлять приложение на релиз, приходится накапливать некоторые пачки.

    Мы приняли решение, что каждую платформу, которую нельзя релизить сразу же, будем релизить раз в две недели. Завели специальный доступный всем календарик, где команда публикует дату feature freeze и дату релиза. Если, находясь в value stream, ты хочешь, чтоб твоя задачка стала доступна реальному пользователю, ты должен успеть до feature freeze. Успел — хорошо, не успел — ждёшь следующего поезда.

    Тимлид в новой схеме


    Что же стало у нас с тимлидами? Они прошли по классической схеме осознания проблем, которые невозможно решить.



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

    Конечно, после отрицания был гнев.

    Было много скандалов, после которых начался торг. Каждый приходил с вопросом: «Давайте у всех будет по-вашему, а у меня — как раньше, но я возьму маркер, напишу у себя „Agile“, буду ходить в футболке с этой надписью, но всё будет по-старому». Не получилось.

    Но в итоге случилось то, чего я очень ждал, — люди поняли, для чего мы это делаем. Я надеюсь, что поняли, хотя может, они и соврали. Тот самый первый успешный кейс показал действительное разительное отличие того, что было раньше, от того, как можно делать по-другому. Вдвое уменьшенный time-to-market позволил определить ориентир для всех. Произошёл следующий шаг, который в классической модели психологии называется «стокгольмский синдром». Люди, принявшие новые правила, научились в них существовать и начали потихоньку пропагандировать эту «религию». Не могу сказать за всех тимлидов, но примерно 30% из них сейчас являются активными «проповедниками» этого направления.

    Проблемы и трудности


    Теперь постараюсь более структурно перечислить сложности, с которыми мы столкнулись:



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

    У нас тут же начались проблемы с Code Review, которые я считаю не проблемами, а большим открытием. Мы выяснили, что большое количество сотрудников не являются самостоятельными. Допустим, был сотрудник, у которого по статистике review задачек проходил максимум со второго раза, обычно с первого раза всё было хорошо. А когда он ушёл работать в value stream, почему-то стало 5-6 итераций.

    Начали разбираться, и выяснилось, что авторитетное мнение знаковой фигуры тимлида, который контролирует, централизует относительно себя все потоки информации, не очень хорошо влияет на развитие разработчиков. Люди ленятся, по всем вопросам обращаются за помощью и получают компетентные ответы. И поэтому review проходит быстро и классно. Оказавшись наедине с собой, многим разработчикам пришлось довольно существенно вырасти над собой, чтобы принимать те же самые архитектурные решения. Никому не нравится пять раз подряд слышать, что твой код не очень хорош. Это расстраивает, заставляет считать себя недостаточно квалифицированным сотрудником, может даже приводить к депрессии или убеждению, что, может быть, работа плохая. Но смысл в том, что нужно посмотреть на себя, понять, что в прежнем режиме работы ты не думал об этих вещах, а теперь развиваешься и должен начать о них думать.

    С другой стороны, у нас были некоторые очень интересные вещи, которые, на мой взгляд, избыточны относительно Code Review. В одной из команд существовало правило: для того, чтобы задачка прошла review, все члены команды должны принять её решение. Когда они сидели все вместе, у них это более-менее получалось, а теперь все расселись — у одних daily stand-up meeting в одно время, у других какие-то другие дела — и review задач стало узким бутылочным горлышком. Они раз за разом на ретроспективе узнавали, что некоторые задачи висят в review по две недели, и были вынуждены что-то менять.

    Дальше начались: сепаратизм, дискриминация и зависть.

    Ранее человек думал, что знает, чем он хочет заниматься. А с разделением на value stream и платформы стало возникать подозрение, что «у соседа вкуснее»: задачки интересней и рост быстрее. Вторая проблема заключается в том, что, когда все становятся фича-центрированные, очень сильно ухудшается качество кода. Вокруг тебя сидят люди, которые хотят быстро получить результат, и не их задача подумать о том, что его нужно будет каким-то образом поддерживать, модернизировать, да и у коллег ничего не должно сломаться от новой фичи.

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

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

    Сила гибких методологий в том, что всем неважно, как всё происходит, главное, чтобы люди договорились и были довольны.

    Это с одной стороны. С другой стороны, чтобы была справедливость относительно того, кто занимается рефакторингом, а кто делает новые фичи, тимлиды начали работать с backlog’ами, я вернусь к этому чуть позже.

    А дальше начались сложности с Release Management. В value stream свои тестировщики, в платформах свои тестировщики, что-то автоматизировано, что-то не автоматизировано, нужно продумать, как сделать общую регрессию. А ещё есть сроки. Мы волюнтаристски решили релизиться раз в две недели, и что же, если придет партнёр с просьбой сделать все к завтрашнему дню (и мешочком денег, например), велеть ему подождать следующего цикла? Все-таки нужно искать компромисс. И тогда красивая схема с релизами может сильно измениться.

    Наглядный пример — закон ФЗ-54, по которому все покупки в интернете должны сопровождаться отправкой электронных чеков пользователям и в налоговую. Можно сколько угодно выступать на конференциях и говорить про гибкие методологии и про то, что есть регламенты и прочее, но как только возникает риск получения штрафа на 70% твоей выручки, ты переходишь в совершенно иной режим и делаешь так, чтобы твою компанию не оштрафовали. Такие случаи нечастые, но бывают. В частности, нам пришлось сделать второй уровень коммуникации на случай изменений в схеме. Это непросто, но возможно.

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

    Инструменты


    Вот, какие инструменты мы используем.



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

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

    Безусловно первое время новый сотрудник прокачивает компетенции, то есть, в наших терминах, находится в команде платформы, а потом уже может мигрировать в необходимый нам value stream. Кстати, маршрутные карты — хорошо, но их адаптивность тоже не нужно исключать.

    Дальше мы ввели Guild Sync — синхронизацию действий гильдии.

    Зачем это нужно? Все слушали лекции по Scrum, в которых говорилось о необходимости daily stand-up meeting, позволяющем узнавать, что происходит вокруг. Но наш специалист, например, с одной стороны разработчик под Android, а с другой стороны — участник продуктовой команды. Если он будет должен два раза в день ходить и общаться — получится какой-то Карго-культ. Такими темпами можно потратить всю жизнь на совещания. Однозначно, людей это будет раздражать.

    Если мы говорим, что мы основываемся на фича-центрической модели, то daily stand-up meeting более важен в своём value stream. Но при этом можно оторваться от того, что происходит в гильдии. Для этого какие-то гильдии устраивают совещания раз в неделю, какие-то — два раза в неделю. И тут тимлид методично продумывает, о чём стоит поговорить. Это не должно переводиться в пустой разговор, это — стратегия развития технологической команды, которой является гильдия. Встречи Guild Sync нужны, чтобы все понимали, какие технологии будет использовать компания, какие стратегические решения приняты относительно этой платформы. На нём же происходит частичное review архитектурных решений.

    В некоторых командах у нас не один тимлид. Вообще, определение тимлида очень неоднозначно. Есть лидеры мнений, которые могут быть тимлидами и нести на себе решение каких-то организационных вопросов. Лидеров мнений со скиллами менеджмента в команде может быть несколько. И дальше они могут сами организоваться, кто за что отвечает. Например, один из лидеров мнений может уйти в value stream. В таком случае нужно синхронизировать свои архитектурные решения, которые в дальнейшем будут определять стратегию развития всей технологической платформы.

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

    Сейчас на рынке труда в вопросах разработчиков всё не очень просто. А переучить хорошего, толкового парня с одного языка программирования на другой иногда бывает намного дешевле, чем взять подобного специалиста с рынка. Поэтому, если человек заскучал, мы приветствуем практику по переводу его в другое направление, которое ему интересно. И внутренние митапы очень помогают, чтобы понять, а что из себя представляет это направление.

    Расскажу об еще одном интересном моменте. Я собрал небольшую статистику, на основе которой выяснилась, что при Agile-трансформации курящие люди оказались более осведомлены, а курящим и пьющим практически не нужны Guild Sync и другие совещания.

    Люди, работающие вместе, не часто обсуждают общебытовые темы, так или иначе всё сводится к работе. У команд, в которых многие курят, Guild Sync нужен реже, потому что они и так всё обсуждают на перекурах.



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

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

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

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

    Самое интересное, наши тимлиды научились продуктивно общаться с product owner’ами в value stream. Они стали методично им объяснять, что если те сделали 10 фич, и в определённом куске кода нужно будет что-то поменять, то это займет полгода, потому что изначально следовало бы учесть ряд особенностей. Положительным фактором является то, что product owner’ы восприняли подобные обращения нормально. И в backlog’ах стали появляться задачи на рефакторинг и исправление своих собственных костылей. И тимлиды довольно серьёзно выдохнули, так как они поняли, что их команды остались их командами. Они убедились, что точно так же управляют этим процессом (не в плане менеджмента, а, скорее, в плане донесения до всех, как нужно сделать правильно).

    В моём понимании задача тимлида — это, прежде всего определение стратегии развития твоего программного продукта.

    Teamlead — клей


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

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

    Я, например, для себя уяснил, что после трансформации многие тимлиды избавились от большого количества «внутреннего бега». Если раньше по всем, даже незначительным и не связанным с менеджментов или кодом, вопросам виноват был тимлид, то теперь при подобной схеме масштабирования по целому ряду вопросов к нему просто не приходят. Тимлиду теперь не нужно отвечать на глупые вопросы, потому что их задают тому, кто разрабатывал эту фичу, к тому, кто отвечает за нужный value stream. У тимлида стало меньше входящих, отвлекающих факторов, и это здорово. Тимлиды стали спокойнее, у них перестали дёргаться глаза, и в целом их уверенность в себе стала выше.

    Следующий слет по обмену тимлидскими премудростями назначен на 24 и 25 сентября. Встретимся в Санкт-Петербурге на Saint TeamLead Conf для обсуждения всевозможных проблем управления командой.

    Программа уже начинает формироваться, в списке поданных докладов больше 40 заявок, и пока есть возможность добавить туда свою тему — Программный комитет принимает заявки до 10 августа.
    Конференции Олега Бунина (Онтико) 679,74
    Конференции Олега Бунина
    Поделиться публикацией
    Комментарии 33
      +2

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


      То, что прокатывает в реале, в тексте выглядит неопрятно и постыдно.

        +1

        Согласен, но если начать интерпретировать и выравнивать кривые фразы, всегда есть шанс подменить смысл. В любом случае учту на будущее.

          0
          Я проблем не заметил. Люди говорят тимлид и прóдукт в реальной жизни.А вы предлагаете писать «лидер команды» и «товар», чтоб формально было грамотно, но никто ничего не понял?

          из-за таких намерений появляются книги «Исскуство автономного тестирования» (вместо искусство unit тестирования).
          +3

          не до конца понял отчего в заголовке есть слово скрам, один раз упоминаеться в контексте дневного митинга

            0

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

              0
              «возможность к масштабированию», прошу прощения за опечатку.
                +1

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

                  –1
                  Масштабировать Scrum можно по разному, мы рассказал о нашей имплантации, думаю, если вы посмотрите выступление станет понятнее
                    +1

                    Из текстовой транскрипции не понятно было, что у вас scrum команды, это и породило мое недопонимание, спасибо за ответ.


                    Родился еще один вопрос, а какие задачи выполняет у вас тимлид в рамках scrum процессов? Есть scrum роли, и там нет тимлида, интересно узнать как вам удалось состыковать эти две вещи.

                      –1
                      teamlead роль не scrum, конечно не прописанная, но его жизнь радикально изменилась, как только участников его команды растащили по разным value stream. В задачу teamlead'a входит контролировать целостность кода следить за вопросами архитектуры и делать так, что бы код не превратился в спагетти. Создав кроссфункциональные команды, которые стимулируют быстрый запуск фич в прод, мы можем привести состояние кодовой, например Android, в неподдерживаемое состояние. Teamlead препятствует анархии.
                        +1

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

                          0
                          Например, есть teamlead Android, это самый опытный разработчик или несколько разработчиков, в их задачу входит стратегия развития кода. У Teamled есть команда (мы ее называем «платформа»), которая так же работает по scrum. При этом есть команды value stream, в которых тоже есть Adnroid разработчики. Teamlead участвует в планировании платформы, но не участвует в планирование Android разработчиков, входящих в value stream'ов. Teamlead не называет сроки ни в команде платформы и уж тем более в команде value stream'ов. Сроки каждая команда определяет сама и сама старается их соблюсти.
                            0

                            Пока только понял что тим-лид просто сидит на планировании. А какие еще есть обязоности у тимлида ?

                              0
                              Тимлид, как и другой член команды, кодит, делает ревью, участвует в планировании, но помимо этого больше других участвует в решении архитектурных вопросах координирует сложные мержи, помогает вливать фичи(при возникновении проблем ), запиленные в стримах в develop.
                                0

                                а ответственность на тимлиде или на команде ?

                                  0
                                  в конечном счете, отвечает все, это же командная работа.
                                    0

                                    а наймом кто занимаеться?

            +1
            Teamlead в Scrum? Хм.
              +4
              Руководству поди просто казалось, что бездельники-программисты постоянно трындят между собой о футболе, непрерывно тусят в курилке, а на все вопросы отвечают, что чрезвычайно заняты, и в ближайшие месяцы никаких новых фич запилить не получится. Поэтому сверху было спущено высочайшее повеление рассадить болтунов по разным комнатам, а менеджерам — придумать что-нибудь в оправдание, желательно умными словами, типа «гильдия», «аджайл», «скрам», и «value stream».

              Буду рад, если всё было не так)
                +1

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

                +4
                Ещё раз, может я всё не так понял. Единственной предпосылкой для этих изменений было то, что менеджеры разных платформ выставляли одним и тем же фичам разный приоритет, в результате чего фичи релизились независимо друг от друга и как попало. Так? Или может я что-то упустил?

                И вместо того, чтобы координировать между собой менеджеров и одновременно релизить фичи, был придуман весь этот ад с разделением людей. Я правильно понимаю?

                Если да, то вы очень точно назвали произошедшее с лидами «стокгольмском синдромом».

                Определение из википедии
                Стокго́льмский синдро́м — термин, популярный в психологии, описывающий защитно-бессознательную травматическую связь, взаимную или одностороннюю симпатию, возникающую между жертвой и агрессором в процессе захвата, похищения и (или) применения угрозы или насилия. Под воздействием сильного переживания заложники начинают сочувствовать своим захватчикам, оправдывать их действия и в конечном счёте отождествлять себя с ними, перенимая их идеи и считая свою жертву необходимой для достижения «общей» цели.
                  0
                  И вместо того, чтобы координировать между собой менеджеров и одновременно релизить фичи, был придуман весь этот ад с разделением людей

                  Тогда бы не о чем было рассказывать на конференции, а так есть гильдии. У меня складывается впечатление, что есть какой-то глобальный челендж

                    0

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

                      0
                      В вашем большом параграфе текста, если вылить воды, останется «менеджерам, отвечающим за разные фичи, очень сложно договориться между собой». Так вам не кажется, что в этом и есть проблема? В том, что каждый менеджер независимо от других придумывает сроки реализации поставленных ему задач?
                        0
                        Конечно в этом проблема, но синхронизировать работу большого количества людей непросто, речь тут не про сроки, речь про количество вариантов, которые надо оценить и про то, что в условиях постоянно меняющихся требований, нужно постоянно находить новые решения и переговариваться. В условиях большой команды нужны какие-то правила игры. Мы выбрали те правила, о которых я рассказал.
                    –3
                    «Технический директор ivi Евгений Россинский (eross) хорошо знаком участникам наших конференций» — ???.. (в смысле — ORLY?)
                    Ну и далее в том же духе
                      +1

                      Не совсем понял суть вопроса. Если говорить про конференции Бунина, то Евгений несколько раз выступал и является членом одного из программных комитетов. Так что вполне себе знаком участникам.

                      0
                      Получилась каша (заоверинжиниренные регламенты и иерархия зон ответственностей) из топора (одноуровневого скрамного цикла). Скрамной и аджайловой истории, кажется, в этом не очень много, кроме тех моментов, которые вы героически преодолеваете.

                      Стартапу — скрам, а бизнесу — квалифицированный менеджер, и, увы, отсутствие такого менеджера не компенсировать ритуалами скрама (делегированием менеджмента на исполнителей). Важно не перепутать и помнить, когда стартап превращается в бизнес (а денежно-тщеславная мотивация совладельцев стартапа в полугодовые премии и мед-страховку наёмного директора выращенного бизнеса).
                        +3
                        Какой кошмар. Бедные разработчики…
                          0
                          Интересно, но по-моему очень сложно получилось.
                          Наверное, в команде разработчиков из 130-140 человек, по-другому быть не может.
                          Но, всё равно спасибо — есть идеи, которые стоит почерпнуть и попробовать в своей среде.
                            +2
                            Наверное, в команде разработчиков из 130-140 человек, по-другому быть не может.
                            В команде из любого количества человек может быть что угодно. Очень разные люди и проекты бывают.
                            0
                            Странный подход менеджмента, работают по принципу индуса в саппорте на первой линии: решение проблемы осуществляется поиском в Knowledge Base нужной статьи, без понимания деталей. Для решения узкой проблемы, в разных продуктах у одной и той же фичи разный приоритет, вы берете и перестраиваете работу полностью. Вместо того, чтобы свести васю из продукта с мишей из сервера и сказать: парни надо сделать такую фичу, договоритесь о тех деталях и все.

                            Почему бы не сделать приоритет новой фичи одинаковым и координировать реализацию фичи сразу в трех продуктах?
                            Почему не выделить людей ответственных за Product Area во всех трех типах продуктов?
                              0
                              не очень понятно как решается проблема зависти,
                              перекинуть разработчика с проекта на проект нетривиальная задача:
                              это минимум с двумя бизнес-заказчиками договариваться придётся

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

                              Самое читаемое