Epigrafo:
La edzo, rigardante la malpurajn infanojn, diras al sia edzino: nu, ĉu ni lavu tiujn aŭ nasku novajn?
Sub la tranĉo estas la dua parto de artikolo de nia teamgvidanto, same kiel Direktoro de RAS-Produkta Disvolviĝo Igor Marnat, pri la proprecoj de instigi programistojn. La unua parto de la artikolo troviĝas ĉi tie -
En la unua parto de la artikolo, mi tuŝis la du malsuperajn nivelojn de la piramido de Maslow: fiziologiaj bezonoj, bezonoj de sekureco, komforto kaj konstanteco kaj transiru al la sekva, tria nivelo, nome:
III - Bezono de aparteno kaj amo
Mi sciis, ke la itala mafio nomiĝas “Cosa Nostra”, sed mi estis tre impresita kiam mi eksciis, kiel estas tradukita “Cosa Nostra”. "Cosa Nostra" tradukita el la itala signifas "Nia Komerco". La elekto de nomo estas tre sukcesa por instigo (ni lasu flanken la okupon, ĉi-kaze nin interesiĝas nur pri instigo). Homo kutime volas esti parto de teamo, fari iun grandan, komunan, nian komercon.
Granda graveco estas metita por kontentigi la bezonon de aparteno kaj amo en la armeo, mararmeo, kaj ajnaj grandaj miliciaj formacioj. Kaj, kiel ni vidas, en la mafio. Tio estas komprenebla, ĉar necesas devigi homojn, kiuj havas malmulte da komunaĵo, kiuj komence ne formas teamon de samideanoj, kiuj estas kunigitaj per deviga militservo (ne memvole), kiuj havas malsamajn edukajn nivelojn, malsamajn personajn valorojn. , por laŭvorte dediĉi siajn vivojn, je mortiga risko, al iu komuna afero , konfidu vian vivon al kamarado en armiloj.
Ĉi tio estas tre forta instigo; por plej multaj homoj estas ege grave senti, ke ili apartenas al io pli granda, scii ke vi estas parto de familio, lando, teamo. En la armeo, uniformoj, diversaj ritoj, paradoj, marŝoj, standardoj, ktp servas ĉi tiujn celojn. Proksimume la samaj faktoroj estas gravaj por iu teamo. Simboloj, kompania marko kaj kompaniaj koloroj, ekipaĵo kaj suveniroj estas gravaj.
Gravas, ke signifaj eventoj havas sian propran videblan enkorpiĝon kun kiu ili povas esti asociitaj. Nuntempe, estas prefere la normo por firmao havi siajn proprajn varojn, jakojn, T-ĉemizojn, ktp. Sed ankaŭ gravas reliefigi la teamon ene de la kompanio. Ni ofte liberigas T-ĉemizojn bazitajn sur la rezultoj de liberigo, kiuj estas donitaj al ĉiuj partoprenantoj en la liberigo. Iuj eventoj, komunaj festoj aŭ agadoj kun la tuta teamo estas alia grava faktoro de instigo.
Krom eksteraj atributoj, pluraj aliaj faktoroj influas la senton de aparteno al teamo.
Unue, la ĉeesto de komuna celo, kiun ĉiuj komprenas kaj kundividas takson de ĝia graveco. Programistoj kutime volas kompreni, ke ili faras bonegan aferon, kaj ili faras ĉi tiun bonegan aferon kune, kiel teamo.
Due, la teamo devas havi komunikadan spacon en kiu la tuta teamo ĉeestas kaj kiu apartenas nur al ĝi (ekzemple babilejo en la mesaĝisto, periodaj teamsinkapoj). Krom laborproblemoj, neformala komunikado, foje diskuto pri eksteraj eventoj, lumo ekstere - ĉio ĉi kreas senton de komunumo kaj teamo.
Trie, mi reliefigus la enkondukon de bonaj inĝenieraj praktikoj ene de la teamo, la deziron altigi normojn kompare kun tiuj akceptitaj en la kompanio. Efektivigi la plej bonajn alirojn akceptitajn en la industrio, unue en la teamo, kaj poste en la kompanio entute, donas al la teamo la ŝancon senti, ke ĝi estas antaŭ aliaj iel, gvidante la vojon, ĉi tio kreas senton de aparteno. al bonega teamo.
La sento de aparteno ankaŭ estas influita per la partopreno de la teamo en planado kaj administrado. Kiam teamanoj estas implikitaj en diskutado de projektceloj, laborplanoj, teamnormoj kaj inĝenieristikpraktikoj, kaj intervjuado de novaj dungitoj, ili disvolvas senton de partopreno, komuna posedo kaj influo sur la laboro. Homoj multe pli pretas plenumi decidojn faritajn kaj esprimitajn de si mem ol tiujn proponitajn de aliaj, eĉ se ili estas praktike agordaj.
Naskiĝtagoj, datrevenoj, signifaj eventoj en la vivo de kolegoj - komuna pico, malgranda donaco de la teamo donas varman senton de implikiĝo kaj dankemo. En iuj kompanioj, estas kutime doni malgrandajn memorsignojn por 5, 10, 15 jaroj da laboro en la firmao. Unuflanke, mi ne pensas, ke tio tiom motivas min por novaj atingoj. Sed, evidente, preskaŭ ĉiuj ĝojos, ke ili ne forgesis pri li. Ĉi tiu estas unu el tiuj kazoj kiam la foresto de fakto malmotivigas prefere ol ĝia ĉeesto instigas. Konsentu, povas esti sufiĉe domaĝe, se LinkedIn memorigis vin matene kaj gratulus vin pro via 10-a datreveno ĉe via laborloko, sed eĉ unu kolego de la kompanio ne gratulus vin aŭ memoris vin.
Kompreneble, grava punkto estas la ŝanĝo en la konsisto de la teamo. Estas klare, ke eĉ se la alveno aŭ foriro de iu el la teamo estas anoncita anticipe (ekzemple en bulteno de kompanio aŭ teama, aŭ ĉe teamkunveno), tio ne precipe motivas iun ajn al novaj atingoj. Sed se unu belan tagon vi vidas novan homon apud vi, aŭ ne vidas maljunan, ĝi povas esti surprizo, kaj se vi foriras, tute malagrabla. Homoj ne devus malaperi trankvile. Precipe en distribuita teamo. Precipe se via laboro dependas de kolego de alia oficejo, kiu subite leviĝis kaj malaperis. Tiaj momentoj certe indas informi la teamon aparte anticipe.
Grava faktoro, kiu en la angla nomiĝas posedo (la laŭvorta traduko de "posedo" ne plene reflektas ĝian signifon). Ĉi tio ne estas sento de posedo, sed prefere sento de respondeco por via projekto, tiu sento kiam vi emocie asocias vin kun la produkto kaj la produkton kun vi mem. Ĉi tio proksimume respondas al la preĝo de la marsoldato en la filmo "Full Metal Jacket": "Jen mia fusilo. Estas multaj tiaj fusiloj, sed ĉi tiu estas mia. Mia fusilo estas mia plej bona amiko. Ŝi estas mia vivo. Mi devas lerni posedi ĝin same kiel mi posedas mian vivon. Sen mi, mia fusilo estas senutila. Mi estas senutila sen mia fusilo. Mi devas pafi mian fusilon rekte. Mi devas pafi pli precize ol la malamiko, kiu provas mortigi min. Mi devas pafi lin antaŭ ol li pafos min. Estu tiel..."
Kiam homo laboras pri produkto dum longa tempo, havas la ŝancon porti plenan respondecon pri ĝia kreado kaj evoluo, por vidi kiel funkcianta afero ŝprucas de "nenio", kiel homoj uzas ĝin, ĉi tiu potenca sento estiĝas. Produktteamoj kiuj laboras kune dum longa tempo en unu projekto estas kutime pli motivitaj kaj koheziaj ol teamoj kiuj estas kunvenitaj por mallonga tempodaŭro kaj laboras en muntaĉena reĝimo, ŝanĝante de unu projekto al alia, sen plena respondeco por la tuta produkto. , de komenco ĝis fino.
IV. Bezono de rekono
Afabla vorto ankaŭ plaĉas al la kato. Ĉiu estas motivita de rekono de la graveco de la laboro, kiun ili faris kaj ĝia pozitiva takso. Parolu al programistoj, donu al ili periodajn sugestojn, festi bone faritan laboron. Se vi havas grandan kaj distribuitan teamon, periodaj renkontiĝoj (kion oni nomas unu al unu) estas perfektaj por tio; se la teamo estas tre malgranda kaj laboras kune loke, ĉi tiu ŝanco estas kutime provizita sen specialaj renkontiĝoj en la kalendaro (kvankam perioda unu). al unu estas ĉio Ĝi ankoraŭ bezonas, vi simple povas fari ĝin malpli ofte). Ĉi tiu temo estas bone kovrita en podkastoj por administrantoj ĉe manager-tools.com.
Tamen, indas konservi kulturajn diferencojn en menso. Iuj aliroj konataj al usonaj kolegoj ne ĉiam funkcios kun rusaj. La nivelo de ĝentileco akceptita en ĉiutaga komunikado en teamoj en okcidentaj landoj komence ŝajnas troa al programistoj el Rusio. Iu simpleco karakterizaĵo de rusaj kolegoj povas esti perceptita kiel malĝentileco fare de iliaj kolegoj de aliaj landoj. Ĉi tio estas tre grava en komunikado en interetna teamo; multe estis skribita pri ĉi tiu temo; la administranto de tia teamo devas memori tion.
Karakterizaĵoj, kie programistoj montras funkciojn evoluigitajn dum sprinto, estas bona praktiko por realigi ĉi tiun bezonon. Krom la fakto, ke ĉi tio estas bonega okazo por malbari komunikajn kanalojn inter teamoj, konigi produktmanaĝerojn kaj testistojn al novaj funkcioj, ĝi ankaŭ estas bona ŝanco por programistoj montri la rezultojn de sia laboro kaj indiki ilian aŭtorecon. Nu, kaj poluru viajn publikajn parolkapablojn, kompreneble, kio neniam estas malutila.
Estus bone festi la signifan kontribuon de aparte eminentaj kolegoj per atestiloj, memorsignoj (almenaŭ afabla vorto) ĉe komunaj teamaj renkontiĝoj. Homoj kutime tre taksas tiajn atestojn kaj memorajn ŝildojn, kunportas ilin dum moviĝado, kaj ĝenerale prizorgas ilin laŭ ĉiuj eblaj manieroj.
Por marki pli signifan, longperspektivan kontribuon al la laboro de la teamo, amasigitan sperton kaj kompetentecon, oni ofte uzas gradan sistemon (denove, analogio povas esti desegnita kun la sistemo de militaj rangoj en la armeo, kiu krome. por certigi subigon, ankaŭ servas ĉi tiun celon). Ofte junaj programistoj laboras duoble pli malfacile por akiri novajn stelojn sur siaj ŝultrorimenoj (t.e. moviĝi de juniora programisto al plentempa programisto, ktp.).
Koni la atendojn de viaj homoj estas kritika. Iuj estas pli verŝajne instigitaj de alta grado, la ŝanco esti nomataj, ekzemple, arkitekto, dum aliaj, male, estas indiferentaj al gradoj kaj titoloj kaj konsideros plialtiĝon de salajro signo de rekono de la kompanio. . Komuniku kun homoj por kompreni kion ili volas kaj kiaj estas iliaj atendoj.
Demonstro de rekono, pli alta nivelo de fido flanke de la teamo, povas esti donita donante pli da libereco de agado aŭ implikiĝo en novaj laborfakoj. Ekzemple, post akiri certan sperton kaj atingi certajn rezultojn, programisto, krom efektivigi siajn funkciojn laŭ la specifo, povas labori pri la arkitekturo de novaj aferoj. Aŭ engaĝiĝu en novaj areoj, kiuj eble ne rekte rilatas al evoluo - testa aŭtomatigo, efektivigado de plej bonaj inĝenieraj praktikoj, helpado pri eldono-administrado, parolado ĉe konferencoj ktp.
V. La bezono de ekkono kaj memrealigo.
Multaj programistoj koncentriĝas pri malsamaj specoj de programaj agadoj en malsamaj stadioj de siaj vivoj. Iuj homoj ŝatas fari maŝinlernadon, evoluigi novajn datummodelojn, legi multe da scienca literaturo por laboro kaj krei ion novan de nulo. Alia estas pli proksima al elpurigado kaj subtenado de ekzistanta aplikaĵo, en kiu vi devas profundigi la ekzistantan kodon, studi protokolojn, stakigi spurojn kaj retkaptojn dum tagoj kaj semajnoj, kaj skribi preskaŭ neniun novan kodon.
Ambaŭ procezoj postulas grandan intelektan penon, sed ilia praktika produktado estas malsama. Estas kredite ke programistoj estas malvolontaj subteni ekzistantajn solvojn; ili estas prefere instigitaj por evoluigi novajn. Estas grajno de saĝeco en ĉi tio. Aliflanke, la plej motivita kaj kunigita teamo kun kiu mi iam laboris estis dediĉita al subteni ekzistantan produkton, trovi kaj ripari cimojn post kiam la subtena teamo kontaktis ilin. La uloj laŭvorte vivis por ĉi tiu laboro kaj estis pretaj eliri sabate kaj dimanĉe. Ni iam avide traktis alian urĝan kaj kompleksan problemon, ĉu vespere de la 31-a de decembro, ĉu posttagmeze de la 1-a de januaro.
Pluraj faktoroj influis tiun altan instigon. Unue, ĝi estis kompanio kun granda nomo en la industrio, la teamo asociis sin kun ĝi (vidu "La Bezono de Aliĝo"). Due, ili estis la lasta limo, estis neniu malantaŭ ili, ekzistis neniu produktteamo en tiu tempo. Inter ili kaj la klientoj estis du niveloj de subteno, sed se la problemo atingis ilin, estis nenie por retiriĝi, neniu estis malantaŭ ili, la tuta korporacio estis sur ili (kvar junaj programistoj). Trie, ĉi tiu granda firmao havis tre grandajn klientojn (landaj registaroj, aŭtomobilaj kaj aviadaj konzernoj, ktp.) kaj tre grandskalajn instalaĵojn en pluraj landoj. Kiel rezulto, ĉiam kompleksaj kaj interesaj problemoj, simplaj problemoj estis solvitaj per la subteno de antaŭaj niveloj. Kvare, la instigo de la teamo estis multe influita de la profesia nivelo de la subtena teamo kun kiu ili interagis (estis tre spertaj kaj teknike kapablaj inĝenieroj), kaj ni ĉiam estis fidindaj pri la kvalito de la datumoj kiujn ili preparis, la analizo kiun ili faris. , ktp. Kvine, kaj mi pensas, ke ĉi tio estas la plej grava punkto - la teamo estis tre juna, ĉiuj uloj estis komence de siaj karieroj. Ili interesiĝis pri studado de granda kaj kompleksa produkto, solvante gravajn problemojn, kiuj estis novaj por ili en nova medio, ili serĉis profesie egali la nivelon de la ĉirkaŭaj teamoj, problemoj kaj klientoj. La projekto montriĝis bonega lernejo, ĉiuj poste faris bonan karieron en la kompanio kaj fariĝis teknikaj gvidantoj kaj altrangaj administrantoj, unu el la uloj nun estas teknika manaĝero ĉe Amazon Web Services, la alia finfine translokiĝis al Guglo, kaj ĉiuj. el ili ankoraŭ memoras ĉi tiun projekton kun varmo.
Se ĉi tiu teamo konsistus el programistoj kun 15-20 jaroj da sperto malantaŭ ili, la instigo estus malsama. Aĝo kaj sperto ne estas, kompreneble, 100% determinaj faktoroj; ĉio dependas de la strukturo de instigo. En ĉi tiu aparta kazo, la deziro por scio kaj kresko de junaj programistoj donis bonegajn rezultojn.
Ĝenerale, kiel ni jam plurfoje menciis, vi devas koni la atendojn de viaj programistoj, kompreni, kiuj el ili ŝatus vastigi aŭ ŝanĝi sian agadkampon, kaj konsideri ĉi tiujn atendojn.
Preter la piramido de Maslow: videbleco de rezultoj, ludado kaj konkurenco, neniu fiaĵo
Estas tri pli gravaj punktoj pri la instigo de programistoj, kiuj nepre devas esti menciitaj, sed entiri ilin en la modelon de bezonoj de Maslow estus tro artefarita.
La unua estas la videbleco kaj proksimeco de la rezulto.
Programaro-disvolviĝo estas kutime maratono. La rezultoj de R&D klopodoj iĝas videblaj post monatoj, foje jaroj. Estas malfacile iri al celo, kiu estas multe preter la horizonto, la kvanto de laboro estas terura, la celo estas malproksima, ne klara kaj ne videbla, "la nokto estas malluma kaj plena de hororoj." Pli bone estas rompi la vojon al ĝi en partojn, fari vojon al la plej proksima arbo, kiu estas videbla, atingebla, la konturoj estas klaraj, kaj ĝi ne estas malproksime de ni - kaj iru al ĉi tiu proksima celo. Ni volas klopodi plurajn tagojn aŭ semajnojn, akiri kaj taksi la rezulton, poste pluiri. Sekve, indas rompi la laboron en malgrandajn partojn (sprintoj en lertaj bone utilas ĉi tiun celon). Ni kompletigis parton de la laboro - registris ĝin, elspiris, diskutis ĝin, punis la kulpulojn, rekompencis la senkulpulojn - ni povas komenci la sekvan ciklon.
Ĉi tiu instigo estas iagrade simila al tio, kion ludantoj spertas dum kompletigado de komputilaj ludoj: ili periode ricevas medalojn, poentojn, gratifikojn dum ili kompletigas ĉiun nivelon; tio povas esti nomita "dopamina instigo".
Samtempe, la videbleco de la rezulto estas laŭvorte grava. Fermita funkcio en la listo devus fariĝi verda. Se la kodo estas skribita, provita, liberigita, sed ne estas ŝanĝo en la vida statuso videbla por la programisto, li sentos nekompleta, ne estos sento de kompletigo. En unu el la teamoj en nia versio-kontrolsistemo, ĉiu flikaĵo trapasis tri sinsekvajn stadiojn - la konstruo estis kunvenita kaj la testoj pasis, la flikaĵo pasis la kodrevizion, la flikaĵo estis kunfandita. Ĉiu stadio estis vide markita per verda iksodo aŭ ruĝa kruco. Unufoje unu el la programistoj plendis, ke la koda revizio daŭris tro longe, kolegoj bezonis akceli, diakiloj pendis dum pluraj tagoj. Mi demandis, kion tio efektive ŝanĝas por li? Post ĉio, kiam la kodo estas skribita, la konstruo estas kunvenita kaj la testoj pasis, li ne bezonas atenti la senditan diakilon se ne estas komentoj. Kolegoj mem revizios kaj aprobos ĝin (se, denove, ne estas komentoj). Li respondis: "Igor, mi volas ricevi miajn tri verdajn iksodojn kiel eble plej baldaŭ."
La dua punkto estas ludado kaj konkurado.
Disvolvante unu el la produktoj, nia inĝenieristiko celis preni elstaran pozicion en la komunumo de unu el la malfermfontaj produktoj, por eniri la suprajn 3-ojn. En tiu tempo, ekzistis neniu objektiva maniero taksi ies videblecon en la komunumo; ĉiu el la grandaj partoprenantaj kompanioj povis aserti (kaj periode asertis) ke ĝi estas la numero unu kontribuanto, sed ekzistis neniu reala maniero kompari la kontribuojn de partoprenantoj. inter si, por taksi ĝian dinamikon ĝustatempe. Sekve, ekzistis neniu maniero fiksi celon por la teamo, kiu povus esti mezurita ĉe kelkaj papagoj, taksi la gradon de ĝia atingo, ktp. Por solvi ĉi tiun problemon, nia teamo evoluigis ilon por mezuri kaj bildigi la kontribuon de kompanioj kaj individuaj kontribuantoj . El instiga vidpunkto, ĝi montriĝis nur bombo. Ne nur inĝenieroj kaj teamoj konstante monitoris sian progreson kaj la progreson de siaj kolegoj kaj konkurantoj. La supera administrado de nia kompanio kaj ĉiuj ĉefaj konkurantoj ankaŭ komencis sian tagon kun stackalytics. Ĉio fariĝis tre travidebla kaj vidata, ĉiu povis zorge kontroli sian progreson, kompari kun kolegoj ktp. Fariĝis oportune kaj facile por inĝenieroj, administrantoj kaj teamoj fiksi celojn.
Grava punkto, kiu aperas kiam oni efektivigas iun ajn sistemon de kvantaj metrikoj, estas, ke tuj kiam oni ilin efektivigis, la sistemo aŭtomate klopodas por prioritati la atingon de ĉi tiuj kvantaj metrikoj, malprofite de kvalitaj. Ekzemple, la nombro da kodaj recenzoj kompletigitaj estas uzata kiel unu el la metrikoj. Evidente, koda revizio povas esti farita en malsamaj manieroj, vi povas pasigi plurajn horojn por ĝisfunda revizio kaj kontrolo de kompleksa flikaĵo kun kontrolado de testoj, kurante ĝin sur via benko, kontrolante kun dokumentado, kaj ricevi pli unu revizion en via karmo, aŭ blinde klaku kelkajn dekduojn en kelkaj minutoj, donu al ĉiu +1 kaj ricevu plus dudek en karmo. Estis komikaj kazoj kiam inĝenieroj klakis sur flikaĵoj tiel rapide ke ili donis +1 al aŭtomataj flikoj de la CI-sistemo. Kiel ni poste ŝercis, "iru, iru, jenkins." En la kazo de kommits, estis ankaŭ multaj homoj, kiuj trarigardis la kodon per kodoformataj iloj, redaktis komentojn, ŝanĝis periodojn al komoj, kaj tiel pumpis sian karmon. Trakti ĉi tion estas sufiĉe simpla: ni uzas komunan prudenton kaj, krom kvantajn metrikojn, ankaŭ uzas esencajn, kvalitajn. La grado de uzo de la rezultoj de la laboro de la teamo, la nombro da eksteraj kontribuantoj, la nivelo de testa kovrado, la stabileco de moduloj kaj la tuta produkto, la rezultoj de skalo kaj agado-testado, la nombro da inĝenieroj kiuj ricevis kernan reviziiston ŝultro rimenoj, la fakto, ke projektoj estis akceptitaj en la kernprojektan komunumon, plenumo de la kriterioj de malsamaj etapoj de la inĝenieristiko - ĉiuj ĉi tiuj kaj multaj aliaj faktoroj devas esti taksitaj kune kun simplaj kvantaj metrikoj.
Kaj fine, la tria punkto - Neniu fiaĵo.
Programistoj estas tre inteligentaj homoj kaj ekstreme logikaj en sia laborlinio. Ili pasigas 8-10 horojn tage konstruante longajn kaj kompleksajn logikajn ĉenojn, do ili vidas vundeblecojn en ili sur la flugo. Farante ion, ili, kiel ĉiuj aliaj, volas kompreni kial ili faras ĝin, kio ŝanĝiĝos por pli bone. Estas ege grave, ke la celoj, kiujn vi fiksas por via teamo, estu honestaj kaj realismaj. Provi vendi malbonan ideon al programa teamo estas malbona ideo. Ideo estas malbona se vi mem ne kredas je ĝi, aŭ, en ekstremaj kazoj, vi ne havas la internan staton de malkonsento kaj engaĝiĝo (mi ne konsentas, sed mi faros ĝin). Ni iam efektivigis instigan sistemon en kompanio, unu el kies elementoj estis elektronika sistemo por doni retrosciigon. Ili investis multe da mono, prenis homojn al Ameriko por trejnado, ĝenerale, ili investis plene. Iam, en konversacio post la trejnado, unu el la administrantoj diris al siaj subuloj: “La ideo ne estas malbona, ŝajnas, ke ĝi funkcios. Mi mem ne donos al vi elektronikajn sugestojn, sed vi donas ĝin al viaj homoj kaj postulas ĝin de ili." Jen ĝi, nenio povus esti efektivigita plu. La ideo, kompreneble, finiĝis per nenio.
fonto: www.habr.com