Bagaimana kami mencoba mobbing

Jika Anda mencoba untuk menemukan gerombolan atau gerombolan di mesin pencari, maka sebagian besar hasil akan mengenai "penyalahgunaan psikologis orang." Karena itu, lebih baik segera mencari "pemrograman mob". Dalam 10 hasil Yandex teratas saat ini (27/2/2019) hanya ada satu artikel dalam bahasa Rusia (dan itu adalah terjemahan), tetapi ada banyak artikel dalam bahasa Inggris. Jika Anda melihat mereka dengan lancar, maka kebanyakan dari mereka adalah teori, bukan analisis dari setiap kasus praktis. Semua orang mengatakan bahwa ini akan membantu tim menjadi lebih efektif, mendistribusikan keahlian proyek secara lokal, dan mengembangkan soft skill pada orang. Saya sendiri menguji latihan dalam salah satu pelatihan scrum, dan, terus terang, senang! Setelah berkonsultasi dengan tim, kami memutuskan untuk melakukan sesi mobbing tes kami.

Di antara kelebihan pendekatan ini untuk bekerja, kami mengidentifikasi bagi diri kami sendiri nilai-nilai seperti penyebaran keahlian dalam tim dan pengembangan keterampilan tambahan untuk setiap peserta. Setelah mengorganisir pertemuan yang didedikasikan untuk mobbing, kami menetapkan diri kami tiga tujuan: pertama, untuk mencoba mobbing dalam praktik. Kedua, untuk memahami apa kerugian dan faktor negatif yang ada di dalamnya dalam kasus kami. Ketiga, tentukan apakah itu akan membawa nilai-nilai di atas ke tim kami.

Apa yang dikerumuni

Pendiri mobbing sebagai gaya kerja Woody Zuill menggambarkannya sebagai berikut:

orang-orang hebat bekerja bersama dalam satu tugas pada satu waktu di satu tempat di satu komputer.

Artinya, Mobbing adalah gaya kerja ketika sebuah tim terus-menerus bekerja bersama dan bersama-sama "menerkam" pada tugas apa pun. Pada saat yang sama, tugas melewati semua tahap yang diperlukan dari siklus hidupnya, dan setiap anggota tim mengerjakannya secara bersamaan dengan semua orang. Dengan demikian, perendaman dan pemahaman tugas oleh seluruh tim tercapai.

Ada beberapa peran dalam mobbing:

• Pengemudi: duduk di tempat kerja umum, melakukan persis seperti yang dikatakan navigator kepadanya.
• Navigator: memberikan instruksi kepada pengemudi. Jika dia tidak tahu apa yang harus dilakukan, dia berkonsultasi dengan massa (sisa tim), menyiarkan tindakan yang diperlukan kepada pengemudi.
• Mob: berpartisipasi dalam pengembangan, memberi tahu navigator apa yang harus dilakukan pengemudi.
• PO (pemilik produk): tahu persis apa yang harus terjadi. Tetapkan arah yang diinginkan untuk pergerakan tim. Ini bisa menjadi driver dan navigator.
• Fasilitator: memantau kepatuhan terhadap aturan, mengumumkan shift, memarkir ide. Sangat diharapkan bahwa ada satu orang dalam peran ini.

Mobbing terdiri dari sesi, yang terdiri dari siklus, yang masing-masing terdiri dari shift.
Sesi - periode waktu di mana tim mengerjakan tugas. Sebelum sesi, tugas dipilih dan dibagi menjadi beberapa tahap, dan tujuannya ditentukan - apa yang perlu diperoleh sebagai hasilnya, misalnya, kenaikan fungsional.

Ubah - interval waktu antara mengubah peran pengemudi dan navigator. Ubah berlangsung, sebagai aturan, 15-20 menit. Pergeseran yang lebih pendek berkontribusi pada kecepatan yang lebih tinggi dan keterlibatan tim yang lebih besar.

Aturan gim

Selama shift, pengemudi duduk di komputer bersama dan melakukan persis apa yang dikatakan navigator kepadanya. Tim mengamati dan, jika perlu, membahas apa yang perlu dilakukan. Navigator menyusun diskusi ini dan menyiarkan kepada pengemudi apa yang sebenarnya harus dia lakukan sekarang. Pengemudi hanya mendengarkan instruksi dari navigator dan dapat mengajukan pertanyaan kepadanya. Navigator dapat menyiarkan pertanyaan ke tim. Fasilitator “taman” ide yang disuarakan tetapi tidak digunakan karena satu dan lain alasan.

Pada akhir pergantian peran, peran pengemudi dan navigator ditransfer ke orang lain dalam antrian yang telah ditentukan: navigator saat ini pergi ke massa, pengemudi menjadi navigator, dan orang berikutnya dalam antrian menjadi pengemudi dari massa. Ketika setiap anggota tim mengunjungi masing-masing peran, "lingkaran ditutup", yaitu, siklus berakhir.



Setelah sesi gerombolan, kami masing-masing berbagi kesan, berdasarkan kesimpulan tertentu. Sebagai hasilnya, kami mendapat hasil yang memberikan pemahaman tentang bagaimana dan kapan lebih baik menggunakan mobbing, dan apakah itu cocok dengan tim kami. Saya akan mulai dengan tayangan negatif.

Negatif

Terkadang peran navigator tidak sepenuhnya jelas. Pada titik tertentu, misalnya, analis bisa berada dalam peran ini, dan pengembang bisa menjadi pendorongnya. Navigator menceritakan kembali apa yang dikatakan tim kepadanya, tidak sepenuhnya memahami "apa artinya semua ini," karena kurangnya pengalaman pengembangan. Akibatnya, muncul situasi di mana navigator sama sekali tidak masuk akal untuk mengirimkan instruksi perintah, karena, pertama, pengembang mendengar perintah, jadi mengapa dia memerlukan perantara? Kedua, pengemudi mengerti bagaimana harus bertindak dalam situasi ini, tetapi menurut aturan peran, tangannya terikat.

Kami juga mencatat bahwa jika navigator perlu melihat tab berikutnya di lingkungan pengembangan untuk menentukan langkah selanjutnya, maka dia perlu menyuarakan ide ini dan menunggu pengemudi untuk mengganti tab. Dia sendiri akan melakukan ini sementara dia menyuarakan permintaan itu kepada pengemudi, dengan semua orang “berbaik hati” dan “tolong terima kasih”.

Kesulitannya adalah kami memiliki dua pengembang yang bekerja dari jarak jauh. Pertama-tama, ia menambahkan waktu untuk operasi seperti "mengalihkan hak ke kursor": sehingga administrator jarak jauh dapat menunjukkan sesuatu di layar, tetapi pada saat yang sama tidak mengambil kendali mouse. Untuk melakukan ini, perlu memperluas jendela kontrol konferensi, mengaktifkan orang yang tepat untuk mengontrol kursor, dan meminimalkan jendela. Tidak butuh waktu lama, tetapi sangat mengganggu, mengetuk itu dari tugas (yang baru saja mulai terjun ke dalamnya), dan umumnya mengganggu. Akibatnya, setelah setiap shift, navigator baru harus bertanya pada yang sebelumnya apa yang ingin dia lakukan sekarang, keduanya harus mengingat ini, "menyinkronkan", dan hanya kemudian melanjutkan.

Kesulitan lain karena "keterpencilan" beberapa karyawan adalah tetangga mereka. Pada titik tertentu, seorang tetangga di navigator jarak jauh memutuskan untuk mengebor lubang di seluruh rumah, jadi kami mendengar berbagai suara yang menyertainya dengan amplifikasi. Ini, seperti yang Anda tahu, sama sekali tidak membantu kami.

Karena waktu kami sangat terbatas (satu jam per sesi mobbing), shift kami sangat singkat - masing-masing 5 menit (sehingga setiap peserta punya waktu untuk mengunjungi peran ini atau itu setidaknya sekali). Menurut saya, ini juga sangat tercermin dalam kemajuan. Seperti yang dikatakan sebelumnya, semua peserta dalam sesi tenggelam dalam tugas hanya pada akhir shift (1-2 menit sampai akhir), dan setelah periode waktu yang singkat ini semua orang terganggu oleh saklar. Jelas bahwa Anda tidak akan melakukan banyak hal dengan cara ini.

Tim lain ingin lebih banyak waktu untuk berpikir "diam-diam" dan mendiskusikan ide-ide, tetapi sering bergiliran mencoba untuk menguji lebih banyak dengan tangan daripada dihipotesiskan dalam teori.

Kami tidak mengambil kasus paling sederhana untuk percobaan selama satu jam: tugas dari proyek lain yang tidak terlalu akrab bagi tim kami. Sebagian besar waktu kami menemukan bagaimana potongan kode yang perlu kami ubah umumnya berfungsi. Selama total 7 jam kerja (1 jam untuk setiap anggota tim), kami benar-benar tidak mengerti sisi mana yang mendekati tugas ini.

Faktor tersebut dicatat bahwa seluruh tim melihat solusi untuk masalah dari sudut pandang tertentu, termasuk penguji. Kami berasumsi bahwa di masa depan (ketika kami mencapai tahap yang sesuai) ini dapat berdampak negatif terhadap obyektivitas pengujian, karena kita semua akan tahu "cara kerjanya", dan tanpa sadar kita akan mencoba menghindari kemacetan. Sayangnya, ini hanya asumsi.

Tetapi hipotesis kami yang lain telah dikonfirmasi. Bahkan sebelum sesi, kami menyarankan bahwa jika orang-orang dengan visi berbeda bertemu saat mengerjakan tugas yang sama, maka akan ada ras ide. Inilah yang terjadi: beberapa pengembang menyarankan untuk melakukan debugging lokal melalui tes integrasi, yang lain - dengan sepenuhnya mengimplementasikan proses bisnis yang seharusnya diubah. Masing-masing pihak membuat argumen yang meyakinkan. Kami keluar dari situasi ini karena kami memutuskan untuk mencoba satu pendekatan terlebih dahulu, dan jika pada saat yang disepakati kami menyadari bahwa metode ini membutuhkan lebih banyak tenaga kerja, maka kami akan menggunakan opsi alternatif.

Pengaturan di lingkungan pengembangan ternyata menjadi batu sandungan: masing-masing pengembang merasa nyaman dengan parameter spesifik mereka sendiri. Dalam hal ini, hanya ada satu lingkungan pengembangan, dan, tentu saja, tidak semua orang menyukai pengaturannya.

Kami bahkan berhasil membuat kesalahan fasilitasi: sesaat sebelum akhir shift, calon pengemudi pergi minum teh. Akibatnya, navigatornya juga pergi untuk menyeduh teh, dan kami kehilangan satu shift dalam waktu.

Seperti yang Anda lihat, beberapa faktor negatif muncul sebagai akibat dari kesalahan organisasi, tetapi, bagaimanapun, mereka menunjukkan bagaimana melakukan lebih baik dan mengapa.

Positif

Peserta mencatat bahwa gaya kerja ini memungkinkan orang yang biasanya menerima tugas dari bisnis, menganalisis dan mengujinya, untuk menyelidiki proses penyelesaian langsung masalah ini. Mereka melihat pekerjaan pada mereka dari sisi lain: langkah-langkah apa yang dilalui sebuah tugas dalam perjalanan ke implementasinya. Jelas bagi mereka tindakan apa yang dilakukan pengembang untuk memahami cara mendekati solusinya. Dengan demikian, semua orang melihat dan memahami apa yang sedang terjadi dengan tugas tersebut.

Bagi sebagian dari kita menjadi jelas mengapa pengembang sering memerlukan analisis yang lebih mendalam ketika menjelaskan suatu tugas, dan mengapa mereka kadang-kadang bertanya agak tidak masuk akal, pada pandangan pertama, mengklarifikasi pertanyaan.

Tidak diragukan lagi, ini adalah pengalaman baru dan berharga bagi kita masing-masing. Selain itu, kolaborasi yang tidak biasa seperti itu membantu memperkuat tim, yaitu berfungsi sebagai semacam pembangunan tim: untuk pertama kalinya, seseorang melihat pekerjaan langsung orang lain, mempelajari pikirannya dalam situasi tertentu.

Hasil

Setelah membahas umpan balik yang diterima dari satu sama lain tentang sesi ini, kami sampai pada kesimpulan tertentu.

Menurut hasil kami, ternyata dalam mobbing Anda tidak boleh bekerja sepenuhnya dengan seluruh tim, atau setidaknya tidak terus-menerus. Dalam kenyataan kami, jika seluruh tim hanya mengerjakan satu tugas, maka negosiasi dengan kontraktor tidak dilakukan dan permintaan pengguna tidak diproses. Anda dapat, tentu saja, melakukan ini sampai giliran kerja Anda tiba, tetapi kemudian Anda perlu terganggu, beralih ke tugas yang diselesaikan semua orang, lalu keluar lagi dan ingat apa yang Anda hentikan sebelum giliran kerja.

Perlu bahwa navigator adalah pengemudi yang sedikit lebih berpengalaman. Kalau tidak, itu ternyata menjadi permainan telepon yang rusak, ketika navigator mencoba untuk benar-benar melewati pengemudi apa yang dia katakan, tidak sepenuhnya memahami "apa artinya semua itu." Anda dapat, misalnya, mengubah peran tidak secara bergantian. Jika Anda tidak dapat memberikan navigator yang lebih kuat kepada pasangan, tetapi Anda perlu mengajar orang untuk bekerja tidak hanya sesuai dengan spesialisasi mereka, maka, menurut kami, pemrograman pasangan akan lebih efektif.

Kami mendapat kesan bahwa mobbing akan bekerja dengan baik ketika pengembang baru muncul di tim, atau seseorang di tim jelas ingin memprogram. Kemudian, ketika melakukan mobbing dengan pengembang yang berpengalaman, pendatang baru akan dengan cepat membenamkan diri dalam proyek tim dan memahami prinsip dan aturan kerja yang diterima secara umum.

Dengan cara yang sama, Anda dapat mengerjakan tugas yang hanya memiliki satu orang di tim yang memiliki keahlian (ya, kami memiliki orang semacam itu dan proyek semacam itu) untuk menyebarkan pengetahuan di antara yang lain.

Kami memiliki asumsi bahwa mobbing baik untuk tim harimau: tim yang dibentuk untuk menyelesaikan beberapa tugas mendesak. Tetapi ini bisa berhasil jika, paling tidak, tim berada di ruangan yang sama dan dengan lingkungan pengembangan dipersiapkan untuk mayoritas. Kalau tidak, akan ada kehilangan waktu karena faktor komunikasi yang tidak perlu.
Jika sebuah tim baru saja terbentuk, dan idealnya, sebuah proyek baru sedang dibentuk bersamanya, maka mobbing dapat bekerja dengan baik. Dalam hal ini, setiap peserta akan melihat bagaimana dan mengapa keputusan konseptual, arsitektur dan lainnya dibuat, akan ada ketidakseimbangan dalam pengetahuan tentang proyek.

Pada akhirnya, shift dibutuhkan lebih lama. Setidaknya 15-20 menit, bukannya 5 kami. Dan Anda perlu melakukan sesuatu dengan aturan bahwa seorang pengemudi hanyalah tangan seorang navigator, tanpa kepala sendiri.

Jadi, kami mencoba melakukan praktek dalam kondisi kerja tim kami. Beberapa aturan mengganggu kami, sesuatu yang kami salah pahami, di suatu tempat kami membuat kesalahan. Namun demikian, kami merasa pada diri sendiri apa itu, apakah itu mungkin dan apakah kami perlu bekerja dengan gaya ini. Menurut hasil percobaan ini, kami tidak sepenuhnya menerima nilai-nilai yang kami identifikasi untuk diri kami sebagai yang paling penting. Perlu dipertimbangkan bahwa kami hanya mencoba mobbing selama satu jam dengan shift yang terlalu pendek, karena hasil ini mungkin bukan yang paling dapat diandalkan. Ketika mengerjakan mobbing "penuh waktu", beberapa masalah tidak akan muncul, dan beberapa akan diatasi setelah "adaptasi" ke proses. Mungkin, kami tidak berhasil mendapatkan nilai yang kami butuhkan dalam waktu yang singkat. Untuk mengetahui hal ini dengan pasti, ada baiknya mencoba pertengkaran dalam situasi lain, tetapi ini akan menjadi cerita yang sama sekali berbeda.

PS
Anda dapat membaca dan melihat bahan-bahan berikut tentang topik ini:
GOTO 2017 - Pemrograman Mob: Pendekatan Seluruh Tim - Woody Zuill
Woody Zuill - Sehari Pemrograman Mob
Agilix Consulting Blog: Membunuh Antrian dan Mempercepat Tim dengan Mobbing