La 21-22-an de marto 2019, miaj kolegoj kaj mi ĉeestis konferencon Lertaj Tagoj 2019, kaj mi ŝatus iom paroli pri ĝi.
Loko: Moskvo, Monda Komerca Centro
Kio estas AgileDays?
AgileDays estas ĉiujara konferenco pri lerta proceza administrado, nun en sia 13-a jaro. Se vi ne konas tiajn konceptojn kiel "plata organiza strukturo" kaj "teama mem-organizado", tiam mi konsilas vin legi pri Agile.
Kiel estis
La konferenco okazis dum du tagoj: ĵaŭdo kaj vendredo (konsentite, la sukcesa fino de la laborsemajno jam estas merkrede).
La konferenca programo konsistis el preskaŭ 100 raportoj kaj majstraj klasoj pri diversaj temoj. La prelegantoj estis dungitoj kaj administrantoj de diversaj kompanioj, kiuj sukcese uzas Agile-alirojn (ABBYY, Qiwi, HeadHunter, Dodo Pizza, ScrumTrek kaj aliaj).
Kutime, la prezento de unu preleganto daŭris 45 minutojn, fine de kiuj oni povis fari demandojn. Bedaŭrinde, estis fizike neeble ĉeesti ĉiujn raportojn - la prezentoj okazis samtempe en diversaj salonoj, do ĉiu el ni devis elekti kien iri (ni ne konsentis, sed ofte niaj interesoj koincidis).
Kiel elekti kien iri?
Antaŭ ĉio, ni koncentriĝis pri la temo de la raporto. Iuj el ili pli taŭgas por Scrum Masters, aliaj por Produktposedantoj. Estas ankaŭ tiuj, kiuj ĉefe interesas kompaniajn administrantojn. Mi ne scias kial, sed la parolado pri la temo estis elĉerpita "Kiel Mortigi Teamlaboron: Gvidilo de Manaĝero". Ŝajne, la organizantoj ne kalkulis pri tia ekscito, ĉar la prezentado estis en relative malgranda gazetara ĉambro (ĉiuj verŝajne volis rapide ekscii, kiel ili povus ruinigi siajn teamojn).
Inter paroladoj okazis kafo-paŭzoj, kie ni kunvenis kaj diskutis la prezentojn de la prelegantoj.
Kaj kiajn utilajn aferojn ni lernis?
Mi ne diros, ke la konferenco ŝanĝis mian opinion kaj devigis min rekonsideri la alirojn al nia laboro. Kvankam, plej verŝajne, ĝuste tio estus okazinta, se antaŭ unu jaro niaj kolegoj (aŭ pli ĝuste direktistoj) ankaŭ ne ĉeestis similan aranĝon, AgileDays 2018. Estis de tiu momento (eble eĉ iom pli frue) ke ni enŝipiĝis. la vojo de transformo laŭ Agile kaj provas apliki iujn principojn kaj alirojn kiuj estis diskutitaj ĉe la prezentoj.
Ĉi tiu konferenco helpis min meti en mian kapon ĉion pri kio mi aŭdis de la uloj antaŭe.
Jen la ĉefaj (sed ne ĉiuj) aliroj al laboro, kiujn la prelegantoj diskutis en siaj monologoj:
Produkta valoro
Ĉiu tasko, ĉiu funkcio liberigita por produktado devus porti certan avantaĝon kaj valoron. Ĉiu grupano devas kompreni kial kaj kial li faras tion. Ne necesas labori pro laboro, estas pli bone iri piedpilkon kun viaj kolegoj. (vi eble elpensos ion utilan dum vi piedbatas la pilkon).
Bedaŭrinde, en nia ŝtato. sektoro (kaj ni okupiĝas pri evoluo por registara kliento), ne ĉiam eblas determini la valoron de specifaj trajtoj. Foje tasko venas "de supre" kaj devas esti farita, eĉ se ĉiuj komprenas, ke ĝi estas nepraktika. Sed ni provos trovi tiun "produktan valoron" eĉ en tiaj situacioj.
Memorganizaj kaj aŭtonomaj teamoj
Oni multe atentis la memorganizadon de dungitoj kaj teamoj entute. Se administranto konstante staras super vi, disdonas taskojn, "piedfrapas vin" kaj provas kontroli ĉion, tiam nenio bona venos el ĝi. Estos malbone por ĉiuj.
Pli malfacile estos por vi kreski kaj disvolviĝi kiel bona specialisto, kaj iam la administranto ankoraŭ ne povos kontroli ĉiujn procezojn (iuj informoj estos distorditaj kiel "rompita telefono", dum aliaj tute malaperos de vido). Kio okazas kiam tia persono (manaĝero) ferias aŭ malsaniĝas? Ho mia Dio, laboro ĉesos sen li! (Mi ne pensas, ke tion ĉiuj volas).
Administranto devas povi fidi siajn dungitojn kaj ne provi esti "ununura enirpunkto" por ĉiuj. Dungitoj, siavice, devus provi preni iniciaton kaj montri sian intereson pri projektoj. Vidante ĉi tion, estos multe pli facile por la administranto eskapi totalan kontrolon super ĉiuj.
Aŭtonoma teamo estas antaŭ ĉio memorganizita teamo kapabla atingi fiksitajn celojn (projektojn). La teamo mem elektas la manierojn atingi ilin. Ŝi ne bezonas eksteran administranton, kiu diros al ŝi kion fari kaj kiel fari ĝin. Ĉiuj demandoj kaj problemoj estu diskutataj kune ene de la teamo. Jes, la teamo povas (kaj devas) iri al la administranto, sed nur se ĝi komprenas, ke ĉi tiu problemo ne povas esti solvita interne (ekzemple, necesas pliigi la rimedon de la teamo por sukcese kompletigi/kompletigi la projekton).
Ebena organiza strukturo
Malproksimiĝi de la principo "Mi estas la estro - vi estas subulo" havas tre utilan efikon al la klimato ene de la kompanio. Homoj komencas komuniki unu kun la alia pli libere, ili ĉesas konstrui konvenciajn limojn inter si "nu, li estas la estro."
Kiam kompanio aliĝas al la principo de "plata organiza strukturo", la pozicio fariĝas formalaĵo. La rolo de la persono, kiun li okupas en la teamo, komencas ekaperi, kaj ĝi povas esti malsama por ĉiuj: ĝi povas esti homo, kiu komunikas kun la kliento kaj kolektas postulojn de li; ĉi tio povus esti Scrum Master, kiu kontrolas la procezojn de la teamo kaj provas plibonigi kaj optimumigi ilin.
Teama instigo
La temo de dungita instigo ne pasis nerimarkita.
Salajro ne estas la sola kriterio, kiu instigas homon labori. Estas multaj aliaj aspektoj, kiuj kontribuas al produktiveco. Vi devas komuniki pli kun viaj dungitoj (ne nur ĉe la laboro), fidi ilin kaj peti iliajn opiniojn, kaj konstante doni komentojn. Estas bonege kiam teamo disvolvas sian propran "kompanian spiriton." Vi povas elpensi vian propran ekipaĵon, ekzemple logopitojn, T-ĉemizojn, ĉapojn (cetere, ni jam havas ĉi tion). Vi povas provi organizi kompaniajn eventojn, ekskursojn kaj aliajn aferojn.
Kiam homo estas agrabla kaj komforta laborante en teamo, tiam la laboro ŝajnas al li pli interesa, li ne havas la penson "Mi dezirus ke estis la 18:00 p.m., por ke mi povu eliri de ĉi tie."
Teama serĉado de novaj dungitoj
Ŝajnus, ke la serĉado de novaj dungitoj devas esti farita de la HR-servo (ĝuste por tio ili bezonas) kaj la manaĝero (li ankaŭ faru ion). Do kial la teamo mem partoprenu ĉi tion? Ŝi jam havas multan laboron por fari en la projekto. La respondo estas efektive simpla - neniu scias pli bone ol la teamo mem, kion ili volas ricevi de la kandidato. Dependas de la teamo labori kun ĉi tiu persono estonte. Do kial ne doni al ŝi la ŝancon fari ĉi tiun gravan elekton por ŝi?
Distribuita teamo
Jam estas la 21-a jarcento kaj tute ne necesas, ke ĉiu el ni iru al la oficejo je la 9-a matene (precipe se ni parolas pri la IT-industrio). Vi povas labori produktive de hejmo. Kaj se homo laboras hejme, kio malhelpas lin labori ankaŭ hejme, sed en alia urbo aŭ eĉ en alia lando? Ĝuste - nenio malhelpas.
La bona afero pri distribuita teamo estas, ke vi havas pli da ebloj por trovi la ĝustan dungiton laŭ la ĝustaj kriterioj (kapabloj, sperto, salajronivelo). Konsentu, la elekto de kandidatoj en tuta Rusio estos multe pli alta ol ene de la urbo sole. Ankaŭ la kostoj de tiaj dungitoj (oficeja prizorgado, ekipaĵo) estas signife reduktitaj.
Ankaŭ estas negativa aspekto en tia laboro - homoj ne vidas unu la alian. Estas tre malfacile labori kun iu, kiun vi ne konas persone. Regulaj videovokoj kaj periodaj komunaj kompaniaj eventoj (almenaŭ unufoje jare) povas facile solvi ĉi tiun problemon.
Malfermaj salajroj kaj aliaj financaj aferoj de la kompanio
Ĝi sonas sufiĉe nekutima, sed kredu min, ĝi funkcias en iuj kompanioj. La aliro estas, ke ĉiu dungito de la kompanio havas la ŝancon vidi kiom gajnas liaj kolegoj (! kaj eĉ kiom gajnas lia administrado).
Ĉi tio estas sufiĉe kompleksa procezo kaj por moviĝi al malfermaj salajroj vi devas moviĝi tre iom post iom. Antaŭ ĉio, necesas egaligi la salajrojn de dungitoj, por ke ne estu situacio, kie por la sama laboro Vasja ricevas 5 rublojn, kaj Petja ricevas eĉ 15. Vi devas esti preta por povi respondi demandojn de viaj. dungitoj kiel "Kial Petya gajnas pli ol mi?" .
Indas noti, ke salajra malkaŝo estas nur la pinto de la glacimonto. Estas multaj aliaj financaj indikiloj, kiuj estos utilaj kaj interesaj por ke dungitoj sciu.
Kaj fine (Tiel preskaŭ ĉiu parolanto finis sian paroladon): vi ne bezonas pensi, ke certa aliro al procezoj ene de kompanio kaj teamoj funkcios 100% por ĉiuj. Se ĉi tio estus tiel, ĉiuj sukcesus antaŭ longe. Vi devas kompreni, ke ni ĉiuj estas homoj kaj ni ĉiuj estas malsamaj. Ĉiu el ni bezonas individuan aliron. Sukceso kuŝas ĝuste en trovi ĉi tiun "via" ŝlosilon. Se vi ne komfortas labori en Scrum, ne devigu vin kaj vian teamon. Prenu Kanban ekzemple. Eble ĉi tio estas ĝuste tio, kion vi bezonas.
Provu, eksperimentu, faru erarojn kaj provu denove, kaj tiam vi certe sukcesos.
fonto: www.habr.com