Команда — это группа людей, которые вместе двигаются к общей цели, распределяют между собой задачи и ответственность за конкретный результат. Команды создаются, чтобы решать задачи, которые один человек выполнить не сможет. Эффективная команда достигает цели за минимальный срок с минимальными затратами.
Собрать несколько человек и сказать: «Теперь вы команда, ждем от вас результата», не получится. Людей нужно организовать, дать им вменяемую цель, мотивацию и решать возникающие проблемы.
Как раз об этом расшифровка доклада Евгения Федореева на TeamLead Conf. В докладе Евгений поэтапно описал процесс организации эффективной команды разработки в Banki.ru: про найм, общение, обмен знаниями и развитие разработчиков и тестировщиков внутри коллектива и отдела.
О спикере: Евгений Федореев (hardj) занимается веб-разработкой 15 лет, их них 6 — в позиции тимлида, а сейчас руководит направлением разработки новых проектов Banki.ru.
Контекст компании, чтобы знать, о каком опыте пойдет речь. Banki.ru — это крупнейший независимый финансовый портал Рунета с ежемесячной аудиторией больше 8 миллионов уникальных пользователей.
В IT-отделе работает 50-70 человек, поделенных на 7 команд разработки. Вся разработка ведется in-house, удаленных разработчиков нет, поэтому в соответствующих процессах и метриках нет необходимости.
Когда готовился к докладу, я задавал людям вопрос:
— Какая цель у команды разработки?
— Разрабатывать.
— Что это значит? Если человек сидит, рефакторит, не приносит пользы, не решает бизнес-задач — это тоже разработка?
— … Нужно эффективно разрабатывать.
Понятие эффективности для менеджера одно, а для разработчика другое.
Для управленца эффективная разработка — прогнозируемая: когда известна дата релиза фичи или срок выполнения задачи, чтобы провести какие-то бизнес-мероприятия.
Для разработчика — это работа с техническим долгом. Это одна из болей, так как на работу с тех. долгом, на рефакторинг, на исправления и улучшения дается очень мало времени.
Следующий критерий эффективности — минимальное количество багов. Можно было бы написать, что критерий — полное отсутствие багов, но мы знаем, что такого не бывает. Кроме того, обидятся тестировщики, ведь они будут не нужны.
Заделы на будущее. Я специально не написал «продуманная архитектура». Заранее углубляться и продумывать архитектуру — зло, поэтому в разработке должен быть задел на будущее, но без фанатизма.
Любой другой критерий, который есть у каждой команды.
Строить процессы разработки в Banki.ru мы начали после того, как компания стала развиваться и расти. Появились новые партнеры и проекты, и 6-9 backend-разработчиков не хватало. Мы пришли к тому, что нужно выстроить процесс разработки и формализовать его, для эффективной работы.
Изначально у нас было 3 команды, в каждой по 3 бэкенд-разработчика и менеджер, который отвечал за части сайта. Backend-разработчики, кроме своей работы, еще верстали и подключали jQuery-плагины, так как в тот момент на фронтенде было мало людей.
Мы взяли двух фронтенд-разработчиков и еще двух тестировщиков, чтобы жить без багов и считали, что этой конфигурации будет достаточно.
В идеальном мире процесс разработки должен выглядеть так.
Мы предположили, что мир не идеален, и QA будут возвращать задачи, так как баги присутствуют в любой разработке, и добавили еще две стрелочки.
После обновления схемы, мы решили, что все круто и стали по ней работать — проводили планирование спринтов, а бэкенд-команды сами ставили задачи в план. Поработали 2 месяца и поняли, что что-то не так.
Наша схема трансформировалась. Задачи прыгают, как мячик в пинг-понге: от QA к фронт и бэк разработчикам, и даже долетают до менеджеров.
Стрелочки занимают много времени — процесс доставки задачи на боевые сервера слишком длинный. Нас это не устраивало. Мы хотели минимизировать количество стрелок, чтобы задачи выполнялись быстрее.
Первое, что пришло на ум — задать вопрос о том, почему мы возвращаем задачи? Почему бэкенд, фронтенд и QA понимают задачу по-разному? Почему взгляды различаются? Мы пришли к тому, что нашли виноватого в менеджере проекта, что он описывает задачи не полностью, и сказали PM описывать задачи полнее, чтобы всем понимать, что имелось в виду.
Планированием у нас занимались три бэкенд-команды. Мы привлекли к планированию тестировщиков и фронтенд-разработчиков, но на 3 команды было всего 2 фронтенд-разработчика и 2 тестировщика. Часто звать их не получалось, потому что кому-то надо работать.
Поделили задачи отдельно на frontend и backend, чтобы отдавать их в разработку параллельно, быстрее тестировать и не ждать всю цепочку.
Мы думали, что делать дальше. На рынке много компаний и практик, и мы стали изучать, смотреть, копать и дошли до feature-team.
Это когда в команде есть все полный набор людей для выполнения задачи:
Между ними также есть связи, задачи прыгают и играют в пинг-понг, но связи гораздо короче и отнимают меньше времени. В планировании участвует вся команда, она заинтересована в результате и создает единую картину: что делать и как доставить задачу в боевой режим в короткие сроки.
В тот момент мы перешли на Agile и Scrum: пригласили тренеров и коучей, провели мастер-классы в компании, и начали классический Scrum — двухнедельные спринты, оценка, планирование и груминги. Теперь задачи быстрее выходят в боевой режим, но вылезла куча проблем.
На тот момент у нас появилось 6 проблем.
Проблемы есть, будем решать.
Изначально каждая команда состояла из фронтенд-разработчика, тестировщика и трех бэкенд-разработчиков. Мы взяли в штат дополнительных фронтенд-разработчиков — продублировали роли.
Ввели еженедельные встречи по направлениям. Фронтенд-разработчики собирались отдельно каждую неделю и обсуждали новые технологии, решение задач и договаривались об общих практиках и подходах. Тестировщики тоже собирались, совещались, решали, как тестировать, обсуждали автотесты.
Фронтенд-разработчики ввели кросс-командное code-review, когда один разработчик решает в одной команде задачу и отдает ее на review в другие команды, и после минимум двух утверждений задача идет в тестирование.
Добавили автотесты. В команде был один тестировщик и продублировать его не получалось, так как задач на такое количество не было. Мы договорились о помощи тестировщика из другой команды: он будет присматривать за задачами соседней команды, и подменять сотрудника, который уходит в отпуск. Это немного увеличило время, но задачи проходили тестирование.
Мы разбирали задачи на планировании. В момент спринтов все работали и кодили, а на планировании чуть ли не в первый раз открывали задачи и разбирались, что надо делать, тестировщики уточняли «definition of done», чтобы понять как тестировать задачу.
Процесс отнимал много времени. Мы решили разбирать задачи до планирования: предложили разработчикам посмотреть задачу в свободное время, задавать вопросы, чтобы на планирование приходить подготовленными.
Мы предложили менеджерам описывать задачи подробнее, но не слишком, чтобы не закопаться в тонне документации.
Мы целенаправленно выделили на дополнительные груминги час а не в свободную минутку. Собирались всей командой, обсуждали задачи и на планирование приходили подготовленными.
Это боль. Может у кого-то они закрываются, а у нас на тот момент — нет.
Мы решили сократить емкость спринта с 10 рабочих дней, до 8-ми. Думали, что будем планировать на 8 дней, а 2 дня оставим тестерам.
В начале спринта, пока есть время, тестировщик составлял тест-кейсы. В теории, в начале спринта, пока разработчики работают, у тестера нет задач. Мы договорились, что в это время тестировщик может пройти все задачи, составить тест-кейсы, а когда задача придет на тестирование, — он прогонит ее по подготовленным тест-кейсам, и сократит время на тестирование. Глобально это не помогло, хотя время немного сократилось.
Сокращение емкости спринта и загрузка тестера не помогли и мы думали, как все-таки решить проблему. В тот момент нам на глаза попалась книга про цель и несколько практик Максима Дорофеева. Мы поняли, что впихнуть «невпихуемое» не получится и стали планировать спринт от узкого места — от тестирования. На планировании тестировщик ставил оценку, емкость спринта рассчитывали от него, и набирали задачу в спринт под тестера.
Класс! Мы пошли к менеджерам продавать эту идею:
— Мы решили планировать от тестеров. Спринты будут закрываться, будет круто!
— Подождите, а что в этот момент будут делать свободные разработчики? Задач будет меньше, у них появится свободное время!
— Ты хочешь, чтобы спринты закрывались, чтобы разработка была прогнозируемая или главная цель людей занять?
— Нет, все-таки прогнозируемая разработка. Давайте спринты закрывать.
После диалога одна команда стала работать по-новому. Схема показала свою живучесть, мы по ней работали, закрывали спринты и у разработчиков оставалось время.
А именно: работать с тех. долгом. В команде всегда есть общий тех. долг на отдел. Эти задачи можно брать в работу и тестировать. Как правило, тех. долг — это системный рефакторинг. Для этих задач нужно проводить регрессионное тестирование, и не всегда это должен выполнять тестер команды. Отдел тестирования выделил специальных тестировщиков, которые проводили регресс, в том числе и руководитель отдела тестирования. Задачи по тех. долгу отдавались в тестирование другим сотрудникам и наши тестировщики не страдали.
Разбирать задачи из backlog и уточнять требования. Когда у разработчика не было задач, он смотрел backlog, уточнял требования. К моменту планирования задачи полностью описаны, все вопросы заданы, а решения приняты. Осталось уточнить детали и все — тестер оценивает, и задача пошла.
Помогать другим командам. В тот момент у нас еще практиковалась помощь другим командам, в которых аврал, кто-то в отпуске или заболел, а проект горит. Обособленные частные задачи можно брать и помогать другим командам.
Кроме того всегда есть отпуска, обучение, участие в конференциях, на которые тоже надо выделять время, для подготовки. Когда сотруднику в рабочее время дают возможность что-то изучить, почитать Хабр, посмотреть видео по работе — лояльность повышается. Мы эту проблему решили, и всем стало комфортно.
У нас есть продуктовые команды, которые делают что-то новое. У них двухнедельное планирование, спринты, длинные проекты и к релизу они приходят через 1-2 месяца или больше.
У нас есть маркетинговые команды, которые работают более реактивно: пришла задача — сделали, пришла задача — сделали. Допустим, коммерческий отдел продал лэндинг — надо его быстро сделать. Эти команды первоначально тоже работали по Scrum и двухнедельным спринтам, но получалось, что в конце спринта задачи совсем другие, чем в начале. Неудовлетворенность команды, постоянный аврал, спринты не завершаются — ситуация неприятная.
Мы решили поговорить с PM и с бизнесом:
— Ребята, у нас Agile, Scrum, спринты, процессы — давайте не будем вкидывать новые задачи, а будем прогнозируемо разрабатывать.
— Смотрите, мы продаем лэндинг, его надо сделать через 3 дня. Нам за это платят миллион. Какие процессы? Деньги надо тоже зарабатывать!
Миллион нас убедил. Мы стали думать дальше.
Решили сократить спринты до недели — так мы сможем быстрее реагировать. Тоже не пошло, потому что планировать в тот момент для этой команды совсем не получалось.
Дальше решили не планировать спринты, а работать по Kanban вместо Scrum: пришла задача, взяли в работу, выпустили. Это сработало. Команда работала продуктивнее, потому что изначально понимала, что планирования нет, а есть только задачи на выполнение.
Чтобы улучшать процессы в команде и получать обратную связь, мы стали проводить ретроспективы каждые 2 недели: команда собиралась, обсуждала, что прошло хорошо, что нет, какие плюсы и минусы, и работали с этим.
В тот момент мы начали расти, у нас появлялись новые команды: приходит тимлид, разработчики, команда обрастает, а люди между собой еще не притерлись. В этот период о планировании не говорим — люди в первый раз видят наш код, а он может быть и плохим, например, у нас есть чуть-чуть Битрикса. Что-то с этим надо было делать
Можно было взять тот же Kanban, чтобы разработчики выполняли задачи, как могут, но это продуктовая команда, ее надо учить. Мы решили — пусть они учатся планировать и оценивать задачи, но сократили спринт до 1 недели.
Увеличим время до 2 недель через 1-2 месяца, когда команда притрется, войдет в общую продуктовую работу, наладит процессы и разработчики смогут нормально оценивать задачи.
Внутри команды разработчики и тестеры общаются между собой и обмениваются опытом, но этот опыт не обновляется, потому что команда «варится в себе». Новому опыту неоткуда взяться.
Мы стали думать — что с этим делать, и ввели еженедельные встречи тимлидов. Цель встреч — перенести опыт от одной команды к другой через тимлидов.
Первые встречи проходили так:
— Здравствуйте, меня зовут Евгений, мы сейчас пилим новости.
— Круто!
Следующая встреча:
— Здравствуйте, меня по-прежнему зовут Евгений, мы продолжаем пилить новости.
— Ок.
Ничего неординарного не происходит.
Третья встреча: Здравствуйте… И все то же самое.
Мы поняли, что надо менять формат. Почитали книги о проведении совещаний и
ввели фиксированную повестку.
Плюсы такого решения
Формат встреч нам понравился и мы стали их проводить регулярно.
Мы ввели кросс-командное code-review. Это некий обмен опытом, который уже практиковали фронтенд-разработчики, а позднее и ребята из бэкенд. Отдавать весь код на кросс-командное code-review не обязательно, достаточно только важных вещей, например, общие библиотеки или общие куски кода. Дляcode-review мы выбирали только заинтересованные команды, не было обязательного approve.
Возникают ситуации, когда соседняя команда, которая занимается банками, просит доработать функционал — добавить поля, а мы занимаемся кредитами.Можно попросить другую команду, но у них свой план и непонятно, когда они выполнят просьбу, а ждать нельзя. В такой ситуации мы помогаем соседней команде, но на code-review отдаем другой.
Бывает так, что разработчики просят перевестись на другое направление или сменить технологию. Например, у нас один сотрудник год занимался кредитными картами и просит сменить область, а другой хочет поменять технологию с UI на Symfony. По договоренности мы организуем переход разработчиков между командами.
Некоторые компании практикуют встречи по пятницам: люди собираются для обмена опытом, что-то обсуждают, рассказывают. Мы тоже решили организовать пятничные посиделки — завели страничку в Wiki, где каждый, кто хочет выступить, пишет тему своего доклада.
Все было круто. На посиделках команды рассказывали, чем занимаются, что нового. Например, с одной из команд у нас возникло непонимание, никто не знал, чем она занимается. На пятничной встрече команда рассказала про свою работу, показала аналитику и все поняли смысл их работы. Фронтенд-разработчики рассказывали как происходит сборка, обсуждали общетехнические темы, например, как пользоваться Debugger’ом в PHPStorm, как происходит деплой.
А потом темы по разработке закончились, мы перешли на психологические и история стала угасать. Как дальше простимулировать разработчиков что-то рассказывать?
И тут мы вспомнили про KPI! Давайте каждого разработчика научим выступать и включим в его KPI 2 доклада за полгода на пятничных посиделках. Мы думали, что идея крутая и все будут выступать.
Пока мы решали проблемы с эффективностью, компания развивалась и появлялись новые проекты и нам приходилось приспосабливаться. Вот что мы из этого поняли.
Каждый член команды — самостоятельный сотрудник.
Мы учим людей выполнять задачу полностью. Например, когда у человека не хватает требований или доступов, мы хотим, чтобы он мог найти эти данные сам: пойти к админами, к PM, попросить логин или пароль.
— У меня нет паролей на интеграцию с партнерами.— ОК, напиши письмо или скажи PM.
Сказал PM и опять сидит день или два.
— Вася, что случилось?— Я PM написал, а пароля все нет.
Мы пришли к тому, что человек должен дожимать, чтобы как можно быстрее получать необходимые данные.
Важно общение внутри команды. Меньше формальностей.
Так как мы все работаем в одном офисе, важно минимизировать формальности внутри команды. Есть инструменты вроде Jira или Slack, которые помогают общаться с удаленными работниками по интернету, а у нас люди общаются между собой лично, решают и обсуждают проблемы сразу. Мы даже ушли от еженедельных Scrum-митингов, потому что они не нужны.
Тимлид следит за настроением в команде и решает проблемы. Например, у нас один разработчик работал год. Мы заметили, что команда перестала с ним общаться. Человек сидит, что-то делает, а к нему никто не подходит — это уже сигнал, — что-то не так. Когда люди создали внутри команды чат для обмена сообщениями, сигнал вопил как пожарная сигнализация. Разработчик спрашивает:
— А что происходит?
— Мы в командном чатике общаемся!
— Меня туда добавьте!
— А у тебя не Айфон, мы в iMessage!
После этого я пошел к директору по разработке и сказал, что надо что-то делать: команда демотивирована, классный специалист не может работать.
Мы перевели его в другую команду, и всем стало лучше: взяли нового разработчика, который влился в команду, а предыдущий нашел себя в новой команде, проработал 2 года, и получал хорошие отзывы от тимлида.
Тимлид защищает команду от «внешних факторов».
Тимлид — это фильтр, который решает какую информацию извне допускать в команду, а какую нет.
Объясню на примере. В отделе маркетинга или в руководстве, всегда «лучше»знают, сколько времени уходит на разработку — им друзья рассказывали, что у себя фичу запилили за месяц, а наши полгода делают. Руководству не объяснить, что у нас куча подводных камней, которые решаем, но быстрее не можем. Когда такая информация доходит до команды, часть разработчиков демотивируется, уходит в себя.
Будьте фильтрами между внешней средой и командой. Всю информацию надо дозировать, чтобы не демотивировать разработчиков.
Собрать несколько человек и сказать: «Теперь вы команда, ждем от вас результата», не получится. Людей нужно организовать, дать им вменяемую цель, мотивацию и решать возникающие проблемы.
Как раз об этом расшифровка доклада Евгения Федореева на 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 февраля в Москве, в самой жаркой стадии. О результатах расскажу здесь, когда уже все будет привязано к расписанию, а в рассылке будут приходить регулярные тематические подборки.
