Expectation

Bicara espekasi, ga ada yang mudah. Tiap orang punya espektasi berbeda, yang bikin makin rumit itu ada juga yang tidak bisa mengungkapkan espektasinya, atau bahkan tidak sesuai apa yang dimaksud. Jadinya malah miss communication dan pusing semua.

Biar lebih teknis, gw coba cerita pengalaman dulu waktu di perusahaan sebelumnya, di sebuah Bank.
Standard documentation dan IT Governance bank itu menggunakan standard CMMI, saking ribetnya dan rumitnya serta ngeselinnya, gw selalu bilang ini CUMI2 - kebawa sampe sekarang. Setiap ada apapun di project atau operation, bejibun document harus disiapkan. Istilahnya, benerin bugs 1 menit, prepare document bisa 3 hari, approval 2 hari, itupun kalau lancar.
Si CUMI2 belum berhenti di situ aja, 3 hari document dan 2 hari approval, itu baru melibatkan 1 direktorat. Dulu aplikasi yang gw handle Internet Banking, minimal harus ada keterlibatan 5 direktorat MINIMAL, IT Regional Transaction Banking Center of Exellence (RTB COE) - team gw dulu, IT Testing Management Division, IT Relationship Management, IT Release Management, IT Change Management, IT Security, IT Data Center, belum lagi kalau error atau perubahan melibatkan It Operation lainnya, misalnya Trade Finance, FSC, etc. Karena dulu handle team Regional (ID, MY, TH, SG), untuk major release mesti lapor dulu ke Regional.

Bos Bisnis, simple sekali, call gw di hari Rabu "Win, Jumat aman kan promote?".

Kan kampret...

Espektasi team Bisnis mau jalan buru2 - secepat mungkin. Espektasi IT gmana biar promote tidak error dan aman tentram. Espektasi team gw : tidur nyenyak. Espektasi Vendor : Dapet senyum yang manis dari gw.
Kan ga sama semua ini espektasi orang-orang.

Apa yang gw lakukan dulu ?

Cek impact analysis
Kondisi pertama : Major release atau impact ke banyak module.
Ini gw akan sounding jauh-jauh hari ke semua stakeholder, team bisnis, team vendor, team regional, team IT Operation. Kalau ini major release, dan team RTB CEO dkk butuh waktu lama untuk pengerjaan dan koordinasi dengan pihak terkait. Waktu lama yang dimaksud ada ukurannya, dan ada due date yang final. Phase komunikasi ini selain dari team gw yang tiap hari bawelin semua orang, juga melibatkan team IT Relationship management, agar jadi corong komunikasi. Ada kemungkinan mundur dari timeline, call semua orang untuk meeting. Bikin MOM, kirim MOM ke semua pihak.
Hal teknis kedua yang dilakukan, list down semua impact dari sisi code dan features lain, mesti sangat hati-hati untuk hal ini. Major release pasti ada impact dari sisi bisnis, antara team bisnis create module jualan baru untuk boosting ke market etc. Jadi analisa yang yang baik menentukan semuanya. Prefer 2-3 hari analisa mendalam, daripada buru-buru dan salah. Salah langkah disini, DEAD.
Langkah teknis ketiga, testing dan quality control yang bener, berdasarkan document impact analysis. Inilah kunci kerja sama antara Tech Lead dan QA, harus bisa fluid kerja nya di sini - dan rapi + teliti.
Langkah teknis keempat, koordinasi dengan semua team lain. Prepare semua hal, kadang bantuin yang bukan tanggung jawab kita, dengan batasan memang kita sanggup dan bukan malah bikin kerja yang tanggung jawab kita malah berantakan. Misalnya, dulu gw dan team prepare semua Test Plan dan Test Script untuk team IT TMD, siapin semua document peer review untuk team IT RM, etc, jadi mereka tinggal follow up approval tanda tangan aja.

Kondisi kedua : medium atau minor release.
Dari sisi impact bisa ketaker. Namun untuk kondisi kedua ini yang paling sering bikin kesalahan. Biasalah, manusia suka JUMAWA (cek di KBBI, apa arti kata ini). Karena ini hal yang medium dan minor, biasanya suka meremehkan. "Ah simple itu"/ atau "Cuma itu ada perubahannya" atau "Ga impact mana2 kok" atau "1 jam kelar". Ingat, kesombongan itu yang bikin kacau hidup.
Step-nya mirip dengan kondisi pertama, cuma timeline lebih pendek dan ketat. Di sini yang gw lakukan dulu, jangan terlalu banyak melibatkan jumlah team. 2 atau maksimal 3 orang dalam satu team cukup untuk handle release ini, jadi bisa ditaker dan responsibility jelas. Dan kalau memang miss waktu promote, teriak dan ngomel2nya cukup ke 3 orang aja maksimal.

Komunikasi
Di bank tempat gw kerja dulu, karena menerapkan CUMI2, tiap hari kamis itu ada namanya CCF Review. Ini semua group head IT dikumpulkan dalam satu ruangan, kerjaan mereka cuma satu, jadi PENJAGA GAWANG semua untuk promote di hari Jumat-nya. Harus lewat sidang mereka dulu, semua hal mereka tanya-tanya, dari hal teknis dan hal bisnis. Tidak bisa meyakinkan mereka atau document tidak lengkap atau secara technical ga jelas atau secara bisnis ga make sense, mereka bisa tolak untuk promote.
Apa yang gw lakukan ?
Pada hari kamis pagi biasanya gw berdoa semoga itu beberapa orang group head yang kadang ga make sense nanyanya sakit, jadi ga masuk review. Hampir 4 tahun gw berdoa gitu, ga ada yang berhasil.
Jadi apa yang gw lakukan ?
Awal-awal pertama CCF Review waktu join di sana sih nightmare, dicuci. Di keramasin, di maki-maki. Impact-nya buat gw apa? Lumayan, kuping kebal dan hati sedikit bebal. Kemudian berkali-kali gw ikutan CCF Review sebelum jadwalnya gw, misalnya jadwal gw jam 11 siang, gw dah dateng di jam 9 pagi. Tujuan gw itu mempelajari pola pikir itu group head, apa yang dia tanyakan. Point-point apa yang dia selalu nanya ke semua orang. Lama-lama gw dah tau pattern-nya, dan bagaimana jawabnya.
Next stepnya, gw tinggal praktekkan aja, dipersiapkan setiap kemungkinan pertanyaan dan cecaran - atau document pendukung, cara jawabnya disesuaikan dengan si penanya dan memang jawaban yang proper.
Alhamdullilah, RTB CEO tidak ada pernah gagal CCF Review lagi. #ehem.

Kalau terjadi krisis
Namanya juga manusia, kerja pasti ada salahnya. Dan salahnya itu kadang critical, atau bukan hal yang critical cuma terlalu lama dibiarkan malah jadi critical, dan terjadi krisis. Impact ke mana-mana, dan semua orang panas dan emosi.
Apa yang gw lakukan ?
GW EMOSI JUGA SIH.
MAU MARAH-MARAH JUGA.
MAU MAKI-MAKI ORANG.
KADANG WAKTU DI GROUP CHATTING NGETIK SAMBIL GEMETERAN NAHAN EMOSI.
PENGEN NABOK ORANG.

cuma...
Kadangkala harus ngerem, atau hilang sejenak. Mikir yang baik dulu, analisa dulu impact-nya. Kadang speed itu ga penting, kecepatan fixing problem itu makin terasah apabila pengalaman + logika + intuisi + kedewasaan bersatu.

1. Jangan panik
2. Jangan cengengesan atau ngeremehin problem juga
3. Jangan nyalahin orang lain, walaupun kita tau itu bukan kita yang problem
4. Kasih tau semua orang, kita lagi ngapain, cek error kah, cek log, coba simulate error atau apapun. Jadi orang lain itu tau kita tidak idle dan memang kita kerja
5. Tiap waktu rutin update ke semua orang, status terakhir
6. Nada suara tidak boleh naik, biarpun emosi
7. Tidak boleh menunduk juga, kerja itu partnership, bukan atasan bawahan
8. Sesama anggota team harus saling cover, kalau team solid juga baik
9. Tidak boleh ada tipu-tipu
10. Waktu crisis, focus benerin yang point-point yang crisis aja. TIDAK BOLEH ADA IMPROVEMENT LAIN SELAIN POINT YANG CRITICAL, BIARPUN ITU SIMPLE ATAU GAMPANG. Untuk point lain titipan, coba di-reschedule ke next release. Ini untuk menghindari senggolan ataupun ketidaktelitian karena waktu yang terbatas.

last but not least...
Dinamika project itu banyak, tidak ada pakem yang pasti. Gw cuma bisa cerita pengalaman gw, namun setiap customer / site / project punya identity sendiri. Cuma menurut gw, espektasi aja dulu yang disamain, kalau udah sama BERIKAN YANG LEBIH.
Baseline espektasi itu : kualitas product yang baik dengan waktu yang pas, biasanya.

Kalau gw di Ifabula, gw ga mungkin selamanya menjadi direktur di Ifabula. Ifabula menjadi semakin besar dan growth semakin baik, dan team semakin keren. Gw berharap dalam waktu jangan terlalu lama, siapapun bisa replace gw di posisi ini, ataupun menjadi beberapa posisi lain as direktur.
Tricky point-nya adalah apakah kalian tau apa espektasi gw ?