Epigraf:
Biyen, Landak lan Beruang Cilik ketemu ing alas.
- Halo, Hedgehog!
- Halo, Beruang Cilik!
Dadi, tembung demi tembung, guyon demi lelucon, Landak kena ing pasuryan dening Beruang Cilik ...
Ing ngisor iki minangka diskusi saka pimpinan tim kita, uga Direktur Pengembangan Produk RAS Igor Marnat, babagan spesifik konflik kerja lan cara sing bisa ditindakake kanggo ngatur.
Sebagéan gedhé konflik sing kita temui ing karya berkembang miturut skenario sing padha karo sing diterangake ing epigraf ing ndhuwur. Ana sawetara peserta sing wiwitane cukup seneng karo siji liyane; padha nyoba ngrampungake sawetara masalah, nanging pungkasane masalah kasebut tetep ora bisa dirampungake, lan sakperangan alesan hubungan antarane peserta diskusi dadi rusak.
Urip iku maneka warna, lan variasi dumadi ing skenario sing kasebut ing ndhuwur. Kadhangkala hubungan antarane peserta ora apik banget ing wiwitan, kadhangkala ora ana masalah sing mbutuhake solusi langsung (kayata, contone, ing epigraph), kadhangkala sawise diskusi hubungan kasebut tetep kaya sadurunge, nanging masalah iki wekasanipun ora ditanggulangi.
Apa sing umum ing kabeh kahanan sing bisa ditemtokake minangka kahanan konflik kerja?
Kaping pisanan, ana loro utawa luwih sisih. Partai-partai kasebut bisa manggoni panggonan sing beda-beda ing organisasi, ana ing hubungan kesetaraan (kolega ing tim), utawa ing tingkat hierarki sing beda (bos - bawahan), dadi individu (pegawe) utawa klompok (ing kasus konflik antarane karyawan lan tim utawa loro tim), lan liya-liyane. Kemungkinan konflik lan gampang resolusi kasebut dipengaruhi banget dening tingkat kepercayaan antarane para peserta. Sing luwih apik pihak ngerti saben liyane, sing luwih dhuwur tingkat kapercayan, sing luwih dhuwur kasempatan sing bakal teka menyang persetujuan. Contone, anggota tim sing disebarake sing durung tau sesambungan adhep-adhepan luwih kerep ngalami konflik babagan masalah kerja sing prasaja tinimbang wong sing wis ngalami interaksi langsung. Mulane, nalika nggarap tim sing disebarake, penting banget kanggo mesthekake yen kabeh anggota tim ketemu sacara periodik kanthi pribadi.
Kapindho, ing kahanan konflik ing karya, para pihak ing kahanan kanggo ngrampungake sawetara masalah sing penting kanggo salah siji pihak, kanggo loro-lorone, utawa kanggo organisasi sakabèhé. Ing wektu sing padha, amarga spesifik kahanan, para pihak biasane duwe wektu sing cukup lan macem-macem cara kanggo ngrampungake (formal, informal, rapat, surat, keputusan manajemen, anané tujuan lan rencana tim, kasunyatan hierarki, lsp). Iki beda karo kahanan ngrampungake masalah karya (utawa non-karya) ing organisasi, contone, ngrampungake pitakonan penting: "Eh, bocah, sampeyan saka wilayah apa?!" ing dalan, utawa konflik saka epigraph. Ing kasus ngrampungake masalah kerja, kualitas proses kerja lan budaya ngrampungake masalah ing tim.
Katelu, faktor penentu konflik (saka sudut pandang diskusi kita) yaiku kasunyatan manawa para pihak ing proses kasebut ora bisa kanthi mandiri nemokake solusi kanggo masalah sing cocog karo kabeh pihak. Kahanan kasebut mbutuhake campur tangan saka pihak katelu, arbiter eksternal. Titik iki bisa uga katon kontroversial, nanging, ing intine, yen kahanan konflik kasil dirampungake tanpa campur tangan saka arbiter eksternal, masalah kasebut bisa dirampungake kanthi sukses lan hubungane para pihak ora rusak, iki kahanan sing kudu ditindakake. . Paling kamungkinan, kita ora bakal ngerti babagan konflik kasebut, utawa kita bakal nemokake kanthi kasempatan sawise dirampungake. Luwih akeh masalah sing bisa ditindakake tim kanthi mandiri, luwih efektif.
Fitur karakteristik liyane saka konflik sing kudu didemek yaiku tingkat intensitas emosional sajrone keputusan kasebut. Konflik ora kudu digandhengake karo tingkat emosional sing dhuwur. Peserta ora kudu bengok-bengok lan ngacungake tangan supaya kahanan kasebut, ing intine, konflik. Masalah kasebut ora dirampungake, ana ketegangan emosional tartamtu (mbok menawa ora diungkapake kanthi jelas ing njaba), tegese kita ngadhepi kahanan konflik.
Apa perlu campur tangan ing kahanan konflik, utawa luwih becik supaya resolusi kasebut ditindakake lan ngenteni masalah kasebut rampung dhewe? Kudu. Ora mesthi ana kekuwatan utawa kepinteran kanggo ngrampungake konflik kanthi lengkap, nanging ing kahanan apa wae, ing konflik apa wae, sampeyan bisa njupuk posisi diwasa, saéngga nggawa sawetara wong liya ing saubengé, nyuda akibat negatif saka konflik lan kontribusi kanggo resolusi.
Sadurunge ndeleng sawetara conto kahanan konflik, ayo goleki sawetara poin penting sing umum kanggo kabeh konflik.
Nalika ngrampungake konflik, penting kanggo dadi ndhuwur perang, lan ora ana ing njero (iki uga disebut "njupuk posisi meta"), yaiku, ora dadi bagian saka salah sawijining pihak ing proses resolusi. Yen ora, duwe arbiter eksternal mbantu keputusan kasebut mung bakal nguatake posisi salah sijine pihak sing ngrugekake pihak liyane. Nalika nggawe keputusan, penting yen ditampa kanthi moral dening kabeh pihak, kaya sing diomongake, "tuku." Dadi, sanajan para pihak ora seneng karo keputusan sing ditindakake, paling ora kanthi tulus setuju kanggo ngetrapake. Kaya sing dikandhakake, supaya bisa ora setuju lan tundhuk. Yen ora, konflik mung bakal ngganti tampilan, geni sing murub bakal tetep ana ing sangisore rawa gambut lan ing sawetara titik mesthi bakal murub maneh.
Titik kapindho, sebagian sing ana gandhengane karo sing pertama, yaiku yen sampeyan wis mutusake kanggo melu ngrampungake konflik kasebut, njupuk kanthi serius saka sudut pandang komunikasi lan sinau konteks. Dhiskusi pribadi karo saben pihak. Kapisah karo saben, kanggo wiwitan. Aja lali kanggo mail. Ing kasus tim sing disebarake, paling ora ngobrol liwat link video. Aja marem karo kabar angin lan saksi mata. Ngerti critane, apa sing dikarepake saben pihak, apa sing dikarepake, apa sing dikarepake, apa dheweke wis nyoba ngrampungake masalah iki sadurunge, apa sing bakal kedadeyan yen ora dirampungake, solusi apa sing dideleng, kepiye carane mbayangno posisine. sisih liyane, apa padha mikir , bener utawa salah, etc. Muat kabeh konteks sing bisa ditindakake ing sirah, kanthi pikiran sing mbukak, kanthi nganggep kabeh wong bener. Sampeyan ora ana ing konflik, sampeyan ana ing njaba, ing metaposisi. Yen konteks mung kasedhiya ing utas kiriman, paling ora maca kabeh lan utas lan dokumen sing ana gandhengane. Sawise sampeyan maca, isih ngomong nganggo swara sampeyan. Sampeyan meh dijamin krungu bab penting sing ora ana ing surat.
Titik penting katelu yaiku pendekatan umum kanggo komunikasi. Iki minangka perkara biasa, ora ana sing kosmik, nanging penting banget. Kita ora nyoba ngirit wektu, ngobrol karo kabeh peserta, ora ngritik wong kasebut, nanging kita nimbang akibat saka tumindake (dudu "sampeyan ora sopan", nanging "mbok menawa wong lanang bisa gelo. bab iki"), kita menehi kesempatan kanggo nyimpen pasuryan, kita nindakake diskusi ing wong, ora ing ngarep baris.
Konflik biasane disebabake salah siji saka rong alasan. Kapisan ana hubungane karo apa wong ing wektu konflik ana ing posisi wong diwasa utawa ing posisi bocah (liyane ing ngisor iki). Iki amarga kadewasan emosional, kemampuan kanggo ngatur emosi (sing, kanthi cara, ora tansah ana hubungane karo umure). Alesan umum kaloro yaiku ora sampurna saka proses kerja, sing nggawe kahanan wilayah abu-abu sing tanggung jawab disebarake antarane peserta, pangarepan para pihak ora transparan, lan peran ing proses kasebut kabur.
Dadi, kanggo ngrampungake konflik (uga masalah liyane), manajer kudu ngelingi telung perspektif: jangka pendek - kanggo ngrampungake masalah / konflik ing kene lan saiki, jangka menengah - kanggo nyuda kemungkinan konflik liyane sing muncul. kanggo alesan sing padha, lan long-term - kanggo cultivate budaya diwasa ing wong tim.
Saben kita duwe anak batin, kira-kira umur telung utawa patang taun. Dheweke turu paling wektu ing karya, nanging kadhangkala tangi lan njupuk kontrol. Anak duwe prioritas dhewe. Penting kanggo dheweke negesake yen iki kothak wedhi, ibune luwih tresna marang dheweke, mesine paling apik (desain sing paling apik, program sing paling apik, ...). Ing kahanan konflik, bocah bisa mencet dolanan, stomp sikil lan retak spatula, nanging ora bisa ngatasi masalah diwasa (arsitektur solusi, pendekatan kanggo testing otomatis, tanggal release, etc.), Dheweke ora mikir babagan keuntungan. kanggo tim. Anak ing konflik bisa diwanti-wanti, nglipur lan dikirim menyang amben kanthi njaluk nelpon wong diwasa. Sadurunge miwiti dhiskusi ing kahanan konflik, priksa manawa sampeyan lagi ngomong karo wong diwasa, dudu bocah, lan sampeyan dhewe ana ing posisi wong diwasa. Yen goal jujur sampeyan ing wektu iki kanggo mutusake masalah serius, sampeyan ana ing posisi wong diwasa. Yen goal sampeyan kanggo stomp sikil lan retak agul-agul Pundhak, iki posisi childish. Kirimi anak batin menyang amben lan nelpon wong diwasa, utawa jadwal maneh diskusi. Wong nggawe keputusan emosional, lan banjur golek pembenaran sing rasional. Keputusan sing digawe bocah adhedhasar prioritas bocah ora bakal optimal.
Saliyane prilaku ing wektu konflik, posisi bocah utawa wong diwasa uga ditondoi dening tingkat tanggung jawab sing siap ditindakake dening wong. Ing manifestasi sing ekstrem, posisi bocah programmer, sing wis ketemu luwih saka sepisan, katon kaya iki: Aku nulis kode kasebut, dikirim kanggo ditinjau - karyaku wis rampung. Reviewer kudu mriksa lan nyetujoni, QA kudu mriksa, yen ana masalah, dheweke bakal ngandhani. Anehe, malah wong-wong sing cukup diwasa lan duwe pengalaman kadang-kadang tumindak kaya ngono. Pungkasan skala liyane yaiku yen wong nganggep awake dhewe tanggung jawab kanggo mesthekake yen kode kasebut bisa digunakake, dilindhungi dening tes, wis dipriksa kanthi pribadi, wis kasil ngliwati review (yen perlu, ora ana masalah ping reviewer, ngrembug masalah. dening swara, etc.) lan wis ditindhes , QA bakal menehi pitulungan yen perlu, skenario test bakal diterangake, etc. Ing kasus-kasus normal, programmer bakal miwiti nyedhaki mburi skala diwasa, utawa pindhah menyang kana nalika entuk pengalaman (yen budaya sing bener ditanam ing tim). Ing kasus sing nemen, dheweke terus kerja, biasane njupuk posisi bocah, banjur dheweke lan tim kanthi periodik duwe masalah lan konflik.
Nggawe budaya sing bener lan diwasa ing tim minangka tugas penting kanggo manajer apa wae. Butuh wektu suwe lan gaweyan saben dina, nanging asile worth iku. Ana rong cara kanggo pengaruhe budaya tim - mimpin kanthi conto (sing mesthi bakal dituruti; tim tansah nggoleki pimpinan) lan ngrembug lan menehi ganjaran marang prilaku sing bener. Ora ana sing abstruse utawa formal banget, mung nalika ngrembug masalah, sok dong mirsani yen ana sing bisa ditindakake ing kene, nandheske yen sampeyan wis mutusake kanthi bener, pujian, cathetan sajrone review rilis, lsp.
Ayo nimbang sawetara kahanan konflik sing khas, saka prasaja nganti kompleks:
Konflik sing ora ana hubungane karo masalah kerja
Cukup asring ana konflik ing karya sing ora ana hubungane karo masalah kerja. Kedadeyan lan gampang resolusi kasebut biasane ana hubungane langsung karo tingkat kecerdasan emosional para peserta, tingkat kedewasaan, lan ora ana hubungane karo kesempurnaan utawa ora sampurna saka proses kerja.
Conto khas: ana sing ora kerep nggunakake mesin cuci utawa adus, sing ora disenengi wong liya, ana sing kesel, ana sing kenek angin yen mbukak jendela, ana sing rame, lan liya-liyane kudu meneng kanggo nyambut gawe, lan liya-liyane. sateruse. Luwih becik ora nundha resolusi konflik kaya iki lan ora ngidini dheweke njupuk dalan. Dheweke ora bakal mutusake dhewe lan bakal ngganggu sampeyan kerja saben dina lan ngracuni atmosfer ing tim. Untunge, ngrampungake masalah kasebut biasane ora dadi masalah gedhe - mung ngobrol kanthi tenang (siji-siji, mesthi) karo kolega sing nglirwakake kebersihan, nyedhiyakake kursi sing nyaman kanggo wong sing luwih seneng nggawe bisu / adhem, tuku headphone sing nyerep swara utawa nginstal partisi. , lsp.
Conto liyane sing aku nemoni kaping pirang-pirang sajrone kerja yaiku ketidakcocokan psikologis anggota tim. Kanggo sawetara alasan, wong ora bisa kerja bareng; saben interaksi mungkasi skandal. Kadhangkala iki amarga kasunyatan manawa wong duwe pandangan kutub babagan sawetara masalah sing penting (biasane politik) lan ora ngerti carane ninggalake dheweke ing njaba kerja. Mesthekake wong-wong mau kanggo ngidinke saben liyane utawa ngganti prilaku minangka tugas sing ora ana gunane. Siji-sijine pangecualian sing daktemoni yaiku kanca-kanca enom sing duwe persepsi terbuka; prilaku kasebut isih bisa diowahi kanthi bertahap liwat obrolan periodik. Biasane masalah kasebut kasil dirampungake kanthi misahake menyang tim sing beda-beda, utawa paling ora menehi kesempatan kanggo tumpang tindih ing karya sing arang banget.
Ing kabeh kahanan ing ndhuwur, sampeyan kudu ngomong karo kabeh peserta kanthi pribadi, ngrembug kahanan kasebut, takon apa dheweke weruh masalah ing kasus iki, takon apa, miturut pendapat, solusi, lan njamin partisipasi ing nggawe iki. kaputusan.
Saka sudut pandang ngoptimalake proses kerja (perspektif jangka menengah sing dakkandhakake), ora akeh sing bisa ditindakake ing kene; siji-sijine titik optimasi yaiku nimbang faktor kompatibilitas nalika mbentuk tim lan ora nglebokake wong. bebarengan ing advance sing bakal konflik.
Saka sudut pandang budaya tim, kahanan kaya ngono asring kedadeyan ing tim kanthi budaya sing diwasa, ing ngendi wong ngajeni tim lan kolega lan ngerti carane ngrampungake masalah kanthi mandiri. Kajaba iku, konflik kasebut luwih gampang dirampungake (asring kanthi otomatis) ing tim sing ana tingkat kepercayaan sing dhuwur, wong wis suwe kerja bareng lan/utawa sering komunikasi ing njaba kerja.
Konflik sing ana gandhengane karo masalah kerja:
Konflik kasebut biasane disebabake dening loro alasan bebarengan, loro emosional (kasunyatan yen salah sijine peserta ora ana ing posisi wong diwasa) lan ora sampurna saka proses kerja kasebut. Mbok menawa jinis konflik sing paling umum sing aku alami yaiku konflik sajrone review kode utawa diskusi arsitektur antarane pangembang.
Aku bakal nyorot rong kasus khas ing kene:
1) Ing kasus pisanan, pangembang ora bisa njaluk review kode saka kolega. Tembelan dikirim kanggo ditinjau, lan ora ana sing kedadeyan. Sepisanan, ora ana konflik sing jelas ing antarane loro-lorone, nanging yen dipikirake, iki pancen konflik. Masalah kerja ora dirampungake, salah sawijining pihak (nunggu review) ngalami rasa ora nyaman sing jelas. Subtipe ekstrim saka kasus iki yaiku pangembangan ing komunitas utawa ing tim sing beda-beda, dene sing nyemak bisa uga ora kasengsem ing kode tartamtu iki, amarga loading utawa kahanan liyane, bisa uga ora nggatekake panjalukan review ing kabeh, lan arbiter njaba. (manajer umum kanggo loro-lorone) ) bisa uga ora ana.
Pendekatan solusi sing mbantu ing kahanan kaya mengkono ana hubungane karo perspektif jangka panjang, budaya wong diwasa. Kaping pisanan, kegiatan cerdas bisa digunakake. Sampeyan ora kudu ngarep-arep yen kode sing digantung ing review bakal narik kawigaten saka reviewer kasebut. We kudu bantuan reviewers sok dong mirsani wong. Pingani wong saperangan, takon babagan syncape, melu rembugan. Temenan, importunity luwih mbebayani tinimbang bantuan, sampeyan kudu nggunakake akal sehat. Kapindho, pre-preparation dianggo kanthi apik. Yen tim ngerti apa sing kedadeyan lan ngapa, kenapa kode iki dibutuhake, desain kasebut wis dibahas lan disepakati sadurunge karo kabeh wong, luwih seneng nggatekake kode kasebut lan nampa kanggo kerja. Katelu, wewenang dianggo. Yen sampeyan pengin dideleng, nggawe akeh review dhewe. Tindakake review kanthi kualitas dhuwur, kanthi mriksa nyata, tes nyata, lan komentar sing migunani. Yen julukan sampeyan wis dikenal ing tim, ana kemungkinan luwih gedhe kode sampeyan bakal katon.
Saka sudut pandang alur kerja, perbaikan sing bisa ditindakake ing kene yaiku prioritas sing bener kanggo mbantu pangembang nggayuh tujuane lan tim (deleng wong liya, nulis surat menyang komunitas, ngiringi kode kanthi deskripsi arsitektur, dokumentasi, tes, melu diskusi karo komunitas, etc.), nyegah patches saka hanging ing antrian dawa banget, etc.
2) Kasus konflik sing umum kaping pindho sajrone review kode utawa desain yaiku tampilan sing beda babagan masalah teknis, gaya coding, lan pilihan alat. Sing penting banget ing kasus iki yaiku tingkat kepercayaan antarane para peserta, sing dadi tim sing padha, lan pengalaman kerja bareng. A buntu occurs nalika salah siji saka peserta njupuk posisi childish lan ora nyoba kanggo ngrungokake apa interlocutor arep kanggo ngirim marang. Asring, pendekatan sing diusulake dening pihak liya lan pendekatan sing diusulake ing wiwitan bisa uga sukses lan ora preduli saka prinsip sing kudu dipilih.
Sawijining dina, programer saka timku (ayo diarani Pasha) nyiapake tembelan kanthi owah-owahan ing sistem panyebaran paket, sing dikembangake lan didhukung dening kolega saka departemen tetanggan. Salah siji saka wong-wong mau (Igor) duwe pendapat sing kuat babagan persis carane layanan Linux kudu dikonfigurasi nalika masang paket. Panemu iki beda karo pendekatan sing diusulake ing tembelan, lan dheweke ora setuju. Kaya biasane, tenggat wektu wis entek, lan kudu nggawe keputusan, salah sijine kudu njupuk posisi diwasa. Pasha ngakoni yen loro pendekatan kasebut nduweni hak kanggo urip, nanging dheweke pengin pilihane lulus, amarga Ora ana siji utawa opsi liya sing duwe kaluwihan teknis sing jelas.
Diskusi kita katon kaya mangkene (skema banget, mesthi, obrolan kasebut nganti setengah jam):
- Pasha, kita duwe fitur beku ing sawetara dina. Penting yen kita ngumpulake kabeh lan miwiti tes sanalika bisa. Kepiye carane bisa ngliwati Igor?
- Dheweke pengin nyiyapake layanan kanthi cara sing beda, dheweke menehi komentar kanggo aku ...
- Lan apa ana, owah-owahan gedhe, akeh fuss?
- Ora, ana kerja kanggo sawetara jam, nanging ing pungkasan ora ana bedane, bakal bisa digunakake, kenapa iki perlu? Aku nggawe sing bisa, ayo nampa.
- Rungokake, wis suwene sampeyan ngrembug kabeh iki?
- Ya, kita wis menehi tandha wektu sajrone seminggu lan setengah saiki.
- Um ... kita bisa ngatasi masalah ing saperangan jam sing wis njupuk minggu lan setengah, lan ora nindakake?
- Ya, nanging aku ora pengin Igor mikir yen aku nyerah ...
- Rungokake, apa sing luwih penting kanggo sampeyan, ngetokake release, bebarengan karo keputusan sampeyan ing njero, utawa mateni Igor? Kita bisa mblokir, banjur, Nanging, ana kasempatan apik kanggo fly liwat karo release.
- Inggih ... bakal kelangan, mesthi, kanggo ngilangke irung Igor, nanging oke, release luwih penting, aku setuju.
- Apa pancene penting kanggo sampeyan apa sing dikira Igor? Jujur, dheweke ora peduli, dheweke mung pengin pendekatan sing manunggal ing macem-macem papan sing tanggung jawabe.
- Inggih, ok, mugi kula nindakaken minangka piyambakipun nyuwun ing komentar lan ayo kang miwiti testing.
- Matur nuwun, Pasha! Aku yakin yen kowe loro bakal luwih dewasa, senajan Igorek luwih tuwa tinimbang kowe :)
Jeksa Agung bisa ngetokake iki ditanggulangi, release wis dirilis ing wektu, Pasha ora aran dissatisfaction akeh, amarga dheweke dhewe ngusulake solusi lan ngetrapake. Igor umume seneng, amarga ... Panemune digatekake lan dheweke nindakake kaya sing disaranake.
Jinis liya saka konflik sing padha yaiku pilihan ing antarane solusi teknis / perpustakaan / pendekatan ing sawijining proyek, utamane ing tim sing disebarake. Ing salah sawijining proyek, sing dipanggonke nggunakake C / C ++, ternyata manajemen teknis proyek kasebut sacara kategoris nglawan nggunakake STL (Perpustakaan Cithakan Standar). Iki minangka perpustakaan basa standar sing nyederhanakake pangembangan, lan tim kita wis biasa banget. Pranyata proyek kasebut luwih cedhak karo C tinimbang C ++, sing ora menehi inspirasi kanggo tim kasebut, amarga manajemen nyoba sing paling apik lan direkrut tenan kelangan plus pemain. Ing wektu sing padha, tim Amerika, insinyur lan manajer, wis suwe kerja ing perusahaan kasebut, wis biasa karo kahanan sing ana, lan seneng karo kabeh. Bagéan Rusia saka tim kasebut digawa metu bubar, ing sawetara minggu (kalebu aku). Bagéan Rusia saka tim kanthi kategorine ora pengin ninggalake pendekatan pembangunan sing biasa.
Diskusi ditulis tanpa wates wiwit antarane rong bawana, huruf ing layar telu utawa papat mabur bolak-balik, ing surat grup lan pribadi, saka programer nganti programer lan manajer. Kaya biasane, aksara sing dawane iki ora diwaca dening wong liya kajaba penulis lan panyengkuyunge. Obrolan creaked karo tension, maringaken multi-layar pikirane ing macem-macem arah bab kaluwihan technical saka STL, carane uga dites iku, carane aman iku, lan ing umum, carane apik urip karo iku, lan carane elek iku tanpa iku. .
Iki kabeh cukup suwe, nganti pungkasane aku ngerti yen kita ngrembug babagan aspek teknis masalah kasebut, nanging masalah kasebut sejatine ora teknis. Masalahe dudu kaluwihan utawa kekurangan STL utawa angel kerja tanpa. Masalahe luwih organisasi. Kita mung kudu ngerti carane perusahaan kita kerja. Ora ana sing duwe pengalaman kerja ing perusahaan kasebut sadurunge. Masalahe yaiku sawise kode kasebut dikembangake lan dirilis menyang produksi, dhukungan ditangani dening wong sing beda banget saka tim liyane, saka negara liya. Tim teknik ageng iki saka sawetara puluhan ewu insinyur (total) mung bisa mbayar minimal minimal sarana teknis, dadi bisa ngomong, minimal minimal. Apa wae sing ngluwihi standar teknik sing ditetepake ing perusahaan kanthi fisik ora bisa didhukung ing mangsa ngarep. Tingkat tim ditemtokake dening tingkat anggota sing paling lemah. Sawise kita mangertos motivasi nyata tumindak bagean Amérika saka tim, Jeksa Agung bisa ngetokake iki dibusak saka agenda, lan bebarengan kita kasil dikembangaké lan dirilis produk nggunakake standar diadopsi dening perusahaan. Huruf lan obrolan ing kasus iki ora bisa digunakake kanthi apik, butuh sawetara lelungan lan akeh komunikasi pribadhi kanggo teka menyang denominator umum.
Saka sudut pandang alur kerja, ing kasus tartamtu iki, bakal mbantu nduwe katrangan babagan alat sing digunakake, syarat kanggo wong-wong mau, watesan kanggo nambah sing anyar, lan pambenaran kanggo watesan kasebut. Dokumen kasebut kira-kira cocog karo sing diterangake ing paragraf Strategi Gunakake maneh lan Lingkungan Pengembangan saka "Buku Pedoman Manajer kanggo Pangembangan Perangkat Lunak", sing dikembangake ing . Senadyan umur, iku sampurna njlèntrèhaké kabeh kegiatan utama lan planning orane tumrap sekolah saka pangembangan piranti lunak saka jinis iki. Duwe dokumen kaya iki nggawe gampang banget kanggo ngrembug babagan komponen lan pendekatan sing bisa digunakake ing produk, lan kenapa.
Saka sudut pandang budaya, jelas, kanthi posisi sing luwih diwasa, ing ngendi para pihak nyoba ngrungokake lan ngerti motivasi nyata tumindak lan tumindak rekan-rekane adhedhasar prioritas proyek lan tim, lan dudu ego pribadi. , konflik bakal dirampungake luwih gampang lan luwih cepet.
Ing konflik liyane babagan pilihan solusi teknis, aku uga butuh wektu sing bisa dingerteni kanggo ngerti motivasi salah sawijining pihak (iku kasus sing ora biasa), nanging sawise motivasi kasebut jelas, solusi kasebut jelas.
Kahanan kasebut yaiku: pangembang anyar katon ing tim udakara 20 wong, ayo diarani Stas. Ing wektu iku, alat standar kanggo komunikasi minangka tim yaiku Skype. Dadi mengko, Stas dadi penggemar standar mbukak lan piranti lunak open source, lan mung nggunakake piranti lan sistem operasi sing sumber kasedhiya kanggo umum lan nggunakake protokol sing diterangake sacara umum. Skype dudu salah sawijining alat kasebut. Kita ngenteni akeh wektu kanggo ngrembug babagan kaluwihan lan kekurangan pendekatan iki, nyoba ngluncurake analog Skype ing sistem operasi sing beda-beda, upaya Stas kanggo ngyakinake tim supaya ngalih menyang standar liyane, nulis menyang dheweke kanthi mail, nelpon dheweke kanthi pribadi. telpon, tuku wong komputer kapindho khusus kanggo Skype, etc. Akhire, aku temen maujud sing masalah iki, ing pet, ora technical utawa organisasi, iku rodo ideologis, malah, siji bisa ngomong, agama (kanggo Stas). Malah yen kita pungkasanipun nyambung Stas lan Skype (kang njupuk sawetara sasi), masalah bakal njedhul maneh ing sembarang instrument sakteruse. Aku ora duwe cara nyata kanggo ngganti pandangan Stas, lan ora ana alesan kanggo nyoba ngganti pandangan jagad tim sing makarya kanthi sampurna ing lingkungan iki. Wong lan perusahaan mung orthogonal ing worldview. Ing kahanan kaya mengkono, solusi sing apik yaiku organisasi. Kita nransfer Stas menyang tim liyane, ing ngendi dheweke luwih organik.
Alesan kanggo konflik iki, miturut pendapatku, yaiku bedane budaya pribadhi saka wong tartamtu (sing nduweni pendapat sing kuat sing ora ngidini dheweke kompromi) lan budaya perusahaan. Ing kasus iki, mesthine salah manajer. Wiwitane salah njupuk dheweke ing proyek kaya iki. Stas pungkasanipun pindhah menyang proyek pangembangan piranti lunak open source lan unggul ing kana.
Conto apik saka konflik sing disebabake dening sikap bocah-bocah saka pangembang lan kekurangan proses kerja yaiku kahanan sing, yen ora ana definisi rampung, pangembang lan tim QA duwe pangarepan sing beda babagan kesiapan. fitur ditransfer menyang QA. Pangembang percaya yen cukup nulis kode kasebut lan mbuwang fitur kasebut ing pager menyang QA - dheweke bakal ngurutake. A programmer cukup diwasa lan experienced, dening cara, nanging sing batesan internal kanggo kualitas. QA ora setuju karo iki lan nuntut kanggo nuduhake lan njlèntrèhaké kanggo wong-wong mau apa wis dipriksa piyambak, lan nuntut script testing kanggo wong-wong mau. Dheweke duwe masalah karo fungsi saka pangembang iki ing jaman kepungkur lan ora pengin mbuwang wektu maneh. Miturut cara, dheweke pancen bener - fitur kasebut pancen ora bisa digunakake, dheweke ora mriksa kode kasebut sadurunge dikirim menyang QA.
Kanggo mutusake masalah kahanan, aku takon marang kanggo nuduhake kula sing kabeh pancene bisa (ora bisa, lan kudu ndandani iku), kita ngomong karo tim lan karo definisi QA rampung (padha ora nggawe ing. nulis, amarga kita padha ora pengin nggawe proses banget birokrasi ), uga, kita rauh parted cara karo spesialis iki (kanggo relief umum).
Saka sudut pandang alur kerja, perbaikan sing bisa ditindakake ing kasus iki yaiku anané definisi rampung, syarat kanggo dhukungan saka saben fitur unit lan tes integrasi, lan deskripsi pengujian sing ditindakake dening pangembang. Ing salah sawijining proyek, kita ngukur tingkat jangkoan kode kanthi tes sajrone CI lan yen tingkat jangkoan mudhun sawise nambahake tembelan, tes kasebut ditandhani minangka gagal, yaiku. kode anyar mung bisa ditambahake yen ana tes anyar kanggo.
Conto khas liyane saka konflik sing ana hubungane karo organisasi proses kerja. Kita duwe produk, tim pangembangan produk, tim dhukungan, lan pelanggan. Pelanggan duwe masalah karo produk lan dhukungan kontak. Dhukungan nganalisa masalah lan ngerti manawa masalah kasebut ana ing produk lan nransfer masalah kasebut menyang tim produk. Tim produk ing wektu sibuk, release wis nyedhak, supaya tiket karo masalah saka customer, ilang antarane karcis liyane pangembang kanggo kang diutus, macet kanggo sawetara minggu tanpa manungsa waé. Dhukungan mikir yen pangembang lagi nggarap masalah pelanggan. Pelanggan ngenteni lan ngarep-arep yen masalahe digarap. Ing kasunyatan, ora ana sing kedadeyan. Sawise sawetara minggu, customer pungkasanipun mutusake kanggo njupuk kapentingan ing kemajuan lan takon support carane iku arep. Dhukungan njaluk pembangunan. Pangembang shudders, katon liwat dhaptar tiket lan nemokake tiket saka customer ana. Maca tiket saka pelanggan, dheweke ngerti yen ora ana informasi sing cukup kanggo ngatasi masalah kasebut, lan dheweke butuh luwih akeh log lan dump. Dhukungan njaluk informasi tambahan saka pelanggan. Banjur pelanggan nyadari yen ora ana sing ngupayakake masalahe sajrone wektu iki. Lan gludhug bakal nyerang ...
Ing kahanan iki, solusi kanggo konflik dhewe cukup ketok lan linear (ndandani produk, nganyari dokumentasi lan tes, appease customer, ngeculake hotfix, etc.). Penting kanggo nganalisa proses kerja lan ngerti sapa sing tanggung jawab kanggo ngatur interaksi ing antarane rong tim, lan kenapa kahanan iki bisa kedadeyan ing wiwitan. Cetha apa sing kudu didandani ing proses kasebut - wong kudu ngawasi gambar sakabèhé tanpa pangeling saka pelanggan, kanthi proaktif. Tiket saka pelanggan kudu ngadeg ing antarane tiket liyane saka pangembang. Dhukungan kudu ndeleng manawa tim pangembang lagi nggarap tiket, lan yen ora, kapan bisa miwiti kerja, lan kapan asil bisa diarepake. Dhukungan lan pangembangan kudu komunikasi sacara periodik lan ngrembug status karcis, koleksi informasi sing dibutuhake kanggo debugging kudu otomatis sabisa, lsp.
Kaya ing perang mungsuh nyoba kanggo mencet prapatan antarane loro Unit, supaya ing karya titik paling alus lan rawan biasane interaksi antarane tim. Yen manajer dhukungan lan pangembangan cukup lawas, dheweke bakal bisa ndandani proses kasebut dhewe, yen ora, proses kasebut bakal terus nyebabake konflik lan masalah nganti manajer campur tangan sing bisa ndandani kahanan kasebut.
Conto khas liyane sing wis dakdeleng bola-bali ing macem-macem perusahaan yaiku kahanan ing ngendi produk ditulis dening siji tim, tes integrasi otomatis ditulis dening tim kapindho, lan infrastruktur sing kabeh dioperasikake diiringi pihak katelu. tim. Masalah nalika nganakake tes terus-terusan, lan panyebab masalah kasebut bisa dadi produk lan tes lan infrastruktur. Biasane masalah kanggo setuju sapa sing kudu nindakake analisis awal masalah, file bug, log parse produk, tes lan infrastruktur, lsp. Konflik ing kene kerep banget, lan, ing wektu sing padha, seragam. Ing kasus intensitas emosional sing dhuwur, para peserta kerep dadi bocah cilik lan diskusi diwiwiti ing seri: "kenapa aku kudu tinker karo iki," "dheweke luwih kerep rusak," lsp.
Saka perspektif alur kerja, langkah-langkah khusus kanggo ngrampungake masalah gumantung saka komposisi tim, jinis tes lan produk, lsp. Ing salah sawijining proyek, kita ngenalake tugas berkala, ing ngendi tim ngawasi tes siji-sijine, saben minggu. Ing sisih liya, analisis awal tansah ditindakake dening pangembang tes, nanging analisis kasebut dhasar banget lan produk kasebut cukup stabil, saengga bisa digunakake kanthi apik. Kuncine yaiku kanggo mesthekake yen proses kasebut transparan, pangarep-arep sing jelas kanggo kabeh pihak, lan kahanan sing adil kanggo kabeh wong.
Apa konflik malah dadi masalah ing organisasi? Apa pratandha ala yen konflik asring (utawa mung sacara periodik) dumadi ing tim sampeyan? Umumé, ora, amarga yen ana wutah, pangembangan, ana sawetara jinis dinamika, banjur muncul masalah sing durung tau dirampungake sadurunge, lan nalika ngrampungake, konflik bisa muncul. Iki minangka indikator yen sawetara wilayah mbutuhake perhatian, yen ana wilayah sing kudu ditingkatake. Iku ala yen konflik muncul kerep banget, angel dirampungake utawa butuh wektu suwe. Iki minangka tandha saka proses kerja sing ora efisien lan kedewasaan tim sing ora cukup.
Source: www.habr.com