Quality, Time, dan Scope

Sebuah perusahaan berbasis teknologi lahir dari ide bisnis yang diwujudkan menjadi produk dan disokong dengan teknologi. Tentunya dalam ekspansi bisnisnya bakal lahir project - project untuk pengembangan produk yang dalam prosesnya bakal melibatkan banyak orang. Pelajaran berharga yang saya dapatkan setelah menjadi bagian didalam berbagai macam project adalah pentingnya memperhitungkan faktor quality, time, dan scope atau QTS didalam sebuah project.

Project yang sehat mempertimbangkan QTS pada pelaksanaannya. Setiap kita mengerjakan project kita hanya bisa memilih untuk fokus pada 2 faktor saja. Jika memilih untuk fokus pada time dan scope, maka quality harus kita korbankan yang berarti more bugs dan sebagainya. Jika kita memilih untuk fokus pada quality dan time, maka scopenya harus kita kecilkan yang berarti fitur - fitur yang dikerjakan harus dikurangi. Jika kita memilih untuk fokus pada quality dan scope, maka time(waktu) pengerjaannya tidak bisa cepat.

QTS yang tidak terkontrol akan menyebabkan segalanya menjadi tidak terukur seperti deadline yang tidak masuk akal dan ekspektasi hasil yang berlebihan. Efeknya adalah orang - orang yang terlibat di project itu akan kelelahan dan kemudian burnout. Fase seseorang yang burnout adalah denial, acceptance, dan ignorance. Hal terburuk yang bisa terjadi adalah orang tersebut resign. Pada tim development yang strukturnya masih kecil dampak jangka panjangnya akan sangat buruk sekali karena orang yang burnout tidak akan bersemangat dalam mengerjakan suatu task dan orang yang resign akan melimpahkan tasknya kepada anggota timnya yang lain. Belum lagi jika knowledgebase management perusahaan itu buruk yang terjadi adalah orang tersebut pergi sambil membawa knowledge yang hanya dia yang paham.

Setiap perusahaan pasti ingin mencapai sustainable business tapi untuk mendukung itu diperlukan sustainable people. Tidak ada ekspansi bisnis atau pengembangan fitur jika orang - orang untuk mengembangkannya sudah tidak ada dan biasanya perusahaan menyadarinya disaat semua sudah terlambat. Disinilah pentingnya struktur kontrol. Harus ada kerangka kerja yang disepakati bersama untuk mengontrol QTS ini. Pada beberapa startup misalnya, mereka menggunakan Scrum sebagai struktur kontrolnya. Sprint planning, Daily Meeting, Sprint Review, dan Retrospective adalah media yang ada pada kerangka kerja Scrum untuk memfasilitasi QTS ini. Retrospective misalnya, di fase ini setiap anggota tim bebas mengeluarkan keluhannya untuk kemudian dijadikan bahan pembelajaran agar sprint berikutnya bisa lebih baik.

Kuncinya adalah kompromi. Semua orang yang terlibat di rantai pengambilan keputusan pengembangan produk harus memahami arti dari QTS ini. Ketika disuatu project yang fokusnya adalah time dan scope maka semua pihak harus kompromi dengan quality, jangan mengharapkan the best experience ketika sudah kompromi dengan quality. Semua pendapat wajib didengar dan konsekuensi pengambilan keputusan harus ditanggung bersama.