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.
    mobile-owasp

    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.

Advertisements

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

Kerja Remote

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

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

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

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

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

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

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

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

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

Meninggalkan zona nyaman haruskah “resign” dari kantor?

Seseorang teman bilang: “yah, masa’ lo balik ke zona nyaman di kantor sebelumnya hanya krn lokasinya jauh?”
tak balas: “yg pgn balik ke zona nyaman siapa? itu pertimbangan jauh ya krn faktor kesehatan dan tingkat stress kalo macet. Tempat kerja baru, jauh sekali..trs saya minta balik ke kantor sebelumnya bukan berarti itu zona nyaman”

Meninggalkan lokasi kerja sebelumnya tidak sama dengan meninggalkan zona nyaman.
Zona nyaman jangan diartikan sempit sebatas tempat kerja.
Zona nyaman itu adalah tempat di mana seseorang merasa aman dan nyaman dan gak mau lagi mencoba hal baru, ragu mencoba sesuatu yang baru dan ragu buat belajar hal baru. Jadi zona seperti itu ya ditinggalkan, bukan kantornya yang ditinggalkan

Contohnya…misal orang tersebut posisi programmer, terus upgrade skill berbeda dengan “push” dan memotivasi diri sendiri untuk belajar sesuatu yang baru. Bisa juga dengan terjun langsung ke tantangannya. Misal: programmer kantoran, kerjaannya gitu2 aja, malah lbh banyak santai youtube-an di kantor, main game, terjun ke dunia proyek (bisa sambilan, bisa ngisi waktu pas liburan atau pas malam hari), walaupun dia belum punya pengalaman, dengan dia berani..dia sdh meninggalkan zona nyaman. Toh, dengan begitu dirinya tertantang buat belajar menghadapi klien, belajar berkomunikasi dengan orang yang berbeda, belajar mencari solusi dari permasalahan yang dihadapi klien dan bagaimana menyampaikannya dengan baik agar solusi tsb dapat diterima oleh orang lain, dan belajar pemrograman baru, teknologi baru, dll. Tanpa meninggalkan kantornya, dia sdh meninggalkan zona nyaman. Itu hanya sebagian contoh loh. Masih banyak contoh lain.

Contoh lainnya, misal dari programmer, tapi pengen naik tingkat ke level yang lebih tinggi, yaitu posisi analyst atau mungkin lebih tinggi lagi, posisi project manager. Jadi sembari dia kerja di kantor sebagai programmer, dia proactive, moving forward memperhatikan bagaimana analyst dan PM bekerja, dia gak malu bertanya, berdiskusi, ngajak makan bareng analyst atau PMnya, buat sekedar mendapatkan ilmunya dan menjalin komunikasi yang baik. Dia akhirnya punya inisatif tinggi di grup dan di kantor, tidak hanya menunggu bola, tapi juga menjemput bola sambil menyampaikan apa strateginya. Ini juga termasuk meninggalkan zona nyaman. 🙂 


Balik ke masalah lokasi, tempat lokasi itu jadi faktor penunjang performa kerja. Kalau tempat jauh, capek atau tua di jalan, performa menurun, boro-boro meninggalkan zona nyaman, buat dapet kenyamanan di kantor aja akan jadi sulit, lah sdh stress di jalan, kerja tentu jadi gak maksimal. Makanya tiap mulai kontrak kerja itu sebisa mungkin pro-active, nego, nanya, dan berdiskusi dengan baik agar ada jalan keluar dan solusi bersama, toh sama-sama butuh kan.


“Tapi kok kamu malah minta balik ke kantor lama sih, wid?” | “eittss, jangan salah..itulah strategi tarik ulur dalam negosiasi.. dengan klien-klienku juga tak pake cara serupa hehe..toh yang penting tiada yang dirugikan, dan kita tidak merugikan orang lain” (terinspirasi ibu-ibu yang nego harga di pasar..wkwkwk)

“Adaptive Design” di Aplikasi Android

Salah satu bentuk tantangan tersendiri di dalam pengembangan aplikasi Android adalah, membuat aplikasi yang well designed secara antarmuka, apalagi ada banyak keberagaman jenis device Android, baik dari ukuran layar (3 inci, 4 inci, 5 inci sampai 10 inci) maupun density (Android menggunakan satuan dp (pixel density) bukan pixel, ini mengacu pada konsentrasi pixel pada layar tertentu, diukur dalam pixel per inch (ppi). Kerapatan pixel (dp) ini dihitung dengan membagi resolusi pixel diagonal layar dengan ukuran diagonal).

Ngomong-ngomong soal pixel density. Bisa dicek di tabel berikut bagaimana acuannya untuk beberapa resolusi dalam satuan pixel ke density pixel:

---------------------------     -----   ------------    --------------- ------- -----------     ----------------    ---         ----------
Device                          Inches  ResolutionPX    Density         DPI     ResolutionDP    AspectRatios        SysNavYorN  ContentResolutionDP
---------------------------     -----   ------------    --------------- ------- -----------     ----------------    ---         ----------                                                          
Galaxy Y                                 320 x  240     ldpi    0.75    120      427 x 320      4:3     1.3333                   427 x 320
?                                        400 x  240     ldpi    0.75    120      533 x 320      5:3     1.6667                   533 x 320
?                                        432 x  240     ldpi    0.75    120      576 x 320      9:5     1.8000                   576 x 320
Galaxy Ace                               480 x  320     mdpi    1       160      480 x 320      3:2     1.5000                   480 x 320
Nexus S                                  800 x  480     hdpi    1.5     240      533 x 320      5:3     1.6667                   533 x 320
"Galaxy SIII    Mini"                    800 x  480     hdpi    1.5     240      533 x 320      5:3     1.6667                   533 x 320
?                                        854 x  480     hdpi    1.5     240      569 x 320      427:240 1.7792                   569 x 320

Galaxy SIII                             1280 x  720     xhdpi   2       320      640 x 360      16:9    1.7778                   640 x 360
Galaxy Nexus                            1280 x  720     xhdpi   2       320      640 x 360      16:9    1.7778                   640 x 360
HTC One X                       4.7"    1280 x  720     xhdpi   2       320      640 x 360      16:9    1.7778                   640 x 360
Nexus 5                         5"      1920 x 1080     xxhdpi  3       480      640 x 360      16:9    1.7778      YES          592 x 360
Galaxy S4                       5"      1920 x 1080     xxhdpi  3       480      640 x 360      16:9    1.7778                   640 x 360
HTC One                         5"      1920 x 1080     xxhdpi  3       480      640 x 360      16:9    1.7778                   640 x 360
Galaxy Note III                 5.7"    1920 x 1080     xxhdpi  3       480      640 x 360      16:9    1.7778                   640 x 360
HTC One Max                     5.9"    1920 x 1080     xxhdpi  3       480      640 x 360      16:9    1.7778                   640 x 360
Galaxy Note II                  5.6"    1280 x  720     xhdpi   2       320      640 x 360      16:9    1.7778                   640 x 360
Nexus 4                         4.4"    1200 x  768     xhdpi   2       320      600 x 384      25:16   1.5625      YES          552 x 384
---------------------------     -----   ------------    --------------- ------- -----------     ----------------    ---         ----------
Device                          Inches  ResolutionPX    Density         DPI     ResolutionDP    AspectRatios        SysNavYorN  ContentResolutionDP
---------------------------     -----   ------------    --------------- ------- -----------     ----------------    ---         ----------
?                                        800 x  480     mdpi    1       160      800 x 480      5:3     1.6667                   800 x 480
?                                        854 x  480     mdpi    1       160      854 x 480      427:240 1.7792                   854 x 480
Galaxy Mega                     6.3"    1280 x  720     hdpi    1.5     240      853 x 480      16:9    1.7778                   853 x 480
Kindle Fire HD                  7"      1280 x  800     hdpi    1.5     240      853 x 533      8:5     1.6000                   853 x 533
Galaxy Mega                     5.8"     960 x  540     tvdpi   1.33333 213.333  720 x 405      16:9    1.7778                   720 x 405
Sony Xperia Z Ultra             6.4"    1920 x 1080     xhdpi   2       320      960 x 540      16:9    1.7778                   960 x 540

Kindle Fire (1st & 2nd gen)     7"      1024 x  600     mdpi    1       160     1024 x 600      128:75  1.7067                  1024 x 600
Tesco Hudl                      7"      1400 x  900     hdpi    1.5     240      933 x 600      14:9    1.5556                   933 x 600
Nexus 7 (1st gen/2012)          7"      1280 x  800     tvdpi   1.33333 213.333  960 x 600      8:5     1.6000      YES          912 x 600
Nexus 7 (2nd gen/2013)          7"      1824 x 1200     xhdpi   2       320      912 x 600      38:25   1.5200      YES          864 x 600
Kindle Fire HDX                 7"      1920 x 1200     xhdpi   2       320      960 x 600      8:5     1.6000                   960 x 600
?                                        800 x  480     ldpi    0.75    120     1067 x 640      5:3     1.6667                  1067 x 640
?                                        854 x  480     ldpi    0.75    120     1139 x 640      427:240 1.7792                  1139 x 640

Kindle Fire HD                  8.9"    1920 x 1200     hdpi    1.5     240     1280 x 800      8:5     1.6000                  1280 x 800
Kindle Fire HDX                 8.9"    2560 x 1600     xhdpi   2       320     1280 x 800      8:5     1.6000                  1280 x 800
Galaxy Tab 2                    10"     1280 x  800     mdpi    1       160     1280 x 800      8:5     1.6000                  1280 x 800
Galaxy Tab 3                    10"     1280 x  800     mdpi    1       160     1280 x 800      8:5     1.6000                  1280 x 800
ASUS Transformer                10"     1280 x  800     mdpi    1       160     1280 x 800      8:5     1.6000                  1280 x 800
ASUS Transformer 2              10"     1920 x 1200     hdpi    1.5     240     1280 x 800      8:5     1.6000                  1280 x 800
Nexus 10                        10"     2560 x  1600    xhdpi   2       320     1280 x 800      8:5     1.6000                  1280 x 800
Galaxy Note 10.1                10"     2560 x  1600    xhdpi   2       320     1280 x 800      8:5     1.6000                  1280 x 800
---------------------------     -----   ------------    --------------- ------- -----------     ----------------    ---         ----------
Device                          Inches  ResolutionPX    Density         DPI     ResolutionDP    AspectRatios        SysNavYorN  ContentResolutionDP
---------------------------     -----   ------------    --------------- ------- -----------     ----------------    ---         ----------

Dan dokumentasi lengkapnya bisa dilihat di sini: https://developer.android.com/guide/practices/screens_support.html#testing

Itulah mengapa di dalam Resources Project di Android Application terdapat drawable dan layout dengan kategori ldpi (low-dpi), mdpi (medium-dpi), hdpi (high-dpi), xhdpi (extra high-dpi), xxhdpi, dan xxxhdpi.
Masing-masing kategori folder tersebut merujuk ke DPI layar device.
Jadi ketika ingin menerapkan aplikasi yang disupport di ukuran layar 3 inch (dengan dpi 160) dan 4 inch (dengan dpi 240), maka harus dicek di tabel di atas, bahwa dpi 160 itu adalah mdpi, so desain yang kamu siapkan mesti ditaruh di folder drawable/drawable-mdpi dan layoutnya di folder layout/layout-mdpi, begitu juga dengan DPI lainnya.

screen-shot-2017-01-13-at-4-07-46-pm

Lalu bagaimana caranya biar satu slicing desain saya bisa pas ditaruh di masing-masing folder tersebut (ldpi, mdpi, hdpi, dll) tanpa perlu repot?

Ada banyak cara loh! Caranya gak pake ribet, ada yang cara online dan ada yang cara offline.

Untuk membuat 1 komponen desain agar bisa diterapkan di masing-masing folder dpi tersebut dapat menggunakan generator, salah satunya 9-patch generator yang bisa dicoba secara online di sini. Dan untuk cara offline-nya, bisa dicoba langsung dari Android Studio dengan cara:

Install plugin “Drawable Importer” dengan cara masuk ke Preferences di Android Studio.

Setelah itu masuk ke bagian Editor\Plugins dan pilih Browse Repositories. Masukkan keyword “Android Drawable Importer” lalu klik “Install Plugin”, seperti pada gambar di bawah ini:

drawable_importer-1

Setelah itu tinggal digunakan dengan cara klik kanan file drawablenya dan pilih New\Scaled drawable. Dan ikutilah petunjuknya di layar.

Dengan mempersiapkan slicing komponen desain dengan berbagai ukuran layar, kita bisa membuat aplikasi tersebut menjadi adaptive design, tanpa khawatir aplikasi tersebut tidak cocok di berbagai ukuran layar.

5 tahun berlalu

Ada pepatah bijak mengatakan “Jika ingin berubah maka lakukanlah saat ini juga
Ya, saat ini juga, tanpa keraguan dan tanpa takut akan gagal.

Dahulu lulus kuliah hanya mengenal 1 bahasa pemrograman yaitu PHP (PHP: Hypertext Preprocessor), dan tidak banyak yang saya persiapkan, hanya mengikuti arus, bekerja setelah lulus, terima gaji yang waktu itu sangatlah kecil, sekitar 3jt, dan itu tinggal di Jakarta dengan menghabiskan biaya hampir 3 jt per bulan. Tidak mengerti bagaimana mengelola uang, tidak mengerti bagaimana nego gaji, tidak mengerti memilih tempat nge-kost, karena waktu itu kebetulan lulus sendiri, sementara teman seangkatan cuma 3 orang yang lulus, termasuk saya pribadi. Dan di Jakartapun bertemu teman-teman angkatan sebelumnya yang lumayan memandu saya untuk bertahan hidup di Jakarta.

Saya bukan tipe orang yang mudah sekali berteman, mungkin introvert. Dan bahkan selama kuliah saya hanya punya sedikit teman yang akrab, malah di kampus beberapa dijahilin teman seangkatan yang menganggap saya sombong (lambat laun saya menyesalinya). Kesulitan itu makin menjadi ketika banyak masalah pribadi pada waktu itu yang mengharuskan saya dipecat dari kantor karena bolos 3 minggu. Ya, jangan ditanya masalah apa, masalah anak muda hahaha…

Saya tidak akan bahas masalah itu, tapi yang saya coba cerita adalah saya bersyukur sampai hari ini, dengan lika-liku jalan yang sudah dilalui yang jujur saja banyak jalan sulitnya, tapi alhamdulillah bisa saya lakukan.

Alhamdulillah dengan banyak dukungan orang tua, teman, dan sekitar, buat move-on itu tidak sulit. Dahulu teman-teman yang saya cuekin, ternyata ketika saya jatuh, mereka malah memberi banyak dukungan. Pada waktu itu saya benar-benar menangis. Betapa berartinya teman. Dan sampai pada satu ketika saya memutuskan kembali ke Jogja, untuk mencoba memperbaiki semua, mengakrabkan kembali dengan teman-teman angkatan, walaupun agak sulit. Tapi alhamdulillah bisa saya nikmati, mulai dari tahun baru berkesan sampai pagi dengan teman seangkatan kuliah sampai acara-acara nonbar yang bener-bener penuh canda. Dalam hati, mengapa tidak saya lakukan dari dahulu. Tapi malah sibuk dengan kuliah, fokus belajar, menghilangkan segala sesuatu yang saya anggap penghalang dan ternyata semua itu tidak benar.

Saya kira karir saya bakal tamat,  setelah pemecatan itu, sampai menganggur 3 bulan, bingung, dan akhirnya saya coba lamar sana kemari, dan dari puluhan surat lamaran, ada 4 yang memanggil saya interview ke Jakarta.

Dengan biaya masih minta orang tua pada waktu itu untuk tiket pesawat dan uang makan selama perjalanan di Jakarta, rasanya sungguh malu sekali.

Dari 4 itu, ke-empat-empatnya pun menjawab “menerima”, sampai pada akhirnya saya diharuskan memilih, alhamdulillah, saya sempat mengira bakal pupus harapan, akhirnya bisa dijalani. Dari ke-4 itu, ada 3 lowongan sebagai php developer, dan 1 adalah asp.net developer. Apa yang saya pilih? sudah bisa ditebak, saya keluar dari zona nyaman saya. Memilih asp.net developer.

Saya tidak akan bercerita banyak bagaimana saya berani menerima tawaran asp.net padahal tanpa skill dasar asp sama sekali.Akan tetapi yang jelas, saya yakin saya bisa belajar. Ya, motivasi yang kuat. Di sana saya mendapatkan banyak pengalaman mencoba hal-hal baru. Sampai pada satu masa, saya tiba-tiba diangkat manager jadi system analyst yang merangkap jadi senior maintenance developer.
Dan hal gila pun terjadi, ketika bertemu dengan klien pertama kalinya, diterjunkan langsung ke kantor-kantor perbankan (BNI, BCA, BII, BRI, Danamon, Indonesia EximBank..hampir semua perbankan pernah saya datangi dan hinggap langsung bertemu dengan para manager dari berbagai divisi yang berkepentingan), saya selalu didampingi teman yang senior, tidak mengerti apa-apa selain teori yang saya pelajari selama kuliah. Bahkan sering kali melakukan kesalahan yang akhirnya diperbaiki oleh teman senior. Berani mencoba, berani menerima kesalahan dan berusaha memperbaiki. Sampai pada satu masa saya pernah merepotkan, seorang teman senior, yang saya ingat betul namanya, mas Aang (bukan pengendali udara). Mas Aang rela menemani saya di kantor klien sampai malam ketika semua orang sudah pulang dari kantor (yang pada waktu itu bank export import a.k.a. Indonesia Exim Bank). Dari kesulitan dan rasa tidak enak tersebut, ditambah rasa malu, motivasi belajar pun meningkat. Sampai pada satu ketika saya akhirnya memahami bagaimana proses bertemu klien, bagaimana menulis proposal, bagaimana cara nego dengan klien bagaimana cara berkomunikasi dengan klien dan segala hal yang berbau manajemen proyek.

Ya, benar, dari situlah saya akhirnya sekarang berani mengelola proyek, bukan sebagai developer ataupun freelance developer, tetapi menjadi manajer dari berbagai proyek langsung. Siapa yang jadi developer? saya merekrut teman-teman yang sama-sama senang dengan proyekan.

Pada tahun 2011, saya memutuskan untuk resign dari kantor di Jakarta, yang telah memberikan saya banyak teman dan pengalaman sangat-sangat berarti. Bahkan sampai manajer saya kaget, mengapa saya resign, apakah gaji saya kurang layak? ternyata sampai seperti itu yang tidak saya sangka-sangka. Ya saya akhirnya memutuskan untuk lanjut S2 karena pada waktu itu ibu saya ingin saya S2 saja, dan pas kebetulan pada waktu itu cukup biaya. Resign dari situ bukan berarti saya langsung menganggur, tetapi pada waktu itu saya sudah mempersiapkan dengan hati-hati kira-kira di Jogja kerja apa? dan akhirnya saya menerima tawaran teman yang saya kenal dari jejaring sosial Plurk, mas Yo, beliau punya start-up bernama PT. Dipeta, di sana saya memulai kembali menjadi php developer sekaligus android developer! Ya, dari situlah saya memulai menjadi android developer new wanna be.

Studi S2 saya tidak sepenuhnya mulus, saya seperti kurang siap dengan apa yang dihadapi, saya kira studi S2 saya bisa menunjang karir saya seperti yang teman saya ceritakan, ternyata sebaliknya, apa yang dipelajari malah kembali membawa saya dengan materi sistem cerdas dan sejenisnya yang tidak begitu saya sukai. Saya kira, saya bisa memilih kosentrasi di manajemen proyek ataupun Sistem Informasi, ternyata kebijakan kampus mengharuskan voting semua mahasiswa S2 seangkatan memilih kluster dengan suara terbanyak, dan didapatlah “SISTEM CERDAS”.

Sambil kuliah saya bekerja, ngoding ngoding dan ngoding, bikin sistem SMS-gateway, bikin sistem berbasis lokasi dan sejenisnya, dan selama 3 bulan berjalan, hubungan saya dengan atasan saya tidak berjalan mulus sejak kedatangan orang baru. Bahkan saya merasakan sekali perbedaannya ketika atasan saya meminta semua serba cepat, padahal saya memiliki 2 tanggungan di web dan di android yang tidak bisa dikerjakan instant. Dan akhirnya saya putuskan untuk resign.

Apakah saya jadi pengangguran? tidak, selama saya join dengan start-up tersebut, saya sudah terikat kontrak dengan BNI. BNI tertarik merekrut saya karena saya sering datang troubleshooting dan patching modul baru di front-end perbankan mereka ke kantor pusat BNI. Dan dari situ beberapa divisi mulai kenal saya secara pribadi sampai memiliki kontak saya. Pas di Jogja, alhamdulillah direkrut dan saya bekerja sebagai administrator fan-page facebook BNIdan juga developer di beberapa micro-site milik BNI. Bekerja di sana sangat menyenangkan, dengan bayaran 2jt per minggu bukanlah sesuatu yang murah. Dan alhamdulillah sangat mencukupi kebutuhan selama di Jogja.

Dan sambil bekerja di BNI, akhirnya saya memutuskan jadi project hunter. Saya menggunakan teknik self-promotion di facebook dengan cara  “show-off” karya-karya sendiri dan akhirnya dikenal. Dan dari situ tawaran-tawaranpun datang. Dari tawaran-tawaran tersebut, saya mulai praktekan teknik yang saya pelajari selama bekerja di Jakarta. Mulai dari menyiapkan proposal, menyusun kalimat-kalimatnya menjadi sistematik, menyusun rancangan aplikasi, menyusun deliveriables, menyusun gantt-chart timeline pekerjaan, menyusun anggaran proyeksi investasi sampai dengan layanan yang saya persembahkan untuk klien.

Apakah berjalan lancar ? ya sebagian besar, alhamdulillah lancar, sebagian kecil tidak. Berhadapan langsung dengan proyek bukan sesuatu yang mudah, penuh dengan rintangan. Rintangan pertama adalah menghadapi klien. Saya menyadari betul pada akhirnya, setiap klien itu berbeda karakteristiknya, komunikasinya dan cara pandangnya. Ditambah lagi dengan tingginya persaingan.
Awal mulanya, ketika mengajukan proyek, tidak semuanya lancar, bahkan gagal, melakukan kesalahan menyusun jadwal, melakukan kesalahan mengatur anggaran sampai akhirnya merasakan kerugian di diri sendiri.

Ya, merugi, apa yang saya kerjakan ternyata terlalu murah sampai-sampai harus begadang garap proyek padahal hasilnya tidak seberapa, dan pada akhirnya saya belajar dari situ untuk mengkalkulasi dengan pas dari masalah waktu sampai biaya.

Proyek pertama yang saya berhasil adalah dengan klien PDAM, digarap berdua, saya mengelola proyeknya, dan teman sebagai developernya. Harga proyek waktu itupun wah, yaitu 40jt, dan itu kami bagi 2 masing-masing 20jt. Dan dari situlah saya punya tv, gadget dan console sendiri di kost-kostan waktu S2 itu (jangan ditiru foya-foyanya)

Sejalannya waktu, proyekpun datang lagi dari tawaran teman di Departemen Keuangan, tawaran di BNI lagi, tawaran di hotel Pullman Jakarta, PLN Bandung, Humanitarian OpenStreetMap, JTETI-UGM, PLN Medan, Kementerian Agama RI, PLN Medan lagi, dan seterusnya…dan karena itu akhirnya bisa keliling beberapa kota di Indonesia secara gratis sambil menikmati hotel-hotelnya 😀 tawaran yang saya ambil bukan yang kecil, kadang satu proyek bernilai 35jt, kadang 40jt, dan bahkan pernah lebih, apakah tanpa tantangan? besar banget, ya kudu kuat hadapi yang besar, great power, great resposibility, great income too.

Dan bukan juga tanpa hambatan dan tanpa kegagalan, taruhlah dengan pengalaman saya akhir-akhir ini di mana, developer yang saya rekrut melakukan keteledoran dengan jadwal yang ia buat dan akhirnya ia ingkari hingga telat 1 bulan. Dan juga dahulu pernah mengalami demikian sampai-sampai harus menggunakan uang pribadi untuk membayar designer dan developer padahal telatnya ya karena klien minta macem-macem dan ngeyelan padahal sudah dipandu cara buat reporting ke developer jika menemukan bugs. Ya dulu pengalaman dengan salah satu perusahaan di Sukabumi yang benar-benar jadi pelajaran buat saya pribadi sekaligus harus lebih cermat memilih tim dan mengelola proyek, terutama bagaimana menghadapi klien yang jumlah anggotanya banyak dan semuanya ikut campur. Ya kesalahan ada di saya selaku manajer kenapa kurang tegas dan kurang cermat mengelola proyek ini sampai jadi gagal.

Gagal dari 1 proyek itu bukan berarti saya lengah dan menyerah, dari situ saya mulai menerima tawaran dari PusatKajianHadis dapet proyek membuat aplikasi Alquranalhadi di Android. Dan sampai pada akhirnya, alhamdulillah, menjelang saya melamar wanita pujaan hati, saya malah direkrut jadi karyawan tetap di PKH. Pas banget! dengan begitu menghadapi calon mertua jadi agak PeDe (walau masih degdegan) karena waktu itu saya minder dengan status pekerjaan saya yang kurang jelas (apalagi kerjanya dari kost-kostan, gimana mau yakin, ntar dikira pelihara tuyul), alhamdulillah, lamaran diterima dan menikah oktober 2013 kemarin. Dan dikaruniai seorang putri cantik yang sekarang usianya 1 tahun 🙂

PKH memberikan keleluasaan kepada saya, membolehkan saya menyambi proyek asalkan semua pekerjaan di PKH dapat tuntas sesuai jadwal dan terus monitoring setiap aplikasi yang saya kembangkan di PKH agar tetap berjalan sebagaimana mestinya setiap waktu untuk semua pengguna.

Sampai detik ini, alhamdulillah, saya sudah 3 tahun bekerja di PKH dan masih aktif dengan proyek-proyek, bahkan sempat mengajar jadi mentor developer android di beberapa kampus di Jogja (UGM, UMY, UNY, AtmaJaya), dan sempat jadi dosen 1 semester di STMIK A.Yani, dan saat ini terikat kontrak kerja proyek dengan SaleStock dan Samsung (padahal dulu sempat manggil interview jadi developer android, tapi saya tolak), dan alhamdulillah, 2 tahun lebih kami menikah, dan sekarang punya rumah sendiri dan menikmati perjalanan hidup ini bersama istri dan anak tercinta.

Saat saya sudah bekeluarga, saya harus pahami hak dan kewajiban saya sebagai seorang suami dan kepala keluarga, dan diputuskan sampai saat ini saya hanya fokus di pekerjaan PKH dan max. 2 proyek saja. Maka dari itulah saya berhenti dari profesi dosen yang lumayan menyita waktu dan lokasinya cukup jauh dari tempat tinggal. Dan bekerja dari rumah sekaligus menemani istri dan anak, tiap hari conference call via skype dan telpon dengan klien dan tiap hari bertemu laporan-laporan, trello, basecamp dan tiap hari masih ngoding, dan yang terpenting adalah..rasa syukur. Rasa syukur menambah nikmat di sanubari. Makan seadanya, ya bersyukur, makan banyak juga bersyukur, punya rezeki, sedekah sbg rasa syukur, lagi sempit rezeki, tetep bersyukur sambil introspeksi diri.

Perjalanan ini masih berliku, mungkin yang diceritakan seakan hidup ini mudah, padahal banyak rintangannya. Namun, saya slalu yakin, rezeki tidak pernah tertukar, tiap orang punya jalannya masing-masing, yakin Allah akan mencukupi kebutuhan, dan terus berusaha agar orang-orang di sekitar senang dengan keberadaan saya.

Semoga Allah selalu memudahkan jalan ini dan melimpahkan rezeki, kesehatan dan kekuatan untuk kita semua agar dapat mengarungi hidup dan slalu pada jalan yang lurus. aamiin.