Geekly articles weekly

Masalah Orang Di Antara Manajer Proyek



Bagi mereka yang tidak terbiasa dengan pengembangan perangkat lunak, mungkin tampak aneh bahwa suatu proyek memiliki manajer produk dan manajer proyek . Perbedaannya adalah bahwa yang pertama bertanggung jawab untuk menentukan produk, dan yang kedua bertanggung jawab untuk status proyek dan melaporkan kepada pihak yang berkepentingan jika tanggal pengiriman berisiko.

Manajer proyek cenderung berusaha untuk memastikan prediksi tenggat waktu melalui proses standardisasi dan siklus. Proses-proses ini fokus pada pelaporan status untuk melacak kemajuan. Secara umum diterima bahwa semakin dekat Anda memantau proses, jadwal proyek akan lebih dapat diprediksi, dan semakin tinggi kemungkinan proyek akan dikirimkan tepat waktu.

Kutukan manajer proyek adalah kualitas perkiraan untuk waktu yang mereka terima dari tim. Perkiraan ini dapat sangat bervariasi. Mereka biasanya berbeda dari orang ke orang, dan pembaruan harian mungkin diperlukan. Pusaran dalam estimasi pada akhirnya mungkin membuat tidak mungkin untuk menentukan waktu proyek, tetapi tanggal yang pasti dari manajer. Ketika tenggat waktu ini akhirnya terlewatkan, manajer harus menemukan cara untuk menjelaskan mengapa tenggat waktu itu terlewatkan, tanpa membuat karyawan terakhir secara langsung bertanggung jawab atas tenggat waktu yang terlewatkan. Diplomasi yang tidak memadai di bidang ini sering membuat staf menuduh manajer proyek “melempar mereka ke bawah kereta,” terlepas dari keakuratan penilaian mereka sebelumnya.

Berikut ini adalah kepribadian yang bermasalah di antara manajer proyek:


Perencana Pertemuan


Manajer proyek, yang percaya bahwa semua masalah proyek disebabkan oleh kurangnya komunikasi dan koordinasi, dan sejumlah besar pertemuan akan menjadi solusinya.

  • Dapat bermutasi menjadi statistik
  • Berbahaya dalam kombinasi dengan manajer produk seperti penulis paten
  • Probabilitas koreksi: tinggi
  • Bahaya untuk proyek: rendah

Masalah


Secara teori, orang-orang berkumpul dalam rapat untuk membahas opsi dan membuat keputusan. Bahkan, ini jarang terjadi. Perencana pertemuan tidak mengetahui fenomena ini dan mencoba menjadwalkan pertemuan sesering mungkin, dengan sebanyak mungkin orang. Dia dengan tulus percaya bahwa ini akan meningkatkan kolaborasi dalam tim: gagasan bahwa komunikasi tidak cukup untuk keberhasilan proyek telah diperkuat dengan kuat dalam pikirannya.

Jenis manajer ini memperburuk tiga masalah utama yang melekat dalam sebagian besar pertemuan:

  1. Sebagai aturan, pemilihan peserta dilakukan dengan buruk, akibatnya beberapa orang mendengarkan informasi yang tidak mereka minati dan menyatakan pendapat tentang masalah yang tidak menjadi perhatian mereka.
  2. Penyelenggaraan rapat juga biasanya dilakukan dengan buruk, yang sering mengarah pada debat kacau yang tidak relevan dengan tujuan pertemuan, yang pada gilirannya tidak mengarah pada kesimpulan praktis.
  3. Proyek diselesaikan bukan pada pertemuan, tetapi di tempat kerja. Jika Anda mengarahkan karyawan ke rapat alih-alih bekerja, mereka menghabiskan waktu yang berharga.

Solusi


Seorang perencana pertemuan tidak menimbulkan ancaman serius bagi suatu proyek karena karyawan biasanya tidak menghadiri rapat yang mengganggu produktivitas mereka. Karena itu, pekerjaan terus berlanjut meskipun ada pertemuan yang sedang berlangsung.

Manajer proyek ini dapat diperbaiki dengan instruksi sederhana:

  1. Klasifikasi semua jenis pertemuan yang biasanya mereka adakan: laporan status, ulasan proyek, penjadwalan, dll.
  2. Tentukan hasil apa (jika ada) dari pertemuan-pertemuan ini dapat dicapai dengan cara lain, misalnya melalui email, alat pelacak, percakapan informal.
  3. Untuk pertemuan wajib, tentukan seberapa sering mereka harus diadakan dan siapa yang harus hadir.
  4. Jadwalkan rapat dalam blok untuk menghindari beberapa gangguan karena pengalihan konteks.
  5. Biarkan beberapa hari dalam seminggu bebas dari rapat.
  6. Dikecualikan dari berkumpul beberapa minggu secara keseluruhan (Anda akan dicintai untuk itu).
  7. Jadwalkan setiap pertemuan setidaknya satu minggu sebelumnya dengan agenda yang dipublikasikan dan bahan apa pun yang perlu dipertimbangkan sebelum pertemuan.
  8. Di awal pertemuan, ulas agenda, tujuan pertemuan, dan bantu mencapai tujuan itu.
  9. Akhiri rapat dengan segera: jangan lanjutkan jika tujuan awal tercapai.

Diperlukan pertemuan untuk menyelesaikan proyek, tetapi yang paling penting:

  1. Buat setiap pertemuan seefektif mungkin.
  2. Minimalkan dampak negatif pada kinerja.

Begitu perencana pertemuan memahami ini, perilakunya akan segera berubah menjadi lebih baik.

Ahli statistik


Seorang manajer proyek yang hanya terlibat dalam membuat daftar dan memeriksa barang, terlepas dari kontennya.


Masalah


Menyelesaikan proyek apa pun membutuhkan dua langkah penting:

  1. Buat daftar tugas.
  2. Tandai item dari daftar yang dibuat.

Manajer proyek dari jenis statistik sampai pada kesimpulan bahwa mempertahankan daftar ini adalah keseluruhan dari tanggung jawab pekerjaannya. Dia tidak khawatir tentang apa yang ada dalam daftar. Hanya dengan fakta bahwa ia memiliki poin dan bahwa mereka diperiksa pada kecepatan yang dapat diprediksi. Ahli statistik tidak mengevaluasi dan tidak menawarkan pendekatan kritis apa pun item dalam daftar, tetapi sebaliknya bergantung pada orang lain, memberi tahu mereka isi item dan tenggat waktu.

Perhatian terbesar untuk manajer seperti itu adalah bahwa perangkat lunak manajemen proyek dapat melakukan tugasnya. Dengan demikian, menjadi tidak perlu. Seringkali statistik diberikan untuk memimpin proyek dalam program semacam itu, dan ia dengan sangat hati-hati memelihara informasi terkini. Proyek itu sendiri mungkin hancur, tim mungkin merilis produk yang sepenuhnya salah dengan penundaan beberapa bulan dan kualitas buruk, tetapi sejauh ini semuanya didokumentasikan dengan baik, statistik tidak melihat masalah.

Untungnya, jika seorang ahli statistik hanya memelihara daftar dan menghapus item, ia tidak membahayakan proyek, jika ia tidak memperhitungkan ketidaktahuannya tentang keadaan sebenarnya. Masalah utama adalah bahwa statistik dapat dengan cepat bermutasi menjadi sesuatu yang jauh lebih buruk.

Solusi


Statistik sulit untuk diperbaiki karena perhatiannya pada detail berakar dalam di alam, sangat mungkin sejak kecil. Jika seseorang menganggap daftar itu penting, dia tidak akan tiba-tiba mengubah pola pikirnya setelah kata-kata Anda. Selain itu, daftar itu sangat penting, tetapi itu hanya peta, bukan lanskap. Paradoks daftar yang membingungkan ini, yang penting, tetapi bukan yang terpenting, membuat statistik sangat sulit untuk diperbaiki.

Keterampilan utama yang kurang dari statistik adalah kemampuan untuk bekerja dengan orang-orang. Manajer berinteraksi dengan daftar daripada dengan orang-orang. Undang mereka untuk berbicara dengan orang-orang secara langsung tentang apa yang mereka lakukan dan mengapa, dan tidak hanya meminta daftar barang. Namun, dalam kasus eksekusi yang buruk, statistik dapat meluncur ke manajemen mikro (lihat manajer tidak aman ).

Akhirnya, mintalah untuk menulis ringkasan satu paragraf tentang status proyek, dan tidak menunjukkan hasilnya sebagai daftar item. Ini akan membuat mereka lebih mempresentasikan proyek secara holistik.

Salah


Manajer sangat bercerai dari realitas proyek sehingga ia memberikan informasi palsu kepada pihak yang berkepentingan.

  • Dapat bermutasi menjadi optimis atau pesimis
  • Berbahaya bila dikombinasikan dengan pengembang yang optimis
  • Probabilitas koreksi: tinggi
  • Bahaya untuk proyek: sangat tinggi

Masalah


Tanggung jawab utama manajer adalah melaporkan status proyek. Ini disebut "menetapkan harapan," dan "memenuhi harapan" adalah ukuran yang menentukan keberhasilan suatu proyek. Seorang manajer proyek yang baik menetapkan harapan berdasarkan pada kombinasi data kuantitatif dan kualitatif, serta pengalaman profesionalnya sendiri. Di sisi lain, manajer yang salah hanya didasarkan pada instingnya.

Berikut ini adalah frase kunci yang memungkinkan Anda mengenali manajer proyek di awan:

  • "Aku punya firasat buruk."
  • "Saya tidak berpikir kita akan tepat waktu saat ini."
  • "Aku pikir semuanya akan baik-baik saja dengan kita."
  • "Aku tidak melihat masalah."
  • "Keputusan ini membingungkan saya."

Perhatikan penggunaan "Aku" dan "kita" - ini adalah penanda yang baik bahwa persepsi manajer didasarkan pada kesan subyektif, dan bukan pada data yang dikumpulkan dan dianalisis.

Penting untuk mencatat perbedaan antara manajer yang salah arah, pesimis, dan optimis :

  • Seorang pesimis , berdasarkan interpretasinya atas informasi kuantitatif dan kualitatif, percaya bahwa proyek itu akan gagal.
  • Seorang yang optimis , berdasarkan interpretasinya atas informasi kuantitatif dan kualitatif, percaya bahwa proyek tersebut akan berhasil.
  • Manajer yang keliru hanya dengan perasaannya sendiri membentuk pendapat tentang keberhasilan atau kegagalan proyek, yang sama sekali tidak benar.

Ini adalah salah satu dari sedikit kepribadian yang dapat merusak seluruh proyek sendiri. Jika manajer seperti itu sering bertemu dengan para pemangku kepentingan, maka kewaspadaan harus ditingkatkan karena hal-hal berikut dapat terjadi:

  1. Manajer memberi tahu pihak berwenang bahwa semuanya hilang, proyek tidak akan pernah masuk ke produksi, sehingga proyek dibatalkan.
  2. Manajer mengatakan bahwa semuanya beres dan semuanya akan tepat waktu, akibatnya pihak berwenang akan lebih kecewa jika mereka terlambat, yang akan mengarah pada pembatalan proyek.

Solusi


Untungnya, manajer seperti itu dapat diperbaiki dalam dua tindakan:

  1. Tanyakan mengapa dia merasakan apa yang dia rasakan.
  2. Tunjukkan padanya data kuantitatif dan kualitatif yang bertentangan dengan instingnya.

Mengapa meminta untuk mengartikulasikan bagaimana perasaannya? Ini akan membantunya memahami bahwa penghakiman tidak didasarkan pada sesuatu yang material, tetapi pada penilaian subyektif, yaitu pada perasaan. Sangat penting bahwa ia sampai pada kesimpulan ini sendiri - tidak perlu mengatakan bahwa ia memiliki naluri buruk. Terus bertanya, "Mengapa menurut Anda begitu?" Sampai Anda mencapai terobosan.

Segera setelah manajer mendapatkannya, tunjukkan kepadanya fakta-fakta yang kuat tentang proyek tersebut. Misalnya, jika ia mengatakan "Kualitas produk tidak baik," bayangkan grafik yang menunjukkan penurunan jumlah bug selama beberapa bulan terakhir. Jika dia berkata, "Kami akan siap tepat waktu," berikan daftar tugas yang tidak lengkap dan waktu penyelesaian tugas yang biasa, yang membuktikan sebaliknya. Pada tahap ini, itu hanya masalah pikiran dan logika manajer untuk menang. Jika dia tetap dalam ilusi, ulangi proses sebanyak yang diperlukan.

Pesimis


Seorang manajer yang dengan penuh percaya diri berbicara tentang kegagalan proyek, dan tidak mungkin untuk meyakinkannya tentang hal yang sebaliknya.

  • Dapat bermutasi menjadi salah
  • Berbahaya jika dikombinasikan dengan tester seperti alarm
  • Probabilitas koreksi: tidak
  • Bahaya proyek: sangat tinggi

Masalah


Sebagian besar proyek pengembangan perangkat lunak dapat disebut gagal dari satu sisi:

  • Kelebihan anggaran.
  • Melebihi tenggat waktu.
  • Kurangnya semua fungsi yang diperlukan.
  • Masalah kinerja, stabilitas, atau skalabilitas.
  • Sejumlah besar bug.

Di dunia nyata ini bisa diharapkan, dan kadang-kadang dianggap sebagai realitas yang tak terhindarkan. Tetapi pesimis membuat tuntutan tinggi sehingga proyek tidak dapat memenuhi, jadi dia mengumumkan kegagalannya jauh sebelum kegagalan sebenarnya dari proyek.

Seorang pesimis mudah diidentifikasi oleh dua karakteristik utama:

  1. Dia secara khusus memilih metrik negatif tentang keadaan proyek untuk fokus pada yang negatif, mengabaikan atau mendevaluasi tanda-tanda positif.
  2. Dia bersemangat tentang penampilannya, yang sering penuh dengan drama emosional.

Posisi seperti itu dapat meyakinkan pihak berwenang bahwa proyek itu tidak ada harapan, dan itu benar-benar dibatalkan.

Solusi


Manajer pesimis tidak dapat diperbaiki, karena ia sering tidak bahagia dalam kehidupan pribadinya, tidak puas dengan pekerjaan, karier, atau perusahaan itu sendiri. Dengan demikian, negatifnya tidak ada hubungannya dengan proyek itu sendiri, tetapi merupakan masalah pribadi. Hal terbaik yang dapat Anda lakukan adalah menawarkan konseling psikologis, yang dilakukan beberapa perusahaan. Ini mengarah pada hasil yang sering kali tak terhindarkan: manajer pergi, atau perusahaan menolaknya.

Optimis


Seorang manajer proyek yang telah meyakinkan dirinya sendiri tentang keberhasilan proyek, terlepas dari bukti yang bertentangan.

  • Dapat bermutasi menjadi kapten tim atau melakukan kesalahan
  • Berbahaya bila dikombinasikan dengan pengembang yang optimis
  • Probabilitas Koreksi: Rendah
  • Bahaya proyek: sangat tinggi

Masalah


Sebagai aturan, orang suka bekerja dengan orang positif. Kerugian dari seorang manajer yang optimis adalah bahwa pandangan dunia positifnya tidak memperjelas tanda-tanda peringatan pada proyek . Alih-alih mengambil langkah-langkah untuk memperbaiki masalah, ia lebih suka mengabaikan tanda-tanda ini, menganggapnya sebagai negatif yang tidak sehat, dan alih-alih lebih suka melaporkan yang baik saja. Ini menciptakan budaya puas diri atau putus asa di antara anggota tim, sementara para bos berada dalam ilusi bahwa semuanya berjalan dengan baik.

Dalam posisi kepemimpinan apa pun, optimisme dalam menghadapi kesulitan adalah keuntungan penting. Untuk membedakan manajer yang optimis dari pemimpin yang berani, gunakan tes berikut:

  • Apakah dia merasa bersyukur atas kabar buruknya?
  • Seberapa sering ia membuat pujian yang tidak berdasar?
  • Apakah dia selalu dalam suasana hati yang baik, tidak peduli seberapa rendah moral tim?
  • Apakah dia menghindari konfrontasi, bahkan jika itu dibenarkan?
  • Bukankah orang-orang menyukainya lebih daripada keberhasilan proyek?

Manajer yang optimis sering menyebabkan proyek gagal, karena mengabaikan masalah yang dapat menyebabkan kegagalan. Semakin lama proyek berlangsung, semakin buruk pengaruhnya.

Solusi


Seorang optimis mudah dikacaukan dengan pemimpin yang berani, itulah sebabnya mereka jarang diidentifikasi, dan karenanya jarang dikoreksi. Pada saat kedok optimis muncul, seringkali sudah terlambat karena proyek sudah gagal.

Organisasi berusaha untuk mempromosikan para pemimpin yang berani. Akibatnya, manajer yang optimis memiliki peluang promosi yang lebih tinggi jika ia dapat meyakinkan atasannya bahwa proyek tersebut gagal karena alasan di luar kendali mereka.

Terlepas dari alasan mengapa manajer berperilaku seperti ini - untuk pertumbuhan karir pribadi, tidak ingin menghadapi kebenaran yang tidak nyaman atau hanya kenaifan - kerusakan pada proyek adalah sama. Satu-satunya perbedaan adalah apakah dia dipromosikan atau dipecat.

Kapten tim


Seorang manajer proyek yang berfokus pada membuat semua programmer senang dan tidak pada keberhasilan proyek.

  • Dapat bermutasi menjadi optimis
  • Berbahaya bila dikombinasikan dengan manajer pengembangan pasukan perdamaian
  • Probabilitas koreksi: tinggi
  • Bahaya untuk proyek: rendah

Masalah


Semangat tinggi penting untuk proyek apa pun: pengembang biasanya lebih kreatif dan produktif ketika semangat kerja tinggi. Ketika sebuah proyek berjalan dengan buruk, secara alami, semangat turun sampai situasinya membaik. Pada saat ini, alih-alih menyelesaikan masalah proyek, kapten tim terlibat dalam meningkatkan moral.

Kapten tim dan optimis memiliki sikap positif yang sama, tetapi manifestasinya secara fundamental berbeda:

  • Optimis mengabaikan masalah yang dihadapi proyek, dan melaporkan informasi yang salah kepada pihak berwenang.
  • Kapten tim menganggap keberhasilan proyek semata-mata dalam hal semangat kerja: semangat kerja rendah adalah proyek yang tidak berhasil; moral tinggi adalah proyek yang sukses. Dia berpikir tentang kepentingan pelanggan dan atasan nanti, jika sama sekali.

Kapten tim sangat mudah dikenali:

  • Muncul secara spontan dengan camilan seperti kopi dan donat.
  • Dia menganggap penting untuk mengadakan pembicaraan secara pribadi dengan setiap karyawan, "untuk mendengarkan kebutuhan mereka."
  • Sebagai aturan, dia suka berbicara tentang hal-hal pribadi, tentang kehidupan seorang karyawan di luar pekerjaan (berpikir bahwa ini bisa menjadi sumber ketidakpuasan).
  • Ini mengirimkan surat-surat positif, menempatkan motivator di seluruh kantor dan biasanya terlalu positif.
  • Ia mewakili perabot kantor terbaik, pencahayaan terbaik dan, sebagai aturan, lingkungan kerja terbaik.
  • Sangat berjuang melawan kondisi kerja yang buruk, seperti kurangnya pengembangan karir untuk karyawan, pelatihan yang tidak memadai dan kerja lembur.
  • Mengorganisir pertemuan ekstrakurikuler dengan tim, tidak terikat pada tahapan penting proyek.
  • Sangat khawatir bahwa semua peserta proyek mencintainya.


Orang seperti itu tampaknya seperti manajer proyek yang ideal, tetapi ada dua alasan yang perlu diperhatikan:

  1. Semua peristiwa ini hanya meningkatkan moral sementara, yang dengan cepat memudar ketika orang mengingat realitas proyek.
  2. Mereka tidak menghilangkan penyebab mendasar dari moralitas rendah, lebih memilih insentif jangka pendek.

Dengan demikian, kapten tim pada akhirnya semua orang suka, tetapi sebenarnya tidak melakukan pekerjaan manajer proyek.

Solusi


Masalah utama adalah bahwa kapten tim biasanya tidak memiliki banyak pengalaman sebagai manajer proyek. Karena itu, solusinya adalah melatihnya. Untungnya, ada sejumlah besar sumber daya pelatihan untuk manajer proyek.

Memberikan manajer dengan alat yang diperlukan, perlu mendorongnya untuk mengidentifikasi akar penyebab rendahnya semangat, dan kemudian memperbaikinya. Mempertimbangkan kecenderungan alami kapten tim untuk meningkatkan mood karyawan, dia pasti akan melakukan upaya agresif untuk menemukan dan memperbaiki akar penyebab kemerosotan moral begitu dia mengerti apa yang harus dicari.

Pada tahap ini, Anda mendapatkan seorang manajer proyek dengan campuran motivasi yang sangat kuat: pertama, ia menggunakan moralitas sebagai ukuran masalah dalam proyek, dan kedua, ia menemukan masalah ini dan memperbaikinya. Karena motivasinya berasal dari belas kasihan terhadap sesamanya, masalah yang mendasari moralitas rendah akan cepat diberantas.

Ngomong-ngomong, dalam karakter mereka untuk bersikap baik kepada orang lain, oleh karena itu tidak mungkin untuk "menyembuhkan" mereka dari komponen ini, dan "koreksi" mereka seharusnya tidak menyiratkan penghapusan bagian-bagian positif dari karakter. Pada akhirnya, jika mungkin untuk meningkatkan level manajer proyek, sulit untuk menemukan opsi yang lebih baik untuk investasi semacam itu daripada kapten tim.

Tiruan


Seorang manajer yang memperlakukan anggota proyek dengan penghinaan atas nama motivasi mereka untuk bekerja lebih keras.

  • Dapat bermutasi menjadi pesimis
  • Berbahaya dalam kombinasi dengan pengembang seperti tentara dan gajah di toko cina
  • Probabilitas koreksi: tinggi
  • Bahaya proyek: sangat tinggi

Masalah


Banyak kepribadian yang kuat biasanya terlibat dalam proyek pengembangan perangkat lunak, tetapi setiap orang harus tunduk pada satu tujuan masing-masing dan fokus pada implementasi proyek. Oleh karena itu, manajer proyek memiliki wewenang untuk memimpin peserta proyek untuk memastikan keberhasilan proyek. Sang tiran menyalahgunakan kekuatan ini, menggunakan penguatan negatif untuk mencapai hasil.

Sementara para tiran mungkin tidak disukai, para bos sering kali percaya bahwa "tangan teguh" mereka adalah apa yang dibutuhkan untuk keberhasilan suatu proyek, terutama jika itu tidak sesuai jadwal. Ancaman dan hukuman sebenarnya bertindak sebagai motivator bagi banyak tipe kepribadian (lihat pengembang seperti tentara ), yang membantu menyebarkan tiran.

Masalah aktual dengan tiran sulit dideteksi, tetapi mereka sangat berbahaya bagi proyek.

  • , , , .
  • , , , .

Semakin lama seorang tiran bekerja, semakin dramatis sederetan bakatnya. Pada akhirnya, begitu semua peserta proyek yang kompeten dikeluarkan, tidak mungkin mengundang peserta yang berbakat dan berpengalaman ke proyek, karena karyawan potensial tidak ingin bekerja dengan tim yang tidak kompeten (fakta yang mudah muncul selama wawancara).

Penting untuk dicatat bahwa tiran biasanya diperkenalkan ke proyek pada saat yang paling tidak tepat: ketika proyek dalam kesulitan. Proyek yang berisiko gagal harus mencampakkan anggota tim yang tidak kompeten, dengan tetap mempertahankan yang kompeten, tetapi tiran itu menyebabkan efek sebaliknya.

Solusi


Untuk mengoreksi seorang tiran, perlu untuk menyadarkannya bahwa perilaku semacam itu mempengaruhi proyek secara negatif. Ada dua pendekatan umum untuk ini:

Pertama, berikan data kuantitatif yang mencerminkan gaya manajemen proyek mereka:

  • Berapa banyak karyawan berharga yang meninggalkan negara bagian.
  • Sukses dalam menarik bakat.
  • Berapa banyak fitur yang dirilis.
  • Berapa banyak bug yang terdaftar.
  • Berapa banyak kencan yang hilang.

Ketika membandingkan informasi ini, garis waktu sangat efektif.

Kedua, beri tahu mereka indikator apa yang Anda harapkan dalam waktu dekat. Kemungkinan besar, mereka akan menunjukkan kejengkelan dan keputusasaan, karena mereka tidak tahu bagaimana memperbaiki indikator-indikator ini. Tetapi ini adalah kesempatan yang ideal untuk memberi mereka nasihat dan pelatihan tentang cara menjadi manajer yang lebih baik. Pelatihan harus mencakup hal-hal berikut:

  • Bagaimana mereka berperilaku dengan karyawan.
  • Bagaimana mereka membahas kegagalan dan keberhasilan proyek.
  • Cara mengidentifikasi dan menyingkirkan peserta proyek yang tidak kompeten.
  • Cara menarik dan mempertahankan peserta yang kompeten.

Asalkan ada spesialis yang cocok untuk pelatihan seperti itu, maka manajer-tiran dapat sepenuhnya diperbaiki, karena karakteristik berikut secara alami melekat pada diri seseorang:

  • Orang tidak ingin menjadi jahat.
  • Orang suka dicintai.
  • Orang suka menjadi efektif.

Yang terpenting adalah tim mengambil pendekatan baru, terlepas dari reputasi tiran di masa lalu. Masalahnya dapat diselesaikan dengan sangat sederhana, misalnya, untuk mengadakan pertemuan dengan tema "Saya minta maaf" dan "Saya telah berubah menjadi lebih baik."

Terobsesi dengan prosesnya


Manajer sangat terobsesi dengan proses yang dia lupa tentang tugasnya - untuk membantu proyek mencapai kesuksesan.

  • Dapat bermutasi menjadi tiran
  • Berbahaya bila dikombinasikan dengan manajer produk jenis diktator
  • Probabilitas koreksi: tinggi
  • Bahaya untuk proyek: rendah

Masalah


Pada akhir kursus pelatihan atau membaca buku apa pun tentang manajemen, setiap manajer menghadapi risiko menjadi terobsesi dengan proses tersebut. Ini dapat terjadi bahkan dengan yang terbaik, jadi kesabaran penting ketika mengoreksi mereka.

Ada dua kategori besar proses yang terobsesi dengan:

  1. Obsesi air terjun
  2. Obsesi dengan pengembangan lincah (Agile)

Mungkin kursus pelatihan atau buku menyebut proses ini secara berbeda, tetapi Anda dapat dengan mudah menempatkannya dalam kategori yang benar dengan menerapkan tes berikut:

  • Terobsesi dengan air terjun percaya bahwa semua masalah dapat diselesaikan dengan bantuan dokumentasi tambahan, misalnya, "mulai sekarang kami akan menulis persyaratan sistem untuk setiap dokumen dengan persyaratan bisnis".
  • Mereka yang terobsesi dengan pengembangan gesit percaya bahwa semua masalah dapat diselesaikan dengan bantuan pertemuan singkat yang sering, misalnya, "mulai sekarang kita akan mengatur pertemuan harian di pagi hari tidak lebih dari 15 menit".

Tujuan setiap manajer adalah untuk memberikan proyek tepat waktu dan sesuai anggaran. Proses yang kami gunakan memfasilitasi ini. Ketika manajer proyek menjadi terobsesi, ia dapat mengabaikan tujuan utama, dan sebaliknya fokus pada pertanyaan "Apakah prosesnya berjalan dengan benar?" merugikan tugas resmi lainnya.

Solusi


Apa pun yang Anda lakukan, jangan mencoba merampok mereka dari proses atau menantangnya. Anda berurusan dengan seorang fanatik agama daripada orang yang rasional. Dia meyakinkan dirinya sendiri bahwa prosesnya akan "memperbaiki" proyek. Jika mereka berpikir proyek itu "rusak," dan Anda mencoba mengatakan "itu tidak akan membantu kami," mereka hanya akan menganggap Anda bagian dari alasan proyek itu rusak.

Sangat mudah untuk memperbaiki proses yang terobsesi: cukup puas dengan semua yang dia katakan, dengan lembut mengingatkan bahwa "butuh waktu untuk mengubah kapal besar" dan "Roma tidak dibangun dalam satu hari". Intinya adalah memaksanya untuk menyetujui implementasi proses baru melalui serangkaian inovasi kecil, bukan perubahan besar. Ini akan memungkinkan mereka untuk belajar dari pengalaman mereka sendiri metode mana yang efektif dan mana yang tidak. Dengan mendapatkan pengalaman ini, mereka akan belajar bagaimana menyesuaikan proses dengan situasi di lapangan. Ada harapan bahwa mereka akan mengerti: proses adalah sarana untuk mencapai tujuan, bukan tujuan itu sendiri.

Tidak yakin


Seorang manajer proyek yang terus-menerus meminta status karyawan saat ini, menganggap perlu bahwa mereka fokus memenuhi tugas-tugas mereka.

  • Dapat bermutasi menjadi statistik
  • Berbahaya dalam kombinasi dengan pengembang seperti tentara dan gajah di toko cina
  • Probabilitas koreksi: tinggi
  • Bahaya untuk proyek: rendah

Masalah


Ketika seorang manajer duduk di mejanya jauh dari peserta proyek yang melakukan pekerjaan itu, ia dapat dengan mudah memiliki perasaan tidak berharga. Ini membuat mereka melakukan apa pun yang diperlukan untuk merasa diri mereka perlu dan berguna. Untuk manajer yang tidak pasti, cara yang paling jelas untuk terlihat produktif adalah dengan memeriksa pekerjaan karyawan saat ini. Ini sering dicapai dengan menggunakan metode berikut:

  • Distribusi email yang meminta status proyek.
  • Jadwalkan rapat untuk membahas status.
  • Persyaratan untuk mengisi lembar waktu secara terperinci.
  • Persyaratan untuk memecah tujuan menjadi tugas-tugas kecil.
  • Mengorganisir pertemuan tatap muka spontan untuk bertanya kepada anggota tim tentang status mereka.

Manajer yang tidak aman dikenal luas dengan nama lain: manajer mikro. Metode manajemen proyeknya ditafsirkan oleh anggota tim proyek sebagai salah satu atau semua hal berikut ini:

  • Nitpicking
  • Pelecehan
  • Kekhawatiran
  • Gangguan
  • Gangguan
  • Mengganggu

Seringkali, karyawan mengembangkan kebencian yang dalam terhadap manajer proyek yang tidak pasti, karena dalam persepsi mereka:
  • Manajer tidak mempercayai keterampilan manajemen waktu mereka.
  • Manajer tidak percaya penilaian mereka terhadap persyaratan.
  • Manajer tidak mengerti kebutuhan sendirian untuk menyelesaikan masalah.
  • Manajer tidak ada hubungannya selain bertanya dan melaporkan status.

Persepsi ini menciptakan konfrontasi antara manajer proyek dan pengembang, menekan komunikasi yang bermanfaat yang dapat digunakan manajer untuk memperbaiki masalah nyata. Alih-alih berinteraksi dengan manajer semacam itu untuk kerja sama dan kerja sama, pengembang menghindari kontak tambahan dengannya, takut mereka akan (sekali lagi) ditanya statusnya.

Solusi


Manajer yang tidak aman sangat umum sehingga perilaku seperti itu dianggap sebagai pekerjaan utama manajer. Dengan asumsi yang tidak terhindarkan, sebagian besar pengembang membentuk ambang tertentu, seberapa sering mereka akan diminta untuk status mereka saat ini. Karena sebagian besar telah belajar untuk beradaptasi dengan pengejaran status yang konstan, seorang manajer yang merasa tidak aman tidak menimbulkan risiko tinggi bagi proyek, meskipun hal itu menghilangkan kemungkinan komunikasi yang bermanfaat bagi tim yang dapat terjadi.

Manajer seperti itu lahir karena fakta bahwa kinerja tim tidak terlihat olehnya. Jadi solusinya adalah menempatkan manajer ini di sebelah tim. Jika tidak, manajer ini diatasi oleh keinginan untuk langsung menanyakan status setiap pengembang. Jika mereka ada di dekatnya, maka manajer dapat memahami keadaan proyek saat ini, hanya dengan menguping pembicaraan para pengembang di antara mereka sendiri. Dalam mode ini, manajer paling efektif, karena ia hanya perlu melakukan intervensi ketika produktivitas sangat sulit.

Lihat juga:

Source: https://habr.com/ru/post/id431802/

More articles:


All Articles