Как мы достигли идиллии, работая без менеджеров. Часть 2. Тайная комната

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

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



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

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

    Напомню, в нашей компании работает на данный момент 28 разработчиков. То, что применимо для 7 команд (по четыре разработчика в команде) может стать нецелесообразным при работе 15 команд и наоборот. В то же время, и разработка качественной архитектуры кодовой базы, и выстраивание качественных процессов подразумевает свободу масштабирования без больших затрат. Кроме этого, в большинстве компаний отдел разработки одного направления большого продукта состоит как раз из 5-7 команд (20-30 человек). Такой отдел, как правило, имеет свободу принятия независимых архитектурных решений, свободу организации внутренних взаимодействий и выстраивания процессов.

    Подробнее о семействе продуктов Renga (Осторожно, маркетинг!)
    Renga Architecture – система для архитектурно-строительного проектирования. Программа создана для максимальной помощи проектировщику в решении его задач: создание архитектурного облика здания и информационной модели, быстрая компоновка чертежей согласно стандартам СПДС и многое другое.

    Renga Structure — cистема для проектирования конструктивной части зданий/сооружений. Программа для инженеров-конструкторов и проектировщиков по созданию информационной модели здания или сооружения и получению чертежей марок КР/КЖ/КЖИ/КМ/АС.

    Семейство продуктов Renga предназначено для проектирования по технологии BIM. Высокая производительность систем позволяет работать с большими проектами без видимого снижения качества работы с 3D-моделью:

    Объектное проектирование
    Создание в Renga 3D-модели здания/сооружения инструментами объектного проектирования (стена, колонна, окно и т.д.)

    Коллективная работа
    Обмен, хранение и управление данными осуществляется с помощью BIM-Server Pilot.
    Взаимодействие со сметными системами.
    Интеграция Renga посредством API со сметными системами 1С-смета и ABC-смета для взаимодействия проектного и сметного отделов.

    Обмен данными
    Renga позволяет обмениваться данными с другими системами через различные форматы (.ifc, .dwg, .dxf, .obj, .dae, .stl, .3ds, .lwo и .csv).

    Автоматизация получения спецификаций и ведомостей
    В Renga реализована функция получения отчетов для формирования спецификаций, ведомостей и экспликаций.

    Автоматизация получения чертежей
    По данным 3D-модели автоматически получаются виды (фасады, разрезы и планы) и размещаются на чертежах в заданных масштабах.

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


    Пример проекта в Renga Structure

    Синхронизация команд


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

    Часто в компаниях синхронизация проводится в виде собрания тимлидов команд. У этого подхода есть минус, который я подробно обсуждал в предыдущей статье: один человек может забыть, не обратить внимание на множество деталей, которые важны для других. Таким образом, синхронизация тимлидов экономит время команд, но существенно уступает качеству коммуникаций. Подразумевается, что после такого собрания тимлид будет рассказывать каждый своей команде о прогрессе других команд, что опять же потратит время каждой команды. Здесь появляется минус «глухого телефона» при передаче знаний от тимлида команде. Таким образом, команда остается как бы «в стороне» от работы других команд, общаясь только посредством тимлида. Как результат, падает заинтересованность, увеличивается разрыв в понимании общего движения разработки всего отдела. Экономия времени команды никак не может покрывать минусы от отстраненности от общего направления разработки и общения между разработчиками.

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

    Другой важный аспект, который обсуждается на синхронизации — актуализация сроков разработки. Как правило, раз в две недели команды публично оценивают свои шансы на «успеть вовремя к релизу». В процессе обсуждения становится понятно, какая команда не успевает, а какая выполняет задачи в срок. Кроме этого, благодаря присутствию продуктовых аналитиков, можно изменить приоритеты разработки. Например, одна команда не успевает выпустить функциональность к релизу. Другая команда также не успевает, но аналитик понимает, что бизнес-значимость (business-value) работы первой команды выше, поэтому вторая команда откладывает функциональность, запланированную к релизу и помогает первой команде закончить работу в срок. При этом важно, что каждый член команды слышит рассуждения и аргументы, которые привели к такому решению. Я уверен, что в большинстве компаний, где такое решение было бы принято на синхронизации тимлидов, у команд возникло бы явное непонимание, почему чьи-то фичи важнее, а чьи-то — нет. Здесь же все вопросы можно задать и непонятных моментов остаться не должно.

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


    Пример проекта в Renga Architecture

    Демо


    Другой активностью, позволяющей оставаться в курсе изменений в продукте уже не на уровне кода, а на уровне пользователя — демо. Демо проводится на следующий день после завершения спринта. Демо организуется продуктовыми аналитиками для всех стейкхолдеров продукта — инвесторов, маркетингового отдела, руководителей компании и внутренних отделов разработки. Ведущие демо — аналитики команд, каждый из которых представляет разработанную, протестированную и слитую в основную ветку разработки функциональность продукта. Каждый сценарий демо проверяется накануне показа на соответствие требованиям (Definition of done). Важно понимать, на демо никогда не показываются незаконченные фичи или сценарии. Подразумевается, что любой сценарий, показанный на демо, может быть с хорошей вероятностью использован конечным пользователем продукта без каких-либо ошибок.

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

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

    Ретро релиза


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

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

    Тайная комната


    Тайная комната — это наш демо-зал, в котором проводятся все описанные активности. Здесь есть все, что необходимо — флип-чарты, столы по количеству команд, доски и проектор. В нашем отделе разработки много конструктивных отсылок к Гарри Поттеру. У нас есть Sirius, Ravenclaw и даже Order of Phoenix, но об этом в следующих статьях.


    В нашем отделе разработки много отсылок к Гарри Поттеру

    Вместо заключения


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

    По чистому времени выходит около 0.4 часа на стендапы, 5 часов на планирование, 2 часа на ретро, 2 часа на демо. 28*0.4*10 + 5*28 + 2*28 + 2*28= 364 человеко-часа за 12 дней на 28 человек или 1 час в день на одного человека. Я не учел активности вроде code-review, архитектурных обсуждений, потому что считаю их неотделимой частью процесса разработки.

    Поделитесь, сколько времени интегрально у Вас (или Ваших команд) уходит на активности помимо разработки? На мой взгляд, 1 час в день «на поговорить» — очень небольшая плата за распространение знаний, рефлексию команд и повышение прозрачности.

    Анатолий Осокин, ведущий инженер-программист, Renga Software.
    АСКОН
    Крупнейший российский разработчик инженерного ПО

    Комментарии 27

      0
      поскольку product owner у вас не является частью команды, это не scrum. вы можете и дальше называть все эти активности словом «скрам», если видите в этом какую-то пользу, но это какой-то другой процесс. насколько он адекватен? очевидно, что решение инженерной задачи не сводится только лишь к написанию кода. поэтому вопрос не в наличии «активностей», как таковых, а в их эффективности. попробуйте для начала оценить хотя бы это.
        +3
        Приветствую. Если хотите конструктивно обсудить, разъясните, пожалуйста, что Вы вкладываете в фразу «po является частью команды»?

        Что касается терминологии, может, у нас и не скрам, но мы эффективно доставляем пак фичей к сроку. В этом и есть посыл моих статей. Книжная методология — не панацея и не решение всех проблем. Каждая организация должна найти свои активности и свои процессы, которые позволяют максимально эффективно доставить продукт конечным пользователям в срок и с нужным качеством.
          +1
          если вы изучали scrum, наверно должны это помнить. как вы понимаете, что ваш процесс не просто достаточно эффективен, чтобы укладываться в сроки (которые по предыдущей статье выставляют сами разработчики, и вероятно с учетом всех этих «активностей»), а в самом деле эффективен максимально?
            +2
            С PO как частью команды вопрос тогда снимается.

            Позвольте мне провести аналогию с Вашим вопросом. Это очень похоже на такую критику: бизнес работает с маржинальностью в 40%. Участники бизнеса всем довольны. Приходит критик и говорит, ваша эффективность не максимальна! Так и не надо, если только Вы не хотите поупражняться в решении математической задачи оптимизации «эффективности процессов agile» :)

            В этом-то и суть. Баланс между затрачиваемыми на процесс усилиями и выхлопом в виде прозрачности, повышения качества архитектуры кода и т.д. Мы не пытаемся найти максимальную эффективность, мы решаем задачи, которые перед нами ставит бизнес. И решаем их с эффективностью, достаточной для успешного закрытия бизнес-планов.
            0
            del
            0
            Может я чего-то не понимаю, но Ваш комментарий вызывает у меня жуткий разрыв шаблона.
            В Scrum'е product owner как раз не может быть частью команды.
            Team, product owner и scrum master — это три разные роли, и если team и scrum master ещё можно совмещать (scrum master может быть в команде)…

            А, упс, вру, я перепутал: это product owner и scrum master не могут быть одним человеком; а product owner может быть в команде и scrum master теоретически может быть в команде.
            Но в любом случае, это отнюдь не обязательно — совмещать роли.
            0
            Интересно, или что-то недоговариваете, или уже в полном объеме описывайте чем вы там и как занимаетесь.

            Кроме этого, благодаря присутствию продуктовых аналитиков, можно изменить приоритеты разработки. Например, одна команда не успевает выпустить функциональность к релизу. Другая команда также не успевает, но аналитик понимает, что бизнес-значимость (business-value) работы первой команды выше, поэтому вторая команда откладывает функциональность, запланированную к релизу и помогает первой команде закончить работу в срок.


            не понимаю, если спринт 10 дней, в него входит одна фича/группа фич…

            4 человека говорят: мы сделаем определенный пул задач/фич к релизу…

            скорее всего были рассуждения и т.п. в кругу этих 4х человек (одна группа разработчиков), они определяли структуры фич, с чего да как фича должна рождаться и как в результате выглядеть…

            план построили, начали делать, пройдя пол-пути поняли: мы это и это не успеем…

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

            где у меня пробелы после прочтения? )
              +1
              Вы абсолютно правы!

              Были груминги в рамках команды с аналитиком. Записали требования к фиче, обсудили, разошлись. Требования выявляем заранее, спринта за 2-3 до фактической реализации. И вот через 2-3 спринта, понимаем, что не успеваем сделать эту фичу. На синхронизации выяснилось, что у другой команды возникает пул времени, так как большую фичу они сделать не успеют, а маленькие закончились.

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

              Так что не похоже, что остались какие-то пробелы :) С другой стороны, и цикл статей не окончен!
              0
              Мне кажется, или статьи пытаются высказать такую мысль: «Менеджеры — это плохо?». Мне лично кажется, выстраиванием командных взаимодействий без менеджера вы решаете какую-то проблему, например, проблему отсутствия в природе нужного количества адекватных менеджеров. Их долго и дорого искать, и на рынке труда очень много самозванцев.
                0
                Приветствую. Скорее, посыл статьи: «И без менеджеров возможно». В современном IT мире большинство книг и методологий настаивают на том, что обязательно должен быть в IT структуре *отдельный* человек с функциями менеджера. Я же пытаюсь показать, что возможно организовать эффективную работу без такого человека. Я могу быть не прав, готов спорить. Но пока что спор никак не завязывается :)
                  +1
                  Ну а о чем тут спорить… Берем толпу умных ребят, оставляем их в покое — они все равно сделают что-то хорошее. Например, будут писать идеальные программы. Но менеджер нужен для того, чтобы бить их по рукам, не позволяя писать идеальные программы, т.к. это долго, дорого и для бизнеса губительно.
                    0
                    Интересное у Вас восприятие. Продукт овнер поставляет бэклог, команда оценивает. И Вы считаете, что без менеджеров команда будет выходить за сроки? Или менеджер, по вашему, урежет качество взамен большей скорости? В Вашем мире разработчик хочет сидеть и писать идеальные программы, а не доставлять результат конечному пользователю?
                      +1
                      У меня специфическое восприятие, но оно коррелирует с реальной действительностью, где за программистами обязательно нужно следить, чтобы дров не наломали. Я не в плохом смысле, я в хорошем — у некоторых бывает такая производительность, что не успеешь отвернуться — вырастают архитектурные монстры с блэкджеком и прочими удовольствиями. За такими нужно приглядывать, чтобы энергия шла в нужное русло. И точно так же про качество — бывают люди, которые хотят добиться наивысшего качества — хорошей производительности, красоты кода, да мало ли чего. За ними тоже нужно присматривать, чтобы они не занимались этим тогда, когда другие вещи горят. Да есть еще куча психологических моментов — неуверенность в себе, или в выбранном подходе, или, как вы уже сказали, банальное непонимание разницы между программой и продуктом. В таком случае иногда нужно просто сказать: «ты справишься» или «не делай этого, это не приведет к хорошему результату». Программа может быть идеальной, но продукт должен доставлять. Поэтому кто-то все равно, так или иначе, принимает эту роль менеджера — человека, который «склеивает» команду, вырабатывает правильные паттерны взаимодействия, пресекает неэффективные/ненужные трудозатраты, поддерживает психологически. Иногда дает «пинка», причем на полном серьезе, некоторые люди мне прям так говорили, что им этого не хватает. В любом случае, человек — существо стадное, идет за лидером. Поэтому кто-то должен вести.
                    0
                    А к чему спорить?

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

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

                    Не заметил в тексте статей, выделена ли у Вас роль scrum master? Лично я воспринимаю эту роль как интегратора/администратора, который мониторит протекающие процессы, проводит изменение процессов, фасилитирует процессы планирования и ретро (с учетом зафиксированных наблюдений) и тем самым разгружает команду для повышения индивидуальной продуктивности.

                    Если у Вас все так красиво как написано, то можно только порадоваться за реализацию ценностей компании в виде работающих в данный момент процессов, обеспечивающих достаточный уровень качества для удовлетворения ожиданий всех заинтересованных лиц :)
                      0
                      Без менеджеров вполне возможно. Особенно, если команда подобралась ответственная и увлеченная своим делом. Есть только один нюанс — кто крайний? Все?
                        0
                        Интересный Вы вопрос поставили! Но что означает этот вопрос? Кто должен быть наказан в случае ошибки?
                    +1
                    Приветствую. Спасибо за статью. Интересный заголовок, сознание невольно продолжает его — с менеджерами могло быть хуже. Из своего скромного опыта могу сказать так. Когда рядом есть опытный менеджер, то возлагаешь на человека определенные надежды, на опыт, разум. И они могут не оправдаться, только и всего. Если такого координатора и опытного человека нет рядом, то нет и надежд, и возможного разочарования. Мне пока везло. И менеджеры помогают.

                    Есть замечание про книжный Scrum. Не так давно коллега посоветовал прочесть книгу «Scrum и XP: заметки с передовой» m.habrahabr.ru/post/47910. Возможно, Вы читали книгу. В ней подчеркивается, что менеджер не должен вмешиваться в работу команды во время спринта. Роль менеджера раскрывается во время планирования, при расстановке приоритетов. Также менеджер проявит себя если будет обнаружен серьёзный дефект, и одной из команд нужно будет поручить заняться им, в ущерб фичам. Ваши менеджеры, вероятно, так и работают, по книжному — как в этой книге. На других проектах менеджеры могут проявлять интерес к работе команд чаще, чем раз в две недели, и не замыкать на себя работу — наблюдать и помогать. Это же их право, зачем запрещать
                      +1
                      А вы не боитесь, что получиться как у Райкина?
                      … Ребята кто сшил этот костюм?
                      Выходят 100 человек, становятся в боксерскую стойку и говорят, МЫ!
                      Все хорошо, пока не нужно будет кому то отвечать за все…
                        –1
                        На синхронизации 7 команд стоят по стойке смирно и на вопрос: «Кто сделал?», — отвечают: «Я!», как в Гайдаевском фильме :) Не помню, чтобы кто-то замалчивал ответственность.
                        0
                        Вы не совсем точно поняли мысль.
                        1. Ситуация когда всем выгодно говорить я
                        2. Ситуация когда главному выгодно когда говорят я.
                        3. Ситуация когда никому не выгодно говорить я.
                        4. А если кому то нужно навредить, или просто сделать назло!
                        Вы все идеализируете, и всё равное есть тот кто отвечает за ВСЁ и он и есть менеджер!
                        У вас не отсутствие менеджеров, у Вас КАЖДЫЙ менеджер, то есть все!
                        :(
                          0

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


                          Но как правило менеджментом в команде разработки ПО обычно занимается опытный разработчик которому близка эта роль(тим.лид).

                            0
                            1000 человека-часов в месяц? Да ещё по цене разработчика. Да ещё в расчете только чистое время. Это около 10 менеджеров, которы работают фуллтайм на проекте, при этом, так как есть аналитики — менеджеры реально занимаются только управлением. Поэтому реально нужно 2-3 менеджера. Вот и считайте разницу.
                            Понятно, что менеджеры не заменят спринты, но выгода спорна, и спорно есть ли она вообще
                              0
                              Не очень понял Ваши расчеты. Откуда взялись 1000 человеко-часов работы в месяц? Если это неправильная арифметика из приведенных в статье расчетов, то готов поспорить. Конкретно, как менеджер уменьшит участие команд в активностях вроде стендапов, ретро, демо и синхронизациях? Или при участии менеджера необходимость в этих активностях пропадет?
                              0
                              Можно по подробнее про «Ретро релиза». Понял что это выполнение определенных заданий, но каких именно? И как выглядят результаты от заданий? Как они оцениваются?
                              Спасибо.
                                0
                                Спасибо за интерес. Постараюсь осветить в отдельной заметке.

                                Если коротко. Ретро релиза — это как ретро спринта, только для всех команд разом в огромном зале с "+" и "-", которые берутся решать не только члены команды-автора минусов, но и другие могут помочь. Кроме этого, "+" берут на заметку другие команды, т.о. обмениваемся опытом положительным и отрицательным. А еще благодарим коллег за помощь на протяжении релиза :)
                                  0
                                  Спасибо за ответ! Само понятние «ретро» пришло из методологии Scrum, я так понимаю?
                                0

                                Я бы статью назвал — "как мы вместо одного выделенного менеджера заставили весь отдел разработки и продуктологов заниматься организацией труда"

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

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