Setiap pemimpin tim memiliki kuburan sendiri kesalahan manajemen karyawan . Setiap hari artikel baru diterbitkan: "5 kesalahan pengembang pemula", "7 contoh bagaimana Anda tidak perlu mengelola proses", "100 dan 1 cara untuk memenuhi tenggat waktu". Dan ini luar biasa!
Rake orang lain menghemat waktu Anda, membuat Anda berani, tepukan di bahu dan menjelaskan bahwa Anda bukan satu-satunya yang "membuat saya", dan semua ini berlalu.
Kesalahan menurut Ozhegov adalah kesalahan dalam pikiran atau tindakan, dan, mungkin, pada saat yang sama. Tetapi bagaimana seorang pemula dengan berbagai tanggung jawab baru dapat melakukannya tanpa mereka? Mungkin tidak ada, tetapi Anda bisa mencoba melunakkan pukulan. Pada contoh saya, saya akan berbicara tentang kesalahan-kesalahan yang tidak bisa saya hindari dalam proses menjadi saya sebagai pemimpin. Saya harap setiap cerita tersenyum pada Anda, karena Anda akan mengingat diri Anda masa kecil awal perjalanan Anda, atau itu akan membuat Anda berpikir tentang cara menghindari menginjak menyapu sendiri.
Latar belakang
Selama 6 tahun terakhir, saya telah mengabdikan pengujian untuk mengubah beberapa perusahaan dan tim untuk mendapatkan pengetahuan yang relevan dan dapat diandalkan tentang cara membuat produk berkualitas tinggi dan apa peran yang dapat dimainkan oleh penguji dan insinyur dalam proses ini. Kadang-kadang alasan untuk pergi adalah kurangnya kesempatan untuk belajar dari kolega penguji yang kuat (dan ini diperlukan di awal jalan), karena mereka sama sekali tidak ada. Saya menguji kekuatan saya dalam pengujian manual dan otomatis. Dan tepat setelah saya memompa dalam otomatisasi bahwa saya memiliki kesempatan untuk mencoba sendiri sebagai penguji memimpin dengan pelatih Agile yang berpengalaman.
Bagi saya, itu seperti dunia terbalik pada saat itu. Kebiasaan mengajukan solusi dan mengimplementasikannya secara mandiri menjadi lebih kuat dan tidak ingin meninggalkan saya. Ternyata gaya kerja insinyur otomasi tidak cocok dengan peran baru pemimpin sekelompok kecil orang. Mari kita beralih ke detailnya.
Kesalahan
Manajer No. 1 "Di Sini dan Sekarang"
Saya lebih baik dalam menyelesaikan masalah poin "di sini dan sekarang", tetapi ini tidak selalu membawa tim lebih dekat ke tujuan yang mereka nyatakan.
Pertimbangkan sebuah contoh. Pada awal pembentukan format QA baru di Dodo, setelah berkenalan dengan cara kerja pengujian dan keinginan semua orang untuk memulai otomatisasi kemarin, saya memutuskan bahwa itu harus dimulai dalam waktu dekat. (Bagaimana kami mengubah proses dapat ditemukan dalam laporan "Alice in the QA Country" ) Kami semua benar-benar ingin menyelamatkan mereka dari rutinitas harian pengujian regresi manual di 9 negara.
Mengikuti prinsip "menyelesaikan masalah di sini dan sekarang", kami mengorganisir pertemuan dengan penguji, membuat peta tindakan, menetapkan prioritas, mengalokasikan waktu untuk setiap penguji untuk mengotomatisasi, dan mengatur tentang melaksanakan tugas dari peta. Pertama-tama, kami memutuskan alat dan mempresentasikan rencana kami untuk mempercepat regresi pada rapat umum TI. Penguji bersukacita pada tes yang muncul dan percaya pada pembuangan awal rutin manual.
Namun, ternyata kami melakukan pengujian yang menghabiskan banyak waktu pada penguji, tetapi pada saat yang sama secara praktis tidak pernah berubah oleh pengembang dan hanya berdampak kecil pada proses bisnis.
Apa yang harus dilakukan Tips topi
Untuk memahami masalah lebih dalam, untuk mencari penyebab, bukan konsekuensi. Sangat mungkin bahwa harapan Anda bahwa penguji adalah gudang utama pengetahuan tentang sistem dari sudut pandang pengguna sangat berlebihan. Layak memanggil berbagai perwakilan perusahaan IT ke pertemuan pertama, meminta bantuan untuk memfasilitasi pertemuan dengan scrum-master, setelah sebelumnya berdiskusi dengan dia apa hasil yang ingin Anda terima.
Manajer No. 2 "Insinyur Berpengalaman"
File kedua saya adalah "tutup" seorang insinyur berpengalaman. Semua tugas yang paling sulit datang kepada saya.
Pembentukan PageObject, implementasi serangkaian metode dasar untuk bekerja dengan sistem kami, skrip peluncuran di CI / CD - saya memutuskan untuk menggunakannya sendiri karena kebiasaan. Saya tidak mulai mendelegasikan komunikasi dengan tim produk, insinyur infrastruktur, dan wawancara, dan teks lowongan. Menurut mentor, tim QA kami adalah "hijau" (pendatang baru) dalam segala hal. Tentu saja, saya memutuskan untuk pertama-tama mengajari mereka apa yang saya ketahui sendiri, mengamati pekerjaan mereka untuk berbagi tugas dari waktu ke waktu.
Masalahnya adalah bahwa dengan jumlah pertemuan (rapat umum, rapat tim, pelatihan internal, 1 & 1, wawancara, hari ujian) yang jatuh di pundak saya, saya berhenti jatuh ke jam kerja dengan tugas-tugas saya. Delapan jam sehari tidak cukup, dan saya mulai mengkompensasi hal ini dengan waktu luang saya, yang saya habiskan untuk coding, teks, persiapan untuk wawancara dengan kandidat. Sisa arloji berharga yang saya habiskan bersama orang-orang bersama-sama dengan tujuan pelatihan dan pengembangan bertahap proyek dengan tes otomatis. Pergantian konteks saya setiap atau dua jam memperlambat kami di semua lini: otomatisasi, komunikasi QA dengan perintah, dan banyak lagi. Rendahnya tingkat pembentukan insinyur QA keren dan otomatisasi proses membuat saya bekerja pada akhir pekan untuk membuat rencana lima tahun dalam beberapa bulan.
Apa yang harus dilakukan Tips topi
Jangan takut untuk mendelegasikan tugas. Setiap orang memiliki hak untuk membuat kesalahan dan Anda tidak boleh mengambilnya, tidak peduli bagaimana Anda dihipnotis oleh pemimpin tim lain atau mentor. Orang-orangmu sendiri harus mau mempercayaimu dan mengikuti kamu, selalu bereksperimen. Berkumpul, tentukan proses mana yang bisa diperbaiki, siapa di antara mereka yang siap mempromosikannya, dan mungkin beberapa dari mereka dapat ditransfer ke luar tim Anda. Seorang fasilitator yang berpengalaman akan membantu memastikan bahwa solusi yang dipilih bersama tidak hanya di atas kertas. Tim efektif independen adalah apa yang harus diperjuangkan setiap pemimpin.
3 Manajer “Sisi kebalikan dari manajemen mikro”
Kesalahan lain adalah sering manajemen mikro. Saya harus menghadapi sisi lain - kontrol ketat implisit.
Berusaha menghindari pemantauan setiap langkah anak-anak dan membatasi bagian depan pekerjaan, saya mulai "memaksakan" kemungkinan "tidak terbatas" pada anak-anak: rencana pengembangan, tugas penelitian, pidato, kursus, organisasi pertemuan, kunjungan ke perusahaan lain dan kegiatan lainnya. Niat baik - melatih, memompa dan mengasah keterampilan, memperluas wawasan seseorang, membuat kenalan baru di bidang profesional. Ini semua yang sangat kurang ketika saya mulai bekerja sebagai penguji. Masalahnya adalah bahwa tim menginginkan hak untuk memilih: untuk berbicara atau tidak, untuk menonton atau tidak, tetapi saya mendorong mereka ke dalam kerangka kerja yang ketat.
- Teman-teman, kita sedang melakukan mitap. Kami membutuhkan peran berikut, hadiah, akan ada pembicara seperti itu. Tanpa bantuan Anda, kami tidak dapat membuat acara yang berkesan.
- Guys, pada bulan Desember akan ada Heisenbug. Saya sudah memesan siaran online untuk kami, memesan ruang rapat, dan pada hari Sabtu saya akan menyiarkan dari komputer di rumah saya. Semua untuk?
- Teman-teman, minggu ini kita akan mengunjungi Odnoklassniki untuk berkenalan dengan bagaimana otomatisasi dibangun.
Peluang ini dianggap sebagai batasan, yang sangat tidak disukai semua orang. Inisiatif saya terlihat tidak terbantahkan, dan yang paling penting, itu tidak seefektif yang diharapkan.
Apa yang harus dilakukan Tips topi
Perawatan yang berlebihan untuk anak mengarah pada fakta bahwa ia tumbuh kekanak-kanakan atau mulai melakukan yang sebaliknya meskipun orang tua. Tampaknya hal yang sama dapat dikatakan tentang kepedulian pemimpin terhadap timnya. Memotivasi, bukan memaksa, mengumpulkan topik pada topik "Bagaimana kita bisa memperluas cakrawala kita di IT?" dan dengarkan baik-baik kolega, jangan mulai dari ambang pintu untuk menyebutkan semua cara yang Anda ketahui. Dan yang paling penting, jangan mengejar kolega Anda dengan proposal untuk berbicara di konferensi dan mendapatkan kelas master yang menarik. Umumkan peluang - itu sudah cukup.
Manajer No. 4 “Di mana pun mereka melakukannya”
Mungkin beberapa solusi yang bekerja untuk Anda sebelumnya di tim / perusahaan lain tidak akan menemukan dukungan dalam kondisi baru dan gagasan kolega yang jauh dari bidang pengujian perangkat lunak, tetapi keren dalam pengembangan, akan terwujud. Argumen bahwa keputusan Anda didukung dan terus dikembangkan secara aktif berdasarkan komunitas tidak mungkin meyakinkan siapa pun untuk melakukan hal yang sama, tetapi pada tumpukan teknologi lokal.
Apa yang harus dilakukan Tips topi
Yang terpenting adalah jangan mulai menindas diri Anda dengan fakta bahwa keahlian dan pengetahuan profesional Anda dipertanyakan dan tidak diperhitungkan ketika membuat keputusan. Entah mencari argumen yang layak yang akan menemukan dukungan dari tim, atau setuju dengan tim.
№5 Manajer "Histeris"
Peran penting dalam proses menjadi Anda sebagai seorang profesional / master keahlian Anda dimainkan oleh seorang mentor. Tapi ada satu peringatan, persepsi Anda tentang bantuan seorang mentor. Jika antara Anda tidak saling percaya, maka efek dari kegiatan bersama tidak mungkin menyenangkan tim dan semua orang di sekitar.
Saran, rekomendasi, menekankan kekuatan dan kelemahan keputusan yang dibuat - ini adalah nilai utama bekerja dengan seorang guru untuk saya. Namun, pelatih sering menggunakan format pelatihan yang berbeda: mereka mengatur situasi sulit bagi Anda tanpa peringatan, misalnya, konflik dalam tim karena pilihan teknologi, cuci tangan dan perhatikan tindakan Anda. Bagi saya, semuanya berakhir dengan fakta bahwa proyek dengan tes otomatis menjadi tanggung jawab tim pengembangan karena ambang masuk yang tinggi yang ditekankan oleh pelatih. Penjajaran ini cocok untuk semua orang, dan tidak ada gunanya untuk melanjutkan pertempuran demi kesederhanaan.
Apa yang harus dilakukan Tips topi
Penting untuk mempelajari momen seperti itu: jeritan, melempar kertas, menghapus kode masing-masing, presentasi oleh Anda dan mentor dari berbagai visi strategi dan langkah-langkah taktis, air mata tidak akan membantu. Jadi, Anda hanya menyeret proses mendekati tujuan, dan mungkin Anda akan terus-menerus mundur, karena Anda akan takut berurusan dengan, duduk di lantai yang sama, meragukan kebenaran ide-ide Anda. Cobalah untuk tidak membuat keputusan cepat, mencari tahu mengapa pelatih membutuhkan konflik ini, mengapa Anda lemah dan bagaimana menyelesaikan situasi tanpa meledak tanpa hasil.
Untuk meringkas
Di atas, saya menggambarkan 5 poin manajemen yang lemah dari seorang insinyur otomasi yang berpengalaman. Anda mungkin menghadapi kesulitan yang dijelaskan di atas, dan seberapa sukses pertempuran Anda dan seberapa kuat dan kuat tim Anda akan bergantung pada kesiapan dan karakter Anda. Kisah saya berakhir dengan pencapaian tujuan.
Penguji sekarang menjadi bagian dari tim-Dev, orang-orang sangat mandiri dan dapat membuat keputusan tentang implementasi teknis, kerjasama dengan tim lain. Mereka menulis skrip sendiri, memilih penguji baru, mengadakan mitaps dan banyak lagi. Ya, kami sudah membahas ini lebih dari setahun, tetapi tidak ada yang berjanji bahwa mengelola orang itu mudah.