Как стать автором
Обновить

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

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

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

не быть сеньору помидором

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


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

Простите, что?
старший сеньор разработчик за свою карьеру не научился себя мотивировать, развивать себя, решать проблемы (это вообще капец), находить с бизнесом общий язык, планировать много дел?
Что это за инфантильный старший разработчик, он вообще чему-либо научился, или в вашем абстрактном представлении сеньор-разработчик это просто тот, который дочитал документацию до конца?
>не научился себя мотивировать
Ну, мотивировать себя и других — это все же две большие разницы. Хотя многие другие из этих тем все же должны входить в обязательную программу синьора.
вот и я о чем. Без мотивации нормальным сеньором стать практически нереально. Особенно таким, которого хотят сделать тимлидом. То есть человек уже на практике пережил довольно продолжительную карьеру, где неоднократно приходилось брать себя в руки и мотивировать на дальнейшее развитие.
Это — ценный опыт и знания, которые не получишь на курсах или в универе.
Видится, что позицию старшего программиста девальвировали раза в 2. Зачастую, разработчика повышают авансом на позицию синьора, это как способ мотивации, так и удержания в компании. Или же, приходится повышать заработную плату, но запрашиваемый оклад находится в другой вилке, и нужно повышать грейд. И не повышать оклад/грейд, бизнес не может, так как на рынке есть компании, которые готовы и платить больше, и лычку синьора давать.
Все противоречия снимаются если разделить роли тимлида и техлида. Тимлид это главный менеджер команды (уж насколько я не люблю слово менеджер но вынужден признать). Его задача состоит в том чтобы быть буфером между бюрократическим щитштормом и разработчиками и давать разрабам спокойно заниматься своим делом, а также в том чтобы нарезать задачи команде в соответствии с потребностями/задачами компании, следить за их выполнением и решать проблемы команды когда они возникают. Техлид же — человек который решает технические вопросы которые возникают у команды в процессе выполнения задач. Т.е техлид — самый крутой разраб. Тимлид — человек который оркестрирует техлида и команду.
Собственно все что я написал выше — личный опыт сеньора ставшего тимлидом.

Аналогичное видение. Проработав в качестве тимлида в 3 компаниях, вернулся обратно в техлидерство, и дело не столько в значительно возросшей нагрузке (когда архитектурирование некому делегировать, а количество обязанностей по пипл+таск-менеджменту и общению с бизнесом начинает зашкаливать), сколько в совмещении двух плохо сочетаемых областей — кодерской и менеджерской. Видел компании, в которых сделано грамотно, и техлид и тимлид разные люди, но в большинстве контор все-таки ради экономии пытаются совмещать, что приводит к выгоранию.


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

Зарегистрируйтесь на Хабре, чтобы оставить комментарий

Публикации

Изменить настройки темы

Истории