Dalam kelanjutan dari serangkaian artikel tentang bagaimana kita akan mengungkap tiga blok paling penting dari
kerja tim di Saint TeamLead Conf - kerja
tim ,
alat memimpin tim dan
pengembangan kesadaran - hari ini saya akan berbicara tentang topik yang akan kita bahas dalam format pertemuan ruang, pertemuan, lokakarya, meja bundar.
Terakhir kali di TeamLead Conf di Moskow, kami mencoba memisahkan semua tabel bundar menjadi aliran yang terpisah. Ternyata cukup baik (dilihat dari penilaian peserta), tetapi banyak dari pendengar menulis di ulasan bahwa akan lebih baik untuk mempersempit topik pembicaraan, mengurangi jumlah pembicara, membuat acara lebih banyak ruang, tetapi pada saat yang sama mendapatkan kesempatan untuk lebih mempertimbangkan topik, mengajukan pertanyaan, mendengarkan pendapat rekan kerja.
Tidak lebih cepat dikatakan daripada dilakukan. Di St. Petersburg, pada tanggal 23 dan 24, dalam kerangka
Saint TeamLead Conf akan ada dua trek terpisah untuk ini, di mana kami telah memposting
9 mitaps . Tentang mereka dan akan dibahas di bawah.
Membangun jalur profesional Anda
Lokakarya tentang penentuan nasib sendiri akan dilakukan oleh
Maxim Tsepkov . Max adalah orang yang unik. Puluhan konferensi per tahun sebagai pendengar, banyak laporan tentang topik yang sangat berbeda (misalnya,
manajemen pengetahuan ,
tanggung jawab dan
soft skill ) dan
laporan ilahi. Pada prinsipnya, jika Anda hati-hati membaca posting-nya di fb dan blog, Anda tidak bisa pergi ke mana pun :) Dan Max dapat mendengarkan dua laporan pada saat yang sama, berselisih di antara aula :)))
Kali ini, di samping
laporan perencanaan proyek dari demonstrasi, Max akan melakukan
kelas master pada topik "Membangun jalur profesional kami - sebuah lokakarya tentang penentuan nasib sendiri". Dalam kehidupan modern perlu untuk mengambil keputusan sangat sering: mana yang akan memilih proyek berikutnya dan di mana perusahaan, konferensi mana yang layak dihadiri, dan banyak lainnya. Keputusan-keputusan ini dapat dibuat setiap kali secara situasional, atau Anda dapat mengingat tujuan pembangunan jangka panjang. Di TeamLead Conf tahun lalu, ada cerita tentang
perakitan sirkuit yang membantu Max membuat keputusan. Dan sekarang dia menawarkan para peserta untuk bekerja dengan penentuan nasib sendiri berdasarkan praktik mereka. Acara ini dirancang selama 2 jam - pertimbangkan ini saat merencanakan waktu Anda di konferensi.
PVS-Studio
Jika Anda memprogram C, C ++, C # atau Java, Anda pasti pernah mendengar tentang produk ini. Selama pertemuan, kami akan mendengar langsung tentang prinsip-prinsip penganalisa. Orang-orang akan menunjukkan bagaimana cara paling efektif menggunakan PVS-Studio dalam proyek baru atau mengimplementasikannya dalam yang sudah ada. Anda mungkin bisa melihat pendirian mereka di konferensi kami dan tidak hanya, tetapi pertemuan ini adalah alasan untuk mencari tahu lebih lanjut.
Ngomong-ngomong, poin penting. PVS-Studio tidak memiliki lisensi pribadi, karena mereka percaya bahwa manfaat dari analisis kode statis adalah keseluruhan proyek, dan bukan pengguna individu yang menjalankan alat. Tidak masalah apakah ia menjalankannya di komputer lokal atau di server build - manfaat dari memperkenalkan alat analisis statis tentu akan berlaku untuk seluruh proyek secara keseluruhan dan untuk seluruh tim, bahkan jika tidak semua pengembang dalam proyek mengetahui PVS-Studio.
Z.Y. Juga dimungkinkan untuk meninggalkan tomat :)
Ulasan DIY
Kali ini, George Mogelashvili dari Booking.com dan Komite Program kami menyarankan untuk melihat Tinjauan Kinerja dari sisi persiapannya. Memang, banyak dari kita telah mendengar tentang proses mengevaluasi kinerja, tetapi tidak semua orang mengerti sampai akhir apa itu dan mengapa itu diperlukan.
Pada
lokakarya ini
, George menawarkan bersama dengan Anda:
- Memahami mengapa proses untuk mengevaluasi kinerja diperlukan (atau tidak diperlukan)
- mengembangkan beberapa indikator untuk matriks penilaian;
- Praktik evaluasi berdasarkan kasus fiksi (atau tidak?).
Dari sudut pandang saya, kedengarannya menarik. Jika topik ini benar-benar tidak dapat dipahami atau tidak menarik, bacalah
artikel oleh Yegor Tolstoy dari Avito (Yegor berbicara tentang topik serupa di salah satu TeamLead Conf) dan Igor Tsupko dari Flant mengikuti jejak
laporan tentang Knowledge Conf. Saya sangat ingin mengundang Anda untuk membaca
artikel oleh Alexey Rybak tentang pengalaman Badoo.
Mengapa Anda membutuhkan CBT di bidang TI?
Mitap berikutnya saya meminta
Andrei Stepenko untuk
melakukan atas dasar percakapan berulang dan perselisihan di ruang obrolan tentang Teori Kendala. Mengapa Anda membutuhkan CBT di bidang TI? Anda bertanya, dan kami membantu menemukan jawabannya. Inilah yang ditulis Andrei tentang acaranya:
Di antara tim TI, ada minat pada topik dan perasaan intuitif bahwa itu berguna. Tetapi sedikit orang yang tahu cakupannya. Saya memiliki pengalaman 20 tahun di bidang ini dan sertifikat Sekolah Goldratt. Sejak 2010, saya terutama terlibat dalam proyek-proyek TI.
Pada pertemuan tersebut, itu akan tentang Drum-Buffer-Rope dan logika aliran material TOC. Ini akan membantu untuk memahami elemen dasar dari konsep tersebut. Dan akan ada kasing. Teori dan praktik.
Misalnya, sebagian besar keluhan dari pengembangan kustom terdengar seperti ini. “Analis kami ada di sisi pelanggan. Kami mengerti bahwa mereka tidak mengerti, tetapi tidak bisa menjelaskan. "
Jika Anda memahami logika bisnis pelanggan Anda, dan kolega Anda tidak terlalu bagus, Anda dapat mengambil inisiatif (akan ada TDR dan cloud). Dan tugas akan datang dari Anda.
Case akan membantu untuk memahami bagaimana bandwidth sumber daya dibenarkan dan bagaimana beban pada mereka berubah selama proyek. Mengapa lebih baik untuk mengganti kanban dengan scrum, dan di mana secara umum untuk mentransfer semuanya ke skema produksi.
Banyak yang mencoba mendekati mesin ini, tetapi tidak mencapai hasil yang layak. Datang jika Anda tertarik dengan topik ini. Andrei, omong-omong, menerjemahkan "Tujuan" dari Goldratt. Ya, "Tujuan" yang sama.
Peta jalan kayu
Jika Anda berlangganan saluran dengan kata "pemimpin tim" (misalnya,
tim Lead Pain ), Anda mungkin sudah mendengar tentang peta jalan yang diluncurkan oleh
Egor Tolstoy dan Stas Tsyganov . Jika tidak, baca
artikel Egor.
Kisah penciptaan adalah ini: beberapa bulan yang lalu Stas dihadapkan dengan masalah penataan pengembangan tim memimpin. Pertanyaan muncul di sekitar berikut ini:
- keterampilan apa yang harus diunduh terlebih dahulu;
- pengetahuan dan keterampilan apa yang secara umum dibutuhkan;
- seperti orang lain.
Penelitian di Internet dan literatur tidak memberikan jawaban untuk pertanyaan-pertanyaan ini, dan Stas, bersama dengan Yegor Tolstoy, mengambil pekerjaan yang sulit untuk menggambarkan dan mengelompokkan keterampilan memimpin. Orang-orang cukup cepat sampai pada ide untuk menarik komunitas dan saat ini repositori memiliki hampir 2.000 bintang, lebih dari 30 PR diterima.
Pada
pertemuan tersebut, para pria ingin membicarakan upaya ini dan menunjukkan kepada sukarelawan bagaimana menyusun peta pengembangan untuk diri mereka sendiri dan petunjuk mereka.
Ngomong-ngomong, saya juga menganut pembentukan roadmap :)
Pengembang Berorientasi Produk
Dmitry Sherstinin menyarankan untuk berdiskusi dalam kasus kehidupan nyata bagaimana mengembangkan "produktivitas" pada karyawan. Sehingga pengembang tidak hanya melihat kode, tetapi juga produk yang ia kembangkan. Saya mencoba melihat dengan mata pengguna nyata pada hasil pekerjaan saya dan menerapkan visi ini untuk menciptakan produk yang lebih baik. Kami akan membahas kasus-kasus yang berhasil atau tidak berhasil dalam praktik.
Menurut format acara, "pemimpin" menetapkan topik dan menguraikan beberapa kasus, harapan, dan apa akibatnya. Peserta berdiskusi dan berbicara tentang 1-2 kasus dari praktik mereka. Jika Anda memiliki sesuatu untuk dibagikan dengan rekan kerja, datanglah. Itu akan menarik!
Permainan Skor Relatif Melukis Story Point
Alexander Baptizmanskaya mengusulkan untuk mempertimbangkan topik abadi lainnya, berulang kali diangkat dalam percakapan yang sama sekali berbeda, sebagai bagian dari permainan tentang penilaian relatif.
Bukan rahasia lagi bahwa penelitian menunjukkan bahwa orang mengevaluasi pekerjaan dengan sangat buruk dalam hitungan jam, dan di bidang TI, mengevaluasi proyek hampir merupakan tempat yang paling menyakitkan dan sering menyerupai program "Battle of Psychics". Tujuan Paint the Story Point adalah untuk menunjukkan manfaat dari peringkat relatif untuk perencanaan jangka panjang dan kemungkinan tim yang lebih besar.
Konstruksi Timlid dan Wawancara dalam 15 Menit
Dan akhirnya, dua pertemuan penuh dari sahabat dan pembicara hebat kami Philip Delgyado dan Vitaliy Levchenko. Phil mendapat nilai tinggi di masa lalu Teamlead Conf dengan
laporan "Metodologi sebagai Pembuat". Jika Anda belum melihatnya, pastikan untuk memeriksanya.
Kali ini, subjek juga dikaitkan dengan konstruksi, tetapi sudah menjadi Timlida. Baru-baru ini, pertanyaan sering menyelinap: "Saya telah menjadi pemimpin tim - dan apa yang harus dilakukan, di mana harus berkembang." Sebagai bagian dari pembahasan topik ini di atas, saya berbicara tentang mitaps dari Yegor dan Stas. Tetapi di perusahaan yang berbeda dan bahkan dalam proyek yang berbeda, "pemimpin tim" berarti hal yang sama sekali berbeda dan tidak ada jawaban
tunggal untuk pertanyaan ini dan itu tidak mungkin.
Pada pertemuan tersebut, sebagai bagian dari seminar bersama, Phil dan hadirin akan mencoba mencari tahu:
- apa "peran" timlid pada contoh-contoh dari kehidupan;
- apa "peran" yang dibutuhkan dalam berbagai situasi ("SCRUM", "Agile", perusahaan, dll.);
- Apakah mungkin untuk memilah beberapa hal dasar di balik daftar 100.500 kompetensi yang berbeda (baik, misalnya, pemikiran sistemik atau kemampuan untuk menempatkan diri Anda di tempat yang lain).
Z.Y. Pada pertemuan tersebut, partisipasi aktif pendengar dalam proses sangat diharapkan.
Mitap kedua
, bersama dengan Nadia Petrova, didedikasikan untuk topik wawancara. Program ini mencakup dua laporan tentang topik ini dari Stas Tsyganov dan Neil Podolsky, tetapi kami memutuskan untuk mengembangkan topik ini juga melalui komunikasi dengan siswa.
Banyak yang suka wawancara panjang. Bicaralah dengan kandidat secara menyeluruh selama beberapa jam, berikan dia beberapa tugas, minta dia untuk mengikuti tes, kemudian kirim dia ke kolega masa depan, ketua tim dari kelompok tetangga, SDM dan setengah dari direktur. Pendekatan ini mungkin dapat diandalkan dan berkualitas tinggi, tetapi sangat mahal bagi kandidat dan perusahaan yang mempekerjakan.
Pada pertemuan tersebut, Phil, bersama dengan para hadirin, akan mencoba memahami untuk apa wawancara itu, apa yang perlu kita pelajari tentang kandidat, bagaimana kita dapat memverifikasi informasi yang diterima dalam waktu singkat (baik milik kita maupun kandidat).
Secara umum, teman-teman saya, program ini sangat kaya dan bermanfaat. Saya mengundang Anda untuk berperan aktif dan berkomunikasi dengan kolega dan pakar. Sampai jumpa pada 23 dan 24 September di ARTPLAY SPb di St. Petersburg.