Hello barátok. Elég gyakran látom ugyanezt a képet, különösen az outsourcingnál. Egyértelmű munkafolyamat hiánya a csapatokban a különböző projekteken.
A legfontosabb dolog az, hogy a programozók nem értik, hogyan kell kommunikálni az ügyféllel és egymással. Hogyan építsünk fel egy folyamatos folyamatot a minőségi termék fejlesztésére. Hogyan tervezd meg a munkanapodat és a sprinteket.
Mindez pedig a határidők megszegését, a túlórákat, a folyamatos leszámolást, hogy ki a hibás, és a vásárlók elégedetlenségét eredményezi – hol és hogyan halad minden. Mindez gyakran programozók, sőt egész csapatok változásához vezet. Ügyfél elvesztése, a hírnév romlása és így tovább.
Valamikor épp egy ilyen projektbe kerültem, ahol megvoltak ezek az örömök.
Senki nem akart felelősséget vállalni a projektért (nagy szervizpiac), borzalmas volt a forgalom, a megrendelő csak tépett és dobott. A vezérigazgató valahogy megkeresett, és azt mondta, hogy megvan a szükséges tapasztalatod, tehát a kezedben vannak a kártyák. Vedd magadnak a projektet. Ha elrontja, lezárjuk a projektet, és mindenkit kirúgunk. Kiderül, menő lesz, majd vezesd és fejleszd ahogy jónak látod. Ennek eredményeként csapatvezető lettem a projektben, és minden a vállamra esett.
Az első dolgom az volt, hogy a nulláról megterveztem egy munkafolyamatot, amely megfelelt az akkori elképzeléseimnek, és munkaköri leírást írtam a csapatnak. A megvalósítás nem volt egyszerű. De valahol egy hónapon belül minden rendeződött, a fejlesztők és a kliens megszokták, és minden csendesen és kényelmesen ment. Annak érdekében, hogy megmutassam a csapatnak, hogy ez nem csak egy vihar a pohárban, hanem egy igazi kiút a helyzetből, maximális felelősséget vállaltam magamra, eltávolítva a csapatból a kellemetlen rutint.
Már eltelt másfél év, és a projekt túlóra, „patkányverseny” és mindenféle stressz nélkül fejlődik. Valaki a régi csapatból nem akart így dolgozni és elment, éppen ellenkezőleg, valaki nagyon belejött, hogy átlátható szabályok jelentek meg. De ennek eredményeként a csapatban mindenki nagyon motivált, és teljes mértékben ismeri a hatalmas projektet, mind a front-end, mind a back-end esetében. A kódalapot és az összes üzleti logikát is beleértve. Még odáig is eljutott, hogy nem csak „evezősök” vagyunk, hanem mi magunk is kitalálunk sok olyan üzleti folyamatot és új funkciót, ami tetszik a vállalkozásnak.
Ennek a hozzáállásunknak köszönhetően az ügyfél úgy döntött, hogy másik piacteret rendel cégünktől, ami jó hír.
Mivel ez működik az én projektemen, talán ez is segít valakinek. Tehát maga a folyamat, amely segített megmenteni a projektet:
A csapatmunka folyamata a "Kedvenc projektem" projekten
a) Csapatfolyamaton belül (fejlesztők között)
- Minden feladat a Jira rendszerben jön létre
- Minden feladatot a lehető legrészletesebben le kell írni, és szigorúan egy műveletet kell végrehajtani.
- Bármely funkció, ha elég összetett, sok apró feladatra bontható
- A csapat egyetlen feladatként dolgozik a funkciókon. Először közösen elkészítünk egy funkciót, tesztelni adjuk, majd a következőt.
- Minden feladat háttér- vagy frontend-címke van
- Vannak különféle feladatok és hibák. Ezeket helyesen kell megadnia.
- A feladat befejezése után átkerül a kódellenőrzési állapotba (lehívási kérés jön létre a kollégának)
- Az, aki elvégezte a feladatot, azonnal követi a feladatra fordított idejét
- A kód ellenőrzése után a PR jóváhagyásra kerül, majd a feladatot végrehajtó önállóan beolvasztja a fő ágba, majd az állapotát a fejlesztői kiszolgálón történő telepítésre kész állapotra változtatja.
- Minden, a fejlesztői kiszolgálón történő telepítésre kész feladatot a csoportvezető (az ő felelősségi köre), néha egy csapattag telepít, ha valami sürgős. Az üzembe helyezés után az összes feladat a telepítésre késztől a fejlesztőig átkerül állapotba – készen áll a fejlesztői tesztelésre
- Minden feladatot az ügyfél tesztel
- Amikor az ügyfél tesztelte a feladatot a fejlesztőn, átviszi azt az éles üzembe helyezésre kész állapotba.
- Az éles üzembe helyezéshez külön águnk van, ahol közvetlenül a telepítés előtt egyesítjük a mestert
- Ha a tesztelés során az ügyfél hibákat talál, akkor visszaküldi a feladatot felülvizsgálatra, beállítva a revízióra visszaadott állapotát. Így különítjük el az új feladatokat a nem teszteltektől.
- Ennek eredményeként az összes feladat a létrehozástól a befejezésig tart: Teendő → Fejlesztés alatt → Kódellenőrzés → Üzembe helyezés készen a fejlesztőre → Minőségbiztosítás a fejlesztőn → (Vissza a fejlesztőhöz) → Üzembe helyezés készen a gyártási folyamatban → Minőségbiztosítás éles állapotban → Kész
- Minden fejlesztő önállóan teszteli a kódját, beleértve a webhely felhasználóját is. Nem szabad egy ágat összevonni a fővel, hacsak nem tudjuk biztosan, hogy a kód működik.
- Minden feladatnak vannak prioritásai. A prioritásokat az ügyfél vagy a csoportvezető határozza meg.
- A fejlesztők először a kiemelt feladatokat végzik el.
- A fejlesztők egymáshoz rendelhetnek feladatokat, ha különböző hibákat találtak a rendszerben, vagy egy feladat több szakember munkájából áll.
- Az ügyfél által létrehozott összes feladat elküldésre kerül a csoportvezetőnek, aki kiértékeli azokat, és felkéri az ügyfelet a véglegesítésre, vagy a csapat egyik tagjához rendeli.
- Minden olyan feladat, amely készen áll arra, hogy üzembe helyezze a fejlesztőt vagy a gyártást, a csapatvezetőhöz is eljut, aki önállóan határozza meg, hogy mikor és hogyan kell üzembe helyezni. A csoportvezetőnek (vagy csoporttagnak) minden telepítés után értesítenie kell erről az ügyfelet. Ezenkívül módosítsa a feladatok állapotát, hogy tesztelésre készen álljon a dev / prod felületen.
- Minden nap ugyanabban az időben (12.00-kor van) gyűlést tartunk az összes csapattag között
- A rallyn mindenki beszámol, beleértve a csapatvezetőt is, hogy mit csinált tegnap, mit tervez ma. Mi nem működik és miért. Így az egész csapat tisztában van azzal, hogy ki mit csinál és milyen szakaszban van a projekt. Ez lehetőséget ad arra, hogy előre jelezzük és szükség esetén módosítsuk becsléseinket és határidőket.
- A megbeszélésen a csapatvezető bejelenti a projektben bekövetkezett összes változást és az aktuális hibák szintjét is, amelyeket a megrendelő nem talált meg. Az összes hibát kiszűrjük, és minden csapattaghoz hozzárendeljük a megoldáshoz.
- A gyűlésen a csapatvezető mindegyikhez kioszt feladatokat, figyelembe véve a fejlesztők aktuális leterheltségét, szakmai felkészültségüket, valamint azt is, hogy egy adott feladat milyen közel áll ahhoz, amit a fejlesztő éppen csinál.
- A megbeszélésen a csoportvezető általános építészeti és üzleti logikai stratégiát dolgoz ki. Ezt követően az egész csapat megvitatja ezt, és eldönti, hogy módosít-e vagy elfogadja-e ezt a stratégiát.
- Minden fejlesztő önállóan ír kódot és épít algoritmusokat egyetlen architektúrán és üzleti logikán belül. Mindenki kifejezheti elképzelését a megvalósításról, de senki nem kényszerít senkit arra, hogy ezt így és nem másképp tegye. Minden döntés indokolt. Ha van jobb megoldás, de most nincs rá idő, akkor fatben jön létre egy feladat, a kód egy részének későbbi átdolgozására.
- Amikor egy fejlesztő elvállal egy feladatot, azt fejlesztési állapotba helyezi. A feladat tisztázásával kapcsolatos minden kommunikáció az ügyféllel a fejlesztő vállára esik. Technikai kérdéseket feltehet a csoportvezetőnek vagy kollégáinak.
- Ha a fejlesztő nem érti a feladat lényegét, és a megrendelő nem tudta értelmesen elmagyarázni, akkor továbblép a következő feladatra. A csapatvezető pedig veszi az aktuálisat és megbeszéli az ügyféllel.
- A fejlesztőnek minden nap meg kell írnia az ügyfél chatjében, hogy milyen feladatokon dolgozott tegnap és milyen feladatokon fog dolgozni ma
- A munkafolyamat a Scrumon alapul. Minden sprintekre oszlik. Minden sprint két hétig tart.
- A sprinteket a csapatvezető hozza létre, tölti ki és zárja le.
- Ha a projektnek szigorú határidői vannak, akkor megpróbáljuk az összes feladatot hozzávetőlegesen becsülni. És beszedünk tőlük egy sprintet. Ha az ügyfél megpróbál több feladatot hozzáadni a sprinthez, akkor prioritásokat állítunk fel, és néhány más feladatot áthelyezünk a következő sprintbe.
b) Az ügyféllel való munka folyamata
- Minden fejlesztő tud és kell is kommunikálnia az ügyféllel
- Nem engedheti meg az ügyfélnek, hogy saját játékszabályait írja elő. Udvariasan és barátságosan kell egyértelművé tenni a megrendelő számára, hogy szakterületünk szakértői vagyunk, és csak mi építsük fel a munkafolyamatokat, és vonjuk be ebbe a megrendelőt.
- Ideális esetben minden funkció megvalósításának megkezdése előtt létre kell hozni egy folyamatábrát egy szolgáltatás (munkafolyamat) teljes logikai folyamatáról. És küldje el az ügyfélnek megerősítésre. Ez csak az összetett és nem nyilvánvaló funkciókra vonatkozik, például fizetési rendszerre, értesítési rendszerre stb. Így pontosabban megértheti, hogy pontosan mire van szüksége az ügyfélnek, elmentheti a funkció dokumentációját, és bebiztosíthatja magát az ellen is, hogy a vásárló a jövőben azt mondhassa, hogy nem azt csináltuk, amit kért.
- Minden diagram/folyamatábra/logika stb. a Confluence/Fat-ba mentünk, ahol a megjegyzésekben kérjük a megrendelőt, hogy erősítse meg a jövőbeni megvalósítás helyességét.
- Igyekszünk nem terhelni a megrendelőt technikai részletekkel. Ha meg kell értenünk, hogy az ügyfél hogyan akarja, akkor primitív algoritmusokat rajzolunk egy folyamatábra formájában, amelyet az ügyfél megérthet, és mindent maga javíthat / módosíthat.
- Ha az ügyfél hibát talál a projektben, akkor azt kérjük, írja le részletesen a Fat-ban. Milyen körülmények között, mikor, milyen műveletsort hajtott végre az ügyfél a tesztelés során. Kérjük, csatoljon képernyőképeket.
- Minden nap, legfeljebb minden második napon megpróbáljuk telepíteni a fejlesztői kiszolgálóra. Az ügyfél ezután elkezdi tesztelni a funkcionalitást, és a projekt nem tétlen. Ugyanakkor ez jelzi az ügyfél számára, hogy a projekt teljes fejlesztés alatt áll, és senki sem mesél neki meséket.
- Gyakran előfordul, hogy az ügyfél egyáltalán nem érti teljesen, mire van szüksége. Mióta új üzletet hoz létre magának, még nem debuggolt folyamatokkal. Ezért nagyon gyakori helyzet az, amikor egész kóddarabokat dobunk a kukába, és átalakítjuk az alkalmazás logikáját. Ebből következik, hogy nem szükséges abszolút mindent tesztekkel lefedni. Célszerű csak a kritikus funkciókat lefedni tesztekkel, majd fenntartásokkal.
- Vannak helyzetek, amikor a csapat rájön, hogy nem férünk bele a határidőkbe. Ezt követően gyors auditot végzünk a feladatokon, és erről azonnal értesítjük a megrendelőt. A helyzetből való kiútként azt javasoljuk, hogy a fontos és kritikus funkciókat időben indítsa el, a többit pedig hagyja a kiadás utánra.
- Ha az ügyfél a fejéből kezd kitalálni különböző feladatokat, fantáziálni kezd, és az ujjain magyarázni kezd, akkor megkérjük, hogy adjon nekünk egy olyan oldalelrendezést és logikai folyamatot, amely teljes mértékben leírja a teljes elrendezés viselkedését és annak működését. elemeket.
- Mielőtt bármilyen feladatot elvállalnánk, meg kell győződnünk arról, hogy ez a funkció szerepel a megállapodásunkban/szerződésünkben. Ha ez egy új funkció, amely túlmutat a kezdeti megállapodásainkon, akkor feltétlenül meg kell becsülnünk ezt a funkciót ((hozzávetőleges átfutási idő + 30%) x 2), és jeleznünk kell az ügyfélnek, hogy ennyi időbe telik a megvalósítás. a határidő eltolódik a becsült idő kettővel szorozva. Gyorsítsuk a feladatot – remek, ebből mindenkinek csak haszna lesz. Ha nem, akkor biztosítottak vagyunk.
c) Amit nem fogadunk el a csapatban:
- Következetlenség, összefüggéstelenség, feledékenység
- "Reggeli etetés". Ha nem tudja elvégezni a feladatot, nem tudja, hogyan, akkor erről azonnal értesítenie kell a csoportvezetőt, és nem kell várnia az utolsóig.
- Brovada és dicsekvés egy olyan embertől, aki még nem tette bizonyította képességeit és szakmaiságát. Ha bebizonyosodik, akkor lehetséges, a tisztesség határain belül 🙂
- Csalás minden megnyilvánulásában. Ha a feladat nem fejeződött be, akkor ne módosítsa az állapotát készre, és írja be a kliens chatjébe, hogy kész. A számítógép összeomlott, a rendszer összeomlott, a kutya megrágta a laptopot - mindez elfogadhatatlan. Valós vis maior esetén haladéktalanul értesíteni kell a csapatvezetőt.
- Amikor egy szakember állandóan offline állapotban van, és munkaidőben nehéz elérni.
- A csapaton belüli toxicitás nem megengedett! Ha valaki nem ért egyet valamivel, akkor mindenki összegyűlik egy nagygyűlésre, megbeszélik és döntenek.
És néhány kérdés / tézis, amelyeket néha felteszek ügyfelemnek, hogy távolítsa el az összes félreértést:
- Mik a minőségi kritériumaid?
- Hogyan állapítható meg, hogy egy projektnek vannak-e problémák vagy sem?
- Ha megszegi a rendszer változtatására/fejlesztésére vonatkozó összes javaslatunkat és tanácsunkat, csak Ön viseli az összes kockázatot
- Bármilyen nagyobb projektmódosítás (például mindenféle extra áramlás) hibák esetleges megjelenéséhez vezethet (amit természetesen kijavítunk)
- Lehetetlen néhány percen belül megérteni, hogy milyen probléma történt a projektben, és még inkább nem lehet azonnal kijavítani
- Egy adott termékfolyamon dolgozunk (Tasks in Zhira - Fejlesztés - Tesztelés - Telepítés). Ez azt jelenti, hogy a chatben nem tudunk válaszolni a kérések és panaszok teljes folyamára.
- A programozók csak programozók, nem professzionális tesztelők, és nem tudják biztosítani a projekttesztelés megfelelő minőségét
- A végső tesztelésért és az eladási feladatok elfogadásáért teljes mértékben Önt terheli a felelősség
- Ha már elvállaltunk egy feladatot, akkor nem tudunk azonnal átváltani másokra, amíg az aktuálisat be nem fejezzük (egyébként ez még több bughoz és a fejlesztési idő növekedéséhez vezet)
- Kevesebb ember van a csapatban (nyaralások vagy betegségek miatt), és több a munka, és fizikailag nem lesz időnk mindenre válaszolni
- Ha a fejlesztőn tesztelt feladatok nélkül kéri meg az éles üzembe helyezést, az csak az Ön kockázata, nem a fejlesztőé
- Ha homályos feladatokat állít be, megfelelő áramlás, tervezési elrendezések nélkül, az sokkal több erőfeszítést és megvalósítási időt igényel tőlünk, mivel nekünk több munkát kell elvégeznünk Ön helyett.
- A hibákkal kapcsolatos feladatok, azok előfordulásának részletes leírása és képernyőképek nélkül, nem adnak lehetőséget arra, hogy megértsük, mi hibázott, és hogyan adhatjuk ki ezt a hibát.
- A projekt folyamatos finomítást és fejlesztést igényel a teljesítmény és a biztonság javítása érdekében. Ezért a csapat ideje egy részét ezekre a fejlesztésekre fordítja.
- Tekintettel arra, hogy túlóráink vannak (sürgős javítások), azokat a többi napon pótolni kell
Általában az ügyfél azonnal megérti, hogy a szoftverfejlesztésben nem minden olyan egyszerű, és a vágy önmagában nyilvánvalóan nem elég.
Általában ez minden. A színfalak mögött sok tárgyalást és minden folyamat kezdeti hibakeresését hagyom, de ennek eredményeként minden sikerült. Azt mondhatom, hogy ez a folyamat egyfajta „Ezüstgolyó” lett számunkra. A projekthez újonnan érkezett emberek már az első naptól kezdve azonnal munkába állhattak, hiszen minden folyamat le van írva, a dokumentáció és az architektúra pedig diagramok formájában azonnal képet ad arról, hogy mit is csinálunk. itt.
PS Szeretném tisztázni, hogy a mi oldalunkon nincs projektmenedzser. Az ügyfél oldalán áll. Egyáltalán nem technikus. európai projekt. Minden kommunikáció csak angol nyelven történik.
Sok sikert mindenkinek a projektjéhez. Ne égjen ki, és próbálja meg javítani a folyamatait.
forrás az én .
Forrás: will.com