En İyi Mühendisler Sizin Bilmediğiniz Neyi Biliyor?

Birçok kişi güçlü mühendisliğin daha fazla araç bilmekten, daha fazla kod yazmaktan veya zor denklemleri daha hızlı çözmekten kaynaklandığını düşünüyor. Deneyimlerim bana, çözümü geliştirmeden önce doğru sorunu seçmek daha zor beceri olduğunu söylüyor. Bir sistem hızlı olabilir ve yine de başarısız olabilir. Bir ürün gösterişli görünebilir ve yine de kullanıcıları hayal kırıklığına uğratabilir. Bir tasarım bir testi geçebilir ve koşullar değiştiğinde yine de bozulabilir. Deneyimli mühendisler başkalarının gözden kaçırabileceği neyi anlıyor? Teknik kararları kullanıcı ihtiyaçları, sistem sınırları, ekip iletişimi ve uzun vadeli bakımla ilişkilendirmeyi öğrenirler. Mühendisliği daha fazla çıktı üretme yarışı olarak görmüyorlar. Bunu riski azaltmanın ve faydalı sonuçlar yaratmanın bir yolu olarak görüyorlar. Aracı seçmeden önce sorunu tanımlarlar Bir proje belirsiz göründüğünde basit bir soruyla başlarım: "Hangi sorunu çözmeye çalışıyoruz?" Bu soru birçok zayıf kararı engeller. Bir ekip yeni bir mobil uygulama isteyebilir ancak asıl sorun yavaş bir onay sürecidir. Bir yönetici bir kontrol paneli talep edebilirken çalışanların yalnızca güvenilir bir haftalık rapora ihtiyacı vardır. Şunu yazıyorum: - Sorun kimde? - Sorun devam ederse ne olur? - Bugün insanlar bununla nasıl başa çıkıyor? - Hangi sonuç çözümün yardımcı olduğunu gösterir? - Ekibin hangi sınırlara uyması gerekiyor? Bu işlem uzun bir belgeye ihtiyaç duymaz. Kısa bir sorun bildirimi haftalarca süren çalışmalara rehberlik edebilir. Örneğin küçük bir teslimat şirketi rota planlamak için yapay zekaya ihtiyaç duyduğuna inanabilir. Ekip, sürecini inceledikten sonra sürücülerin eksik adres bilgileri aldığını keşfedebilir. Veri girişini iyileştirmek, karmaşık bir tahmin sistemi eklemekten daha fazla değer getirebilir. İyi mühendislik genellikle kafa karışıklığının giderilmesiyle başlar. Basit tasarımlara saygıyla yaklaşırlar Her yeni özellik başka bir mantık katmanı eklediğinden çoğu sistemin bakımı zorlaşır. Orijinal ekip tasarımı anlayabilir, ancak yeni bir mühendis yeni hatalar yaratmadan küçük bir parçayı değiştirmek için çabalayabilir. İhtiyaca cevap verebilecek basit yapıları tercih ediyorum. Basit, dikkatsiz anlamına gelmez. Bu, her bir parçanın net bir işi olduğu, veri akışının takip edilmesinin kolay olduğu ve ekibin ana seçenekleri açıklayabildiği anlamına gelir. Basit bir tasarım şunları içerebilir: - Açık sorumluluklara sahip küçük modüller - Amacı açıklayan adlar - Birkaç gizli bağımlılık - Kısa bir kurulum süreci - Temel davranış testleri - Gelecekteki ekiplerin kafasını karıştırabilecek kararlar için yazılı notlar Kısa bir işlev her zaman uzun bir işlevden daha iyi değildir. Yararlı soru, başka bir mühendisin bunu anlayıp makul bir çabayla değiştirip değiştiremeyeceğidir. Varsayımları erken test ederler Bir plan genellikle kullanıcılar, trafik, donanım, maliyet ve yanıt süresi hakkında tahminler içerir. Tahminler gizli kaldığında sorunlar ortaya çıkar. Her büyük varsayımı küçük bir teste dönüştürmeyi seviyorum. Bir ekip, kullanıcıların bir formu iki dakika içinde dolduracağına inanıyorsa, birkaç kişinin onu kullandığını gözlemleyin. Bir hizmetin dakikada on bin isteği işlemesi bekleniyorsa, başlatmadan önce bu yükün güvenli bir sürümünü test edin. Bir sensörün soğuk bir ortamda çalışması gerekiyorsa onu ofis dışında test edin. Testin mükemmel olmasına gerek yok. Yararlı bilgiler üretmesi gerekiyor. Bu yaklaşım, NASA'daki mühendislerin uzay görevleri sırasında bazı belirsizliklerden kaçınmasına yardımcı oldu, ancak ünlü bir başarısızlık, temel bir varsayımın gözden kaçırılması durumunda neler olabileceğini gösterdi. Mars Climate Orbiter, yazılım ekiplerinin farklı ölçü birimleri kullanmasının ardından 1999 yılında kaybedildi. Bir grup pound-kuvvet saniyeleri ile çalışırken, bir diğeri Newton saniyeleri bekliyordu. Uzay aracı Mars çevresinde yanlış yola girdi. Çıkarılacak ders, her projenin daha fazla toplantıya ihtiyaç duyması değildir. Buradan alınacak ders, ekiplerin değerler, formatlar, birimler ve sınırlar için ortak tanımlara ihtiyaç duymasıdır. Başarısızlık için tasarlarlar Bir sistem her parçanın mükemmel çalışmasına bağlı olmamalıdır. Ağların bağlantısı kesilir. Piller gücünü kaybeder. İnsanlar yanlış bilgi giriyor. Sunucular aşırı yükleniyor. Tedarikçi bir bileşeni değiştiriyor. Soruyorum: - Bu hizmet durursa ne olur? - Kullanıcı güvenli bir şekilde tekrar deneyebilir mi? - Sistem veri kaybedecek mi? - Ekip sorunu görebiliyor mu? - Acil durumlar için manuel bir süreç var mı? Örneğin bir ödeme hizmeti, müşteriden iki kez ücret talep etmeden ağ zaman aşımını ele almalıdır. Bir depo tarayıcısı, bağlantı kesildiğinde net bir mesaj sağlamalıdır. Bir tıbbi cihaz, bir hatayı eğitimli personelin müdahale etmesine yardımcı olacak şekilde bildirmelidir. Başarısızlık planlaması bir felaket tahmini değildir. Kullanıcıları önlenebilir kafa karışıklığından korumanın bir yoludur. Verileri yargılamayı unutmadan kullanırlar Ölçümler, mühendislerin kalıpları görmesine yardımcı olur. Düşünmenin yerini almazlar. Bir ekip sayfa hızını, hata oranlarını, üretim maliyetini veya müşteri destek isteklerini takip edebilir. Bu sayılar nereye bakılacağını gösterebilir ancak her metriğin sınırları vardır. Daha az sayıda destek bildirimi, ürünün iyileştirildiği anlamına gelebilir. Bu aynı zamanda kullanıcıların vazgeçtiği ve yardım istemeyi bıraktığı anlamına da gelebilir. Kullanıcı yorumlarının, kayıtların, saha raporlarının ve doğrudan gözlemin yanı sıra rakamlara da bakıyorum. Bir ölçüm bana ne olduğunu anlatıyor. Bağlam bunun nedenini açıklamaya yardımcı olur. Bu denge, bir şirket bir ürünü geliştirmek istediğinde önemlidir. Tıklama oranı daha yüksek olan bir düğme daha fazla etkinlik getirebilir ancak bir sonraki adım kafa karışıklığı yaratabilir. Kullanıcı yolculuğunun tamamını ölçmek, tek bir sayıya odaklanmaktan daha iyi bir görünüm sağlar. Sadece sonuçları değil, kararları da iletirler Teknik işler, kod okumayan veya sistem mimarisini anlamayan kişileri etkiler. Kararları sade bir dille anlatmaya çalışıyorum: - Neyi seçtik? - Neyi reddettik? - Hangi tavizi kabul ettik? - Hangi risk kaldı? - Koşullar değişirse ne olmalı? Kısa bir karar kaydı aylar sonra bile zaman kazandırabilir. Ayrıca ekibin eski bir tartışmayı tekrarlamasını da engelleyebilir. Açık iletişim, tüm teknik ayrıntıların kaldırılmasını gerektirmez. Doğru detayı doğru yere koymak anlamına gelir. Müşterinin gecikmenin teslimatı nasıl etkileyeceğini bilmesi gerekebilir. Bir mühendisin tam zaman aşımı kuralını bilmesi gerekebilir. Bir yöneticinin maliyeti ve riski anlaması gerekebilir. Her kişinin aynı karara ilişkin yararlı bir görüşe ihtiyacı vardır. Bakım için yer bırakır Bir ürün, kullanıcıya ulaştığında bitmez. Mühendislerin onu izlemesi, onarması, bağımlılıkları güncellemesi, soruları yanıtlaması ve yeni koşullara uyarlaması gerekiyor. Bakım çalışmalarını orijinal plana dahil ediyorum: - Hizmetin sahibi kim? - Hatalar nasıl raporlanacak? - Bağımlılıklar ne sıklıkla gözden geçirilecek? - Bir sonraki mühendise hangi bilgiler yardımcı olacak? - Hangi parçaların değişmesi muhtemel? Geliştirme sırasında bir hafta tasarruf sağlayan ancak aylarca onarım gerektiren bir sistem, zayıf bir denge yaratabilir. En iyi tasarım, orijinal ekip yola çıktıktan sonra onu işletecek kişileri destekleyen tasarımdır. Küçük hatalardan öğrenmeye devam ederler Güçlü mühendisler hatalardan arınmış değildir. Hataların bulunmasını kolaylaştıran ve tekrarlanmanın daha az maliyetli olmasını sağlayan alışkanlıklar geliştirirler. Bir olaydan sonra sadece “Hatayı kim yaptı?” diye sormaktan kaçınırım. Soruyorum: - Hatayı mümkün kılan neydi? - Hangi sinyali kaçırdık? - Sürecin hangi kısmı hatayı teşvik etti? - Hangi küçük değişiklik tekrarlanma şansını azaltabilir? Bu inceleme tarzı suçlama yerine faydalı eylem yaratır. Daha net bir kontrol listesi, otomatik bir test veya daha güvenli bir varsayılan, daha sonra benzer bir sorunun yaşanmasını önleyebilir. İyi mühendisliği şekillendiren alışkanlıklar pratiktir: problemi tanımlamak, varsayımları test etmek, tasarımları anlaşılır tutmak, başarısızlıkları planlamak, seçenekleri iletmek ve lansmandan sonra sistemi desteklemek. Araçlar değişecek. Programlama dilleri değişecek. Takım yapıları değişecek. Dikkatli düşünme ihtiyacı devam edecek. Bir mühendislik kararını değerlendirirken çözümün ne kadar etkileyici göründüğünün ötesine bakarım. Bunun gerçek bir ihtiyacı çözüp çözmediğini, insanların bunu anlayıp anlayamadığını ve koşullar artık ideal olmadığında ekibin bunu destekleyip destekleyemeyeceğini soruyorum.

Pek çok mühendis teoriyi biliyor ancak projeler hala gecikmelerle, belirsiz gereksinimlerle, tekrarlanan hatalarla ve maliyetli yeniden çalışmayla karşı karşıya kalıyor. Bunun, bir ekip sorunu anlamadan önce inşaat yapmaya başladığında gerçekleştiğini gördüm. Güçlü mühendisler farklı çalışır. Daha iyi sorular sorarlar, küçük fikirleri test ederler, kararları belgelendirirler ve kullanıcının ihtiyaçlarını göz önünde bulundururlar. Bu alışkanlıklar bir iş unvanına ya da özel bir kişiliğe bağlı değildir. Bir yazılım projesinde, bir ürün tasarım görevinde veya bir fabrika iyileştirme planında uygulanabilirler. İşte istikrarlı, faydalı sonuçlar veren mühendislerde sıklıkla gördüğüm beş alışkanlık. 1. Bir çözüm seçmeden önce sorunu tanımlarlar “Sistemi hızlandırın” gibi bir istek kulağa çok açık gelse de birçok soruyu cevapsız bırakır: - Hangi kısım yavaş geliyor? - Kim etkileniyor? - Gecikme ne sıklıkla meydana geliyor? - Hangi hız seviyesi kabul edilebilir? - Bir değişiklik başka bir yerde yeni bir sorun yaratabilir mi? Bir zamanlar bir ekibin yavaş bir aracı değiştirmeyi planladığı bir süreç üzerinde çalıştım. Verileri kontrol ettikten sonra asıl gecikmenin aracın kendisinden değil manuel onay adımından kaynaklandığını gördük. Onay akışındaki küçük bir değişiklik, sistemin tamamının değiştirilmesini gerektirmeden bekleme süresini kısalttı. İyi mühendisler bir şeyler inşa edebileceklerini göstermek için acele etmezler. Doğru sorunu çözdüklerinden emin olurlar. Basit bir sorun ifadesi yardımcı olabilir: "Kullanıcıların ___'yi tamamlaması gerekiyor, ancak şu anda ___ ile mücadele ediyorlar, bu da ___'ye neden oluyor." Bu format ekibe ortak bir referans noktası sağlar. Ayrıca zayıf varsayımların tespit edilmesini kolaylaştırır. **2. Büyük görevleri küçük testlere bölerler** Büyük projeler çoğu zaman çok fazla bilinmeyenin birbirine karışması nedeniyle zor gelir. Mühendis sorunun koddan mı, donanımdan mı, veriden mi, yoksa kullanıcı akışından mı kaynaklandığını bilemeyebilir. Ben bu bilinmeyenleri ayırıp teker teker test etmeyi tercih ediyorum. Bir yazılım özelliği için şu şekilde görünebilir: 1. Verilerin mevcut olduğunu doğrulayın. 2. Ana iş kuralını küçük bir örnekle test edin. 3. Sistemin eksik verilerle nasıl davrandığını kontrol edin. 4. Tepki süresini ölçün. 5. Kullanıcıdan görevi tamamlamasını isteyin. 6. Sonucu ekiple birlikte gözden geçirin. Ekip tam bir yapı üzerinde haftalar harcamadan önce küçük bir test yararlı geri bildirim sağlar. Test başarısız olursa ekip, değişiklik yapmanın daha kolay olduğu zamanı erkenden öğrenir. Bu alışkanlık aynı zamanda proje maliyetini kontrol etmeye de yardımcı olur. Kısa bir test, planlı bir yaklaşımın uygun olmadığını ortaya çıkarabilir. Bu faydalı bir bilgidir, boşa giden bir iş değil. **3. Başarısızlığa bilgi gözüyle bakarlar** Başarısız bir test, özellikle de insanlar teste hazırlanmak için zaman harcadıklarında, sinir bozucu olabilir. Güçlü mühendisler sonucu saklamaz veya sorunu bulan kişiyi suçlamaz. Sonucun takıma ne öğrettiğini soruyorlar. Thomas Edison'un elektrikli aydınlatma konusundaki çalışması birçok deneyi içerdiği için sıklıkla tartışılıyor. Yararlı ders, belirli sayıda denemeyle ilgili bir iddia değildir. Ders, tekrarlanan testlerin zayıf seçenekleri ortadan kaldırabileceği ve anlayışı geliştirebileceğidir. Bir işyeri projesinde arıza daha küçük olabilir: - Bir sensör kararsız okumalar veriyor. - Bir sayfa bir cihazda çalışıyor ancak diğerinde çalışmıyor. - Bir prototipin kullanılması zor geliyor. - Daha büyük veri kümeleriyle birlikte veritabanı sorgusu yavaşlar. Her sonuç bir soruyu işaret ediyor. Tasarım hatalı mı? Test kurulumu eksik mi? Gereklilik açık değil mi? Başarısız bir testten sonra üç ayrıntıyı kaydetmeyi seviyorum: - Beklediklerimiz - Gözlemlediklerimiz - Bundan sonra neyi değiştireceğiz Bu, tartışmanın kanıtlara odaklanmasını sağlar. Ayrıca ekibin aynı testi öğrenmeden tekrar etmesini de önler. **4. Teknik tercihleri ​​sade bir dille açıklıyorlar** Mühendislik kararları kod yazamayan, teknik çizimleri okuyamayan veya sistem sınırlarını anlayamayan kişileri etkiler. Güçlü bir mühendis, zor terimlerin arkasına saklanmadan bir seçimi açıklayabilir. Bunun yerine şunu söylemek yerine: "Mimari, ölçeklenebilirliği geliştirmek için eşzamansız işleme gerektirir." Şöyle diyebilirim: "Sistem arka planda görevleri işlerse büyük partileri daha sorunsuz halleder. Kullanıcılar, görevler tamamlanırken çalışmaya devam edebilir." İkinci açıklama insanlara takası tartışmak için yeterli bilgi veriyor. Aynı zamanda sorulara da yer bırakıyor. Açık iletişim, her teknik ayrıntının ortadan kaldırılması anlamına gelmez. Bu, her kişiye ihtiyaç duyduğu ayrıntıyı vermek anlamına gelir. Bir proje yöneticisinin maliyet, zamanlama, risk ve kullanıcı etkisini anlaması gerekebilir. Bir geliştiricinin veri kurallarına ve arayüz ayrıntılarına ihtiyacı olabilir. Müşterinin ekranında nelerin değişeceğini bilmesi gerekebilir. Ayrıca sınırları erkenden açıklamaya çalışıyorum. Bir tasarım istenen her özelliği desteklemiyorsa bunu söylüyorum ve mevcut seçenekleri açıklıyorum. Bu, güveni korur ve ekibe daha iyi bilgilerle seçim yapma şansı verir. **5. Geri bildirimleri işin içine katarlar** Mühendisler, kullanıcıların ihtiyaç duymadığı bir çözümü geliştirmek için uzun zaman harcayabilirler. Düzenli geri bildirim bu riski azaltır. Geri bildirim birçok kaynaktan gelebilir: - Kısa bir kullanıcı görüşmesi - Bir tasarım incelemesi - Bir prototip testi - Bir destek bildirimi - Bir üretim raporu - Yapım sürecine dahil olmayan bir meslektaş Küçük bir yazılım şirketinde bir ekip, bir zamanlar ayrıntılı bir raporlama panosu oluşturmuştu. Tasarım dahili incelemeler sırasında kullanışlı görünüyordu ancak müşteriler filtrelerin çoğunu nadiren kullandı. Kısa bir müşteri oturumu, kullanıcıların esas olarak iki numara ve bunları dışa aktarmanın bir yolunu istediklerini gösterdi. Ekip sayfayı basitleştirdi ve günlük görevi kolaylaştırdı. Bu örnek ürün çalışmasına yaklaşımımı değiştirdi. Artık geri bildirimi son onay adımı olarak ele almıyorum. Fikri değiştirmek hâlâ kolayken onu arıyorum. Yararlı bir geri bildirim sorusu şudur: "Bunu kullanmaktan sizi ne alıkoyabilir?" Genellikle "Beğendin mi?" sorusundan daha yararlı yanıtlar üretir. İnsanlar bir tasarımdan hoşlanabilir ama yine de onu yavaş, kafa karıştırıcı veya rutinlerine uyması zor bulabilirler. Bu beş alışkanlık birlikte çalışır. Açık bir sorun, odaklanmış testlere yol açar. Küçük testler kanıt oluşturur. Kanıtlar daha iyi teknik kararları desteklemektedir. Sade dil, daha geniş ekibin bu kararları anlamasına yardımcı olur. Düzenli geri bildirim, işin kullanıcı ihtiyaçlarına bağlı kalmasını sağlar. Bir mühendisi yalnızca ne kadar inşa edebildiğine göre yargılamıyorum. Ayrıca gereksinimler belirsiz olduğunda nasıl düşündüklerine, bir test başarısız olduğunda nasıl tepki verdiklerine ve başkalarının doğru seçimler yapmasına yardımcı olup olamayacaklarına da bakıyorum. Yararlı bir mühendislik alışkanlığı tek bir projeyle başlayabilir. Sorunu bir cümleyle yazın. Küçük bir test yapın. Olanları kaydedin. Kararı basit bir dille açıklayın. İşin bittiğini hissetmeden önce kullanıcıdan geri bildirim isteyin. Bu süreç her zorluğu ortadan kaldırmayabilir ancak ekibe bunlarla başa çıkmanın daha net bir yolunu sunar.

Birçok kişi sorunları daha fazla çaba göstererek çözmeye çalışır. Ben farklı bir yaklaşım kullanıyorum: Yavaşlıyorum, sorunu tanımlıyorum ve sebebini arıyorum. Bu düşünce tarzı, aceleye getirilmiş kararlardan, boşa giden işlerden ve sorunu yalnızca kısa bir süreliğine gizleyen çözümlerden kaçınmama yardımcı oluyor. Mühendislik, işletme, yazılım, ürün tasarımı ve günlük işlerde çalışır. Bir proje zor göründüğünde kendime şu soruyu sorarım: Bir mühendis herhangi bir şeyi değiştirmeden önce neyi kontrol eder? 1. Sorunu tek cümleyle tanımlayın Belirsiz bir sorun belirsiz eylemler yaratır. “Satışlar düşük” ifadesi bana yeterince bilgi vermiyor. Şunu sormam gerekiyor: - Hangi ürünün satışları daha düşük? - Değişim ne zaman başladı? - Hangi müşteriler etkilendi? - Sorun trafikle mi, fiyatla mı, güvenle mi yoksa satın alma süreciyle mi ilgili? Daha iyi bir ifade şu olabilir: "Mobil ziyaretçiler ödeme sayfasına ulaşıyor ancak birçoğu siparişi tamamlamadan ayrılıyor." Bu cümle bana başlamam için net bir yer veriyor. Hem ürünü hem fiyatı hem de reklamı aynı anda değiştirmemi engelliyor. 2. Gerçekleri tahminlerden ayırın Takımların genellikle tahminleri gerçekmiş gibi ele aldığını görüyorum. Bir yönetici “Müşteriler fiyatı beğenmiyor” diyebilir. Veriler farklı bir hikaye gösterebilir. Ziyaretçiler, ödeme sayfasının yavaş yüklenmesi, nakliye ücretinin geç görünmesi veya formun çok fazla bilgi istemesi nedeniyle ayrılabilir. İki basit liste oluşturuyorum: Gerçekler - Trafik geçen ay arttı. - Ziyaretçilerin çoğu mobil cihaz kullanıyor. - Birçok kullanıcı ödeme sayfasından ayrılıyor. Tahminler - Fiyat yüksek gelebilir. - Ödeme formu çok uzun olabilir. - Müşteriler daha fazla ödeme seçeneği isteyebilir. Bu küçük alışkanlık tartışmanın kalitesini değiştirir. Gerçekler bir sonraki kontrolü yönlendirir. Tahminler karar yerine soru haline gelir. 3. Temel nedeni bulun Görünür bir sorun her zaman gerçek sorun değildir. Vardiya sırasında bir makinenin durduğunu varsayalım. Bir parçanın değiştirilmesi tekrar çalışmasını sağlayabilir. Bir mühendis ayrıca parçanın neden arızalandığını da soracaktır. “Neden” yöntemini kullanıyorum: - Makine neden durdu? Motor aşırı ısındı. - Motor neden aşırı ısındı? Hava soğutma alanından geçemiyordu. - Hava akışı neden engellendi? Toz filtreyi kapladı. - Filtre neden tozla doluydu? Temizlik programı net değildi. İlk cevap motora işaret ediyor. Daha derindeki neden yetersiz bakım olabilir. Sonsuza kadar "neden" diye sormayacağım. Yanıt aynı sorunun tekrarlanmasını engelleyebilecek bir eyleme yol açtığında duruyorum. 4. Büyük sorunları küçük testlere bölün Büyük değişiklikler daha fazla risk taşır. Küçük testler bana daha az israfla faydalı geri bildirimler sağlıyor. Bir ödeme sayfasını iyileştirmek istersem mağazanın tamamını bir kerede yeniden inşa etmem. Bir değişikliği test edebilirim: - Toplam maliyeti daha erken göster. - İki form alanını kaldırın. - Misafir ödeme seçeneği ekleyin. - Mobil düzeni iyileştirin. - Ödeme adımı sayısını azaltın. Tamamlanan siparişler gibi bir ana önlemi takip ediyorum. Test sırasında diğer değişiklikleri sabit tutuyorum. Bu, sonuca neyin sebep olduğunu anlamama yardımcı oluyor. Küçük bir test dramatik bir değişiklik yaratmayabilir. Bu hâlâ işe yarar. Zayıf bir sonuç bana hangi yolun daha az dikkat gerektirdiğini söyler. 5. Gerçek kullanım için tasarım Bir fikir kağıt üzerinde güzel görünse de günlük kullanımda başarısız olabilir. Mühendisler bir sistem etrafındaki kişiyi, yeri, araçları ve sınırları düşünürler. Bir ürünü veya süreci incelerken aynı görüşü kullanırım. Mobil ödeme için şunu soruyorum: - Bir kişi sayfayı parlak ışıkta okuyabilir mi? - Form tek elle çalışabilir mi? - İnternet bağlantısı zayıfladığında ne olur? - Kullanıcı bir hatayı yeniden başlatmadan düzeltebilir mi? - Sayfada ödeme yapıldıktan sonra ne olacağı açıklanıyor mu? Gerçek bir örnek birçok çevrimiçi formda görünmektedir. Bir şifre reddedildiğinde “Geçersiz giriş” gibi bir mesajın pek faydası olmaz. "En az sekiz karakter ve bir sayı kullanın" gibi bir mesaj kişinin sorunu çözmesine yardımcı olur. İyi tasarım tahminleri azaltır. 6. Başarısızlığı bekleyin ve bir yanıt hazırlayın Güçlü bir sistem, asla başarısız olmayan bir sistem değildir. Bir şeyler ters gittiğinde insanlara açık bir yol veren bir yoldur. Soruyorum: - Ne başarısız olabilir? - Bunu nasıl fark edeceğim? - Kimin yanıt vermesi gerekiyor? - Kullanıcı ne görmeli? - Sistem güvenli duruma dönebilir mi? Teslimat sürecinde eksik adres, hasarlı paket veya ödemede gecikme yaşanabilir. Açık bir mesaj ve basit bir destek yolu, küçük bir sorunun ciddi bir şikayete dönüşmesini engelleyebilir. Bu zihniyet aynı zamanda ekip çalışmasını da geliştirir. Amaç bir kişiyi suçlamak yerine süreci düzeltmek olduğunda insanlar sorunları daha erken bildirirler. 7. Her kararın arkasındaki nedeni kaydedin Hakkında kısa notlar tutuyorum: - Gördüğüm sorun - Kullandığım kanıtlar - Gözden geçirdiğim seçenekler - Seçtiğim test - Sonuç - Bir sonraki eylem Bu notlar bir proje el değiştirdiğinde yardımcı olur. Ayrıca ekibi eski tartışmaların tekrarlanmasından da korurlar. Bir karar günlüğünün uzun raporlara ihtiyacı yoktur. Birkaç net cümle genellikle yeterlidir. 8. Yalnızca sonucu değil, sistemi de iyileştirin Geçici bir düzeltme, neden devam ettiği sürece raporun daha iyi görünmesini sağlayabilir. Müşteri desteği her gün aynı soruyu alıyorsa daha fazla destek personeli eklemek kısa bir süre için yardımcı olabilir. Ürün talimatlarını geliştirmek, yardım sayfasını güncellemek veya kafa karıştırıcı ekranı değiştirmek daha iyi bir yol olabilir. Tekrarlanan çalışmaları, tekrarlanan hataları ve tekrarlanan soruları ararım. Çoğunlukla sürecin dikkat edilmesi gereken noktalarını gösterirler. En iyi mühendislik alışkanlıkları basittir: Sorunu tanımlayın. Gerçekleri kontrol edin. Sebebini arayın. Bir değişikliği test edin. İnsanların sonucu nasıl kullandıklarını izleyin. Başarısızlığa hazırlanın. Kayıt tutun. Süreci iyileştirin. Bu yöntemi kullanmak için mühendis olmama gerek yok. Zor bir görevle karşılaştığımda, hızlı fikirlerin yerine net sorular koyarım. Bu değişim daha iyi seçimler yapmama, mantığımı açıklamama ve tek bir anın ötesinde işe yarayan çözümler geliştirmeme yardımcı oluyor.

Pek çok ekip daha hızlı inşa etmek ister ancak hız çoğu zaman daha fazla yeniden çalışmaya neden olur. Aceleye getirilmiş bir plan, belirsiz görevlere, gözden kaçan müşteri ihtiyaçlarına ve bakımı aylar süren özelliklere yol açabilir. Daha akıllı binaların daha uzun iş günleriyle değil, daha iyi kararlarla başladığını keşfettim. ### Kullanıcının gerçek sorunuyla başlayın Bir ürün, hizmet veya kampanya planlamadan önce sorunu tek cümleyle yazarım. Örneğin: > "Müşteriler ödeme yapmadan önce teslimat maliyetlerini göremedikleri için küçük çevrimiçi mağazalar siparişlerini kaybediyor." Bu açıklama takıma net bir yön veriyor. “Daha iyi bir alışveriş deneyimine ihtiyacımız var” demekten daha faydalı. Daha sonra sorunu müşteri görüşmeleri, destek mesajları, arama verileri veya satış aramaları yoluyla kontrol ediyorum. Beş kullanıcıyla yapılan kısa bir görüşme, uzun bir şirket içi toplantının gözden kaçırabileceği sorunları ortaya çıkarabilir. ### İlk sürümü küçük tutun İlk sürüm, açık bir sorunu çözmelidir. İstek listesindeki her özelliğe ihtiyaç duymaz. Müşterinin ihtiyacından pratik bir sonuca giden faydalı bir yola ihtiyacı var. Bir ödeme ekibi şunlarla başlayabilir: - Net teslimat maliyetleri - Daha kısa bir form - Mobil uyumlu ödeme - Basit bir sipariş onayı Ekip, sadakat puanlarını, gelişmiş raporları ve özel tasarım araçlarını daha sonraki bir aşamaya bırakabilir. Bu, işin test edilmesini ve değiştirilmesini kolaylaştırır. ### Fikirleri görünür görevlere dönüştürün Büyük hedefler, ekiplerin gerçek bir ilerleme göstermeden kendilerini meşgul hissetmesine neden olabilir. Her hedefi birisinin tamamlayıp gözden geçirebileceği görevlere bölüyorum. > "Web sitesini geliştirin" yazmak yerine aşağıdaki gibi görevleri kullanıyorum: - En çok ziyaret edilen beş ürün sayfasını gözden geçirin - Tekrarlanan form alanlarını kaldırın - Fiyatın yanına teslimat bilgilerini ekleyin - Sayfayı üç ortak ekran boyutunda test edin - Değişiklikten önce ve sonra tamamlanan siparişleri karşılaştırın Görevleri temizleme, insanların daha sonra ne olması gerektiğini görmesine yardımcı olur. Ayrıca gecikmelerin tespit edilmesini kolaylaştırırlar. ### Kısa bir geri bildirim döngüsü oluşturun Geri bildirim toplamadan önce mükemmel bir lansmanı beklemiyorum. Küçük bir kullanıcı grubuna basit bir çalışma sürümü gösterilebilir. Soruları genellikle ekibin göremediği sorunları ortaya çıkarır. Amazon, çalışma kültürünün bir parçası olarak küçük, bağımsız ekipleri ve erken testleri kamuoyuna açıkladı. Yararlı ders, o modelin her parçasını kopyalamak değildir. Sahipliği açık tutmak ve çok fazla zaman harcanmadan müşteri geri bildirimlerini sürece dahil etmektir. ### Yararlı sonuçları ölçün Daha hızlı bir süreç hala net bir ölçüme ihtiyaç duyar. Bir ürün sayfası için şunları izleyebilirim: - Sepete ekleme oranı - Ödeme işleminin tamamlanması - Müşteri soruları - Geri ödeme talepleri - Sayfa yükleme süresi Tek bir ölçüm nadiren hikayenin tamamını anlatır. Daha yüksek bir tıklama oranı olumlu görünebilir, ancak ödeme sırasında daha fazla müşterinin ayrılmasının pek bir anlamı yoktur. Verileri müşteri yorumlarıyla birlikte inceliyorum. Rakamlar neyin değiştiğini gösteriyor. Konuşmalar genellikle nedenini açıklar. ### Müşteriye faydası olmayan işleri kaldırın Bazı görevler, bunları her zaman bir ekip yaptığı için devam eder. Basit bir soru soruyorum: > “Bu çalışma hangi kararı vermemize yardımcı olacak?” Haftalık rapor kimse tarafından kullanılmıyorsa formatın değişmesi gerekebilir. Toplantının net bir kararı yoksa paylaşılan bir belge daha iyi sonuç verebilir. Bir özelliğin bilinen bir kullanıcı ihtiyacı yoksa otoparka ait olabilir. Bu kesim bakımı veya kalite anlamına gelmez. Gerçek bir sonucu destekleyen çalışmaya dikkat etmek anlamına gelir. ### İyileştirmeyi rutinin bir parçası haline getirin Her sürümden sonra üç noktayı gözden geçiririm: - Çalışmanın ilerlemesine ne yardımcı oldu? - İnsanlar nerede bekledi veya işi tekrarladı? - Bir sonraki döngüde neyi değiştirmeliyiz? Kısa bir inceleme, daha net tasarım notları, daha erken testler veya daha az onay adımı gibi pratik ayarlamalara yol açabilir. Daha akıllı ve daha hızlı üretim yapmak, insanları ara vermeden çalışmaya itmek anlamına gelmiyor. Bu, tahminleri azaltmak, kapsamı açık tutmak ve işin değiştirilmesi hâlâ kolayken öğrenmekle ilgilidir. Ekipler tek bir müşteri sorununa odaklandığında, küçük fikirleri test ettiğinde ve faydalı sonuçları ölçtüğünde ilerlemenin görülmesi ve sürdürülmesi kolaylaşır.

Pek çok kişi uzmanların bildiklerini öğrenmek ister, ancak genellikle dağınık videolar, kısa gönderiler ve ihtiyaçlarına uymayan tavsiyelerle başlarlar. Sonuç tanıdık: çok sayıda not, çok az ilerleme ve öğrenmenin yararlı olup olmadığına karar vermenin net bir yolu yok. Daha basit bir yolu tercih ediyorum. Yetenekli insanların nasıl düşündüklerine, nasıl karar verdiklerine ve bir plan başarısız olduğunda nasıl tepki verdiklerine bakıyorum. Uzman bilgisi yalnızca gerçeklerin bir listesi değildir. Sorunları görmenin bir yoludur. ### 1. Net bir problemle başlayın Uzmanlar nadiren sebepsiz öğrenirler. Genellikle şu soruyla başlarlar: - Müşteriler neden bir hizmetten ayrılıyor? - Bir ürün neden ziyaret alıyor ama satışları az? - Bir takım neden aynı hatayı tekrarlar? - Bir çalışma planı neden birkaç gün sonra çalışmayı bırakıyor? Açık bir problem öğrenmeye pratik bir yön verir. Sorunu tanımladığımda, kulağa ilginç gelen ancak daha iyi bir karar vermeme yardımcı olmayan bilgileri göz ardı edebilirim. Yararlı bir soru şudur: "Bunu öğrendikten sonra neyi daha iyi yapmam gerekiyor?" Cevap bir beceri, bir karar veya bir süreç olabilir. ### 2. Yalnızca sonuçları değil, kararları da inceleyin Yeni başlayanlar genellikle başarılı bir sonuca bakar ve onu kopyalamaya çalışır. Uzmanlar bu sonucun ardındaki seçimlere dikkat ediyor. Benzer ürünler satan iki çevrimiçi mağaza düşünün. Bir mağazanın güçlü satışları var. Renklerini, düzenini veya ürün fotoğraflarını kopyalamak aynı sonucu vermeyebilir. Gerçek neden, daha net ürün bilgileri, daha iyi müşteri desteği veya daha sorunsuz bir iade süreci olabilir. Güçlü bir örneği incelediğimde şunu sorarım: - Kişi hangi sorunla karşılaştı? - Hangi seçenekler mevcuttu? - Hangi seçimi yaptılar? - Bu seçimi hangi bilgiler şekillendirdi? - Karardan sonra ne oldu? - Şimdi neyi değiştirirlerdi? Bu yöntem bir yüzey detayını kopyalamak yerine bir süreci öğrenmeme yardımcı oluyor. ### 3. Tekrarlanan kalıpları arayın Bir örnek yararlı olabilir, ancak aynı zamanda alışılmadık da olabilir. Aynı fikri birkaç güvenilir kaynakta arıyorum. Örneğin birçok deneyimli yazar benzer bir çalışma alışkanlığını kullanır: 1. Yazmadan önce okuyucuyu tanımlarlar. 2. Gerçek kullanıcılardan soru toplarlar. 3. Her seferinde bir ana fikri açıklarlar. 4. Okuyucuyu desteklemeyen cümleleri çıkarırlar. 5. İnsanların nasıl tepki verdiğini gördükten sonra gözden geçirirler. İfadeler yazardan yazara değişir. Desen kalır. Tekrarlanan desenlerin test edilmesi daha kolaydır. Küçük bir değişiklik yapıp sonucu izleyebilir ve durumuma uyup uymadığına karar verebilirim. ### 4. Hasarı kopyalamadan hatalardan ders çıkarın Uzmanlar her hatadan kaçınmazlar. Hataların maliyetini azaltırlar ve onlardan özenle öğrenirler. Havacılık endüstrisi faydalı bir örnek sunuyor. Pilotlar, karmaşık görevler sırasında kaçırılan adımları azaltmak için kontrol listelerini kullanır. Hastaneler ayrıca iletişimi ve güvenliği desteklemek için cerrahi kontrol listelerini benimsedi. Bir kontrol listesi becerinin yerini almaz. İnsanlar yorgunken, acele ederken veya birçok ayrıntıyla uğraşırken dikkati korur. Aynı fikri daha küçük görevlerde de kullanıyorum. Bir sayfayı yayınlamadan önce şunları kontrol edebilirim: - Sayfa net bir soruyu yanıtlıyor mu? - Okuyucu teklifi tahmin etmeden anlayabilir mi? - Gerçekler güvenilir bilgilerle destekleniyor mu? - Sayfa telefonda iyi çalışıyor mu? - Bir sonraki eylemin anlaşılması kolay mı? Kısa bir kontrol listesi, basit hataların tüm sonucu etkilemesini önleyebilir. ### 5. Daha iyi sorular sorun Uzmanlara erişim her zaman faydalı öğrenmeye erişim anlamına gelmez. Belirsiz bir soru çoğu zaman belirsiz bir cevap üretir. “Pazarlamamı nasıl geliştirebilirim?” diye sormak yerine Şunu sorabilirim: - Müşteri yolculuğunun en çok hangi kısmı insan kaybediyor? - Bu sayfanın değişiklik gerektirdiğini gösteren kanıtlar nelerdir? - Hangi mesaj kafa karışıklığına neden olur? - Kampanyanın tamamını değiştirmeden hangi küçük testi yapabilirim? - Hangi sonuç değişikliğin yardımcı olduğunu gösterir? İyi sorular bir cevabın ardındaki düşünceyi ortaya çıkarır. Ayrıca farklı kaynaklardan alınan tavsiyeleri karşılaştırmayı da kolaylaştırırlar. ### 6. Küçük birimler halinde pratik yapın Bir beceri hakkında okumak aşinalık yaratır. Uygulama onu kullanıp kullanamayacağımı gösteriyor. Arama içeriğini öğreniyorsam bir sayfa seçip odağını, yapısını ve dilini geliştirebilirim. Satışı öğreniyorsam, bir müşteri görüşmesini gözden geçirebilir ve müşterinin kararsız kaldığı noktayı belirleyebilirim. Tasarım öğreniyorsam, iki sayfa düzenini karşılaştırabilir ve kullanımının neden daha kolay olduğunu açıklayabilirim. Küçük pratik geri bildirim yaratır. Geribildirim bilgiyi çalışma bilgisine dönüştürür. ### 7. Bir karar kaydı tutun Üç kısa not yazmayı faydalı buluyorum: - Görevden önce neye inandım - Neyi değiştirdim - Değişiklikten sonra ne oldu Bu kayıt beni bir yöntemi yalnızca hafızaya göre yargılamaktan alıkoyuyor. Ayrıca hangi fikirlerin hedef kitleme, bütçeme, araçlarıma ve çalışma tarzıma uygun olduğunu da gösterir. Büyük bir şirkete yardımcı olan bir yöntem, küçük bir işletmeye uygun olmayabilir. Bir kişi için işe yarayan bir çalışma rutini başka biri için başarısız olabilir. Uzman bilgisi, kendi koşullarımla test ettiğimde faydalı oluyor. ### Bu basit rutini kullanabileceğim pratik bir öğrenme planı: 1. Belirli bir problem seçin. 2. Birkaç güvenilir örnek bulun. 3. Her örneğin arkasındaki kararları inceleyin. 4. Birden çok kez görünen desenleri not edin. 5. Küçük bir değişikliği test edin. 6. Sonucu kaydedin. 7. Yöntemi ayarlayın ve işlemi tekrarlayın. Bu yaklaşım sabır gerektirir ancak rastgele çabayı azaltır. Ayrıca tavsiyeleri değerlendirmem için bana daha iyi bir yol sağlıyor. Her popüler düşünceyi takip etmem gerekmiyor. Bir yöntemin ardındaki nedeni anlamam, onu dikkatle test etmem ve yararlı olduğunu kanıtlayanları saklamam gerekiyor. Uzmanların bildiklerini öğrenmek, daha fazla bilgi toplamak anlamına gelmez. Sorunları daha dikkatli görmek, daha iyi kanıtlarla seçimler yapmak ve uygulama yoluyla gelişmeye devam eden alışkanlıklar oluşturmakla ilgilidir. Daha fazlasını öğrenmek için bugün bizimle iletişime geçin JennyHU: Jennyhu@jh-products.com/WhatsApp ++8618913784194.

Steve Krug (2014) Beni Düşündürme Tekrar Ziyaret Edildi Frederick P Brooks Jr (1995) Efsanevi Adam-Ay Geni Kim Kevin Behr ve George Spafford (2013) Phoenix Projesi James Reason (1997) Organizasyonel Kaza Risklerini Yönetmek Ulusal Havacılık ve Uzay İdaresi (1999) Mars İklim Orbiter Kaza Araştırma Kurulu Aşama I Raporu Eric Ries (2011) Yalın Başlangıç