Paradigma

Tadi teman bilang: “saya di Java sudah 5 tahun, pak, tapi di rails belum setahun, kalau saya masuk tim itu, bisa-bisa saya jadi kroco”
Lantas teman yang senior satunya bilang: “pengalaman kerja kan bukan dilihat dari berapa lama kamu pengalaman di bahasa pemrograman itu..tapi dari selama ini yang kamu kerjakan, problem solving-nya seperti apa, achievement yang diperoleh apa saja”.

Banyak yang bisa coding, coding malah mudah, bisa otodidak, tapi yang memiliki skill problem solving itu sedikit.
Berapa banyak di grup developer bertanya “mas, aku liat gojek aplikasinya kayak gini, bikinnya gimana ya?” | “yaelah mikirnya langsung gede, mbok ya dipecah satu per satu fiturnya, cari masalahnya, terus cari solusinya…”

Logika coding seperti pemakaian logical expression, dan lain-lain, kalau memang logikanya jalan, mau coding pakai bahasa apapun ya mudah tinggal belajar syntax pemrograman tersebut saja. Bahkan dengan sangat mudah seseorang developer java beralih ke javascript.
Terus apakah yang mempengaruhi hal tersebut? Paradigma!

Paradigma adalah sudut pandang terhadap suatu masalah, realitas, keadaan, dan sebagainya. Dalam pemrograman pun dikenal istilah paradigma pemrograman, yakni sudut pandang atau strategi analisa khusus yang diambil untuk menyelesaikan suatu masalah pemrograman.
Kalau sudah bisa paradigma, mau belajar programming apapun jadi mudah. “if you know how to code, you can code in anything“. Tidak perlu menghapal syntax pemrograman, nanti juga mahir sendiri setelah googling>stackoverflow dan langsung ke kasus.

Nah, balik ke pengalaman kerja tadi, kalau sekedar teori, itu hanya pengetahuan yang masih “terkurung”. Sedangkan wawasan, lebih ke kesadaran emosional, ketika seseorang sudah berpengalaman, wawasan ini membuka “kurungan” pengetahuan yang selama ini dipelajari didasari pada yang telah diamati/dirasakan/kebiasaan. Dan paradigma menjadi seperangkat aturan dan aturan tsb melakukan dua hal:
(1) menetapkan dan mendefinisikan batasan; dan
(2) Ini memberitahu kita bagaimana berperilaku di dalam batas-batas agar tercapai tujuan.
Bagaimana belajar paradigma? ya bertahap dari pahami konsepnya, teorinya, baru memperkuat wawasan dari pengalaman.
Itulah mengapa seseorang problem solver itu paradigma-nya bagus.

Advertisements

Mendapatkan klien proyek lokal sebanyak mungkin

Coba nulis berdasarkan pengalaman di lapangan.
Mendapatkan klien lokal di proyek itu bukan “pufff…simsalabim” tiba-tiba datang proyek.

Tetapi membangun kepercayaan yang dijalin secara terus menerus.

“Lu ngapain sih wid, aktif FB terus… apa aja diurusin…”

Dulu sehabis lulus kuliah S1, saya bekerja di perusahaan vendor TI di Jakarta. Dan tugas saya slalu datang ke tempat klien-klien si vendor, karena saya sbg sr. maintenance developer .NET (dengan CMS dotnutnuke). Datang sendirian, dan kenal berbagai orang bank-bank di Indonesia. Tapi dari situ jadi kenal pribadi dan jadi teman. Lepas dari situ kembali ke Jogja, klien-klien tsb saya jadikan teman di Facebook.
Saya sering komentar status klien-klien saya di facebook, hanya sekedar tegur sapa..dan membangun kepercayaan. Bukan mengharapkan biar segera dapat proyek, dengan membangun relasi, seseorang sudah memperluas silaturahim. Toh siapa tau kita yang butuh bantuan, atau mereka yang butuh bantuan kita.

Ok, buatlah personal branding di jejaring kalau kita ini memang bisa ngoding, biasa bermain proyek dan bisa membangun sistem ataupun aplikasi.

“Eh, tapi banyak loh yang ketipu pencitraan, keliatan di jejaring pinter, eh pas ketemu langsung, ternyata mengecewakan”

Nah itu, jangan coba-coba memakai topeng kepalsuan.

Ok, sambil merutinkan tsb, coba berkunjung ke grup-grup FB seputar programming ataupun seputar proyek. Mesti ada tawaran. Naaaaah, dari situ mulai inisialisasi diri ke dalam proyek lokal.

Lakuin seserius mungkin. Ok, udah? teliti juga ya, pilih klien yang bener-bener bisa diajak kerjasama. Soalnya ada beberapa tipikal klien yang “agak gak masuk akal”. Kalo dah deal..lakukan sebaik mungkin, dari sinilah bangun lebih dalam kepercayaan tsb. Yakinkan bahwa “saya bisa bekerjasama dengan baik dengan anda”
Bangun komunikasi aktif dengan klien. Contohnya?
Ya laporin kerjaan jangan nunggu ditagih, tapi aktif memberi berkala, misal tiap hari di sore hari atau tiap minggu. Jangan sekedar bilang “pak, halaman ini sudah saya buat” <- ini gak informatif.
Tapi bilang yang kayak gini “pak, saya sudah bikin halaman ini, di halaman ini bapak bisa lihat sudah ada form a, b, c..” sambil nunjukin bukti. “bapak, bisa akses di halaman web ini, dengan username dan password abc, xyz”
Kalimat komunikatif ini salah satu bentuk keprofesionalan kita. Di email ataupun di aplikasi chatting.

Ok, kalo kerjaan tuntas, mintalah “referral” dari klien, bisa berupa rekomendasi di linkedin atau sekedar testimoni di halaman web/jejaring pribadi, atau sekedar mention di statusnya si klien. Kok minta? soalnya kalo nunggu, bisa jadi klien sibuk atau lupa.

Kalau sudah, coba bangun relasi dengan perusahaan startup atau software house lokal di daerahmu, siapa tau nanti kita direkrut buat kerja proyek bareng software house. Atau bisa jadi karena ada “bendera”, bisa dapet kerjaan proyek pemerintah. Sekedar buat pengalaman, seru loh.

Dari situ, tinggal rutinkan saja..sudah cukup untuk bisa mendatangkan proyek-proyek lokal 🙂

Dan jangan jadi “kacang lupa kulitnya”, kalo sudah dapat klien, begitu selesai proyek, jangan putus komunikasi, bangunlah terus komunikasi itu, walaupun sudah tidak ada perlu.

Disclaimer: tulisan ini tidak ada maksud menggurui, justru saya masih harus banyak belajar, dan justru ada banyak yang lebih sukses dalam hal proyekan. Tapi sebisa mungkin tak share biar ilmu ini bermanfaat.

Dari pengalaman, dengan membangun kepercayaan, saya bisa mendapatkan klien sampai ke Sumatera-Utara dan Balikpapan, saya kerja dari Jogja, dan bahkan tanpa pernah ketemuan langsung? loh …kok bisa? iya, karena saling percaya. Tapi ada juga yang minta ketemuan pas tandatangan kontrak kerja/MoU, penyerahan sourcecode dan dokumentasi pas di Jakarta dan Bandung, dan semua ditanggung klien.

Bacaan menarik:
https://clientflow.io/blog/33-ways-to-get-more-clients/
http://www.thedigitalprojectmanager.com/project-red-flags-…/

Kerja Remote

Secara definisi, kerja remote dapat diartikan kerja jarak jauh dari rumah dan berkomunikasi dengan perusahaan via email/telpon/aplikasi chat.[1]

Apakah seorang freelance atau project-based job sudah pasti pekerja remote?
Tidak, dari beberapa berita, termasuk dari media forbes [2], pekerja remote itu bisa jadi memang pegawai tetap, namun ia bekerja jarak jauh karena alasan tertentu.
Dan bisa juga seorang freelance, yang mendapatkan job kontrak/project-based, yang ia peroleh secara online.

Di Indonesia, sangat jarang perusahaan yang menerapkan pekerja tetap yang diperbolehkan remote. Ada, tapi sangat jarang. Alasannya ada beragam [3]:

1. Komunikasi
“eh lu gk ngantor? ngapain?” | “ya kerja pak, tapi dari rumah” | “gmn gw tau lu kerja di rumah? bisa aja lu ngegame”
Banyak perusahaan enggan menerapkan sistem kerja remote karena biasanya komunikasi tidak begitu lancar. Apalagi untuk lingkungan start-up yang ketat, penuh dengan target jangka pendek dan dinamika bisnisnya cenderung tinggi. Dengan kondisi tersebut, akan sangat rawan bagi perusahaan terjadi miss-communication dan terlambatnya “delivery” pekerjaan sesuai dengan yang ditargetkan. Mengapa? karena komunikasi menjadi kurang jelas.
Selain itu trusting level jadi persoalan, apakah orang tersebut memang sedang bekerja dari rumah atau sedang melakukan yang lain.

2. Kultur
Seorang pekerja biasa bekerja dengan kultur bekerja di perusahaan, menerima kerjaan dari atasan secara langsung, dan mendiskusikan pekerjaan dengan tim secara tatap muka. Tiba-tiba harus menjadi “remote worker” tentu akan mengagetkan orang tersebut.
Dan sebuah perusahaan yang demikian, akan sulit memperkerjakan pekerja remote apalagi sering terjadi diskusi secara tatap muka dan rapat project dilakukan di dalam ruangan tertutup. Persoalan urgensi, ketika remote worker harus segera hadir di kantor karena rapat yang harus dijelaskan secara tatap muka, namun tidak bisa hadir, tentu perusahaan akan mengalami kerepotan menghadapi kondisi tersebut.

3. Bukan sebagai team
Ketika seseorang bekerja secara remote, kecenderungan individualisme terbuka lebar. Mereka bekerja dalam tim, tapi melakukan semuanya berjalan sendiri-sendiri, walaupun ada software project management dan issue tracker. Diskusi antar anggotapun nyaris tidak pernah, malah yang terjadi, kerjakan task->set status di project management software->lapor PM->done->doing another task (looping)

================================

Pengalaman pribadi, dari 2011 sampai 2016 kerja remote dengan Pusat Kajian Hadis (karyawan tetap remote) dan beberapa project-based dengan klien dari Humanitarian Open Street Map Jakarta, JasaConnect Jakarta, BNI pusat Jakarta, Radio Dakwah Islam (Jambi), PDAM Palembang, dll (kantor di luar Jogja, kerja dari kost/kontrakan dan rumah di Jogja), dari 3 alasan di atas, memang kendala no.1 beberapa kali terjadi, tidak sering, hanya beberapa kali, terutama ketika inisialisasi project dan transfer-knowledge. Antisipasinya adalah: sering komunikasi (daily call) baik via Skype/slack ataupun telepon. Dirutinkan setiap hari, biasanya di akhir jam kerja. Untuk tracking pekerjaan juga dilakukan setiap hari, status pekerjaan dari in-analysis>in-development>in-testing>dll..perlu segera diset dan tidak ditunda untuk mencegah “misscommunication”, selain itu delivery pekerjaan secara remote juga harus sedetail mungkin apa saja yang telah dikerjakan per hari melalui tulisan dengan menggunakan kata-kata yang jelas, padat dan informatif, berbeda dengan bekerja “on-site” di kantor, yang bisa disampaikan dengan berbicara langsung dengan atasan. Kenapa? biasanya saya bekerja dengan tim programmer, ada saja developer yang delivery pekerjaan, memberitahukan status pekerjaannya hanya dengan tulisan “mas, task A sudah digarap”, sudah gitu aja, saya gak tau dia push kerjaan di mana, buktinya mana, testingnya gimana, jam berapa, apa saja yang berubah/ditambahkan, akhirnya jadi repot harus cek sendiri di git source-codenya. Ingat, bekerja remote itu sebisa mungkin tidak merepotkan, dibuat sama kondisinya sama seperti bekerja di kantor. Informasi yang dibutuhkan PM sebisa mungkin inisiatif diberikan tanpa harus diminta.

Referensi:
[1]http://dictionary.cambridge.org/dict…/english/remote-working
[2]https://www.forbes.com/…/how-remote-work-is-changing-and-…/…
[3]https://www.inc.com/…/work-from-home-won-t-happen-in-my-com…
https://blog.hubstaff.com/reasons-companies-fail-remote-wo…/

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 🙂

Pentingnya bagi seorang designer mobile app. memahami “design pattern” dan guidelines desain aplikasi

Waaah…. desainer baru…. begitu dilihat pengalamannya ternyata basic-nya adalah desainer web yang sudah bekerja selama 5 tahun lebih.

Tiba-tiba kebutuhan akan aplikasi mobile begitu tinggi, alhasil beberapa desainer web beralih profesi mengerjakan desain-desain antarmuka aplikasi mobile.

Nah, ada kesalahan fatal yang terjadi, menyebabkan potensi kesalahan di dalam pengembangan, ntah itu timeline menjadi tambah panjang, developer yang menjadi sulit mengimplementasikan desain yang diberikan, dan sebagainya.

Siapapun yang menjadi desainer aplikasi mobile, dimohon jangan samain seperti mendesain website yah..hehe
Desain aplikasi platform apapun itu, baik itu iOS, Android, Windows Phone, Blackberry, ada prinsip-prinsip desain yang harus dipahami, ada guidelines yang harus dipatuhi. Setiap OS mobile punya pattern desain sendiri yang mesti diikuti. Tidak bisa “semau gue, menurut gue itu keren”.

Seorang designer antarmuka aplikasi mobile mesti mendalami pengetahuan seputar perangkat OS platform tersebut, mindset-nya juga harus diubah. Sama seperti pada waktu seorang designer web mendapatkan job dari perusahaan ternama (pernah saya alami di BNI, Jakarta), mereka (BNI…yg saya tau) punya guidelines terhadap website mereka. Misal : Warna tema website mereka.. di guidelines-nya dijelasin hexa codenya apa, logo web-nya pakai yang mana, resolusi “width height“-nya berapa, ukuran hurufnya berapa, pake typeface apa, dan sebagainya..maka terjadilah konsistensi desain di web yang dimiliki perusahaan ternama tersebut.

Begitu juga dengann platform mobile. Antarmuka di aplikasi mobile punya konsistensi, ketika mendesain layout, peletakan menu slalu di sebelah mana, icon aplikasi bentuknya seperti apa, di hape layar kecil resolusinya berapa, di hape layar besar resolusinya berapa, kalo bikin tab taruh di mana, default typeface pake apa, dan sebagainya.

Saya rasa tantangan yg mereka (designer web) hadapi ketika menjadi designer apps adalah bagaimana caranya agar menguasai design interaksi dan UX-nya.

Untuk mengubah sebuah tampilan website menjadi tampilan aplikasi yg mungil, layar terbatas, jangkauan pengguna ketika menyentuh layar bagaimana, dan hal-hal lain yang perlu diperhatikan… bukanlah sebuah pekerjaan yang mudah. Sebagai contoh : ketika mengatur ukuran huruf yang nyaman dibaca pengguna aplikasi, mengatur komponen apa aja yang dapat dijangkau pengguna aplikasi ketika menyentuh layar, dan dari langkah tersebut, desainer masih dibuat pusing lagi ketika menguji hasil karya antar mukanya.

Si desainer sudah merasa yakin mendesain aplikasi di hape layar besar (di atas 5 inch), ternyata di hape layar kecil membuat pengguna kurang nyaman, terkadang mengalami masalah komponen layout-nya oversize di hape layar kecil, terkadang ukuran hurufnya kegedean diterapkan di hape layar kecil, dan masih banyak lagi masalah-masalah yang mungkin terjadi. Dan akhirnya si desainer aplikasi  mencoba mengatur ulang layout-nya.

Dengan kata lain, mau tidak mau si desainer harus menyiapkan beberapa layout design untuk beberapa jenis ukuran layar smartphone maupun tablet (dari ldpi, mdpi, hdpi, xhdpi, sampai dengan xxhdpi).

Seperti yang sudah saya jelaskan, masing-masing perangkat mobile, baik itu smartphone maupun tablet punya UX berbeda. Apalagi beda platform, tentu User Experience di tiap platform berbeda. Pengguna device Android sudah terbiasa melihat menu dengan slide ke kanan atau tap pada pojok kiri dan kanan, sedangkan pengguna device iOS terbiasa dengan menu slide di bawah ke atas, dan berbeda lagi dengan pengguna WindowsPhone, menu disajikan per tab dengan label yang besar di atasnya, tidak ada menu pojok seperti di Android ataupun menu bawah seperti di iOS. Setiap platform punya guidelines-nya bagaimana meletakkan komponen design, seperti yang saya sampaikan yaitu menu, slide menu, tombol, tab, tabel, dan komponen lainnya.

Biasanya, seorang desainer itu melakukan coret2 dulu di wireframe (wireframing), diskusikan dengan tim (ntah dengan desainer web ataupun aplikasi mobile yang lain ataupun dengan developer dan system analyst) apa yang telah di-wireframing sudah pas atau belum, kemudian periksa guidelines di docs platform tersebut apakah sudah sesuai pattern OS tersebut atau belum, kemudian UX-nya bagaimana.. apakah sudah sesuai dengan kebiasaan pengguna di platform tersebut atau belum, setelah itu baru memulai perbaiki designnya agar menjadi tampilan antarmuka aplikasi yang ideal yang siap diimplementasikan ke dalam aplikasi.

Bagi teman-teman yang belum mengetahui guidelines atau panduan mendesain di masing-masing platform mobile, bisa merujuk ke link berikut ini :
Semua udah ditulis lengkap, resmi dan terstruktur, tinggal kitanya mau belajar dengan tekun atau tidak.
iOS : https://developer.apple.com/…/UserExp…/Conceptual/MobileHIG/
Android : http://developer.android.com/de…/get-started/principles.html
WP : https://dev.windows.com/en-us/design

Sekian 🙂

Memasang harga untuk sebuah aplikasi

Kekeliruan yg pernah saya alami dan jg bbrp tmn2 developer yg terjun ke dunia proyek aplikasi mobile (kebetulan sy blm pernah ngalamin yg model bisnis berjualan, tetapi model request by user/client dan donasi) adalah terlalu cepat menyimpulkan, terkadang tanpa disadari, memberikan layanan ke klien/user dengan kurang cermat.

Menerapkan performa dan kualitas yang sempurna itu hampir mustahil dilakukan, semestinya itu disadari bersama, baik developer maupun user, karena segala yang sudah besar seperti facebook app, dll. Itu dilakukan melalui riset yang panjang dan bekerja bertahap mengikuti kebiasaan pengguna (dan lagi-lagi ini menyangkut User Experience ataupun kebiasaan pengguna)

Ide yang solid dibarengi dengan potensi pasar yang siap dieksekusi adalah kuncinya. Namun, dapet ide yang orisinil juga bukan sesuatu yang mudah (dan ide itu mahal, jadi kalo ada orang yg share status : “kalo temen2 minta dibuatkan aplikasi di OS blabla..apa yg pgn temen2 inginkan?” berarti orang tsb lg kekurangan ide hehehe), mungkin wajar bagi kita selaku developer untuk meniru. Tapi yang perlu digarisbawahi adalah, hindari godaan untuk sukses dengan instant. Lebih baik sedikit demi sedikit berjalan, tidak apa pas launching app masih sederhana, tetapi lambat laun terus diriset, dikembangkan, mendengar tanggapan dari user, ditampung dan ditelusuri lebih lanjut sehingga tercipta gagasan baru untuk membuat aplikasi tersebut bertahap menjadi besar.

Membangun aplikasi bukan serta merta untuk mencari duit, perlu di-explore juga jenis aplikasi apa yang bisa/boleh dijadikan uang. Ada beberapa kategori yang semestinya tidak boleh dijadikan lahan uang.

Aplikasi kategori sosial : jejaring, messaging, religi dan app yg hits yang mencakup semua kalangan pengguna, konten beragam, tapi biasanya harga rendah bahkan gratis (loh kok bisa? gk rugi tuh?). Mereka berani memasang harga rendah karena cakupan pasarnya luas, campaignnya mudah (ntah dengan viral, memasarkan via iklan di jejaring, dsb), dan semua orang bisa pakai. Contoh : chat macem WA yang menarik pembayaran tiap tahunnya dengan harga murah (dan tentu target download sudah lebih dari 1000 pengguna)

Sedangkan yang harga tinggi biasanya menargetkan konsumen yang serius/tertentu. Sebagai contoh app. multimedia/office, biasanya harganya mahal, bahkan sampai mencapai $100, seperti : photoshop, fruity loops, officetogo, dll.

Dan ada yang model premium, konten besar, profit yang didapat besar juga dari per penggunanya. Biasanya model ini lebih sedikit dibandingkan 2 jenis sebelumnya. Dan terkadang menerapkan sistem berlangganan per tahun. Sebagai contoh : game karaoke yang tiap lagunya harus berlangganan, microsoft office, aplikasi kolaborasi, dll.

Dan beberapa kegagalan yang sering terjadi adalah developer tidak memahami target penggunanya, memasang harga yang tidak pas.

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 ^_^