Привет, Хабр! Меня зовут Саша Лапина, я проджект-менеджер* в Lamoda Tech, в стриме по разработке внутреннего продукта — ML-модели оптимизации ценообразования. Поделюсь кейсом управления разработкой и расскажу, как мы налаживали процессы в нашей кросс-функциональной команде, которая за два года выросла в шесть раз.
С чего все начиналось
На тот момент, когда я пришла в стрим по разработке ML-модели оптимизации ценообразования, в команду входило шесть человек — три дата-сайентиста, их тимлид, Go-разработчик и продакт-менеджер.
Моей первостепенной целью стало выстроить процессы в команде, где задачи Dev и DS пересекались, а сроки, конечно же, были сжатыми. Казалось бы, какие могут быть сложности для опытного проджект-менеджера? Команда небольшая, задачи есть — вперед!
Здесь стоит уточнить, что это был мой первый опыт взаимодействия с дата-сайентистами. Одним из крайне интересных открытий стало то, что это не обычные разработчики, и вообще не разработчики :) «Натягивать» на них привычные процессы оказалось не так-то просто (и остается по сей день) в силу специфики их деятельности.
Расскажу, с какими еще сложностями на старте я столкнулась как проджект-менеджер, и как их решала.
Сложность:
Отсутствие точной оценки задач. Дата-сайентисты не могли дать конкретных оценок, так как большинство их задач подразумевают аналитику, рисерч, и являются непредсказуемыми.
Решение:
Согласование лимита на оценку и декомпозицию задач. С неточными оценками в какой-то степени пришлось смириться. Действительно, DS-специалистам сложно оценить время на анализ. Был вариант отталкиваться от времени, которое мы готовы потратить на задачу. Но он встретил сопротивление, потому мы пришли к компромиссу: мы декомпозируем всё, что можно декомпозировать, то есть делим крупные задачи на более мелкие, а максимальная оценка каждой задачи должна составлять не более 20 часов. Так прогнозирование сроков стало более управляемым.
Сложность:
Долгие обсуждения вопросов. Стендапы длились по 1 часу, Карл!
Решение:
Уточнение цели встреч. Выяснилось, что стендап для ребят — не только встреча по синхронизации статусов в команде, а еще и площадка для совместного поиска решения. Тогда мы разделили эти мероприятия на стендап и брейншторм. Брейнштормы начали проводить 2 раза в неделю и готовить к ним вопросы для обсуждения конкретных задач, над которыми работает команда. Впоследствии вопросов становилось все меньше, и спустя некоторое время потребность в брейнштормах отпала — ребята стали самостоятельно решать свои задачи, а не привлекать лида по каждой из них.
Сложность:
Трудно контролировать результаты работ без погружения в ML, так как это был мой первый опыт взаимодействия с DS-специалистами.
Решение:
Погружение в специфику ML. С этим пунктом оказалось сложнее всего. Но здесь помог тимлид, который мог «перевести» неизвестные вещи на понятный язык, и время на понимание, что происходит — без погружения в предметную область было просто невозможно качественно управлять проектом.
Сложность:
Единственный Go-разработчик в команде. У него рядом не было специалистов аналогичного стека, с которыми можно обсудить детали задачи, вместе оценить их и пройти код-ревью.
Решение:
Присоединение Go-разработчика к команде разработки другого стрима, чтобы он не чувствовал себя одиноко. В этой команде специалист «жил» по всем процессам и ритуалам, а к нашей DS-команде присоединялся на совместные синки 2 раза в неделю, так как наши задачи плотно пересекались.
Рост проекта и новые вызовы
Итак, шло время, мы вставали на рельсы, а проект рос. Первым этапом мы сделали MVP, и по итогам A/B-тестов приступили к полноценной разработке. В процессе развития продукта появились новые подпроекты. Так мы пришли в точку, когда команда из шести человек выросла до 40, и ее состав был таким:
1 команда дата-сайентистов,
2 команды разработки (с тимлидом в каждой),
1 проджект-менеджер и 2 продакт-менеджера,
привлеченные специалисты из других команд на разовые задачи (big data инженеры, дизайнеры, аналитики, инженеры DWH, Axapta).
В какой-то момент процессы, отлаженные на команде в составе до 10 человек, перестали работать. И помимо задачи выстроить их заново, нужно было организовать все так, чтобы не потерять общий контекст в большой команде.
Поделюсь тем, какие сложности нас ждали на этом пути, и как мы с ними справлялись.
1. Рост команды
Сложность:
Как я уже упоминала выше, мы выросли, и выросли мощно. В тот момент, когда команда дата-сайентистов состояла еще из шести человек, а в команду разработки шел активный найм, управление стало усложняться и выходить из-под контроля: вышло много новичков, которым требовался онбординг и внимание со стороны команды и лидов, дейлики стали затягиваться, точек соприкосновения стало меньше, а контекстов для одной команды больше. И мы приняли решение создать вторую команду. Здесь нас ждал интереснейший процесс с рисованием схем и сбором пазлов.
Решение:
Мы наняли второго тимлида и сформировали две команды. Укомплектовали их в соответствии со скиллами, интересами и контексту задач каждого участника. Это позволило кратно упростить облегчить пипл-менеджмент (первый тимлид выжил!) и сфокусировать каждую команду на конкретных проектах, тем самым ускорив разработку. При этом на переходный период мы запланировали временное продолжение участия некоторых ребят в проектах, в которых они обладали экспертизой, чтобы передать знания новичкам: помочь с погружением и ревью, погрузить в контекст.
Для двух команд разработки мы внедрили регулярные демо для обмена опытом, чтобы ребята оставались в контексте задач друг друга — хоть они и делают разные проекты, но в рамках одной системы, поэтому в случае ротации должны понимать, что происходит у соседей. Но при этом разделили доски команд в Jira и все ритуалы (дейли, ретро, груминги) для большей прозрачности и порядка.
Таким образом, наш стрим стал состоять из трех команд, и мы внедрили новые процессы:
общее демо, где каждая команда рассказывает о результатах проделанной работы — 2 раза в квартал,
контроль метрик команд: Cycle Time, Недооценка задач, что позволило ускорить разработку и показать команде, что они могут работать еще лучше — каждый месяц,
боты в чатах с напоминалками о регулярных процедурах вроде логирования времени или необходимости поревьюить зависшую задачу: автоматизировали всё, что смогли,
общую диаграмму Ганта для всего направления и детальную для каждой команды с загрузкой по исполнителю,
kick-off — встречу на всю команду в начале квартала, где мы сетапим цели и фокусы — 1 раз в квартал,
синки по смежным проектам для команд Dev + DS, на которых представитель от каждой команды рассказывает о статусах задач, и мы вместе обсуждаем проблемы — 1 раз в неделю,
регулярные синки с тимлидами — 1 раз в неделю.
А также позаботились о поддержании атмосферы в команде:
наладили коммуникации в общих чатах и по командам, не только на рабочие темы,
начали проводить неформальные онлайн/офлайн-мероприятия — посиделки в офисе, тимбилдинги — 1 раз в квартал,
настроили календарь команды стрима (в Яндексе/Гугле), где записаны все дни рождения и отпуски — это очень помогает быть в курсе,
создали страничку в Confluence с домашними питомцами команды — +100500 к хорошему настроению и разбавление рутины :)
Чтобы не повторять прошлые ошибки, наши три команды теперь всегда вместе и синхронизируются во всем, а новые члены команды с первых дней начинают знакомиться с ML-спецификой.
2. Непогруженность команды разработки в специфику Data Science и недостаточное взаимодействие между командами.
Сложность:
ML-модель, над которой мы работали, требовала создания административной панели, ей занималась команда разработки. Для успешной реализации разработчикам необходимо было глубоко изучить внутреннюю работу модели, ее принципы и логику. А дата-сайентисты, уже обладающие большим опытом в этой области, ожидали от коллег на старте такого же уровня погружения, как у них самих. Поэтому возникало непонимание, почему сроки затягиваются, и ощущение, что в аналогичных командах разработка больше погружена в задачи Data Science. Более того, непонимание стало приводить к увеличению времени разработки, переделкам, что еще больше накаляло обстановку. Начали «ехать» сроки проекта, и в очередной раз, когда время выполнения задачи увеличилось x2, мы решили, что пора принимать меры.
Решение:
Мы стали обмениваться опытом, чтобы максимально выровнять уровень экспертизы. Проводили встречи-погружения, на которых команды рассказывали о своей предметной области, как все устроено, что именно они делают и для чего. Еще нам помогли совместные ретроспективы, регулярные синки по статусам 1-2 раза в неделю, а также онлайн-тимбилдинги. Это все помогло сплотиться и понять, что мы одна команда, даже если стек у специалистов разный.
3. Шеринг экспертизы
Сложность:
Когда мы стали набирать в команду новых разработчиков, то столкнулись с проблемой шеринга экспертизы. Как выяснилось, не так просто делиться своими знаниями и забирать их без потерь в процессе передачи. К тому же времени на это как обычно не хватает — нужно «еще вчера». Кажется, что проще сделать задачу самому, чем кому-то ее объяснять. В какой-то момент нагрузка на разработчика была колоссальная: требовалось и техлидить, и ревьюить, и онбордить, и еще кодить кому-то надо, а все вокруг одни новички. Ситуация сложилась рискованная, это был боттлнек для всего стрима.
Решение:
Через боль, сопротивления и страдания мы настроили процесс передачи знаний команде, чтобы снять с него нагрузку:
распределили обязанности техлида и сислида между другими разработчиками. Да, среди них были и новички. Доверие — это важно!
стали проводить встречи-погружения,
наладили процесс дополнения отсутствующей документации, а где-то создали ее с нуля.
В итоге к моменту расширения проекта экспертиза была у всей команды, и все оказались в выигрыше. Разработчик, с которого все начиналось, и по сей день трудится над проектом, но теперь счастливый и в окружении еще 15 коллег: может и в отпуск сходить, и делать интересные задачи, и имеет за плечами надежную команду!
Роль проджект-менеджера
Во всем описанном можно потерять роль проджект-менеджера, и чтобы этого не произошло, пишу этот блок. Моя роль в проекте менялась с течением времени. На старте я была классическим проджектом, который проводит стендапы, 1-1 с разработчиками и знает каждую задачку. Сейчас я управляю межкомандными процессами, и к сожалению (а может быть, к счастью) не всегда есть время заглянуть на стендап и погрузиться в атмосферу стартапа, потому что требуется провести аудит процессов или сформировать матрицу ответственности между лидами. При этом я также отвечаю за сроки, но теперь моими контактными лицами по статусу и прогрессу становятся тимлиды команд. Обе разновидности роли проджекта одинаково важны, но они разные, и я рада, что в этом стриме мой путь сложился именно так. Мы продолжаем работать и по сей день, проект развивается, и чем дальше идем, тем более интересные вызовы возникают перед нами.
Заключение
Хочется зафиналить, возможно, простой истиной: команда и проект — это живой организм. Помимо изменения задач, целей проекта и продукта меняются люди, их экспертиза, жизненные обстоятельства и настроения. От изменения одного слагаемого меняется вся формула, и об этом нужно помнить. Команда проходит разные циклы, в каждом нужно варьировать подходы к управлению проектом — фундаментальный, основанный на хард-скилах проджекта, и индивидуальный, где требуются эмпатия и порой нужно быть психологом своей команде. Но это уже совсем другая история :)
*Пока я писала эту статью, моя роль в проекте расширилась — я стала еще и менеджером продукта в этом же стриме. И необходимости в подключении отдельного проджекта мы пока не видим. Это ли не знак, что действия дали плоды?
Чек-лист
Закреплю все описанное выше небольшим чек-листом, который вы можете использовать как ежедневное напоминание в работе с кросс-функциональными командами:
Поддерживайте постоянную синхронизацию: между командами, внутри команды, между лидами.
Шерьте экспертизу. Не должно быть так, что критически важной экспертизой владеет единственный специалист, это боттлнек.
Поймите и примите, что всё меняется: то, что работает сегодня, завтра может не взлететь.
Применяйте индивидуальный подход к ролям и людям: учитывайте интересы, особенности и таланты, формируйте команды, в которых специалисты будут и эффективно работать, и чувствовать себя на своем месте.
Погружайтесь и в продукт, и в техническую часть. Ваша ценность как менеджера только вырастет.
А с какими сложностями вы столкнулись при работе с кросс-функциональными командами и как справлялись? Поделитесь в комментариях.