Proses Pengembangan Aplikasi Android

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

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

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

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

Picture1

Gambar 1. Proses Manajemen Proyek Pengembangan Aplikasi Android.

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

  1. Dimulai dari mendefinisikan ide dan persyaratan aplikasi

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

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

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

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

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

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

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

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

  1. Pengembangan dan pengujian aplikasi

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

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

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

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

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

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

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

build-process_2x

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

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

  1. Penerbitan aplikasi ke PlayStore

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

Picture2

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

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

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

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

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

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

Semoga materi singkat ini dapat bermanfaat 🙂

Advertisements

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)

Menentukan harga jasa untuk programmer dan desainer

Setelah pernah dibahas mengenai menentukan harga project TI khususnya mobile apps. yang ingin kita bahas adalah bagaimana menentukan harga jasa untuk programmer atau desainer mobile apps (mungkin bisa dipakai untuk developer software secara global)

Begini, akhir-akhir ini saya sering ditanya mahasiswa : “mas, bagaimana cara menentukan harga desain saya? saya ragu mau pasang harga”

Kalau menghendaki harga yang pantas dan ideal, itu subjektif, silahkan tentukan berdasarkan usaha yang akan dikeluarkan dan alokasi waktunya. Dan pasang harganya. Yang penting berani dan sudah mengukur sendiri harga yang pantas. Jangan sampai, kamu pasang harga 3 juta rupiah, namun, ternyata uang yang dikeluarkan untuk usaha begadang, internet dan ngemil serta ngopi sambil bekerja itu ngepas 3jt, atau mepet 3juta, alhasil tekor dan gak ada untungnya.

Namun, beberapa programmer/desainer software junior, masih bingung, harga jasa saya berapa?

Mari kita perhatikan 5 hal yang mempengaruhi harga jasa kamu di dunia software engineering sebagai berikut :

  1. Scope pekerjaan.
    Scope adalah segala hal yang ada di dalam produk software/produk dari project TI dan segala proses di dalamnya.
    Mendefinisikan apa yang diminta, apa yang mesti dikerjakan, dibagi step-stepnya (rencana->rancangan) sampe menjadi rangkaian berurut apa saja yang dikerjakan. Dengan demikian, dapat diestimasi jadwal dan waktu pengerjaannya.
    Contoh, ketika saya dari tidur pengen berangkat ke sekolah :

    1. Saya bangun tidur (15 menit), kemudian
    2. saya mandi (15 menit), kemudian
    3. saya sarapan (30 menit), kemudian
    4. saya berangkat ke sekolah (20 menit).
  2. Proses pengerjaan,
    Sulit kah? mudah kah? simple kah? kompleks kah?
    Terus bagaimana proses yang mesti saya ikuti? banyak kah? tentu mesti memperhatikan, jika ternyata proses untuk mengerjakan codingannya ataupun desainnya, bisa memakan waktu berjam-jam.
    Mulai dari :

    1. memahami klien kemudian menganalisis kehendak si klien;
    2. brainstorming, berguna untuk mendefinisikan semua kebutuhan biar bisa dikerjakan menjadi karya kita;
    3. inisialisasi, mulai dari kamu corat-coret desain/coba-coba code init/awal sampe jadi prototyping;
    4. prototyping, membuat karyamu sampe dengan prototype;
    5. development/design, mulai deh ngembangin sampe memroses semua kebutuhan menjadi produk
    6. revisi, mesti ketemu bagian ini, kadang ada saja bagian yang tidak sesuai kehendak klien, nah ini mesti diperhitungkan;
    7. final version, ketika sudah direvisi, dipoles, dibungkus, terus diserahin deh ke klien.

    panjang kan prosesnya? 😀 Makanya perlu diperhatiin betul, jangan sampe harga yang kamu pasang gak sesuai.
    Nah, ada beberapa hal itu bisa dikerjakan bebarengan, serentak (jika kamu ngerjainnya berdua atau lebih sama teman), tentu ada beberapa proses bisa dihemat waktunya. Coba lihat ilustrasi berikut :

    Critical Chain Project Schedule
    Critical Chain Project Schedule

    Kalo dilihat dari gambar di atas, tentu kita bisa memperkirakan, task apa saja yang bisa dikerjakan dalam 1 waktu bersamaan, dan mana yang tidak bisa. Jika tidak bisa, terus taruh di mana prosesnya..apa dikerjakan duluan, apa dikerjakan belakangan? tentu kalau ingin mengerjakan sesuatu, kerjakan dari yang paling mendasar.

  3. Standar harga per jam kerja (hourly rate)
    Kalo bagian ini, gak bisa sembarangan ditentuin. Kamu mesti sadari gaji/rate bayaran kamu berapa yang pernah kamu terima? terus itu dikerjakan berapa lama?
    Misal :
    Kamu pernah kerja 2 minggu (10 hari kerja, minus sabtu-minggu) dibayar Rp 3.000.000
    Sehari kerja dari jam 09:00 – 12:00, dilanjut ishoma, terus jam 13:00 – 16:00, berarti kalo ditotal : 6 jam kerja.
    Dan jika kita konversi menjadi perjam, rumusnya: Harga / total jam kerja / total hari
    Rp. 3.000.000 / 6 / 10 = Rp 50.000
    Berarti kamu dibayar Rp50.000,- per jam. Rate ini selalu naik seiring pengalaman, tentunya bila dinamika perubahannya naik, dalam artian, kamu sudah mengalami pengalaman yang banyak, yang dulunya sulit, jadi gampang, skill bertambah, dan beberapa project kamu jadi terbiasa garap (pengalaman). Semakin tinggi pengalaman, rate tentu semakin tinggi juga.
    Apalagi dibarengi skill yang makin tinggi pula (semakin banyak pengalaman, mestinya semakin beragam pula soft skill yang dikuasai). Bila kamu sudah 10 kali project dalam 2 tahun dengan hourly rate Rp 50.000,-… pas tahun ke-3, ya naikin lagi hourly rate jadi Rp 75.000,- atau Rp 100.000,-.Apalagi dalam 2 tahun itu kamu sudah belajar banyak, ditambah sekolah lagi, bisa berkali-kali lipat.Dan lagi-lagi, perhatiin juga standar gaji di dunia saat ini. (coba googling : salary guide [tahun], contoh : salary guide 2014, saya gak akan jelasin ini, cari di google dan baca sendiri sesuai posisi kamu di pekerjaan, bila orang kerja dibayar per bulan (20 hari kerja) sekian rupiah, tentu bisa dihitung per jamnya). Tentunya jika kamu di tahun kedua pernah mendapatkan proyek membuat sistem informasi perkantoran dengan harga Rp 60.000.000,-, kemudian di tahun ke empat jangan pasang 60jt lagi, tapi dinaikin. Berapa besar kenaikannya? kalau masih kesulitan menentukan, kembali ke pembahasan kita di atas yang baru kita bahas dan perhatikan di salary guide untuk profesi kita di tahun ke-4 besar gaji/rate-nya berapa.

    Berikut ini contoh hourly rate di beberapa negara

    Screen Shot 2017-03-31 at 2.21.26 PM

    Mahal ya? iya, di sana dihargai lebih. Kalo rate di atas diterapkan di indonesia, tentu gak pas 😀 makanya tadi saya sampaikan cek salary guide untuk Indonesia. Contohnya di sini: Salary Guide 2016. Cek profesimu sebagai developer apa. terus cek berapa tahun pengalaman kerjanya. Jika sudah dapat, ya tinggal konversi ke per jam.

  4. Investasi
    Seluruh hal yang berhubungan dengan proses yang dikerjakan di atas, dan biaya yang keluar karena hal tersebut. Seperti yang saya jelaskan di atas.

    1. Saya bangun tidur (15 menit) -> gratis
    2. saya mandi (15 menit) -> sabun : Rp 2000, sampoo Rp 1000, pasta gigi+sikat giginya : Rp 8000
    3. saya sarapan (30 menit) -> sarapan ketoprak : Rp 6000, jalan kaki ke TKP
    4. saya berangkat ke sekolah (20 menit) -> berangkat naik motor, bensin Rp 6500

    Terus, kalo ditotalin : makan waktu 1 jam 20 menit (1,33 jam), dan biaya : Rp 82.000 (2000+1000+….+6500)

    Rumusnya : hourly rate x total proses kerja
    Jadi, ketika hourly rate kamu Rp 50000, berarti :

    Rp 50000 x 1,33 jam + Rp 82.000 = Rp 148666,66 (mari kita bulatkan ke atas :p Rp 149000)

    Ya nilai dari project ini : Rp 149.000,-

    Contoh di atas mungkin sedikit membingungkan, pada intinya saja ya. Jadi kalau kamu dapat proyek dalam waktu 1 bulan, ya dikonversi saja dalam satuan hari. 1 bulan = 20 hari kerja, 1 hari = 8 jam kerja. 20*8=160 jam.

    Misal hourly rate kamu adalah Rp 250.000,- dengan pengalaman sudah 3 tahun. Ya untuk proyek dengan waktu 1 bulan…tinggal dikalikan saja: Rp 250.000*160 jam= Rp 40.000.000

    Nilai 40 juta ini bukanlah nilai mutlak, jadi ada nilai resiko juga di dalam proyek, nah ini kita bahas di poin nomor 5 di bawah.

  5. Resiko
    Segala hal tentu ada resiko, nah jangan sampe resiko ini terjadi dan menimpa kamu. Resiko mungkin bisa dihindari, tapi jika terjadi, pikirkan dampaknya dan apa antisipasinya.
    Resiko besar yang biasanya terjadi itu : project diberhentikan di tengah jalan (bahaya dong, ntar ketabrak), requirements berubah (nah ini dia yang biasanya bikin jengkel, udah bikin capek-capek, gak dipake, mesti diganti)
    Resiko kecil : perubahan minor aplikasi/software, jadi menyita waktu juga walaupun perubahannya dikit-dikit.
    Resiko juga mesti diklasifikasikan berdasarkan :

    1. kesempatan terjadi
    2. potensi yang diakibatkan (parah apa nggak?)
    3. kesulitan mendeteksi resiko supaya bisa dihindari

    Contoh : bugs di aplikasi
    Kesempatan terjadi : menengah lah, gak sedikit juga, gak banyak juga kesempatannya.
    Potensi yang diakibatkan : tinggi, kadang 1 bugs, bisa bikin aplikasi gagal jalan sebagaimana mestinya
    Kesulitan mendeteksi : tinggi, kadang bugs itu sulit banget dicari >.<

    contoh lain : server kebanjiran
    Kesempatan terjadi : kecil, ini sih kesempatan langka banget sampe-sampe server kebanjiran, kecuali kamu taruh servernya di pinggir kali ciliwung.
    Potensi yang diakibatkan : tinggi, server tenggelam, nangislah kliennya. Kamu juga mesti ikutan nangis!
    Kesulitan mendeteksi : kecil, lah wong hujan deres, knapa gak disingkirin tuh server ke tempat yang tinggi.

    Nah, resiko-resiko seperti ini yang mesti diperhitungkan. Terutama ya bayaran kamu. Misal kalo kejadian macem-macem, bayaran kamu telat, bagaimana?. Atau kamunya yang telat ngumpul kerjaan bagaimana?

    Dari sisi developer, pas di kontrak kerja, jangan lupa cantumkan aturan-aturan untuk klien (biasanya klien bikin aturan-aturan juga di poin proposal proyek (misal: apabila kamu telat mengumpulkan progress, atau progress tidak sesuai apa yang diharapkan klien, biasanya klien punya hak mengurangi harga proyek), nah, di sini kamu juga perlu membuat aturan-aturan atau klausa yang memperjelas batasan kamu selaku developer, misal: masalah konfigurasi server ataupun backend bukan tanggungjawab kamu yang seorang developer mobile app, masalah akun PlayStore tanggungjawab klien dan harus menggunakan data dari klien, atau apabila ada permintaan tambahan di luar scope pekerjaan yang telah disepakati, maka klien harus di-charge bayaran baru. Itu harus ada klause kerjasama tambahan yang menyatakan poin-poin apa saja tambahannya dan berapa besar biayanya. Nah yang model ini, developer sering luput, lalai, klien menghendaki revisi ini itu, tambahan ini-itu, tapi nilai proyeksi investasinya tetap. Jatuhnya kita yang rugi. 🙂
    Berikut ini ada gambar ilustrasi bagaimana harga sebuah proyek apabila dideliver ke klien lebih awal, tepat waktu atau terlambat. Dan berapa harga yang diharapkan. Dari sini bisa kamu kenali kalau untuk deliver sebuah progress pekerjaan ada resiko pinalty dari klien. Dan itu seharusnya kamu sudah antisipasi.

    Decision Trees
    Decision Trees

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

Terima kasih.

Pernyataan Jokowi soal “panggil programmer 2 minggu selesai” buat kalangan programmer melek dengan e-gov negeri sendiri

well, banyak sekali sisi positif gara-gara statement Jokowi “e-gov, panggil programmer 2 minggu selesai” di debat capres tempo hari. Di kaskus, facebook, twitter, berkumpul dan berdiskusi soal e-gov. Nama “programmer” pun jadi makin dikenal.

Namun, ada banyak gap yg terjadi di kalangan profesional TI, apalagi di kalangan fanatisme kedua kubu capres, akibat dari pernyataan Jokowi tersebut.

Sebagian kalangan mengkritik itu hanya bualan atau kalimat berlebihan dr seorang capres, krn sejatinya membangun sebuah aplikasi tidak hanya terkait programmer dan codingannya, tetapi ada metodologi dan tahapan pengembangan softwarenya, ditambah regulasi dan birokrasi dengan pihak pemerintah.

Namun sebagian kalangan menganggap ini tantangan besar buat indonesia, mereka menyadari bahwa e-gov tidak dikembangkan dalam satu malam, tp bertahun-tahun. Semua sudah jelas, apalagi untuk kalangan IT.

Korea saja misalnya, dr kuliah online pakar e-gov dengan judul “Ten Lessons from Korean Experiences of e-Government”, Professor Sang W. KIM, Ph.D. bilang kalau Pemerintah Korea telah melaksanakan secara berdampingan berbagai master plan, program dan proyek untuk menerapkan “masyarakat berorientasi informasi” secara nasional selama 20 tahun terakhir. Banyak project, dimulai dari 1987 (NBCN) sampai dengan e-gov nya mereka (2001-sekarang)

Di Indonesia sendiri, bbrp informasi yg sy dpt dr berbagai surat kabar online, menyebutkan sudah ada e-gov yang berhasil di beberapa daerah, di Jawa Timur (http://www.surabayapagi.com/index.php?read~Jawa-Timur-Terbaik-Kedua-di-Pemeringkatan-e-Gov-Indonesia). Berhasil di sini maksudnya sudah diuji secara teknis (aplikasi dan jaringan) dan tanggapan masyarakat.

Dan polemik di sini adalah e-gov yang sudah sukses tersebut tidak disosialisasikan oleh pemerintah pusat agar diterapkan di berbagai pemerintah daerah. Pemerintah tidak menjalankannya secara utuh. Alhasil, saat ini yang terjadi adalah tidak ada transparansi di kalangan pemerintah ke masyarakat. (mungkin ini yg dikhawatirkan bbrp elit politik, biar tidak ketahuan belangnya..makanya e-gov tdk dijalankan)

Kalo pak Jokowi memang pernah terlibat dlm pengembangan e-gov dan bilang “panggil programmer, 2 minggu selesai”, maka mungkin sebaiknya perlu diklarifikasi “selesai” di sini utk tahap apanya?  Karena beliau menyebut “programmer” bukan “vendor TI” maka mungkin bisa diasumsikan ini maksudnya “development-nya” (LOL) Drpd para simpatisan debat kusir dan para programmer berasumsi yg rumit-rumit.

Dan kembali lg ke topik yang disampaikan prof. Sang W. KIM, Ph.D, kalau Sistem Informasi tidak dibuat sekaligus, tapi bertahap. Dan suksesnya sebuah sistem informasi itu tidak ditentukan oleh ouput dari Sistem Informasi tersebut, tetapi hasilnya dapat dirasakan dan bermanfaat oleh pengguna. Manajemen data untuk mengelola atribut dalam e-gov harus lebih baik (Membangun Data Warehouse dari OLTP ke OLAP). Dan ini juga dipengaruhi bbrp domain sosial seperti Kepemimpinan (leadership), Strategi (strategi), Hukum & Peraturan (law & regulation) di pemerintah tersebut.

Menjadi suami seorang pekerja TI

Masa di mana suami jd spontan merenung itu ketika suami melihat istrinya sedang tidur.. Ada rasa bersyukur ada rasa bersalah…menyadari bahwa suami itu cenderung lebih egois. 

Ntah alasannya mencari nafkah, ia sudah merasa paling capek sendiri..selesai bekerja dgn penuh keringat, kadang mukanya kusut, ia pulang sudah dilayani istri spt tuan rumah. Namun istri tetap setia menanti dengan senang hati, menyambut suami dengan manja walau suami kusut, dan siap menjadi tempat berlabuh lelahnya suami.

Ntah alasan suami krn ia seorang developer, designer ataupun analis yg minta dimengerti kalau kerjaannya butuh konsentrasi tinggi berjam-jam kerja memperhatikan layar komputer bahkan seorang programmer yg asyik ngoding sampai “gak sengaja” overtime (lembur). Membuat suami jd lalai dengan kewajibannya.

Sudahkah jadi suami yg terbaik utk istri?
Nasehat yg datang dari orang tua dan dari dosen ketika di plurk yg slalu sy tanamkan dr sejak menikah ketika sy menulis status kesibukan saya di jejaring : “ingat, ada yang harus diperhatiin, sekarang bukan hidup sendiri lagi. Sesibuk apapun, keluarga nomor satu”

Suami ya jangan gila kerja, rezeki sudah diatur, waktu kerja yg normal jg sudah diatur Undang-undang.
Lakuinlah hal-hal ringan yg bisa membuat nyaman istri.
Ntah pulang langsung segera mandi, peluk cium istri dlm keadaan wangi. Menyuapi istri dikala makan bersama, berangkat ke masjid dengan boncengan sambil ngobrol ngalor-ngidul, nemenin istri belanja di pasar, dll. Bahkan kalau istri lg hamil yg tidak bisa aktifitas rumah tangga yang berat, suami siap mengemban pekerjaan rumah tangga sambil dengan cermat mensupport, memperhatikan pola makan dan istirahat istri.
Dan bukan hanya itu saja, keharmonisan memang slalu harus dijaga. Canda-tawa, tingkah lucu suami yg bisa membuat istri tersenyum tertawa..pulang kerja bukan membawa masalah kantor tapi membawa hal-hal lucu, romantisme…dan obrolan-obrolan ringan seputar kegiatan td pagi, obrolan soal tetangga, soal keadaan orang tua, dll. yg dapat membinasakan rasa kaku membisu yg bisa membuat problematika renggangnya hubungan rumah tangga.

Ada satu curhatan yg pernah terdengar…biasanya suami yg kerja di bidang TI, jam kerjanya tinggi per hari, istri bersyukur orang macem gini biasanya gk akan mungkin sempat selingkuh apalagi lirik cewek lain..(sempetnya selingkuh sm komputer), biasanya sih romantisnya garing hahaha…( tapi ya suami jangan egois) 

Kecocokan bisa dibentuk dan tersusun rapi dengan slalu terbuka berbagi cerita antara suami istri 

PS : kata2 ini sy dpt wkt denger ceramah di radio rodja, pengalaman pribadi, perkataan ortu dan dosen yg balas plurk saya.

6 pelajaran hidup yang dapat kita pelajari dari seni pemrograman

  1. Flow Chart sederhana adalah segalanya
    Sama halnya seperti seorang programmer, ketika kita dihadapi masalah besar, sebisa mungkin dipecahkan menjadi bagian-bagian terkecil, Baru dengan mudah kita dapat mengambil keputusan atas masalah tersebut.
  2. Setiap hal ada tempatnya.
    Selalu, ktika kita men-develop aplikasi, tentu di tahap awal kita menempatkan variable2 yang ingin kita pakai beserta tipe datanya (inisialisasi), begitu jg hal lain, slalu ada tempatnya, semua ada aturannya.
    Sama seperti kehidupan nyata, di mana letak tempat menaruh peralatan kerja, menaruh makanan, menaruh permasalahan kantor ya di kantor, bukan di rumah, dan sebagainya.
  3. Re-use/menggunakan kembali module yang sudah ada untuk menghemat waktu
    Setiap programmer yg baik akhirnya belajar bahwa ketika sudah membuat sebuah function ataupun module, dapat digunakan kembali untuk pengembangan aplikasi yang lain/berikutnya. Jadi menghemat waktu tentunya
    Henry Ford pernah berkata tentang Model T, “Setiap pelanggan dapat memiliki mobil dicat warna apa saja yang dia inginkan, asalkan itu hitam.”
    Alasan ini yang dipake Ford untuk merakit mobil dan membuat produk-produknya keluar pintu lebih cepat jika ia bisa menggunakan kembali peralatan yang sama (cat warna yg sama) tanpa harus menciptakan proses setiap kali mobil baru dibuat.
  4. Dokumen(tasi) adalah segalanya
    Kalo programmer yang “khilaf” 😐 dokumentasi itu malah diabaikan, atau malah dikerjakan pas aplikasi selesai 😐 sama aja boong :)) keasikan ngoding sih jadinya males, malah terkadang dianggap repot 😐 “gak ah, mending ngoding aja, ntar jg gampang diinget-inget, gak taunya mesti tracing code lagi”
    Sebenernya dokumentasi itu penting, dengan adanya dokumentasi, kita mencatat setiap hal yg kita perbuat dengan aplikasi itu, apa kesalahan dan perbaikannya, apa fungsi-fungsinya, dan tau tata letaknya, jadi mempermudah developer lain (berikutnya) untuk mengembangkan, dan bahkan bagi user.
    Sama seperti sehari-hari, terkadang jadwal penting, rutinitas sehari-hari, dan apa saja yang mesti dilakukan perlu dicatat di dalam sebuah catatan/agenda, memudahkan anda mengingat dan tidak tertinggal satu halpun.
  5. Jangan terjebak di satu situasi yang buruk.
    Ketika aplikasi mengalami looping gk berujung, process CPU jadi tinggi, dan tentunya si programmer harus mencari alternatif cara agar aplikasi berjalan lancar. Begitu jg dengan kehidupan nyata, ketika sudah merencanakan sesuatu, tau2 datang hal yg tidak diprediksi, satu2nya cara adalah menyiapkan “skenario terburuk” dari rencana itu, jadi tidak stuck di situ saja.
  6. Free Up Memory ketika kamu selesai.
    Kalo buat aplikasi, misal aplikasi Android, terapin masalah service, yang jelas setiap execute dalam durasi beberapa waktu, butuh free-up memory, agar app.tersebut tetap efisien ketika berjalan. Jika tidak, bakal makan banyak memory.
    Di kehidupan sehari-hari, sama juga, abis kerja, abis makan, cepetan diberesin dan dibersiin ruangannya, jangan sampe numpuk sampah, peralatan kerja berserakan, dsb. Malah buat aktifitas berikutnya jadi lambat.

Seputar Manajemen Proyek (bag.1)

Q : Jika misal klien kita sebuah perusahaan, nah masalah tarifnya gimana? Tarifnya menyesuaikan besarnya company gak? Misal perusahaannya itu perusahaan baru dan yang lagi berkembang skala nasional, kan income mereka juga beda gitu. Gimana mas?

A : masalah tarif proyek TI itu ada beberapa pertimbangan :

  • Ketersediaan infrastruktur untuk lingkungan implementasi.
  • banyaknya personil yang terlibat dalam pengembangan sistemnya + beban job descnya (manajerial & staff teknis & staf pendukung).
  • milestone pekerjaan systemnya (apa saja yang dikerjakan dan berapa lama waktunya (timelineny).. nah ini ada penjelasannya lagi).
  • Teknologi yang dipakai.

Dan itupun tidak menyesuaikan besarnya perusahaan kok.

Q : oh, brarti menentukan harga memang tahapnya banyak juga ya…hehe…oh, trus klo kliennya personal/individu gimana, mas? Kan tarifnya mesti beda sama klien company ya?

A : Banyak.. dan semuanya tertulis. Jadi pihak vendor dan pihak client jelas. Tetapi terkadang juga sulit diterapkan hal tersebut, apalagi dari clientnya yg “kotor”, itu yg gawat, biasanya mereka memang mengadakan apa gitu (tender), buat menghabiskan anggaran belanja saja, tanpa keperluan dan tujuan yang jelas, akhirnya useless. Hehehe..tetapi tidak semua begitu. Hanya sedikit. Dan kalau bisa ya mending dihindari. 😀
Kalau clientnya personil, liat skala pengerjaannya juga, apakah besar atau kecil? Jika kecil, tidak serumit seperti yang dijelaskan di atas.

Biasanya meliputi hal berikut :

  1. biaya hosting, domain, dll (adakah?)
  2. Milestone pekerjaan perangkat lunaknya
  3. Teknologi yang dipakai, biasanya semakin baru maka semakin bagus
  4. Tidak dikenai pajak, karena ratenya rendah 😀

Walau personil/pribadi atau proyek bersama, keduanya mesti ada kontrak tertulis, dan jangan lupa, kasih aturan, terutama menghindari client yang hobi telat bayar, kalo telat = denda. Haha 😀

modelnya ada 3 loh :

  1. Tender (jadi si client sudah punya harga, sudah menentukan jumlah personil yang harus disediakan)
  2. Dari permintaan (permintaan client ke kita, via pribadi atau via vendor)
  3. Dari penawaran (kita yang menawarkan diri ke client)

nah, untuk no.1 ada tata urutannya. Biasanya sebagai berikut :

  1. Opening project (meeting internal) dgn client, rapat, dengerin user stories – ini siapin analyst dan team dokumentasi (buat nyatet+dokumentasiin) dan PM.
  2. Breakdown keperluan app yg mau dibuat.
  3. Dokumentasi dibuat secara rapi sesuai format, terus diperiksa oleh client apakah sudah benar dan sesuai belum.
  4. Kalo no.3 sudah, tinggal system architecture (db+server), system analyst yg kerja.
  5. Kerjaan si no.4 dikasih ke pimpinan developer (lead programmer atau supervisor) dan dijelaskan jg ke designer UInya.
  6. Rapat lagi ke programmer, jelasin job descnya, negosiasi harga, blablabla..ini agak panjang jg.
  7. Masuk masa implementasi.
  8. PM control pekerjaan beserta analyst bantu ngarahin biar kerjaan programmer terarah.
  9. Closing project, dokumentasi akhir, dll.

Q : Oya satu lagi, cuma pengen tau pembagian gaji tiap orang. Misal : utk proyek diatas PM dapet berapa trus analyst berapa, programmer, dst…itu juga masih kurang tau aku 🙂

A : Lebih detailnya malah bisa berlembar-lembar hahaha. Intinya masih sama dengan yang diajarkan di RPL, walau sebenernya ada beberapa yg “basi” sudah ditinggalkan, kayak model “waterfall” dan masalah user testing.

  • PM tanggung jawab 100% kegiatan
  • Analysis itu component pekerjaannya 20% dari seluruh kegiatan,
  • Dokumentasi+testing itu 20% juga dari seluruh kegiatan
  • Programmingnya 60% dari seluruh kegiatan (makanya kerjaan programmer itu banyak daripada analyst LOL)

Tapi kenapa dari setiap personil, bobot pekerjaan sedikit, namun gajinya lebih besar? Ya, sebagai contoh Analyst terhadap Programmer, terlihat karena tanggungjawab, tingkat pemahaman serta tingkat stressnya lebih tinggi daripada programmer 😀

Nah, masalah hitung menghitung masing-masing personil+job desc-nya. Tergantung kesepakatan dan kebijakan si PM (project manager) dan si pemilik vendor dan bagian keuangannya. Ada beberapa perusahaan, yang mewajibkan setiap investasi harga proyek dari client itu 25%-nya masuk ke kas perusahaan. Jadi misal, kalo 25% dari harga proyek itu sudah PASTI masuk kas perusahaan, maka yg didapet personil adalah 75% dari harga proyek. Kenapa? demi kemajuan perusahaanlah 😀 dan juga penggajian karyawannya. Nah, harga personilnya di-breakdown lagi.

Ini personilnya ada yang outsourcing atau dari pegawai sendiri? 😀 Sayangnya kalo pegawai sendiri itu hitungannya gaji.. jadi agak sedikit rugi, namun untungnya pas tutup buku akhir tahun biasanya.

Sedangkan outsourcing, itu dibagi lagi, apanya? dia posisinya apa? analyst, bisa dapet sekitar 15%-20% dari harga proyek, kalo programmer (total loh..jadi kalo ada 6 ya dibagi 6 aja) itu sekitar 30%-40%. Tapi masing-masing punya kebijakan berbeda-beda.

Q : Ada tips-tipsnya gak mas mengenai proyek agar aplikasi yang kita kembangkan mendekati keinginan user?

A :

tipsnya :
punya “koneksi” + “komunikasi” yang bagus, mas 🙂 Dan dengan koneksi dan komunikasi yang bagus, tentunya kita dapat memahami bagian “user stories” dengan baik, mulai dari bagian manajerial sampai ke teknisnya. Semua itu kita bagi menjadi bagian kerangka acuan kerja, timeline, wireframe kemudian milestone dan kemudian kita bagi lagi menjadi lebih spesifik menjadi tasks yang akan dikerjakan oleh programmer.

Untuk masalah koneksi, sedia link di mana-mana, bahkan di luar kota sekalipun, artinya mas wajib punya relasi dan partner yang bener-bener se-visi. Agak susah memang, itu dari pengalaman soalnya. Kalau sudah bagus koneksinya, biasanya akan dapat rekomendasi dari mana-mana : “eh, dia itu bagus loh..buat ngerjain ini, coba contact dia” dan “blablabla..” spt itu 🙂

Apalagi urusan SDM, karena koneksi yang kita maksud di sini adalah ketersediaan SDM, jika salah pilih, gk akan maksimal hasilnya.

Masalah investasi, ada tolak ukur sendiri-sendiri c..jadi tepat jg mengukur apa saja beban personil dan berapa besar biayanya.

Jangan jg “membodohi” personil, apalagi urusan investasi ini.

Mengenai masalah teknologi yg dipakai, hmm..kebanyakan pakai framework c mas, lebih enak buat pelebaran dan bongkar pasang, kalopun pake CMS juga bisa. 🙂

Nah urusan timeline (waktu), ada banyak hal yg harus diperhatikan dan sepakati bersama dengan si Client.
Jangan sampai salah satunya melanggar atau mengulur waktu, dan konsistensi ini perlu ada perjanjian di atas kertas.

Dan bagi temen-temen yang butuh template dokumen business plan, kerangka acuan kerja, dan lain-lain untuk startup ataupun proyek, bisa mampir ke link : <a href=”http://www.businessinsider.com/document-center”>ini</a&gt; 😀