Mari kita bicara tentang aplikasi praktis dari satu topik yang sangat menarik - pemikiran sistemik.
Ada banyak prinsip dan metode dalam pemikiran sistemik, saya sangat merekomendasikan membaca literatur yang relevan. Misalnya, buku yang sederhana dan menarik. Hari ini kita akan menyentuh hanya satu prinsip - sifat sistem yang muncul atau muncul.
Saya akan memberi tahu Anda tentang teorinya, dan, yang paling penting - tentang aspek praktis aplikasi. Dalam hidup kita - programmer, pelaksana, arsitek, analis dan manajer proyek.
Namun pada awalnya, sedikit teori.
Sistem dan properti
Di tempat kerja, kita hampir selalu berurusan dengan sistem - kumpulan orang yang kompleks, proses, hubungan (formal dan informal), pemimpin yang eksplisit dan tersembunyi, objek material, sistem informasi, pelanggan, pemasok, peralatan, dll., Hingga tak terbatas.
Jika Anda memiliki semua elemen di depan Anda, Anda tahu mereka, atau bahkan melihatnya - misalnya, letakkan semuanya di satu tempat - maka ini bukan sistem, tetapi serangkaian elemen. Hanya banyak detail.
Bagaimana cara membuat sistem dari tumpukan ini? Anda harus meletakkan elemen di tempatnya dan menyalakannya - mulai sistem bekerja.
Ini dipahami dengan baik oleh programmer, atau insinyur biasa. Berikut adalah kode program, ini adalah komputer atau server, berikut adalah data input untuk diproses. Tekan HIDUP - sistem berfungsi. Ya, atau tidak berfungsi jika ada kesalahan di dalamnya.
Dalam sistem yang terdiri dari orang, biasanya yang sebaliknya adalah benar, dan perbedaan ini adalah kuncinya. Sistem orang bekerja sebelum Anda, dan akan bekerja setelah Anda. Tetapi mereka tidak akan bekerja
dengan Anda , di hadapan Anda. Sebenarnya, di hadapan Anda mereka tidak lagi menjadi sistem, dan sekali lagi berubah menjadi serangkaian elemen.
Kembali ke contoh di atas, ketika Anda mengumpulkan segala sesuatu dan semua elemen sistem di satu tempat. Apa yang telah kamu lakukan Anda telah
mematikan sistem.
Apa perbedaan antara sistem hidup dan mati? Orang-orang menyukai posisi yang sama, posisi yang sama, proses yang sama, pemimpin yang sama - semuanya ada di tempatnya.
Perbedaan dalam sifat-sifat sistem, yang memanifestasikan diri hanya ketika "dihidupkan", yaitu ketika sistem sedang berjalan.
Contoh properti sistem seperti itu ada di mana-mana, Anda dapat menemukannya tanpa kesulitan.
TV tanpa listrik adalah sistem yang dimatikan yang tidak menunjukkan kepada kita fungsi utamanya - untuk menampilkan gambar. Nyalakan TV - Anda akan melihat gambar, fungsi akan muncul. Jika Anda memercikkan air ke TV yang berfungsi, Anda akan melihat properti baru dari sistem yang mungkin tidak Anda sadari.
Sifat-sifat sistem tersebut disebut
emergent , atau
timbul .
Mereka muncul ketika suatu sistem dirakit dan dihidupkan dari serangkaian elemen. Kedua kondisi itu penting - keduanya dirakit dan dihidupkan. Dalam kasus kami, ketika itu tidak mematikan.
Jadi, tugas kita adalah memahami sistem untuk kemudian mengubahnya. Bagaimana cara memahami sistem?
Jangan dimatikan
Sangat mudah untuk mengawasinya tanpa mematikan.
Sama seperti kita men-debug kode - nyalakan dan lihat apa yang terjadi. Pada prinsipnya, Anda dapat men-debug kode dengan mata Anda, tetapi dengan cetakan - ingat, di institut, “daftar program”? Tapi sepertinya, sedikit orang yang melakukannya. Sistem yang kami buat terlalu rumit. Banyak dependensi, yang bukan berarti kita tidak tunduk pada, tetapi bermain-main dengan mereka selama debugging adalah tugas tanpa pamrih.
Dengan konvensional, sistem non-komputer, masih lebih rumit. Tidak ada "daftar." Bayangkan seberapa tinggi untuk bekerja dengan sistem "manusia", jika kotak centang "Jeda tentang pengecualian" ada di sana?
Bagaimana biasanya kita mematikan sistem:
- Kami berbicara dengan karyawan secara individual
- Kami berbicara dengan semua karyawan sekaligus
- Kami membawa semua orang ke acara informal
- Kami membuat permintaan kepada karyawan, mengatur tugas, meminta laporan
- Tolong jelaskan kegiatan mereka, atau tulis proses bisnis
- Mengumpulkan Pemimpin di Rapat
- Kami bertanya kepada mantan karyawan bagaimana sistem bekerja
- Dll
Ternyata semua tindakan kita yang biasa mengarah pada penutupan sistem dan upaya untuk memahami sifat-sifat yang muncul dari serangkaian elemen.
Sherlock Holmes melakukan pekerjaan yang sangat baik dengan pekerjaan ini, ia menyebutnya deduksi - untuk memahami gambar secara detail. Benar, dia tidak punya pilihan lain - Anda tidak akan meminta penjahat untuk melakukan kembali kejahatan di hadapan kejeniusan pencarian.
Situasi kami lebih sederhana, dan ada peluang untuk mengamati sistem yang berfungsi dan tidak berubah.
Metode terbaik, tentu saja, adalah selalu hadir dalam sistem, menjadi bagian darinya, dan pada saat yang sama mengamatinya dari kejauhan. Ini, misalnya, adalah jalur master scrum. Dan, menurut definisi, peran atasan langsung. Kecuali, tentu saja, ia tidak menjalankan rapat alih-alih bekerja.
Contoh serupa adalah seorang pelatih, misalnya, dalam tim sepak bola. Di sana, pemantauan sistem dalam tindakan, dengan segenap kekuatannya, adalah bagian dari pekerjaan.
Apa yang kita, pekerja kantor, dibagi dengan partisi, lemari, kadang-kadang benua?
Melakukan pengawasan rahasia, secara langsung atau menggunakan cara teknis.
Pengamatan
Pengamatan pribadi tidak selalu memungkinkan, itu semua tergantung pada posisi Anda mengenai sistem yang diamati.
Jika Anda bekerja dalam suatu organisasi, Anda dapat dengan mudah menempatkan tempat kerja Anda di mana sistem berada - orang yang interaksinya ingin Anda pahami.
Pada awalnya Anda akan menjadi elemen asing yang mematikan sistem. Namun lambat laun mereka akan terbiasa dengan Anda dan berhenti memperhatikan Anda.
Agar terbiasa dengan Anda lebih cepat, berpura-puralah bahwa Anda tidak terlalu tertarik dengan apa yang terjadi di sekitar. Anda dapat berpura-pura bahwa Anda bekerja dengan antusias di depan komputer, mengenakan headphone dan menyalakan musik - tetapi dengan tenang untuk mendengar apa yang terjadi di sekitar. Jangan pura-pura mendengarkan percakapan. Lebih tepatnya, berpura-pura tidak mendengarkan percakapan. Saya pikir, lebih jauh Anda sendiri akan mencari cara untuk bergabung.
Jika ada orang di tim Anda yang akan merasa lebih mudah untuk bergabung dengan sistem, Anda dapat mengirim mereka dengan instalasi yang jelas.
Anda dapat menggunakan berbagai
alat untuk melacak tindakan orang dalam sistem . Anda tidak akan melihat keseluruhan sistem dengan cara ini, tetapi setidaknya Anda akan mengetahui apakah orang menggunakan alat Anda atau tidak. Dengan kata-kata mereka mengatakan satu hal, tetapi dalam kenyataannya - hal lain.
Praktek menunjukkan bahwa biasanya 2-5 hari sudah cukup untuk mendapatkan gambaran tentang sistem. Ini tidak akan menjadi gambaran yang sangat akurat, tetapi sebuah sketsa yang memberikan visi umum dan integral dari sistem.
Sketsa selanjutnya dapat dilengkapi dengan detail, sudah tanpa menggunakan pengamatan. Misalnya, melengkapi dengan data pengujian hipotesis, data dari sistem kontrol, dll.
Menariknya, observasi membantu mengembangkan kemampuan prediksi. Peramalan membantu memahami dengan cepat, berdasarkan pengalaman dan pengetahuan tentang perilaku sistem, metode dan perubahan mana yang akan bekerja dan memberikan hasil, dan mana yang tidak. Ini adalah aplikasi lain dari pemikiran sistemik dan sifat-sifat sistem yang muncul, kita akan membicarakan ini di bawah.
Akibatnya, pemantauan sistem kerja yang tidak dimatikan adalah metode yang sangat baik yang sulit untuk diganti dengan sesuatu. Pengamatan membantu untuk melihat sistem seakurat mungkin, tidak memihak dan seobyektif mungkin, tanpa interpretasi.
Opsi lain adalah
interpretasi , atau proyeksi dalam sistem koordinat tertentu. Terutama jika Anda bertanya tentang sistem dari pemimpinnya (seperti yang sering terjadi). Ini tidak hanya berlaku untuk pekerjaan programmer, tetapi juga untuk rutinitas manajemen harian.
Sebenarnya, tidak ada yang baru dalam pendekatan ini, sering digunakan di daerah-daerah tertentu.
Misalnya, di sektor ritel dan layanan, pembeli misteri digunakan - orang yang sengaja dikirim ke toko, hotel, dll., Sehingga mereka dapat melihat sistem beraksi seperti apa adanya.
Baru dalam pendekatan ini adalah penggunaannya dalam pekerjaan perusahaan biasa, sebagai aturan yang tidak terkait dengan produksi ritel, misalnya. Kami mengambil metode lama yang diketahui, menemukan aplikasi baru.
Peramalan
Sekarang tentang perkiraan. Dalam pekerjaan seorang programmer, suatu situasi sering ditemui ketika Anda perlu memberikan perkiraan keberhasilan suatu proyek. Biasanya kita berbicara tentang proyek pengembangan organisasi internal perusahaan. Sederhananya, tentang perubahan konsep.
Mereka biasanya bertanya tentang proyek orang lain - proyek yang tidak melibatkan programmer bisnis. Yaitu tentang proyek yang dilakukan tidak sesuai dengan aturan pemrograman bisnis, tetapi menurut aturan "yang saya bisa."
Seorang programmer bisnis, setelah studi singkat tentang informasi tentang proyek yang direncanakan, biasanya mengatakan bahwa tidak ada yang berguna akan datang darinya. Atau - tidak ada yang berhasil sama sekali. Perbedaannya jelas - proyek dapat diselesaikan dengan sukses, tepat waktu dan anggaran, tetapi tidak akan membawa manfaat bagi perusahaan.
Opini diungkapkan, mis. perkiraan programmer bisnis biasanya menyebabkan reaksi negatif - depresi, kemarahan, penolakan, "siapa kamu?", "akting Dewa di Bumi, atau apa? " dll.
Reaksi negatif meningkat ketika ramalan menjadi kenyataan, dan itu menjadi sangat sering terjadi.
Namun, tidak semuanya begitu sedih, dan lambat laun orang mulai terbiasa dengan "kekuatan super" programmer bisnis, dan bahkan menggunakannya secara memadai untuk kepentingan perusahaan, atau pribadi mereka. Beberapa bahkan menyimpan catatan perkiraan - buku catatan di mana mereka mencentang "dia benar." Sebagai contoh, dua rekan manajer saya memiliki buku catatan seperti itu. Saya tidak tahu, sungguh, virtual atau nyata.
Sekarang mari kita lihat bagaimana seorang programmer bisnis membuat perkiraan seperti itu.
Dari mana ramalan itu berasal?
Ini semua tentang menggunakan pengetahuan tentang perilaku sistem.
Proyek perubahan selalu mengandung setidaknya dua sistem: variabel dan perubahan.
Variabel -
apa yang akan kita tingkatkan . Proses bisnis, kerja unit, interaksi fungsi, dll. Kami akan menyebutnya
objek perubahan .
Ubah - orang
yang menemukan, mengimplementasikan dan mengimplementasikan perubahan . Sederhananya, tim implementasi perubahan. Kami akan memanggilnya
subjek perubahan .
Kedua sistem terdiri dari serangkaian elemen dan hubungan di antara mereka. Ini adalah orang-orang, sistem informasi, tujuan, hubungan formal dan informal, model manajemen, pendekatan kepemimpinan, kekuatan berpengaruh, dll.
Dalam subjek, mis. proyek dan tim perubahan, ada elemen khusus - algoritma untuk memilih metode yang akan dilaksanakan, tujuan dan motivasi manajer proyek dan tim, metodologi implementasi, prinsip-prinsip manajemen proyek, pendekatan manajemen untuk menilai kemajuan dan hasil proyek, rencana tim untuk kehidupan setelah proyek, pilihan masalah yang harus diselesaikan, dll. .d.
Tidak seorang pun dapat dengan andal melihat semua elemen dan koneksi, bahkan programmer bisnis yang paling berpengalaman. Tetapi beberapa, bagian tertentu dilihat oleh semua orang - manajer proyek implementasi, kepala perusahaan, dan semua kolega di sekitarnya.
Namun, itu adalah programmer bisnis yang memberikan perkiraan paling akurat. Semua orang melihat hal yang sama. Lihat objek, lihat subjek, rencana proyek, sumber daya, lingkungan. Tetapi ramalan itu berbeda secara mendasar. Mengapa
Jawabannya sangat sederhana, dan bahkan membosankan: seorang programmer bisnis memperhitungkan
informasi historis akun. Informasi historis dan statistik tentang perilaku sistem yang serupa.
Hasil dari proyek implementasi perubahan terdiri dari
kombinasi dua sistem - sebuah objek dan subjek. Jika sistem tidak pas dengan benar, hasilnya akan negatif.
Jika proyek perubahan baru sedang disusun, tetapi sistem objek dan subjek tidak banyak berubah, hasilnya kemungkinan besar akan serupa. Orang yang sama berusaha menerapkan metode yang sama di unit yang sama.
Ada banyak contoh. Jika Anda melihat dengan sistematis melihat sejarah pengenalan perubahan di perusahaan Anda, Anda akan melihat konfirmasi dari pola ini.
Anda dapat mencari contoh di jalan, sekarang sistem yang tepat - "musim dingin" disebut. Musim dingin + kota + ini, seperti mereka, salju mana yang harus dihilangkan. Tahun-tahun berlalu, dan hasilnya serupa. Karena semua sistem ada, tidak berubah. Oh ya, terkadang musim dingin tanpa salju - maka hasilnya sangat bagus. Milik siapa
Bagian tersulit dari pendekatan ini adalah untuk menentukan apakah
ada perbedaan dalam sistem atau tidak. Untuk melakukan ini, Anda perlu belajar menentukan peringkat elemen dan hubungan sistem dengan kepentingan - untuk menyoroti elemen kunci dan elemen pembentuk sistem dan hubungan.
Tidak ada resep tunggal, ada banyak pilihan. Ada, misalnya, metode 7S, dibuat di McKinsey, yang mem-parsing sistem menjadi 7 bagian. Secara pribadi, saya lebih suka untuk tidak membatasi diri, jika tidak, Anda dapat melihat sesuatu yang baru untuk diri sendiri.
Memahami elemen-elemen kunci dapat dilakukan secara intuitif, tetapi Anda perlu mengecek diri sendiri, karena kualitas intuisi tergantung pada tingkat perkembangan Anda saat ini sebagai programmer bisnis, dan dapat menipu Anda.
Menyoroti elemen kunci akan memungkinkan Anda membuat perkiraan lebih cepat, tanpa masuk ke detail dan tanpa mempelajari kebisingan. Anda hanya melihat bahwa elemen kunci dari kedua sistem tetap di tempatnya, dan Anda dapat yakin bahwa hasilnya akan diulang dengan probabilitas tinggi.
Semakin sering Anda melakukan latihan ini, semakin cepat keterampilan Anda akan berkembang, dan prediksi Anda akan semakin akurat.
Ada ungkapan yang begitu populer di negara kita - “mereka menginginkan yang terbaik, tetapi ternyata seperti biasa”. Sekarang, setelah membaca, Anda mengerti bahwa ada sesuatu yang hilang di sini. Akan lebih benar "mereka menginginkan yang terbaik, bertindak seperti biasa, yah, inilah hasilnya ...".
Saya melihat contoh pendekatan semacam itu dengan Menteri Luar Negeri kita, Sergey Lavrov. Pada konferensi pers setelah pertemuan dengan Menteri Luar Negeri AS Rex Tillerson, Lavrov mengatakan: "Sehubungan dengan masalah spesifik Suriah, khususnya B. Assad, hari ini kami membahas perjalanan sejarah, dan R. Tillerson mengatakan bahwa ia adalah orang baru dan memilih untuk tidak menggali sejarah. , dan menangani masalah hari ini. Namun, dunia dirancang sedemikian rupa sehingga jika kita tidak belajar dari masa lalu, kita tidak akan berhasil di masa sekarang. ”
Kemudian Lavrov mendaftar beberapa contoh - kombinasi sistem dari objek dan subjek, dengan tujuan yang sama dari subjek - pengenalan model demokrasi melalui penggulingan diktator. NATO dan Irak, NATO dan Libya. Dan meramalkan hasil kombinasi NATO dan Suriah.
Sejauh ini, tampaknya, Lavrov benar.