Teknik Praktis Analisis Posted on : 2/26/2009 07:20:00 AM

Di Cinox Media Insani, kami sering 'berganti-ganti formasi' dalam setiap pengerjaan sebuah project. Kadang, setelah progress berjalan, developer kami perannya digantikan oleh developer kami yang lain. Hal ini sangat mudah dilakukan karena kami semua mempergunakan framework aplikasi yang sama, dan kami sudah memahami standarisasi code yang ditetapkan oleh perusahaan, juga kami sudah tau karakteristik coding masing-masing rekan yg duduk di samping kami.

Beberapa minggu belakangan, gw melihat sebuah 'potensi baru' dalam tim kami yang solid ini. Gw mo latihan switch-role ke definisi jenjang yang berbeda. Bukan substitusi antar coder, tapi substitusi di level query building, di level art-designing, dan di level architecting. Permasalahan umum-nya yg dihadapi, apakah ada standarisasi di aspek query building, art-designing, dan bahkan architecting? Bukankah hal-hal tersebut adalah aspek-aspek subyektif yang *so-pasti* berbeda klo ditangani oleh orang-orang yang berbeda?

Betul sekali.

Maksut gw sebenarnya bukan substitusi dalam arti di tengah2 permainan sang architect diganti ama architect lain. Bukan begitu. Tapi formasi tempur Cinox pada "starting line-up" nya utk posisi-posisi architect, query-builder, art-designer -- seyogyanya jangan melulu di-isi oleh orang-orang yang sama terus. Bosan. Gag ada variasi-nya. Jadi, maksut gw, substitusi di sini adalah memberikan kesempatan bagi bro-bro dan sis-sis Cinoxers yang lain untuk "ikut merasakan" gimana sengsara-nya jadi Software Architect, atau jadi Art-Designer, atau jadi Query Developer.

Oke, deal!

Project yang jadi 'kelinci percobaan' udah ditentukan. Yang dijadikan case-study adalah aplikasi manajemen penerimaan pajak daerah. Gw lirik-lirik dokumen output yg diharapkan, cukup simpel. Dan gw coba utk project ini, gw hibahkan role Software Architect ke Bro Ali Hanifa. Hehehe.. sekalian belajar buat dia. Udah selayaknya dia naik 'pangkat' jadi Programmer/Analyst mengingat potensi besar yang dia tunjukin "kadang-kadang" udah cukup bagus utk di-upgrade ke level selanjutnya.

Eh, tau-tau... selang beberapa hari setelah dia nyoba ngebikin Spesifikasi Aplikasi, nongol imel dari dia yang isinya *curhat* -- dia kebingungan. BINGOENG ABIEZZ mo mulai nge-trace dari mana, sementara apa yang dia dapat hanya satu bundel format reporting yang diberikan ama Dinas Pendapatan Daerah.

Terlalu raw. Terlalu mentah.

Akhirnya, gw coba share-share dikit tentang teknik praktis analisis sebagai berikut (gw co-pas aja dari imel yg gw tulis utk beliau via milis staff@cinox.co.id) :

Sebenarnya "merumuskan spec" dari data2 mentah seperti format laporan itu adalah fungsi dari Software Architect berpusing-pusing ria di awal. hehehe...

klo data mentah masih kurang menggambarkan requirements? yang (biasa gw) bisa lakukan adalah :

1. tanya ke marketing kita atau "penghubung kita" --> apa sih yg elo janji-in ke client? itu akan jadi patokan dasar pembuatan spec kita. Dokumen kontrak kerjasama sebenarnya harus diberikan ke SA (oke lah, silakan sensor bagian tentang nominal project) -- karena dari situ kita bisa dapatkan scope pekerjaan. Batasan, scope, sampai di garis mana seorang SA boleh berimajinasi tentang struktur aplikasi yg bakal dihasilkan. Jangan sampe, marketing bilang ke client "sampe pendataan pajak" -- eh si S.A. berfantasi sampe ke "Wikimapia untuk informasi subyek pajak secara GIS" hehehe... -- atau sebaliknya. Scope yang dijanjiin sampe di state ini, tp spec yang dibuat ngga nyampae ke sono. Ini berbahaya. Sangat berbahaya.
   
2. bikin prototype trus ajukan ke client, klo begini kurangnya di mana?
3. klo client abstain ato malah bingung dengan spec prototype, kita tanyakan penilaian spec kita ke orang lain yg lebih 'terampil' : pegawai-nya client. Soalnya kebanyakan client itu adalah top-management. Sedangkan kebanyakan aplikasi yg kita bikin itu adalah aplikasi yg bakal dikonsumsi ama level low-management.
4. bingung bikin prototype? pelajarin proposal dan spec orang. Google adalah sahabat Anda.
5. Juga cari referensi apakah ada produk opensource serupa yg pernah dibikin orang? ato walo gag opensource, ada gag produk orang yg ada live-demo-nya? SourceForge.Net adalah kekasih Anda utk urusan beginian..
   
6. baca-baca referensi non-teknis tentang kasus yg dihadapi itu banyak membantu pemahaman kita n mempengaruhi spec yg kita bikin. Misal : undang-undang perpajakan daerah, bacaan2 direktori pajak dari pajak.go.id, artikel2 di koran atau portal berita seputar pajak
7. dan cukup penting juga kita "berteman" ama orang2 yg bergumul dengan tema sistem yg mo kita kembangkan. Misal, gw : punya temen SMA yg skrg kerja di pajak, kerja di depkeu, yg dulu kuliah di FIA Negara atau Ekonomi -- obok2 Facebook & Friendster Anda utk mendapatkan contact teman2 lama Anda...
8. juga, cukup penting juga kita "berteman" ama sesama software developer yang mungkin pernah mbikin sistem/aplikasi serupa. Klo ini, Kaskus room 147, diskusiweb, dan milis-milis komunitas software developer adalah tempat yang tepat untuk scouting.
9. Pengalaman pribadi dalam bikin sistem serupa sebelumnya juga "sangat berharga bangedd" utk membentuk perspektif spec yang akan kita hasilkan.
   

begitulah bro... keep on rolling the eyes..

Untuk kasus aplikasi pajak daerah ini ini, mgkn bro Ali bisa bikin spec utk dinikmati ama Jeng Tika (query), Non Dety (desain), ama Suhu Dendie (coder) dengan berpatokan dari struktur-schema yang akan gw bikinkan. Tapi utk development-lifecycle yg bener, bikin spec IO ama bikin struktur-schema itu adalah responsibility dari SA secara keseluruhan --> karena dalam bikin IO n struktur itu dilakukan secara iteratif n bersamaan. Saling mengevaluasi satu sama lain.

gpp.. kita jadikan ini ajang buat belajar bareng aja.. -- siapatau ntar "dalam perjalanan" kita nge-development, kita bisa dapat pengalaman-pengalaman yg makin mematangkan perspektif kita tentang Software Engineering...

:-)

_______________________


Rizky Prihanto
Software Architect PT Cinox Media Insani