Helló barátok. Folyamatosan, különösen az outsourcingban, ugyanazt a képet látom. A csapatokban különböző projektek esetén hiányzik a világos munkafolyamat.
A legfontosabb az, hogy a programozók nem értik, hogyan kell kommunikálni az ügyféllel és egymással. Hogyan kell felépíteni a folyamatos fejlesztési folyamatot egy minőségi termékhez. Hogyan kell megtervezni a munkanapjukat és a sprinteket.
Mindez végül meghiúsult határidőkben, túlórákban, folyamatos vitákban abban, hogy ki a hibás, és az ügyfelek elégedetlenségében ölt testet — hogy hová és hogyan halad minden. Elég gyakran ez a programozók, vagy akár egész csapatok cseréjéhez vezet. Megbeszéltek elvesztéséhez, a hírnév romlásához és így tovább.
Én is belekerültem egy ilyen projektbe, ahol mindezek a szépségek megvoltak.
Senki sem akart felelősséget vállalni a projekthez (nagy szolgáltató piactér), a fluktuáció borzasztó volt, az ügyfél egyszerűen tépte a haját. A CEO valahogy odajött hozzám, és azt mondta, hogy neked megvan a szükséges tapasztalatod, így hát itt a lehetőség. Vedd át a projektet. Ha elrontod, bezárjuk a projektet és mindenkit kirúgunk. Ha sikerül, akkor csináld úgy, ahogy jónak látod. Végül csapatvezető lettem a projekten, és minden rám hárult.
Az első dolog, amit tettem — új munkafolyamatot dolgoztam ki a nulláról, amely akkoriban megfelelt a víziómnak, és írtam egy munkaköri leírást a csapat számára. Bevezetni nem volt egyszerű. De körülbelül egy hónapon belül minden stabilizálódott, a fejlesztők és az ügyfél hozzászoktak, és minden csendesen és kényelmesen indult. Annak érdekében, hogy megmutassam a csapatnak, hogy ez nem csak "zűrzavar a pohárban", hanem a helyzet tényleges megoldása, magamra vállaltam a maximális feladatmennyiséget, levéve a kellemetlen rutint a csapatról.
Már másfél éve, hogy a projekt túllépett a túlórákon, a "patkányversenyeken" és a különféle stresszeken. Valaki a régi csapatban nem akarta így végezni a munkát, és elment, valaki más viszont nagyon örült, hogy megjelentek az átlátható szabályok. De végül mindenki, aki a csapatban van, nagyon motivált, és teljesen ismeri a nagy projektet, beleértve a frontend és backend aspektusokat is. Beleértve a kódalapokat és az összes üzleti logikát. Mára odáig jutottunk, hogy nem csak "evezünk", hanem magunk is sok üzleti folyamatot és új funkciókat találunk ki, amelyek az üzletnek kedvére vannak.
E megközelítésnek köszönhetően az ügyfél úgy döntött, hogy cégünktől újabb piacteret rendel, ami rendkívül örvendetes.
Mivel a projektimen ez működik, talán másoknak is segíthet. Íme a folyamat, amely segített megmenteni a projektet:
A csapat munkafolyamata a „Kedvenc projektem” című projektben
a) Belső csapatmunka (a fejlesztők között)
- Minden feladatot a Jira rendszerében hoznak létre
- Minden feladatnak a lehető legpontosabbnak kell lennie, és pontosan egy cselekvést kell végrehajtania
- Bármilyen funkciót, ha elég bonyolult, sok apró feladatra bontunk
- A csapat együtt dolgozik a funkciókon, mint egy egységes feladat. Először mindenki közösen végez egy funkciót, áttanulmányozásra adjuk, majd átvesszük a következőt.
- Minden feladatot címkéznek, hogy hátsóend vagy elülső end.
- Vannak feladat- és hiba típusok. Ezeket helyesen kell megadni.
- A feladat befejezése után kódellenőrzésre állítják (ezalatt létrehozunk egy pull requestet a kollégánknak)
- Aki végrehajtotta a feladatot, az azonnal nyomon követi az időt szintén arra a feladatra
- A kód ellenőrzése után a PR jóváhagyásra kerül, és ezt követően, aki a feladatot végezte, maga mergeli a fő ágba, majd módosítja a státuszát a kész a telepítésre a dev-en szerver.
- Minden feladat, amely kész a telepítésre a dev szerverre, a csapat vezetőjeként telepítve van (ez az ő felelőssége), néha a csapat egy tagja, ha valami sürgős. A telepítés után minden feladat amit kész a telepítésre a dev állapotba kerül — kész a tesztelésre a dev-en
- Minden feladatot az ügyfél tesztel
- Amikor az ügyfél tesztelte a feladatot a dev-en, azt a státuszba helyezi, hogy kész a telepítésre a prod-hoz
- A prod-hoz való telepítéshez külön ággal rendelkezünk, ahová a főből csak a telepítés előtt mergelünk
- Ha a tesztelés során az ügyfél hibákat talál, akkor visszaküldi a feladatot további feldolgozásra, és visszaküldés a javításra státuszt állítja be. Így elválasztjuk az új feladatokat azoktól, amelyek nem mentek át a tesztelésen
- A végeredmény minden feladat útja a létrehozástól a befejezésig: To Do → In Development → Code Review → Ready deploy to dev → QA on dev → (Return to dev) → Ready deploy to prod → QA on prod → Done
- Minden fejlesztő önállóan teszteli a kódját, beleértve a weboldal felhasználói élményét is. Nem engedélyezett a fő ággal való összefonódás, ha nem biztos, hogy a kód működik.
- Minden feladatnak vannak prioritásai. A prioritásokat vagy a megrendelő, vagy a csapatvezető határozza meg.
- A fejlesztők először a prioritásos feladatokat hajtják végre.
- A fejlesztők egymásnak is kijelölhetnek feladatokat, ha különböző hibákat találnak a rendszerben, vagy ha egy feladat több szakember munkáját öleli fel.
- Minden feladat, amelyet a megrendelő hoz létre, a csapatvezetőhöz kerül, aki értékeli őket, és vagy kéri a megrendelőt, hogy dolgozza ki tovább, vagy kijelöl egy csapattagot.
- Minden feladat, amely készen áll a kihelyezésre a fejlesztői vagy éles környezetbe, szintén a csapatvezetőhöz kerül, aki önállóan határozza meg, mikor és hogyan történik a kihelyezés. Minden kihelyezés után a csapatvezető (vagy egy csapattag) értesíti a megrendelőt. Emellett a feladatok státuszait is frissíteni kell, hogy készen álljanak a tesztelésre a fejlesztői/éles környezetben.
- Minden nap ugyanabban az időben (nálunk ez 12:00) találkozót tartunk az összes csapattag részvételével.
- Mindenki beszámol a találkozón, beleértve a csapatvezetőt is, hogy mit csinált tegnap, mit tervez ma csinálni, milyen nehézségekkel küzd és miért. Így az egész csapat tudja, ki mivel foglalkozik és hol tart a projekt. Ez lehetővé teszi számunkra, hogy előre jelezzük és szükség esetén korrigáljuk az előrejelzéseinket és határidőinket.
- A találkozón a csapatvezető beszámol az összes projektbeli változásról és a jelenleg található hibák szintjéről, amelyeket nem a megrendelő talált. Minden hibát átbeszélünk és minden csapattagra kijelölünk megoldásra.
- A találkozón a csapatvezető kijelöl a csapattagoknak feladatokat, figyelembe véve a fejlesztők aktuális terheltségét, szaktudásuk szintjét, valamint azt, hogy mennyire áll közel az adott feladat ahhoz, amivel éppen foglalkozik a fejlesztő.
- A találkozón a csapatvezető közösen kidolgozza az architektúra és az üzleti logika jövőbeli stratégiáját. Ezt követően az egész csapat megbeszéli, és döntést hoz a módosítások végrehajtásáról vagy a stratégia elfogadásáról.
- Minden fejlesztő önállóan ír kódot és épít algoritmusokat, egy közös architektúra és üzleti logika keretein belül. Mindenki kifejezheti a megvalósításra vonatkozó elképzeléseit, de senkit sem kényszerítenek arra, hogy csak így és nem másként dolgozzon. Minden döntést indokolni kell. Ha létezik jobb megoldás, de jelenleg nincs rá idő, akkor egy feladatot hozunk létre a JIRA-ban, hogy a jövőbeni kódrefaktorálás során foglalkozzunk vele.
- Amikor a fejlesztő átveszi a feladatot, átállítja azt fejlesztési státuszra. Minden kommunikáció a feladat tisztázásával kapcsolatban a megrendelőnél a fejlesztőre hárul. A technikai jellegű kérdéseket a csapatvezetőnek vagy kollégáknak lehet feltenni.
- Ha a fejlesztő nem érti a feladat lényegét, és a megrendelő nem tudta azt világosan elmagyarázni, akkor a következő feladatba kezd. Az aktuális feladatot a csapatvezető veszi át, és ő beszélget a megrendelővel.
- Minden nap a fejlesztőnek a kliens csevegőjében beszámolnia kell arról, hogy miken dolgozott tegnap, és miken fog dolgozni ma.
- A munkafolyamat Scrum módszertan szerint zajlik. Minden feladat sprintre van bontva, melynek időtartama általában két hét.
- A sprinteket a csapatvezető hozza létre, tölti ki és zárja le.
- Ha a projektnek szigorú határidői vannak, akkor próbáljuk megbecsülni az összes feladatot, és összeállítani egy sprintet. Ha a megrendelő próbál új feladatokat hozzáadni a sprinthez, akkor prioritásokat állítunk fel, és egyes feladatokat átviszünk a következő sprintbe.
b) A megrendelővel való munkafolyamat
- Minden fejlesztőnek kommunikálnia kell a megrendelővel.
- A megrendelőnek nem szabad megengedni, hogy a saját játékszabályait ránk erőltesse. Kedves és barátságos módon kell értesíteni a megrendelőt arról, hogy szakértők vagyunk a területen, és hogy nekünk kell kialakítanunk a munkafolyamatokat, amelyekben a megrendelőt is be kell vonnunk.
- Ideális esetben, mielőtt bármilyen funkcióval foglalkoznánk, el kell készítenünk a funkció logikai folyamatának blokkdiagramját (workflow). Ezt el kell küldeni a megrendelőnek jóváhagyásra. Ez csak a bonyolult és nem nyilvánvaló funkciókra vonatkozik, például a fizetési rendszerekre vagy az értesítési rendszerekre. Ez lehetővé teszi, hogy pontosabban megértsük, mire van szüksége a megrendelőnek, fenntartsuk a funkció dokumentációját, és biztosítsuk magunkat az ellen, hogy a megrendelő a jövőben azt mondhassa, hogy nem azt csináltuk, amit kért.
- Minden diagramot/sémát/logikát stb. a Confluence/Jira rendszerében tárolunk, ahol kérjük az ügyfelet, hogy a megjegyzésekben erősítse meg a jövőbeli megvalósítás helyességét.
- Igazán próbálunk nem túlterhelni az ügyfelet technikai részletekkel. Ha meg kell értenünk, hogy az ügyfél mit szeretne, akkor primitív algoritmusokat rajzolunk diagram formájában, amelyeket az ügyfél is megérthet, és így saját maga javíthat vagy átdolgozhatja azokat.
- Ha az ügyfél hibát talál a projektben, akkor kérjük, hogy nagyon részletesen írja le azt a Jira rendszerében. Milyen körülmények között történt, mikor, és milyen lépéseket tett az ügyfél a tesztelés során. Kérjük, hogy csatoljon képernyőképeket.
- Próbáljuk meg mindennap, legfeljebb két naponta elvégezni a telepítést a fejlesztői szerverre. Az ügyfél ekkor elkezdi tesztelni a funkciót, és a projekt nem áll. Ez egy jelző az ügyfél számára, hogy a projekt teljes mértékben fejlesztés alatt áll, és senki sem mond neki meséket.
- Nagyon gyakran előfordul, hogy az ügyfél nem teljesen érti, hogy valójában mire van szüksége. Mivel új üzletet indít, még nem kiforrott folyamatokkal. Ezért gyakori jelenség, hogy egész kódrészeket dobunk a kukába, és átalakítjuk az alkalmazás logikáját. Ezért nem érdemes mindent tesztelni. Csak a kritikus fontosságú funkciókat érdemes tesztelni, de figyelmeztetésekkel.
- Vannak olyan helyzetek, amikor a csapat rájön, hogy nem tartjuk be a határidőket. Ilyenkor gyors auditot végzünk a feladatokon, és azonnal értesítjük az ügyfelet. Mint megoldást arra a helyzetre, javasoljuk, hogy az fontos és kritikus funkciót határidőre indítsuk, míg a többit hagyjuk a megjelenés utánra.
- Ha az ügyfél elkezd különféle feladatokat kitalálni a levegőből, elkezd fantáziálni és kézzel magyarázni, akkor kérjük, hogy adjon nekünk oldalelrendezést és egy logikai folyamatábrát, amely teljes mértékben leírja az egész elrendezés és elemeinek viselkedését.
- Bármely feladat elvállalása előtt meg kell győződnünk arról, hogy ez a funkció benne van a szerződésünk feltételeiben. Ha ez egy új funkció, amely túllép az eredeti megállapodásainkon, akkor azt feltétlenül meg kell becsülnünk ((körülbelüli teljesítési idő + 30%) x 2), és tájékoztatnunk kell az ügyfelet arról, hogy mennyi időt vesz igénybe, plusz a határidő a becslés ideje kétszerese alapján tolódik el. Ha gyorsabban végezzük el a feladatot — remek, mindenki nyer ezzel. Ha nem, akkor biztosítottuk magunkat.
b) Amit nem tolerálunk a csapatban:
- Nem kötelező, szétszórtság, feledékenység.
- „Jövőbe nézés“. Ha nem tudod végrehajtani a feladatot, vagy nem tudod, hogyan, akkor erről azonnal értesítened kell a csapatvezetőt, és nem várhatsz az utolsó pillanatig.
- Felszínesség és hencegés olyan embertől, aki még nem bizonyította tettekkel a képességeit és professzionalizmusát. Ha bizonyította, akkor lehet, a megfelelő keretek között 🙂.
- Bármilyen formájú csalás. Ha a feladat nincs elvégezve, akkor nem szabad megváltoztatni annak státuszát teljesítettre, és nem szabad azt írni a kliensek csevegésébe, hogy készen áll. A számítógép meghibásodott, a rendszer leállt, a kutya megrágta a laptopot — ezek mind elfogadhatatlanok. Ha valódi vis maior történik, a csapatvezetőt azonnal értesíteni kell.
- Amikor a szakember folyamatosan offline van, és nehezen elérhető munkaidőben.
- Toxikus légkör a csapatban nem megengedett! Ha valaki nem ért egyet valamivel, akkor mindannyian összegyűlnek egy megbeszélésre, ahol megvitatják és megoldják azt.
És még egy sor kérdés/teza, amelyeket néha felteszek az ügyfelemnek, hogy eloszlassam a félreértéseket:
- Mik az Ön minőségi kritériumai?
- Hogyan állapítja meg, hogy vannak problémák a projektben vagy nincs?
- Az összes ajánlásunk és tanácsunk megsértésével minden kockázatért csak Ön felel.
- Bármilyen jelentős változtatás a projektben (például mindenféle extra munkafolyamat) potenciálisan hibák megjelenéséhez vezethet (amelyeket természetesen javítunk).
- Pár perc alatt lehetetlen megérteni, milyen probléma történt a projektben, és ezáltal azonnal megoldani.
- Konkét termékfolyammal dolgozunk (Feladatok a Jira — Fejlesztés — Tesztelés — Telepítés). Ezért nem tudunk reagálni az összes sürgősségre és panaszra a csevegésben.
- A programozók programozók, nem pedig professzionális tesztelők, és nem tudják biztosítani a projekt megfelelő tesztelési minőségét.
- A végső tesztelés és a feladatok elfogadása a termelésben teljes mértékben önön felelőssége.
- Ha már elkezdtük a feladat munkálatait, akkor nem tudunk azonnal másokra váltani, amíg be nem fejezzük a folyamatban lévőt (különben ez még több hibához és a fejlesztési idő növekedéséhez vezet).
- Kevesebb ember van a csapatban (szabadságok vagy betegségek miatt), míg a munka mennyisége megnövekedett, és fizikailag nem tudunk reagálni minden kérésére.
- Az ön részéről érkező kérés, hogy a nem tesztelt feladatokat a fejlesztői környezetből telepítse a termelésbe - ez csak az ön kockázata, nem a fejlesztőké.
- Amikor homályos feladatokat ad meg, helyes folyamatok és dizájn minták nélkül, ez sokkal nagyobb erőfeszítéseket és a megvalósítási határidők meghosszabbítását igényli tőlünk, mivel nekünk kell elvégezni a plusz munka egy részét helyettük.
- Bármilyen hibaügy, részletes leírás és képernyőképek nélkül nem adja meg a lehetőséget számunkra, hogy megértsük, mi ment rosszul, és hogyan tudjuk reproduced javítani ezt a hibát.
- A projekt folyamatos fejlesztéseket és javításokat igényel a teljesítmény és biztonság növelése érdekében. Ezért a csapatunk idejének egy részét ezekre a fejlesztésekre fordítja.
- Abból kifolyólag, hogy előfordulhatnak túlórák (sürgős javítások miatt), ezeket más napokon kell kompenzálnunk.
Általában a megrendelő azonnal megérti, hogy a szoftverfejlesztés nem is olyan egyszerű, és az itt kifejezett szándék nyilvánvalóan nem elegendő.
Ez minden. Hátul sok tárgyalást és a folyamatok kezdeti finomítását hagyok, de a végeredmény minden simán ment. Azt mondhatom, hogy ez a folyamat számunkra egyfajta „Ezüst golyóvá” vált. Az újonnan érkezett emberek, akik a projektre jöttek, azonnal belevághattak a munkába az első naptól kezdve, mivel minden folyamat dokumentálva volt, és a dokumentáció és az architektúra diagramos formája már az első naptól világosan bemutatta, hogy mivel foglalkozunk.
P.S. Szeretném tisztázni, hogy a mi oldalunkon nem létezik projektmenedzser. Az ügyfél oldalán van. Teljesen nem technikai típusú. A projekt európai. Az egész kommunikáció kizárólag angolul folyik.
Mindenkinek sok szerencsét a projekteknél. Ne égjenek ki, és próbálják javítani a folyamataikat.
A forrás kód nálam van. .
Forrás: habr.com
