Fallacy #10: The system is finished
Mari kita kembali flashback ke IT project.Hal ini biasanya dimulai dengan kalangan business memiliki ide dan kemudian datang ke developer untuk mengembangkan ide tersebut. Hal ini dimulai tentu saja dengan prototype dan kemudian business setuju agar sistem tersebut tidak akan di deploy di production. Tetapi hal ini tentu saja tidak dapat ditepati oleh business. Sistem kemudian go live dan kita tetap harus terus menambahkan sesuatu untuk requirement dari business.
Kemudian janji disusul dengan janji ke pada business dan semua menjadi sangat kompleks karena system tersebut menjadi tambal sulam dan tidak untuk production. Tetapi kita tidak diberikan kesempatan untuk melakukan rewrite, karena target date sudah ditentukan. Ketika business menyatakan project tersebut berhasil, maka anda akan melihat semua dosa yang anda lakukan pada project tersebut sudah melanggar software design yang baik dan benar.
Dan disitulah mulai kita akan melakukan maintenance terhadap project dan disitulah benar-benar kita berjuang untuk hal tersebut.
Sistem tidak pernah selesai, tetap saja ada refactoring yang harus dilakukan, restructuring, code review, penambahan fitur, isu scalability. Biaya yang dibutuhkan untuk maintenance biasanya jauh lebih besar dibandingkan dengan development cost yang ada. Dan hal tersebut akan menyebabkan software tersebut tidak dapat berinovasi lagi di kemudian hari. Biaya untuk memperbaiki dan skill yang diperlukan juga sangat besar.
Banyak orang salah strategy menempatkan orang-orang paling senior dan punya skill tinggi di software yang baru dibuat ketimbang di maintenance mode. Karena hal tersebut jauh lebih menyenangkan membangun sesuatu dari awal ketimbang memaintain software yang ditulis oleh orang lain.
Hal tersebut berkembang dan sampai pada satu waktu kita memutuskan untuk melakukan rewrite terhadap sistem yang lama.
Product berbeda dengan project karena product merupakan investasi long term.Ini adalah komitmen. Kita perlu memikirkan bahwa perubahan akan terjadi pada long term dan kita harus memberikan peluang untuk software tersebut dikembangkan dan diperbaiki. Kita harus lebih mengadopsi mental pembuatan product ketimbang project.
Anda tidak akan dapat masuk ke product jika tidak terbakar dulu di project. :) Organisasi hanya akan berubah perilakunya sebagai hasil dari kesalahan yang menimbulkan sakit yang luar biasa.
Project merupakan model yang buruk untuk software development. Tetapi product yang life time nya panjang akan menjadi investasi yang besar dan cocok diterapkan untuk software project.
Jadi bagaimana sebaiknya proses development yang baik ? Mari kita mulai bahas.
Business dan IT berinteraksi melalui hal yang kita sebut sebagai requirement. Business biasanya tidak memberikan kita requirement tetapi workaround. Ada sesuatu yang ingin business lakukan tetapi software tidak mengijinkannya sehingga business meminta perubahan sesuatu dan penambahan fitur. Jangan biarkan business melakukan design yang berorientasi terhadap data dan database. Business analyst harus menjadi jembatan bagi business dan IT.
Orang yang cocok pada posisi business analyst adalah orang-orang yang dapat menggali lebih dalam process business dan menemukan model yang lain untuk mengatasi kekurangan dari system. Sehingga business tidak lagi datang dengan work around tetapi solusi yang tepat. Business analyst bukan hanya sebagai penulis requirement tetapi pemberi solusi terhadap business. Bukan sebagai proxy atau pembawa pesan atau messanger.
Salah satu tools yang bagus adalah rapid protoytyping. Mungkin hal ini tidak terkesan agile untuk kita. Tetapi hal ini bekerja dengan sangat baik sekali jika kita ingin membangun suatu product. Hal ini dapat dilakukan dengan balsamic atau screen prototyping tools untuk menemukan permasalahan sebenarnya. Setelah kita menemukan X yang ingin dilakukan oleh IT. Kita harus mengerti WHY business menginginkan solusi tersebut. Hal tersebut tetap saja bukan menjadi requirement tetapi memberikan kita gambaran apa dan mengapa business menginginkan fitur tambahan tersebut.
Kita juga memiliki role lain yaitu Architect yang berfungsi memberikan estimasi terhadap business. Estimasi merupakan hal yang sulit dilakukan dan tidak banyak orang yang dapat melakukannya.
Estimasi adalah sesuatu yang dapat digambarkan sebagai berikut.
Jika diberikan team yang telah padu dan skill yang tepat dengan size S dan berdedikasi hanya untuk project tersebut ( tidak bekerja untuk yang lain ). Saya yakin C% pekerjaan tersebut akan selesai dalam range waktu T1 dan T2. Ini adalah probability. Estimasi memiliki range dan probability dari confidence level. Hal ini adalah sesuatu yang harus kita berikan sebagai architect dari suatu software. Hal tersebut menjadi komunikasi yang lebih baik antara business dan IT.
Setelah terjadi komunikasi tersebut maka Architect akan melakukan POC, analysis, implementation dan testing dan dan akan memberikan estimate yang baru. Negosiasi terjadi di estimasi dan ada production dan progress. Setelah business menerima estimate tersebut disitulah kita memiliki requirement.
Jika estimasi tersebut diterima maka komunikasi akan berlanjut ke project manager dan melakukan check terhadap priority yang telah disepakati untuk tahun tersebut. Project manager tidak akan menentukan tanggal deadline. Tetapi biarkan business yang memberikan prioritas terhadap pekerjaan dan requirement yang telah di sepakati sebelumnya. Apakah hal ini terlihat tidak agile ? Apakah anda mencium bau waterfall ?
Ini berfungsi memperbaiki kesalahan atau gap dalam komunikasi. Beberapa hal yang saya sampaikan tadi dapat terjadi secara parallel dan tidak berarti bahwa tim tidak bekerja melakukan apa-apa dalam proses negosiasi yang terjadi. Jadi 3 role tersebut hrus berkomunikasi dengan baik dengan business sehingga dapat menghasilakn software yang baik. Eksekusi project bisa dilakukan secara agile atau scrum atau apa yang anda inginkan. :)