„Универсален“ в екипа за разработка: полза или вреда?

Здравейте всички! Казвам се Людмила Макарова, аз съм мениджър развитие в UBRD и една трета от екипа ми са „генералисти“.

Признайте си: всеки технически ръководител мечтае за многофункционалност в своя екип. Толкова е готино, когато един човек може да замени трима и дори да го направи ефективно, без забавяне на срокове. И което е важно, спестява ресурси!
Звучи много примамливо, но дали наистина е така? Нека се опитаме да го разберем.

Кой е той, нашият предшественик на очакванията?

Терминът „генерален специалист“ обикновено се отнася до членове на екипа, които комбинират повече от една роля, например разработчик-аналитик.

Взаимодействието на екипа и резултатът от неговата работа зависят от професионалните и личните качества на участниците.

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

Има много статии за всички типове личности в ИТ индустрията. Въз основа на моя опит бих разделил ИТ специалистите в четири категории:

1. „Универсален – Всемогъщ“

Такива са навсякъде. Винаги са много активни, искат да бъдат център на вниманието, постоянно питат колегите си дали имат нужда от тяхната помощ, а понякога дори могат да бъдат досадни. Те се интересуват само от смислени задачи, участието в които ще даде поле за творчество и може да забавлява гордостта им.

В какво са силни:

• умеят да решават сложни проблеми;
• потопете се дълбоко в проблема, „копайте“ и постигнете резултати;
• имат любознателен ум.

но:

• емоционално лабилен;
• лошо управлявани;
• имат собствена непоклатима гледна точка, която е много трудна за промяна;
• Трудно е да накараш някого да направи нещо просто. Лесните задачи нараняват егото на всемогъщия.

2. „Универсален – ще го разбера и ще го направя“

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

В какво са силни:

• независим;
• устойчиви на стрес;
• компетентен по много въпроси;
• ерудиран - винаги има за какво да се говори с тях.

но:

• често нарушават задълженията;
• склонни да усложняват всичко: решават таблицата за умножение чрез интегриране по части;
• качеството на работа е ниско, всичко работи 2-3 пъти;
• Те непрекъснато изместват срокове, защото в действителност всичко не се оказва толкова просто.

3. „Универсален – добре, нека аз да го направя, тъй като няма кой друг“

Служителят е добре запознат с няколко области и има подходящ опит. Но не успява да стане професионалист в нито едно от тях, защото често е използван като спасителен пояс, запушващ дупки в текущи задачи. Гъвкав, ефективен, смята себе си за търсен, но не е такъв.

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

В какво са силни:

• отговорен;
• ориентирани към резултат;
• спокоен;
• напълно контролиран.

но:

• показват средни резултати поради ниско ниво на компетенции;
• не може да решава сложни и абстрактни проблеми.

4. „Универсалният е майстор на занаята си“

Човек със сериозен опит като разработчик има системно мислене. Педантичен, взискателен към себе си и екипа си. Всяка задача, свързана с него, може да расте безкрайно, ако границите не са определени.

Той познава добре архитектурата, избира метод на техническо изпълнение, като внимателно анализира влиянието на избраното решение върху настоящата архитектура. Скромен, не амбициозен.

В какво са силни:

• показват високо качество на работа;
• способен да реши всеки проблем;
• много ефикасно.

но:

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

Какво имаме на практика?

Нека видим как най-често се съчетават роли и компетенции. Нека вземем стандартен екип за разработка като отправна точка: PO, мениджър по разработката (технически лидер), анализатори, програмисти, тестери. Няма да вземаме предвид собственика на продукта и техническото ръководство. Първият е поради липса на технически компетенции. Вторият, ако има проблеми в отбора, трябва да може всичко.

Най-често срещаният вариант за комбиниране/сливане/комбиниране на компетенции е разработчик-аналитик. Тестващият анализатор и „три в едно“ също са много разпространени.

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

PO получи спешна задача да въведе нови тарифи в съществуващ продукт. Моят екип има 4 анализатори. По това време единият беше в отпуск, другият беше болен, а останалите бяха ангажирани с изпълнението на стратегически задачи. Ако ги изтегля, това неминуемо ще наруши сроковете за изпълнение. Имаше само един изход: да се използва „тайното оръжие“ - универсален разработчик-аналитик, който овладя необходимата предметна област. Да го наречем Анатоли.

Типът му личност е „универсален – ще го разбера и ще го направя“. Разбира се, той се опитваше дълго време да обясни, че „има пълно изоставане от задачите си“, но по мое волево решение той беше изпратен да реши спешен проблем. И Анатоли го направи! Той извърши постановката и изпълнението в срок, а клиентите останаха доволни.

На пръв поглед всичко се получи. Но след няколко седмици отново възникнаха изисквания за подобряване на този продукт. Сега формулирането на този проблем беше извършено от „чист“ анализатор. На етапа на тестване на новото развитие дълго време не можехме да разберем защо имаме грешки при свързването на нови тарифи и едва тогава, след като разплетехме цялата плетеница, стигнахме до дъното на истината. Загубихме много време и пропуснахме крайни срокове.

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

Имаше и друга ситуация. Сега имаме само един тестер, така че някои задачи трябва да бъдат тествани от анализатори, включително специалисти от общ характер. Затова дадох една задача на условния Федор - „универсален – добре, нека го направя, тъй като няма кой друг“.
Fedor е „три в едно“, но вече е определен разработчик за тази задача. Това означава, че Федя трябваше да комбинира само анализатор и тестер.

Изискванията са събрани, спецификацията е изпратена за разработка, време е за тестване. Федор познава модифицираната система „като своите пръсти“ и е разработил старателно текущите изисквания. Следователно той не се занимаваше с писане на тестови скриптове, а извърши тестване на това „как трябва да работи системата“, след което го предаде на потребителите.
Тестът беше завършен, ревизията отиде в производство. По-късно се оказа, че системата не само е спряла плащанията към определени балансови сметки, но също така е блокирала плащания от много редки вътрешни сметки, които не е трябвало да участват в това.

Това се случи поради факта, че Федор не провери как „системата не трябва да работи“, не състави тестов план или контролни списъци. Той реши да спести време и да разчита на собствените си инстинкти.

Как се справяме с проблемите?

Ситуации като тези оказват влияние върху ефективността на екипа, качеството на издаването и удовлетвореността на клиентите. Следователно те не могат да бъдат оставени без внимание и анализ на причините.

1. За всяка задача, която е причинила затруднения, ви моля да попълните унифициран формуляр: карта на грешките, която ви позволява да идентифицирате етапа, на който е настъпило „усвояването“:

2. След идентифициране на тесните места се провежда мозъчна атака с всеки служител, повлиял на проблема: „Какво да променим?“ (не разглеждаме частни случаи в ретроспекция), в резултат на което се раждат конкретни действия (специфични за всеки тип личност) със срокове.

3. Въведохме правила за взаимодействие в екипа. Например, ние се съгласихме задължително да записваме цялата информация за напредъка на дадена задача в системата за управление на проекти. Когато артефактите се променят/идентифицират по време на процеса на разработка, това трябва да бъде отразено в базата знания и окончателната версия на техническите спецификации.

4. Контролът започна да се извършва на всеки етап (особено внимание се обръща на проблемните етапи в миналото) и автоматично въз основа на резултатите от следващата задача.

5. Ако резултатът на следващата задача не се е променил, тогава не поставям въпросния генералист в ролята, в която се справя зле. Опитвам се да оценя способността и желанието му да развива компетенции в тази роля. Ако не намеря отговор, го оставям в ролята, която му е по-близка.

Какво стана накрая?

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

Данни

Общите служители имат своите плюсове и минуси.

Предимства:

• можете да затворите провиснала задача по всяко време или да разрешите спешна грешка за кратко време;
• интегриран подход за решаване на проблем: изпълнителят го разглежда от гледна точка на всички роли;
• генералистите могат да правят почти всичко еднакво добре.

Недостатъци:

• BUS факторът се увеличава;
• основните компетенции, присъщи на ролята, са ерозирани. Поради това качеството на работа намалява;
• вероятността от изместване на сроковете се увеличава, защото няма контрол на всеки етап. Съществуват и рискове от израстването на „звезда“: служителят е уверен, че знае по-добре, че е професионалист;
• рискът от професионално прегаряне се увеличава;
• много важна информация за проекта може да остане само „в главата“ на служителя.

Както можете да видите, има повече недостатъци. Затова използвам генералисти само ако няма достатъчно ресурси и задачата е доста спешна. Или човек има компетенции, които липсват на другите, но качеството е заложено.

Ако при съвместна работа по дадена задача се спазва правилото за разпределение на ролите, то качеството на работата се повишава. Гледаме на проблемите от различни ъгли, погледът ни не е замъглен, винаги се появяват свежи мисли. В същото време всеки член на екипа има всички възможности за професионално израстване и разширяване на своите компетенции.

Смятам, че най-важното е да се чувстваш съпричастен в процеса, да си вършиш работата, като постепенно увеличаваш широчината на своите компетенции. Въпреки това генералистите в екип носят ползи: основното е да се гарантира, че те ефективно комбинират различни роли.

Пожелавам на всички самоорганизиращ се екип от „универсални майстори на занаята”!

Източник: www.habr.com