Здравейте на всички! Аз съм Людмила Макарава, мениджър по разработката в УБРиР и една трета от моя екип са "универсали".
Признайте: всеки 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
