Rapat tim yang efektif


10

Saya seorang pemimpin tim dari tim 8 programmer di sebuah perusahaan yang terdiri dari sekitar 20 orang teknis. Mereka sedang mengerjakan berbagai proyek, proyek ini juga melibatkan orang-orang dari tim lain yang berada di luar kendali saya. Organisasi saya tidak melakukan pengembangan tangkas yang tepat, dan mereka agak resisten terhadap perubahan, tetapi saya telah mengadakan rapat harian di dalam tim saya dan kami semua menganggapnya berguna dan semua orang terlibat dan kami selesai dalam 10-15 menit. Saya juga mengadakan pertemuan individu setiap minggu dengan setiap anggota tim tempat kami membahas berbagai topik umum (baik teknis maupun non-teknis) secara lebih terperinci, serta berbagai pertemuan topikal ad-hoc.

Namun, yang saya perjuangkan adalah pertemuan tim mingguan saya. Kehilangan tenaga dan saya belum bisa membuat orang tertarik.

Saya masih ingin mengadakan pertemuan yang lebih lama, meskipun harus dua minggu atau sebulan sekali. Tujuannya adalah untuk membahas berbagai topik yang tidak dapat dilakukan selama pertemuan karena mereka membutuhkan lebih banyak waktu. Pembaruan dari saya termasuk ringkasan tentang setiap proyek saat ini yang sedang mereka kerjakan (apakah itu sesuai jadwal, berbagai penundaan, dll), setiap perubahan arah, proyek masa depan, perubahan pada proses pengembangan, dll. Namun, akhirnya menjadi ceramah dari saya, dan setidaknya 2 orang jelas dikategorikan dan sisanya paling tertarik.

Saya mencoba membuat orang lebih terlibat dengan membuat mereka berbicara tentang minggu mereka, tetapi dengan 8 orang itu membutuhkan waktu yang lama dan (sebagian karena banyak pekerjaan mereka tidak terlalu banyak), sebagian besar tim sisanya melakukan tidak peduli apa yang rekan kerja mereka telah kerjakan secara lebih detail (mereka mendapatkan gambaran tingkat tinggi selama stand up).

Jadi, selama pertemuan ini, setidaknya beberapa orang sangat bosan, dan hampir memalukan bagi saya untuk terus memegang ini. Ini sangat kontras dengan rapat pagi kami yang penuh semangat.

Adakah saran tentang apa yang bisa saya lakukan untuk membuat orang lebih terlibat dan lebih tertarik? Dan bagaimana saya bisa membuat mereka mempresentasikan sesuatu pada mereka atau memulai diskusi yang melibatkan semua orang alih-alih menjadi monolog dari saya?

Jawaban:


8

Anda mengatakan bahwa pertemuan itu terasa seperti Anda sedang menguliahi mereka. Jika terasa seperti itu bagi Anda, dan tim tampaknya tidak tertarik dengan apa yang Anda katakan, lalu mengapa masih ada rapat? Jika Anda hanya memberikan informasi kepada mereka, dan itu tidak menarik perhatian mereka, mengapa tidak meringkas semuanya dalam email mingguan saja?

Jika Anda ingin memanfaatkan waktu yang Anda miliki dengan seluruh tim, Anda mungkin ingin mempertimbangkan untuk menjalankan retrospektif. Anda dapat memperkenalkan retrospektif dengan kejujuran sederhana di pihak Anda: katakan kepada mereka bahwa Anda merasa pertemuan sebelumnya tidak produktif dan Anda ingin mencoba sesuatu yang berbeda untuk membantu semua orang mendapat manfaat dari jam yang mereka miliki bersama.

Dalam retros tempat saya bekerja, kita akan memiliki tiga kolom di papan tulis, biasanya menempatkan smiley, meh, dan wajah sedih di atas, misalnya :), :|, dan :(. Kemudian anggota tim dapat meletakkan apa pun di papan yang ingin mereka bicarakan dengan seluruh kelompok.

Di kolom bahagia, Anda dapat merayakan kesuksesan (seperti memberi selamat Alice dan Bob atas rilis proyek yang mereka kerjakan bersama), dan Anda dapat mendeklarasikan kemenangan dengan proses baru yang Anda coba (seperti pelacak bug baru jauh lebih baik daripada yang lama).

Di kolom meh, Anda meletakkan hal-hal yang tidak benar-benar bahagia atau sedih selama seminggu. Mungkin Anda membeli lisensi untuk versi baru IDE Anda, dan seseorang belum melihat keuntungan dari IDE baru - mereka dapat meletakkannya di papan untuk mengetahui apakah semua orang merasa bahwa upgrade itu tidak berharga atau jika orang lain memiliki menemukan cara yang sebenarnya lebih unggul dari versi sebelumnya.

Di kolom sedih, Anda meletakkan hal-hal yang tidak berjalan dengan baik selama seminggu. Mengidentifikasi poin rasa sakit untuk minggu ini mungkin merupakan manfaat terbesar dari retrospektif menurut saya. Seluruh tim mendiskusikan solusi untuk masalah nyata. Pada tim yang semuanya bekerja pada basis kode tunggal misalnya, seseorang mungkin mengatakan bahwa kelas FooBar tidak dapat dipertahankan dan telah menjadi penyebab berjam-jam debugging. Tiba-tiba Anda mengetahui bahwa semua orang di tim juga telah kehilangan beberapa jam minggu ini untuk FooBar, tetapi tidak ada yang menghabiskan waktu untuk membersihkannya. Dalam hal itu, tim mungkin secara kolektif memutuskan masuk akal bagi seseorang untuk meluangkan waktu merevisi kode itu minggu depan.

Setelah semua orang menulis topik yang diusulkan di papan tulis, saya ingin membahas secara singkat setiap topik dan meminta pengarangnya memberikan penjelasan 10-30 detik tentang topik tersebut. Bagian pertemuan ini mudah dielompokan, jadi Anda harus berhati-hati untuk menjaga orang-orang pada topik - misalnya seseorang akan mengatakan bahwa X telah menjadi masalah, dan orang lain mulai berbicara tentang solusi untuk masalah tersebut; solusi tidak boleh didiskusikan sampai setelah pemungutan suara. Dalam memperkenalkan topik, Anda dapat menemukan cara untuk mengelompokkan beberapa topik yang terkait erat.

Setelah perkenalan, semua orang mendapat tiga suara yang bisa mereka bagikan di antara topik-topik yang mereka sukai. Akhirnya, suara dihitung, dan topik apa pun yang memiliki jumlah suara terbesar adalah apa yang dibahas tim. Untuk setiap topik, tentukan apakah ada tindakan yang perlu diambil. Merayakan kesuksesan biasanya tidak memiliki item tindakan, tetapi refactoring kode tertentu dapat ditugaskan untuk satu orang. Item tindakan biasanya harus diselesaikan oleh satu orang, tetapi kadang-kadang item tindakan "seluruh tim" seperti menjadi sadar memiliki pesan komit yang baik.

Kebanyakan retro cenderung fokus pada topik di kolom sedih, dan hampir tidak ada retro yang membahas semua yang tertulis di papan tulis. Pertemuan cenderung selesai setiap kali waktu habis. Segera setelah pertemuan, lihat bahwa item tindakan ditugaskan untuk orang-orang tertentu; lakukan ini dengan cara apa pun yang masuk akal untuk organisasi Anda.

Saya telah sukses besar dengan retrospektif. Mereka adalah cara yang bagus untuk membangun kohesi dalam tim, dan mereka adalah cara yang bagus untuk merefleksikan minggu sebelumnya dan untuk menyempurnakan proses Anda. Saya pikir jika Anda mencoba ini dengan tim Anda, mereka akan jauh lebih terlibat untuk pertemuan Anda.


1
Ini saran yang menarik. Saya mencoba membuat orang "meringkas minggu Anda" satu per satu, tetapi itu tidak berhasil - semua orang akan mati atau bermain-main dengan telepon mereka sementara satu orang berbicara. Berfokus pada hal-hal positif, hal-hal negatif dan meh sebagai sebuah kelompok mungkin hanya bekerja lebih baik dalam membuat orang terlibat.
kay

Saran luar biasa - Saya sendiri berada dalam tim yang menderita karena desakan para Manajer kami pada pertemuan panjang jam mingguan (dan kami 25 ppl!)
Sandeep

4

Selamat datang di dunia manajemen menengah!

Anda akan menemukan masalah jenis ini terjadi BANYAK!

Anda memiliki 3 opsi:

Big Stick Lakukan ini atau Anda dipecat - tidak pernah berhasil. Jangan lakukan itu.

Kepemilikan Minta mereka untuk memfasilitasi pertemuan. Ambil satu langkah mundur dan pilih orang lain. Memiliki itu sebagai posisi berputar di mana orang yang berbeda menjadi tuan rumah setiap kali

Bicaralah yang tak terucapkan Dari apa yang Anda katakan, semua orang bosan - lalu mengapa tidak meminta mereka begitu? Apakah kamu bosan ? / Apakah ini buang-buang waktu, dll. Mengapa kita mendengar? Apa gunanya ini?

Tidak jelas dalam pertanyaan Anda mengapa Anda ingin melakukan ini. Jika Anda adalah satu-satunya yang merasa ini berharga, apakah Anda bersedia berubah? Tanyakan apa yang mereka inginkan. Mereka adalah orang-orang perangkat lunak, tugas mereka adalah menyelesaikan masalah sepanjang hari - selesaikan yang ini!


1
Saya kira saya sendiri tidak sepenuhnya yakin mengapa saya harus terus memegang ini. Gagasan awal saya adalah memberikan kesempatan kepada orang-orang untuk membahas topik secara lebih rinci dan juga memberikan pembaruan perusahaan. Ternyata sebagian besar adalah yang terakhir dengan sedikit diskusi. Saya akan meminta mereka untuk melihat apa yang mereka inginkan, tetapi ada kecenderungan dengan mereka untuk menghindari mengungkapkan pandangan tentang topik (non-teknis) tersebut.
kay

2

Coba beri nilai lebih kepada pengembang dalam rapat Anda. Beberapa contoh mungkin:

  • demo singkat menunjukkan fitur baru yang dikembangkan dalam sprint baru-baru ini. (disajikan oleh semua orang)
  • diskusi pembelajaran di mana mereka memiliki kesempatan untuk mengubah cara kerja tim dan meningkatkan (diskusi memimpin tangan kanan Anda dalam tim, dan Anda berada di sana untuk membenarkan keputusan manajemen Anda. mirip dengan sesi ventilasi 1 lawan satu) tapi lebih besar)
  • kuliah tentang proyek open-source baru yang bisa relevan atau bahasa pengkodean yang berbeda seperti Lang atau Golang fungsional atau utas hijau dalam python. (mungkin disajikan oleh salah satu pengembang yang lebih muda, atau dalam bentuk video online)
  • sebuah diskusi yang dipimpin oleh seorang insinyur penjualan yang menggambarkan masalah teknik yang sangat sulit yang berusaha diselesaikan oleh pelanggannya. (kesepakatan yang sama dengan manajer dukungan / layanan yang berusaha mengurangi biaya dukungan dengan meningkatkan kegunaan produk)
  • palungan yang mengungkapkan berbagai alternatif strategis yang bisa diambil perusahaan dan bagaimana hal itu akan memengaruhi teknik mengingat lanskap kompetitif.
  • penasihat eksternal yang memberikan sesi konsultasi tentang teknologi yang sudah Anda gunakan tetapi tidak secara maksimal (biasanya nosql, cep, RDBMS, jaringan, keamanan, pemantauan ...)
  • sebuah kode yang melintas di mana setiap orang dapat mempelajari pengkodean atau debugging baru atau menguji kiat produktivitas (oleh pengembang yang memiliki produktivitas 10x).
  • sesi pengkodean di mana tidak ada mouse diizinkan. Pelajari pintasan IDE.
  • berbicara dengan seorang akuntan tentang masalah keuangan terkait pensiun, investasi
  • berbicara tentang pemrograman sosial dan karier (pertukaran tumpukan, twitter, github, blog pribadi, LinkedIn, pertemuan di daerah Anda)

1

Dapatkah pertemuan atau mengadakannya jauh lebih jarang. Tulis kuliah Anda dalam email biasa dan kirimkan ke semua orang.

Hanya mengadakan pertemuan jika orang-orang di dalamnya benar-benar memiliki alasan untuk berpartisipasi di dalamnya. Jika tidak, Anda benar-benar membuang waktu orang.


Ini adalah rencana cadangan saya. Orang-orang yang peduli dengan pembaruan perusahaan, dll, dapat membaca email, dan orang-orang yang tidak dapat mengabaikannya. Jika ada topik yang lebih spesifik untuk didiskusikan, saya bisa memanggil rapat untuk membahasnya ketika topik itu muncul.
kay 11'13

1

Jangan mengadakan rapat panjang dan memanfaatkan perangkat lunak pengelolaan proyek. Jika Anda ingin membuat orang tertarik, maka padatkan dan sorot yang penting dan simpan sisanya untuk log dan laporan proyek. Berkonsentrasilah pada tonggak sejarah, pengiriman, sorotan dan tujuan, dan jika hanya berlaku untuk 1/3 orang, simpanlah untuk utas diskusi proyek.

  • Buat rapat Anda singkat
  • Leverage Proyek Mengelola Perangkat Lunak
  • Tetap pribadi, bertujuan dan terhubung dengan emosi dan tujuan
  • Pecahkan masalah dalam grup fokus, bukan di forum
  • Dapatkan umpan balik dari rekan-rekan Anda

Juga, jangan biarkan orang lain masuk ke percakapan dan lanjutkan pekerjaan mereka kecuali mereka telah menetapkan poin yang ingin mereka atasi. Jika Anda ingin umpan balik, bersiaplah untuk itu, atau simpan untuk komentar di suatu tempat daring di mana orang punya waktu untuk mengatasinya. Ini adalah salah satu masalah paling menjengkelkan dalam rapat; memberikan waktu ke lantai untuk teman sebaya karena rasa hormat. Simpan barang-barang itu di akhir setelah Anda menyelesaikan semua hal yang perlu Anda sampaikan.

Arahkan pendekatan manajemen proyek Anda, dan dorong praktik pengembangan yang baik dengan memimpin melalui contoh.

Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.