Tune-up your M1 Macbook

M1 chip is so powerful, but it doesn’t came without issues.

After 2 days i work using Mackbook Air M1, i saw the “Activity Log” on “Activity Monitor App” have a serious high process running on Background.
So, i did some researches and try it by myself and monitoring after it, to know is this tweaks is harming my Macbook or not. So i write this post to tell what i found.

1. CalNCService on Memory TabIf you see on the Memory Tab, you will see “CalNCService” using the memory higher than other process, between 800 MB till 1 GB.
   So what need to do to make the “Memory Pressure” always green?

   OK, the steps need to follows are below:

   1. Open System Preferences, Internet accounts and untick Calendar for each account.
   2. Open Activity Monitor, search calendar and quit calendar processes.
   3. In Spotlight Search (⌘Space) open /Library/Caches and drag contents to trash.
   4. In Spotlight Search (⌘Space) open ~/Library/Caches and drag contents to trash.
   5. Again, in Spotlight Search open ~/Library/Caches and drag contents to trash.
   6. In Spotlight Search (⌘Space) open ~/Library/Containers  and select
      com.apple.CalendarAgent,
      com.apple.CalendarAgent.CalNCService,
      com.apple.CalendarFileHandler,
com.apple.CalendarNotification.CalNCService
      Drag the selection to trash.
   7. In Spotlight Search (⌘Space) open ~/Library/Calendars and drag contents of the folder to trash.
   8. Restart your computer.
   9. Empty trash.
   10. Open System Preferences, Internet accounts and tick Calendar for each account.
   11. Open Calendar and wait for Calendars to sync.

   Notes: this issue is happened on macOS Sierra and above, not only M1, but in M1 make this issue worst. So you’ll need to do this step.
   I am ensuring this step is no harming your Macbook.

   

   so green..so healthy

2. kernel_task on Disk Tab
   There are so many articles on the internet that told you, the SSD on M1 chip is bad. They said it will make SSD lifespan on M1 short. I found it on “Activity Monitor”, the kernel_task has 1,4 GBytes written.
   The suggestion came out and want you to turn off swap memory. Trust me, don’t do that, it will make your M1 Macbook worst. So what need to do? Don’t worry about that. I’ve read so many articles, and found this: How worried should you be about your M1 Mac’s SSD lifespan? (macworld.com):

   “What is also clear from other studies is that the more memory you have the less you have to swap it to the SSD. The M1’s memory management is no doubt more efficient than that of Intel Mac’s, but it can’t work miracles. When it’s time to swap, it’s time to swap, and that may be due to heavy-duty creative work or simply having a lot of memory-hungry programs open at once.”

   So, don’t worry about that. Let it flow……

Thank you.

Take and Give

Ada beberapa chat yang masuk gara-gara saya deklarasi menolak proyek pemerintah kemarin.
Salah satunya, “kok berani, mas? “
Untuk urusan proyek, saya memang cara mencarinya adalah dengan membangun relasi. Contohnya gini: Anggaplah beberapa rekanan saya itu bisa melihat potensi pasar, dan saya yang menyediakan SDMnya.

Nah, beberapa rekanan saya seperti itu, mereka punya peluang tp kekurangan SDM, saya siap bantu. Di sinilah kenapa tawaran datang silih berganti dari berbagai pihak. Resourcenya? ya saya simpen. Itulah kenapa kalo ada chat yang masuk: “mas widy, ada developer X gak 2 buah?” ini beneran gak sopan, well, saya bukan talent hunter, silakan cari sendiri. Kenal juga kagak, dateng-dateng nanya. Di kantor saya dulu, saya merekomendasikan orang buat masuk kantor, saya dibayar 5jt, ini saya gratisan doang ya jelas tidak mau. Business is business.

Relasi yang saya bangun juga bukan tiba-tiba deketin orang, terus nawarin kerjaan, tp mengalir, ntah karena pernah kerjasama bareng, proyekan bareng yang tidak sengaja, terus kenal, dan akhirnya timbul chemistry untuk partnership.Dan itu masih saya lakukan sampai sekarang.Nah, di beberapa kasus, saya kekurangan tenaga tambahan, maka dari itu saya biasa bikin postingan dibutuhkan developer x, y, z, di grup programming ataupun di wall saya. Dan filteringnya, dibantu internal tim. Jadi, semua dilibatkan, agar tim internal juga bisa mendapatkan tandem baru yang benar-benar “sehati”.

Dan ada juga beberapa designer yang mengajak kerjasama, di 2 kota berbeda. Mereka tim designer. Bisa desain tp tidak bisa mewujudkan desain tsb menjadi sebuah sistem, padahal klien butuh itu, dan maka dari itulah, akhirnya saya masuk ke studio-studio design tersebut membantu kebutuhannya.

Di beberapa situasi, karena ini kerjasama mutualisme. Biasanya saya sudah memasang harga:
harga proyek=harga tim+harga pribadi saya+harga komisi karena partner sudah merekomendasikan saya.

“loh jadi mahal dong?” | “gak juga, kita semua gak idealisis materialistis, sikon klien, potensi pasar, dll mempengaruhi”Dan terkadang saya bilang gini “aku sudah pasang harga segini, silakan aja mas/mbaknya tambahin yah buat diajuin ke klien” (nah di sini biasanya saya sadar partnernya memainkan harga untuk dirinya), untung dong keduanya.

Nah, sayangnya model yang saya ceritakan di atas tidak berlaku buat plat merah. Harga tim jelas di-press buat vendor, karena vendor mesti punya backup dana, mesti punya jaringan orang dalem (uang pelicin), mesti punya pasang badan+nama buat ngadepin klien, jadi ketika kita coba idealis pasang harga tinggi, otomatis ditekan dengan sendirinya. Kalo gak gitu, opsinya, tim saya maju semuanya sendiri, dan ini biasanya akan kalah dengan urusan birokrasi, karena memang butuh orang yang berpengalaman dan tahan banting.

Di beberapa situasi, opsi kasih harga rendah buat dapet portofolio adalah jalan ninja beberapa pihak plus agar lolos penunjukan langsung tanpa tender. Dan gimana caranya bisa ngambil 2 atau 3 proyek pemerintah dalam 1 waktu? pake ijazah palsu? pake data SDM palsu? pake vendor palsu? GAK. Jawabannya adalah “Kage bushin no jutsu”. Anggaplah vendor A, punya SDM inti yg sdh diajukan, terus proyek gak selesai, karena SDM bermasalah, kemudian di waktu bersamaan, ada vendor B dengan kasus serupa, nah saya masuk di keduanya. Jadilah saya bisa garap 2 proyek plat merah di waktu bersamaan. Yang sebetulnya, secara UU 1 vendor itu tidak boleh menggarap 2 proyek pemerintah bersamaan, tapi ini vendornya tetep berbeda, cuma SDMnya saja yang komposisinya mirip. Saya sadari saya berada di zona abu-abu.
“Loh, mas Widy jadi broker SDM dong?” nope, walau gak ikut ngoding, saya yang mengelola tim ini, sebagai project manager.

Dibekali sedikit pengetahuan teknis, saya bisa berkomunikasi dengan klien ataupun dengan developer. Jadi, saya menjamin SDM ini tetap ontrack dan jikalau ada yang berhalangan, saya mesti cara cara ntah meyakinkan klien atau menambah tenaga tambahan atau hal lain, yang intinya project tetap on-track. Komunikasi, mengatur tiket, bikin summary, itu yang dikerjakan.

Desain antarmukanya dulu, baru hitung harga pengembangan Aplikasinya!

Pernah dapet kerjaan yang walaupun requirementnya sudah diberikan dengan detail, dalam bentuk FSD, tapi belum bisa berasumsi apapun bakal kayak apa nanti aplikasinya.

Di saat itu jadi “gambling” kalau kita buat proposal penawaran dikhawatirkan meleset dari budget dan time yang disepakati karena alasan di atas.

Bila sudah timbul keraguan seperti itu, maka ada baiknya memisahkan penawaran desain antarmuka dengan penawaran development.

Rekrut-lah designer UI/UX yang berpengalaman. Bila kerjaannya desain UI/UX app mobile maka rekrutlah UI/UX designer yang punya pemahaman dan pengalaman soal design pattern mobile, begitu juga dengan web app maupun progressive web app. Jangan sampe kita rekrut UI/UX designer web untuk mobile app, tau-tau yang didesain itu gak sesuai design pattern Android/iOS, yang ada ntar menyulitkan developer mengimplementasikan desain UI/UXnya.

Biarkan desain UI/UXnya clear dan jadi dahulu, sehingga kita tau ekspektasi klien seperti apa dan goal yang harus dicapai developer.

Pakai designer collaborative tool seperti Zeplin, Figma atau Marvelapp.
Tool ini sangat bermanfaat buat presentasikan desain UI/UX sehingga klien maupun developer dapat gambaran sempurna mengenai UI dan UXnya. Tinggalkan cara lama dengan kirim psd apalagi belum dislicing. Pakai tool design collaborative di atas juga sudah bisa export menjadi assets yang dibutuhkan di mobile app secara instant.
Bila desain UI/UX sudah siap 100%, dengan begitu developer dengan sangat yakin dapat menghitung berapa lama dan berapa biaya yang dibutuhkan untuk pengembangan aplikasi tersebut. Dan skup kerjaan dikunci sesuai desain UI/UX yang sudah disiapkan.

Jadi, apabila ada perubahan desain ataupun tambahan desain pada saat pengembangan aplikasi berlangsung, maka ini akan dianggap sebagai tambahan atau di luar skup yang disepakati.

Bila klien menghendaki sekaligus, maka kita selaku developer memberikan masukan mengapa desain antarmuka dibutuhkan di awal agar nantinya tidak ada yang missed antara yang diharapkan klien dengan apa yang dikerjakan developer.

Pertimbangan sebelum membuat aplikasi berbasis layanan (produk/jasa)

Beberapa waktu yang lalu, tim saya membuat aplikasi berbasis layanan jasa, bisa dibilang sudah 80% pengembangan selesai.
Dari awal meeting saya sudah salut dengan klien, “jujur, bu, saya salut Ibu bisa biayain semua sendiri buat infrastruktur sampai dengan development, karena aplikasi berbasis layanan jasa itu mahal. Mahal developmentnya, mahal juga post-developmentnya. Saya saranin ke depannya Ibu cari investor. Dari pengalaman saya handle aplikasi berbasis layanan jasa, ada dua yang saya tau itu sudah dapat investor, ada yang dari Lembaga Pemerintah, ada juga yang dari luar Indonesia”

Tiba-tiba, pas mau launch, muncul masalah ini dan itu.. ekspektasi si klien, setelah development selesai app bisa dipakai tanpa masalah, auto pilot, tinggal hasilin duit.

Realita-nya, di beberapa customer, app muncul error macem-macem, saya yang sudah lepas kontrak, tiba-tiba dihubungi kembali.

“Pak, ini app.nya bermasalah, ada customer gak bisa login” |
“masalahnya apa ya bu?” |
“bapak bisa saya telpon?”.

Setelah ditelpon, ditanya macem-macem, si Ibu ini kaget..

“loh, kontrak bapak sudah selesai ya?” |

“sudah lama, bu. Ibu belum diceritain bu Y” |

“Y gak cerita apa-apa, Y juga sudah resign Oktober lalu” |

“nah, kontrak saya juga sudah habis Oktober lalu, bu. Saya juga sudah serahkan sourcecode, technical guide document, dan juga installer app.nya ke kantor ibu” |

“wah kok saya gak tau ya” |
“masa’ gk ada yg cerita, bu? Pak C masih kan bu?” |
“masih, tapi pak C juga bilangnya semua yang tau itu ya Y” dari diskusi ini saya cuma mengkerut kening 😅

“Terus gimana ini, pak?” |
“ya Ibu harus rekrut kami sebagai maintenance developer bulanan” |
“loh, kok kontrak kerja lagi, pak?” |

“ya iya, bu, kan kontrak kemarin sudah berakhir, masa’ kami tiba-tiba langsung nimbrung aja benerin kerjaan” |
“hehe..kira-kira bayar berapa, pak?” |
“kami ada biaya maintanence bulanan, bu..kami kirim quotation-nya ya”

Dan muncul masalah ini dan itu, mulai dari migrasi, ubah fitur, dll. dibilang..

“bapak kan sudah kami rekrut, masa’ ada biaya lagi, pak?” |
“ya ini bukan maintenance sih, bu, sudah dianggap sebagai changes request (CR), kan kami sudah bikin catatan di quotation mana aja yang bukan kerjaan kami” |
“ya tapi kan bapak yang develop, harusnya tanggungjawab bapak dong”..

Menghadapi klien memang kudu extra sabaaar 😅

“iya, bu, tapi gak gratis, kami juga di sini kerja, kontrak kerja sudah selesai, ada baiknya Ibu rekrut aja developer tetap buat menjaga sistem di kantor Ibu, kalo rekrut maintenance developer ya cuma support aja. Lagian sistem kayak gini gak bisa ditinggal gitu aja gak ada yang jagain, bu, Ibu harus punya tim TI internal yang menjamin keberlangsungan sistem ini berjalan baik, mulai dari PM, system analyst, UI/UX engineer, development engineer, QA engineer, dan sys admin/devops“, kalo ngandalin kami ber-3 ya gak mungkin bisa, apalagi ini reportnya banyak sekali yang masuk dari customer.”

Sayapun berceramah panjang lebar.

“tapi tolong, pak, kami disupport, kami sudah percayakan bapak selama 1/2 tahun ini..” |
“ya kami support sesuai job desc kami, bu.” |
“ini jujur, pak, dananya belum sampai ke kami, saya juga sedang berusaha cari investor” |
“iya, bu, kalau kayak gini mau gak mau Ibu cari investor, jumlah user juga sudah banyak kan” |
“iya, pak, ini tagihan server sudah tembus 24juta”

saya baca ini kaget. Kok cepet ya, apa karena storagenya kepake banyak, karena app. customernya butuh upload banyak data image.

Dari sini tiba-tiba si klien ini berpikir agak berbeda,

“Pak, apa boleh kami pending bayaran tim bapak, kami soalnya terkendala biaya server” |
“waduh, gak bisa, bu, ini bukan keputusan saya sendiri, tim yang kerja, masing-masing freelancer” (soalnya dulu juga pernah kepending 1 bulan oleh ini klien bayaran kami, masa’ dipending lagi)

“Wah, bu, Ibu tau gak kenapa aplikasi berbasis layanan jasa kayak Grab, Gojek, dan Ruang Guru..itu tiap tahun slalu buka lowongan kerja developer, QA engineer.. (sambil saya nyodorin link job vacancy-nya buat barang bukti…), ya karena sistem mereka gak autopilot, itu post-development mereka makan biaya ratusan juta sampe M per bulan loh, bu, selain bakar duit, jagain sistemnya biar tetap lancar tanpa masalah juga mahal. Tiap hari tim developernya ada aja kerjaan benerin bugs di beberapa device, itupun yang ngetest bukan developer, tapi tim QA Engineer, dan mereka dibekali beragam HP Android dan iOS, bu”

Ibu ini diem gak berkomentar.. cuma bilang…

“ok, pak, terima kasih insight-nya”

Ini cerita dah mirip dengan cerita klien-klien yang lalu-lalu, seragam, rata-rata orang sini menganggap sistem/app walau tampilannya kecil, ketika sudah jadi, langsung bisa menghasilkan duit, autorun, autopilot tanpa harus “dijagain”…kok enak ya kalo dipikir-pikir 🤣

Tahun 2012-2013, saya pernah punya pengalaman direkrut perusahaan di Jakarta sebagai Maintenance Developer, ya kerjaannya sebagai support, balesin chat soal development, bantuin PM balesin email, dateng ke tempat klien buat maintain webnya klien, dan kadang magabut (makan gaji buta) karena tidak ada laporan bug, tapi ya tetap digaji bulanan di Jakarta.

Pas di Jogja juga pernah sebagai support untuk sebuah startup koki masakan, namanya “Stagiaire”..bikin app resep masakan seperti cookpad, direkrut buat maintain, dibayar 6,5jt/bulan dan kerjanya gak pasti ada tiap hari, sehari cuma 3-5 jam aja. (Jadi bisa saya sambi kerjaan lain). Artinya ya perusahaan ini paham, “lo gw bayar buat support, siap kapan aja pas ada masalah di sistem/app.nya”.
Setelah kerjaan maintain aplikasinya selesai, dilanjut diujicoba QA engineer, dicari bug-nya, dilaporkan balik ke developer, sampai test case passed, langsung dicoba tim production. Jadi kalau sudah lolos QA dari development, itu belum selesai, bisa jadi pas production bermasalah, ini ntar direproduce QA issuenya dari Production, kemudian balik ke developer, setelah diperbaiki, balik ke QA dan selanjutnya balik ke Production lagi, kalau sudah OK, barulah dilepas ke publik.

Itulah kenapa perusahaan yang bergerak dibidang layanan (service) produk/jasa, mesti recruitment nya banyak. Soalnya timnya juga banyak, per tim ada 4-6 orang. Dan kerjaannya serba cepat dan agile.

Di Jakarta dah biasa kayak gitu untuk kelas perusahaan. Tapi buat klien personal memang harus dibuka pemahamannya dengan sabar. Jika hendak membuat sesuatu yang besar, butuh dana besar, dan tim yang besar agar bisa berlari kencang.

Melompat melewati zona nyaman Programmer

Harus diakui yang berperan penting membekali saya untuk melewati zona nyaman programmer adalah 2 perusahaan: Plasmedia dan Dimo.
Dua perusahaan ini suasananya hidup, sangat fleksibel. Misal berhalangan karena anak/keluarga sakit, tidak dibilang “wah gak profesional dong alasannya keluarga”, tetapi kantor-kantor tersebut toleransi, asal keterangannya jelas dan tidak menghilang.

Dari situ saya jadi menerapkan ke tim developer yang saya rekrut, “apapun beritanya kabarin, mau soal keluarga, padam listrik, dll..dengan saya terbuka saja, gak akan saya cap gak profesional. Kalo gak ada kabar barulah tidak profesional”
Bahkan ada jam olah-raga, di Plasmedia dulu futsal rutin per minggu, pas di Dimo sempat beberapa kali Badminton. Bos-bosnya juga easy going, tidak horor/killer, dari situ saya belajar mengenai seorang leader, bukan seorang boss yang hanya bisa perintah.
Di Plasmedia, atasan saya ada yang muslim dan ada yang non-muslim, semuanya baik, tidak pernah urusan agama jadi pembeda. Bahkan kalau waktunya sholat ya ada break buat sholat. Jum’atan juga bareng dengan atasan-atasan yang muslim.
Di Dimo, atasan saya non muslim, tetapi pas kerja remote, misal di Jogja kedengeran suara adzan melalui Skype, yang di Jakarta langsung bilang: “di Jogja sudah adzan ya, kita break dulu, silahkan yang mau sholat-sholat dulu, setelah itu kita lanjut diskusi”. Dan klien (klien kami waktu itu Sinarmas), bisa dikondisikan beliau, “pak, bu, ini tim developer Jogja mau sholat dulu, kita break dulu, setelah ini kita lanjut diskusinya”
Dari sini saya bisa belajar mengerem, balance antara kerjaan dengan agama. Jangan grasak-grusuk.

Pas di Plasmedia, atasan saya bernama Pak Agus Salim slalu mengajak saya (berdua) bertemu klien-klien, saya ingat betul kata beliau “Wid, ntar lu belajar ya liatin gua ngomong dengan klien, cara bertemu klien gimana, ketemu siapa aja, biar ntar lu bisa mandiri”. Dan betul, dari situ saya bener-bener diterjunkan sendiri ke Bank Export Import (eximbank), BRI pusat, BNI46 pusat, dan Danamon pusat. Dari situ yang kaku gak ngerti apa-apa, jadi belajar berani, dan dari situ saya pahami kalau atasan saya mengajak saya agar melewati boundary. Dan jadi pelajaran berharga buat saya sampai sekarang di dalam dunia perproyekan. Walaupun di Plasmedia saya cuma 1 tahun pas.

Setelah kembali ke Jogja, gabung Dimo, saya juga sering curhat ke atasan saya, namanya pak Albo Gitananda. Salah satu perkataan beliau yang sampai hari ini saya ingat adalah, “ketika saya tidak ada, kalian harus mandiri memanage pekerjaan ini, bagaimana membuat tiket di Jira, membreakdown persoalan menjadi task kecil-kecil, mengatur target deadline, dan yang lebih penting adalah jadi bekal buat mas Widy, dkk agar nanti kalau sudah naik tingkat ke level manajerial tidak kaget, tho pasti nantinya pengen naik tingkat juga kan demi keluarga. Saya juga dulunya programmer, mas. Bahkan skill saya serba setengah-stengah, backend bisa setengah-stengah, mobile app juga bisa setengah-setengah, di CIMB juga saya ngoding, tapi perlahan tapi pasti, saya juga belajar level atas saya, kalo diajak bos-bos saya meeting ya ikut aja, perhatiin sikap mereka menghadapi klien, gaya bicara, intonasi, dll..semua saya perhatiin”
Di Dimo-pun yang setahun lebih kemudian ditarik ke Sinarmas guna melanjutkan digital banking (e-money), dari situ saya banyak belajar.

Dan sekarang sudah melalui itu, tidak jadi programmer lagi, membawa beberapa tim di beberapa proyek, dari yang murah hanya 5-7 juta sampai yang ratusan juta. Bekal yang tidak pernah saya lupakan, dan yang jelas masih kurang, karena harus banyak belajar lagi dari para senior-senior.

Dan dari situ juga, saya bisa memetik pelajaran, bila ingin naik ke tingkat lebih tinggi, maka perhatikan dulu, seperti selogan Vini, Vidi, Vici (saya melihat, saya datang, dan saya menang). Sambil belajar level lebih tinggi. Terkadang ada saja programmer yang ngeluh, “lah, database dan rancang arsitektur kan bukan tugas saya, ngapain saya ikut-ikutan”, “lah, ngapain saya ikut2an ketemu klien, ikut rapat, itukan tugas PM!”, yang seperti ini berarti developer yang menolak diajak maju.

Pihak Ketiga

Di dalam perproyekan TI, terkadang antara kedua belah pihak (klien dan developer) mengalami jalan buntu untuk mengejar target deadline, ntah karena terkendala teknis ataupun butuh percepatan. Biasanya yang dilakukan kedua belah pihak tersebut adalah merekrut developer tambahan dari pihak ketiga. Pihak ketiga di sini adalah tim developer yang punya badan sendiri.

Ketika menjadi pihak ketiga di antara kedua belah pihak perproyekan tersebut, akan banyak sekali resiko yang bisa dihadapai, di antaranya:

1. Proses adaptasi yang lambat.
   Karena kerjaan developer pihak ketiga nantinya melanjutkan existing code, maka proses adaptasi beresiko menjadi lambat, butuh developer yang punya skill adaptasi yang tinggi dan tentunya jam terbang yang cukup tinggi. Jika tidak, maka tentunya akan merepotkan developer pihak pertama/kedua, proses brainstorming ke pihak ketiga menjadi penghambat proses development. Belum lagi menyesuaikan git flow dan juga pengaturan manajemen proyek di keduabelah pihak tersebut.
2. Tidak fokus.
   Ketika developer pihak ketiga sudah jelas kerjaan yang akan dikerjakan, sudah diberikan briefing masalah yang harus diselesaikan, kemudian masuk di antara kedua belah pihak proyek, terkadang pekerjaan developer pihak ketiga menjadi tidak fokus, biasanya ada saja kendala, “lah, diminta garap report kok malah datanya belum siap, pakai dummy-pun mereka lambat menyediakan”… “lah katanya API ready, ini kok pas ditest malah error”, “hmmm..ini kok malah disuruh garap yang belum selesai dari kerjaan developer internal”. Maka dari itu, sebelum pihak ketiga masuk ke pekerjaan tersebut, ada baiknya mengecek kesiapan semua yang akan dikerjakan, jangan sampai dibuat tidak fokus oleh masalah internal proyek tersebut. Selain itu, terkadang karena klien merasa dengan menambah personil maka akan bisa kejar target tepat waktu, ada saja request tambahan yang diminta sebagai bonus, yang menyebabkan resiko molor dan melebar dari skup pekerjaan yang dibahas terjadi.
3. Pembayaran terlambat.
   Biasanya pihak ketiga ini tidak bisa membuat kesepakatan pembayaran tersendiri, ntah karena kendala birokrasi atau regulasi, dan lain sebagainya. Dan biasanya diikutsertakan di pembayaran tim developer kedua belahpihak, “maaf ya mas, bayarannya tunggu web yang sudah disiapkan pihak kedua siap, biar sekalian” walaupun pekerjaan developer pihak ketiga ini sudah selesai. Jadi ya nunggu proyeknya ditutup dulu mengikuti jadwal kedua belah pihak.

Oleh karena itu, pahami resiko-resiko tersebut jangan sampai nanti salah melangkah menjadi developer pihak ketiga.

Fenomena Gunung Es

Ilustrasi gunung es

 

Di dalam dunia proyek pengembangan aplikasi atau software, tidak jarang bertemu “gunung es”

tahukan kamu maksudnya? 😁 ya, meleset dari perkiraan atau estimasi, ntah itu spesifikasi, harga ataupun waktu. Terlihat kecil, ternyata di dalamnya sangat besar.

 

Sayapun beberapa kali mengalami hal seperti ini, perkiraan saya makan waktu sekian dengan biaya sekian, ternyata ada 1-2 fitur yang kurang detail atau kurang dalam, dan ternyata menjadi melebar ke mana-mana dan memperburuk keadaan terutama waktu.

Harga jelas sulit diubah, karena model proyek seperti ini biasanya sudah ditetapkan di awal. Akan berbeda situasinya kalau menggunakan “tarif durasi” seperti di upwork.com atau freelancer.com

 

Nah, jika sudah terjepit di situasi seperti ini, segeralah keluar dari “zona nyaman” stuck di “gunung es”. Saya biasanya melakukan negosiasi kembali dengan klien, agar tidak merugikan keduanya.

Kenapa disebut “merugikan keduanya”?

Karena klien jelas rugi, bisnis dia tidak jalan, molor, padahal target production bulan Februari, tapi sampai Maret tidak selesai. Jelas rugi, bisnisnya tidak jalan.

Dan si developer juga jelas rugi, yang tadinya harusnya nerima bayaran Februari, sampe Maret puasa tidak mendapatkan bayaran tapi masih lanjut kerja terus. Jelas rugi, tidak ada pemasukan, kasihan keluarga.

 

Nah sebelum terlalu lama stuck, negosiasi wajib dilakukan, obrolinlah dengan baik ke klien, kalau situasi “gunung es” terjadi. Komunikasi persuasif sangat penting, yaitu membicarakan solusinya bersama, sebagai contoh bisa dipisah fase development-nya, misal target bulan maret sampe 8 tasks saja, setelah itu lanjut termin pembayaran, dan sisa tasks-nya dibuat bayaran per item atau per durasi, misal bayaran per bulan. Atau coba ajukan penambahan biaya, jelaskan kalau fiturnya sudah melebar dari kesepakatan dan ada fitur yang belum spesifik, biasanya klien bisa memahami, ntah mungkin skup pekerjaannya diperkecil atau memang termin pembayarannya ditambah, atau solusi-solusi lain yang masih banyak kemungkinan yang bisa dibicarakan disesuaikan dengan situasi dan kondisi.

 

Jadi, jangan malah menghindari klien, ngeluh berat menjalankannya dan stuck di situasi tersebut. 😊

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.

Menghindari tambal sulam di dalam pengembangan Software

Tadi sore ada pertanyaan soal ini:

Terkadang saya masih bertanya-tanya mas bagaimana sebenarnya desain arsitektur software dan juga database yang baik. Setidaknya, ketika ada pengembangan menjadi lebih mudah utk dikembangkan.
Apalagi kaitannya dengan perubahan atau penambahan struktur database yang terkadang menyebabkan perubahan coding (sering sy alami)

Pertanyaan cukup menarik.

Berdasarkan pengalaman, jangan terburu-buru masuk ke tahap development.

Kekeliruan kebanyakan developer, menurut saya, terlalu prematur tahapan rancangan, langsung lompat ke tahap development.

Saya selalu menghindari hal tersebut, alasannya karena rancangan arsitektur yang tidak matang menyebabkan sistem yang akan dibangun ntar jadi tambal sulam

“eh iya ada yang ketinggalan, tambahin dulu deh tabel databasenya”,

“waduh, ternyata di tabel lama sudah ada kolomnya, apa direfactoring aja ya…”, jadinya njelimet.

Pahami “Design thinking“. Yaitu, ajak tim melakukan brainstorming, duduk bareng mendefinisikan masalah dan scope pekerjaan, kemudian di-breakdown menjadi task-task, dan duduk bareng dengan orang-orang yang biasa mendesain rancangan arsitektur software, mendesain rancangan database, dan mendesain rancangan antarmuka, melakukan coret-coret UML-nya (use case dan activity diagram), bikin physical data model database-nya, dan coret-coret wireframe/mockup desainnya.

Setelah itu, diskusikan lagi bareng-bareng lebih lanjut, ajak juga si klien, sambil jelaskan design flow sistemnya seperti apa, biar kelihatan nanti kekeliruan mendesain arsitektur software-nya di mana, pemilihan teknologi, service yang dipakai, database yang dipakai, nanti kelihatan semua yang perlu dikoreksi di mana.

Biasanya nanti ada sanggahan dari klien..

Misal “saya gak pengen flownya seperti itu, pengennya seperti ini”, nah ini jangan langsung manut, ajak orang UX, kasih tau UX jaman now untuk software yang dibangun kayak gimana, UX di software/aplikasinya seperti apa.

Paling mudah sih, kasih pembanding, pembanding dengan software serupa yang sudah ada di dunia ini, jadi si klien bisa percaya kalau usulan dia keliru.

Dan terkadang ada sanggahan lagi dari klien terkait teknologi, “wah, pake teknologi itu biayanya mahal ya, uang kami tidak cukup”, nah, untuk kasus yang kayak gini, kasih alternatif teknologi yang gratis misalnya atau yang lebih murah lagi, sambil kasih tau apa kekurangannya jika ada.

Kalau misal nanti ketemu kendala, “wah teknologi yang dipakai kalau yang handal sih X, tapi masalahnya belum punya pengalaman soal itu”, nah yang kayak gini harus pandai memposisikan diri “mau rekrut personil yang ahli di teknologi tersebut” atau “alokasikan waktu dengan tim buat mempelajari” (masing-masing ada resikonya)

Tips buat para klien yang hendak merekrut pekerja TI

Ada banyak sekali permasalahan di dalam manajemen proyek.

Salah satu yang menarik adalah ketika klien salah memilih vendor/tim developer yang menyebabkan project amburadul. Atau karena tim developer baru sadar keliru di dalam merancang design arsitektur software yang sudah terlanjur dibuat.

Dan biasanya ujung-ujungnya dicarilah penyelamat proyek.

Setidaknya sudah lebih dari 3x saya diminta jadi “penyelamat proyek”

Dulu, klien personal dari PLN Sumatera Utara, meminta saya develop aplikasi pelanggan dalam waktu semalam, padahal si klien ini dadakan mengabarkan.

Pernah juga, ada teman yang ditinggal developernya, saya diminta menggarap aplikasi fintech dalam waktu 2 minggu. (Dulu app-nya pernah saya share juga di facebook)

Pernah juga, ada startup marketplace yang sourcecodenya berantakan akhirnya susah dimaintain yang akhirnya meminta saya refactoring code tersebut.

Permasalahan seperti ini akar masalahnya kebanyakan adalah menganggap bahwa membuat software itu tanpa perlu monitoring di setiap prosesnya. Cukup perintah ke developer untuk kerjakan karena merasa sudah bayar mereka. Dan penyebab lainnya adalah keliru menunjuk developer yang ahli di dalam mengatasi permasalahan si klien.

Ingat, developer software di dunia ini banyak sekali, tetapi tidak semuanya ahli atau memahami permasalahan yang dihadapi si klien.

Klien yang awam yang mungkin bisa “dikibulin” developer, si developernya “menggampangkan” permasalahan, padahal ia tidak paham masalahnya. Nah, untuk mencegah hal kayak gini, kudu cari “penasehat” atau “konsultan” yang bisa menilai kemampuan para developer yang direkrut. Karena bisa jadi, developer yang direkrut dikira si klien memang memahami permasalahan, ternyata malah “penurut” dan tidak paham permasalahan sebenarnya. Tidak mampu memberikan “insight” yang tepat buat klien, dll. 

Atau, klien sebaiknya minta tim developer yang direkrut menunjukkan portofolionya, ceritakan portofolionya dan kalau sampai si klien berkata, “nah, ini masalaha saya, mas. Serupa yang pernah mas ceritakan dan mas kerjakan barusan”, berarti kemungkinan besar developer tersebut adalah orang yang tepat.

Dan perlu diperhatikan juga Kunci keberhasilan proyek itu adalah komunikasi, kolaborasi antar stakeholder (end-user, vendor, klien, dll) yang terlibat. Tidak bisa lepas tangan begitu saja, begitu menjelang deadline, baru perhatian dan kocar-kacir cari Superman.

Komunikasi efektifpun bukan komunikasi antara juragan dengan pembantu, atau master dengan slave, atau raja dengan prajurit, melainkan kerjasama, ya kerjasama, saling bekerja bersama-sama mencapai tujuan, menciptakan hubungan baik dan siap beradaptasi dengan segala kondisi atau kendala yang mungkin dihadapi di tengah tahap pengembangan berlangsung (yang sudah pasti tentu tidak slamanya berjalan mulus).

Jika mampu berkolaborasi asik seperti itu, tidak ada lagi masalah ditinggal kabur developer, salah nentuin, krn mesti akan ketahuan di awal.