de er maksimalister. De fors\u00f8ger at g\u00f8re alt korrekt, hvilket forl\u00e6nger udviklingstiderne. <\/li>\n<\/ul>\n<\/p>\n
Hvad har vi i praksis? <\/h2>\n \nLad os se, hvordan roller og kompetencer ofte kombineres. Vi tager udgangspunkt i et standard udviklingsteam: PO, udviklingsleder (techlead), analytikere, programm\u00f8rer, testere. Vi vil ikke tage produktlederen og techleaden med. Den f\u00f8rste \u2013 p\u00e5 grund af manglende tekniske kompetencer. Den anden, hvis der er problemer i teamet, skal netop kunne g\u00f8re det hele.<\/p>\n
Den mest almindelige variant af at kombinere\/fusionere\/samle kompetencer er udvikler-analytikeren. Analytik-testeren og \"tre i \u00e9n\" ses ogs\u00e5 meget ofte.<\/p>\n
Ved at tage udgangspunkt i mit eget team vil jeg vise fordele og ulemper ved de alsidige kollegaer. En tredjedel af mit team best\u00e5r af dem, og jeg holder meget af dem. <\/p>\n
Fra PO kom der en hastesag om at implementere nye tariff\u00e9r i det eksisterende produkt. I mit team er der 4 analytikere. P\u00e5 det tidspunkt var en p\u00e5 ferie, en anden var syg, og de \u00f8vrige arbejdede med strategiske opgaver. Hvis jeg havde trukket dem ud, ville det uundg\u00e5eligt have forsinket implementeringen. Der var kun \u00e9n l\u00f8sning: at bruge \"det hemmelige v\u00e5ben\" - den alsidige udvikler-analytiker, som kendte det n\u00f8dvendige fagomr\u00e5de. Lad os kalde ham Anatolij. <\/p>\n
Hans personlighedstype er \"alsidig - jeg finder ud af det og g\u00f8r det\"<\/b>. Selvf\u00f8lgelig pr\u00f8vede han l\u00e6nge at forklare, at han havde \"en fuld backlog af sine opgaver\", men mit bestemmende valg sendte ham til at l\u00f8se den hastesag. Og Anatolij klarede det! Han satte opgaven og udf\u00f8rte implementeringen til tiden, og kunderne var tilfredse. <\/p>\n
Ved f\u00f8rste \u00f8jekast lykkedes det hele. Men efter et par uger opstod der igen krav om forbedringer til dette produkt. Nu var det en \"ren\" analytiker, der arbejdede med opgaven. P\u00e5 teststadiet af den nye udvikling kunne vi l\u00e6nge ikke forst\u00e5, hvorfor der opstod fejl ved tilknytningen af de nye tarif\u00e9r, og f\u00f8rst senere, efter at have afd\u00e6kket hele knuden, n\u00e5ede vi sandheden. Vi brugte en masse tid og forsinkede tidsplanen.<\/p>\n
Problemet var, at mange skjulte detaljer og faldgruber kun var i hovedet p\u00e5 vores alsidige og ikke var blevet nedskrevet. Som Anatolij senere forklarede, havde han skyndt sig for meget. Men det mest sandsynlige scenario er, at han m\u00f8dte problemer allerede under udviklingen og blot undveg dem uden at notere noget. <\/p>\n
Der var ogs\u00e5 en anden situation. Nu har vi kun \u00e9n tester, s\u00e5 nogle opgaver m\u00e5 analyserne, inklusive de alsidige, teste. Derfor gav jeg \u00e9n opgave til den hypotetiske Fedja - \"alsidige - fint, lad mig g\u00f8re det, da der ikke er andre\"<\/b>.
Kravene er indsamlet, specifikationen er sendt til udvikling, og det er tid til at teste. Fjodor kender det forbedrede system \u00absom sin egen lomme\u00bb og har grundigt gennemg\u00e5et de aktuelle krav. Derfor tog han ikke besv\u00e6ret med at skrive testscenarier, men udf\u00f8rte testningen p\u00e5, hvordan \u00absystemet b\u00f8r fungere\u00bb, og derefter \u2013 overgav det til brugerne.
Dette skete, fordi Fjodor ikke udf\u00f8rte en kontrol af, hvordan \u00absystemet ikke skal fungere\u00bb, og han udarbejdede ikke en testplan eller tjeklister. Han besluttede at spare tid og stolede p\u00e5 sin egen mavefornemmelse. <\/p>\n
Hvordan arbejder vi med problemer? <\/h2>\n \nS\u00e5danne situationer p\u00e5virker teamets effektivitet, kvaliteten af de frigivne versioner og kundetilfredsheden. Derfor kan de ikke ignoreres og skal analyseres n\u00e6rmere.<\/p>\n
1.<\/b> For hver opgave, der har givet problemer, beder jeg om at udfylde en standardformular: fejlkortet, som g\u00f8r det muligt at identificere det trin, hvor der opstod et \u00abfald\u00bb:<\/p>\n
2.<\/b> Efter identifikationen af flaskehalse gennemf\u00f8res der en brainstorm med hver medarbejder, der har p\u00e5virket problemet, \u00abHvad skal \u00e6ndres?\u00bb (vi ser ikke p\u00e5 specifikke tilf\u00e6lde under retro), hvorefter der skabes konkrete handlinger (for hver personlighedstype sine) med tidsfrister.<\/p>\n
3.<\/b> Vi har indf\u00f8rt regler for interaktion internt i teamet. For eksempel har vi aftalt at registrere al information om opgavens fremdrift i projektstyringssystemet. Ved \u00e6ndringer\/identifikation af artefakter i udviklingsprocessen skal dette vises i vidensbasen og den endelige version af kravspecifikationen.<\/p>\n
4.<\/b> Kontrollen er blevet udf\u00f8rt p\u00e5 hvert trin (s\u00e6rlig opm\u00e6rksomhed gives til problematiske trin fra fortiden) og automatisk p\u00e5 baggrund af resultaterne af den n\u00e6ste opgave.<\/p>\n
5.<\/b> Hvis resultatet af den n\u00e6ste opgave ikke er \u00e6ndret, placerer jeg ikke den p\u00e5g\u00e6ldende universelle medarbejder i den rolle, som han har sv\u00e6rt ved. Jeg pr\u00f8ver at vurdere hans evne og vilje til at udvikle kompetencer i denne rolle. Hvis jeg ikke finder nogen respons, lader jeg ham forblive i den rolle, der passer ham bedst.<\/p>\nHvad blev resultatet? <\/h2>\n
\nUdviklingsprocessen er blevet mere gennemsigtig. BUS-faktoren er blevet reduceret. Teammedlemmer, der arbejder p\u00e5 fejl, bliver mere motiverede og forbedrer deres karma. Vi h\u00e6ver gradvist kvaliteten af vores udgivelser. <\/p>\n
Konklusioner <\/h2>\n \nMangefacetterede medarbejdere har deres fordele og ulemper.<\/p>\n
Fordele:<\/b><\/p>\n\nDet er muligt at lukke en h\u00e6ngende opgave p\u00e5 ethvert tidspunkt eller l\u00f8se en presserende fejl hurtigt;<\/li>\n En helhedsorienteret tilgang til at l\u00f8se opgaven: den udf\u00f8rende ser p\u00e5 den fra alle roller;<\/li>\n Mangefacetterede medarbejdere kan praktisk talt g\u00f8re alt lige godt. <\/li>\n<\/ul>\n\nUlemper:<\/b><\/p>\n\nBUS-faktoren stiger;<\/li>\n de prim\u00e6re kompetencer, der h\u00f8rer til en rolle, bliver udvandet. Dette reducerer kvaliteten af arbejdet;<\/li>\n der er st\u00f8rre risiko for tidsforskydninger, da der mangler kontrol ved hver fase. Der opst\u00e5r ogs\u00e5 risici for at skabe en 'stjerne': medarbejderen er sikker p\u00e5, at han ved bedre og er ekspert; <\/li>\n risikoen for professionelt udbr\u00e6ndthed \u00f8ges;<\/li>\n mange vigtige oplysninger om projektet kan forblive kun 'i hovedet' p\u00e5 medarbejderen. <\/li>\n<\/ul>\n\nSom du kan se, er der flere ulemper. Derfor bruger jeg kun mangefacetterede medarbejdere, n\u00e5r ressourcerne er knappe, og opgaven er tilstr\u00e6kkeligt hastende. Eller personen har kompetencer, som de andre ikke har, og kvaliteten st\u00e5r p\u00e5 spil.<\/p>\n
Hvis der i det f\u00e6lles arbejde med opgaven overholdes reglen om rollefordeling, s\u00e5 stiger kvaliteten af arbejdet. Vi ser p\u00e5 problemerne fra forskellige vinkler, synet bliver ikke sl\u00f8ret, og der dukker altid friske tanker op. Samtidig har hver deltager i teamet alle muligheder for professionel v\u00e6kst og udvidelse af deres kompetencer. <\/p>\n
Jeg mener, at det vigtigste er at f\u00f8le sin tilknytning til processen, at besk\u00e6ftige sig med sit arbejde og gradvist udvide sine kompetencer. Ikke desto mindre bringer mangefacetterede medarbejdere v\u00e6rdi til teamet: det vigtigste er at f\u00e5 dem til effektivt at kombinere forskellige roller. <\/p>\n
Jeg \u00f8nsker alle selvorganiserende team af 'mangefacetterede mestre i deres fag'!<\/i>habr.com<\/a><\/p>","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"excerpt":{"rendered":"\u0412\u0441\u0435\u043c \u043f\u0440\u0438\u0432\u0435\u0442! \u041c\u0435\u043d\u044f \u0437\u043e\u0432\u0443\u0442 \u041b\u044e\u0434\u043c\u0438\u043b\u0430 \u041c\u0430\u043a\u0430\u0440\u043e\u0432\u0430, \u044f \u043c\u0435\u043d\u0435\u0434\u0436\u0435\u0440 \u0440\u0430\u0437\u0440\u0430\u0431\u043e\u0442\u043a\u0438 \u0432 \u0423\u0411\u0420\u0438\u0420 \u0438 \u0442\u0440\u0435\u0442\u044c \u043c\u043e\u0435\u0439 \u043a\u043e\u043c\u0430\u043d\u0434\u044b \u2013 \u00ab\u0443\u043d\u0438\u0432\u0435\u0440\u0441\u0430\u043b\u044b\u00bb. \u041f\u0440\u0438\u0437\u043d\u0430\u0439\u0442\u0435: \u043a\u0430\u0436\u0434\u044b\u0439 Tech Lead \u043c\u0435\u0447\u0442\u0430\u0435\u0442 \u043e \u043a\u0440\u043e\u0441\u0441-\u0444\u0443\u043d\u043a\u0446\u0438\u043e\u043d\u0430\u043b\u044c\u043d\u043e\u0441\u0442\u0438 \u0432\u043d\u0443\u0442\u0440\u0438 \u0441\u0432\u043e\u0435\u0439 \u043a\u043e\u043c\u0430\u043d\u0434\u044b. \u0412\u0435\u0434\u044c \u044d\u0442\u043e \u0442\u0430\u043a \u043a\u0440\u0443\u0442\u043e, \u043a\u043e\u0433\u0434\u0430 \u043e\u0434\u0438\u043d \u0447\u0435\u043b\u043e\u0432\u0435\u043a \u0441\u043f\u043e\u0441\u043e\u0431\u0435\u043d \u0437\u0430\u043c\u0435\u043d\u0438\u0442\u044c \u0442\u0440\u0435\u0445, \u0434\u0430 \u0435\u0449\u0435 \u0438 \u0441\u0434\u0435\u043b\u0430\u0442\u044c \u044d\u0442\u043e \u043a\u0430\u0447\u0435\u0441\u0442\u0432\u0435\u043d\u043d\u043e, \u043d\u0435 \u0441\u0434\u0432\u0438\u0433\u0430\u044f \u0441\u0440\u043e\u043a\u0438. \u0418, \u0447\u0442\u043e \u043d\u0435\u043c\u0430\u043b\u043e\u0432\u0430\u0436\u043d\u043e, \u044d\u0442\u043e \u043e\u0431\u0435\u0441\u043f\u0435\u0447\u0438\u0432\u0430\u0435\u0442 \u044d\u043a\u043e\u043d\u043e\u043c\u0438\u044e \u0440\u0435\u0441\u0443\u0440\u0441\u043e\u0432! \u0417\u0432\u0443\u0447\u0438\u0442 \u043e\u0447\u0435\u043d\u044c […]<\/p>\n","protected":false,"gt_translate_keys":[{"key":"rendered","format":"html"}]},"author":1,"featured_media":27224,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[688],"tags":[],"class_list":["post-36379","post","type-post","status-publish","format-standard","has-post-thumbnail","hentry","category-administrirovanie"],"aioseo_notices":[],"aioseo_head":"\n\t\t\n\t
![\"\u00abUniversal\u00bb](\"\/wp-content\/uploads\/2019\/07\/a25639788762e858c731714cdd701c3e.jpg\")