Tenggat waktu itu sendiri bukanlah hal yang buruk, saya bahkan akan mengatakan, di suatu tempat yang baik. Secara pribadi, pekerjaan saya menjadi lebih produktif jika saya secara mental fokus pada beberapa kerangka waktu, dan ketika sebuah proyek tidak memiliki kerangka waktu sama sekali, pada akhirnya hal itu dapat merugikannya. Hal utama di sini adalah berpikir realistis dan menjaga keseimbangan.
Tenggat waktu harus dijustifikasi. “Karena” bukanlah pembenaran. Ini adalah praktik pengaturan waktu yang buruk yang memengaruhi perusahaan dan pengembang. Saya beruntung karena sebagian besar perusahaan tempat saya bekerja tidak memiliki kebiasaan memilih tenggat waktu. Tapi ada pengecualian. Saya ingin berbicara tentang satu situasi seperti ini sebagai contoh dalam artikel ini.
Saya bekerja di sebuah startup saat itu; Tim front-end kami terdiri dari tiga orang, dan ada juga tim back-end dengan ukuran yang sama. Kami sedang mengerjakan versi terbaru dari aplikasi seluler dan harus memenuhi rilis sebelum hari yang ditandai dengan jelas. Satu masalah: hari ini dipilih secara sewenang-wenang baik oleh direktur sederhana, atau oleh seorang teknis tanpa alasan untuk keputusan seperti itu.
Artinya, tidak sepenuhnya tanpa pembenaran - ketika memilih hari, perkiraan durasi pekerjaan yang dinyatakan oleh pengembang diperhitungkan. Jika Anda bekerja dengan kode atau dengan orang yang menulisnya, maka Anda mungkin sudah mengerti apa masalahnya. Tanggal perkiraan selalu merupakan perkiraan, yaitu sangat berbeda dari yang sebenarnya keluar. Dan ini bukan tentang ketidakmampuan para pengembang, hanya sangat sulit untuk memperkirakan jumlah pekerjaan pada keseluruhan proyek. Ada banyak hal yang dapat mengubah tenggat waktu dan tidak mungkin untuk diprediksi.
Dengan satu atau lain cara, perkiraan kasar kami adalah hasil dari pertemuan dua hari: pertama, gambaran umum fungsi baru, kemudian analisis rinci masing-masing secara terpisah, kemudian analisis yang bahkan lebih rinci ... Akhirnya, untuk setiap tahap pekerjaan , kami memperkirakan jumlah jam, memeriksa ulang, berkorelasi dengan desain UX dan UI, mereka menggabungkan semuanya, menghabiskan beberapa jam di atasnya - dan itulah tenggat waktu untuk pekerjaan itu.
Anda mungkin sekarang berpikir: yah, karena desain UX dan UI mereka sudah siap, dan bahkan lebih banyak lagi waktu yang disiapkan, lalu, mungkin, semuanya akan baik-baik saja? Dalam kebanyakan kasus, kondisinya lebih buruk saat mengatur tanggal. Secara umum, tidak. Tidak ada yang baik-baik saja.
Durasi pengerjaan ditetapkan pada tiga hingga empat minggu - tidak terlalu lama jika kita berbicara tentang rilis produk baru dengan tim kecil. Tentu saja, setelah dua minggu pertama, kami sudah terlambat. Bukan karena mereka bekerja lambat atau menghabiskan beberapa jam pada proyek tersebut, tetapi karena semuanya selalu berjalan salah.
Backend sedang mempelajari implementasi API untuk aplikasi, ketika tiba-tiba ternyata sistem tidak dapat berinteraksi secara normal dengan add-on sederhana, yang berarti perlu menulis ulang fragmen API yang sudah disiapkan untuk mengambil keadaan ini. Akun. Butuh dua hari tak terjadwal untuk menyelesaikan titik akhir.
Karena perubahan kecil ini, API mulai bekerja sedikit berbeda dari yang dimaksudkan pada tahap diskusi, yang menyebabkan kebutuhan untuk menulis ulang bagian individu dari aplikasi - sebuah pekerjaan selama beberapa jam. Menulis ulang seperti ini biasa terjadi di aplikasi seluler dengan semua ukuran, dan seharusnya tidak mengejutkan siapa pun. Tetapi kami memiliki tenggat waktu yang ketat. Dan sekarang kami tidak bisa muat.
Jadi apa yang bisa kamu lakukan? Keesokan harinya, kami diberi tahu bahwa kami harus bekerja empat jam ekstra untuk bisa maju lagi. Empat jam di atas hari kerja delapan jam yang khas. Ya, kami diberi makan, tentu saja, tetapi tidak ada yang berguna bagi otak dalam shift dua belas jam seperti itu dan tidak mungkin. Namun demikian, kami berhasil mengejar ketinggalan dan mengikuti jadwal.
Seminggu kemudian, aplikasi tersebut dirilis. Kami senang, seseorang membawa beberapa cupcake untuk merayakannya, dan lima menit kemudian semua orang sudah duduk di depan monitor dan berpura-pura tidak ada yang terjadi.
Tidak ada yang begitu penting dalam pembaruan yang akan memotivasi perlunya rilis pada tanggal khusus ini dan tidak sehari kemudian. Tidak ada pengguna yang tahu bahwa versi baru sedang disiapkan, tidak ada (baik klien maupun investor) yang membuat rencana berdasarkan tanggal. Ya, fitur-fiturnya berguna, tetapi apakah ada yang akan merasa lebih buruk jika dirilis suatu hari nanti? Apakah itu akan mempengaruhi siapa pun?
Tapi pengembang terpengaruh. Di sana-sini orang menumpahkan ketidaksenangan mereka satu sama lain; hubungan antara tim dan manajemen jelas rusak. Dan ini bukan kasus tersendiri, ini sering terjadi saat saya bekerja di sana - dengan frekuensi sekitar sekali dalam beberapa bulan.
Dan apa kesimpulan dari semua ini? Menyerah sepenuhnya kapan saja? Tentu tidak. Seperti yang disebutkan di awal artikel, tenggat waktu sebenarnya berguna, dan saya sendiri merasa lebih mudah untuk bekerja dengannya. Tapi itu harus diambil sebagai pedoman, bukan sebagai komitmen yang kaku. Jika produk keluar beberapa hari kemudian, itu seharusnya tidak dianggap sebagai akhir dunia. Apa gunanya memberikan tekanan yang tidak perlu pada pengembang? Atau apakah menurut Anda kualitas kode tidak terpengaruh oleh pawai seperti itu?
Ketika kami berolahraga beberapa jam tambahan setelah hari kerja larut malam di bawah panji-panji force majeure, suasana umumnya adalah: "Jadi, kami harus menyelesaikannya secepat mungkin." Seringkali, segala macam solusi kruk diperkenalkan yang akan berfungsi untuk sementara waktu, dan kemudian memerlukan refactoring. Dalam beberapa kasus, pemfaktoran ulang terkait segera dijadwalkan, dalam kasus lain itu dilupakan dengan aman. Dan kebetulan para pengembang sendiri tidak benar-benar menyadari bahwa mereka melakukan sesuatu yang penopang, karena mereka lelah dan ingin pulang.
Ketika datang ke refactoring (di mana asalnya), itu mungkin lebih merupakan sumber daya daripada force majeure itu sendiri. Bug mulai muncul dalam potongan kode yang ditulis dengan tergesa-gesa. Karena aplikasinya telah dirilis, hal itu membuat semua orang gelisah terutama.
Menurut perkiraan saya (saya tidak mengumpulkan statistik, jadi saya tidak dapat menjamin), pemrosesan ini hanya berguna dalam jangka pendek. Ya, kami merilis aplikasi tepat waktu. Dan rilis berikutnya sudah harus ditunda, karena banyak yang sedang ditulis ulang. Para pengembang tidak senang (dan, Anda dapat menebaknya, mereka secara aktif berhenti), suasana di tim menjadi tegang. Dan kami masih belum memperhitungkan konsekuensi dari bug yang ditemui pengguna setelah rilis.
Bagaimana Anda membutuhkannya?
Jika Anda ingin semuanya dilakukan secara efisien, jangan terburu-buru, dengarkan pengembangnya dan pastikan untuk melacak kemajuannya. Jika tim tidak fit dan tidak ada alasan untuk mendesak, pindahkan tenggat waktu! Bukan sembarangan, tapi untuk waktu itu tidak cukup pada tahap saat ini. Mendorong pengembang untuk mengomunikasikan kemungkinan penyebab penundaan dan risiko. Jika seseorang melihat sesuatu yang jelas tidak sesuai dengan jadwal umum, ada baiknya menarik perhatian orang yang berencana, sehingga dia memiliki kesempatan untuk mengoreksi tanggal perkiraan.
Apakah Anda melakukan semuanya sebelumnya? Nah, dalam situasi seperti itu, semua orang hanya menang. Dan pengujian dapat dilakukan dengan baik, dan memberikan kesempatan kepada pengembang untuk meningkatkan sesuatu di basis kode. Jika Anda seorang pengembang atau berkomunikasi dengan pengembang untuk bekerja, maka Anda sendiri tahu: selalu ada tempat dalam kode yang ingin Anda perkencangkan. Terkadang hanya butuh satu jam dan terkadang butuh beberapa hari. Lebih baik tidak membuang waktu untuk membuat kode lebih baik dan lebih akurat - seperti yang dapat kami konfirmasikan, ada cukup banyak kekurangan dalam aplikasi yang tidak akan dihargai oleh pengguna mana pun.