Наверх ▲

Опыт реформирования большой команды разработчиков

Сергей Никулин Сергей Никулин Технический директор в компании "HeadHunter".
Whale rider никулин
View more presentations from Ontico

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

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

У нас эта проблема очень остро встала в конце 2010-го года. Что же представлял собой HeadHunter в это время? Мы разрабатывали и эксплуатировали самый высоконагруженный и популярный сайт, связанный с поиском работы в Восточной Европе. Причем на нашей платформе работает не только hh.ru, который знают, наверное, все присутствующие, но и множество сайтов в других странах. Например, самый популярный сайт по поиску работы в Казахстане hh.kz, самый популярный сайт по поиску работы в Белоруссии jobs.tut.by. На Украине у нас тоже есть сайт, и так далее.

Кроме этого, у нас есть множество нишевых сайтов, тоже связанных с поиском работы. Есть проект Ri.ru, который ориентирован на поиск людей, которые только заканчивают учиться или еще учатся. Есть JobList, который предназначен для людей рабочих специальностей. Также существует множество других, более мелких проектов. 

Команда в тот момент состояла из порядка 30 программистов и верстальщиков, а также 5 тестировщиков. Есть еще служба эксплуатации, где работают сисадмины, которые обслуживают серверы. В компании около десяти «внутренних заказчиков», которые генерируют идеи по созданию новых продуктов, изменению существующих, предлагают какие-то доработки, связанные с маркетинговой активностью, есть отдел модерации, и так далее. У нас очень много всяких «хотелок».

На тот момент у нас существовало «функциональное» разделение команд. Наши Java-разработчики были выделены в отдельную большую команду, где насчитывалось порядка 20 человек. У них был свой руководитель группы разработки (англ. Team Lead). Верстальщики были выделены в отдельную команду (там было, условно говоря, 10 человек). Тестировщики тоже работали со своим руководителем группы, и так далее. Это все как-то функционировало.

На этом слайде перечислены технологии, которые мы на тот момент использовали. В качестве системы управления задачами у нас применялась JIRA, в качестве Wiki - Confluence (это тоже продукт Atlassian), в качестве системы контроля версий - Subversion. Мы использовали такой подход, как нестабильный trunk и выпуск релизов из веток, которые периодически отделяются от trunk, когда он должен быть стабилизирован.

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

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

Тестирование на тот момент было основным узким местом, из-за которого мы задерживали выпуск функционала.

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

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

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

Естественно, наличие таких проблем никого не устраивало. Мы стали думать, что же делать, как решать эти проблемы. Размышляли над следующими путями решения.

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

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

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

Что в итоге мы выбрали? SCRUM как методологию. Была альтернатива в виде Kanban, но у нас был опыт работы со SCRUM, в каких-то командах он уже применялся. Мы видели, что он нам подходит. Был выбран SCRUM.

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

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

Мы решили мигрировать на GIT в качестве системы контроля версий, потому что GIT более удобен, там разработка ведется в ветках и приходится часто выполнять действие "merge". На самом деле, GIT здесь не является чем-то обязательным для этой технологии. Он просто удобнее, чем Subversion. Мы прочувствовали на себе все его прелести.

Кроме этого, мы выделили руководителей групп во всех функциональных направлениях. У нас есть три функциональных направления: разработка на стороне сервера, frontend и тестирование. За каждым функциональным направлением закреплен свой технический руководитель, который отвечает за методологию, применяемую в этом направлении. Он отвечает за развитие своих сотрудников, их обучение, перемещение между командами, накопление опыта, обмен опытом.

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

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

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

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

На самом деле, это плохо. Это приводит к конфликтам и работает очень плохо. В результате пришлось нанять еще двух человек, решить эту проблему. Все стало значительно лучше.

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

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

Что мы выбрали? На текущий момент все это уже внедрено. Мы решили  сделать обязательную централизованную приемку кода. Она заключается в том, что в службу эксплуатации, которая принимает код и выкладывает его на продакшн, введены автотестеры. Люди, которые пишут функциональные тесты и которые проверяют функционал перед выкладкой, стали подчиняться руководителю службы эксплуатации. Их задача состоит в том, чтобы провести приемочное тестирование.

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

Мы ввели две методики. Одна из них называется «технологический долг», вторая – это наше изобретение – «технологический налог». Я думаю, что технологический долг многие используют. Суть в том, что когда нам все-таки что-то позарез надо, мы это делаем, но при этом мы фиксируем в отдельном бэклоге наш долг, который мы должны исправить. Этот долг закрепляется за той командой, которая его создала. Мы следим, чтобы этот бэклог не рос (а в идеале – постоянно уменьшался и становился нулевым). Понятно, что нулевым он не бывает, поэтому мы следим за тем, чтобы он, как минимум, не рос.

Суть технологического налога в следующем. У нас есть команды, которые отвечают за инфраструктуру. Это так называемые «внутренние команды». Они занимаются развитием общей архитектуры сайта, каким-то глобальным рефакторингом. Эти команды не могут обслуживать весь продукт в целом. Их ресурсов для этого просто недостаточно.

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

Поэтому мы решили ввести такое понятие, как технологический налог. Мы с некоторой периодичностью собираемся и описываем «хотелки» по архитектурным улучшениям. После этого мы распределяем их в конечные команды к заказчикам. Для PM из этой команды эта задача становится в той же степени «родной», как и основная задача от заказчика. За квартал он должен ее выполнить и довести до продакшна.

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

С этой измененной конфигурацией мы уже проработали с середины июля до текущего момента. Она стала намного лучше.

Кроме того, мы изменили систему мотивации. Изначально система мотивации была построена таким образом, что разработчики должны удовлетворить заказчика. Но они могут не думать о качестве кода… То есть, они должны, конечно, об этом думать, но мы не даем им стимула к этому. Нельзя не думать о качестве, не думать еще о каких-то важных вещах типа архитектуры.

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

Мы ввели следующую систему. У нас внутри есть некая структура, которая называется Architecture Board. Это набор людей, которые лучше всех разбираются в работе высоконагруженных систем, в построении правильной архитектуры, в том, как должна вестись разработка, и так далее.

Эта организация собирается с некоторой периодичностью (это должно происходить раз в месяц) и оценивает каждую отдельную команду. Она определяет, насколько хорошо (или плохо) работала команда с точки зрения технологических вещей, ставит оценку.

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

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

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

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

Нам надо дальше работать над повышением качества, потому что качество – это наше все.

У меня все. Я готов поотвечать на вопросы.

Вопросы и ответы

Вопрос из зала: На каком размере команд вы в итоге остановились?

Сергей Никулин: От 5 до 7 человек. По моему опыту, 7 человек – это максимум.

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

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

Вопрос из зала: У вас, наверное, отделены задачи на стороне сервера и на стороне клиента?

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

Вопрос из зала: Немного запутался. Есть команды, и они функционально ориентированы?

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

Вопрос из зала: Но 5-7 человек – получается, это размер третьей команды, которая занимается разработкой на стороне сервера, на стороне клиента?

Сергей Никулин: Команд, которые занимаются исключительно разработкой на стороне сервера, сейчас нет. Они виртуальные. Есть руководитель, отвечающий за разработку на стороне сервера. У него нет людей в непосредственном подчинении. Они рассредоточены в конечных командах продуктов. 

Он просто следит за тем, какая методология используется во всех этих командах. Если в одной команде frontend-разработчики уже применили какую-то JS-библиотеку, то в другой не надо изобретать велосипед и прикручивать другую. Он должен синхронизировать это.

Вопрос из зала: Руководители вынесены за пределы команд?

Сергей Никулин: Функциональные – да. Командные – внутри команды. Это разные роли.

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

Сергей Никулин: Функциональный – вне команды.

Вопрос из зала: Понятно. В команде руководитель группы видит все три направления: разработку на стороне сервера, на стороне клиента и тестирование?

Сергей Никулин: Да.

Вопрос из зала: Хорошо. Я хотел кое-что уточнить. Меня интересует то, что вы называете технологическим налогом. Это фактически задачи, в которых заказчиком является команда разработки. Я правильно понимаю?

Сергей Никулин: Ну, да. Это задачи, для которых заказчиком является Architecture Board. 

Вопрос из зала: Вы не могли бы рассказать подробнее, как вы используете GitHub, GIT, ветки?

Сергей Никулин: Да. Могу рассказать. Мы используем GitHub. HeadHunter сейчас размещен на GitHub. 

У нас есть стабильная ветка master. Когда начинается разработка какого-то нового функционала, команда делает ветку, ответвляет ее от master-ветки и постоянно коммитит туда все изменения. Если это достаточно «долгоживущая» задача (у нас она практически всегда занимает более нескольких дней), то в эту ветку через "merge" добавляются все изменения, которые попадают в master. 

После этого разработка функционала заканчивается. Он проходит тестирование. Тестировщики говорят: «Все отлично. Функционал полностью работает». 

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

Если все нормально, это уходит в релиз и попадает на продакшн. Если нет, это может откатываться. Бывают ситуации, когда и с продакшна откатывается, естественно.

Вопрос из зала: А в master-ветку вы что-то добавляете достаточно часто?

Сергей Никулин: Ежедневно. Мы ежедневно выпускаем один релиз с несколькими возможностями. 

Вопрос из зала: Не возникает проблем, когда какая-то команда долго работает (например, месяц) над какой-то крупной функциональностью, задерживая master? После этого могут быть проблемы у всех остальных, потому что их разработки плохо стыкуются с этим кодом.

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

Реплика из зала: Спасибо.

Реплика из зала:  У меня вопрос про систему мотивации. Насколько я понял, Architecture Board оценивает работу команды и в каком-то виде передает эти данные заказчику. 

Сергей Никулин: Он не передает данные заказчику. Он ставит оценки каждой конечной команде. Эта финальная оценка используется в формуле, исходя из которой рассчитывается общий бонусный фонд команды. Весь вычисленный размер бонусного фонда отдается заказчику.

Вопрос из зала: Понятно. Какие другие параметры есть в этой формуле?

Сергей Никулин: Бонусный фонд делится на две части: 30 % и 70 %. 70 % – это то, что уходит заказчику. Есть еще тридцатипроцентная часть. Она необходима, чтобы люди тратили время на ненужные с их точки зрения вещи. Ненужные с их точки зрения вещи – это, например, списывание времени в JIRA. Мы капитализируем большую часть времени разработчиков. Чтобы этого достичь, нам надо, чтобы были актуальные данные по бэклогам. Если человек всегда вовремя корректно списывает время, он получит этот кусок 30 %. Если нет, то…

Вопрос из зала: Параметр дисциплины, получается. 

Сергей Никулин: Ну, да.

Вопрос из зала: 70 % – это то, как поработала команда с точки зрения Architecture Board, с точки зрения заказчика?

Сергей Никулин: С точки зрения заказчика, да.

Вопрос из зала: Получается, что все это субъективные параметры. С каким-то ленинским прищуром: «Хорошо».

Сергей Никулин: Да, да. На самом деле, не бывает объективных параметров. Это вымысел.

Вопрос из зала: Спасибо.

Вопрос из зала: Насчет Architecture Board. Скажите, как он связан с командами. Нет ли, условно говоря, коррумпированности в них?

Сергей Никулин: Нет, Architecture Board сейчас состоит из следующих людей. Я (технический директор), руководитель службы эксплуатации, руководитель всей разработки в HeadHunter и руководитель всего тестирования в HeadHunter. Из этих людей двое, конечно, находятся в командах (руководитель разработки и руководитель тестирования), но еще двое ни в каких в командах вообще не находятся.

Реплика из зала: Коррупция как минимум наполовину.

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

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

Сергей Никулин: С моей точки зрения, ключевым, точнее, необходимым условием являются технические изменения. Без них это было бы просто невозможно. Например, при старой системе с нестабильным trunk выпускать так много функционала с таким размером команды в принципе невозможно. Это просто уже не работает.

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

Вопрос из зала: Грубо говоря, 50 на 50.

Сергей Никулин: Ну, да. Просто техническая составляющая является блокирующей, без нее невозможна вторая. 

Вопрос из зала: Вопрос про техническую составляющую. Какие еще варианты вы рассматривали? Например, вариант с SVN, но с несколькими промежуточными серверами для тестирования. Или вариант с Bazaar, который интегрируется с SVN. Говорят, он попроще и понадежнее, чем GIT.

Сергей Никулин: Мы рассматривали вариант с тем, чтобы оставить на SVN, но при этом вести разработку в ветках. Это чуть менее удобно. Рассматривали и вариант с Mercurial, но он на текущий момент менее популярен. GIT – это сейчас практически индустриальный стандарт.

Вопрос из зала: Понятно. Спасибо.

Вопрос из зала: Можно пару слов про вашу приемку кода? Как она устроена?

Сергей Никулин: Приемка кода. Первый этап – это приемка внутри команды. Есть тестировщик, который находитс внутри команды. Он проверяет код на соответствие тому, что заказчик хотел изначально.

Следующий этап. Код попадает на автотестирование к команде автотестировщиков. Прогоняются автотесты.

Следующий этап. Если это какая-то большая функциональность, она попадает в службу эксплуатации в виде инструкции по выкладке, где описаны все шаги, которые необходимы. На этом этапе подключается еще и администратор БД (DBA), который проверяет все скрипты. После этого идет выкладка в продакшн.

Вопрос из зала: Автотесты кто пишет?

Сергей Никулин: Автотесты пишут специально выделенные люди. Но мы сейчас проводим эксперимент: начинаем писать автотесты и в командах тоже. Пока рано говорить об успешности или неуспешности этого замысла. 

Автотесты – это функциональные тесты на Selenium. Юнит-тесты, конечно, пишут программисты.

Вопрос из зала: Есть ли какие-то практики, когда код проверяется за пределами команды, которая его написала?

Сергей Никулин: Нет, сейчас нет. Раньше у нас была такая практика, как просмотр кода (англ. code review), она была практически обязательной. Но вследствие того, что команда была огромна, не стоило говорить о том, что это происходит вне команды. Сейчас в некоторых командах тоже есть эта практика, но не во всех. 

Вопрос из зала: Спасибо.

Вопрос из зала: Скажите, пожалуйста, кто у вас принимает решение по поводу, допустим, ввода нового ПО? Что-нибудь типа Redis, и так далее. Кто за это отвечает – эксплуатация или разработка?

Сергей Никулин: Простой ответ: Architecture Board. Здесь надо договориться. Разработчики приходят к нам с идеей, хотят попробовать что-то новое. Ответственные за эксплуатацияю при этом всегда пытаются сказать: «Мы не хотим нового. Нам и так надо поддерживать то, что есть». Здесь все договариваются, исходя из логики, насколько оно нам нужно.

Вопрос из зала: Хорошо. Вы говорили, что 70 % премиальной части – это, грубо говоря, часть заказчика. Правильно?

Сергей Никулин: Да.

Вопрос из зала: Сколько из этих 70 % приходится на те баллы, который Architecture Board оставляет? Это попадает тоже в эту сумму?

Сергей Никулин: Есть общий объем, который рассчитывается, исходя из баллов, которые поставил Architecture Board. После того как мы получили некую цифру X, мы делим ее 70 на 30. Сначала оценка, потом разделение 70 на 30.

Вопрос из зала: Кто в вашей схеме занимается мотивацией разработчиков?

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

Следующий уровень – функциональные руководители. Их задача – чтобы их функциональное направление работало хорошо.

Есть еще более высокий уровень – это я как руководитель всего департамента. 

Вопрос из зала: Какие-то неформальные вещи типа роста сотрудника, выбора направления, в котором он растет, вы практикуете?

Сергей Никулин: Мы стараемся как-то поощрять деятельность людей, которым просто интересно. Некоторые люди в свободное время делают какие-то классные, интересные штуки. Часть этих штук потом попадает в основной код и выпускается. Это приятно, хорошо.

Еще как мотивация – PlayStation 3 с XBox поставили сейчас.

Вопрос из зала: В рабочее время им надо по 6 часов отыграть?

Сергей Никулин: Нет, не надо, но можно.

Вопрос из зала: Футбол между командами. Вы сказали, что отмечаете эти результаты во внерабочее время.

Сергей Никулин: Бонусы.

Вопрос из зала: Бонусы. Есть еще бонусы?

Сергей Никулин: Да.

Вопрос из зала: Как много, как часто? На 30 человек в квартал сколько бонусов?

Сергей Никулин: В течение квартала, наверное, бывает, что 2-3 человека что-то классное сделали.

Вопрос из зала: Понятно. Спасибо.

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

Вопрос из зала: Трех из скольки?

Сергей Никулин: Из шести.

Вопрос из зала: Кто учит?

Сергей Никулин: Учим мы сами.

Вопрос из зала: Architecture Board?

Сергей Никулин: Нет. Наши программисты. Те, кто реально пишет код. Те, кто знает, как оно работает, как должно быть.

Вопрос из зала: То есть вы выделяете время?

Сергей Никулин: Да, да.

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

Сергей Никулин: Если интересно, я могу подробнее рассказать. Устроено это было следующим образом. Была некая программа обучения, основная идея которой была в том, что люди будут заниматься реальным проектом и работать в реальной команде, которая занимается разработкой. Исходя из этого, была построена программа обучения. 

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

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

Вопрос из зала: Следующая школа сколько людей планирует привлечь?

Сергей Никулин: 12. Хотим гораздо больше людей набрать. Сколько возьмем внутрь, пока вопрос открытый. Может быть, 3-х, может быть, 8. Заявок на первый этап, кстати, пришло около тысячи.

Вопрос из зала: Как отбираете?

Сергей Никулин: Там было тестовое задание. Первый этап отбора – проверка тестового задания. Второй – личное собеседование.

Вопрос из зала: Наверное, из тысячи человек сложно отобрать 12. 

Сергей Никулин: Из тысячи на личное собеседование мы позвали 30 или 40, я не помню точно. 

Вопрос из зала: Какая-нибудь оплата бывает?

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

Вопрос из зала: Стипендия какая?

Сергей Никулин: Стипендия сейчас – можно посмотреть, зайти на сайт school.hh.ru. Там будет написано.

Вопрос из зала: Процесс обучения долгий?

Сергей Никулин: Полгода.

Вопрос из зала: Сколько часов примерно?

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

Вопрос из зала: О каких технологиях там рассказывается? Полностью веб-серверы, базы данных, все-все-все?

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

Мы отбирали людей, которые хорошо соображают. У них уже есть какие-то навыки. Они понимают алгоритмы, они знают, как писать на Java, на Python. Но реальный опыт работы с проектом – это самое важное для них.

Вопрос из зала: По вашим ощущениям, окупились ли эти инвестиции?

Сергей Никулин: Да.

Вопрос из зала: Сколько ваши специалисты потратили времени? Грубо – тысяча часов, сто часов...

Сергей Никулин: Сейчас надо прикинуть. 20 недель можно умножить на 5. 100 часов. Порядок такой.

Вопрос из зала: Школа - это сколько человек на выходе и на входе?

Сергей Никулин: У нас было 6 студентов, взяли троих.

Вопрос из зала: То есть вы взяли 6?

Сергей Никулин: 6 человек обучались. Троих из них мы взяли в штат. 

Вопрос из зала: То есть никто в процессе обучения не отсеялся?

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

Вопрос из зала: Спасибо.

Вопрос из зала: Какой был мотив для вас организовывать школу, привлека директоров? Совет HH не мог найти студентов на работу? В чем профит?

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

У нас очень серьезные требования. По моему личному опыту самые продуктивные сотрудники – это те, кто вырос внутри. У нас уже был опыт, когда мы брали людей после института или в процессе обучения. Они росли внутри команды. Из них получаются самые лучшие люди.

Вопрос из зала: Вы решили предварительно их поучить, набрать в команду, чтобы они прошли обучение у вас, чтобы они понимали, как это, и были более адаптированными для работы у вас?

Сергей Никулин: Да. Кстати, мы не единственные это делаем. Практически все крупные игроки так делают. Про Яндекс, наверное, знают абсолютно все. В Mail.Ru есть чем-то похожая программа в Питере, в Москве они тоже некоторую активность развивать начали.

Вопрос из зала: Если совсем формально подходить, за полгода вы взяли троих. Так же и получается – по два месяца на человека. 

Сергей Никулин: Но мы ведь при этом и основной подбор тоже вели. Школа дает результат только в долгосрочной перспективе, конечно.

Комментарии

Нет ни одного комментария

Только пользователи могут оставлять комментарии

Возможно, вам будет интересно:

Антон Немцев

Антон Немцев

Независимый frontend-разработчик c 14-летним стажем, создатель Frontender Magazine, докладчик на WSD, представитель ВСТ в Украине.

Доклад с примерами использования 3D/2D/анимации с помощью CSS для создания эмоционального дизайна.

Юрий Востриков

Юрий Востриков

Один из ведущих разработчиков Mail.Ru.

Юрий Востриков (Mail.Ru) рассказывает о Tarantool/Silverbox - высокопроизводительной базе данных в оперативной памяти.

Георгий Баркан

Георгий Баркан

Руководитель разработки технологической стратегии развития пользовательских продуктов «Лаборатории Касперского».

Рассказ об управлении продуктом с точки зрения успеха этого процесса.