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

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

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



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


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

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


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

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

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


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

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

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


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

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

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

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

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

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

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


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

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



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

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



    • 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», чтобы понять как тестировать задачу.

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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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


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

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

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

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

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

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

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

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


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

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

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

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


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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

    Выводы


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

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


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

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

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

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

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

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

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

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

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

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

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

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

    Сбор программы TeamLead Conf, которая пройдет 25 и 26 февраля в Москве, в самой жаркой стадии. О результатах расскажу здесь, когда уже все будет привязано к расписанию, а в рассылке будут приходить регулярные тематические подборки.
    • +30
    • 5,4k
    • 6
    Конференции Олега Бунина (Онтико)
    829,00
    Конференции Олега Бунина
    Поделиться публикацией

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

      0

      "повезло", что проблемы "решились" раздутием штата (добавили ещё фронтендеров) и "предсказуемость важнее сжатых сроков". Жаль, что так получается навсегда.


      В какие примерно годы происходили описанные в статье события?

        0
        Начало преобразований это 2013 год. Оптимизация и совершенствование идут до сих пор…

        Я рассказывал как у нас все устроено. Соглашусь что каждая компания имеет свою специфику и не всем наш путь подойдет.
        +1

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


        1. Аврал никуда не девает, нужно все также быстро
        2. Отсутствие планирование также не дает команде синхронизироваться в понимании задач, тестировщики говорят — мы узнаем о задаче только когда она попадает в тестирование
        3. Срочность, отсутствие груминга и планирования не дает описывать задачи приемлимо, зачастью уточнения происходят уже в процессе разработки.

        Могли бы в двух словах рассказать сталкивались ли с такими проблемами и если да, то как боролись?

          +1
          1. Вы правы, аврал никуда не девается. Бороться с ним нужно на уровне менеджеров, команда, к сожалению ничего сделать с этим не может. (вариант не брать задачи в течении спринтов не рассматриваем). Мы постоянно общаемся с продуктовым отделом и по возможности они идут навстречу разработке. Работа по канбану скорее показывает, что команда приняла реактивную работу и не прикрывается тем что есть планирование и спринты.
          2. Я говорил что команда проводит ретроспективы каждые две недели, они позволяют выяснить что хорошо и плохо и как это улучшить (например у однотипных задач договорится что нужно описывать в них чтобы на всех этапах разработки и тестирования понимать суть задачи). Планирование перед спринтом в чистом виде нет. Но груминги проходят, в команде всегда есть плановые задачи и проектные задачи, их можно разбирать.
          3. Вы правы, зачастую задачи влетают с неполным описанием и нужно по ходу реализации уточнять. Хотя все уточнения мы проводим устно (общение с менеджером) результаты мы всегда заносим в задачу, чтобы тестеры и все причастные видели к чему пришли и что в итоге нужно сделать в задаче.

          К сожалению работа в режиме аврала свойственна некоторым командам и без нее никак. Но мы всячески стараемся снизить масштабы аврала: общением с менеджерами, типизация задач и стандартизация описания требований для однотипных задач (которых в команде достаточное количество). Мы не обманываем себя что у нас жесткие спринты и планирование… Возможно в будущем как-то улучшим процессы и обязательно поделюсь.
          0
          Не совсем понятно, вы работали по Scrum, затем перешли на Kanban из-за особенностей работы маркетингового отдела, а затем обратно вернулись к Scrum и двухнедельным спринтам? А как же маркетинг с лендингами?
            0
            Не совсем так. У нас несколько команд, часть команд работает по скраму, а часть по канбану.

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

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