İnsanları dinleme işinden mühendislik yoluyla kaçmaya çalışmayın

• Yazılım sahasındaki temel zorluk, diyaloğun kendisinin eksikliğinden çok dinleme eksikliğidir; bunu framework ya da system gibi ifadelere çevirerek çözmeye çalışma yaklaşımı, aslında gerekli olan dinleme işinin etrafından dolanır
• Birinin talebini aynen yerine getirmek, gerçek ihtiyacı anlamakla aynı şey değildir; uzmanlık etkisi ve technical/non-technical ikiliği, karşımızdakinin bilgisini ve bağlamını gözden kaçırmamıza yol açar
• Herkesin aynı enerjiye, beceriye ve paraya sahip olduğunu varsaymak ya da bir kişinin özelliklerini tüm gruba genellemek, kişiden kişiye değişen kısıtları ve karar ölçütlerini doğru yakalamayı engeller
• İnsanlar ve organizasyonlar zamana, role, strese ve grup dinamiklerine göre değişir; söylenenlerle gerçekten düşünülenler de her zaman örtüşmediği için sabit gereksinimler, yazılım üretimiyle kolayca uyumsuz hale gelir
• Dinleme başarısızlığı, en değerli içgörülerin kaçırılmasına yol açar ve gelir fırsatlarının ve rekabet avantajının kaybına, yanlış anlamaların birikmesiyle tech debt artışına neden olur

---

Ana tez

• Yazılım sahasında insanlar arası diyalog eksikliğinden daha büyük asıl mesele dinleme eksikliğidir; bunu framework ya da system gibi terimlere çevirerek çözmeye çalışma yaklaşımı, gerçekte gerekli olan işi yapmaktan kaçınma biçimidir
• Tasarımcılar ve product ekipleri, insanlarla yapılan konuşmaları engineering'in daha kolay kabul edeceği ifadelere çevirmeye çalışıyor; ancak daha iyi bir çerçeveden çok, gerekli olan şey insanların söylediklerini gerçekten dinlemek
• İnsanlarla konuşmaktan daha zor olanın insanları dinlemek olduğu kabulüyle, dinlemeyi fiilen engelleyen başlıca tuzaklar sıralanıyor

Dinlemeyi engelleyen başlıca tuzaklar

• Söyleneni yapmak ile dinlemek aynı şey değildir

  • Birinin istediğini söylediği şeyi aynen yapmak ile gerçek ihtiyacı duymak aynı değildir
  • Bu konuyla ilgili mevcut yaklaşımlar olarak Jobs To Be Done, Outcome Driven Innovation ve UX alanındaki empathy mapping anılıyor

• Uzmanlık etkisi nedeniyle kendi bakış açını hafife almak

  • Belirli bir alanda uzun süre çalışınca "bunu zaten bilir" varsayımı kolayca oluşur
  • Karşımızdaki kişi o alanın uzmanı olsa bile aynı bilgiyi biliyor olmayabilir; bunun yerine başka bir bilgiye sahip olabilir
  • Doğru dinleyebilmek için, karşımızdakinin ne bildiğini daha iyi anlamaya ihtiyaç vardır

• technical kavramını tek bir kategori saymak

  • Özellikle yazılım geliştiricilerde yaygın bir tuzaktır; technical, tek bir özellik değil, heterojen bilgi alanlarından oluşan geniş bir spektrumdur
  • İnsanlara "technical / non-technical" ikiliğiyle bakmak, içgörülerin kaçmasına ve doğru dinleyememe ihtimalinin artmasına neden olur

• Herkesin aynı kaynaklara sahip olduğunu varsaymak

  • Herkesin aynı enerjiye, aynı beceriye ve aynı miktarda boş paraya sahip olduğunu varsaymak yanlış yargılara yol açar
  • Aynı sağlık durumuna sahip insanlar bile bunu yönetme biçimleri ya da fiilen yapabilecekleri şeyler bakımından farklı olabilir
  • Matematikte güçlü olanlar, başka becerilerde güçlü olanlar, parası ya da zamanı daha az olduğu için daha riskten kaçınan davrananlar gibi farklar vardır

• Bir kişinin özelliğini tüm gruba genellemek

  • Belirli bir özelliğe sahip bir kişiyle karşılaşmış olmak, diğer herkesin de aynı olduğu anlamına gelmez
  • Örnek olarak yaşlı insanların bilgisayarı anlamadığını peşinen varsayan tutumdan söz ediliyor
  • Tüm kadınları kişisel aile ilişkilerinden türetilen bir imgeye indirgemek de aynı hatadır

• İnsanların ve organizasyonların sabit olduğunu varsaymak

  • Makro düzeyde kişilik zaman içinde değişir
  • Mikro düzeyde ise iş yerindeki persona ile evdeki hâl farklıdır; stres altında ya da belirli koşullarda yargılar da değişir

• Söylenenle düşünülenin aynı olduğunu varsaymak

  • Bazı insanlar söyledikleri şeyi aynen kasteder, bazıları ise etmez
  • Kişi kendisinin dürüst konuştuğunu sansa bile, gerçekte çoğu zaman durum böyle değildir

• İnsanları yargılamak

  • Kötü belgelenmiş bir şeyi yanlış anlayan birinden nefret etmek ya da onu dismiss etmek, gerçekten dinleme ihtimalini ciddi biçimde düşürür
  • Karşımızdakinin işini beceremediğini ya da hayatını yanlış yaşadığını varsaymak da dinlemeyi engelleyen unsurlardandır

• 80 kişiyi 80 ayrı insan yerine tek bir grup olarak ele almak

  • B2B, B2C'ye kıyasla aslında daha da insani yönler taşır; ilişkiler, dinamikler ve organizasyon şemasının dışındaki soft power gibi unsurlar işler
  • Grup dinamikleri eklendiğinde, birey düzeyine kıyasla daha karmaşık değişkenler ortaya çıkar

Sabit gereksinimlerle yazılımın uyumsuzluğu

• İnsanların ve organizasyonların değiştiği gerçeği nedeniyle fixed project management, yazılım üretimine uygun değildir
• Gereksinimler başta netleştirilse bile bu sırada insanlar değişir ve ortaya çıkan ürün, en fazla başlangıç anındaki taleple örtüşür
• Yayınlandığı noktada artık istenen şey olmayabilir; ayrıca insanlar beklerken kendi beklentilerini eklediği için gerçeklik bunların hiçbiriyle tam olarak uyuşmaz

Sonuçlar ve etkiler

• İnsanların söylediklerini doğru dinleyememek, en değerli içgörülerin kaçırılmasına neden olur; bu da gelir fırsatlarının ve rekabet avantajının kaybına yol açar
• Yanlış anlamalar biriktikçe, ileride birlikte çalışılması gereken koda yeni unsurlar eklenir; bazı tech debt nedenlerini azaltmak da dinlemeyle bağlantılıdır
• Ne zaman dinlemediğimizi fark edebilirsek, daha iyi dinleme ihtimalimiz o kadar artar

[GN⁺]

Hacker News görüşleri

• Ben kelimeleri oldukça özenle seçen biriyim; belirli bir ifadeyi kullandıysam, gerçekten o anlamı kastetmişimdir. Ama bana göre birçok insan adeta bir ton şiiri gibi konuşuyor; eldeki sözcüklerin etrafında dolaşıp ortak bir nüansla anlaşılmayı bekliyor, bu yüzden yorumlamak başlı başına yorucu oluyor. Ben yazarken her kelimeyi bilinçli seçiyorum ama iş yerinde bile söylediklerim sanki muğlakmış gibi yorumlanması neredeyse sürekli tekrarlanan ve oldukça can sıkıcı bir şey. Spektrumda olabilirim ama hiç teşhis almadım. Yaklaşık altı ay önce başka bir ekibin uzun bir işe başlayabilmesi için küçük bir RPC yazıp dokümantasyonunu hazırladım; bir sayfadan kısa bir metindi ama eksiksiz, doğru ve özdü. Sonra yöneticim hiçbir gerekçe açıklamadan bu dokümanı AI'dan geçirip iletmiş, üstelik benim bundan haberim bile yokmuş. Bir günden kısa sürede saçma sapan geri bildirimler yağmaya başladı ve gerçek istek örneklerine bakınca endpoint tahrifatı yapıldığını gördüm. Yazım hatası falan değildi; tamamen uydurulmuş bir adres vardı, dokümandaki endpoint ve zorunlu parametrelerin hepsi yanlıştı, hatta var olmayan özellikler bile icat edilmişti. Normalde sabırlı biriyimdir ama o kadar öfkelendiğimi hatırlamıyorum, hâlâ da sinirliyim. İş piyasası böyle olmasaydı sanırım anında istifa ederdim. İnsanların kendilerinin okuyup yorumlaması gereken dili AI'ya bırakmak bana titiz dilin ölümü gibi geliyor ve üretken yapay zekânın uygarlığı çökerten bir Great Filter olup olmadığını aylardır ciddi ciddi düşünüyorum

  • Bu bakış açısı bana biraz yabancı geliyor. Konuşmanın düşüncenin sınırlarını kusursuzca kesip biçtiğini sanmıyorum; dil, dünyayı ve kişisel anlayışı ifade etmeye yarayan bir araç, bu yüzden benzer kavramları farklı kelimelerle anlatmak doğal. Düşünceden kelimeye döken kişiye daha net görünebilir ama dinleyen için öyle olmayabilir. Bu yüzden yorumlama emeğini hafife alamayız. Muhtemelen bu durumdaki karşı tarafla konuşsanız, onlar da sonunda sizin söylediklerinizi yorumlamanın zor olduğunu benzer şekilde söyleyecektir
  • Bu kurgu bana o kadar güçlü geldi ki aklıma hemen bir roman fikri geldi. Great Filter ile üretken yapay zekâyı birleştiren fikir çok iyi; sanki Cory Doctorow'un hemen yazması gereken bir hikâye gibi
  • Bence önce yöneticinin bu dokümanı neden AI'ya verdiğini sormak gerek. Bazen kesinlik arttıkça okunabilirlik düşer ve dil ne kadar sıkıştırılmışsa okur her kelime için o kadar büyük bilişsel maliyet öder. Okumak, yazarın zihnindeki modeli okurun modeline çevirmek demektir; kelimelerle otomatik dönüşüm olmaz, yorumlama eylemi gerekir. Fazla öz yazınca okura yardım eden dayanaklar kaybolabilir. Bir sayfalık doküman sıradan okur için anlaşılmayı desteklemeyecek kadar kısa olduğu için AI özeti gibi bir dolambaçlı yol seçilmiş olabileceğinden şüpheleniyorum. Okur için yazmak, bağlamı en yüksek okur için tutulan kesin notlardan tamamen farklı bir iştir; özellikle de belirsiz bir kitleye yazarken tekrar, kolay örnekler, tanıdık bağlam, adımların ayrıştırılması, hatta bazen mizah ve arka plan açıklamalarıyla anlamayı desteklemek gerekir
  • Ben de yakın zamanda benzer bir şey yaşadım. Dört sayfalık bir spesifikasyon yazdım ama alan kişi bunu okumak yerine bir LLM ile birkaç madde özeti çıkarmış, sonuçta gereksinimlerle uyuşmayan bir teklif geri geldi. Ben itiraz edince bunun aslında orijinal spesifikasyonda olması gerektiğini söyledi; oysa zaten vardı, sadece onun LLM summary çıktısında yoktu. Ben her kelimeye takılan biri değilim ama dört sayfalık bir dokümandaki bilginin 10 maddeye eksiksiz sığamayacağını düşünüyorum
  • Bana kalırsa bu tam olarak bunu normie speak'e çeviren özel bir prompt ya da özelleştirilmiş LLM kullanılması gereken bir örnek

• Sadece bu yorum bölümüne bakınca bile yazının işaret ettiği sorunu birebir yeniden üreten pek çok kişi görmek bana ironik geliyor. Buna birkaç şey daha eklemek istiyorum. Birincisi, ne kadar bilgi ve tartışma biriktirirseniz biriktirin, karşı taraf kabul etmek istemediği şeyi kolay kolay kabul etmez. İkincisi, gerçekten dinlemek zihinsel ve fiziksel olarak kendini savunmasız bir konuma koymaktır. Çünkü kendi deneyimlerinizle, inançlarınızla ve dünya görüşünüzle çatışan şeyler duyabilirsiniz; insanları yargılama tavrı çoğu zaman bir özsavunma mekanizmasıdır ve bu yüzden aslında iyi dinlemeyi engeller. Üçüncüsü, dinlemek çoğu zaman hemen çözüme atlamamak, karşı tarafın acılarını içine alıp işlemektir. Örneğin bir Product manager bunu hemen yeni özellik ya da ticket'a indirgemeye çok yatkın olabilir ama aslında kullanım senaryosunu dinleyip acı noktalarını bulup çözmek gerekir; kullanıcının istediği özelliğin adını anlamaya çalışmak yetmez

  • Bu önermeyi baştan varsayım olarak kabul etmek bana tehlikeli geliyor. Çoğu işte pazarlık payı vardır ve doğru pazarlık etmeyi bilirseniz işler değişebilir
  • Özellikle 2. madde bana çok derin geldi. Bunu değer verdiğim birine mutlaka göndermek istiyorum ve onun da gerçekten listen etmesini umuyorum
  • Dinlemenin savunmasızlaşmak olduğu fikrine katılıyorum ama bu savunmasızlığın her seferinde istismar edilmeyeceği garanti edilse, seve seve zaman ayırıp her zaman gerçekten dinlemek isterdim
  • Gerçekten merak ettiğim şey şu: Başkasının acısını içine almak pratikte ne demek ve oradan özellik tanımına ya da ticket yazımına nasıl doğal biçimde geçiliyor?
  • Bu açıklama bana tam olarak presales discovery işinin özünü anlatıyor gibi geliyor. Gerçekten teknikten çok sanata yakın bir alan

• Sorun tespitine katılıyorum ama bu liste biraz yakınma gibi geldi. Etkili iletişim neredeyse tüm insanlık için temel bir mesele ve yazı, geliştiricileri dinleyememekle azarlıyormuş gibi bir ton taşıdığı için biraz tepeden bakan geldi. Asıl sorun, insanların ne bilmediklerini bilmemesi. En iyi iletişimciler çevirmen gibidir; insanlar ancak mesaj kendi anlayışları içinde apaçık hâle geldiğinde gerçekten duyar. Bunun herkesin kulağını kapatmış çocuk gibi davranmasından kaynaklanan basit bir çöküş olduğunu düşünmüyorum. Bu yüzden sistemlere ve mühendisliğe yöneliyoruz; sistemlerin boşluk tespiti ve çeviri çerçevelerini içine almasını istiyoruz. Mükemmel olmayabilir ama insanlara daha iyi dinlemeleri gerektiğini vaaz etmektense ekip, şirket ve sistem düzeyinde ortamı değiştirmek daha önemli

  • Bu bana bir zamanlar yaşlı birinin bunu bir Noisy system olarak görmem gerektiğini söylemesini hatırlattı. Sinyal her zaman gürültüden daha zayıftır ve bu sistemin içinde sınırları olan insanlar vardır. Herkesin yapabileceklerinin bir üst sınırı var, insanların zihinsel modellerinin güncellenme hızının da sınırları var ve grubun sınırı bireyinkinden bile daha düşük. Özellikle büyük organizasyonlar, gerçeklik tamamen değişse bile mevcut modeli değiştirmek için onlarca yıl harcayabilir. Bu yüzden bu kısıtları kabul edip zamanımı ve enerjimi nereye harcayacağıma karar vermenin önemli olduğunu düşünüyorum
  • Bu yazı bana sadece sıradan bir self-help yazısı gibi geldi, hatta örnekleri de az olduğu için ondan biraz daha zayıf buldum
  • Ben bir geliştiriciyim ama başka işler de epey yaptım; bu yüzden iletişimin önemini ve geliştiricilerin burada ne kadar sık zayıf kaldığını iyi biliyorum. Yaygın örüntü şu: geliştiriciler kötü doktorlar gibi davranıp dinliyormuş gibi yapıyor ama çok erken teşhis koyuyor. Karşı taraf önemli olan her şeyi daha söylemeden neye ihtiyaç duyduğunu bildiklerini ilan ediyorlar. Yazılımda, müşterinin istediğinden daha önemli olan şey çoğu zaman müşterinin gerçekten ihtiyaç duyduğu şey oluyor. Müşterilerin çok azı sorununu yazılımla zarif biçimde çözmenin yolunu bilir; genelde fikirle gelen kişi yazılımı derinlemesine hiç düşünmemiş biridir. Bu, fikrin değersiz olduğu anlamına gelmez ama gereksinimleri netleştirme ve çözüm çıkarma işinin daha bitmediği anlamına gelir. Bunu tamamlamanın yolu gözlem, açıklama ve diyalogdur. Benim deneyimime göre birçok geliştirici gerçekten iyi dinlemiyor; doktorlar ve başka teknik meslekler de benzer. Ne kadar bilgili olduklarını gösterip hızla yetkin görünmek istiyorlar ve karşı tarafı zaten daha önce çok gördükleri bir problem türüne yerleştiriyorlar. Bazen işe yarıyor ama işlemediği an mutlaka geliyor
  • Şaka yollu söylemek gerekirse, iletişim gerçekten insanlığın merkezî sorunuysa Bible'da bununla ilgili bir ayet falan olması gerekmez miydi diye düşünüyorum

• İnsanların söyledikleriyle gerçekten düşündüklerinin aynı olduğunu kolayca varsaymamak gerekir. Tersine, konuşan kişi de dinleyenin aynı şeyi hayal ederek anladığını sanma hatasına düşebilir. Bu yüzden olabildiğince ayrıntılı ve muğlaklıktan uzak yazmak önemlidir. Bir toplantıda biri hedefi altı kelimelik bir maddeyle açıklamaya çalışıyorsa, bu bana fiilen kimsenin hedefi anlamadığı sinyalini veriyor. Bir sayfalık doküman bile olmadan toplantıya geliyorsa, o kişi de muhtemelen konuyu henüz yeterince anlamamıştır; eğer benim ilerlemem o çıktıya bağlıysa daha net bir resim talep etmem gerekir

  • İş arkadaşlarıma günde birkaç kez about what? diye tekrar tekrar sormam gereken durumlar sık oluyor. Hangi müşteri, hangi özellik, hangi ürün olduğunu net söyleyene kadar bazen 4-5 kez yeniden soruyorum. Hatta ne demek istediklerini zaten tam olarak bildiğim durumlarda bile bunu yapmak zorunda kalabiliyorum
  • Gereksinimlerin meşruiyetini de mutlaka sorgulamak gerekir diye düşünüyorum. Çünkü gerçek ihtiyacı bilmemeyi gizlemenin en kolay yolu aşırı talep oluşturmaktır. Benim deneyimimde ihtiyaç duyulanın 10 katını istemek çok yaygın; hatta geçmişte 500 kat maliyet farkı olan seçenekler arasında, geleceği dert etmemek için en üst düzeyi almak gerektiğini söyleyen biri bile oldu
  • Ayrıntılı ve muğlak olmayan yazmanın derin karşılıklı anlayış için önkoşul olabileceğini kabul ediyorum ama son birkaç yılda insanlar mesajların, ticket'ların ya da e-postaların ilk cümlesinden sonrasını gerçekten çok az okuyor gibi geliyor. Bu yüzden bilgiyi çok küçük parçalara bölüp adeta kaşıkla vermek zorunda kalıyoruz ve bundan hiç hoşlanmıyorum
  • Bunun gerçek hayatta çok sık yaşandığını düşünüyorum. Ben production için hazır değil dediğimde, yöneticiler bunu müşteriye acceptance testing diye satabiliriz anlamında duyuyor olabiliyor
  • Burada aklıma birden Sovyet dönemi filmi Kin-dza-dza geldi. Orada bir karakter bir başkası için, düşünmediği şeyleri söylüyor ve düşünmediği şeyleri düşünüyor gibi bir ifade kullanıyordu; bu konuşmalardaki karmaşayı anlatmak için epey uygun geliyor

• Ben çoğunlukla müşteri ilişkileri tarafında çalışıyorum ve en önemli işin müşterinin beklentilerini hizalamak olduğunu düşünüyorum. Neyin mümkün olduğu, ne kadar süreceği, neye mal olacağı, ne zaman production'a alınabileceği gibi konuları müşteri beklentileriyle uyumlu hâle getirirseniz; başlangıç tarihi ya da maliyet hoşlarına gitmese bile sonunda mutlu müşteri elde edersiniz. Özellikle maliyet çoğu zaman anlaşmayı bozan unsur olduğu için kabaca hangi aralıkta olacağını baştan hizalamaya çalışıyorum. Ne kadar iyi dinleyip empati kursanız da gerçekler gerçektir ve müşterinin de bu kısıtları kabul etmesi gerekir. Müşterinin istediği her şeye sadece baş sallayan müşteri temsilcisi sonunda müşteriyi daha mutsuz eder; iyi bir arayüz görevi gören kişi ise hem müşteriyi hem iç ekibi dinleyip gerçekten teslim edilebilir olanla müşteri beklentisini uyumlu hâle getirir

• Belki de iletişime gereğinden fazla zaman harcıyoruzdur diye düşünüyorum. Çok fazla zaman ayrıldığında odak dağılıyor ve nasıl olsa bir dahaki sefere netleştiririz diye erteleme eğilimi doğuyor. Gereksiz toplantıları azaltıp sadece minimum viable time ayırsak, belki herkes daha iyi dinler

  • Ben bu olguyu pratikte neredeyse hiç görmedim. Çoğu toplantı aslında iletişim değil, daha çok talimat ve duyuru; dinleme becerisi ise toplantının uzunluğundan bağımsız ayrı bir yetenek. Dinlemek pratikle gelişen bir beceri, toplantı süresini azaltınca kendiliğinden ortaya çıkmıyor
  • Sonucu bir sonraki toplantıyı planlamak olan çok fazla toplantıya girdim. Hatta daha fazla insanı dahil eden, kalabalık ekiplerin kararları kendi tarafına çekerek politik etki kazandığı ve bunun da daha fazla gereksiz işe alım ve toplantıya yol açtığı örüntüler de gördüm. Çıkış yolunun iletişimi artırmak değil, tek bir vizyon kurmak ve ekipler arası bağımlılıkları azaltarak her ekibin bağımsız çalışmasını sağlamak olduğunu düşünüyorum
  • Yazılım mimarisi işi yaparken bir diyagramın 60 dakikadan fazla tartışmayı ve birden fazla toplantıyı kurtardığını çok gördüm. Çok iyi çizilmemiş olsa bile gerçeğe sadık bir çizim yeterliydi; karmaşık ya da kendiliğinden anlaşılmayan mantıklar sözden çok diagram ile daha net oluyordu. Uzaktan toplantıysa Ai agent ve Mermaid.js ile hızlıca çizilebilir, yüz yüzeyse beyaz tahta ya da kâğıt kalem yeter
  • İletişime zaman harcamak ile gerçekten iletişim kurmak tamamen farklı şeyler gibi geliyor
  • Bence asıl sorun iletişime çok zaman harcamamız değil, iletişim kuruyormuş gibi yapmaya çok zaman harcamamız. Yeterli katılım bile olmayan toplantıları zorla açıyorlar, hiçbir önkoşul olmadan ilerliyorlar, düşünmeden üretilmiş AI slop document bırakıyorlar ve insanlar anlamayınca da sanki okuyanlar aptalmış gibi davranıyorlar. Toplantının ilk 30 dakikası neredeyse gaslighting gibi geçiyor, son 10 dakikada ise bunun zaman kaybı olduğu kabul edilip toparlanmaya çalışılıyor. Oysa toplantının amacı olgunlaşmış düşünceleri ve tutarlı yönü paylaşmak, net iddialara anlamlı geri bildirim almaktır; pratikte ise çoğu zaman birinin kendi işini stone soup usulü bir grup projesine çevirme girişimini herkes birlikte yönetmek zorunda kalıyor. Başta bu toplantının amacının ne olduğunu sorarsanız, ev sahibinin aslında sadece bir çalışma grubu açmış olduğu ortaya çıkabiliyor. Yüksek seviyeden bakan yöneticiler işin toplantılarda yapıldığını sanıyor ama iyi toplantıdan önce gereken düşünme emeğini göremiyor. Düşünce netleşmeden iletişimi zorlamak, toplantıyı sadece gürültüye çeviriyor. Böyle durumlarda en güçlü tepki haydi şimdi birlikte öğrenelim tavrı ve ben Why, What, How, Who, When sırasındaki bağımlılıkların korunmasını sağlıyorum. Ön tarafta boşluk varsa sonraki adıma geçilmiyor; ister stajyer olsun ister VP, kolay geçiştirmeye izin vermiyorum. Sorunu parçalayıp yerinde düşünmeye rağmen ekip değişmiyorsa, sonunda başka bir ekip aramak gerekebiliyor

• Bu yazıdaki specialism effect tespiti bana epey küçümsenmiş geliyor. Ben de kullanıcıların benim yıllar içinde içselleştirdiğim şeyleri anlamamasına sinirlendiğim oldu ama kısa sürede sorunun onların bilgisiz olması değil, birikimlerinin başka yerde yoğunlaşmış olması olduğunu fark ettim. Aynı zamanı sadece bambaşka şeyleri derinlemesine öğrenerek geçirmişler

• Sorunun temel nedeninin insanların konuşmaması ve dinlememesi olduğu açıklamasına tamamen katılmıyorum. Bir çizgi roman benzetmesi yaparsam, birçok insan en başından beri yolun kendisinden çok kurdele kesme törenini istiyordu ve sonunda da onu aldığı için bunlar oluyor diye düşünüyorum

• İnsanların kendilerinin tam olarak söyledikleri şeyi kastettiklerini iddia edip pratikte hiç de öyle davranmamalarıyla ilgili epey komik deneyimlerim oldu. Birinin dediğini neredeyse aynı kelimelerle yeniden ifade edip anladığımı kontrol ettim ve aldığım karşılık, bunun kesinlikle kastettiği şey olmadığına dair çok güçlü bir inkâr oldu

• Teknik olmayan kişilerle konuşurken çıkan birçok sorunun merkezinde, onların maliyet bağlamı olmadan sadece X'i ekleyelim, Y'yi değiştirelim demesi olduğunu düşünüyorum. Elbette istenenlerin çoğu yapılabilir ama her talebin bir maliyeti var; bu anlaşılmadığında güvenilir ürün çıkışıyla bunu bağdaştırmak zorlaşıyor

  • Bu yanıt bana aslında yazının ana fikrini doğrudan gösteriyor gibi geliyor. Sorun onların maliyeti anlamaması değil, sadece bağlamlarının farklı olması; teknik kişinin görevi de insanların maliyeti önceden bilmesini beklemek değil, onların bilgiye dayalı tradeoff yapmasına yardımcı olmak
  • Bu durumda neden gerektiğini soran whys soruları önemli geliyor. Teknik olmayan süreci anlayınca belki de o ekleme ya da değişiklik aslında hiç gerekmiyor olabilir. Her şeyi eklerseniz sonunda Turing complete Excel/Email clone gibi bir canavar çıktığına da katılıyorum
  • Bu gibi durumlarda bence asimetri şu: teknik olmayan taraf maliyeti bilmiyor, teknik taraf ise faydayı bilmiyor. Sonuçta iki tarafın da iletişim kurması gerekiyor ki makul maliyet-fayda dengesi bulunsun
  • Bana bu oldukça çözülebilir bir sorun gibi geliyor. Her talep için kaç ay süreceğini ve ne kadara mal olacağını ay ve dolar cinsinden tahmin edip söylemek yeterli
  • Ama bugünlerde AI'nın code thing işini üstlenmesiyle uygulama maliyetinin gerçekten epey düştüğü de bir gerçek gibi geliyor. İster sevin ister nefret edin, bu değişimi kabul etmek gerek