SĂ« fundmi, krejt rastĂ«sisht, me ndihmĂ«n e njĂ« personi tĂ« mirĂ«, lindi ideja â tĂ« bashkĂ«ngjisim njĂ« pĂ«rmbledhje tĂ« shkurtĂ«r pĂ«r çdo artikull. Jo njĂ« pĂ«rmbledhje, jo njĂ« tĂ«rheqje, por pikĂ«risht njĂ« pĂ«rmbledhje tĂ« shkurtĂ«r. NjĂ« gjĂ«, qĂ« mund tĂ« bĂ«het pa lexuar fare artikullin.
E tryeva, dhe mĂ« pĂ«lqeu shumĂ«. Por kjo nuk ka rĂ«ndĂ«si â e rĂ«ndĂ«sishme Ă«shtĂ« qĂ« iu pĂ«lqeu lexuesve. Filluan tĂ« kthehen ata qĂ« kishin ndaluar sĂ« lexuari, duke mĂ« etiketuar si njĂ« grafoman. Dhe njĂ« tjetĂ«r person i mirĂ« mĂ« sugjeroi tĂ« shkruaj njĂ« pĂ«rmbledhje pĂ«r çdo artikull tĂ« vjetĂ«r. UnĂ« pranova dhe tani, pĂ«rmes punĂ«s, po shkruaj kĂ«to pĂ«rmbledhje tĂ« shkurtra. I quajta shorta.
Ju ofroj disa nga këto shorta, për disa publikime. Ndoshta do të gjeni diçka të dobishme për vete.
Maceja vdiq, koda u plak
Mbledhjet shpeshherë kalojnë pa rezultat. Mblidhen, bisedojnë, shpërndahen.
Rezultatet, ose produktet e mbledhjes â janĂ« vendimet. KĂ«to zakonisht mungojnĂ«. Dhe nĂ«se ka, nuk janĂ« gjithmonĂ« tĂ« mira.
Nëse mbledhja është e kufizuar në kohë, dhe vendimi duhet të merret patjetër, atëherë ai (vendimi) zakonisht është i dobët.
Nëse takimi nuk ka një limit kohor dhe zgjat deri në marrjen e një vendimi, atëherë çdo vendim në marrë, mjafton që takimi të përfundojë.
Nëse vendimi është krijuar gjatë takimit, ai do të merret - thjesht sepse truri vlerëson atë që është krijuar.
Kuptimi i cilësisë së ulët të vendimit do të vijë më vonë, por atëherë do të jetë tepër vonë.
Për të marrë një vendim efektiv, është më mirë të mos marrësh pjesë në diskutim, por të vëzhgosh në heshtje.
Së pari, truri nuk do të jetë i angazhuar në krijimin e përgjigjeve.
Së dyti, nuk ka presionin për të marrë një vendim.
Pas përfundimit të takimit, mund të mendosh qetësisht dhe të marrësh një vendim. Ai do të jetë më i cilësishëm.
ĂelĂ«si: tĂ« heshtĂ«sh dhe tĂ« dĂ«gjosh gjatĂ« takimit. PĂ«r tĂ« mos shqetĂ«suar tĂ« tjerĂ«t, thoni se kjo Ă«shtĂ« njĂ« pozitĂ« e vetĂ«dijshme.
â
Parazitët latente
Në mënyrë themelore, ekzistojnë dy qasje për vendosjen e detyrave dhe kontrollin e zbatimit: parazitare dhe simbiotike.
Qasja simbiotike - të sigurohet që detyra të zgjidhet.
Qasja parazitare - të sigurohet që detyra Tà MOS zgjidhet.
Qasja simbiotike është e drejtpërdrejtë dhe e thjeshtë, por e vështirë për t'u zbatuar. Prandaj, ajo ndodh rrallë.
Detyra vendoset nĂ« njĂ« mĂ«nyrĂ« qĂ« gjithçka tĂ« jetĂ« e qartĂ« â si objektivat, ashtu edhe burimet dhe kufizimet.
Kontrolli bëhet në mënyrë që detyra të zgjidhet me saktësi.
Qasja simbiotike nënkupton lënien e një pjesë të përgjegjësisë (madje, më të madhe) për zgjidhjen e detyrës te personi që e ka vendosur atë.
Qasja parazite është e ndërlikuar dhe e zgjuar, por e thjeshtë në zbatim. Prandaj, ajo ndodhet shpesh.
Detyra vendoset në një mënyrë që të mos jetë e qartë fare. Sa më pak e qartë, aq më mirë.
Kontrolli, preferohet, të mos bëhet fare.
Nuk ka asnjĂ« pĂ«rgjegjĂ«si te personi qĂ« vendos detyrĂ«n, e gjithĂ« âmajmuniâ transferohet te ekzekutori.
Qëllimi i qasjes parazite: manipulim, egoizëm, vetëaffirmim. Prandaj, ajo ndodh shpesh në punën e mentorëve me punonjësit fillestarë.
Sigurisht, është më mirë qasja simbiotike.
â
Masa vs Iluzionet
Nëse e vlerësoni procesin dhe rezultatet e aktivitetit tuaj pa masa, do të gaboni gjithmonë.
VlerĂ«simi pa numra varet nga humorin. NjĂ« humor i keq do tĂ« duket se po punoni keq. NjĂ« humor i mirĂ« â pĂ«rkundrazi.
Kështu mund të kaloni një javë duke punuar keq, dhe të premten të paraqisni një rezultat, dhe do të duket sikur e gjithë java ka kaluar mirë.
Praktikisht, ekzistojnë dy lloje metrikesh: sasiore dhe alternative (më të njohura për programuesit si Boolean).
"Detyra Ă«shtĂ« pĂ«rfunduar nĂ« kohĂ«" â kjo Ă«shtĂ« Boolean. ĂshtĂ« e njĂ«jta gjĂ« si "Pjesa Ă«shtĂ« e pĂ«rshtatshme" (njĂ« shenjĂ« alternative cilĂ«sie, kur nuk mund tĂ« matet me numra).
"Ne punojmĂ« mirĂ«", "Ne realizojmĂ« planin", "UnĂ« jam i mirĂ«" â gjithashtu Boolean.
ĂshtĂ« e komplikuar tĂ« ndĂ«rtohet njĂ« proces menaxhimi mbi vlerĂ«simet e tipit Boolean. Rekomandohet qĂ« sa mĂ« shpejt tĂ« kaloni nĂ« metrike sasiore.
Boolean çon në burokraci dhe formalizëm. Për shembull, arritja e detyrave në kohë mund të realizohet duke zgjeruar afatet, duke shpikur detyra për veten, duke kryer IBD.
PĂ«r tĂ« menaxhuar nĂ« bazĂ« tĂ« treguesve Boolean, duhet tĂ« harxhoni shumĂ« kohĂ« â nĂ« takime, analiza, etj. Sepse informacioni Ă«shtĂ« shumĂ« i pakĂ«t.
Rekomandohet të matni si procesin ashtu edhe rezultatin. Kështu, pasqyra do të jetë më e plotë.
PĂ«r programuesit rekomandohet metoda "Planifikimi i Pokerit" nga Scrum.
â
Kjo është Sparta
Supozoni se ju jeni njĂ« programues dhe ju Ă«shtĂ« dhĂ«nĂ« njĂ« detyrĂ« serioze. Dhe ju mendoni se nuk duhet ta zgjidhni atĂ« â Ă«shtĂ« e marrĂ«zishme, e dĂ«mshme.
Një sjellje tipike në një situatë të tillë: ta nxirrni detyrën në një hapësirë publike. Të dërgoni për miratim te shefi, të nisni një projekt të brendshëm, ta regjistroni në sistem, etj.
Në këtë pikë, gjithçka dëmtohet. Njeriu që solli detyrën, nuk dëshiron që të mendohet se është budalla. Dhe pasi ka dalë në hapësirë publike, ai do të mbrohet.
I rĂ«ndĂ«sishĂ«m pĂ«r njeriun Ă«shtĂ« tĂ« mos humbasĂ« fytyrĂ«n, nĂ« kuptimin politik. E rĂ«ndĂ«sishme nĂ« politikĂ« Ă«shtĂ« â kurrĂ« tĂ« mos e pranosh gabimin tĂ«nd. Mund tĂ« mos bĂ«sh asgjĂ«, por e rĂ«ndĂ«sishme Ă«shtĂ« qĂ« tĂ« mos kesh gabime tĂ« pranuara.
Njeriu do të përdorë të gjitha forcat për të provuar se programuesi është një i lig, idiot, armik i ndryshimeve. Dhe programuesi do të duhet ta zgjidhë detyrën në çdo rast.
NĂ« disa raste, njeriu do ta organizojĂ« gjithçka qĂ« programuesi tĂ« mos e zgjidhĂ« fare detyrĂ«n. AtĂ«herĂ« njeriu do tĂ« jetĂ« âi bardhĂ«â, ndĂ«rsa programuesi do tĂ« jetĂ« krejtĂ«sisht âi ziâ (edhe ka rezistuar, edhe nĂ« fund nuk e ka pĂ«rmbushur).
Ka disa zgjidhje.
E para â tĂ« bĂ«heni programues biznesi, tĂ« kuptoni fushat e lidhura dhe vetĂ« tĂ« pĂ«rcaktoni se çfarĂ« dhe si duhet automatizuar.
E dyta â tĂ« bĂ«ni njĂ« artikull si Kryetar i ndryshimeve. PĂ«r shembull, drejtor zhvillimi.
E treta â mos u shfaqni dhe thjesht bĂ«ni atĂ« qĂ« thonĂ«.
E katĂ«rta â Rruga e SpartĂ«s, njĂ« seleksionim i shpejtĂ« i zgjidhjeve. MĂ« i njohur si dĂ«shtoni shpejt, dĂ«shtoni lirĂ« (fail fast, fail cheap).
E rĂ«ndĂ«sishmja â tĂ« mos shkoni nĂ« publik. T'i thoni njeriut â le tĂ« mos humbim shumĂ« kohĂ«, tĂ« bĂ«jmĂ« njĂ« prototip dhe tĂ« shohim nĂ«se zgjidhja Ă«shtĂ« e jetueshme apo jo.
Prototipi do tĂ« marrĂ« pak kohĂ«. NĂ« rast suksesi, tĂ« dy do tĂ« fitojnĂ« â njĂ« zgjidhje tĂ« mirĂ« dhe pikĂ« politike.
Në rast dështimi, askush nuk do të vuajë. Po ashtu, njeriu do të ketë një qëndrim më të mirë ndaj programuesit.
â
Surogatet
Biznesi nuk e do 1C dhe produktet e saj, zhvilluesit web, SMK, kontabilitetin, ekonomistët, projektet e zhvillimit, Scrum, TOS, kontrollet, KPI-të dhe sistemet e motivimit.
Biznesi favorizon rritjen e fitimeve përmes automatizimit, rritjen e qarkullimit nga promovimi në internet, përmirësimin e cilësisë së produkteve, një pamje të thjeshtë dhe të qartë të bizneseve përmes numrave, parashikime për gjendjen e kompanisë, një rritje të vërtetë të efikasitetit, përshpejtimin e realizimit të projekteve me 2-4 herë, një rritje të konsiderueshme të fitimeve dhe një reduktim të inventarëve, një sistem të saktë menaxhimi, një sistem të qartë dhe të kuptueshëm për vlerësimin e gjendjes në biznes, një sistem vlerësimi të punës që lejon shkarkimin e gjysmës së menaxherëve.
Biznesi dëshiron të arrijë qëllimet e tij. Biznesi nuk do surrogatet.
Surrogat është kur kërkohet arritja e një qëllimi biznesi, por merrni një projekt automatizimi, një faqe interneti, një hell të dokumenteve, një staf të paqartë ose raporte të pakuptueshme.
Surrogat është kur qëllimi zëvendësohet në rrugë me mjetin për ta arritur. Ndërsa për qëllimin, të gjithë harrojnë.
Prodhimi i surrogatëve mbështetet në tre shtylla: formalizmi, gradualizmi dhe garantimi i rrethit.
Formalizmi Ă«shtĂ« transferimi i qĂ«llimeve nĂ« letĂ«r me dekompozim. NĂ« thelb, Ă«shtĂ« zhvendosja e fokusit nga njĂ« qĂ«llim tĂ« madh nĂ« detaje tĂ« vogla. Askush nuk e mban mend qĂ«llimin â tĂ« gjithĂ« diskutojnĂ« detajet.
Gradualizmi është një shpejtësi e ulët kalimi nga qëllimet në mjete. Në fillim, qëllimi shpesh diskutohet ende. Por gradualisht, hap pas hapi, përmendet gjithnjë e më pak. Derisa porositësi ta harrojë atë, duke u zhytur në detaje.
Rrethimi është në atë që të gjithë kontraktuesit veprojnë në një mënyrë të ngjashme. Nuk ka asnjë automatizues që vërtet rrit fitimin. Prandaj, porositësi nuk ka vërtet shumë mundësi.
ĂfarĂ« tĂ« bĂ«jmĂ«?
TĂ« shmangim surrogatĂ«t dhe hapat e parĂ« nĂ« rrugĂ«n e krijimit tĂ« tyre: formalizmi. TĂ« paktĂ«n nĂ« projektet e brendshme. Vendosni njĂ« qĂ«llim dhe flisni vazhdimisht me ekzekutuesin pĂ«r tĂ«. Po ashtu edhe pĂ«r shkallĂ«t, burimet, planet etj. Por mĂ« kryesorja â pĂ«r qĂ«llimin.
Në të kundërt, fokusi do të zhvendosej patjetër dhe do të merrni një tjetër surrogat.
â
Vladimir Klicko
Ka njĂ« boksier â Vladimir Klicko. Ai ka njĂ« veçori â pĂ«rdorimin e vazhdueshĂ«m tĂ« gjebit. Pra, mĂ« tĂ« vazhdueshĂ«m se boksierĂ«t e tjerĂ«.
Gjebit vazhdimisht mban kundërshtarin nën tension, e rraskapiti.
Karakteristikat kryesore të gjebit të Klicko: thjeshtësia e ekzekutimit (relativisht, natyrisht) dhe vazhdimësia.
Shumë autorë flasin për faktin se veprime të thjeshta, të vazhdueshme dhe të dobishme mund të sjellin shumë përfitime.
Edhe unĂ« vendosa tĂ« provoj. Krijova njĂ« sistem tĂ« thjeshtĂ« pĂ«r tĂ« regjistruar â cilat detyra kam realizuar sot.
Ishte në fabrikë. I realizoja detyrat në drekë (nuk ha drekë), dmth 1 orë në ditë. Bëja atë që të tjerët nuk e bënin (thuhen se kjo çon në sukses).
Konfigurova verifikimet e sistemit vetë-mësues, mendova ide për zhvillim, realizova ide të tjera për zhvillim, konfigurova detyrat automatike, rifillova dhe optimizova kodin.
Ădo ditĂ« â çfarĂ«do detyre nga ky listĂ«. E realizova njĂ« detyrĂ« â super punĂ«. Mund tĂ« bĂ«j disa.
Aktivitetet i mbajta për 3 muaj. Gjatë kësaj kohe realizova 30 verifikime, mendova 200 ide, realizova 80 ide të tjera, ndërtova procese automatizimi për dy departamente, bëra tri optimizime të shkëlqyera.
E bukur, çfarë. Kjo është "ndërkohë". Të gjithëve ia rekomandoj.
â
Zëvendësimi fleksibël
Me termin «Scrum» përshkruhen të paktën dy entitete: filozofia dhe framework-u.
Filozofia, ose qasja ndaj punës, është e përshkruar në librin e Jeff Sutherland.
Framework-u, dmth algoritmi i veprimeve, është i përshkruar në dokumentin e titulluar Scrum Guide.
Filozofia u shndërrua në një kornizë sepse autorët e filozofisë donin të fitonin para nga ajo (për të thënë në fjalët e tyre).
Korniza është shumë më e thjeshtë krahasuar me filozofinë. E rëndësishmja është se është e thjeshtëzuar, dhe saktësisht, qëllimi është hequr.
Qëllimi i filozofisë: përshpejtimi i arritjes së rezultateve. Madje, disa herë më shumë. Në libër ka shembuj të një përshpejtimi deri në 8 herë.
QĂ«llimi i kornizĂ«s: qĂ« ju tĂ« keni Scrum. Aty shkruhet: NĂ«se veproni sipas udhĂ«zimeve â keni Scrum, nĂ«se shkelni udhĂ«zimin â nuk keni Scrum.
Korniza nuk parashikon përshpejtimin e arritjes së rezultateve, fare.
Njerëzit që i japin mësim ose implementojnë Scrum punojnë me kornizën. Ata tregojnë dhe implementojnë një algoritem që nuk çon në asnjë rezultat, përveç 'tani kemi Scrum'.
Thelbi është i qartë. Të shesësh filozofi është shumë e vështirë. Korniza është më e lehtë.
Korniza është një produkt. Ajo, siç duhet, ka kaluar 'paketimin'. Ajo është e thjeshtë, e kuptueshme, ka mbështetje dhe shumë specialistë. A nuk ju kujton diçka?
TĂ« gjitha janĂ« mirĂ«, pĂ«rveç rezultateve â ato nuk ekzistojnĂ«.
Nëse klienti nuk është i njohur me filozofinë e Scrum, atëherë implementimi i kornizës do ta kënaqë atë.
NĂ«se klienti Ă«shtĂ« i njohur me filozofinĂ« Scrum, ai do tĂ« pĂ«rjetojĂ« zhgĂ«njim nga implementimi i kĂ«tij framework-u â nuk do tĂ« ketĂ« asnjĂ« pĂ«rshpejtim nĂ« arritjen e rezultateve.
Do të jetë interesante, moderne, por asnjë objektiv biznesi nuk do të arrihet (përveç shpenzimit të buxhetit për "diçka të re").
ĂfarĂ« tĂ« bĂ«sh? TĂ« studosh filozofinĂ« Scrum. Ajo bazohet nĂ« filozofinĂ« japoneze tĂ« menaxhimit tĂ« cilĂ«sisĂ«, e cila ka si thelb: matjet dhe pĂ«rmirĂ«simet e pafundme.
FatkeqĂ«sisht, aty duhet tĂ« mendosh shumĂ«, tĂ« eksperimentosh, tĂ« vĂ«sh re dhe, pĂ«r fat tĂ« keq, tĂ« punosh. NĂ«se kjo nuk i pĂ«rshtatet â merr framework-un.
â
Burimi: habr.com
