skip to content

Rankul - Project Management #1

Project Management Reading Material for Rankul.id

Ditulis oleh : Bondan R Santoso

Pertemuan Sebelumnya...

Project management secara umum dapat dibagi menjadi enam tahapan umum:

  1. Studi Kelayakan
  2. Analisis Kebutuhan
  3. Perancangan dan Desain
  4. Coding dan Unit Testing
  5. Integrasi dan System Testing
  6. Maintenance

Adapun dari tahapan tersebut, dapat diidentifikasi bahwa: tahap-tahap no. 1-3 termasuk dalam proses perencanaan proyek, no. 3-5 termasuk dalam proses implementasi, dan no. 6 Maintenance atau perawatan produk.

Perencanaan Proyek

Perencanaan proyek merupakan tahapan manajemen proyek yang bertujuan untuk mempelajari latar belakang, tujuan, dan batasan masalah proyek yang hendak dikerjakan. Apabila kita kembali ke enam poin manajemen proyek di atas, proses perencanaan proyek dapat dijelaskan seperti berikut:

Studi Kelayakan

Studi Kelayakan dilakukan untuk mempelajari latar belakang, tujuan umum, dan solusi-solusi umum yang mungkin dikerjakan. Pada tahap studi kelayakan, tugas seorang Project Manager adalah untuk mendeskripsikan alasan dan tujuan utama dilakukannya suatu proyek. Setelah alasan dan tujuan umum telah ditentukan, berbagai solusi yang dirasa dapat dilakukan untuk untuk mencapai tujuan kemudian dieksplorasi. Solusi-solusi tersebut kemudian dipertimbangkan kelayakannya berdasarkan pertimbangan seperti:

  1. Ketersediaan Anggaran
  2. Ketersediaan dan Kemampuan Sumber Daya Manusia
  3. Ketersediaan Peralatan, dan
  4. Keterbatasan Waktu

Latar belakang, tujuan, dan solusi-solusi yang telah dipertimbangkan dan disetujui pengerjaannya kemudian diteruskan ke tahap selanjutnya.

Analisis Kebutuhan

Analisis Kebutuhan merupakan tahap perencanaan proyek yang pokok bahasannya berupa kebutuhan-kebutuhan proyek aplikasi yang berupa:

  1. Use-case,
  2. Kebutuhan Fungsional, dan
  3. Kebutuhan Non-fungsional.

Use-Case

Use-Case merupakan kebutuhan proyek yang merupakan kasus-kasus atau skenario-skenario aplikasi yang akan disediakan oleh proyek software. Kalau kita ambil contoh kasus mesin ATM, mesin ATM memiliki beberapa use-case sebagai berikut:

  1. Penarikan Tunai
  2. Transfer antar rekening
  3. Transfer antar bank

Pada tahap analisis kebutuhan ini, 3 use-case di atas merupakan skenario-skenario yang harus dibuat atau disediakan oleh software yang hendak dibuat.

Kebutuhan Fungsional

Kebutuhan fungsional merupakan kebutuhan-kebutuhan yang akan mempengaruhi fungsi atau cara kerja program. Sebagai contoh kalau kita merujuk ke use-case no. 1 di atas, kebutuhan fungsional yang berkaitan dengan use-case Penarikan tunai adalah sebagai berikut:

  1. Pengguna ATM dapat memilih preset penarikan tunai dari Rp100.000, Rp300.000, Rp.750.000, dan Rp1.000.000
  2. Pengguna ATM dapat melakukan penarikan tunai untuk kelipatan Rp50.000
  3. Pengguna ATM harus memasukkan PIN sebelum mengkonfirmasi penarikan tunai

Kebutuhan Non-Fungsional

Kebutuhan non-fungsional merupakan kebutuhan-kebutuhan software yang tidak secara langsung mempengaruhi fungsi, cara kerja, atau interaksi pengguna dengan program. Sebagai contoh, kebutuhan non-fungsional untuk use-case no. 2 (transfer antar rekening) mungkin sebagai berikut:

Proses transfer harus selesai kurang kurang lebih selama 3-5 detik untuk koneksi jaringan dengan kecepatan 56Kbps

Perancangan dan Desain

Perancangan dan desain merupakan tahapan pada kerja proyek yang termasuk pada kategori perencanan maupun implementasi proyek, tergantung dengan metodologi atau model pengembangan yang digunakan. Pada model/metodologi pengembangan software seperti prototyping, perancangan dan desain (bahkan tahap coding untuk prototype) termasuk pada tahap perencanaan proyek. Adapun tahap perancangan/desain yang umumnya termasuk ke dalam tahap perencanaan adalah tahap perancangan sistem dengan flowmap atau UML.

Dokumen Perencanaan Proyek

Dokumen Perencanaan Proyek merupakan dokumen yang berisi/merangkum rencana proyek yang hendak dikerjakan, mulai dari latar belakang, tujuan, hingga scope dan vision. Ada beberapa gaya dokumen perencanaan proyek yang tersedia di lapangan, tergantung dengan kebutuhannya. Adapun tulisan ini hanya akan membahas isi dokumen perencanaan proyek secara teori, dan salah satu implementasi dokumen perencanaan proyek dalam bentuk Project Charter.

Isi Dokumen Perencanaan Proyek

Menurut Stellman dan Greene (2006) dalam bukunya, Applied Software Project Management, perencanaan proyek dapat didokumentasikan menggunakan Vision and Scope Document Dengan format sebagai berikut:

  1. Problem Statement a. Latar Belakang Proyek b. Stakeholders c. Users d. Risiko e. Asumsi
  2. Vision of The Solution a. Vision Statement b. Daftar Fitur c. Scope/Ruang Lingkup Rilis Bertahap (opsional) d. Fitur yang tidak akan dikerjakan

Adapun detail dari tiap-tiap bagian dokumen di atas adalah sebagai berikut:

Latar Belakang Proyek

Bagian ini berisi tentang rangkuman masalah yang hendak diselesaikan. Isinya menjelaskan bagaimana permasalahan ini mempengaruhi kerja perusahaan/organisasi yang bersangkutan, proyek apa saja yang pernah dilakukan untuk menyelesaikan permasalahan ini, dan keputusan apa yang menyebabkan diadakannya proyek ini.

Stakeholders

Stakeholders adalah pihak-pihak atau orang-orang yang pekerjaannya terpengaruh oleh proyek, contohnya: proyek "pembuatan aplikasi manajemen stok gudang" akan mempengaruhi pekerjaan/kinerja Pak Adam sebagai Manajer Logistik. Maka dari itu nama "Pak Adam" dan/atau nama jabatannya "Manajer Logistik" dapat ditulis di bagian Stakeholders, disertai dengan kebutuhannya yang dijelaskan dalam beberapa kalimat singkat, contohnya:

Adam, Manajer Logistik Manajer Logistik memerlukan adanya sistem notifikasi produk yang stok-nya kurang dari ambang batas bawah 5% dari stok normal.

Pengguna

Pengguna, sesuai namanya, berisi daftar pengguna yang akan menggunakan aplikasi atau sistem yang dikembangkan dalam proyek. Karena pekerjaan/kinerja pengguna akan terpengaruh dengan adanya proyek ini, secara tidak langsung pengguna merupakan stakeholders proyek. Namun karena pengguna akan berinteraksi langsung dengan software yang akan dibangun, tempatnya bisa dipisah dengan stakeholders biasa. Cara penulisan dan isinya sama dengan bagian stakeholders, nama dan/atau jabatannya disertai dengan kebutuhannya dalam beberapa kalimat singkat. Contohnya:

Reni, Staf Gudang

Aplikasi harus mendukung barcode scanner sebagai alat input untuk memudahkan proses pendataan produk.

Risiko

Bagian Risiko berisi daftar risiko atau skenario-skenario yang mungkin terjadi ketika melaksanakan kerja proyek. Risiko yang dimaksud dapat berasal dari dalam (risiko internal) maupun dari luar (risiko eksternal) dan meliputi skenario-skenario yang dapat (berpotensi) memperlambat proses kerja proyek. Idealnya pada bagian ini juga dicantumkan cara untuk menghindari risiko sebelum terjadi dan skenario yang akan dijalankan apabila risiko yang diantisipasi terjadi

Asumsi

Bagian Asumsi berisi asumsi-asumsi yang melandasi keputusan, keputusan tertentu. Adapun asumsi yang layak ditaruh pada dokumen perencanaan proyek adalah asumsi non-teknis yang dapat mempengaruhi scope atau ruang lingkup pekerjaan. Asumsi-asumsi teknis yang hanya akan mempengaruhi proses desain dan/atau implementasi namun tidak mempengaruhi scope tidak dimasukkan dalam dokumen ini. Contoh asumsi dan keputusan adalah "Apliksai manajemen gudang ini akan dibuat dengan inteface Bahasa Indonesia karena target pengguna semuanya berbahasa Indonesia". Tujuan ditulisnya asumsi adalah apabila di lapangan ditemukan adanya perubahan yang perlu terjadi karena asumsi awal tidak sesuai, seorang Project Manager dapat dengan mudah menentukan asumsi sumber permasalahan dan memudahkan komunikasi/negosiasi dengan klien/stakeholders.

Vision Statement

Vision Statement berisi tujuan atau poin-poin yang diharapkan dapat dicapai atau diselesaikan dengan dilakukannya suatu proyek. Isi vision statement harus jelas dan berisi alasan yang kuat untuk menggunakan sumber daya waktu, tenaga, maupun dana untuk melakukan suatu proyek.

Daftar Fitur

Bagian daftar fitur berisi fitur-fitur aplikasi yang hendak diwujudkan. Tergantung dengan kebutuhan dan ruang lingkup proyeknya, seorang Project Manager boleh menentukan jumlah fitur yang akan ditulis. Standarnya sekitar 10 fitur, tidak terlalu banyak sehingga mudah dibaca. Apabila fitur-fiturnya banyak dan kompleks, beberapa fitur-fitur yang terkait dapat disatukan menjadi satu fitur yang lebih umum.

Scope/Ruang Lingkup Rilis Bertahap (opsional)

Apabila software akan dirilis secara bertahap, sedikit demi sedikit, tambahkan bagian ini untuk menjelaskan rencana dan ruang lingkup software yang akan dirilis pada tahap ke-1, tahap ke-2, ..., hingga tahap ke-n. Bagian ini berguna apabila proyek yang dikerjakan besar dan rumit; menentukan deadline untuk software yang besar dan rumit untuk langsung rilis sebagai satu produk jadi seringkali tidak realistis, untuk itu umumnya proyek dibagi menjadi beberapa deadline rilis bertahap yang lebih sederhana. Untuk mengisi bagian ini seorang Project Manager harus berdiskusi dengan anggota tim-nya, karena tidak semua proyek dapat dengan mudah dibagi-bagi (kadang ada fitur-fitur yang saling terkait dan tidak terbayang oleh stakeholders dan project manager). Adapun apabila proses rilis bertahap ini telah disetujui, tim kerja proyek harus membuat estimasi/perkiraan kerja baru sesuai dengan kemampuan, prioritas kerja, dan tujuan organisasi stakeholders.

Fitur yang Tidak Akan Dikerjakan

Fitur-fitur yang dengan sengaja tidak akan dikerjakan harus ditulis di bagian ini sehingga pembaca memahami bahwa ada keputusan yang diambil, secara langsung/eksplisit, untuk tidak mengerjakan fitur ini. Bagian ini penting sehingga semua pihak memahami dan setuju atas pengecualian fitur-fitur yang ditulis dan alasannya.

Project Charter

Project Charter merupakan salah satu implementasi dokumen perencanaan proyek yang umum dibuat. Biasanya digunakan untuk mengajukan proyek yang akan dikerjakan kepada stakeholders. Format Project Charter adalah sebagai berikut:

[Nama Proyek]

  • Project name: [Nama Proyek]

  • Project manager: [Nama PM, misalnya John Doe]

  • Creation date: [tanggal pertama kali charter dibuat]

  • Last revision date: [tanggal revisi terakhir, misalnya 09 September 2022]

  • Project purpose statement: [Lihat latar belakang proyek]

  • Project objectives: [Lihat vision statement]

  • Client name/company: [Nama klien]

  • Client title: [Gelar klien, opsional]

  • Client email: [Email klien]

  • Client phone number: [nomor telepon klien]

  • Services: [layanan yang disediakan oleh tim, contoh: pembuatan aplikasi, konsultansi]

  • Project start date: [Tanggal mulai proyek]

  • Project end date: [Tanggal deadline proyek]

Project Scope

  • Deliverables:

    [Isi daftar aplikasi dan/atau daftar fitur aplikasi di sini]

  • Benefits

    [Isi manfaata yang diharapkan dari kerja proyek]

  • Requirements:

    [Isi daftar use-case, kebutuhan fungsional dan non-fungsional di sini]

  • Out-of-Scopes

    [berisi daftar fitur yang sengaja tidak dibuat/dikerjakan]

  • Assumptions

    [Diisi oleh asumsi proyek]

  • Constraints

    [Diisi keterbatasan kerja proyek]

  • Risks

    [Diisi risiko yang berpotensi terjadi]

  • Resources

    [Diisi sumber daya yang tersedia untuk kerja proyek, seperti dana/anggaran, SDM, dan alokasi waktu]

  • Project Teams

    [Diisi daftar pihak-pihak yang terlibat]

  • Stakeholders and Approvers

    [Diisi oleh daftar stakeholders dan pihak-pihak yang mengesahkan proyek]

  • Key dependencies

    [Diisi oleh ketergantungan atau kondisi yang harus dipenuhi untuk melaksanakan kerja proyek]

Appendix: Menentukan tujuan dengan SMART

Pada bahasan ini banyak pembahasan mengenai latar belakan dan tujuan, namun tujuan proyek tidak dapat secara sembarangan ditentukan. Tujuan proyek yang baik harus mengikuti pinsip SMART sebagai berikut:

  • Specific: Tujuan proyek harus spesifik dan jelas
  • Measurable: Tujuan terukur, dan mudah dievaluasi. Dapat berupa angka, persentase, atau tanggal tertentu
  • Achievable: Tujuan dapat dan sangat mungkin untuk dicapai
  • Realistic: Tujuan harus realistis dan masuk akal, bukan tujuan yang asal dapat dicapai tapi mengharuskan tim developer untuk kerja lembur 14 hari berturut-turut
  • Time-Bound: Tujuan harus terikat waktu, harus ada deadline yang jelas

Contoh tujuan tidak SMART: Meningkatkan penjualan sebanyak 120%

Contoh tujuan SMART: Meningkatkan repeat customer sebanyak 20% untuk 4 bulan terakhir tahun 2022 hingga 31 Desember 2022