---

Mengatasi Kurangnya Komitmen, Pengelolaan Perubahan & Kerja Tim! Ini Mungkin Mengejutkan Anda!

Kelemahan terbesar kerangka perbaikan proses sebelum Scrum adalah: Kerangka tersebut terutama berfokus pada tuntutan organisasi yang melayani kepentingan pemimpin sendiri.

Sebagian tuntutan ini adalah pemantauan, kepatuhan, dan prediktabilitas. Sama sekali tidak berfokus melayani klien dengan baik atau meningkatkan semangat karyawan.

Karena itu, tim manajemen perangkat lunak serta pemangku kepentingan internal dan eksternal lain berusaha menetapkan tenggat tetap proyek penyampaian perangkat lunak dan memantau kemajuan tahap rekayasa dengan mudah.

Mereka menghukum orang jika pekerjaan keluar dari rencana dan berharap memperbaiki masalah sebelum tanggal penyelesaian proyek yang dijadwalkan.

Silo mandiri juga menjalankan tahap rekayasa perangkat lunak yang sepenuhnya terpisah. Misalnya, tim pengembangan sepenuhnya mandiri dari tim pengujian (verifikasi). Kebanyakan orang yang seharusnya bekerja untuk misi bisnis sama bahkan tidak saling mengenal nama.

Dapatkah Anda menebak penyebab pola pikir silo ini, alih-alih fokus pada misi bisnis dan kematangan profesional (bisnis) karyawan?

Penyebabnya sederhana, yaitu manajemen matriks . Manajemen matriks adalah struktur pengelolaan organisasi dan karyawan yang hadir dalam bisnis sejak 1970-an. Sekilas, gagasan pembeda organisasi atau manajemen matriks tampak cerdas.

Pemimpin menciptakan struktur organisasi dengan mengumpulkan karyawan berketerampilan fungsional serta teknis serupa ke dalam silo yang sama atau, paling baik, bersebelahan.

Model Penyampaian Proyek Waterfall dalam Organisasi Matriks

Dahulu, "Pusat Kompetensi" cukup populer dalam perusahaan kami, dan setiap pusat mewakili silo mandiri serta otonom.

Satu silo pengembang C++, silo lain administrator basis data, dan silo penjaminan kualitas yang sepenuhnya terpisah di luar negeri, dan seterusnya. Coba bayangkan!

Tantangan terbesar struktur matriks ialah bahwa untuk menyelesaikan proyek perangkat lunak tanpa kerangka kerja Scrum dan Scrum Master, manajer proyek harus meminjam karyawan dari silo untuk sementara.

Karyawan ini bahkan tidak berada secara fisik bersama tim proyek; mereka tetap di ruang pusat kompetensinya masing-masing.

Setelah proyek selesai, tim sementara dibubarkan dan peserta berpindah ke tugas berikutnya pada proyek lain.

Karena itu, nilai bisnis sasaran proyek perangkat lunak yang berjalan tidak pernah menjadi prioritas tertinggi silo mandiri ini.

Mereka cenderung melihat pekerjaan sebagai kotak centang yang ditandai untuk proyek di sini dan proyek lain di sana.

Kepemimpinan serta model matriks tidak mengajarkan cara profesional berkomitmen pada bisnis untuk meningkatkan hasil akhir, termasuk penjualan, pendapatan, dan laba.

Artikel McKinsey Quarterly oleh McKinsey & Company juga dengan jelas menggambarkan ilusi optimalisasi biaya di balik organisasi matriks ini .

Gartner memperkirakan organisasi di seluruh dunia setiap tahun menghabiskan 600 miliar USD untuk memulihkan sistem TI dari pekerjaan pemeliharaan tak terjadwal dan cacat.

Mari luangkan waktu membayangkan cara pengelolaan perubahan serta penanganan hambatan proyek perangkat lunak berlangsung. Yaitu dalam konfigurasi proyek dengan model Waterfall, organisasi matriks, dan tanpa proses Scrum.

Ya, Anda benar.

Manajemen dan karyawan memperlakukan pengelolaan perubahan, hambatan, serta kesalahan sebagai pengecualian tidak diinginkan yang seharusnya tidak terjadi sejak awal.

Karena itu, perubahan dalam proyek perangkat lunak identik dengan keterlambatan. Perubahan biasanya menciptakan efek domino penundaan beruntun. Tim mencari orang untuk disalahkan atas cacat dan hambatan.

Terakhir, karena silo tidak memiliki mekanisme untuk memproses, memperbaiki, dan belajar dari kesalahan, mereka terus mengulangi kesalahan sama.

Selain itu, mereka terus menambah jumlah utang teknis sambil secara pasif berusaha mengatasi masalah.