Siapa yang akan mendapat manfaat dari artikel ini?
Artikel ini akan bermanfaat bagi para pemimpin dan anggota tim proyek kecil yang terdiri dari 5-10-15 orang.
Apa yang harus digunakan dan mengapa?
Kami secara pribadi menggunakan Slack untuk berkomunikasi dan berbagi informasi.
Sebagian besar dari apa yang tertulis di bawah, dengan satu atau lain cara, dapat diatur di messenger lain.
Alasan kami menggunakan Slack:
- Kenyamanan dalam mengatur obrolan grup (saluran)
- Kehadiran utas - kemampuan untuk membuat cabang dialog
- Perbedaan antara dialog yang berfungsi dan yang tidak berfungsi. Bekerja di Slack. Lainnya - di telegram / watsap / di mana saja
- Ketersediaan reaksi
- Ketersediaan pengingat
- Kemampuan untuk mengintegrasikan Slack dengan banyak alat
Jika ada alternatif Slack yang semua 6 poin di atas valid, beri tahu saya di komentar. Dan untuk alternatif semacam itu, beri tahu saya fitur keren apa yang dimilikinya dan sering digunakan di tim Anda.
Apa aturan komunikasi dalam tim dan mengapa?
1. Jangan berkomunikasi di PM
Kami meninggalkan komunikasi di PM hanya untuk dua kasus:
- Mendiskusikan sesuatu yang membutuhkan privasi.
- Memasiks / guyonan banjir dan lainnya.
Untuk yang lainnya, kami menggunakan saluran komunikasi umum.
Sekarang saya akan memberi tahu Anda untuk apa itu. Saya akan memberitahu Anda nanti bagaimana mengatur saluran komunikasi umum sedemikian rupa sehingga tidak ada kekacauan dan kekacauan.
Mengapa aturan ini dibutuhkan?
Aturan ini diperlukan untuk:
- Ada kemungkinan untuk menangkap situasi ketika seseorang menyimpang dari jalur dan mulai melakukan sesuatu yang salah.
- Itu mungkin untuk menangkap situasi ketika seseorang mulai melakukan sesuatu yang salah.
- Tidak ada situasi ketika dua orang menyetujui sesuatu, dan orang lain menderita karenanya.
- Manajer dapat memantau koordinasi kerja tim.
- Manajer dapat melacak terjadinya konflik, kekesalan, dan terjadinya hal-hal negatif lainnya.
2. Tandai orang-orang yang menerima seruan
Setiap pesan harus memiliki penerima. Satu atau lebih.
Saat merujuk pada seseorang, Anda harus menandainya.
Saat berbicara dengan banyak orang, tandai semua orang, bukan semua orang di saluran.
Mengapa aturan ini dibutuhkan?
Aturan ini diperlukan untuk:
- Tidak semua peserta obrolan terganggu oleh pesan dalam obrolan / utas grup, tetapi hanya mereka yang diberi tag.
- Kemungkinan penerima akan memunculkan notifikasi adalah maksimum. Misalnya, di Slack, notifikasi terkadang hilang.
3. Bereaksi terhadap pesan
Setiap pesan yang dikirim oleh seseorang (tidak secara otomatis) tidak boleh diabaikan oleh penerima pesan ini. Penerima pesan , saat menerima pesan, harus memberikan tanggapan. Jika ada beberapa penerima, setiap orang harus bereaksi.
Agar tidak menulis frasa "ok", "dipahami", dll., Slack memiliki fitur yang nyaman - reaksi. Anggota tim kami biasanya memberikan reaksi: mata:. Pemimpin menggunakan reaksi: mata:.
Mengapa aturan ini dibutuhkan?
Aturan ini diperlukan agar pengirim mengetahui bahwa pesannya "tidak hilang".
4. Gunakan utas
Slack memiliki fitur seperti utas - kemampuan untuk membuat "utas percakapan" dan melakukan percakapan di dalamnya, dan bukan di alur pesan utama.
Fitur ini sangat cocok untuk membahas satu masalah.
Mengapa aturan ini dibutuhkan?
Aturan ini diperlukan agar tidak membuat arus utama pesan berantakan, sehingga meningkatkan struktur informasi dan kemudahan navigasi melaluinya.
5. Catat percakapan yang terjadi di luar Slack
Jika beberapa dialog terjadi, katakanlah, dalam panggilan tersebut, maka perlu untuk memasukkan protokol berdasarkan hasil panggilan - serangkaian tesis yang mencerminkan hasil percakapan.
Mengapa aturan ini dibutuhkan?
Aturan ini diperlukan untuk:
- Pastikan sekali lagi bahwa peserta dialog saling memahami dengan benar
- Kami tidak melupakan apa yang kami sepakati
- Menyadari apa yang terjadi yang tidak menerima dialog, tetapi tertarik dengan topik dialog.
- Itu mungkin untuk merujuk pada hasil percakapan
- ... dan argumen yang sama dari paragraf pertama tentang saluran komunikasi umum
Protokol harus memiliki penerima dan menerima tanggapan!
Tidak semua orang harus ditempatkan sebagai penerima, tetapi mereka yang menjadi perhatian topik dialog ini.
6. Memulai panggilan / rapat jika masalah tidak terpecahkan dalam 15 menit korespondensi aktif
Semuanya sederhana di sini: jika Anda melihat bahwa Anda harus menulis banyak teks, jika obrolan dimulai dari kekacauan, Anda perlu menelepon dan mendiskusikan semuanya dengan suara.
Dan sebagai hasil dari panggilan - kirim protokol ke semua orang.
7. Lakukan pertemuan harian secara tertulis
Pertemuan harian adalah pertemuan kelompok di mana setiap anggota tim harus menjawab beberapa pertanyaan penting dan mendiskusikan isu / masalah terkini untuk menyinkronkan tim. Contoh serangkaian pertanyaan untuk rapat harian:
- Apa yang kamu lakukan kemarin?
- Apa yang akan saya lakukan hari ini?
- Masalah apa yang saya hadapi dalam perjalanan saya?
Kami mengadakan pertemuan harian dari pukul 11:30 hingga 11:35 dalam obrolan grup khusus. Manajer menulis terakhir - pada 11:36. Siapapun yang berhenti berlangganan setelah itu dianggap terlambat. Pekerjaan pendidikan harus dilakukan dengan yang terlambat. Setiap orang harus di bawah pesan masing-masing membubuhkan reaksi: mata:. Reaksi ini adalah konfirmasi bahwa setiap orang telah membaca setiap pesan harian.
Template pesan harian kami:
- Apa yang telah kulakukan?
1. Metode API / halo
2. Metode API / howareyou - Apa yang akan saya lakukan?
1. Metode API / bye - Pertanyaan:
1. Alice, menurut Anda berapa lama tugas Anda akan berlangsung? - Masalah:
1. Penerapan gagal. Tolong!
Saat membahas soal / soal, jangan lupakan aturan nomor 6 - jika soal / soal tidak terselesaikan dalam 15, kami taruh di hitungan.
Untuk sebagian besar, harian kita membutuhkan waktu 15 menit dari waktu semua orang, dengan mempertimbangkan waktu untuk mempersiapkan reli.
Mengapa aturan ini dibutuhkan?
Aturan ini diperlukan untuk menggunakan waktu kerja tim secara efisien. Dan kesabaran.
Betapapun indahnya dunia Scrum kita mencoba membuat, dalam praktik, setiap hari, selama pidato salah satu anggota tim, tidak seluruh tim yang tersisa mendengarkannya, tetapi 1-2 orang. Sisanya tinggal menunggu giliran. Biasanya, untuk tim yang terdiri dari 10 orang, harian seperti itu berlangsung dari setengah jam hingga satu jam, yang berarti bahwa sebagian besar tim hanya duduk dan kue untuk sebagian besar waktu itu. Menerjemahkan ke dalam format teks membuat harian cepat, ringkas dan, yang terpenting, tetap.
8. Bonus: Dalam tim inhouse, diskusikan dalam format teks segala sesuatu yang berhubungan dengan produk dan proses pembuatannya
Pengalaman pribadi saya adalah hidup menjadi lebih baik ketika Anda berdiskusi secara tertulis:
- tuntutan
- rancangan
- realisasi
- proses kerja
- saran dan masalah
Dalam praktiknya, ini tidak selalu 100% memungkinkan.
Kemudian, jika sesuatu dari daftar di atas dibahas secara langsung, hasil pembahasan harus dicatat.
Mengapa ini dibutuhkan?
Untuk memecahkan masalah berikut dalam tim inhouse:
- Selalu: para pemimpin berpikir bahwa mereka “sudah siap”, tetapi pada kenyataannya mereka secara praktis tidak melihat bagaimana kinerja tim. Segala sesuatu yang dapat ditangkap saat berkomunikasi dalam obrolan grup praktis tidak dapat diakses dalam format langsung
- Seringkali: keputusan dibuat di ruang merokok, yang kemudian tidak disiarkan ke semua pihak yang berkepentingan
- Terkadang: pembahasan masalah pekerjaan dibarengi dengan percakapan "tidak ada" dalam jumlah besar
Bagaimana cara mengatur messenger?
Agar saluran dapat dipesan dengan nyaman, kami menggunakan sistem prefiks.
Karena tim kami terlibat dalam berbagai proyek, kami membuat awalan untuk setiap proyek dan menggunakannya dalam nama saluran.
Misalnya, kami memiliki 2 proyek - GoldFixing dan Aurrency. Untuk proyek ini kami menggunakan awalan berikut: gf untuk GoldFixing dan aurm untuk Aurrency. Kemudian semua saluran yang terkait dengan GoldFixing akan dimulai dengan awalan gf_ dan terlihat seperti gf_somechannel. Demikian pula dengan Aurrency - saluran akan terlihat seperti aurm_somechannel.
Pada saat yang sama, ada juga banyak saluran dalam proyek tersebut. Untuk mengaturnya, kami membuat kategorisasi saluran sesuai dengan tujuannya. Dan untuk setiap kategori, mereka mendapat prefiksnya masing-masing.
Saluran dapat dibagi menjadi 4 kategori:
1. Belanjaan
Ini adalah saluran yang didedikasikan untuk produk yang dibuat dalam proyek.
Awalan: prdct_
Saluran dalam kategori ini membahas semua masalah yang dalam satu atau lain cara berhubungan dengan produk ini atau itu.
Jadi, jika dalam kerangka proyek GoldFixing, dua produk dibuat - platform dan back office, maka untuk mereka kami membuat saluran berikut:
- gf_prdct_platform
- gf_prdct_backoffice
2. Informasi
Saluran dalam kategori ini tidak dimaksudkan untuk komunikasi, tetapi untuk penyebaran informasi.
Awalan: info_
Semua jenis pemberitahuan dan pesan untuk tujuan organisasi masuk ke saluran kategori ini. Misalnya, pemberitahuan dari pengelola tugas datang tepat di sini.
Jadi, jika kita menggunakan JIRA dalam proyek GoldFixing, maka kita akan memiliki saluran gf_info_jira.
3. Tim
Ini adalah saluran yang didedikasikan untuk tim berdasarkan profesi mereka.
Awalan: tim_
Dalam saluran dalam kategori ini, topik dibahas yang terkait dengan beberapa disiplin profesional (frontend / backend / dll) dan tidak terkait dengan disiplin ilmu lain.
Misalnya, jika ada beberapa pengembang frontend dalam proyek GoldFixing, maka kita akan memiliki saluran gf_team_frontend.
Jika orang yang sama terlibat dalam beberapa proyek, maka Anda dapat menghilangkan awalan proyek dan cukup memberi nama saluran - team_frontend.
4. Sementara
Ini adalah saluran di mana Anda ingin mendiskusikan sesuatu yang Anda tidak ingin memuat orang yang tidak terkait.
Prefix: tmp_
Misal, jika dalam project GoldFixing perlu membahas pembelian cup dengan logo project, maka kita buat channel gf_tmp_brand-cups.
Jika Anda perlu mendiskusikan sesuatu yang tidak terkait dengan proyek tertentu, maka kami menghilangkan awalan proyek.
Pengaturan dasar saluran informasi
Terlepas dari kenyataan bahwa penyiapan ini dibuat untuk tim TI, saya pikir ada sesuatu yang dapat dipinjam oleh tim non-TI.
- gf_info_general - untuk segala sesuatu yang berhubungan dengan bagian organisasi: deklarasi, memperbaiki perjanjian dan proses. Biasanya ditujukan kepada semua orang dan membutuhkan tanggapan dari semua orang.
- gf_info_daily - di sini setiap orang berhenti berlangganan pesan harian mereka
- gf_info_changelog — , //wireframes/api , - - , Change Report , , ,
- gf_info_jira — JIRA
- gf_info_confluence — Confluence
- gf_info_deploy — . :
— Instance — Repository —
— Branch —
— Pipeline — gitlab
— Job — gitlab
— Triggered by — Slack ,
— Commit — - gf_info_sentry — Sentry
- team_backend — backend
- team_dlt — DLT
- team_frontend — frontend
- team_qa — QA
Advanced JIRA
Jika Anda menuangkan notifikasi tentang segala hal yang terjadi di JIRA ke dalam satu channel, channel tersebut akan berubah menjadi pesan yang berantakan.
Untuk melakukan ini, kami menyesuaikan notifikasi dan membuat tidak hanya satu, tetapi beberapa saluran untuk JIRA:
- gf_info_jira_comments - untuk pemberitahuan komentar di JIRA
- gf_info_jira_qa - untuk notifikasi QA tentang tampilan tugas yang siap untuk diuji. Saluran ini hanya memiliki QA dan pengelola
- gf_info_jira_qa_verdict - untuk notifikasi tentang transfer tiket dari status "TEST" menjadi "DONE" atau "REWORK"
Pemberitahuan pengaturan lanjutan dari Sentry
Pada setiap proyek kami memiliki beberapa contoh (berdiri) proyek:
- Dev stand - singkatan dari developer
- Dudukan uji - dudukan untuk penguji
- Stand rilis - stand untuk mencalonkan kandidat rilis
- Stand produksi - stand produksi
Untuk masing-masing, kami membuat saluran penjaga terpisah.
Dan agar frontend developer tidak berkedut saat terjadi error pada backend, begitu pula sebaliknya, mereka juga membagi channel tersebut menjadi grup frontend / backend.
Ternyata:
- gf_info_sentry_back_dev
- gf_info_sentry_back_test
- gf_info_sentry_back_release
- gf_info_sentry_back_prod
- gf_info_sentry_front_dev
- gf_info_sentry_front_test
- gf_info_sentry_front_release
- gf_info_sentry_front_prod
Dengan demikian, bagian depan tidak bergerak-gerak karena kesalahan di bagian belakang, begitu pula sebaliknya.
Untuk pendirian yang berbeda, urgensi berbeda dari tanggapan pengembang dapat diterima.
Karena fakta bahwa instance produksi proyek terletak di satu cluster, dan semua instance lainnya di cluster lain, kami berpikir tentang cara mengelompokkan saluran ke dalam cluster dan mendapatkan:
- gf_info_sentry_back_dev-cluster
- gf_info_sentry_back_prod-cluster
- gf_info_sentry_front_dev-cluster
- gf_info_sentry_front_prod-cluster
Contoh organisasi saluran
Pertanyaan untuk audiens
- Aturan komunikasi apa yang akan Anda tambahkan ke yang telah saya daftarkan?
- Hal berguna apa lagi yang dapat Anda konfigurasikan / gunakan di messenger pada level seluruh tim?