Manajemen konflik dalam tim – tindakan penyeimbang atau kebutuhan vital?

Prasasti:
Pada suatu ketika, Landak dan Beruang Kecil bertemu di hutan.
- Halo, Landak!
- Halo, Beruang Kecil!
Jadi, kata demi kata, lelucon demi lelucon, wajah Landak dipukul oleh Beruang Kecil...

Di bawah ini adalah diskusi dari ketua tim kami, serta Direktur Pengembangan Produk RAS Igor Marnat, tentang konflik kerja secara spesifik dan kemungkinan metode untuk mengelolanya.

Sebagian besar konflik yang kita temui di tempat kerja berkembang menurut skenario yang serupa dengan yang dijelaskan dalam prasasti di atas. Ada beberapa peserta yang pada awalnya bersikap cukup baik terhadap satu sama lain, mereka berusaha menyelesaikan suatu masalah, namun pada akhirnya masalah tersebut tetap tidak terselesaikan, dan entah kenapa hubungan antar peserta diskusi menjadi rusak.

Kehidupan itu beragam, dan variasi terjadi dalam skenario yang dijelaskan di atas. Kadang-kadang hubungan antar peserta pada awalnya tidak terlalu baik, kadang-kadang bahkan tidak ada suatu persoalan yang memerlukan penyelesaian langsung (seperti misalnya pada prasasti), kadang-kadang setelah diskusi hubungan tetap sama seperti sebelum dimulai, tetapi masalah tersebut pada akhirnya tidak terselesaikan.

Apa kesamaan dalam semua situasi yang dapat didefinisikan sebagai situasi konflik kerja?



Pertama, ada dua sisi atau lebih. Pihak-pihak ini dapat menempati tempat yang berbeda dalam organisasi, berada dalam hubungan kesetaraan (rekan kerja dalam tim), atau pada tingkat hierarki yang berbeda (atasan - bawahan), menjadi individu (karyawan) atau kelompok (jika terjadi konflik antara suatu karyawan dan satu atau dua tim), dan seterusnya. Besar kecilnya kemungkinan terjadinya konflik dan kemudahan penyelesaiannya sangat dipengaruhi oleh tingkat kepercayaan antar partisipan. Semakin baik para pihak mengenal satu sama lain, semakin tinggi tingkat kepercayaannya, semakin tinggi pula peluang mereka untuk mencapai kesepakatan. Misalnya, anggota tim terdistribusi yang belum pernah berinteraksi tatap muka lebih mungkin mengalami konflik karena masalah pekerjaan sederhana dibandingkan orang yang setidaknya pernah melakukan beberapa interaksi tatap muka. Oleh karena itu, ketika bekerja dalam tim terdistribusi, sangat penting untuk memastikan bahwa semua anggota tim bertemu secara langsung satu sama lain secara berkala.

Kedua, dalam situasi konflik di tempat kerja, para pihak berada dalam situasi penyelesaian beberapa masalah yang penting bagi salah satu pihak, bagi keduanya, atau bagi organisasi secara keseluruhan. Pada saat yang sama, karena situasi yang spesifik, para pihak biasanya memiliki cukup waktu dan berbagai cara untuk menyelesaikannya (formal, informal, pertemuan, surat, keputusan manajemen, adanya tujuan dan rencana tim, fakta hierarki, dll.). Berbeda dengan situasi penyelesaian persoalan pekerjaan (atau non-pekerjaan) dalam suatu organisasi, misalnya dengan penyelesaian pertanyaan penting: “Eh nak, kamu dari daerah mana?!” di jalan, atau konflik dari prasasti. Dalam hal penyelesaian masalah pekerjaan, kualitas proses kerja dan budaya penyelesaian masalah dalam tim adalah hal yang penting.

Ketiga, faktor penentu konflik (dari sudut pandang diskusi kita) adalah kenyataan bahwa pihak-pihak yang terlibat dalam proses tersebut tidak dapat secara mandiri menemukan solusi atas masalah yang menguntungkan semua pihak. Situasi ini memerlukan intervensi pihak ketiga, yaitu arbiter eksternal. Hal ini mungkin terkesan kontroversial, namun pada hakikatnya jika situasi konflik berhasil diselesaikan tanpa campur tangan arbiter eksternal, masalah berhasil diselesaikan dan hubungan para pihak tidak memburuk, maka situasi inilah yang harus kita perjuangkan. . Kemungkinan besar kita bahkan tidak akan mengetahui konflik semacam itu, atau kita akan mengetahuinya secara kebetulan setelah konflik tersebut terselesaikan. Semakin banyak masalah yang dapat diselesaikan sendiri oleh suatu tim, maka akan semakin efektif tim tersebut.

Ciri khas lain dari konflik yang patut disinggung adalah tingkat intensitas emosional selama pengambilan keputusan. Konflik belum tentu dikaitkan dengan tingkat emosi yang tinggi. Peserta tidak perlu berteriak dan melambaikan tangan agar situasi pada hakikatnya menjadi konflik. Masalah tidak terselesaikan, ada ketegangan emosional tertentu (mungkin tidak diungkapkan secara jelas secara lahiriah), yang berarti kita dihadapkan pada situasi konflik.

Apakah perlu campur tangan sama sekali dalam situasi konflik, atau lebih baik membiarkan penyelesaiannya berjalan sebagaimana mestinya dan menunggu sampai masalah teratasi dengan sendirinya? Perlu. Tidak selalu Anda memiliki kekuatan atau kompetensi untuk menyelesaikan konflik sepenuhnya, tetapi dalam situasi apa pun, dalam konflik skala apa pun, Anda dapat mengambil posisi dewasa, sehingga membawa beberapa orang lagi di sekitar Anda ke sana, dan mengurangi dampak negatif dari konflik tersebut. konflik dan berkontribusi pada penyelesaiannya.

Sebelum melihat beberapa contoh situasi konflik, mari kita lihat beberapa poin penting yang umum terjadi pada semua konflik.

Saat menyelesaikan suatu konflik, penting untuk berada di atas pertarungan, dan bukan di dalamnya (ini juga disebut “mengambil posisi meta”), yaitu tidak menjadi bagian dari salah satu pihak dalam proses penyelesaian. Jika tidak, keberadaan arbiter eksternal yang membantu pengambilan keputusan hanya akan memperkuat posisi salah satu pihak dan merugikan pihak lainnya. Saat membuat keputusan, penting agar keputusan tersebut diterima secara moral oleh semua pihak, seperti yang mereka katakan, “dibeli”. Sehingga meski para pihak tidak senang dengan keputusan yang diambil, setidaknya mereka dengan tulus setuju untuk melaksanakannya. Seperti yang mereka katakan, untuk bisa tidak setuju dan berkomitmen. Jika tidak, konflik akan berubah tampilannya, api yang membara akan tetap berada di bawah rawa gambut dan suatu saat pasti akan berkobar lagi.

Poin kedua, sebagian berkaitan dengan poin pertama, adalah jika Anda telah memutuskan untuk berpartisipasi dalam menyelesaikan konflik, tanggapilah masalah tersebut seserius mungkin dari sudut pandang komunikasi dan mempelajari konteksnya. Bicaralah secara pribadi dengan masing-masing pihak. Secara terpisah dengan masing-masing, sebagai permulaan. Jangan puas dengan surat. Dalam kasus tim terdistribusi, setidaknya berbicara melalui tautan video. Jangan puas dengan laporan desas-desus dan saksi mata. Pahami ceritanya, apa yang diinginkan masing-masing pihak, mengapa mereka menginginkannya, apa yang mereka harapkan, apakah mereka pernah mencoba menyelesaikan masalah ini sebelumnya, apa yang akan terjadi jika masalah ini tidak diselesaikan, solusi apa yang mereka lihat, bagaimana mereka membayangkan posisi pihak-pihak tersebut. sisi lain, apa yang mereka pikirkan, benar atau salah, dll. Masukkan semua kemungkinan konteks ke dalam kepala Anda, dengan pikiran terbuka, dengan asumsi semua orang benar. Anda tidak berada di dalam konflik, Anda berada di luarnya, dalam sebuah metaposisi. Jika konteksnya hanya tersedia di thread postingan, setidaknya bacalah secara keseluruhan dan thread serta dokumen yang terkait dengannya. Setelah Anda membacanya, tetaplah berbicara dengan suara Anda. Anda hampir dijamin akan mendengar sesuatu yang penting yang tidak dikirimkan melalui pos.

Poin penting ketiga adalah pendekatan umum terhadap komunikasi. Ini adalah hal-hal biasa, bukan hal kosmik, tetapi sangat penting. Kami tidak mencoba menghemat waktu, kami berbicara dengan semua peserta, kami tidak mengkritik orang tersebut, tetapi kami mempertimbangkan konsekuensi dari tindakannya (bukan “Anda kasar”, tetapi “mungkin orang-orang tersebut tersinggung olehnya. hal ini”), kita beri kesempatan untuk menyelamatkan muka, kita melakukan diskusi secara langsung, bukan di depan antrean.

Konflik biasanya disebabkan oleh salah satu dari dua alasan. Yang pertama berkaitan dengan apakah seseorang pada saat konflik berada pada posisi dewasa atau posisi anak-anak (selengkapnya di bawah). Hal ini disebabkan oleh kematangan emosinya, kemampuan mengelola emosinya (yang tidak selalu berhubungan dengan usianya). Alasan umum kedua adalah ketidaksempurnaan proses kerja, yang menciptakan situasi wilayah abu-abu di mana tanggung jawab tersebar di antara para peserta, harapan para pihak tidak transparan satu sama lain, dan peran dalam proses menjadi kabur.

Oleh karena itu, dalam menyelesaikan suatu konflik (dan juga permasalahan lainnya), seorang manajer harus mengingat tiga perspektif: jangka pendek - untuk menyelesaikan permasalahan/konflik saat ini, jangka menengah - untuk meminimalkan kemungkinan timbulnya konflik lain. untuk alasan yang sama, dan dalam jangka panjang - untuk menumbuhkan budaya dewasa dalam diri tim.

Masing-masing dari kita memiliki inner child, yang berusia sekitar tiga atau empat tahun. Dia tidur hampir sepanjang waktu di tempat kerja, tetapi terkadang bangun dan mengambil kendali. Anak itu punya prioritasnya sendiri. Penting baginya untuk menegaskan bahwa ini adalah kotak pasirnya, ibunya lebih mencintainya, mesinnya adalah yang terbaik (desainnya adalah yang terbaik, ia memprogram yang terbaik, ...). Dalam situasi konflik, seorang anak dapat menekan mainan, menghentakkan kakinya dan memecahkan spatulanya, tetapi ia tidak dapat menyelesaikan masalah orang dewasa (arsitektur solusi, pendekatan pengujian otomatis, tanggal rilis, dll.), ia tidak memikirkan manfaatnya. untuk tim. Seorang anak yang berkonflik dapat disemangati, dihibur, dan disuruh tidur dengan memintanya menelepon orang dewasa. Sebelum memulai diskusi dalam situasi konflik, pastikan Anda berbicara dengan orang dewasa, bukan anak-anak, dan Anda sendiri berada pada posisi orang dewasa. Jika tujuan jujur ​​Anda saat ini adalah menyelesaikan masalah serius, Anda berada dalam posisi dewasa. Jika tujuan Anda adalah menghentakkan kaki dan mematahkan tulang belikat, ini adalah posisi yang kekanak-kanakan. Kirimkan inner child Anda ke tempat tidur dan teleponlah orang dewasa, atau jadwalkan ulang diskusi. Seseorang membuat keputusan emosional, dan kemudian mencari pembenaran rasional untuk keputusan tersebut. Keputusan yang diambil seorang anak berdasarkan prioritas anak tidak akan optimal.

Selain perilaku pada saat konflik, kedudukan seorang anak atau orang dewasa juga ditandai dengan tingkat tanggung jawab yang siap dipikul seseorang. Dalam manifestasinya yang ekstrem, posisi kekanak-kanakan seorang programmer, yang saya temui lebih dari sekali, terlihat seperti ini: Saya menulis kode, mengirimkannya untuk ditinjau - pekerjaan saya selesai. Reviewer harus meninjaunya dan menyetujuinya, QA harus memeriksanya, jika ada masalah, mereka akan memberi tahu saya. Anehnya, bahkan orang yang cukup dewasa dan berpengalaman pun terkadang berperilaku seperti ini. Ujung lain dari skala ini adalah bahwa seseorang menganggap dirinya bertanggung jawab untuk memastikan bahwa kodenya berfungsi, tercakup dalam pengujian, telah diperiksa secara pribadi olehnya, telah berhasil lulus tinjauan (jika perlu, tidak ada masalah dengan melakukan ping ke pengulas, mendiskusikan masalah melalui suara, dll.) dan telah disembunyikan, QA akan memberikan bantuan jika diperlukan, skenario pengujian akan dijelaskan, dll. Dalam kasus normal, pemrogram akan mulai mendekati skala dewasa, atau pindah ke sana seiring bertambahnya pengalaman (asalkan budaya yang tepat ditanamkan dalam tim). Dalam kasus ekstrim, ia terus bekerja, biasanya mengambil posisi kekanak-kanakan, kemudian ia dan tim secara berkala mengalami masalah dan konflik.

Menumbuhkan budaya yang benar dan matang dalam sebuah tim adalah tugas penting bagi manajer mana pun. Memang butuh waktu lama dan usaha setiap hari, tapi hasilnya sepadan. Ada dua cara untuk mempengaruhi budaya tim - memimpin dengan memberi contoh (yang pasti akan diikuti; tim selalu bergantung pada pemimpinnya) dan berdiskusi serta memberi penghargaan atas perilaku yang benar. Tidak ada yang muskil atau terlalu formal di sini, hanya ketika membahas masalah, perhatikan bahwa sesuatu bisa dilakukan di sini, tekankan bahwa Anda memperhatikan ketika diputuskan dengan benar, pujian, catatan selama peninjauan rilis, dll.

Mari kita pertimbangkan beberapa situasi konflik yang umum, dari yang sederhana hingga yang kompleks:

Konflik tidak terkait dengan masalah pekerjaan

Tak jarang terjadi konflik di tempat kerja yang tidak berkaitan dengan masalah pekerjaan. Kemunculan dan kemudahan penyelesaiannya biasanya berhubungan langsung dengan tingkat kecerdasan emosional peserta, tingkat kematangannya, dan tidak berhubungan dengan sempurna atau tidaknya proses kerja.

Contoh umum: seseorang tidak cukup sering menggunakan mesin cuci atau mandi, hal yang tidak disukai orang lain, ada yang pengap, ada yang kemasukan angin jika membuka jendela, ada yang terlalu berisik, dan ada yang butuh ketenangan untuk bekerja, dan segera. Lebih baik tidak menunda penyelesaian konflik semacam ini dan tidak membiarkan konflik tersebut mengambil jalannya sendiri. Mereka tidak akan menyelesaikannya sendiri dan akan mengalihkan perhatian Anda dari pekerjaan setiap hari dan meracuni suasana dalam tim. Untungnya, penyelesaiannya biasanya bukan masalah besar - cukup berbicara dengan tenang (satu lawan satu, tentu saja) dengan rekan kerja yang mengabaikan kebersihan, menyediakan tempat duduk yang nyaman bagi orang yang lebih menyukai keheningan/kesejukan, membeli headphone penyerap suara atau memasang partisi , dll.

Contoh lain yang saya temui beberapa kali selama bekerja adalah ketidakcocokan psikologis anggota tim. Untuk beberapa alasan, orang tidak bisa bekerja sama; setiap interaksi berakhir dengan skandal. Kadang-kadang hal ini disebabkan oleh fakta bahwa orang-orang mempunyai pandangan yang berbeda mengenai suatu masalah yang mendesak (biasanya politik) dan tidak tahu bagaimana cara meninggalkan mereka di luar pekerjaan. Meyakinkan mereka untuk bertoleransi satu sama lain atau mengubah perilaku adalah tugas yang sia-sia. Satu-satunya pengecualian yang saya temui adalah rekan-rekan muda dengan persepsi terbuka; perilaku mereka masih dapat diubah secara bertahap melalui percakapan berkala. Biasanya masalah berhasil diselesaikan dengan memisahkan mereka ke dalam tim yang berbeda, atau setidaknya sangat jarang memberikan kesempatan untuk tumpang tindih dalam pekerjaan.

Dalam semua situasi di atas, ada baiknya berbicara dengan semua peserta secara pribadi, mendiskusikan situasinya, menanyakan apakah mereka melihat adanya masalah dalam kasus ini, menanyakan apa, menurut pendapat mereka, solusinya, dan memastikan partisipasi mereka dalam mewujudkan hal ini. keputusan.

Dari sudut pandang optimalisasi proses kerja (perspektif jangka menengah yang saya sebutkan), tidak banyak yang bisa dilakukan di sini, yang bisa dilakukan hanyalah optimalisasi dengan mempertimbangkan faktor kompatibilitas saat membentuk tim dan tidak menempatkan orang. bersama-sama terlebih dahulu siapa yang akan berkonflik.

Dari perspektif budaya tim, situasi seperti ini lebih jarang muncul dalam tim dengan budaya yang matang, di mana orang-orang menghormati tim dan rekan kerja serta tahu cara menyelesaikan masalah secara mandiri. Selain itu, konflik-konflik seperti ini dapat diselesaikan dengan lebih mudah (seringkali secara otomatis) dalam tim yang memiliki tingkat kepercayaan yang tinggi, orang-orang yang telah lama bekerja sama dan/atau sering berkomunikasi di luar pekerjaan.

Konflik yang berkaitan dengan masalah pekerjaan:

Konflik tersebut biasanya disebabkan oleh kedua alasan sekaligus, baik emosional (salah satu peserta tidak dalam posisi dewasa) maupun ketidaksempurnaan proses kerja itu sendiri. Mungkin jenis konflik paling umum yang saya temui adalah konflik selama peninjauan kode atau diskusi arsitektur antar pengembang.

Saya akan menyoroti dua kasus umum di sini:

1) Dalam kasus pertama, pengembang tidak bisa mendapatkan tinjauan kode dari rekannya. Tambalan dikirim untuk ditinjau, dan tidak ada yang terjadi. Sekilas memang tidak ada konflik yang terlihat jelas antara kedua belah pihak, namun jika dipikir-pikir, ini adalah konflik yang cukup besar. Masalah pekerjaan tidak terselesaikan, salah satu pihak (menunggu review) jelas mengalami ketidaknyamanan. Subtipe ekstrem dari kasus ini adalah pengembangan dalam komunitas atau tim yang berbeda, sedangkan peninjau mungkin tidak tertarik dengan kode khusus ini, karena pemuatan atau keadaan lain, mungkin tidak memperhatikan permintaan peninjauan sama sekali, dan arbiter eksternal (seorang manajer yang sama bagi kedua belah pihak) ) mungkin tidak ada sama sekali.

Pendekatan solusi yang membantu dalam situasi seperti ini berkaitan erat dengan perspektif jangka panjang, budaya orang dewasa. Pertama, aktivitas cerdas berhasil. Anda tidak boleh berharap bahwa kode yang tergantung pada review akan menarik perhatian reviewer itu sendiri. Kita perlu membantu pengulas memperhatikannya. Pingani beberapa orang, mengajukan pertanyaan tentang sinkap, berpartisipasi dalam diskusi. Jelas sekali, sikap mendesak lebih cenderung merugikan daripada membantu, Anda perlu menggunakan akal sehat. Kedua, persiapan awal berjalan dengan baik. Jika tim memahami apa yang terjadi dan mengapa, mengapa kode ini diperlukan, desain telah didiskusikan dan disepakati sebelumnya dengan semua orang, orang akan lebih cenderung memperhatikan kode tersebut dan menerimanya untuk bekerja. Ketiga, otoritas bekerja. Jika Anda ingin direview, lakukan banyak review sendiri. Lakukan ulasan berkualitas tinggi, dengan pemeriksaan nyata, tes nyata, dan komentar bermanfaat. Jika nama panggilan Anda terkenal di tim, kemungkinan besar kode Anda akan diperhatikan.

Dari sudut pandang alur kerja, perbaikan yang mungkin dilakukan di sini adalah penentuan prioritas yang tepat yang bertujuan membantu pengembang mencapai tujuan mereka dan tim (meninjau orang lain, menulis surat kepada komunitas, menyertai kode dengan deskripsi arsitektur, dokumentasi, pengujian, berpartisipasi dalam diskusi dengan komunitas, dll.), mencegah patch terlalu lama berada di antrian, dan sebagainya.

2) Kasus konflik umum kedua selama tinjauan kode atau desain adalah perbedaan pandangan mengenai masalah teknis, gaya pengkodean, dan pilihan alat. Yang sangat penting dalam hal ini adalah tingkat kepercayaan antar peserta, tergabung dalam tim yang sama, dan pengalaman bekerja sama. Jalan buntu terjadi ketika salah satu peserta mengambil posisi kekanak-kanakan dan tidak berusaha mendengarkan apa yang ingin disampaikan lawan bicaranya. Seringkali, baik pendekatan yang diusulkan oleh pihak lain maupun pendekatan yang diusulkan pada awalnya mungkin berhasil dan pada prinsipnya tidak menjadi masalah pendekatan mana yang harus dipilih.

Suatu hari, seorang programmer dari tim saya (sebut saja dia Pasha) menyiapkan patch dengan perubahan pada sistem penerapan paket, yang dikembangkan dan didukung oleh rekan-rekan dari departemen tetangga. Salah satu dari mereka (Igor) mempunyai pendapat yang kuat mengenai bagaimana tepatnya layanan Linux harus dikonfigurasi ketika menerapkan paket. Pendapat ini berbeda dengan pendekatan yang diusulkan dalam patch, dan mereka tidak dapat menyetujuinya. Seperti biasa, tenggat waktu hampir habis, dan perlu diambil suatu keputusan, salah satu dari mereka perlu mengambil posisi dewasa. Pasha mengakui bahwa kedua pendekatan tersebut memiliki hak untuk hidup, namun ia ingin pilihannya lolos, karena Baik opsi satu maupun opsi kedua tidak memiliki keunggulan teknis yang jelas.

Diskusi kami terlihat seperti ini (secara skematis, tentu saja percakapan berlangsung selama setengah jam):

- Pasha, kami memiliki fitur membekukan dalam beberapa hari. Penting bagi kita untuk mengumpulkan semuanya dan memulai pengujian sesegera mungkin. Bagaimana kita bisa melewati Igor?
— Dia ingin mengatur layanan secara berbeda, dia memberikan komentar di sana untuk saya...
- Dan apa yang terjadi, perubahan besar, banyak keributan?
- Tidak, ada pekerjaan selama beberapa jam, tetapi pada akhirnya tidak ada perbedaan, itu akan berhasil, mengapa ini perlu? Saya membuat sesuatu yang berhasil, mari kita terima.
- Dengar, sudah berapa lama kamu membicarakan semua ini?
- Ya, kami sudah menandai waktu selama satu setengah minggu sekarang.
- Um... bisakah kita menyelesaikan masalah dalam beberapa jam yang sudah memakan waktu satu setengah minggu, dan tidak melakukannya?
- Ya, tapi aku tidak ingin Igor berpikir aku menyerah...
- Dengar, apa yang lebih penting bagimu, mengeluarkan pembebasan, bersama dengan keputusanmu di dalam, atau membunuh Igor? Kami dapat memblokirnya, namun, ada peluang bagus untuk lolos dengan rilis tersebut.
- Yah... pasti keren kalau usap hidung Igor, tapi oke, pelepasannya lebih penting, saya setuju.
- Apakah pendapat Igor begitu penting bagimu? Sejujurnya, dia tidak peduli sama sekali, dia hanya menginginkan pendekatan terpadu di berbagai bidang yang menjadi tanggung jawabnya.
- Baiklah, biarkan saya melakukan apa yang dia minta di komentar dan mari kita mulai pengujian.
- Terima kasih, Pasha! Aku yakin di antara kalian berdua kalian akan lebih dewasa, meski Igorek lebih tua dari kalian :)

Masalah terselesaikan, rilis dirilis tepat waktu, Pasha tidak merasa banyak ketidakpuasan, karena dia sendiri yang mengusulkan solusi dan menerapkannya. Igor secara umum senang, karena... Pendapatnya diperhitungkan dan mereka melakukan apa yang dia sarankan.

Jenis lain dari konflik yang pada dasarnya sama adalah pilihan antara solusi/perpustakaan/pendekatan teknis dalam sebuah proyek, terutama dalam tim terdistribusi. Pada salah satu proyek yang diposisikan menggunakan C/C++, ternyata pihak teknis manajemen proyek tersebut tegas menolak penggunaan STL (Standard Template Library). Ini adalah perpustakaan bahasa standar yang menyederhanakan pengembangan, dan tim kami sudah sangat terbiasa dengannya. Ternyata proyek ini lebih mirip dengan C daripada C++, yang tidak terlalu menginspirasi tim, karena manajemen mencoba yang terbaik dan merekrut pemain plus yang sangat keren. Pada saat yang sama, anggota tim Amerika, baik insinyur maupun manajer, telah lama bekerja di perusahaan tersebut, terbiasa dengan keadaan saat ini, dan senang dengan segalanya. Bagian tim Rusia dikumpulkan baru-baru ini, dalam beberapa minggu (termasuk saya). Bagian tim Rusia dengan tegas tidak ingin meninggalkan pendekatan pengembangan yang biasa.

Diskusi tertulis tanpa akhir dimulai antara dua benua, surat-surat di tiga atau empat layar terbang bolak-balik, dalam surat kelompok dan pribadi, dari pemrogram ke pemrogram dan manajer. Seperti biasanya, surat-surat sepanjang ini tidak dibaca oleh siapa pun kecuali penulis dan pendukung setia mereka. Obrolan berderit dengan ketegangan, menyampaikan pemikiran multi-layar ke berbagai arah mengenai keunggulan teknis STL, seberapa baik pengujiannya, seberapa amannya, dan secara umum, betapa indahnya hidup dengan STL, dan betapa buruknya tanpa itu. .

Ini semua berlangsung cukup lama, hingga akhirnya saya menyadari bahwa kami sedang membahas aspek teknis dari masalah tersebut, namun masalahnya sebenarnya bukan teknis. Masalahnya bukan pada kelebihan atau kekurangan STL atau kesulitan bekerja tanpa STL. Masalahnya lebih bersifat organisasional. Kami hanya perlu memahami cara kerja perusahaan tempat kami bekerja. Tak satu pun dari kami memiliki pengalaman bekerja di perusahaan seperti itu sebelumnya. Masalahnya adalah setelah kode dikembangkan dan dirilis ke produksi, dukungan ditangani oleh orang yang sangat berbeda dari tim lain, dari negara lain. Tim teknik besar yang terdiri dari beberapa puluh ribu insinyur (secara total) hanya mampu membeli sarana teknis minimum yang mendasar, bisa dikatakan, minimum minimum. Apa pun yang melampaui standar teknik yang ditetapkan secara fisik di perusahaan tidak dapat didukung di masa depan. Level sebuah tim ditentukan oleh level anggota terlemahnya. Setelah kita paham motivasi nyata tindakan tim bagian Amerika, masalah ini telah dihapus dari agenda, dan bersama-sama kami berhasil mengembangkan dan merilis produk menggunakan standar yang diadopsi oleh perusahaan. Surat dan obrolan dalam kasus ini tidak berjalan dengan baik; dibutuhkan beberapa kali perjalanan dan banyak komunikasi pribadi untuk sampai pada kesamaan.

Dari sudut pandang alur kerja, dalam kasus khusus ini, akan membantu jika memiliki deskripsi alat yang digunakan, persyaratannya, pembatasan penambahan alat baru, dan pembenaran atas pembatasan tersebut. Dokumen-dokumen tersebut kira-kira sesuai dengan yang dijelaskan dalam paragraf Strategi Penggunaan Kembali dan Lingkungan Pengembangan dari “Buku Pegangan Manajer untuk Pengembangan Perangkat Lunak”, yang dikembangkan di NASA. Meskipun usianya sudah tua, ia dengan sempurna menggambarkan semua kegiatan utama dan tahapan perencanaan pengembangan perangkat lunak semacam ini. Memiliki dokumen seperti ini memudahkan untuk mendiskusikan komponen dan pendekatan apa saja yang dapat digunakan dalam suatu produk, dan alasannya.

Dari segi budaya tentunya dengan posisi yang lebih matang, dimana para pihak berusaha mendengar dan memahami motivasi sebenarnya dari tindakan rekan-rekannya dan bertindak berdasarkan prioritas proyek dan tim, dan bukan ego pribadi. , konflik akan diselesaikan dengan lebih mudah dan cepat.

Dalam konflik lain mengenai pilihan solusi teknis, saya juga membutuhkan banyak waktu untuk memahami motivasi salah satu pihak (ini adalah kasus yang sangat tidak biasa), tetapi setelah motivasinya jelas, solusinya pun jelas.

Situasinya begini: pengembang baru muncul dalam tim yang terdiri dari sekitar 20 orang, sebut saja dia Stas. Saat itu, alat komunikasi standar kami sebagai sebuah tim adalah Skype. Ternyata kemudian, Stas adalah penggemar berat standar terbuka dan perangkat lunak sumber terbuka, dan hanya menggunakan alat dan sistem operasi yang sumbernya tersedia untuk umum dan menggunakan protokol yang dijelaskan secara publik. Skype bukan salah satu alat ini. Kami menghabiskan banyak waktu mendiskusikan kelebihan dan kekurangan pendekatan ini, upaya untuk meluncurkan analog Skype pada sistem operasi yang berbeda, upaya Stas untuk meyakinkan tim untuk beralih ke standar lain, menulis surat kepadanya secara pribadi melalui surat, meneleponnya secara pribadi di telepon, belikan dia komputer kedua khusus untuk Skype, dll. Akhirnya saya menyadari bahwa masalah ini pada hakikatnya bukan masalah teknis atau organisasional, melainkan ideologis, bahkan bisa dikatakan keagamaan (bagi Stas). Bahkan jika kami akhirnya menghubungkan Stas dan Skype (yang memerlukan waktu beberapa bulan), masalah akan muncul lagi pada instrumen berikutnya. Saya tidak punya cara nyata untuk mengubah pandangan dunia Stas, dan tidak ada alasan untuk mencoba mengubah pandangan dunia tim yang bekerja dengan sempurna di lingkungan ini. Pandangan dunia orang tersebut dan perusahaannya ortogonal. Dalam situasi seperti ini, solusi yang baik adalah organisasi. Kami memindahkan Stas ke tim lain, di mana dia lebih organik.

Penyebab konflik ini, menurut saya, adalah ketidaksesuaian antara budaya pribadi seseorang (yang mempunyai pendapat kuat yang tidak memungkinkannya untuk berkompromi) dan budaya perusahaan. Dalam hal ini tentu saja kesalahan pengelola. Awalnya salah jika mengajaknya mengerjakan proyek semacam ini. Stas akhirnya pindah ke proyek pengembangan perangkat lunak sumber terbuka dan unggul di sana.

Contoh yang baik dari konflik yang disebabkan oleh sikap kekanak-kanakan pengembang dan kekurangan proses kerja adalah situasi di mana, tanpa adanya definisi selesai, pengembang dan tim QA memiliki ekspektasi berbeda mengenai kesiapan. fitur ditransfer ke QA. Pengembang percaya bahwa cukup dengan menulis kode dan membuang fitur tersebut ke QA - mereka akan menyelesaikannya di sana. Omong-omong, seorang programmer yang cukup matang dan berpengalaman, tapi itu adalah ambang batas kualitas internalnya. QA tidak setuju dengan hal ini dan meminta untuk menunjukkan dan menjelaskan kepada mereka apa yang telah dia periksa sendiri, dan meminta naskah pengujian untuk mereka. Mereka pernah mengalami masalah dengan fungsionalitas dari pengembang ini di masa lalu dan tidak ingin membuang waktu lagi. Omong-omong, mereka benar - fitur tersebut benar-benar tidak berfungsi, dia tidak memeriksa kode sebelum mengirimkannya ke QA.

Untuk mengatasi situasi ini, saya memintanya untuk menunjukkan kepada saya bahwa semuanya benar-benar berfungsi (tidak berhasil, dan dia harus memperbaikinya), kami berbicara dengan tim dan dengan definisi QA selesai (mereka tidak berhasil masuk menulis, karena kami tidak ingin membuat prosesnya terlalu birokratis ), kami segera berpisah dengan spesialis ini (untuk kelegaan umum).

Dari sudut pandang alur kerja, perbaikan yang mungkin dilakukan dalam hal ini adalah adanya definisi selesai, persyaratan dukungan setiap fitur unit dan pengujian integrasi, serta deskripsi pengujian yang dilakukan oleh pengembang. Di salah satu proyek, kami mengukur tingkat cakupan kode dengan pengujian selama CI dan jika tingkat cakupan turun setelah menambahkan patch, pengujian tersebut ditandai sebagai gagal, mis. kode baru apa pun hanya dapat ditambahkan jika ada pengujian baru untuk kode tersebut.

Contoh tipikal konflik lainnya berkaitan erat dengan pengorganisasian proses kerja. Kami memiliki produk, tim pengembangan produk, tim dukungan, dan pelanggan. Pelanggan memiliki masalah dengan produk dan menghubungi dukungan. Dukungan menganalisis masalah dan memahami bahwa masalahnya ada pada produk dan mentransfer masalah tersebut ke tim produk. Tim produk sedang sibuk, rilis semakin dekat, sehingga tiket dengan masalah dari pelanggan, hilang di antara tiket lain dari pengembang yang ditugaskan, hang selama beberapa minggu tanpa perhatian. Dukungan berpendapat bahwa pengembang sedang mengatasi masalah pelanggan. Pelanggan menunggu dan berharap masalahnya teratasi. Kenyataannya, belum ada yang terjadi. Setelah beberapa minggu, pelanggan akhirnya memutuskan untuk menaruh perhatian pada kemajuannya dan menanyakan dukungan bagaimana keadaannya. Dukungan meminta pengembangan. Pengembang bergidik, melihat daftar tiket dan menemukan tiket dari pelanggan di sana. Membaca tiket dari pelanggan, dia memahami bahwa tidak ada cukup informasi untuk menyelesaikan masalah, dan dia membutuhkan lebih banyak log dan dump. Dukungan meminta informasi tambahan dari pelanggan. Dan kemudian pelanggan menyadari bahwa selama ini tidak ada seorang pun yang mengatasi masalahnya. Dan guntur akan menyambar...

Dalam situasi ini, solusi terhadap konflik itu sendiri cukup jelas dan linier (memperbaiki produk, memperbarui dokumentasi dan pengujian, menenangkan pelanggan, merilis perbaikan terbaru, dll.). Penting untuk menganalisis proses kerja dan memahami siapa yang bertanggung jawab mengatur interaksi antara kedua tim, dan mengapa situasi ini bisa terjadi. Jelas apa yang perlu diperbaiki dalam prosesnya - seseorang harus memantau gambaran keseluruhan tanpa pengingat dari pelanggan, secara proaktif. Tiket dari pelanggan harus menonjol di antara tiket lain dari pengembang. Dukungan harus melihat apakah tim pengembangan sedang mengerjakan tiketnya, dan jika tidak, kapan tim dapat mulai bekerja, dan kapan hasil dapat diharapkan. Dukungan dan pengembangan harus mengkomunikasikan dan mendiskusikan status tiket secara berkala, pengumpulan informasi yang diperlukan untuk debugging harus diotomatisasi sebanyak mungkin, dll.

Sama seperti dalam perang, musuh mencoba mencapai persimpangan antara dua unit, demikian pula dalam pekerjaan, titik yang paling rumit dan rentan biasanya adalah interaksi antar tim. Jika manajer dukungan dan pengembangan sudah cukup umur, mereka akan dapat memperbaiki prosesnya sendiri, jika tidak, proses tersebut akan terus menimbulkan konflik dan masalah sampai ada manajer yang dapat memperbaiki situasi tersebut turun tangan.

Contoh umum lainnya yang telah saya lihat berulang kali di perusahaan yang berbeda adalah situasi di mana suatu produk ditulis oleh satu tim, tes integrasi otomatis untuk produk tersebut ditulis oleh tim kedua, dan infrastruktur tempat semuanya dioperasikan disertai oleh tim ketiga. tim. Masalah saat menjalankan pengujian muncul setiap saat, dan penyebab masalah di dalamnya dapat berupa produk, pengujian, dan infrastruktur. Biasanya sulit untuk menyepakati siapa yang harus melakukan analisis awal terhadap masalah, kesalahan file, penguraian log produk, pengujian dan infrastruktur, dll. Konflik di sini sangat sering terjadi, dan pada saat yang sama, seragam. Dalam kasus intensitas emosional yang tinggi, peserta sering kali jatuh ke dalam posisi kekanak-kanakan dan diskusi dimulai dalam rangkaian: “mengapa saya harus mengutak-atik ini”, “mereka lebih sering putus asa”, dll.

Dari perspektif alur kerja, langkah spesifik untuk menyelesaikan masalah bergantung pada komposisi tim, jenis pengujian dan produk, dll. Dalam salah satu proyek, kami memperkenalkan tugas berkala, di mana tim memantau pengujian satu per satu, minggu demi minggu. Di sisi lain, analisis awal selalu dilakukan oleh pengembang pengujian, namun analisisnya sangat mendasar dan produknya cukup stabil, sehingga berfungsi dengan baik. Kuncinya adalah memastikan prosesnya transparan, harapannya jelas bagi semua pihak, dan situasi terasa adil bagi semua orang.

Apakah konflik bahkan menjadi masalah dalam sebuah organisasi? Apakah ini pertanda buruk bahwa konflik sering terjadi (atau hanya terjadi secara berkala) di tim Anda? Secara umum tidak, karena jika ada pertumbuhan, perkembangan, ada dinamika, maka timbul persoalan-persoalan yang belum pernah terselesaikan sebelumnya, dan bila diselesaikan dapat timbul konflik. Hal ini merupakan indikator bahwa ada beberapa hal yang perlu mendapat perhatian, dan masih ada hal-hal yang perlu diperbaiki. Alangkah buruknya jika konflik sering muncul, sulit diselesaikan, atau memakan waktu lama. Hal ini kemungkinan besar merupakan tanda dari proses kerja yang kurang efisien dan kurangnya kematangan tim.

Sumber: www.habr.com