[Управление разработкой, Agile, Управление персоналом] Самодиагностика команды разработки

Ответить на тему

Автор

Сообщение

news_bot ^®

Стаж: 6 лет 9 месяцев
Сообщений: 27286

news_bot ^® написал(а)
20-Май-2021 10:31

Цитировать

Как любая скрам-команда каждый день, мы стараемся быть лучше чем вчера. Мы делаем лучше наш продукт, мы вместе развиваемся как команда и, конечно же, мы растём личностно и профессионально. Очевидно, что одной лишь веры в то, что завтра мы станем быстрее/выше/сильнее не достаточно. Нужно понимание своих слабых и сильных сторон, а так же осознание того, что нам нужно здесь и сейчас, а что нам понадобится через неделю/месяц/год.С точки зрения каждого члена команды, мы полагаем, что "каждый сам себе CEO", тем самым, это зона ответственности каждого индивида. С точки зрения продукта - у нас есть менеджмент, который собирает метрики, делится своим видением будущего и планирует дорожные карты. Но с точки зрения команды - у нас есть мы сами, продукт и нам со всем этим нужно что-то делать.Я хочу поделиться с вами некоторыми инструментами, которые мы используем командой для обнаружения проблем на ранних стадиях, улучшения продукта и сохранения миролюбивой и уютной обстановки внутри.ОпросыДа, это очередные опросы, но в нашем случае они приносят пользу и каждую ретроспективу поднимаем вопрос, нужны ли нам они или уже нет. У нас спринты длятся 2 недели, поэтому у нас есть еженедельный опрос и опрос в конце спринта.Еженедельный опросВ конце каждой недели мы получаем опросник на 30 секунд с вопросами: как часто у вас не было сил выполнять работу? Получал ли удовольствие от задачи? Сколько часов переработал? На выходе мы строим график для всей команды в динамике за последние 6 недель и обсуждаем на ретроспективе. На таких графиках сразу становится понятно состояние команды, на сколько команда устала, как текущие задачи или краткосрочные приоритеты влияют на команду. Каждый член команды может сопоставить свои ответы с результатами команды. Например, если мне было тяжело, а по графикам я вижу что команда была в хорошем состоянии, то в следующий спринт я попробую забрать более интересные задачи себе, или брать поменьше задач. Или видно, что вся команда падает духом, тогда с владельцем продукта (PO) обсуждаем приоритеты следующего спринта и т.п. Как минимум, появляются аргументы для обсуждения.Опрос в конце спринтаТут всё просто, мы за пару часов до ретроспективы всей командой отвечаем на простой вопрос "Как вам спринт"? Тут мы уже преследуем цель разговорить команду. До введения этого опроса, ретроспектива начиналась с молчания и попыток скрам-мастера разговорить людей, что, как правило, заканчивалось "да обычный спринт, ничего такого". Сейчас же команда стала более разговорчивой, больше обсуждают проблем и кидают больше идей.

Опросы раздражаютТем не менее, хоть мы и используем опросы, они раздражают, т.к. есть ещё опросы от компании, но более эффективных инструментов, работающих для команды вне офиса, мы пока не придумали. Может быть, кто-то в комментариях подскажет более эффективный способ, подходящей для удалённой работы. Однако, люди также отвечают на эти вопросы сами себе и тоже делают выводы.МотивацияНаша команда разрабатывает B2B продукт, известный только в узких кругах компаний, и новые члены команды столкнулись с тем, что им никто не объяснил кто и для чего используют наш продукт. В итоге это выглядело так: вот вы, вот продукт с кучей легаси кода, вот Jira - поехали.Внутри команды мы собрали вопросы для менеджмента и попросили нам предоставить разные цифры. Например, список всех наших кастомеров, какой функционал чаще используется, приносит ли наш продукт прибыль и т.п.Как минимум, воодушевление пришло когда люди узнали кастомеров, например, "О, это мой банк", "У этих 3-х компаний больше миллиона сотрудников", "У меня машина этой компании" или "Я читаю финансовые новости от них". Думаю, в компаниях, названия которых встречаются хотя бы раз в месяц дела обстоят лучше.Боли (от выполнения ручной/неудобной работы)Когда мы взяли новых членов команды, то от них услышали, что некоторые процессы сложные/долгие/непонятные. Возможно, ранее так казалось и другим, но со времени все привыкли/забили/смирились. Т.к. у нас появилась возможность выявить слабые стороны, мы решили ею воспользоваться. Для этого мы начали:

Выслушивать и записывать недовольства всех членов команды. Про долгий билд, про QA автоматизацию, про непонимание того, на что нужно делать акцент в продукте и т.д.
Сравнивать затреканое время в Jira между нашей командой и другими командами, чтобы понять, кто делает что-то лучше нас и почему мы не делаем также.
Опять же посмотреть в Jira и рассмотреть что мы можем делать лишнего, или что уже не актуально и можно упразднить. Например, мы рассматривали релиз-тикеты и пытались понять какие моменты мы можем делать быстрее. Так мы обнаружили, что security scan кода занимал по 20-30 минут, мы подумали, что можно делать всё проще и в итоге сейчас это занимает около 5-10 минут.

На выходе у нас появились тикеты в существующих эпиках и новый эпик. В тот момент мы осознали, что для реализации некоторых тикетов могут понадобиться дополнительные скилы, которые ранее не использовались командой или случалось это крайней редко. А также пожелания от членов команды, кто и что хотел бы изучать. В результате у нас всё задокументировано в Jira в эпиках (с чем мы уже можем прийти к PO для обсуждения включения этих улучшений в дорожную карту на следующий квартал), у нас уже есть правило, что 10% времени в спринте каждый тратит на развитие своих навыков, и у нас уже был план кто и что будет изучать. В нашей компании у всех есть доступ к обучающим курсам на разных площадках, поэтому вопрос самообучения был решён автоматически, но мы договорились о следующем:

Изучение будет происходить в паре/тройке. Так и интересней, и если кто-то уйдёт в отпуск - работа не встанет.
Пары/тройки будут меняться в будущем. Чтобы команда не дробилась на небольшие "кружки по интересам" и оставалась одной командой.
Внутри пары/тройки нет ограничений на источник обучения. Кому-то могут нравиться курсы с LinkedIn, кому-то с Udemy, а кто-то вообще нашёл крутой разбор темы на YouTube на своём родном языке.

Больше болтовниИногда в офисе обсуждение небольшого вопроса у кулера может затянуться больше чем на пол часа и вовлечь несколько человек. Эти живые, неформальные беседы иногда вносят большой вклад в развитие команды и продукта. С уходом на удалёнку таких бесед почти не стало. А если ещё учесть что почти никто из нас ранее на удалёнке не работал - всем было очень трудно делить личное и рабочее время.Внутри команды мы стараемся (правда не всегда получается) общаться не только на рабочие вопросы: создавать мемы, обсуждать мировые темы и делиться ссылками на сторонние сайты. Это помогает поднять настроение и немного отвлечься от работы. Если таких разговоров много, значит в целом, команда в позитивном настрое. Если разговоров мало или совсем нет - значит что-то происходит: личные проблемы людей, какой-то блок, у кого-то с кем-то конфликт. В общем может быть что угодно - в любом случае на это нужно обращать внимание и копать в суть.Также мы заметили, что когда люди включают web-камеру - они более искренне и более разговорчивы. Если вся команда не разговорчива, мы просто используем Wheel Of Names и там уже рандомом выбираем кто будет говорить. ФидбекиФидбек - сам по себе очень крутой инструмент. Вы можете придумать крутую идею, внедрить её, не услышать фидбек и затем убрать её, т.к. можете считать, что она провалилась. Или наоборот, вы можете внедрить в процесс фигню, никто не будет говорить, что это плохо и в итоге эта фигня так и продолжит существовать. В общем, фидбеки - вещь классная.Мы постоянно общаемся с менеджментом и PO и слышим от них статистику, на что стоит обратить внимание сейчас. Как правило, это запаздывающие метрики и в итоге часто мы тушим пожары, но редко уделяем много времени причине их возникновения, т.к. сразу переключаемся на другой пожар. Это не значит, что мы не проводим анализы причины, просто "предотвращать" пожары может стоить дороже, чем их многочисленное тушение.Поэтому, мы стали искать те причины пожаров, решение которых займёт не много времени. Например, мы заметили, что наша L2 поддержка перегружена. Мы попросили фидбек от L2 команды и выяснили что у них много однотипных проблем от кастомеров, например, вот две из них:

Кастомеры задавали вопросы на одни и те же сообщения в логе. Суть в том, что в логе мы печатали что-то вроде "Module: service XXX call, RC = Y, RSN = ZZ". Т.к. это вообще не понятно никому, L2 выстраивали у себя сводную таблицу таких сообщений, чтобы отвечать кастомерам. Если какая-то новая комбинация - то это шло дальше в L3 (к разработчикам). Решением было простым: мы просто написали функцию которая по кодам печатает user-friendly сообщения с полным описанием причины проблемы.
Кастомеры находили уже пофикшенные баги. С каждым релизом мы не так много внимания уделяли описанию проблем. В итоге, когда пользователь встречал баг, он открывал описания выпущенных релизов и искал там свою проблему - разумеется он там ничего не находил и писал в саппорт. Ребятам из L2 приходилось лезть в нашу Jira и они пытались найти баги, похожие на кастомерские. Решение банально - мы стали лучше описывать баги с их симптомами в релизах. Кастомеры стали меньше писать в саппорт, т.к. находили свои баги в описаниях релизов, а если уж и открывалось, L2 на них почти всегда могли ответить самостоятельно и быстро.

В результате мы упростили работу нашей L2 поддержки. Но как это помогло нашей команде? У ребят из L2 появилось больше времени, и они тратили его на более глубокое изучение продукта, что позволяло отвечать самостоятельно на большую часть вопросов. Тем самым, количество обращений в саппорт уменьшилось, а также уменьшилось количество тикетов переходящих от L2 в L3. Тем самым, разработчики высвободили себе больше времени для решения реальных и актуальных проблем.Ежедневный отчётУ нас каждый день скрам-мастер, в конце рабочего дня, в канале команды в слаке публикует суточный отчёт, который описывает текущие горящие темы, блоки команд, проблемы в команде/продукте и т.п. Этот отчёт полезен как для команды, так и для менеджмента. Во-первых, если кто-то из команды имеет проблемы и видит, что его проблема там не описана - он идёт к скрам-мастеру и отчёт обновляется. Во-вторых, все видят что происходит сейчас в команде, у менеджмента есть актуальный, обобщённый отчёт, и им не нужно дёргать людей, чтобы получать ответы на свои вопросы. С помощью этого отчёта мы пытаемся добиться прозрачности и выявлять блоки как можно раньше, чтобы избегать случаев "У нас уже месяц всё хорошо, но 4 недели назад случилась проблема и мы не успеваем".Я хочу ещё раз подчеркнуть, что этот "отчёт" - был создан внутри команды для нас самих же и не занимает больше 5 минут в день для его поддержания. Свои метрикиВнутри команды у нас есть свои метрики. Некоторые пересекаются с менеджерскими, некоторые уникальны.Например, кастомерские проблемы идут в приоритет и нам, как команде, очень важно, чтобы оно в L3 находилось как можно меньше времени. Поэтому мы стараемся отвечать на проблему, либо находить реальную причину (например, баг) как можно быстрее. Менеджмент всего лишь следит, чтобы ответ был не дольше чем за 2/7 дней (в зависимости от важности проблемы - у них свои метрики).Частота "незапланированных" задач. Каждый спринт у нас случаются не запланированные таски, возникающие после старта спринта, которые откладывать на 1-2 недели нет возможности. Мы пытаемся отслеживать такие вещи, смотреть сколько в среднем мы тратим на них время и каждый спринт откусывать кусок пирога для этой активности. Тем самым, нам проще выполнять наши собственные коммитменты и тогда команда становится более предсказуемой. Мы используем и другие метрики, включая самые очевидные: процент покрытия кода юнит-тестами, покрытие QA тестами функционала продукта, время жизни пулл-ревквеста или velocity команды.Больше правилНикто не любит правила, особенно никто не любит появления новых рамок. Однако, внутри команды правила могут помочь избежать конфликтов, или использоваться как аргументы в них.Можно долго спорить и ругаться, например, что лучше: табы или пробелы, можно назначать митинги для их обсуждения, создавать новые чаты, ругаться в пулл-реквестах, а можно просто написать правило "только пробелы" и просто следовать ему. Кто-то будет недоволен, но теперь это правило, и его не обсуждают, ему просто следуют. Поэтому, рекомендую задокументировать всё, что связано с правилами написания кода. А ещё лучше, посоветовать команде почитать какой-нибудь Code Complete, чтобы разработчики (особенно начинающие) имели представление откуда эти правила берутся. Правила помогают разделять белое и чёрное, избегать конфликтов и иногда упрощать жизнь. А иногда, наоборот, усложняют жизнь. Ввод любого нового правила означает снижение доверия к индивидуумам, снижение доверия означает рост неэффективности, рост неэффективности приводит к увеличению времени разработки. Также, правила должны подвергаться пересмотру. Например, в какой-то момент времени у нас случилось несколько кастомерских проблем из-за релиза, баги в котором могли быть замечены аж на трёх этапах: Разработка (code review), Просмотр билда разработчиками, и уже QA. На всех трёх этапах можно было предотвратить ошибку. Разумеется, после этого инцидента все этапы были ужесточены. В итоге то, что раньше могло занимать до 5 дней, стало занимать до 10 дней. Со временем все ужесточения были пересмотрены. Некоторые до сих пор остались, просто был изменён процесс чтобы действие занимало меньше времени, что-то было упразднено, а что-то наоборот добавилось.Правила - как инструмент, может нести и пользу, и вред. Иногда удобно вводить временные правила, чтобы решить текущую проблему, а иногда нужно осознано вводить правило в ущерб краткосрочным целям в пользу долгосрочных. Например, сейчас для любого изменения в коде у нас требуется минимум 2 апрува. Т.е. как минимум трое из пяти членов команды согласны на эти изменения.Ответственность на всехВ нашей команде мы стараемся играть в "трёх мушкетёров", т.е. ответственность за всё лежит на ВСЕЙ команде, никто не будет осуждать члена команды вне команды. Если кто-то один облажался и это привело к каким-то последствиям, то всё равно виноваты все, потому что:

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

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

Женщину, которая в полной темноте переходила дорогу в неположенном месте?
Водителя автомобиля с автопилотом, который вряд ли сам среагировал бы?
Компанию, которая разрабатывает автопилот?
Разработчиков, кто писал код для автопилота?
QA кто выпустил этот код в прод?

Субъективно, тут виноваты все, либо никто. Но, очевидно, что виновные есть, т.к. в итоге женщина скончалась. Значит виноваты все.Данный подход может показаться не справедливым, т.к. обвиняя всю команду вы обвиняете и каждого её члена, даже тех кто вообще никакого отношения к инциденту не имел. Но с другой стороны, переживать такого рода стресс всем вместе проще, чем одному, это также увеличивает вовлечённость всей команды в процесс и жизнь продукта, а ещё, справедливости не существует. Аналогично, когда хвалят всю команду - значит хвалят и каждого в отдельности. А похвалу любят все.Team BuildingЯ не хочу заострять внимание на тимбилдинге, все мы понимаем зачем он нужен и каждый в этом участвовал. Тимбилдинг, так или иначе, нужен, особенно когда в команде появляются новые люди. Хочу отметить, что сейчас онлайн тимбилдингов уже существует много и есть где разгуляться. Основной посыл здесь, что не стоит ждать пока менеджмент соберёт всех вместе где-нибудь на очередной ежегодной вылазке. Нужно самоорганизовываться самим и организацию таких мероприятий (онлайн или оффлайн) брать на себя скрам-мастеру, тимлиду или самовыдвиженцам из команды.ЗаключениеВыбрав фреймворк как Scrum, Kanban, Lean и т.д. глупо надеяться что все проблемы разрешатся, все будут мотивированы, счастливы и довольны. Внутри команды не стоит надеяться, что кто-то другой решит ваши проблемы, особенно, если вы о них не говорите.Как инструмент, можно использовать что угодно: ответственность, правила, болтовню, боль, главное уметь пользоваться в конкретно вашем случае. Не существует большой красной кнопки, на которую вы нажмёте и все проблемы решатся, но существуют инструменты, которые в умелых руках могут сотворять шедевры, а в неумелых калечить людей.
===========
Источник:
habr.com
===========
Похожие новости:

Теги для поиска: #_upravlenie_razrabotkoj (Управление разработкой), #_agile, #_upravlenie_personalom (Управление персоналом), #_scrum, #_komanda (команда), #_agile, #_upravlenie_komandoj (управление командой), #_upravlenie_proektami_i_komandoj (управление проектами и командой), #_komanda_razrabotki (команда разработки), #_komandnaja_rabota (командная работа), #_upravlenie_razrabotkoj (
Управление разработкой
), #_agile, #_upravlenie_personalom (
Управление персоналом
)

Профиль ЛС

Ответить на тему

Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы

Текущее время: 25-Ноя 23:16
Часовой пояс: UTC + 5