I hate all software project management

I hate all software project management

Because all I want is building software 7 min read

Sebenernya gue bukan tipe orang yang suka mengatur apa yang gue lakukan. Misalnya, bila gue ingin membuat sebuah aplikasi untuk tracking dosa-dosa gue, gue gak bakal menulisnya di sebuah catatan misalnya. Yang gue lakukan adalah yaa memulai nulis kode.

Karena kalau gak langsung gue mulai, ujung-ujungnya ya bakal terbengkalai :)

Sayangnya, sekarang gue ingin mencoba untuk tidak sendirian memulai sebuah project. Gue bisa aja desain UI sendiri, desain database sendiri, buat API sendiri, frontend sendiri, fucking fullstack gitu lah. Tapi tujuan gue bukan itu, you know the quote like this:

"If you want to walk fast, walk alone. If you want to walk far, walk together."

––Anonim

Dan ya, itu bener banget. Banyak banget project yang ingin gue buat, bersama, sekitar 5 an.

Tapi gue bingung mau ngaturnya gimana. GitHub ada built-in project management, but it sucks.

Alternatif Lain

Gue dapet alternatif lain seperti Zenhub, Wricker, Taiga, Trello, dsb. Tapi enggak cocok dengan workflow dan selera gue. Dulu yang paling cocok adalah Jira, tapi berbayar sekitar $10/bulan. Bisa aja gue bayar, tapi untuk organisasi yang bahkan belum menghasilkan apapun/sepeserpun?

Redmine

Ini alternatif lain yang paling cocok menurut gue. Self-hosted lagi. Ngeliat interface dan fungsionalitasnya, cocok lah sama gue. Gue coba deploy lah ke server gue sendiri, dan disini gue bencinya. Redmine ini dibuat menggunakan Ruby On Rails, bahasa program Ruby, dan entah kenapa gue selalu benci dengan Ruby.

Atau, lebih spesifiknya, gue benci dengan Bundler.

Lebih dari 4x gue coba deployment ke server gue, dari via manual git clone, sampai automation via docker. Dan akar permasalahannya disini adalah di Bundler nya tersebut.

Pertama, gue coba gak bawa Gemfile.lock. Local works, server kagak. Katanya butuh file Gemfile.lock. Terus, gue coba lah bawa Gemfile.lock tersebut, error beda. Harus pakai Bundler versi 2.x katanya.

Oke, gue coba pakai Bundler versi 2.x, error lagi. Katanya untuk pakai Bundler versi 2.x, gue harus pakai Ruby versi yang bodo amat gue udah lupa. Bisa aja gue pakai cara kotor, ssh ke server, clone sendiri, install Ruby pakai Rvm/rbenv, install bundler entah versi berapa, bundle install, rake, dsb.

But hey.

Server gue gak cuma diisi bahasa Ruby yes. Udah gue coba via isolated pakai Docker, tetep aja permasalahannya disitu.

Coba di lingkungan Node.js. Spesifik versi node via engine di package.json bila perlu, install dependencies, lalu terbuatlah file yarn.lock atau package-lock.json yang just it works. Enggak pernah ada masalah ketika gue eksekusi yarn atau npm ci sebelum project ke fase build. Sekali lagi, it just works.

(Software) Project Management yang gue impikan

Hemat gue, ketika kita membuat project software, hanya ada 7 tipe "task" yang terjadi:

  • (Buat) fitur
  • (Fix) bug
  • (Menulis/mengubah) dokumentasi
  • (Melakukan) refactor
  • (Meningkatkan) performa
  • (Menulis) test (yang belum dibuat)
  • (Melakukan) pekerjaan-pekerjaan rumah (yang biasanya di level infra)

Atau yang lebih generalnya, ber-label:

  • Bug
  • Feature Request
  • Enhancement (refactor, performa)
  • Task (menulis test, pr)

That's it, right? Atau yang bisa lebih general:

Oke, itu tipe task ya. Yang berkaitan dengan project, gue mungkin hanya butuh ini:

  • Judul
  • Deskripsi
  • Status: Todo, In progress, In/Need Review, Deployed, Released (Atau langsung release aja)
  • Prioritas: Low, Medium, High?
  • Timestamp (dibuat & terakhir diupdate)
  • Penanggung jawab: Siapa yang ngehandle task tersebut
  • Pelapor: Siapa yang ngelaporin task tersebut
  • Jenis Product/Software
  • Component (bila product/software tersebut sangat besar & kompleks)
  • Versi (bila memelihara lebih dari 1 versi: canary, beta, etc)
  • Votes. Berguna untuk prioritas/feature request

Mari gue buat contoh. Gue ingin membuat sebuah aplikasi blogging, yang mana fitur utama nya pastinya bisa menerbitkan tulisan. Berarti, gambaran tasknya adalah seperti ini:

Title: Publish post from user input
Reporter: Fariz Rizaldy
Status: TODO
Priority: High
Created at: 11 May 2019 06:50 WIB
Updated at: -
Assignee: -
Product: Blog
Component: (Backend) Post
Version: 0.1.0

Votes: 1

Description:

As a user, I want to publish what I've write so people
on internet can read what I've written.

Agar lebih lengkap, bisa ditambahkan dengan:

  • Effort (Beda dengan priority, ini lebih ke "beban kerja")
  • Milestone (Versi "lebih kecil" dari version)
  • Due Date (Deadline, you know. Ehm, estimasi)
  • Time Tracker. Sudah berapa jam task ini dikerjakan?

Poin-poin diatas berguna untuk Velocity dan Retrospective kalau bahasa agile nya.

Prinsip

Selain fungsionalitas inti yang gue sebutkan diatas, untuk project management ini ada beberapa prinsip yang harus terpenuhi agar bisa "At least, it perfect for me".

Distraction-less

Sengaja gue taro di poin awal, yang berarti: Kalo poin ini enggak terpenuhi, berarti semua nya gak terpenuhi. No excuse. Tujuannya: Untuk fokus. Agar fokus, berarti kita harus "memusatkan perhatian kita kepada satu perhatian", yang berarti: Do one thing.

Implementasinya, di UI, mungkin hanya memiliki 1 layout. 1 Kolom. Lihat gambar diatas, ada 2 kolom kan? Kolom kiri adalah bagian inti, dan kolom kanan adalah bagian "extra".

Bagian kanan membuat gue "terdistraksi", karena ya, link "View All Issues", "Summary", dan "DevelopersMeeting" membuat gue tertarik untuk mengklik nya.

Simple

Salah satu faktor yang mendukung untuk mendukung gue untuk bisa fokus adalah UI yang simple. Less all that fancy and shit UI. Because, you know, we are programmer.

Semakin banyak pilihan, semakin banyak pula peluang gue untuk terdistraksi (Look at that sidebar and New Issue button!). Dan yes, I hate that kanban board.

Ini yang terjadi ketika gue melihat "detail" dari task yang ada.

Fancy enough. But, I have no idea.

Keyboard-friendly

Dan, harus intuitif. Seperti, untuk melakukan "pencarian" di Vim, kita menggunakan "shortcut" /, maka di aplikasi pun harus seperti itu. Sisanya, yaa sesuai intuisi kita aja. Seperti, n untuk membuat "issue" baru misalnya, c untuk membuat komentar, dsb.

Dan harus aksesibel. Tab harus berfungsi. Aksesibilitas bukan hanya untuk maaf, orang-orang yang memiliki kelebihan. Developer pun––yang notabene nya malas––harus mendapatkan keuntungan tersebut.

Juga, kita bisa "merefactor" UI konvensional yang ada. Shortcut n dan klik tombol "New Issue" sama-sama melakukan fungsi yang sama, so, you know the answer.

Great UX

Seharusnya, karena simple, harusnya memiliki pengalaman pengguna yang keren! Ambil contoh, detail task diatas yang berbentuk modal, ada berapa "PR" yang sekiranya harus kita fikirkan?

  • Apakah ketika klik "backdrop" harus close modal, atau enggak?
  • Handle transisi ketika muncul modal agar tidak glitch
  • Atur persistensi input ketika user "gak sengaja" klik backdrop dan modal menghilang

Pokoknya banyak deh. Belum disisi teknikal seperti ngatur z-index, transisi, persistensi input, dsb.

Salah satu faktor "Great UX" menurut gue adalah di latensi. Latensi sangat sangat berpengaruh terhadap pengalaman pengguna, khususnya di fokus. Bayangkan fokus kita "buyar" karena menunggu halaman selesai diload.

Eh udah lama-lama nunggu malah muncul error 500. Fuck you-able banget, kan?

Works offline

Kebanyakan, aplikasi web sekarang enggak mendukung offline. Karena, jarang banget yang menggunakan mindset "offline-first". Coba ketika kalian develop web app yang baru, apa faktor utama yang kalian andalkan?

Yes, API Endpoint.

Your web app is nothing without that. Karena pada dasarnya, desain dari web app kita yaa sebagaimana "data" yang kita peroleh dari server.

Sedangkan, ide itu bisa datang kapan saja. Enggak mengenal waktu, tempat, apalagi koneksi internet. Otak bukan tempat untuk mengumpulkan ide, kita harus cepat menuangkan ide kita dimanapun selain di otak. Baik ide untuk fitur baru, refactor, fix bug, whatever.

Entah ide tersebut akan dieksekusi atau tidak, yang penting ide tersebut tidak hanya "sebatas lewat". Kesempatan tidak datang dua kali, right?

Integrate well

Infrastruktur kita bergantung pada pihak ketiga Zeit Now atau Netlify. Bahkan, mungkin di level CI seperti Travis dan whatever lah lieur.

Code kita, disimpan di remote repository. Agar proses kolaborasi menjadi lebih mudah. Karena menggunakan layanan pihak ketiga, seharusnya, aplikasi ini bisa terintegrasi dengan baik.

Feature request? Create PR. Push dengan commit message feat: done #{some issue id}, ubah task menjadi "In Review".

Fix bug? Create PR, run test on CI, ubah task menjadi "Done" ketika testing kita pass.

Kenapa tidak ada fitur Code Review di aplikasi ini? Karena aplikasi ini khusus untuk Project Management aja. Gak perlu dukung fitur "Repository Hosting" disini. Rata-rata juga repository hosting yang ada ngedukung "Webhook", kan?

Responsive. Great Performance. Secure. Open Source.

Gak perlu dijelasin panjang lebar, sudah ada dalam DNS DNA kita.


Ide ini muncul ketika gue nge-tweet ini:

Setelah frustasi dengan Trello, Zenhub, dan Redmine namun terlalu miskin untuk sewa Jira/Planio/Basecamp.

Sayangnya, belum ada aplikasi serupa yang sesuai dengan apa yang gue bayangkan tersebut. Jadi, mungkin gue akan bikin sendiri, karena enggak mungkin gue harus nunggu orang buat seperti itu, karena ini menjadi bottleneck akan project-project gue yang ada.

Dan ya, Open Source. Gratis. Harusnya mudah untuk di-instalasi dan digunakan. Ngapain bikin software yang susah di instalasi hanya untuk uang nah?

Feedback is (always) welcome

Bagaimana menurutmu? Apa yang kamu fikirkan tentang Project Management impian ku (sebagai developer yang ingin membuat software) tersebut? Oke oke mungkin gue bisa aja buat di Post-it atau tulis di kertas, lalu heloooo yakali gue fotoin satu-satu, share ke grup, ada update, gitu lagi gitu terus yang gue lakuin?

Ingin kolaborasi? Tertarik ikut andil dalam membuat ini? Ingin mempelajari hal baru (yang mungkin belum terlalu familiar dengan konsep diatas)? Welcome! Kontak aku di Telegram (iya euy gue ganti username telegram demi bucin), dan kasih tau gue bagian mana yang buat lo tertarik (tentang konsep diatas) dan berikut bagian teknikal lo nya juga.

Deadline Estimasi minimal H-7 lebaran. MINIMAL. Move slow, break things. Itung-itung ngabuburitnya ngoding yah (dari jam 5 shubuh - 5 sore. Kidding).

Yes, this is Open Source project. Impress your techy bf/gf with your contribution graph.

SPOILER: Some techs key probably we will face:

  • Node.js
  • Express
  • JWT
  • React
  • PouchDB
  • serviceWorker
  • (Bare) CSS In JS
  • ...More