Trik untuk mewawancarai manajer proyek atau berjalan melalui ladang ranjau yang penuh keajaiban

ketika mereka meminta saya untuk permainan
Kegilaan adalah ketidakmampuan untuk melihat lapisan yang menghubungkan delirium dan kenyataan. Stephen E. King
Setelah diwawancarai pada akhir tahun sebagai manajer proyek, saya bertemu banyak pertanyaan yang mungkin tampak seperti omong kosong terakhir atas nama hr'ov dan atas nama spesialis yang berkualitas. Tentu saja, masing-masing perusahaan aneh dengan caranya sendiri, tetapi tujuan dari beberapa masalah masih menjadi misteri bagi saya.

Seorang manajer proyek adalah seorang spesialis yang harus selalu berada dalam konteks. Mustahil untuk memahami tujuan bisnis dan latar belakang penerapannya tanpa pertanyaan: mengapa? kenapa bagaimana Pada wawancara, tujuan manajer adalah untuk memberikan jawaban yang jelas untuk pertanyaan yang diajukan dengan memasukkan konteksnya. Oleh karena itu, saya selalu berusaha untuk tidak memperhatikan "permainan" yang hadir di wawancara, dan untuk alasan bahkan pada pertanyaan yang tampaknya paling bodoh.

Semua manajer sangat menyadari bahwa wawancara itu berjalan tidak tergesa-gesa, selama satu jam melalui ladang ranjau. Pernyataan ini ditunjukkan dengan sempurna oleh sepeda manajer lama: “Perusahaan pertama bertanya kepada saya apa yang akan saya lakukan jika tim tidak punya waktu untuk rilis: apakah saya akan bertanya kepada tim tentang lembur atau apakah saya akan menulis kode sendiri? Saya menjawab bahwa saya akan duduk untuk menulis kode sendiri, dan mereka menolak saya dengan motivasi: "tidak diterima dengan kami". Perusahaan kedua mengajukan pertanyaan yang sama kepada saya, dan saya menjawab bahwa saya akan meminta tim untuk lembur, dan penolakan berikutnya terhadap perusahaan ini dimotivasi oleh kenyataan bahwa mereka tidak melakukannya. Di perusahaan ketiga, saya sekali lagi menghadapi pertanyaan yang tidak menguntungkan ini, dan jawabannya adalah pertanyaan - bagaimana kebiasaan Anda? "

Karena itu, terutama bagi para pembaca Habr, saya menuliskan pertanyaan-pertanyaan paling menarik menurut pendapat saya dan memutuskan untuk menganalisis jawaban yang mungkin bagi mereka. Pertanyaan akan menjadi delusi dan masuk akal.

1) Anda memiliki tim scrum pengembang dan penguji. Pengembang bekerja, mengevaluasi tugas dalam poin sejarah, dan penguji dalam hitungan jam. Penguji ditugaskan memprogram tombol, tetapi dia tidak tahu bagaimana menggunakan poin sejarah. Bagaimana menjelaskan kepadanya metodologi untuk mengevaluasi tugas yang akan dia gunakan?

Kadang-kadang scrum mencapai titik absurditas. Dalam menjawab pertanyaan ini, perlu dicatat bahwa dalam scrum tim-tim tersebut bersifat universal, tetapi dalam arti yang berbeda. Konteks dalam hal ini secara keseluruhan tidak terlalu penting. Anda hanya perlu menjelaskan kepada karyawan bagaimana poin cerita dipertimbangkan. Anda perlu mengambil tugas-tugas sebelumnya, menuliskannya di selembar kertas dan menawarkan untuk membandingkannya dengan skala fibonacci, menjelaskan kepadanya konsep titik cerita: jumlah pekerjaan * kompleksitas * risiko. Setelah itu, penguji akan dapat membandingkan tugas mengembangkan tombol dengan tugas-tugas yang telah diselesaikan sebelumnya dalam hal kompleksitas dan, dengan demikian, dengan nilai dalam poin sejarah.

2) Apa yang harus saya lakukan jika karyawan jauh kehilangan kinerja?

gambar

Pertanyaan paling abstrak yang bisa Anda tanyakan. Budaya dan nilai-nilai perusahaan terutama bertanggung jawab atas pekerjaan yang nyaman dari sang pembuat jarak jauh. Jika sebuah perusahaan memiliki komunikasi berkualitas tinggi, misalnya, diskusi bersama aktif mengenai tugas dan masalah di messenger yang nyaman memungkinkan karyawan yang jauh merasakan nilai mereka dan masuk ke dalam pekerjaan tim dan perusahaan, ketika komunikasi dibatasi hanya satu huruf per hari pulang pergi, seseorang tidak merasa terhubung dengan rekan kerja . Juga, ketika tugas hanya terbang ke master dan dilepaskan untuk dijual tanpa umpan balik dan menandai keberhasilan setiap karyawan selama berbulan-bulan, karyawan mulai merasa terisolasi dari tim, ia menempatkan kekuatan dan emosinya ke dalam pekerjaannya, tetapi tidak menerimanya sebagai respons, Sehubungan dengan ini, kelelahan emosional dimulai bahkan tanpa kerja berlebihan. Oleh karena itu, perlu untuk mengajukan pertanyaan bukan mengapa karyawan itu buruk, tetapi apa yang meredam motivasinya untuk mengerjakan tugasnya, dan kemudian menyelesaikannya.

3) Seorang karyawan terlambat setiap hari pada rapat harian, apa yang harus saya lakukan?

"Dia tidak berbagi nilai-nilai tim dan perusahaan, mengapa kita membutuhkan karyawan seperti itu?" - Begitu saya mendengar ungkapan seperti itu dari jam, dan saya pikir, apakah benar-benar layak menjaga seseorang yang tinggal 80 kilometer dari kantor, mereka tidak memberinya remote, dan di pagi hari dia selalu terlambat karena kemacetan lalu lintas jam 9 pagi?

Ketika saya menjawab, saya sudah maksudkan bahwa Anda, sebagai scrum master atau manajer proyek, mencoba menjelaskan dua kali kepada karyawan betapa pentingnya aksi harian bagi gerakan keseluruhan tim menuju tujuan dalam aliran yang berkelanjutan.

Demonstrasi, di samping aturan internal untuk perilaku yang efektif, juga harus memiliki aturan untuk penunjukan mereka untuk kunjungan nyaman mereka:

  • Cari tahu dari peserta rapat umum waktu yang tepat untuk semua orang, mungkin seseorang memiliki risiko tinggi terlambat selama 10-15 menit, di mana rapat umum akan berakhir, atau mungkin peserta dalam rapat umum memiliki zona waktu yang berbeda dan seseorang akan memiliki waktu Anda pada pukul 9:00 waktu Moskow jam 5 pagi;
  • Persiapkan tempat untuk aksi unjuk rasa sehingga anggota tim tidak melepaskan diri dari rapat di mana mereka harus berteriak untuk saling mendengar di tengah ruang terbuka;

Semua orang berbeda - ini disangkal. Seseorang kurang terorganisir, sebagian lagi, jika semua kondisi untuk menghadiri rapat umum yang nyaman terpenuhi, tetapi seorang karyawan yang terpisah dan sedikit terorganisir masih tidak ingin tiba di pertemuan tepat waktu, maka pemicu tanpa kekerasan dapat diperkenalkan untuk meningkatkan motivasi karyawan tersebut, misalnya:

  • Untuk memberikan sedikit percikan dopamin di awal rapat umum dengan menceritakan tentang pencapaian perusahaan atau departemen, mengucapkan selamat kepada seseorang atas prestasi atau liburan, tentang kabar baik di industri. Pada hari-hari acak, Anda bisa meletakkan kue kecil di atas meja di awal pertemuan (dan mengapa tidak?);
  • Mainkan permainan "yang tidak punya waktu - dia terlambat." Siapa yang terlambat - yang memimpin rapat mencatat 2 pertemuan berikut, misalnya. Hal ini memungkinkan Anda untuk membawa rasa kejahatan komik ke awal pertemuan, dan untuk mengkonfirmasi kepada mereka yang datang bahwa kedatangan tepat waktu mereka adalah perilaku yang tepat dalam tim dan perusahaan.
  • Mungkin hal utama yang tidak boleh Anda lakukan adalah denda finansial. Menurut undang-undang perburuhan Federasi Rusia, Anda tidak dapat membuat pengurangan dari gaji, dan komponen motivasi, sebagai suatu peraturan, cukup rendah untuk “mengenai” saku karyawan dan, oleh karena itu, memotivasi dia.

4) Perbedaan antara air terjun dengan gelombang bebas dan scrum?

Terus bekerja dengan metodologi, tidak sulit untuk menjawab pertanyaan ini. Waterfall dan Scrum adalah tentang proses. Metode gelombang bebas adalah metode perencanaan. Oleh karena itu, kami mendapatkan pertanyaan jebakan di mana metode gelombang datang merupakan kondisi yang tidak perlu, dan pertanyaan itu dirancang untuk pemahaman Anda yang jelas tentang metodologi air terjun dan scrum. Scrum adalah model berulang yang memungkinkan Anda untuk mengambil proyek untuk bekerja sampai Anda mendapatkan jumlah persyaratan penuh, di mana Anda dapat mengubah persyaratan produk, dan proses pengulangan berulang. Air terjun adalah indikasi yang jelas tentang persyaratan produk di masa depan, dan penyimpangan dari mereka memecah proses. Dan Anda dapat merencanakan apa pun dengan metode pendekatan gelombang. Ngomong-ngomong, siapa pun yang mengatakan sesuatu tentang kelembaman air terjun, tetapi bahkan PMBOK tidak melarang penggunaan Rolling Wave Planning dengannya.

5) Pada aksi unjuk rasa, beberapa rekan kerja Anda tidak memberi tahu tim tentang keberhasilan persalinan kemarin, tetapi "laporkan" kepada Anda, apa yang harus saya lakukan?

Untuk menjawab pertanyaan, Anda harus menerapkan situasi itu pada diri Anda sendiri jika Anda tidak jatuh ke dalam situasi seperti itu. Untuk mengatasi masalah, Anda dapat menggeser fokus perhatian. Jika kolega Anda berbicara tentang kemarin, lihat saja anggota tim yang lain, dan kolega Anda secara tidak sadar akan mengalihkan fokusnya ke yang Anda lihat. Juga, setiap pertemuan dapat mengubah lokasinya di antara kolega.

6) Misalkan karyawan memiliki manajer + manajer lini + 2 manajer lebih dari proyek lain (karyawan bekerja pada beberapa proyek pada saat yang sama), dan dua atau tiga manajernya menetapkan satu kali tugas mendesak, apa yang harus dia mulai?

gambar

Sebuah pertanyaan dari kategori masalah matematika: “Vasya membeli 1000 pisang ...”. Mengapa
Dengan hierarki seperti itu di perusahaan, ketidaksepakatan antara komponen manajerial tidak dapat dihindari, pengembang tidak boleh terlibat dalam situasi seperti itu dan masuk ke dalam pembongkaran independen antara 10 manajer, yang tugasnya lebih diprioritaskan, karena ini ada manajer tim atau manajer langsungnya.

7) Perbedaan antara pemimpin tim dan pemimpin tim?

Jelas, pemimpin teknis adalah spesialis teknis paling kuat. Dengan pemimpin tim, semakin sulit setelah pemimpin tim tidak ditafsirkan dari perusahaan ke perusahaan. Mungkin ini adalah salah satu spesialisasi paling subjektif di bidang TI. Misalkan seorang pengembang datang untuk wawancara, dan mereka bertanya kepadanya: "Bagaimana menurut Anda, apa yang dilakukan tim pemimpin?" Dan pemimpin tim pengembang di pekerjaan sebelumnya tidak hanya mengarahkan tim dan di bagian-bagian itu adalah spesialis yang keren, tetapi juga berhasil melayani mesin kopi, dan menggambar peta jalan untuk manajer proyek. Siapa yang tidak bertanya - setiap orang memiliki interpretasinya sendiri. Satu-satunya jawaban yang dapat diberikan untuk pertanyaan ini adalah: "Tunjukkan deskripsi pekerjaan Anda untuk pemimpin tim dan pemimpin tim, dan saya akan memberi tahu Anda apa perbedaannya".

8) Bagaimana cara menjelaskan kepada para pengembang tentang nilai poin pembangunan?

Siapa pun yang mengatakan apa pun, tetapi untuk pengembang, nilai utama dari poin pembangunan adalah kemudahan perhitungan dan dimasukkannya risiko dalam penilaian ini, yang bertentangan dengan penilaian per jam. Ketika mengevaluasi dengan poin bangunan, pengembang tidak harus memikul kewajiban untuk menyelesaikan tugas, misalnya dalam 2 jam, sehingga segera setelah berakhirnya waktu mereka mulai menarik dengan permintaan untuk hasilnya. Waktu yang diinvestasikan dalam penilaian untuk menyelesaikan masalah yang mungkin timbul memungkinkan Anda untuk bekerja dalam mode yang nyaman tanpa tekanan yang tidak perlu dan kunjungan manajer yang konstan dengan persyaratan untuk menyerahkan tugas.

9) Bagaimana cara menjelaskan nilai scrum kepada pengembang?

Sebagai mantan pengembang, saya dapat menulis seluruh pendekatan Agile, termasuk kerangka kerja SCRUM, karena kehidupan anggota tim menjadi lebih mudah, mari kita ambil beberapa poin:

  • Kehadiran manajemen direktif yang luar biasa langka dan hanya dalam situasi kritis. Artinya, semua tugas direncanakan untuk sprint ke depan, dan secara teori tidak ada yang bisa mengubahnya, dalam praktiknya force majeure kadang terjadi, tetapi tidak ada yang aman dari ini.
  • Tanggung jawab kolektif, tim scrum tidak akan dapat mengalihkan tanggung jawab atas kualitas produk kepada peserta individu.
  • Pemilik produk hanya memprioritaskan tugas dalam jaminan simpanan, tetapi tidak mengelola tugas tim dalam pengertian klasik kata-kata ini. Tim, bekerja sama dengan pemilik produk, memutuskan sendiri tugas apa yang akan diambil sprint berikutnya.

Anda dapat menulis banyak poin tentang nilai scram, jika poin utama tidak meyakinkan pengembang dari tim Anda, maka Anda dapat menggunakan pendapat kolega lain tentang pendekatan ini, misalnya, salah satu mantan kolega saya menjawab pertanyaan ini:

“Dalam perintah scrum, proses didebug. Anda memiliki rencana sprint dan, sebagai suatu peraturan, tidak ada arahan mendesak mendesak dari formulir: "letakkan semuanya, tugas mendesak baru telah tiba". Tim memantau waktu dan pengembangan menjadi dapat diprediksi, Anda dapat merencanakan. Karena ini, tugas saat ini dalam sprint memiliki beberapa kunci. Sebagai seorang pengembang, saya ingin bahwa ketika saya mengambil tugas saya, semuanya sudah siap untuk itu: baik bagian belakang maupun desainnya digambar. Tidak perlu berlari dan mengguncang orang lain. "

Jika nilai scrum masih tidak diterima, maka membaca Panduan Scrum akan menjadi pilihan terakhir. Dan mungkin tim Scrum Anda memiliki keputusan yang buruk (Pikirkanlah).

Ringkasnya , saya ingin memberikan rekomendasi kepada manajer dari semua spesialisasi tentang perilaku selama wawancara - menganggap “permainan” apa pun sebagai kasus baru untuk dianalisis, karena “permainan” sering muncul tidak hanya dalam masalah tetapi juga dalam kehidupan, dan kemudian seiring waktu akan menjadi untuk Anda frasa yang relevan adalah: "Siapa pun yang bekerja dengan pm, tidak menertawakan sirkus".

PS Jika Anda memiliki pertanyaan pm yang menarik, pastikan untuk meninggalkannya di komentar!

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


All Articles