Baru-baru ini, secara tidak sengaja, atas saran dari satu orang baik, sebuah ide lahir - untuk melampirkan ringkasan singkat pada setiap artikel. Bukan abstrak, bukan bujukan, tapi ringkasan. Sehingga Anda tidak bisa membaca artikel tersebut sama sekali.
Saya mencobanya dan sangat menyukainya. Tapi itu tidak masalah - yang utama adalah pembaca menyukainya. Mereka yang sudah lama berhenti membaca mulai kembali lagi, mencap saya seorang graphomaniac. Dan orang baik lainnya menyarankan saya untuk menulis ringkasan untuk setiap artikel lama. Saya setuju dan sekarang, dengan santai, saya menulis cerita pendek ini. Menyebutnya celana pendek.
Saya sampaikan kepada Anda beberapa celana pendek serupa, berdasarkan beberapa publikasi. Mungkin Anda akan menemukan sesuatu yang berguna untuk diri Anda sendiri.
Kucingnya mati, ekornya lepas
Rapat sering kali tidak membuahkan hasil. Mereka berkumpul, mengobrol, dan berpisah.
Hasil atau produk rapat merupakan keputusan. Itu sebabnya mereka biasanya tidak ada. Dan kalaupun ada, kualitasnya tidak selalu bagus.
Kalau rapat terbatas waktu dan harus diambil keputusan, maka (keputusan) itu mutunya buruk.
Jika rapat tidak dibatasi waktunya dan berlangsung sampai ada keputusan, maka keputusan apa pun diambil selama rapat berakhir.
Jika suatu keputusan dibuat pada suatu pertemuan, maka keputusan itu akan diterima - hanya karena otak menghargai apa yang dihasilkan.
Pemahaman tentang buruknya kualitas solusi akan muncul kemudian, namun sudah terlambat.
Untuk mengambil keputusan yang efektif, lebih baik tidak berpartisipasi dalam diskusi, tetapi mengamati secara diam-diam.
Pertama, otak tidak akan sibuk mencari jawaban.
Kedua, tidak ada tekanan untuk mengambil keputusan.
Setelah rapat selesai, Anda bisa dengan tenang memikirkannya dan mengambil keputusan. Kualitasnya akan lebih tinggi.
Kuncinya adalah tetap diam dan mendengarkan selama pertemuan. Agar orang lain tidak khawatir, katakanlah ini adalah posisi sadar.
→
Parasit laten
Pada dasarnya, ada dua pendekatan untuk menetapkan tujuan dan memantau pelaksanaannya: parasit dan simbiosis.
Pendekatan simbiosis adalah untuk memastikan bahwa masalah terpecahkan.
Pendekatan parasit adalah memastikan bahwa masalah TIDAK terpecahkan.
Pendekatan simbiosis bersifat lugas dan lugas, namun sulit diterapkan. Oleh karena itu jarang terjadi.
Tugasnya diatur sedemikian rupa sehingga semuanya jelas—tujuan, sumber daya, dan batasannya.
Pengendalian dilakukan agar permasalahan terselesaikan dengan tepat.
Pendekatan simbiosis adalah menyerahkan sebagian tanggung jawab (apalagi) penyelesaian masalah kepada sutradara.
Pendekatan parasit ini penuh hiasan dan cerdas, namun mudah diterapkan. Oleh karena itu hal ini sering terjadi.
Tugas tersebut diajukan sedemikian rupa sehingga tidak ada yang jelas. Semakin kurang jelas semakin baik.
Dianjurkan untuk tidak melakukan kontrol sama sekali.
Tidak ada tanggung jawab pada pengarah tugas; seluruh “monyet” ditransplantasikan ke leher pelaku.
Tujuan dari pendekatan parasit: manipulasi, tekanan emosional, penegasan diri. Oleh karena itu, sering dijumpai pada pekerjaan mentor dengan karyawan pemula.
Tentu saja yang lebih baik adalah pendekatan simbiosis.
→
Dimensi vs Ilusi
Jika Anda mengevaluasi proses dan hasil kegiatan Anda tanpa pengukuran, Anda akan selalu melakukan kesalahan.
Rating tanpa angka tergantung mood Anda. Suasana hati yang buruk - sepertinya Anda tidak bekerja dengan baik. Suasana hati yang baik justru sebaliknya.
Dengan cara ini, Anda dapat duduk dan bekerja dengan buruk selama seminggu, dan pada hari Jumat Anda dapat memperoleh hasil yang sangat baik, dan tampaknya seluruh minggu berjalan dengan baik.
Pada dasarnya, ada dua jenis metrik: kuantitatif dan alternatif (lebih dikenal oleh programmer sebagai Boolean).
“Tugas selesai tepat waktu” adalah Boolean. Ini sama dengan “Bagiannya bagus” (tanda alternatif kualitas jika tidak bisa diukur dengan angka).
“Kami bekerja dengan baik”, “Kami memenuhi rencana”, “Saya hebat” - juga Boolean.
Sulit untuk membangun proses pengendalian menggunakan estimasi tipe Boolean. Disarankan untuk beralih ke metrik kuantitatif secepat mungkin.
Boolean menghasilkan birokrasi dan formalisme. Misalnya, menyelesaikan tugas tepat waktu dapat dicapai dengan meningkatkan tenggat waktu, menciptakan tugas untuk diri sendiri, dan menerapkan IBD.
Untuk mengelola berdasarkan indikator Boolean, Anda perlu menghabiskan banyak waktu - untuk rapat, analisis, dll. Karena informasinya terlalu sedikit.
Disarankan untuk mengukur proses dan hasil. Maka gambarnya akan menjadi paling lengkap.
Untuk programmer, metode “Planning Poker” dari Scrum direkomendasikan.
→
Ini SPARTA
Katakanlah Anda seorang programmer dan Anda diberi tugas yang serius. Dan Anda berpikir bahwa masalah tersebut tidak perlu diselesaikan - itu bodoh, berbahaya.
Perilaku khas dalam situasi seperti ini: menampilkan tugas di bidang publik. Kirimkan untuk disetujui oleh atasan, luncurkan proyek internal, catat di sistem, dll.
Di sinilah semuanya rusak. Orang yang membawa tugas tidak mau dianggap bodoh. Dan begitu mereka memasuki arena publik, mereka akan membela diri.
Penting bagi seseorang untuk tidak kehilangan muka, dalam arti politik. Hal utama dalam politik adalah jangan pernah mengakui kesalahan Anda. Anda tidak perlu melakukan apa pun, tetapi yang utama adalah jangan sampai ada kesalahan yang diakui.
Seseorang akan melakukan yang terbaik untuk membuktikan bahwa programmer adalah penjahat, idiot, penentang perubahan. Dan programmer masih harus menyelesaikan masalahnya.
Dalam beberapa kasus, seseorang akan mengatur segalanya sehingga programmer tidak menyelesaikan masalah sama sekali. Maka orang tersebut akan menjadi “kulit putih”, dan programmernya akan menjadi benar-benar “hitam” (dia menolak dan pada akhirnya gagal).
Ada beberapa solusi.
Yang pertama adalah menjadi seorang programmer bisnis, memahami bidang-bidang terkait, dan menentukan sendiri apa dan bagaimana cara mengotomatisasi di sana.
Yang kedua adalah artikel Ketua Perubahan. Misalnya, direktur pengembangan.
Ketiga, jangan muncul dan lakukan saja apa yang diperintahkan.
Keempat - Jalan Sparta, penolakan cepat terhadap keputusan. Lebih dikenal dengan istilah gagal cepat, gagal murah.
Hal utama adalah tidak melibatkan publisitas. Beritahu orang tersebut - jangan buang banyak waktu, mari buat prototipe dan lihat apakah solusinya layak atau tidak.
Prototipe akan memakan sedikit waktu. Jika mereka berhasil, keduanya akan mendapatkan apa yang mereka inginkan—keputusan normal dan poin politik.
Jika gagal, tidak ada yang akan terluka. Ya, orang akan memperlakukan programmer dengan lebih baik.
→
Pengganti
Bisnis tidak menyukai 1C dan produknya, pengembang web, QMS, akuntansi, ekonom, proyek pengembangan, Scrum, TOS, pengendalian, KPI dan sistem motivasi.
Bisnis menyukai peningkatan profitabilitas karena otomatisasi, peningkatan omset dari promosi online, peningkatan kualitas produk, gambaran bisnis yang sederhana dan mudah dipahami dalam jumlah, perkiraan kondisi perusahaan, peningkatan efisiensi yang nyata, penyelesaian proyek lebih cepat 2-4 kali lipat, peningkatan laba berlipat ganda dan penurunan persediaan, sistem manajemen yang akurat, sistem yang jelas dan dapat dipahami untuk menilai keadaan bisnis, sistem penilaian tenaga kerja yang memungkinkan Anda memecat setengah dari manajer.
Bisnis senang mencapai tujuan bisnis. Bisnis tidak menyukai pengganti.
Pengganti adalah ketika Anda meminta untuk mencapai tujuan bisnis, tetapi menerima proyek otomatisasi, situs web, setumpuk kertas, staf karyawan yang tidak dapat dipahami, atau laporan yang tidak dapat dibaca.
Pengganti adalah ketika tujuan di sepanjang jalan digantikan dengan sarana pencapaian. Dan mereka semua lupa akan tujuannya.
Produksi pengganti didasarkan pada tiga pilar: formalisme, bertahap dan tanggung jawab bersama.
Formalisme adalah pengalihan tujuan ke atas kertas dengan dekomposisi. Namun intinya - mengalihkan fokus perhatian dari tujuan besar ke detail kecil. Tidak ada lagi yang mengingat tujuannya - semua orang mendiskusikan detailnya.
Gradualisme adalah kecepatan transisi yang rendah dari tujuan ke sarana. Pada awalnya, tujuan tersebut terkadang masih dibicarakan. Namun lambat laun, selangkah demi selangkah, hal itu semakin jarang disebutkan. Sampai pelanggan sendiri melupakannya, tenggelam dalam detailnya.
Tanggung jawab bersama adalah bahwa semua kontraktor bertindak kurang lebih sama. Tidak ada satu pun alat otomatisasi yang benar-benar meningkatkan keuntungan. Oleh karena itu, pelanggan tidak punya pilihan.
Apa yang harus dilakukan?
Hindari pengganti dan langkah pertama menuju penciptaannya: formalisme. Setidaknya pada proyek internal. Tetapkan tujuan dan terus-menerus bicarakan dengan pemain tentang hal itu. Tentang skala, sumber daya, rencana, dll. - Sama. Namun yang utama adalah mengenai tujuan.
Jika tidak, fokus perhatian pasti akan teralihkan, dan Anda akan mendapatkan pengganti lain.
→
Jab Klitschko
Ada petinju seperti itu - Vladimir Klitschko. Dia memiliki kekhasan - penggunaan jab yang konstan. Ya, itu. lebih konsisten dibandingkan petinju lainnya.
Jab tersebut terus-menerus membuat lawan dalam ketegangan dan melelahkannya.
Fitur utama dari jab Klitschko: kemudahan eksekusi (relatif, tentu saja) dan konsistensi.
Banyak penulis mengatakan bahwa tindakan yang dilakukan terus-menerus, bermanfaat, namun sederhana dapat membawa banyak manfaat.
Saya memutuskan untuk mencobanya juga. Saya membuat sistem akuntansi sederhana - pukulan apa yang saya lakukan hari ini.
Itu terjadi di pabrik. Saya melakukan pukulan saat makan siang (saya tidak makan siang), mis. 1 jam sehari. Melakukan apa yang orang lain tidak lakukan (mereka bilang itu membawa kesuksesan).
Saya menyiapkan pengujian sistem belajar mandiri, menghasilkan ide untuk pengembangan, menerapkan ide pengembangan orang lain, menyiapkan tugas otomatis, memfaktorkan ulang, dan mengoptimalkan kode.
Setiap hari - tugas apa pun dari daftar ini. Menyelesaikan satu tugas - tampan. Beberapa kemungkinan bisa terjadi.
Observasi dilakukan selama 3 bulan. Selama waktu ini, saya melakukan 30 pemeriksaan, menghasilkan 200 ide, mengimplementasikan 80 ide orang lain, membangun proses otomatis untuk dua departemen, dan melakukan tiga optimasi keren.
Dingin. Ya, ini adalah "di antara". Saya merekomendasikan kepada semua orang.
→
Pengganti yang fleksibel
Kata “Scrum” mengacu pada setidaknya dua entitas: filosofi dan kerangka kerja.
Filosofi, atau pendekatan terhadap pekerjaan, dijelaskan dalam buku karya Jeff Sutherland.
Kerangka, mis. algoritma tindakan dijelaskan dalam dokumen yang disebut Panduan Scrum.
Filsafat menjadi suatu kerangka kerja karena para penulis filsafat ingin menghasilkan uang darinya (dengan kata-kata mereka sendiri).
Kerangka ini sangat disederhanakan dibandingkan dengan filosofinya. Yang utama adalah tujuannya disederhanakan, atau lebih tepatnya dibuang.
Tujuan filsafat: mempercepat pencapaian hasil. Apalagi kadang-kadang. Buku tersebut berisi contoh percepatan sebanyak 8 kali.
Tujuan dari kerangka ini: agar Anda memiliki Scrum. Ada tertulis di sana: jika Anda mengikuti instruksi, Anda memiliki Scrum; jika Anda melanggar instruksi, Anda tidak memiliki Scrum.
Kerangka kerja ini sama sekali tidak menyiratkan percepatan dalam mencapai hasil.
Orang yang mengajar atau mengimplementasikan Scrum bekerja dengan kerangka kerja tersebut. Mereka memberi tahu dan menerapkan algoritma yang tidak memberikan hasil apa pun selain “kami sekarang memiliki Scrum.”
Intinya jelas. Filsafat sangat sulit untuk dijual. Kerangka kerjanya lebih sederhana.
Kerangka kerja adalah sebuah produk. Dia, seperti yang diharapkan, melakukan “pengemasan”. Sederhana, jelas, ada dukungan dan banyak spesialis. Tidak mengingatkanmu pada apa pun?
Semuanya baik-baik saja, kecuali hasilnya - tidak ada.
Jika pelanggan belum familiar dengan filosofi Scrum, maka dia akan cukup senang dengan penerapan framework tersebut.
Jika pelanggan sudah familiar dengan filosofi Scrum, maka dia akan kecewa dengan penerapan framework tersebut - tidak akan ada percepatan dalam mencapai hasil.
Itu akan keren, modis, modern, tetapi tidak ada tujuan bisnis yang akan tercapai (kecuali menghabiskan anggaran untuk “sesuatu yang baru”).
Apa yang harus saya lakukan? Pelajari filosofi Scrum. Hal ini didasarkan pada filosofi manajemen mutu Jepang, yang intinya adalah: pengukuran dan peningkatan tanpa akhir.
Sayangnya, Anda harus banyak berpikir, bereksperimen, mengamati, dan sayangnya, bekerja. Jika ini tidak cocok untuk Anda, ambil kerangkanya.
→
Sumber: www.habr.com