Transparansi - The Butcherts 'Panacea

Saya sudah mencoba untuk mengobati scrum "mekanis" ( bagian 1 , bagian 2 , bagian 3 ), dan dalam artikel ini saya akan mencoba menulis obat universal untuk "membakar". Dengan sendirinya, "membakar", "mendidih", dll. - ini bagus, itu berarti Anda tidak peduli ( tetapi ketidakpedulian adalah langkah menuju keputusasaan, atau, seperti kebiasaan di TI, untuk kehabisan tenaga ). Banyak bahan telah ditulis dan ditembak dengan topik bahaya burnout, misalnya: di sini , di sini , di sini atau di sini .

Salah satu kebijaksanaan umum mengatakan: "Buttherts adalah mesin kemajuan." Tetapi sering terjadi seperti ini: itu terbakar => solusi dangkal cepat diadopsi, menutupi masalah => solusi menjadi hidup => terus terbakar. Dengan kata lain, alih-alih memilah dan membuat diagnosis, kami segera melanjutkan perawatan. Saya akan mencoba mengilustrasikan ini dengan contoh.


Pertama, mari kita mendefinisikan istilah "transparansi". Panduan Scrum mendefinisikannya seperti ini:

Aspek penting dari proses harus terlihat oleh mereka yang bertanggung jawab atas hasilnya. Transparansi mengharuskan aspek-aspek tersebut didefinisikan oleh standar umum sehingga pengamat berbagi pemahaman yang sama tentang apa yang dilihat.

Aspek penting dari proses harus terlihat oleh mereka yang bertanggung jawab atas hasilnya. Aspek-aspek ini harus didefinisikan oleh standar umum sehingga pengamat sama-sama memahami objek pengamatan.

Definisi-definisi ini hanya berlaku untuk proses, saya ingin mempertimbangkan konsep lebih luas. Saya tidak akan berusaha untuk memberikan definisi ilmiah yang tepat, tetapi saya akan mencoba menggambarkan "transparansi" melalui kondisi yang diperlukan untuk keberadaannya. Jadi, untuk transparansi, Anda perlu:

• Objek yang dibutuhkan seseorang ;
• Tujuan bersama untuk semua pemangku kepentingan terkait dengan fasilitas;
• Keinginan semua pemangku kepentingan untuk mencapai tujuan;
• Kemampuan semua orang untuk berkomunikasi dalam satu bahasa, yaitu kemampuan untuk mengembangkan kerangka kerja konseptual seperti itu yang akan berarti bagi semua pihak yang berkepentingan ( misalnya, istilah seperti ROI dan Redux , tampaknya mereka terletak di bidang yang berbeda dan jauh, meskipun sangat luas di lingkungan informasi tertentu ).

Jika kondisi yang diperlukan ini terpenuhi, maka Anda dapat memulai proses membangun transparansi: mendefinisikan tugas, menentukan kriteria keberhasilan dalam menyelesaikan masalah, mengembangkan metode untuk mengevaluasi kriteria. Bagaimana bisa:

Pertama-tama, kami menjawab pertanyaan utama:

• Untuk apa anda pergi
• Apa tujuannya?

Urutan tindakan berikut dimungkinkan:

• Kami mendefinisikan terminologi ( misalnya, semua orang memahami tugas yang telah diselesaikan dengan cara yang sama, dan tidak untuk pengembangannya adalah ketika kode ditulis, dan untuk bisnis adalah ketika klien mulai menggunakan hasil );
• Kami menyetujui aspek-aspek utama dan bagaimana kami akan mengukur kondisi mereka, bagaimana kami akan memahami hasilnya ( misalnya, kami berkumpul sekali sehari, melihat rencana, menentukan kondisi kami mengenai rencana ini );
• Kami mewujudkan rencana kami.

Secara terpisah, saya ingin menekankan bahwa koherensi dan penerimaan umum atas perjanjian itu penting, yang tanpanya sulit untuk mencapai keterlibatan. Memang, dalam sistem pengambilan keputusan ( misalnya, dalam ketentaraan ) dasar konseptualnya seragam, tindakan dan kriteria evaluasi jelas, tetapi berapa banyak yang diterima ( apakah ada empati ) oleh peserta adalah pertanyaan besar.

Saya harap saya berhasil mengungkap ide transparansi saya, maka saya akan mencoba memberikan beberapa contoh situasi yang dapat ditingkatkan jika transparansi ditambahkan.

Apakah saya makhluk yang gemetar atau saya punya hak?

Baru-baru ini, bagi saya tampaknya masalah kelelahan profesional di lingkungan TI sudah sangat akut ( Seluruh mitaps tematik diadakan pada topik ini, misalnya, PiterJS , di mana ada laporan oleh rekan saya Zhenya Kot bunopus ).


Pekerjaan kami adalah intelektual, pola pikir analitis, well, Anda sendiri yang tahu. Tampak bagi saya bahwa ada kecenderungan untuk menciptakan kesulitan di mana mereka tidak ada. Kadang-kadang ini datang justru dari kurangnya transparansi ( berikut adalah beberapa hasil penelitian: satu dan dua ), dan bukan karena jumlah pekerjaan yang besar: tidak ada informasi yang diperlukan - saya sendiri yang akan membuatnya ( ingat pola pikir analitis ), saya akan menarik kesimpulan dari asumsi - saya akan menyusun rencana dan pergi berperang dengan istana di udara. Berikut adalah pertanyaan yang mungkin menjadi perhatian kami ( spesialis TI ):

• Tetapi apakah saya melakukan omong kosong? Bagaimana pekerjaan saya meningkatkan dunia?
• Seberapa baik saya dalam bisnis saya?
• Ya mereka tahu siapa saya? Siapa mereka? Apa yang mereka izinkan sendiri?
• Apa selanjutnya Kemana saya akan pergi? Apakah saya pergi dengan itu?

Pertanyaannya benar, penting bagi seseorang untuk merenungkan masa lalu, memikirkan masa kini dan merencanakan masa depan. Penting untuk memikirkan orang-orang yang ada di sekitar. Dan mentransfernya untuk bekerja, tentu saja, kita dapat berharap bahwa para pekerja sendiri akan mencari jawaban atas pertanyaan-pertanyaan ini, akan menjelaskan apa yang menjadi perhatian mereka. Tetapi Anda bisa membuat semua ini transparan, dan kemudian orang akan fokus pada hal-hal yang lebih tinggi dan menyelesaikan masalah di tingkat berikutnya, yang ditujukan untuk optimasi, inovasi, dll. Ada banyak alat untuk menyediakan transparansi semacam ini, berikut adalah beberapa contoh:

• Tujuan, misi dan strategi perusahaan terbuka dan dapat dipahami oleh karyawan, dan mereka terkenal. Semua tugas taktis diajarkan melalui komunikasi dengan strategi, selalu jelas untuk apa tujuan saat ini atau pekerjaan itu diperlukan. Jelas tidak hanya apa yang perlu dilakukan, tetapi juga mengapa itu perlu dilakukan.
• Karyawan secara teratur menerima umpan balik tentang hasil pekerjaan mereka: prestasi, poin pertumbuhan ( misalnya, jajak pendapat 360 atau 1 banding 1 ). Perencanaan pengembangan bersama dan inspeksi dinamika pencapaian rencana ini.
• Struktur organisasi yang dijelaskan dan komunikasi di dalamnya: apa dan dengan siapa Anda dapat berbicara. Kontrak sosial, kartu bisnis tim, dll.
• Sistem motivasi yang transparan, pohon karier dan, mungkin, gamifikasi proses ini. Anda dapat terinspirasi oleh contoh liter atau 2GIS , dan membangun budaya Anda sendiri di mana karyawan memahami cara menentukan dan memengaruhi tingkat motivasi materi mereka.

Namun, sekarang, seperti biasa, semua orang sibuk mencari "tempat seseorang di dunia ini," dan jika alat diberikan untuk mendefinisikan diri mereka sendiri setidaknya di tempat kerja, karyawan seperti itu akan sedikit lebih harmonis dan lebih bahagia, dan mungkin ada lebih sedikit kasus kelelahan profesional.

Perang Salib

Kami orang kulit putih suka merusak tombak dalam perang suci: Bereaksi vs Angular , iOS vs Android, OOP vs fungsionalitas, dll. Namun sayangnya atau untungnya, tidak ada "peluru perak". Ada tugas dan solusi khusus. Ketika kita dihadapkan dengan pilihan teknologi, kerangka kerja, arsitektur, dll., Dengan tingkat probabilitas tinggi kita berada dalam domain "bingung", menurut model Kenevin , dan, sebagai hasilnya, tidak ada jawaban yang tepat. Dalam situasi ini, diinginkan untuk menyadari dan memperbaiki masalah yang sedang dipecahkan, untuk memahami alternatif apa yang sedang kita pertimbangkan, kriteria apa yang kita miliki untuk membuat keputusan. Penting untuk mengumpulkan data ini bersama-sama, membuat pilihan dan juga mendokumentasikannya. Seiring waktu, ada baiknya kembali ke artefak ini dan berdamai dengan di mana kita akan pindah. Semuanya dapat berubah: dunia, perusahaan, tim, orang-orang tertentu, kondisi, dll., Oleh karena itu, ketika kita memiliki informasi tentang bidang mana dan mengapa kita memilih, lebih mudah untuk menyesuaikan jalur berdasarkan pengetahuan ini. Dan tidak jatuh ke dalam situasi klasik merobek rompi di dadanya : "Tapi siapa yang pernah menemukan semua ini ?! Tampaknya orang-orang tidak cocok, setelah ini menumpuk. Inilah jawaban yang benar, sudah jelas. Saya akan menyelamatkan semua orang dan mengulang semuanya. "

Saya pikir banyak orang yang akrab dengan situasi ketika, dalam upaya untuk membangun "dunia baru yang indah," mereka mengubah pemimpin mereka, tim, menjadi mereka yang siap untuk membakar Babel, tetapi hasilnya bukan phoenix, tetapi goblin.

Anda dapat mencoba untuk tidak memotongnya dari bahu Anda, tetapi secara retrospektif menganalisis semua kesalahan dan ketidakakuratan, melacak logika keputusan teknis, mempertimbangkan risiko dan mengajukan hipotesis baru. Dan dasar pengambilan keputusan bukanlah "mereka semua bodoh ...", tetapi "kondisinya telah berubah dan kita sudah menyelesaikan masalah baru."

Menurut saya sulit untuk membuat keputusan teknis yang tepat setiap saat. Anda dapat belajar mengatur eksperimen, mengevaluasi hasil yang diperoleh, dan merencanakan langkah selanjutnya, dengan mempertimbangkan informasi baru yang diterima. Dan bisa lebih mudah jika Anda memiliki artefak yang tersedia untuk semua pihak yang berkepentingan yang menggambarkan logika keputusan teknis.

Terapkan agile / scrum / kanban / lean dalam cp * ki terkompresi

Ada perdebatan abadi di lingkungan Agile: "Di mana untuk memulai transformasi: dari budaya / nilai / pola pikir atau mekanik / ritual / artefak?". Seperti dilema ayam dan telur klasik. Posisi saya adalah bahwa untuk pelatih lincah "kuat dan mandiri" itu mungkin terjadi bahwa tim melalui mekanik secara bertahap menjadi perhatian. Tetapi lebih sering, jika Anda mulai dengan mekanik dan memperkenalkan semacam pendekatan sebagai pemujaan kargo, maka kemungkinan besar kita akan mendapatkan skeptisisme dan kekecewaan dalam metodologi, dan dalam kasus terburuk, kita juga akan mendapatkan pembenci. Bagaimana ini bisa terjadi dijelaskan dengan baik di Panduan Berteriak (di sini terjemahan berapi-api ).

Oleh karena itu, saya mendukung untuk menganalisis berapa banyak nilai Agile masuk ke kasus Anda, dan baru kemudian melanjutkan dengan penerapan kerangka kerja atau teknik. Tidak ada tes universal, tetapi ada kertas lakmus ( misalnya: tes lincah dan panduan lincah ): pertama pikirkan tentang apakah scrum bersyarat akan membantu Anda dalam kasus Anda atau tidak ( contoh lain dari tabel tes ).



Mari kita lihat sebuah contoh: sebuah bisnis terbakar karena perkembangannya lambat, keputusan dibuat - mari kita terapkan scrum / kanban / lean, karena itu mempercepat pembangunan ( jadi itu tidak berarti ). Dan seiring waktu, kami menyimpulkan: "ini tipuan dan trik pemasaran, itu tidak berhasil." Kisah yang akrab? Pendapat saya adalah memulai dengan transparansi. Mari kita mengerti apa yang sebenarnya mengganggu. Mari kita mulai berbicara dengan istilah yang sama dan memahami istilah dengan cara yang sama. Mari kita rumuskan pertanyaan: "Apa masalahnya?", "Bagaimana kita memahami bahwa itu buruk?", "Bagaimana memahami apa yang lebih baik?", "Bagaimana kita menentukan apa yang baik?", "Apakah semua orang menyadari masalah dan mempersepsikannya?" dia sebagai masalah ( misalnya, bukan keinginan manajer bodoh )? " Dan ketika semuanya menjadi transparan, maka pada saat ini Anda dapat mencari solusi. Memang, "perkembangan lambat" dapat berarti:

• Tidak ada proses penyebaran yang normal, menyebarkan perubahan pada produk adalah hal yang merepotkan. Opsi solusi - mengimplementasikan budaya DevOps , jalankan CI / CD ;
• Bisnis dan pengembangan belum belajar bicara. Tampaknya bagi bisnis, pengembangan tidak memahami apa pun, dan sebaliknya, pengembangan percaya bahwa bisnis itu tidak tahu apa yang diinginkannya. Solusi yang memungkinkan - cobalah membangun penetapan tujuan, membuat Pemetaan Dampak atau menggunakan OKR ;
• Struktur hierarkis dipenuhi dengan manajemen mikro, di mana ada adopsi lambat dari keputusan taktis karena kebutuhan untuk koordinasi dengan yang lebih tinggi. Pilihan solusi - latih orang dalam fasilitasi, lakukan eksperimen dengan percaya diri ( tonton video motivasi dengan TED );
• Daftarnya berlanjut.

Mungkin ada banyak situasi, karena masing-masing dari mereka, ada alat perbaikan sendiri. Dan seringkali implementasi agile / scrum / kanban / lean / dll. kelihatannya seperti memalu kuku dengan mikroskop dan, pada kenyataannya, menciptakan penampilan aktivitas yang keras, tetapi tidak mencari solusi untuk masalah tersebut. Oleh karena itu, aturan "jangan menjadikan dirimu idola" berfungsi di sini: Anda tidak harus mencari peluru perak dalam pendekatan / metodologi / kerangka kerja yang hype, pertama-tama sadarilah masalah apa yang Anda selesaikan, dan pilih alat solusi setelah itu. Dan ternyata, setelah memulai jalur peningkatan berkelanjutan ( kesadaran akan masalah, memformalkan pekerjaan dengannya, transparansi, menemukan solusi melalui eksperimen ), Anda akan membangun proses Anda tidak seperti yang lain, tetapi bekerja dengan baik untuk Anda.

Kenapa saya semua ini

Menurut model Kenevin, hampir semua pekerjaan IT kami berada dalam domain yang membingungkan, yang berarti pendapat ahli tidak berfungsi di sini dan tidak ada jawaban yang benar. Dan salah satu opsi yang memungkinkan untuk keberadaan yang nyaman di dalamnya adalah proses empiris yang dimulai dengan transparansi. Tampaknya ini adalah kebenaran umum, tetapi tampaknya tidak selalu diingat.

Jika Anda membaca di tempat ini dan dibombardir oleh artikel kapten populis lain, maka Anda dapat mencoba bertanya pada diri sendiri:

• Mengapa dibakar?
• Mengapa itu membuat saya marah?
• Apa yang bisa berbeda, agar tidak membuat saya emosi seperti itu?

Tuliskan semua ini di komentar: letakkan semua titik di atas saya dan buat pertanyaan ini transparan.
Meringkas: opacity dapat menyebabkan disintegrasi masyarakat menjadi kelompok-kelompok, perang suci, manifesto , dll. Tetapi Anda bisa duduk dan mencoba berbicara dalam bahasa yang sama dan saling mendengarkan. Semua transparansi!

Terima kasih untuk ilustrasinya, Sai Kin !