Ўсім прывітанне! Мяне клічуць Людміла Макарава, я менеджэр распрацоўкі ва УБРиР і траціна маёй каманды - «універсалы».
Прызнайце: кожны 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