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!

Desain antarmukanya dulu, baru hitung harga pengembangan Aplikasinya!

Pernah dapet kerjaan yang walaupun requirementnya sudah diberikan dengan detail, dalam bentuk FSD, tapi belum bisa berasumsi apapun bakal kayak apa nanti aplikasinya.

Di saat itu jadi “gambling” kalau kita buat proposal penawaran dikhawatirkan meleset dari budget dan time yang disepakati karena alasan di atas.

Bila sudah timbul keraguan seperti itu, maka ada baiknya memisahkan penawaran desain antarmuka dengan penawaran development.

Rekrut-lah designer UI/UX yang berpengalaman. Bila kerjaannya desain UI/UX app mobile maka rekrutlah UI/UX designer yang punya pemahaman dan pengalaman soal design pattern mobile, begitu juga dengan web app maupun progressive web app. Jangan sampe kita rekrut UI/UX designer web untuk mobile app, tau-tau yang didesain itu gak sesuai design pattern Android/iOS, yang ada ntar menyulitkan developer mengimplementasikan desain UI/UXnya.

Biarkan desain UI/UXnya clear dan jadi dahulu, sehingga kita tau ekspektasi klien seperti apa dan goal yang harus dicapai developer.

Pakai designer collaborative tool seperti Zeplin, Figma atau Marvelapp.
Tool ini sangat bermanfaat buat presentasikan desain UI/UX sehingga klien maupun developer dapat gambaran sempurna mengenai UI dan UXnya. Tinggalkan cara lama dengan kirim psd apalagi belum dislicing. Pakai tool design collaborative di atas juga sudah bisa export menjadi assets yang dibutuhkan di mobile app secara instant.
Bila desain UI/UX sudah siap 100%, dengan begitu developer dengan sangat yakin dapat menghitung berapa lama dan berapa biaya yang dibutuhkan untuk pengembangan aplikasi tersebut. Dan skup kerjaan dikunci sesuai desain UI/UX yang sudah disiapkan.

Jadi, apabila ada perubahan desain ataupun tambahan desain pada saat pengembangan aplikasi berlangsung, maka ini akan dianggap sebagai tambahan atau di luar skup yang disepakati.

Bila klien menghendaki sekaligus, maka kita selaku developer memberikan masukan mengapa desain antarmuka dibutuhkan di awal agar nantinya tidak ada yang missed antara yang diharapkan klien dengan apa yang dikerjakan developer.

Pertimbangan sebelum membuat aplikasi berbasis layanan (produk/jasa)

Beberapa waktu yang lalu, tim saya membuat aplikasi berbasis layanan jasa, bisa dibilang sudah 80% pengembangan selesai.
Dari awal meeting saya sudah salut dengan klien, “jujur, bu, saya salut Ibu bisa biayain semua sendiri buat infrastruktur sampai dengan development, karena aplikasi berbasis layanan jasa itu mahal. Mahal developmentnya, mahal juga post-developmentnya. Saya saranin ke depannya Ibu cari investor. Dari pengalaman saya handle aplikasi berbasis layanan jasa, ada dua yang saya tau itu sudah dapat investor, ada yang dari Lembaga Pemerintah, ada juga yang dari luar Indonesia”

Tiba-tiba, pas mau launch, muncul masalah ini dan itu.. ekspektasi si klien, setelah development selesai app bisa dipakai tanpa masalah, auto pilot, tinggal hasilin duit.

Realita-nya, di beberapa customer, app muncul error macem-macem, saya yang sudah lepas kontrak, tiba-tiba dihubungi kembali.

“Pak, ini app.nya bermasalah, ada customer gak bisa login” |
“masalahnya apa ya bu?” |
“bapak bisa saya telpon?”.

Setelah ditelpon, ditanya macem-macem, si Ibu ini kaget..

“loh, kontrak bapak sudah selesai ya?” |

“sudah lama, bu. Ibu belum diceritain bu Y” |

“Y gak cerita apa-apa, Y juga sudah resign Oktober lalu” |

“nah, kontrak saya juga sudah habis Oktober lalu, bu. Saya juga sudah serahkan sourcecode, technical guide document, dan juga installer app.nya ke kantor ibu” |

“wah kok saya gak tau ya” |
“masa’ gk ada yg cerita, bu? Pak C masih kan bu?” |
“masih, tapi pak C juga bilangnya semua yang tau itu ya Y” dari diskusi ini saya cuma mengkerut kening 😅

“Terus gimana ini, pak?” |
“ya Ibu harus rekrut kami sebagai maintenance developer bulanan” |
“loh, kok kontrak kerja lagi, pak?” |

“ya iya, bu, kan kontrak kemarin sudah berakhir, masa’ kami tiba-tiba langsung nimbrung aja benerin kerjaan” |
“hehe..kira-kira bayar berapa, pak?” |
“kami ada biaya maintanence bulanan, bu..kami kirim quotation-nya ya”

Dan muncul masalah ini dan itu, mulai dari migrasi, ubah fitur, dll. dibilang..

“bapak kan sudah kami rekrut, masa’ ada biaya lagi, pak?” |
“ya ini bukan maintenance sih, bu, sudah dianggap sebagai changes request (CR), kan kami sudah bikin catatan di quotation mana aja yang bukan kerjaan kami” |
“ya tapi kan bapak yang develop, harusnya tanggungjawab bapak dong”..

Menghadapi klien memang kudu extra sabaaar 😅

“iya, bu, tapi gak gratis, kami juga di sini kerja, kontrak kerja sudah selesai, ada baiknya Ibu rekrut aja developer tetap buat menjaga sistem di kantor Ibu, kalo rekrut maintenance developer ya cuma support aja. Lagian sistem kayak gini gak bisa ditinggal gitu aja gak ada yang jagain, bu, Ibu harus punya tim TI internal yang menjamin keberlangsungan sistem ini berjalan baik, mulai dari PM, system analyst, UI/UX engineer, development engineer, QA engineer, dan sys admin/devops“, kalo ngandalin kami ber-3 ya gak mungkin bisa, apalagi ini reportnya banyak sekali yang masuk dari customer.”

Sayapun berceramah panjang lebar.

“tapi tolong, pak, kami disupport, kami sudah percayakan bapak selama 1/2 tahun ini..” |
“ya kami support sesuai job desc kami, bu.” |
“ini jujur, pak, dananya belum sampai ke kami, saya juga sedang berusaha cari investor” |
“iya, bu, kalau kayak gini mau gak mau Ibu cari investor, jumlah user juga sudah banyak kan” |
“iya, pak, ini tagihan server sudah tembus 24juta”

saya baca ini kaget. Kok cepet ya, apa karena storagenya kepake banyak, karena app. customernya butuh upload banyak data image.

Dari sini tiba-tiba si klien ini berpikir agak berbeda,

“Pak, apa boleh kami pending bayaran tim bapak, kami soalnya terkendala biaya server” |
“waduh, gak bisa, bu, ini bukan keputusan saya sendiri, tim yang kerja, masing-masing freelancer” (soalnya dulu juga pernah kepending 1 bulan oleh ini klien bayaran kami, masa’ dipending lagi)

“Wah, bu, Ibu tau gak kenapa aplikasi berbasis layanan jasa kayak Grab, Gojek, dan Ruang Guru..itu tiap tahun slalu buka lowongan kerja developer, QA engineer.. (sambil saya nyodorin link job vacancy-nya buat barang bukti…), ya karena sistem mereka gak autopilot, itu post-development mereka makan biaya ratusan juta sampe M per bulan loh, bu, selain bakar duit, jagain sistemnya biar tetap lancar tanpa masalah juga mahal. Tiap hari tim developernya ada aja kerjaan benerin bugs di beberapa device, itupun yang ngetest bukan developer, tapi tim QA Engineer, dan mereka dibekali beragam HP Android dan iOS, bu”

Ibu ini diem gak berkomentar.. cuma bilang…

“ok, pak, terima kasih insight-nya”

Ini cerita dah mirip dengan cerita klien-klien yang lalu-lalu, seragam, rata-rata orang sini menganggap sistem/app walau tampilannya kecil, ketika sudah jadi, langsung bisa menghasilkan duit, autorun, autopilot tanpa harus “dijagain”…kok enak ya kalo dipikir-pikir 🤣

Tahun 2012-2013, saya pernah punya pengalaman direkrut perusahaan di Jakarta sebagai Maintenance Developer, ya kerjaannya sebagai support, balesin chat soal development, bantuin PM balesin email, dateng ke tempat klien buat maintain webnya klien, dan kadang magabut (makan gaji buta) karena tidak ada laporan bug, tapi ya tetap digaji bulanan di Jakarta.

Pas di Jogja juga pernah sebagai support untuk sebuah startup koki masakan, namanya “Stagiaire”..bikin app resep masakan seperti cookpad, direkrut buat maintain, dibayar 6,5jt/bulan dan kerjanya gak pasti ada tiap hari, sehari cuma 3-5 jam aja. (Jadi bisa saya sambi kerjaan lain). Artinya ya perusahaan ini paham, “lo gw bayar buat support, siap kapan aja pas ada masalah di sistem/app.nya”.
Setelah kerjaan maintain aplikasinya selesai, dilanjut diujicoba QA engineer, dicari bug-nya, dilaporkan balik ke developer, sampai test case passed, langsung dicoba tim production. Jadi kalau sudah lolos QA dari development, itu belum selesai, bisa jadi pas production bermasalah, ini ntar direproduce QA issuenya dari Production, kemudian balik ke developer, setelah diperbaiki, balik ke QA dan selanjutnya balik ke Production lagi, kalau sudah OK, barulah dilepas ke publik.

Itulah kenapa perusahaan yang bergerak dibidang layanan (service) produk/jasa, mesti recruitment nya banyak. Soalnya timnya juga banyak, per tim ada 4-6 orang. Dan kerjaannya serba cepat dan agile.

Di Jakarta dah biasa kayak gitu untuk kelas perusahaan. Tapi buat klien personal memang harus dibuka pemahamannya dengan sabar. Jika hendak membuat sesuatu yang besar, butuh dana besar, dan tim yang besar agar bisa berlari kencang.

Melompat melewati zona nyaman Programmer

Harus diakui yang berperan penting membekali saya untuk melewati zona nyaman programmer adalah 2 perusahaan: Plasmedia dan Dimo.
Dua perusahaan ini suasananya hidup, sangat fleksibel. Misal berhalangan karena anak/keluarga sakit, tidak dibilang “wah gak profesional dong alasannya keluarga”, tetapi kantor-kantor tersebut toleransi, asal keterangannya jelas dan tidak menghilang.

Dari situ saya jadi menerapkan ke tim developer yang saya rekrut, “apapun beritanya kabarin, mau soal keluarga, padam listrik, dll..dengan saya terbuka saja, gak akan saya cap gak profesional. Kalo gak ada kabar barulah tidak profesional”
Bahkan ada jam olah-raga, di Plasmedia dulu futsal rutin per minggu, pas di Dimo sempat beberapa kali Badminton. Bos-bosnya juga easy going, tidak horor/killer, dari situ saya belajar mengenai seorang leader, bukan seorang boss yang hanya bisa perintah.
Di Plasmedia, atasan saya ada yang muslim dan ada yang non-muslim, semuanya baik, tidak pernah urusan agama jadi pembeda. Bahkan kalau waktunya sholat ya ada break buat sholat. Jum’atan juga bareng dengan atasan-atasan yang muslim.
Di Dimo, atasan saya non muslim, tetapi pas kerja remote, misal di Jogja kedengeran suara adzan melalui Skype, yang di Jakarta langsung bilang: “di Jogja sudah adzan ya, kita break dulu, silahkan yang mau sholat-sholat dulu, setelah itu kita lanjut diskusi”. Dan klien (klien kami waktu itu Sinarmas), bisa dikondisikan beliau, “pak, bu, ini tim developer Jogja mau sholat dulu, kita break dulu, setelah ini kita lanjut diskusinya”
Dari sini saya bisa belajar mengerem, balance antara kerjaan dengan agama. Jangan grasak-grusuk.

Pas di Plasmedia, atasan saya bernama Pak Agus Salim slalu mengajak saya (berdua) bertemu klien-klien, saya ingat betul kata beliau “Wid, ntar lu belajar ya liatin gua ngomong dengan klien, cara bertemu klien gimana, ketemu siapa aja, biar ntar lu bisa mandiri”. Dan betul, dari situ saya bener-bener diterjunkan sendiri ke Bank Export Import (eximbank), BRI pusat, BNI46 pusat, dan Danamon pusat. Dari situ yang kaku gak ngerti apa-apa, jadi belajar berani, dan dari situ saya pahami kalau atasan saya mengajak saya agar melewati boundary. Dan jadi pelajaran berharga buat saya sampai sekarang di dalam dunia perproyekan. Walaupun di Plasmedia saya cuma 1 tahun pas.

Setelah kembali ke Jogja, gabung Dimo, saya juga sering curhat ke atasan saya, namanya pak Albo Gitananda. Salah satu perkataan beliau yang sampai hari ini saya ingat adalah, “ketika saya tidak ada, kalian harus mandiri memanage pekerjaan ini, bagaimana membuat tiket di Jira, membreakdown persoalan menjadi task kecil-kecil, mengatur target deadline, dan yang lebih penting adalah jadi bekal buat mas Widy, dkk agar nanti kalau sudah naik tingkat ke level manajerial tidak kaget, tho pasti nantinya pengen naik tingkat juga kan demi keluarga. Saya juga dulunya programmer, mas. Bahkan skill saya serba setengah-stengah, backend bisa setengah-stengah, mobile app juga bisa setengah-setengah, di CIMB juga saya ngoding, tapi perlahan tapi pasti, saya juga belajar level atas saya, kalo diajak bos-bos saya meeting ya ikut aja, perhatiin sikap mereka menghadapi klien, gaya bicara, intonasi, dll..semua saya perhatiin”
Di Dimo-pun yang setahun lebih kemudian ditarik ke Sinarmas guna melanjutkan digital banking (e-money), dari situ saya banyak belajar.

Dan sekarang sudah melalui itu, tidak jadi programmer lagi, membawa beberapa tim di beberapa proyek, dari yang murah hanya 5-7 juta sampai yang ratusan juta. Bekal yang tidak pernah saya lupakan, dan yang jelas masih kurang, karena harus banyak belajar lagi dari para senior-senior.

Dan dari situ juga, saya bisa memetik pelajaran, bila ingin naik ke tingkat lebih tinggi, maka perhatikan dulu, seperti selogan Vini, Vidi, Vici (saya melihat, saya datang, dan saya menang). Sambil belajar level lebih tinggi. Terkadang ada saja programmer yang ngeluh, “lah, database dan rancang arsitektur kan bukan tugas saya, ngapain saya ikut-ikutan”, “lah, ngapain saya ikut2an ketemu klien, ikut rapat, itukan tugas PM!”, yang seperti ini berarti developer yang menolak diajak maju.

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.

Perubahan skup pekerjaan di tengah proses pengembangan?

Proyek itu cirinya 3: Waktu, Budget, dan Skup Pekerjaan terbatas.

1. Waktu
   Waktu, jelas terbatas, dibatasi misal 3 bulan dari project start sampai dengan project selesai.
   Di dalamnya terdapat banyak fase mulai dari perancangan FSD/skup pekerjaan (dibarengi interview atau rapat dengan klien), kemudian tandatangan PKS (PO) dan surat kontrak kerja, kemudian perancangan sistem (wireframe) dan databasenya, dilanjut desain UI sampai dengan development dan testing, baru kemudian proyek dinyatakan ditutup.
2. Budget
   Budget juga memiliki estimasi anggaran yang jelas sejak awal, tidak pernah mendadak budget di tengah-tengah naik mendadak, gak pasti, ini sudah tidak sehat.
3. Skup pekerjaan
   Scope juga jelas terbatas, apa yang sudah disepakati di awal, itulah yang dikerjakan. Maka dari itu skup pekerjaan harus didefinisikan sedetail-detailnya. Biasanya pihak vendor/developer akan bertanya hal-hal yang kurang jelas terkait skup pekerjaan, fitur, input dan output yang diharapkan dan desain antarmuka yang dikehendaki.

• Tambahan: SDM, dari awal personilnya sudah jelas di awal, misal terdapat 1 orang sistem analis, 1 orang db design, 1 orang sysadmin, 4 orang developer web (backend dan frontend), 2 orang designer UI (app dan web), dan 2 orang developer app. Artinya jika di tengah-tengah terdapat developer yang keluar ataupun bertambah, ini juga sudah tidak sehat.

Lantas, bagaimana bila ada perubahan skup pekerjaan?
Harus disepakati bersama antara kedua belah pihak, bahwa tambahan tersebut sebagai “change request” atau permintaan perubahan/tambahan.

Biasanya kedua belah pihak diminta segera menyusun adendum. (cek kbbi: https://kbbi.web.id/adendum)

Adendum menurut UU no. 54 tahun 2010, pasal 87, ayat 1, yaitu 4 hal:

1. apabila ada perubahan, yaitu penambahan atau pengurangan volume dari kontrak kerja,
2. apabila menambah jenis pekerjaan,
3. apabila mengubah spesifikasi pekerjaan
4. apabila mengubah jadwal pekerjaan.

Maka harus dimuat ke dalam adendum.

Jelas ya sampai di sini, di UU cukup jelas loh, jadi kalau ada klien meminta perubahan atau hal-hal lain yang gak sesuai kontrak kerja, ini menyalahi UU. Untuk itu juga sebagai pihak developer harus tegas dan teliti di dalam membuat kontrak kerja bersama.

Adendum ini sering terjadi, terutama apabila ternyata proses bisnis yang sedang berjalan sudah tidak bisa dilanjutkan lagi, biasanya karena pengaruh permintaan pasar (customer), dan harus disesuaikan agar aplikasi tersebut dapat dipakai nantinya, atau karena ada desakan momentum waktu (misal menyambut ramadhan yang segera tiba), maka waktunya yang tadinya minta 3 bulan, diubah menjadi 2 bulan, atau hal lain.

Mengapa adendum ini perlu? karena jika tetap dipaksakan sesuai dengan kesepakatan awal, yang ada proyeknya jadi cacat sebelah, merugikan salah satu pihak ataupun keduanya.

Bayangin tiba-tiba QA minta sesuatu dari negative case “mas, ini kalo gak dibikin, kasian user yang pake” | “lah, ini baru ada pas development jalan, mas, saya ngikuti kesepakatan awal, kalo gak ya dicharge sebagai tambahan” | “lah, itu kan kewajiban masnya sebagai developer” | “lah, saya kerja di sini sbg proyek, mas, bukan karyawan, kalo karyawan mah siap dengan segala pekerjaan, kalo proyek kan harus sesuai kesepakatan awal, jika tidak mah kami yang rugi” | “pokoknya itu tanggungjawab anda, mas..desain sudah disiapkan” | “lah, desainnya jg baru ada.., anda terlalu kaku dan terlalu ideal sbg QA, sedangkan waktu dan budget proyek ini terbatas sekali, kalo saya turuti semua ya saya yang rugi”

Bukan soal “terlalu perhitungan banget sih“, di manapun proyek selalu sama, dengan vendor software lainpun juga demikian, artinya memang proyek itu terbatas, baik waktu, biaya, scope.

Tidak ada tanpa batas. Kalau gak terbatas, ya mending jadiin developernya sebagai karyawan saja, daripada jadi “slave never ending project“.

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.

Fenomena Gunung Es

Ilustrasi gunung es

 

Di dalam dunia proyek pengembangan aplikasi atau software, tidak jarang bertemu “gunung es”

tahukan kamu maksudnya? 😁 ya, meleset dari perkiraan atau estimasi, ntah itu spesifikasi, harga ataupun waktu. Terlihat kecil, ternyata di dalamnya sangat besar.

 

Sayapun beberapa kali mengalami hal seperti ini, perkiraan saya makan waktu sekian dengan biaya sekian, ternyata ada 1-2 fitur yang kurang detail atau kurang dalam, dan ternyata menjadi melebar ke mana-mana dan memperburuk keadaan terutama waktu.

Harga jelas sulit diubah, karena model proyek seperti ini biasanya sudah ditetapkan di awal. Akan berbeda situasinya kalau menggunakan “tarif durasi” seperti di upwork.com atau freelancer.com

 

Nah, jika sudah terjepit di situasi seperti ini, segeralah keluar dari “zona nyaman” stuck di “gunung es”. Saya biasanya melakukan negosiasi kembali dengan klien, agar tidak merugikan keduanya.

Kenapa disebut “merugikan keduanya”?

Karena klien jelas rugi, bisnis dia tidak jalan, molor, padahal target production bulan Februari, tapi sampai Maret tidak selesai. Jelas rugi, bisnisnya tidak jalan.

Dan si developer juga jelas rugi, yang tadinya harusnya nerima bayaran Februari, sampe Maret puasa tidak mendapatkan bayaran tapi masih lanjut kerja terus. Jelas rugi, tidak ada pemasukan, kasihan keluarga.

 

Nah sebelum terlalu lama stuck, negosiasi wajib dilakukan, obrolinlah dengan baik ke klien, kalau situasi “gunung es” terjadi. Komunikasi persuasif sangat penting, yaitu membicarakan solusinya bersama, sebagai contoh bisa dipisah fase development-nya, misal target bulan maret sampe 8 tasks saja, setelah itu lanjut termin pembayaran, dan sisa tasks-nya dibuat bayaran per item atau per durasi, misal bayaran per bulan. Atau coba ajukan penambahan biaya, jelaskan kalau fiturnya sudah melebar dari kesepakatan dan ada fitur yang belum spesifik, biasanya klien bisa memahami, ntah mungkin skup pekerjaannya diperkecil atau memang termin pembayarannya ditambah, atau solusi-solusi lain yang masih banyak kemungkinan yang bisa dibicarakan disesuaikan dengan situasi dan kondisi.

 

Jadi, jangan malah menghindari klien, ngeluh berat menjalankannya dan stuck di situasi tersebut. 😊