Hari ini kami melanjutkan pengenalan kami dengan buku " Team Geek: The Ideal IT Company " oleh Brian Fitzpatrick dan Ben Collins-Sussman, yang didedikasikan untuk komunikasi "di tempat kerja" dalam segala bentuknya. Terakhir kali kami memulai dengan komunikasi intra-tim dan berbicara terutama tentang bagaimana pola pikir masing-masing karyawan memengaruhi mereka. Kali ini kita harus melihat tim secara lebih luas - sebagai kelompok yang bersatu dengan budaya internalnya sendiri, yang entah bagaimana dibentuk dan dibutuhkan untuk sesuatu.
Budaya tim adalah seperangkat pengetahuan, nilai, dan tujuan khusus untuk kelompok programmer tertentu. Ini termasuk metode pembuatan kode program, dan gaya komunikasi antara orang-orang, dan cara mengatur alur kerja - ada banyak komponen. Beberapa dari mereka tidak terlalu kritis, mereka datang dan pergi dengan mudah (misalnya, kebiasaan memesan pizza dan bermain permainan papan pada hari Jumat), yang lain membentuk "tulang punggung" budaya dan dapat bertahan dari seluruh generasi programmer (misalnya, prosedur untuk proses inspeksi kode, pengujian, dokumentasi, dll. Selanjutnya).
Dalam bentuk aslinya, budaya biasanya ditetapkan oleh para pendiri dan tim teknis asli. Selanjutnya, itu pasti berkembang dan mengalami perubahan, tetapi untuk tim yang kuat dan terbukti (Google, Apple, Microsoft, Oracle dapat dikutip sebagai contoh) paling sering mempertahankan wajah aslinya sampai batas tertentu - koneksi dengan akar tidak sepenuhnya hilang.
Berlawanan dengan kesalahpahaman populer, budaya tim tidak sepenuhnya ada di tangan dan hati nurani pemimpin. Kalau benar-benar ada (tentang apa jadinya kalau benar-benar tidak ada budaya, nanti kita bicarakan sedikit lagi), itu disiarkan oleh hampir semua karyawan. Ini menjadi jelas ketika Anda melihat bagaimana tim pemula biasanya berintegrasi. Pengembang baru mendapat gambaran tentang bagaimana hal itu diterima di sini, apa yang penting dan apa yang tidak penting melalui interaksi dengan rekan kerja: apa yang diperhatikan dalam kodenya, bagaimana dan dengan nada apa mereka menjelaskan perlunya perbaikan, bagaimana konflik terjadi terselesaikan.
Budaya tim mandiri: metafora toko roti
Mengapa bekerja pada budaya tim?
Jadi, budaya tim adalah semacam campuran yang tersebar dari berbagai sikap dan kesepakatan yang memungkinkan orang-orang yang bekerja sama untuk tetap berada di gelombang yang sama. Sebuah pertanyaan wajar muncul: Apakah perlu mengkhawatirkan hal ini? Saling mempengaruhi karyawan satu sama lain dalam proses kerja terjadi secara alami, sehingga budaya apapun cenderung terbentuk dengan sendirinya.
Masalahnya di sini adalah, seperti halnya semua proses spontan, budaya yang berkembang secara spontan akan menghasilkan lebih banyak entropi dan dapat menghasilkan hasil yang tidak dapat diprediksi. Dengan kata lain, cepat atau lambat akan ada orang yang akan memutuskan dengan tangannya sendiri untuk menentukan "seperti yang biasa di sini". Jika mereka berubah menjadi waras dan bertindak ke arah yang sama, akhirnya akan bahagia. Tetapi lebih sering daripada tidak, itu berubah menjadi perang kantor lama yang sama atau, bahkan lebih buruk, kantong pembusukan di dalam tim.
Jadi melepaskan sesuatu bukanlah pilihan terbaik. Di atas, kita berbicara tentang fakta bahwa budaya tidak dapat ditanamkan secara paksa, tetapi Anda dapat mendekati pembentukannya dengan kesadaran. Jika masing-masing peserta tidak hanya berperilaku sesuai dengan prinsip-prinsip dari bab terakhir, tetapi juga mencoba membawanya ke level tim, menekan tindakan yang berbahaya untuk kerja sama, dan tidak takut menegosiasikan aturan umum untuk semua orang, risikonya kejutan yang tidak menyenangkan berkurang.
Apa yang seharusnya menjadi budaya tim?
Tentu saja tidak mungkin menjawab pertanyaan ini dengan tegas dan lengkap. Tanaman sangat beragam, dan kisaran variasi yang sehat dan produktif sangat luas. Pekerjaan yang terorganisir dengan baik dan nyaman dapat terjadi dalam start-up yang kacau, di mana semua orang ada di dewan, dan di perusahaan besar dengan proses yang jelas dan menjaga jarak. Mencoba menetapkan patokan untuk masing-masing dari banyak elemen itu sia-sia.
Dalam istilah yang paling umum, budaya harus:
- . . , , . , : .
- . , , , , . . , , – .
- . , , , : , , . , – , .
- . , , . , . , .
Saluran komunikasi adalah komponen budaya yang paling mudah dikendalikan, dan penulis sangat memperhatikannya. Namun, sebelum membahas detailnya, mereka memberikan beberapa tip tentang elemen lain yang lebih halus.
Ketika sampai pada cara membuat keputusan, maka sebagian besar programmer lebih menyukai model demokratis. Mungkin ini karena keinginan terkenal mereka untuk kemerdekaan, atau mungkin faktanya adalah bahwa profesinya secara inheren kreatif, tetapi faktanya tetap: penting bagi pengembang untuk memiliki suara dan kemampuan untuk berbagi pemikiran mereka sendiri. Para pemimpin harus mempertimbangkan hal ini saat mengatur proses pengambilan keputusan. Tidak perlu menyelesaikan semua masalah dengan pemungutan suara umum, cukup bahwa karyawan benar-benar didengarkan dan sistem mengandaikan cukup konsensus bagi mereka untuk merasakan kepemilikan mereka.
Adapun cara berkomunikasi, dia harus lebih menekankan kesopanan daripada keagresifan. Masalah dengan tim yang menggunakan teriakan atau nada tegas untuk menegaskan diri mereka adalah bahwa mereka mendorong dan membanjiri orang dengan pikiran yang lebih tenang. Seseorang yang rentan konflik akan merasa cukup nyaman baik di lingkungan yang agresif maupun di antara orang-orang yang sopan. Orang yang tenang dan pendiam (di antara banyak programmer), sebaliknya, tidak akan bisa membuka diri dengan baik dalam tim yang agresif. Karenanya, dengan mendorong atau hanya mengadopsi cara komunikasi yang ofensif, kami secara otomatis memutuskan beberapa karyawan potensial yang kuat. Ini tidak praktis.
Pada saat yang sama, harus dipahami bahwa budaya benar dan saling menghormati lebih rapuh dan rentan terhadap pengaruh eksternal. Seorang pemula yang tegas sudah cukup untuk mengguncang harmoni. Oleh karena itu, sangat penting untuk mengakhiri setiap upaya yang bertentangan dengan cara komunikasi yang diterima dan mencegah orang memenangkan kemenangan melalui perilaku yang merusak. Cara terbaik untuk melakukannya adalah dengan menolak berkomunikasi dengan nada agresif.
Saluran komunikasi
Kami telah menemukan bahwa fiksasi dan transmisi informasi memainkan peran yang menentukan dalam budaya tim. Dalam kondisi modern, banyak alat tersedia bagi kita untuk tujuan ini; bagian ini hanya memberikan gambaran umum yang paling umum.
Ciri umum dari tim yang sukses adalah bahwa mereka secara aktif menggunakan berbagai saluran komunikasi untuk memastikan bahwa setiap orang tetap mengetahui arah umum pergerakan dan kemajuan pekerjaan saat ini. Pada saat yang sama, penekanannya ada pada saluran yang, pertama, membuat informasi tersedia untuk umum, dan kedua, memanfaatkan kemungkinan komunikasi asinkron.
Lebih lanjut, penulis mempertimbangkan sejumlah alat khusus yang digunakan untuk komunikasi dalam tim teknis; mengklarifikasi tujuan dan aturan penggunaan mereka.
Definisi misi
Dari judul seperti itu, pembaca-programmer mungkin akan membuat tanda silang, tetapi pada kenyataannya, semuanya tidak begitu menakutkan. Dalam pekerjaan teknis, misi dirumuskan pada tingkat proyek individu dan bertujuan bukan untuk memuji perusahaan dalam ekspresi hiasan yang samar-samar, tetapi untuk dengan jelas menunjukkan apa yang sedang dilakukan dan apa yang tidak dilakukan. Dengan kata lain, pernyataan misi adalah definisi singkat dari arah pengembangan produk dan membatasi ruang lingkupnya.
Katakanlah demikian:
Misi GWT adalah meningkatkan pengalaman pengguna World Wide Web secara radikal dengan memungkinkan pengembang memanfaatkan alat Java yang ada untuk membuat aplikasi AJAX untuk browser modern apa pun.
Sebagai orang yang secara aktif terlibat dalam proyek open source, Fitzpatrick dan Sussman dapat melihat dari pengalaman mereka sendiri berapa banyak waktu, energi dan saraf yang dapat dihemat oleh tindakan seperti itu untuk tim dalam jangka panjang. Ketika anggota baru terus-menerus bergabung dalam pekerjaan, masing-masing dengan ambisi, komentar, dan ide cemerlang mereka sendiri, "inti" kelompok harus memiliki pemahaman yang jelas dan seragam tentang esensi proyek. Jika tidak, karya akan berjalan sesuai dengan skenario dongeng tentang angsa, kanker, dan tombak, atau akan terus-menerus mengalami trombus karena upaya untuk mengklarifikasi masalah ini di sepanjang jalan.
Oleh karena itu, pernyataan misi berguna dalam dua hal. Pertama, jika ada ketidaksepakatan di antara para pemangku kepentingan utama tentang tujuan dan ruang lingkup proyek, ini akan segera muncul dan diselesaikan tanpa penundaan. Kedua, hasil diskusi akan menjadi sebuah dokumen dengan tesis utama, yang akan memungkinkan untuk merujuk pendatang baru yang membosankan atau terlalu bersemangat.
Pernyataan misi memberi tim pijakan dalam setiap keputusan terkait proyek, tetapi tidak boleh dianggap benar-benar tidak dapat diganggu gugat. Kadang-kadang terjadi (terutama di startup) bahwa tujuan atau keadaan kerja berubah secara radikal. Dalam situasi darurat, masuk akal untuk menilai dengan jujur apakah misi awal masih relevan dan mengubahnya sesuai kebutuhan.
Dokumentasi proyek
Jika misi dirancang untuk mengembangkan satu jawaban bagi semua peserta proyek untuk pertanyaan "apa", maka dokumentasi proyek menyiratkan pekerjaan serupa pada pertanyaan "bagaimana".
Dokumen proyek menyajikan sketsa proyek masa depan yang lebih rinci dan isian teknisnya. Biasanya, terdapat satu pemilik, dua atau tiga penulis, dan cukup banyak pengulas yang memberikan komentar mereka. Menulis dokumentasi, tidak peduli betapa sulitnya mempersiapkannya, harus mendahului pekerjaan pada kode - momen ketika tidak ada satu baris pun yang ditulis paling cocok untuk mendengarkan kritik dan menyesuaikan rencana implementasi. Dokumen proyek yang sudah selesai sangat nyaman digunakan saat menyusun peta jalan, menyoroti tahapan pekerjaan, dan sebagainya.
Dokumentasi desain pada dasarnya jauh lebih fleksibel daripada pernyataan misi; ini bukan dogma, tetapi substansi yang hidup. Selama proses pengembangan, beberapa detail perlu direvisi, dan idealnya, dokumentasi harus mencerminkan semua perubahan ini secara real time sehingga tim dapat terus mengikuti. Pada kenyataannya, sayangnya, itu sering diedit setelah rilis produk.
Rapat
Banyak orang akan berpikir bahwa akan menyenangkan membuat tanda salib di sini juga - rapat memiliki reputasi yang agak buruk di antara pengembang. Menurut penulis, alasannya adalah karena mereka tidak terorganisir dengan baik dan sering digunakan di tempat yang lebih masuk akal untuk beralih ke saluran komunikasi asynchronous.
Contoh bagus dari pemilihan format yang gagal adalah “pertemuan”, yang diadakan dengan keteraturan tertentu (biasanya seminggu sekali) dan banyak orang. Biasanya pengumuman penting dibacakan di sana, hasil umum dirangkum, dan seterusnya. Padahal, seluruh isi brosur sangat mudah dan produktif untuk diterjemahkan ke dalam milis elektronik, kecuali untuk kasus-kasus yang justru membutuhkan diskusi kolektif yang luas.
Untuk rapat, yang benar-benar tidak dapat Anda lakukan tanpanya, aturan berikut harus selalu diingat saat menyelenggarakannya:
- . – , , , . « » — . , - .
- , , . , . , , .
- . – .
- (, ). , – Google .
Mailing
List Email adalah alat yang sangat berguna untuk mendokumentasikan riwayat proyek di latar belakang. Jauh lebih mudah untuk mengekstrak informasi darinya daripada dari pengirim pesan instan, di mana lalu lintas lebih banyak dan regulasi jauh lebih sedikit. Oleh karena itu, disarankan untuk mengirimkan semua informasi penting di milis, di mana pun kedengarannya sebelumnya: salinan rencana dan catatan rapat, hasil diskusi tentang masalah tertentu, dokumen proyek, analisis kesalahan. Dengan demikian, gudang data terpusat dibentuk, di mana pada tahap apa pun dimungkinkan untuk kembali tidak hanya untuk menemukan informasi tertentu, tetapi juga untuk melacak asal-usul keputusan dan jalannya diskusi. Tentu saja, arsip harus dilengkapi dengan pencarian terindeks.
Pentingnya dokumentasi dan, karenanya, pengiriman surat ditentukan oleh seberapa kompak tim ditempatkan di ruang angkasa. Jika beberapa karyawan bekerja dari jarak jauh atau muncul di kantor secara tidak teratur, praktik berkelanjutan untuk menggandakan berita proyek besar melalui surat menjadi kebutuhan yang mendesak. Jika tidak, sebagian besar informasi yang "sedang disiarkan" (diskusi di koridor dan meja dekat, transmisi lisan informasi baru kepada mereka yang tidak hadir dalam rapat) akan melewati mereka.
Jika tim besar dan prosesnya bergejolak, peserta akan segera tenggelam dalam arus pengumuman yang heterogen. Dalam situasi ini, dokumentasi dibagi menjadi beberapa pesan tematik (pengembangan, analisis kode program, dukungan pengguna, pengujian, dan sebagainya), yang mencakup karyawan yang tertarik. Namun, lebih baik memulai dengan satu aliran - jika ada kebutuhan untuk pemisahan, mereka akan segera menyampaikannya kepada Anda.
Pembawa pesan online Pembawa pesan
berdiri di suatu tempat di tengah-tengah antara komunikasi sinkron dan asinkron. Mereka tidak optimal untuk dokumentasi, tetapi sangat diperlukan untuk menyelesaikan masalah dengan cepat, terutama dalam tim terdistribusi. Dari sudut pandang budaya komando, dua aspek penting di sini.
Pertama, garis pemisah antara diskusi pribadi dan publik. Sebagian besar pengirim pesan internal dan komersial memberi pengguna kesempatan untuk memilih antara berkomunikasi dengan orang tertentu atau sekelompok orang, dan ini sangat nyaman. Namun, menurut Fitzpatrick dan Sussman, akhir-akhir ini terdapat kecenderungan isolasi - diskusi semakin banyak dilakukan secara tertutup.
Dalam beberapa hal, ini tidak buruk - masalah pribadi pasti tidak akan "menyumbat udara" bagi semua karyawan. Namun di sisi lain, orang kehilangan kesempatan untuk mengikuti jalannya diskusi, menyisipkan komentar mereka, dan segera mengetahui perubahannya. Para pemula juga kehilangan banyak hal, karena mereka dapat memperoleh banyak informasi berharga hanya dengan membaca diskusi aktif dalam obrolan umum secara diam-diam. Seringkali, diskusi menjadi tertutup, bukan karena terlalu ceruk, tetapi semua karena ketakutan yang sama akan kerentanan: Anda tidak ingin mengajukan pertanyaan atau memberi saran di depan semua orang - bagaimana jika mereka ternyata bodoh? Pengembang harus menangkap motivasi seperti itu dan mencoba untuk tidak menyembunyikan apa yang lebih bijaksana untuk tetap berada di domain publik.
Kedua, Anda perlu mengingat bahwa pesan instan, terlepas dari semua reaksi instan, bukanlah pengganti yang lengkap untuk komunikasi langsung. Mereka tidak memiliki intonasi dan ekspresi wajah yang dapat melembutkan atau memperjelas beberapa frasa. Hal ini meningkatkan risiko kesalahpahaman yang mengancam prinsip kesopanan, rasa hormat, dan kepercayaan, dan ini harus selalu diingat.
Bug Tracking System
Alat ini tidak umum seperti yang disebutkan di atas. Ini bisa sangat bermanfaat dalam kondisi tertentu:
- Ketersediaan prosedur untuk memproses dan menyortir kesalahan, yang memastikan pendaftaran dan koreksi tepat waktu. Jika proses debug sistem tidak diberi perhatian yang cukup, orang-orang tidak akan menggunakannya, atau mereka akan menyalahgunakannya dengan cara-cara kecil.
- . « » , .
- . – .
- . , , .
Komunikasi sebagai bagian dari pengembangan
Komunikasi dalam tim teknis tidak hanya terjadi di sekitar, tetapi juga langsung di dalam kode. Saluran utama di sini tentu saja adalah komentar pengembang .
Penulis secara singkat menyentuh aturan dasar berkomentar kode, yang mungkin akrab bagi semua orang: jelaskan bukan apa yang dilakukan, tetapi mengapa itu dilakukan, cobalah untuk berkomentar pada tingkat fungsi dan metode, singkat saja dan tidak berlebihan pergi dengan detail. Gaya komentar lainnya adalah hal yang subjektif, setiap tim mengembangkannya sendiri-sendiri tergantung pada kebutuhan dan suasana umum. Hal utama adalah bahwa gaya umum ini pada prinsipnya harus ada; fakta keseragaman dalam kasus ini lebih penting daripada karakteristik khusus.
Cara komunikasi lain di dalam kode adalah atribusi , yaitu tanda tangan pengembang di dalam file. Kebiasaan meninggalkan nama Anda pada dokumen sudah ada sejak zaman kuno; di program lama, Anda sering melihat tanda tangan seperti itu:
Fitzpatrick dan Sussman bersikeras bahwa sekarang tanda tangan ini harus dianggap anakronistik. Dari sudut pandang psikologis, keinginan untuk menunjukkan kepenulisan, tentu saja, tetap alami dan dapat dimengerti: ini adalah perwujudan kebanggaan dan rasa tanggung jawab atas pekerjaan yang telah dilakukan. Namun, pada sisi praktisnya, hal ini menimbulkan lebih banyak masalah daripada manfaat. Sekarang pengembangan, seperti yang sudah kita buat di bagian pertama artikel, sudah menjadi aktivitas tim. Kenyataannya, beberapa orang dapat terlibat dalam satu bagian kode sekaligus, yang berarti bahwa menyelesaikan masalah kepenulisan dapat menimbulkan kontroversi, kebencian, dan, pada akhirnya, membuang-buang waktu.
Dalam lingkungan saat ini, lebih bijaksana untuk melacak kepengarangan di tingkat proyek, daripada langsung di kode. Ketika Anda perlu mencari tahu siapa yang harus dihubungi dengan pertanyaan tentang bagian tertentu dari kode, sistem kontrol versi akan membantu.
Sekarang kita telah melihat inti dari "dimensi manusia" dalam sebuah perusahaan IT dari semua sisi, kita dapat beralih ke lapisan periferal: elemen asing yang mengelilingi tim dan pengguna.