Хабрахабр

Один в поле не воин. Путь до эффективной командной работы

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

Людей нужно организовать, дать им вменяемую цель, мотивацию и решать возникающие проблемы. Собрать несколько человек и сказать: «Теперь вы команда, ждем от вас результата», не получится.

В докладе Евгений поэтапно описал процесс организации эффективной команды разработки в Banki.ru: про найм, общение, обмен знаниями и развитие разработчиков и тестировщиков внутри коллектива и отдела. Как раз об этом расшифровка доклада Евгения Федореева на TeamLead Conf.

О спикере: Евгений Федореев (hardj) занимается веб-разработкой 15 лет, их них 6 — в позиции тимлида, а сейчас руководит направлением разработки новых проектов Banki.ru.

Что такое Banki.ru?

Контекст компании, чтобы знать, о каком опыте пойдет речь. Banki.ru — это крупнейший независимый финансовый портал Рунета с ежемесячной аудиторией больше 8 миллионов уникальных пользователей.

Вся разработка ведется in-house, удаленных разработчиков нет, поэтому в соответствующих процессах и метриках нет необходимости. В IT-отделе работает 50-70 человек, поделенных на 7 команд разработки.

Основная задача команды разработки

Когда готовился к докладу, я задавал людям вопрос:

Если человек сидит, рефакторит, не приносит пользы, не решает бизнес-задач — это тоже разработка?
— … Нужно эффективно разрабатывать. — Какая цель у команды разработки?
— Разрабатывать.
— Что это значит?

Эффективность разработки

Понятие эффективности для менеджера одно, а для разработчика другое.

Для управленца эффективная разработка — прогнозируемая: когда известна дата релиза фичи или срок выполнения задачи, чтобы провести какие-то бизнес-мероприятия.

Это одна из болей, так как на работу с тех. Для разработчика — это работа с техническим долгом. долгом, на рефакторинг, на исправления и улучшения дается очень мало времени.

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

Я специально не написал «продуманная архитектура». Заделы на будущее. Заранее углубляться и продумывать архитектуру — зло, поэтому в разработке должен быть задел на будущее, но без фанатизма.

Любой другой критерий, который есть у каждой команды.

Процесс разработки

Строить процессы разработки в Banki.ru мы начали после того, как компания стала развиваться и расти. Появились новые партнеры и проекты, и 6-9 backend-разработчиков не хватало. Мы пришли к тому, что нужно выстроить процесс разработки и формализовать его, для эффективной работы.

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

Мы взяли двух фронтенд-разработчиков и еще двух тестировщиков, чтобы жить без багов и считали, что этой конфигурации будет достаточно.

В идеальном мире процесс разработки должен выглядеть так.

  • Project manager скидывает задачу в бэкенд-команду и они ее выполняют.
  • Если нужна доработка — отправляют задачу фронтенд-команде.
  • После доработки фронтенд отдает ее в QA.
  • Багов нет? — В продакшен.

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

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

Задачи прыгают, как мячик в пинг-понге: от QA к фронт и бэк разработчикам, и даже долетают до менеджеров. Наша схема трансформировалась.

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

Как сократить время доставки?

Первое, что пришло на ум — задать вопрос о том, почему мы возвращаем задачи? Почему бэкенд, фронтенд и QA понимают задачу по-разному? Почему взгляды различаются? Мы пришли к тому, что нашли виноватого в менеджере проекта, что он описывает задачи не полностью, и сказали PM описывать задачи полнее, чтобы всем понимать, что имелось в виду.

Мы привлекли к планированию тестировщиков и фронтенд-разработчиков, но на 3 команды было всего 2 фронтенд-разработчика и 2 тестировщика. Планированием у нас занимались три бэкенд-команды. Часто звать их не получалось, потому что кому-то надо работать.

Поделили задачи отдельно на frontend и backend, чтобы отдавать их в разработку параллельно, быстрее тестировать и не ждать всю цепочку.

В результате время сократилось, но все равно нас не устраивало. Мы попробовали все решения.

Мы думали, что делать дальше. На рынке много компаний и практик, и мы стали изучать, смотреть, копать и дошли до feature-team.

Feature-team

Это когда в команде есть все полный набор людей для выполнения задачи:

  • бэкенд-разработчики.
  • фронтенд -разработчики.
  • QA-разработчики.

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

Теперь задачи быстрее выходят в боевой режим, но вылезла куча проблем. В тот момент мы перешли на Agile и Scrum: пригласили тренеров и коучей, провели мастер-классы в компании, и начали классический Scrum — двухнедельные спринты, оценка, планирование и груминги.

Проблемы feature-team

На тот момент у нас появилось 6 проблем.

  • Bus-factor.
  • Долгое планирование. Для планирования мы выделяли полдня или больше: разбирали задачи, уходили на обед, потом опять разбирали. Когда планирование заканчивалось, никто уже работать не мог и не хотел — день потерян.
  • Незакрытые спринты. Это серьезная боль — большинство задач в спринтах не доходило до колонки «Выполнено».
  • Разный характер задач у команд.
  • Появление новых команд.
  • Обмен опытом среди команд.

Проблемы есть, будем решать.

Bus-factor

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

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

Фронтенд-разработчики ввели кросс-командное code-review, когда один разработчик решает в одной команде задачу и отдает ее на review в другие команды, и после минимум двух утверждений задача идет в тестирование.

В команде был один тестировщик и продублировать его не получалось, так как задач на такое количество не было. Добавили автотесты. Это немного увеличило время, но задачи проходили тестирование. Мы договорились о помощи тестировщика из другой команды: он будет присматривать за задачами соседней команды, и подменять сотрудника, который уходит в отпуск.

Долгое планирование

Мы разбирали задачи на планировании. В момент спринтов все работали и кодили, а на планировании чуть ли не в первый раз открывали задачи и разбирались, что надо делать, тестировщики уточняли «definition of done», чтобы понять как тестировать задачу.

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

Мы предложили менеджерам описывать задачи подробнее, но не слишком, чтобы не закопаться в тонне документации.

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

Незакрытые спринты

Это боль. Может у кого-то они закрываются, а у нас на тот момент — нет.

Думали, что будем планировать на 8 дней, а 2 дня оставим тестерам. Мы решили сократить емкость спринта с 10 рабочих дней, до 8-ми.

На 20% меньше задач в спринте ничего не дали. В реальности оказалось, что когда разработчик видит меньше задач, то он их и выполняет неспешно.

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

В тот момент нам на глаза попалась книга про цель и несколько практик Максима Дорофеева. Сокращение емкости спринта и загрузка тестера не помогли и мы думали, как все-таки решить проблему. На планировании тестировщик ставил оценку, емкость спринта рассчитывали от него, и набирали задачу в спринт под тестера. Мы поняли, что впихнуть «невпихуемое» не получится и стали планировать спринт от узкого места — от тестирования.

Мы пошли к менеджерам продавать эту идею: Класс!

Спринты будут закрываться, будет круто!
— Подождите, а что в этот момент будут делать свободные разработчики? — Мы решили планировать от тестеров. Давайте спринты закрывать. Задач будет меньше, у них появится свободное время!
— Ты хочешь, чтобы спринты закрывались, чтобы разработка была прогнозируемая или главная цель людей занять?
— Нет, все-таки прогнозируемая разработка.

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

Оказалось, что разработчики могут делать очень много дел, когда они свободны.

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

Когда у разработчика не было задач, он смотрел backlog, уточнял требования. Разбирать задачи из backlog и уточнять требования. Осталось уточнить детали и все — тестер оценивает, и задача пошла. К моменту планирования задачи полностью описаны, все вопросы заданы, а решения приняты.

В тот момент у нас еще практиковалась помощь другим командам, в которых аврал, кто-то в отпуске или заболел, а проект горит. Помогать другим командам. Обособленные частные задачи можно брать и помогать другим командам.

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

Разный характер задач у команд

У нас есть продуктовые команды, которые делают что-то новое. У них двухнедельное планирование, спринты, длинные проекты и к релизу они приходят через 1-2 месяца или больше.

Допустим, коммерческий отдел продал лэндинг — надо его быстро сделать. У нас есть маркетинговые команды, которые работают более реактивно: пришла задача — сделали, пришла задача — сделали. Неудовлетворенность команды, постоянный аврал, спринты не завершаются — ситуация неприятная. Эти команды первоначально тоже работали по Scrum и двухнедельным спринтам, но получалось, что в конце спринта задачи совсем другие, чем в начале.

Мы решили поговорить с PM и с бизнесом:

Нам за это платят миллион. — Ребята, у нас Agile, Scrum, спринты, процессы — давайте не будем вкидывать новые задачи, а будем прогнозируемо разрабатывать.
— Смотрите, мы продаем лэндинг, его надо сделать через 3 дня. Деньги надо тоже зарабатывать! Какие процессы?

Мы стали думать дальше. Миллион нас убедил.

Тоже не пошло, потому что планировать в тот момент для этой команды совсем не получалось.
Дальше решили не планировать спринты, а работать по Kanban вместо Scrum: пришла задача, взяли в работу, выпустили. Решили сократить спринты до недели — так мы сможем быстрее реагировать. Команда работала продуктивнее, потому что изначально понимала, что планирования нет, а есть только задачи на выполнение. Это сработало.

Чтобы улучшать процессы в команде и получать обратную связь, мы стали проводить ретроспективы каждые 2 недели: команда собиралась, обсуждала, что прошло хорошо, что нет, какие плюсы и минусы, и работали с этим.

Появление новых команд

В тот момент мы начали расти, у нас появлялись новые команды: приходит тимлид, разработчики, команда обрастает, а люди между собой еще не притерлись. В этот период о планировании не говорим — люди в первый раз видят наш код, а он может быть и плохим, например, у нас есть чуть-чуть Битрикса. Что-то с этим надо было делать

Мы решили — пусть они учатся планировать и оценивать задачи, но сократили спринт до 1 недели. Можно было взять тот же Kanban, чтобы разработчики выполняли задачи, как могут, но это продуктовая команда, ее надо учить.

Увеличим время до 2 недель через 1-2 месяца, когда команда притрется, войдет в общую продуктовую работу, наладит процессы и разработчики смогут нормально оценивать задачи.

Обмен опытом между командами

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

Цель встреч — перенести опыт от одной команды к другой через тимлидов. Мы стали думать — что с этим делать, и ввели еженедельные встречи тимлидов.

Первые встречи проходили так:

— Здравствуйте, меня зовут Евгений, мы сейчас пилим новости.
— Круто!

Следующая встреча:

— Здравствуйте, меня по-прежнему зовут Евгений, мы продолжаем пилить новости.
— Ок.

Ничего неординарного не происходит.

Третья встреча: Здравствуйте… И все то же самое.

Почитали книги о проведении совещаний и
ввели фиксированную повестку. Мы поняли, что надо менять формат.

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

Плюсы такого решения

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

Формат встреч нам понравился и мы стали их проводить регулярно.

Это некий обмен опытом, который уже практиковали фронтенд-разработчики, а позднее и ребята из бэкенд. Мы ввели кросс-командное code-review. Дляcode-review мы выбирали только заинтересованные команды, не было обязательного approve.
Возникают ситуации, когда соседняя команда, которая занимается банками, просит доработать функционал — добавить поля, а мы занимаемся кредитами.Можно попросить другую команду, но у них свой план и непонятно, когда они выполнят просьбу, а ждать нельзя. Отдавать весь код на кросс-командное code-review не обязательно, достаточно только важных вещей, например, общие библиотеки или общие куски кода. В такой ситуации мы помогаем соседней команде, но на code-review отдаем другой.

Например, у нас один сотрудник год занимался кредитными картами и просит сменить область, а другой хочет поменять технологию с UI на Symfony. Бывает так, что разработчики просят перевестись на другое направление или сменить технологию. По договоренности мы организуем переход разработчиков между командами.

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

На посиделках команды рассказывали, чем занимаются, что нового. Все было круто. На пятничной встрече команда рассказала про свою работу, показала аналитику и все поняли смысл их работы. Например, с одной из команд у нас возникло непонимание, никто не знал, чем она занимается. Фронтенд-разработчики рассказывали как происходит сборка, обсуждали общетехнические темы, например, как пользоваться Debugger’ом в PHPStorm, как происходит деплой.

Как дальше простимулировать разработчиков что-то рассказывать? А потом темы по разработке закончились, мы перешли на психологические и история стала угасать.

Давайте каждого разработчика научим выступать и включим в его KPI 2 доклада за полгода на пятничных посиделках. И тут мы вспомнили про KPI! Мы думали, что идея крутая и все будут выступать.

К обязательным выступлениям возник негатив. Оказалось, что после введения KPI, разработчики перестали делать доклады. Программисты решили пожертвовать 100% выполнением KPI, лишь бы не делать добровольно-принудительные доклады.

Выводы

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

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

Принципы эффективной команды

Каждый член команды — самостоятельный сотрудник.

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

Задача должна быть сделана одним человеком — если ты взял ее на себя, то должен довести до конца.

Бывали случаи, когда разработчик говорит:
— У меня нет паролей на интеграцию с партнерами.— ОК, напиши письмо или скажи PM.
Сказал PM и опять сидит день или два.
— Вася, что случилось?— Я PM написал, а пароля все нет.

Мы пришли к тому, что человек должен дожимать, чтобы как можно быстрее получать необходимые данные.

Меньше формальностей. Важно общение внутри команды.

Есть инструменты вроде Jira или Slack, которые помогают общаться с удаленными работниками по интернету, а у нас люди общаются между собой лично, решают и обсуждают проблемы сразу. Так как мы все работаем в одном офисе, важно минимизировать формальности внутри команды. Мы даже ушли от еженедельных Scrum-митингов, потому что они не нужны.

Когда у нас появляется проблема, мы ее сразу обсуждаем и решаем.

Тимлид поддерживает единство в команде.

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

— А что происходит?
— Мы в командном чатике общаемся!
— Меня туда добавьте!
— А у тебя не Айфон, мы в iMessage!

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

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

Тимлид защищает команду от «внешних факторов».

Тимлид — это фильтр, который решает какую информацию извне допускать в команду, а какую нет.

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

О результатах расскажу здесь, когда уже все будет привязано к расписанию, а в рассылке будут приходить регулярные тематические подборки.
Сбор программы TeamLead Conf, которая пройдет 25 и 26 февраля в Москве, в самой жаркой стадии.

Показать больше

Похожие публикации

Добавить комментарий

Ваш адрес email не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»