Epigrafo:
Iam la Erinaco kaj la Urseto renkontis en la arbaro.
- Saluton, Erinaco!
- Saluton, Urseto!
Do, vorto post vorto, ŝerco post ŝerco, la Erinaco estis trafita en la vizaĝon de la Ursino...
Malsupre estas diskuto de nia teamgvidanto, same kiel Direktoro de RAS-Produkta Disvolviĝo Igor Marnat, pri la specifaĵoj de laborkonfliktoj kaj eblaj metodoj por administri ilin.
La plej multaj el la konfliktoj, kiujn ni renkontas en la laboro, evoluas laŭ scenaro simila al tiu priskribita en la supra epigrafo. Estas pluraj partoprenantoj, kiuj komence sufiĉe favore disponas unu al la alia; ili klopodas solvi iun aferon, sed fine la problemo restas nesolvita, kaj ial la rilatoj inter la partoprenantoj en la diskuto montriĝas difektitaj.
La vivo estas diversa, kaj variadoj okazas en la scenaro priskribita supre. Kelkfoje la rilato inter la partoprenantoj ne estas tre bona komence, foje eĉ ne estas afero, kiu postulas rektan solvon (kiel ekzemple en la epigrafo), foje post la diskuto la rilato restas la sama kiel antaŭ ol ĝi komenciĝis, sed la afero finfine ne estas solvita.
Kio estas komuna en ĉiuj situacioj, kiuj povas esti difinitaj kiel situacio de laborkonflikto?
Unue, estas du aŭ pli da flankoj. Ĉi tiuj partioj povas okupi malsamajn lokojn en la organizo, esti en rilato de egaleco (kolegoj en teamo), aŭ sur malsamaj niveloj de la hierarkio (estro - subulo), esti individua (dungito) aŭ grupa (en kazoj de konflikto inter dungito kaj teamo aŭ du teamoj), ktp. La verŝajneco de konflikto kaj la facileco de ĝia solvado estas tre influitaj de la nivelo de fido inter la partoprenantoj. Ju pli bone la partioj konas unu la alian, des pli alta estas la nivelo de fido, des pli alta estas la ŝanco ke ili venos al interkonsento. Ekzemple, membroj de distribuita teamo, kiuj neniam interagis vizaĝ-al-vizaĝe, pli verŝajne travivas konflikton pri simpla laborproblemo ol homoj, kiuj havis almenaŭ kelkajn vizaĝ-al-vizaĝajn interagojn. Tial, kiam vi laboras en distribuitaj teamoj, estas tre grave certigi, ke ĉiuj teamanoj periode renkontiĝas persone unu kun la alia.
Due, en situacio de konflikto sur la laboro, la partioj estas en situacio de solvado de iu afero, kiu estas grava por unu el la partioj, por ambaŭ, aŭ por la organizo entute. Samtempe, pro la specifaĵoj de la situacio, la partioj kutime havas sufiĉe da tempo kaj diversaj manieroj por solvi ĝin (formala, neformala, kunvenoj, leteroj, administraddecidoj, la ĉeesto de celoj kaj planoj de la teamo, la fakto de hierarkio, ktp.). Ĉi tio diferencas de la situacio solvi laboran (aŭ nelaboran) problemon en organizo de, ekzemple, solvi gravan demandon: "Eh, infano, el kiu areo vi estas?!" sur la strato, aŭ la konflikto el la epigrafo. En la kazo de solvado de laborproblemo, la kvalito de la laborprocezo kaj la kulturo de solvado de problemoj en la teamo gravas.
Trie, la determinanta faktoro de la konflikto (el la vidpunkto de nia diskuto) estas la fakto, ke la partioj en la procezo ne povas sendepende veni al solvo de la afero, kiu konvenas al ĉiuj partioj. La situacio postulas la intervenon de tria partio, ekstera arbitro. Ĉi tiu punkto povas ŝajni polemika, sed, esence, se la konflikta situacio estis sukcese solvita sen interveno de ekstera arbitracianto, la afero estis solvita sukcese kaj la rilatoj de la partioj ne malboniĝis, ĉi tiu estas la situacio al kiu ni devus strebi. . Ni plej verŝajne eĉ ne scios pri tia konflikto, aŭ ni hazarde ekscios, post kiam ĝi estos solvita. Ju pli da problemoj teamo povas solvi memstare, des pli efika ĝi estos.
Alia karakteriza trajto de la konflikto, kiun indas tuŝi, estas la grado de emocia intenseco dum la decido. Konflikto ne nepre rilatas al alta emocia nivelo. Partoprenantoj ne devas krii kaj svingi la brakojn por ke la situacio estu, esence, konflikto. La afero ne estas solvita, certa emocia streĉiĝo ĉeestas (eble ĝi ne estas klare esprimita ekstere), kio signifas, ke ni estas antaŭ situacio de konflikto.
Ĉu entute necesas interveni en konfliktaj situacioj, aŭ ĉu estas pli bone lasi ilian solvon fari sian kurson kaj atendi, ke la problemo solvu sin? Bezonas. Ne ĉiam estas en via povo aŭ kompetenteco solvi la konflikton tute, sed en ajna situacio, en konflikto de ajna skalo, vi povas preni plenkreskan pozicion, tiel venigante kelkajn pliajn homojn ĉirkaŭ vi al ĝi, mildigi la negativajn sekvojn de la konflikto kaj kontribui al ĝia solvo.
Antaŭ ol rigardi kelkajn ekzemplojn de konfliktsituacioj, ni rigardu kelkajn gravajn punktojn komunajn al ĉiuj konfliktoj.
Solvante konflikton, gravas esti super la batalo, kaj ne ene de ĝi (ĉi tio ankaŭ nomiĝas "preni metapozicion"), tio estas, ne esti parto de unu el la partioj en la solva procezo. Alie, havi eksteran arbitron asisti la decidon nur plifortigos la pozicion de unu el la partioj en malutilo de la alia partio. Dum decido, gravas, ke ĝi estas morale akceptita de ĉiuj partioj, kiel ili diras, "aĉetita". Tiel ke, eĉ se la partioj ne ĝojis pri la farita decido, ili almenaŭ sincere konsentis efektivigi ĝin. Kiel oni diras, povi malkonsenti kaj kompromiti. Alie, la konflikto simple ŝanĝos sian aspekton, la brulanta fajro restos sub la torfejo kaj iam neeviteble ekflamos denove.
La dua punkto, parte rilata al la unua, estas, ke se vi jam decidis partopreni en la solvado de la konflikto, prenu ĝin kiel eble plej serioze el la vidpunkto de komunikado kaj studado de la kunteksto. Parolu persone kun ĉiu el la partioj. Aparte kun ĉiu, por komenci. Ne kontentiĝi kun poŝto. En la kazo de distribuita teamo, almenaŭ parolu per video-ligo. Ne kontentiĝu pri onidiroj kaj ĉeestantaj raportoj. Komprenu la rakonton, kion ĉiu flanko volas, kial ili volas ĝin, kion ili atendas, ĉu ili provis solvi ĉi tiun problemon antaŭe, kio okazos se ĝi ne estas solvita, kiajn solvojn ili vidas, kiel ili imagas la pozicion de la alia flanko, kion ili opinias, ĝusta aŭ malĝusta, ktp. Ŝarĝu la tutan eblan kuntekston en vian kapon, kun malferma menso, supozante ke ĉiuj pravas. Vi ne estas ene de la konflikto, vi estas ekster ĝi, en metapozicio. Se la kunteksto disponeblas nur en afiŝofadeno, almenaŭ legu ĝin tute kaj la fadenojn kaj dokumentojn rilatajn al ĝi. Post kiam vi legis ĝin, ankoraŭ parolu per via voĉo. Vi preskaŭ garantias aŭdi ion gravan, kio ne estas en la poŝto.
La tria grava punkto estas la ĝenerala aliro al komunikado. Ĉi tiuj estas ordinaraj aferoj, nenio kosmaj, sed ili estas tre gravaj. Ni ne provas ŝpari tempon, ni parolas kun ĉiuj partoprenantoj, ni ne kritikas la homon, sed ni konsideras la sekvojn de liaj agoj (ne “vi estas malĝentila”, sed “eble la uloj povus ofendiĝi pro ĉi tiu afero"), ni donas la ŝancon savi vizaĝon, ni faras diskutojn persone, ne antaŭ la linio.
Konfliktoj estas kutime kaŭzitaj de unu el du kialoj. La unua rilatas al ĉu persono en la tempo de konflikto estas en la pozicio de plenkreskulo aŭ en la pozicio de infano (pli pri tio ĉi malsupre). Ĉi tio estas pro lia emocia matureco, la kapablo administri siajn emociojn (kiu, cetere, ne ĉiam rilatas al lia aĝo). La dua komuna kialo estas la neperfekteco de la laborprocezo, kiu kreas situaciojn de grizaj areoj en kiuj respondeco estas disvastigita inter partoprenantoj, la atendoj de la partioj ne estas travideblaj unu al la alia, kaj roloj en la procezo estas malklarigitaj.
Sekve, en solvado de konflikto (same kiel ajna alia afero), administranto devas memori tri perspektivojn: mallongperspektiva - por solvi la aferon/konflikton ĉi tie kaj nun, meztempe - por minimumigi la probablecon de alia konflikto estiĝanta. pro la sama kialo, kaj longtempe - kulturi plenkreskan kulturon en la teampersono.
Ĉiu el ni havas internan infanon, ĉirkaŭ tri aŭ kvar jarojn. Li dormas plejofte ĉe la laboro, sed foje vekiĝas kaj ekkontrolas. La infano havas siajn proprajn prioritatojn. Gravas por li insisti, ke tio estas lia sablokesto, lia patrino amas lin pli, lia maŝino estas la plej bona (la dezajno estas la plej bona, li programas la plej bonan, ...). En situacio de konflikto, infano povas premi ludilojn, piedpremi siajn piedojn kaj fendi sian spatelon, sed li ne povas solvi plenkreskajn problemojn (solvo-arkitekturo, aliroj al aŭtomata testado, eldondatoj ktp.), li ne pensas pri avantaĝoj. por la teamo. Infano en konflikto povas esti kuraĝigita, konsolita kaj sendita al lito petante lin voki sian plenkreskulon. Antaŭ ol komenci diskuton en konflikta situacio, certigu, ke vi parolas kun plenkreskulo, ne kun infano, kaj ke vi mem estas en la pozicio de plenkreskulo. Se via honesta celo nuntempe estas solvi gravan problemon, vi estas en la pozicio de plenkreskulo. Se via celo estas piedpremi viajn piedojn kaj fendi vian ŝultron, ĉi tio estas infana pozicio. Sendu vian internan infanon al lito kaj voku plenkreskulon, aŭ replanu la diskuton. Homo faras emocian decidon, kaj tiam serĉas racian pravigon por ĝi. Decido farita de infano surbaze de la prioritatoj de infanoj ne estos optimuma.
Krom konduto en la tempo de konflikto, la pozicio de infano aŭ plenkreskulo ankaŭ estas karakterizita per la nivelo de respondeco, kiun persono pretas preni sur sin. En ĝiaj ekstremaj manifestiĝoj, la infana pozicio de programisto, kiun mi renkontis pli ol unufoje, aspektas jene: mi skribis la kodon, sendis ĝin por revizio - mia laboro estas finita. Recenzistoj devus revizii ĝin kaj aprobi ĝin, QA devus kontroli ĝin, se estas problemoj, ili sciigos min. Sufiĉe strange, eĉ sufiĉe maturaj kaj spertaj homoj foje kondutas tiel. La alia fino de la skalo estas, ke persono konsideras sin respondeca por certigi, ke lia kodo funkcias, estas kovrita de testoj, estas persone kontrolita de li, sukcese trapasis la revizion (se necese, ne estas problemo pripingi recenzistojn, diskuti aferojn). per voĉo, ktp.) kaj estis subpremita, QA provizos helpon se necese, testscenaroj estos priskribitaj, ktp. En normalaj kazoj, la programisto aŭ komenciĝas pli proksime al la plenkreska fino de la skalo, aŭ moviĝas tien kiam li akiras sperton (kondiĉe ke la ĝusta kulturo estas kultivita ene de la teamo). En ekstremaj kazoj, li daŭre laboras, kutime prenante infanan pozicion, tiam li kaj la teamo periode havas problemojn kaj konfliktojn.
Kreski la ĝustan, maturan kulturon en teamo estas grava tasko por iu manaĝero. Ĝi bezonas longan tempon kaj ĉiutagan penadon, sed la rezulto valoras ĝin. Estas du manieroj influi teamkulturon - gvidi per ekzemplo (kiu certe estos sekvata; la teamo ĉiam rigardas la gvidanton) kaj diskuti kaj rekompenci la ĝustan konduton. Ankaŭ ĉi tie estas nenio abstrusa aŭ tre formala, nur dum diskutado de problemoj, rimarku, ke io povus esti farita ĉi tie, emfazu, ke vi rimarkis, kiam ĝi estis ĝuste decidita, laŭdu, notu dum la eldonrecenzo ktp.
Ni konsideru plurajn tipajn konfliktajn situaciojn, de simpla ĝis kompleksa:
Konfliktoj ne rilataj al laborproblemoj
Sufiĉe ofte estas konfliktoj en la laboro, kiuj ne rilatas al laboraj aferoj. Ilia okazo kaj facileco de rezolucio estas kutime rekte rilataj al la nivelo de emocia inteligenteco de la partoprenantoj, ilia nivelo de matureco, kaj ne rilatas al la perfekteco aŭ neperfekteco de la laborprocezo.
Tipaj ekzemploj: iu ne sufiĉe ofte uzas la lavmaŝinon aŭ duŝon, kion aliaj ne ŝatas, iu estas sufoka, dum aliaj ricevas venton se ili malfermas la fenestron, iu estas tro brua, kaj aliaj bezonas silenton por labori, kaj tiel plu. Estas pli bone ne prokrasti la solvon de tiaspecaj konfliktoj kaj ne lasi ilin fari sian kurson. Ili ne solvos per si mem kaj distros vin de laboro ĉiutage kaj venenos la etoson en la teamo. Feliĉe, solvi ilin kutime ne estas granda problemo - nur parolu trankvile (unu-kontraŭ-unu, kompreneble) kun kolego, kiu neglektas higienon, havigu komfortajn sidlokojn por homoj, kiuj preferas silenton/malvarmon, aĉetas sonsorbajn aŭdilojn aŭ instalu vadojn. , ktp.
Alia ekzemplo, kiun mi renkontis plurfoje dum mia laboro, estas la psikologia nekongrueco de teamanoj. Ial, homoj simple ne povas kunlabori; ĉiu interago finiĝas en skandalo. Foje tio estas pro la fakto, ke homoj havas polajn opiniojn pri iu urĝa afero (kutime politika) kaj ne scias kiel lasi ilin ekster la laboro. Konvinki ilin toleri unu la alian aŭ ŝanĝi sian konduton estas sufiĉe vana tasko. La sola escepto kiun mi renkontis estas junaj kolegoj kun malfermaj perceptoj; ilia konduto ankoraŭ povas esti iom post iom ŝanĝita per periodaj konversacioj. Kutime la problemo estas sukcese solvita disigante ilin en malsamajn teamojn, aŭ almenaŭ havigante la ŝancon interkovri ĉe la laboro tre malofte.
En ĉiuj ĉi-supraj situacioj, indas paroli kun ĉiuj partoprenantoj persone, diskuti la situacion, demandi ĉu ili entute vidas problemon en ĉi tiu kazo, demandi, kiuj, laŭ ilia opinio, estas la solvoj, kaj certigi ilian partoprenon en fari ĉi tion. decido.
El la vidpunkto de optimumigo de la laborprocezo (la mezperspektiva perspektivo, kiun mi menciis), ĉi tie ne multe povas fari; la nura punkto por optimumigo estas konsideri la kongruecfaktoron dum la formado de teamo kaj ne meti homojn. kune anticipe kiuj konfliktos.
El teamkultura perspektivo, tiaj situacioj aperas multe malpli ofte en teamoj kun matura kulturo, kie homoj respektas la teamon kaj kolegojn kaj scias kiel solvi problemojn sendepende. Krome, tiaj konfliktoj estas solvitaj multe pli facile (ofte aŭtomate) en teamoj kie estas alta nivelo de fido, homoj kunlaboris dum longa tempo kaj/aŭ komunikas ofte ekstere de laboro.
Konfliktoj rilataj al laborproblemoj:
Tiaj konfliktoj estas kutime kaŭzitaj de ambaŭ kialoj samtempe, ambaŭ emociaj (la fakto ke unu el la partoprenantoj ne estas en la pozicio de plenkreskulo) kaj la neperfekteco de la laborprocezo mem. Eble la plej ofta tipo de konfliktoj kiujn mi renkontis estas konfliktoj dum kodaj recenzoj aŭ arkitekturaj diskutoj inter programistoj.
Mi reliefigus du tipajn kazojn ĉi tie:
1) En la unua kazo, la programisto ne povas ricevi kodan revizion de kolego. La flikaĵo estas sendita por revizio, kaj nenio okazas. Unuavide, ne estas evidenta konflikto inter la du flankoj, sed se vi pensas pri tio, ĉi tio estas sufiĉe konflikto. La laborproblemo ne estas solvita, unu el la partioj (atendante revizion) spertas evidentan malkomforton. Ekstrema subtipo de ĉi tiu kazo estas evoluo en komunumo aŭ en malsamaj teamoj, dum la recenzisto eble ne interesiĝas pri ĉi tiu aparta kodo, pro ŝarĝo aŭ aliaj cirkonstancoj, eble tute ne atentas la revizian peton, kaj la ekstera arbitracianto. (manaĝero komuna al ambaŭ flankoj) ) eble tute ne ekzistas.
La solva aliro, kiu helpas en tia situacio, rilatas ĝuste al la longtempa perspektivo, la kulturo de plenkreskulo. Unue, inteligenta agado funkcias. Vi ne devus atendi, ke la kodo pendanta sur la recenzo altiros la atenton de la recenzisto mem. Ni devas helpi recenzistojn rimarki lin. Pingani paro da homoj, faru demandon pri sinkapo, partoprenas en diskutoj. Evidente, inciteco pli verŝajne damaĝas ol helpon, necesas uzi prudenton. Due, antaŭpreparo funkcias bone. Se la teamo komprenas, kio okazas kaj kial, kial ĉi tiu kodo entute bezonas, la dezajno estis diskutita kaj interkonsentita antaŭe kun ĉiuj, homoj pli verŝajne atentos tian kodon kaj akceptas ĝin por laboro. Trie, aŭtoritato funkcias. Se vi volas esti recenzita, faru mem multajn recenzojn. Faru altkvalitajn recenzojn, kun veraj kontroloj, realaj testoj kaj utilaj komentoj. Se via kromnomo estas konata en la teamo, estas pli granda ŝanco, ke via kodo estos rimarkita.
El laborflua vidpunkto, eblaj plibonigoj ĉi tie estas ĝusta prioritatado celanta helpi la programiston atingi siajn celojn kaj de la teamo (revizii aliajn, skribi leterojn al la komunumo, akompani la kodon kun arkitektura priskribo, dokumentado, testoj, partopreni diskutojn kun komunumo, ktp.), malhelpi flikojn pendi en la atendovico tro longe, ktp.
2) La dua ofta kazo de konfliktoj dum kodaj aŭ dezajnaj recenzoj estas malsamaj vidpunktoj pri teknikaj aferoj, kodigostilo kaj elekto de iloj. Gravas en ĉi tiu kazo la nivelo de fido inter la partoprenantoj, apartenanta al la sama teamo, kaj sperto kunlabori. Senelirejo okazas kiam unu el la partoprenantoj prenas infanecan pozicion kaj ne provas aŭdi tion, kion la interparolanto volas transdoni al li. Ofte, kaj la aliro proponita de la alia partio kaj la aliro proponita komence povas bone funkcii sukcese kaj principe ne gravas kiun elekti.
Iun tagon, programisto de mia teamo (ni nomu lin Paŝao) preparis diakilon kun ŝanĝoj al la paka disfalda sistemo, kiu estis evoluigita kaj subtenata de kolegoj de najbara fako. Unu el ili (Igor) havis sian propran fortan opinion pri ekzakte kiel Linuksaj servoj devus esti agordita dum deplojado de pakaĵoj. Ĉi tiu opinio diferencis de la aliro proponita en la peceto, kaj ili ne povis konsenti. Kiel kutime, la limdatoj finiĝis, kaj necesis fari ian decidon; necesis, ke unu el ili prenu plenkreskan pozicion. Paŝao rekonis, ke ambaŭ aliroj havas rajton al vivo, sed li volis ke lia elekto pasu, ĉar Nek unu nek la dua opcio havis evidentajn teknikajn avantaĝojn.
Nia diskuto aspektis tiel (tre skeme, kompreneble, la konversacio daŭris duonhoron):
- Paŝao, ni havas funkcion frostigi post kelkaj tagoj. Gravas, ke ni kolektu ĉion kaj komencu testi kiel eble plej baldaŭ. Kiel ni povas trairi Igor?
— Li volas alimaniere agordi servojn, li fiksis tie komentojn por mi...
- Kaj kio estas, grandaj ŝanĝoj, multe da tumulto?
- Ne, estas laboro dum kelkaj horoj, sed finfine ne estas diferenco, ĝi funkcios ambaŭflanke, kial tio necesas? Mi faris ion kiu funkcias, ni akceptu ĝin.
- Aŭskultu, kiom longe vi diskutas ĉion ĉi?
- Jes, ni jam markas tempon de unu semajno kaj duono.
- Um... ĉu ni povas solvi problemon en kelkaj horoj, kiu jam daŭris semajnon kaj duonon, kaj ne fari ĝin?
- Nu, jes, sed mi ne volas, ke Igor pensu, ke mi kolapsis...
- Aŭskultu, kio estas por vi pli grava, eldoni liberigon, kune kun via decido ene, aŭ mortigi Igoron? Ni povas bloki ĝin, tiam, tamen, estas bona ŝanco traflugi kun la liberigo.
- Nu... estus mojose, kompreneble, viŝi la nazon de Igor, sed bone, la liberigo estas pli grava, mi konsentas.
- Ĉu vere tiom gravas por vi, kion opinias Igor? Verdire, li tute ne zorgas, li nur volas unuecan aliron en malsamaj lokoj de la afero, pri kiu li respondecas.
- Nu, bone, mi faru kiel li petas en la komentoj kaj ni komencu testi.
- Dankon, Paŝao! Mi estis certa, ke el vi du vi estos la pli matura, kvankam Igorek estas pli aĝa ol vi :)
La afero estis solvita, la liberigo estis liberigita ĝustatempe, Paŝao ne sentis multe da malkontento, ĉar li mem proponis solvon kaj efektivigis ĝin. Igor estis ĝenerale kontenta, ĉar... Lia opinio estis enkalkulita kaj ili faris kiel li sugestis.
Alia speco de esence sama konflikto estas la elekto inter teknikaj solvoj/bibliotekoj/aliroj en projekto, precipe en distribuita teamo. En unu el la projektoj, kiu estis poziciigita kiel uzante C/C++, montriĝis, ke la teknika administrado de la projekto kategorie kontraŭis uzi STL (Norma Ŝablono-Biblioteko). Ĉi tio estas normlingva biblioteko, kiu simpligas evoluon, kaj nia teamo tre kutimas al ĝi. Montriĝis, ke la projekto estas multe pli proksima al C ol al C++, kio ne multe inspiris la teamon, ĉar administrado provis sian plej bonan kaj varbis vere bonegajn plus ludantojn. Samtempe, la usona parto de la teamo, kaj inĝenieroj kaj administrantoj, jam delonge laboris en la kompanio, alkutimiĝis al la ekzistanta stato de aferoj kaj estis feliĉa pri ĉio. La rusa parto de la teamo estis kunvenigita sufiĉe lastatempe, ene de kelkaj semajnoj (inkluzive de mi). La rusa parto de la teamo kategorie ne volis forlasi la kutiman aliron al disvolviĝo.
Senfinaj skribaj diskutoj komenciĝis inter la du kontinentoj, leteroj sur tri aŭ kvar ekranoj flugis tien kaj reen, en grupaj dissendoj kaj personaj, de programistoj ĝis programistoj kaj administrantoj. Kiel kutime, leteroj de tiu ĉi longeco estis legitaj de neniu krom la aŭtoroj kaj iliaj fervoraj subtenantoj. Babiladoj knaris pro streĉo, pasigante plurekranajn pensojn en malsamaj direktoj pri la teknikaj avantaĝoj de la STL, kiom bone elprovita ĝi estas, kiom sekura ĝi estas, kaj ĝenerale, kiel mirinda vivo estas kun ĝi, kaj kiom terura ĝi estas sen ĝi. .
Ĉio ĉi daŭris sufiĉe longe, ĝis mi finfine komprenis, ke ni diskutas la teknikajn aspektojn de la afero, sed la problemo fakte ne estis teknika. La problemo ne estas la avantaĝoj aŭ malavantaĝoj de STL aŭ la malfacileco labori sen ĝi. La problemo estas sufiĉe organiza. Ni nur bezonis kompreni kiel funkciis la firmao, por kiu ni laboris. Neniu el ni antaŭe havis sperton labori en tia firmao. La afero estis, ke post kiam la kodo estis evoluigita kaj liberigita en produktadon, subteno estis pritraktita de tute malsamaj homoj de aliaj teamoj, de aliaj landoj. Ĉi tiu grandega inĝenieristikteamo de pluraj dekoj da miloj da inĝenieroj (entute) povis pagi nur tute bazan minimumon de teknikaj rimedoj, por tiel diri, minimuman minimorumon. Ĉio, kio preterpasis la inĝenieran normon establitan en la firmao fizike, ne povus esti apogita en la estonteco. La nivelo de teamo estas determinita de la nivelo de siaj plej malfortaj membroj. Post kiam ni komprenis vera instigo agoj de la usona parto de la teamo, ĉi tiu afero estis forigita de la tagordo, kaj kune ni sukcese disvolvis kaj publikigis la produkton uzante la normojn adoptitajn de la kompanio. Leteroj kaj babiloj en ĉi tiu kazo ne funkciis bone; necesis pluraj vojaĝoj kaj multe da persona komunikado por veni al komuna denominatoro.
El la vidpunkto de la laborfluo, en ĉi tiu aparta kazo, helpus havi priskribon de la uzataj iloj, postuloj por ili, limigoj pri aldono de novaj kaj pravigo por tiaj limigoj. Tiaj dokumentoj proksimume respondas al tiuj priskribitaj en alineoj Reuzo-Strategio kaj Disvolva Medio de la "Manlibro de Administranto por Programaro-Evoluo", ellaborita en . Malgraŭ sia aĝo, ĝi perfekte priskribas ĉiujn ĉefajn agadojn kaj planajn stadiojn de ĉi tiu speco de programaro. Havi tiajn dokumentojn faciligas diskuti, kiaj komponantoj kaj aliroj povas esti uzataj en produkto, kaj kial.
El kultura vidpunkto, evidente, kun pli matura pozicio, en kiu la partioj provas aŭdi kaj kompreni la veran motivadon de la agoj de siaj kolegoj kaj agadi surbaze de la prioritatoj de la projekto kaj la teamo, kaj ne la persona egoo. , la konflikto estus solvita pli facile kaj pli rapide.
En alia konflikto pri la elekto de teknika solvo, ankaŭ mi bezonis rimarkindan tempon por kompreni la instigon de unu el la partioj (estis tre nekutima kazo), sed post kiam la instigo estis klara, la solvo estis evidenta.
La situacio estas jena: nova programisto aperas en teamo de ĉirkaŭ 20 homoj, ni nomu lin Staĉjo. En tiu tempo, nia norma ilo por komunikado kiel teamo estis Skajpo. Kiel montriĝis poste, Staĉjo estis granda ŝatanto de malfermaj normoj kaj malfermkoda programaro, kaj uzis nur ilojn kaj operaciumojn, kies fontoj estis publike haveblaj kaj kiuj uzis publike priskribitajn protokolojn. Skype ne estas unu el ĉi tiuj iloj. Ni pasigis multe da tempo diskutante la avantaĝojn kaj malavantaĝojn de ĉi tiu aliro, provojn lanĉi analogojn de Skype en malsamaj operaciumoj, la provoj de Stas konvinki la teamon ŝanĝi al aliaj normoj, skribi al li persone per poŝto, voki lin persone sur la telefono, aĉetu al li duan komputilon specife por Skajpo, ktp. Fine mi konstatis, ke ĉi tiu problemo, esence, ne estas teknika aŭ organiza, ĝi estas prefere ideologia, eĉ, oni povus diri, religia (por Staĉjo). Eĉ se ni finfine konektus Staĉjon kaj Skajpon (kiu daŭris plurajn monatojn), la problemo denove aperos ĉe iu ajn posta instrumento. Mi ne disponis pri realaj rimedoj por ŝanĝi la mondkoncepton de Staĉjo, kaj ne estis kialo por provi ŝanĝi la mondkoncepton de teamo, kiu perfekte funkciis en ĉi tiu medio. La persono kaj la firmao estis simple ortaj en sia mondkoncepto. En tiaj situacioj, bona solvo estas organiza. Ni translokigis Staĉjon al alia teamo, kie li estis pli organika.
La kialo de ĉi tiu konflikto, laŭ mi, estas la diferenco inter la persona kulturo de aparta persono (kiu havas fortan opinion, kiu ne permesas al li kompromisi) kaj la kulturo de la kompanio. En ĉi tiu kazo, ĝi estas, kompreneble, la eraro de la administranto. Estis komence malĝuste preni lin sur tia projekto. Staĉjo poste translokiĝis al projekto pri disvolvado de malfermkoda programaro kaj elstaris tie.
Bona ekzemplo de konflikto kaŭzita de kaj la infana sinteno de la programisto kaj la mankoj de la laborprocezo estas situacio en kiu, sen difino de farita, la programisto kaj la QA-teamo havas malsamajn atendojn pri la preteco de la funkcio transdonita al QA. La programisto kredis, ke sufiĉas skribi la kodon kaj ĵeti la funkcion trans la barilon al QA - ili ordigus ĝin tie. Sufiĉe matura kaj sperta programisto, cetere, sed tio estis lia interna sojlo por kvalito. QA malkonsentis kun tio kaj postulis montri kaj priskribi al ili tion, kion li kontrolis mem, kaj postulis testan manuskripton por ili. Ili havis problemojn kun funkcieco de ĉi tiu programisto en la pasinteco kaj ne volis perdi sian tempon denove. Cetere, ili pravis - la funkcio vere ne funkciis, li ne kontrolis la kodon antaŭ sendi ĝin al QA.
Por solvi la situacion, mi petis lin montri al mi, ke ĉio vere funkciis (ĝi ne funkciis, kaj li devis ripari ĝin), ni parolis kun la teamo kaj kun la QA-difino de farita (ili ne faris ĝin en verkado, ĉar ni ne volis tro burokratigi la procezon ), nu, ni baldaŭ disiĝis de tiu ĉi specialisto (al ĝenerala helpo).
De la vidpunkto de la laborfluo, eblaj plibonigoj en ĉi tiu kazo estas la ĉeesto de difino de farita, postuloj por subteno de ĉiu unuo-trajto kaj integrigaj testoj, kaj priskribo de testado farita de la programisto. En unu el la projektoj, ni mezuris la nivelon de koda kovrado per testoj dum CI kaj se la kovradnivelo malpliiĝis post aldoni diakilon, la testoj estis markitaj kiel malsukcesaj, t.e. ajna nova kodo povus esti aldonita nur se estis novaj testoj por ĝi.
Alia tipa ekzemplo de konflikto proksime rilatita al la organizo de la laborprocezo. Ni havas produkton, produktan teamon, subtenan teamon kaj klienton. La kliento havas problemojn kun la produkto kaj kontaktoj subteno. Subteno analizas la problemon kaj komprenas, ke la problemo estas en la produkto kaj transdonas la problemon al la produkta teamo. La produktteamo estas en okupata tempo, ĵeto alproksimiĝas, do bileto kun problemo de kliento, perdita inter la aliaj biletoj de la programisto al kiu ĝi estas asignita, pendas dum kelkaj semajnoj sen atento. Subteno opinias, ke la programisto laboras pri la problemo de la kliento. La kliento atendas kaj esperas, ke ilia problemo estas prilaborata. En realeco, nenio ankoraŭ okazas. Post kelkaj semajnoj, la kliento finfine decidas interesiĝi pri la progreso kaj demandas subtenon kiel la aferoj iras. Subteno petas disvolviĝon. La programisto ektremas, trarigardas la liston de biletoj kaj trovas bileton de la kliento tie. Legante bileton de kliento, li komprenas, ke ne estas sufiĉe da informoj por solvi la problemon, kaj li bezonas pli da ŝtipoj kaj rubejoj. Subteno petas pliajn informojn de la kliento. Kaj tiam la kliento rimarkas, ke neniu laboris pri sia problemo dum ĉi tiu tempo. Kaj tondro trafos...
En ĉi tiu situacio, la solvo de la konflikto mem estas sufiĉe evidenta kaj lineara (riparu la produkton, ĝisdatigu dokumentadon kaj provojn, trankviligi la klienton, liberigu korekton ktp.). Gravas analizi la laborprocezon kaj kompreni kiu respondecas pri organizado de la interago inter la du teamoj, kaj kial ĉi tiu situacio fariĝis ebla en la unua loko. Estas klare, kio devas esti riparita en la procezo - iu devas monitori la ĝeneralan bildon sen memorigiloj de klientoj, proaktive. Biletoj de la kliento devus elstari inter aliaj biletoj de programistoj. Subteno devus vidi ĉu la evolua teamo nuntempe laboras pri siaj biletoj, kaj se ne, kiam ĝi povas ekfunkcii, kaj kiam oni povas atendi rezultojn. Subteno kaj disvolviĝo devus periode komuniki kaj diskuti la staton de biletoj, la kolekto de informoj necesaj por elpurigado estu aŭtomatigita kiel eble plej multe, ktp.
Same kiel en milito la malamiko provas trafi la krucvojon inter du unuoj, tiel en laboro la plej delikata kaj vundebla punkto estas kutime la interagado inter teamoj. Se la administrantoj de subteno kaj disvolviĝo estas sufiĉe maljunaj, ili povos mem ripari la procezon, se ne, la procezo daŭre generi konfliktojn kaj problemojn ĝis intervenos administranto, kiu povas ripari la situacion.
Alia tipa ekzemplo, kiun mi plurfoje vidis en malsamaj kompanioj, estas situacio en kiu produkto estas verkita de unu teamo, aŭtomataj integrigaj testoj por ĝi estas verkitaj de dua teamo, kaj la infrastrukturo sur kiu ĝi estas ĉio operaciita estas akompanata de tria. teamo. Problemoj dum rulado de testoj aperas la tutan tempon, kaj la kaŭzo de problemoj en ili povas esti kaj la produkto kaj la testoj kaj infrastrukturo. Kutime estas probleme konsenti pri kiu devus fari la komencan analizon de problemoj, dosieraj cimoj, analizaj protokoloj de la produkto, testoj kaj infrastrukturo ktp. Konfliktoj ĉi tie estas tre oftaj, kaj, samtempe, unuformaj. En la kazo de alta emocia intenseco, partoprenantoj ofte falas en infanan pozicion kaj diskutoj komenciĝas en la serio: "kial mi faru ĉi tion", "ili rompiĝas pli ofte", ktp.
De laborflua perspektivo, la specifaj paŝoj por solvi problemon dependas de la konsisto de la teamoj, la speco de testoj kaj produkto, ktp. En unu el la projektoj, ni enkondukis periodan devon, en kiu teamoj monitoris testojn unuope, semajnon post semajno. En la alia, la komenca analizo ĉiam estis farita de la testprogramistoj, sed la analizo estis tre baza kaj la produkto estis sufiĉe stabila, do ĝi funkciis bone. La ŝlosilo estas certigi, ke la procezo estas travidebla, ke atendoj estas klaraj por ĉiuj partioj, kaj ke la situacio sentiĝas justa al ĉiuj.
Ĉu konflikto eĉ estas problemo en organizo? Ĉu malbona signo, ke konfliktoj ofte (aŭ nur periode) okazas en via teamo? Ĝenerale, ne, ĉar se estas kresko, evoluo, estas ia dinamiko, tiam aperas problemoj, kiuj neniam antaŭe estis solvitaj, kaj kiam ili solvas, povas aperi konfliktoj. Ĉi tio estas indikilo, ke iuj areoj bezonas atenton, ke ekzistas areoj por plibonigo. Estas malbone se konfliktoj aperas tre ofte, malfacilas solvi aŭ daŭras longan tempon. Ĉi tio plej verŝajne estas signo de nesufiĉe fluliniaj laborprocezoj kaj nesufiĉa matureco de la teamo.
fonto: www.habr.com