🥇Organisasyon ng proseso ng trabaho sa isang koponan sa isang proyekto sa IT

Kumusta Mga Kaibigan. Madalas, lalo na sa outsourcing, nakikita ko ang parehong larawan. Kakulangan ng isang malinaw na daloy ng trabaho sa mga koponan sa iba't ibang mga proyekto.

Ang pinakamahalagang bagay ay hindi naiintindihan ng mga programmer kung paano makipag-usap sa customer at sa bawat isa. Paano bumuo ng isang tuluy-tuloy na proseso ng pagbuo ng isang kalidad na produkto. Paano planuhin ang iyong araw ng trabaho at mga sprint.

At ang lahat ng ito sa huli ay nagreresulta sa hindi nasagot na mga deadline, overtime, patuloy na pagtatalo sa kung sino ang dapat sisihin, at hindi kasiyahan ng customer sa kung saan at paano gumagalaw ang lahat. Kadalasan, ang lahat ng ito ay humahantong sa isang pagbabago ng mga programmer, o kahit na buong mga koponan. Pagkawala ng isang customer, pagkasira ng reputasyon, at iba pa.

Sa isang pagkakataon, natapos ko lang ang ganoong proyekto, kung saan naroon ang lahat ng mga kasiyahang ito.

Walang gustong kumuha ng responsibilidad para sa proyekto (isang malaking marketplace ng serbisyo), ang turnover ay kakila-kilabot, ang customer ay napunit at nabigo. Minsang lumapit sa akin ang CEO at sinabing mayroon kang kinakailangang karanasan, kaya narito ang mga card sa iyong mga kamay. Kunin ang proyekto para sa iyong sarili. Kung susuko ka, isasara namin ang proyekto at sipain lahat. Ito ay gagana, ito ay magiging cool, pagkatapos ay pangunahan ito at paunlarin ito ayon sa nakikita mong akma. Bilang isang resulta, ako ang naging pinuno ng koponan para sa proyekto at lahat ay nahulog sa aking mga balikat.

Ang unang bagay na ginawa ko ay bumuo ng isang daloy ng trabaho mula sa simula na nakahanay sa aking paningin sa panahong iyon, at nagsulat ng isang paglalarawan ng trabaho para sa koponan. Hindi naging madali ang pagpapatupad nito. Ngunit sa loob ng isang buwan o higit pa ay naayos na ang lahat, nasanay na ang mga developer at ang kliyente, at naging tahimik at kumportable ang lahat. Upang maipakita sa koponan na ito ay hindi lamang isang "bagyo sa isang tasa ng tsaa", ngunit isang tunay na paraan sa labas ng sitwasyon, kinuha ko ang pinakamataas na halaga ng mga responsibilidad, inalis ang hindi kasiya-siyang gawain mula sa koponan.

Lumipas na ang isang taon at kalahati, at umuunlad ang proyekto nang walang overtime, walang "mga karera ng daga" at lahat ng uri ng stress. Ang ilang mga tao sa lumang koponan ay hindi nais na magtrabaho nang ganoon at umalis; ang iba, sa kabaligtaran, ay labis na nalulugod na lumitaw ang mga malinaw na patakaran. Ngunit sa huli, lahat ng tao sa koponan ay napaka-motivated at alam ang malaking proyekto nang buo, kabilang ang parehong front-end at back-end. Kasama ang parehong code base at lahat ng lohika ng negosyo. Dumating pa nga sa puntong hindi lang tayo "mga tagasagwan", kundi tayo mismo ang nakabuo ng maraming proseso ng negosyo at mga bagong feature na nagustuhan ng negosyo.

Salamat sa diskarteng ito sa aming bahagi, nagpasya ang customer na mag-order ng isa pang marketplace mula sa aming kumpanya, na magandang balita.

Dahil ito ay gumagana sa aking proyekto, marahil ito ay makakatulong din sa isang tao. Kaya, ang proseso mismo na tumulong sa amin na i-save ang proyekto:

Ang proseso ng pangkatang gawain sa proyektong "Aking Paboritong Proyekto"

a) Proseso ng panloob na koponan (sa pagitan ng mga developer)

Lahat ng isyu ay nilikha sa Jira system
Ang bawat gawain ay dapat ilarawan hangga't maaari at magsagawa ng mahigpit na isang aksyon
Anumang tampok, kung ito ay sapat na kumplikado, ay nahahati sa maraming maliliit na gawain
Ang koponan ay gumagana sa mga tampok bilang isang solong gawain. Una, lahat tayo ay nagtutulungan sa isang feature, ipadala ito para sa pagsubok, pagkatapos ay kunin ang susunod.
Ang bawat gawain ay minarkahan, para sa backend o frontend nito
Mayroong mga uri ng mga gawain at mga bug. Kailangan mong ipahiwatig ang mga ito nang tama.
Pagkatapos makumpleto ang isang gawain, ililipat ito sa status ng pagsusuri ng code (sa kasong ito, isang pull request ang ginawa para sa isang kasamahan)
Ang taong nakakumpleto ng gawain ay agad na sinusubaybayan ang kanyang oras para sa gawaing ito.
Pagkatapos suriin ang code, aaprubahan ng PR at pagkatapos nito, ang isa na nagsagawa ng gawaing ito ay nakapag-iisa na pinagsasama ito sa master branch, pagkatapos nito ay binago niya ang katayuan nito upang maging handa para sa pag-deploy sa dev server.
Ang lahat ng mga gawain na handa para sa pag-deploy sa dev server ay na-deploy ng pinuno ng koponan (ang kanyang lugar ng responsibilidad), kung minsan ng isang miyembro ng koponan, kung may apurahang bagay. Pagkatapos ng deployment, lahat ng gawain mula sa ready for deployment hanggang dev ay ililipat sa status - handa na para sa pagsubok sa dev
Ang lahat ng mga gawain ay sinubok ng customer
Kapag nasubukan na ng customer ang gawain sa dev, ililipat niya ito sa status na handa na para sa pag-deploy sa produksyon
Para sa pag-deploy sa produksyon, mayroon kaming hiwalay na sangay, kung saan pinagsasama namin ang master bago lang i-deploy
Kung sa panahon ng pagsubok ang customer ay nakahanap ng mga bug, ibabalik niya ang gawain para sa rebisyon, na itinakda ang katayuan nito bilang ibinalik para sa rebisyon. Sa ganitong paraan, pinaghihiwalay namin ang mga bagong gawain mula sa mga hindi nakapasa sa pagsubok.
Bilang resulta, ang lahat ng mga gawain ay napupunta mula sa paglikha hanggang sa pagkumpleto: Gagawin → Sa Pag-unlad → Pagsusuri ng Code → Handa nang i-deploy sa dev → QA sa dev → (Bumalik sa dev) → Handa nang i-deploy sa prod → QA sa prod → Tapos na
Ang bawat developer ay sumusubok sa kanyang code nang nakapag-iisa, kabilang ang bilang isang user ng site. Hindi pinapayagan na pagsamahin ang isang sangay sa pangunahing isa maliban kung tiyak na alam na gumagana ang code.
Ang bawat gawain ay may mga priyoridad. Ang mga priyoridad ay itinakda ng customer o ng team lead.
Kinukumpleto muna ng mga developer ang mga priyoridad na gawain.
Ang mga developer ay maaaring magtalaga ng mga gawain sa isa't isa kung ang iba't ibang mga bug ay natagpuan sa system o ang isang gawain ay binubuo ng gawain ng ilang mga espesyalista.
Ang lahat ng mga gawain na ginagawa ng customer ay mapupunta sa pinuno ng koponan, na susuriin ang mga ito at hihilingin sa customer na baguhin ang mga ito o italaga ang mga ito sa isa sa mga miyembro ng koponan.
Ang lahat ng mga gawain na handa para sa pag-deploy sa dev o prod ay mapupunta din sa pinuno ng koponan, na independiyenteng tumutukoy kung kailan at paano isasagawa ang deployment. Pagkatapos ng bawat deployment, dapat ipaalam ng pinuno ng koponan (o miyembro ng koponan) ang customer tungkol dito. At baguhin din ang mga katayuan para sa mga gawain upang maging handa para sa pagsubok para sa dev/cont.
Araw-araw sa parehong oras (para sa amin ito ay sa 12.00) nagsasagawa kami ng isang pagpupulong sa pagitan ng lahat ng mga miyembro ng koponan
Ang lahat sa pulong ay nag-uulat, kabilang ang pinuno ng pangkat, sa kung ano ang kanilang ginawa kahapon at kung ano ang plano nilang gawin ngayon. Ano ang hindi gumagana at bakit. Sa ganitong paraan, alam ng buong team kung sino ang gumagawa sa ano at saang yugto ng proyekto. Nagbibigay ito sa amin ng pagkakataong mahulaan at ayusin, kung kinakailangan, ang aming mga pagtatantya at mga deadline.
Sa pulong, ang pinuno ng koponan ay nagsasalita din tungkol sa lahat ng mga pagbabago sa proyekto at ang antas ng mga kasalukuyang bug na hindi nakita ng customer. Ang lahat ng mga bug ay inayos at itinalaga sa bawat miyembro ng koponan upang malutas ang mga ito.
Sa pagpupulong, ang pinuno ng koponan ay nagtatalaga ng mga gawain sa bawat tao, na isinasaalang-alang ang kasalukuyang workload ng mga developer, ang antas ng kanilang propesyonal na pagsasanay, at isinasaalang-alang din ang kalapitan ng isang partikular na gawain sa kung ano ang kasalukuyang ginagawa ng developer.
Sa pulong, ang pinuno ng pangkat ay bumuo ng isang pangkalahatang diskarte para sa arkitektura at lohika ng negosyo. Pagkatapos nito, tinalakay ito ng buong pangkat at nagpasya na gumawa ng mga pagsasaayos o gamitin ang diskarteng ito.
Ang bawat developer ay nagsusulat ng code at gumagawa ng mga algorithm nang nakapag-iisa sa loob ng balangkas ng isang solong arkitektura at lohika ng negosyo. Maaaring ipahayag ng lahat ang kanilang pananaw sa pagpapatupad, ngunit walang pinipilit ang sinuman na gawin ito sa ganitong paraan at hindi kung hindi man. Ang bawat desisyon ay makatwiran. Kung mayroong isang mas mahusay na solusyon, ngunit walang oras para dito ngayon, kung gayon ang isang gawain ay nilikha sa taba para sa hinaharap na refactoring ng isang tiyak na bahagi ng code.
Kapag gumawa ang isang developer ng isang gawain, inililipat niya ito sa status ng development. Ang lahat ng komunikasyon tungkol sa paglilinaw ng gawain sa customer ay nasa balikat ng developer. Ang mga teknikal na katanungan ay maaaring itanong sa pinuno ng koponan o mga kasamahan.
Kung hindi naiintindihan ng developer ang kakanyahan ng gawain, at hindi malinaw na maipaliwanag ito ng customer, pagkatapos ay magpapatuloy siya sa susunod na gawain. At kinukuha ng lead team ang kasalukuyan at tinatalakay ito sa customer.
Araw-araw, dapat isulat ng developer sa chat ng kliyente ang tungkol sa kung anong mga gawain ang ginawa niya kahapon at kung anong mga gawain ang gagawin niya ngayon.
Ang proseso ng trabaho ay nagaganap ayon sa Scrum. Ang lahat ay nahahati sa mga sprint. Ang bawat sprint ay tumatagal ng dalawang linggo.
Ang mga sprint ay nilikha, pinupunan at isinara ng pinuno ng koponan.
Kung ang proyekto ay may mahigpit na mga deadline, pagkatapos ay susubukan naming tantiyahin ang lahat ng mga gawain. At pinagsama namin sila sa isang sprint. Kung susubukan ng customer na magdagdag ng higit pang mga gawain sa sprint, pagkatapos ay nagtatakda kami ng mga priyoridad at ililipat ang ilang iba pang mga gawain sa susunod na sprint.

b) Proseso ng pakikipagtulungan sa customer

Ang bawat developer ay maaari at dapat makipag-ugnayan sa customer
Ang customer ay hindi maaaring pahintulutan na magpataw ng kanyang sariling mga patakaran ng laro. Kinakailangang linawin sa customer sa isang magalang at palakaibigan na paraan na kami ay mga espesyalista sa aming larangan, at kami lang ang dapat bumuo ng mga proseso ng trabaho at isali ang customer sa mga ito.
Ito ay kinakailangan, sa isip, bago simulan ang pagpapatupad ng anumang pag-andar, upang lumikha ng isang flowchart ng buong lohikal na proseso para sa tampok (workflow). At ipadala ito sa customer para sa kumpirmasyon. Nalalapat lamang ito sa kumplikado at hindi halatang pag-andar, halimbawa, isang sistema ng pagbabayad, sistema ng abiso, atbp. Magbibigay-daan ito sa amin na mas tumpak na maunawaan kung ano ang eksaktong kailangan ng customer, mag-save ng dokumentasyon para sa feature, at masiguro rin ang aming sarili laban sa katotohanang maaaring sabihin ng customer sa hinaharap na hindi namin ginawa ang hiniling niya.
Lahat ng mga diagram/flowchart/lohika atbp. Ise-save namin ito sa Confluence/Fat, kung saan hinihiling namin sa customer na kumpirmahin ang kawastuhan ng pagpapatupad sa hinaharap sa mga komento.
Sinisikap naming huwag pasanin ang customer ng mga teknikal na detalye. Kung kailangan namin ng pag-unawa sa kung paano ito gusto ng customer, pagkatapos ay gumuhit kami ng mga primitive na algorithm sa anyo ng isang flowchart na mauunawaan ng customer at maitama/mabago ang lahat sa kanyang sarili.
Kung ang customer ay nakahanap ng isang bug sa proyekto, hinihiling namin sa iyo na ilarawan ito nang detalyado sa Fat. Sa ilalim ng anong mga pangyayari ito nangyari, kailan, anong pagkakasunud-sunod ng mga aksyon ang isinagawa ng customer sa panahon ng pagsubok. Mangyaring mag-attach ng mga screenshot.
Sinusubukan namin araw-araw, bawat ibang araw sa pinakamaraming, upang i-deploy sa dev server. Ang customer ay magsisimulang subukan ang pag-andar at ang proyekto ay hindi nakatigil. Kasabay nito, ito ay isang marker para sa customer na ang proyekto ay nasa ganap na pag-unlad at walang nagsasabi sa kanya ng mga fairy tale.
Madalas na nangyayari na hindi lubos na nauunawaan ng customer kung ano ang kailangan niya. Dahil gumagawa siya ng bagong negosyo para sa kanyang sarili, na may mga prosesong hindi pa naitatag. Samakatuwid, ang isang napaka-karaniwang sitwasyon ay kapag itinapon namin ang buong piraso ng code sa basurahan at muling idisenyo ang logic ng application. Ito ay sumusunod mula dito na hindi mo dapat ganap na sakupin ang lahat ng mga pagsubok. Makatuwirang saklawin lamang ang kritikal na paggana sa mga pagsubok, at pagkatapos ay sa mga reserbasyon lamang.
May mga sitwasyon na napagtanto ng koponan na hindi kami nakakatugon sa mga deadline. Pagkatapos ay nagsasagawa kami ng mabilis na pag-audit ng mga gawain at agad na ipaalam sa customer ang tungkol dito. Bilang isang paraan sa labas ng sitwasyon, iminumungkahi namin ang paglulunsad ng mahalaga at kritikal na functionality sa oras, at iwanan ang iba para sa post-release.
Kung ang customer ay nagsimulang makabuo ng iba't ibang mga gawain mula sa kanyang ulo, nagsimulang magpantasya at magpaliwanag gamit ang kanyang mga daliri, pagkatapos ay hihilingin namin sa kanya na bigyan kami ng isang layout ng pahina at daloy ng lohika na dapat ganap na ilarawan ang pag-uugali ng buong layout at mga elemento nito.
Bago gawin ang anumang gawain, dapat naming tiyakin na ang tampok na ito ay kasama sa mga tuntunin ng aming kasunduan/kontrata. Kung ito ay isang bagong feature na higit pa sa aming mga paunang kasunduan, dapat naming presyohan ang feature na ito ((tinantyang oras ng pagkumpleto + 30%) x 2) at ipahiwatig sa customer na aabutin kami ng ganito katagal para makumpleto ito, kasama ang ang deadline ay inililipat sa pagtatantya ng oras na pinarami ng dalawa. Gawin natin ang gawain nang mas mabilis - mahusay, lahat ay makikinabang dito. Kung hindi, nasasakupan ka namin.

c) Ano ang hindi namin tinatanggap sa isang pangkat:

Uncommitment, kawalan ng composure, pagkalimot
"Nagpapakain ng almusal." Kung hindi mo makumpleto ang isang gawain at hindi mo alam kung paano, kailangan mong ipaalam kaagad sa pinuno ng koponan ang tungkol dito, at huwag maghintay hanggang sa huling minuto.
Mga kilay at ipinagmamalaki mula sa isang taong hindi pa napatunayan ang kanyang mga kakayahan at propesyonalismo. Kung ito ay napatunayan, kung gayon posible, sa loob ng mga hangganan ng pagiging disente :)
Panlilinlang sa lahat ng anyo nito. Kung ang isang gawain ay hindi nakumpleto, hindi mo dapat baguhin ang katayuan nito upang makumpleto at isulat sa chat ng kliyente na ito ay handa na. Nasira ang computer, nag-crash ang system, ngumunguya ang aso sa laptop - lahat ng ito ay hindi katanggap-tanggap. Kung may nangyaring totoong force majeure na kaganapan, dapat ipaalam kaagad ang pinuno ng pangkat.
Kapag ang isang espesyalista ay offline sa lahat ng oras at mahirap makipag-ugnayan sa kanya sa oras ng trabaho.
Bawal ang toxicity sa team! Kung ang isang tao ay hindi sumasang-ayon sa isang bagay, pagkatapos ay ang lahat ay nagtitipon para sa isang rally at pag-usapan at pagpapasya tungkol dito.

At ilang tanong/thesis na minsan ay tinatanong ko sa aking customer para i-clear ang lahat ng hindi pagkakaunawaan:

Ano ang iyong pamantayan sa kalidad?
Paano mo malalaman kung ang isang proyekto ay may mga problema o wala?
Sa pamamagitan ng paglabag sa lahat ng aming mga rekomendasyon at payo sa pagbabago/pagpapabuti ng system, ang lahat ng mga panganib ay ikaw lamang ang bahala
Anumang malalaking pagbabago sa proyekto (halimbawa, lahat ng uri ng dagdag na daloy) ay hahantong sa posibleng paglitaw ng mga bug (na, siyempre, aayusin natin)
Imposibleng maunawaan sa loob ng ilang minuto kung anong uri ng problema ang naganap sa proyekto, mas hindi ito ayusin kaagad
Nagtatrabaho kami sa isang partikular na daloy ng produkto (Mga Gawain sa Zhira - Pag-unlad - Pagsubok - I-deploy). Nangangahulugan ito na hindi kami makakatugon sa buong daloy ng mga kahilingan at reklamo sa chat.
Ang mga programmer ay mga programmer, hindi mga propesyonal na tester, at hindi masisiguro ang tamang kalidad ng pagsubok sa proyekto
Ang responsibilidad para sa panghuling pagsubok at pagtanggap ng mga gawain sa produksyon ay ganap na nasa iyo
Kung nagawa na namin ang isang gawain, hindi kami agad makakalipat sa iba hanggang sa makumpleto namin ang kasalukuyang gawain (kung hindi, hahantong ito sa mas maraming mga bug at pagtaas ng oras ng pag-unlad)
Mas kaunti ang mga tao sa team (dahil sa mga bakasyon o mga sakit), ngunit mas maraming trabaho at pisikal na hindi kami magkakaroon ng oras upang tumugon sa lahat ng gusto mo
Hinihiling namin sa iyo na gumawa ng deployment sa produksyon nang walang nasubok na mga gawain sa dev - ito lang ang iyong panganib, hindi ang mga developer
Kapag nagtakda ka ng mga hindi malinaw na gawain, nang walang tamang daloy, walang mga layout ng disenyo, nangangailangan ito ng higit na pagsisikap at oras ng pagpapatupad mula sa amin, dahil kailangan naming gumawa ng karagdagang dami ng trabaho sa halip na ikaw
Anumang mga gawain sa mga bug, nang walang detalyadong paglalarawan ng kanilang paglitaw at mga screenshot, ay hindi nagbibigay sa amin ng pagkakataong maunawaan kung ano ang naging mali at kung paano namin maaayos ang bug na ito.
Ang proyekto ay nangangailangan ng patuloy na pagpipino at mga pagpapabuti upang mapabuti ang pagganap at kaligtasan. Samakatuwid, ang koponan ay gumugugol ng bahagi ng kanilang oras sa mga pagpapahusay na ito
Dahil sa katotohanan na mayroon tayong overtime ayon sa oras (mga kagyat na pag-aayos), dapat nating bayaran ang mga ito sa ibang mga araw

Bilang isang patakaran, agad na nauunawaan ng customer na ang lahat ay hindi gaanong simple sa pagbuo ng software, at ang pagnanais lamang ay malinaw na hindi sapat.

Sa pangkalahatan, iyon lang. Nag-iiwan ako sa likod ng mga eksena ng maraming mga negosasyon at ang paunang pag-debug ng lahat ng mga proseso, ngunit bilang isang resulta, lahat ay gumana. Masasabi kong ang prosesong ito ay naging isang uri ng "Silver Bullet" para sa amin. Ang mga bagong tao na dumating sa proyekto ay maaaring agad na makisali sa trabaho mula sa unang araw, dahil ang lahat ng mga proseso ay inilarawan, at ang dokumentasyon at arkitektura sa anyo ng mga diagram ay agad na nagbigay ng ideya kung ano ang ginagawa nating lahat dito.

PS Nais kong linawin na walang project manager sa aming panig. Ito ay nasa panig ng customer. Hindi isang techie sa lahat. proyekto sa Europa. Ang lahat ng komunikasyon ay nasa Ingles lamang.

Good luck sa lahat sa iyong mga proyekto. Huwag masunog at subukang pagbutihin ang iyong mga proseso.

Source sa akin post ng blog.

Pinagmulan: www.habr.com

Organisasyon ng daloy ng trabaho sa isang koponan sa isang proyekto sa IT