Кто такой техлид и почему он нужен команде

Менеджер vs тимлид: распределение ответственности

Андрей Рыжкин

Часто ли вы сталкиваетесь с тем, что тимлид и менеджер играют в «пинг-понг», стремясь перекинуть выполнение задачи друг на друга? А бывает так, что кто-то берет на себя лишнюю ответственность и делает чужую работу в ущерб своим основным обязанностям? Приходится спорить по вопросу «кто должен это делать?» или находить компромисс, чтобы задача двигалась к результату? Роль тимлида отличается от компании к компании и единых стандартов не существует. В AGIMA позиция «тимлид» существует более пяти лет и является ключевой для бизнеса. Но за это время мы набили много шишек, пока не определили, какие обязанности должны быть у тимлида. Сегодня у нас работают более тридцати тимлидов и более ста разработчиков, примерно столько же менеджеров. В таком большом коллективе контролировать каждого невозможно, поэтому чрезвычайно важным становится наличие системы коммуникации. В своем докладе я хочу рассказать, как мы решали возникающие проблемы и помочь тем, кто столкнулся (или скоро столкнется) с трудностями, решить их за счет нашего опыта, а не собственных ошибок. В частности, поговорим о следующем: — кто за что отвечает: распределение ответственности между менеджером и тимлидом; — как должна выглядеть эффективная коммуникация между тимлидом и менеджером: правильные и неправильные вопросы; — как исключить перебрасывание задачами внутри команды; — «Сначала я на тебе поезжу, а потом ты меня покатаешь»: как сделать так, чтобы каждый занимался только своей работой; —jira-workflow в AGIMA как пример эффективного взаимодействия «менеджер-тимлид-другие роли»; — «побочная» работа, которую все равно нужно делать: как тимлид должен планировать свое время.

Планы

Изначально, когда я ещё только начал задумываться о смене работы, я хотел уехать на Кипр, потому что ждал от него солнца (стереотипы про Питер совсем не стереотипы), спокойствия, хорошей зарплаты, интересных вызовов и отсутствия стрессов.

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

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

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

Ну то есть всего того, что мы ждём от прекрасного далёко.

Уровень 5. Флоу разработки, больше ответственности. Рост до сеньора и тимлида

У плат­фор­мы, над кото­рой мы рабо­та­ли, мик­ро­сер­вис­ная архи­тек­ту­ра. Это зна­чит, что для раз­ных частей бизнес-логики был свой отдель­ный сер­вис. Напри­мер, сер­вис, кото­рый хра­нит инфор­ма­цию о кур­сах, или сер­вис, кото­рый рабо­та­ет с плат­ны­ми про­дук­та­ми. Всё это обща­ет­ся меж­ду собой и с фрон­том через REST API. Но из-за осо­бен­но­сти интер­фей­са исполь­зо­вать REST было не очень удобно.

Напри­мер, нам нуж­но пока­зать поль­зо­ва­те­лю кар­точ­ку видео­кур­са. Назва­ние и опи­са­ние лежат в одном мик­ро­сер­ви­се. Инфор­ма­ция об авто­ре в дру­гом. Рей­тинг — в тре­тьем. Дан­ные о том, доба­вил ли поль­зо­ва­тель курс себе в избран­ное, — в чет­вёр­том. Плат­ный ли курс — в пятом. То есть, что­бы отоб­ра­зить кар­точ­ку одно­го мате­ри­а­ла, нуж­но сде­лать мно­го запро­сов. А у нас раз­ные фор­ма­ты мате­ри­а­лов, кар­то­чек и несколь­ко плат­форм, кар­точ­ки на кото­рых отличаются.

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

Я про­дол­жал осва­и­вать тех­но­ло­гии, в том чис­ле GraphQL, redux-saga, react native. К тому же глу­бо­ко погру­зил­ся в про­дукт, сво­и­ми рука­ми потро­гал уже почти все моду­ли плат­фор­мы. Это помо­га­ло общать­ся с биз­не­сом и под­дер­жи­вать дру­гих раз­ра­бот­чи­ков: я пони­мал воз­мож­но­сти и огра­ни­че­ния систе­мы, видел пути, кото­ры­ми луч­ше решать задачи.

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

Напри­мер, вме­сте с одним бэкенд-разработчиком я пол­но­стью отве­чал за инте­гра­цию Apple Pay. Или была такая зада­ча: нуж­но было под­клю­чить к плат­фор­ме связ­ку с дру­гим про­дук­том — сер­ви­сом, на кото­ром пред­при­ни­ма­те­ли могут най­ти мен­то­ра или экс­пер­та. Я сам дого­ва­ри­вал­ся с раз­ра­бот­чи­ка­ми дру­гой ком­па­нии, как им нуж­но дора­бо­тать мето­ды, как и какие дан­ные мы будем отправлять.

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

Проблемы со списками задач

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

Чтобы навести порядок, я начал договариваться с каждым человеком в команде перейти обратно в общий трекер и не забивать на статусы. От себя я пообещал, что за 2-6 недель наведу порядок в трекере. А для того, чтобы история поехала, ввёл несколько правил. Во-первых, разработчик берёт в работу самую первую задачу из списка. Не надо смотреть на приоритеты, на северити, читать комментарии или что-то спрашивать. Если задача вверху, значит её нужно делать. Тем самым мне удалось уменьшить нагрузку на ребят, избавив их от трат времени по выяснению, что нужно делать. Во-вторых, я снял ответственность за то, что была сделана ненужная задача. Т.е. если ненужная задача оказалась вверху списка, то виноват в этом лид, т.е. я. Без каких-либо оговорок.

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

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

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

Налаживание системы разработки и поставки кода

На тот момент у нас было несколько проектов, которые разрабатывались довольно хаотично:

• где-то на бою был мастер, где-то другая ветка
• где-то были тестовые площадки, где-то нет
• а если и были, то адреса у всех разные
• гит в принципе использовался слабо и со скрипом
• изменения в базы данных вносились вручную
• …

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

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

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

Система заключается в следующем:

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

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

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

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

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

Заведите личные карточки

План развития.

• что должен уметь сотрудник к определённому моменту времени;
• с какими задачами он должен справляться и на каком уровне;
• какие области ответственности должен закрывать.

1. Первый аргумент против карточек высказывал я сам: до определённого момента я думал, что буду держать всё в голове, потому что я же тимлид, я могу! Но количество навыков, планов развития и областей ответственности росло вместе с размером команды. Уровень ответственности слишком высок, чтобы полагаться только на свои память и интуицию. Поэтому я завёл карточки. 
2. «Это слишком сложно!». Ответ на это очень простой: не надо усложнять! Не стоит перечислять 100500 навыков и расписывать план развития каждого сотрудника на 25 страниц. Оставьте только те сведения, которые реально необходимы. 
3. «Ведение карточек занимает слишком много времени». Я решил проверить этот тезис на себе. Разумеется, с секундомером не сидел, но у меня получилось что-то около часа в месяц на всю команду из пяти человек.
4. «Невозможно формализовать рост людей». Да, невозможно формально описать развитие человека — это многогранный и очень непростой процесс. И карточки — это как раз то, что помогает мне подходить к нему чуть более осознанно. Ещё раз: именно помогает, а не заменяет собой всю работу. 

Как построить работу DevOps 24/7?

Борис Ершов

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

А именно:- как передавать задачи между сменами так, чтобы инженерам не нужно было гадать, какие задачи и с какого места им нужно подхватить;- какие рабочие графики для 24/7 мы перепробовали и к чему в итоге пришли, чтобы решить проблемы выгорания ночных инженеров, не допускать их отрыва от команды и избегать текучки кадров;- как выстроить алгоритм приоритизации задач, когда в стеке более 100 активных проектов, чтобы в каждый конкретный момент времени инженеры понимали, какие задачи и по каким проектам важные и срочные;- как организовать удобную систему нотификаций, чтобы свести к минимуму информационный шум и каждый участник получал только релевантные для него уведомления.И самое важное — люди. 24/7 — график дико неудобный

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

Пополнение штата, интеграция в команду

Практически изначально было понятно, что людей катастрофически не хватает (я сам полный рабочий день писал код, но мы всё равно не успевали).

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

Тут очень повезло, что у меня был (и есть) друг фронт, который в то же самое время начал подумывать уйти с фриланса, поэтому мы смогли быстро заткнуть вакансию, а я получил премию за приведение сотрудника (ещё один плюс начальству, до этого не видел hr-премии).

Почти сразу же после фронта нашлись 2 бека. И где-то в это же время ушёл джун (чей код меня выбешивал ещё несколько месяцев после его ухода).

Итого в разработке сложилась следующая ситуация:

• один “старичок”
• я
• трое абсолютных новичков
• работа ещё не налажена
• часть знаний уже потеряна

Закономерно, что на меня, как на тимлида, сразу посыпались десятки вопросов от новичков. В основном это были вопросы по жизненному циклу кода (где писать код, как показывать, куда его отправлять потом, как собирать релиз), по ведению задач (как брать задачи в работу, как показывать статус, как определять приоритеты) и по работе с гитом. Плюс ребята ещё пытались задавать вопросы “Как работает А?”, “Есть ли у нас на сайте В?”, но практически всё в тот момент сводилось лишь к необходимости изучать код.

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

Здесь же стоит сказать пару слов о процессе найма в нашу фирму, которая работает до сих пор.

Процесс найма

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

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

Задачу на самом деле может решить и джун за пару вечеров, объёмной её делает большая свобода в реализации, улучшениях и напрашивающихся фишках. Именно эта гибкость реализации помогает нам оценить уровень соискателя. Мы сразу говорим, что самое главное для нас это лишь уложиться в сроки решения задачи (называет сам исполнитель) и в конце показать рабочий код в репозитории. Мы не оговариваем использование каких-либо подходов и технологий, их выбирает сам исполнитель, но чтобы пойти на встречу и дать подсказки, мы перечислили возможные улучшения списком, как задания со звёздочкой, например, работа через аякс, доп. валидация на бэке, защита от спама, оформление в виде модуля, использование D7, …

Итого:

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

По данным портала ЗАЧЕСТНЫЙБИЗНЕСОБЩЕСТВО С ОГРАНИЧЕННОЙ ОТВЕТСТВЕННОСТЬЮ «ЛИДЕР ТИМ ПРО»По данным портала ЗАЧЕСТНЫЙБИЗНЕС9710011109

О компании:
ООО «ЛИДЕР ТИМ ПРО» ИНН 9710011109, ОГРН 1167746422909 зарегистрировано 27.04.2016 в регионе Москва по адресу: 127106, г Москва, проезд Нововладыкинский, дом 8 СТРОЕНИЕ 5, ОФИС 012. Статус: Действующее. Размер Уставного Капитала 1 000 000,00 руб.

Руководителем организации является: Генеральный Директор — Жиделев Николай Андреевич, ИНН . У организации 1 Учредитель. Основным направлением деятельности является «деятельность по предоставлению прочих вспомогательных услуг для бизнеса, не включенная в другие группировки». На 01.01.2020 в ООО «ЛИДЕР ТИМ ПРО» числится 988 сотрудников.

Рейтинг организации:
Средний
  подробнее

ВНИМАНИЕ: для оценки рисков работы с данной организацией рекомендуем отчет

Должная осмотрительность ?

Статус: ?
Действующее

Дата регистрации: По данным портала ЗАЧЕСТНЫЙБИЗНЕС

?
По данным портала ЗАЧЕСТНЫЙБИЗНЕС

27.04.2016

Среднесписочная численность работников: ?
01.01.2020 – 988 ↓ -285 (1273 на 01.01.2019 г.)
Фонд оплаты труда / Средняя заработная плата Доступно в Премиум Доступе ?
Среднемесячная заработная плата в организации ниже среднемесячной заработной платы в регионе Москва. Подробнее…Размещенные вакансии

ОГРН  ?	1167746422909    присвоен: 27.04.2016
ИНН  ?	9710011109
КПП  ?	771501001
ОКПО  ?	02227222
ОКТМО  ?	45359000000

Реквизиты для договора 
?
 …Скачать

Проверить блокировку cчетов 
?

Контактная информация +7(9… Посмотреть
?

Отзывы об организации 
?: 0   Написать отзыв

Юридический адрес: ?
По данным портала ЗАЧЕСТНЫЙБИЗНЕС
127106, г Москва, проезд Нововладыкинский, дом 8 СТРОЕНИЕ 5, ОФИС 012
получен 13.04.2020
зарегистрировано по данному адресу:
По данным портала ЗАЧЕСТНЫЙБИЗНЕС

По данным портала ЗАЧЕСТНЫЙБИЗНЕС
Руководитель Юридического Лица ?По данным портала ЗАЧЕСТНЫЙБИЗНЕС
Генеральный ДиректорПо данным портала ЗАЧЕСТНЫЙБИЗНЕС

Жиделев Николай Андреевич

ИНН ?	По данным портала ЗАЧЕСТНЫЙБИЗНЕС
действует с	По данным портала ЗАЧЕСТНЫЙБИЗНЕС 05.03.2019

Учредители ? ()
Уставный капитал: По данным портала ЗАЧЕСТНЫЙБИЗНЕС
1 000 000,00 руб.

100%	По данным портала ЗАЧЕСТНЫЙБИЗНЕС По данным портала ЗАЧЕСТНЫЙБИЗНЕС КЛАУДНАЙН ЛИМИТЕД По данным портала ЗАЧЕСТНЫЙБИЗНЕС 1 000 000,00руб., 07.09.2017

Основной вид деятельности: ?По данным портала ЗАЧЕСТНЫЙБИЗНЕС
82.99 деятельность по предоставлению прочих вспомогательных услуг для бизнеса, не включенная в другие группировки

Дополнительные виды деятельности:

Единый Реестр Проверок (Ген. Прокуратуры РФ) ?

Реестр недобросовестных поставщиков: ?
По данным портала ЗАЧЕСТНЫЙБИЗНЕС

не числится.

Налоговый орган ?
По данным портала ЗАЧЕСТНЫЙБИЗНЕС
Инспекция Федеральной Налоговой Службы № 15 По Г. Москве
Дата постановки на учет: По данным портала ЗАЧЕСТНЫЙБИЗНЕС
17.03.2020

Регистрация во внебюджетных фондах

Фонд	Рег. номер	Дата регистрации
ПФР  ?	087309030633	По данным портала ЗАЧЕСТНЫЙБИЗНЕС 14.04.2020
ФСС  ?	770604931177061	По данным портала ЗАЧЕСТНЫЙБИЗНЕС 28.04.2016

Уплаченные страховые взносы за 2019 год (По данным ФНС):

— на обязательное социальное страхование на случай временной нетрудоспособности и в связи с материнством: 14 452,62 руб. ↓ -0.19 млн. (206 350,85 руб. за 2018 г.)

Коды статистики

ОКАТО  ?	45280574000
ОКОГУ  ?	4210011
ОКОПФ  ?	12300
ОКФС  ?	23

Финансовая отчетность ООО «ЛИДЕР ТИМ ПРО» ?

 ?

Финансовый анализ отчетности за 2019 год
Коэффициент текущей ликвидности:

1
Коэффициент капитализации:

25.6
Рентабельность продаж (ROS):
Подробный анализ…

В качестве Поставщика: , на сумму

В качестве Заказчика: , на сумму

По данным портала ЗАЧЕСТНЫЙБИЗНЕС

Судебные дела ООО «ЛИДЕР ТИМ ПРО» ?

найдено по ИНН: По данным портала ЗАЧЕСТНЫЙБИЗНЕС

Истец: По данным портала ЗАЧЕСТНЫЙБИЗНЕС , на сумму: 680 246,00 руб.

найдено по наименованию (возможны совпадения): По данным портала ЗАЧЕСТНЫЙБИЗНЕС

По данным портала ЗАЧЕСТНЫЙБИЗНЕС

Исполнительные производства ООО «ЛИДЕР ТИМ ПРО»
?

найдено по наименованию и адресу (возможны совпадения): По данным портала ЗАЧЕСТНЫЙБИЗНЕС

По данным портала ЗАЧЕСТНЫЙБИЗНЕС

Лента изменений ООО «ЛИДЕР ТИМ ПРО»
?

Не является участником проекта ЗАЧЕСТНЫЙБИЗНЕС ?

Больше информации об организации — в Премиум доступе

Удержание сотрудников: метрики и инструменты для управления эффективностью и удовлетворённостью

Ольга Проходская

Этот доклад будет не про то, как можно удержать сотрудников, которые приходят к вам с оффером от другой компании. Удерживать, конечно, можно и нужно. Для этого есть масса вариантов. Но “тушить пожар” — это всегда дороже, чем проактивно предупреждать его с помощью грамотного people management.В своем докладе я расскажу про то, как мы в Wargaming Platform собираем данные об эмоциональном состоянии сотрудников, а именно как определить:- мотивационный статус (и что это такое),- уровень стресса, — степень удовлетворенности, — риск ухода, — риск профессионального выгорания, — эффект от ухода.Мы поговорим о том, как WG Platform начинает переходить к ongoing performance review process, и как мы работаем в направлении развития талантов. Я хочу дать тимлидам конкретные инструменты для проведения 1:1 митингов, оценки потенциала к развитию, предложить простые метрики и примеры вопросов, которые помогут получить от сотрудника информацию, верно ее проанализировать и принять своевременные решения.

ЛИДЕР ТИМ, АУТСОРСИНГ

город Воронеж

     

В других странах: kzua

Leader Team

Компания «Leader Team» — Уже более 10 лет, успешно выполняет различные работы по продвижению товаров и услуг для наших партнеров – лидирующих компаний на российском рынке. Мы являемся крупнейшим прямым работодателем на территории Российской Федерации. У нас открыты более тысячи предложений по работе, что позволяет практически каждому соискателю найти себе подходящую вакансию, стабильный заработок, удобный график и любимую работу. Более 20 000 человек доверили нам свое время и работают сейчас в нашей компании. Устроившись в нашу компанию, Вы получите не только хороший опыт работы, но и достойную оплату труда. Сеть офисов в России: Москва, Санкт-Петербург, Екатеринбург, Самара, Ростов-на-Дону, Новосибирск,   Казань, Нижний Новгород, Иваново и многие другие. Наши партнеры: «X5 Retail Group», «Вимм-Билль-Данн», «Zara», «Доширак», «ВТБ 24», «КампоМос», «Майский чай», «Спар», «Сбербанк», «Реал», «Мегафон», «Europe Foods GB», «Микоян», «Теремок», «Нарзан», «Большевичка».

Не забывайте, что самую подробную информацию об организации Leader Team в Воронежe вы всегда можете получить на официальном сайте, в офисе компании или позвонив по телефону ↓

Что надо понять

Вам платят деньги не за то, что вы пишите код

Умение писать код и понимать его — по-прежнему важно для TL, он оценивает и продумывает архитектуру и т.д. Но у вас всего две руки, а у команды их явно больше

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

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

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

Ваши главные показатели эффективности — качество всего проекта и время разработки. Здесь, пожалуй, главную роль играют ваши навыки коммуникабельности. Что-то надо делать качественно и долго, а иной раз целесообразнее быстрое решение. Сложность состоит в том, что вы должны донести это до программиста и убедить его сделать, как нужно в этот момент. А не через 2 дня обнаружить, что он только на середине, а готовое решение нужно сейчас.

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

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

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

Вы не можете выбирать технологии, какие хотите. Обычный разработчик может предлагать новые технологии, а задача TL — поддерживать баланс стека технологий проекта. Помните, стабильность проекта и процесса разработки — ваша обязанность. Что делать, если из команды уходит единственный хранитель какой-то особенной технологии? Кроме того, использование каждой технологии должно быть обосновано. Я периодически наблюдал как полтора земплекопа в крохотном проекте всё пилят на микросервисах. Они не догадывались, что компания не была готова к этому. Конечно, ни к чему хорошему такие эксперименты не приводили.

Вы палочка-выручалочка в любом аврале. В любых нештатных ситуациях вы не можете просто рявкнуть на команду: «Всё должно быть сделано!» и уйти. Сидеть до ночи должны именно вы. Нельзя бросать разработчиков с проблемой один на один. Это плохой пример для них, ответственность в таких случаях лежит именно на TL. Но и держать всю команду на аварийных работах тоже нет смысла. Я сам несколько раз возвращался домой в 5 утра, а на следующий день приезжал к 9 утра на совещание. Вообще, ваша работа в том, чтобы до такого не доводить.

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

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