Di TeamLead tahun ini, Sergey berbicara tentang bagaimana Agile berubah dalam organisasi besar dan, karenanya, bagaimana lingkungan Anda (pemimpin tim dan tim) berubah dan persyaratan baru apa yang ditempatkan pada Anda sebagai pemimpin. Dan dia menunjukkan seluruh proses Agile dengan foto.
Memulai dengan Agile
Jika Anda sudah memiliki Agile, bagaimana Anda memutuskannya? Sudahkah Anda memutuskan sendiri dan secara sadar apa sebenarnya proses ini (Scrum atau Kanban) yang Anda butuhkan dan apa sebenarnya yang akan membantu menyelesaikan masalah Anda? Apakah kenalan pertama Anda dengan Agile seperti ini?
... atau apakah ini terjadi?
Dalam organisasi besar, cerita yang biasa terjadi ketika seorang manajer datang: “Itu saja, besok semua orang adalah Scrum! Tidak ada waktu untuk mengetahuinya - Anda adalah Scrum Master atau Pemilik Produk. " Selain itu, dari studi "Agile in Russia", angka-angka menunjukkan: semakin besar skalanya, semakin sering cerita ini muncul. Tetapi tidak peduli bagaimana Anda berhasil terlibat dalam Agile, mari kita cari tahu ke mana Anda pergi, apa lingkungan ini dan persyaratan apa yang diberlakukannya pada Anda dan tim Anda. Jika Anda tidak memahami ini, sering kali penerapan Agile berubah menjadi pabrik fitur.
Dulu, developer mengambil tiket dari Jira. Sekarang mereka melakukan hal yang sama, tetapi mereka mengambil dari apa yang sekarang disebut simpanan: simpanan digulung ke Anda, Anda mengambilnya - dan konveyor melanjutkan. Pada saat yang sama, di suatu tempat, produk Anda memperkenalkan pengguna pada apa yang terjadi pada akhirnya: pengguna dan produk, cium!
Apakah itu benar-benar Agile? Kami tidak melakukannya untuk itu.
Apa itu Agile dan Mengapa?
Anda tahu bahwa Agile adalah pendekatan tentang cara melaksanakan proyek dalam menghadapi ketidakpastian yang besar. Ini adalah matriks kebingungan Stacy:
Agile bekerja dengan baik dalam situasi di mana Anda memiliki dua ketidakpastian besar:
- apa yang perlu Anda lakukan untuk konsumen Anda sehingga mereka memilih perusahaan dan produk Anda dengan uang;
atau
- Anda tidak tahu dengan teknologi apa untuk menerapkan ini,
maka Anda menemukan diri Anda dalam lingkungan yang kompleks di mana Anda ditawarkan:
- melepaskan opini bahwa Anda tahu apa yang dibutuhkan pengguna Anda;
- mengajukan hipotesis;
- melakukan serangkaian eksperimen;
- mendapatkan umpan balik dari pengguna akhir (pada awalnya tidak puas, dan di masa depan kami berharap dapat menemukan cara untuk menyelesaikan masalahnya).
Hasilnya, tim Anda dan, secara umum, seluruh organisasi Anda memiliki dua fokus:
- Apa nilai pelanggan? Anda perlu belajar bagaimana mengukurnya dengan bekerja dengan nilai pelanggan secara sistematis.
- Lakukan dengan cepat. Terkadang dikatakan bahwa ketangguhan tim diukur dengan jumlah hipotesis yang diuji per unit waktu.
Bagaimana kita bisa mendapatkan semua ini pada realitas kita?
Apa tugas pemimpin?
Ada dua aktor dalam sistem: Anda, sebagai pemimpin, dan tim Anda. Pertimbangkan contoh sederhana: tim membuat produk, tetapi pelanggan tidak senang. Apa yang harus kita lakukan sebagai pemimpin, apa tugas kita dalam cerita ini? Tentu saja, cari tahu apa masalahnya: Anda, sebagai seorang ahli, pergi dan mencari tahu. Katakanlah tim pengembangan mengirimkan untuk pengujian pada hari terakhir, sehingga banyak sekali masalah yang sampai ke pengguna. Apa yang kita lakukan selanjutnya?
Kami sudah tahu apa masalahnya, kami mengidentifikasinya. Hal termudah untuk dilakukan sekarang adalah datang ke tim dan berkata: "Dengar, kalian sedang melakukan ini sekarang - jangan lakukan itu! Ayo lakukan dengan benar. " Ini biasanya dilakukan dengan anak-anak. Saya memberi tahu putra saya yang berusia tujuh tahun: "Vladik, tolong jangan lakukan ini!" Dan ini, omong-omong, benar-benar berhasil - dia berhenti melakukan itu. Benar, kemudian istri saya memberi tahu saya bahwa dia tidak melakukan ini di depan saya. Dan saat saya sedang bekerja, semuanya berlanjut seperti sebelumnya.
Jadi tidak berhasil. lalu apa yang harus kita lakukan? Kami mengubah proses, mengajukan pertanyaan kepada tim tentang apa yang bisa dilakukan agar tidak berbuat buruk. Pada dasarnya, semua yang kami bisa sebagai pemimpin adalah menyesuaikan lingkungan yang menentukan perilaku tim kami. Kami menciptakan lingkungan yang membuat perilaku negatif menjadi tidak mungkin dan memotivasi orang untuk berperilaku berbeda:
Misalnya, Anda menerapkan Scrum. Mulai sekarang, tidak mungkin untuk tidak memberikan hasil setidaknya sekali setiap 2 minggu. Tidak, pengembang dapat melakukan itu, tetapi mereka akan menerima umpan balik yang memotivasi dan merangsang ketika Anda, sebagai pemimpin, mengundang orang untuk meninjau sprint, yang akan mengatakan semua yang mereka pikirkan tentang produk tanpa ragu-ragu dalam ekspresi. Lambat laun, karena suatu alasan, dia menjadi sedikit malu untuk menyeret tugas yang sama setiap hari - setiap hari dia harus menjawab Daily Scrum apa yang dia lakukan kemarin, apa yang akan dia lakukan hari ini, dan bahkan dengan penambahan jahat “dalam tujuan sprint”.
Artinya, Anda menciptakan lingkungan yang secara bertahap mengubah cara berpikir orang, dan mereka mulai berperilaku berbeda. Tugas kita adalah terus memikirkan tentang bagaimana mengatur lingkungan. Dalam pengertian ini, kita bukan menjadi pemimpin orang, tetapi menjadi mekanik untuk menyiapkan sistem. Bayangkan sebuah sistem - baut-roda berputar dengan sendirinya (ini adalah spesialis pintar kami), dan ada gesekan di antara mereka. Anda berkeliling dengan kaleng oli dan menambahkan di mana sesuatu mulai retak - Anda membuat sistem yang bekerja dengan sendirinya.
Dan yang paling keren dari kami membuatnya sehingga sistem untuk beberapa alasan mulai berkembang sendiri. Misalnya, Anda menciptakan lingkungan di mana tim mengetahui cara melihat hasil pekerjaan mereka dan, seperti yang mereka katakan, melatih diri mereka sendiri: apa lagi yang bisa dilakukan untuk menjadi lebih keren? Benar, jika Anda telah menyiapkan sistem seperti itu, itu masalah bagi Anda, kesedihan (atau kegembiraan) - Anda tidak lagi membutuhkan sistem ini (setidaknya setiap hari), sistem mulai berkembang dengan sendirinya. Inilah yang disebut tim yang mengatur dirinya sendiri.
Tetapi bagaimana ini bisa dicapai?
Apa tanggung jawab tim Scrum?
Mari kita mulai dari bawah ke atas - ambil saja satu tim Scrum, belum ada skala. Sebuah pertanyaan untuk Anda: apa tanggung jawab tim di akhir sprint? Ketika sprint selesai, untuk apa Anda memarahi mereka?
Jawaban biasa adalah untuk fitur. Jika tim adalah pabrik fitur, lalu bagaimana fitur terkait satu sama lain? Mengapa kami melakukan fitur ini, dan bukan yang lain? Tidak ada jawaban untuk pertanyaan-pertanyaan ini - lingkungan seperti itu belum tercipta. Contoh klasik adalah dewan tim dari Avito sekitar 2,5 tahun yang lalu. Terlihat bahwa di akhir sprint banyak tugas yang masih belum selesai - hanya sekitar 40% yang siap:
Mari kita cari tahu apa masalahnya. Salah satu masalah paling umum di awal adalah tim tidak tahu cara mengevaluasi. Kita perlu mengajari mereka apa itu Story Point, bagaimana mendekatinya dengan benar jika ada backing, front, dll dalam tim. Tunjukkan kepada mereka bagaimana melakukan ini dengan memberi contoh.
Ada masalah lain - mereka bisa melakukan semuanya, tapi mereka tidak fokus. Kemudian kami membawa tim ke retrospektif dan bertanya: "Apa tujuan pekerjaan Anda?" Sebagai tanggapan, seekor kambing melihat tombol akordeon dan pertanyaan: "Apa tujuan sprintnya?" Oke, mari kita masukkan ke dalam kotak besar apa yang telah Anda lakukan selama dua minggu terakhir. Mereka terdengar, Anda menulis. Setelah itu, setiap orang secara anonim memberi peringkat pada stiker: "Seberapa jauh Anda sebagai tim mencapai tujuan sprint ini?" Artinya, tim harus menjawab pertanyaan tersebut, meninjau semua yang telah dilakukan:
Mari kita lihat contoh.
Tujuan sprint - 8
Intinya, ini adalah tugas umum. Selain itu, saya menciptakan lingkungan yang menunjukkan bahwa setiap karyawan memiliki tujuan (tugas) mereka sendiri. Dan ketika orang lain menjawab, saya mengambil spidol dengan warna yang berbeda:
terlihat bahwa setiap orang memiliki pekerjaannya sendiri. Dan pemahaman tim tentang bagaimana kami mencapai tujuan sangat berbeda. Setelah itu, biasanya muncul pertanyaan: "Berapa kita satu tim?" Karena sepertinya setiap orang hanya menggergaji pekerjaan mereka sendiri. Mungkin, pria yang memberi dua benar-benar melakukan tugas yang sulit dan, tampaknya, tidak ada yang membantunya. Rekan dengan sembilan orang itu tidak membantu secara khusus - dia memotong tugasnya dan, mungkin, di akhir sprint dia terlibat dalam pengembangan diri, meskipun di bagian lain tim ada pemboman dan bantuan dibutuhkan.
Sprint goal - 6 buah
Ini adalah tim yang berbeda, tetapi situasinya sama. Pemahaman tentang realitas sudah mendekati 8-9, tetapi ada enam. Inilah tepatnya pemimpin tim - dia lebih memahami daripada siapa pun seberapa dekat mereka dengan tujuan:
Sprint goal - 5 buah
Mengompresi tujuan. Ini lucu, tapi distribusi sudah normal. 3-4-5 dan 7-8-9 adalah dua sub-tim yang terdiri dari tiga orang dalam tim, yang bersama-sama menyeret satu pekerjaan, dan mereka kurang lebih berhasil. Orang-orang dari 3-4-5 memiliki fitur yang sulit, mereka tidak mengatasinya. Tapi mereka hampir sama mengerti bahwa mereka mengomel. Tiga berenam adalah senior yang paling memahami apa yang terjadi karena mereka membantu Jun di kedua bagian:
Sprint goal - 2-3 buah
Bagaimana jika Anda mencubit sama sekali? Semakin sedikit tujuan sprint, semakin banyak pemahaman tentang kenyataan - apa yang sebenarnya kita lakukan dan seberapa banyak kita mencapainya - mulai muncul di benak orang:
Mengapa saya menunjukkan semua ini? Mengapa keren jika tim memiliki satu tujuan?
Pentingnya Tujuan di Agile
Karena Agile berbeda dari game klasik dalam hal ini:
Di game klasik, kami menjanjikan serangkaian fitur dan kami dapat terus bermain: menginvestasikan lebih banyak sumber daya dalam pengembangan, atau menjual tenggat waktu. Hanya ada dua parameter ini, karena Anda perlu melakukan seluruh volume.
Di Agile, kami memahami sebelumnya bahwa kami berada di area ketidakpastian dan tidak tahu kumpulan fitur yang benar-benar dibutuhkan konsumen kami: kami hanya memiliki hipotesis. Terkadang mereka mengatakan halusinasi, dan pakar terbesar di dalamnya adalah Pemilik Produk kita. Dia berhalusinasi dalam dua batasan: sumber daya terikat (tim penuh waktu, semua dialokasikan 100%) dan sprint akan berakhir tepat ketika berakhir, tidak lebih awal dan tidak nanti. Kedua parameter sudah diperbaiki, tetapi kami ingin cakupannya mengambang. Ini bukan hal yang buruk, ini adalah fitur yang keren: kami ingin dapat mengubah cakupan, menerima umpan balik - apakah kami sedang melakukannya atau tidak. Tetapi Anda membutuhkan pengukur - inilah tujuannya. Kapan lagi target menembak?
Apa tujuan dari Sprint Review?
Ada dua opsi untuk melakukan tinjauan sprint.
Tim menunjukkan kepada pemilik produk produk yang berfungsi di akhir sprint. Lihat bagaimana dia menatapnya. Ini menanyakan pertanyaan yang paling penting: “Pemilik Produk, beri kami umpan balik: seberapa jauh kita telah mencapai tujuan sprint? Dan bagaimana kami perlu mengubah backlog selanjutnya? " Pemilik Produk berpose tertutup: “Apa yang bisa saya ceritakan di sini? Ya, sepertinya tombolnya berfungsi. " Kebingungan muncul: bagaimana pemilik produk dapat memberikan umpan balik tentang tombol yang berfungsi, jika tidak ada informasi nyata tentang cara kerjanya di lapangan, yaitu tidak ada umpan balik dari konsumen akhir:
Opsi kedua adalah cerita favorit saya tentang salah satu tim Avito, yang mana juga sekitar 2 tahun. Tim ini menghubungkan penjual dan pembeli di messenger. Ini memiliki dua metrik utama:
- , , , ..
- , .
Tim dalam sprint telah menerapkan fitur dangkal - potongan bulat, yang menunjukkan bahwa di ujung lain baris pembeli atau penjual sekarang online: Anda dapat dengan cepat menulis, dan dia akan segera menjawab. Selama tinjauan sprint, mereka menunjukkan hasil pengujian A / B, meluncurkan fitur ke produksi untuk sejumlah pelanggan terbatas dan melihat apakah itu benar-benar berkorelasi dengan dua metrik ini. Tidak ada korelasi yang jelas, dan tim meminta waktu seminggu lagi untuk mengambil data dan memahami: jika fitur ini masih diperlukan, lalu bagaimana cara memodifikasinya?
Ini adalah dua opsi berbeda. Tujuan Anda akan berhasil jika Anda tidak hanya meletakkannya sebagai slogan, tetapi juga jika dirumuskan dalam metrik yang dapat diukur. Jika tidak, lagi-lagi ini adalah pencemaran nama baik.
Apa yang bisa menjadi tujuan sprint?
Anda dapat menetapkan tujuan berdasarkan pencapaian: membuat rilis pada tanggal ini dan itu, dll. Ada sedikit informasi di sini lagi: bagaimana Anda mengukur bahwa ini yang diinginkan konsumen Anda?
OKR menawarkan pendekatan yang berbeda: kami menetapkan tujuan berdasarkan metrik, dan khusus pelanggan. Bagaimana pelanggan berinteraksi dengan produk Anda? Bagaimana hal ini memengaruhi fakta bahwa dia menyelesaikan masalahnya dengan lebih cepat, lebih baik, lebih baik, dll. dan siap memilih bisnis Anda dengan uang? Oleh karena itu, Anda harus memiliki meteran.
Salah satu sifat tujuan, seperti yang dikatakan OKR, haruslah tingkat ambisi. Artinya, kami ingin meningkatkan kehidupan klien untuk sprint tidak hanya, tetapi seberapa banyak - hingga 80%, 52%, dll. Ini adalah meteran tempat Anda ingin melompat:
Intinya: lingkungan seperti apa yang kita ciptakan?
Product backlog hanyalah serangkaian hipotesis. Kami, sebagai mekanik dari sistem ini, di level tim, harus secara mental mengubah sikap orang-orang terhadap backlog. Anda memiliki halusinasi di backlog Anda. Karena itu, selalu ajukan pertanyaan kepada pemilik produk, bisnis, dll. - mengapa kita melakukan ini? Mengapa Anda yakin bahwa ini yang dibutuhkan klien kami? Jika tidak yakin, bagaimana kita dapat mengukur bahwa ini benar-benar yang mereka inginkan? Ubah mentalitas tim dan pelanggan bisnis Anda untuk bersama-sama melepaskan perasaan bahwa Anda tahu segalanya sebelumnya.
Tim berkomitmen pada tujuan sprint. Harap tidak mengambil komitmen apa pun dari tim untuk pelingkupan. Inilah cara Anda mendorong mereka ke Waterfall, meskipun Anda menyebutnya Scrum. Ini bukan tentang melakukan semua fitur dalam sprint. Tidak, tim Anda dalam sprint proses Scrum bahkan dapat mengubah product backlog Anda jika mereka tiba-tiba menemukan bahwa apa yang Anda berhalusinasi seminggu yang lalu bukanlah sesuatu yang membawa Anda lebih dekat ke tujuan Anda. Tentu saja, dua minggu adalah waktu yang singkat, dan pada akhirnya, mungkin tidak banyak perubahan untuk Anda. Namun demikian, ubah mental - dalam skala, masalah ini keluar dengan segala kemuliaan.
Produk dan sprint backlog hanyalah sebuah rencana untuk mencapai suatu tujuan. Rencana tersebut harus secara teratur diperiksa terhadap hasilnya dan diubah jika terjadi penolakan. Saya sudah mengatakan bahwa di Daily Scrum Anda perlu menanyakan pertanyaan setiap hari: "Apa yang kita lakukan, dengan tujuan secara umum berkorelasi?" Secara bertahap, Anda akan melatih orang untuk berpikir lebih banyak tentang tujuan daripada cakupannya. Tapi pertama-tama Anda perlu mengulanginya beberapa kali agar orang akhirnya mengerti mengapa kami melakukan ini.
Fokusnya lebih pada hasil akhir daripada prediksi waktu pengiriman. Kami lebih fokus untuk mengubah beberapa metrik daripada hanya menarik fitur. Bahkan dimungkinkan untuk tidak menyelesaikan beberapa fitur: mungkin dengan menyelesaikan 2/3 dari sprint backlog Anda, Anda akan mencapai peningkatan dalam metrik utama untuk klien, dan tidak masalah lagi jika 2 fitur tidak diselesaikan. Tujuannya adalah hal lain.
Ulasan Sprint - Menilai kemajuan Anda menuju tujuan berdasarkan umpan balik pelanggan. Apalagi dari pelanggan nyata. Ini adalah tantangan bagi semua karyawan yang terkait dengan praktik teknik yang digunakan tim Anda: Integrasi Berkelanjutan, Penerapan Berkelanjutan, dll. Inilah yang saat ini menyerbu industri lain di mana Agile mencoba menerapkannya.
Misalnya, perusahaan Siberian Gurman di Novosibirsk, yang membuat pangsit, memutuskan untuk bereksperimen dengan area ketidakpastian: bagaimana jika Anda mengubah isian perasa pangsit atau bungkusnya, bagaimana hal ini akan memengaruhi daya beli produk? Keren! - sekarang kami akan melakukan percobaan dan menerima umpan balik. Tapi apa artinya eksperimen? Mereka datang ke pengecer dengan format pangsit baru, tetapi pengecer tidak ingin melakukan pembelian kecil dan menawarkan pasokan besar selama enam bulan - begitulah percobaan berlangsung selama setahun. Hasilnya, Sibirskiy Gurman membuka tokonya sendiri, di mana Anda dapat dengan cepat mendapatkan tanggapan, tetapi toko tersebut adalah bagian yang sangat mahal dari proyek tersebut.
Di TI, seperti yang Anda lihat, semuanya lebih sederhana. Semuanya telah ditemukan. Dan di industri lain, orang-orang kreatif untuk mendapatkan umpan balik secepat mungkin. Tapi itu terjadi pada semua orang.
Apa yang terjadi pada skala?
Di suatu tempat di gambar ini adalah tim Anda. Dan itu dimulai: setiap tim memiliki simpanannya sendiri, tujuannya sendiri, Anda memahami siapa klien Anda, tetapi untuk beberapa alasan banyak orang (kontraktor, pemangku kepentingan, dll.) Berlari kepada Anda yang menginginkan sesuatu yang lain dari Anda ( misalnya, masukkan halusinasi Anda ke dalam backlog Anda), dan untuk beberapa alasan Anda harus melakukannya juga:
Pada tingkat gejala akhir, kami memiliki yang berikut:
- Sejumlah besar dependensi.
- Kami sering tidak tahu sebelumnya kepada siapa kami bergantung - ini adalah transparansi yang rendah tentang siapa yang harus saya setujui untuk meluncurkan beberapa fitur. Anda mulai melakukannya di dalam sprint dan pada saat itu Anda akan mengetahui: ternyata kita tidak dapat mengubah API sendiri, kita harus menjalankannya; tetapi di sini Anda perlu menyetujui peraturan, keamanan informasi, dll. Artinya, tidak diketahui sebelumnya siapa yang harus lari.
- , . , . , . .
- — . - , , ? , , , . .
- — . : « , ! !» — « ?» .
Dari mana semua ini berasal dari suatu skala dan mengapa itu muncul? Mari kita perhatikan contoh contoh klasik dalam memperoleh pinjaman, dari mana semua ketergantungan ini muncul di bank.
Hal pertama yang harus dilakukan bank adalah memberi tahu orang-orang bahwa bank tersebut memiliki persyaratan pinjaman yang bagus: kualitas tinggi, cepat, dll. Faktanya, bekerja dengan klien dimulai dengan pemasaran. Lalu ada penilaian, registrasi, dll, hingga penutupan pinjaman secara lengkap. Perusahaan memiliki layanan operasional yang langsung melayani klien dan berkomunikasi dengannya:
Lebih jauh, sistem TI tampaknya mendukung, mempercepat, mengotomatiskan - secara umum, mereka memastikan bahwa klien mendapatkan pinjaman dengan tenang dan cepat. Di sinilah orang-orang kami dan struktur organisasi kami muncul. Berikut adalah contoh yang dibuat-buat: ada 310 pengembang di departemen TI Moskow, 30 orang di Estonia, dan vendor lain di Amerika (150 orang):
Contoh nyata tentang saya. Ketika saya mendapatkan hipotek ketiga saya di bank favorit saya, pada tahap # 2 (penilaian cepat permohonan) saya ditolak. Pada malam hari di hari yang sama, manajer VIP saya menelepon saya dengan pertanyaan klasik: "Sergey, apakah bank kami baik-baik saja dengan Anda? Mungkin saya bisa membantu Anda dengan sesuatu? " Tentu saja, saya bertemu dengannya: “Bung, apa yang terjadi? Saya klien VIP Anda. Mengapa hipotek saya ditolak ketika semuanya baik-baik saja dengan saya? " Dia meminta waktu tunggu dan menelepon saya kembali di malam hari - dia tidak dapat segera menjawab pertanyaan itu, karena dia melihat ke dalam CRM dan tidak melihat informasi apa pun di sana yang bahkan saya telah mengajukan aplikasi.
Pasalnya, pada tahun-tahun tersebut bank ini mengalihkan sebagian besar layanan operasionalnya kepada mitranya. Artinya, ada bank induk dan bank rekanan yang melayani klien di pintu masuk - secara kasar, bukan bank induk yang mencintai saya, tetapi mitranya yang menolak saya. Karena tanggung jawab satu bank berakhir di persimpangan dengan tanggung jawab bank lain, integrasi tersebut macet. Sebuah kesalahan kecil membuat bank induk tidak menyadari bahwa klien tercintanya tidak diperlakukan dengan baik oleh bank rekanan. Pada persimpangan seperti itu, bisnis sangat sering kehilangan pelanggannya dan, akibatnya, uang.
Mengapa aku melakukan ini? Bayangkan bahwa tim Scrum Anda - lintas fungsi dalam hal dukungan, depan, dll. - ada di dalam struktur ini. Pertanyaan kuncinya adalah, seberapa fungsional tim Anda dalam memecahkan masalah pelanggan? Idealnya, fungsionalitas silang harus sedemikian rupa sehingga Anda dapat membantu klien pada setiap tahap siklus hidup komunikasinya dengan perusahaan. Bisakah Anda bayangkan berapa banyak kompetensi yang Anda butuhkan untuk dimasukkan ke dalam satu tim scrum, misalnya untuk 11 orang?
Sayangnya, dalam skala besar, ini adalah masalah utama: tim berhenti berfungsi silang sehubungan dengan klien. Solusinya adalah ini: mari kumpulkan tim besar yang bersama-sama akan berfungsi lintas mungkin.
Berikut contohnya (dua stiker merah). Stiker bertuliskan "Hipotek" berarti kita mengubah struktur organisasi sedemikian rupa sehingga muncul divisi hipotek (aliran, suku, kereta api, dll., Di berbagai perusahaan disebut berbeda). Kami menggabungkan bisnis (bertanggung jawab atas metrik keuangan untuk menerbitkan hipotek) dan tim (tinggal di Moskow dan Estonia) untuk mengembangkan sistem di bagian pertama aliran ini, memperbaiki kesalahan integrasi, dll.:
Dalam cerita saya, vendor tidak bisa diseret ke topik ini. Mereka berkata: "Tuliskan TOR kepada kami, kami akan melakukan segalanya." Tapi bagaimanapun juga, Anda membentuk divisi yang memandang kliennya seluas mungkin. Sering kali ada bersulang: "Fokus pada pelanggan, nilai," tetapi hitung jumlah langkah yang ditutup unit ini. Semakin tertutup, semakin dingin, lebih tepatnya, secara bertahap akan menjadi curam dan akan dapat menyelesaikan semua masalah klien.
Mengapa saya mengatakan ini? Tugas pemimpin bukan hanya membangun lingkungan untuk pengembangan tim. Pertama, Anda perlu memahami:
- Dalam konteks apa Anda?
- Langkah-langkah dan masalah klien apa yang diselesaikan oleh tim atau departemen Anda?
- Bisnis anda siapa
- Apa KPI pelanggan akhir untuk unit bisnis Anda? Artinya, apa yang Anda tingkatkan, dan bukan hanya tim Anda, tetapi seluruh sirkuit.
Sebagai contoh, saya menyajikan tiga opsi untuk unit lintas fungsi.
Opsi 1: per saluran dengan platform
Salah satunya pada dasarnya adalah seluruh umpan web, tempat semua pengembang web berada. Misalnya, untuk bank, metrik utamanya adalah dalam hal daya tarik, sehingga klien dapat mencoba menghitungnya dengan kalkulator pinjaman dan menjadi peminjam hipotek.
Aplikasi seluler (iOS, Android, dll.) Sudah dengan metrik yang terkait dengan aktivasi dan pemeliharaan. Bisa juga ada divisi platform, yaitu membuat komponen, yang konsumennya divisi lain:
Opsi 2: berdasarkan produk dengan platform
Opsi kedua lebih keren: Anda mengubah struktur organisasi sedemikian rupa sehingga setiap unit menjadi lintas fungsi sehubungan dengan saluran. Kami perlu memperbaiki sesuatu di kredit - kami melakukan ini di saluran web dan di ponsel, sama dengan kartu debit. Departemen dapat sepenuhnya mengubah saluran apa pun. Tetapi Anda harus membuatnya agar divisi dapat melakukan perubahan pada basis kode yang sama.
Ini adalah opsi yang lebih sulit tetapi lebih keren. Bisnis sangat menyukainya, karena aliran debit menghasilkan: Anda dapat memahami berapa banyak yang kami hasilkan, ditambah ada gaji untuk tim pengembangan. Akibatnya, Anda menggabungkan pendapatan dengan biaya. Departemen Anda menjadi perusahaan kecil di dalam perusahaan besar, karena memiliki P&L sendiri dan Anda dapat melihat seberapa efektif Anda sebagai organisasi mikro:
Opsi 3: aliran nilai langkah demi langkah
Kasus yang kompleks memiliki banyak divisi, dan masing-masing bertanggung jawab atas sekumpulan metrik. Dalam organisasi besar, ini adalah opsi paling populer:
Jenis lingkungan apa yang kita ciptakan dalam skala besar?
Pada skala tertentu, kami menciptakan lingkungan yang sama seperti pada level satu tim. Ini sebenarnya melakukan hal yang sama, tetapi kami tumbuh lintas fungsi di seluruh perjalanan klien. Oleh karena itu, ada lautan kesulitan: komunikasi dengan bisnis, tim lain, siklus yang lebih kompleks (bukan dua minggu, tetapi setiap tiga bulan):
Berbagi Perencanaan Tujuan Kuartalan: Perencanaan OKR (Perencanaan PI)
Baik. Tim Anda sudah memahami bahwa Anda tidak dapat membantu klien Anda di semua tahap. Tetapi Anda memahami bahwa ada bisnis yang perlu Anda rencanakan untuk mengubah metrik pelanggan. Soalnya, masih banyak orang: sekitar 150 spesialis lainnya (10-12 tim). Dan dengan siapa, tampaknya, harus berkomunikasi, karena Anda bergantung pada mereka, dan mereka - pada Anda.
Bagaimana cara berkomunikasi? Dalam semua pendekatan, Agile memberikan resep sederhana: "Bicara saja: Anda memiliki kecanduan dengan seseorang, pergi dan bicara dengannya." Pengembang, terutama mereka yang lebih suka berkomunikasi dengan monitor dibandingkan dengan orang lain, berkata: "Saya tidak bisa melakukan itu - bagaimana saya bisa bicara?" Oleh karena itu, semua kerangka kerja menawarkan dorongan komunikasi: “Oke, Anda tidak dapat berkomunikasi. Sekarang Anda akan berkomunikasi, tetapi menurut algoritme berikut. "
Perencanaan OKR kolaboratif (dalam pendekatan lain yang disebut Perencanaan PI) semakin populer. Idenya adalah bahwa untuk jangka waktu yang lama (seperempat) kita bersama, dengan semua orang, memahami siapa bisnis kita dan ketergantungan kita di dalamnya, merencanakan tujuan bersama. Ini adalah acara dua hari, tetapi beberapa orang berhasil mengadakannya dalam sehari jika tim sudah belajar untuk berkomunikasi satu sama lain. Secara kasar, ini adalah acara tanya jawab yang difasilitasi selama dua hari, seperti:
- Siapa yang kita andalkan?
- Apa yang kita lakukan kuartal ini?
- Metrik keuangan apa yang ingin kita dapatkan? Bisnis, tolong jawab.
Artinya, kami memastikan bahwa semua orang mencapai kesepakatan dengan semua orang dan bekerja sesuai keinginan kami pada akhir kuartal. Ini adalah foto nyata ketika tiga tahun lalu Sberbank pertama kali mencoba meluncurkan acara tersebut:
Perencanaan OKR bersama atau Perencanaan PI dilakukan secara bertahap.
Pengarahan
Di awal, diperlukan pengarahan. Bisnis harus berkata: "Saya ingin melihatnya pada akhir kuartal ..." Dan sebagai contoh, di atas adalah Sberbank 3 tahun yang lalu, dan di bawah - Perusahaan GameDev Xsolla dari Los Angeles. Omong-omong, orang Amerika itu menceritakan sebuah kisah sederhana bahwa mereka tidak memiliki masalah dalam mengaktifkan klien baru: semuanya baik-baik saja dengan metrik pada aktivasi. Tetapi ada masalah dengan pembelian berulang: karena alasan tertentu, persentase pembelian berulang sangat rendah. Dan masalah kedua adalah karena alasan tertentu layanan tambahan tidak dibeli, cek rata-rata rendah. Dan bisnis tersebut bertanya: "Tolong, semua fitur dalam kuartal ini ditujukan untuk pembelian berulang dan peningkatan rata-rata cek (layanan tambahan)":
Ini adalah salah satu tampilan visi yang baik: ketika kita berbicara tentang konteks bisnis dan metrik keuangan. Tapi kami tidak tahu sebelumnya apa yang akan dilakukan di kuartal tersebut. Apa yang terjadi selanjutnya?
Pidato arsitek
Di perusahaan IT, kami pasti mendengarkan arsiteknya. Sebuah cerita yang menarik untuknya! - lingkungan juga berubah. Pada sesi seperti itu, arsitek akhirnya memahami siapa klien mereka (sebagian besar arsitek perusahaan berpikir bahwa ini adalah bisnis):
Arsitek ini ingin segera melaporkan lanskap Sberbank yang "mengerikan" dan melarikan diri: "Saya sudah memberi tahu Anda semuanya! Apalagi ia memberi arsitektur konseptual 50-100 halaman. Apa lagi yang bisa saya lakukan di sini? Masih bisa dimengerti, tetapi jika ada - telepon. " Namun setelah presentasi, salah satu ketua tim mengajukan pertanyaan kepadanya:
- Arsitek yang terhormat! Kubus ketiga dari kanan atas - tahukah Anda bahwa sistem ini belum beroperasi?
- Tentu saja saya tahu. Saya sendiri menggambar kubus ini.
- Apakah Anda tahu bahwa itu akan dilakukan dalam enam bulan?
- Ya tentu saja.
- Sekarang ingatlah bahwa kita berada pada sesi perencanaan untuk tujuan triwulanan, dan bisnis menginginkan fungsionalitas dari kita, yang, secara teori, harus melewati sistem ini.
Di sini arsitek mengerti apa pertanyaannya. Dan tim memintanya untuk tetap bersama mereka sehingga ketika mereka merencanakan fitur mereka, mereka akan berpikir bersama bagaimana membuat keputusan yang tidak tepat.
Berkerumun (generasi target)
Kemudian tim berangkat untuk berenang bebas. Mereka memiliki waktu tiga jam, dan mereka harus menghasilkan tujuan yang mereka bersedia tanggung jawabnya setiap tiga bulan. Ini disebut Swarming (swarming, buzzing). Ini semacam jaringan, tetapi dalam kerangka kerja:
Tentu saja, tidak semuanya sesederhana itu. Orang-orang diberi algoritme untuk mencapai sasaran yang memadai yang dapat mereka ambil untuk kuartal tersebut. Mereka membuat lembar flipchart yang menunjukkan perkiraan sprint backlog seperempat ke depan. Hal ini diperlukan agar setelah mereka, dengan mempertimbangkan ketersediaan mereka, secara kasar mengisi simpanan mereka dan berbicara dengan tim lain tentang ketergantungan (siapa, kepada siapa, apa yang akan / tidak akan melakukan apa), ajukan pertanyaan kepada mereka: “Jika Anda menyeret semua pekerjaan ini, apa tujuan yang akan Anda capai, dan dengan ukuran (metrik) apa Anda dapat mengukur tingkat pencapaian? "
Artinya, kami merencanakan backlog kerja, lalu kami merumuskan tujuan untuk mereka, setelah itu kami menolak backlog tersebut. Itu hanya teknik bagaimana mencapai penetapan tujuan yang memadai. Dalam situasi apa pun, jangan berpikir bahwa orang-orang melakukan semua tim untuk rangkaian pekerjaan ini untuk kuartal ini:
- Tim, tentukan tujuan!
- ... Itu dia!
- Kamu yakin akan mencapainya?
- Tidak, kamu baru saja meminta.
Tidak, kami memfasilitasi, yaitu, kami membantu mencapai tujuan yang kurang lebih memadai.
Dalam foto tersebut terdapat perwakilan tim yang dipaksa untuk berkomunikasi. Mereka terkadang datang ke sesi ini dengan perasaan: "Ya, kami memahami apa yang akan kami lakukan, dan tampaknya kami bahkan tahu ketergantungan pada tim lain, karena kami berbicara dengan mereka minggu lalu." Tetapi ketika Anda bertanya kepada saya secara langsung untuk mengatakan apa yang akan dilakukan tim kuartal ini, ketergantungan akhirnya terungkap:
Kami memberi mereka alat sehingga, setelah membicarakan kecanduan mereka, mereka dapat menampilkannya dan melihat siapa yang bergantung pada siapa. Lompatan vertikal adalah sprint dalam satu blok, lompatan horizontal adalah tim. Di persimpangan, tim menempatkan fitur apa yang akan dilakukannya, dan menggambarnya dengan panah merah: "Tapi mereka berjanji kepada kami untuk melakukannya sprint sebelum API, lalu kami akan membuat tombol di depan." Ini adalah protokol perjanjian yang telah kami sepakati dengan Anda, siapa, kepada siapa, kapan dan apa:
Presentasi Pemilik Produk
Lebih lanjut pada presentasi, pemilik produk menunjukkan hasil dari timnya:
Satu-satunya yang mencoba merekatkan otak bagaimana skenario ujung ke ujung akan bekerja adalah bisnis. Ada pertanyaan untuk Pemilik Produk di awal jenis: "Skenario ujung-ke-ujung apa yang akan berhasil?" - sering kali tetap tidak terjawab: "Tunggu, kami bertanggung jawab atas komponen ini. Ini akan berhasil untuk kami, pertanyaan Anda bukan untuk kami. Peluru beterbangan dari pihak kita, lihat tim lain untuk mendapatkan jawaban atas pertanyaan Anda. " Pada awalnya, bisnis tidak memahami apa pun, tetapi mencoba merekatkan gambaran ini di kepalanya.
Dependensi eksternal
Xsolla memiliki garis kedua dari belakang dari Tech Ops. Orang-orang sudah memahami bahwa penting untuk terlibat dalam DevOps, masing-masing, untuk membawa dukungan lingkungan di dalam tim. Tapi saat itu (enam bulan lalu) itu adalah unit eksternal. Manajer operasi juga mempresentasikan - dia berjalan melewati stiker merah dan mengkonfirmasi: “Ya, Anda mendorong saya ke sini sehingga kita perlu menerapkan lingkungan ini dan itu. Saya bertanggung jawab, kami akan melakukannya ":
Sangat menarik bahwa ketika dia mengatakan di satu stiker apa yang akan mereka lakukan, timnya mengoreksi:
- Tunggu, bung, kami tidak menanyakan ini padamu, tapi sesuatu yang lain. Mengerti?
- Mengerti.
- Maukah kamu melakukannya?
- Aku akan melakukannya.
- BAIK.
Mereka punya masalah dengan pengacara, pemasaran, desainer - orang-orang ini ada di Amerika (di Los Angeles), dan mereka tidak datang ke pertemuan ini. Oleh karena itu, ketergantungan pada mereka digantung, tetapi ada ketakutan: mungkin mereka akan melakukannya, tetapi Anda perlu menelepon secara terpisah, berkomunikasi, dll. Kesimpulan dari perusahaan ini adalah mereka juga mengundang mereka untuk perencanaan triwulanan berikutnya.
Perawatan resiko
Ada algoritme tertentu tentang bagaimana risiko ditangani. Ide utama: kami menciptakan lingkungan di mana, ternyata, manajemen puncak dapat mengatur tugas. Dan bahkan tidak menakutkan, mereka siap menerimanya. Mereka berkata: "Jika saya memperbaiki kontrak dengan agen outsourcing kami di sini, ternyata kami dapat melakukan lebih banyak dari yang saya inginkan," dan mereka pun terlibat.
Ini adalah contoh pemecahan masalah yang dapat diterima jika Anda memiliki segalanya dalam pertemuan ini:
Pemilihan jari
Langkah terakhir adalah memeriksa apakah tim benar-benar siap untuk mengambil tanggung jawab atas tujuan yang telah mereka kembangkan. Kami meminta Anda untuk mengangkat jari:
- 5 jari - lurus, sangat percaya diri dengan tujuan mereka;
- 1 jari - dengan tujuan secara umum, ini adalah bencana, mereka harus diulang.
Anda melihat gambaran besarnya dan jika Anda melihat kepercayaan diri yang rendah terhadap perusahaan, minta mereka untuk melihat sekeliling: “Lihat, tampaknya Anda sendiri tidak percaya pada tujuan Anda. Ulangi, buatlah agar Anda sendiri percaya pada rencana Anda. Tidak ada yang mendorong mereka ke Anda (setidaknya mereka mencoba) ":
Retrospektif Bersama Akhir Kuartal: Tinjauan OKR (Periksa & Adaptasi)
Di akhir kuartal kami mempertemukan semua orang lagi. Sebenarnya, ini adalah retrospektif besar (disebut OKR Review di OKR):
Saya akan menunjukkan kepada Anda apa yang terjadi di sana dengan contoh nyata. Tujuan yang diambil tim untuk kuartal ini dituliskan. Mereka memiliki penilaian terencana tentang dampak pada metrik, yaitu pada tujuan yang diinginkan bisnis dari tim dan perusahaan. Pencapaian aktual dinilai:
Di sini, jepretannya lagi: apakah Anda tahu cara mengevaluasi rencana-fakta tidak hanya sebagai "Menurut kami fitur ini mungkin dipengaruhi", tetapi apakah produk dengan bisnis mengumpulkan metrik nyata dari pengujian A / B, dari beberapa opsi menjangkau pelanggan.
Pilihan lain: jika tim belum menyiapkan insinyur, tidak tahu cara cepat menjangkau klien, mereka mengevaluasi, seperti dalam Perencanaan Poker, hanya dengan jari mereka: "Tampaknya bagi kami bahwa kami telah mencapai tujuan ini begitu banyak":
Mereka pada dasarnya menetapkan sendiri persentase pencapaian: Anda dapat melihat bahwa tim telah mencapai 88% di kuartal ini. Idenya adalah bahwa metrik seperti itu menunjukkan:
- Seberapa ambisius tujuan yang Anda tetapkan dengan bisnis;
- Seberapa lancar Anda tahu cara membawanya:
Akhirnya, ada retrospektif rutin dan masing-masing tim bekerja secara terpisah. Poin kunci: masalah umum dicabut: tidak secara terpisah untuk setiap tim, tetapi masalah yang menembak beberapa sekaligus. Biasanya kami membuat kriteria 3+ tim. Jika mereka memiliki masalah yang sama, maka perlu menyelesaikannya di tingkat seluruh unit:
Ringkasan. Apa masalah pemimpinnya?
Apa tantangan bagi kita dalam keseluruhan cerita ini? Tampaknya sudah jelas apa yang harus dilakukan. Tetapi Anda berada dalam konteks lingkungan yang lebih besar: tim lain, bisnis, memahami bagian mana dari perjalanan pelanggan yang Anda putuskan dan untuk pelanggan mana. Faktanya, ada banyak dari kita, seperti prospek dan pimpinan tim:
Apa persyaratan bagi kita dalam skala tersebut? Apa masalah pemimpinnya? Fakta bahwa ukuran itu penting ... :)
Cheburashka bermutasi menjadi buaya untuk kelangsungan hidup yang lebih baik di lingkungan keras perusahaan besar ... Dengan kata lain, Anda perlu mengembangkan diri. Ini pepatah yang menyakitkan, tetapi kenyataannya, jika Anda tidak mengembangkan diri sendiri, orang-orang di bawah Anda juga tidak melakukannya. Dan di perusahaan besar, tuntutannya kejam tentang seperti apa Anda seharusnya menjadi pemimpin. Anda harus mampu mengatur lingkungan untuk sejumlah besar tim, yaitu mengembangkan diri berkali-kali dengan lebih aktif.
Pemimpin apa yang bertahan di Agile
Pada dasarnya, Anda perlu berhenti mengelola orang. Bentuk lingkungan tempat orang mengatur dirinya sendiri. Berhenti menjadi ahli, jadilah negosiator.
Berikut adalah sesuatu yang perlu diverifikasi seberapa curam Anda telah berkembang di semua bidang ini:
Tahun ini kami akan mengadakan Conf TeamLead kedua di Moskow alih-alih Conf TeamLead Saint di St. Petersburg. Sudah pada 16 dan 17 November, kita akan bertemu langsung dan membahas apa yang berubah selama ini. Kami sudah merindukan konferensi tatap muka yang sebenarnya. Sehingga Anda bisa melihat karisma pembicara di atas panggung dan kemudian mengajaknya satu jam lagi di aula. Untuk minum kopi setiap bulan dan melihat semua pimpinan tim yang Anda kenal sekaligus. Dan untuk bulan berikutnya setelah itu, pilah catatan dengan kontak, buku, dan kata kunci.
, , , , . : , , -, , .
. . . 2019 .