Unë kam punuar si një zhvillues front-end për rreth dy vjet dhe kam marrë pjesë në krijimin e një sërë projektesh. Një nga mësimet që mësova është se bashkëpunimi midis ekipeve të ndryshme zhvilluesish që ndajnë të njëjtin qëllim, por kanë detyra dhe përgjegjësi të ndryshme nuk është i lehtë.
Në konsultim me anëtarët e tjerë të ekipit, dizajnerët dhe zhvilluesit, kam krijuar një cikël krijimit të faqeve të internetit të krijuar për ekipe të vogla (5-15 persona). Ai përfshin mjete të tilla si Confluence, Jira, Airtable dhe Abstract. Në këtë artikull do të ndaj veçoritë e organizimit të rrjedhës së punës.
Skillbox rekomandon: Kurse praktike dyvjeçare .
Kujtojmë: për të gjithë lexuesit e "Habr" - një zbritje prej 10 rubla kur regjistroheni në çdo kurs Skillbox duke përdorur kodin promovues "Habr".
Pse është e nevojshme e gjithë kjo?
Ekipi minimal i nevojshëm për të krijuar një faqe interneti nga e para është një projektues, programues dhe menaxher projekti. Në rastin tim, ekipi u formua. Por pas publikimit të disa faqeve, pata ndjenjën se diçka nuk shkonte me të. Ndonjëherë ne thjesht nuk i kuptonim plotësisht përgjegjësitë tona dhe komunikimi me klientin linte shumë për të dëshiruar. E gjithë kjo e ngadalësoi procesin dhe i shqetësoi të gjithë.
Fillova të punoj për zgjidhjen e problemit.
Një kërkim në Google jep rezultate të mira për problemin tonë.
Për ta bërë punën më vizuale, krijova një diagram të rrjedhës së punës që jep një kuptim se si bëhet puna këtu.
Klikoni mbi imazhin për t'u hapur në rezolucion të plotë.
Qëllimet dhe objektivat
Një nga teknikat e para që vendosa të testoja ishte "modeli i kaskadës" (Ujëvara). E përdora për të nxjerrë në pah problemet dhe për të kuptuar se si t'i zgjidhja ato.
Problemi: Më shpesh, klienti nuk e vlerëson procesin e krijimit të faqes në internet në mënyrë modulare, siç bëjnë zhvilluesit. Ai e percepton atë si një faqe të rregullt, domethënë, ai mendon në terma të faqeve individuale. Sipas mendimit të tij, projektuesit dhe programuesit krijojnë faqe individuale, njëra pas tjetrës. Si rezultat, klienti thjesht nuk e kupton se çfarë pason gjatë procesit aktual.
Detyra: Nuk ka kuptim të bindësh klientin për të kundërtën; opsioni më i mirë është zhvillimi i një procesi modular për krijimin e një faqe interneti brenda kompanisë bazuar në një model faqe për faqe.
Shenjat dhe komponentët e dizajnit universal menaxhohen nga zhvilluesit dhe projektuesit.
Problemi: Kjo është një situatë e zakonshme që trajtojnë shumë strategji. Ka shumë zgjidhje interesante, në shumicën e rasteve propozohet të krijohet një sistem dizajni që kontrollohet nga një udhëzues stili / gjeneratorë bibliotekë. Por në situatën tonë, shtimi i një komponenti tjetër në procesin e zhvillimit që do të na lejonte të menaxhonim nivelet e aksesit për projektuesit thjesht nuk ishte e mundur.
Detyra: ndërtimi i një sistemi universal në të cilin projektuesit, zhvilluesit dhe menaxherët mund të punojnë në mënyrë sinkrone pa ndërhyrë me njëri-tjetrin.
Ndjekja e saktë e zhvillimit
Problemi: Ndërsa ka shumë mjete të dobishme në dispozicion për të gjurmuar çështjet dhe për të matur progresin e përgjithshëm, shumica nuk janë fleksibël ose optimale. Mjeti mund të jetë i dobishëm duke kursyer kohën e ekipit që normalisht do të shpenzohej për pyetje dhe sqarime për detyra specifike. Gjithashtu e bën jetën më të lehtë për menaxherët duke u dhënë atyre një kuptim më të saktë të të gjithë projektit.
Detyra: krijoni një panel kontrolli për të ndjekur përparimin e detyrave të kryera nga anëtarë të ndryshëm të ekipit.
Set i mjeteve
Pasi eksperimentova me mjete të ndryshme, u vendosa në grupin e mëposhtëm: Confluence, Jira, Airtable dhe Abstract. Më poshtë do të zbuloj përfitimet e secilit.
turmë
Roli i mjetit: qendra e informacionit dhe burimeve.
Hapësira e punës e Confluence është relativisht e lehtë për t'u konfiguruar, ka shumë veçori, integrime me aplikacione të ndryshme dhe ka modele individuale, të personalizueshme. Nuk është një zgjidhje e vetme për të gjithë, por është ideale si një qendër informacioni dhe burimesh. Kjo do të thotë që çdo referencë ose detaj teknik në lidhje me projektin duhet të futet në bazën e të dhënave.
Mjeti ju lejon të dokumentoni siç duhet çdo komponent dhe çdo detaj tjetër rreth projektit.
Avantazhi kryesor i Confluence është personalizimi i shablloneve të dokumenteve. Përveç kësaj, mund të përdoret për të zbatuar një depo të vetme specifikimesh dhe dokumentacioni të ndryshëm të projektit, duke ndarë nivelet e aksesit të pjesëmarrësve. Tani nuk keni pse të shqetësoheni se keni një version të vjetër të specifikimeve në duart tuaja, siç ndodh kur dërgoni dokumente me email.
Më shumë informacion rreth mjetit .
Jira
Roli i mjetit: monitorimi i problemeve dhe menaxhimi i detyrave.
Jira është një mjet shumë i fuqishëm i planifikimit dhe menaxhimit të projektit. Pjesa kryesore e funksionalitetit është krijimi i flukseve të punës të personalizueshme. Për të menaxhuar në mënyrë efektive çështjet (që është ajo që na nevojitet), ia vlen t'i kushtohet vëmendje e veçantë përdorimit të saktë të llojit të kërkesës dhe llojit të çështjes (lloji i çështjes).
Pra, për t'u siguruar që zhvilluesit po ndërtojnë komponentë bazuar në dizajnin e saktë, ata duhet të njoftohen sa herë që diçka ndryshon në dizajn. Sapo komponenti të përditësohet, projektuesi duhet të hapë një problem, të caktojë një zhvillues përgjegjës, duke i caktuar atij llojin e saktë të problemit.
Me Jira, mund të jeni i sigurt që absolutisht të gjithë pjesëmarrësit në proces (më lejoni t'ju kujtoj, në rastin tonë ka 5-15 prej tyre) marrin detyra të sakta që nuk humbasin dhe gjejnë ekzekutuesin e tyre.
Mëso më shumë për hostin Jira .
Airtable
Roli i mjetit: menaxhimi i komponentëve dhe bordi i progresit.
Airtable është një përzierje e tabelave dhe bazave të të dhënave. E gjithë kjo bën të mundur personalizimin e funksionimit të të gjitha mjeteve të diskutuara më sipër.
Shembulli 1: Menaxhimi i komponentëve
Sa i përket gjeneratorit të udhëzuesit të stilit, nuk është gjithmonë i përshtatshëm për t'u përdorur - problemi është se projektuesit nuk mund ta modifikojnë atë. Përveç kësaj, nuk do të ishte një vendim i mirë për të përdorur bibliotekën e komponentëve Sketch, pasi ajo ka shumë kufizime. Me shumë mundësi, thjesht nuk do të mund ta përdorni këtë bibliotekë jashtë programit.
As Airtable nuk është perfekt, por është më i mirë se shumë zgjidhje të tjera të ngjashme. Këtu është një demonstrim i modelit të tabelës së menaxhimit të komponentëve:
Kur një zhvillues pranon një komponent të projektimit, ai vlerëson ABEM-in që rezulton duke e regjistruar komponentin në një tabelë. Gjithsej janë 9 kolona:
- Emri - emri i komponentit sipas parimit ABEM.
- Paraafishimi - Këtu vendoset ose një pamje e ekranit ose një imazh i komponentit të shkarkuar nga një burim tjetër.
- Një faqe e lidhur është një lidhje me faqen e një komponenti.
- Komponenti fëmijë - një lidhje me komponentët fëmijë.
- Modifikuesi - kontrollon praninë e opsioneve të stilit dhe i përcakton ato (për shembull, aktive, të kuqe, etj.).
- Kategoria e komponentëve është një kategori e përgjithshme (tekst, imazh promovues, shirit anësor).
- Statusi i zhvillimit - progresi aktual i zhvillimit dhe përcaktimi i tij (i përfunduar, në progres, etj.).
- Përgjegjës - zhvilluesi i cili është përgjegjës për këtë komponent.
- Niveli atomik është kategoria atomike e këtij komponenti (sipas konceptit të dizajnit atomik).
- Të dhënat mund të referohen në të njëjtat ose në tabela të ndryshme. Lidhja e pikave do të parandalojë konfuzionin gjatë shkallëzimit. Përveç kësaj, të dhënat mund të filtrohen, renditen dhe ndryshohen pa asnjë problem.
Shembulli 2: progresi i zhvillimit të faqes
Për të vlerësuar progresin e zhvillimit të faqes, ju nevojitet një shabllon i krijuar posaçërisht për këtë qëllim. Tabela mund t'u shërbejë si nevojave të vetë ekipit ashtu edhe klientit.
Çdo informacion në lidhje me faqen mund të shënohet këtu. Ky është një afat, një lidhje me prototipin e InVision, një destinacion, një komponent fëmijë. Menjëherë bëhet e dukshme se operacionet janë shumë të përshtatshme për t'u kryer, si për sa i përket dokumentimit dhe përditësimit të dizajnit, ashtu edhe statusit të zhvillimit të pjesës së përparme dhe të pasme. Për më tepër, këto operacione kryhen njëkohësisht.
Abstrakt
Roli i mjetit: një burim i vetëm i kontrollit të versionit për asetet e projektimit.
Abstrakt mund të quhet GitHub për asetet në Sketch, dhe i kursen dizajnerët nga nevoja për të kopjuar dhe ngjitur skedarë. Avantazhi kryesor i mjetit është se ai ofron një depo projektimi që vepron si një "burim i vetëm i së vërtetës". Projektuesit duhet të përditësojnë degën kryesore në versionin më të fundit të paraqitjes së miratuar. Pas kësaj, ata duhet të njoftojnë zhvilluesit. Ata, nga ana tjetër, duhet të punojnë vetëm me asetet e projektuesit nga dega kryesore.
Si perfundim
Pasi zbatuam procesin e ri të zhvillimit dhe të gjitha mjetet e përmendura më sipër, shpejtësia e punës sonë u rrit të paktën dy herë. Nuk është një zgjidhje perfekte, por është një zgjidhje shumë e mirë. Vërtetë, në mënyrë që ai të funksionojë, duhet të bëni shumë përpjekje - kërkon "punë manuale" për ta përditësuar dhe mirëmbajtur të gjitha në gjendje pune.
Skillbox rekomandon:
- Kurse praktike .
- Kurs online .
- Kursi praktik i vitit .
Burimi: www.habr.com