Koostöömudeli loomine

Hästi määratletud ja struktureeritud koostöömudel on peamine sulatusmeeskonna tõhusaks toimimiseks. Selles jaotises käsitletakse tegureid, mis võivad sellele edule kaasa aidata, nagu näiteks hästi määratletud rollid ja kohustused, struktureeritud ärirütm, usaldusväärsed suhtluskanalid ja juurdepääsetav dokumentatsiooniportaal.

Rollide ja vastutusalade määratlemine

Tõhusaks sulatusmeeskonna loomiseks peate esmalt määratlema selged rollid ja kohustused. Võtmelähenemiseks on alustada väikselt ja tutvustada rohkem rolle ja personali alles siis kui on vaja. Kasutage väiksemaid eesmärke, et tugineda edule ja näidata sulatusmeeskonna mudeli väärtust enne, kui proovite ambitsioonikamaid projekte.

Teie meeskond peab sisaldama vähemalt järgmisi töötajaid ja rolle:

  • Toote omanik – tavaliselt on see isik, kelle ülesandeks on tagada projektide edu. Samuti määratleb ta selge ja mõjuva eesmärgi või võib seda visiooni arendada koostöös ülejäänud meeskonnaga.
  • Valdkonnaekspert – see on äriteadlik meeskonnaliige, kes mõistab ja oskab sõnastada nii väljakutset kui ka lahendust. Power Appsi vähese koodiga lähenemise lihtsusega, peaks tal olema võimalik saada selle lahenduse loomisest kõige rohkem osa.
  • Professionaalne arendaja – "Pro Dev" võtab lahenduse domeenieksperdilt ja annab sellele piisavalt kodeerimistuge, et see saaks vajadusel pakkuda ettenähtud funktsionaalsust (ja ei midagi enamat).
  • Administraator – see meeskonnaliige hõlbustab integreerimis- ja tugistsenaariume, osutades samal ajal taustahaldusteenuseid. Mis tahes täiendav tugi aja ja asjatundmise osas, mida põhimeeskond vajab, võib olla paindlikult meeskonda toodud, mitte rühma püsiv liige. See meetod tagab sulatusmeeskonna tõhusa toimimise, tagades samal ajal juurdepääsu ressurssidele, mida tooteomanik oma eesmärkide saavutamiseks vajab.

Ärimudeli rütmi loomine

Rakenduse arendamisega seotud tegevuste sünkroonimisel tegevuste rütmiga saab sulatusmeeskonna tõhusust parandada, joondudes järgmisse struktuuri:

  • Määratlege meeskonna sünkroonimiseks korduv kalendrisündmus. Enamikule meeskondadele sobivad nädalase või kahenädalase intervalliga ajakohastamise koosolekud. Kuid ärge ajastage koosolekuid lihtsalt kohtumiste kokku panemiseks ja proovige vältida kohtumiste sagenemist tähtaja lähenedes, sest see teguviis võib olla ebaproduktiivne.
  • Pidage kinni kokkulepitud tööajast. Ideaaljuhul võiks teie meeskond olla ühes asukohas, kuigi sulatusmeeskonnad saavad tulemuslikult töötada erinevates geograafilistes piirkondades ja ajavööndites. Olenemata töökorraldusest, veenduge, et igaüks mõistaks tööaja kestust ja eesmärki ning austab neid piire.
  • Looge nädala rütm. Meeskonna nädalane rütm peaks sisaldama iseseisvat tööd, koostööd ja vajadusel tõhusaid kohtumisi. Nendel koosolekutel peaks olema konkreetne eesmärk, näiteks:
    • Ulatuse ülevaated - tuua meeskond kokku uute algatuste raames.
    • Kasutuskogemuse ülevaated - vaatamaks üle rakenduse kujundus ja näidised. Koosolekud, mille eesmärk on planeerida muid koosolekuid, koosolekud, meilide või kiirsõnumite asemel, või koosolekuid, mille eesmärk pole selgelt määratletud, vähendavad tööviljakust.
  • Töötage tõhusalt. Meeskond peab olema sisemiselt joondunud, et luua kõige sobilikum lahendus. See joondus peaks sisaldama võimalust kasutada uuesti komponente, mis on teised loonud.
  • Säilitage järjepidev edu eesmärgi suunas. Tagamaks, et meeskond täidab oma eesmärgid, on oluline, et kõik töötaksid koos selle tulemuse saavutamiseks. Sulatusmeeskonnad, kes töötavad Power Appsiga, tähendab edasimineku säilitamine kasutajatelt tagasiside hõivamist ja mõistmist, tegemata tööde prioriseerimist ning kogu projekti tervikliku tegevuskava loomist ja säilitamist.
  • Looge tugimaatriks. Tugimaatriks pakub struktureeritud lähenemist, et saada vajalikku tuge meeskonna üldeesmärkide saavutamise toetamiseks. Otse rakendusi loovate äritehnoloogide paratamatu väljakutse on see, et nad jõuavad oma teadmiste ja võimete piirini. Selles punktis, kellega nad ühendust võtavad ja kuidas nad seda teevad? Kuidas nad tegelevad kasutaja veateatega? Selles maatriksis tuleks määrata, kuidas nad saavad tugiteenusepilet tõstatada, et kaasata probleemi tõrkeotsingusse ja lahendamisesse õige meeskond, lähtudes probleemi tõsidusest. Iga tugistsenaariumi puhul selgitab see maatriks eskalatsiooni- ja tõrkeotsinguteed.

Meeskonna suhtluse määratlemine

Meeskonna kommunikatsiooni standardiseerimine on veel üks oluline komponent tõhusa toimingu säilitamisel. Kõik meeskonnaliikmed peavad teadma, kuidas meeskond ühendub, eriti asünkroonses režiimis ajavööndites. Suhtlusstrateegias tuleks arvesse võtta järgmisi valdkondi:

  • Kanalite. Milliseid kanaleid hakkab meeskond kasutama peamises ja teiseses suhtluses? Millised on igaühe eelised ja puudused? Valikute maailmas ei pruugi lihtsalt meili saatmine olla parim lahendus, ja võimalused nagu Microsoft Teams võivad pakkuda rohkem selgust, paremat jälgimist ja kõrgema reageeringumäära.
  • Teatiste tüübid. Kuidas te teavitate oma meeskonda värskendustest või sündmustest, millele nad peavad reageerima?
  • Sõnumi sagedus ja maht. Kui tihti te oma meeskonda teavitate? Igapäevane suhtlus võib anda kasuliku kokkuvõtte sellest, mis tol päeval juhtus, kuid mõni sõnum võib vajada varasemat toimingut. Paljusid kogenuid töötajaid koormatakse meilidega üle. Veenduge, et saavutate sageduse ja mahu vahelise tasakaalu, et vältida meeskonnaliikmete üle külvamist projektiga seotud sõnumitega.
  • Automatiseerimine. Kuidas saate suhtlusprotsessi automatiseerida? Standardiseeritud meilimallid, robotid ja sündmuseteatised võivad kõik aidata, kuid neid on vaja vastutustundeliselt kasutada, et nad ei koormaks üle meeskonnaliikmete võimet reageerida.
  • Hea suhtlemisoskus. Kõigil meeskonnas pole sama suhtlemisoskuse tase, kuid igaüks võib saada paremaks. Lihtsad lähenemised, nagu hea teema valimine meili jaoks, muudavad märkimisväärselt seda, kui hästi meeskond sellele sõnumile vastab. Julgustage lihtsat ja tõhusat kirjutamist kogu suhtluses; kui on tegevusi, mida meeskonnaliikmed peavad tegema, olege konkreetne ja nimetage need tegevused teemareal.

Näiteks, kuidas saate rakendada tõhusaid suhtlemisoskusi: võib olla vajate tabeli määratluse muutmist Dataverseis, näiteks mitme välja lisamiseks. Kui saadate välja teate selle kavandatava muudatuse kohta, peab meeskond aru saama, et kui nad ei vasta mõistliku aja jooksul, siis vastuse puudumine tähendab nõusolekut. Standardiseeritud ja loogiline suhtlus aitavad parendada tõhusust ja saavutada oodatud tulemusi.

Dokumentatsiooniportaali avaldamine

Dokumentatsioon ei ole lihtsalt ühegi projekti valikuline osa - see on oluline suhtluse, koostöö, toe ja pooleliolevate toimingute jaoks. Kommenteeritud kood on hea kood ning põhjalike selgituste ja koolituse dokumentatsiooni loomine on oluline osa iga sulatusprojekti juurutus-ja õppekogemuses.

  • Rakenduste kataloog. Rakenduse kataloog on maatriks või tabel, mis võtab kokku ja kooskõlastab kõik konkreetse meeskonna vastutusse kuuluvad rakendused. Kataloog sisaldab kõiki vastavaid rolli omanikke ja vastutusalade jaotist. Põhifunktsiooniks on tagada, et meeskond teaks täpselt, mis kellele kuulub, ning võtab sel viisil konkreetsete vastuste saamiseks ühendust õige meeskonna liikmega.
  • Tehnilised küsimused. Teie meeskonnal peaks olema korduma kippuvate (või isegi mitte-nii korduma kippuvate) tehniliste küsimuste hoidla rakenduse käitamise kohta. Need küsimused peavad olema mõistlikud ning vastused peavad olema hästi kirjutatud ja kättesaadavad.
  • Juhendid. Kasutusjuhendid on koheselt omaksvõetavad protseduuride komplektid, mis pakuvad lihtsaid vastuseid levinud installi- ja tegevusküsimustele. Tavaliselt vastaksid nad mõnele kindlale küsimustele, näiteks „Kuidas alustada uue rakenduse loomist?“
  • Sisseelamine. Sisseelamise juhised on ettevõttesisesed dokumendid, mis on mõeldud uute meeskonnaliikmete aitamiseks. Dokumentatsioon võiks sisaldada informatsiooni teemadel, nagu näiteks juurdepääsutaotlused, meili levitusloenditega ühinemine, teatiste seadistamist ja tellimist jne.

Head tavad

Järgmised head tavad peaksid aitama määratleda piirid ja lähenemised tõhusaks tööks sulatusmeeskondades.

Vastutus

Kui tegijate juhitud arendus ja sulatusmeeskonnad võimaldavad rakenduste kiiret arendamist ja juurutamist, on oluline tagada, et see jõupingutus on ilmselge ja seda tehakse koostöös IT-osakonnaga. Tegijad peavad olema vastutavad IT ees, aitamaks ennetada probleeme seonduvalt varju IT süsteemide kasvuga.

Sellest tulenevalt, tuleb IT-d teavitada, kui tegija alustab uue rakenduse ehitamisega. See teavitamine lihtsustab omakorda arendusprotsessi, kuna IT saab pakkude tegijatele ja sulatusmeeskondadele sobivat tuge, aidates neil luua hästi tagatud rakendusi, mis on õigestu turvatud ja hallatud.

automaatika

Hästi rakendatud automatiseerimine võib oluliselt suurendada tööviljakust. Näide, kuidas suurendada lahenduse juurutamise õnnestumist, on automatiseerida kõik nõutavad kontrollid mitmiklahenduse juurutamisel. Need automaatsed kontrollid võivad sisaldada järgmist:

  • Lahenduse versiooni kontrollimine, kus iga juurutamine kasutab värskendatud versiooninumbrit, vältides seega tõrkeotsingu käigus probleeme.
  • Ühenduse viidete dubleerimine.
  • Puuduolevad ühenduse viited.
  • Komponentide dubleerimine.

PR Checkeri lahendus sisaldab näidet selle kohta, kuidas seda automatiseerimist tõhusalt kaasata.

Aruandlus

Sulatusmeeskonnad ja tegijate välja töötatud rakendused peavad vastama andmed enne lähenemisele, mis tähendab rakenduste loomist siis, kui on võimalik edukust otse jälgida. Selle tulemuse saavutamiseks on vaja head vahendit, mis annab võimaluse tuvastada, mida meeskond hästi teeb, sealjuures tagasiside analüüsiga, et luua täpseid hindamisi konkreetse rakenduse tõhususest. Selle tulemuse saavutamiseks, peaksite:

  • Jälgige ja hinnake rakendusi. See, et üks inimene arvab, et midagi on kasulik või tal on hea idee, ei tähenda automaatselt, et igaüks leiaks sellest väärtuse. Meeskonnad peavad jälgima rakenduse kasutatavust ja hindama nende funktsioone, et tagada uute kaasatus ning funktsionaalne töö.
  • Julgustage head otsustusvõimet. Teisisõnu, ärge looge rakendusi ainult seetõttu, et saate neid luua - looge neid konkreetse ärieesmärgi jaoks.