Manajer tanpa latar belakang teknis sering berpikir bahwa hal utama adalah menulis kerangka acuan terperinci untuk pengembang, dan setelah itu, yang tersisa hanyalah meminta mereka untuk memenuhi tenggat waktu dengan ketat. Ya, ini penting.
Selain deskripsi fungsionalitas, kerangka acuan harus menyertakan mock-up layar dengan desain yang telah selesai sepenuhnya dan teks dari semua pesan yang ditampilkan kepada pengguna karena merupakan ide yang buruk untuk menyerahkan desain dan copywrite ke pengembangan perangkat lunak. .
Tetapi yang terburuk, setelah mendiskusikan fungsionalitas dengan para pengembang, untuk mundur dan menunggu dengan tenang untuk hasilnya. Pengembangan perangkat lunak adalah proses yang berkelanjutan, dan Anda perlu memahami dengan jelas apa yang sedang Anda kerjakan saat ini dan apa yang tersisa untuk dilakukan. Semakin dalam Anda masuk ke dalam proses, semakin besar kemungkinan Anda akan menyadari ketika ada yang tidak beres.
Fokus pada Fungsi Utama
Bagaimana pencelupan semacam ini dapat membantu? Salah satu penyebab paling umum dari slippage tenggat waktu adalah kesulitan yang tidak terduga dalam mengimplementasikan fitur-fitur kecil dan tidak terlalu penting. Pengembang yang baik berusaha keras untuk membuat produk yang baik, yang berarti menerapkan semua elemen yang ditentukan dalam spesifikasi. Sebagai seorang ideologis produk, Anda dapat dan harus menghapus semua fitur minor dari rencana jika mulai memakan terlalu banyak waktu, yaitu lebih dari beberapa hari.
Jangan Tambahkan Tugas Baru Selama Pengembangan Perangkat Lunak
Setelah Anda membenamkan diri dalam proses pengembangan dan mendapatkan kesempatan untuk melihat hasil antara, Anda akan memiliki keinginan yang kuat untuk menambah dan mengubah fungsionalitas dengan cepat. Jangan pernah lakukan itu! Menambahkan dan memodifikasi persyaratan secara langsung adalah hambatan terbesar pada timeline pengembangan; fungsionalitas yang diimplementasikan sebagian jauh lebih sulit untuk diubah.
Dalam 95% kasus, lebih baik tetap dalam rencana awal dan menguji fitur baru yang dibuat pada pengguna langsung. Dan kemudian buat perubahan berdasarkan umpan balik.
Kontrol Upaya Pengembang
Seiring waktu, Anda akan memperkirakan berapa lama waktu yang dibutuhkan sebuah tugas, dan itu akan lebih akurat daripada tim pengembangan perangkat lunakhasil. Misalnya, fitur baru ditambahkan relatif cepat, sementara mendesain ulang fitur lama saat mengonversi data pengguna yang ada selalu lambat dan menyiksa. Belajar menyajikan tenggat waktu yang kurang lebih realistis tidak begitu sulit; lebih sulit untuk mempengaruhi mereka.
Perfeksionisme adalah kualitas psikologis yang membedakan pengembang yang baik dari yang buruk. Ini tidak hanya berlaku untuk layar dan tombol hasil yang terlihat, tetapi juga untuk implementasi internal produk, yaitu kode.
Misalnya, Anda perlu menambahkan mekanik tindakan bonus di halaman pembayaran. Pengembang yang baik akan dapat menerapkan dalam seminggu mekanisme yang mendukung tindakan apa pun yang dilakukan dari panel admin, dengan kondisi yang dapat disesuaikan, waktu, dan sebagainya.
Tetapi Anda memerlukan solusi cepat untuk meluncurkan promosi besok dan membuang kode itu selamanya seminggu kemudian. Anda perlu memahami komponen mana yang akan bertahan dalam produk Anda untuk waktu yang lama dan mana yang dapat diimplementasikan untuk tujuan sekali pakai dan mengomunikasikannya dengan jelas kepada tim pengembangan perangkat lunak.
Urutkan Tugas dan jangan Tetapkan Semuanya Sekaligus
Tugas tim pengembangan perangkat lunak dibagi menjadi besar (membuat fitur baru) dan kecil (memperbaiki formulir pendaftaran). Aturan umumnya adalah jangan pernah mengalihkan perhatian pengembang dari tugas besar untuk menyelesaikan tugas kecil, bahkan yang mendesak.
Beberapa profesional unik dapat bekerja secara efisien dalam mode seperti itu, tetapi sebagian besar pengembang secara drastis menurunkan produktivitas karena pergantian tugas yang konstan. Oleh karena itu, masuk akal untuk memiliki pergantian-pertama tugas yang sangat besar, kemudian satu minggu tugas-tugas kecil. Rekam tugas-tugas kecil saat muncul tetapi berikan kepada pengembangan perangkat lunak untuk memasukkannya ke dalam daftar saat iterasi atau rilis berikutnya direncanakan.
Setiap Pengembang Berbeda
Perbedaan kinerja antara pengembang individu bisa sangat besar. Misalnya, dalam beberapa penelitian, versi programmer terbaik dan terburuk dengan pengalaman yang kurang lebih sama berbeda sepuluh kali lipat.
Anda perlu memahami bahwa orang yang sama dapat menunjukkan kecepatan luar biasa pada tugas dalam satu paket (misalnya, ekstensi antarmuka) dan kecepatan sangat rendah pada tugas lain (tugas sisi server skala besar). Jadi setiap orang harus diberi tugas yang membuat mereka nyaman bekerja. Jika tidak, produktivitas akan turun.
Jadilah Asisten Pengembang
Suatu hal penting akan membantu Anda berbicara dalam bahasa yang sama dengan para pengembang. Kebanyakan orang teknis memiliki otak yang sangat terorganisir dan rasional; mereka masuk ke dalam skema logis. Tetapi skema ini tidak akan selalu nyaman bagi pengguna Anda.
Sebagai orang non-teknis, Anda memiliki keuntungan — lebih mudah bagi Anda untuk melampaui kerangka kerja yang disarankan oleh implementasi dan mengkomunikasikan visi yang tepat dengan pengembang. Tapi ingat: untuk menyampaikan sudut pandang Anda ke tim pengembangan perangkat lunak, Anda harus membuktikan ide Anda benar dengan argumen logis.
Sisihkan Waktu untuk Perubahan Internal
Anda harus ingat bahwa ada tugas yang memakan waktu yang tidak dapat Anda lihat dari luar dalam proyek apa pun, tetapi Anda harus melakukannya. Ini disebut utang teknis. Bagaimana itu terbentuk? Sambil menambahkan fitur baru, proyek ini memperoleh kruk dan alat peraga.
Banyak tugas diselesaikan dengan cepat tetapi dengan cara yang tidak dapat diandalkan. Misalnya, jika Anda tidak secara teratur mengatur kode Anda (proses ini disebut refactoring) dan tidak mengembangkan arsitektur proyek, Anda akan terus-menerus menumbuhkan kesalahan setelah beberapa waktu.
Mereka mungkin terjadi saat menambahkan fitur baru atau bahkan saat memperbaiki bug lama. Jika Anda tidak menghabiskan waktu mengembangkan arsitektur proyek, cepat atau lambat Anda tidak akan mampu mengatasi meningkatnya jumlah pengguna.
Tugas utang teknis perlu direncanakan dan dilaksanakan, tetapi bagaimana Anda menemukan keseimbangan yang tepat antara tugas tersebut dan pengembangan produk? Secara alami, fokus Anda sebagai penyandang dana dan orang non-teknis akan beralih ke fitur baru. Namun di sisi lain, pengembang cenderung memperbaiki kode yang ada tanpa henti dan kurang antusias dengan fungsionalitas baru.
Oleh karena itu, Anda masih harus, setidaknya pada tingkat dasar, memahami teknologi dan struktur produk Anda untuk menemukan keseimbangan dalam diskusi dengan pengembang. Tugas teknis harus menghabiskan sekitar 20% dari jam kerja tim pengembangan perangkat lunak dan sejalan dengan pengembangan fungsionalitas baru dan perbaikan bug.
Pelajari Tentang Teknologi
Untuk mengembangkan suatu produk, Anda harus mempelajari struktur dan teknologinya secara umum, setidaknya pada tingkat dasar. Ini penting karena teknologinya mungkin masih hidup tetapi tidak cukup cocok untuk tugas Anda. Dan seringkali tidak mungkin untuk mengetahui hal ini sebelum meluncurkan sistem dalam mode pertempuran — dengan pengguna nyata dan di bawah beban berat.
Singkatnya, Anda tetap tidak dapat melakukannya tanpa terjun dalam teknologi dan pengembangan perangkat lunak sebagai penyandang dana. Selain itu, pengetahuan ini akan memberi Anda pemahaman yang lebih baik tentang bagaimana proyek Anda berkembang.
