Manajemen tidak rasional

Manajemen tidak rasional

Anti Pola Nama: Manajemen irrasional
Disebut Juga Sebagai: Pengawas patologis, Berpikir Jangka Pendek, Managing oleh Reaksi, Keputusan Phobia, Manajer Bermain dengan Teknis Mainan
Kebanyakan Skala Sering: Kewirausahaan
Refactored Nama Solusi: Pengambilan Keputusan Rasional
Refactored Solusi Jenis: Peran dan Proses
Penyebab root: Tanggung Jawab (penyebab universal)
Angkatan seimbang: Manajemen Sumber Daya

Anekdot Bukti: "Siapa yang menjalankan proyek ini?" "Saya berharap dia akan membuat pikiran berdarah!" "Apa yang kita lakukan sekarang?" "Kami lebih baik membersihkan ini dengan manajemen sebelum kita mulai." "Jangan repot-repot meminta, mereka hanya akan mengatakan tidak."

Latar belakang
Manajemen tidak rasional mencakup berbagai sering terjadi masalah proyek software yang dapat ditelusuri kembali ke kepribadian dari orang (s) menjalankan proyek.

Misalnya, manajer mungkin memiliki kepentingan obsesif dalam beberapa aspek teknologi atau kepribadian keterbatasan yang menyebabkan mereka untuk menjadi manajer tidak efektif atau tidak rasional. Manajemen rasional dapat dilihat sebagai satu set miring prioritas mana prioritas pribadi manajer, tidak peduli seberapa nonsensible, membimbing proyek perangkat lunak di arah irasional.

Bentuk umum
Manajer (atau tim manajemen) dari satu atau lebih proyek pembangunan tidak bisa membuat keputusan. Ini mungkin cacat kepribadian atau hasil dari obsesi dengan rincian.

Rincian mungkin kepentingan pribadi atau perilaku dari manajer, seperti teknis "mainan" atau micromanagement. Ketika dihadapkan dengan krisis, keputusan manajer adalah reaksi spontan daripada hati-hati strategi berpikir-out atau tindakan taktis. Reaksi-reaksi ini sering menyebabkan masalah lebih lanjut. Siklus kebingungan dan reaksi dapat meningkat dalam frekuensi dan keparahan konsekuensi.

The irrasional Manajemen antipattern secara signifikan diperparah oleh ketidakmampuan manajer untuk staf pengembangan langsung. Ini juga disebut kurangnya keterampilan yang baik orang-manajemen, yang ditandai oleh ketidakmampuan untuk:

Kenali kemampuan staf, baik kekuatan dan kelemahan.

Memberikan tujuan yang jelas yang sesuai untuk staf keterampilan.

Berkomunikasi secara efektif dengan staf.

Gejala Dan Konsekuensi

Gejala utama dari irrasional Manajemen antipattern adalah proyek meronta-ronta, sebuah perdebatan tentang topik penting. Keputusan harus dibuat untuk memungkinkan pengembangan staf untuk kemajuan. Meronta-ronta memiliki beberapa konsekuensi.

Peningkatan staf frustrasi.

Penundaan tambahan untuk pengiriman.

Eksploitasi oleh tongkol jagung.

Penyebab khas

Manajer tidak memiliki kemampuan untuk mengelola:

Pengembangan staf.

Manajer lain.

Proses pembangunan.

Dia juga tidak memiliki visi yang jelas dan strategi, dan karena itu:

Tidak bisa membuat keputusan.

Takut Sukses

Apakah tahu tentang keadaan sebenarnya dari kegiatan proyek dan kiriman.

Dikenal Pengecualian
Seharusnya tidak akan ada pengecualian untuk irrasional Manajemen antipattern. Namun, "anak emas" yang memiliki keterampilan guru-tingkat yang benar-benar unik dalam beberapa cara dan memberikan keuntungan teknis utama harus ditoleransi, sementara solusi jangka panjang yang lebih baik dan direncanakan.

Solusi refactored
Ikuti panduan ini untuk menyelesaikan Manajemen irrasional antipattern:

Mengakui Anda memiliki masalah dan mendapatkan bantuan. Ketika manajer menderita satu atau lebih penyebab yang khas, mereka pertama kali harus mengakui bahwa mereka memiliki masalah. Dengan asumsi bahwa mereka tidak menyadari situasi mereka, langkah pertama adalah untuk mengidentifikasi indikator kunci, yang paling umum adalah bahwa dari "menemukan cara yang keras." Misalnya, daripada staf teknis menangani masalah yang berkembang dan meminta bantuan dalam berurusan dengan itu, manajer irasional tahu hanya setelah masalah telah mencapai tahap krisis; tidak ada yang bersedia untuk membahas masalah, karena hal itu tidak pernah membantu. Manajer harus mengelilingi diri dengan staf berbakat (atau konsultan) yang berbagi pekerjaan kompleks mengelola dan bersedia untuk mendengarkan mereka.

Memahami pengembangan staf. Manajer perlu memahami baik keterampilan teknis dan ciri-ciri kepribadian anggota staf mereka. Kesadaran keterampilan teknis membantu pekerjaan manajer delegasi; kesadaran kepribadian membantu sebuah menunjuk manajer hubungan kerja.

Menyediakan jelas, tujuan jangka pendek. Mudah dicapai tujuan harus ditentukan untuk proyek tersebut. Tujuan jangka panjang yang diperlukan, tetapi tidak sebagai berhasil memotivasi staf setiap hari. Seorang manajer harus memastikan bahwa jangka pendek, tujuan yang sangat spesifik diatur dan staf yang mengerti bagaimana mereka dapat dicapai.

Bagi fokus. Staf proyek harus berbagi tujuan proyek mereka untuk memastikan mereka semua bekerja menuju tujuan yang sama. Manajer harus memulai dan tumbuh fokus.

Mencari perbaikan proses. Menyadari bahwa setiap proyek sedikit berbeda dari yang sebelumnya, manajer harus memantau proses pembangunan dan meningkatkan mereka di mana dan kapan diperlukan. Meskipun ini sering tweak kecil untuk membuat proses tertentu yang lebih pragmatis, mereka secara signifikan dapat meningkatkan produktivitas.

Memfasilitasi komunikasi. Setiap kali "panas" bahan bakar topik perdebatan, memutuskan cara untuk bergerak maju yang terbaik adalah dicapai dalam sesi difasilitasi. Untuk melakukannya:

Mengidentifikasi pemain kunci.

Mengumpulkan bukti pada perdebatan.

Dapatkan kesepakatan yang jelas pada masalah (s).

Membuat suara yakin semua orang yang mendengar.

Mengkonfirmasi bahwa pilihan solusi yang dipahami oleh semua.

Setuju dengan pilihan yang lebih disukai.

Libatkan staf yang bersangkutan dalam melaksanakan solusi di mana mungkin.

Mengelola mekanisme komunikasi. E-mail dan newsgroup pada umumnya adalah mekanisme komunikasi yang berguna, tetapi keduanya dapat mengatur orang-orang di jalan berliku dari kehancuran. E-mail dapat dengan cepat keluar dari tangan, dan newsgroup dapat menghasilkan perdebatan arogan dan agresif. Solusinya adalah dengan melacak e-mail dan posting newsgroup harian dan mengidentifikasi miskomunikasi. Berbicara langsung dengan pihak-pihak yang terlibat dan memberitahu mereka untuk menghentikan perdebatan elektronik. Jika itu penting untuk menemukan solusi, maka pertemuan yang difasilitasi biasanya lebih cepat dan jauh lebih efektif.

Mengelola dengan pengecualian. Ekstrem selalu berbahaya, dan overmanagement tidak terkecuali. Rapat harian dan mingguan ulasan yang memerlukan keterlibatan seorang manajer di semua thread proyek adalah contoh dari kelebihan atau micromanagement. Sebaliknya, mengelola dengan pengecualian; menonton, tapi tidak mengganggu. Biarkan masalah waktu untuk diselesaikan oleh orang lain. Langkah hanya bila diperlukan.

Menerapkan teknik pengambilan keputusan yang efektif. Dua teknik manajemen rasional dari Kepner-Tregoe sangat efektif dalam pengambilan keputusan software. Yang pertama disebut analisis situasi Teknik ini membantu dalam organisasi dan manajemen lingkungan yang tidak terstruktur dan kacau. Hal ini dapat digunakan secara individual atau kelompok. Yang kedua disebut analisis keputusan Teknik ini sangat penting untuk membuat keputusan secara obyektif.

Bias subjektif dalam proses pengambilan keputusan dapat memiliki konsekuensi yang menghancurkan dalam proyek perangkat lunak. Kami sudah sering melihat semacam ini bias mengakibatkan bencana software. Bias dapat dihasilkan oleh persahabatan, waktu panggilan penjualan, kendala platform yang tidak perlu, dan kendala infrastruktur tak terlihat.

Kedua teknik dijelaskan secara mendalam di subbagian berikut.

Analisa situasi

Tujuan dari analisis situasi adalah untuk mengidentifikasi masalah prioritas tertinggi dalam situasi yang kompleks. Sebuah versi disesuaikan dari teknik ini berisi langkah-langkah berikut:

Daftar semua kekhawatiran. Ini mungkin termasuk masalah yang diketahui, item tindakan, komitmen, kesenjangan teknologi, dan barang-barang lainnya. Dengan kata lain, daftar mungkin berisi hampir apa saja yang mempengaruhi proyek di tangan.

Menilai kekhawatiran sehubungan dengan tiga kriteria: keseriusan, urgensi, dan potensi pertumbuhan. Menggunakan tiga tingkatan: tinggi, sedang, dan rendah. Sebagai contoh, jika kekhawatiran tersebut penting untuk keberhasilan proyek, sangat serius. Jika kekhawatiran harus segera diselesaikan untuk resolusi yang akan efektif, itu dinilai sangat mendesak. Jika keseriusan diharapkan meningkat secara dramatis dalam waktu, itu dinilai memiliki potensi pertumbuhan yang tinggi.

Tabulasi skor untuk setiap item berdasarkan peringkat. Menetapkan nomor ke tingkat wisatawan: tinggi = 2, menengah = 1, dan rendah = 0. Misalnya, peringkat tinggi / menengah / rendah akan mencetak 3 poin (2 + 1 + 0).

Memprioritaskan item dalam hal nilai. Untuk semua kekhawatiran bahwa skor 6, memilih yang paling penting, kedua penting, dan sebagainya. Lanjutkan tugas prioritas dengan item mencetak 5 dan lebih rendah, sampai seluruh daftar kekhawatiran diberikan sebuah nomor prioritas.

Menetapkan item yang dapat diselesaikan dengan staf yang sesuai. Beberapa item pada daftar akan dikendalikan oleh kekuatan eksternal, dan itu akan masuk akal untuk mengeluarkan energi menyelesaikan mereka sampai perubahan situasi. Item lainnya harus diselesaikan sebelum orang lain karena ketergantungan. Untuk staf benar berkualitas, resolusi yang paling item akan langsung: Program benda yang diperlukan, membuat model analisis, mengurangi risiko melalui pengujian, dan sebagainya. Manajer harus membuat pertandingan terbaik dari sumber daya staf untuk keprihatinan yang harus diselesaikan.

Bekerja pada item top-prioritas dalam daftar. Teknik analisis situasi bekerja pada prinsip mengatasi hal pertama yang pertama dan kedua hal tidak pernah. Menggunakan analisis situasi, manajer secara efektif dapat mengatasi masalah yang paling penting dari antara daftar membingungkan keprihatinan menghadapi proyek perangkat lunak.

Analisis Keputusan

Sebuah proses disesuaikan untuk analisis keputusan memuat langkah-langkah ini:
Menentukan ruang lingkup keputusan yang harus ditangani. Dengan kata lain, proses tersebut harus dimulai dengan pertanyaan tertulis untuk menyelesaikan.

Mengidentifikasi solusi alternatif untuk menyelesaikan keputusan. Ini dapat termasuk alternatif konkret tertentu, seperti produk software tertentu atau kategori solusi yang dapat dievaluasi.

Mendefinisikan kriteria keputusan. Analisis situasi dapat digunakan untuk membuat daftar ini.

Membagi kriteria antara penting dan desirables. Kriteria penting adalah karakteristik yang harus menjadi bagian dari solusi dalam rangka untuk itu untuk dapat diterima. Jika kriteria penting yang hilang dari alternatif, alternatif didiskualifikasi. Untuk alasan ini, kriteria penting harus dipilih dengan cermat, daftar pendek. Semua kriteria lain yang disebut desirables, dan mereka harus diprioritaskan. Gunakan proses tugas prioritas dari analisis situasi untuk tujuan ini, kemudian menetapkan alternatif diinginkan berat. Misalnya, jika ada tujuh kriteria, yang paling penting memiliki berat 7; berikutnya yang paling penting memiliki berat 6, dan sebagainya.

Menentukan apakah alternatif memenuhi semua kriteria penting. Jika tidak, menghilangkan alternatif yang tidak memuaskan.

Lakukan pencari fakta. Penelitian untuk menilai kepuasan kriteria oleh masing-masing alternatif.

Mengatur meja yang menampilkan alternatif dalam kolom dan kriteria dalam baris. Di meja, peringkat alternatif untuk kriteria yang diinginkan. Misalnya, jika ada lima alternatif, alternatif terbaik mendapat peringkat dari 5; terbaik berikutnya mendapat pangkat 4, dan sebagainya.

Kalikan bobot oleh jajaran untuk menghitung skor untuk setiap posisi dalam matriks. Menjumlahkan skor di setiap kolom untuk menghitung skor untuk setiap alternatif. Alternatif skor tertinggi adalah rasional (atau terbaik) pilihan.

Sadarilah bahwa pilihan rasional mungkin tidak menjadi pilihan yang manajer atau pelanggan akan menerima. Bias penting atau kriteria yang tidak tercermin dalam analisis keputusan dapat menyebabkan ini, dalam hal ini, adalah penting untuk mengevaluasi kriteria keputusan. Bereksperimen dengan bobot pada kriteria yang diinginkan, dan menambahkan kriteria baru sampai analisis keputusan memilih alternatif yang dapat diterima. Mengkonfirmasi bahwa kriteria dan bobot yang dihasilkan sesuai dengan kriteria keputusan subjektif yang mendorong solusi ini. Mungkin otoritas pengambilan keputusan akan mengubah kriteria mereka untuk asumsi yang lebih realistis ketika dihadapkan dengan pengaruh sebenarnya yang bias mereka memiliki pada keputusan.

Variasi
Konsultan dapat menjadi sumber daya berharga. Mereka dapat membawa hilang pengetahuan dan keterampilan untuk organisasi, dan dapat memberikan saran yang independen dari politik internal dan detailitis; yaitu, mereka bisa objektif dalam situasi dikenakan. Konsultan dapat memainkan tiga peran kunci dalam sebuah proyek software. Kategori ini didasarkan pada model Block untuk praktek konsultasi umum:

Sepasang Tangan.

Ahli teknis.

Manajemen Peer.

Mengisi Pair-of-Tangan peran, konsultan menjadi pengembang perangkat lunak lain, mirip dengan seorang karyawan biasa. Sebagai Teknis-Ahli, konsultan menyelesaikan masalah dalam domain tertentu.

Sebagai Manajemen-Peer, konsultan adalah penasehat manajemen, memberikan transfer pengetahuan mentoring dari pengalaman terkait nya. Meskipun profesional bermanfaat bagi konsultan untuk berada di dua yang terakhir peran, kita telah melihat hasil yang luar biasa dari Pair-of-Tangan peran, terutama dalam situasi prototyping cepat dengan teknologi baru.

Contoh
Seorang manajer kami bekerja dengan datang ke sebuah proyek di titik tengah. Dia tidak memiliki pemahaman tentang keterampilan staf, atau latar belakang yang baik pada proyek sampai saat ini.

Saat masalah terjadi, ia dialokasikan staf. Hal ini menciptakan masalah yang lebih serius. Anggota staf pindah ke proyek-proyek yang mereka tidak punya paparan sebelumnya. Hal ini mengakibatkan efektivitas berkurang. Situasi ini sebagian diselesaikan ketika manajer meninggalkan perusahaan.

Manajer baru adalah sangat kuat "orang-orang" yang memastikan bahwa keterampilan karyawan cocok dengan kegiatan yang diperlukan. Sayangnya, penundaan sudah berpengalaman tidak bisa dibuat untuk.

Dalam situasi lain, seorang arsitek proyek (a tongkol jagung) menyuarakan pendapatnya tentang C ++ standar pengkodean melalui e-mail kepada semua staf proyek. Proyek ini memiliki beberapa guru tingkat C ++ pengembang yang mengambil pengecualian untuk beberapa pernyataan arsitek.

Hal ini mengakibatkan dua bulan e-mail dan newsgroup "perang." Solusi akhirnya adalah bahwa manajer proyek menunjuk "Tim harimau" untuk mengatasi masalah tersebut. Ini adalah solusi yang difasilitasi berdasarkan prinsip run-depan. Sayangnya, tidak ada tindakan pencegahan yang diambil untuk menghilangkan komunikasi destruktif serupa di berbagai topik lainnya. Contoh ditangani dengan bukan masalah utama.

Dalam contoh ketiga, proyek integrator sistem ini memiliki tim manajemen yang tidak rasional. Manajer individu yang pemilik bagian mereka dari proses. Hal ini menciptakan proses cerobong asap dengan baik koherensi atau kedekatan. Hal ini mengakibatkan berbagai perang kepemilikan.

Salah satu perang didasarkan pada kriteria masuk untuk berpindah dari satu tahap pengembangan ke depan. Hal ini menyebabkan bulan meronta-ronta dan perselisihan, yang kemudian disebarkan fokus pada masalah-masalah pembangunan yang muncul. Manajemen perusahaan harus melangkah di. Dan karena resolusi itu diberlakukan dari atas, itu tidak berkelanjutan.