Hal penting dan paling pertama yang dilakukan oleh development manager dalam sebuah projek IT adalah duduk bersama dengan pemilik proyek untuk memastikan kebutuhan yang diperlukan dalam produk IT tersebut. Jika langkah ini berhasil dilakukan (mendefinisikan kebutuhan dari produk IT) maka selanjutnya tim development akan dengan mudah bergerak dan ditinjau hasil pekerjaannya.

Kasus di atas adalah sebuah hal yang cukup klise tetapi sangat sulit untuk dilaksanakan. Dalam bidang IT, pembuatan apikasi di web, mobile, ataupun desktop diciptakan untuk memenuhi kebutuhan si pemakai, atau bisa menjadi inovasi yang menawarkan pemecahan masalah bagi si pengguna. Tapi… kadang kebutuhan yang didefinisikan di awal pembuatan aplikasi tidak diikuti atau bahkan tidak terdefinisikan secara pas. Sehingga banyak sekali produk yang gagal ataupun tidak dapat memenuhi kebutuhan dan memecahkan masalah si pengguna.

Ada beberapa faktor yang membuat hal di atas bisa terjadi, dan biasanya hal-hal ini sudah sering dirasakan oleh sebuah tim developer. Tapi.. Tetap cukup sulit untuk dihindari.

Faktor pertama adalah tidak cocoknya business requirements dan ekspektasi masing masing individu, baik dari si pemilik maupun dari tim itu sendiri. Adanya celah di antara tim mengenai gambaran produk akhir akan menjadi sebuah masalah tersendiri. Si A akan beranggapan bagiannya sangat baik dan sudah memenuhi requirment, tetapi si B beranggapan pekerjaan yang di lakukan si A masih jauh dari sempurna (menurut versi si B).

Hal ini bisa menimbulkan deadline projek yang ngaret, hilangnya kepercayaan antar tim ataupun dari si pemilik, serta yang paling parah adalah gagalnya aplikasi tersebut memenuhi kebutuhan atau memecahkan masalah si pengguna, dan malah merepotkan si pengguna dalam memanfaatkannya.

Faktor kedua adalah proses iterasi pengembangan aplikasi yang tidak berjalan. Bagi para pengembang aplikasi pastinya sering menagalami yang namanya “perpanjangan” waktu deadline alias pekerjaan tidak sesuai dengan deadline. Dan biasanya menurut para pengembang aplikasi hal itu cukup bisa dimaklumi dengan berbagai alasan. Tapi bagaimana jika si pengembang aplikasi itu mengalami pesawat yang delay? Pesan makanan tetapi terlambat di sajikan? Atau bagaimana kalau mereka kirim SMS tapi “telat” sampai ke nomor tujuan? Apakah bisa dimaklumi?

Deadline itu adalah sebuah hal yang kritikal dan harusnya dicapai sesuai target. Deadline adalah mengenai menyelesaikan pekerjaan tepat waktu. Nah.. biasanya banyaknya beban pekerjaan tidak sesuai dengan waktu yang diberikan. Kadang project manager kurang memperhatikan masalah iterasi pengembangan di awal. Dalam satu siklus biasanya langsung dijejali dengan fitur kompleks yang nantinya malah membuat produk versi awal tidak bisa diulas karena melebihi batas deadline. Mungkin lebih baik jika fungsi yang dibuat disederhanakan dan pada iterasi berikutnya baru disempurkanan. “Done is Better than Perfect”.

Kemudian, faktor terakhir menurut saya adalah dari masalah teknikal yaitu masalah clean code dan code reinvention. Kegagalan untuk mendaur ulang kode  yang sudah pernah dibuat, cukup cocok mendeskripsikan masalah ini.

Ada beberapa penemuan hebat dunia yang dibuat untuk memberikan solusi masalah ini :

• object-oriented languages
• component-based development
• service-oriented architecture (SOA)

Kesemua penemuan di atas diciptakan untuk satu tujuan utama: untuk membantu membuat kode yang bisa dipakai kembali untuk proyek/aplikasi berikutnya. Semakin banyak kode yang bisa dipakai kembali di sebuah tim/perusahaan, maka akan semakin efisien lah kerja mereka, dapat memangkas waktu kerja, sehingga kemungkinan tepat waktu untuk deadline juga bertambah. Begitu juga dengan proses modifikasi, pengembangan, fleksibilitas, serta penambahan pada suatu fitur akan terasa mudah dan terkontrol, baik di satu platform maupun beda platform.

Walupun 3 faktor di atas sangat sering kita dengar, nyatanya implementasinya bukanlah hal yang mudah. Maka tidak heran banyak produk IT yang gagal di pasaran. Hal semi teknis seperti ini sangat penting untuk diperhatikan, selain memperhatikan bagaiamana mendapat keuntungan dari produk IT. Karena percuma jika model bisnisnya sudah jadi tetapi masalah internal tim pengembangan kacau balau dan tidak memenuhi ekspektasi.

Jadi untuk para pengebang aplikasi, project manager, maupun programmer janganlah jatuh di lubang yang sama :)