Proses pembangunan dari awal: dari kekacauan ke ketertiban

Pada artikel ini, saya akan berbicara tentang membangun alur kerja di departemen pengembangan web kecil. Departemen dibentuk dari awal dan segera memulai pekerjaan otonom, jadi kami harus membangun proses produksi sendiri, menginjak semua jenis garu dan menarik kesimpulan yang diperlukan dari ini. Dengan harapan hal ini akan membantu seseorang menghemat waktu, uang, dan kegelisahan, saya akan menjelaskan masalah yang kita hadapi dan pilihan kita untuk menyelesaikannya.

Penting untuk dicatat bahwa ini bukan metodologi universal yang dapat diimplementasikan dalam tim pengembangan apa pun, dan semuanya akan segera menjadi luar biasa. Ini hanya campuran teknik terkenal dan pengalaman praktis, yang kami dapat menyesuaikan secara efektif dengan fitur perkembangan kami. Tidak ada solusi tunggal dan sederhana untuk masalah ini. Anda selalu perlu membangun ukuran dan pengalaman tim itu sendiri, karakteristik bisnis, spesifikasi proyek, dll.

Data awal departemen kami: tim produk kecil (5-10 orang), sebagian didistribusikan (sebagian karyawan bekerja dari jarak jauh, beberapa di kantor) dengan pelanggan di dalam perusahaan. Proyek web. Tidak ada spesialis administrasi sistem dalam departemen, tetapi ada departemen yang terlibat dalam perusahaan.

Komunikasi tim

Mari kita mulai dengan membangun komunikasi yang efektif di dalam departemen. Dalam tim mana pun, penting untuk membangun saluran dan cara komunikasi yang efektif, tetapi ketika tim didistribusikan, kebutuhan ini meningkat. Ini mencapai ketajaman maksimumnya di sini karena tim hanya didistribusikan sebagian. Kami harus belajar untuk menggabungkan dunia kantor dan karyawan jarak jauh.

Masalah paling penting yang kami temui adalah diskusi verbal. Staf kantor selalu memiliki godaan untuk dengan cepat mengemas secangkir kopi dan mendiskusikan status proyek. Namun, dalam kasus ini, pekerja jarak jauh tidak akan dapat berpartisipasi dalam diskusi ini, oleh karena itu, mereka tidak akan dapat menyumbangkan ide-ide mereka, dan memang mereka tidak akan tahu bahwa sesuatu sedang terjadi. Sebagai aturan, ini menghasilkan desinkronisasi tindakan tim, diskusi berulang karena munculnya pemikiran dan saran baru dari bagian tim terdistribusi dan hanya aftertaste yang tidak menyenangkan.

Menjadi jelas bahwa beberapa hal umum yang penting harus dibahas secara tertulis dalam obrolan umum atau pada beberapa panggilan kelompok.

Ini menimbulkan masalah lain yang sangat umum yang muncul dalam tim di mana Anda perlu banyak menulis - masalah budaya menulis. Anda tidak bisa hanya pergi ke kolega, menarik lengan baju Anda, menggambar sesuatu di atas serbet dan menambahkan gerakan ke cerita Anda. Di satu sisi, ini mempersulit pekerjaan, dan di sisi lain, orang mengembangkan keterampilan menulis pikiran mereka dengan cara yang dapat dipahami dan terstruktur. Sebagai hasil dari pendekatan ini, dokumentasi mulai diformalkan dengan lebih baik, tugas-tugas mulai dirumuskan lebih jelas, semua orang mulai berpikir tentang bagaimana menyajikan pemikiran mereka sedemikian rupa sehingga mereka dapat dimengerti oleh orang lain sejak membaca pertama.

Semua hal di atas tidak berarti bahwa kami sepenuhnya mengabaikan komunikasi pribadi, panggilan suara dan video. Namun, kami membuat aturan bahwa hasil diskusi tersebut harus dicatat secara tertulis, sebagai semacam artefak pengetahuan, selalu tersedia untuk semua orang.
Secara singkat lihat daftar alat dangkal yang dengannya kami menyelesaikan tugas komunikasi kami di dalam tim.

Pertama, kami memulai obrolan di Telegram. Tetapi kemudian, sehubungan dengan pertumbuhan tim, kami menyadari bahwa dalam satu obrolan kami sudah dekat, dan beralih ke Slack. Di sana kami membagi aliran umum ke saluran tematik dan menetapkan aturan yang jelas - untuk alasan apa untuk menulis ke saluran mana. Ini membantu menghindari pencampuran informasi yang berguna dan banjir.

Selain itu, beralih ke Slack memberi kami beberapa peluang bagus untuk otomatisasi dan integrasi dengan layanan lain, seperti sistem manajemen repositori atau pelacak bug.

• Panggilan audio dan video - Skype for Business.
• Kami melakukan tugas di Jira.
• Basis pengetahuan disimpan dalam Confluence.

Perencanaan tugas, pelaksanaan, dan kontrol

Ketika kami membangun komunikasi, masalah pengaturan, pengendalian, dan penyelesaian tugas dalam tim menjadi relevan (saya akan berbicara tentang bekerja dengan pelanggan dalam hal ini beberapa saat kemudian).
Kami tidak memiliki satu daftar tugas, prioritas, status kesiapan, dll. Alih-alih rencana yang jelas, transparan, dan dapat dilacak, perencanaan dan pelaksanaan jangka pendek spontan hadir.

Untuk menghadapi situasi ini, kami mulai menggunakan bugtracker (pada kenyataannya, kami mencoba lima dari mereka). Garis besar arah umum proyek mulai muncul, pemahaman tentang keadaan di mana tugas-tugas tertentu dan gambaran keseluruhan secara keseluruhan muncul. Namun, kami dihadapkan dengan masalah kurangnya disiplin ketika menggunakan bugtracker, yang mulai merendahkan banyak upaya kami. Tidak semua tugas dimulai di bugtracker, yang ada tidak selalu diperbarui, dll. Sederhananya, gambaran keadaan proyek tidak lagi relevan dan dapat diandalkan.

Untuk mengatasi hal ini, kami telah mengembangkan dan menerapkan budaya manajemen tugas kami sendiri:

• Pekerjaan tidak boleh dilakukan sampai tugas yang sesuai telah dimulai. Ini membantu untuk tetap mengetahui sejarah proyek dan pekerjaan tim.
• Ketika bekerja dengan suatu tugas, perlu untuk mengubah statusnya secara tepat waktu. Dalam kasus kami, empat status sudah cukup: "Untuk melakukan" - status awal tugas, "Sedang berlangsung" - tugas yang sedang berlangsung, "Ditunda" - tugas yang mulai mereka lakukan, tetapi pekerjaan ditunda (kami sedang menunggu beberapa informasi tambahan ), "Done" - tugas sudah siap. Kesiapan tugas entah bagaimana harus dikonfirmasi oleh pelanggan atau manajer dalam tim.
• Seiring waktu, jumlah tugas dan proyek telah meningkat secara signifikan, jadi kami telah membagi daftar pekerjaan umum menjadi subproyek yang terpisah, dan tugas tersebut harus dimulai sesuai dengan daftar sub proyek ini.
• Tugas harus diberikan prioritas. Ini membantu untuk memahami tugas apa dalam urutan apa yang harus dilakukan untuk membawa manfaat maksimum proyek.
• Tugas yang ditinjau secara berkala dan prioritasnya. Karena proyek hidup dan berkembang, dan rencana bisnis terkadang berubah, seiring berjalannya waktu, beberapa tugas menjadi kurang atau lebih relevan atau bahkan mengharuskan mereka dihapus.
• Beberapa diskusi utama tentang tugas-tugas yang dilakukan secara lisan atau tertulis dalam obrolan memerlukan perbaikan solusi akhir dalam tugas itu sendiri, sehingga ketika kita menyelesaikannya kita selalu melihat informasi yang paling relevan tentang hal itu dan sejarahnya. Sering terjadi bahwa pernyataan awal masalah setelah serangkaian diskusi diubah menjadi sesuatu yang sama sekali berbeda, dan kita perlu memantau ini.
• Jika tugas dipindahkan dari satu kelompok spesialis ke yang lain dalam tim, maka kelompok yang mentransfer harus memperbaiki semua artefak pengetahuan yang diperlukan yang harus ditransfer ke kelompok berikutnya. Misalnya, tim desain harus melampirkan mock-up dan semua dokumentasi yang diperlukan untuk pengembangan sebelum mentransfer tugas ke tim pengembangan. Ini menghindari pertanyaan yang tidak perlu, gangguan, dan perubahan konteks.
• Melampirkan komitmen pada tugas. Menggunakan beberapa aturan untuk memberi nama komit, kami secara otomatis melampirkan tautan ke komit ke tugas GitLab. Ini sangat membantu dalam pengembangan untuk memahami siapa, apa, bagaimana, dan kapan melakukan tugas ini. Dan di arah yang berlawanan, dengan komit yang dinamai dengan benar, Anda selalu dapat menemukan tugas yang berisi alasan perubahan yang dilakukan.

Komunikasi Pelanggan

Kategori kesulitan berikutnya yang perlu kami selesaikan adalah bekerja dengan pelanggan. Hal pertama yang harus kami hapus adalah menetapkan kata-kata dengan kata-kata. Jika kami memperkenalkan budaya menulis di dalam departemen, maka sudah saatnya untuk memperluasnya ke kontak eksternal.

Bukan rahasia lagi bahwa manajer lain suka mendekati pengembang, dengan kata lain memberitahunya apa yang perlu dilakukan, menyodok jari di layar untuk persuasif dan pergi, berharap semuanya akan dilakukan dengan baik dan tepat waktu. Dalam situasi ini, manajer dan pengembang dapat digantikan oleh pemilik produk dan manajer tertentu dari tim pengembangan yang memimpin semua tugas ini. Hasil ini tidak akan berubah.

Ada beberapa masalah dengan pendekatan ini:

• Apa yang diucapkan dengan kata-kata dan gerak tubuh akan dilupakan (setidaknya sebagian) tentang besok, paling banter, lusa. Ini bukan tentang hal-hal kecil, tetapi tentang bahaya melupakan tugas itu sepenuhnya. Pada saat yang sama, tidak mungkin untuk mengkonfirmasi dengan cara apa pun Anda menaruhnya ke seseorang atau seseorang menjanjikan Anda untuk melakukan setidaknya sesuatu.
• Biasanya, pernyataan masalah semacam itu agak kacau, dan tidak ada detail yang mendalam di dalamnya. Akibatnya, sangat sulit untuk mengklarifikasi informasi yang hilang.
• Seperti dibahas sebelumnya, pernyataan masalah dalam kata-kata memanjakan keengganan yang korup untuk belajar merumuskan pikiran mereka secara tertulis sehingga orang lain mengerti.

Ketika Anda memiliki banyak pelanggan, dan masing-masing memiliki karakteristiknya sendiri, sulit untuk membangun satu urutan kerja dengan semua orang. Idealnya, kami ingin membawa semua pelanggan ke pelacak bug, tempat mereka dapat menetapkan tugas, menetapkan prioritas, membahas detail, menerima pekerjaan. Tetapi ini tetap merupakan tugas yang mustahil. Namun, kami dapat menemukan kompromi di mana tugas mengalir bersama dalam alur yang ditulis dengan ketat ke departemen surat perusahaan kami, dan di pihak kami manajer memulai dan mengarahkan mereka lebih jauh dalam pelacak bug sesuai dengan aturan yang telah ditetapkan di negara kami. Tugas tidak lagi hilang, dilupakan, disimpan dalam benak orang-orang tertentu, dibahas oleh komposisi yang tidak lengkap dari spesialis yang diperlukan, dll.

Selanjutnya, kami menghadapi satu masalah penting: sulit bagi pelanggan untuk merumuskan tugas. Pelanggan tidak selalu cukup kompeten (atau lebih tepatnya, hampir selalu kurang kompeten) dalam perumusan spesifikasi teknis untuk tim teknis. Dan ini normal. Faktor manusia tidak dapat diabaikan: bisa menjadi hal yang biasa bagi pelanggan untuk merasa malu dan tidak nyaman untuk datang ke tim dengan permintaan ketika dia sendiri belum dapat merumuskannya sepenuhnya. Salah satu kriteria tim profesional yang matang adalah kemampuan untuk membantu pelanggan dalam mengidentifikasi masalah, persyaratan, dan solusinya.

Sering terjadi bahwa pelanggan, bukannya datang dengan masalah, datang dengan permintaan untuk implementasi solusi yang telah ia ciptakan. Agar tidak mengejutkan diri sendiri atau pelanggan dengan hasil pekerjaan pada ToR yang disusun "di atas serbet", kami membuat daftar periksa dasar pertanyaan untuk pelanggan. Sudah berdasarkan jawaban ini, lebih mudah bagi pelanggan untuk memahami apa yang benar-benar diinginkannya dan tim pengembangan apa yang diperlukan darinya. Dan kemudian giliran untuk mengajukan beberapa pertanyaan sugestif untuk menjelaskan atau mengidentifikasi persyaratan.

Jadi, sebelum pertemuan pertama dengan pelanggan, kami meminta Anda untuk mengisi sebelumnya (sebanyak mungkin) dan mengirimkan daftar periksa ini kepada kami sehingga setelah itu Anda tidak perlu membuang waktu untuk pertanyaan yang sama, tetapi segera mulai dialog yang bermanfaat. Perlu dicatat bahwa ketika berinteraksi dengan pelanggan, penting tidak hanya untuk mengklarifikasi jawaban yang ia berikan, tetapi juga berdasarkan masalah yang dinyatakannya untuk membantunya mengidentifikasi persyaratan yang mungkin tidak terpikirkan olehnya.

Daftar pertanyaan untuk pelanggan:

• Apa tujuan dari proyek ini? Masalah apa yang dipecahkan ini? Nilai bisnis apa yang dibawanya?
• Apakah ini satu-satunya solusi yang mungkin untuk masalah ini? Jika tidak, opsi apa lagi yang ada?
• Apakah ada persyaratan umum yang harus dipenuhi dalam keseluruhan proyek? Misalnya, jika ini adalah toko online, maka ia harus sepenuhnya mematuhi undang-undang yang mengatur perdagangan online.
• Apakah ada persyaratan fungsional? Apa yang harus dilakukan bagian (halaman, proyek)? Misalnya, bagian tersebut harus memberikan informasi tentang produk perusahaan dan, melalui formulir di halaman, kumpulkan mereka yang ingin mengajukan pertanyaan tentang produk ini atau memperolehnya.
• Apakah ada persyaratan non-fungsional? Seberapa baik dia harus melakukan ini? Misalnya, waktu pembukaan halaman tidak boleh lebih dari 5 detik.
• Persyaratan tambahan. Format gratis di mana Anda dapat mencurahkan jiwa.

Masalah lain yang harus kami hadapi: tugas datang dari semua sisi secara bersamaan. Ketika ada banyak pelanggan pada proyek yang berbeda, maka semua orang ingin memberikan tugasnya prioritas tertinggi. Dalam kasus ideal umum, mungkin, masalah seperti itu tidak dapat diselesaikan 100%. Bagaimana kita hidup dengan ini? Dengan diperkenalkannya disiplin dalam perumusan dan pengelolaan tugas, serta beberapa elemen metodologi Agile, kumpulan tugas kami menjadi lebih ramping, transparan bagi pengamat eksternal, dan yang paling penting, dapat diprediksi. Kami telah menetapkan pesanan dan rencana dalam tim kami, dan kami hanya perlu memperkuat umpan balik dengan pelanggan. Dalam membahas prioritas, tenggat waktu, dan rencana, kami belajar bagaimana membangun dialog argumentatif, daripada secara membabi buta melemparkan diri pada tugas dan terus-menerus memadamkan api yang menyala-nyala (yang sebenarnya tidak selalu relevan dan tidak selalu kebakaran).

Kami juga mencoba untuk memberantas “manajemen burung camar” antipattern klasik dalam kerangka paragraf ini, ketika seorang pelanggan atau manajer terbang, “meletakkan” tugas - dan terbang dengan keyakinan penuh bahwa begitu ia menetapkan tugas, ia pasti akan mendapatkan hasil yang sangat baik. Seperti yang telah ditunjukkan oleh praktik, hasil dengan pendekatan ini bukan yang paling mengesankan. Bagaimana cara mengatasinya? Di sini, juga, tidak ada nasihat universal, tidak ada ungkapan ajaib yang mengubah perilaku orang. Untuk melakukan ini, Anda perlu bicara, mendidik, menjelaskan, menunjukkan, Anda bisa mengatakan mendidik. Hanya pekerjaan pendidikan dan contoh yang sangat visual atau sangat terukur (dan lebih disukai keduanya) positif dan negatif akan membantu untuk mengatasi "manajemen burung camar" secara memadai.

Dev vs Ops

Dan masalah penting terakhir kami adalah masalah komunikasi antara departemen Dev dan Ops.
Kami dihadapkan pada situasi klasik di mana pengembang tidak memahami dengan baik bagaimana server bekerja, dan tim admin pihak ketiga tidak benar-benar memahami cara kerja aplikasi. Setiap kesulitan di persimpangan dua bidang ini diberikan kepada kami dengan rasa sakit dan banyak waktu. Bahkan sulit untuk mendiagnosis sisi masalah yang mana:

• Anda memprogramnya di sana!
• Tidak, di sana Anda memiliki sesuatu dengan server di sana!

Dalam hal ini, ini membantu kami bahwa pengembang muncul dalam tim yang fasih dalam administrasi. Dia dapat berbicara dengan masing-masing kelompok dalam bahasanya dan mendiagnosis setiap masalah dari kedua belah pihak. Perbedaan mulai menurun, tetapi kami tetap terikat pada pria ini. Untuk mengatasi semua masalah ini dari dirinya sendiri, ia mulai membantu administrator memahami cara kerja aplikasi, dan programmer - apa yang terjadi di server. Kami menambah penjelasan dokumentasi penulisan suara dan tidak hanya mendapatkan pengetahuan dari seluruh tim, tetapi juga pekerjaan yang lebih terkoordinasi dari departemen Dev dan Ops. Ya, di bagian besar dari perusahaan berdarah ada tim khusus dan orang-orang yang memenuhi syarat yang akan mengatur semuanya sehingga para pengembang bahkan mungkin tidak tahu bagaimana dan di mana pekerjaan mereka bekerja di server. Namun, dalam tim kecil akan menyenangkan untuk mengembangkan tingkat kompetensi ini pada orang, serta memiliki setidaknya satu karyawan yang sudah berkembang dengan baik dalam hal ini.

Pengembangan

Sejalan dengan semua ini, kami mengambil pengembangan budaya pembangunan.
Saya tidak akan fokus pada bagian teknis, dan sekarang sudah menjadi standar de facto dan hampir semua orang tidak memiliki pemahaman tentang perlunya sistem kontrol versi, CI / CD dan alat pengembangan, perakitan dan penyebaran lainnya. Saya hanya akan memikirkan saat-saat lembut perkembangan.

• Codestyle Sangat penting untuk mengembangkan dan secara eksplisit menyetujui aturan untuk desain kode. Pertama, secara estetika menyenangkan melihat satu tampilan harmonis dalam proyek, daripada kebun binatang dengan gaya dan standar yang berbeda. Kedua, ini meningkatkan keterbacaan kode, dan seperti yang kita ketahui, sebagian besar waktu programmer tidak menulis kode, tetapi membaca kode orang lain.
• Penamaan berkomitmen . Kami memperkenalkan aturan tertentu untuk penamaan yang dilakukan, sehingga dengan nama komit, jelas perubahan apa yang dilakukan, oleh siapa, dan dalam tugas apa.
• Ulasan kode . Kekhususan proyek dan tim kami sedemikian rupa sehingga kami tidak memiliki tinjauan kode wajib, yang tanpanya tidak mungkin untuk menuangkan kode kami ke dalam produksi. Namun, kami membuat aturan bahwa setidaknya satu orang melihat kode yang didorong oleh rekan kerja. Ini membantu baik untuk melihat kekurangan, memperkenalkan ide-ide alternatif, dan mengikuti semua bagian dari sistem. Tinjauan kode menjadi sangat relevan dengan meningkatnya jumlah dan kompleksitas proyek, itulah sebabnya setiap pengembang tidak lagi memiliki waktu untuk mengerjakan semua proyek cukup untuk memahami semua detail mereka.
• Menyelaraskan arsitektur dalam tim sejak dini . Sering terjadi bahwa dalam upaya untuk membuat fitur lebih cepat, frontend mulai melakukan sesuatu sendiri, backend cepat memulai sendiri, dan kemudian ternyata terintegrasi dengan kesulitan besar atau tidak berintegrasi sama sekali. Dalam pengembangan fitur-fitur besar, kami bersama-sama mendiskusikan arsitektur sebelumnya, format pertukaran data, dll. Akibatnya, integrasi tidak lagi panjang dan menyakitkan.
• Pengembangan Berbasis CV . Ini adalah masalah di mana pengembang menyeret teknologi baru (segar, modis, bergaji tinggi) ke dalam proyek bukan demi proyek, tetapi demi tanda centang dalam resume. Kami terbuka untuk teknologi baru dan mencoba mengembangkan proyek kami secara teknologi, namun penting untuk menjaga keseimbangan di mana akan ada kemajuan teknologi dan berhasil menyelesaikan proyek dalam kerangka waktu yang wajar. Dua hal penting dalam topik licin ini: bahwa pelanggan tidak mendorong tenggat waktu sehingga pengembang tidak memiliki waktu istirahat, dan bahwa tim pengembangan (atau, setidaknya, pemimpin tim yang kompeten atau tim teknis) tidak hanya peduli tentang pengembangan profil LinkedIn mereka, tetapi juga tentang kesejahteraan proyek. secara umum.

Refactoring, utang teknis dan prinsip peningkatan berkelanjutan

Departemen kami mulai terbentuk di sekitar armada proyek yang ada yang dibuat oleh agen outsourcing. Secara alami, tidak ada dokumentasi di sana, tidak ada yang mengikuti relevansi dan kualitas kode. Karena kami memahami bahwa kami masih harus bekerja, memelihara, dan mengembangkan ini untuk waktu yang lama, diputuskan untuk mencurahkan sebagian waktu untuk menertibkan proyek - refactoring, menghapus kode yang tidak relevan, dll.

Karena proyek itu besar, tingkat entropi juga tinggi di dalamnya. Kami menyadari bahwa dalam sekali duduk tidak mungkin mengatasi semuanya secara fisik, dan secara moral menyerah pada prospek pekerjaan kolosal semacam itu. Kami memutuskan untuk menerapkan prinsip Jepang perbaikan berkelanjutan "kaizen". Kami membagi utang teknis menjadi banyak bagian kecil dan sedikit demi sedikit, tetapi secara berkala menutup bagian-bagian kecil ini, terus menerus memodifikasi dan meningkatkan baik proyek maupun pekerjaan tim itu sendiri.Secara moral, ini tidak menimbulkan ketidaknyamanan, tetapi pada saat yang sama tidak berdampak signifikan pada pengembangan fungsionalitas baru dan cakupan persyaratan bisnis. Setelah satu setengah tahun, kami menemukan bahwa utang teknis lama telah dilunasi, dan ini membuka peluang bagi kami untuk mengembangkan fungsionalitas tingkat kompleksitas dan kepentingan yang secara fundamental baru.

Tentu saja, ini tidak berarti bahwa kita sekarang tidak memiliki hutang teknis. Ketika proyek hidup, berevolusi, tumbuh dan berkembang, itu tentu membangun. Namun, kami dengan hati-hati memonitornya, menundanya dalam kumpulan tugas khusus, dan secara teratur menyediakan waktu untuk melunasinya. Kerja berkelanjutan seperti itu dengan utang teknis memungkinkan kami menemukan keseimbangan antara pengembangan fungsionalitas baru dan dukungan berkualitas tinggi untuk yang lama.

Dalam kasus kami, kami, pengembang, dapat menjelaskan dan menunjukkan bisnis pentingnya melunasi hutang teknis. Bagaimana kami melakukan ini? Dalam praktiknya, kami telah menunjukkan situasi di mana, jika Anda tidak melakukan refactor atau melakukan beberapa perubahan struktural lainnya pada proyek saat ini, mengembangkan fungsionalitas baru atau mengubah yang lama pada prinsipnya (atau mungkin, tetapi beberapa kali lebih lambat).

Terapkan Metodologi Agile

Implementasi beberapa ide metodologi Agile memungkinkan kami untuk meningkatkan transparansi pekerjaan kami baik di dalam tim dan untuk bisnis, untuk membuat pengembangan lebih mudah diprediksi dan fleksibel, dan hasilnya lebih stabil.

Hal pertama yang kami lakukan adalah mengatur stand-up harian dalam tim. Karena tim didistribusikan, Slack menetapkan saluran terpisah untuk ini, di mana setiap karyawan menulis tiga poin setiap pagi: tugas apa yang dia kerjakan kemarin, apa yang dia rencanakan untuk kerjakan hari ini, apakah ada masalah yang menghambat pekerjaannya. Dilarang membanjiri saluran ini, mendiskusikan tugas atau masalah seseorang. Saluran ini hanya untuk pengumpulan informasi tentang keadaan. Diskusi yang tersisa harus dilakukan dalam saluran tematik yang sesuai. Ini memungkinkan setiap orang dalam tim untuk memahami apa yang dilakukan rekan-rekannya, apa yang terjadi dengan proyek secara umum, siapa yang dapat dan harus dibantu. Jika tanpa stand-up masalah tersendat, dan setelah waktu yang lama tiba-tiba ternyata tugas itu belum siap, sekarang jelas siapa yang butuh bantuan,apa yang perlu dilakukan untuk membuat tim bekerja lebih efektif.

Selanjutnya, kami memutuskan untuk mengembangkan sprint. Setiap hari Jumat di penghujung hari kami melakukan sprint retrospektif, melihat tugas apa yang direncanakan, apa yang siap, apa yang tidak siap, dan jika ada sesuatu yang tidak siap, lalu mengapa itu terjadi. Kami memikirkan masalah apa yang kami miliki dan apa yang bisa kami lakukan untuk menghindari kesulitan yang sama di masa depan. Kemudian kami merencanakan sprint untuk minggu depan berdasarkan beban kerja berbagai area dalam tim dan prioritas bisnis. Akibatnya, pada awal minggu, semua pengembang tahu apa yang harus dilakukan dan dalam urutan apa, dan bisnis tahu apa kebutuhannya akan tercakup dalam waktu dekat, dan sudah dapat membentuk "Wishlist" sendiri untuk sprint berikutnya. Perlu dikatakan bahwa kita tidak luput dari tugas mendadak yang dapat mengganggu rencana sprint kita.Dalam hal ini, Anda perlu bertindak berdasarkan sifat spesifik pekerjaan: seberapa sering tugas tersebut muncul? Berapa banyak Bisakah ini diprediksi? Dalam kasus khusus kami dalam pengembangan, kami secara eksperimental menghitung berapa banyak waktu rata-rata jatuh pada tugas yang tidak direncanakan dan mencoba untuk meletakkan margin ini dalam sprint. Secara terpisah, perlu dicatat bahwa setelah mulai bekerja pada sprint, kami dapat secara khusus mengetahui berapa banyak pekerjaan yang dikirimkan kepada kami di pintu masuk yang tidak terjadwal, menganalisis dan mengurangi jumlah ini, dengan hati-hati membahas prioritas dengan pelanggan dan dengan jelas menunjukkan bagaimana keinginan sesaat untuk mendapatkan fitur yang paling penting saat ini memengaruhi pada produktivitas keseluruhan dari seluruh tim.berapa waktu rata-rata untuk tugas yang tidak direncanakan dan mencoba meletakkan margin ini di sprint. Secara terpisah, perlu dicatat bahwa setelah mulai bekerja pada sprint, kami dapat secara khusus mengetahui berapa banyak pekerjaan yang dikirimkan kepada kami di pintu masuk yang tidak terjadwal, menganalisis dan mengurangi jumlah ini, dengan hati-hati membahas prioritas dengan pelanggan dan dengan jelas menunjukkan bagaimana keinginan sesaat untuk mendapatkan fitur yang paling penting saat ini memengaruhi pada produktivitas keseluruhan dari seluruh tim.berapa waktu rata-rata untuk tugas yang tidak direncanakan dan mencoba meletakkan margin ini di sprint. Secara terpisah, perlu dicatat bahwa setelah mulai bekerja pada sprint, kami dapat secara khusus mengetahui berapa banyak pekerjaan yang dikirimkan kepada kami di pintu masuk yang tidak terjadwal, menganalisis dan mengurangi jumlah ini, dengan hati-hati membahas prioritas dengan pelanggan dan dengan jelas menunjukkan bagaimana keinginan sesaat untuk mendapatkan fitur yang paling penting saat ini memengaruhi pada produktivitas keseluruhan dari seluruh tim.bagaimana keinginan sesaat untuk mendapatkan fitur yang tidak perlu sekarang memengaruhi produktivitas keseluruhan tim.bagaimana keinginan sesaat untuk mendapatkan fitur yang tidak perlu sekarang memengaruhi produktivitas keseluruhan tim.

Kami juga beralih dari rilis lama ke rilis pendek. Sebelumnya, kami menerima TK, berminggu-minggu atau berbulan-bulan melakukan seluruh paket fitur, dan baru kemudian menunjukkannya kepada pelanggan. Akibatnya, sering kali ternyata pelanggan berubah pikiran atau tidak mengharapkannya, dan kami mulai mengulangi semua atau sebagian dari apa yang telah kami lakukan. Dan untuk melakukan perubahan pada serangkaian besar fitur yang sudah jadi adalah kesenangan yang meragukan. Sekarang kami mendemonstrasikan setiap fitur sedini mungkin sehingga pelanggan membuat keputusan - apakah ini yang benar-benar diinginkannya, atau sesuatu perlu diubah. Semakin cepat ia menyetujui atau mengirimkannya untuk direvisi, semakin sedikit tenaga kerja yang akan kami investasikan, oleh karena itu, semakin cepat fitur tersebut mulai diproduksi. Akibatnya, fitur mulai tiba dalam produksi lebih cepat, hipotesis diuji lebih cepat, dan proyek berjalan lebih cepat.

Faktor bus

Karena tim kami kecil, kami segera mulai memikirkan masalah yang mungkin kami temui selama rotasi personel. Orang-orang tertentu telah menjadi penjaga tunggal dari beberapa pengetahuan, proyek telah berkembang dengan cukup, dan oleh karena itu kami mulai mengembangkan budaya penyimpanan dan manajemen pengetahuan.

Pemberantasan masalah ini dibantu oleh akumulasi artefak pengetahuan yang pindah dari kepala orang-orang tertentu ke dunia tulisan fisik. Yaitu:

• Semua pekerjaan dilakukan hanya jika ada tugas di bugtracker. Ini memungkinkan Anda untuk membuat riwayat lengkap perubahan dalam proyek.
• Jika di suatu tempat dalam obrolan atau di rapat umum kami membahas perubahan dalam tugas, kita harus mencerminkan dalam tugas itu sendiri hasil dari diskusi ini.
• . , Gitlab. , .
• Confluence , - , .
• - postmortem « — — — ».

Masih ada praktik yang baik, di mana, tentu saja, Anda perlu mengetahui ukurannya dan tidak menaikkannya secara absolut: jika Anda ditanya tentang beberapa bagian dari sistem yang hanya Anda ketahui, maka disarankan untuk menulis dokumentasi tentangnya dan merespons dengan tautan ke sana. Jadi Anda tidak perlu menjawab pertanyaan ini lagi, dan bertanya kepada orang lain.

Metode mempertahankan artefak pengetahuan ini telah berulang kali membantu kami menemukan informasi tentang bagian-bagian proyek yang seharusnya hilang. Dan dia juga secara signifikan mengurangi risiko untuk proyek dan tim selama rotasi personel. Contoh terakhir: kami dengan cepat dan mudah mengambil informasi tentang logika bisnis, prinsip operasi dan metode penempatan alat, yang dilakukan oleh karyawan yang berhenti dua tahun lalu.

Jika kita menerapkan pekerjaan dengan stand-up dan sprint untuk teknik ini, maka faktor bus semakin berkurang. Belum lama ini, kami melakukan percobaan: satu pengembang sedang berlibur, dan pengembang lain bekerja. Pada saat itu, ketika yang pertama pergi berlibur, yang kedua pergi berlibur. Inti dari percobaan ini adalah tidak menulis surat penjelasan, pesan, tidak menyerahkan kasus dan melihat betapa sulitnya bagi seseorang setelah liburan panjang untuk memahami apa yang terjadi dalam ketidakhadirannya, apa yang berubah, persis bagaimana dan apa rencana untuk masa depan. Seperti yang telah ditunjukkan oleh praktik, melihat bugtracker, komit, dokumentasi, stand-up, dan sprint memungkinkan karyawan untuk memasuki bisnis dengan mudah dan melanjutkan pekerjaan mereka secara mandiri.

Kesimpulan

Sebagai kesimpulan, saya ingin mencatat bahwa tidak ada masalah di atas yang diselesaikan dengan segera dan tanpa cacat. Perubahan organisasi selalu merupakan pekerjaan yang panjang dan metodis. Anda tidak bisa hanya mengatakan "sekarang kita lakukan ini" dan berharap bahwa sekarang semuanya akan berbeda. Setiap keputusan yang Anda buat, setiap peristiwa yang Anda selenggarakan, membutuhkan kontrol, pelatihan dan pencerahan orang, waktu untuk menyesuaikan tim baik dengan metode baru, dan metode itu sendiri dengan situasi tertentu. Saya juga mencatat bahwa penerapan metodologi pada orang adalah proses yang sangat melelahkan dan tidak efisien. Orang-orang akan beristirahat, lupa, bahkan mungkin sabotase.

Agar perubahan yang diperlukan untuk memulai dalam tim, tim itu sendiri harus ingin membuat perubahan ini. Penting untuk memantau bagaimana dia melakukan, mengidentifikasi bidang masalah, menyadari masalah ini, menemukan solusi, dan hanya kemudian mengimplementasikannya. Tentu saja, tidak setiap anggota tim harus dan ingin melakukan ini, tetapi jika ada seseorang yang melihat masalah ini dan menemukan solusi mereka, maka ia pertama-tama akan mencerahkan tim.

Bagikan pengetahuan, pengamatan, pengalaman, perdebatan, tunjukkan, dan buktikan di mana masalahnya sekarang dan langkah apa yang bisa diambil untuk menyelesaikannya. Hanya dengan cara ini transformasi organisasi utama dapat dilakukan seefisien mungkin. Bahkan jika Anda seorang pemimpin dan ingin mendorong posisi dan keputusan Anda - cobalah untuk melakukannya dengan meyakinkan dan meyakinkan, sehingga menghemat waktu dalam implementasi dan menyelamatkan tim dari negativitas yang tidak diinginkan.

Diposting oleh Evgeny Antonov, Kepala Grup Pengembangan Teknologi Positif