Ya, judulnya memang “The End”, tapi ditambahi dengan tanda tanya. Apa maksudnya? Mungkin memang sudah berakhir, tapi saya sendiri bingung bagaimana mengakhirinya dengan baik dan indah. Dan saya juga nggak ngerti apa ini memang benar-benar berakhir, atau sebuah awal yang baru. Kalo memang akhir, ya akhir yang melenceng dari harapan sih, dengan “sedikit” rasa sakit di hati. Haha.

Mungkin memang benar kata seorang teman, terlalu dekat juga kadang nggak baik. Karena kedekatan itu, saya jadi tahu kalau dia sedang suka sama seseorang, dan sepertinya sudah jadian. Sayangnya saya nggak kenal siapa orang itu, tapi sepertinya mereka suka sama suka. Ya sudahlah, hak asasi setiap orang untuk mencintai orang lain. Dengan kondisi seperti ini, saya cuma bisa mendoakan bahwa pilihan dia itu yang terbaik, dan harus lebih baik dari saya, setidaknya untuk hatinya. Hm, ini sih balik lagi ke masalah ikhlas yang dulu pernah saya post.

Bingung? Sangat.
Sedih? Iya donk.
Sakit? Pasti.
Kecewa? Lumayan lah.
Kesepian? Rasanya bakal gitu.
Kehilangan? Nggak usah ditanya.
Putus asa sampe bunuh diri? Ups, ya jangan lah. Hidup adalah anugerah dari Allah YME. Jangan disia-siakan hanya karena salah satu makhluk ciptaannya.

Fyuh, untungnya kalau sekarang saya lebih bisa mensyukuri hidup. Saya masih punya keluarga yang sayang sama saya, masih punya teman-teman yang dukung saya, masih punya mimicreative yang jadi masa depan saya, masih punya band tempat meluapkan emosi, masih punya laptop tempat mengungkapkan semuanya, masih punya gitar teman bersenandung, dan saya masih punya impian yang panjang. Beda dengan yang dulu itu, waktu saya masih memikirkan diri sendiri saja.

Yang harus saya lakukan saat ini adalah ikhlas dan mengambil pelajaran dari semua yang sudah saya lewati. Yang baik ditingkatkan, yang buruk jangan diulangi lagi. Salah satu kebodohan terbesar saya adalah terlalu ingin tahu. Seperti kata seseorang, semakin ingin tahu, maka akan semakin nggak tahu apa-apa. Dan ternyata benar-benar terbukti. Meski saya nggak bener-bener ngerti maksud kata-kata itu apa.

Ngomong-ngomong ikhlas, jadi inget lagunya Bondan neh.

Saat kau berharap, keramahan cinta… Tak pernah kau dapat, ya sudahlah…

Yah, mungkin nantinya kita berdua bakal tetap dekat, entah dengan status apa. Yang pasti saya masih sayang dia.

Kalo udah gini, cuma bisa nyanyi ini neh.

Beri sedikit waktu, biar cinta datang karena telah terbiasa… huwooo…

Oke, berarti mungkin inilah post terakhir tentang Ice Queen. Setelah ini, nggak akan ada lagi post dengan tag Ice Queen, gak ada lagi hashtag #theicy di twitter, gak ada lagi kangen-kangenan di plurk, apalagi status di FB yang semakin membosankan. Saya cuma bisa bilang terima kasih kepada semua pihak yang telah membantu saya selama ini. Tapi kalo masih ada yang pingin bantu buat saya bisa lebih deket dengan Ice Queen, ya saya malah sangat berterima kasih. Sapa tahu masih bisa lanjut. Haha. Ya kita lihat ntar aja deh. Siapa tahu bisa membaik lagi.

Hidup baru sudah menunggu, saatnya melakukan pencarian lagi. Semoga ketemu yang lebih baik lagi. Hayok bangkit Haqqi!!! Semangat!!! Ayo, ayo, cewek-cewek cakep. Ada cowok jomblo keren neh. Hahaha…

Post ini adalah lanjutan dari seri sebelumnya. Pinginnya sih bikin post lebih banyak lagi tentang masa menganggur di sana, tapi ternyata nggak jadi. Sebelumya saya cerita bahwa saya akan ikut dalam project SAP di semen gresik, tentunya dengan berbagai pertimbangan. Pertimbangan pertama, SAP adalah software ERP yang cukup besar. Hanya dengan “bisa” saja menggunakan SAP itu, dan sedikit pembuatan modul, “harga” saya bisa menjadi cukup mahal. Kedua, dengan anggapan tanpa dasar, uang saku PKL di semen gresik rasanya cukup tinggi. Di pemikiran kami, at least 500rb lah. Kalo jadi 3 bulan, berarti kan bisa dapat 1,5 juta. Lumayan buat jajan. Pertimbangan ketiga, dengan banyak berinteraksi dengan senior-senior IT, pasti kemampuan saya bakal meningkat. Meski sedikit meleset dari apa yang ingin saya konsentrasikan. Yah, banyak lah pertimbangan lain yang membuat kami, terutama saya, memutuskan untuk perpanjangan PKL dengan join ke project ERP.

Eh tapi eh tapi, keputusan saya berubah.

Suatu ketika, seperti janji, saya diajak ke gedung project SAP oleh kabag sana. Karena gak ada kendaraan, kita bareng pak kabag, naek mobil dinasnya yang plat W. Oke, sampai di sana, saya dikenal-kenalkan ke tiap ruangan. Berasa artis aja neh. Tapi yang paling menjengkelkan, kita dikenalkan sambil beliau bilang, “ini loh, ada mahasisa ITS pingin belajar dan gabung di SAP”. Whuaat?? Ma Chung pak, kami dari Ma Chung. Tapi ya tetep aja, setelah dikasih tahu ya bilangnya masih anak ITS. Ya sudahlah.

Kita berempat dimasukkan ke suatu ruang rapat, di divisi control. Disuruh duduk dulu, sementara beliau bilang kalau mau ke Surabaya dulu. Wogh, okeh. Awalnya saya semangat, siapa tahu bisa nyerap ilmu di ruang rapat itu. Tapi…

Duduk di ruang rapat itu membosankan. Satu orang ngomong apa, saya nggak ngerti maksudnya. Orang yang lain menanggapi, tambah bingung lagi saya. Lha dari awal memang belum ada dasar SAP sama sekali, tiba-tiba langsung masuk implementasi yang notabene udah berjalan beberapa minggu. Celakanya, di sana saya gak bawa laptop. Kalau mau balik ke gedung utama, jaraknya lumayan jauh dan sanggup membuat kaki jadi keriting.

Intinya, hari itu serba gak jelas deh. Nganggur-nganggur gimana gitu. Untungnya waktu siang dikasih makan. Sorenya baru balik bareng mobil pak kabag lagi.

Ya, ketidakjelasan saya kalau masuk di project SAP itu salah satu pertimbangan yang mengubah keputusan saya. Pertimbangan kedua, gak terlalu penting sih. Tapi layak untuk diceritakan.

Waktu mau jumatan, saya ketemu teman saya SMA di pinggir jalan. Saya tanya dia darimana, eh katanya habis ngumpulin laporan PKL di semen gresik. Ternyata dia sudah lebih dulu PKL. Iseng-iseng saya tanya uang saku yang dikasih semen gresik. Dan dia jawab, “mek 100 ewu”. Whuuuaat!!! Lha ntar 3 bulan berarti cuma 300rb. Nyaris buang-buang waktu donk. Mesti belajar SAP dari nol, tapi secara finansial gak didukung. Weleh, mendingan di rumah ae nulis artikel majalah, bisa dapet lebih banyak. Bisa memanfaatkan waktu untuk belajar yang lain juga.

Hem, oke deh. Akhirnya kita semua ambil keputusan untuk nggak lanjut 3 bulan. Cukup 1 bulan saja, sesuai kesepakatan awal.

Karena nggak jadi join project SAP, apa yang kita lakukan?

Kita masuk kantor jam 8. Kita datang, ngucapin selamat pagi ke orang yang ada di kantor (kalo ketemu). Jalan ke tempat duduk, buka laptop, pasang charger, duduk nunggu booting, connect wifi, internetan. Jam 12 istirahat, cari makan, sholat, balik ke kantor jam 1. Di kantor duduk lagi, buka laptop lagi, internetan lagi, sampe pulang. So, apa yang kita lakukan? NGANGGUR JAYA!!

Ada banyak alasan kenapa kita nganggur. Yang pertama, jelas karena kita sendiri ngerasa males. Bukan cuma males sih, ada kerjaan pribadi juga yang mengharuskan duduk diam di depan laptop. Yang kedua, di sana memang masa-masa sibuk. Project SAP sedang gencar digarap. Jadi orang-orang kantor sering menghilang, sibuk sendiri. Lah kalo gini gimana mau tanya-tanya. Kalo waktu sibuk gini, jadi sungkan. Alhasil, ya itu. Kita gak dapat apa-apa.

Buat saya sih, nggak terlalu masalah. Karena saya jadi punya waktu untuk nyelesein artikel dan project Mimi Creative yang pertama, GEPUKEK.com. Ada banyak hal yang bisa saya lakukan kalo saya punya waktu luang itu.

Hari demi hari berlalu seperti biasa. Datang, duduk, internetan, makan, internetan lagi, pulang. Sampe kosan, kalo gak capek ya lanjut kerja, capek ya tidur. Selesai. Itu aja yang kami lakukan sebulan ini, dari 1 Juni sampe 30 Juni 2010. Kita bener-bener gak dapat apa-apa. Padahal dosen pembimbing saya termasuk cukup strict soal laporan ini. Wah, kita baru gopoh beberapa hari terakhir. Padahal pembimbing lapangan udah janji mau dampingi, eh ternyata dia lagi keluar kota. Terpaksa cuma tanya-tanya sekedarnya, tentang Wireless-nya semen gresik.

Fyuh, 30 Juni kemarin adalah hari terakhir, dan saya menginjakkan kaki lagi di kota Malang yang sejuk pada tanggal 1 Juli 2010. Tapi sekarang saya bener-bener bingung, GIMANA INI LAPORAN PKL-NYA NTAR?!?!?!?!?

Sekarang jamannya berwirausaha. Dimana-mana ada seminar tentang bikin usaha sendiri. Kampus-kampus yang mengedepankan pengajaran entrepreneurship juga semakin banyak bermunculan. Yah, salah satunya memang kampus saya sih. Usaha yang mau dilakukan bisa berbagai macam. Dari makanan sampai alat berat juga bisa. Saat ini, makanan memang masih menjadi ladang wirausaha yang menjamin. Gimana gak menjamin, setiap manusia kan butuh makan. Setiap ada acara makan-makan, pasti lebih milih ke rumah makan atau manggil catering biar gak repot. Akhirnya, semakin berjayalah para entrepreneur bidang makanan. Tapi kalo nggak benar-benar punya skill masak, atau benar-benar bermodal untuk bayar tukang masak yang bagus, ya tetep aja repot.

Bidang lain yang cukup “berladang” saat ini adalah dunia Teknologi Informasi. Blogging, online shop, main-main di forum, online writer, dan sebagainya menjadi kegiatan yang bisa menghasilkan uang. Buat yang mau benar-benar freelancer, bisa masuk ke getafreelancer.com. Buat yang mau jualan, juga banyak tempatnya. Yang mau produksi, bisa bikin theme atau program-program yang disebarin lewat internet. Cloud application berbasis servis juga semakin marak beredar.

Seberapa besar sih peluang sukses untuk berjuang di dunia Teknologi Informasi?

Bisa dibilang sangat besar, bisa dibilang sangat kecil. Tergantung dimana Anda bermain, dan seberapa keras usaha Anda. Oke, saya akan lihat diri saya sendiri sebagai perbandingan. Saya bukan orang berduit. Juga bukan orang yang benar-benar ahli dalam hal tertentu. Bahasa Java? Pas-pasan. PHP? Apalagi. Bahasa yang lain malah belum nyoba.

Saya pernah mendengar opini dosen saya, yang lebih suka “bermain” di low level. Beliau berniat untuk melakukan sesuatu yang jarang dilakukan orang lain. Ya, beliau mengembangkan suatu bahasa pemrogramannya sendiri. Tanya kenapa? Ternyata salah satu alasan beliau adalah di bidang itu akan lebih mudah untuk bersinar, karena saingannya sedikit. Memang benar sih, ya karena pasarnya sendiri juga sedikit. Gak tau lagi deh.

Kalau pingin bermain di ranah yang lebih atas, sebut saja bikin software. Nah, software sendiri itu luas. Nggak ada orang biasa yang sebodoh-bodohnya mau ngembangin search engine tanpa ada dukungan kuat dari sebuah perusahaan. Siapa sekarang yang bisa menyaingi Google? Bing aja yang notabene milik perusahaan besar Micr*soft susah payah mau ngejar. Jelas itu bukan pilihan yang baik.

Tunggu-tunggu, dari yang saya bahas secara singkat di atas, sudah jelas ada parameter penting untuk sukses di dunia IT. Yup, saingan. Dengan banyaknya saingan, akan semakin susah untuk bersinar, seperti kata dosen saya itu. Apalagi untuk main di level atas.

Mau main di dunia per-template-an website? Memang pasarnya besar. Banyak yang butuh website setiap harinya. Tapi, yang mengejar peluang ini juga banyak, dan nggak tanggung-tanggung. Banyak expert yang gila di luar sana. Lihat source code buatannya aja, gak kebayang gimana proses saya mengejar ilmunya. Sementara teknologi di dunia IT terus berkembang, saya mesti mengejar dengan beban yang lebih dari mereka. Bisa nggak ya?

Mau main di dunia sistem informasi? Lagi-lagi peluang yang sama besar, tapi juga banyak saingannya. Banyak yang menguasai seputar ilmu sistem informasi. Dengan dasar yang kurang kuat sebagai mahasiswa S1 ini, sulit rasanya ngejar software house yang sudah berpengalaman. Perjuangan yang berat.

Mau ikut kerja di software house orang? Itu sih namanya bukan entrepreneur. Akhirnya malah jadi kuli aja. Dengar cerita-cerita programmer yang kerja di orang lain, bilangnya mereka serasa jadi kuli. Hm, susah juga ya. Terus gimana?

Nah, saya sebagai mahasiswa Teknik Informatika juga pingin bikin usaha sendiri. Pinginnya setelah lulus bukan bekerja sama orang, tapi sudah mempekerjakan orang. Memang sih banyak saingan dan perlu perjuangan keras. Saya juga nggak mungkin cuma kerja sendiri. Tapi semua harus dimulai dari sekarang Untung ada beberapa teman yang mau diajak sama-sama kerja bakti di awal untuk merintis sebuah usaha di bidang Teknologi Informasi. Thanks buat Davied dan Alex. Mari kita lanjutkan perjuangan kita!!! Meski masih sebuah mimpi, tapi suatu saat pasti jadi kenyataan. Haha.

Sudah semester 6 nih. Sebentar lagi akan beranjak keluar dari kampus, alias lulus. Tapi sebelum itu, ada proses yang harus dilewati untuk mencapai kelulusan itu. Yup, apalagi kalau bukan skripsi atau tugas akhir.

Sampai detik ini, sebenarnya saya masih bingung mau berkonsentrasi di bidang apa di dunia IT ini. Sebab ada banyak sekali hal yang ingin saya pelajari dan kuasai. Tapi lagi-lagi, katanya skripsi harus fokus. Padahal belajar coding aja masih belum fokus.

Untuk dunia programming, saya sudah memutuskan untuk mempelajari dan fokus pada 2 bahasa ini saja, yaitu Java dan PHP. Kenapa Java? Karena dari awal memang bahasa ini sangat sesuai dengan pola pikir otak saya. Begitu OOP, MVC, dan segala hal tentang modularitas. Awalnya sih cuma pingin konsentrasi di Java ini saja. Tapi karena terkendala dengan resource, akhirnya juga belajar PHP, meskipun nggak dari nol, demi memenuhi permintaan pasar akan website sederhana. Tapi ternyata jatuh cinta juga dengan bahasa ini.

Sementara ini, untuk Java sedang istirahat karena lagi bingung mau ngapain. Untuk PHP, sedang saya lanjutkan karena saya sedang ingin bikin framework sendiri pakai CodeIgniter dan Doctrine, beserta library modular-nya. Memang sih, ini didasari juga karena saya sedang merintis sebuah usaha di bidang web developing. Yang penting tetap mengasyikkan lah untuk dikerjakan.

Selain itu, saat ini saya juga tertarik dengan apa yang disebut IT Project Management. Saya juga sudah join milisnya. Ternyata ada banyak yang harus diatur dalam mengerjakan sebuah project IT. Memang awal saya tahu tentang version control bukan dari sini, tapi dari seorang developer game engine java. Tapi saya jadi tahu kalau ternyata ada yang lebih hebat dari subversion melalui milis ini. Benar-benar bermanfaat loh join milis-milis kayak gini. Bisa tanya-tanya secara gratis pula ke orang yang sudah berpengalaman.

Nah, kembali ke masalah konsentrasi. Sekarang ini, apa yang saya gemari berbeda jauh dengan gambaran saya dulu. Dulu saya kepikiran untuk memperdalam AI, atau game development. Tapi ternyata, AI begitu ruwetnya dan harus kembali belajar matematika dan kalkulus. Untuk game development, masih belum jelas konsentrasi yang berhubungan dengan pendidikan itu apa. Masa depan game development juga nggak selebar web development, meski mungkin hasilnya akan lebih kelihatan kalau jadi. Akhirnya, saya jadi bingung sendiri deh.

Karena sementara ini saya tertarik dengan manajemen proyek IT, saya pikir saya harus meneliti tentang ini. Tapi apa yang harus diteliti? Saya tanya-tanya di milis jawabannya juga masih belum jelas. Padahal, senin ini saya harus sudah membuat sebuah pendahuluan proposal skripsi untuk tugas salah satu mata kuliah. Huft. Ada yang punya ide?

Rasanya, saya masih harus meraba-raba lagi nih. Lihat temen-temen di jurusan lain, sudah pada bikin pendahuluan skripsi. Padahal saya menentukan topik aja belum. Repot juga yah. Nggak terasa sudah semester 6.

Dekat-dekat ini, saya rasa saya akan lebih konsentrasi ke usaha saya. Sambil mencoba membuat framework sendiri untuk kecepatan kerja tim saya. Kuliah aja terasa banget kalau nggak saya perhatikan lagi. Akhirnya nilai-nilai saya jadi jelek-jelek. Nggak masalah lah. Yang penting enjoy.

Mungkin di post berikutnya saya akan publish tentang tutorial CodeIgniter dan Doctrine, dalam proses pembuatan framework saya. Happy reading.

Posting ini adalah copas dari rangkuman salah satu topik hangat di milis JUG Indonesia yang dikemas Bung Ifnu di blognya. Sebenarnya sayalah topic starternya di milis. Sebagai gambaran, dengan ikutan milis ini, saya jadi banyak menerima masukan dan sharing dari programmer-programmer berpengalaman. Terima kasih semuanya. Mungkin style tulisan ini juga nggak terlalu bagus karena format number dan bullet-nya nggak saya betulkan saking banyaknya. Tapi kalo Anda memang niat baca, pasti akan dapat banyak ilmu di sini. Selamat membaca.

Beberapa hari ini ada diskusi seru di milis JUG-indonesia, ada salah satu member JUG yang bertanya bagaimana membuat software house dan melakukan pembagian kerja. Dari satu posting berkembang menjadi panjang lebar sampai puluhan email dalam thread ini. Saya tergelitik untuk merangkup thread tersebut menjadi satu sesi QA agar lebih terurut informasinya.

Nah silahkan menyimak serunya thread ini.

—

Q : Ada yang bisa share gak gimana SOP dari software house tempat teman-teman? Gimana workflow-nya, dan pembagian tugasnya. Kapan sih orang management dan akuntansi dilibatkan dalam project?

A : Kalo di kantor, qta ada 1 orang head developer, dia yang me-manage proyek dari awal sampe akhir. Ada 1 orang analis + desainer aplikasi (database + modul2), trus ada programmer, trus ada tester/qc

Kalo dulu kerja bareng sama temen, kita bagi2 tugas siapa yang analisis + desain DB, sapa yang bikin SP, Trigger, View, sapa yang bikin front end.

A : Life Cycle project itu kira-kira gini :

1. Cari kabar dimana ada yang perlu aplikasi
2. Kalau ada, janjian untuk mendengarkan requirement
3. Menunjukkan bahwa anda bisa mengerjakan aplikasi sesuai requirement. Caranya :
- paling gampang tunjukkan portofolio aplikasi yang pernah dibikin
- Paling efektif tunjukkan produk yang sesuai dengan requirement(ini agak sedikit mustahil)
- Presentasikan kembali requirement dalam bahasa yang sedikit lebih teknis
- Presentasikan SDLC dan proses pengembangan aplikasi di perusahaan anda. Gimana requirement gathering, prototyping, demo sampai ke user acceptance test (UAT). Trus garansi, change request management.
4. Biasanya point 2 dan 3 bisa dalam satu sesi meeting, tapi lebih sering sesi 3 dilaksanakan beberapa hari setelah sesi 2
5. Setelah point 3 disetujui biasanya sih ada proses nego harga dan termin pembayaran. Usahakan di termin pembayaran ada DP dan ada step2 pembayaran yang berdurasi pendek, misalnya setiap satu modul selesai dibayar sekian persenya.
6. kalau deal baru mulai developmet.
7. Requirement gathering dengan mewawancara client dan user yang akan menggunakan aplikasinya. Kemudian minta segala macem form, data, dokumen yang di print beserta semua dokumen bisnis.
8. Mulai develop
9. Demo setiap modul, jangan sampai demo di akhir saja untuk semua modul, kalau ada perubahan bisa berdarah2. Release often release fast.
10. Sign off modul yang udah disetujui, minta dibayar
11. Implementasi, biasanya ada proses migrasi data dari sistem lama atau dari excell kalau masih manual.
12. Bug fix dan maintenance
13. closing
14. makan2, jangan lupa saya ditraktir

Kalau saran saya sih ya, daripada memulai usaha menjadi software consultant mending mulai usaha untuk bikin web 2.0 service, kalau belum bisa secanggih facebook ya bikin seperti kaskus aja tuh, simple aja, install vbuletin . Atau bikin produk seperti accurate, zahir
dan software untuk pendidikan

Software consultant yang 100% bergantung kepada project base itu sangat rentan, model bisnisnya nggak survive, karena semua usaha kita ujung-ujungnya hanya menghasilkan upah, artinya kita jadi kuli aja. Berbeda halnya kalau km bikin produk, nanti kalau produknya sudah mapan, income tidak lagi bergantung pada berapa baris kode yang kita buat tapi berapa banyak lisensi yang kita buat. Nah kelihatan kan bedanya? kalau konsultant kita dibayar karena keringat yang kita keluarkan, tapi kalau bikin produk ya yang “nyari duit” produk kita.

Jadi jerih payah kita terakumulasi ke produk tersebut, nggak bayar lepas seperti project . Saya lihat bisnis model seperti ini cukup
terbuka dengan adanya apple app store, bikin aplikasi kecil2 dijual $1, sebulan kejual 600 buah aja udah cukup lah ya

Model bisnis lain yang cukup bagus adalah membuat “service” yang banyak digunakan orang dan bisa kita jual ke pengiklan, seperti detik.com, kaskus.us, indowebster.com dll. Kelemahanya ya butuh investor sih, harus ada yang bayarin bandwith, infrastruktur dll. Di US sana ada ycombinator.com/faq.html yang mau nalangin, di indonesia sih blom ada sepertinya .

Bisa juga model bisnis “komisi per transaksi” seperti ATM bersama, atau bikin software loket pembayaran PLN, atau bikin marketplace yang
transaksinya dikenakan fee.

Bisnis model yang bagus tapi agak susah diimplementasikan adalah software as service (SAS) dengan model subscription, untuk mendapatkan layanan dari aplikasi tersebut, customer perlu membayar sekian rupiah per satuan waktu (bulan, tahun). Di indonesia yang sudah jalan sepertinya http://www.asianbrain.com, cuman lebih ke jualan konten dibanding jualan layanan software. Di luar sana yang terkenal ya salesforce.com, google application, http://www.fogcreek.com/FogBUGZ/. Bayarnya per user

A : Pembagian perand dalam tim pengembangan perangkat lunak :
1. Tukang nanyain user apa yang mau dibikin
2. Tukang coding level jago, supaya bikinnya gak sembarangan
3. Tukang coding level pemula, supaya ada yang disuruh2 bagian coding yang boring seperti validasi, geser2 tombol, pasang icon, dsb
4. Tukang ngetes
5. Tukang ngurusin hal2 lain supaya tukang no. 1 sampe 4 bisa kerja dengan nyaman Misalnya: reimburse taksi, janjian meeting sama client, laporan progress ke client dan ke bos, cari pengganti kalo ada yang sakit/resign/cuti/dipecat, mengucapkan, “You’re fired” kalo ada yang gak bener
6. Tukang tagih invoice kalau sudah tiba masanya

Versi keren :
1. Business Analyst
2. Software Architect
3. Programmer
4. Tester
5. Project Manager
6. Biasanya sih dikerjain sama no. 5 juga

A : Kalo pengalamannya nol semua rada ribet ya… kalo mau n niat, bisa bikin pake tipe prototipe.
1. Tentuin mo bikin apa, scopenya sampe mana.
2. Kumpulin requirementsnya
3. Desain aplikasi + bikin prototipe
4. Menta komentar dari user, biasanya di sini user bikin ribet, ada requirements yang sebelomnya diomongin tau2 ada. Hal2 gaib terjadi di sini, makanya siapin dokumentasi requirements.
5. balik ke nomer 3, kalo user setuju, aplikasi di deliver.

Kalo ada waktu n produknya umum, aplikasi bisa dikembangin sendiri n disempurnakan. Yang mesti diinget :
1. Siap2 cape n makan ati, maklum soalnya starter…
2. Jangan mikirin duitnya dulu, tapi pengalaman, produk, sama relasi dulu.
3. Komitmen tiap2 individu agar “perusahaan” jalan.
4. Profesionalitas, bedakan urusan teman sama pekerjaan.

Q : Nah, apa di software house itu ada semacam SOP tertulis, tentang pembagian kerja atau sebagainya? Bagaimana struktur businessnya? Kapan bagian management atau akuntansi ikut gabung?

A : Tergantung software housenya.

Kalau balicamp/sigma setahuku sudah menerapkan CMMi yang mendefinisikan berbagai macam dokumen yang harus dibuat dalam satu project. SOP dan resource management dijelaskan dengan tegas. Tapi kalau software house semacam yang kecil-kecil sih biasanya masih cowboy belum ada process yang jelas, SOP dan dokumen. Paling sih ada template bikin proposal, form untuk requirement, form untuk change request, berita acara UAT / testing, Invoice untuk nagih. Kayaknya udah cukup segitu.

Orang accounting sama management gak dilibatkan dalam project. Paling cuma nanya2 doank tentang konsep accounting, malah kadang2 kita diajarin sama usernya. Kalau buku besar ini begini tablenya, jurnal AR dan AP begini begitu dst.

Kalau di operasional perusahaan biasanya ada bagian administrasi perusahaan yang ngurusi accounting, awal2 cukup pekerjakan lulusan SMK saja untuk membuat dokumen2 di atas.

Q : Trus gimana menentukan lamanya waktu pengerjaan sebuah software misalkan membuat software accounting atau CBI?

A : Ada beberapa cara untuk menentukan project estimation
1. Cara kasar : tentukan deadline berdasarkan kebutuhan bisnis, misalnya: PT A akan memulai usahanya pada juli bulan ini, maka aplikasi harus selesau bulan juni. Pokoknya aplikasi harus selesai,
2. Cara Marketing : Ikut tender, terus dengarkan tim lain presentasi, hitung waktu penyelesaianya kirakira 40% lebih cepat dibanding pesaing. Kalau pesaing bilang 5 bulan, ya kita bilang 3 bulan ).
3. Cara logis : Tentukan kapan deadlinenya, kemudian tentukan feature apa yang diperlukan agar aplikasi Accounting bisa berjalan. Kemudian bentuk tim, training tim, setup teknologinya. Lalu bersama-sama dengan tim estimasi setiap feature berapa lama bisa dikerjakan. Kalau timnya berisi programmer berpengalaman dan pernah terlibat project development aplikasi serupa, peluang estimasi akurat bisa cukup tinggi, kalau semuanya belum pernah membuat aplikasi tersebut ya coba tanya sama yang pernah bikin, kalau ada yang nggak tanya ya pura2 jadi mama laurent trus cari hari baik untuk deadline

Kalkulasi estimasi project bisa ditentukan dengan berbagai teknik ada yang dihitung berdasarkan table, banyak kolom, banyaknya screen, export-import modul, banyaknya report. Bisa menggunakan semacam poin untuk setiap item yang dihitung. Kemudian dibandingkan dengan history pengerjaan aplikasi, misalnya setelah dirata2 kecepatan pembuatan aplikasi ternyata 3 feature point per orang per hari, trus dari perhitungan feature point dari aplikasi dihasilkan 3000 feature point. Mandaysnya : 3000/3 = 1000 mandays, dikerjakan 5 orang jadinya 200 hari

A : Estimasi pada intinya dibagi menjadi beberapa tahap :
1. Estimasi dulu seberapa besar aplikasi yang akan dibuat. Ada beberapa satuan yang umum digunakan untuk mengukur besarnya aplikasi, diantaranya Function Point dan Line of Code (LOC) LOC lebih akurat, tapi sulit diestimasi di awal project. FP lebih mudah, karena berkaitan langsung dengan requirement.

2. Setelah didapat besarnya aplikasi, estimasi effortnya. Berapa manday yang dibutuhkan untuk menyelesaikan. Perusahaan berpengalaman dan rajin ngumpulin data seperti Balicamp biasanya sudah punya data historis tentang kemampuan pasukannya. Satu FP bisa diselesaikan berapa manday. Nah dengan data ini, tinggal dibagi aja, berapa FP jadinya berapa manday.

3. Setelah manday didapat, estimasi durasi. Durasi adalah jumlah hari kalender untuk membuat aplikasi, satuannya hari kerja. Apa bedanya effort dan durasi? Misalnya satu fitur effortnya 8 manday. Ini belum tentu selesai dalam 1 hari. Mungkin saja durasinya bisa 4 hari, sbb :
2 jam meeting dengan client 2 jam coding.
2 hari clientnya lagi sibuk, sehingga gak bisa ngetes
2 jam UAT, dapat 10 bug
1 hari programmer mules-mules, gak bisa coding.
2 jam fixing
Total effort 8 jam, tapi durasi jadi 5 hari karena ada 2 hari nungguin user dan 1 hari programmer murus.

4. Setelah durasi dapat, baru bisa hitung cost. Misalnya durasi 4 bulan, berarti 4 kali gajian programmer, PM, tester, dsb. Kalo nyebrang lebaran, hitung juga THR, sehingga cost nambah.

Itu sederhananya. Mau yang rumit dan penuh jargon? Coba google function point calculation, wideband delphi, cocomo, planning game. Kalo saya sih yang gampang2 aja dan minim hype. Estimasi itu sederhana, tapi tidak mudah, karena butuh experience.

A : Klo ginian, enaknya dilihat dulu kapasitas team internal-nya spt apa. Maksud saya sih gini, coba lihat 1 orang itu sanggup bikin 1 screen CRUD standart + UI n DB validation brp jam. Nah dr situ dilihat kira2x brp form yg dibutuhin, trs hitung dengan cara yg udah dipaparin ama mas Ifnu. Nah masalah dr ngitung berdasarkan kompleksitas screen ini timbul klo misalkan client ga ada aplikasi sebelum-nya (manual abis, masih pakai excel) Nah klo udah masuk masalah ini, tergantung PM-nya gmn. Soalnya kadang-2x dr UI yg udah dibuat, ketika deliver iterasi 1 eh user-nya ngomong wah nih UI koq susah banget yah, klo diganti gmn ?? (gubrak ~_~’) Gmn cara ngitung-nya klo spt ini ^_^

A : Kalo soal screen design mah harusnya udah di waktu UReq dong, Khan dari requirement kita kasi mock up screen nya kayak apa, Lalu kalo di setujui, ntar kita estimate, bikin screen gituh bisa berapa lama, Nah kadang… consultant company is banking on the user to change their mind :p

Hahahaha
Believe me…
Jadi gitu user minta ganti UI… that’s it!
Time frame nya udah bisa di nego ulang… asal project nya udah di tangan toh?

Satu hal lagi, Buat management, 3000 feature point dengan 30 programmer jadi dalam 100 hari. Tapi apakah 3000 feature point dengan 60 programmer bisa jadi dalan 50 hari? Hal ini yang selalu bikin susah nih…

Q : Seberapa pentingnya kah orang yang benar-benar background marketing di software house?
Lebih menghasilkan mana, marketing online atau offline??

A : Kalau belum bisa gaji orang marketing, mending dikerjakan sendiri.

Kalau di perusahaan2 kecil marketing ini ibarat jantungnya software consulting, ngebul apa nggak dapur tergantung project yang diperoleh marketing.

Kalau masih pure tukang jait dan belum punya keunggulan kompetitif selain harga yang murah, sepertinya offline dengan pendekatan person to person lebih gampang. Kalau online lebih enak punya keunggulan kompetitif, misalnya punya nama yang dah dikenal banyak orang.

Offline dan online juga tergantung bussiness yang mau digarap. Kalau client besar seperti banking, telco, oil & gas dan pertambangan sepertinya lebih pendekatan ke personal. Masalahnya di industri ini cuma cukup untuk pemain-pemain besar saja, perusahaan masih baru mulai sih mana dipercaya.

Kalau mau mulai paling gampang nih, jadi sub kontraktor pengadaan software pemerintah . Ini project paling gampang, tapi paling berdarah2. Requirement tidak jelas, termin pembayaran tidak jelas, belum tentu aplikasi digunakan, dst dst.

Pikir-pikir dulu kalau mau bikin software consulting. Lebih enak kalau kerja dulu dan melihat industri apa yang bisa digarap. Kecuali km gak jadi consulting tapi bikin produk/service/framework dll

A : ArtiVisi udah jalan 3 tahun, tanpa ada orang ber-background marketing maupun orang yang dedicated untuk marketing. Nyatanya kita survive, project sih ada aja. Nah, kalo gitu penting gak marketing?

Menurut saya, reputasi lebih penting.

Q : Screen design dilakukan pada waktu UReq dan menghasilkan mock up screen, kalo di setujui, ntar kita estimate, bikin screen gituh bisa berapa lama. Proses ini biasanya software udah deal apa belum ya? sign kontrak dst?

A : Belom dong…
Khan biasa nya step nya tuh die undang buat presentation… Lalu di jelasin scope dasar nya… Ini masi blur nih.. tapi karna udah ada gambaran nya khan at least kita udah bisa sketch gambar screen.. Nothing fancy.. nothing written on stone… Cuma kayak.. kalo mo load data.. pasti ada search screen dulu.. search screen nya di kasi criteria Cuma yang wildcard searchable.. di taro di tengah… Ntar ada border warna biru …

Gitu2 ajah… Kalo udah ada patokan ini khan udah ada screen mock up.. Semua search screen akan kliatan seperti ini… Tapi kalo tiba2 user nya mau ganti… Gak gini deh.. mau nya pake pop-up search.. Lah ya bongkar toh? Ini lho maksud gue… Kalo udah beres screen mock up nya.. Tar kita kasi proposal. Tampilan nya gimana.. Feature2 yang bisa kita throw in apa ajah.. Time line nya berapa lama.. Harga nya berapa.. Assumptions nya apa ajah.. Report nya bisa apa ajah.. Mesin nya musti apa ajah..

Lalu baru di seleksi lagi.. terakhir baru harga.. Nah ideal nya khan semua udah ada waktu nya.. Kayak tiba2 udah mau deliver.. user nya minta.. wah.. report ginian gak ada nih.. minta dong.. Lah ya kalo Cuma 1-2 ya gpp..(mungkin) tapi kalo minta 30-40 report?

Q : Pernah coba terapkan agile methodology? user bisa mengerti methodology ini gak sih?

A : Sayang nya selama ini client2 gue kagak mau ngerti segala methodology ginian.. U give the timeline, and I expect a stable product by that date.. That’s it..

Hahahaha
Ya gue mah..lu neken gue teken balik…
Gak bole meleset ya lu gak bole banyak minta.. :p hahahaha

Q : Kalau semuanya masih mahasiswa dan belum pernah sama sekali masuk software house, ada saran ?

A : Disclaimer :
Tidak bermaksud meruntuhkan semangat ataupun psywar bagi calon kompetitor ;p

Untuk bisa mendeliver sebuah aplikasi berkualitas production, sangat sulit. Apalagi kalo timnya semua fresh graduate, gak ada yang experienced.

Sebagai gambaran, Martinus bikin aplikasi kasir, Point of Sale, itu cuma 2 hari sudah komplit fiturnya, lengkap dengan print ke dot matrix. Tapi dari situ sampe aplikasi implement dan go live, butuh 3 minggu.

Pesan moralnya, deliver software jauh lebih banyak dari sekedar coding. Ada tarik-tarikan fitur/change, implementasi, training user, nagih invoice, dan urusan non teknis lainnya.

Coding itu sangat gampang, apalagi aplikasi bisnis. Paling cuma insert update delete database, nothing new. Yang sulit itu :
- estimasi nilai project : butuh pengalaman
- menggali requirement di awal dengan lengkap supaya di belakang gak banyak hidden feature : butuh pengalaman
- mendesain aplikasi supaya adaptif terhadap perubahan : butuh jam terbang
- menerapkan change procedure supaya project tidak melebar : butuh skill negosiasi yang didapat dari pengalaman

Satu lagi, kalo core businessnya project, siap2 puasa berbulan-bulan. Cashflow perusahaan berbasis project sangat unpredictable. Bisa-bisa 4 bulan baru turun 1 termin. Nah selama itu biaya operasional dari mana?

Jadi, apa rekomendasi saya? Kerja dulu di software house yang sudah mapan dengan tujuan sbb :
- belajar siklus mulai dari sales sampe project closing
- memperluas wawasan business process, misalnya akunting, procurement, dsb
- memperdalam kebijaksanaan dalam mendesain software
- menabung uang untuk modal bikin perusahaan
- menabung relasi untuk modal bikin perusahaan
- menabung reputasi biar gampang dapet orderan

Nanti setelah 2 – 3 tahun kerja, udah tau project dari kepala sampe buntut, baru deh bikin sendiri.

Hmm … jadi ingat thread sebelah tentang lulusan IT ;p

Coba baca ini dulu :

http://endy.artivisi.com/blog/life/pengetahuan-wajib-buat-programmer/

Kalo mau buka software house, harus bisa solve problem, bukan cuma bisa coding.

Q : Nah, muncul satu lagi pertanyaan. Ntar yang bagian hubungan sama user, seberapa jauh harus mengerti teknis program yang kita buat?

Yang jelas harus ngerti bisnis process, dan ngerti behavior aplikasi yang dibuat. Jadi kalo user punya skenario, misalnya, gimana caranya kalo saya ada diskon dari supplier? Implementor bisa menjelaskan cara aplikasi mengakomodasinya. Bagian mana yang harus dikonfigurasi.

Q : Oia, untuk project management, tanya nih. Software apa saja yang bagus n gratisan yang untuk:
- project manager (misal: MS Project untuk yang punya mikocok)
- uml designer (power designer kan bayar)
- dll yang perlu lagi untuk software house ?

A : Uml jarang dperlukan. Ms project dipake tim yg ada Pm-nya, nggak ada manfaat praktis ke developer. Yg penting tools itu versioning sistem spt subversion trus issue tracker spt trac atau redmine. Kl 2 itu dipake bnyak bantu developer.

klo emang ingin kerja tim, siapkan build tool yg bisa ngurusin smua secara otomatis + nanganin masalah dependencies library Nah enaknya lagi, di java ada 2 tool yg keren yaitu :
- Apache Ant (Automatic build tool, didlm ini jg bisa ditambahin custom task utk kepentingan smua team)
- Apache Ant + Ivy ( Jika digabung ama ivy, bisa automatic dependencies resolution )
- Apache Maven (Udah nge-cover smua yg disebutin diatas )

Nah pilih salah 1 aja Btw meskipun hal diatas ini kelihatan-nya sepele, tapi pengetahuan tool2x diatas diperlukan biar lebih nyaman klo mau beruusan ama subversion, release dan yg terkait dng versi aplikasi

A : Hmm… biasanya sih kita gak pake aplikasi Gantt chart model ginian. Berdasarkan pengalaman, aplikasi Gantt chart seperti ini kurang praktis. Soalnya kita jadi banyak berkutat mikirin dependensi antar task. Padahal task di software development itu sangat dinamis.

Planning dan tracking di ArtiVisi tidak kompleks. Kita ngikutin fitur yang disediakan trac. Cuma ada milestone dan task. Milestone bisa dikasi tanggal deadline Satu milestone terdiri dari banyak task. Yang manapun task yang dikerjakan duluan tidak masalah.

UML juga tools yang kita gak pake. Mau presentasi class diagram ke siapa? Di ArtiVisi, karena client kita kebanyakan adalah end-user, kita tidak mendiskusikan hal2 teknis dengan client. Kita mau pakai surrogate atau natural key, client tidak perlu mikir. Kita mau pakai 1 tabel atau 10 tabel, bukan urusan client. Kita dibayar karena kita experienced dan bisa mengambil keputusan sendiri berkaitan dengan internal teknologi yang kita gunakan. So, ngapain lagi ngerecoki user dengan urusan jeroan?

Kita diskusi aplikasi dengan client menggunakan prototype UI. Kalo desktop, bikin pakai Swing, kalo web, ya langsung HTMLnya. Client memutuskan what to be built, kita memikirkan how to build.

Tools yang perlu lagi untuk software house :
- version control (kita pakai Subversion)
- Issue/task tracker, lebih sipp kalo ada version control browsernya (kita pakai Trac)
- IDE (kita pakai Netbeans)
- Skype, kita pake fitur share screennya, sangat berguna untuk remote discussion
- Aplikasi Email (Gmail sudah cukup, personally saya pakai TB)
- YM client

Intinya: stay simple, supaya bisa fokus ke kerjaan, bukan tools.

A : UML itu sepengalaman saya cocok digunakan untuk dokumentasi teknik yang dimengerti oleh developer, sedangkan user sebenarnya tidak mengerti UML, kecuali usernya mengerti IT. Kasus user yang mengerti IT biasanya terjadi di project2 besar, sedangkan project web application, POS atau apliksi transaksi kecil hingga sedang tidak perlu UML. Malah lebih berguna Entity Relation Diagram (ERD).

User yang mengerti IT pun kalau berasal dari lingkungan nonOOP juga tidak familiar dengan UML.

Q : kalau mau manage project bareng-bareng, enak jelasin ke programmernya pake uml. Tentunya pake narasi di diagramnya. begitu ?

Ini adalah sesuatu yang mudah diucapkan tapi sulit dilakukan. Yang namanya programmer, akan lebih memilih coding daripada bikin UML. Soalnya dia akan mikir, daripada bikin UML lama, akan lebih cepat kalau langsung dicoding. Dan jangan lupa, sesuatu yang dibuat harus dimaintain. Class diagram sih bisa direverse engineer biar tetap up to date, tapi narasinya?

ERD juga sesuatu yang kita gak pake. Gimana cara kita bikin diagram skema database? Bikin dulu aplikasinya, setelah selesai reverse engineer pakai Netbeans.

Kalau sesuatu terdengar indah di kuliah, belum tentu applicable di real project.

ERD, UML, kedengarannya keren dan mudah, kalau class/tabelnya < 10 Di aplikasi nyata, class biasanya > 100 dan tabel biasanya > 20. User management aja sudah 7 tabel sendiri : user, group, user_group, permission, group_permission, user_session, user_preference.

UML tidak hanya class diagram. Yang lainnya adalah :
- Use Case Diagram : kayaknya terlalu simplistik untuk menjelaskan business process.
- Activity Diagram : ok lah ini mungkin bermanfaat untuk menjelaskanflow, sama aja kayak flowchart
- State Diagram : jarang dipakai kecuali untuk sesuatu yang state berubah misalnya status Order.
- Sequence Diagram : definetely for programmer, melihat invocation stack.

Saya gak bilang UML bad, crap, useless atau apa. Cuma gini aja, UML itu kan cara berkomunikasi. Jadi mau dipakai atau tidak ya tergantung pihak-pihak yang terlibat. Selama ini komunikasi kita lebih efektif dengan prototype screen, ya itu yang kita gunakan.

A : Gua juga pernah mau pakai UML sampai capai-capai baca beberapa buku. Terus latihan. Tapi ujung-ujungnya nggak kepakai. User lebih mengerti narasi dalam bentuk tulisan atau screen mock-up. Kalau menurut gua UML itu berguna sih tapi untuk skala proyek tertentu yang amat besar kalau menurut skala Indonesia. Untuk skala proyek normal di Indonesia UML adalah “overkill”/terlalu berlebihan.

Q : Gimana cara kita bikin diagram skema database?

A : Diagram ERD di kantor saya juga ga dipake, bukan ga mau ngikutin standar, tapi gmana cara bikin ERD untuk 35-40 database, tiap database > 100 tabel & > 50 view, tiap tabel/view kebanyakan > 20 field? Kita bikin desain tabel pake fasilitas diagram punya SQL Server 2000/2005.

Kalo saya dari sisi programmer keluarga DFD, ngeliat aplikasi itu berdasarkan fitur dan data. Fitur yang user mau apa? Data yang mo ditampilin apa? Data yang diinput apa? Nah dari situ baru bikin desain fitur, desain database, dll dsb sampe terakhir coding. Kalo coding dulu baru desain database terakhir ngikutin maunya program bakal lebih ribet pengembangan kedepannya.

A : Klo di tempat saya, urusan database pake ERWIN Data Modeller, support cukup banyak RDBMS. Disana bisa dipecah-pecah berdasarkan subject area, cuma ya ada kemudahan, ya ada harga.

Jadi biar ada 1000 tabel pun, bisa dikelompokkan berdasarkan subject area. Manfaatnya dapat semua:
- Dokumentasi database
- Reverse / Forward Engineering
- dan mendukung semua fitur database yang disupport.

Ini yang paling basic dulu sih, semua kembali pada kedisplinan dan toleransi yang mengerjakan proyek. Klo gak disiplin jg bakal susah implementasi semua SOP Kerja yang ada, dan kembali ke dunia primitif.

Q : Yang namanya programmer, akan lebih memilih coding daripada bikin UML. Soalnya dia akan mikir, daripada bikin UML lama, akan lebih cepat kalau langsung dicoding. begitu?

A : Maaf kalo saya bilang ini programmer belom pengalaman megang aplikasi besar. Programmer yang pengalaman, dia bakal desain dulu aplikasinya ntar kaya gmana, butuh apa aja (fitur2nya), ada modul apa aja, hubungan antar modul gmana, data yang dibutuhin apa aja, nampilin data apa aja, desain databasenya gmana, kemungkinan evolusi aplikasi ke depannya gmana, permasalahan umum lainnya apa, dsb. Setelah desain udah jadi, baru coding. Kalo programmer yang langsung maen coding aja tanpa bikin desain, jamin deh dimasa depan pas pengembangan aplikasi (tambah fitur, tambah modul, integrasi modul lain) pasti lebih kelimpungan daripada yang desainnya udah bagus.

A : Hmm.. saya tidak sepenuhnya setuju dengan yang diatas. Di company tempat saya sekarang aplikasi yang dibangun rata2 semuanya kompleks. Tapi di sini gak terpaku pada design formal (ada diagram pun paling oret oret di kertas ato gambar pake power point saja). System yang rumit2 aja docsnya gak perlu sebanyak yang diminta dosen saya waktu jaman mata kuliah Software Engineering.

Menurut saya kalo design yang sampai mendetail itu cocoknya kalau polanya system architect mendesign untuk “dijahit” oleh programmer, maka perlu design yang detail. Di tempat kami programmer semuanya tipe2 yang engineer, jadi design sendiri, coding sendiri, kadang2 konsultasi dengan rekan2, jadi design yang diperlukan cuma garis besarnya saja kira2 programnya mau dibuat bagaimana, sisanya improvisasi dipikir sambil dicoding.

Maintenance hell? Nggak juga, menurut saya malah lebih “agile” dari yang pakai SDLC tradisional – asalkan codingannya bagus dan kebaca, gak perlu design doc yang njelimet koq.

Design database? Kalau buat saya sih baca ERD sama baca schema (dengan asumsi schemanya rapi buatnya), gak banyak bedanya. Jadi perlu ERD kalau mau dikomunikasikan dengan client, dokumentasi, etc. saja. Jangan malah jadi “beban” karena merasa “wajib” buat diagram ini itu.

Jadi menurut saya, design kadang2 perlu, tapi nggak perlu yang extreme2 amat kecuali kalau mau dideliver ke pihak luar.

A : Perhatikan perbedaan antara *tidak melakukan desain* dan *tidak membuat dokumen desain* Yang saya bilang di atas, saya tidak bikin UML, DFD, ERD, and whatever dokumen desain yang orang lain biasa bikin. Lalu apa saya tidak melakukan desain? Tidak juga. Saat ini di ArtiVisi, yang biasanya mendesain aplikasi saya dan Martinus.

Gini cara kerjanya.
1. Analisa UI prototype (kami tidak membuat SRS, URS, atau whatever *RS)
2. Tentukan tabel dan relasi (biasanya pada tahap ini cuma nama tabel, PK, dan FK) Ini tidak pakai tools apa2, cukup kertas dan pulpen.
3. Jalankan test scenario untuk berbagai variasi use case menggunakan sampel data sederhana, lihat apakah semua use case, baik untuk saat ini ataupun ke depan, sudah bisa terakomodasi oleh tabel dan relasi.
4. Revisi desain sesuai feedback dari step #3.
5. Repeat until done.
6. Setelah dirasa memuaskan, langsung coding domain class berikut relasinya (@Entity, @ManyToOne, @OneToMany, dsb)
7. Commit, kemudian buang kertasnya, pulpennya jangan.

Lalu apa kami sama sekali tidak pernah bikin gambar skema pakai tools? Pernah juga kadang2. Biasanya teman saya suka minta pendapat saya, atau saya pengen review skema yang dibikin Martinus. Gimana caranya? Generate dulu database pakai hbm2ddl, kemudian reverse engineer jadi diagram pakai whatever tools yang tersedia. Kalo gak ada tools, pakai ini aja http://teethgrinder.co.uk/database-diagram/ Martinus kirim png ke saya. Saya komentar, kalo ada revisi langsung edit domain model. Regenerate png.

So, skema database itu dibuat secara reverse engineer, untuk keperluan komunikasi. Begitu selesai, ya dibuang aja itu gambarnya, toh kalo perlu bisa dibikin lagi dengan mudah. Kalo perlu, generate pakai Ant aja dan masukkan ke build process.

Inilah interpretasi kami terhadap prinsip “the source code is the documentation” yang dianut Agile.

Kita tidak menganut pendekatan arsitek bikin gambar, programmer coding. Soalnya software itu dinamis, kalau desainnya pakai dokumen rigid semacam MS Word,nanti capek maintainnya. Kalo tiap nambah field, refactor nama tabel, add/remove relasi harus edit *doc, jaminan gak bakal dikerjain. Sudah jadi human nature males ngerjain gitu2an.

Jadi gini, dokumen itu ada untuk 2 purpose : komunikasi dan dokumentasi. Komunikasi itu untuk ngobrol sama orang lain. Dokumentasi itu untuk meringkas informasi biar gak harus ngetrace source code.

Yang untuk komunikasi, kita generate on demand. Abis komunikasi selesai ya dibuang, gak dimaintain.

Yang untuk dokumentasi, dibikin belakangan, setelah semua coding selesai. Kalo dibikin di depan, repot maintainnya, karena source code belum stabil. Masih banyak refactoring. Idealnya, setelah go live baru bikin dokumentasi. Jadi gak banyak rework. Tapi karena berhubungan dengan invoice, bisa juga dibuat pas UAT dimana perubahan sudah tidak signifikan lagi.

Sekali lagi, gak bikin dokumen desain bukan berarti tidak melakukan desain.

Nah sekarang, yang pada bikin ERD, DFD, UML, saya mau tanya? Kenapa Anda bikin diagram itu? Why? Asal ada manfaatnya no problem. Tapi kalo karena disuruh bos, di kuliah gitu, di buku dianjurkan demikian, think again. Apa gak sebaiknya masa remaja digunakan untuk hal2 yang lebih bermanfaat?

Akhirnya saya penasaran sendiri apa bisa diautomate, jadi saya google dan dapat ini : http://schemaspy.sourceforge.net/

Bisa tuh dari Ant/Maven :
ant generate-skema-db

A : Yg ini bener banget neh.. kebanyakan kerjaan gw cuciin piring orang laen, jadi mana ada dokumentasi UML,ERD atau apapun juga.. Kalo gw milih dokumentasiin itu semua, bisa ga kelar-kelar kerjaan dan kehilangan pekerjaan gw.

Kalo menurut gw seh daripada pusing ngurusin UML dan segala macemnya itu lebih bagus belajar design pattern dulu dah. Buat make library dan mempelajari framework yang baru itu gampang, yg susah itu nerapin design pattern yang bagus buat applikasi kita. Kalo udah capek-capek bikin UML tapi design pattern nya ga diterapin juga pasti di jamin dalam pengembangan applikasinya nanti itu kelimpungan juga. yah kayanya emang UML lebih cocok untuk menjadi alat komunikasi antar programmer aja deh..

Gw bayangin presentasiin itu uml ke client gw Bisa di ketawain + di goblok-goblokin + di keluarin Undang-undang garuda tuh.. Mana mo tau mereka urusan begituan.. Client butuh solusi bukan gambar-gambar gituan..

Kesimpulan
K : baru baca thread ini, sop di software house. tp jadinya menarik bahan diskusinya

ada beberapa hal menarik disini, seperti sharing dari Bung Ifma, dan Endy bagaimana mereka menerapkan development process di artivisi, menurut saya itu bagus banget dimana kita harus melihat skala perusahaan dan success level untuk menjadi sebuah result oriented company. tapi memang akan kurang cantik kelihatannya dari sisi documentation, inget technical team hate documentation, jadi rule of the gamenya sah2 aja.

Cerita Adelwin, ureq di indo jika bisa seindah itu…. gw demen banget deh. sayang sepanjang experience di project, belum pernah seindah itu, walaupun bisa sih di manage supaya ontime, tapi balik lagi, kemampuan business analyst, and project manager penting banget dalam hal ini.

about UML and development ini menarik banget untuk saya… karena saya sendiri berangkat dari dunia developer dan analyst dalam bekerja saat ini.

Dalam dunia development banyak yang menggunakan UML sebagai design and documentation. pake use case, class diagram, sequence dan activity diagram. di tempat saya sendiri bekerja saat ini, saya menggunakan UML terutama class diagram sebagai acuan dasar, karena saya menggunakan Model Driven Architecture. dimana class diagram sebagai design dasar untuk pengembangan application. klo ditanya kenapa sih butuh class diagram, kebetulan project kami menggunakan sekitar 200-400 domain model bahkan ada class yang memiliki attribute hingga 200, jadi tools cukup membantu dalam hal ini.

Tapi ada hal yang menarik mengenai diagram lain, seperti usecase dan sequence diagram. dimana diagram2 lain ini dapat dengan mudah digantikan oleh oret2 pencil, powerpoint, prototype maupun user stories. kebetulan sempat menggunakan 2 cara yang agak berbeda dalam menyampaikan apa yang harus dikerjakan developer :
satu team, selalu menggunakan use case scenario lengkap, prototype, hasilnya… programmer kesannya jadi jauh lebih manja, bahkan kemampuan analisa dan logika programmer kurang terasa.
di team yang lain, kita mencoba menggunakan oret2 pencil, prototype atau simple scenario dapat juga verbal aja. hasilnya perkembangan developer yang ada, di team ini jauh lebih significant, kemampuan terhadap analisa dan logika lebih baik bahkan mereka tahu apa yang sebenarnya diminta oleh customer. Selain isu sense yang dimiliki oleh programmer bahwa mereka lebih berkembang dan tidak bosan dengan aktivitas mereka jauh lebih bagus dibandingkan dengan team yang lain.

Jadi ini lebih kelihat sebagai dinamika team dalam software development

K : Wowowow.. ternyata topik ini jadi panjang juga yah. sebagai TS, saya harus berterima kasih nih, banyak ilmu dan pendapat yang saya bisa ambil dari sini.

Saya memang newbie sih, belum pernah bikin aplikasi besar. Mungkin bagi yang sudah berpengalaman kayak om Endy, UML itu sudah nggak ada apa-apanya karena proses desain udah manteb di otak, tanpa perlu divisualisasikan. Itu juga dipengaruhi tingkat kerjasama tim dan pengalaman tim itu sendiri.

Tapi bagi saya yang jadi pemimpin tim programmer saya, saya masih perlu UML untuk menyampaikan desain aplikasi saya ke teman-teman. sebenarnya agak susah juga, karena semua harus dipikir di awal, agar nggak banyak perubahan seperti yang om Endy bilang. Tapi memang, efeknya ada bagusnya juga. Pengerjaan jadi lebih cepat karena si programmer nggak perlu susah-susah mikir desain-nya. Tapi ya kayak katanya om Tjiputra, akhirnya jadi males deh si programmer.

Dari sisi dokumentasi, rasanya UML patut diperhitungkan. Sayangnya saya belum ngerti gimana proses reverse engineer itu. Jadinya sekarang ini masih manual bikin UML, terus di share ke anggota, baru kalo ada perubahan ya tambal sulam diagramnya.

Oia, saya nemu tool gratisan yang cukup bagus. Saya pakai Visual Paradigm UML for Community. Itu gratisan juga, meski ada yang versi enterprise. Fiturnya cukup bagus, sayangnya agak lambat di Windows karena dia jalan pake Java.

Salam

-to be continued-

Nggak nyangka, ternyata sekarang banyak sekali hal yang mesti saya kerjakan. Semenjak saya keluar dari jajaran LK (Lembaga Kemahasiswaan) di kampus saya, saya memang mencari segudang kegiatan yang bisa membuat saya berkembang. Dari pertama, saya bikin komunitas open source bernama Macos, yang awalnya dari acara osum waktu ngadain Software Freedom Day 2009. Awalnya sih jalannya banter, sering rapat dan sebagainya. Tapi begitu masuk liburan, protol satu-satu. Yah, mungkin memang karena kesalahan saya nggak bisa manage kegiatan dengan baik.

Sejenak saya pikir-pikir lagi apa saja aktifitas saya yang ada sekarang ini. Wah, ternyata banyak juga ya. Sulit untuk menceritakannya urut sesuai waktunya. Tapi akan saya coba list semuanya. Ini bukan untuk menyombongkan diri, tapi sebagai pengingat saja bagi saya nanti di masa depan, kalau saya pernah melakukan apa saja di masa lalu (sekarang-red).

Kalo nggak salah, liburan semester lalu saya beserta 2 orang teman saya mencoba menjemput bola, yaitu ngejar proyek bikin aplikasi point of sales untuk supermarket milik pakdhenya temen saya itu. Nasibnya sama, di awal niat banget. Setiap minggu kita kumpul buat bahas gimana kelanjutannya. Bahkan sampe ngajak 2 anak Akuntansi untuk join di project ini. Karena kesibukan masing-masing, terutama si project manager yang nggak bisa manage kegiatannya itu, akhirnya project ini terbengkalai. Katanya sih nunggu supermarket pakdhenya jadi dulu aja, lha tapi saya mikir itu terlalu lama. Sekarang, saya jadi sungkan sama 2 anak Akuntansi itu karena sudah ngajak-ngajak kok nggak ada kelanjutannya. Padahal saya sudah oprak-oprak si project manager, tapi diam aja. Sudahlah.

Meskipun saya secara struktur sudah keluar dari jajaran LK, ternyata sebagai residivis mantan anggota, juga diminta bantu kegiatan lainnya. Salah satunya adalah diklat buat periode setelah saya, dan ikut ngurusin LKTD buat mahasiswa baru. Benar-benar menyita waktu loh itu.

Kerjaan saya yang lain sekarang, yang sudah terbukti memberi penghasilan, adalah menulis. Sementara ini, saya jadi kontributor majalah PC Media di rubrik Programming. Sempat mandeg beberapa bulan sih, karena dosen saya menyarankan bahwa artikel yang saya submit dikirim ke CHIP Indonesia, siapa tahu masuk. Tapi setelah beberapa bulan nggak ada respon, akhirnya mending ditarik aja. Sekarang balik lagi jadi kontributor PC Media. Semoga masih bisa terus menjadi kontributor tetap lah. Amiin.

Berikutnya, jelaslah sebagai mahasiswa. Terutama mahasiswa IT yang benci sekali dengan hafalan, sepertinya semester depan ini saya harus mengambil banyak mata kuliah yang membutuhkan kemampuan menghafal dengan baik. Saya nggak suka itu. Untungnya, masih ada mata kuliah lain yang semoga saja mengasyikkan.

Balik lagi ke Macos, rasanya komunitas ini jadi mati kalau saya nggak ngapa-ngapain. Gimana yah caranya menghidupkan sebuah komunitas? Masa kalau saya yang ketuanya ini diam, yang lain ikut diam? Susah nih. Mungkin saya diam juga sekarang ini karena lagi bingung mau ngerjain yang mana dulu.

Di organisasi yang lain, saya tergabung di Rotaract Universitas Ma Chung yang ada di distrik 3400 (Indonesia). Meskipun sama sekali nggak ada hubungannya sama IT, saya sengaja ikut kegiatan ini untuk membangun relasi dengan pihak non-IT. Toh, organisasi ini termasuk sangat besar sedunia. Nggak ada salahnya juga kan? Motif tersembunyi lain sih, biar bisa lebih sering ketemu sama Ice Queen, hehe. Nah, di sini ternyata saya juga memegang jabatan yang cukup tinggi. Saya termasuk di jajaran Board of Director di divisi Public Relation. Saya mikirnya kenapa saya mau sih, karena ini masih berhubungan sama tulis-menulis dan bikin website. Jadi saya terima saja. Tapi ternyata, ini juga menyita waktu sekali.

Kegiatan di luar kampus, saya masih tetap nge-band. Meskipun nggak sengebet dulu, tapi tetap saya lanjutkan main musik. Sebenernya kasihan juga sih sama anggota yang lain, kalo ternyata saya nggak fokus di nge-band. Tapi toh yang lain ternyata juga nggak terlalu serius. Ada yang futsal, main kartu, dan sebagainya. Apa gunanya saya mikir-mikir serius kayak dulu ya, malah bikin makan ati. Sekarang, lagi nyari vokalis cewek nih, buat yang berdomisili di Malang dan suka aliran Japan Rock, silahkan hubungi saya. :p

Sebagai blogger, jelaslah harus tetap aktif nulis. Dengan blog pribadi beralamat di http://www.fauzilhaqqi.net yang baru saja di launching, saya akan terus menulis dan berbagi apa yang bisa saya bagi.

Hm, apa lagi yah… *mikir*… oia, hobi saya bikin game juga tertunda gara-gara kebanyakan aktifitas. Akhirnya saya jadi sungkan sendiri sama teman seperjuangan saya bikin game ini. Nggak itu saja, niat saya bikin HQLibrary juga masih suspended. Banyak yang harus dikerjakan.

Tapi dari itu semua, saya masih saja merasa kurang puas. Kemarin baca-baca blog orang lain, report wordcampid, dan sebagainya, saya jadi terinspirasi untuk serius bikin usaha. Teman-teman kampus saya sudah ada yang bikin sih, tapi nggak terlalu jalan juga. Saya pikir lagi, ternyata di sekitar saya ini banyak orang hebat yang masih belum memanfaatkan potensinya. Singkat cerita, saya bikin sebuah usaha yang diawali oleh 4 orang termasuk saya. Untuk detailnya, masih rahasia. Saya akan bahas lebih lanjut di posting berikutnya, soalnya nggak mau dibilang sombong. Masih belum ada wujudnya kok koar-koar.

Nah, sekarang dengan segudang aktifitas, saya jadi bingung mana yang harus dikerjakan dulu. Dari Rotaract minta didesainkan sertifikat dan kartu nama. Dari macos, saya punya kewajiban sebagai ketua yang harus memanage semuanya. Di band, saya juga harus ngikuti jadwal ngumpul dan latihan, plus manggung. Di LK, masih saja diminta bantu-bantu. Kuliah, nggak terlalu ngurus sih. Blogging masih harus menambah posting setiap minggunya. Nulis artikel, harus jadi minimal 1 dalam 1 bulan. Targetnya sih minimal 2. Dan sekarang, lagi fokus ngembangin usaha sendiri. Lha terus, mana yang harus dikerjakan lebih dulu???

Kalau ngurus Rotaract, yang macos nggak keurus. Ngurus macos, anak-anaknya pada ribet ngumpulnya. Nge-band, halah cuma gitu-gitu doank. LK, sementara menjauh deh. Rasanya sih, yang sekarang harus konsen, ya demi masa depan. Melanjutkan nulis artikel, blogging, dan mikirin wirausaha. Ok deh.

Tapi semua rasanya sepi dan nggak ada vision kalo nggak ada yang satu itu. Yup, belum ada pendamping *blush*. Masih aja ribet sama Ice Queen, sampe-sampe teman-teman saya bilang “cepetan donk, lama amat sih”. Kadang-kadang juga nggak bisa konsen kalo lagi kepikiran Ice Queen, terutama waktu main rahasia-rahasiaan. Sebenernya, sudah niat mau confess dan mengungkap semua rahasia di balik Ice Queen sih, tapi susah amat waktunya. Bahkan karena ketidakkonsistenan waktu tersebut, bikin saya bingung sendiri ngatur jadwal saya. Begitu ada waktu buat confess, eh malah keadaan lagi nggak mendukung. Yang BadMood lah, yang keburu waktu lah. Yah, sudahlah. Mungkin memang belum waktunya. Tapi saat ini dialah prioritas utama, karena nggak ada dia semua terasa hampa. *lebai mode on, tapi serius* haha.. Dan itu berarti post saya tentang rahasia Ice Queen akan tetap menjadi draft sampai waktunya tiba.