NDA dan Portofolio

Beberapa kali interview, nanya portofolio, rata-rata pada takut share karena concern di NDA.

Wajar, sayapun bisa memaklumi. Tapi portofolio itu penting buat meyakinkan pewawancara ketika hendak membuktikan ucapan si kandidat.

Kadang terjebak dengan NDA, dengan NDA kita gak bisa ngapa-ngapain, share foto sedikit, dianggap menyebarkan rahasia perusahaan, padahal kalo kita membaca dengan teliti NDA itu, ada beberapa yang bisa kita “sebarkan” sebagai portofolio ataupun “personal branding”.

Case #1 Ada network engineer, foto di ruang server kantor pemerintah, lantas ada yang komen: “wah kok berani banget foto-foto di ruang server, nanti rahasia negara ketahuan”

Ok, apakah salah share foto ruang server?

1. Ruang server bukanlah sesuatu yang rahasia, selama kita gak ngasih tau isi ruang server data apa aja, IPnya, lantai berapa, ataupun detail lainnya yang berakibat ancaman keamanan server tersebut, maka seharusnya tidak mengapa.
2. Foto-foto kerja, ntah di ketemu praktisi lain, ngobrol dengan si A soal topik X, dll, itu bisa jadi “personal branding” buat kita kalo kita memang punya koneksi yang bagus, punya pengalaman yang cukup OK.
3. Adapun yang komentar aneh-aneh, ya anggap aja iri.

Case #2 Ada programmer, share screenshot website dan mobile apps yang dia buat, share ke dokumen portfolio ataupun di media sosial. Lantas ada yang komentar “Wiih, gak taku ketahuan dalemannya kyk gini, ntar ditiru kompetitor loh”

Ok, apakah share screenshot berbahaya terkait software (app mobile/website) yang dibuat?

Nah, ini harus benar-benar hati-hati, ada batasannya:

1. Jika website/aplikasi tersebut belum rilis, potensi ketahuan kompetitor fitur-fiturnya cukup besar, kalau dishare sebelum mereka launch, khawatir nanti pas launch strategi bisnisnya dipatahkan kompetitor. Ada baiknya share yang bersifat general saja, misal page login dan homepage, sedangkan fitur-fitur unggulannya, lebih baik dihide/diblur.
2. Jika website/aplikasi tersebut telah rilis, tidak mengapa share fullscreen portofolionya, atau sekalian URL download app dan websitenya. Paling tidak yang perlu diperhatikan adalah, tidak mencantumkan data asli dari website/aplikasi tersebut, share screenshot pakai data dummy saja, dan jangan dimunculkan semua fieldnya, yang bersifat general saja. Alasannya? data aslinya bisa jadi sudah dilindungi kebijakan privasi, kalau kita menyebarkan malah melanggar hukum.
3. Adapun fitur-fitur unggulan lainnya, bisa diceritakan dalam bentuk narasi singkat saja. Ingat, ada potensi kebocoran data dari sesuatu yang dilindungi, dan itu lebih baik dihindari.

Maka dari itu, perlu identifikasi secara detail sebelum mencantumkan ke portfolio.

Pada akhirnya, sebelum menjadikan sebuah karya yang telah kita persembahkan buat klien itu menjadi portfolio, pelajari dahulu NDAnya. Baca berulang-ulang sampai kita paham batasannya. Bila perlu ngobrol dengan kliennya buat minta izin. Jika tidak diizinkan, ya cukup cantumkan pengalaman saja tanpa portofolio.

Portfolio ataupun share foto di sosmed itu bertujuan menunjukan keterampilan ke orang-orang bahwa kita pernah punya pengalaman dengan orang terkenal, atau project besar, dan sejenisnya. Eksitensi seperti ini penting. Karena banyak juga orang terpengaruh dengan sendirinya, mencari kita ketika orang tersebut membutuhkan sesuatu terkait masalah yang perlu diselesaikan dengan keterampilan kita.

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.

Contoh Surat Perjanjian Kontrak Software Developer

PR besar selain skill coding seorang Software Developer adalah kemampuan menulis. Baik itu menulis surat cinta buat calon istri #eh, menulis surat penawaran, menulis list tugas-tugas dan skup pekerjaan, menulis percakapan yang baik dan mudah dipahami klien (baik itu yang awam maupun yang pro), dan menulis dokumentasi.

Di kesempatan ini saya coba menulis Surat Perjanjian Kontrak (SPK) Software Developer yang mungkin berguna, khususnya buat saya sendiri maupun temen-temen yang berprofesi sebagai software developer. Sudah disesuaikan berdasarkan pengalaman-pengalaman lampau sehingga, insya’ Allah tidak merugikan kedua belah pihak, khususnya si Software Developer.

Mungkin di kesempatan lain saya akan menulis contoh-contoh surat yang lain di dunia manajemen proyek. Tapi menunggu ada waktunya dulu hahaha.

Berikut ini contohnya: download di SINI

Perlu diingat bahwa Surat Kontrak Kerja tidak berdiri sendiri di saat membuat kesepakatan dengan klien, harus disertakan juga PO (Purchase Order) yang berisi pekerjaan yang diminta dan harganya, kemudian FSD (Fuctional Spesification Document) yang berisi list skup pekerjaan beserta detailnya, kemudian NDA (Non-disclosure agreement) yang berisi kesepakatan kerahasiaan pekerjaan.

 

Tips buat para klien yang hendak merekrut pekerja TI

Ada banyak sekali permasalahan di dalam manajemen proyek.

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

Dan biasanya ujung-ujungnya dicarilah penyelamat proyek.

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

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

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

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

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

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

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

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

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

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

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

Mengapa waktu proyek tidak dapat dihitung dengan pasti?

Pengembangan software ataupun aplikasi itu tidak pernah menggunakan ilmu pasti.

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

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

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

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

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

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

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

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

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

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

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

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

Proses Pengembangan Aplikasi Android

Banyak dari kita yang dari developer backend ataupun frontend web dan desktop beralih menjadi developer frontend mobile, sebagai pembahasan kali ini adalah menjadi developer Android.

Di sini saya mencoba menulis hal-hal yang patut diperhatikan oleh developer “peralihan” tersebut, agar nantinya lebih matang lagi mendalami dunia mobile application development. Dan juga bagi Anda yang hendak mencari dan bekerjasama dengan developer mobile Android untuk produk Anda ataupun studi kasus/penelitian Anda, agar memahami bagaimana proses pengembangan aplikasi Android dari awal hingga menerbitkannya di PlayStore, bagian mana yang membuatnya menjadi panjang prosesnya, dan tahap apa saja di dalam pengembangan aplikasi mobile Android itu sendiri.

Pembahasan kali ini mencakup tahapan dari proses pengembangan Aplikasi Android yang sedikit berbeda dengan platform lain seperti Web ataupun Desktop.

Berikut ini gambaran singkat mengenai proses pengembangan aplikasi Android dari memulai menemukan ide, perancangan sampai dengan menerbitkannya di Google Play Store.

Gambar 1. Proses Manajemen Proyek Pengembangan Aplikasi Android.

Dari gambar di atas, saya coba jabarkan secara singkat satu per satu:

1. Dimulai dari mendefinisikan ide dan persyaratan aplikasi

Apabila Anda hendak mengembangkan sebuah aplikasi, yang patut anda lakukan pertama kali adalah mendefinisikan ide Anda ke dalam sebuah tulisan, kemudian dari ide tersebut berkembang menjadi sebuah masalah. Dari masalah tersebut, tugas Anda selanjutnya adalah berusaha memecahkan permasalahan menjadi solusi. Di antara tahap mencari solusi di dalam sebuah masalah, tentu ada uraian-uraian proses pemecahan masalah, nah, dari situ kita dapat menentukan kebutuhan apa saja di dalam aplikasi yang hendak dibuat.

Untuk persyaratan (requirements) aplikasi, ada banyak poin di dalamnya, requirement  aplikasi ini sangat penting sebagai dasar untuk mendefinisikan dan mengelola scope  pekerjaan atau scope produk. Untuk mendefinisikan requirements ini ada banyak teknik yang dapat dilakukan, diantaranya:

• brainstorming ataupun mindmapping
  berdiskusi dengan anggota grup tentang ide produk aplikasi yang hendak dibuat, dan mengupayakan pencarian solusi dari permasalahan yang ada sehingga menjadi ide yang matang dari berbagai anggota grup, di sini masing-masing anggota mencoba mem-breakdown masalah agar nantinya masalah tersebut dapat diselesaikan dengan pendekatan aplikasi.
  
• interview
  mewawancarai orang yang ahli dalam bidangnya atau orang yang memiliki informasi yang dapat memberikan masukkan terkait requirement aplikasi yang hendak Anda buat sehingga Anda menjadi tahu detail permasalahan yang dihadapi dari ahli tersebut, dan tentunya berupaya mencapai solusi dengan pendekatan aplikasi,
• kuesioner
  apabila Anda masih belum yakin apakah ide Anda akan laku di pasaran, langkah yang bisa Anda ambil adalah membuat kuisoner dan menyebarkannya ke target pengguna aplikasi, Anda dapat membuat sejumlah pertanyaan dan ditujukan kepada responden dalam jumlah yang banyak dan bervariasi sehingga didapat akumulasi informasi dengan cepat,
• observasi
  teknik melihat dan mengamati secara langsung orang-orang dilingkungannya, pekerjaannya dan proses-nya. Observasi dikenal juga dengan nama “job shadowing”.
• prototype
  Anda dapat membuat prototype aplikasi yang hanya berupa tampilan atau model kerja dari Aplikasi yang hendak dikembangkan. Prototype ini dapat Anda promosikan ke pengguna ataupun penanam modal, yang nantinya diharapkan Anda mendapatkan feedback atau bekal requirement untuk aplikasi yang hendak dibuat.

2. Wireframing atau protoyping tampilan antarmuka (UI) aplikasi

Untuk dapat mengembangkan aplikasi, Anda harus mempunyai gambaran jelas seperti apa nantinya tampilan antarmuka aplikasi Anda. Dan dari tahap wireframing inilah Anda dapat mengetahui apakah penempatan fitur atau menu ini sudah sesuai layoutnya atau belum, apakah desainnya sudah sesuai pattern OS Android atau belum, apakah tampilannya sudah kelihatan nyaman dipandang atau belum, dan apakah desain yang diterapkan sudah sesuai User Experience atau belum.

Ada banyak tools prototyping yang akan membantu anda mendesign dengan cepat. Diantaranya Adobe Photoshop (Win/Mac), Sketch (Mac), Gravit Design (Win/Mac/Linux), Invision Studio (web), Zeplin.io (web), Figma.com (web), dan app.studio.design (web).

Ketika anda telah membuat wireframing tampilan antarmuka aplikasinya, selanjutnya adalah membuat desain antarmukanya menggunakan tools di atas, agar nantinya ketika Anda telah memasuki masa pengembangan aplikasi, Anda tinggal memindahkan desain tersebut ke layout Android.

Layout Android dikembangkan dengan menggunakan bahasa pemrograman XML, dan ditaruh di dalam folder resource (res) layout Android.

Dan perlu diingat, ponsel dan tablet Android itu memiliki beragam jenis layar dan ukuran, pentingnya menyiapkan desain yang adaptive, yang mendukung beragam jenis layar tersebut (heterokapabilitas). Pembahasan Adaptive Design pernah dibahas di artikel berikut ini.

3. Pengembangan dan pengujian aplikasi

Pengembangan aplikasi Android secara native dapat menggunakan bahasa Pemrograman Java ataupun Kotlin. Keduanya mempunyai ciri khas masing-masing. Dan keduanya didukung penuh oleh Android SDK. Namun, apabila Anda tertarik mengembangkan aplikasi Android secara hybrid, Anda dapat menggunakan berbagai bahasa pemrograman yang sudah ada, misal dengan javascript nodejs/angularjs (react-native, ionic), menggunakan html5 (phonegap), atau .NET (xamarin/visualstudiocode).

Baik native maupun hybrid memiliki keunggulan dan kelemahan masing-masing. Untuk native sendiri karena sudah didukung penuh oleh Google Android, tentunya semua fasilitas di dalam SDK sudah pasti paling cepat mendapatkan layanan. Sedangkan hybrid, sangat mengandalkan komunitas developernya.

Dan dalam tahap pengembangan aplikasi Android, seorang developer tidak hanya fokus menulis code dalam bahasa pemrograman Java/Kotlin, namun Anda juga harus mampu menulis code untuk resource antarmuka pengguna dalam bahasa pemrograman XML dan juga mampu menguji aplikasi yang Anda buat.

Untuk pengujian Aplikasi, ada banyak tools yang dapat dipakai, salah satunya TestFairy (web), Firebase Reporting (web), ataupun Fabric.io (web). Dan yang terpenting adalah Anda dituntut untuk mampu membaca Log di Logcat Android (DDMS/Android Studio) ketika aplikasi berjalan, dan juga pentingnya skill debugging dan bugs fixing code Android.

Selain itu, pengaturan aplikasi di manifests penting untuk diperhatikan, misalnya, permission apa saja yang Anda cantumkan di manifests yang nantinya diminta kepada pengguna. Sudah sesuaikan permission yang Anda definisikan di manifests, jangan sampai Anda menambahkan permission yang tidak dibutuhkan Aplikasi apalagi yang berbahaya bagi pengguna aplikasi Anda. Dan juga bagaimana pengaturan tema masing-masing halaman aplikasi Anda, semua diatur di manifests ini. Pengaturan lainnya seperti background service dan broadcast (SMS ataupun push notification), penggunaan memory dan jenis ukuran layar yang didukung oleh Aplikasi Anda. Semua itu diatur di manifests file ini.

Dan tidak lupa juga pengaturan build configuration di gradle, apakah Anda telah menggunakan library versi terbaru atau yang stable (minim masalah bugs), dan apakah target OSnya sudah sesuai dengan OS terbaru, dan sebagainya. Itu semua harus dipersiapkan oleh Anda sebagai developer.

Berikut ini rincian bagaimana source code yang telah Anda kerjakan di-“build” menjadi sebuah APK (installer) aplikasi Android.

Gambar 2. Proses sourcecode yang digodok menjadi sebuah installer (APK)

Semua proses, dari sebuah sourcecode mentah, menjadi sebuah Android Package Kit (APK) alias installer yang nanti digunakan oleh pengguna (user) Anda, dimulai dari proses compiling source code tersebut. Compiler yang digunakan di Android Studio adalah Dalvik. Compiler tersebut mengonversi source code yang Anda kerjakan menjadi file DEX (Dalvik Executable) dan resources yang compiled, yang menyertakan bytecode yang berjalan pada perangkat Android. Dan setelah DEX tersebut dibuat, proses selanjutnya adalah mengubah DEX file dan lainnya tersebut menjadi sebuah APK, dan ini ditandai dengan kunci (Keystore) ntah versi debug ataukah versi release. Dan semua proses itu, dari menentukan kunci mana yang dipakai, menentukan library module dan plugins mana yang akan dipakai, library versi berapa, OS target versi berapa dan sebagainya, semua itu diatur melalui Gradle. Detailnya dapat dibaca dari sini.

4. Penerbitan aplikasi ke PlayStore

Aplikasi yang telah dikembangkan dan sudah teruji dengan baik, selanjutnya diterbitkan ke PlayStore. Untuk penerbitan ini Google memiliki syarat standar yang harus dipenuhi. Selain membayar biaya sebesar 25 USD untuk seumur hidup, Anda juga harus mempersiapkan APK yang telah memiliki status ditandatangani (signed) dengan kunci keamanan (KeyStore) versi release yang valid milik Anda. Seperti yang Anda lihat di gambar sebelumnya (no.3), source code yang anda kerjakan, akan di-compile dan ditandai dengan Keystore. Nah, untuk lebih detailnya bagaimana proses penandatanganan aplikasi oleh Keystore tersebut, perhatikan gambar berikut.

Gambar 3. Proses menandatangani APK yang telah di-build di Android Studio

Saat menggunakan penandatanganan Aplikasi Google Play, jika Anda kehilangan kunci unggahan, atau ada risiko keamanan, Anda bisa menghubungi Google untuk mencabut kunci unggahan lama dan membuat kunci baru. Karena kunci penandatanganan aplikasi dilindungi oleh Google, Anda bisa terus mengunggah versi baru aplikasi sebagai pembaruan ke aplikasi asli, meskipun Anda mengubah kunci unggahan. Namun, daripada Anda repot dengan proses pengembalian kunci yang lama, sebaiknya Keystore yang sudah Anda buat dan pakai untuk penandatanganan APK tersebut jangan sampai hilang (bisa dibackup di google drive ataupun dropbox). Dan jangan lupa Keystore tersebut dilindungi oleh password Anda, jangan sampai lupa yah 😉

Untuk informasi lengkapnya dapat mengunjungi tautan berikut: https://developer.android.com/studio/publish/app-signing.html?hl=id

Selain syarat di atas, Anda juga harus mempersiapkan nama aplikasi, deskripsi yang “menjual” agar orang lain tertarik untuk mencoba aplikasi Anda, screenshots aplikasi, kata kunci, kategori produk, dan kontak yang dapat dihubungi.

Untuk pasca pengembangan ini, Anda dituntut dapat menjadi mitra konsumen/pengguna aplikasi yang telah Anda buat. Mengapa? karena nantinya Anda akan menerima review (baik berupa kritikan, saran, dan hal-hal lain terkait aplikasi Anda) dan rating. Nantinya, review dan rating ini menjadi bahan evaluasi bagi Anda apakah yang perlu diperbaiki dan ditingkatkan dari fitur atau layanan yang ada di Aplikasi Anda. Ini tentunya penting bagi anda yang hendak mengukur apakah aplikasi yang Anda terbitkan ini sukses di pasaran. Jika tidak, mulailah mengevaluasi dari kritikan-kritikan di halaman review aplikasi Anda di Playstore, kemudian coba kontak beberapa pengguna, bagaimana tingkat kepuasan pemakaian aplikasi yang Anda buat.

Dan paling penting, jaga kerahasiaan data dan privasi pengguna Anda, jangan sampai disalahgunakan oleh siapapun. Untuk itulah mengapa di kebanyakan app sekarang diminta mencantumkan menu dan halaman “terms of services” atau “terms and conditions” dan “privacy policies“. Detailnya bisa dibaca di sini.

Semoga materi singkat ini dapat bermanfaat 🙂

Native vs Hybrid App. Programming. Pilih yang mana?

Sebelum saya membahas lebih jauh, saya ingin menjelaskan secara singkat pengertian apa itu Native dan apa itu Hybrid di dalam pengembangan aplikasi mobile (Android dan iOS pada khususnya).

Native app: build 1 app, hanya bisa di-deploy di single platform.

Hybrid app: build 1 app, bisa di-deploy multi platform (makanya ada jargon “build once, deploy anywhere“)

Aplikasi Android ditulis dengan menggunakan bahasa pemrograman Java (dan yang terbaru dengan Kotlin), dan Aplikasi iOS (iPhone/iPad/Watch) ditulis dengan Objective-C (dan yang terbaru dengan Swift), dan tidak ada cara keduanya dapat dicampur dengan bahasa pemrograman lain. Itulah native.

Sedangkan Aplikasi Hybrid mengizinkan kita untuk mengeksekusi platform web (misal Javascript) agar dapat berjalan pada  “native wrapper” (Apa itu native wrapper? sebuah subroutine di dalam lapisan Aplikasi, yang berfungsi sebagai penyedia akses menuju API di Sistem Operasi perangkat). Sistem arsitektur aplikasi Hybrid bisa dilihat di gambar berikut:

Di awal 2017, bahasa pemrograman Hybrid sudah diramaikan dengan adanya “react-native” yang basednya Javascript. Dan berdasarkan penelusuran saya di Github, Javascript sekarang sedang “naik daun”, dengan node.js, vue.js, dan react-nya

most popular programming languages on Github

React-native ini sendiri membutuhkan node, watchman dan react-cli. Dan sampai tanggal 29 November 2017 ini, react-native masih dalam tahap beta, belum ada versi stable. Namun, bukan berarti lambat berkembang, sampai saat ini sudah banyak framework yang telah dikembangkan dan dapat digunakan oleh para developer secara bebas, di antaranya Ignite. Ignite mempermudah pengembangan aplikasi dengan basis react-native, apalagi semua komponen, UI, theme, dll..sudah tersedia, tinggal pakai.

Ok, saya tidak akan membahas react-native lebih jauh soal ini. Mungkin akan saya bahas di lain kesempatan.

Pembahasan kali ini adalah menjawab 2 pertanyaan:

1. “manakah yang lebih baik? hybrid kah atau native kah?”
2. “Dan dalam kondisi seperti apa kita mesti menggunakan bahasa pemrograman native atau hybrid di dalam mengembangkan sebuah aplikasi?”

Ok, mari kita jawab satu persatu.

Bila ditanya mana yang lebih baik? saya bilang, tergantung kondisi. “Mengapa?” karena masing-masing ada keunggulan dan kekurangannya. “Loh, native ada kekurangannya toh?” sabar..sabar.. kekurangan di sini bukan ditinjau dari segi teknis pengembangan saja, tetapi juga dari harga dan waktu. Tentu pertimbangan ini penting bagi perusahaan di dalam menentukan produk mereka nanti mau dikembangkan secara hybrid atau native.

Secara singkat, ketika perusahaan memilih Programming Hybrid, maka yang harus dipertimbangkan adalah:

• Membutuhkan human-resource(s) (SDM) yang menguasai teknologi web, seperti CSS, Javascript, HTML5, dan atau AngularJS.
• Tampilan UI/UX cenderung statis, bisa dikustomisasi, namun effortnya lumayan.
• Performance di beberapa kasus sama baiknya dengan native, tapi ketika melibatkan hardware, misal push notification, akses audio, sensor GPS/Kompas/Accelerometer, tidak sebaik native. Namun perkembangannya terus membaik.
• Lack of documentation, developer dituntut tidak kaku dalam membaca dokumentasi, ada banyak sekali dokumentasi terkait hybrid programming dan sayangnya tidak di satu tempat, harus punya wawasan lebih dalam bereksplorasi teknologi hybrid. Berbeda dengan Android/iOS dengan menggunakan native, dokumentasi tersusun rapi dan sangat lengkap di masing-masing website resminya.
• Membutuhkan tenaga konsultan di dalam mempertimbangkan module atau library apa yang hendak dipakai yang sesuai dengan spesifikasi aplikasi. Mengapa? karena belum tentu tersedia (akan tetapi sejenis react sekarang sudah banyak sekali library dan sudah lumayan lengkap) atau bagaimana effort-nya di dalam pengembangan.

Di lain pihak, native programming, ada yang harus diperhatikan juga, diantaranya:

• Biaya pengembangan tinggi, dibandingkan dengan hybrid. “Kok bisa?” Jikalau perusahaan menginginkan aplikasi mobile di platform Android dan iOS, tentu ia harus menyediakan setidaknya dua human-resources (SDM) developer mobile android (dengan spesifikasi Java-Android atau Kotlin) dan iOS (dengan spesifikasi obj-C atau Swift), dan ini berjalan paralel agar tidak memakan banyak waktu. Sudah tentu biayanya tidak murah, apalagi kalau kompleks dan berbasis online, mesti harus menyediakan developer backend+API (agar aplikasi dapat berkomunikasi dengan server) juga. Jadi jangan heran “kok aplikasi seukuran Hape, kecil gitu, mahal banget ngalahin bikin website?” ya iyalah, kecil-kecil gitu, pengembangannya lumayan banyak yang harus dikerjakan.
  Sebagai contoh: aplikasi facebook. Aplikasi tersebut dikembangkan bertahap dan berlangsung sudah lama sekali. Awal rilis, fiturnya sedikit, lama-lama kompleks, selain menghindari lack-of-technology, tentu membuat pengguna juga jadi mudah beradaptasi dengan antarmuka-nya (ada hubungannya dengan User Experience), coba misalkan aplikasi facebook langsung kompleks kayak sekarang pas awal launch 2004 lalu, tentu ditinggalkan pengguna.
• Yang pasti membutuhkan pengetahuan seputar bahasa pemrograman masing-masing platform (iOS dan Android) untuk masing-masing personel dalam tim, ntah itu Project Manager-nya, System Analyst-nya dan juga Desainer Antarmuka-nya. Jadi, jangan menggunakan designer web ya, akan jadi gak nyambung, karena spesifikasinya agak sedikit berbeda.
• Source code terpisah masing-masing platform. Ada hal yang harus dipertimbangkan di dalam menjaga source-code tersebut, di antaranya, tentu platform Android dan iOS diletakkan di dalam repository berbeda di source control/versioning, semisal git (apalagi nanti misalkan fiturnya banyak, versinya banyak, kudu buat branch management), tapi ada juga yang monolitik. Selain itu punya keystore/cert yang berbeda untuk masing-masing platform, dan ini tidak boleh hilang. Selain itu menggunakan IDE dan tools berbeda untuk pengembangan, pengujian dan penerbitan untuk masing-masing platform tersebut.

Keuntungannya? mari kita bahas satu per satu

Dari hybrid programming, di antaranya:

• Murah, cukup menyediakan satu developer, bisa bikin dua platform aplikasi Android dan iOS (dan untuk iOS membutuhkan sistem operasi macOS dan xcode, karena Apple hanya mengizinkan melalui itu di dalam mengembangkan aplikasi iOS)
• Target pasar cukup besar, sekarang banyak sekali aplikasi yang dikembangkan secara hybrid, sebut saja facebook, instagram, airbnb, tesla, dan lain-lain. Ada yang dikembangkan dengan react-native, ionic, atau cordova. Dan ada juga kombinasi antara ionic/react-native dengan cordova (phonegap). Selain itu komunitas developernya cukup besar.
• Low Barrier to Entry. Tidak perlu pesimis jika kita awalnya developer web, kemudian terjun ke dunia mobile apps. “Mengapa?”, karena untuk terjun ke sana, pembatasnya sangat sedikit, adaptasinya pun tidak lama, dalam hitungan waktu sebulan kita dapat menyesuaikan diri dengan platform hybrid dan frameworknya.
• Source code cenderung ramping, dan kemampuan mendukung heterokapabilitas perangkat mobile.
• Mudah di dalam menerbitkan aplikasi, dapat langsung terintegrasi dengan PlayStore dan AppStore.
• Untuk beberapa kasus, mudah untuk di-maintain. Tetapi terkadang merepotkan, apalagi jika ada banyak library yang di-update (tapi bisa diantisipasi dengan mematikan auto-update beberapa library)
• Sangat cepat di dalam mempersiapkan prototype. Butuh menyediakan prototype untuk presentasi dengan calon investor dalam waktu dekat? maka pilihan hybrid begitu tepat.
• Banyak contoh script ataupun library JavaScript yang sudah tersedia di internet, ya karena didukung komunitas yang sangat besar, makanya sangat banyak.

Dari Native Programming, di antaranya:

• Best end-user experiences. Tampilan antarmuka (UI) berdasarkan SDK masing-masing platform (Android ataupun iOS). Di hybrid framework, tampilan aplikasi bisa dibuat 1 tampilan yang kembar identik antara Android dan iOS, namun bisa juga dipisah dengan tampilan berbeda sesuai design pattern masing-masing. Namun, di hybrid framework, tampilan UInya kaku. Kalau di native, tampilan UI mampu mengikuti UI framework bawaan masing-masing platform. Misal, Handphone Xperia dengan Handphone Galaxy mempunyai UI framework berbeda kan? nah, jika kita mengembangkan aplikasi native, aplikasi secara otomatis menyesuaikan dengan UI framework masing-masing OS, atau mengikuti standar SDK dari OS yang terinstall di handphone. Sedangkan hybrid, tampilannya statis, UXnya sedikit berbeda dengan UI di OS yang terinstall di handphone tersebut.
  Berikut ini saya sertakan contoh mengapa hybrid agak kurang dalam urusan UX, terutama dari sisi UInya identik antar platform. (Namun di sisi lain, mempercepat pengembangan).

  

  Perbandingan tampilan web (browser), ios dan android di hybrid yang hampir tidak ada bedanya.

• Highest ceiling for performance. Performa lebih baik. Secara jujur saya bilang, performa native dan hybrid tidak begitu signifikan bedanya. Saya belum pernah melihat ada delay terlalu jauh antara keduanya. Namun, untuk masalah yang melibatkan hardware, performa aplikasi yang dikembangkan secara native lebih baik, response load dan event-nya lebih cepat beberapa detik. Salah satu contohnya bisa dilihat di artikel berikut. Beberapa kendala yang ditemui juga untuk hybrid ketika melakukan push-notification, masih harus dua arah, dalam artian, masih harus melibatkan code secara native dikombinasikan dengan hybrid itu sendiri, makanya jadi agak bermasalah di performa. Sedangkan native, untuk persoalan tersebut tidak jadi masalah.
• Natural look and feel. Masih berhubungan dengan poin pertama, tampilannya lebih natural mengikuti OS yang terinstall di perangkat Android/iOS.
• Dan masih berhubungan dengan poin kedua, karena native, tentu akses layanan ataupun API SDK tentu lebih mudah dan cepat (bisa dibandingkan dengan gambar sistem arsitektur hybrid yang saya cantumkan di atas).
  Atau langsung melihat di gambar perbandingan berikut:

  

  hybrid-native-web comparison

• IDE (Android menggunakan Android Studio dan iOS menggunakan xcode), Development tools dan Dokumentasi tersusun rapih, lengkap dan jelas untuk masing-masing platform Android dan iOS. Untuk Android dapat mengunjungi website https://developer.android.com  dan untuk iOS dapat mengunjungi website https://developer.apple.com.
• Lebih mudah untuk melakukan debug aplikasi di masing-masing IDE.
• Paling sesuai dengan target pasar. Dengan native, kita dapat menyediakan aplikasi yang sesuai dengan masing-masing OS yang digunakan end-user. Toh sampai detik ini masih banyak pengguna yang menggunakan OS Gingerbread, Jellybean dan belum tentu menggunakan OS terbaru (Oreo). Apalagi terdapat back-compatibility dengan perangkat OS yang lama. Dan sudah tentu desainnyapun mengikuti OS masing-masing tersebut. Sedangkan native ya statis seperti saya bilang sebelumnya tadi.
• Keamanan aplikasi lebih baik. Pengembangan aplikasi secara native dibandingkan hybrid dianggap lebih aman, dengan fakta bahwa aplikasi native memanfaatkan fitur keamanan terintegrasi khusus dengan platform OS. Berbeda dengan hybrid, yang menempel pada webview, tentu beberapa pihak berpandangan bahwa hybrid rentan akan serangan injeksi ketika mengakses API tertentu di server.
  
  
  Beberapa kejadian serangan ke aplikasi mobile adalah seorang hacker melakukan reverse-engineering aplikasi untuk memperoleh akses resource (seperti source-code, gambar, file database, dll) dan juga menggunakan aplikasi malicious yang berjalan secara background untuk mencuri/menyadap data pengguna. Beberapa waktu lalu, saya pernah membahas masalah keamanan aplikasi ini, di tulisan berikut.

Kesimpulan dari artikel ini….

Sekarang sih tidak jadi persoalan yang rumit lagi,  mau menentukan pilihan ke hybrid ataukah ke native.  Tergantung kebutuhan saja. Pertimbangannya seperti yang saya tuliskan di atas. Semoga menjawab kedua pertanyaan tersebut.

Beberapa perusahaan memilih native karena ingin menghindari masalah-masalah pasca deployment, apalagi pass mass-production, kekhawatiran di perangkat pengguna tidak berjalan sebagaimana mestinya. Namun, ada pula perusahaan yang memilih dengan hybrid, karena ingin cepat launch, target waktu mepet, mungkin faktor bisnis atau faktor budget (biasanya sih yang seperti ini startup). Beberapa kasus yang terjadi, beberapa startup ingin mengembangkan sebuah aplikasi, saya tanya alasannya, karena uang dari investor sudah dikucurkan, namun si investor memberikan target waktu, waktunya mepet, maka dipilih hybrid. Di satu sisi juga menguntungkan si startup ini, karena cost lebih hemat, mampu membuat 2 platform sekaligus (android dan ios). Apalagi perusahaan yang model seperti ini tidak mempermasalahkan pasca-production “yang penting ada dulu produknya, urusan testing dan perbaikan bisa sambil jalan”.

Monggo yang mau berdiskusi, tanya-jawab dipersilahkan, toh saya juga masih newbie yang masih harus banyak belajar.

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.

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