Изискванията и критериите за оценка на ръководителите на екипи не са толкова добре описани, както за повечето позиции в ИТ сектора. В тази статия ще се опитам да систематизирам това, което показва опитът ми, и да отговоря на следните въпроси:
- Какво е Team Lead?
- По какво се различава ръководителят на екип от ръководителя на технологии?
- Какви са основните изисквания към ръководителя на екипи?
- Как трябва да се оценява работата му?
- Кариерно израстване
Кой е ръководител на екип?
„Ръководителят на екип“ или наложилият се международен термин “Team Lead” в ИТ сферата е ръководителят на екипа за софтуерната разработка. За клиентите ръководителят на екипа е ключово техническо лице и нещо като входяща точка за обсъждане на технически проблеми. За самия екип тийм лидерът е човек, който взима технически решения и носи съответната отговорност за тях. Но това не е всичко. Изграждането на екипа и атмосферата в екипа също е грижа на ръководителя на екипа.
Team Lead и Technical Lead — едно и също ли е това?
Не точно. Няма конкретни насоки за това къде свършва едната позиция и къде започва другата. Казано иначе, ръководителите на екипи и техническите ръководители не са едно и също нещо, но и не се разграничават толкова лесно. Рядко е в един и същи проект да има едновременно PM (проектен мениджър), ръководител на екип, технически лидер, софтуерен архитект и бизнес анализатор. В проекти, където всички те съществуват, най-вероятно трима от тези петима могат да свършат цялата лидерска работа, стига да успеят да се справят с голямото натоварване.
Проектният мениджър обикновено е по-ангажиран с процесите, бюджетите и хората в екипа. Той често изпълнява ролята на Scrum master при съответните срещи.
Ако проектът има отделен технически ръководител, то той би следвало да отговаря за техническите решения.
Тийм лидерът от своя страна е някъде по средата между тях. В същото време той трябва да е достатъчно добър инженер, способен да отговори на всеки технически въпрос (независимо дали от страна на клиента или на екипа). Но ръководителят на екипа се нуждае както от добро познаване на методологиите за развитие, така и от добре развити меки умения, за да действа като Scrum master и да представлява екипа на различни срещи с клиенти. Най-често тийм лидерът изпълнява и ролята на технически лидер, въпреки че съм виждал екипи, в които това са различни хора.
Аз самият съм бил тийм лидер в подобна конфигурация само веднъж. Техническият лидер беше един много добър Javа специалист, с когото се работеше изключително ефективно. Предпочиташе да получава възможно най-трудните задачи и не обичаше никой да го безпокои, докато работи. Не вземах никакви технически решения без него и той всъщност не общуваше с клиенти. Но се придържахме към правилото, че ако трябваше да се направи труден избор, техническият ръководител съветваше и настояваше, но винаги оставяше окончателното решение на мен. Неговото мислене беше нещо като "ти си отговорен, така че сам вземаш решението".
Изисквания към ръководителя на екип
Сега нека поговорим по-подробно какво точно трябва да прави тийм лидерът и защо той или тя няма време за писане на код.
Работата на ръководителя на екипа се основава на четири стълба:
- Компетенции на технически лидер
- Умения за управление на процеси
- Комуникация с клиенти и управление на акаунти
- Комуникация с екипа и управление на хора
Компетенции на технически лидер
Повече от ясно е, че трябва да сте достатъчно добър програмист, за да можете да намирате технически решения. Дори ако има отделен технически лидер в проекта, трябва да сте достатъчно добре запознати с писането на код, за да помогнете на екипа и да отговорите на въпросите на клиентите. Следователно, ръководителят на екипа винаги участва в прегледа на кода. Често процесът е конфигуриран така, че да не можете да обедините заявка за изтегляне без одобрение от ръководителя на екипа, дори ако целият екип вече я е разгледал.
За авторитета на тийм лидера също е важно да има добри технически компетенции. Той трябва да може да замести всеки един от разработчиците и да свърши техническата част от работата си не по-зле от тях. Когато това е факт, екипът ще гледа с по-голяма доверие на тийм лидера и ще приема по-лесно гледната му точка, отколкото ако той е просто теоретик, който не пише код.
Аз самият станах точно такъв теоретик, когато напуснах позицията на ръководител на екипа, за да стана софтуерен архитект.
Писах много на Java преди версия 7 и знам много неща, пробвал съм ги и ги оценявам. Но не навлязох в тях в необходимата дълбочина. Бях обект на шеги от страна на екипа няколко пъти, защото предлагах дълги парчета код, когато днес можете просто да напишете три реда със същия ефект. Оттогава винаги, когато предлагам решения, се опитвам да опиша самия алгоритъм, а не това как да го приложа.
Управление и процеси
Ръководителят на екипа не винаги е Scrum master, но трябва да е готов да замени Scrum master-а по всяко време. Той участва във всички процеси от жизнения цикъл на спринта и Scrum церемонията (който не си спомня петте scrum церемонии, трябва да потърси в Google още сега). Следователно, трябва да разберете теорията зад основните методологии за разработка. Днес това са различни Agile производни. Трябва да знаете как да прилагате тези методики, защото екипът не може да оцелее само с PM.
Тийм лидерът, заедно с PM-а, изграждат процес, който е удобен както за екипа, така и за клиента (дори ако процесът първоначално е наложен от клиента, той може да бъде пригоден впоследствие). Освен това тийм лидерът не само учи екипа как да работи с този процес, но и трябва да се увери, че клиентът се придържа към него. Мисля, че много хора познават усещането, когато малко след определяне на обхвата на спринта, клиентът започва да изисква в него да бъдат вмъкнати още няколко много важни задачи. За предпочитане е да не изхвърляте нищо от спринта.
Комуникация с клиенти и управление на акаунти
Ръководителят на екипа комуникира с клиента постоянно — всеки ден по няколко пъти. Участва в техническите дискусии и в обсъждането на изискванията. Той би следвало да насърчава успеха на екипа, да съобщава за проблеми и да разрешава всякакви конфликти и недоразумения. Освен това тийм лидерът трябва да умее да наложи мотото: „Ние не просто пишем код по цял ден, но и разбираме бизнес нуждите на клиента и отговаряме на тях адекватно. И можем да го направим по начин, който е напълно различен от това, което клиентът е очаквал”.
Ръководителят на екипа не спира да преговаря с клиента, докато той не разбере точно от какво се нуждае, когато всичко е казано и направено. Разработчикът не започва да пише никакъв код, докато не е наясно дали наистина клиентът се нуждае от съответната функция. Ако видим, че клиентът пропуска нещо, ние не мълчим: трябва да информираме както клиента, така и нашия екип за управление на акаунти относно това. Не защото ще продадем повече от нашите услуги и ще спечелим повече пари (въпреки че това също е важно), а защото клиентът ще е доволен и ще ни благодари по-късно.
Прекарахме няколко месеца, опитвайки се да убедим Product Owner-а, че в проекта е необходима система за наблюдение в реално време. По-конкретно - система за мониторинг на бизнеса, където наред с броя на грешките ще се виждат и графики за дневните продажби. По-късно отидохме при тях в командировка и нашето табло беше показано на големия екран на стената на офиса, така че всички служители да могат да видят как вървят нещата.
В същото време, когато работи с клиента, тийм лидерът трябва да умее да защитава интересите и позициите на своя екип. И тук отново следва важен рефрен на съвременния аутсорсинг: „Ние не просто пишем висококачествен код по цял ден, но и разбираме бизнес нуждите на клиента и ги задоволяваме“. Ако клиентът не може да се придържа към собствените си ангажименти, ръководителят на екипа и PM-а трябва да поемат тежестта от това, но не и екипът.
Например, ако клиентът започне ежедневно обсъждане на възможна промяна на обхвата на проекта, по-добре е екипът да не бъде намесван. Същото важи и за изясняване на изискванията на задача, по която вече се работи, или други подобни неща, които променят договорените планове. Голямото количество междинни резултати не само изнервя разработчиците, но и им пречи да се концентрират.
Комуникация с екипа и управление на хора
Може би ключово задължение на тийм лидера, което отнема и по-голямата част от времето му, е да се грижи за екипа.
По отношение на техническата работа е ясно: ако екипът не е съставен само от Senior разработчици, тогава ще трябва да се отделя по-специално внимание на тези, които са Middle и Junior, ако не разбират нещо или не успяват да се справят.
Но тук има едно важно правило: само екип от приятели работи наистина добре заедно. Екип, в който хората се шегуват, забавляват се и си помагат, в който те са на една и съща вълна и винаги са честни един с друг, е много по-успешен. Основната задача на тийм лидера е изграждането именно на такъв екип и поддържането на приятелска атмосфера в него. Всички аспекти на изграждането на екип попадат директно върху плещите на ръководителя на екипа - от избора на хора до провеждането на разговори и дори до това да се съберат всички заедно и да разпуснат след работа. Тийм лидерът е ангажиран и с провеждането на интервюта с нови членове на екипа, с отсяването на неподходящи хора (което е неприятно, но понякога е необходимо), с налагането на ориентираната към клиента култура на работа в екип и дори с утешителни разговори с неуверените Junior разработчици, които в крайна сметка ще се превърнат в опитни специалисти след време.
И тук не бива да забравяме и още едно важно нещо – култивирането на здравословна конкуренция. Когато екипът се разраства и развива, някои Senior специалисти, че дори и Middle, ще започнат да демонстрират лидерски качества. Такива хора трябва да бъдат стимулирани, като им се делегира изпълнението на отделни функции под тяхна пълна отговорност. В крайна сметка в тяхно лице може да се появи нов лидер на екипа, който да заеме вашето място. Може да звучи изненадващо, но когато аз напуснах позицията си на ръководител на екип, за да стана архитект, екипът беше оглавен от човек, който дойде при нас като Junior две години по-рано. Сега с него отново работим по един и същ проект, където той е PM. А други двама колеги от този славен екип се преместиха в проекти, където също заемат лидерски позиции.
Ако екипът е достатъчно голям и се вземат предвид всички отговорности, изброени по-горе, ръководителят на екипа наистина няма време да пише код. Вероятно по навик все още ще си дава задачи, свързани с програмиране, но едва ли ще може да свърши всичко, а това води до напрежение и извънредни часове труд през уикенда. И в крайна сметка ще се наложи да делегира тези задачи на друг човек от екипа. Всичко това е нормално. Плашещо е да спрете да пишете код, но опитът показва, че ако е необходимо, можете да възстановите предишната си форма само след няколко месеца.
Как да оценим ръководителя на екип
Доста трудно е да се изготвят подробни критерии за оценка на тийм лидерите, тъй като тяхната ефективност е силно зависима от т. нар. “Soft skills”. По време на оценяването обикновено задавам няколко въпроса по основните теми, изброени по-горе, обхващащи теория и типични ситуации. Обикновено въз основа на тези отговори става ясно колко обигран и опитен е колегата в управлението на екипи.
- Технически лидерски умения. Пропускаме тази част, тъй като това не е техническо интервю.
- Управление и процеси. Основна Agile теория и въпроси за това как се прилага.
Например:
- Разликата между Scrum и Kanban.
- Scrum церемонии. Кои са видовете и кои използвате? Ако не всички от тях са приложими, защо?
- Story points. Защо са необходими? Използвате ли ги? Ако не, защо?
- Капацитет и скорост. Какво представляват и за какво служат? Как се свързват помежду си? Използвате ли ги? Ако не го правите, как изобщо планирате?
- Как да не пропуснете с вашите оценки?
- Как бихте реагирали на опитите на клиентите да вложат непланирана работа в спринта?
- Комуникация с клиенти (управление на акаунт).
Как да се държим, ако:
- Клиентът не разполага с достатъчно ресурси, но наистина има нужда да се разработи нещо.
- Направихме сериозна грешка и клиентът знае за това.
- Направихме сериозна грешка, но клиентът все още не знае за това.
- Клиентът се опитва да прилага микромениджмънт спрямо нашите разработчици.
- Мениджмънтът на клиента е променен.
- Не сме съгласни с техническите изисквания на клиента.
- Комуникация с екипа (управление на хора).
Как да се държим, ако:
- Човек от екипа се държи пасивно-агресивно.
- Отказва да изпълни безинтересна задача.
- В екипа идва нов колега, чийто начин на общуване стресира всички останали.
- Един от членовете на екипа изобщо не притежава твърди умения.
- Опитвате се „да разчупите леда“, но разговорите в екипа все още звучат официално и скучно. Какво може да се направи?
Кариерно израстване – какво следва?
Може би липсата на критерии и ясно дефинирани насоки се дължи на факта, че самата позиция на мениджъра на екипа е междинна стъпка. Вие вече сте специалисти в ролята си на разработчик и можете да направите повече. Вашите меки умения ви позволяват да достигнете ново ниво на взаимодействие с клиентите, но все още не е ясно накъде точно да растете. След като сте били ръководител на екип вече няколко години, т.е. все още сте инженер, но с голямо количество организационна работа, е време да разбирате дали искате:
- да се задълбочете в организационните дейности, като същевременно се отдалечите от техническите (пътят на PM);
- да се откажете се от управлението и просто да напишете готин код, като помолите всички да ви безпокоят по-малко (пътят на технически експерт или SME);
- да вършите по-малко организационна работа и да се потопите по-дълбоко в техническа дейност, но на високо ниво без код или почти без код (пътят на техническия архитект, известен още като системен архитект);
- да вършите по-малко организационна работа, с по-малко код — само с архитектура на високо ниво и много разговори с клиенти за изясняване на изискванията и координиране на подходите (пътят на solution архитект);
- да не променяте нищо (пътят да се наслаждавате на нещата точно такива, каквито са, което също е напълно приемливо)!
