Здравейте на всички! Казвам се Людмила Макарова, мениджър по разработки в УБРиР, и третата част от моя екип е «универсали».
Признайте: всеки Tech Lead мечтае за крос-функционалност в своя екип. Наистина е впечатляващо, когато един човек може да замести трима и то качествено, без да отлага сроковете. И, което е особено важно, това осигурява икономия на ресурси!
Звучи много примамливо, но наистина ли е така? Нека да разгледаме по-подробно.
Кой е нашият предвещател на очакванията?
Под термина «универсал» обикновено се разбират члены на екипа, които съчетават повече от една роля, например, разработчик-аналитик.
Взаимодействието в екипа и резултатите от работата му зависят от професионалните и личностните качества на участниците.
По hard skills всичко е ясно, но soft skills заслужават специално внимание. Те помагат да се намери подход към служителя и да се насочи точно към задачата, в която той ще бъде най-полезен.
Съществуват много статии за всички видове личности в IT индустрията. Основавайки се на опита си, бих разделила IT универсалите на четири категории:
1. «Универсал – всемогъщият»
Такива хора ги има навсякъде. Те винаги проявяват голяма активност, искат да бъдат в центъра на вниманието, постоянно питат колегите дали им е необходима помощ, понякога дори могат да дразнят. Те се интересуват само от значими задачи, участие в които ще даде простор за творчество и ще подхрани самочувствието им.
В какво са силни:
- способни са да решават сложни задачи;
- задълбочават се в проблема, «копаят» и постигат резултат;
- обладават любознателен ум.
Но:
- емоционално лабилни;
- слабо управляеми;
- имат своя непоклатима позиция, която е много трудна за промяна;
- трудно е да се накарат да направят простичка задача. Леките задачи засягат самочувствието на всемогъщите.
2. «Универсал – ще разбера и ще направя»
На тези хора им трябва само ръководство и малко време – и те ще разрешат въпроса. Обикновено те имат голям опит като DevOps. Такива универсали не се затрудняват с проектиране и предпочитат да използват метод на разработка, основаващ се единствено на собствения им опит. Могат без проблем да спорят с техлида относно избрания вариант за реализиране на задачата.
В какво са силни:
- самостоятелни;
- устойчиви на стрес;
- компетентни в много въпроси;
- ерудиранти – винаги има с какво да се говори.
Но:
- често нарушават ангажиментите;
- склонни са да усложняват всичко: решават таблицата на умножение чрез интегриране по части;
- качеството на работа е ниско, всичко се получава от 2-3 пъти;
- постоянно отлагат сроковете, защото всъщност всичко се оказва не толкова просто.
3. „Универсал – добре, давай, аз ще го направя, тъй като няма друг“
Служителят разбира добре в няколко области и има съответния опит. Но не му се удава да стане професионалист в нито една от тях, защото често го използват като спасителна опора, запълвайки дупките по текущите задачи. Податлив, изпълнителен, счита себе си за търсен, но такава не е.
Практически идеален служител. Най-вероятно има направление, което му харесва повече, но поради размитите компетенции развитие не се случва. В резултат на това човекът рискува да стане ненужен и емоционално изгорен.
В какво са силни:
- отговорни;
- насочени към резултата;
- спокойни;
- напълно контролируеми.
Но:
- показват среден резултат поради ниското ниво на компетенции;
- не могат да решават сложни и абстрактни задачи.
4. „Универсал – майстор на своето дело“
Човек с сериозен бекграунд на разработчик, притежава системно мислене. Педантичен, изискващ към себе си и екипа. Всяка задача с негово участие може да се разтегне до безкрайност, ако не се определят граници.
Добре познава архитектурата, избира метода на техническата реализация, внимателно анализирайки влиянието на избраното решение върху текущата архитектура. Скромен, не амбициозен.
В какво са силни:
- показват високо качество на работа;
- способни са да решат всяка задача;
- много работоспособни.
Но:
- нетърпими към мнението на другите;
- максималисти. Стремят се всичко да направят правилно, а това увеличава сроковете за разработка.
Какво имаме на практика?
Нека видим как в повечето случаи се комбинират роли и компетенции. За отправна точка ще вземем стандартния екип за разработка: PO, мениджър на разработка (техлид), анализатори, програмисти, тестери. Собственика на продукта и техлида няма да ги броим. Първият – поради липса на технически компетенции. Вторият, ако в екипа има проблеми, просто трябва да може да прави всичко.
Най-широко разпространеният вариант за съчетаване на умения е разработчик-аналитик. Също така много често се срещат аналитик-тестировчик и "три в едно".
На примера на своя екип ще покажа какви са предимствата и недостатъците на универсалите. В моя екип те са една трета и много ги обичам.
От PO дойде спешна задача за внедряване на нови тарифи в съществуващия продукт. В моя екип има 4 аналитика. По това време един беше в отпуск, другият беше болен, а останалите се занимаваха с реализирането на стратегически задачи. Ако ги бях изтеглила, това неизбежно щеше да провали сроковете. Останал единственият вариант: да използвам "тайното оръжие" – универсалния разработчик-аналитик, който владееше необходимата предметна област. Нека го наречем Анатолий.
Неговият тип личност е "универсал – ще се справя и ще го направя". Разбира се, той дълго се опитваше да обясни, че има "пълен беклог на задачите си", но с моето волево решение беше изпратен да реши спешната задача. И Анатолий се справи! Той проведе формулирането и изпълни реализацията в срок, а клиентите останаха доволни.
На пръв поглед всичко се получи. Но след няколко седмици по този продукт отново възникнаха изисквания за доработка. Сега формулирането на тази задача беше поето от "чист" аналитик. На етапа на тестване на новата разработка дълго не можехме да разберем защо получаваме грешки при свързването на новите тарифи, едва след това, след като разплетохме целия клубок, достигнахме до истината. Изразходвахме куп време и провалихме сроковете.
Проблемът се заключаваше в това, че много скрити моменти и подводни камъни останаха само в главата на нашия универсал и не бяха прехвърлени на хартия. Както по-късно обясни Анатолий, той се е опитал твърде бързо. Но най-вероятно е, че е попаднал на проблеми вече при разработването и просто ги е заобиколил, без никъде да го отрази.
Имаше и друга ситуация. Сега имаме само един тестировчик, затова някои задачи трябва да се тестват от аналитиците, включително – универсалите. Затова една задача дадох на условния Фьодор – "универсал – добре, давайте, аз, щом няма повече никой".
Фьодор е "три в едно", но за тази задача вече беше определен разработчик. Значи, Фьодор трябваше да съчетае в себе си само аналитика и тестировчика.
Изискванията са събрани, спецификацията е предадена за разработка, време е за тестиране. Фьодор познава усъвършенстваната система „като собствените си пет пръста“ и подробно е проработил текущите изисквания. Затова не се затрудни с написването на тестови сценарии, а проведе тестове за това „как системата трябва да работи“, след което – предаде на потребителите.
Тестът приключи, подобренията бяха пуснати в продукция. По-късно се разбра, че системата не само спира обработката на плащания по определени балансови сметки, но и блокира плащанията от много редки вътрешни сметки, които не трябваше да участват в това.
Това се случи, защото Фьодор не направи проверка за това как „не трябва да работи системата“, не изготви тест план или контролни списъци. Той реши да спести време и се довери на собственото си усет.
Как работим с проблемите?
Подобни ситуации влияят на ефективността на екипа, качеството на издадените версии и удовлетвореността на клиентите. Затова не бива да се оставят без внимание и анализ на причините.
1. По всяка задача, която е предизвикала трудности, моля да се попълни унифицирана форма: карта на грешките, която позволява да се установи етапа, на който е възникнала „проблемът“:
2. След идентифициране на тесните места, с всеки служител, повлиял на проблема, се провежда мозъчна атака „Какво да променим?“ (не разглеждаме частни случаи на ретро), в резултат на което се раждат конкретни действия (за всеки тип личност свои) със срокове.
3. Въведохме правилата за взаимодействие в рамките на екипа. Например, се договорихме да записваме цялата информация за хода на задачата в системата за управление на проекти. При промяна/идентифициране на артефакти в процеса на разработка, е необходимо да се отрази това в базата знания и в окончателната версия на ТЗ.
4. Контролът започна да се извършва на всеки етап (особено внимание се обърна на проблемните етапи в миналото) и автоматично по резултатите от изпълнението на следващата задача.
5. Ако резултатът от следващата задача не се е променил, не поставям разглеждания универсал в ролята, с която справя лошо. Стремя се да оценя способността и желанието му да развива компетенции в тази роля. Ако не открия отзив, оставям го в ролята, която му е по-близка.
Какво в крайна сметка се получи?
Процесът на разработка стана по-прозрачен. BUS-факторът намаля. Членовете на екипа, работейки върху грешките, стават по-мотивирани и подобряват своята карма. Постепенно повишаваме качеството на нашите версии.
Изводи
Работниците-универсали имат своите плюсове и минуси.
Предимства:
- може по всяко време да се затвори висяща задача или да се разреши спешен бъг в кратки срокове;
- комплексен подход при решаването на задача: изпълнителят я разглежда от всички роли;
- универсалите могат практически всичко да правят еднакво добре.
Недостатъци:
- нараства BUS-факторът;
- размиват се основните компетенции, характерни за ролята. Поради това се намалява качеството на работа;
- повишава се вероятността от забавяне на сроковете, тъй като липсва контрол в всеки етап. Също така възникват рискове от отглеждане на "звезда": служителят е уверен, че знае по-добре, че е професионалист;
- увеличава се рискът от професионално изгаряне;
- много важна информация за проекта може да остане само "в главата" на служителя.
Както виждате, недостатъците са повече. Затова използвам универсали само в случай, че няма достатъчно ресурси и задачата е достатъчно спешна. Или човекът притежава компетенции, които другите нямат, а качеството е на линия.
Ако в съвместната работа по задачата се спазва правилото за разпределение на ролите, качеството на работата нараства. На проблемите гледаме от различни ъгли, погледът не увисва, винаги се появяват свежи идеи. В същото време всеки член на екипа има всички възможности за професионален растеж и разширяване на своите компетенции.
Смятам, че най-важното е да се усеща своята принадлежност към процеса, да се занимаваш със своята работа, постепенно увеличавайки широчината на своите компетенции. Въпреки това, универсалите в екипа носят полза: важно е да се направи така, че те ефективно да съчетават различни роли.
Пожелавам на всем самоорганизиращия се екип на "универсалите-майстори на своето дело"!
Източник: habr.com
