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

За полтора года, что Максим работает тимлидом, он накопил немало опыта. “У меня есть время, чтобы программировать, и, значит, я управляю командой хорошо”, - шутит он. В этой статье Максим делится советами и лайфхаками - как балансировать между задачами тимлида и программиста, решать конфликты, планировать свое время и управлять командой.



Планка в 50%
Я разработчик до мозга костей. Все, что не относится к разработке проекта, кажется мне чужеродным, все это отнимает то время, когда я мог бы создавать продукты. Но тимлид - это больший масштаб: больше проектов, больше требований к ним и их качеству, собственная команда, опыт в управлении проектом, развитие. Ради этого приходится перераспределять силы и время.

Я определил для себя планку в 50%: половину времени занимают обязанности тимлида, половину - задачи разработчика. 50% - это искусственное ограничение: если бы я не ограничивал себя, то тратил бы больше. В команду можно вкладываться бесконечно, можно отдавать все 100% времени, но это негативно скажется на итоговом продукте, а затем и на моих коллегах.

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



Распределение задач и разумные эксперименты
В моей команде каждый человек отвечает за 1-2 проекта - работает над ними и общается с менеджерами. Я стараюсь по мере сил участвовать во всех этапах разработки всех проектов, начиная от сбора требований и заканчивая эксплуатацией.

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

Что касается методологии разработки - мы применяем нечто среднее между scrum и XP (экстремальное программирование). В отличие от экстремального программирования мы пишем тесты после собственно разработки и только для самого важного функционала. В отличие от scrum у нас небольшая команда из 5 человек. В целом мы работаем недельными итерациями, стараемся разбирать задачи внутри команды на специальных встречах и раз в квартал меняемся направлениями разработки (к примеру, другой проект либо другой функционал) - это свежий взгляд и обмен опытом.

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

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

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

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

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

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

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

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

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

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

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

Распределение времени
Чтобы быть эффективным, нужно постоянно заниматься планированием.
У меня есть текстовый файл, заменитель таск-трекера, куда мне удобно записывать все свои задания - учеба, работа, все прочее. Это эффективно и универсально: записывая задачи, я не отвлекаюсь от разработки. Файл с заданиями лежит в Dropbox и автоматически расшаривается с ноутбука на смартфон и другие устройства.

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

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