👏🏽 👸 🚮 Sumber: "Hukum Conway" 🚏 👧 🏂🏻

Catatan penulis 42 tahun setelah publikasi:

Mungkin yang paling menonjol dalam artikel ini, itu diterbitkan karena pernyataan yang dijelaskan dalam paragraf ketiga dari akhir. Untuk meringankan kesulitan mengatasi 45 paragraf sebelumnya, saya akan menyuarakannya dalam bentuk bebas sekarang:

Setiap organisasi yang merancang sistem (ditafsirkan di sini lebih dari sekadar sistem informasi) pasti akan membuat model yang akan mengulangi struktur komunikasi organisasi itu sendiri.

Ternyata prinsip ini diamati tidak hanya dalam pengembangan perangkat lunak, dalam konteks yang sering disebut.

Saya sarankan Anda membiasakan diri dengan materi, dan kemudian melihat-lihat dan mencarinya di daerah lain.

Saat ini, contoh favorit saya adalah kompleks masalah sosial terkait dengan kemiskinan di Amerika: akses ke pasar tenaga kerja, perumahan, pendidikan dan perawatan kesehatan. Setelah membaca artikel tersebut, pertimbangkan bagaimana struktur berbagai pemerintahan kita memengaruhi sikap mereka terhadap masalah-masalah tersebut.

Bagaimana komite membuat yang baru?

Melvin E. Conway
PDF asli .

Aktivitas intelektual, sebagai hasil dari mana keseluruhan dibuat dari bagian yang berbeda, dapat disebut desain sistem. Baik itu persiapan kompleks militer besar, rekomendasi untuk menyelesaikan masalah sosial atau daftar program komputer. Tujuan tipikal dari organisasi desain adalah menyiapkan dokumen yang berisi jumlah informasi yang terstruktur secara koheren. Kami menyebut informasi ini model sistem. Biasanya, penggagasnya adalah pelanggan yang ingin menggunakan model untuk memberikan tindakan lebih lanjut. Misalnya, seorang negarawan bermaksud mengajukan RUU untuk mencegah terulangnya bencana baru-baru ini, karena ini ia menyewa sebuah tim untuk mencari tahu penyebab bencana. Atau pabrikan membutuhkan produk baru, dan ia menunjuk orang yang bertanggung jawab untuk menentukan produk baru dan merencanakan pembebasannya.

Organisasi desain mungkin atau mungkin tidak terlibat dalam implementasi sistem yang dirancang. Seringkali dalam upaya pemerintah, ada norma yang mencegah kelompok untuk bertindak sesuai dengan rekomendasi sendiri, sementara situasi sebaliknya berlaku di sektor swasta. Masuk akal untuk mengasumsikan bahwa kondisi ini akan memengaruhi proses desain sistem, bersama dengan gagasan pengembang lainnya tentang masa depannya sendiri. Seperti yang akan kita lihat nanti, insentif yang ada di lingkungan manajerial tradisional mungkin bertentangan dengan tujuan pelanggan. [1]

Tahapan desain

Fase desain awal lebih terkait dengan penataan proses itu sendiri daripada pengembangan sistem [2]. Pengembangan penuh didahului oleh tindakan pendahuluan tertentu, yaitu:

Menentukan batas-batas kegiatan proyek dan hasil akhir yang ditetapkan oleh pelanggan dan realitas yang ada.
Penilaian awal terhadap struktur sistem dengan tujuan pembentukan tim pengembangan yang seimbang.

Di masa depan, kami akan menjelaskan secara rinci bahwa struktur organisasi tim sudah mempengaruhi pelaksanaan proyek, secara langsung atau tidak langsung. Jadi, bahkan ketidakmampuan untuk menyediakan kondisi ideal untuk mencari karyawan, pembentukan tim tidak akan dilakukan sepenuhnya secara objektif. Dan setelah pembentukan tim, tanggung jawab akan didelegasikan ke subkelompok, mempersempit ruang lingkup penelitian, yang secara bersamaan akan mengurangi jumlah opsi untuk pengembangan sistem.

Setelah mengalokasikan tanggung jawab, manajer menghadapi masalah koordinasi di tingkat kelompok kerja, yang berdampak negatif pada konsolidasi upaya masing-masing kelompok untuk menciptakan sistem yang seragam. Meskipun ada kemungkinan penurunan peran individu ini.

Proses desain sistem memiliki tahapan sebagai berikut:

Mendefinisikan batas sesuai dengan aturan dasar.
Pengembangan konsep sistem pendahuluan.
Organisasi pekerjaan desain dan pendelegasian tugas sesuai dengan konsep.
Koordinasi di tingkat tugas yang didelegasikan.
Menggabungkan subsistem ke dalam suatu sistem.

Dalam satu karya desain, semua tahapan mungkin tidak dilacak. Mungkin saja dalam prosesnya akan ditemukan konsep proyek baru yang lebih sempurna. Ini, tentu saja, bukan momen yang sangat menguntungkan, karena penghentian kerja selanjutnya akan menyakitkan dan mahal. Tentu saja, dari sudut pandang sejarawan, semuanya terulang.

Dalam hal ini, mengapa selalu tidak ada cukup waktu untuk melakukan semuanya dengan benar, tetapi selalu ada cukup waktu untuk mengulang sesuatu?

Desain sistem

Setiap sistem serial terdiri dari subsistem yang saling berhubungan. Deskripsi struktur internal sistem harus mencerminkan hubungannya dengan lingkungan eksternal dan hubungan subsistemnya. Turun ke tingkat yang lebih rendah, kita dapat mengatakan hal yang sama tentang subsistem, menganggapnya sebagai suatu sistem. Dan seterusnya, ke subsistem seperti itu, yang akan sangat sederhana dan tak terpisahkan.

Contohnya

Sistem transportasi lintas negara terdiri dari bus, kereta api, pesawat terbang, taksi, tempat parkir, terminal, dll. Ini adalah sistem yang sangat heterogen, yang berarti subsistemnya cukup beragam. Turun ke tingkat yang lebih rendah, misalnya, kita akan melihat subsistemnya: kerangka, mesin, distribusi daya, komunikasi, muatan. Sistem mesin mencakup subsistem seperti bahan bakar, pengapian, dll.

Tidak begitu jelas, tetapi teori juga merupakan suatu sistem. Ini mengacu pada lingkungan eksternal, ke peristiwa yang diamati, yang harus dijelaskan atau setidaknya tidak bertentangan dengan mereka. Ini terdiri dari bagian-teori yang berhubungan satu sama lain dengan cara yang sama. Sebagai contoh, dalam proses penyelidikan kecelakaan, sebuah teori telah dibuat yang menggambarkan lintasan pesawat, komunikasinya, kerusakan, dan interaksinya dengan objek lain selama kecelakaan. Masing-masing item itu sendiri adalah cerita yang terpisah dan juga dapat dibagi menjadi sub-item, hingga masing-masing unit informasi.

Skema

Dalam Fig. 1, sistem digambarkan dalam bentuk diagram - mirip dengan mainan - dengan koneksi (cabang) dalam bentuk garis dan simpul utama (node) dalam bentuk lingkaran. Setiap node melambangkan subsistem yang berkomunikasi dengan subsistem lain, yang dapat direpresentasikan dengan cara yang sama. Antarmuka istilah, yang semakin populer di kalangan pengembang, mengacu pada interaksi subsistem, yang ditunjukkan oleh garis.

gambar

Gambar grafis dengan jelas menunjukkan bentuk identik dari dua konsep yang kami pertimbangkan: sistem dan organisasi yang mendesainnya. Coba ganti:

"Sistem" ke "komite"
"Subsistem" ke "subkomite"
"Antarmuka" ke "koordinator"

Seperti dalam kasus sistem, kita melihat bahwa organisasi desain dapat dipertimbangkan dengan mempertimbangkan beberapa tingkat kompleksitas. Pemerintah federal adalah contoh yang bagus dari organisasi desain dengan tingkat kompleksitas yang dapat memuaskan setiap insinyur. Ini adalah contoh yang sangat menarik, menunjukkan kesamaan dari dua konsep yang kami pertimbangkan, karena Pemerintah Federal adalah organisasi desain (mengembangkan undang-undang, perjanjian, kebijakan) dan organisasi desain (dengan Konstitusi sebagai dokumentasi desain utama).

Interaksi primer

Sekarang kita siap untuk masalah utama artikel ini. Apakah ada hubungan yang dapat diprediksi antara struktur organisasi desain dan sistem yang dirancangnya? Jawaban yang benar adalah ya, dan koneksi ini sangat sederhana sehingga sering konstan. Pertimbangkan "bukti" berikut ini.

Mari kita secara sewenang-wenang memilih sistem dan organisasi yang mengembangkannya dan secara acak memilih tingkat kerumitan sistem yang dirancang, membuat sketsa (pilihan kita sewenang-wenang, karena jika kita mengamati hubungan yang menarik, kita dapat memperluasnya ke organisasi desain dan tingkat kerumitan apa pun). Dalam Fig. Gambar 2 menunjukkan (untuk kejelasan) struktur di mana pernyataan di bawah ini benar.

gambar

Untuk setiap simpul x dalam sistem, kami dapat mengidentifikasi kelompok kerja dari organisasi desain yang mengembangkannya (dilambangkan dengan X). Dengan cara ini

meringkas proses ini, untuk setiap simpul dalam sistem kami memiliki aturan untuk menemukan kelompok kerja yang sesuai. Harap perhatikan bahwa rasio 1: 1, mis. dua subsistem dapat dirancang oleh organisasi desain yang sama.

Menariknya, kita bisa membuat pernyataan serupa tentang cabang. Ambil dua simpul dari sistem yang sama, x dan y. Mereka mungkin atau mungkin tidak terhubung (mis., Apakah mereka berinteraksi satu sama lain dalam beberapa cara yang penting untuk berfungsinya sistem atau tidak). Jika ada koneksi di antara mereka, maka dua kelompok kerja X dan U, yang mengembangkan dua node data, harus menyetujui fitur antarmuka untuk menyadari kemungkinan komunikasi antara node. Jika tidak ada koneksi antara x dan y, maka subsistem tidak berkomunikasi satu sama lain, yang berarti bahwa kelompok kerja tidak saling berinteraksi (karena tidak ada koneksi antara X dan Y). [3]

Apa yang baru saja kami tunjukkan? Dengan kata sederhana, kami telah menunjukkan bahwa ada hubungan yang erat antara struktur sistem dan struktur organisasi yang terlibat dalam desainnya. Ketika setiap subsistem memiliki kelompok kerja terpisah, kita dapat mengamati bahwa struktur (skema) dari kelompok kerja dan subsistem itu identik. Dalam kasus ketika beberapa kelompok kerja mengembangkan satu subsistem, struktur organisasi desain terlihat seperti struktur sistem, tetapi dengan lebih sedikit subsistem (node dalam diagram).

Hubungan struktur-pengawetan serupa antara dua objek disebut homomorfisme. Dalam bahasa matematika, ada homomorfisme antara diagram sistem dan diagram proyeksi organisasi.

Sistem adalah refleksi dari organisasi yang mendesainnya

Banyak perancang sistem berpengalaman percaya bahwa siapa pun dapat melakukan desain sistem dengan lebih baik. Dengan kata lain, adalah keliru dan salah untuk berbicara tentang tugas desain kecuali dalam konteks tempat, waktu, tingkat pengetahuan dan teknologi. Ini harus diingat oleh mereka yang membaca kisah karya mendesain objek atau mengingat dan menganalisis karya mereka.

Pengembangan penerjemah komputer dari bahasa pemrograman seperti FORTRAN dan COBOL adalah contoh yang bagus. Pada pertengahan 1950-an, ketika prototipe bahasa-bahasa ini muncul, kompiler mereka bahkan lebih rumit daripada komputer itu sendiri, raksasa pada masa itu yang seharusnya menjalankan perintah. Saat ini, para penerjemah ini hanyalah keajaiban sejarah yang tidak memiliki kesamaan dengan kompiler modern. (Perlu dicatat bahwa terobosan besar dalam pengembangan penyusun dikaitkan dengan kemunculan kelompok orang baru di daerah yang sebelumnya dianggap sebagai warisan produsen komputer - ini awalnya merupakan kelompok peneliti universitas yang kompak, diikuti oleh pengembang perangkat lunak independen).

Jika kita mengasumsikan bahwa untuk persyaratan sistem apa pun ada sejumlah proyek sistem yang akan memenuhi persyaratan ini, kita juga harus bertanya apakah pilihan organisasi desain memengaruhi proses pemilihan proyek sistem dari seri ini. Jika kita percaya pada homomorfisme kita, maka kita akan setuju dengan apa yang memengaruhi. Mengingat bahwa organisasi tidak memiliki struktur komunikasi yang fleksibel, organisasi ini akan mencap salinan dirinya dalam produk proyek apa pun. Semakin besar organisasi, semakin tidak fleksibelnya dan semakin banyak properti ini dimanifestasikan.

Contohnya

Dalam satu organisasi penelitian, ada delapan orang yang seharusnya membuat kompiler COBOL dan ALGOL. Setelah penilaian awal dari kompleksitas dan tenggat waktu yang mungkin, lima dari mereka ditentukan untuk bekerja dengan COBOL, dan tiga ditugaskan untuk bekerja dengan ALGOL. Akibatnya, kompiler COBOL bekerja dalam lima lintasan, dan kompiler ALGOL dalam tiga lintasan.

Dua dinas militer di bawah kepemimpinan komandan mereka telah mengembangkan sistem senjata untuk kebutuhan mereka. Setelah itu, bukan tanpa usaha, mereka membuat salinan struktur organisasi mereka (lihat Gambar. 3a)

gambar

Perhatikan sistem operasi komputer yang terlibat dalam tugas ini. Setelah mempelajarinya secara rinci, kita melihat bahwa itu terdiri dari tiga bagian: perangkat keras, perangkat lunak, dan aplikasi (lihat Gambar. 3b). Pengembang mereka terkait dengan subsistem ini: insinyur dari produsen komputer, pemrogram sistemnya dan pengembang aplikasi khusus (hal yang jarang terjadi ketika spesialis perangkat keras dan perangkat lunak berkolaborasi, dan tidak hanya saling menanggung dengan susah payah)

Manajemen sistem

Struktur sistem besar cenderung membusuk ketika mereka berkembang. Pengamatan ini sangat jelas ketika mempertimbangkan sistem informasi militer besar selama sepuluh tahun terakhir. Mereka adalah objek paling kompleks dari semua yang diciptakan manusia sebelumnya. Suatu kegiatan yang disebut "manajemen sistem" telah muncul, termasuk karena kecenderungan sistem untuk berpisah menjadi elemen-elemen penyusunnya. Mari kita lihat kepraktisan manajemen sistem dalam konteks ide utama artikel ini.

Mengapa sistem besar berantakan? Proses ini melewati tiga tahap, dua yang pertama dapat dikontrol, dan tahap ketiga adalah konsekuensi langsung dari homomorfisme kita.

Pertama, para pengembang, setelah menyadari ukuran sistem yang diproyeksikan, tidak dapat menahan godaan untuk mempekerjakan orang sebanyak mungkin untuk membuatnya.
Kedua, ketika menerapkan model manajerial biasa untuk implementasi proyek berskala besar seperti itu, struktur komunikasinya terpecah menjadi beberapa bagian yang terpisah.
Ketiga, proses disintegrasi yang terjadi dalam struktur organisasi-perancang terjadi dalam struktur sistem, sesuai dengan fenomena homomorfisme.

Untuk memulai, pertimbangkan situasi dengan "kelebihan penduduk". Keinginan alami pengembang untuk mendelegasikan tugas cukup dapat dipahami ketika tingkat kompleksitas sistem mendekati batas pemahamannya. Ini adalah titik balik dalam proses pengembangan. Entah dia berjuang untuk menyederhanakan sistem dan menang, atau dia kehilangan kendali atasnya. Hasilnya hampir dapat diprediksi, mengingat tekanan kerangka waktu dan anggaran.

Jika tenggat waktu hilang, manajer akan disalahkan jika ia tidak menggunakan semua sumber daya untuk mencegahnya. Oleh karena itu, ia akan mencoba untuk mempengaruhi pengembang, yang, mungkin, lebih suka berurusan dengan kompleksitas sistem, dan tidak mendelegasikan tugas kepada orang lain. Akibatnya, jumlah sumber daya yang terlibat akan meningkat.

Atau contoh lain, menunjukkan kasus serupa dari konflik manajer dan integritas sistem yang dirancang. Manajer harus memberikan bagian pekerjaan yang kritis dan kompleks untuk implementasi. Dia dapat memilih salah satu dari dua pemain: perusahaan kecil baru, yang dibedakan dengan pendekatan kreatif dan upah rendah, atau kantor terkemuka yang telah memantapkan dirinya, yang memiliki harga lebih "realistis". Dia tahu bahwa jika perusahaan muda yang cerdas tidak mengatasi tugas tersebut, dia akan bersalah karena mengganggu proyek. Jika organisasi terkenal gagal, maka ini hanya akan menunjukkan bahwa tugasnya sangat sulit.

Apa hasil tangkapan di sini? Pada dasarnya, dalam metode mengevaluasi dan mengalokasikan sumber daya, yang secara tradisional digunakan. Jadi, unit sumber daya adalah dolar, jadi semua sumber daya dinyatakan dalam dolar. Jika sumber dayanya adalah tenaga manusia, satuan pengukuran akan menjadi biaya satu jam kerja dikalikan dengan jumlah pekerja.

Kekeliruan dari pendekatan ini adalah bahwa pekerjaan dua orang selama tahun tersebut dievaluasi dengan cara yang sama dengan pekerjaan ratusan orang selama seminggu. Tetapi karena struktur organisasi pekerjaan dua ratus akan berbeda, mengingat homomorfisme, dapat dikatakan bahwa mereka akan menciptakan sistem yang berbeda, jadi Anda tidak harus membandingkan biaya pekerjaan mereka. Dari pengalaman, kita tahu bahwa dua orang yang dipilih dengan benar, jika mereka mengatasinya, akan menunjukkan hasil terbaik. Asumsi yang mungkin benar untuk mengupas kentang atau meletakkan batu bata adalah keliru dalam desain sistem.

Hukum Parkinson [4] sangat penting dalam redistribusi sumber daya tenaga kerja dalam kegiatan proyek. Selama reputasi manajer tergantung pada ukuran anggaran, ia akan tertarik untuk memperluas organisasinya. Ini bukan motivasi yang cocok untuk memecahkan masalah pengembangan sistem. Setelah sebuah organisasi ada, maka tentu saja itu akan digunakan. Mungkin alasan yang paling menarik untuk keberadaan begitu banyak sistem yang dirancang dengan buruk saat ini terletak di hadapan organisasi desain yang mencari pekerjaan.

Di tempat kedua, alasan runtuhnya proses desain sistem - fragmentasi struktur komunikasi organisasi desain - mulai memanifestasikan dirinya dengan awal pendelegasian tugas. Menurut teori probabilitas elementer, jumlah komunikasi yang mungkin sama dengan setengah kuadrat dari jumlah karyawan organisasi. , . .

. , . . , .

Kesimpulan

— , ( ) , . , . : , , . , . , , , , , - , .

, . , , . . .

[1] . « » (John Kenneth Galbraith's The New Industrial State). VI, «».

[2] C. « » (.J. Middleton, «How to Set Up a Project Organization,» 1967, . 73).

[3] . , . , , .

[4] .. « » (C. Northcote Parkinson, Parkinson's Law and Other Studies in Administration, 1957)

:

Lebih banyak

«»

«Augmenting Human Intellect:
A Conceptual Framework» , .

«» — « », «» , , () .

— ( , ! , .) — , , , , , , , , WikiPedia, Web Archive, Knol, Quora, Cybersyn, Xanadu, DARPA, IARPA.

— 50 . Ibu dari semua demo

Jika Anda benar-benar ingin memahami NLS, Anda harus melupakan kenyataan hari ini. Lupakan semua yang Anda ketahui tentang komputer. Bayangkan Anda masih belum tahu apa itu komputer. Kembali ke tahun 1962. Dan kemudian membaca apa yang ada dalam pikirannya .
- Bret Victor, Beberapa kata tentang Douglas Engelbart

bahan yang bermanfaat