Tidak Semua Bisa Latah “Agile”, Tergantung Permasalah dan Sikon Perusahaan

eberapa waktu lalu, saya dapat pelajaran berharga dari salah satu perusahaan…

di mana perusahaan ini mengikuti trend yang ada.

“kita akan gunakan agile metodology!”

Sontak yg lain girang “wah, keren nih…itu gw denger metodologi kekinian dlm pengembangan software… waterfall so yesterday”

Lantas, seiring waktu berjalanlah..
yang dianut paham scrum fundamentalist, namun yang terjadi adalah mentalitas kerja yang silo abis.

Tau apa itu mentalitas silo?
Itu loh, contohnya di lembaga pemerintahan, masing-masing lembaga pasang pagar berduri, tidak mau bersinergi satu sama lain, alhasil antar lembaga negara format data dan standarisasinya berbeda-beda…kecenderungan tertutupnya, yang kudu digarisbawahi. Alhasil ketika mencoba mengintegrasikan sistem atau sinkronisasi data menjadi tersendat, yang berakhir membuat database tersendiri yang tidak realtime.

Antar anggota tim dan antar tim di dalam perusahaan tidak memikirkan standarisasi, ada yang bikin database formatnya kayak begini, ada yg bikin backend kayak begitu, ada yangmemanfaatkan komunikasi tim menggunakan tool ini, ada tim lain yang menggunakan tool itu..dan yang terjadi adalah tidak sinkron antar departemen/lembaga di dalam perusahaan.

Ibarat membangun sebuah rumah, masing-masing tim memiliki kamar yang tidak menentu ukuran kamarnya, ukuran pintunya, bentuk pintunya, dll. Jadi semua bergerak sendiri-sendiri. Tidak akan terasa betapa “chaos”-nya nanti pada saat ada yang ngomong “kita mau nyoba nyatuin semua layanan yg dibuat tim A dan B” | “waduh, pak…masalah e tim B bikinnya pake anu..iki aku malah bingung integrasiinnya piye?” | “bikin ulang po?” | “walah”

Jangan heran kalo ada perusahaan yang setiap tahun ganti platform. 😀 

Beberapa waktu lalu saya dapat artikel menarik juga mengenai hal ini, dan mengenai silo busting.
Apa itu silo busting? Secara garis besar silo busting dapat diartikan sebagai bentuk memecah pembatas kolaborasi antar tim/lembaga di dalam perusahaan.

Berikut artikelnya; sila klik tautan

  1. Forget Agile vs Waterfall, It’s Silo Busting.
  2. dan How to boost collaboration.
Advertisements

Mengapa waktu proyek tidak dapat dihitung dengan pasti?

Pengembangan software ataupun aplikasi itu tidak pernah menggunakan ilmu pasti.

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

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

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

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

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

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

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

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

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

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

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

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

Port Forwarding In Nintendo Switch

For those who has a problem when playing Splatoon 2 on Nintendo Switch, i think i figured it out the problem.

The problem is when you got NAT type “C” or worst type “E”, you could connecting to Splatoon multiplayer match. The game uses P2P for connection management, and if the required ports is closed, you could join any match in the game. So basically, the NAT type on Nintendo Switch is represent what port and protocol that open for playing this game. If all the required ports and protocol open, you will get NAT type “A”, and if several ports and protocol open, you will get NAT type “B” or “C”, and if the required ports and protocol are close, you will get NAT type “D” or “E”.

So how to upgrade your internet NAT type to NAT “B” or the best “A”?

Here’s the method to do that:

Access your router configurations using web browser (usually on IP: 192.168.1.1), login and search the configuration of “Port-forwarding”. After that, you need to open ports range between 45000 till 65535, and don’t forget to using UDP protocol. Make sure that your port range and protocol input is correct, and then restart your router. And then check your Nintendo Switch Internet connection again. Goodluck!

 

Port-forwarding

Penjelasan Soal NAT di Dalam Nintendo Switch Beserta Penanganannya

Kalo ada orang jaringan (network engineer) di sini mesti bisa jelasin lebih mudah apa itu NAT. Apalagi yang sudah CCNA certified
Jadi begini, apa itu NAT?
NAT atau Network Address Translation adalah suatu metode atau salah satu protocol di dalam jaringan untuk menghubungkan lebih dari satu device ke jaringan internet dengan menggunakan satu alamat IP (melalui router).
Router internetmu akan menggunakan NAT tersebut untuk menyimpan setiap catatan (log) dari semua request device yang terhubung ke jaringan router tersebut, dan kemudian mengirimkan semua request tersebut ke server yang dituju (dalam hal ini server Nintendo) di internet. Request ini kalau dalam game bisa berupa request ID/user ide pemain di dalam game multiplayer, request data pergerakan pemain, dsb. Ketika routermu menerima respon dari server (dari internet), kemudian router tersebut mengirimkan respon-nya ke perangkat yang sesuai. Ya, yang request si Switch yang nerima juga tentu si Switch.
Dengan banyaknya request tersebut dan banyaknya perangkat yang terhubung ke internet dan terutama server Nintendo, untuk itulah diperlukan pengklasifikasian NAT (NAT juga dapat membedakan mana IP public dan mana IP static).
Mengapa pengklasifikasian NAT dilakukan? salah satunya, agar menjamin komunikasi antar device (dalam hal ini Switch) dapat berjalan lancar sesuai dengan type NAT-nya.
Mengapa Nintendo, Sony, dan Microsoft melakukan klasifikasi NAT ini? ya karena beberapa provider internet tidak mengizinkan NAT dibuka (biasanya port diblokir), atau bahkan dibatasi oleh vendor tersebut, jadi kalau NAT-nya gak OPEN ya bakal susah melakukan koneksi ke server.
Nah, di dalam dunia games Nintendo Switch, klasifikasi NAT adalah sebagai berikut:
    1. NAT type A (dalam hal ini OPEN): artinya kamu akan mendapatkan skala 1:1 mapping port di dalam jaringan, koneksi tidak terblokir. Buat nge-game splatoon gak masalah.
    2. NAT type B (dalam hal ini OPEN tapi mengerucut ke MODERATE): artinya koneksi tetap berlangsung dari device ke server namun terjadi di belakang NAT, dalam hal ini console Switch bakal terkoneksi ke server STUN punya Nintendo. Buat nge-game Splatoon mestinya masih OK, gak masalah.
    3. NAT type C (dalam hal ini MODERATE, yang mengerucut ke Strict): artinya koneksi terbatas hanya pada port yang dibuka saja, jadi kalau ada gamer dengan koneksi dan port yang sama ya dapat terhubung. Sayangnya Splatoon menggunakan port yang acak, jadi ya kalau port-nya gak cocok gak bakal bisa konek ke server Splatoon (gak bisa main multiplayer). Buat nge-game Splatoon ya nasib-nasib-an.
    4. NAT type D & E (dalam hal ini STRICT): artinya routernya tidak ada pengaturan NAT, alias sepenuhnya diatur oleh ISP (provider internet-nya), yang model gini biasanya sangat-sangat terbatas.

Klasifikasi NAT
Untuk tipe NAT C sampai dengan B, sebenarnya ada cara dan masih memungkinkan untuk bisa naik ke type A. Karena NAT ini berhubungan dengan settingan Port, maka kamu harus melakukan port-forwarding.
Apa itu port-forwarding?
Fitur dari router di mana fungsi ini akan membuka akses terhadap perangkat pada jaringan lokal untuk bisa diakses dari internet) di router ISP-mu. Bila di console sebelah dikasih tau port berapa aja yang harus dibuka untuk device tertentu, sayangnya di Nintendo Switch sampai saat ini belum diketahui (Nintendo belum memberitahukan port apa saja dan protocol apa saja yang harus dibuka).
Nah, langkah lain adalah membuka semua port untuk koneksi yang masuk dari internet.
Biasanya di pengaturan router ada yang namanya pengaturan NAT type: “full-cone NAT”, yang berarti semua tipe NAT di mana port-nya dibuka secara permanen (OPEN) dan mengizinkan permanently open and mengizinkan semua koneksi dari luar.
Namun, ada beberapa router tidak menyediakan hal tersebut, akan tetapi menyediakan menu untuk pengaturan port-forwarding. Di menu port-forwarding tersebut, kita diminta mengisi IP address device dan port yang ingin dibuka, seperti pada gambar di bawah ini:
Contoh pengaturan PORT FORWARDING untuk console sebelah
Nah, seperti yang sudah dituliskan;disampaikan sebelumnya kalau kita tidak mengetahui port berapa saja yang harus dibuka. (*ada pembaharuan tulisan ini, cek di bawah ya untuk pengaturan port-forwarding di Nintendo Switch)
Untuk itu, pengaturan lain agar dapat mengubah type NAT menjadi OPEN, adalah dengan membuat pengaturan DMZ server.
DMZ atau DeMilitarized Zone sederhananya adalah fitur yang memungkinkan perangkat dibalik router untuk diakses dari internet.
Jadi, kalau tadi kita sudah tahu kalau port-forwarding hanya akan membuka akses sesuai dengan port yang dibuka dan bisa digunakan terhadap beberapa IP, nah sedangkan DMZ akan membuka seluruh port sebuah IP lokal untuk bisa diakses dari internet dan hanya bisa membuka satu ip local saja (satu perangkat, dalam hal ini Switch).
Perlu diperhatikan juga, karena DMZ ini membuka semua port tanpa terkecuali, oleh karena itu jangan sekali-kali membuat koneksi DMZ host untuk PC/laptop, karena akan sangat rawan diserang intruder/cracker. Untuk Switch, sampai saat ini masih relative aman lah.
Bagaimana pengaturan DMZ server di router? Berikut ini langkah-langkahnya:
        1. Login ke routernya: biasanya menggunakan IP 192.168.1.1 (buka dari browser). Atau kalau tidak tahu IP routernya, cek di pengaturan Network di OS PC/Laptop, biasanya ada keterangan IP router/gateway (untuk TCP/IP)
        2. Pilih menu DMZ host atau DMZ server seperti di gambar ini (biasanya di dalam menu Application):

          DMZ Host
        3. Nyalakan Nitendo Switch, masuk ke Pengaturan>Internet, cek Mac Address Switch kamu, seperti pada gambar di bawah ini:
          Cek mac address di Nintendo Switch

          Mengapa menggunakan Mac Address? karena Mac Address ini sifatnya permanen, berbeda dengan IP (apalagi cuma punya IP dinamis) yang berubah-ubah setiap ganti koneksi/restart koneksi. Jadi, tidak perlu setting ulang IP di DMZ Host, karena yang dikenali Mac Address-nya si Switch.

        4. Input MAC Address dari Switch ke DMZ Host dengan cara memberi tanda centang “Enable Mac Mapping” dan mengisi alamat Mac Address Switch tersebut, setelah itu submit.
        5. Jika sudah selesai langkah-langkah di atas, lakukan restart router dan koneksi ulang Switch kamu ke internet rumahmu melalui router tersebut. Semestinya sih dari B bisa naik ke A.

Updated, Port Forwarding:

Bagaimana pengaturan port forwarding di Nintendo Switch?

Berdasarkan informasi yang beredar di forum reddit dan nintendo, port yang harus dibuka untuk koneksi ke server Nintendo adalah dari port 45000 sampai dengan port 65535, dan protocol UDP.
Bagaimana caranya?
  1. Login ke routernya: biasanya menggunakan IP 192.168.1.1 (buka dari browser). Atau kalau tidak tahu IP routernya, cek di pengaturan Network di OS PC/Laptop, biasanya ada keterangan IP router/gateway (untuk TCP/IP)
  2. Masuk ke Menu Application>Port Forwarding seperti pada gambar berikut:

    Menu Port-forwarding
    Menu Port-forwarding
  3.  Centang tombol enable, beri nama, misal “Switch”, Protocol UDP, WAN host IP address start dan end biarkan kosong, kemudian pilih WAN Connection “pppoe_1”, WAN start port, input angka “45000”, dan WAN end port, input angka “65535” (berlaku juga untuk LAN Host port start dan end), kemudian centang “Enable MAC Mapping”, dan masukkan Mac Address Switch (*untuk cara mengetahui mac address switch, cek tulisan di atas ya, dibahas di pengaturan DMZ, atau search aja di tulisan ini dengan mengetik “mac address”). Jika sudah, pastikan yang diinput benar, seperti pada gambar berikut:
    Pengaturan port-forwarding Switch
  4. Tekan tombol “Add”, selesai, selanjutnya restart router dan coba koneksi ulang dari Switch ke Router.
Sekianlah tulisan singkat, semoga bermanfaat.
Referensi :

Pentingnya memahami penamaan “assets” di dalam desain

Apa itu “aset desain” atau Design Assets ?
Aset desain adalah resources tertentu di dalam UI/UX yang digunakan ke dalam proses pengembangan perangkat lunak atau aplikasi.

Apa saja yang termasuk “aset desain”?

Yang termasuk di dalam UI aset desain adalah color palettes(codes/hexa/rgb), styles (tema), icons (icon yang akan dipasang), fonts (font yang digunakan), images (gambar, baik itu background komponen desain, background halaman, banner, gambar header, footer, dsb), animation (animasi transisi halaman), audio (suara ketika klik tombol, dsb), video (video panduan penggunaan software, video iklan) dan setiap elemen yang digunakan untuk memvisualisasikan aplikasi atau software.

Dalam pembahasan kali ini difokuskan mengenai masalah penamaan file, karena ada beberapa kasus di mana designer tidak memberikan nama yang pas untuk assets desain yang ia desain. Alhasil, untuk tracing assets design (misal: icon) ataupun memanggil assetsnya di codingan menjadi membingungkan.

Ditambah lagi, ada beberapa assets design yang nama filenya sama dengan assets design yang lain. Tentu ini akan membuat frustasi developer yang menggunakannya.

Penamaan file di dalam assets design itu sangat penting, itu akan memudahkan designer maupun developer yang akan memindahkan desain ke dalam codingan.

Umumnya, penamaan assets design itu menggunakan prefix, sama halnya dengan penamaan tabel di database, menggunakan prefix atau suffix:
Contoh
ic_email => menandakan ini icon untuk email.
bg_email => menandakan ini background untuk halaman email.
ic_email_selected => menandakan ini icon email ketika dipilih.
ic_email_pressed => menandakan ini icon email ketika ditekan.

Ya, menggunakan prefix ic_ untuk icon, bg_ untuk background, suffix _selected untuk icon yg dipilih, suffix _pressed untuk icon yang ditekan, dan lain sebagainya.

Dan ada pula yang ditaruh ke dalam sub folder tertentu untuk background di dalam folder tersendiri, untuk icon di dalam folder tersendiri, dan lain-lain.

Dengan begitu, manajemen assets design jadi tertata dengan baik 

Mengapa masih banyak startup TI yang mencari superman?

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

Lantas, di mana letak kesalahannya?

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

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

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

Ok, lanjut ke cerita saya untuk artikel ini.

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

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

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

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

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

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

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

9 Women Can’t Make a Baby in a Month

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

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

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

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

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

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

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

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

Sekian sekelumit peristiwa yang semoga bisa bermanfaat bagi pembaca 🙂

Terima kasih.

Referensi terkait tools online manajemen proyek:

 

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.