Membudayakan IT Review di Indonesia
Pernahkah Anda mengalami masa-masa frustasi ketika sedang menjalankan sebuah proyek IT ataupun memimpin tim/organisasi IT? Frustasi itu bisa karena:
- sumber daya, baik itu anggaran yang tidak cukup, ataupun key user yang tidak available untuk grooming/requirement gathering,
- kurangnya dukungan dari atasan/leadership,
- banyaknya inisiatif yang berjalan pada saat yang sama sehingga anggota tim tidak fokus pada hal yang kritis,
- komunikasi yang sulit,
- Atau bisa juga, kegiatan berjalan tetapi terjadi stagnasi dimana pekerjaan hanya berputar-putar pada masalah yang sama, berulang, dan tidak ada peningkatan,
- Atau Anda menyadari sesuatu yang salah tetapi sulit mengurai atau menunjuk bagian mana yang harus diperbaiki atau mana dulu yang harus diprioritaskan dan caranya seperti apa.
Hal-hal semacam di atas sesuatu yang umum terjadi dan dialami oleh banyak perusahaan dari berbagai tingkatan, baik yang kecil atau pun besar. Dan dari sekian banyak resep, ada satu cara sederhana yang merupakan best practice tetapi masih jarang diadopsi di Indonesia. Yaitu IT Review, yang akan kita bahas saat ini.
Bagaimana IT Review membantu kita?
IT Review dapat membantu sebuah tim atau organisasi IT untuk mengetahui kekurangan dan kelemahan yang ada dan bagaimana untuk memperbaikinya. Kadang saat kita menjadi bagian dari tim, kita tidak bisa dengan jernih melihat masalah yang ada. Pandangan kita terlalu banyak terdisktraksi oleh gejala(symtopms), tetapi penyebab utamanya justru kita kurang bisa melihat dengan jelas.
Juga faktor obyektivitas, saat kita sendiri mencoba mengevaluasi, maka kita cenderung mewakili kepentingan kita sendiri. Padahal dari pihak counterpart mungkin juga mengalami tantangan yang berbeda saat mereka berkerja sama dengan kita.
Faktor obyektivitas, juga mengakibatkan suara kita tidak terdengar lantang dan jelas oleh manajemen. Hal berbeda jika pihak lain yang mengevaluasi dan menyampaikan.
Oleh karena itu bagi pimpinan tim atau organisasi, review bisa digunakan sebagai media atau sounding board, untuk menyampaikan concerns atau saran secara tidak langsung. Caranya? Temukan di bagian tips dan trick akan dibahas akhir artikel ini.
Apa bedanya dengan IT Audit?
Biasanya begitu terdengar kata review, yang terbayang dalam benak banyak orang adalah IT audit. Dan sebagian besar orang ketakutan terhadap kata audit ini. Memang keduanya sama-sama sebuah metode Quality Assurance, tetapi ada perbedaan dari keduanya. Daftar berikut menunjukkan perbedaan antara audit dan review.
Mengapa IT Review belum populer di Indonesia?
Jawaban utamanya adalah kedewasaan (maturity). Kedewasaan ini bisa berupa ukuran tim atau organisasi yang tidak memungkin terjadinya review bahkan jika itu sekedar peer review. Karena tidak adanya sumber daya manusia yang bisa melakukan review ini untuk organisasi yang kecil.
Namun begitu, ada juga perusahaan IT Indonesia yang sudah besar dengan terbagi atas berbagai divisi atau proyek tetapi belum mengadopsi IT Review ini. Tentunya ini terkait kedewasaan budaya/culture di dalam organisasi yang bersangkutan. Jadi seperti mahluk hidup, dewasa belum tentu dari ukuran/tinggi tubuh ya?
Kedewasaan juga bisa dari faktor pimpinan/leadership. Tim bisa jadi sudah besar, engineer-engineer-nya sudah paham perlunya IT Review, tetapi leadership belum buy-in terhadap konsep-konsep best practice seperti IT Review ini. Tentunya jawaban terhadap masalah maturity ini adalah edukasi sehingga organisasi mampu membuat IT Review sebagai budaya.
Kapan IT Review dilakukan?
Panduan yang ada biasanya terkait pada sebuah proyek. Project management Institute(pmi.org) setidaknya menyarankan siklus review sebagai berikut:
- Awal perencanaan proyek
Ini biasanya terjadi setelah proses initial scoping dilakukan dimana perencanaan proyek(implementation plan), strategi pengujian(testing strategy), deployment strategy, rencana sumber daya (resource plan) sudah ada. Selain menguji kesiapaan pelaksanaan proyek, reviewer bisa diminta melakukan verifikasi alignment dari harapan pihak stakeholder dan sponsor, dan menguji bahwa tujuan proyek akan sesuai dengan misi, visi, dan strategi perusahaan ke depan. Jika ternyata tujuan sebuah proyek tidak sejalan, tentu lebih baik jika anggaran yang ada dialihkan ke keperluan yang lebih prioritas, bukan?
2. Ketika project berjalan (interim review)
Saat project berjalan, bisa juga dilakukan review. Yang sering adalah menjelang Go Live atau disebut pre-deployment review. Tujuanya adalah memberikan assurance bahwa organisasi telah siap dengan perubahan yang dibawa oleh proyek. Baik itu sebuah aplikasi baru atau sebuah penaik-tarafan(upgrade). Yang menjadi poin atau area dari review adalah hasil user acceptance test dan kecukupan skenario-nya, kesiapan cut over plan, user training, kesiapan post-GoLive support, dan lain-lain.
3. Ketika proyek berakhir
Setelah proyek selesai dan terjadi hand over ke tim support, biasanya diadakan sebuah review yang sering disebut post implementation review. Tujuan dari review ini adalah melakukan kilas balik terhadap apa yang baik dan apa yang bisa diperbaiki atau ditingkatkan. Juga utamanya adalah mengukur apakah proyek sudah mencapai tujuan awalnya baik men-deliver aplikasi yang pada ujungnya membuat organisasi atau perusahaan semakin dekat kepada visi, misi, dan strategi nya.
Apa tahap-tahap sebuah review?
Tahap-tahap sebuah review cukup sederhana kok:
a. Pembuatan Term Of Reference(TOR)
Term of Reference(TOR) ini semacam proposal yang berisi tujuan, ruang lingkup, kapan pelaksanaan, dan siapa yang akan melakukan. Di sinilah pentingnya mengarahkan reviewers untuk memeriksa area-area yang menjadi pokok masalah atau concerns.
b. Kick Off
Sebaiknya pelaksanaan review diawali dengan rapat singkat untuk kick-off. Di dalam rapat kick off, sponsor, para interviewers, dan interviewees sebaiknya diundang. Selain perkenalan, juga penjelasan akan adanya review, tujuan, dan permintaan agar meluangkan waktu untuk pelaksanaan review. Walau nampak sederhana, percayalah, bahwa kickoff akan membantu mengikis resistensi saat Anda bertanya, meminta akses, dokumentasi, dan evidence lainnya.
c. Sesi wawancara
Dari daftar area/divisi bisa dijadwalkan wawancara terpisah sehingga bisa fokus di topik. Sebaiknya dari setiap wawancara ada seseorang yang bertugas mencatat. Pada saat wawancara, bisa juga diminta untuk menampilkan demo terhadap aplikasi yang dipakai atau proses yang dilakukan jika kebetulan membahas topik proses bisnis.
d. Studi hasil wawancara, dokumentasi, source code review, arsitektur sistem maupun arsitektur solusi, dll.
Pada tahap ini reviewers bisa melakukan studi terhadap berbagai hasil wawancara, dokumentasi yang didapat. Juga melakukan check bukti-bukti baik di JIRA/Confluence, ataupun checking langsung ke AWS/Google Cloud untuk melihat arsitektur maupun praktek devops yang dilakukan.
e. Pembuatan laporan
Laporan biasanya merupakan kesimpulan dari observasi yang telah dilakukan. Kesimpulan observasi tentunya terbagi atas area-area yang diminta di dalam Term of Reference. Utamanya adalah bagian terakhir yaitu rekomendasi yang perlu dilakukan untuk perbaikan kedepannya.
Tip & Trick
Pada cerita di atas telah disebutkan tentang manfaat review sebagai sounding board. Tentunya apabila Anda seorang manajer IT, manajer proyek, atau bahkan pimpinan dari sebuah perusahaan rintisan, bisa meminta sebuah adhoc review kapan pun dirasa perlu. Pada titik tersebut, Anda boleh jadi merasa perlu melakukan check up terhadap kesehatan proyek atau organisasi yang Anda pimpin. Seperti layaknya seorang pasien yang membutuhkan general/medical checkup.
Maka yang perlu Anda lakukan adalah menuliskan Term of Reference(TOR). Tuliskan tujuan dan di bagian ruang lingkup masukkan area-area yang perlu untuk dievaluasi. Terutama di bagian-bagian yang memang ada concerns.
Selanjutnya review akan berjalan menguak tabir masalah yang dihadapi. Dalam interview, hal-hal yang menjadi kendala akan jadi topik pembahasan dan Anda bisa menyampaikan keluhan/concerns Anda punya saat giliran Anda di-interview. Reviewers akan melakukan cross check dari hasil interview dengan Anda untuk ditanyakan ke stake holder yang lain. Secara tidak langsung, reviewers melakukan validasi untuk Anda.
Dan hasilnya bisa diharap obyektif dan akan disampaikan ke atasan Anda melalui laporan yang dihasilkan. Kehadiran pihak ketiga dalam review biasanya akan menarik perhatian lebih dari stake holder ataupun pimpinan/leadership. Sehingga concerns Anda bisa tersampaikan dengan lebih jelas.
Terakhir, sebagai pesan sponsor, Hyperjump saat ini memiliki jasa Technical Due Diligence yang semula merupakan jasa technical assessment untuk Venture Capital yang hendak melakukan investasi di sebuah perusahaan rintisan. Saat ini kami telah membantu banyak perusahaan dalam me-review bagian IT engineering mereka untuk mengetahui seberapa jauh implementasi Software Development Life Cycle(SDLC) mereka dibandingkan standard/best practice baik itu agile maupun waterfall. Sejauh ini kami sudah terbukti dapat membantu menemukan area of improvement dalam rekomendasi-rekomendasi kami. Rekomendasi tersebut ada yang ditindaklanjuti dalam proyek selanjutnya baik dalam kerangka CTO-as-A-Service ataupun digunakan sebagai masukan untuk ditindak lanjuti secara internal.
Daftar referensi:
- “Best practices — project review process”, PMI.org,https://www.pmi.org/learning/library/best-practices-create-project-office-491
- “Difference Between Audit and Review (With Table)”,askanydifference.com,https://askanydifference.com/difference-between-audit-and-review/
