Lesson Learned

Kali ini tentang Project Management. Ada sebuah dokumen yang ada dalam rangkaian fase dalam project management, ada 1 dokumen yang isinya memuat berbagai pelajaran yang dipetik dari pengerjaan suatu project yang disebut sebagai "Lesson Learned Report". Pelajaran itu bisa berupa pelajaran baik maupun yang buruk. Tujuan pembuatan dokumen adalah untuk pembelajaran, baik untuk project itu sendiri (andaikata belum selesai) maupun project-project lain yang akan dikerjakan.

Dari pengalaman pengerjaan di beberapa project, ternyata ada beberapa hal yang bisa di-share di sini. Mungkin rekan-rekan sekalian pernah mengalaminya, atau bahkan mengalami hal yang belum ada di sini. Ini hanya keinginan untuk men-share sebuah pengalaman dan pengamatan.

Dari beberapa pengamatan terhadap project yang ada, biasanya akan mengalami pemekaran scope project, requirement gathering yang tidak sempurna, serta development yang tidak/kurang memuaskan.

• Pemekaran scope project
• Pemekaran scope project ini biasanya terjadi karena kurangnya antisipasi tim project yang bersangkutan (tim yang dimaksud ini mencakup tim pemasaran hingga tim produksi) dan "terlalu percaya" pada fase yang namanya pre-assessment. Dari pengalaman di berbagai project, dapat disimpulkan bahwa apa yang dipromosikan dan diterima oleh (calon) klien pada saat pre-assessment atau pra-proyek itu sebenarnya masih jauh dari bayangan sebenarnya. Jadi jangan harapkan mendapat bayangan lebih dari separo ketika fase ini. Jika mempunyai produk dan memiliki kebijakan kustomisasi sekian persen (misal: 30% seperti di kantor saya) asumsikan saja ketika masa pre-assessment baru didapat 10% dari keinginan kustomisasi keseluruhannya, sehingga dengan asumsi seperti itu kita bisa membuat antisipasi yang lebih nyaman, misal dengan mematok harga lebih tinggi (tidak menetapkan margin yang mepet), atau mematok target waktu lebih panjang, dan juga membatasi request-request pada masa pre-assessment dengan asumsi bahwa di masa pengembangan pasti tetap ada request tambahan yang sulit untuk ditolak.
• Mengapa pre-assessment harus diasumsikan meleset jauh? Hal ini pertama disebabkan oleh terlalu sedikitnya waktu yang dipunyai oleh tim pada masa itu. Dalam waktu yang sedikit, tentu saja hampir tidak mungkin jika berharap hasil yang didapat akan banyak. Yang kedua, perlu diasumsikan bahwa klien tidak "siap setiap saat" untuk memberikan jawaban atas pertanyaan-pertanyaan kita maupun memberi feedback saat aplikasi yang kita bangun telah jadi atau setengah jadi. Bisa jadi mereka hanya akan siap pada saat-saat tertentu saja. Misal kita membangun sistem untuk pendaftaran ujian masuk PT secara online. Maka asumsikan saja klien akan mencermati hasil kerja yang kita bangun hanyalah pada masa-masa kelulusan SMA, karena pada saat itulah mereka memerlukan/memakai aplikasi kita. Di luar waktu tersebut, asumsikan saja feedback yang ada hanya mencerminkan 10% dari keseluruhan feedback.
• Lemahnya perjanjian maupun kesepakatan pada saat project belum deal, sehingga pada saat pengembangan para project manager beserta tim developer-nya tidak kuasa saat menghadapi request yang terus membengkak.
• Requirement Gathering (RG) yang tidak sempurna. RG merupakan hal yang sangat penting bagi pengembangan software. Kesalahan yang terjadi di fase ini akan berakibat pengembangan berikutnya akan salah semua. RG yang tidak sempurna ini bisa disebabkan karena berbagai faktor:
  
• Kualitas para system analyst (SA) yang belum sesuai dengan harapan. Untuk menganalisis sistem dengan baik memang tidak "sesederhana" fase konstruksi (coding). Coding saya sebut sebagai sederhana karena sesulit apapun di dalamnya, namun aspek yang dipikirkan hanya sampai pada level output yang sesuai dengan harapan, dan efektifitas coding itu sendiri. Sedangkan analysis harus mempertimbangkan aspek teknis (feasible atau tidak), kemudian berapa estimasi effort yang dibutuhkan untuk mengakomodir suatu request, kemudian kemungkinan pengembangan dari suatu request, dan bagaimana menyikapi kemungkinan pengembangan itu, dst. Semakin tinggi jam kerja seorang system analyst, maka akan semakin tajam juga kemampuannya.
• Selain kualitas, pengetahuan seorang SA terhadap aplikasi/program yang ditanganinya juga menjadi faktor penentu kualitas RG. RG untuk aplikasi yang sudah biasa ditangani akan lebih baik dibanding RG untuk aplikasi yang baru untuk dia, walaupun dia sudah diberi waktu dan tugas untuk mempelajari.
• Waktu/kesempatan untuk melakukan RG. Makin lama dan sering waktu/kesempatan untuk RG, maka akan semakin tajam dan bagus pula hasil analisa yang diperoleh. (RG sebagaimana fase development yang lain, bisa dan sangat baik jika diperlakukan secara iteratif). Dan ketidaksempurnaan RG ini, salah satunya adalah minimnya waktu dan kesempatan yang diberikan kepada SA untuk bereksplorasi di fase ini, karena biasanya titik perhatian adalah di fase konstruksi.
• Development yang kurang memuaskan.
• Fase ini biasanya jarang menjadi biang-keladi dari kegagalan dalam pengembangan project. Namun fase ini juga bisa menjadi salah satu faktor. Kondisi development yang kurang memuaskan ini --menilik dari pengalaman pribadi-- terjadi apabila developer ybs memang di bawah standar, atau bisa jadi karena beban kerjanya yang di atas rata-rata. Misalnya bekerja paralel untuk mengerjakan beberapa aplikasi. Paralelisme hanya akan efektif sampai batas tertentu, untuk kemudian akan menurunkan performa jika diperbanyak paralelnya.

Well, itu dari sisi teknis. Bagaimana dengan non-teknis? Beberapa pengalaman yang bisa di-share adalah:

• Komunikasi antara developer dengan klien. Semakin intensif komunikasi yang terjadi (dengan media apapun) maka pengembangan project akan semakin baik. Tentu saja mekanisme komunikasi ini perlu diformulakan dengan formulasi terbaik. Misal: kita tidak bisa memaksakan komunikasi dengan e-mail (yang relatif murah dan cukup praktis) sementara klien kita susah sekali untuk konek ke internet dengan berbagai alasannya. Itu tidak akan efektif.
• Klien yang kurang proaktif. Jika klien semakin proaktif, maka hasil yang diperoleh akan semakin baik, walaupun klien yang proaktif ini sering membuat kuping jadi panas hehehe. Namun jika klien tidak proaktif, akan mengakibatkan SA kita tidak bisa menganalisi sistem dengan sempurna, kemudian aplikasi kita tidak dapat dites dengan sempurna (sehebat-hebatnya aplikasi, pasti ada aja kekurangannya, dan sehebat-hebat tester di sisi developer, pasti akan tetap dibutuhkan tester di sisi klien/tester saat implementasi). --tentang aplikasi yang tidak ada yang sempurna ini, kalo mau mendebat saya silakan, kalo ada aplikasi yang "sempurna", ya pasti dia memang sudah mengalami penyempurnaan berkali-kali :p itu pendapat saya--
• Pelatihan aplikasi (pelatihan ini biasanya diperlukan agar para pengguna lebih mudah dalam masa transisi penggunaan program) sebaiknya tidak diletakkan di bagian yang sangat akhir. Memang pelatihan ini idealnya dilakukan setelah semua development selesai, namun biasanya event inilah yang menjadi gerbang terakhir datangnya change request dari klien. Nah, kalau ini diletakkan benar-benar di akhir, maka developer akan kehabisan waktu untuk memperbaiki program/aplikasi. Sehingga terpaksa dilakukan perpanjangan, padahal sebenarnya kita bisa mengakalinya dengan menempatkan pelatihan agak ke tengah waktu.
• Perlunya didapat kesepakatan tentang perbedaan "pelatihan" dan "pendampingan" dalam implementasi program/aplikasi karena 2 hal ini memang berbeda, dan "bagusnya" biasanya terjadi perbedaan persepsi antara developer dan klien terhadap 2 ini hehehe.
• Struktur organisasi pada klien maupun developer ternyata sangat mempengaruhi struktur organisasi pada proyek. Walaupun sering dibilang bahwa orang-orang pada proyek itu bertanggung jawab untuk proyek dan berbeda dengan tanggung jawab jabatan di instansi, namun tetap saja itu sangat berpengaruh pada kenyataannya. Dan itu perlu diwaspadai, terutama ketika terjadi mutasi jabatan, baik di sisi klien maupun developer.

Wew..... ternyata panjang juga hehehe. Yach, itu "sedikit" yang bisa saya share dalam kesempatan kali ini. Mungkin sedikit (atau malah banyak) meleset dari teori, karena memang tidak based-on-theory. Sekedar memperkaya pengalaman saja.