Saya ingin berbicara tentang pengalaman saya mempercepat otomatisasi dalam tim programmer, dan tentang teknik apa yang kami praktikkan, dan apa yang terjadi.
Kondisi awal
Kami melakukan percobaan kami untuk mempercepat pekerjaan programmer dalam kondisi berikut:
- itu adalah perusahaan manufaktur yang terdistribusi secara geografis;
- 4 programmer 1C dan saya, pemimpin mereka mengambil bagian dalam percobaan;
- kami adalah pemrogram penuh waktu yang mendukung konfigurasi yang rumit;
- kami menjadi bosan, dan kami memutuskan untuk berkembang.
Pertama-tama, keinginan untuk berkembang muncul setelah kami menarik perhatian sebuah buku karya Jeff Sutherland tentang Scrum. Anda mungkin sudah tahu banyak tentang teknik ini, jadi saya tidak akan memikirkannya. Bagian utama dari artikel ini bukan tentang Scrum.
Jadi, ketika kami membaca buku ini, kami menemukan ada dilema, yaitu terjemahan nama buku yang salah. Nama bahasa Inggris menunjukkan bahwa Scrum mempercepat empat kali: "Seni melakukan pekerjaan dua kali lebih banyak di separuh waktu."
Dan dalam terjemahan Rusia dinyatakan bahwa Scrum adalah metode revolusioner manajemen proyek. Ketika manajer TI siap untuk wawancara, mereka sering diberitahu - memperhatikan apa yang orang berkonsentrasi pada - proses atau hasilnya. Terjemahan Rusia berfokus pada proses .
Mengapa saya membicarakan hal ini dengan penuh percaya diri? Saya melihat lusinan orang yang menggunakan Scrum secara langsung. Sebagian besar dari mereka baru memulai proses Scrum , dan ketika Anda bertanya kepada mereka: "Apa yang telah Anda ubah?" - mereka mengatakan: "Kami telah menjadi transparan, menarik, menyenangkan." Tetapi ketika Anda tertarik pada bagaimana hasilnya berubah, apakah kecepatan pengembangan telah meningkat, apakah Anda mulai menyerahkan proyek lebih cepat, ternyata mereka tidak mengetahui hal ini, karena mereka tidak mengukur efektivitasnya .
Jadi, kami membaca buku ini dan meluncurkan Scrum klasik dengan semua tahapan utama proses bisnisnya (ditunjukkan pada gambar).
Saya akan menyebutkan metode pengukuran (akan muncul di seluruh laporan). Cara tradisional untuk mengukur dalam Scrum adalah perencanaan poker . Ini terdiri dari yang berikut ini: untuk setiap tugas, tim (atau peserta yang memahami sesuatu dalam tugas ini) diberi skor 1, 2, 3, 5, 8 dan hingga 34 (angka dari seri Fibonacci). Menurut totalitas perkiraan, rata-rata diambil. Tugas dianggap selesai saat diterima oleh pelanggan.
Hasil pertama
Apa yang diberikan oleh pengantar Scrum klasik kepada kita? Sebelum dia, output harian rata-rata per orang adalah 4,2 poin, dan dengan diperkenalkannya, indikator naik menjadi 7,73 poin . Ternyata produktivitas kami berlipat ganda.
Semua orang menyukainya, kami memberi tahu kolega dari departemen lain tentang hal itu, seluruh perusahaan menjadi tertarik, semua orang mulai menerapkan Scrum di rumah.
Tapi tidak ada yang terjadi, karena semua orang terbawa oleh jimat - mereka membeli papan gabus, menempelkan stiker pada mereka, dan membatasi diri pada hal ini. Bahkan pemiliknya, yang juga tertarik pada Scrum, menggembalakan para karyawan: dia pergi ke papan gabus, mengambil fotonya, lalu kembali seminggu kemudian dan mengambil fotonya lagi - papan tidak berubah.
Saya menginginkan lebih
Peningkatan kinerja dua kali lipat terasa membosankan bagi kami. Jadi saya mulai membaca buku itu lagi. Di halaman 54-55, beberapa shuhari memperhatikan. Dalam buku itu tertulis bahwa ini adalah prinsip dari Aikido yang mengatakan - pertama lakukan segalanya sesuai aturan (syu), kemudian mulailah berimprovisasi (ha), dan baru kemudian pisah dan lakukan teknik Anda sendiri (ri) .
Menariknya, dalam Panduan Scrum yang terkenal, prinsip ini dibuang, dan hanya "syu" yang tersisa dari "shuhari".
Dan kami memutuskan untuk terus maju.
Algoritma akselerasi dasar yang direkomendasikan dalam buku Jeff Sutherland adalah siklus Deming . Dengan kata-kata sederhana, dapat dirumuskan sebagai berikut: Anda melihat bagaimana orang-orang Anda bekerja, Anda perhatikan di mana mereka bodoh, di mana ada penundaan, Anda membuat semacam perubahan, Anda menerapkannya dan menonton apa yang terjadi. Jika menjadi lebih baik, lebih cepat - Anda meninggalkan perubahan. Jika semakin buruk - hapus perubahan. Yang utama adalah melakukannya dengan cepat.
Ngomong-ngomong, Teori Kendala Sistem Goldratt mengatakan tentang hal yang sama, hanya berkonsentrasi pada yang lain. Dia mengatakan - temukan tautan tersempit di sistem Anda, perluas atau hapus. Kemudian ulangi lagi.
Tujuan dari yang satu dan yang lainnya adalah untuk memungkinkan mendapatkan hasil secepat mungkin pada siklus produksi penuh. Gagasan yang sama, secara kebetulan, diungkapkan oleh pengembang Toyota Production System - tujuan dari sistem produksi adalah untuk memastikan bahwa uang klien tiba secepat mungkin.
Peran pengamat untuk alur kerja dilakukan oleh Scrum-master. Kita dapat mengatakan bahwa ini adalah pelatih. Ketika Anda membaca pengalaman rekan Scrum Anda, mereka menganggap Scrum-master sebagai pembela dan mengatakan bahwa Scrum-master harus menghilangkan hambatan , mengusir beberapa orang, membantu dalam sesuatu.
Namun, saya yakin bahwa Scrum-master adalah seorang pengamat dan pelatih yang mengajar orang-orangnya untuk bekerja lebih cepat, melihat di mana mereka bodoh, membantu, meminta, mencari sesuatu yang baru, mencoba kombinasi yang berbeda. Seperti seorang pelatih sepakbola.
Tim eksperimen.
Untuk memahami konteks tempat eksperimen kami berlangsung, kami perlu memperkenalkan tim. Jika saya memberi tahu Anda bahwa ada dua Stas, Oleg dan Igor, ini tidak akan memberi tahu Anda apa-apa, karena tidak ada yang tahu orang-orang ini. Anda, plus atau minus, hanya tahu saya.
Oleh karena itu, alih-alih dua Stasov, Oleg dan Igor, tim akan menampilkan karakter yang diketahui semua orang dan yang sama mungkin dengan orang sungguhan:
- Kelinci itu pintar, diam, diam.
- Piglet adalah yang termuda, tercepat, paling penasaran.
- Keledai adalah yang paling tertekan, dan dia seperti itu dalam hidup.
- Dan burung hantu ... Sebenarnya, buku aslinya bukan burung hantu, tapi burung hantu elang, maskulin. Jadi tim memiliki burung hantu elang.
Langkah selanjutnya adalah improvisasi.
Pada hari pertama, ketika kami memutuskan untuk mengubah segalanya, kami:
- Membuang papan Scrum dan stiker. Scrum-board digantikan oleh sistem informasi berdasarkan 1C: Manajemen dokumen;
- Stiker telah diganti oleh tugas-tugas dalam sistem informasi ini;
- Poker kiri dan pengukuran kecepatan;
- Rapat harian yang dihapus, retrospektif, proyek (secara umum, sebagai entitas) - hanya menyisakan klasifikasi tugas berdasarkan topik tertentu;
- Ditambahkan pemantauan konstan downtime, kerugian;
- Dan mereka menambahkan perubahan proses yang konstan.
Secara total , selama percobaan ini, yang berlangsung sekitar satu tahun bersama kami, kami menemukan sekitar 40 akselerator . Saya mencoba mengelompokkan 40 akselerator ini dan sekarang saya akan segera memberi tahu Anda bagaimana masing-masing memengaruhi alur kerja.
Untuk jaga-jaga, saya akan menyebutkan dari mana akselerator ini berasal. Tidak ada yang baru di sini. Saya datang dengan beberapa prinsip sendiri, beberapa orang saya datang dengan sesuatu, kami membaca sesuatu dari buku. Misalnya, ketika dalam sebuah buku disarankan untuk bertindak seperti ini untuk menyelesaikan masalah seperti itu, Anda perlu mengambil dan mencoba. Jika ternyata, maka tinggalkan saja. Jika tidak masuk akal, kami membuangnya.
Tidak ada perubahan
Jadi, hal pertama yang memulai kami memikirkan kembali proses tersebut adalah buku "Code of Samurai" . Saya sarankan semua orang membaca, membeli, dan menyimpannya di rumah. Karena ditulis 500 tahun yang lalu, dan sudah 500 tahun yang lalu, orang tahu bagaimana mengelola, bagaimana mematuhi, bagaimana mengembangkan dan bagaimana meningkatkan.
Perhatian karakter, yang saya sebut Piglet, dalam "Kode Samurai" tertarik oleh dua frasa ini. Dia melihat bahwa:
- Keputusan harus diambil dengan sangat cepat - dalam tujuh tarikan nafas;
- Dan jika Anda tidak mengambil keputusan dengan cepat, maka hasilnya akan menjadi bencana.
Piglet begitu terbawa oleh gagasan ini sehingga jika dia tidak bisa membuat keputusan dalam tujuh napas, dia menolak. Suatu kali saya bahkan melewatkan minuman keras yang menyenangkan.
Menjadi menarik bagi saya, saya membaca kembali buku ini lagi dan memperhatikan bahwa kira-kira setiap halaman ke-10 mengatakan: untuk membuat keputusan dengan cepat, Anda harus berpikir terlebih dahulu bagaimana Anda akan bertindak dalam situasi tertentu.
Seperti apa bentuknya?
Itu seperti sebuah strategi ketika Anda memiliki aturan untuk membuat keputusan .
Apa strategi yang paling umum di negara kita? Ketika Anda bertanya kepada seseorang: "Apa strategi perusahaan Anda?", Mereka menunjukkan kepada Anda "kaki" panjang yang mengatakan apa yang akan mereka lakukan tahun ini - apa rencana perusahaan, anggaran, tugas, bagaimana mereka akan tumbuh dalam penjualan, dll. .d.
Definisi ini tidak dekat dengan saya, tidak cocok untuk tujuan saya.
Karena itu, kami pergi untuk diri kami sendiri hanya definisi kedua dan mulai menganggap strategi hanya sebagai seperangkat aturan untuk membuat keputusan .
Karenanya, nol perubahan yang kami perkenalkan dalam proses Scrum kami adalah bahwa, dalam tim kami , mencoba teknik percepatan baru, kami merumuskan prinsip-prinsip untuk mereka , memberi mereka nama (untuk membuatnya lebih mudah diingat dan didiskusikan), dan menggunakannya lebih lanjut dalam pekerjaan kami . Prinsip-prinsip ini adalah pembawa segala yang lain.
Rahasia utama perbaikan
Prinsip dasar berikutnya yang kita miliki adalah "rahasia utama perbaikan . "
Anda menginginkannya, percaya saja, Anda menginginkannya - tidak, tetapi kami telah menemukan "rahasia utama perbaikan", efektivitas yang telah kami lihat berkali-kali.
Dapat dirumuskan sebagai berikut: 75% masalah dalam perubahan muncul karena fakta bahwa orang tidak bekerja seperti yang diperintahkan.
Mengapa ini terjadi? Faktanya adalah orang-orang yang mencoba menerapkan perubahan (misalnya, Scrum) datang dan memberi tahu bawahan mereka: "Anda sekarang bekerja dengan cara yang baru." Dan kemudian mereka pergi begitu saja. Dan ketika mereka kembali dalam satu atau dua minggu, mereka melihat bahwa tidak ada hasil. Dan pada akhirnya, "curang" ini memutuskan bahwa Scrum tidak berfungsi, dan menghapusnya secara permanen dari memori mereka dan dari set alat mereka. Hal yang sama terjadi dengan semua metode lain. Saya melihat ini beberapa kali di perusahaan saya, dan mereka terus-menerus berusaha meyakinkan saya bahwa sesuatu (semacam perubahan) tidak berfungsi.
Karena itu, kami telah membentuk prinsip dasar perubahan - agar perubahan terjadi, itu harus diterapkan . Jika kami memutuskan bahwa kami tidak memiliki dukungan teknis hari ini - kami hanya ingin melihat apa yang akan terjadi tanpa dukungan teknis - maka tidak ada dukungan teknis, dan tidak ada yang lain.
Ini mungkin adalah hal terpenting yang menjadi dasar kesuksesan kami - pada kenyataan bahwa orang-orang yang bekerja dengan saya menerima aturan-aturan ini. Mereka tidak meminta saya untuk perintah, instruksi, perubahan staf, atau permutasi. Kami hanya setuju dan melakukannya bersama. Akibatnya, dalam satu hari kita dapat memeriksa pengoperasian beberapa metode, praktik, dll.
Selalu ada banyak manajer keren di sekitar. Saya sendiri pernah ingin menjadi satu.
Siapa manajer yang keren? Ini adalah orang yang percaya bahwa perlu untuk menetapkan tugas, untuk menyebutkan tenggat waktu, dan ketika tenggat waktu berlalu, dan tugas tidak selesai, eksekutif yang harus disalahkan. Ini bukan milikku, tetapi ekspresi mereka. Mereka mengatakan demikian: Scrum semua omong kosong, Anda harus mengatur tugas dan mengeringkan ketika mereka gagal memenuhi tenggat waktu.
Tetapi kami memutuskan sendiri bahwa tenggat waktu itu jahat . Mengapa
- Pertama, ketika Anda memiliki kumpulan tugas, misalnya, 150, dan Anda menetapkan tenggat waktu untuk masing-masing, Anda perlu menghitung ulang tanggal ini setiap hari, karena mereka "hanyut" sepanjang waktu. Akibatnya, sejumlah besar waktu dihabiskan untuk administrasi;
- Kedua, karena fakta bahwa kurma "melayang" sepanjang waktu, mereka selalu salah ;
- Selain itu, sejauh mana seseorang jatuh ke dalam waktu tidak berarti apa-apa sama sekali . Hanya saja seseorang, untuk suatu periode, dapat memiliki satu tugas;
- Dan untuk apa mereka dibutuhkan? Jika Anda banyak ribut, tetapi sebenarnya waktunya selalu salah? Pengaturan waktu hanyalah sebuah jimat;
- Kami memutuskan untuk diri kami sendiri bahwa manajemen waktu adalah "pendekatan feminin" dalam manajemen .
Poin terakhir harus diklarifikasi secara terpisah. Saya segera meminta wanita untuk tidak tersinggung, terutama karena pendekatan ini sekarang bahkan lebih umum pada pria. Metafora ini diciptakan untuk menjelaskan tindakan beberapa manajer.
Sebuah analogi dari kehidupan: bayangkan bahwa seorang wanita meminta seorang pria untuk memperbaiki keran dan memberinya 5 hari untuk melakukannya. Apa yang akan terjadi selama lima hari ini? Seorang pria akan melakukan beberapa bisnisnya sendiri, dan seorang wanita akan mengingatkan? Tidak, tidak akan. Dia akan datang setiap hari dan diam - diam menonton - diperbaiki atau tidak diperbaiki. Dan inilah hari kelima, wanita itu muncul, terlihat - tidak memperbaikinya. Menunggu di pagi hari, dan di pagi hari ...
Dan yang paling penting, bagi seorang wanita ini adalah hasil yang positif . Mengapa Karena setelah itu bisa Anda lakukan seperti ini:
Sekarang gambarkan analogi dengan manajer tangguh yang mengatur tugas sehingga orang tersebut tidak menyelesaikannya tepat waktu, dan kemudian ia bisa diledakkan . Menurut saya ini semacam kesadisan. Mereka bersenang-senang dan percaya bahwa ini adalah pekerjaan , dan untuk itu Anda harus membayar 300-500 ribu rubel sebulan.
Kami tidak seperti itu, oleh karena itu kami telah merumuskan sendiri prinsip bahwa suatu istilah hanya diperlukan ketika tidak ada yang perlu dilakukan setelahnya . Misalnya, tenggat waktu pelaporan. Setelah itu, Anda tidak bisa lagi melakukan tugas itu, karena penalti untuk pelaporan terlambat, tampaknya, sekitar 20 persen dari pendapatan?
Tujuan
Tentunya semua orang kebetulan melihat bawahan mereka di negara bagian ini.
Anda datang kerja - dan karyawan Anda duduk seperti ini.
Atau seperti itu.
Apa hubungannya dengan itu? Saya biasa melakukan ini:
Akibatnya, ia terus terang dikirim beberapa kali, suatu kali membawa seseorang ke pingsan, dan ini tidak termasuk air mata yang tertumpah - baik pria maupun wanita. Menjijikkan, masih malu.
Seseorang yang terus menerus berteriak berubah menjadi kotoran. Meskipun lebih tepat untuk mengatakan bahwa bajingan adalah orang yang membuatnya seperti itu.
Mengapa kondisi ini buruk? Jika Anda terus-menerus meneriaki seseorang, Anda tidak akan melihat air matanya lagi, yang berarti Anda tidak akan tahu bahwa dia sedang duduk dan tidak melakukan apa-apa . Karena seseorang yang depresi tidak melakukan apa-apa . Untuk efisiensi, ini adalah kerugian besar. Jika seseorang menjadi depresi di pagi hari, dia akan menghabiskan sepanjang hari menjelajahi Internet, membuka konfigurator dan beralih bolak-balik dengan cepat. Tetap saja, programmer tetap duduk di dekat monitor dari pintu, bukan?
Karena itu, lebih baik jangan berteriak pada orang. Penting untuk menganalisis situasi, dan mungkin ternyata orang tersebut tidak memiliki motivasi yang sama . Tetapi seseorang tidak memiliki motivasi karena dia tidak memiliki tujuan . Dia datang untuk bekerja dan tidak tahu kenapa. Dan jika dia juga menerima semacam negativitas di rumah, misalnya, karena dia tidak mencapai tujuan rumah (istrinya ingin pergi berlibur ke Maladewa, tetapi dia tidak dapat menyediakan ini), dia datang bekerja hanya untuk duduk . Karena bagaimana mencapai tujuan, dia tidak tahu . Atau mungkin dia tidak punya tujuan.
Oleh karena itu, kami telah merumuskan sendiri prinsip yang kami butuhkan untuk membicarakan tujuan . Pertama, kami duduk satu per satu, berbicara, lalu berkumpul, berdiskusi.
Sebagai hasilnya, kami berhasil mendapatkan tujuan "rata-rata" tertentu - satu untuk semua .
"Sasaran rata-rata" ini seperti ini - bekerja untuk pemberi kerja di masa depan . Kata-kata ini memiliki banyak makna (sepertinya bagi saya). Saya hanya akan menyebutkan dua:
- Pertama, tujuan programmer tidak terkait dengan pekerjaan saat ini untuk organisasi saat ini. Karena orang-orang yang menjadi terikat pada organisasi saat ini ketika mereka meninggalkannya menerima pukulan yang sangat besar untuk kepentingan mereka. Lagi pula, apa yang penting di sini, tidak ada yang perlu di sana .
- Kedua, apa artinya “bekerja untuk majikan di masa depan”? Ini berarti mendapatkan pengalaman paling abstrak yang akan bermanfaat bagi sebagian besar pengusaha di masa depan.
Ini adalah tujuan yang kami rumuskan untuk anak-anak, dan ini memiliki efek yang sangat positif pada mereka.
Beberapa kata tentang "kustomisasi on the fly" adalah cara murni teknis untuk mempercepat pekerjaan.
Gambar menunjukkan daftar akselerator yang tidak lengkap. Ini adalah solusi abstrak yang memecahkan kelas masalah tertentu dengan sangat cepat . Contoh paling umum adalah validasi data. Alih-alih setiap kali ketika pengguna ingin melarang sesuatu sambil memegang dokumen, menulis kode selama 30 menit, kami melakukan pemeriksaan dalam tiga menit tanpa meluncurkan konfigurator. Itu saja.
Setelah menambahkan "Sasaran Rata-rata" dan "Kustomisasi saat itu", kami mendapatkan "Perangkat Pemberhentian Layak". Apa ini Ini hanya seperangkat pengetahuan, pengalaman, ide-ide yang dibawa seseorang, meninggalkan perusahaan, bersamanya .
Untuk setiap anggota tim, kami membuat daftar yang cukup besar tentang apa yang perlu kita pelajari, apa yang perlu kita coba, apa yang perlu kita pahami, sehingga ketika kita meninggalkan perusahaan, ini dapat diterapkan ke pekerjaan baru.
Prioritas adalah hal yang sangat penting.
Dalam hidup saya, saya telah mencoba banyak opsi berbeda untuk menetapkan prioritas pada tugas - sejauh saya menggunakan model pengembangan vektor inovatif suatu perusahaan dari disertasi doktor di bidang ekonomi.
Tetapi praktik telah menunjukkan bahwa efisiensi adalah kesederhanaan. Oleh karena itu, pada akhirnya, untuk menetapkan prioritas, saya memilih matriks Eisenhower yang biasa . Semua orang tahu tentang alat ini - ketika semua tugas dibagi menjadi empat kotak.
Dalam prinsip-prinsip tim, ini tercermin sebagai berikut:
- Urgensi / Pentingnya dilakukan oleh manajer;
- Karyawan tidak memiliki pilihan perintah eksekusi;
- Untuk Nefig.
Mengapa karyawan itu tidak punya pilihan perintah eksekusi? Karena kemampuan untuk memilih tugas bagi programmer adalah kejahatan yang hebat untuk efisiensi . Dia dapat memilih tugas sepanjang hari. Apa itu hari? Ini 20% dalam seminggu. Itu saja, hari telah berlalu. Dia tidak hanya memilih tugas, dia bisa masuk ke konfigurator, melihat bagaimana itu diselesaikan, apa perangkapnya, dan kemudian dia akan takut dan berubah pikiran tentang melakukannya. Begitulah yang terjadi sepanjang hari, dan mungkin lebih.
Dan dua kejahatan terbesar untuk efisiensi adalah ketika seseorang takut dan ketika dia tidak mengerti .
Menakutkan - ini adalah saat seseorang duduk dan dia:
- Menakutkan untuk ditanyakan;
- Mengerikan itu mengerikan;
- Sangat menakutkan untuk mengalihkan perhatian rekan kerja untuk bertanya sesuatu;
- , .
, . , – , – ?
, , . , . . ?
, .
, metadata.js.
, , 20 . , , – , – . .
, . , .
, . . , . , , .
, ? , , , .
- , , , . ? : « , ». , . - – . , : «, , ». , , , , . , , .
, ? – , . :
- .
- « ». , – . , , – . – , , .
- - – - . , - , – . , : «, , , , , ». , – 30 .
- – . : , , , . , . : , . : «, , » – . - - .
, , . – – , , .. , .
– , ? . , , , , .
. 30 % . :
, … , , . , , , . , . .
– .
, , . . , — , . , , – , . – . , . , . – . , , , .
, , .
… , « ». .
, ? . :
, , , . , - , .
, , .. , – . – , , , . « », .
, . . , – , - . , , , , – , , , , – -, .
, , , , . , – , , , -, , , . , . , .
Bos baru datang menggantikannya. Vasya, tentu saja, tidak memberitahunya bahwa semua yang ada di departemennya buruk. Saya harus mulai dari awal, tetapi saya mengalami kesulitan. Bos baru itu adalah gadis yang serius, sangat percaya diri. Dia tidak mau mengakui apa pun, terjun ke mana saja, dan umumnya berbicara kepada saya. Saya harus mencari solusinya.
Menjatuhkan mereka, di departemen pengadaan, Piglet. Saya katakan - berapa lama Anda mengeluh bahwa Anda kekurangan otomatisasi? Inilah Piglet yang Anda inginkan. Pendaratan itu dengan niat jahat, karena Piglet adalah pria yang ceria, menawan, dan gadis-gadis sangat menyukainya (kebanyakan dari mereka berada di departemen pembelian).
Selama seminggu dia hanya duduk bersama mereka - itu adalah tugas dari pusat, untuk duduk dan menonton. Saya menyaksikan, datang dan berkata - mereka bekerja 3% dari waktu. Mereka bekerja - dalam arti pembelian, mencari pemasok, memesan, mis. melakukan fungsi utama mereka. Sepanjang sisa waktu mereka terlibat dalam beberapa jenis proses, birokrasi dan omong kosong lainnya.
Secara alami, kami tidak memberi tahu pembeli tentang hal ini, agar tidak tersinggung. Piglet menerima tugas baru dan kembali ke pengadaan. Dia mulai mengajukan pertanyaan yang tidak nyaman kepada bos, atau sekadar troll. Cukup untuk beberapa hari - bosnya sendiri mendatangi kami di departemen TI dan berkata - ahhh, bagaimana dengan kebun binatang ini?
Yah, saya masih punya rencana dari zaman Vasya - di sini, saya katakan, mari kita lakukan. Dan itu dia.
Sekarang sedikit tentang Kelinci. Dia bekerja sendirian untuk waktu yang sangat lama di pabrik.
Apa yang terjadi pada seseorang ketika dia bekerja sendirian di pabrik untuk 1C sebagai programmer? Dia mulai menolak tugas. Dia melakukannya dengan kualitas sangat tinggi - Saya ingatkan Anda, Kelinci sangat cerdas, ia belajar dengan baik di sekolah dan universitas. Mereka membawanya tugas, kata mereka - mari kita lakukan, dan Kelinci menjawab - tidak, Anda tidak perlu melakukan ini, dan memberikan banyak alasan yang tampaknya obyektif mengapa masalahnya benar-benar tidak perlu diselesaikan.
Semuanya akan baik-baik saja, tetapi dia mulai melakukan hal yang sama dengan saya. Misalnya, saya mengatur tugasnya. Dia tidak mengatakan apa-apa, duduk di depan komputer.
Saya menjalankan bisnis saya dan dengan tulus berpikir bahwa ia duduk dan menyelesaikan masalah. Dan dia, si anjing, duduk dan berpikir mengapa itu tidak boleh dilakukan . Hasil karyanya dalam sehari, atau bahkan dua, adalah daftar alasan berkualitas tinggi mengapa tugas itu tidak boleh dilakukan!
Dan jika dia masih berhasil mengatasi tahap ini, dia bersandar di kursinya, melihat ke langit-langit dan mulai menceritakan kesulitan apa yang akan dia hadapi dalam menyelesaikan masalah ini. Saya katakan - eh, berhenti! Apakah Anda tahu cara melakukan semua ini? Ya, benar. Jadi mengapa Anda memberi tahu saya tentang kesulitan Anda di sini! Nah, jadi saya ... - kata Kelinci.
Sebagai hasilnya, kami merumuskan prinsip paling sederhana: masalah harus diselesaikan . Tidak peduli apa yang Anda pikirkan, jika saya, sebagai seorang pemimpin, mengambil tugas ini untuk bekerja, maka Anda harus menyelesaikannya - tanpa opsi. Jangan mencari cara untuk menghindari tugas ini. Dan itu saja, lebih dari situasi ini tidak muncul.
Ini adalah prinsip yang sangat sederhana. Tugas besar dan kecil. Scrum mengatakan - Anda perlu memecah tugas menjadi beberapa bagian sehingga masing-masing tidak lebih dari satu hari.
Namun terkadang ternyata seperti ini. Seorang pria duduk, melakukan tugas, dan selesai, misalnya, pada 15-00, dua jam sebelum akhir hari kerja. Keengganan untuk memulai tugas baru. Demikian pula di pagi hari - sambil kopi, surat, jejaring sosial, itu, dan hanya kemudian tugas.
Untuk menggunakan cut-off waktu ini secara efektif, kami telah mengidentifikasi kumpulan tugas khusus, yang kami sebut "shorties". Mereka tidak mematuhi matriks Eisenhower, berbaring di daftar terpisah, dan dimaksudkan khusus untuk "memasukkan lubang." Ada satu jam tersisa sebelum akhir hari kerja - buat beberapa shorties. Sederhana, tanpa menyelam ke dalam konteks, tetapi tugas yang bermanfaat. Jika Anda tidak mengabaikannya, Anda bisa mendapatkan peningkatan efisiensi tiga puluh persen.
Lalat yang penting adalah aku.
Scrum Klasik mengatakan Anda harus melakukan pertemuan harian di pagi hari. Dan saya ingat favorit saya mengendalikan dan melihat melalui prismenya. Apakah pertemuan pagi harian? Ini adalah tindakan manajemen sekali pada siang hari. Yaitu dalam Scrum klasik, Anda dapat mendekati helm sekali sehari.
Ini tidak cukup bagi saya, karena jika pada pertemuan itu seseorang mengatakan bahwa semuanya berjalan baik baginya, dan setelah lima menit itu tidak berhasil, maka saya akan mengetahuinya hanya pada hari berikutnya, setelah kehilangan 20% efisiensi.
Jadi saya mengganti rapat harian dengan mengendalikan.
- Anda bertanya sekali sehari - Anda mengelola sekali sehari;
- Anda bertanya sekali seminggu - Anda mengelola seminggu sekali;
- Anda bertanya sebulan sekali - Anda mengelola sebulan sekali;
- Anda bertanya 5 kali sehari - Anda mengelola 5 kali sehari;
- Manajemen adalah perubahan ke arah yang benar .
Secara alami, papan scrum tidak cocok untuk kontrol semacam itu. Dia menjawab pertanyaan "apa yang telah dilakukan selama sprint", tetapi tidak tahu apa-apa tentang apa yang telah dilakukan di pagi hari, atau kemarin. Mereka mencoba beradaptasi - misalnya, menulis tanggal dan waktu eksekusi pada stiker, tetapi membaca informasi ini tidak nyaman.
Karena itu, dewan scrum, sebagai seorang pemimpin, sangat membuat saya marah - tidak memberikan informasi untuk manajemen. Yah, saya membuangnya, menggantikan otomatisasi sederhana dalam sistem informasi. Tugas tertutup segera jatuh ke dalam laporan, yang saya bagi menjadi dua bagian - dari awal minggu dan pagi hari. Mengontrol kedua indikator ini, setiap saat saya melihat ada semacam kegagalan.
Prinsip-prinsipnya sederhana:
- Lihatlah volume tugas beberapa kali sehari ;
- Secara sadar dan mendesak bertanya tentang kesulitan dan hambatan;
- Segera pahami;
- Terima kasih 1C: SEBELUM, bye scrum-board.
Hasil akhir
Hasilnya, kami mendapat teknik tertentu dengan prinsip dan titik kontrol. Karena kami sudah menemukan prinsip-prinsipnya, kami harus mencari nama, karena kalau tidak, tidak nyaman untuk didiskusikan. Pencarian nama itu memakan waktu tepat satu menit!
Pertama, seperti itu.
Dan kemudian seperti itu.
Eksperimen yang kami lakukan sesuai dengan metodologi "Kazakh" berlangsung sekitar satu tahun.
- Biarkan saya mengingatkan Anda, sebelum pengenalan Scrum klasik, efisiensi kami berada di level 4.2 poin.
- Book Scrum menaikkan skor menjadi 7,73 poin.
- Dan di Scrum "Kazakh", kami mulai membagikan 17 poin.
Dan setelah semua ini, saya meninggalkan perusahaan ini, dan “manajer tangguh” datang menggantikan saya. Seorang manajer yang benar-benar keren, yang disebut Scrum "scrum" dan mengatakan bahwa ini adalah teknik baru-ketinggalan jaman. Karena orang-orang saya tetap di perusahaan, mereka terus mengukur efektivitas mereka, dan memberi saya indikator mereka tentang bagaimana mereka bekerja sekarang. Sekarang efektivitas mereka turun menjadi 2,5 poin.
Jika kita menghitung hasil bagi dari pengukuran akhir dan pertama, ternyata semua metode dan prinsip yang diterapkan memberi kita peningkatan efisiensi 4 kali lipat .
PS Ada juga versi video: satu dan dua .