- Bir sistemi ya da ürünü anlamaya yarayan mental modeli başkalarına aktarmak ve birlikte geliştirmek için etkili araç ve teknikleri soran bir soru
- Mental modeli geliştirmenin bir yolu olarak sistemi doğrudan kurma ve bakımını yapma deneyimi anılıyor
- Aktarım biçimi; peçeteye karalamak, yan yana durup jestlerle anlatmak, birlikte düşünürken sözlü olarak açımlamak gibi gayriresmî açıklamalara daha yakın
- İşlev listelerini ya da yüzey alanını eksiksiz biçimde düzenleyen belgeler kapsamlı olabilir, ancak bir konunun mental modelini kurmak veya aktarmak için yetersiz kalabilir
- İyi tasarlanmış bir araç ya da ürünü bizzat kullanma deneyimi, mental modeli geliştirme ve aktarma sürecine aynı anda yardımcı olabilir
Sorunun odağı
- Hangi araç veya tekniklerin mental modelleri aktarmada ve büyütmede etkili olduğu temel mesele
- Soru iki yönü birlikte ele alıyor
- Mental modeli geliştirmenin yolları
- Mental modeli başkalarına aktarmanın yolları
Örnekler ve mesele
- Mental modeli geliştirmenin bir örneği olarak sistem kurma ve bakımını yapma yaklaşımı veriliyor
- Mental modeli aktarma biçimi, sahada birlikte anlayışı hizalama şeklinde ortaya konuyor
- Peçeteye karalamak
- Yanında durup jestlerle açıklamak
- Birlikte düşünürken açıklamak
- İşlevleri sıralayan ya da yüzeysel kapsamı kataloglayan belgeler kapsamlı olabilir
- Ancak bu tür belgeler, ilgili konunun mental modelini kurmaya veya aktarmaya kadar gitmeyebilir
- İyi tasarlanmış bir aracı ya da ürünü doğrudan kullanma deneyimi, mental modelin hem gelişimini hem de aktarımını sağlayabilen bir yöntem olarak ele alınıyor
- Son soru, herkesin etkili bulduğu araç ve teknikleri ve bunların neden etkili olduğunu soruyor
1 yorum
Lobste.rs görüşleri
Olog, ontolojiyi aktarmak için iyi bir biçimselciliktir.
Çok sayıda iç durumu olan uzun süre çalışan süreçlerde, durum diyagramları ve state chart'lar sistem dokümantasyonu için faydalıdır.
Sistem kullanıcıları genelde gerçek sistem yapısını algılamaz. Bunun bir nedeni, Nakatomi space'in yalnızca sistemi yanlış kullanan kullanıcılara görünmesi; bir diğeriyse weird machines gibi istenmeyen davranışlara ayrılmış ayrı durum uzayı bölgelerinin bulunmasıdır.
Bir başka neden de the purpose of a system is what it does bakış açısında olduğu gibi, kullanıcıların sistemin kendileri için yaptığı şeye bakıp kişisel bir varlık nedeni üretmesi, ama tasarımcılar ve bakımcıların amaçladığı bütünsel amacı fark etmeyebilmesidir.
Bir kitap yazıp bir editör tutabilirsiniz.
Bu bana eğitimin özündeki mesele gibi geliyor. Yapa yapa öğrenme ve uzman rehberliği diye iki kategori duydum; üçüncüsü de öğretmek.
Daha önemli soru, benzer ilke ve tasarımları yeniden kullanarak daha kolay edinilen modeller kurup kuramayacağınız ya da soyutlama yoluyla bunları tamamen edinme ihtiyacını azaltıp azaltamayacağınızdır. Yalnız soyutlamanın nerede sızdırdığı iyi tanımlanmış olmalıdır.
Bu bağlamda Felienne Hermans'ın The Programmer's Brain kitabı ilginç. Küçük çocuklara matematik vb. öğretirken kullanılan “bir sürü örneği ben çözeceğim, sen izle” yaklaşımının programlama eğitiminde de oldukça işe yaraması dikkat çekiciydi.
İş ortamında onboarding yapıyorsanız bu, “bu bug'ı nasıl araştırdığımı izle” ya da “bir süredir el sürmediğim bu alt sistemi nasıl yeniden kavradığımı izle” gibi görünebilir.
Yazılım mühendisliğinde zihinsel modeli kullanıcı hikayeleri ve teknik uygulama olarak ayırmak faydalıdır.
Genellikle kullanıcı hikayeleri birincil gereksinimlerdir; yani ulaşılılmak istenen değerdir. Teknik uygulama ise bu hedefe ulaşmak için gereken ikincil unsurdur.
Kullanıcı hikayeleri müşteriye aktarılan değeri açıklar; teknik uygulama ise kurulan sistemin kısıtlarının kullanıcı hikayelerini nasıl sınırladığını açıklar.
Bazen ikisi çakışır; kullanıcı hikayesi teknik uygulamayla kısıtlanır ya da tersine, kullanıcı hikayesini gerçekleştirmek için teknik uygulama seçilir. Ama birçok sistem davranışı bu ikisinden biriyle çerçevelenebilir.
Sonrasında en uygun aracı seçebilirsiniz. UML nesne haritaları çizmek için iyidir, akış diyagramları akışı anlatmak için iyidir. Durum diyagramları izin verilen/verilmeyen durumları ve geçişleri açıklamak için iyidir; değişkenler ve durum tablolarıysa tüm olası değerleri listelemek için iyidir.
Bir sistemi çizmeyi öğrenmenin en iyi yolu, üç farklı kişiden her birinin kendi düşündüğü diyagramı çizmesini istemektir. Aynı fikri ifade etmenin ne kadar şaşırtıcı derecede çeşitli olduğunu görürsünüz; çoğu da eşit derecede geçerlidir ama konunun farklı yönlerini görünür kılar. Biraz sanata benzer.
Çoğunlukla daha biçimsel diyagramlar kullanıyorum. Yine de ekran paylaşımı sırasında gerçek zamanlı karalama yaparken bazen jspaint'i açıyorum; daha sonra başkalarının da bakacağı bir şeyse Figjam gibi araçlar kullanıyorum.
Diyagram ve işaret etmenin iyi çalışmasının nedeni, bunların sahip olduğumuz en eski ve hâlâ yararlı dikkat yönlendirme araçları olması. Konuşmadan önce de işaret ediyor ve ağlıyorduk; konum ve gezinmede işaret etmek dilden çok daha dolaysız olduğu için lazer işaretçi pazarı hâlâ var.
Peter Gårdenfors'un The Geometry of Meaning: Semantics of Conceptual Spaces kitabı bu konuyu epey ayrıntılı işler. Barbara Tversky'nin de diyagramlar ve bilişsel mekânın yapılandırılması üzerine çok sayıda çalışması var; Peter Cheng'in “What Constitutes an Effective Representation?” yazısı ise etkili temsilin ölçütlerini oldukça nicel biçimde ortaya koyuyor.
Shadowing, pairing ve whiteboard oturumları iyidir. Bu sırada her iki taraf da çizim yapmalı ve soru sormalıdır.
Modeli genişleten ya da değiştiren bir projeyi birlikte seçip yürütmek, quiz'ler, öğrencinin geri öğretmesi, ezberleyip elle yeniden yazmak gibi yöntemler de vardır.
Basit ezber her zaman başka yöntemlerle birlikte kullanılmalı, asla tek yöntem haline gelmemelidir. Whiteboard dışında diyagram ya da karalamalar yapmak, başka model/çözümlerle kıyaslanan boşluk analizi ve hammock time gibi düşünsel, yarı bilinçdışı yansıma biçimleri de yardımcı olur.
Aktarım için kullanılan temsil ile gerçek görevi yerine getirmek için kullanılan temsili ayırmak gerektiğini düşünüyorum. İkincisi burada pek geçmese de daha çok “icra”ya yakındır.
Çalıştırılabilir modeller çoğu zaman aktarmada başarısızdır; çünkü genellikle soyutlama sınırları kötüdür. Bilişimde bunlar neredeyse her zaman sızdıran soyutlamalardır.
Bir şeyin ne yaptığını anlamak, onu verimli kılmak için üst üste yığılmış emek dağı tarafından gizlenebilir. Bu yüzden peçeteye bir şeyler karalayıp “senin mevcut zihinsel modeline uygun soyutlama düzeyinde bu sistem böyle çalışıyor” diye açıklamak gerekir.
Dokümantasyon ayrı bir çıktı olduğu için yürütülebilir modelin gerisinde kalma eğilimindedir; bunu önlemek için çok özenli bakım gerekir. Daha zor yöntem, dokümantasyonu doğrudan koda bağlamak ya da literate programming gibi yaklaşımlarla dokümantasyonu kodun önüne koymaktır.
Bu yüzden zihinsel modelleri aktarmada genelde en az çaba ve bakım gerektiren yol doğrudur: peçete karalamaları ve zaman içinde gerçek sistemle birlikte çalışma.
Yeni başlayanların tasarım belgesi yazmakla değil, kolay bug düzeltmeleriyle başlamasının bir nedeni var.
Yeni başlayan biri yaparak öğrenmek zorundadır; bu yüzden tutorial en uygun seçenek olabilir. Ama biraz kurcaladıktan sonra büyük olasılıkla bazı yanlış anlamalar da birikmiştir ve bunları peçete üstündeki bir açıklama çözebilir.
Dolayısıyla tutorial yazmaya karar verdiyseniz “her şeyi kapsayan” bir belge üretmeye çalışmayın; odağı net, iyi bir tutorial yazın.
Cevap yazmaktır.
Yazılım, kişiye özel dinamik bir ortam olduğu için oldukça ilginç.
Etkileşimli sistemlerin yardımcı olduğunu düşünüyorum. Örneğin Python'u ve kutulanmış değişkenleri öğreten görsel bir debugger gibi.