İlk soruya cevap verme

 (lalitm.com)
1 puan yazan GN⁺ 3 시간 전 | 1 yorum | WhatsApp'ta paylaş
  • Performans hata ayıklama araçlarında, tuhaf görünen isteklere hemen cevap vermek yerine arka planı sormak gerekir; böylece kullanıcının gerçek sorunu ve aracın boşlukları ortaya çıkar
  • Bu yaklaşım, basit bir XY problemi müdahalesinin ötesine geçer; yanlış sorunun ortaya çıkmasına yol açan karmaşayı başlangıç noktası alarak hem kullanıcı hem ürün tarafındaki anlayışı geliştirir
  • Perfetto'da tüm metrik hesaplamaları için trace kullanmak teknik olarak mümkün olsa da verimsizdir; özel bir metrik toplama sistemi daha uygun olabilir
  • Trace bölme isteğinde olduğu gibi, görünen cevap ile gerçek ihtiyaç farklı olduğunda periodic trace snapshots gibi mevcut özellikler daha iyi bir yol olabilir
  • Ürün değişikliklerini, tekrar eden ihtiyaç yeterince netleştiğinde yapmak daha iyidir; aceleyle eklenen özellikler büyük teknik borca yol açabilir

İlk soruya neden hemen cevap vermemeli

  • Perfetto gibi performans hata ayıklama araçlarında kullanıcı “Perfetto trace'i birden fazla dosyaya nasıl bölerim?” gibi tuhaf görünen bir soru sorduğunda, hemen yöntemi anlatmak yerine önce “Bu kadar büyük bir trace toplamanızın nedeni ne?” diye sormak gerekir
  • Bu yaklaşım, basit bir XY problemi çözümünün bir adım ötesine geçer
    • Kullanıcının sorusunu “gerçek niyete” çevirip cevaplayarak bitirmekle kalmaz, yanlış sorunun ortaya çıkmasına yol açan karmaşanın kendisini sohbetin başlangıç noktası yapar
    • Kullanıcı araç hakkında daha iyi bir zihinsel model edinir, aracı yapan taraf ise ürünün nerede kafa karıştırdığını daha net görür
    • Sohbetin sonunda ürünün kendisinin değişmesi gerektiği sonucuna da varılabilir
  • Bu yöntem özellikle mühendisler için araç geliştirenler açısından doğrudan uygulanabilir
    • Tüketici ürünlerine veya B2B hizmetlerine daha az doğrudan aktarılabilir, ama temel yaklaşım yine de faydalı olabilir

İsteği teşhis etme biçimi

  • Her soru derin bir konuşma gerektirmez
    • Sadece dokümantasyona yönlendirilerek çözülebilecek basit ve tekrarlayan sorular ayrı bir tartışma konusu değildir
    • İlginç durum, ilk isteğin tek başına bağlam vermediği ve sorunun kendisinin alışılmadık göründüğü zamandır
  • Tuhaf sorularda, şu ölçütlere göre uyumsuzluk aranır
    • Daha önce görülmüş bir soru olup olmadığına bakılır; değilse nadir bir istek olarak değerlendirilir ve tempo düşürülür
    • Diğer sorularla kıyaslandığında makul olup olmadığı incelenir; değilse altında daha genel bir soru olup olmadığı araştırılır
    • Aracın yapısıyla uyumlu bir istek olup olmadığına, kullanıcının farkında olmadan mimariyle kavga edip etmediğine bakılır
  • Uyumsuzluk noktası bulunduktan sonra, eksik bağlamı ortaya çıkaracak sorular sorulur
    • Doğrudan cevap X olsa da, Y nedeni yüzünden bunun oldukça tuhaf bir istek gibi göründüğü ve daha geniş sorunun anlatılmasının istendiği türden bir konuşma başlatılır
    • Sonraki hız, kullanıcının düşüncesini ne kadar iyi aktarabildiğine göre değişir
  • Konuşma genelde üç sonuçtan birine varır
    • Kullanıcı aracın felsefesini kaçırmıştır
    • Doğru yol ürünün içindedir ama görünür değildir
    • Ürünün kendisinin değişmesi gerekir

Aracın felsefesinin kaçırıldığı durumlar

  • Kullanıcıların, ne istediklerini veya hangi sorunu çözmeye çalıştıklarını tam bilmeden araca yönelmesi yaygındır
    • Bu, kullanıcıyı eleştirmek anlamına gelmez
    • Ekipler sınırlı zaman ve kaynaklarla bir sorunu çözmeye çalışırken ilerleme kaydedemediğinde yeni hata ayıklama araçları arar
    • Araç istenen işlevlerin önemli bir kısmını sağlasa bile, kullanıcının “bunun böyle çalışması gerekir” modeliyle uyuşmuyorsa özellik talebine dönüşür
  • Perfetto'da yaygın bir örnek, trace'i tüm metrik hesaplamaları için her derde deva bir çözüm gibi görmektir
    • Perfetto trace, belirli bir zaman aralığında cihazın yaptığı işleri çok ayrıntılı biçimde kaydeder
    • Trace'ten metrik hesaplanabildiği için kullanıcılar kare hızı, uygulama bellek kullanımı gibi değerleri de trace'ten hesaplamaya çalışır
    • İlke olarak herhangi bir metrik trace'ten hesaplanabilir
  • Ancak tüm metrikleri trace ile hesaplamak verimsizdir
    • Trace toplama ve işleme maliyeti yüksektir
    • Yalnızca tek bir sayı gerekse bile tüm sistem verisi toplanmış olur
    • Özel bir metrik toplama sistemi aynı işi çok daha verimli yapabilir
  • Araçların bir tasarım felsefesi vardır ve kullanıcılar anlık soruna odaklandıkları için bunu kolayca gözden kaçırır
    • Önemli olan yalnızca Perfetto'nun nasıl kullanılacağını öğretmek değil, performans mühendisliğine nasıl yaklaşılacağını da öğretmektir
    • Başlangıç süresi, frame drop, bellek, güç gibi konuların nasıl düşünülüp ele alınacağını göstermek gerekir
    • Hem normal durumda hem sorun yaşanan durumda hangi aracın nasıl kullanılacağını anlamalarını sağlamak gerekir

Doğru yolun gizli olduğu durumlar

  • Bazen kullanıcı sorunun kendisini anlamıştır ama mevcut araçları nasıl birleştireceğini bilmiyordur
    • Araçlar bilinçli olarak güçlü tasarlanmıştır ve başka ekiplerin tüm işlev yelpazesini tamamen anlaması beklenemez
    • Gerçek ihtiyaç anlaşıldığında, başka amaçlarla yapılmış özelliklerin kullanıcının ihtiyacını karşıladığı sık görülür
  • Trace bölme isteği bunun tipik örneğidir
    • Kullanıcı, uzun bir trace içinde ilgilendiği bir bölüm olduğunu ve bunu kesip ayırmak istediğini söyler
    • Gerekçesi performansı ve görselleştirmeyi kolaylaştırmaktır
    • Ancak bu durumda baştan uzun trace toplamamak daha uygun olabilir
  • Perfetto'da zaten periodic trace snapshots vardır
    • Tek bir uzun kayıt yerine kısa kayıtları tekrar tekrar alma özelliğidir
    • Uzun bir trace topladıktan sonra bunu bölme ihtiyacını ortadan kaldırır
  • Kullanıcının sorduğu cevap ile gerçekten ihtiyaç duyduğu cevap farklı olabilir
    • “Tam olarak ihtiyacım olan şey buydu” tepkisi, kullanıcının düşündüğü isteğin değil gerçek ihtiyacın bulunduğunun işaretidir

Ürünün değişmesi gereken durumlar

  • Bazı yanıtlar, üründe büyük değişikliklere yol açabilecek yeni ihtiyaçları ortaya çıkarır
    • Bu durumlar zordur
    • İstek yeni olsa bile, istekte bulunan kişi gerçekte neye ihtiyaç duyduğunu net biçimde ifade edemeyebilir
  • Altyapı yazılımlarında yanlış karar vermenin maliyeti yüksektir
    • Bu yüzden eksik olan şeyi gerçekten can yakana kadar yapmamayı tercih etmek daha iyidir
    • Birden fazla ekip aynı ihtiyacı dillendirmeye başladığında, gerçekten yapılmaya değer çekirdeğin görünür hale gelmesi daha olasıdır
    • Tek bir istekten bu çekirdeği çıkarmak çok zor olduğundan, beklemek güçlü bir yöntemdir
  • Perfetto'nun geçici UI özelleştirmesi, yanlış kararın bir örneğidir
    • İnsanlar iş akışlarına uyacak şekilde UI'ı hacklemek istiyordu ve bunun zor olduğundan sürekli şikayet ediyordu
    • Buna izin verilir verilmez büyük miktarda teknik borç oluştu
    • Her yeni özellik, mevcut tüm özelliklerle etkileşmek zorundaydı ve genel yapı hızla ölçeklenemez hale geldi
    • Bu sorundan çıkmak için doğru bir plugin API tasarlamak yaklaşık 1 yıl sürdü
  • Gerçek ihtiyaç, “tüm kullanıcılara etki etmeden UI'ı ekip veya kullanım senaryosuna göre kişiselleştirmenin bir yolu” idi
    • Bu ihtiyaç baştan net biçimde ifade edilmemişti
    • Bunu istek akışı içinde erken yakalama sorumluluğu ürünü yapan taraftaydı
  • Perfetto trace'leri merge edebilme özelliği ise iyi yönetilmiş bir örnektir
    • İnsanlar bunu sürekli istedi ama hemen yapılmadı
    • Geçici çözümler gösterildi ve durum izlenmeye devam edildi
    • Doğru uygulanması için iş yükü büyük ve yanlış tasarlanması kolay bir özellik olduğu biliniyordu
    • Sorun alanı yeterince anlaşıldıktan sonra geçen yıl sürdürülebilir bir şekilde uygulandı

Temel ders

  • İlk soru çoğu zaman gerçek soru değildir
    • Cevap vermeden önce neden böyle bir soru sorulduğunu sormak gerekir
    • Bazen kullanıcı aracı nasıl kullanması gerektiğini öğrenir
    • Bazen ürün içindeki doğru yolun gizli olduğu ortaya çıkar
    • Bazen henüz yapılmaya değer bir şey olmadığı sonucuna varılır
    • Bazen de bir sonraki büyük özelliği iki kez değil, tek seferde doğru yapmaya hazır hale gelinir
  • Basit ama kolayca atlanan bir tekniktir
    • Hızlı yanıt verme baskısı her zaman vardır
    • Hızlı cevaplar her seferinde üretken hissettirir
    • Yine de bir adım geri atıldığında, her iki tarafın da başlangıca göre daha fazlasını kazandığı durumlar neredeyse her zaman daha fazladır

İlgili okumalar

1 yorum

 
GN⁺ 3 시간 전
Lobste.rs görüşleri

  • Yazar bunun XY probleminden çok daha ileri gittiğini söylüyor ama bana daha çok XY probleminin nasıl ele alınacağını ilginç içgörülerle ayrıntılı biçimde açıklayan bir yazı gibi geldi

    • Bunun aslında XY problemi hakkında bir yazı olduğunu düşünmüyorum. XY probleminden çok daha geniş uygulanabiliyor ve cevap veren tarafın “bu bir XY problemi” diye varsayması kadar tehlikeli de değil
      Soruyu XY problemi olarak çerçevelemek, XY problemi gibi görünen sorulara cevap verirken insanların kullandığı ters etki yaratan sezgisel yaklaşımlara geri dönme ihtimalini artırıyor
      Tavsiye istemeye çalışırken etrafımdaki insanların benim bir XY problemi yaşadığımı varsayıp, yazdıklarımı gerçekten okuyacak birine ulaşana kadar durmadan açıklama yapmak zorunda kaldığım sayısız durum oldu. Programlama kültürünün XY problemine verdiği tepkinin yanlış kalibre edilmiş olduğunu hissediyorum ve bu yazı da o aşırı düzeltmeye bir itiraz gibi okunuyor
      Soru soranın benden çok daha az şey bildiğini hissetsen bile yavaşlamak ve örüntü eşleştirmeye gitmemek önemli. Zaten bunun XY problemi olma ihtimali ezici biçimde yüksek değil; öyle olsa bile değilmiş gibi ele almak daha iyi olabilir

  • Güzel bir yazıydı. Bana bunun madalyonun öteki yüzü olan şu durumu hatırlattı: size sorulan şeyi daha basit bir soruya çevirip ona cevap vermemeye dikkat etmek gerekir
    Mesela “Amsterdam ile San Francisco arasındaki mesafe ne kadar?” sorusuna “Uçakla 12 saat sürüyor” diye cevap vermek gibi
    Soru mesafe hakkındaydı ama mesafeyi bilmek zor, uçuş süresini düşünmek ise daha kolay olduğu için cevap veren kişi soruyu daha kolay bir soruya çevirip onu cevaplamış oluyor
    Bu epey sık görülüyor ve özellikle soru soranla cevap veren arasında güç mesafesi olduğunda daha da yaygın gibi görünüyor

  • Çeşitli nedenlerle sistemi modernize ederken ingress router'a bir 404 sayfası ekledik ve bu sorun çıkardı. Bir geliştirici eski 404 davranışını geri istedi, çünkü eski sayfada gezinme çubuğu ve menü vardı
    Biraz daha kurcalayınca bazı müşteri yapılandırmalarında giriş yaparken her zaman 404 alındığı ve müşterilerin eski 404 sayfasını kullanarak aslında gitmeleri gereken yere ulaştıkları ortaya çıktı
    lolcry'ı böyle anlar için icat ettim 🤣😭

    • > GET /hyrums-law HTTP/1.1  
> Host: ingress.customer.doctor_eval.work  
>  
< HTTP/1.1 404 Not Found  
< Content-Type: text/plain  
<  
< Yeterince çok API kullanıcınız olduğunda,  
< sözleşmede ne vaat edildiği önemli olmaz:  
< sistemde gözlemlenebilen her davranış  
< birileri tarafından bağımlılık haline getirilir.  
<

  • @lalitm, bu sorun internetten daha eski ve zaten bir adı da var: gereksinim analizi
    Ed Yourdon ve diğerleri, kullanıcının elde etmek istediği sonuç olan süreç ile o sonuca ulaşma yöntemi olan prosedürü ayırıyordu. Örneğin müşteriye siparişinin gönderildiğini bildirmek bir süreçtir; bu bilgiyi e-postayla göndermek ise prosedürdür
    Sistem kullanıcıları çözümü, sistemin bir özelliği gibi düşünme eğilimindedir. Programcılar da istisna değil; bu yüzden “X içinde Y'yi çözmek” türünün çok varyasyonu var. Analistin işi, belirli bir uygulama biçiminden gereksinimleri çıkarmaktır; mühendis olarak bundan sonra çözümü uygulayabilirsiniz
    Kısa süre önce syslog(3) geride kaldığında olaylar logdan kaybolduğu için loglamayı hızlandıralım tartışmasına katıldım. Ama asıl sorun daha hızlı loglama değildi. Kullanıcılar daha hızlı loglama istemiyor; sorunlarının çözülmesini istiyor. Gerekli bilgiyi sağlamak süreçtir, her şeyi loga yazmak ise bunun yollarından yalnızca biridir
    Yourdon, CASE araçlarını savunan kişilerden biriydi. Yönetim kaliteyi ve üretkenliği ölçebilseydi belki başarılı olurdu ama bu başka bir günün yakınması

  • “Yanlış soruyu doğuran kafa karışıklığının kendisi bir fırsattır” deniyor ama o alanın en üst düzey uzmanı değilseniz hangi sorunun yanlış olduğunu en baştan yargılamak oldukça zor

    • Evet. Üstelik bir kurumun kendine özgü hangi koşullarının böyle “yanlış” bir soruya yol açtığını anlamak için zaman harcamak bazen kimseye fayda sağlamıyor

  • Aslında cevap vermek gerekir
    Değerli zihinsel kaynakları koruyan bir kapı bekçisi rolünde değilseniz, doğaçlama tiyatro taktiği gibi “evet, ve…” yaklaşımıyla ilerleyebilirsiniz. Elbette istenen sonuca ulaşmanın başka yolları da olabileceğini ekleyebilirsiniz
    Tıkanmış bir durumu açmak için tek bir strateji kullanmak yerine, mümkün olan bütün stratejileri kullanmak daha iyidir

    • Bu ifade çok hoş. Mesajın karışabileceği sayısız yol var ve sorunun kökünü bulmaya yardımcı olmak için birden fazla yaklaşım gerekiyor. Ayrıca kafa karışıklığı yaşayan tarafın her zaman karşı taraf olduğu da söylenemez