Projekti õigel rajal hoidmine on paljude tehnoloogiaettevõtete jaoks, kelle peamine eesmärk on õigeaegne ja tõhus tootearendus, tavaline väljakutse. Ma loen seda meie klientide ja partneritega peetavate regulaarsete vestluste ridade vahelt. Tahan jagada teiega ühte huvitavat lugu lootuses, et see inspireerib ka teid ja aitab teil lahendada oma tavalisi probleeme, mis on seotud tarkvaraarendusprojektide tõhusa juhtimisega.
Mis on asja tuum?
Siin on mõned tavalised põhjused, mida me sageli kuuleme:
- Me töötame oma uue toote/start-up'i kallal ja turule jõudmise aeg on meie ja meie investorite jaoks väga oluline.
- Meil on kavas olulised versioonid või uued funktsioonid ja meil on tõesti vaja need õigeaegselt välja anda.
- Meil on arenguprogramm planeeritud kuni aasta lõpuni ja me tahame, et neljandas kvartalis oleks olukord mugav, vältides asjatut kiirustamist ja stressi.
Nagu näete, on haldamine projekt tekitab üsna palju peavalu igale tehnikajuhile. Nad küsivad sageli, kuidas korraldada arendustegevuse tööd meeskond et vältida viivitusi ja veenduda, et kõik kavandatud toode funktsioonid on sujuvalt ja õigeaegselt välja töötatud. On ütlematagi selge, et võimalik "lõhe" ja arengu seiskumine võib olla valusate tagajärgedega. Liiga optimistlikud ajakavad, arendajate puudus, halvasti korraldatud töö jne võivad kokku viia, et teie projekt jääb tähtajast maha.

Moskva meetod
Alustame kiire selgitusega, mis on täpselt MOSKUSi meetod. See on eriline prioriteetide seadmise tehnika, mida kasutatakse projektijuhtimises ja tarkvaraarendus jõuda sidusrühmadega (kliendid või projektis osalevad liikmed) kokkuleppele, kui tähtsaks nad peavad iga nõude täitmist.
Seega arvan, et hea lahendus igale tehnikajuhile on tutvuda MOSKUMi meetodiga (koos selliste kategooriatega nagu "peab", "peaks", "võiks", "ei taha"). Kahe esimese kategooria - "peab" ja "võiks" - rakendamine on tavaliselt keeruline. Täitmisele kuuluvate ülesannete arv - mõnikord piiratud inimressursside, eelseisvate tähtaegade või mõne muu takistuse tõttu - ei pruugi olla teostatav.
Põhimõtteliselt on ettevõtetel erinevaid lähenemisviise sellise probleemi lahendamiseks. Hea riskijuhtimine on võti, et muuta ohud võitudeks. Lubage mul tuua üks hiljutine näide, mis on seotud selle teemaga. Mõned nädalad tagasi võttis minuga ühendust SaaS-toodete ettevõtte projektijuht seoses võimalusega, et outsourcing kolm tarkvarainseneri kindlaksmääratud ajavahemikuks oktoobri algusest kuni novembri lõpuni. Juhtub, et mõnel perioodil vajavad ettevõtted rohkemate arendajate tuge, sest on vaja teha palju ülesandeid ja hoida projekti soovitud arengutempo.
Mainitud projektijuht tuli välja ideega palgata spetsiaalne backend-inseneride meeskond, teades, et meie tehniline korpus vastab nende põhitoodete virnale. Me käivitasime projekti paindliku ja mugava tasulise mudeli abil. See ei nõudnud arvukaid pikki kohtumisi, kõnesid ega kuhjaga keeruliste lepingute allkirjastamist. Saime selge ettekujutuse taotluse olemusest ja teades, et aeg on siin oluline, korraldasime ülesehituse sujuvalt, nii et päästemeeskond on valmis.
Tehnoloogiapartneriga ühinemisel on veel palju muid eeliseid, mis on teie kasvuplaanide jaoks olulised. Väline tugi on eelkõige kulutõhus (see säästab teie eelarvest kuni 35%). Arendajad, kes liituvad teie majasisene meeskond toob sageli rakendatud projektile lisateadmisi ja värskeid vaatenurki. Tänu sellisele koostööle välistab klient riskid ja kitsaskohad, mis on seotud tähtaegade, aeglustumise ja pika nimekirja pooleliolevate ülesannete täitmisega. Tulles tagasi mainitud MOSCOW-meetodi juurde: kas "peab" ja "peaks" kategooria ülesannete täitmise tempo on kompromissi väärt?

Kas see on teie jaoks lahendus?
See on meie vaatenurk, kuidas hoida projekte õigel teel. Ma olen uudishimulik, kas teil on sarnaseid kogemusi oma inseneritiimi ülesehitusega? Kuidas te planeerite töömahtu tähtsate funktsioonide puhul oma torujuhtmes pühade ajal? Milliseid muid meetodeid te kasutate ja soovitate teistele tehnikajuhendajatele, et neil võiks olla suurepärane suvi mitte ainult puhkuse ajal, vaid ka sujuvalt toimides tootearendus? Anna mulle teada privaatsõnumiga siin.
Head planeerimist!
Loe edasi: