Bebas bugs?

Jika ada klien yang menuliskan kontrak kerja ataupun FSD ataupun SPK yang berisi poin “Aplikasi yang telah dikembangkan dijamin bebas dari segala macam bug ataupun error” atau sejenisnya.
Maka bersiaplah menghadapi “never ending project“.

Mengapa?
Teknologi itu berkembang “rapid pace of change“, alias cepet banget berubah, versinya hari ini 1.0, besok sudah 1.0.1, dan bahkan sudah 2.1.0.
Lantas dengan segala perubahan itu, terkadang code yang sudah ditanam di aplikasi perlu dimutakhirkan, diperbaharui agar sesuai dengan perkembangan.
Itulah kenapa kadang pas Apple atau Google mengumumkan OS terbaru, perangkat iPhone/Android baru, banyak aplikasi di PlayStore/Appstore yang minta diperbaharui (diupdate). Gunanya agar menjamin keberlangsungan aplikasi dapat berjalan dengan baik.
Terkadang urusan “back-compatibility” itu tidak terjamin, apalagi perubahan struktur code/bahasa pemrogramannya radikal. Terpaksa deh diperbaharui daripada bermasalah di perangkat baru ataupun OS baru.

Ruginya kalau kita menjamin app yang telah dikembangkan menjadi app “yang bebas kutu”, maka kita harus siap dengan segala macem perubahan teknologi tersebut, alhasil jadilah “senjata” klien agar dapat layanan gratis dari developer.

Bagaimana antisipasinya?

1. Buatlah batasan masa UAT (User Acceptance Test) atau masa alpha/beta version dari aplikasi yang telah dikembangkan menjadi 1 periode waktu, misal masa UAT dibikin terbatas selama 1 (satu) minggu, 2 (dua) minggu atau max 1 (satu) bulan.
   Jadi, selama masa UAT, klien harus menyiapkan laporan bugs sekali selama 1 minggu (misalnya), kemudian ditulis di dokumen agar nanti masalah-masalah tersebut di-reproduce dari sisi developer untuk dicari masalahnya.
   Biasanya yang dilaporkan itu adalah waktu (jam/tanggal) pengujian, kronologi (urutan) actual result, dan expected result (hasil yang diharapkan). Akan lebih bagus lagi dilaporkan via tiket di gitlab/jira/trello.
   Ingat, klien harus punya gerak terbatas di UAT, jangan sampai pas kita lagi benerin bugs, dia malah laporin bugs-bugs lain dan minta cepet diperbaiki, alhasil masa perbaikan bugs mengalami banyak interupsi dari klien yang sudah pasti akan menyebabkan “delay” pekerjaan. Makanya kalau di kontrak kerja, saya selalu tulis “report once” pada tanggal tertentu (yang sudah ditentukan). Jika klien telat memberikan laporan bugs tanpa sebab yang jelas? siap-siap deh “project termination”. Di luar masa tersebut, tidak perlu dilayani, kan kontrak sudah habis.
2. Beri garansi terbatas, misal “2 (dua) minggu aplikasi tersebut bebas bugs dan siap memperbaiki masalah minor”, jadi kalau ada update library, struktur codingan, dll selama itu minor, ya dikerjakan dalam waktu 2 (dua) minggu tersebut, jika tidak ya harus dinyatakan sebagai “change request” (CR) alias permintaan tambahan.

“Lah kok enak banget, sudah bayar mahal-mahal masa’ gak dijamin? kan tanggungjawab anda selaku developer!”

hahaha..ini saya kutip dari klien yang pernah ngomong kayak gitu ke saya. Jadi dianggapnya, karena kita sudah dibayar maka tanggungjawab penuh sampai aplikasi dan sistemnya itu wafat 😂 “enak, gundulmu!” akhirnya ya saya tinggalin klien kayak gini (alias project termination karena permintaannya tidak saya penuhi karena di luar kriteria “bugs” dan “minor update” dan sudah lewat masa garansi).

Saya di kantor saja, selesai masa development, kelar UAT 1 bulan, setelah itu ya cuma rapat ini itu, gak ngoding sama sekali, tetap digaji, walaupun kerjaan garap app dah kelar, tetap digaji, iya, “kok enak? magabut ya?” yo nggaklah, itu kita standby siap sedia kapan saja bila ada masalah, kesulitan dari user, dll..siap bantu selama jam kerja. Setelah pengembangan selesai, kita dibayar untuk tanggungjawab melayani sesuai “job desc” kita. Lah enakan klien sudah gak bayar, minta dilayani aplikasi dijamin hidup terus. 😅

Logikanya, kita beli motor/mobil, mana maulah perusahaan yang bikin motor/mobil tersebut nyediain layanan atau sparepart gratis. Coba aja datang ke dealer motor/mobil pas mobilnya mogok “pak, saya beli mobil dengan anda, kenapa ini mogok, ini tanggungjawab anda, tolong perbaiki”, saya jamin diteriakin “stress!”.

Inget kata-kata Joker, “never do it for free“. Mau teman sekalipun, profesionalisme harus tetap dijaga, karena ya ingat, ada hak pekerja yang harus dipenuhi, dan pekerja tersebut juga punya tanggungjawab terhadap keluarganya.

10 hal yang bikin “annoying” di dunia proyek pengembangan aplikasi/software. Nomor 10 bikin kamu tercengang.

1. Kadang klien bercandanya kelewatan, ngajuin penawaran 45 hari, ditawar jadi 6 hari.

2. Kadang klien gak kira-kira minta revisi fitur, disangkanya nambah atau ubah scope pekerjaan itu gratis dan bisa sekejap selesai.

3. Disangkanya kalau aplikasi mobile itu karena ukuran smartphone lebih kecil dari layar monitor, maka pengembangannya lebih cepat.

4. Klien ngasih laporan error gak jelas. “Mas fitur anu kok gak bisa ya” tapi gak dijelasin gak bisanya di mana, pas melakukan apa, pake smartphone apa, pake browser apa. Minimal kasih detail singkat pas lagi ngapain.

5. Klien ngasih target 30 hari, tapi sampai H+15 belum juga ngasih contoh data yang dibutuhkan.

6. Klien potong kompas, langsung japri si developer gak melalui kanal grup, dan gak melalui project manager, akhirnya gak ke-track-ing issue-nya.

7. Developer yang SKS, semaleman dirafel beberapa task, setelah itu tepar/menghilang. Mending daily push atuh walau sedikit yang penting rutin/disiplin, karena bukan kerja individu, tetapi tim (kolaborasi).

8. Developer yang kurang inisiatif, gak ngasih kabar kesulitan di mana, tau-tau menjelang deadline ditanyain kenapa lelet, ternyata slama ini ada masalah.

9. Project Manager yang semena-mena. Gak pake diskusi dgn developer/tim, langsung ambil keputusan ngomong ke klien “bisa dikerjakan cepat, pak.. 1 hari kelar”, gak taunya developer kaget “lah kok sehari, ini fitur effortnya gede”.

10. Bikin kamu tercengang.

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; 😀