Suatu kali saya mengubah pekerjaan dan beralih dari organisasi besar yang terstruktur dengan baik ke startup yang sedang berkembang pesat. Saya benar-benar menyukai semuanya sekaligus: energi yang digunakan orang untuk bekerja, profesionalisme, dan jiwa komunikasi internal. Tetapi pada saat mereka mulai menyampaikan kepada saya PM-urusan, kejutan menunggu saya:
- Dalam arti tidak ada deskripsi? Artinya, Anda belum menulis di mana pun, dengan aturan apa tim Anda bekerja? Benar-benar ?! Bahkan SLA? Dan bagaimana Anda akan memberi saya? Dalam hal memori, bagaimana jika semacam pengaturan dilupakan dan tidak ditransmisikan? Bagaimana saya memahami hal ini sepanjang jalan? Oh ibu ...
Pernahkah Anda memiliki perasaan bahwa kepala Anda bulat, dan pikiran yang Anda coba pikirkan adalah persegi? Itulah yang saya rasakan tentang diri saya, mencoba memahami bagaimana saya akan bekerja. Startup itu tidak lagi kecil - lebih dari 200 orang, kantor di beberapa negara, klien di seluruh dunia. Dan, sejauh yang saya mengerti, perjanjian tentang bagaimana tim pengembangan bekerja, seberapa sering mereka merilis rilis, sesuai dengan aturan apa yang mereka perbaiki tiket, bagaimana mereka melaporkan, di mana dokumen itu dan bagaimana mereka diperbarui - semuanya entah bagaimana diputuskan berdasarkan firasat. Dan ini luar biasa - ketika Anda sedikit dan Anda semua berada di satu tempat. Tetapi ketika tim baru Anda duduk di lokasi baru, semua orang di kota lain dan bahkan negara, dan orang-orang baru setiap hari semakin banyak ... Saya merasa tidak nyaman.
Akibatnya, saya ingat satu pemikiran sederhana, karena saya memiliki pendidikan teknis:
Sistem berubah dari mana saja dalam sistem
Dan dia memutuskan bahwa saya mungkin akan menjadi titik yang akan membawa sistem dari keadaan kacau ke keadaan struktur yang jelas.
Untuk programmer dan tidak hanya mereka yang percaya bahwa menggambarkan proses manajemen adalah buang-buang waktu: sama seperti kode harus ditutup dengan dokumentasi teknis dan pengguna, pekerjaan perusahaan harus dijelaskan dengan instruksi dan proses. Untuk alasan yang sama: semakin banyak aturan dan semakin membingungkan, semakin sulit untuk disebutkan.
Terutama mereka perlu dijelaskan jika jumlah pendatang baru terus tumbuh dan proses cenderung terus berubah. Apa manfaatnya untuk nanti:
- Ingatkan orang tentang bagaimana proses itu bekerja (misalnya, ketika tidak dijalankan)
- Masukkan yang baru dalam proses
- Buat perubahan pada proses tanpa melewatkan apa pun
- Pikirkan apa yang kami lakukan salah dan optimalkan prosesnya.
Saya tidak pernah berpikir bahwa saya akan menulisnya, sepertinya jelas dan benar. Tapi tidak, ternyata startup teknis biasanya kehilangan kompleksitas proses manajerial dan lebih suka berpikir bahwa semuanya harus berjalan sendiri.
Apa yang harus ditulis
Singkatnya dan lebih sederhana, maka instruksi dan perjanjian dengan semua pihak tentang bagaimana pekerjaan diatur dengan insiden, masalah, rilis, pengetahuan, kemampuan, keamanan, dll di organisasi kami.
Jika lebih, buka Talmud ITSM dan baca :)
Artikel ini tidak sepenuhnya tentang apa yang harus dideskripsikan, melainkan bagaimana menjelaskan dan mengimplementasikan sehingga proses hidup.
Bagaimana cara menulis
Tugas mendeskripsikan sehingga orang menggunakannya tidak terlalu sepele, terutama dalam kondisi ketika perubahan tidak datang dari atas, dari kepemimpinan. Itu menjadi lebih kompleks dengan perlawanan belaka.
Saya menemukan sumber perlawanan, instruksi panjang sekitar 10-30 halaman, ditulis sekitar 5 tahun yang lalu, yang semua orang lupa setahun kemudian. Artinya, upaya penataan itu, tidak berhasil, dan ada keyakinan bahwa itu tidak akan berhasil.
Dengan membaca dokumen-dokumen ini (cukup, omong-omong, masuk akal, tapi panjang, terlalu canggih), saya membuat diri saya tegang
Pelajaran 1: Jelaskan pengaturan singkat dan hidup.Apa yang tidak bisa Anda jelaskan dengan istilah sederhana adalah proses yang rumit adalah masalah Anda, bukan yang membacanya. Mungkin Anda mencoba memasukkan beberapa proses menjadi satu.
Pelajaran 2 Jika Anda tidak dapat menggunakan grafik - jangan gunakan. Jangan pernah menggunakan diagram yang kompleks.Dari luar tampaknya kebalikannya adalah bahwa membaca dermaga lebih sulit daripada melihat grafik. Saya juga berpikir begitu. Namun, saya sekarang memegang dua dokumen yang menjelaskan bagaimana kami akan merilis fitur, teks dan diagram. Grafik tidak diperbarui (sulit atau sekali), teksnya terus-menerus (bukan hanya saya yang telah melakukan ini sejak lama).
Pelajaran 3: Dua dokumen pendek lebih baik dari satu.Tidak ada yang membaca teks panjang lagi, Anda hanya harus tahan dengan ini.
Pelajaran 4: Jika Anda sendiri tidak bisa menulis, jangan menulis.
Lebih mudah bagi orang untuk menggunakan apa yang mereka hasilkan dan susun sendiri. Untuk meyakinkan seseorang tentang pentingnya membuat perjanjian lebih tepat daripada menulis sendiri. Meski tentu saja tidak mudah.
Pelajaran 5: Jika Anda masih menulis sendiri, maka mintalah untuk memeriksaSangat sering, sebuah dokumen muncul setelah pertanyaan "Bagaimana ini dilakukan dengan kita?" Nah, jika Anda mengirim dokumen untuk verifikasi kepada seseorang yang menerima informasi, dengan kata-kata "silakan periksa, apakah itu benar?"
Pelajaran 6: Selain pintu masuk, pintu keluar dan pemain serta mereka yang bertanggung jawab, setiap dokumen harus memiliki target audiensSeperti dalam pemasaran: untuk membaca artikel, artikel itu harus menarik bagi Anda secara pribadi. Jika Anda memasukkan informasi untuk semua orang ke dalam satu dokumen, itu akan lama, dan kami ingat bahwa teks yang panjang membuat orang takut. Sebagai contoh, ada aturan umum untuk semua orang bagaimana kita bekerja sesuai dengan GDPR. Dalam praktiknya, ini adalah tiga dokumen:
- untuk semua karyawan - deskripsi peraturan itu sendiri, apa yang dapat dilakukan dan apa yang tidak dapat dilakukan dengan informasi.
- Di mana dan bagaimana menghubungi dalam situasi luar biasa - untuk pengembang dan layanan dukungan
- Bagaimana dan di mana teknis yang dijelaskan dijalankan - untuk pengembang
Apa yang harus dilakukan sehingga tidak hanya dijelaskan, tetapi juga berfungsi?
Nyatakan bahwa Anda dan tim Anda dikelola sebagaimana tertulis.
Jika ada yang tidak beres, saya membuka dokumen, menyentuhnya dan berkata, kami setuju untuk melakukannya. Apa yang perlu diperbaiki? Jika seseorang dari manual, katakanlah, tidak puas dengan tenggat waktu untuk mengerjakan tiket, saya membuka proses di mana tertulis
- bagaimana kita mengambil tiket untuk bekerja,
- tahap apa yang bisa mereka lalui
- apa alasan untuk berhenti bekerja pada tiket dan
- berapa waktu rata-rata di setiap tahap.
dan ajukan pertanyaan, apakah kita akan mengubah proses, prioritas tiket, atau hal lain?
Ini cukup banyak mengurangi ketidakpuasan, memfasilitasi komunikasi dan, yang paling penting, meningkatkan prediksi dan transparansi pekerjaan Anda. Dan di mana ada transparansi, ada kepercayaan. Dan dengan kepercayaan, Anda bisa membangun lebih banyak.
Plus, itu memberi Anda kemampuan untuk membela tim Anda jika kesalahannya tidak di depan umum tetapi dalam kebingungan dalam manajemen (80% kasus sebenarnya).
Tunjukkan pada orang-orang cara kerjanya
Bagian dari proses manajemen rilis lahir dari tiga percakapan dengan manajer rilis ... Berdasarkan hal itu, saya menjelaskan kepada manajemen mengapa rilis itu memakan waktu begitu lama, dan manajer rilis meminta diskusi ini. Sekarang di tempat ini ada beberapa dokumen tentang bagaimana, mengapa dan apa yang harus dirilis di sini. Ditulis, tentu saja, bukan oleh saya, tetapi oleh manajer rilis. Membiasakan orang dengan fakta bahwa itu nyaman, yang membebaskan Anda dari penjelasan yang tidak perlu dan memungkinkan untuk transparan sekaligus dan untuk semua orang. Dengan contoh
Menjadi sumber pengetahuan
Saya tidak lupa dari waktu ke waktu untuk memberikan kuliah kecil bahwa perjanjian tertulis tentang format pekerjaan jauh lebih baik daripada yang tidak tertulis. Saya tertarik membicarakan hal ini, jadi setiap orang harus mendengarkan berkali-kali. Bukan pertama kalinya, secara bertahap, sebagian besar perjanjian yang kami jelajahi bersatu. Air menajamkan batu.
Mengapa kamu membutuhkannya?
Paling tidak, kekacauan di kepala dan di tempat kerja akan berkurang.
Maksimal, Anda beruntung dan Anda akan diperhatikan dalam organisasi ini sebagai manajer cerdas yang tahu cara bekerja dengan proses. :)
Pikiran tentang, cukup kontroversial, hanya berspekulasi.
Saya memiliki keyakinan yang cukup serius bahwa seseorang tidak dapat menulis dan mengimplementasikan proses dari luar. Dia dapat menggambarkan keadaan saat ini, tetapi tidak ada yang akan mendukung proses. Dan jika Anda membutuhkan perubahan cepat, itu akan terjadi, dan prosesnya akan menunggu sampai pembuatnya melakukan perubahan.
Proses manajemen adalah urusan orang-orang yang menggunakannya.
Namun, harus terjadi bahwa pendekatan proses bukanlah aturan yang dipaksakan dari luar, tetapi persetujuan saya dengan dunia luar tentang aturan untuk bekerja dengan saya. Maka pendekatan proses tidak akan menjadi rem pada pengembangan organisasi (saya pernah melihat ini sebelumnya), tetapi merupakan katalis pertumbuhan.