Di GitLab, udalenka bukan risiko bisnis, tetapi keunggulan kompetitif.
Saya seorang manajer produk di GitLab. Saya biasanya melakukan tahap perencanaan dalam siklus hidup DevOps . Saya datang pada November 2016 dan sejak itu saya mengagumi lompatan dan batasan yang dikembangkan GitLab sebagai produk dan sebagai tim. Banyak pendatang baru yang meminta saya minum kopi tentang budaya GitLab, terutama tentang udalenka, karena kami hanya bekerja seperti itu . Seiring waktu, pandangan saya berubah, dan saya ingin memberi tahu Anda mengapa udalenka bagi saya tampaknya bukan sebagai hambatan, tetapi sebagai keunggulan kompetitif. Pokoknya, untuk GitLab.
Bagaimana saya terbiasa
Ketika saya datang ke GitLab, bagi saya sepertinya udalenka adalah masalah yang perlu diselesaikan. Atau setidaknya kontrol. Saya pikir itu risiko. Misalnya, saya ingin bertemu dengan tim saya setiap hari. Perusahaan dan buku pintar Lembah Silikon mengatakan Anda perlu bertemu dan berbicara secara teratur, jika tidak, tidak mungkin menciptakan produk yang sukses dan menaklukkan pasar. Betapa terkejutnya saya saat itu, kami tidak pernah bertemu (dan tidak akan pergi). Dan - hal yang aneh - kami bekerja sama dengan sukses dan mengirimkan produk hanya di jalan. Saya tentu tidak mengharapkan ini.
Kemudian ia menjadi terbiasa membuat produk dengan gaya GitLab , dan udalenka tampaknya tidak begitu berisiko. Tentu saja ada beberapa kekurangan, tetapi sisanya adalah kegembiraan belaka. Inilah pro dan kontra udalenka , jika tertarik.
Sebenarnya, menimbang pro dan kontra tidak cukup untuk menggambarkan pentingnya pekerjaan jarak jauh untuk GitLab. Dengan remote (dan komponen kunci lainnya dari GitLab), kami menciptakan inovasi dengan sangat cepat, yang berarti kami mendapatkan keunggulan kompetitif yang unik. Dan inilah alasannya.
Komponen yang saling tergantung
Udalenka sangat cocok di GitLab berkat komponen-komponen penting yang saling tergantung:
Komunikasi asinkron
Karyawan jarak jauh tersebar di seluruh planet ini dan bekerja di zona waktu yang berbeda. Oleh karena itu, kami lebih suka komunikasi asinkron (biasanya dalam bentuk teks) , diperluas dalam ruang dan waktu. Dalam format ini, Anda harus merekam semuanya, dan diekspresikan dengan jelas dan jelas. Itu tidak melakukan sebaliknya, karena kadang-kadang mungkin untuk bertukar hanya satu atau dua kalimat sehari. Kami lebih suka teks, karena di Internet dan aplikasi modern (misalnya, dalam tugas GitLab ), teks cocok untuk pengorganisasian, pencarian, dan hyperlink. Teks mudah diurai dan berasimilasi. Ini adalah bentuk komunikasi yang sangat efektif, terutama untuk kolaborasi.
Transparansi
Pesan asinkron digital dapat dikirim sebanyak yang Anda suka, tidak seperti dokumen kertas di kantor. Kami tidak dipagari oleh tembok, seperti pada perusahaan tradisional. Komunikasi dan pekerjaan kami transparan secara default. Terkadang Anda harus menambahkan izin dan kemudian mengelolanya lagi, dan ini merupakan biaya tambahan. Jika Anda ingin mengirim pesan, Anda harus memikirkan siapa yang harus menerimanya dan mengonfigurasi izin. Penerima juga mendapatkan lebih banyak pekerjaan, karena Anda tidak akan dapat mengakses konten dengan mudah. Ini sakit kepala tambahan, dan hal-hal seperti itu menumpuk. Kami berusaha menghindarinya.
Jadi jelas bahwa siapa pun dapat melihat pesan Anda, meskipun tidak berfungsi di sini. Jadi lebih baik mengatakannya segera.
Jika semuanya transparan, mengatakan yang sebenarnya sangat sederhana, dan tidak perlu berbohong. Ini tidak hanya benar, tetapi juga bermanfaat dalam hal pengembangan bisnis jangka panjang. Misalnya, jelas bahwa siapa pun dapat melihat pesan Anda, meskipun tidak berfungsi di sini. Jadi lebih baik untuk segera mengatakannya apa adanya, dan Anda cepat terbiasa dengannya. Anda tidak perlu membuat versi terpisah untuk masing-masing, dan kemudian masih ingat apa yang Anda kirim kepada siapa. Anda memiliki satu sumber kebenaran, dan Anda tidak akan bingung karenanya. Tidak ada yang lain. Kami biasanya memiliki deskripsi ini di tiket.
Semua orang menari!
Ketika satu sumber kebenaran tersedia untuk semua orang, semua orang berkontribusi . Setiap orang memiliki informasi yang sama, dan setiap orang dapat bekerja dengannya. Ingat, saya mengatakan bahwa pengirim biasanya berpikir siapa yang akan menerima pesan? Dalam kasus kami, sesuatu yang bermanfaat dapat datang dari tempat mereka tidak menunggu. Anda tidak dapat melakukan ini tanpa transparansi: hambatan buatan menghalangi kemungkinan kerjasama. Terkadang ide yang bagus perlu matang. Misalnya, Anda menyatakan beberapa ide, tetapi syarat untuk itu bukan yang paling cocok. Dan ternyata hanya masalah waktu saja. Di masa depan, seseorang akan menggali ide ini dan mengembangkannya lebih lanjut, menggunakan semua diskusi dan perkembangan terbuka.
Ketika semua orang bisa mengirimkan ide, mereka menjadi kereta. Di GitLab, terkadang solusi terbaik untuk masalah rumit datang dari tim yang sepenuhnya berbeda. Tetapi kita masih memiliki mereka yang bertanggung jawab . Mereka membuat keputusan saat kita mandek.
Iterasi
Bagaimana cara mengumpulkan semua komunikasi dan kolaborasi ini jika pada dasarnya bersifat transaksional, didistribusikan, dan tidak terstruktur? Kita harus bekerja secara iteratif . Banyak (termasuk saya) berpikir mereka mengerti iterasi sampai mereka datang ke GitLab. Saya terus-menerus melihat pendatang baru yang terkejut sampai sejauh mana kami membawa konsep ini. Produk dan kode dikirimkan dalam fragmen minimal sehingga pengembang segera menerima umpan balik dan tahu ke mana harus bekerja selanjutnya. Di GitLab, Anda memotong potongan-potongan kecil dan segera mulai bekerja. Tentu saja, kami membuat rencana muluk, tetapi kami tidak terpaku pada analisis terperinci. Kami hanya mengambil tugas terkecil dan menyelesaikannya. Setiap hari menunggu, kami menganggapnya sebagai untung yang hilang. Lebih baik melakukan setidaknya sesuatu hari ini dan mendapatkan hasilnya segera. Kami fokus pada aksi .
Setiap hari menunggu, kami menganggapnya sebagai untung yang hilang. Lebih baik melakukan setidaknya sesuatu hari ini dan segera mendapatkan hasilnya.
Dan fragmen kecil memiliki masalah kecil. Adalah logis bahwa ada lebih banyak orang yang tertarik dengan masalah kecil: melihat deskripsi tiket bukanlah presentasi dua jam untuk Anda duduk. Dan karena masalah ini transparan secara default, siapa pun dapat menyelesaikannya sama sekali. Secara pribadi, saya membahas 20-30 masalah pada waktu yang sama setiap hari. Saya hampir tidak akan menguasainya jika saya harus menghadiri pertemuan khusus setiap saat. Sebagai hasilnya, saya setidaknya entah bagaimana berpartisipasi dalam sejumlah proyek yang luar biasa. Lipat gandakan ini dengan semua tim GitLab, dan kemudian oleh seluruh komunitas GitLab, dan segera jelas dari mana semua inovasi ini berasal dari GitLab.
GitLab tidak menderita dengan remote, tetapi mendapat manfaat penuh darinya.
Kesimpulannya
Di sini saya berbicara tentang korespondensi tanpa akhir dan sumber ide. Jadi kami bekerja. Kebetulan bahwa pendatang baru dalam beberapa minggu melihat bahwa mereka macet dalam semua diskusi sekaligus. Ini tidak mengherankan, karena kami berkembang, ada semakin banyak ide, jaringan kami tumbuh dan ikatan di antara kami semakin berlipat ganda. Tetapi segera, para pemula belajar untuk memilih hanya yang paling menarik. Saya pikir ini adalah strategi yang baik, karena ide-ide bagus menarik lebih banyak perhatian, dan kami mempercayai pikiran kolektif kami. Tetapi kita masih membutuhkan peran dan tanggung jawab yang jelas sehingga spesialis dan pengambil keputusan yang sempit mendorong inovasi kita ke kanan
arah.
Dan bagaimana Anda menangani udalenka? Posting komentar atau tweet di @gitlab .