Kenapa saya mematikan fitur Instant Run pada Android Studio

Fitur Instan Run merupakan fitur yang relatif baru pada Android Studio. Fitur ini bertujuan untuk mempercepat proses run aplikasi ataupun debug pada Android Studio. Proses instalasi debug pada Android Studio dikenal cukup lambat, dari proses build APK debug sampai proses instalasai pada device ataupun emulator. Instant Run memperbaiki hal ini dengan mengubah proses instalasi keseluruhan APK untuk setiap run aplikasi menjadi instalasi kode yang berubah saja. Pada kasus normal, fitur ini mampu membuat proses run menjadi sangat cepat, dapat terjadi hampir seketika. Untuk perubahan yang hanya terjadi di file xml view saja, Android Studio bahkan hanya perlu melakukan restart activity yang sedang berjalan. Hal ini sangat merupakan angin segar untuk developer android, terlebih lagi yang banyak bereksperimen dengan view melalui perubahan file xml.

Biasanya, pada awal session run atau debug, instant run membuat APK yang khusus untuk device atau emulator yang akan dijalankan. Hal ini memakan waktu lebih lama, tapi ini tidak masalah karena build dan run selanjutnya dapat berjalan dengan cepat. Walaupun begitu, dari pengalaman saya mengerjakan aplikasi Android, untuk kasus-kasus tertentu, hal diatas menjadi kelemahan yang fatal untuk fitur Instant Run ini.

Terdapat dua kasus yang membuat fitur ini menjadi terasa menyebalkan. Kasus pertama adalah ketika developer harus melakukan run kepada device yang sering harus dicopot dari laptop. Saya menggunakan device saya sendiri untuk menjalankan aplikasi yang saya buat. Ketika saya akan pergi makan atau shalat, tentu saya akan melepas device saya dari laptop. Ketika saya memasang kembali device saya ini, Instant Run mendeteksi ini sebagai session baru sehingga melakukan rebuild ulang APK untuk device tersebut. Hal ini juga terjadi jika kabel penghubung device tersebut tergeser atau terlepas. Android Studio yang biasanya langsung dapat melakukan run dengan cepat karena tidak ada perubahan kode, sebaliknya karena instant run aplikasi dibuild kembali dengan waktu yang cukup lama.

Kasus kedua adalah ketika proyek yang dilakukan adalah membuat library yang digunakan pada banyak aplikasi seperti Appsterize. Appsterize merupakan aplikasi yang didesain untuk dapat menciptakan aplikasi mobile dengan cepat. Setiap kali saya akan melakukan build dan run untuk aplikasi-aplikasi yang berbeda, Android Studio mendeteksi ini sebagai session yang baru. Hal ini menyebabkan banyak terjadinya build awal pada Instant Run yang memakan waktu cukup lama.

Saya juga menemukan beberapa bug yang saya duga terjadi karena fitur Instant Run ini. Kasusnya adalah sebagai berikut. saya melakukan run kemudian saya melepas device atau menekan tombol stop session pada Android Studio. Setelah itu saya melakukan uninstall aplikasi. Ketika melakukan run kembali, Android Studio tidak mendeteksi bahwa di device saya sudah tidak terinstall aplikasi tersebut, kemudian Android Studio berusaha menjalankan aplikas tersebut. Hal yang terjadi adalah error. Cara untuk memperbaiki ini adalah dengan melakukan perubahan kode, atau melakukan Clean and Rebuild yang memakan waktu cukup lama ataupun restart Android Studio.

Hal tidak nyaman berikutnya adalah APK yang telah di Build tidak dapat diinstal di device lain karena Build yang dilakukan adalah incremental khusus untuk device yang dituju. Kasus lain yang serupa adalah APK tidak dapat diinstal di device dibawah Android versi terbaru karena device tersebut belum mendukung fitur Instant Run. Hal yang dilakukan untuk masalah ini adalah dengan memilih opsi Build APK yang memakan waktu cukup lama juga.

Berdasarkan hal-hal tersebut, saya mengambil kesimpulan untuk tidak menggunakan fitur Instant Run. Jika anda ingin mematikan fitur Instant Run Ini, maka pastikan versi Android Studio anda adalah 2.1.2 ataupun lebih tinggi. Karena di versi sebelumnya, Instant Run menjadi fitur default yang tidak dapat dinon aktifkan. Berikut langkah-langkahnya :

  • Buka halaman setting atau preferences. Untuk windows ada di menu File > Settings sedangkan untuk Mac ada pada menu Android Studio > Preferences
  • Pilih menu Build, Execution, Deployment > Instant Run
  • Hilangkan centang pada bagian Enable Instant Run dan Restart Activity on Code Change

Fitur yang harusnya mempercepat dan mempermudah, berakibat mempersulit dan membuat lebih lama karena belum menangani kasus-kasus tertentu. Pada akhirnya, kita sebagai user lah yang menentukan akan memakai fitur tersebut atau tidak. Saya sendiri mungkin untuk proyek lain akan memilih untuk menggunakan fitur tersebut.

Jika ada yang menemukan hal berbeda dari saya, yuk kita bisa diskusi di bagian komentar :D. Diskusi juga bisa di halaman facebook saya.

Cheers.

Mid Year Review

Mid Year Review adalah sesuatu yang baru dilakukan di Radya Labs. Tahun ini memang kita sedang mengusahakan untuk meningkatkan fungsi organisasi di perusahaan. Hal ini baru bisa dengan rapi dilakukan setelah kita pada tahap memiliki layer management di atas layer tim pengembang, desainer, dan QA. Radya Labs sendiri saat ini memiliki total karyawan 22 orang.

Untuk melakukan mid-year review tentu saja kita harus melihat kembali target yang sudah ditetapkan di awal tahun. Kami sendiri sudah menetapkan beberapa target dan sudah pernah dibahas disini.

Target Pemasukan

Pemasukan atau revenue merupakan sumber bahan bakar untuk perusahaan. Maka it’s very natural untuk melihat angka tersebut sebagai salah satu indikator penting keberjalanan perusahaan. Hal pertama yang dilakukan adalah melihat rasio pencapaian target per tengah semester ini dibandingkan dengan target di akhir tahun.

Dari sini, kami dapat mengukur, berapa jumlah dan nilai proyek yang harus dicari dan dikerjakan pada sisa tengah semester ini agar target tersebut dicapai. Dari pengalaman Radya Labs sebelumnya, mengenai rasio jumlah opportunity dan jumlah opportunity yang akhirnya closing, kita jadi mengetahui berapa banyak lead yang harus dihasilkan. Rasio opportunity : opportunity yang akhirnya closing adalah perbandingan sederhana yang membantu kami untuk menentukan berapa banyak lead yang harus dihasilkan tim marketing & sales. Dari pengalaman sebelumnya, kita mendapatkan rasio 4:1 artinya jika ada 4 opportunity yang berhasil dikonversi menjadi proyek adalah 1 opportunity. Jumlah opportunity yang diperlukan untuk mencapai target finansial di akhir tahun menjadi target organisasi marketing/sales di sisa semester ini.

Hal berikutnya yang dilakukan adalah menghitung produktivitas per kru, dihitung dari jumlah revenue yang dihasilkan dibandingkan dengan jumlah kru Radya Labs. Teknik ini dikenal dengan istilah revenue per employee dihitung dengan membagi jumlah revenue dengan jumlah karyawan. Jumlahnya makin besar artinya makin baik. Nilai ini kemudian bisa dibandingkan dengan perusahaan yang bergerak di industri yang sama untuk mendapatkan gambaran pencapaian.

Dari hasil diskusi dengan Pak Budi Rahardjo, untuk di Indonesia, beliau mengambil angka minimal 200 juta untuk mengukur performa bisnis perusahaannya. Menarik jika ada perusahaan yang melakukan riset untuk mengukur performa usaha jasa di bidang IT di Indonesia – mungkin ada dan saya tidak tahu – agar perusahaan yang bergerak di bidang sejenis dapat mengevaluasi keberjalanan bisnisnya dengan lebih terarah.

Sebagai perbandingan, perusahaan diluar negeri, seperti IBM mampu membukukan $ 244,447 / employee. Anda bisa baca disini untuk 12 perusahaan IT terbesar di dunia. Kalo dari kami, yang ingin dilihat adalah apakah nilai revenue per employee ini harus meningkat setiap tahunnya. Kita belum akan menganalisis lebih jauh, komparasi dengan kompetitor dan lain sebagainya.

Kualitas Pekerjaan

Karena sebagian besar revenue masih bersumber dari pengerjaan proyek maka hal yang pertama ingin dilakukan adalah mengetahui bagaimana persepsi para klien yang sudah pernah bekerja sama dengan kami terhadap kualitas pekerjaan yang kami hasilkan. Ada dua hal yang kami lakukan : (1) Melakukan survey pasca pelaksanaan proyek , (2) dan jika proyek menghasilkan aplikasi mobile, melihat rating dari aplikasi tersebut.

Untuk melakukan survey, karena ini pertama kalinya kami melakukan hal tersebut, kita tidak ingin membebani klien dengan pertanyaan yang panjang dan membingungkan. Tujuan pertama kami adalah mendapatkan baseline untuk digunakan ke depannya. Tito – direktur Radya Labs – sudah menetapkan untuk menggunakan NPS sebagai indikator kepuasan pelanggan dengan harapan hal tersebut mengindikasikan kualitas pekerjaan yang dihasilkan. Selain itu, ada beberapa item pertanyaan yang khusus dimaksudkan untuk mengetahui beberapa hal detail dalam proses pengerjaan proyek.

Setelah mendapatkan hasil survey, kita bandingkan dengan target NPS yang sudah ditetapkan sebelumnya. Lagi-lagi, jika hasilnya melebih target atau kurang dari target, kami belum membatasi evaluasi secara rigid. Menemukan baseline adalah tujuan utama dari sini.

Hal kedua, adalah melihat rating aplikasi. Ada 3 proyek yang menghasilkan aplikasi mobile sehingga kita melihat rating dari aplikasi tersebut. Target yang kita tetapkan untuk setiap aplikasi yang dihasilkan adalah 3.5.

Peningkatan Kapasitas Kru

Ini merupakan hal yang ingin kita miliki di Radya Labs. Kita ingin, sebagai perusahaan, mampu memfasilitasi para kru untuk terus dapat berkembang. Semakin baik perkembangan para kru, pada prosesnya akan berdampak pada kualitas pekerjaan. Dari sisi teknologi yang saya lakukan adalah melakukan analisis terhadap seluruh pekerjaan yang sudah kita kerjakan hingga saat ini dan melihat benang merah dari teknologi-teknologi yang pernah kita hasilkan dan kita gunakan untuk mendukung pekerjaan berikutnya. Setelah melakukan pendataan tersebut, hal selanjutnya yang perlu dilakukan adalah memastikan setiap kru memiliki informasi yang sama sehingga informasi tidak terkotak-kotak atau dimiliki salah satu orang saja. Dengan demikian, kapasitas kru dapat ditingkatkan dengan saling berbagi hal-hal yang dikerjakan oleh kru yang lain. Harapannya, kita akan kuat sebagai tim, bukan hanya individu.

Ini adalah contoh hasil analisis yang saya dapatkan.

image

Selanjutnya adalah eksekusi dari rencana ini meliputi:

  • Kru yang mencicipi teknologi tersebut, membuat snippet code yang siap di-refer kembali jika ada proyek yang membutuhkan.
  • Setelah snippet code, kru yang mencicipi melakukan sharing kepada rekan-rekan yang lain

Selain itu masih ada beberapa hal lain dari sisi teknologi yang ingin jika dilakukan, misalnya melakukan satu eksplorasi yang bisa menjadi teknologi penting atau menjadi ciri khas dari perusahaan. Saya belum memutuskan apa yang akan dikerjakan karena juga sedang dalam pembahasan dan inisiasi. Mungkin cerita untuk blog post yang lain Smile.

Demikian sedikit intipan mengenai kegiatan mid-year review yang dilakukan di Radya Labs. Harapannya, kita sebagai organisasi dan invidu dapat terus berkembang menjadi lebih baik dari versi kita yang sebelumnya.

Teknologi Xamarin Untuk Mengembangkan Aplikasi Multiplatform

Pada 25 May 2016, salah satu kru Radya Labs, Albilaga, Software Engineer Radya Labs, mengisi workshop pengembangan aplikasi cross platform menggunakan Xamarin. Acara ini diadakan oleh DiLo Bandung dan didukung sepenuhnya oleh Microsoft.

Xamarin-6

Pada kegiatan ini, disampaikan materi mengenai Xamarin secara umum dan Hands-on-Lab menggunakan Xamarin.Android. Peserta yang hadir mencapai 30 orang dan semuanya bersemangat mengikuti kegiatan dan mencoba tugas yang diberikan oleh trainer.

Yang perlu diingat, Xamarin bukan merupakan solusi untuk semua permasalahan pengembangan aplikasi multiplatform. Xamarin akan tepat digunakan jika Anda :

  • Memiliki Tim yang menguasai bahasa pemrograman C# dan XAML
  • Menargetkan multiplatform dengan memaksimalkan code-sharing
  • Mau bertoleransi dengan ukuran aplikasi (yang akan membengkak akibat penggunakan beberapa library wajib supaya)
  • Memahami adanya kemungkinan (meskipun mungkin sangat kecil) adanya fitur yang tidak didukung dan atau fitur yang sulit diimplementasi dibandingkan menggunakan teknologi native bawaan platform tsb.

Xamarin memiliki 2 teknologi yaitu Xamarin.Android/Xamarin.iOS (kita sebut Xamarin ) dan Xamarin.Form. Pada Xamarin, bagi yang sudah mengenal salah satu pola yang biasa digunakan untuk pengembangan aplikasi, misalnya MVC maka Xamarin dapat digunakan untuk mengerjakan bagian model dan controller, pada sisi view, tetap harus menggunakan native interface bawaan masing-masing platform. Dengan teknik ini, code sharing bisa berkisar diantara 60-70%. Sedangkan Xamarin.Form dapat digunakan untuk 100% code sharing namun memaksa kita mengerjakan bagian view menggunakan XAML, yang pada saat runtime nanti akan dihasilkan tampilan sesuai dengan karaktek platform masing-masing.

Menurut dokumentasi Xamarin, pendekatan Xamarin mana yang terbaik untuk pengembangan aplikasi Anda ?

Gunakan Xamarin Form jika :

  • Aplikasi membutuhkan sedikit sekali fungsionalitas yang terkait ke spesifik platform
  • Aplikasi mementingkan code sharing dibandingkan dengan antarmuka yang sangat custom
  • Pengembang menguasai XAML

Gunakan Xamarin.iOS dan Android jika:

  • Aplikasi membutuhkan interaksi native dengan platform
  • Aplikasi banyak membutuhkan fitur spesifik dan API
  • Aplikasi membutuhkan custom UI yang banyak

Xamarin-5

 

Validating Your Business Idea ?

Kira-kira enam bulan yang lalu, saya dikenalkan Niki, founder Goers,  kepada seseorang yang memiliki ide bisnis. Dia sudah menyelami bisnis laundry selama 2 tahun terakhir. Menurutnya ada layanan yang bisa dikembangkan di seputar layanan laundry. Dia sudah melakukan survey melalui Jakpat. Dia sudah melakukan FGD untuk memeriksa kemungkinan eksekusi ide tersebut. Ia mendatangani Radya Labs untuk kemungkinan kerja sama pengembangan aplikasi. Dibutuhkan sistem yang cukup besar, 2 aplikasi customer, 1 aplikasi agen dan 1 backend system. Saya sampaikan bahwa dengan sistem seperti itu dibutuhkan waktu paling tidak empat bulan dan biaya yang lumayan. Dia belum mendapatkan investasi. Dia ingin membiayai semuanya dari uangnya sendiri. Tekadnya kuat sampai saya kagum. Bulan Febuari lalu, produknya berhasil diluncurkan. Taptopick, adalah layanan on-demand laundry yang siap meringankan beban anda dalam urusan cuci-mencuci.

Beberapa kali ada yang menghubungi saya untuk berdiskusi dan bercerita mengenai ide bisnis yang dimiliki. Beberapa yakin idenya disruptif. Beberapa bilang idenya adalah the next best thing. Beberapa yakin idenya akan menjadi bisnis yang besar. Namun, untuk memulai bisnis tersebut, keluhan yang umum disampaikan adalah (1) kekurangan dana untuk mengeksekusi bisnis, (2) tidak mengetahui cara membangun sebuah app untuk bisnis tersebut , (3) dan lain-lain.

Ingin memastikan apakah ada demand terhadap pembelian bersama suatu jenis produk dengan harga miring (group buying), Andrew Mason membuat sebuah website menggunakan WordPress. Bagi Anda yang tidak tahu WordPress, itu adalah alat untuk membuat website dengan mudah dan cepat tanpa harus mengetahui seluk beluk pemrograman. Berbekal alat gratisan, Andrew mulai menjual barang di website tersebut. Barang-barang dijual dengan harga miring jika dan hanya jika sejumlah orang ingin membeli barang tersebut. Katakanlah, tiket nonton AADC akan dihargai 10.000 rupiah jika ada 200 orang yang ‘berjanji’ akan membelinya. Listing barang ditampilkan menggunakan sistem post biasa layaknya tulisan yang Anda baca ini. Bedanya, ada gambar, keterangan jumlah minimal orang dan harga.

Tidak ada fitur pencarian advanced, tidak ada form pemesanan bahkan add-to-cart apalagi payment. Sebuah website sederhana, working prototype. Bisa jadi Andrew mengambil jalan itu karena ingin menguji hipotesisnya  tanpa harus menghabiskan banyak sumber daya dahulu di awal. Ide-nya adalah memastikan  apakah memang ada orang yang mau membeli barang secara bersama-sama dengan skema group buying seperti itu.

Andrew Mason adalah founder dari Groupon.com, website daily deals yang diluncurkan pada tahun 2008, mulai menghasilkan keuntungan pada tahun 2009 dan mencapai valuasi USD 1.35 billion pada tahun 2010. Dengan keterbatasan yang ada, ia memilih untuk membangun prototipe menggunakan tools yang tersedia agar dapat secepat mungkin menguji hipotesisnya.

Radya Labs sebagai mobility solution provider, salah satu segmen pelanggan kami adalah startup atau sekelompok orang yang ingin membangun bisnis. Terkadang mereka datang bukan dari latar belakang IT. Terkadang mereka startup, namun belum memiliki tim inti. Mereka akan membutuhkan jasa mengembangkan aplikasi sebagai bagian dari produk mereka. Karena masih tahap awal, seringkali memiliki keterbatasan sumber daya untuk mendanai atau mengembangkan aplikasinya.

Biasanya, klien tipe ini ingin langsung memiliki sebuah well-polished app sebagai bagian dari strategi produk mereka. Sebuah well-polished app membutuhkan waktu yang tidak sebentar untuk dikembangkan. Banyak bagian yang harus dianalisis, mungkin perlu dibangun dari awal, atau bagian yang terkesan mudah ternyata secara teknis sulit sekali diimplementasi. Klien tipe ini adalah yang menginginkan aplikasi yang sangat bagus, dengan sangat cepat dan harga yang sangat murah. Sayangnya, itu adalah utopia. Aplikasi yang sangat bagus dan cepat dikembangkan biasanya harganya sangat mahal. Cepat, murah, bagus…pilih dua.

Beberapa bulan yang lalu, seorang teman menanyakan biaya pembuatan aplikasi seperti gojek tapi untuk kurir sepeda. Mereka menginginkan dua aplikasi untuk customer di Android dan iOS, satu aplikasi Android untuk kurir menerima order dan satu aplikasi web untuk melakukan administrasi kurir, customer dan melihat order bagi admin. Sistem lengkap. Paket gojek kalau saya bilang. Untungnya, teman ini memahami bahwa sistem sebesar itu butuh waktu yang sangat lama, mungkin empat hingga lima bulan dan memakan biaya bisa hingga 500-an juta. Tentu saja, tidak semua startup mampu menyediakan dana tersebut diawal mereka beroperasi.

Selang berapa lama, di Bandung muncul usaha kurir sepeda. Untuk memesannya tidak membutuhkan aplikasi. Cukup tambahkan nomor Whatsapp call center perusahaan tersebut. Dengan format pesan tertentu, sebuah order dapat dilakukan. Di sisi kurir, juga menggunakan Whatsapp untuk berkomunikasi. Mereka adalah orang yang sama dengan tim yang ingin dibantu teman saya. Dengan batasan yang ada akhirnya mereka memutuskan untuk membuat protitpe, untuk menguji hipotesis apakah akan banyak permintaan kurir seperti ini menggunakan aplikasi Whatsapp yang sifatnya gratis. Mereka menguji ide bisnis yang mereka miliki, dengan cara yang mereka tahu dan sesuatu yang mereka punyai.

Gojek hari ini adalah fenomena di ibu kota. Aplikasi Android  dan iOS nya sudah didownload jutaan orang. Tapi ternyata bisnis ini bermula dari sebuah call center. Untuk memesan ojek, Anda tinggal memesan nomor telpon tertentu, memberikan alamat penjemputan dan ojek tersebut akan datang. Itu adalah tahun 2011 ketika konsep gojek bermula di kepala Nadiem Makarim, CEO Gojek saat ini. Empat tahun kemudian, baru di tahun 2015, aplikasi Android dan iOS diluncurkan. Gojek booming. Dan semuanya merasa itu 100% karena didukung oleh aplikasi. Saya rasa tidak juga. Berbekal call center, mungkin Nadiem sudah melihat begitu tingginya permintaan transportasi roda dua yang menjadi pilihan favorit warga di tengah kemacetan ibu kota. Sebelum membuat aplikasinya, diuji dulu menggunakan pemesanan melalui telpon. Nadiem menguji ide bisnis yang ia miliki, dan menempuh cara tercepat untuk memastikan ide bisnis tersebut.

Sudah cek fitur go-massage dan go-glam ? Hingga sekarang fitur di aplikasi gojek tersebut masih berupa website. Saya rasa mereka ingin memeriksa demand terlebih dahulu dan menempuh cara tercepat – membenamkan sebuah website, daripada membuat aplikasi native – untuk memastikan ide tersebut mendapat sambutan dari masyrakat.

Terkadang, untuk menguji ide bisnis yang kita miliki, kita perlu memulai dari apa yang kita bisa dan kita ketahui. Saat ini, banyak tools yang dapat membantu. Mungkin ini adalah alasan banyak orang berjualan melalui Instagram. Belum perlu memiliki sebuah website e-commerce, uji dulu apakah banyak orang yang ingin membeli baju bayi, baju muslim dan sebagainya. Daripada membangun sebuah website e-commerce lengkap dengan berbagai fitur, lihat dulu permintaan pasarnya. Atau Anda juga dapat mulai berjualan di situs seperti Tokopedia dan Bukalapak. Dan jika membutuhkan toko aplikasi di smartphone, bisa juga menggunakan Appsterize.com, cara mudah dan cepat memiliki toko online di smartphone pelanggan.

Pengecualian tentunya bagi anda memiliki sumber daya yang cukup. Anda benar-benar tahu apa yang ingin dilakukan. Anda merupakan veteran di suatu vertikal bisnis dan melihat peluang terbuka begitu lebar. Anda sangat faham betul resikonya. Kami, Radya Labs, ada untuk Anda, membantu anda mengeksekusi ide bisnis Anda melalui pengembangan aplikasi. Media sosial, e-reader, atau on-demand solution ? Kontak kami di info@radyalabs.com.

Sinkronisasi Jadwal Dengan Google Calendar

Saya yakin saat ini tim Anda menggunakan WhatsApp atau messaging app lainnya untuk berkomunikasi satu sama lain. Di organisasi Anda akan ada grup untuk BOD, grup untuk Developer dan mungkin pembagian grup berdasarkan divisi atau fungsi kerja. Hal yang menyulitkan ketika seluruh pembicaraan dilakukan via messaging app adalah begitu mudahnya suatu hal terlewatkan ketika kita tidak pay attention atau kesulitan mengacu kembali terhadap apa yang sudah dibicarakan. Terkadang chat tidak selamanya efektif karena karakteristik chat itu sendiri.

Kemarin, saya mendapatkan suatu pengalaman yang membuat saya menulis blogpost ini. Saya dikontak pukul 5 sore, di tanggal merah, di hari keagamaan yang dirayakan oleh kru Radya. Karena memang kondisinya sulit sekali untuk memberikan solusi sesuai permintaan, saya menyampaikan alasan yang menurut saya masuk akal dan bernegosiasi agar permintaan dipenuhi pada hari ini.

Satu hal penyebabnya, transparansi jadwal. Hal ini mudah terjadi ketika anggota tim tidak mengetahui kegiatan anggota tim yang lain. Untuk menyikapi hal ini, di Radya Labs, kami menggunakan teknik sederhana, menggunakan Google Calendar.

Saat ini, ada empat orang di Radya Labs yang punya fungsi berbeda dan sering kali harus meninggalkan kantor. Pada kasus ekstrim, keempat orang ini bisa bersamaan tidak di kantor. Pada saat yang lain, satu orang perlu mengatur jadwal meeting untuk dihadiri oleh orang lain. Misalnya, saya ditelpon klien, dan minta bertemu di Jakarta, pada saat yang bersamaan berarti saya harus mengetahui jadwal Faizal supaya bisa memenuhi permintaan tersebut.

Sejak awal tahun lalu, kami memanfaatkan Google Calendar, yang dapat dilihat secara bersama oleh kami berempat. Setiap orang yang mendapat jadwal pertemuan, wajib membuat satu entri, mengenai pertemuan tersebut, jam berapa dan orang yang terlibat. Setiap ada permintaan bertemu, kami tinggal memeriksa kalender tersebut. Formatnya sederhana :

Nama Kegiatan @ Lokasi – Nama Yang Terlibat.image

Dengan cara ini, saya dapat mengetahui dengan cepat, kapan saja rekan-rekan memiliki jadwal sehingga tidak perlu diganggu atau menanyakan hal-hal yang perlu disiapkan oleh saya terkait pertemuan tersebut. Misalnya, jika Tito akan meeting dengan klien, dan kebetulan pembicaraannya terkait teknologi, sudah kewajiban saya untuk menanyakan beberapa hari sebelumnya, apakah ada yang perlu saya siapkan atau tidak. Atau hal lain, Faizal minggu depan akan meeting dan meminta saran mengenai suatu perkara teknis yang mungkin diperlukan di proyek tersebut.

Dengan hal ini, besar harapan kita dapat melakukan sinkronisasi jadwal dengan baik.

Karena sesungguhnya, sedapat mungkin kita dapat membagi waktu, antara pekerjaan dan hal lain diluar pekerjaan. Dengan sinkronisasi jadwal yang baik setidaknya menjadi salah satu cara untuk mendekati hal tersebut.

What I’ve Learned from Incode.design : Idea is cheap, Execution is everything.

Hackathon merupakan kegiatan yang sangat digandrungi developer saat ini. Kegiatan coding semalam suntuk itu dijadikan ajang ‘rekreasi’ bagi para pengembang aplikasi. Mencoba membuat sesuatu, hal lain diluar dari pekerjaan sehari-hari mereka.

Saya pun cukup sering mengikuti Hackathon. Pernah suatu kali, saya bersama rekan di Paris van Java (Aqsath, Upan, Tito) mengikuti Hackathon yang diadakan Nokia dan DailySocial. Di acara tersebut, kita ditantang untuk membuat aplikasi yang menggunakan device Nokia, sekaligus mengakses API yang dimiliki Evernote dan Foursquare, partner di acara tersebut. Dalam 1×24 jam, kami membuat 3 aplikasi, aplikasi mobile untuk sisi customer, aplikasi mobile untuk sisi driver dan aplikasi backend untuk menghubungkan kedua aplikasi tadi.

Skenarionya sederhana, berbekal perangkat Nokia, seorang pengguna dapat melihat lokasi taksi disekitar mereka, melakukan pemesanan taksi sesuai dengan lokasi terdekat mereka. Pemesanan tadi akan disimpan ke server dan akan dilakukan bidding ke supir-supir taksi terdekat… melalui aplikasi driver, driver dapat memutuskan apakah akan mengambil order tersebut atau tidak. Setelah driver mengambil order, pengguna dapat melihat lokasi taksi ketika sedang dalam perjalanan menjemput. Setelah taksi datang, pelanggan masuk, diantar sampai tujuan, dan invoice akan dikirimkan ke email pengguna melalui evernote.

Pada saat pitching berlangsung, kita mengambil resiko untuk melakukan demo secara live. Aqsath dan Tito, menggunakan motor standby di area Hang Jebat, sementara saya dan Upan, presentasi di Binus Internasional Senayan. Aplikasi customer dihidupkan,,terlihat ada 1 taksi mangkal di sekitar kita – aka Aqsath dan Tito yang sedang nongkrong asik. Kami pesan taksi tersebut, taksi-nya langsung bergerak menuju lokasi kami berada. Kami dapat memantau posisi dari taksi tersebut. Setelah taksi tiba, terdapat notifikasi yang menandakan taksi sudah sampai. Ketika taksi sampai, Aqsath dan Tito-pun masuk ruangan..menyimulasikan kami naik taksi,dan di akhir perjalanan mereka menandai pekerjaan setelah selesai. Invoice pun sampai ke akun kami.

Apakah fiturnya terasa familiar bagi Anda ? Mungkin iya. Karena itu adalah skema yang membuat Uber, Gojek, dan Grab populer di masyarakat ibu kota saat ini. Pada tahun 2012, sekitar 4 tahun yang lalu, kami berhasil memenangkan Hackathon dengan ide tersebut, mendapatkan sejumlah uang dan sedikit kebanggaan. Keesokan harinya, saya dan Tito kembali ke Radya Labs, Aqsath ke NoLimit dan Upan ke Dissee. Kembali melanjutkan pekerjaan masing-masing. Artikel seperti ini muncul : https://dailysocial.id/post/mau-dibawa-kemana-taxify-aplikasi-juara-hackaton-sparxup-2012/ dan semuanya terasa menyenangkan. Bahkan kata-kata  salah seorang juri masih membekas hingga saat ini.

Some really good stuff from the sparxup hackathon. Taxify is my favorite. Expecting it to be a company on its own by next year.

Kemarin saya baru saja berpartisipasi di acara Incode.design, sebuah acara yang mengutamakan proses dan ajang kompetisi untuk mendorong kolaborasi masyarakat sipil, swasta, pemerintah, akademisi dan komunitas pengembang aplikasi (developers) untuk membangun solusi inovatif untuk menjawab tantangan utama pembangunan di Indonesia. Tulisan ini adalah bagian kedua, pelajaran yang saya dapatkan dari keikutsertaan di kegiatan ini. Untuk bagian pertama, silahkan baca Apa yang dibutuhkan oleh Museum DKI ?

Ada total 10 ide yang berhasil dijaring dari ratusan prototipe. 10 ide ini dipresentasikan. Dan akhirnya dipilih beberapa pemenang yang akan mendapatkan grant. Diharapkan dari grant tersebut ide dapat diimplementasikan dan menciptakan dampak yang diinginkan. Sebelum pemberian grant diberikan, ada sesi talkshow yang membicarakan mengenai terlalu seringnya kegiatan serupa hackhaton atau lomba aplikasi namun sedikit sekali yang akhirnya lahir menjadi suatu bisnis yang bertahan.

Sejak dua tahun lalu Radya Labs menambah satu orang Project Manager, dampaknya luar biasa. Saya memiliki tambahan waktu untuk mengeksplorasi. Sebagai Technology Director, saya ditugaskan partner saya untuk mengeksplorasi ide, menciptakan prototipe dan mencari apa yang bisa kita jadikan produk untuk perusahaan. Bisnis pengembangan aplikasi berbasiskan pesanan sudah berjalan sejak tahun 2011. Namun, kita punya cita-cita, pada satu titik, perusahaan software ini bisa menjadi besar dengan hasil karyanya sendiri, bukan hanya mengerjakan pesanan orang lain. Sejak saat itu pula, saya semakin rajin mengikuti kompetisi, hackathon atau apapunlah, demi menguji ide yang dimiliki apakah ada yang tertarik. Menguji ide diluar kantor membuka peluang kita untuk mendapatkan feedback. Sesuatu yang tidak Anda dapatkan dari menguji aplikasi di dalam kantor.

Tidak terkecuali di Incode.design tersebut. Kita ingin menguji kemungkinan pengembangan sistem aplikasi museum, yang kita harapkan jika berhasil, dapat kita jadikan produk kita, dan menjualnya ke pihak-pihak yang membutuhkan. Ide kita terbukti mentah. Belum ada yang tertarik. Feedback yang kita dapatkan kurang menggembirakan.

Dalam perjalanan pulang tersebut, saya sudah mulai mengubur fakta bahwa ide museum mungkin belum cukup OK. Apalagi mengenai cerita 4 tahun lalu  mengenai aplikasi yang sekarang sering disebut sebagai on-demand service, bukannya tidak OK, tapi sudah banyak sekali yang bermain di area itu. Di pool travel saya bertemu dengan salah satu pemenang Incode. Kami berkenalan, casual, mencoba saling mengenal satu sama lain.

Tanpa saya sangka, pemenang tersebut ternyata mengetahui Radya Labs dari suatu ajang lomba lainnya yang diadakan di akhir tahun 2015. Pada lomba tersebut, kita menguji prototipe yang sudah kita kembangkan selama 2 bulan sebelumnya, sebuah aplikasi rapor online untuk sekolah menengah negeri. Cita-cita luhurnya adalah orang tua dapat memperoleh hasil ujian langsung setelah ujian selesai, tanpa perlu menunggu waktu penerimaan rapor yang diadakan 6 bulan sekali. Yang lebih mengagetkan, dia bertutur bahwa dia menggunakan ide tersebut dan membuatnya ke suatu sistem jadi yang diimplementasikan di 3 sekolah swasta dan 1 sekolah negeri. Tidak lama lagi dia akan mulai mendapatkan revenue dari sistem tersebut. Sementara, prototipe yang sudah kami kerjakan, tidak kami lanjutkan sejak awal tahun 2016, karena kami fikir akan kesulitan untuk mendapatkan user yang ingin membayar sistem seperti itu. Kita berhenti mengeksekusi ide tersebut. Kita tidak melanjutkannya. Enam bulan yang lalu kami berhasil memenangkan satu kompetisi dengan suatu ide, namun ide tersebut tidak kami lanjutkan dan di tempat lain, ide itu diwujudkan dan berhasil menemukan pengguna yang membutuhkan.

 

Idea is cheap, execution is everything. Tidak peduli seberapa disruptive-nya ide yang kita pikir kita miliki. Tidak peduli seberapa sederhana tapi menyelesaikan masalahnya ide yang kita miliki. Tapi ide benar-benar tidak terlalu berharga. Eksekusi ide tersebutlah yang akan menentukan. Bukannya saya tidak memahami betapa murahnya ide. Begitu skeptisnya saya terhadap ide sehingga saya termasuk yang paling anti menandatangani sebuah NDA jika ada kelompok yang ingin minta dibuatkan software namun sebelum dia menceritakan ide-nya itu, kami harus dipaksa menandatangani perjanjian tersebut. Begitu anti-nya, hingga saya sempat menuturkan ke seorang rekan, jika ada temannya yang tertarik ingin bekerja sama dengan Radya Labs, tapi meminta kita menandatangani NDA hanya untuk mendengar ide tersebut, sebaiknya jangan diperkenalkan dahulu.

Tapi memang terkadang manusia bisa lengah juga. Begitupula saya. Tidak percaya atau tidak mau mengusahakan sebuah ide terlebih dahulu sebelum memutuskan untuk berhenti.

Dari pengalaman mengikuti Incode.design ini saya kembali mendapatkan tamparan keras. Saya tidak akan kapok mengikuti lomba. Saya belum menyerah dan masih senang-senang saja berpartisipasi dalam Hackathon. Tapi kini saya memiliki mantra yang semakin melekat. Bahwa ide yang kami miliki tidak berarti apa-apa hingga berhasil diwujudkan menjadi suatu kenyataan.

Perjalanan ini masih panjang.

What I’ve Learned from Incode.design : Apa Yang Sebenarnya Museum DKI Butuhkan ?

Lima tahun yang lalu, Google, memutuskan untuk mendirikan Google X, satu divisi yang memiliki misi Change the world. Break things. Not necessarily in that order. Dalam menjalankan misi tersebut, mereka memiliki 3 patokan dasar. (1) Temukan masalah yang besar yang berefek pada jutaan orang, (2) usulkan solusi yang radikal terhadap masalah tersebut, (3) kepercayaan bahwa teknologi untuk solusi itu bisa dihasilkan. Anda pasti sudah mendengar mengenai Project Loon, balon internet raksasa yang dapat memberikan akses internet ke jutaan orang di daerah tidak terjangkau, Self-driving car, mobil yang dapat berjalan sendiri atau Project Wing, sebuah drone yang dapat mengantarkan barang. Beberapa proyek dari Google X bahkan sudah ada yang lulus dari divisi tersebut dan dibentuk suatu unit bisnis terpisah yang akan mengeksplorasi komersialiasi dari teknologi yang dihasilkan, seperti Google Glass dan Google Brain. Beberapa project mungkin tidak sempat kita dengar muncul ke permukaan, seperti automated vertifal farming atau kapal kargo yang dapat melaju cepat tanpa menghasil emisi bahan bakar yang besar.

Salah satu teknik yang mereka gunakan adalah identifikasi masalah-membangun prototipe-menguji dilapangan-lakukan hal ini berkali-kali. Teknik ini juga merupakan intisari dari teknik Lean Startup yang banyak dijadikan kitab pelaku startup. Melalui cara tersebut,  tidak terhitung ribuan prototipe yang sudah dihasilkan. Berapa banyak prototipe yang mengalami kegagalan pada saat uji coba. Berapa banyak prototipe yang rusak.

Tapi diakhir hari, hal yang terpenting adalah melalui cara tersebut didapatkan pembelajaran. Data. Feedback. Masukan. Apapun itu yang mampu mengantarkan kita menuju tujuan kita walaupun hanya selangkah. Itu adalah cara Google X mengubah dunia. Dan itulah teori yang tampaknya mudah dilakukan. Kita semua sudah tahu. Feedback loop. Real feedback. Real users.

Namun seringkali kita lengah juga.

Google X’s boss, Sergey Brin, wants X to drive dramatic change, defined as a 10x improvement on current methods, through rigorous experiments involving atoms, not just bits (in other words, real stuff that can crack, fall apart and explode)

Kemarin saya baru saja berpartisipasi di acara Incode.design, sebuah acara yang mengutamakan proses dan ajang kompetisi untuk mendorong kolaborasi masyarakat sipil, swasta, pemerintah, akademisi dan komunitas pengembang aplikasi (developers) untuk membangun solusi inovatif untuk menjawab tantangan utama pembangunan di Indonesia. Tulisan ini adalah bagian pertama, pelajaran yang saya dapatkan dari keikutsertaan di kegiatan ini.

Saya tidak mengetahui kegiatan ini sampai bertemu dengan Yohan, yang secara kebetulan akan mengadakan roadshow acara Incode  di Bali. Pada saat yang sama, saya mengisi kegiataan workshop pula disana. Yohan menceritakan apa yang ingin dilakukan organisasi tempat dia bekerja, Asia Foundation, bukan lagi hanya hackathon yang sudah terlalu sering dilakukan. Kegiatan incode ingin memberikan dampak yang berbeda. Benar ada funding bagi proyek yang berhasil menarik perhatian donor, namun fokusnya bukan pada hadiah tersebut, tapi bagaimana hadiah tersebut benar-benar digunakan untuk membangun solusi yang diusulkan. Saya tertarik.

Sadar tidak ada tantangan yang sesuai dengan apa yang ingin saya kerjakan, saya menghubungi Paw, salah satu leader di Jakarta Smart City. Sebelumnya kita sudah ada pembicaran singkat mengenai kebutuhan aplikasi museum untuk wilayah DKI, atau lebih luas lagi, aplikasi untuk meningkatkan kunjungan wisata di DKI Jakarta, follow-up dari prototipe yang saya dihasilkan di acara HackJak 2015. Masih adanya kebutuhan JSC terhadap aplikasi museum tadi akhirnya mengantarkan museum sebagai salah satu tantangan yang dilempar tim JSC di kegiatan incode ini. Harapannya, kita ingin memaparkan kebutuhan ini ke para donor berharap ada donor yang tertarik dan kita mendapatkan pendanaan untuk memulai proyek ini.

Berbekal prototipe yang pernah saya kembangkan itu, kami mengikuti kegiatan incode.design. Pada acara workshop Design Sprint yang diadakan, para pengembang diharapkan dapat berkolaborasi dengan calon pengguna dari aplikasi yang ingin dihasilkan. Sayangnya, pada acara itu, tim kami, kekurangan 1 elemen yang mungkin adalah elemen paling penting : real user. Jadilah pada workshop tersebut, perwakilan developer (saya) dan perwakilan JSC (paw) merancang prototipe lanjutan berdasarkan asumsi dan riset kecil-kecilan kita via internet.

Masalah Yang dihadapi Museum di DKI Jakarta

Masalah yang kita angkat adalah masih rendahnya tingkat kunjungan wisatawan ke museum di wilayah DKI. Ada 9 museum dibawah pengeloloaan DKI. Total kunjungan museum ini hanya sekitar 1 juta selama tahun 2015, bandingkan dengan Ancol yang mencapai 17 juta pada tahun yang sama. Padahal, menurut teori urban tourism, museum dan marketing yang saya baca, museum di kota-kota besar sudah menjadi faktor penentu apakah seorang wisatawan akan memperpanjang waktu stay mereka di suatu kota. Begitu pentingnya pengaruh museum, sehingga dapat membawa dampak ekonomi bagi kota. Makin lama waktu stay wisatawan, berarti makin banyak spending yang dapat kita harapkan dari wisatawan tersebut.

Sebagai salah satu penikmat museum jika sedang berpergian, saya dan Paw mengambil perspektif pengunjung. Apa sih yang diharapkan dari pengunjung ketika berada di museum. Experience. Kekurangan dari Museum DKI menurut kita adalah ketidakmampuan museum membungkus koleksi yang mereka miliki dan menciptakan “pengalaman berkunjung” yang membekas bagi wisatawan. Tidak usah jauh-jauh ke Madame Tussaud, Museum Angkut di Malang memberikan experience yang menurut saya lebih menarik, menggabungkan koleksi, tata letak dan storyline sehingga benar-benar menawarkan pengalaman sekaligus pengetahuan kepada para pengunjung.

Dari situ kami merancang fitur-fitur aplikasi yang ingin dikembangkan, fokus untuk memanjakan pengunjung. Mulai dari kelengkapan informasi mengenai museum, pembelian tiket online hingga audio tour untuk menghadapi kurangnya guide pada museum-museum di DKI. Tentu saja untuk mendukung informasi tadi, perlu pula dikembangkan aplikasi Backoffice, yang akan digunakan oleh pengelola museum. Lebih lanjut lagi, saya melemparkan ide untuk membuat satu komponen lagi, aplikasi Ticket Scanner, yang akan digunakan penjaga pintu untuk memindai tiket dipintu masuk, sehingga jumlah kunjungan dapat dipantau secara real-time. Total ada 3 komponen, aplikasi mobile untuk customer, aplikasi backoffice dan scanner untuk pengelola museum. Kita cukup percaya diri dengan diskusi produktif yang dihasilkan di sesi Design Sprint tersebut. Selanjutnya prototipe dihasilkan dan Alhamdulillah, berhasil masuk Top Ten dari kegiatan itu.

Masalah Sebenarnya Yang dihadapi Museum di DKI Jakarta

Pada hari puncak Incode, seluruh Top Ten akan diminta presentasi di depan para donor dan hadirin yang lain. Untungya, pada Acara tersebut Paw berhasil mendatangkan Bu Sri, Direktur untuk Museum Sejarah Jakarta. Ada 4 Museum dibawah pengawasan Bu Sri, salah satunya adalah Museum Fatahillah. Sebelum sesi presentasi tim kami, saya menyempatkan diskusi singkat dengan Bu Sri. And I wish I met her sooner.

Dari obrolan singkat tak lebih dari 30 menit, saya mulai menangkap apa masalah sebenarnya yang dihadapi oleh Museum DKI Jakarta. Saya ceritakan secara singkat prototipe yang saya kembangkan, konsep dan pengaplikasiannya. Bu Sri mengapresiasi. Namun beliau menceritakan pain problem yang ia hadapi selama ini. Tidak adanya suatu cara yang mudah untuk mencatat dan mengelola koleksi yang mereka miliki sehingga memudahkan mereka dalam melakukan perawatan, perancangan tata letak dan kegiatan promosi. Selama ini kegiatan tersebut dilakukan menggunakan file excel, terhadap ribuan koleksi yang mereka miliki. Dapat saya bayangkan sulitnya pekerjaan yang mereka lakukan selama ini. Beliau menjelaskan kembali,  fungsi utama Museum di Indonesia adalah pelestarian cagar budaya. Bahwasanya ada fungsi ekonomi tidak dapat dipungkiri, namun hal itu tidak menjadi suatu tugas yang utama.

Dari solusi yang saya tawarkan, ternyata pada tahap ini, menurut beliau, aplikasi Backoffice-lah yang benar-benar dibutuhkan. Museum belum memikirkan aplikasi mobile interaktif yang memudahkan pengunjung menikmati koleksi yang tersedia. Saat ini, kebutuhan mereka adalah mendata dan mencatat seluruh benda koleksi yang mereka miliki, yang mana asetnya bisa saja mencapai milyaran rupiah. Aset berharga yang harus dilindungu. Kekayaan negara. Yang dapat menunjukkan jati diri suatu bangsa. Yang saat ini mereka butuhkan adalah  suatu cara yang lebih mudah dalam pengelolaan, pencatatan pemugaran, lokasi dan hal-hal detail terkait koleksi museum tersebut.

Audio tour ? Nice to have. Booking tiket ? Not now. Yang mereka butuhkan adalah aplikasi Backoffice yang fokus kepada pengelolaan aset.

Belajar Dari Berbagai Sudut Pandang

Tigapuluh menit di acara puncak Incode.design meskipun singkat kembali mengajarkan hal penting bagi saya. Bukannya tidak faham akan hal ini. Saya sudah coba mempelajari  betapa pentingnya melihat sesuatu dari berbagai sudut pandang, pain problem dan mencari akar masalah sebelum menghasilkan solusi. Itu sudah diajarkan sejak zaman kuliah, melalui buku-buku yang saya baca dan entah berapa banyak diskusi pada event startup yang saya datangi. What is the main problem ? Mulailah dari masalahnya terlebih dahulu.

Akan tetapi masih saja saya seringkali lengah, karena merasa bisa menciptakan sesuatu, namun bukan hal yang sebenarnya sedang dibutuhkan. Pengalaman ini kembali menjadi pelajaran yang sangat berharga. Pentingnya berbicara dengan real user. Pentingnya membawa prototipe kita segara ke dunia luar untuk secepat mungkin mendapatkan masukan. Pentingnya menemukan akar masalah sebelum jauh bergerak mencari solusi. Pentingnya untuk melihat dari berbagai sudut pandang, tidak hanya kita yang mampu mengembangkan aplikasi, tetapi sudut pandang siapa yang memerlukan dan siapa yang akan menggunakan.

Meskipun di acara kali ini, Moresa belum berhasil mendapatkan perhatian yang kami harapkan, namun pelajaran berharga sudah saya terima. Saya, Paw dan Bu Sri berjanji untuk terus berdiskusi mengenai kemungkinan-kemungkinan yang ada untuk proyek ini. Karena sesungguhnya koleksi museum merupakan salah satu aset bangsa yang berhaga. Kalau tidak kita yang menjaganya, siapa lagi ?