Trial

5.6 The Matrix RACI


Penataan Akuntabilitas Untuk Efisiensi Maksimum dan Hasil
Related varian: ARCI, RASCI, RASIC, RACI-V dan KAIRO 
 

Teamwork sering dilihat sebagai cara yang efektif untuk mencapai tujuan bekerja. Dan tidak ada keraguan bahwa ketika tim bekerja sama dengan baik hasilnya bisa mengesankan. Sayangnya, sebaliknya adalah benar dan terlalu umum: Tim yang gagal untuk bekerja dengan baik juga dapat gagal untuk memberikan hasil yang diinginkan.

Ketika beberapa orang bekerja pada sebuah proyek mudah untuk mengasumsikan bahwa orang lain mengurus
detail tertentu atau tugas. Hal ini juga mudah untuk jari-jari titik dan menyalahkan ketika salah satu dari pekerjaan-pekerjaan dilakukan dengan buruk atau tidak dilakukan sama sekali.

Banyak faktor yang dapat berkontribusi untuk kinerja yang kurang dari tim, tapi kecuali tanggung jawab dan akuntabilitas yang jelas, bisa ada resiko signifikan bahwa masalah akan timbul.

Dengan proyek yang kompleks, sensitif terhadap waktu atau misi-kritis, atau dalam situasi di mana orang merunduk tanggung jawab, hal ini sering layak meluangkan waktu untuk berpikir melalui peran yang Anda dan tim Anda anggota harus bermain dalam setiap tugas yang melakukan tim Anda. Tanpa kejelasan ini, Anda akan paling mungkin menemukan kesenjangan, duplikasi dan kebingungan. Kerja tim akan frustasi, tidak efisien dan Anda cenderung untuk memberikan hasil yang baik. Dalam situasi ini, delegasi tugas dan tanggung jawab lainnya dapat terlalu penting untuk meninggalkan kebetulan.

Matrix RACI adalah sistem yang membawa struktur dan kejelasan untuk menempatkan peran orang bermain dalam tim. Ini adalah sistem grid sederhana yang dapat Anda gunakan untuk memperjelas tanggung jawab masyarakat dan memastikan bahwa semuanya tim perlu lakukan adalah diurus.

R = Responsible (Orang yang melakukan pekerjaan)
A = Accountable (
Orang-orang yang memastikan pekerjaan akan dilakukan)
C = Consulted (
Orang-orang yang memberikan masukan sebelum dan selama pekerjaan)
I = Informed (
Orang yang diinformasikan kemajuannya /  progress)


Dari Mana Datangnya Persyaratan

Craig Brown memulai seri yang ditulis oleh Nilesh Raje, berjudul " Siapa yang Memutuskan Persyaratan Proyek ? " Ini merupakan pertanyaan usia tua dalam pengembangan perangkat lunak. Nilesh menulis untuk Jaringan Kelompok Persyaratan . Seperti Blog Craig, RQNG adalah harus membaca situs.

Sebelum membaca konten meskipun, kita ingin membangun gagasan bahwa persyaratan hanya datang dari satu tempat dalam proyek kelas enterprise. Dalam yang terbaik dari dunia, semua persyaratan berasal dari tempat yang sama.

Berasal dari strategi bisnis. Strategi ini memberitahu kita "Mengapa" kita melakukan hal-hal. Salah satu representasi dari strategi adalah Balanced Scorecard. Ada ae saat ini 3 generasi Balanced Scorecard. Banyak buku TI masih menggunakan generasi pertama. Satu dengan kuadran foyr. Hal ini tidak cocok untuk masalah organisasi modern. Generasi ketiga tiba seperti ini.


Dengan generasi ketiga kita dapat menghubungkan strategi dengan taktik. Dan dengan hubungan ini kita dapat mendefinisikan proyek dan persyaratan dalam proyek-proyek yang memenuhi strategi bisnis. Sebuah akhir penuh untuk mengakhiri loop untuk menjawab pertanyaan usia terus dalam pengembangan perangkat lunak

Mengapa Kita Melakukan Ini?
Jadi, inilah yang mereka koneksi terlihat seperti di awal. 


Apa yang di sebelah kanan gambar ini adalah kumpulan proyek - mungkin dalam portofolio program dan proyek - yang memenuhi Visi, Tujuan Strategis, Sasaran Kinerja, Faktor Kritis Sukses, dan Indikator Kinerja Kunci Sebuah strategi bisnis. Catatan Sebuah strategi Bisnis - ada banyak semua didefinisikan dalam Peta Strategi. Berikut peta Strategi kita digunakan untuk menjalankan sebuah departemen TI yang besar di Departemen multi-miliar dolar dari situs Energi. 

Untuk setiap item dalam Peta Strategi - P1 misalnya - ada satu set proyek (program dan portofolio) menyebabkan manfaat dari strategi yang muncul pada waktu yang direncanakan, untuk anggaran yang direncanakan dan sebagian besar semua untuk hasil menguntungkan direncanakan ke situs. 


Dapatkah Matriks Manajemen Kerja?


Ada salah satu kutipan bakhil tidak memenuhi syarat, berdasar, dan cukup banyak beredar. Kau tahu semacam itu. "Ini tidak bekerja untuk kita sehingga tidak dapat bekerja untuk Anda." Ini biasanya berlangsung seperti ini ... 


"Kita pikir itu adalah jelas bahwa manajemen matriks bukan dan tidak bekerja, memimpin kita untuk menyimpulkan bahwa itu adalah salah satu penyebab utama untuk bukan kepalang" keberhasilan "level proyek di kebanyakan organisasi."


Tentu saja, tidak ada satuan ukuran di sini. Tidak, teknis bisnis, atau konteks operasional atau domain. Tidak ada bukti atau fakta yang sebenarnya, selain pendapat pribadi dan anekdot - pendekatan yang berbahaya untuk proses perbaikan.


Jadi mari kita lihat apakah kita bisa mendapatkan semua ini anekdot "teori" tentang matriks manajemen entah bagaimana datang dalam kontak dengan realitas.


Dalam bisnis penerbangan berawak ruang dan hampir setiap DoD lainnya, NASA, dan DOE matriks manajemen domain adalah dasar dari Produk Terpadu (Proyek) Tim (IPTs). O Lihat 413,3-18 sebagai contoh untuk konteks DOE. NAVAIR dan NASA memiliki panduan praktek yang serupa.



Jadi di sini adalah cara kerjanya. Mari kita berpura-pura aku Engineering Propulsion Timbal (ya itu adalah ilmu roket).


Kita bertanggung jawab untuk desain dan pengembangan sistem propulsi untuk komputer kita terbang. Ini adalah konsep penting - akuntabilitas - yang tidak terjawab di sebagian besar program yang masuk ke parit. Pertama Akuntabel, kemudian Bertanggung Jawab.


Kita melaporkan kepada Program Manager - baris tanggung jawab mengalir turun. Tapi itu mengalir turun melalui Lead Systems Engineering. Aku mengambil arah dari dua orang. PM dan SE. Mereka bekerja dengan kita dalam cara matrixed karena kita berada di sebuah organisasi IPT. Sekarang jika mereka menceritakan hal yang bertentangan - mengatakan berapa banyak yang dibutuhkan dorongan untuk terus mengorbit di Mars, maka kita perlu untuk mengadakan pertemuan untuk mendapatkan ini diurutkan keluar. Mengapa, karena aku AKUNTABEL untuk membuat pekerjaan sistem propulsi. Ini tidak bekerja, misi gagal.


Sekarang, PM memiliki peran lebih besar dari SE. Jadi, selama pertemuan, SE akan membuat poin mereka, aku akan membuat titik kita (didukung oleh data teknis, tidak ada pendapat diperbolehkan di sini) dan PM akan mengambil semua informasi ini dan kami - sebagai sebuah tim - akan memiliki persetujuan pada hasilnya. Ingat kita IPT sebuah.


Sekarang, dalam berjalan Keselamatan dan Jaminan Misi (S & MA) Timbal, http://www.hq.nasa.gov/office/codeq/ . Dan ia tidak setuju dengan keputusan kecil kami. Jadi siapa mengalahkan siapa? Nah dalam bisnis penerbangan antariksa berawak S & MA memiliki peran kuat. Lebih kuat daripada PM, karena sertifikasi kesiapan peluncuran peran S & MA, bukan peran PM. 

Kita kembali ke akuntabilitas.


Semua akuntabilitas didefinisikan dalam Matrix Tugas Tanggung Jawab (RAM). Tanggung jawab, akuntabilitas, komunikasi, informasi (RACI) drive model bagaimana kerja IPTs dalam matriks. Bahkan bagian tanggung jawab RACI tidak pernah dibahas sampai tugas Akuntabilitas dibuat, dan selanjutnya terserah kepada orang yang bertanggung jawab untuk mengalir ke bawah tanggung jawab.


Jadi untuk berusaha untuk mendapatkan teori untuk datang dalam kontak dengan realitas bagaimana manajemen matriks "dapat" bekerja. Karena itulah AM nyata adalah soal, realitas proyek.


Tidak diragukan lagi ada banyak contoh bagaimana membuatnya TIDAK bekerja. Tapi itu disebut "premis palsu" argumen. Hanya karena Anda belum pernah melihatnya bekerja, atau memiliki beberapa kutipan dari beberapa orang mati yang mengatakan itu tidak bisa bekerja, tidak berarti itu tidak bekerja setiap hari di 1.000 's program. Ini dibuktikan dengan anekdot. TIDAK


Ini penting di sini untuk melihat-lihat untuk tempat manajemen matriks tidak bekerja dan melihat apakah apa yang mereka lakukan adalah dalam tetap berguna dan berlaku untuk lingkungan proyek Anda. Mungkin tidak. Tapi itu tidak berarti itu adalah umumnya kasus yang tidak bekerja. Bahkan justru sebaliknya. Jika berhasil di tempat lain, Anda memiliki contoh kerja anekdot. Coba dan mencari tahu bagaimana mereka membuatnya berhasil. 

Jika Anda tidak bisa figure it out, atau tidak dapat menempatkan bekerja apa yang mereka tahu - kami telah menemukan masalah - ANDA. Belajar dari orang lain, tidak percaya semua yang anda baca di buku-buku lama 50 tahun. Ajukan pertanyaan yang lebih dalam. Selidiki beberapa pandangan. Cobalah untuk menentukan apakah suatu konsep atau pernyataan sebenarnya universal, atau hanya sebuah anekdot kegagalan dalam domain yang spesifik.


Ini merupakan kesalahan umum dari pembalik pencarian untuk perbaikan. "Tidak bekerja untuk kita, tidak bisa bekerja untuk Anda," adalah pendekatan lemah untuk mencoba untuk meningkatkan probabilitas keberhasilan program.


0 comments:

AddThis