Basic Project Management

Bismillah. Assalamu'alaikum.

Tulisan ini saya buat sebagai pegangan kepada para pemula. Jika saat ini kamu sedang atau akan mengerjakan project membuat aplikasi dari seorang client (product owner), kamu perlu membaca ini. Di akhir artikel saya sisipkan bab kendala-kendala teknis dan non-teknis yang sering ditemukan dalam membuat sebuah aplikasi.

Saya akan memfokuskan pada perangkat pendukung dalam mengatur project, yang memiliki 2 tujuan, yaitu:

  1. Perencanaan (Gantt Chart + Gitlab.com Issue Boards / Trello.com)
  2. Dokumentasi & Source Code (Gitlab.com)
  3. Pelaporan Progress Pekerjaan (Gantt Chart + Gitlab.com)

Perencanaan

Tahapan terpenting dari sebuah project adalah perencanaan. Dengan perencanaan yang matang dan detil, pengerjaan sebuah project dapat dikerjakan dengan terukur. Untuk membuat perencanaan, perangkat yang digunakan adalah perangkat implementasi Gantt Chart, berikut perangkat implementasi Gantt Chart:

ProjectLibre

Pencatatan pada aplikasi Gantt Chart memiliki keunggulan:

  • Mulai dan Akhir pekerjaan sebuah task
  • Alokasi waktu sumber daya manusia (SDM)
  • Perkiraan ongkos pembuatan sebuah aplikasi
  • Terukur

Setelah dokumentasi Gantt Chart selesai, langkah berikutnya adalah menuliskan pekerjaan task ke dalam perangkat pendukung yang lain. Ada 2 perangkat pendukung yang bisa digunakan, yaitu:

  • Gitlab.com (Gitlab)
  • Trello.com

Saya lebih suka Gitlab, terlebih lagi Gitlab memiliki fitur yang sama dengan Trello, yaitu Issue Boards.

Gitlab Issue Boards

Gitlab juga memiliki fitur-fitur yang lebih lengkap dan lebih siap untuk Project Management ketimbang trello, contohnya adalah Gitlab memiliki fitur Issue, Repository dan Wiki (Dokumentasi).

Kenapa tidak Github.com? Karena kita harus mengeluarkan uang ekstra untuk membuat repo private di Github.com. Berbeda dengan Gitlab yang menggratiskannya.

Sederhana menjadi keunggulan Trello, sehingga pihak product owner lebih mudah memantau progress pekerjaan di Trello.

Dokumentasi dan Source Code

Penggunaan Gitlab pada tahapan Perencanaan sejalan dengan bab ini, yaitu Dokumentasi dan Source Code.

Dokumentasi (Wiki)

Gitlab memiliki fitur Wiki yang bisa digunakan untuk membuat dokumentasi produk atau teknis (API), dokumentasi produk sebagai buku pegangan/panduan bagi para engineer dan QA untuk memahami produk yang ingin dibuat.

Semakin lengkap dokumentasi yang dibuat, semakin baik.

Issue

Setiap task yang dibuat pada Issue akan memilki keterkaitan dengan source code yang dibuat, contohnya adalah jika fitur login dicatat pada issue nomor 2, maka jika fitur login telah selesai dikerjakan, maka para engineer akan dengan mudah mengaitkan fitur login yang sudah selesai tadi dengan source code yang dimaksud dengan cara me-mention nomor issue pada commit message di Gitlab.

Tag

Jika aplikasi sudah siap untuk di-release, kamu memerlukan fitur Tag.

Tag berkaitan erat dengan versioning, penggunaan nomor versi pada sebuah aplikasi memudahkan engineer untuk memperbaiki sebuah issue, contohnya adalah jika ada laporan bug masuk dari user, kita bisa mulai dengan pertanyaan versi aplikasi yang digunakan oleh user tersebut, karena bisa jadi yang digunakan oleh user tersebut adalah aplikasi versi lama, sedangkan bug tersebut sudah diperbaiki padaa versi yang terbaru.

Kegunaan Tag berikutnya adalah, jika terjadi issue yagn bersifat critical/blocker pada versi terbaru yang ada di server production, maka insyaa Allah dengan cepat kita bisa memperbaikinya dengan menggunakan tag yang sebelumnya dan yang stabil untuk menggantikan sementara versi terbaru yang bermasalah.

Jika Anda belum pernah mempraktekannya, lakukan mulai sekarang juga! ;)

Pelaporan Progress Pekerjaan

Selama proses pengerjaan, kita memiliki tanggung jawab untuk melaporkan progress pekerjaan ke Product Owner.

Proses pelaporan bisa dilakukan seminggu sekali atau setiap akhir hari kerja, tergantung kesepakatan. Pelaporan status pekerjaan bisa dilakukan pada Gantt Chart.

Percent Work Complete

Kendala dan Solusi

1. Fitur Dadakan

Tidak bisa dipungkiri adanya fitur-fitur dadakan yang bermunculan selagi proses pengerjaan sebuah milestone.

Milestone adalah periode waktu sebuah project dengan sebuah pencapaian. Saya sarankan untuk membatas waktu setiap milestone tidak lebih dari 80 hari kerja, mulai dari proses product development sampai final release.

Fitur dadakan dapat merusakan proses berjalannya sebuah milestone.

Solusi

Jika fitur dadakan adalah minor, maksudnya tidak perlu banyak effort, bisa dikerjakan maksimal 3 hari, maka insyaa Allah tidak apa-apa. Namun jika major, Anda bisa menyampaikan ke product owner untuk fitur dadakan tersebut bisa dikerjakan pada milestone berikutnya, sampaikan dengan pertimbangan-pertimbangan teknis.

Jika product owner bersikeras ingin dimasukkan ke milestone yang sedang berjalan, maka Anda bisa melakukan negosiasi dengan menambah waktu produksi, walaupun saya tidak merekomendasikan ini. Atau mengganti fitur yang sudah direcanakan menjadi fitur dadakan, fitur yang diganti tadi dimasukkan ke milestone berikutnya.

Pada prakteknya semua disesuaikan dengan kondisi di lapangan. Pertimbangan-pertimbangan teknis perlu disampaikan ke product owner.

Perlunya membatasai periode milestone tidak terlalu lama karena pertimbangan faktor-faktor berikut:

  1. Kesehatan lifecycle pada lingkungan kerja
  2. Cepat mengeluarkan versi terbaru (Release Early, Fail Fast!)

2. Penambahan Waktu

Kadang-kadang atau bahkan sering software engineer mendapatkan kendala dalam proses pengerjaan sehingga memerlukan waktu tambahan agar bisa menyelesasikan pekerjaan tersebut. Yang mengerikan jika penambahannya memakan waktu lebih dari 20 hari.

Solusi

Segera adakan meeting koordinasi untuk mengerucutkan masalah, targetnya adalah fitur yang tertunda dapat diselesaikan dengan cepat. Lakukan komunikasi intensif mulai dari tim product development, system analyst, serta para engineer.

Semoga tulisan yang sedikit ini bermanfaat. Anda mungkin punya perangkat pendukung yang biasa digunakan, silakan sampaikan di kolom komentar di bawah.

© KLANJABRIK. Built using Pelican. Theme by Giulio Fidente on github.