Mengenal berbagai Pola Pembayaran Klien pada saat menjadi Freelancer

Menjadi freelancer itu harus paham bahwa jarang ada bayaran ontime layaknya gajian bulanan kantoran.

Ini saya coba ceritakan satu per satu pola dan jenis kliennya biar pada siap kalau jadi freelancer.

1. Tipe plat merah atau BUMN
   • Penunjukan langsung
     Ini kadang ada DP, kadang diminta selesai 100% dulu baru dibayar. Tapi karena penunjukan langsung, biasanya ada “orang dalam” yang bantu memudahkan jalan sehingga ada DP ataupun ada termin pembayaran, aslinya? secara regulasi ya nunggu 100% dulu baru bayar. Makanya ini yang saya sebut kurang sehat secara bisnis.
   • Tender
     Ini ada yang minta diselesaikan dulu 100% baru dibayar 100%, adapula karena nilainya di atas 500 jt, pihak klien minta uang jaminan. Ini pernah tau di tahun 2010, saya gak tau aturan ini masih ada apa tidak.
     Nah, bagaimana nasib programmernya dong? kalo dibayar tunggu selesai dulu, padahal yang kerja kan kadang estafet dari system analyst, db designer, ui/ux designer, developer, terus qa tester? Ya, project ownernya yang turun tangan ngasih bayaran buat developer pake duit pribadi atau kas perusahaan dianya.
     Kalo yang agak kejam ya membiarkan semua personil belum dibayar sampe klien mencairkan.
   • Outsourcing yang stay di kantor
     Kerja di kantor klien setiap hari kerja. Dibayar layaknya karyawan tetap, yaitu dibayar setiap bulan, tapi minus tunjangan.
2. Tipe klien lokal bank atau swasta
   • Dengan termin / DP
     Karena swasta itu lebih fleksibel, bisa dinegosiasikan mau pake DP berapa persen, mau pake termin berapa kali, dsb.
     Nah untuk pembayaran, kudu dijelaskan di kontrak, tiap termin dibayar tanggal berapa, biasanya klien minta tenggang waktu pembayaran, ada yang sampai 7 hari, ada pula yang sampai 30 hari (biasanya bank swasta sampai 30 hari sejak pengajuan invoice, baru cair). Jadi, developer ketika tau kondisi seperti ini, asal invoice sudah kita tagihkan, harusnya tidak perlu nagih berulang-ulang. Saya pernah loh dimarahin klien bank, karena nagih setiap minggunya haha.
   • Bulanan
     Nah untuk swasta/bank bulanan, ya sama seperti kerja karyawan biasa, dibayar setiap bulan layaknya gajian, tapi tidak ada tunjangan. Tapi beberapa kasus, ada pula yang ngasih bonus misal karena performa atau aplikasi yang dibuat membuat klien untung besar.
3. Tipe klien luar 
   
   • Dengan termin
     Selama setahun terakhir, beberapa klien luar juga ada yang menerapkan termin, tapi jarang, kalopun ada mesti di luar kota besar. Pakai metode termin di sini kalo kliennya sudah yakin scope of worknya fix, maka costnya juga wajib fix. Tidak ada penambahan ataupun surprice cost.
   • Bulanan
     Selama setahun terakhir, ada beberapa klien yang mau bayar bulanan, jadi scope pekerjaan tidak fix, akan ada perubahan (sedikit/banyak), dan kitanya gak boleh baper kalo ternyata yang sudah digarap tidak jadi dipakai. Lah wong tetep dibayar hehe.
     Dan kayak pengalaman kami dengan klien Swedia, itu bulanan, dibayar di muka, tiap bulan gajian dulu, baru kerja 30 hari ke depannya. Tapi kami tetap pro, walau kadang pembayaran telat cair, kami tetap bekerja setiap harinya selama hari kerja (dan beberapa kali weekend juga tetep kerja), dan gak masalah, wong gak ada masalah juga hehe.
   
   
   Kondisi apa yang bisa bikin klien luar terlambat bayar?
   Aslinya kliennya bukan terlambat bayar, sudah dibayar tapi cair ke rekening Indonesianya yang lama.
   Nah, klien luar itu tidak seperti klien lokal, bayarannya tidak seperti transfer dari Mandiri ke BCA, tapi karena internasional, biasanya ada beberapa kondisi lagi:
   
   • Tidak bisa menggunakan pembayaran internasional pihak ke-3 kayak Wise/Stripe/Payoneer
     Maka untuk masalah ini, pembayaran bisa terlambat cair sejak dibayarkan klien, proses transfer bisa memakan waktu 3-10 hari kerja, aslinya sih makan waktu 3 hari, tapi karena hari kerja, misal ditransfer kamis, maka hitungan harinya jadi: jum’at, senin, selasa, yang berarti estimasi hari selasa, bukan minggu. Dan kalo ternyata regulasinya unik, contoh seperti pengalaman kami dengan klien Israel: klien transfer butuh waktu 3 hari, nah buat cairkan makan waktu 3 hari lagi, jadi total 6 hari kerja. Kalo kena weekend ya siap-siap jadi 10 hari.
     
   • Pakai Wise/Stripe/Payoneer
     Wise super cepat dan fee transfernya cukup murah dibandingkan yang lain, proses transfer 1/2 sampai 2 jam saja sudah sampai ke rekening kita. Tapi sayangnya tidak semua negara dan bank hanya bank tertentu saja yang support Wise. Payoneer lumayan besar coverage-nya, tapi fee transfer bisa sampai 80 usd, dan itupun buat cairkannya sama, bisa makan waktu 6 hari.

Semoga bermanfaat!

Pihak Ketiga

Di dalam perproyekan TI, terkadang antara kedua belah pihak (klien dan developer) mengalami jalan buntu untuk mengejar target deadline, ntah karena terkendala teknis ataupun butuh percepatan. Biasanya yang dilakukan kedua belah pihak tersebut adalah merekrut developer tambahan dari pihak ketiga. Pihak ketiga di sini adalah tim developer yang punya badan sendiri.

Ketika menjadi pihak ketiga di antara kedua belah pihak perproyekan tersebut, akan banyak sekali resiko yang bisa dihadapai, di antaranya:

1. Proses adaptasi yang lambat.
   Karena kerjaan developer pihak ketiga nantinya melanjutkan existing code, maka proses adaptasi beresiko menjadi lambat, butuh developer yang punya skill adaptasi yang tinggi dan tentunya jam terbang yang cukup tinggi. Jika tidak, maka tentunya akan merepotkan developer pihak pertama/kedua, proses brainstorming ke pihak ketiga menjadi penghambat proses development. Belum lagi menyesuaikan git flow dan juga pengaturan manajemen proyek di keduabelah pihak tersebut.
2. Tidak fokus.
   Ketika developer pihak ketiga sudah jelas kerjaan yang akan dikerjakan, sudah diberikan briefing masalah yang harus diselesaikan, kemudian masuk di antara kedua belah pihak proyek, terkadang pekerjaan developer pihak ketiga menjadi tidak fokus, biasanya ada saja kendala, “lah, diminta garap report kok malah datanya belum siap, pakai dummy-pun mereka lambat menyediakan”… “lah katanya API ready, ini kok pas ditest malah error”, “hmmm..ini kok malah disuruh garap yang belum selesai dari kerjaan developer internal”. Maka dari itu, sebelum pihak ketiga masuk ke pekerjaan tersebut, ada baiknya mengecek kesiapan semua yang akan dikerjakan, jangan sampai dibuat tidak fokus oleh masalah internal proyek tersebut. Selain itu, terkadang karena klien merasa dengan menambah personil maka akan bisa kejar target tepat waktu, ada saja request tambahan yang diminta sebagai bonus, yang menyebabkan resiko molor dan melebar dari skup pekerjaan yang dibahas terjadi.
3. Pembayaran terlambat.
   Biasanya pihak ketiga ini tidak bisa membuat kesepakatan pembayaran tersendiri, ntah karena kendala birokrasi atau regulasi, dan lain sebagainya. Dan biasanya diikutsertakan di pembayaran tim developer kedua belahpihak, “maaf ya mas, bayarannya tunggu web yang sudah disiapkan pihak kedua siap, biar sekalian” walaupun pekerjaan developer pihak ketiga ini sudah selesai. Jadi ya nunggu proyeknya ditutup dulu mengikuti jadwal kedua belah pihak.

Oleh karena itu, pahami resiko-resiko tersebut jangan sampai nanti salah melangkah menjadi developer pihak ketiga.

Bebas bugs?

Jika ada klien yang menuliskan kontrak kerja ataupun FSD ataupun SPK yang berisi poin “Aplikasi yang telah dikembangkan dijamin bebas dari segala macam bug ataupun error” atau sejenisnya.
Maka bersiaplah menghadapi “never ending project“.

Mengapa?
Teknologi itu berkembang “rapid pace of change“, alias cepet banget berubah, versinya hari ini 1.0, besok sudah 1.0.1, dan bahkan sudah 2.1.0.
Lantas dengan segala perubahan itu, terkadang code yang sudah ditanam di aplikasi perlu dimutakhirkan, diperbaharui agar sesuai dengan perkembangan.
Itulah kenapa kadang pas Apple atau Google mengumumkan OS terbaru, perangkat iPhone/Android baru, banyak aplikasi di PlayStore/Appstore yang minta diperbaharui (diupdate). Gunanya agar menjamin keberlangsungan aplikasi dapat berjalan dengan baik.
Terkadang urusan “back-compatibility” itu tidak terjamin, apalagi perubahan struktur code/bahasa pemrogramannya radikal. Terpaksa deh diperbaharui daripada bermasalah di perangkat baru ataupun OS baru.

Ruginya kalau kita menjamin app yang telah dikembangkan menjadi app “yang bebas kutu”, maka kita harus siap dengan segala macem perubahan teknologi tersebut, alhasil jadilah “senjata” klien agar dapat layanan gratis dari developer.

Bagaimana antisipasinya?

1. Buatlah batasan masa UAT (User Acceptance Test) atau masa alpha/beta version dari aplikasi yang telah dikembangkan menjadi 1 periode waktu, misal masa UAT dibikin terbatas selama 1 (satu) minggu, 2 (dua) minggu atau max 1 (satu) bulan.
   Jadi, selama masa UAT, klien harus menyiapkan laporan bugs sekali selama 1 minggu (misalnya), kemudian ditulis di dokumen agar nanti masalah-masalah tersebut di-reproduce dari sisi developer untuk dicari masalahnya.
   Biasanya yang dilaporkan itu adalah waktu (jam/tanggal) pengujian, kronologi (urutan) actual result, dan expected result (hasil yang diharapkan). Akan lebih bagus lagi dilaporkan via tiket di gitlab/jira/trello.
   Ingat, klien harus punya gerak terbatas di UAT, jangan sampai pas kita lagi benerin bugs, dia malah laporin bugs-bugs lain dan minta cepet diperbaiki, alhasil masa perbaikan bugs mengalami banyak interupsi dari klien yang sudah pasti akan menyebabkan “delay” pekerjaan. Makanya kalau di kontrak kerja, saya selalu tulis “report once” pada tanggal tertentu (yang sudah ditentukan). Jika klien telat memberikan laporan bugs tanpa sebab yang jelas? siap-siap deh “project termination”. Di luar masa tersebut, tidak perlu dilayani, kan kontrak sudah habis.
2. Beri garansi terbatas, misal “2 (dua) minggu aplikasi tersebut bebas bugs dan siap memperbaiki masalah minor”, jadi kalau ada update library, struktur codingan, dll selama itu minor, ya dikerjakan dalam waktu 2 (dua) minggu tersebut, jika tidak ya harus dinyatakan sebagai “change request” (CR) alias permintaan tambahan.

“Lah kok enak banget, sudah bayar mahal-mahal masa’ gak dijamin? kan tanggungjawab anda selaku developer!”

hahaha..ini saya kutip dari klien yang pernah ngomong kayak gitu ke saya. Jadi dianggapnya, karena kita sudah dibayar maka tanggungjawab penuh sampai aplikasi dan sistemnya itu wafat 😂 “enak, gundulmu!” akhirnya ya saya tinggalin klien kayak gini (alias project termination karena permintaannya tidak saya penuhi karena di luar kriteria “bugs” dan “minor update” dan sudah lewat masa garansi).

Saya di kantor saja, selesai masa development, kelar UAT 1 bulan, setelah itu ya cuma rapat ini itu, gak ngoding sama sekali, tetap digaji, walaupun kerjaan garap app dah kelar, tetap digaji, iya, “kok enak? magabut ya?” yo nggaklah, itu kita standby siap sedia kapan saja bila ada masalah, kesulitan dari user, dll..siap bantu selama jam kerja. Setelah pengembangan selesai, kita dibayar untuk tanggungjawab melayani sesuai “job desc” kita. Lah enakan klien sudah gak bayar, minta dilayani aplikasi dijamin hidup terus. 😅

Logikanya, kita beli motor/mobil, mana maulah perusahaan yang bikin motor/mobil tersebut nyediain layanan atau sparepart gratis. Coba aja datang ke dealer motor/mobil pas mobilnya mogok “pak, saya beli mobil dengan anda, kenapa ini mogok, ini tanggungjawab anda, tolong perbaiki”, saya jamin diteriakin “stress!”.

Inget kata-kata Joker, “never do it for free“. Mau teman sekalipun, profesionalisme harus tetap dijaga, karena ya ingat, ada hak pekerja yang harus dipenuhi, dan pekerja tersebut juga punya tanggungjawab terhadap keluarganya.

Tips buat para klien yang hendak merekrut pekerja TI

Ada banyak sekali permasalahan di dalam manajemen proyek.

Salah satu yang menarik adalah ketika klien salah memilih vendor/tim developer yang menyebabkan project amburadul. Atau karena tim developer baru sadar keliru di dalam merancang design arsitektur software yang sudah terlanjur dibuat.

Dan biasanya ujung-ujungnya dicarilah penyelamat proyek.

Setidaknya sudah lebih dari 3x saya diminta jadi “penyelamat proyek”

Dulu, klien personal dari PLN Sumatera Utara, meminta saya develop aplikasi pelanggan dalam waktu semalam, padahal si klien ini dadakan mengabarkan.

Pernah juga, ada teman yang ditinggal developernya, saya diminta menggarap aplikasi fintech dalam waktu 2 minggu. (Dulu app-nya pernah saya share juga di facebook)

Pernah juga, ada startup marketplace yang sourcecodenya berantakan akhirnya susah dimaintain yang akhirnya meminta saya refactoring code tersebut.

Permasalahan seperti ini akar masalahnya kebanyakan adalah menganggap bahwa membuat software itu tanpa perlu monitoring di setiap prosesnya. Cukup perintah ke developer untuk kerjakan karena merasa sudah bayar mereka. Dan penyebab lainnya adalah keliru menunjuk developer yang ahli di dalam mengatasi permasalahan si klien.

Ingat, developer software di dunia ini banyak sekali, tetapi tidak semuanya ahli atau memahami permasalahan yang dihadapi si klien.

Klien yang awam yang mungkin bisa “dikibulin” developer, si developernya “menggampangkan” permasalahan, padahal ia tidak paham masalahnya. Nah, untuk mencegah hal kayak gini, kudu cari “penasehat” atau “konsultan” yang bisa menilai kemampuan para developer yang direkrut. Karena bisa jadi, developer yang direkrut dikira si klien memang memahami permasalahan, ternyata malah “penurut” dan tidak paham permasalahan sebenarnya. Tidak mampu memberikan “insight” yang tepat buat klien, dll. 

Atau, klien sebaiknya minta tim developer yang direkrut menunjukkan portofolionya, ceritakan portofolionya dan kalau sampai si klien berkata, “nah, ini masalaha saya, mas. Serupa yang pernah mas ceritakan dan mas kerjakan barusan”, berarti kemungkinan besar developer tersebut adalah orang yang tepat.

Dan perlu diperhatikan juga Kunci keberhasilan proyek itu adalah komunikasi, kolaborasi antar stakeholder (end-user, vendor, klien, dll) yang terlibat. Tidak bisa lepas tangan begitu saja, begitu menjelang deadline, baru perhatian dan kocar-kacir cari Superman.

Komunikasi efektifpun bukan komunikasi antara juragan dengan pembantu, atau master dengan slave, atau raja dengan prajurit, melainkan kerjasama, ya kerjasama, saling bekerja bersama-sama mencapai tujuan, menciptakan hubungan baik dan siap beradaptasi dengan segala kondisi atau kendala yang mungkin dihadapi di tengah tahap pengembangan berlangsung (yang sudah pasti tentu tidak slamanya berjalan mulus).

Jika mampu berkolaborasi asik seperti itu, tidak ada lagi masalah ditinggal kabur developer, salah nentuin, krn mesti akan ketahuan di awal.

Mengapa waktu proyek tidak dapat dihitung dengan pasti?

Pengembangan software ataupun aplikasi itu tidak pernah menggunakan ilmu pasti.

Untuk waktu pengerjaan proyek dan biaya proyek juga selalu menggunakan estimasi: estimasi waktu dan estimasi harga.

Di luar sana, selalu menggunakan pendekatan “agile”, di mana interaksi antara tim pengembang dengan tim user ataupun klien lebih penting daripada proses.

Mengapa demikian? dengan kita berinteraksi, persepsi tim pengembang dengan tim “user”/klien akan selalu seirama.
Itulah mengapa terkadang walau sudah kita definisikan rancangan sistem dari “software” ataupun aplikasi di awal, pas di proses terkadang ada saja perubahan atau tidak tepat 100% sesuai dengan rancangan awal, mesti ada yang bergeser. Ini dikarenakan apa yang ditangkap tim pengembang dengan apa yang disampaikan tim “user”/klien ketika menyampaikan “scope” pekerjaan ataupun masalah yang harus diselesaikan, tidak semuanya 100% sama.

Contoh: tim klien meminta dibuatkan rumah yang ada tangganya. Tim developer menerjemahkan maksud dari si tim klien tangga kayu vertikal. Padahal, yang dimaksud tim klien adalah tangga spiral terbuat dari besi (ini contoh sederhana saja).

Jika di awal terlalu detail mendefinisikan semua, yang ada waktu akan banyak terbuang. Itulah mengapa pekerjaan pengembangan software dilakukan bertahap dan ada batas waktu, selanjutnya ya tinggal evaluasi bersama. Dan penting juga bagi tim developer memahami apa masalah klien dan apa solusi yang tepat (tidak harus menuruti 100% keinginan klien, karena terkadang sebenarnya klien juga tidak memahami masalahnya sendiri).

Nah, itulah mengapa pentingnya dipahami bersama jika waktu dan harga proyek itu tidak bulat sama dengan yang direncanakan di awal, mesti ada perubahan, ya lazimnya kalau ada tambahan “task”, di-charge di akhir, biar fair. Atau dibuat per fase, jadi kalau ada pekerjaan tambahan, dilanjutkan di fase kedua (tergantung prioritas).

Demi mencapai hal tersebut, biasanya ada “daily meeting/call”, “weekly meeting/call”, laporan dwi-mingguan, dll. demi mencapai target yang diinginkan agar semua tetap pada tempo-nya, pada prinsip yang sama, dan tetap “on-track” sesuai “task” pekerjaannya.

Tim klien juga harus menyadari, tidak bisa menuntut “loh, kok molor, kan di kontrak kerja targetnya tanggal sekian” | “pak, itu yang di proposal kami dan di kontrak kerja sudah kami sampaikan kalau itu estimasi. Bapak juga mestinya paham, di tengah proses pengembangan kemarin, bapak minta perubahan di bagian form tertentu, itu tentu memakan waktu dan mempengaruhi timeline dari pekerjaan ini. Tidak bisa sama waktunya, pak. Ibarat bapak bangun rumah, bapak minta tambahin garasi mobil, yang sebelumnya minta garasi motor, tentu akan merubah requirement yang sudah disepakati, meskipun sama-sama garasi”.

Di tambah lagi, terkadang di tengah proses, ntah tim klien ataupun tim developer, “discover” sesuatu yang lebih baik, ntah berdasarkan “feedback” dari “end-user”-nya, ntah karena sudah terlihat wujud desainnya, dirasa kurang pas, dan lain sebagainya.

—————————————-

Apakah perubahan di tengah proses dapat diatasi dengan menambah personil? belum tentu, terkadang “transfer knowledge” sampai dengan progress terakhir itu butuh waktu bagi personil baru, dan bahkan untuk “menyamakan tempo” saja butuh keahlian khusus, tidak semua bisa. Paling aman ya waktunya yang bergeser, atau personil baru mengerjakan “task-task minor”.

Oleh karena itu, penting dipahami bersama, masalah waktu dan harga di dalam proyek itu hanya bisa dihitung sebatas estimasi saja (lazimnya seperti itu), dan harus mengetahui resiko-resiko(resiko teknis, “scope” pekerjaan, SDM, man hour, dll) dari setiap keputusan perubahan yang diambil di dalam pengembangan aplikasi atau software.

Project Hunter wanna be

Kemarin ada teman yang berdiskusi mengenai proyek, teman saya ini dari pegawai kantoran yang akhirnya berhenti dan memilih membangun usaha sendiri dan menjadi project-hunter.
Diskusi panjang lebar.. hingga 2 hari tetap dilanjut dari chat sampai telpon.
Dari diskusi ini saya mendapati beberapa yang mesti dikoreksi, dan smoga menjadi pelajaran bersama..

1. Jangan pernah membawa perkara teknis pengembangan ke klien (apalagi kalau kliennya gaptek). Cukuplah internal saja yang mengetahui perkara teknisnya bagaimana. Kecuali, si klien memang punya tim engineer yang bakal turut campur di dalam proyek ini, dan mereka harus mengetahui hal tersebut atau emang si klien mengerti soal teknologi dan ingin mengetahui teknologi apa yang nantinya diterapkan di produk software yang ia minta, dan biasanya si klien duluan yang buka omongan teknis, ya kita sebagai vendor TI menjawab pertanyaan tersebut dengan baik dan benar.
   Terkadang salahnya di sini, pas meeting, kita yang merasa sudah jago develop aplikasi. malah menyampaikan hal-hal teknis dari A sampai Z di software yang ingin ia bangun, kalau yang seperti ini yang ada klien cm “angguk-angguk” padahal ya bingung (masuk kuping kanan keluar kuping kiri). Kesan ke kliennya tidak kita dapatkan sama sekali, malahan maksud hati ingin meyakinkan klien dengan cara menjelaskan teknis pengembangan, mulai dari bikin flow diagram/flowchart, bikin pake framework apa, codenya seperti apa, versi berapa, terus nanti pakai web service apa, dan lain-lain, eh malah tidak berkesan.
   Ada baiknya sampaikan presentasi yang bagus dalam bentuk gambar, flow aplikasinya sudah dlm bentuk tampilan antarmuka software, dan kita jelaskan tiap step-nya dari login sampe logout di gambar tampilan antarmuka tersebut, sehingga si klien sudah dapat gambaran, seperti apa nantinya tampilan software tersebut, dan ini lebih meyakinkan daripada kita bawa-bawa hal teknis pengembangan. Dan di situ juga diharapkan klien memberi feedback, kira-kira dari gambar yang disajikan adakah yang kurang pas menurut pengguna, misal warna, susunan menu, dan sebagainya. Atau syukur-syukur kita sudah punya contoh dari prototype/portofolio yang kita punya.
2. Kebanyakan klien tidak mengetahui apa yang mereka butuhkan, mereka mengikuti trend atau dari apa yang ia ketahui saja. Misal : dia tau Windows itu mudah dipakai, karena memang ia taunya cuma OS itu, dan belum coba Linux atau OSX. Ketika dikasih lihat Linux, mereka bingung, belum terbiasa. Nah sama kasusnya ketika disuruh memilih server, kita menyarankan menggunakan Linux CentOS, si klien lebih memilih OS Windows 10, padahal kebutuhannya si klien ini tidak cocok diimplementasikan di OS tersebut. (ini cuma contoh kecil, ada banyak lagi contoh lain, seperti keinginan klien supaya tampilan softwarenya seperti Facebook, ingin akses message-nya secepat Whatsapp/telegram, padahal si klien belum memahami kebutuhannya seperti apa, ketersediaan resourcenya bagaimana, budgetnya seberapa, jatuhnya kebanyakan keinginan yang tidak tepat sasaran)
   Maka dari itu, coba tawarkan solusi alternatif, misal ketika kita mendapat order membuat aplikasi mobile. untuk broadcast SMS, coba tawarkan alternatif, tulis di proposal dan ketika meeting, sampaikan yg anda tawarkan tersebut yg mungkin bisa menjadi solusi bagi klien: “pak, bagaimana kalo broadcastnya mirip bbm/wa, ntar muncul di smartphone konsumen, promonya apa aja..kalo sms takutnya regulasinya panjang, apalagi sekali broadcast terbatas, dan mungkin ada kendala delay”..syukur-syukur klien angkut dua tawaran yang kita sampaikan, proyek sms broadcast dapet, ditambah proyek messanger jg dapet.
3. Buang sedikit ego, ketika harga proyek ditawar klien terlalu menyakitkan, cobalah sedikit tenang, berpikir apa yang bisa kita coba agar tetap goal mendapatkan proyek tersebut.
   Dengan berpikir tenang, kita coba koreksi apa saja bagian yang bisa kita kurangi standarnya (tanpa mengurangi esensi pemenuhan kebutuhan klien), misal harga desainnya dikurangi, nego lagi dengan designer, kira-kira apabila harga dikurangi segini bakal dapet seperti apa, dan sebagainya..atau ditambah waktunya, biasanya semakin tipis timeline, harga tentu semakin tinggi, karena jam kerja/hari tentu menjadi tinggi, mungkin dengan melebarkan timeline (misal ditawarkan waktu pengerjaan 3 bulan, kita tawarkan menjadi 5 bulan), mengurangi “beban” kerja dan tentu harganya bisa dikurangi. Atau tawarkan alternatif harga modular : “bapak, silahkan dilihat list harga dari kami, ini kami pasang per module : “Bapak bisa cek untuk kebutuhan yang bapak minta standar harganya segini, namun karena bapak meminta kami mengerjakan bagian X, Y, Z, saya coba tawarkan harganya per module, sehingga bapak bisa pilih yang mana yang akan bapak ambil saat ini dan yang mana bapak pending. Dan apabila nanti ingin melanjutkan kerjasama ini, siapa tau ke depannya, bapak meminta kami mengembangkan modul-modul yang bapak belum kesampean karena terbatasnya budget di penawaran berikutnya.”

Kira-kira seperti itu tips hari ini.
Sekian dan terima kasih 🙂

Panduan untuk developer dalam menyusun Kontrak Kerjasama dengan klien

Tulisan saya kali ini mencoba menjabarkan apa saja komponen yang harus ada di dalam menyusun berkas Kontrak Kerja antara developer (vendor software) dengan klien.

Mengapa saya tidak menyertakan contoh kontrak kerja?
Karena tidak ada yang instant di dunia ini, semuanya berproses, begitu juga apabila teman-teman developer menggarap kontrak kerja, tentu tiap kerjasama ada pelajaran yang berarti yang dapat membuat teman-teman developer sadar bahwa ada komponen yang tertinggal di kontrak kerja dan jadi pelajaran bahwa teman-teman harus menyertakan komponen tersebut di kontrak kerja berikutnya.

Ditambah, kontrak kerja itu bersifat rahasia, tidak bisa bebas dibeberkan ke publik. Dan setiap teman-teman punya ciri khas dalam menulis kontrak kerja yang menjadi nilai tambah mengapa klien memilih anda dalam kerjasama pengembangan software.

Ok, kita mulai bahas satu per satu apa saja komponen yang harus ada di dalam kontrak kerja kerjasama dengan klien.

Komponen-komponen yang sebaiknya ada di kontrak kerja :

1. Yang bertanda tangan, tuliskan diawali dengan tanggal, kemudian disertai nama lengkap, alamat lengkap, no.telepon pihak pertama dan pihak kedua. Di dokumen pertama ini saya tuliskan bahwa pihak pertama adalah klien dan pihak kedua adalah developer.
2. Pasal-pasal :
   • Bentuk Kerjasama
     Kerjasamanya dijelaskan seperti apa dari pihak pertama ke pihak kedua, dan dari pihak kedua ke pihak pertama.
     Karena di sini tidak satu arah.
     Tidak hanya developer yang punya tugas/peranan, tapi juga Klien punya peranan.
     Nah dijelaskan saja satu per satu. Masing-masing tugasnya (bukan menjelaskan apa saja yang dibuat tapi lebih general, karena kalau membicarakan apa yang dikerjakan itu masuk ke proposal dan laporan pekerjaan bukan kontrak kerja)
     Contoh :
     Pihak Pertama memberikan pekerjaan kepada pihak kedua yaitu ….
     
     Pekerjaan yang dilaksanakan adalah : a. …. b. …. c….
     Pekerjaan tersebut dilaksanakan pihak kedua.
     
     Sedangkan untuk pihak pertama sebagai penanggungjawab proyek mempunyai peranan sebagai : a… b… c….

   • Jangka Waktu Pelaksanaan
     Tulis jangka waktu pelaksanaannya, dituliskan dengan jelas, tanggal mulai dan tanggal berakhirnya proyek, terus jangka waktu dijelaskan masing-masing tahap.
     contoh :
     kontrak kerja tanggal …
     pengumpulan data yang dibutuhkan tanggal …
     setup server tanggal …
     development tanggal….
     testing dan review tanggal …
     bugs fixing tanggal…
     maintenance tanggal..
     penutupan proyek tanggal…
   • Hak dan Kewajiban
     Setiap pihak, baik itu pihak pertama maupun pihak kedua, memiliki hak dan kewajiban, maka dari itu tulislah semua hak dan kewajiban tersebut sampai bagian terkecil, jangan sampai ada yang terlewat, mengapa? karena pekerjaan yang kita lakukan bukan hal cuma-cuma, ya jasa developer dipakai tentu dibayar, jangan sampai developer mengerjakan sesuatu yang bukan kewajibannya. Semakin spesifik detail hak dan kewajiban di kontrak kerja, maka makin bagus. Tentunya menguntungkan kedua belah pihak menghindarkan pihak pertama menuntuk pekerjaan kepada pihak kedua yang bukan kewajiban pihak kedua (sayangnya sering terjadi yang seperti ini, karena pihak kedua/developer kurang spesifik menuliskan kewajiban-kewajibannya) Dan setiap hak masing-masing pihak dipenuhi oleh pihak lain sesuai waktu dan kapasitas yang telah dirumuskan bersama.
   • Nilai Kontrak dan Sistem Pembayaran
     Nilai kontrak dituliskan dengan jelas beserta mekanisme pembayarannya seperti apa.
     misal, pihak kedua dibayar 4x cicilan, yaitu di waktu : awal kontrak (DP), pada saat alpha testing (atau pada waktu masa development berakhir sebelum masuk masa review/bugs fixing), pada saat mulai tahap bugs fixing / beta testing, dan terakhir ketika proyek dinyatakan selesai/penutupan proyek. Biasanya dibuat dalam persentase..atau bisa juga ditentukan porsinya masing-masing tahap tersebut. Dan masing-masing waktu pembayaran yang diamanahkan ke pihak pertama ada masa jatuh tempo dituliskan supaya jelas dan menghindarkan dari hal klien terlambat melakukan  pembayaran (sering kejadian). Misalnya : jatuh tempo 1 minggu dari tanggal invoice diberikan ke pihak pertama (klien).
   • Denda Keterlambatan (development, testing, reviewing, payment)
     Denda harus ditentukan dengan hati-hati. Developer/pihak kedua biasanya dikenakan denda apabila terlambat di dalam menyelesaikan pekerjaannya, ntah itu denda per hari atau per minggu, nominalnya mesti dibicarakan bersama antara kedua belah pihak. Jangan sampai ada yang dirugikan. Denda telat testing atau telat review dan telat pembayaran jg mesti dibahas bersama.
   • Perselisihan
     Perselisihan terkadang dapat saja terjadi, baik itu perselisihan kecil ataupun yang sudah membesar karena permasalahan yang kompleks. Nah di sini diatur pasal mengenai perselisihan tersebut, tulislah keterangan akan diselesaikan di mana perselisihan tersebut, dan dengan cara seperti apa? misalnya : apabila masalahnya dapat diselesaikan secara musyawarah mufakat, maka ini menjadi prioritas, namun apabila memang tidak ada titik temu, ya melalui jalur hukum di pengadilan, maka dari itu tuliskan nama pengadilan dan alamatnya.
   • Aturan lain-lain
     Aturan tambahan disertakan di bab pasal ini, apapun itu pasalnya, contohnya : klien berkeinginan mengubah fitur di tengah jalan development, aturannya mainnya seperti apa jika klien ingin mengubah fitur yang sudah disepakati? maka dari itu tulislah tata cara/aturan mainnya. Jika nanti memang harus ada bentuk kerjasama tambahan, mekanismenya seperti apa dicantumkan di pasal ini. Pasal penting di bab kali ini juga harus menyertakan ketentuan perubahan dari bentuk kerjasama, misalkan klien ingin mengajukan perubahan fitur, maka harus diajukan ke developer paling tidak 2 minggu sebelum fitur itu dikerjakan (disesuaikan dengan jadwal), jika sudah dikerjakan dan minta diubah, maka harus ada aturan yang mengatur tentang ini, apakah klien dikenakan denda atau biaya tambahan, atau perubahan tersebut dikerjakan di akhir proyek dengan kontrak kerja baru. Dan jangan lupa cantumkan batas waktunya berapa lama untuk merumuskan dan pengajuan (menghindari masalah jangan sampai dadakan yg dapat merugikan developer).
   • Ketentuan Penutupan Kontrak
     Mulai berlakunya kontrak kerja, ketentuan kontrak kerja, dan tanda kalau kontrak kerja berakhir itu seperti apa nantinya, dicantumkan di bab ini. Dengan penutupan bab ini, menandakan tidak ada aturan baru yang terjadi. Jikalau memang ada aturan baru, maka akan berlaku adendum. Adendum adalah dokumen yang berisi perubahan kontrak kerja tanpa ada penambahan ataupun pengurangan klausa kontrak yang telah disepakati.
3. Tanda tangan pihak pertama dan pihak kedua di atas materai. Masing-masing pihak memegang surat kontrak kerja dan 1 materai yang ditandatangani kedua belah pihak.

Beberapa catatan :

• Berkas Kontrak kerja dipegang masing-masing pihak dan kedua berkas tersebut telah ditandatangani dan dibubuhi materai.
  Kontrak kerja yang dipegang developer itu, pihak pertamanya adalah developer, sedangkan pihak keduanya klien (aktif).
  Sedangkan untuk kontrak kerja yang dipegang klien, pihak pertamanya klien, pihak keduanya developer (pasif).
• Isinya kontrak kerja yang dipegang masing-masing pihak dapat dibuat sama, tapi perlakuannya beda. Atau Kontrak Kerja masing-masing pihak itu dibuat sama persis, dengan ketentuan pihak pertama klien, pihak kedua developer.
• Ada alasan mengapa terkadang kontrak kerja pihak pertama dan pihak kedua dibuat berbeda, biasanya dengan kondisi pasal-pasal untuk developer dan untuk klien banyak perbedaan dan lebih spesifik.
• Kemudian, apabila ada tulisan angka, baik itu tanggal, nominal pembayaran, denda, jumlah hari, dll, dituliskan dengan angka dan dieja (ditulis dengan huruf).

Semoga bermanfaat. Jika ada tambahan..silahkan ^_^

Menentukan harga jasa untuk programmer dan desainer

Setelah pernah dibahas mengenai menentukan harga project TI khususnya mobile apps. yang ingin kita bahas adalah bagaimana menentukan harga jasa untuk programmer atau desainer mobile apps (mungkin bisa dipakai untuk developer software secara global)

Begini, akhir-akhir ini saya sering ditanya mahasiswa : “mas, bagaimana cara menentukan harga desain saya? saya ragu mau pasang harga”

Kalau menghendaki harga yang pantas dan ideal, itu subjektif, silahkan tentukan berdasarkan usaha yang akan dikeluarkan dan alokasi waktunya. Dan pasang harganya. Yang penting berani dan sudah mengukur sendiri harga yang pantas. Jangan sampai, kamu pasang harga 3 juta rupiah, namun, ternyata uang yang dikeluarkan untuk usaha begadang, internet dan ngemil serta ngopi sambil bekerja itu ngepas 3jt, atau mepet 3juta, alhasil tekor dan gak ada untungnya.

Namun, beberapa programmer/desainer software junior, masih bingung, harga jasa saya berapa?

Mari kita perhatikan 5 hal yang mempengaruhi harga jasa kamu di dunia software engineering sebagai berikut :

1. Scope pekerjaan.
   Scope adalah segala hal yang ada di dalam produk software/produk dari project TI dan segala proses di dalamnya.
   Mendefinisikan apa yang diminta, apa yang mesti dikerjakan, dibagi step-stepnya (rencana->rancangan) sampe menjadi rangkaian berurut apa saja yang dikerjakan. Dengan demikian, dapat diestimasi jadwal dan waktu pengerjaannya.
   Contoh, ketika saya dari tidur pengen berangkat ke sekolah :
   1. Saya bangun tidur (15 menit), kemudian
   2. saya mandi (15 menit), kemudian
   3. saya sarapan (30 menit), kemudian
   4. saya berangkat ke sekolah (20 menit).
2. Proses pengerjaan,
   Sulit kah? mudah kah? simple kah? kompleks kah?
   Terus bagaimana proses yang mesti saya ikuti? banyak kah? tentu mesti memperhatikan, jika ternyata proses untuk mengerjakan codingannya ataupun desainnya, bisa memakan waktu berjam-jam.
   Mulai dari :
   1. memahami klien kemudian menganalisis kehendak si klien;
   2. brainstorming, berguna untuk mendefinisikan semua kebutuhan biar bisa dikerjakan menjadi karya kita;
   3. inisialisasi, mulai dari kamu corat-coret desain/coba-coba code init/awal sampe jadi prototyping;
   4. prototyping, membuat karyamu sampe dengan prototype;
   5. development/design, mulai deh ngembangin sampe memroses semua kebutuhan menjadi produk
   6. revisi, mesti ketemu bagian ini, kadang ada saja bagian yang tidak sesuai kehendak klien, nah ini mesti diperhitungkan;
   7. final version, ketika sudah direvisi, dipoles, dibungkus, terus diserahin deh ke klien.

   panjang kan prosesnya? 😀 Makanya perlu diperhatiin betul, jangan sampe harga yang kamu pasang gak sesuai.
   Nah, ada beberapa hal itu bisa dikerjakan bebarengan, serentak (jika kamu ngerjainnya berdua atau lebih sama teman), tentu ada beberapa proses bisa dihemat waktunya. Coba lihat ilustrasi berikut :

   

   Critical Chain Project Schedule

   Kalo dilihat dari gambar di atas, tentu kita bisa memperkirakan, task apa saja yang bisa dikerjakan dalam 1 waktu bersamaan, dan mana yang tidak bisa. Jika tidak bisa, terus taruh di mana prosesnya..apa dikerjakan duluan, apa dikerjakan belakangan? tentu kalau ingin mengerjakan sesuatu, kerjakan dari yang paling mendasar.

3. Standar harga per jam kerja (hourly rate)
   Kalo bagian ini, gak bisa sembarangan ditentuin. Kamu mesti sadari gaji/rate bayaran kamu berapa yang pernah kamu terima? terus itu dikerjakan berapa lama?
   Misal :
   Kamu pernah kerja 2 minggu (10 hari kerja, minus sabtu-minggu) dibayar Rp 3.000.000
   Sehari kerja dari jam 09:00 – 12:00, dilanjut ishoma, terus jam 13:00 – 16:00, berarti kalo ditotal : 6 jam kerja.
   Dan jika kita konversi menjadi perjam, rumusnya: Harga / total jam kerja / total hari
   Rp. 3.000.000 / 6 / 10 = Rp 50.000
   Berarti kamu dibayar Rp50.000,- per jam. Rate ini selalu naik seiring pengalaman, tentunya bila dinamika perubahannya naik, dalam artian, kamu sudah mengalami pengalaman yang banyak, yang dulunya sulit, jadi gampang, skill bertambah, dan beberapa project kamu jadi terbiasa garap (pengalaman). Semakin tinggi pengalaman, rate tentu semakin tinggi juga.
   Apalagi dibarengi skill yang makin tinggi pula (semakin banyak pengalaman, mestinya semakin beragam pula soft skill yang dikuasai). Bila kamu sudah 10 kali project dalam 2 tahun dengan hourly rate Rp 50.000,-… pas tahun ke-3, ya naikin lagi hourly rate jadi Rp 75.000,- atau Rp 100.000,-.Apalagi dalam 2 tahun itu kamu sudah belajar banyak, ditambah sekolah lagi, bisa berkali-kali lipat.Dan lagi-lagi, perhatiin juga standar gaji di dunia saat ini. (coba googling : salary guide [tahun], contoh : salary guide 2014, saya gak akan jelasin ini, cari di google dan baca sendiri sesuai posisi kamu di pekerjaan, bila orang kerja dibayar per bulan (20 hari kerja) sekian rupiah, tentu bisa dihitung per jamnya). Tentunya jika kamu di tahun kedua pernah mendapatkan proyek membuat sistem informasi perkantoran dengan harga Rp 60.000.000,-, kemudian di tahun ke empat jangan pasang 60jt lagi, tapi dinaikin. Berapa besar kenaikannya? kalau masih kesulitan menentukan, kembali ke pembahasan kita di atas yang baru kita bahas dan perhatikan di salary guide untuk profesi kita di tahun ke-4 besar gaji/rate-nya berapa.

   Berikut ini contoh hourly rate di beberapa negara

   

   Mahal ya? iya, di sana dihargai lebih. Kalo rate di atas diterapkan di indonesia, tentu gak pas 😀 makanya tadi saya sampaikan cek salary guide untuk Indonesia. Contohnya di sini: Salary Guide 2016. Cek profesimu sebagai developer apa. terus cek berapa tahun pengalaman kerjanya. Jika sudah dapat, ya tinggal konversi ke per jam.

4. Investasi
   Seluruh hal yang berhubungan dengan proses yang dikerjakan di atas, dan biaya yang keluar karena hal tersebut. Seperti yang saya jelaskan di atas.
   1. Saya bangun tidur (15 menit) -> gratis
   2. saya mandi (15 menit) -> sabun : Rp 2000, sampoo Rp 1000, pasta gigi+sikat giginya : Rp 8000
   3. saya sarapan (30 menit) -> sarapan ketoprak : Rp 6000, jalan kaki ke TKP
   4. saya berangkat ke sekolah (20 menit) -> berangkat naik motor, bensin Rp 6500

   Terus, kalo ditotalin : makan waktu 1 jam 20 menit (1,33 jam), dan biaya : Rp 82.000 (2000+1000+….+6500)

   Rumusnya : hourly rate x total proses kerja
   Jadi, ketika hourly rate kamu Rp 50000, berarti :

   Rp 50000 x 1,33 jam + Rp 82.000 = Rp 148666,66 (mari kita bulatkan ke atas :p Rp 149000)

   Ya nilai dari project ini : Rp 149.000,-

   Contoh di atas mungkin sedikit membingungkan, pada intinya saja ya. Jadi kalau kamu dapat proyek dalam waktu 1 bulan, ya dikonversi saja dalam satuan hari. 1 bulan = 20 hari kerja, 1 hari = 8 jam kerja. 20*8=160 jam.

   Misal hourly rate kamu adalah Rp 250.000,- dengan pengalaman sudah 3 tahun. Ya untuk proyek dengan waktu 1 bulan…tinggal dikalikan saja: Rp 250.000*160 jam= Rp 40.000.000

   Nilai 40 juta ini bukanlah nilai mutlak, jadi ada nilai resiko juga di dalam proyek, nah ini kita bahas di poin nomor 5 di bawah.

5. Resiko
   Segala hal tentu ada resiko, nah jangan sampe resiko ini terjadi dan menimpa kamu. Resiko mungkin bisa dihindari, tapi jika terjadi, pikirkan dampaknya dan apa antisipasinya.
   Resiko besar yang biasanya terjadi itu : project diberhentikan di tengah jalan (bahaya dong, ntar ketabrak), requirements berubah (nah ini dia yang biasanya bikin jengkel, udah bikin capek-capek, gak dipake, mesti diganti)
   Resiko kecil : perubahan minor aplikasi/software, jadi menyita waktu juga walaupun perubahannya dikit-dikit.
   Resiko juga mesti diklasifikasikan berdasarkan :
   1. kesempatan terjadi
   2. potensi yang diakibatkan (parah apa nggak?)
   3. kesulitan mendeteksi resiko supaya bisa dihindari

   Contoh : bugs di aplikasi
   Kesempatan terjadi : menengah lah, gak sedikit juga, gak banyak juga kesempatannya.
   Potensi yang diakibatkan : tinggi, kadang 1 bugs, bisa bikin aplikasi gagal jalan sebagaimana mestinya
   Kesulitan mendeteksi : tinggi, kadang bugs itu sulit banget dicari >.<

   contoh lain : server kebanjiran
   Kesempatan terjadi : kecil, ini sih kesempatan langka banget sampe-sampe server kebanjiran, kecuali kamu taruh servernya di pinggir kali ciliwung.
   Potensi yang diakibatkan : tinggi, server tenggelam, nangislah kliennya. Kamu juga mesti ikutan nangis!
   Kesulitan mendeteksi : kecil, lah wong hujan deres, knapa gak disingkirin tuh server ke tempat yang tinggi.

   Nah, resiko-resiko seperti ini yang mesti diperhitungkan. Terutama ya bayaran kamu. Misal kalo kejadian macem-macem, bayaran kamu telat, bagaimana?. Atau kamunya yang telat ngumpul kerjaan bagaimana?

   Dari sisi developer, pas di kontrak kerja, jangan lupa cantumkan aturan-aturan untuk klien (biasanya klien bikin aturan-aturan juga di poin proposal proyek (misal: apabila kamu telat mengumpulkan progress, atau progress tidak sesuai apa yang diharapkan klien, biasanya klien punya hak mengurangi harga proyek), nah, di sini kamu juga perlu membuat aturan-aturan atau klausa yang memperjelas batasan kamu selaku developer, misal: masalah konfigurasi server ataupun backend bukan tanggungjawab kamu yang seorang developer mobile app, masalah akun PlayStore tanggungjawab klien dan harus menggunakan data dari klien, atau apabila ada permintaan tambahan di luar scope pekerjaan yang telah disepakati, maka klien harus di-charge bayaran baru. Itu harus ada klause kerjasama tambahan yang menyatakan poin-poin apa saja tambahannya dan berapa besar biayanya. Nah yang model ini, developer sering luput, lalai, klien menghendaki revisi ini itu, tambahan ini-itu, tapi nilai proyeksi investasinya tetap. Jatuhnya kita yang rugi. 🙂
   Berikut ini ada gambar ilustrasi bagaimana harga sebuah proyek apabila dideliver ke klien lebih awal, tepat waktu atau terlambat. Dan berapa harga yang diharapkan. Dari sini bisa kamu kenali kalau untuk deliver sebuah progress pekerjaan ada resiko pinalty dari klien. Dan itu seharusnya kamu sudah antisipasi.

   

   Decision Trees

Sekian dulu yang dapat saya sampaikan, kurang lebih mohon maaf dan mohon dikoreksi 🙂

Terima kasih.

Pernyataan Jokowi soal “panggil programmer 2 minggu selesai” buat kalangan programmer melek dengan e-gov negeri sendiri

well, banyak sekali sisi positif gara-gara statement Jokowi “e-gov, panggil programmer 2 minggu selesai” di debat capres tempo hari. Di kaskus, facebook, twitter, berkumpul dan berdiskusi soal e-gov. Nama “programmer” pun jadi makin dikenal.

Namun, ada banyak gap yg terjadi di kalangan profesional TI, apalagi di kalangan fanatisme kedua kubu capres, akibat dari pernyataan Jokowi tersebut.

Sebagian kalangan mengkritik itu hanya bualan atau kalimat berlebihan dr seorang capres, krn sejatinya membangun sebuah aplikasi tidak hanya terkait programmer dan codingannya, tetapi ada metodologi dan tahapan pengembangan softwarenya, ditambah regulasi dan birokrasi dengan pihak pemerintah.

Namun sebagian kalangan menganggap ini tantangan besar buat indonesia, mereka menyadari bahwa e-gov tidak dikembangkan dalam satu malam, tp bertahun-tahun. Semua sudah jelas, apalagi untuk kalangan IT.

Korea saja misalnya, dr kuliah online pakar e-gov dengan judul “Ten Lessons from Korean Experiences of e-Government”, Professor Sang W. KIM, Ph.D. bilang kalau Pemerintah Korea telah melaksanakan secara berdampingan berbagai master plan, program dan proyek untuk menerapkan “masyarakat berorientasi informasi” secara nasional selama 20 tahun terakhir. Banyak project, dimulai dari 1987 (NBCN) sampai dengan e-gov nya mereka (2001-sekarang)

Di Indonesia sendiri, bbrp informasi yg sy dpt dr berbagai surat kabar online, menyebutkan sudah ada e-gov yang berhasil di beberapa daerah, di Jawa Timur (http://www.surabayapagi.com/index.php?read~Jawa-Timur-Terbaik-Kedua-di-Pemeringkatan-e-Gov-Indonesia). Berhasil di sini maksudnya sudah diuji secara teknis (aplikasi dan jaringan) dan tanggapan masyarakat.

Dan polemik di sini adalah e-gov yang sudah sukses tersebut tidak disosialisasikan oleh pemerintah pusat agar diterapkan di berbagai pemerintah daerah. Pemerintah tidak menjalankannya secara utuh. Alhasil, saat ini yang terjadi adalah tidak ada transparansi di kalangan pemerintah ke masyarakat. (mungkin ini yg dikhawatirkan bbrp elit politik, biar tidak ketahuan belangnya..makanya e-gov tdk dijalankan)

Kalo pak Jokowi memang pernah terlibat dlm pengembangan e-gov dan bilang “panggil programmer, 2 minggu selesai”, maka mungkin sebaiknya perlu diklarifikasi “selesai” di sini utk tahap apanya?  Karena beliau menyebut “programmer” bukan “vendor TI” maka mungkin bisa diasumsikan ini maksudnya “development-nya” (LOL) Drpd para simpatisan debat kusir dan para programmer berasumsi yg rumit-rumit.

Dan kembali lg ke topik yang disampaikan prof. Sang W. KIM, Ph.D, kalau Sistem Informasi tidak dibuat sekaligus, tapi bertahap. Dan suksesnya sebuah sistem informasi itu tidak ditentukan oleh ouput dari Sistem Informasi tersebut, tetapi hasilnya dapat dirasakan dan bermanfaat oleh pengguna. Manajemen data untuk mengelola atribut dalam e-gov harus lebih baik (Membangun Data Warehouse dari OLTP ke OLAP). Dan ini juga dipengaruhi bbrp domain sosial seperti Kepemimpinan (leadership), Strategi (strategi), Hukum & Peraturan (law & regulation) di pemerintah tersebut.

Pengembangan perangkat lunak dari sisi realita disiplin ilmu TI

X : “mas, aku pgn buat kyk gini, tp kalo aku pake software A, katanya mesti convert ke XML atau pake software B”
saya : “ya, kalo sy memang lebih ringan pake XML, pak, ntar ditaruh di project app.nya”
X : “kalo sy pake software A ini, mas, gimana? saya tuh pengennya kayak aplikasi yg di d*** atau di *****, tau kan mas?”
saya : “yup, pernah pake, pak, install juga kok, malah sy nemu yg lebih bagus lg, smooth di iOS dan Android, tp ya itu tetap saja enakan pake XML atau pake file tambahan dr Adobe AIR (SWF), pak”

Well, sebagai developer, jangan terpaku pada satu tools/software/teknologi saja, ingat, teknologi bisa kadaluarsa, bakal ada terus teknologi2 baru, dan sepantasnya memang kita masih harus terus belajar, biar bisa bersaing.

Ada pernah kejadian : “mas, knapa web servicenya pake rest, pdhal ada SOAP di sini” | “krn rest sdh terbukti lebih ringan, pak” | “lah, kata siapa? teman saya pake SOAP dgn php lancar-lancar aja”
beda case, pak, kalo itu kan infrastukturnya kyk gitu, sedangkan punya kita sekarang terlalu boros kalo pake SOAP. Banyak javascript di sini, kalo pake SOAP, ntar definisiin lg strukturnya di XML dll.. sementara timeline yang ada 3 bulan, pak.”

Nah, satu pelajaran lg, gk bisa kita generalisir satu masalah itu sama dgn masalah lain. Kasus lain, kamu bisa kerjain satu aplikasi dlm 1 malam, liat dulu skala aplikasinya.. krn sejatinya, permasalahan di dalam TI itu beda-beda, tidak bisa semua app itu bisa dalam 1 malam. Maka dari itu, banyaklah bergaul dgn sesama profesional TI, rajin berdiskusi (tidak sekedar bertanya, kadang orang lain jengkel kalo ditanya-tanya terus), dan kembangkan (sambil latihan terus).

Seseorang ingin dibuatkan aplikasi dgn metode re-use, kalau developer sebelumnya rapih dalam mengerjakan dan terstandar, enak, developer lain yg melanjutkan tidak akan keteteran, apalagi kalo dokumentasinya jelas dan lengkap. Tapi kalo yg sebelumnya develop gk selesai, ditinggal programmernya, terus developer yg baru disuruh gantiin dan lanjutin, apalagi tidak ada dokumentasi, dan mesti baca-baca codingan developer sebelumnya yg berantakan, apa gk stress tuh developernya? 

Kalo yang pernah saya hadapi di bank-bank (dulu kebetulan jd developer asp.net di Plasmedia kliennya bank kabeh | loh knapa skrg jd dev. Android? gk laku y? | klo sy skrg msh jd dev. asp.net, mungkin sy msh jomblo, mas soalnya hidupnya kost-kantor-mall-kost-kantor-mall, pas ramadhan aja, terawih gk pernah sempat, buka puasa sering di jalan/di kantor, makanya pas ada kesempatan S2, sy beraniin diri resign dan nyambi2 di jogja, eh alhamdulillah, salah satu klien sy, dr Pusat Kajian Hadis Jakarta menarik sy, skrg bs kenal ust. Lutfi, ust. YM, ust. Arifin Ilham, dll, sambil belajar agama dr beliau2 tsb), mereka (tiap bank) sudah punya core sistemnya, mereka tidak akan mengganti core sistem dan itu tetap berjalan (bahkan ada upgrade core sistem berkala), ketika ada penambahan aplikasi/software, ya biasanya tinggal re-use dengan beberapa penambahan modul dan desain sesuai pakem (guide book) yang sudah diberikan mereka. Dan itu bisa cepat selesai, bahkan untuk aplikasi besar, bisa 1-2 bulan kelar (bukan satu malam/2 minggu, krn birokrasi, kesiapan database, server, sampai konfigurasinya, dsb juga butuh waktu). Tapi gak tau juga ya kalo di tempat lain, pernah sm temen-temen grup PPP di DepKeu, denger-denger sampe ada debat internal antar pejabat dirjen. Itupun ngurusin database sampe cronnya juga njelimet di birokrasi. Syukur PMnya mental baja bisa ngadepin mereka. Dan 3 orang developernya : mas Mulia, Radita dan Nur Hidayat juga handal dalam development app.

“halah banyak ngomong, yg penting ngerjain!” |  “nah iya, yg penting kerjain, anda sudah pernah ngerjain yg kyk gitu belum? mengerjakan sesuatu itu harus rapih, tdk bisa asal jadi, tepat sasaran untuk stakeholdernya, tepat guna dalam fungsi, teknologi dan biaya. Karena sejatinya, software itu mesti memiliki prinsip : useful, usable dan beautiful. Dengan proses bisnis yang tertata dan metodologi yang tepat sehingga siklus pengembangannya berjalan sesuai rencana”

Satu lagi..software personal jelas beda dgn software pemerintahan. software setipe front-end jelas beda dengan setipe backend.
Satu teknologi di satu tempat itu cepat, belum tentu di tempat lain jg cepat. Ada beberapa karakteristik dan parameter yg mendukung/menghalangi hal tsb. untuk bisa dikatakan itu cepat/lambat.

Ada kalanya kita sbg. developer sudah berbuat sesuatu utk klien, tp kurang puas dgn hasil kerja keras sendiri krn terkendala waktu yang diberikan sedikit, ada kalanya kita nemu kelompok developer yang diberikan waktu banyak, tp ngerjainnya asal-asalan, yang penting duitnya turun..alhasil tidak dipakai dan merepotkan user. Dan banyak kejadian-kejadian dengan plot twist yang dihadapi developer. “Kalo ketemu klien yg awam TI, minta cepet, ya garap aja, kalo ntar klien ngerasa tidak puas atau kurang pas, tinggal buka penawaran baru” 

Yang jelas, teruslah berusaha sebaik mungkin, jangan pesimis, kalo ada orang berusaha menjatuhkan, coba gerak terus saja. Dan satu hal, tidak ada salahnya mendengar dan belajar dari yang sudah berpengalaman/ahli biar makin meningkat ilmu yang kita pelajari, dan tentunya jadi bermanfaat lebih luas hasil yang kita kerjakan.