Organisering av arbetsprocessen i teamet på IT-projektet

Hej vänner. Jag ser ofta samma mönster, särskilt inom outsourcing. Bristen på en tydlig arbetsprocess i team på olika projekt.

Det viktigaste är att programmerarna inte förstår hur man ska kommunicera med kunden och varandra. Hur man bygger en kontinuerlig utvecklingsprocess av kvalitetsprodukter. Hur man planerar sin arbetsdag och sina sprintar.

Allt detta leder i slutändan till missade deadlines, övertid, ständiga konflikter om vem som är skyldig och missnöje bland kunderna – vart och hur allt går. Ganska ofta leder detta till att programmerare, och ibland hela team, byts ut. Förlust av kunder, sämre rykte och så vidare.

Under en tid hamnade jag på ett sådant projekt där alla dessa problem fanns.

Ingen ville ta ansvar för projektet (ett stort tjänstmärkte marketplace), omsättningen var skrämmande, och kunden var väldigt otålig. CEOn kom över och sa till mig att jag hade rätt erfarenhet, så nu har du chansen. Ta projektet om du vill. Misslyckas du, stänger vi projektet och sparkar alla. Lyckas du, så blir det fantastiskt, och du får leda och utveckla det som du anser nödvändigt. Tillslut blev jag teamledare för projektet och allt låg på mina axlar.

Det första jag gjorde var att utveckla en arbetsprocess från grunden, som motsvarade min vision då, och jag skrev en arbetsbeskrivning för teamet. Att implementera detta var inte lätt. Men efter ungefär en månad var allt på plats, utvecklarna och kunden vänjde sig, och allt blev lugnt och bekvämt. För att visa teamet att detta inte bara var en "storm i ett vattenglas", utan en verklig lösning på situationen, tog jag på mig den största delen av ansvaret och avlastade teamet från jobbiga rutiner.

Det har nu gått ett och ett halvt år, och projektet utvecklas utan övertid, utan "råttkapplöpning" och med minskad stress. Någon i det gamla teamet ville inte jobba så här och lämnade, medan andra verkligen uppskattade de transparenta reglerna. Men i slutändan är alla i teamet mycket motiverade och har full förståelse för det stora projektet, både frontend och backend. Vi har en djup förståelse för hela kodbasen och all affärslogik. Vi har till och med kommit till den punkt där vi inte bara är " paddlare", utan själva kommer på många affärsprocesser och nya funktioner som verket verkligen uppskattat.

Tack vare vår metod har kunden valt att beställa ytterligare en marknadsplats från vårt företag, vilket glädjer oss.

Eftersom det fungerar för mitt projekt kan det kanske också hjälpa någon annan. Så här såg processen ut som hjälpte oss att rädda projektet:

Teamets arbete i projektet 'Mitt favoritprojekt'

a) Inom teamprocessen (mellan utvecklarna)

• Alla uppgifter skapas i Jira-systemet
• Varje uppgift ska beskrivas så utförligt som möjligt och utföra enbart en åtgärd
• Om en funktion är tillräckligt komplex delas den upp i flera små tasks
• Teamet arbetar med funktionerna som en enda uppgift. Först gör vi tillsammans en funktion, skickar den för testning, och därefter tar vi nästa.
• Varje uppgift märks, antingen för backend eller frontend
• Det finns olika typer av uppgifter och buggar. De måste anges korrekt.
• Efter att uppgiften har slutförts omvandlas den till statusen kodgranskning (samtidigt skapas en pull request till sin kollega)
• Den som utförde uppgiften spårar omedelbart sin tid för denna uppgift
• Efter kodgranskningen godkänns PR och därefter merges uppgiften av den som utförde det in i mastergrenen, och de ändrar statusen till redo för deployment på dev server.
• Alla uppgifter som är klara för deployment på dev-servern deployas av teamledaren (hans ansvarsområde), ibland av ett teammedlem om det är något brådskande. Efter deployment övergår alla uppgifter från redo för deployment på dev till status - redo för testning på dev
• Alla uppgifter testas av kunden
• När kunden har testat uppgiften på dev överförs den till statusen redo för deployment på prod
• För deployment på prod har vi en separat gren där vi merges master endast före deployment
• Om kunden hittar buggar under testningen återför han uppgiften för revidering och sätter statusen återförd för revidering. På så sätt separerar vi nya uppgifter från de som inte passerade testningen
• I slutändan passerar alla uppgifter från skapande till avslut: To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
• Varje utvecklare testar sin egen kod självständigt, inklusive som användare av webbplatsen. Ingen merge av grenen med huvudgrenen tillåts om det inte är helt säkert att koden fungerar.
• Varje uppgift har sina prioriteringar. Prioriteringarna fastställs antingen av beställaren eller teamledaren.
• Utvecklare utför först och främst de prioriterade uppgifterna.
• Utvecklare kan tilldela uppgifter till varandra om olika buggar har hittats i systemet eller om en uppgift består av arbete från flera specialister.
• Alla uppgifter som beställaren skapar går till teamledaren, som bedömer dem och antingen ber beställaren att justera dem eller tilldelar dem till en av teammedlemmarna.
• Alla uppgifter som är klara för deployment till dev eller prod går även till teamledaren, som själv avgör när och hur deploy ska göras. Efter varje deployment måste teamledaren (eller en teammedlem) informera beställaren om detta. Dessutom måste de ändra status för uppgifter till redo för testning på dev/prod.
• Varje dag på samma tid (för oss är det kl. 12.00) håller vi ett möte mellan alla teammedlemmar.
• Var och en rapporterar på mötet, inklusive teamledaren, vad han gjorde igår, vad han planerar att göra idag. Vad som inte fungerar och varför. På så sätt är hela teamet medvetet om vem som gör vad och i vilket skede projektet befinner sig. Detta ger oss möjlighet att förutsäga och justera våra uppskattningar och deadlines om det behövs.
• På mötet meddelar teamledaren även om alla förändringar i projektet och nivån av aktuella buggar som inte har hittats av beställaren. Alla buggar utreds och tilldelas varje teammedlem för att åtgärdas.
• På mötet tilldelar teamledaren uppgifter till varje individ, med hänsyn till de nuvarande arbetsbelastningarna för utvecklarna, deras yrkesskicklighet samt med hänsyn till hur nära en viss uppgift är det som utvecklaren för tillfället arbetar med.
• På mötet utvecklar teamledaren en övergripande strategi för arkitektur och affärslogik. Efter detta diskuterar hela teamet det och fattar beslut om att göra justeringar eller godkänna den aktuella strategin.
• Varje utvecklare skriver kod och bygger algoritmer självständigt inom en gemensam arkitektur och affärslogik. Varje person kan uttrycka sin vision av genomförandet, men ingen tvingas att göra det på ett visst sätt. Varje beslut motiveras. Om det finns en bättre lösning men ingen tid för den just nu, skapas en uppgift i JIRA för framtida refaktorering av en specifik del av koden.
• När en utvecklare har tagit en uppgift i arbete, ändrar han dess status till 'Under utveckling'. All kommunikation kring att klargöra uppgiften med beställaren ligger på utvecklarens axlar. Tekniska frågor kan ställas till teamledaren eller kollegor.
• Om utvecklaren inte förstår kärnan i uppgiften, och beställaren inte lyckas förklara den tydligt, går han vidare till nästa uppgift. Den aktuella uppgiften tas över av teamledaren som sedan diskuterar den med beställaren.
• Varje dag ska utvecklaren skriva i kundchatten om vilka uppgifter han arbetade med igår och vilka han kommer att arbeta med idag.
• Arbetsprocessen följer Scrum. Allt är uppdelat i sprintar. Varje sprint varar i två veckor.
• Sprintarna skapas, fylls med innehåll och stängs av teamledaren.
• Om projektet har strikta tidsfrister försöker vi estimera alla uppgifter. Därifrån skapar vi en sprint. Om beställaren försöker lägga till fler uppgifter i sprinten sätter vi prioriteringar och flyttar vissa uppgifter till nästa sprint.

b) Processen för arbete med beställaren

• Varje utvecklare kan och bör kommunicera med beställaren.
• Man får inte låta beställaren påtvinga sina spelregler. Det är viktigt att på ett artigt och vänligt sätt låta beställaren förstå att vi är specialister inom vårt område och det är bara vi som ska bygga upp arbetsprocesserna och involvera beställaren i dem.
• Det är lämpligt, innan man börjar implementera någon funktionalitet, att skapa ett flödesschema för hela den logiska processen för funktionen (work flow). Det ska skickas för bekräftelse till beställaren. Detta gäller endast komplex och otydlig funktionalitet, till exempel betalningssystem, notificationssystem etc. Det kommer att göra det möjligt att tydligare förstå vad beställaren verkligen behöver, bevara dokumentationen för funktionen och skydda sig mot att beställaren i framtiden säger att vi inte gjorde det som han bad om.
• Vi sparar alla diagram/flödesscheman/logik osv. i Confluence/Jira, där vi ber kunden bekräfta korrektheten av den framtida implementeringen i kommentarerna.
• Vi försöker att inte överbelasta kunden med tekniska detaljer. Om vi behöver förståelse för hur kunden vill ha det, ritar vi primitiva algoritmer i form av flödesscheman som kunden kan förstå och själv rätta/tweaka.
• Om kunden hittar en bugg i projektet ber vi dem att noggrant beskriva den i Jira. Under vilka omständigheter den uppstod, när, vilken åtgärdssekvens kunden följde vid testning. Vi ber dem att bifoga skärmdumpar.
• Vi försöker varje dag, max varannan dag, att göra en deploy till utvecklingsservern. Kunden börjar då testa funktionaliteten och projektet står inte stilla. Detta fungerar också som en markör för kunden att projektet är under full utveckling och att ingen berättar sagor.
• Det händer ofta att kunden inte riktigt förstår vad de överhuvudtaget behöver. Eftersom de skapar ett nytt företag med ännu inte etablerade processer. Därför är det en vanlig situation att vi kastar hela kodbitar i papperskorgen och omarbetar logiken i applikationen. Därav följer att man inte bör täcka allt med tester. Det är meningsfullt att täcka endast kritiskt viktig funktionalitet med tester, och det med vissa förbehåll.
• Det finns situationer när teamet inser att vi inte håller våra tidsfrister. Då gör vi en snabb granskning av uppgifterna och meddelar kunden om detta omedelbart. Som en lösning på situationen föreslår vi att lansera den viktiga och kritiska funktionaliteten i tid, medan resten kan skjutas till efter release.
• Om kunden börjar påhittar olika uppgifter från huvudet, börjar fantisera och förklara med fingrarna, ber vi dem att ge oss en skiss på sidan och flödet med logik som helt ska beskriva beteendet hos hela mallen och dess element.
• Innan vi tar oss an någon uppgift måste vi säkerställa att den här funktionen ingick i våra avtalsvillkor. Om det är en ny funktion som går utöver våra ursprungliga överenskommelser, så måste vi uppskatta denna funktion ((ungefärlig tidsram + 30%) x 2) och informera kunden om att det kommer att ta så här lång tid, plus att deadline flyttas fram med tiden för uppskattningen multiplicerat med två. Om vi kan göra uppgiften snabbare — fantastiskt, alla vinner på det. Om inte, har vi haft en säkerhetsmarginal.

v) Vad vi inte accepterar i teamet:

• Brist på ansvar, oorganiseradhet, glömska
• Att "skjuta upp". Om du inte kan utföra uppgiften eller inte vet hur, måste du omedelbart informera teamledaren istället för att vänta till sista stund.
• Skryter och överdrifter från en person som inte har bevisat sina förmågor och professionalism med handlingar. Om de har bevisat det, går det bra, inom rimliga gränser 🙂
• Bedrägeri i alla dess former. Om uppgiften inte är klar, ska du inte ändra statusen till klar och skriva i kundens chatt att den är redo. Datorn kraschade, systemet föll bort, hunden tuggade på bärbara datorn — allt detta är oacceptabelt. Om det verkligen är en force majeure, måste teamledaren omedelbart informeras.
• När specialisten alltid är offline och svårt att nå under arbetstid.
• Toxicitet i teamet accepteras inte! Om någon är oense, samlas alla för ett möte och diskuterar och löser det.

Och ytterligare några frågor/teser som jag ibland ställer till min kund för att undanröja alla missförstånd:

1. Vilka är era kvalitetskriterier?
2. Hur avgör ni om det finns problem i projektet eller inte?
3. Om ni bryter mot alla våra rekommendationer och råd för förändringar/förbättringar, bär ni alla risker själva.
4. Alla större ändringar i projektet (t.ex. alla möjliga extra flöden) kan leda till möjliga buggar (som vi naturligtvis kommer att åtgärda)
5. Det är omöjligt att förstå vilket problem som har inträffat i projektet på bara några minuter, än mindre att lösa det direkt.
6. Vi arbetar efter ett specifikt produktflöde (Uppgifter i Jira – Utveckling – Testning – Deployment). Det innebär att vi inte kan reagera på hela flödet av förfrågningar och klagomål i chatt.
7. Programmer är just programmerare och inte professionella testare, och de kan inte säkerställa tillräcklig kvalitet på projektets tester.
8. Ansvarigheten för slutlig testning och godkännande av uppgifter i produktion ligger helt på er.
9. Om vi redan har påbörjat en uppgift kan vi inte omedelbart byta till andra uppgifter förrän vi har slutfört den aktuella, annars leder det till ännu fler buggar och ökad utvecklingstid.
10. Antalet personer i teamet har minskat (på grund av semester eller sjukdom), men arbetsbördan har ökat och vi kan fysiskt inte hinna med allt ni vill.
11. Er begäran att göra deployment i produktion utan testade uppgifter i utveckling är endast ert risktagande, och inte utvecklarnas.
12. När ni ställer oklara uppgifter, utan korrekt flöde, utan designskisser, kräver det av oss mycket mer arbete och längre implementationstid, eftersom vi istället för er måste utföra ytterligare arbetskapacitet.
13. Eventuella buggar, utan detaljerad beskrivning av deras uppkomst och skärmdumpar, ger oss ingen möjlighet att förstå vad som gått fel och hur vi ska reproducera den buggen.
14. Projektet kräver ständig utveckling och förbättringar för att öka prestanda och säkerhet. Därför lägger teamet en del av sin tid på dessa förbättringar.
15. Eftersom vi ibland har övertid (akuta fixar) måste vi kompensera för det på andra dagar.

Som regel förstår kunden omgående att det inte är så enkelt med mjukvaruutveckling, och bara vilja är uppenbarligen inte tillräckligt.

Detta är det hela. Jag lämnar kvar många förhandlingar och den initiala justeringen av alla processer bakom kulisserna, men i slutändan har allt ordnat sig. Jag kan säga att den här processen blivit någon slags "Silverkula" för oss. Nya personer som kom till projektet kunde omedelbart delta i arbetet från första dagen, eftersom alla processer är dokumenterade, och dokumentationen samt arkitekturen i diagramform gav en tydlig bild av vad vi alla gör här.

P. S. Jag vill уточнить, что у нас нет менеджера проекта. Он есть с стороны заказчика. Совсем не технарь. Проект европейский. Вся коммуникация только на английском.

Lycka till med projekten. Bränn inte ut er och försök förbättra era processer.

Källan finns i min blogg.

Källa: habr.com