Menghindari tambal sulam di dalam pengembangan Software

Tadi sore ada pertanyaan soal ini:

Terkadang saya masih bertanya-tanya mas bagaimana sebenarnya desain arsitektur software dan juga database yang baik. Setidaknya, ketika ada pengembangan menjadi lebih mudah utk dikembangkan.
Apalagi kaitannya dengan perubahan atau penambahan struktur database yang terkadang menyebabkan perubahan coding (sering sy alami)

Pertanyaan cukup menarik.

Berdasarkan pengalaman, jangan terburu-buru masuk ke tahap development.

Kekeliruan kebanyakan developer, menurut saya, terlalu prematur tahapan rancangan, langsung lompat ke tahap development.

Saya selalu menghindari hal tersebut, alasannya karena rancangan arsitektur yang tidak matang menyebabkan sistem yang akan dibangun ntar jadi tambal sulam

eh iya ada yang ketinggalan, tambahin dulu deh tabel databasenya”,
waduh, ternyata di tabel lama sudah ada kolomnya, apa direfactoring aja ya…”, jadinya njelimet.

Pahami “Design thinking“. Yaitu, ajak tim melakukan brainstorming, duduk bareng mendefinisikan masalah dan scope pekerjaan, kemudian di-breakdown menjadi task-task, dan duduk bareng dengan orang-orang yang biasa mendesain rancangan arsitektur software, mendesain rancangan database, dan mendesain rancangan antarmuka, melakukan coret-coret UML-nya (use case dan activity diagram), bikin physical data model database-nya, dan coret-coret wireframe/mockup desainnya.

Setelah itu, diskusikan lagi bareng-bareng lebih lanjut, ajak juga si klien, sambil jelaskan design flow sistemnya seperti apa, biar kelihatan nanti kekeliruan mendesain arsitektur software-nya di mana, pemilihan teknologi, service yang dipakai, database yang dipakai, nanti kelihatan semua yang perlu dikoreksi di mana.

Biasanya nanti ada sanggahan dari klien..

Misal “saya gak pengen flownya seperti itu, pengennya seperti ini”, nah ini jangan langsung manut, ajak orang UX, kasih tau UX jaman now untuk software yang dibangun kayak gimana, UX di software/aplikasinya seperti apa.
Paling mudah sih, kasih pembanding, pembanding dengan software serupa yang sudah ada di dunia ini, jadi si klien bisa percaya kalau usulan dia keliru.

Dan terkadang ada sanggahan lagi dari klien terkait teknologi, “wah, pake teknologi itu biayanya mahal ya, uang kami tidak cukup”, nah, untuk kasus yang kayak gini, kasih alternatif teknologi yang gratis misalnya atau yang lebih murah lagi, sambil kasih tau apa kekurangannya jika ada.
Kalau misal nanti ketemu kendala, “wah teknologi yang dipakai kalau yang handal sih X, tapi masalahnya belum punya pengalaman soal itu”, nah yang kayak gini harus pandai memposisikan diri “mau rekrut personil yang ahli di teknologi tersebut” atau “alokasikan waktu dengan tim buat mempelajari” (masing-masing ada resikonya)
Advertisements

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 masih banyak startup TI yang mencari superman?

Beberapa hari yang lalu, saya sempat berdiskusi dengan teman-teman penggiat startup di Yogyakarta, dan satu startup dari Surabaya. Mereka berkumpul dan berdiskusi masalah progress pekerjaan developer-nya yang terkesan lambat, tidak sesuai target waktu yang ditetapkan si pemilik startup.

Lantas, di mana letak kesalahannya?

Keterlambatan deliverable progress pekerjaan dari developer, bukannya hanya mutlak kesalahan si developer itu sendiri, ada beberapa faktor keterlambatan sebuah proyek, di antaranya kurangnya komunikasi antar personil, keterbatasan resource (SDM), dan kehabisan budget. Berikut ini sedikit cerita pengalaman saya di beberapa startup TI

Saya beberapa kali menjadi “penasehat” a.k.a konsultan TI dalam hal resource di beberapa startup. Dan ini ada kasus yang menurut saya menarik diambil hikmahnya, karena ini jadi kasus yang sering terjadi.

Bulan februari 2018 lalu, saya diminta mengevaluasi sebuah startup yang bermasalah dengan programmernya. Sebenernya saya sudah sering diminta jadi konsultan, dari beberapa kasus startup, ya rata-rata semua masalahnya di resource-nya. Bahkan November 2017 ada startup yang targetnya ketat, sementara si developer-nya tunggal fullstack, ya saya bilang ke si empunya Startup, “sebaiknya si developer tunggal ini naik jabatan aja jadi Manajer TI atau Lead Developer-nya, terus rekrut 2 developer junior yang melanjutkan pekerjaanSaya rasa gak mahal, apalagi based-nya di Jogja. Daripada dipaksa seseorang buat selesaikan semua fitur ini dalam waktu singkat, hasilnya gak bagus. Proyek yang dipaksa pada timeline yg tidak wajar dan memangkas tahapan proses jelas mengorbankan kualitas. Daripada aplikasinya buggy, toh nanti repot di akhir”

Ok, lanjut ke cerita saya untuk artikel ini.

Jadi ini startup sudah berkembang, tapi ada masalah di sistemnya yang kurang termanajemen dengan baik. Saya lihat si startup ini malah dapat pendanaan dari beberapa investor. Sayangnya, dana tersebut bukan dimanfaatkan untuk meningkatkan kualitas TI-nya, yang merupakan salah satu komponen penting untuk penunjang sekaligus percepatan core bisnis si startup ini, melainkan si startup memakai dananya untuk ekspansi ke daerah-daerah lain, padahal sistemnya belum sanggup. Begitu dipakai “kok lelet…, kok sistemnya bermasalah”. Dan akhirnya, saya melakukan observasi selama seminggu, saya ajak ngobrol pemilik startup, dari ngobrol ini-itu, saya jadi tau masalahnya di mana.. akhirnya, ada beberapa pertanyaan yang saya ajukan ke pemilik startup ini.

“mas, biasanya me-manage para developer gimana? pakai tools apa atau cuma chat biasa?” | “saya biasanya chat di Whatsapp, mas. Saya tanyain developer saya: progressnya ​halaman report bisa diselesaikan kapan? dia jawab: seminggu lagi, mas. Tapi ya saya tagih seminggu kemudian malah belum jadi, masih ada bug katanya” | “owh, jadi selama ini memantau pekerjaan developer dari Whatsapp aja, mas?” | “kalau misal masnya nanya kerjaan yang dikerjakan tahun lalu, terus pengen dikembangkan lagi gimana… apa nanya lagi terakhir sampe mana?” | “ya biasa, mas..saya tanyain “terakhir fitur tsb sampe mana ya? siapa yang ngerjain?” | “naah, gak ribet tuh misal developernya lagi kerjain fitur yang sekarang, harus tiba2 cek sourcecode yang lama yang ia kerjakan tahun lalu.. karena saya tau, untuk refresh ingatan soal kerjaan tahun lalu, apalagi tidak ada catatannya, ya repot, harus cari-cari dulu” | “owh, iya ya, kayaknya harus dicatat” | “saran saya, chat ya monggo, mas. Tapi jangan lupa ditulis di tools untuk organisir pekerjaan. Banyak contohnya, yang gratis sih ada trello, atau yang berbayar macem basecamp, jira, atau bitbucket” | “owh iya, mas, dulu saya juga pernah dapet saran dari teman disuruh pake trello..saya belum paham maksudnya” | “iya, kalau masnya cuma mengandalkan chat, nanya developer progress dah sampai mana, itu bisa saja developernya ngeles/alasan aja.. sementara buktinya tidak terlihat, kalau bisa ya dicontrol.. jadi pakai source control management, macem github, bitbucket ataupun gitlab. Dari situ kita bisa lihat progress si developer per hari bagaimana, apa saja perubahannya, walaupun masnya gak gitu paham TI, tapi setidaknya bisa dilihat. Dan juga atur waktunya dari tools organisir/manajemen proyek macem trello, jira ataupun basecamp. Saran saya sih untuk startup pakai trello aja dulu, jadi masnya bikin tiket pekerjaannya, tentukan deadlinenya di situ, nanti si developer tinggal melaporkan pekerjaannya dari situ juga, beserta url pekerjaannya dan apa saja yang dikerjakan, dibikin poin-poinnya. Dengan begitu, ketika ada developer yang melanjutkan, misal masnya rekrut developer baru, karena yang lama sudah resign, ya gak panik, tinggal si developer lama lengkapi dokumentasinya di trello tersebut, kalau ada yang kurang, terus ntar developer baru, tinggal baca-baca apa yang sudah dikembangkan, dan mana saja yang masih to-do-list, baik pekerjaan baru ataupun perbaikan error/bugs/masalah” | “wah, sarannya boleh juga, mas, iya tuh, saya denger ada startup yang ditinggalkan developernya, malah bisnisnya jadi tertunda sementara” | “iya, mas, kebanyakan fatalnya di situ. Jadi, biasakan mengontrol pekerjaannya dengan baik. Kalau dirasa masnya sibuk karena mesti ngurus bisnisnya, ya masnya rekrut orang lagi buat jadi CTO ataupun jadi Manajer TI Produk masnya ini. Biar dia yang bermain, mengelola proyek pekerjaan di startup ini” | “siap, mas, requirement manajernya seperti apa ya mas?” | “simpel aja, mas, gak perlu rumit-rumit, yang penting punya pengalaman membuat perencanaan, mampu mengelola, mengatur, dan mengevaluasi pekerjaan-pekerjaan TI di produk masnya ini. Nanti dia yang kontrol kerjaan developer, lebih bagus lagi paham project management dan agile methodology

Kemudian saya meminta izin ke si pemilik startup-startup agar saya bisa berdiskusi dengan teman-teman developer yang bekerja di sana.

Dan akhirnya saya berdiskusi sekaligus bertanya, pertanyaan saya pertama adalah.. “masnya sudah berapa lama di sini?”, dijawab “sudah, setahun, mas Widy”.

kemudian saya lanjut nanya “sendirian mas? apa ada temen yang bantu?” | “kalau saya sendiri mas yang garap backend, tapi kalau aplikasi mobile, saya sama 1 temen lagi yang bantu” | “owh, masnya full stack developer ya?” | “iya, mas” | “mas, saya ini kan diminta mas X (si pemilik startup) buat evaluasi produk yang mas kembangkan.. saya boleh minta tolong gak, dibikin list apa saja pekerjaan to-do-list dari produk ini, dari yang sedang masnya kerjakan sampai yang masih bermasalah yang jadi PR masnya” | “siap, mas..saya buatkan ya” |”iya, simple aja, kasih tau nama fitur>sub fiturnya saja.. gak perlu dikasih deskripsi, biar gk ribet”

Dan didapatlah list-nya dari developer tersebut. Saya akhirnya bertemu lagi dengan si pemilik startup: “mas, ini saya sudah ngobrol dengan developer X. Saya pengen tau, mas.. masnya kasih target ke developer sampai kapan?” | “ya kalo bisa akhir februari ini, mas. Soalnya Maret saya mesti ke Dubai, mau pitching di sana” | “ok, mas.. jadi gini, saya sudah cek fitur-fitur yang di aplikasi maupun yang di backend, dan saya lihat memang banyak sekali masalah/bugs dan kurangnya, apalagi masnya pengen ada report gitu kan..biar tau berapa income per bulan dan laporan keluhan pengguna. Dan ada masalah lain juga, mas, saya lihat desainnya tidak sesuai pattern OS Android dan iOS, mas. Mas, coba buka aplikasi Facebook di Android, ini saya sambil kasih liat yang di iOS, ada bedanya gak?” | “iya, mas, ada bedanya..kok gitu ya?” | “iya, UX (User eXperience) untuk masing-masing OS, baik Android dan iOS itu berbeda..jadi kalau user Android dicobain pake desain layout yang mirip iOS mungkin agak kurang terbiasa” | “tapi ini saya sudah dapat desainer, mas. Desainnya bagus, dia anak magang di sini” | “owh, boleh kasih liat desainnya, mas?” | “ini, mas” (sambil nunjukin kertas berlembar-lembar…ternyata desainnya diprint) | “ok, mas, ini sudah mendingan, cuma harus ada beberapa hal yang dikoreksi. Tapi yang terpenting adalah, ini kalau dilihat dari to-do-list si programmer dengan deadline waktu 2 bulan yang masnya tetapkan, saya sih beranggapan ini tidak akan berjalan sebagaimana mestinya. Problem yang ini (sambil saya nunjukin halaman yang buggy) lumayan juga effort-nya, kalau dia sendirian yang garap, sepertinya akan memakan waktu lama, karena kalau saya lihat existing code dengan yang akan dibuat itu seperti buat baru. Apalagi desain yang diminta untuk perubahan lumayan berbeda, mas. Saran saya, bergegas si developer sekarang biar dia fokus ke bugs fixing, karena dia yang paham existing code. Dan masnya rekrut 2 orang lagi untuk fitur-fitur tambahan yang ditargetkan februari ini, ya jangan dibuat ketat, masnya buat sedikit kelonggaran agar mereka bisa memulai mengelola pekerjaannya masing-masing, apalagi misal nanti datang developer baru, biar mereka bisa berbaur dulu sebagai tim, ya paling masuk akal menurut saya, akhir maret bisa selesai dengan semua list ini. Dan sambil jalan, masnya coba hire manajer yang memahami manajemen proyek TI dan juga seluk-beluk produk ini. Soalnya kan saya tau masnya basic-nya ekonomi, kemarin saya tanya masnya kalau nanya progress ke developer gimana..ya kayak gitu kurang control, mas” | “siap, mas, sarannya bagus, bisa saya coba, nanti saya tanya-tanya lagi ya mas” | “monggo, mas. Santai saja. Semoga berhasil ya”

Dari cerita di atas, hikmah yang dapat dipetik adalah… Mungkin sudah pernah dengar istilah:

9 Women Can’t Make a Baby in a Month

Ya, dimaklumi memang, kebanyakan startup butuh percepatan movement mereka agar bisnisnya dapat segera “menghasilkan”, namun sayangnya memangkas budget untuk resource agar dapat dialihkan ke marketing, dan lain-lain. Kebanyakan kekeliruan startup lokal di sini adalah, mereka belum paham, bahwa 1 orang tidak bisa begitu saja memiliki kemampuan superman, yang mampu menyelesaikan semua pekerjaan TI. Si developer disuruh desain sistemnya, desain databasenya, desain antarmuka penggunanya, terus dilanjut coding mengembangkan backend dan aplikasi frontend-nya, terus dia juga harus bisa benerin bugs dan menanggapi keluhan-keluhan pengguna. Wah, yang seperti ini superman atau mungkin sudah gila. Apalagi bayarannya tidak seberapa, dan ujung-ujungnya si developer jatuh sakit dan tidak betah.

Sama juga misalkan startup Anda banyak uang, kemudian uang tersebut dipakai untuk marketing besar-besaran, melontarkan lebih banyak uang untuk mempercepat adopsi pasar, ya ujung-ujungnya mubadzir. Ya seperti ungkapan di atas, 9 wanita tidak dapat melahirkan dalam waktu 1 bulan.

Standar yang tepat itu adalah “well-organized” dan “well educated“, mesti cerdas dalam mengelola produk anda, berapa besar biaya yang dipakai untuk SDM, berapa besar biaya yang dipakai untuk support, marketing, desain, dll..semua diatur di business plan yang semestinya sudah dibuat sebelum startup dijalankan. Well educated maksudnya, punya pengetahuan terkait startup ini, bagaimana motor penggerak bisnisnya, bagaimana infrastruktur yang dipakai dan SDMnya. Jangan sampai biaya habis di infrastruktur sistemnya, eh ternyata tidak dipakai secara maksimal. Jangan sampai sudah keluar banyak biaya buat marketing, pas pengguna tertarik buat nyoba produknya, eh ternyata produknya gak siap meng-handle banyak pengguna.

Saran saya, ya buat business plan yang matang, bila budget terbatas, mulailah kembangkan dari PoC atau Prototype-nya dulu, kemudian pitching ke investor, buat dapat pendanaan, siapa tau idenya menarik bagi investor. Kalau berani ambil resiko (tentunya punya manajemen resiko yang baik), coba mulai bagi tahapan pengembangan produknya dalam beberapa tahap, jangan semua sekaligus langsung jadi dalam waktu yang ketat. Tetapi dibagi, misal: kembangkan backend+API (web service) dan aplikasi Androidnya saja dulu, jika ada dana lagi, lanjut ke iOS, terus rekrut masing-masing personil sesuai keahliannya, biar mereka fokus dengan pekerjaannya.

Sebagai contoh, idealnya untuk startup kecil, ya bisa dimulai dengan: 1 developer backend, 1 developer frontend (mobile apps: Android/iOS), ini rekrut dengan sistem gaji per bulan (ntah kontrak dalam waktu tertentu, misal satu tahun ataupun permanen), dan cari freelancer desainer UI (antarmuka pengguna) yang direkrut dalam waktu 1-3 bulan untuk menggarap desainnya. Atau kalau mau lebih bagus lagi, ya dibuat lebih spesifik: 2 orang infrastructure dan network engineer, 1 orang manager, 1 orang database designer, 1 orang system designer, 1 orang UI designer, 2 orang backend+API developer, dan 2 orang frontend developer (web admin dan mobile apps).

Tahapannya biasanya, ketika infrastruktur sudah siap (server/hosting, database, dan setup beberapa kebutuhan lainnya sudah berstatus installed untuk lingkungan development), ya backend developer mempersiapkan dan memulai pemrograman backend system dan API-nya, dalam waktu bersamaan…si desainer kerja dalam waktu 1-3 bulan itu men-desain halaman dari halaman login, sampai halaman utama, nah, ketika halaman login sudah jadi, dan dirasa sudah bagus, tinggal si developer frontend yang garap login, dan seterusnya bertahap, (dengan asumsi API Login juga sudah dikerjakan oleh developer backend), jadi pekerjaannya berjalan paralel dan tidak saling tunggu. Dan yang terpenting, kelola pekerjaan mereka dengan tools manajemen proyek yang saya sebutkan di atas (misal: trello/jira), ajarkan mereka agar terbiasa melaporkan pekerjaan di tools online manajemen proyek tersebut. Dengan begitu, masing-masing personil bisa saling cek pekerjaan anggota tim yang lain, sambil menunggu pekerjaan si backend developer selesai, ya developer frontend bisa mulai dari memrogram tampilan halamannya dulu, dan seterusnya. Dan, yang paling utama, yang sering luput dari pelaku startup adalah komunikasi antar anggota tim, biasakan melakukan daily atau weekly call/conferences jika sedang berjauhan, atau daily/weekly meeting jika sedang dalam satu ruangan, atau ya sekedar makan siang atau hangouts bareng biar gak terlalu “tegang” suasana, dan tentunya biar refresh juga. Komunikasi yang baik adalah salah satu kunci penting keberhasilan proyek/startup. Jangan sampai, pemilik startup sibuk uruan ini itu, cuma bisa chat Whatsapp doang, sementara developernya bergerak sendiri, seperti kasus di atas.

Dan sambil pengembangan berlangsung, coba observasi pasar, bagaimana reaksi pengguna dan calon pengguna ketika anda perkenalkan produk anda tersebut, minta masukkan dari mereka jika diperlukan, karena inilah yang disebut “product / market fit”, soal kecocokan pasar, sehingga anda yakin dengan target pengguna anda.

Dan pesan saya terakhir pada artikel ini sebagaimana hadis Nabi Shallallahu alaihi wassalam: “Berikan kepada seorang pekerja upahnya sebelum keringatnya kering.” (HR. Ibnu Majah, shahih).

Sekian sekelumit peristiwa yang semoga bisa bermanfaat bagi pembaca 🙂

Terima kasih.

Referensi terkait tools online manajemen proyek:

 

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-…/

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

    Screen Shot 2017-03-31 at 2.21.26 PM

    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
    Decision Trees

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

Terima kasih.