Baru-baru ini, saya melihat banyak contoh bagaimana manajer proyek teknis (alias CTO) mengikuti kanon Kultus kargo dalam pengembangan dan pengelolaan proyek, alih-alih memperkenalkan entitas yang diperlukan, dan membangun proses berdasarkan kebutuhan saat ini, sumber daya yang tersedia, dan keterampilan pemain. Kami akan berbicara tentang cara mengidentifikasi kultus Kargo tersebut dan risiko apa yang mereka tanggung untuk proyek tersebut.
Diskusi pagi setiap hari (alias Standup Harian)
Untuk pertanyaan alami saya kepada salah satu CTO seperti itu - seberapa nyata manfaat dari acara ini, CTO dengan jujur menjawab - "Saya juga tidak tahu." Meskipun ada beberapa keuntungan bagi tim, yang sebagian bekerja secara jarak jauh, diskusi tentu saja berujung pada "Kemarin saya menulis kode, hari ini saya menulis kode dan besok saya berencana untuk menulis kode juga, tapi, yah, saya memperbaiki bug ini dan itu". Akibatnya, kami memiliki waktu setengah jam dari masing-masing anggota tim. Beberapa nilai tambah bagi pekerja jarak jauh adalah komunikasi sehari-hari dengan tim, bagi sebagian orang penting. Menurut pendapat saya, kegunaan diskusi harian semacam itu untuk pembangunan agak kecil, karena tugas utama dari pertemuan umum tersebut adalah untuk menyampaikan kepada semua orang informasi tentang keadaan pembangunan saat ini, rencana untuk waktu dekat (dari satu minggu ke satu bulan), untuk membahas beberapa masalah yang menarik semua. Sangat sering, diskusi semacam itu masuk ke dalam diskusi tentang beberapa masalah niche yang menarik untuk beberapa orang, dan sisanya mulai bosan dan berharap kapan itu akan berakhir. Ini tentunya harus ditekan dan dibahas kemudian, dalam format yang lebih sempit. Keadaan pengembangan dan rencana saat ini sangat penting, tetapi cukup untuk membahasnya seminggu sekali atau bahkan kurang, tergantung pada kecepatan tim bekerja.
Penyebaran Cloud
Saat ini, banyak alat tersedia yang memungkinkan Anda untuk menggambarkan infrastruktur proyek (layanan, jaringan, dependensi) dalam bentuk yang nyaman, misalnya, Terraform. Hal ini tentu bermanfaat, tetapi dengan ukuran proyek tertentu, misalnya, ketika menjadi cukup rumit. Untuk sebagian besar startup dan proyek kecil, ini adalah alat yang berlebihan, karena infrastrukturnya sangat jarang berubah, dan kemampuan untuk dengan cepat menggunakan Produksi lain diperlukan, secara kasar, sekali setahun, banyak startup mungkin tidak bertahan hidup. Oleh karena itu, proyek yang lebih sederhana dijelaskan - semakin baik, bagi banyak orang, Susunan Docker akan cukup.
Cakupan kode dengan uji unit
Antusiasme yang berlebihan untuk pengujian mengarah pada fakta bahwa sumber daya pengembangan yang berharga dihabiskan untuk hal ini, secara signifikan meningkatkan biaya refactoring (setelah semua, semua tes yang terkena dampak harus ditulis ulang) dan seringkali menciptakan ilusi kode yang dapat diandalkan dan operasi yang benar. Saya bertemu dengan startup di mana, setelah satu tahun pengembangan, lebih dari 2000 tes ditulis hanya untuk backend! Untuk bergerak maju secara efektif dalam pengembangan, tes harus mencakup hanya bagian yang sangat penting dari kode di mana beberapa perhitungan dilakukan dan diagnosis kesalahan manual sulit dilakukan. Seringkali, untuk pemula, cakupan pengujian dapat ditunda hingga struktur kode menjadi stabil, dan logika bisnis menjadi jelas dan tidak mungkin berubah secara signifikan. Untuk tes unit frontend, mereka sering tidak efektif, karena biasanya tidak ada perhitungan dan algoritma yang cukup kompleks, dan lebih baik untuk mencakup fungsionalitas SPA dasar seperti penekanan tombol selama fase pengujian BlackBox melalui Selenium atau sejenisnya.
Manajemen proses pengembangan
Kultus Cargo CTO selalu menggunakan alat-alat dan teknologi yang pernah bekerja untuknya sebelumnya, dia membaca sebelumnya tentang beberapa hal keren atau dia diberitahu tentang mereka. Penerapan semua ini dalam kondisi saat ini sulit baginya untuk mengevaluasi, jadi dia jelas mengikuti kanon kultus Cargo - "lagipula, pesawat terbang sebelumnya, jadi saya melakukannya dengan benar." Untuk meyakinkan CTO bahwa lebih baik menggunakan alat dan teknologi lain untuk proyek saat ini menjadi tugas yang sulit dan tidak sepele, karena CTO tidak digunakan untuk menganalisis konsekuensinya.
Manajemen tim
Ada satu cara untuk pemujaan Cargo, dan dia mengikutinya. Fakta bahwa manajemen tim perlu dibangun berdasarkan keadaan proyek saat ini, persyaratan, kualifikasi, dan batasannya dari kontraktor adalah hal baru baginya dan ia tidak mementingkan hal ini, karena ia berisiko tinggi sehingga ia tidak akan mampu mengatasinya. Tidak mudah baginya untuk mengakui bahwa harus ada sikap yang berbeda terhadap pengembang Senior dan Menengah, bahwa ada pengembang dengan spesialisasi dalam komunikasi, pendekatan bisnis, dan tanggung jawab. Baginya, semua bagian di papan catur hampir sama, ia bergerak hampir sama. Dia kemungkinan besar tidak mendengar tentang fakta bahwa perlu untuk mengidentifikasi dan menggunakan poin terkuat dari setiap pengembang. Karena itu, efisiensi kerja tim berkurang secara signifikan, para pengembang memperhatikan hal ini dengan sangat baik dan ini membuat mereka kurang puas dengan pekerjaan itu, biasanya ditandai dengan pergantian yang layak. Seringkali, CTO seperti itu mengatakan bahwa mereka memiliki segalanya - Pengembang Fullstack, meskipun secara pribadi saya jarang melihat yang sama kuatnya dengan backend dan backend, terlalu banyak teknologi yang perlu diketahui pada level yang baik.
Bagaimana tidak menjadi / tidak menjadi pemuja Cargo
- Selalu mengambil pendekatan kritis untuk memperkenalkan entitas baru (layanan, teknologi). Jika ada orang di tim Anda yang mengenal MySQL dengan baik tetapi belum bekerja dengan Postgres, maka tidak ada gunanya memilih Postgres jika ini tidak memberi Anda keuntungan yang signifikan.
- Proses pengembangan harus disesuaikan dengan tim dan bisnis. Jika Vasya bekerja pada Scrum dan mencakup semuanya dengan unit test, ini tidak berarti bahwa pendekatan ini juga cocok untuk Anda, Anda harus selalu mengevaluasi dan membandingkan secara kritis dengan opsi lain (Air Terjun). Sebagai aturan, apa yang bekerja untuk tim kecil berhenti bekerja untuk tim besar dan sebaliknya.
- Identifikasi kekuatan anggota tim dan gunakan secara maksimal. Ini akan meningkatkan efisiensi seluruh tim, dan karyawan akan lebih bahagia, karena mereka membawa lebih banyak manfaat dengan sedikit usaha.