Mencari Titik Keseimbangan dalam Proyek

Ardi
Impruvia
Published in
3 min readOct 23, 2022
Inilah Constraint Triangle

Saat belajar Project Management, saya berkenalan dengan yang namanya Iron Triangle atau Constraint Triangle. Triangle ini seperti hal yang natural, hal yang umum kita temui dalam kehidupan sehari-hari. Memahami batasan dalam Constraint Triangle ini bisa membuat kita lebih bijak mengambil keputusan dalam pengembangan produk atau proyek.

Ada tiga sisi dalam triangle ini, yaitu:

  • Scope: Scope: tentang requirements atau kebutuhan yang perlu hadir dalam produk. Kita seringkali merepresentasikan scope dalam fitur atau fungsionalitas
  • Cost atau Budget: dana yang tersedia untuk mengembangkan produk. Dana ini biasanya dikeluarkan sebagai pembayaran tim pengembangan, pembelian alat bantu hingga lisensi perangkat lunak, dan penyewaan server
  • Time: waktu yang diperlukan untuk men-deliver sekumpulan fitur atau fungsionalitas

Tiga sisi dalam triangle di atas terasa berkaitan satu sama lain. Jika kamu pernah menyusun rencana pengembangan, kamu mungkin pernah membuat sekumpulan item yang menggambarkan deskripsi fitur. Kamu membuat fitur A, fitur B, fitur C, dst. Kamu juga mempertimbangkan aspek non-functional-nya seperti keamanan (security), kecepatan (performance), dan kemudahan dipelihara (maintainability).

Jika kamu sudah melihat atau merasakan seberapa besar sistem atau produk yang ingin dikembangkan, kamu perlu menentukan jumlah orang yang terlibat dalam pengembangan. Jumlah orang ini akan menentukan berapa lama scope yang sudah didefinisikan akan diimplementasikan dan di-deliver. Makin banyak orang terlibat, budget yang perlu dialokasikan tentu akan semakin besar.

Mencari Keseimbangan

Mari kita lihat beberapa skenario yang umum terjadi sehari-hari.

Klien kamu memutuskan bahwa produk perlu rilis cepat di momen penting, misalnya saat hari pahlawan. Berarti faktor time tidak bisa diganggu gugat alias fixed. Kita perlu fleksibel di faktor lain. Kita mungkin perlu developer lebih banyak (meningkatkan budget) atau mengurangi scope dari fitur ynag ingin di-deliver.

Bagaimana jika budget untuk pengembangan terbatas? Ini berarti budget adalah faktor yang fixed. Mari fleksibel di faktor lain. Kamu bisa berdiskusi dengan klien kamu untuk untuk mengurangi scope dari fitur atau rilis fitur dengan waktu yang relatif lebih lama. Opsi lainnya adalah menyusun prioritas fitur. Fitur dengan prioritas tinggi ditandai sebagai fitur yang akan dirilis terlebih dahulu. Fitur dengan prioritas rendah akan ditunda atau dirilis belakangan.

Ingin rilis cepat dengan fitur yang banyak namun budget seminimal mungkin? Mmm ini lumayan sulit. Hal ini memungkinkan dilakukan tapi seringkali kualitas (quality) yang jadi korbannya. Kualitas produk menjadi rendah dan biaya perbaikan kedepannya akan mahal.

Dampak lainnya adalah seringkali tim pengembang menjadi tidak nyaman dan kurang puas dalam bekerja karena mereka membangun produk secara tergesa-gesa dan akhirnya hanya untuk memperoleh produk berkualitas rendah. Sebaiknya lakukan negosiasi ke stakeholder jika kita menemui situasi ini.

Penutup

Dari iron triangle ini, kita belajar bahwa kita perlu mencari titik keseimbangan. Umumnya kita maupun stakeholder seringkali melihat tiga faktor scope, budget, dan time. Namun jangan lupakan faktor quality. Dalam keseharian, diskusikan faktor yang paling penting buat kita atau stakeholder (itulah faktor fixed), kemudian fleksibel-lah minimal di satu faktor lainnya. Dengan ini, kesuksesan pengembangan menjadi lebih mudah dicapai.

--

--

Ardi
Impruvia

Sharing my learning and experience in product management and software process like Scrum. Sometimes inspiration from life