Yazılım kalitesine ilişkin notlar
Kalite hakkında nasıl düşünüyorum?
Kalite sorunların olmamasıdır
Kalite için bulabildiğim en iyi tanım “sorunların olmaması”dır.
Detaylar ve Etkileri
Kaliteyi ölçmenin en pratik yolu, birçok farklı kişiyle test yapmak ve birçok uzmanın incelemesini sağlamaktır. Kapsamlı testler ve 100 uzman bir sorun bulamazsa, sorun muhtemelen mükemmeldir.
Kalite “mükemmelliğe” uzanan bir yelpazedir
Mükemmellik imkansızdır. Sektörde üzerinde uzlaşılan en iyi tasarlanmış yazılımın gözle görülür sorunları var. Ama ne kadar yaklaşabilirsen o kadar iyi.
Gelecekte Ne Bekleniyor?
Mükemmelliğe ne kadar yaklaşırsanız o kadar zorlaşır. Bu, kalitenin söz konusu olduğu her yerde göreceğiniz "getirilerin azalması" etkisinin aynısıdır.
Kalite organizasyona bağlıdır
Uzmanların Görüşleri
Liderlik ve kültür kaliteyi hem tanımlar hem de kaliteye olanak sağlar. Her ne kadar yaptıklarına inanmasalar da. Bunu düşünmemiş olsalar bile. Eylemleri ve inançları kaliteyi ya etkinleştirecek ya da sınırlayacaktır.
Teknik Analiz
Kalite, yeteneğin ve iştahın sonucudur. Organizasyonda yüksek kalite (yetenek) üretebilecek insanlar var mı? Ve organizasyon kalitenin sağlanmasına (iştah) izin veriyor mu?
Sonuç ve Değerlendirme
~%100 oranında bir kuruluşun yüksek kaliteli yazılım ürettiğini gördüm, bunun nedeni liderlerin bunu istemesiydi. Eğer liderler kaliteyi istemiyorsa bu çok daha zor olacaktır.
Ancak ne üzerinde çalışırsanız çalışın, kişisel olarak elde edebileceğiniz bir miktar kalite olduğunu unutmayın. En katı tasarım sistemi kontrollü arayüzde bile, hala daha yüksek ve daha düşük kalitede seçimler yapabilirsiniz.
Sistem Güvenliği
Bir kuruluş objektif kalite ölçümleri belirleyebilir (ör. rapor edilen hatalar). Umarız bu objektif ölçümler, organizasyonu subjektif ölçümlere karşı körleştirmez (örneğin, "bir uzman bunun yüksek kalitede olduğunu düşünüyor mu?").
Kalite ölçeklendikçe zorlaşıyor
Önemli Gelişmeler
Organizasyon veya yazılım ne kadar büyük olursa, kalite de o kadar zor olur. Belirli bir ölçek noktasından sonra yüksek kalite imkansızdır. Bazı kuruluşlar yüksek kaliteli yazılım üretme konusunda yetersizdir.
Nasıl Önlem Alınmalı?
Daha da önemlisi, bu ölçeğin doğal bir sonucudur. Bu bir şikayet ya da çözülmesi gereken bir sorun değil. Bu çözülemez. Yazılımdaki hemen hemen her şey gibi bu da bir değiş-tokuş.
Kalite gerekli değil ama idealdir
Keşke her kuruluş kaliteye önem verse. Birçoğunun bunu yapmadığı ve buna gerek duymadığı açıktır. Ticari açıdan başarılı birçok kuruluş kaliteye öncelik vermez.
Ancak kalite idealdir. Herkes daha kaliteli bir dünyada yaşamak ister. Kalite yaratmak güzel bir duygu. Daha kaliteliyse işler daha uzun süre dayanır. Ve uzun vadede, insanlar markanızın kaliteyi temsil etmediğini fark ederse ticari başarı daha da zorlaşır.
Kalitenin evrensel sinyalleri
Bunlar her şey için geçerli olduğunu bulduğum kalite sinyalleridir. İnsanlar ve eserler.
Görünüm: Basit bir ifadeyle, bir şey ne kadar güzelse, o kadar kaliteli olduğunu düşünüyoruz. Bunun güzelliğin ve genel olarak kalitenin çaba gerektirmesinden kaynaklandığını düşünüyorum. Bir şeye özen gösterdiğimize dair herhangi bir kanıt, daha fazla özen gösterdiğimizin kanıtıdır. Çağrışım: Bir şeyin kaliteli olup olmadığına, ilişkilendirildiği şeye göre karar veririz. Buna yaygın bir yaklaşım, birisinin veya bir şeyin başka birisi veya bir şeyle ilişkilendirildiği sosyal kanıttır. Bir şeyi sahip olduğu şirkete göre yargılarız. Maliyet: Birinin veya bir şeyin maliyeti daha yüksekse bunun, değerinin daha fazla olmasından kaynaklandığını varsayabiliriz. Ancak “maliyet”in “para” anlamına gelmesi gerekmez. Örneğin bir şey daha fazla zaman alıyorsa, onun daha kaliteli olduğunu varsayabiliriz. Performans: Performans, "en yüksek hız" gibi niceliksel veya "bana nasıl hissettiriyor" gibi niteliksel olabilir. “Görevimi tamamlamama yardımcı oldu mu?” gibi sonuç odaklı olabilir. Basit bir ifadeyle, görünüş “nasıl göründüğü” ise performans da “nasıl olduğu”dur.
Yazılımda kalitenin altı sinyali
Güvenilirlik: Yazılım teknik olarak her zaman beklendiği gibi performans gösteriyor mu? Bu, hata olmadığı, kesinti olmadığı, hata olmadığı vb. anlamına gelir. Hız: Yazılım girdilere anında mı yoksa pratik olarak mümkün olduğu kadar yakın mı tepki veriyor? Daha uzun sürmesi gereken görevler mümkün olduğunca hızlı mı yapılıyor? Açıklık: Yazılımı kullanan kişi her şeyi anlıyor mu? Etkinlik: Kişi yazılımla yapması gerekenleri yapabilir mi? Verimlilik: Kişi yazılımla yapması gerekenleri mümkün olduğunca kolay bir şekilde yapabiliyor mu? Güzellik: Yazılım mümkün olduğunca estetik açıdan hoş mu?
Yazılım kalitesinin faydaları
Bazıları kalitenin bariz bir iyilik olduğunu iddia edebilir. Kalitenin önemli olmasının nedenleri doğaldır Herkes tarafından anlaşıldı. Ama hâlâ bir sürü berbat yazılımımız var, o yüzden 🤷.
Çalışanları kendinize çekin: İnsanlar kaliteye önem veren şirketlerde çalışmak ister. Yaratıcılar olarak memnuniyet: Katılan herkes kendini daha iyi hissedecek. Daha az yangınla mücadele edin: Daha yüksek kalite, daha sonra çözülmesi gereken sorunların daha az olması anlamına gelir. Daha az hata, daha az güvenilirlik sorunu vb. Yazılım entropisiyle savaşın: Tüm yazılımlar büyüdükçe zarar görür. Şişirilir, kullanımı ve bakılması zorlaşır. Kaliteye bağlılık entropiye karşı geri adım attırır. Daha az çalışan kaybı: Yazılıma özen gösterilmesi genellikle onu yapan kişilere özen gösterilmesi anlamına gelir. Beceri gelişimini teşvik eder. Satışı daha kolay: Eğer kalite şirketinizin kimliğinin bir parçasıysa ürünün satışı daha kolaydır. Ağızdan ağıza pazarlamanın bir kısmını sizin için yapacaktır. Kullanıcıları çekin: Kalite insanları çeker. Yazılımınızı kullanma olasılıkları daha yüksektir. Kullanıcılar hayran olur: Kullanılabilir, etkili, tatmin edici yazılımlar kullanıcıları hayrana dönüştürür. Hayranlar şirketi desteklemek, onu daha kolay affetmek istiyor ve gelişmesine yardımcı olmaktan mutluluk duyuyor. Rekabetçi bir hendek: Kalite zordur. Rakipleriniz muhtemelen bu çabayı göstermeyecektir. Daha fazla para kazanın: İnsanlar evrensel olarak kaliteye daha fazla para ödüyor. Güzellik toplumu iyileştirir: Güzel eserler evrensel olarak yaşama şeklimizi iyileştirir. Başkalarına kaliteye ilham verin: Diğer insanlar ve şirketler çalışmalarınızdan ilham alacaktır. Bir miras bırakın: Hiçbir ürün sonsuza kadar dayanmaz. Ancak insanlar onlarca yıldır iyi yazılımlardan bahsediyor.
Kaliteyle ilgili çürütmek istediğim inançlar
Kariyerimin büyük bölümünde yazılım arayüzü kalitesi aklımdaydı. İşte doğru olduğuna inandığım bazı şeyler. Olmamalarını tercih ederim.
Bir kişi tüm arayüzü aklında tutabildiğinde kalite en kolay hale gelir. Bir yazılım üzerinde ne kadar çok insan çalışırsa, yüksek kalite o kadar zorlaşır. Hayatınızda ne kadar kaliteli şeyler varsa hayatınız o kadar iyi olur. Ürününüzün kalitesi ne kadar düşük olursa, o kadar çok insan onu terk eder. Kalite yüksekse ürününüz hakkında daha fazla kişi konuşacaktır. Kalite, bir kuruluşta en güçlü olanın iznine bağlıdır. Kalite, yalnızca işi yapan kişilerin yönlendirdiği aşağıdan yukarıya bir çaba olamaz. Yüksek kalite her zaman bir şeylerden fedakarlık etmeyi gerektirir; kapsam, para, büyüme veya zaman. Yüksek kalite her zaman birisinin ona karşı güçlü bir kişisel ilgiye/takıntıya sahip olmasını gerektirir. Kaliteye odaklanmak, büyümeden fedakarlık etmek anlamına gelir. Sık kullanılan yazılımlarda kalite hem daha zordur hem de daha önemlidir. Kalite, rekabetçi bir hendektir çünkü çok az kuruluş buna odaklanmaktadır. Yüksek kalite istiyorsanız ideal olarak iyi insanları işe almalısınız. İyi insanları işe alamıyorsanız, birçok şeyi yinelemeye istekli olmalısınız. Yüksek kalite elde etmek için beklenenden çok daha fazlasını yinelemeniz gerekir. Bazı örgüt kültürleri yüksek kaliteye sahip değildir. Organizasyon ne kadar büyük olursa, kalite de o kadar zorlaşır. Belirli büyüklükteki bir organizasyonda yüksek kalite mümkün değildir. Yazılım büyüdükçe kalite de zorlaşır. Belirli bir yazılım boyutunda yüksek kalite mümkün değildir. Bazı yazılımlarda bir şeyin kalitesi düşükse, bu genellikle diğer şeylerin de düşük kalitede olduğuna dair güvenilir bir işarettir. Bazı kalite türleri her zaman hemen belli olmaz. Mükemmellik imkansızdır. Ürünler ve şirketler, başka şeylerin pahasına kaliteye odaklandıkları için başarısız olabilirler. Kalite her şeye çok dikkat edilmesini gerektirir. Herkes kalitenin olumlu olduğunu kabul etse de insanları kaliteye odaklanmaya ikna etmek zordur. Bazı insanlar özel hayatlarında kaliteyi isterler ama profesyonel hayatlarında bunu yeterince önemsemezler. Birçok ticari hedef kaliteye zarar verir; büyüme. Kalite sürekli bir çabadır. Özellikle değişiklikler yapılırken sorunlar sessizce ortaya çıkabilir. Kaliteyi ölçmenin tek güvenilir yolu, yazılıma çok sayıda uzmanın bakmasını sağlamaktır. Kaliteye odaklanmanın getirileri azalıyor. “%90” kaliteye ulaşmak, “%80” kaliteye ulaşmaktan çok daha fazla çaba gerektirir. Yazılım oluşturmaya yardımcı olacak mevcut sistemler (örneğin tasarım sistemleri) kaliteye odaklanma çabalarına da zarar verebilir. İnsanlar etkileyici görsel stilleri görsel kaliteyle ilişkilendirir. İhtiyaç duyulmadığında bile yüksek kaliteli yazılımlardan etkileyici görsel stiller bekleyebilirler. İnsanlar yüksek maliyeti kaliteyle ilişkilendirir. İnsanlar abartıyı/topluluğun ilgisini kaliteyle ilişkilendirir. Kaliteden daha düşük maliyetle rekabet etmenin birçok yolu vardır; özellikler, fiyat, satış deneyimi. İnsanlar kaliteye istedikleri kadar odaklanamadıkları için firmadan ayrılabiliyorlar. Yenilik daha acildir İnsanlar için yüksek kaliteden daha çekici. Yüksek kalite genellikle daha sonra fark edilir. Kuruluşlar ve kişiler, ürünlerinin düşük kalitesi hakkındaki gerçeği neredeyse hiçbir zaman söylemezler.
Kalite ölçekte imkansızdır
Yazılım büyüdükçe iyi arayüz tasarımı zorlaşır. Sonuçta birinci sınıf arayüz tasarımı imkansızdır. İşte bazı düşünceler.
Yönetilmesi gereken çok fazla ilişki var
İyi arayüz tasarımı tutarlıdır. "Tutarlı", arayüzdeki tüm şeyler arasındaki ilişkilerin iyi çalıştığı anlamına gelir. Ancak şeylerin sayısı arttıkça ilişkilerin sayısı da daha hızlı artıyor. Sonuçta insanların tüm bu ilişkileri doğru bir şekilde değerlendirmeleri imkansızdır.
Bu prensip insanlar için de geçerlidir. Yazılım üzerinde ne kadar çok kişi çalışırsa, bunların arasındaki ilişkileri yönetmek de o kadar zorlaşır. Çeviride bazı şeyler kaybolur. İnsanlar hedef konusunda anlaşamazlar ve farklı yönlere çekilirler.
Bunu daha sıkı süreçlerle yönetebilirsiniz. Ancak sonuçta tasarımdan çok sürece zaman harcayacaksınız.
Bazı insanlar yeterince umursamıyor
Ne kadar çok kişiyi işe alırsanız, iyi arayüz tasarımını yeterince önemsemeyen kişileri işe alma olasılığınız da o kadar artar. İyi bir arayüz tasarımının işe etki edebilecek herkes tarafından değer görmesi gerekir. Buna geliştiriciler, tasarımcılar, ürün yöneticileri ve çoğu zaman CEO dahildir.
Bazı ticari hedefler iyi tasarıma zarar verir
Bir şirket ticari nedenlerden dolayı bazı rakamların artmasını isterse, bu genellikle arayüz tasarımının kalitesine zarar verir. Örneğin, bir web sitesine daha fazla reklam eklemek bir şirketin kârlı olmasına yardımcı olabilir. Ancak arayüzü daha da kötüleştirebilir.
Büyümenin bir yolu, insanların talep ettiği özellikleri eklemektir. Ancak çoğu zaman eklenen her özellik arayüzü daha da kötüleştirir. Yukarıdaki ilk nokta nedeniyle bundan kaçınmak zordur.
Kalitenin geniş ölçekte imkansız olduğuna dair anekdot niteliğinde kanıtlar
Patrick McKenzie, Stripe'taki kalite kültürü hakkında tweet attı. Patrick sözlerini "Hiçbiri yeterli değil. Şu anda kalitenin bulunduğu noktadan aktif olarak memnun değiliz" diyerek bitirdi.
Family and Honk'tan Benji Taylor, "büyük kurumsal yazılımlar her yıl daha da sorunlu hale gelirken, bağımsız yazılımlar daha sorunsuz ve daha güvenilir hale geliyor gibi görünüyor" dedi.
Bazı önemli isimler Benji'nin tweet'ine yanıt verdi:
"Detaylara verilen önem, ekibin büyüklüğüyle ters orantılıdır" (Jordan Singer) "Detaylara, makro açıdan bütünsel olarak düşünülebildiğinde en iyi şekilde önem verilir. Büyük organizasyonlar, tasarımları gereği buna izin vermez." (Brandon Jacoby) "ürününüz/ekibiniz büyüdükçe zanaat daha da pahalı hale geliyor" (George Kedenburg III) "Yüksek zanaatın ölçeklendirilmesinin dayanılmaz derecede zor olduğuna tüm kalbimle katılıyorum" (Kurt Varner) "hızla büyüdüğümüz için zanaatın Twitter'da sürdürülmesi imkansızdı" (Sean Thompson)
Tarayıcı şirketi, Optimizing For Feelings adlı makalesinde şöyle diyor: "Gündelik yazılım araçlarımız ve medyamız ilk kez küresel hale geldikçe, sanatçının eli yerini algoritmanın kaprislerine bıraktı. Ve yazılımımız, pek çok farklı insanla dolu bir dünyada herkese uyan tek kalıp haline geldi. Tüm görüşlerimiz, inançlarımız ve fikirlerimizin ortalaması alındı".
Stately'nin kurucusu David Khourshid, "bir uygulamaya tek bir 'özellik' (yeni durumlar + geçişler) eklemenin bile, uygulamanın kullanılabileceği yolların katlanarak artmasını sağlayabileceğini" söylüyor.
Benji Taylor, "Tüm bu ürünlerin ortak noktası, küçük ekipler tarafından üretilmiş olmalarıdır... Çoğu zaman ürünler belirli bir ölçeğe ulaştıklarında ruhunu kaybederler" diye tweet attı.
Paul Stamatiou, "şu ana kadar burada verilen yanıtlar, yüksek kaliteli yazılım ürünlerinin yalnızca küçük ekipler tarafından üretildiği yönündeki teorimi doğruluyor" dedi.
Nathan A. Curtis şöyle dedi: "Figma'yı seviyorum ve daha fazlasını eklemek için yaptıkları deneylere değer veriyorum. Ancak bunu hissedebiliyorum... kullanıcı arayüzleri 'Adobe Creative Suite'. Ve bu bir kullanılabilirlik maliyeti taşıyor." Bunu 2022 yılının Nisan ayında, Adobe'nin Figma'yı satın almasından aylar önce söylediğini unutmayın.
Steve Jobs'un öne sürdüğü iddiayı tekrarlayan Marty Cagan şöyle dedi: "Bir şirket büyüdükçe, ürün tarihsel olarak daha az önem kazandı... İyi ürüne sahip insanlar artık orada çalışmak istemiyor... Ürüne değer veren bir şirkete gidiyorlar. Sanırım bu, duyduğum diğerlerinden daha iyi bir açıklama."
Steve Ruiz "maalesef zevk ölçeklenmiyor" dedi.
Packy McCormick bunun hakkında yazdı. İşte bazı güzel parçalar:
"Sihir, startuplar için bir strateji olabilir, hatta olmalıdır. Bu onların benzersiz bir şekilde yaratabileceği, yerleşik şirketlerin ise çoğu zaman yapamadığı bir şeydir." “Figma seçebildi… yeterli yirmi yıllık teknik borç konusunda endişelenmeden, tam o anda gelişmiş teknolojiler. Genç bir girişim olarak, sihir yaratmaya odaklanabildi ve bu sihirden yararlanabildi, ta ki bir gün o da çok fazla teknik borca sahip oluncaya kadar… ta ki kamu piyasalarının talepleri onu sihri öldüren türden pratik, iş odaklı kararlar almaya zorlayana kadar.” "Adobe çöküşü hızlandırsa da hızlandırmasa da... sihir eninde sonunda bozulacaktı." "Yeni kurulan bir şirket, eğer şanslıysa, sihir yaratır, bu sihri dolara dönüştürür ve muazzam kar ve güce sahip, ancak artık sihir yaratamayan başarılı bir Büyük Muggle Şirketi olarak hayata geçiş yapar." “Bir zamanlar sevdiğim ürünlerdeki büyünün kaybolmasından yakınmayı ve kullandığım teknolojinin neden eskisi kadar büyülü olmadığını anlamaya çalışmayı planlıyordum. Ama olan bu değil. Yaşananlar daha da etkileyici. Büyülü ürünlerin son nesli olgunlaştı, Muggle'lara dönüştü ve böylece yeni bir Sihirbazlar grubuna yer açıldı." “Tanıdıklığı suçla. İş modellerini suçlayın. Teknik borcu suçlayın. Çok değişkenli test ve optimizasyonu suçlayın. Pazarın acımasız soğukluğunu suçlayın. Hedonik koşu bandını suçla. Bitmek bilmeyen yeni, parlak şeyler arayışımızı suçlayın. İnsan doğasını suçlayın.”
Paul Graham, "Bu gezide Silikon Vadisi'ndeki insanlarla konuşurken fark ettiğim bir konu, Google'ın son derece bürokratik hale gelmesidir" dedi.
Stripe'ın kurucu ortağı Patrick Collison, Tim Feriss şovunda şunları söyledi: "Herhangi bir büyük şirketi düşünün... her ne nedenle olursa olsun, sermayeyi iyi bir yazılıma dönüştüremezler. Ve eğer yapabilirlerse bu onlar için son derece değerli olacaktır. Ama yapamazlar. Ya da en azından yapmıyorlar. Ve bunun denememekten ya da farkına varamamaktan kaynaklandığını düşünmüyorum. Ve bence aslında, küçük şirketler burada ne kadar üstün olduklarının farkında değiller, eğer çok daha iyi bir ürün yaratabilirlerse… büyük bir şirketin etkili bir şekilde rekabet etmesi gerçekten çok zor olacak çünkü yine, yazılımda iyi olmaya yönelik bu organizasyonel dönüşüm son derece zor.
Dan Luu, "Tam olarak yaygın olmasa da, genellikle ağır süreçler veya büyük teşvikler olmadan varlığını sürdüren mükemmellik kültürüne sahip çok sayıda küçük firma var" dedi, ancak "bu, büyük teknoloji şirketlerinde işe yaramıyor çünkü hepsi (ana akım standartlara göre) bu kadar aşırı kültürel değerleri korumanın imkansız olduğu bir aşırı büyüme döneminden geçtiler."
Kevin Yien şöyle diyor: "[organizasyon] yapınız iyi niyetli insanların sorunları çözmesini engellediğinde artık bir startup olmadığınızı bilirsiniz".
Instagram'da ürün müdürü Cemre Güngör şöyle diyor: "Büyük teknoloji şirketleri pahalı üst düzey tasarımcıları işe alıyor ancak yine de kötü tasarımla karşılaşıyorlar çünkü teşviklerde yapısal değişiklikler yapmak ve kölece ölçüm takibi yapmak çok daha zor. Zaten çoğu şirkette büyük yetenekler var. Sadece etraflarındaki organizasyon tarafından bastırılıyorlar.”
Craig Mod şunları söyledi: “… macOS'taki üç ana yazılım parçası muhtemelen Finder, Safari ve Mail'dir. Bunlardan iki tanesinin istikrarsızlık belirtileri göstermesi… çok tuhaf. Özellikle bunlar onlarca yıllık programlardaki yeni, kritik hatalar olduğunda böyle bir şeyin yaşanmaması gerekir. Bu hataların ortaya çıkmasına izin veren geliştirme döngüsünde neyin bozulduğunu merak etmenizi sağlar... bir zamanlar güvenilir olan uygulamaların özellik kayması ve şişmesinden muzdarip olduğunu görüyoruz. Belki de bu, halka açık şirketlerin doğasına özgüdür ve özelliklerin kullanıcı büyümesiyle birleştirilmesinden kaynaklanmaktadır? Örneğin: Dropbox, gelişmiş, son derece güvenilir bir dosya senkronizasyon hizmetinden, belirsiz nedenlerle işlemciyi %200'e sabitleyen şişirilmiş bir meraka dönüştü."
Financial Times'dan Tim Bradshaw şunları söyledi: "... süper bir uygulamada daha fazla özelliği bir araya getirerek yanıt veren geliştiriciler, kullanıcıların hayal kırıklığı yaşamasına neden olabilir. Tek amaçlı uygulamalarda gezinmek daha hızlı ve kolaydır. Buna karşılık, süper uygulama yaklaşımı şişirilmiş bir yazılıma mümkün olduğunca çok özelliği sıkıştırmayı içeriyor… Örneğin Spotify'ın arayüzü, podcast'ler eklediğinden beri karmaşık ve kafa karıştırıcı hale geldi… Süper uygulamalarla ilgili asıl sorunum bu: çoğu, müşteri için değil şirket için bir sorunu çözüyor.
Adam Michela, Airbnb'nin yanıltıcı fiyatlandırma tasarımı konusunda şunları söylüyor: "Sorun, Airbnb'nin ana ölçüsünün Rezervasyon Yapılan Geceler (satılan adetler) olması ve kullanıcıları temel fiyatlandırma psikolojisiyle manipüle etmenin birimleri hareket ettirmesidir. İş performansı yerine kullanıcı deneyimine öncelik vermek Jobs benzeri bir şef gerektirir."
Ada Michela ayrıca şunları söyledi: "Yüzlerce 2-200 kişilik startup'ın ürün geliştirmesine yardımcı olduk... ~30 kişilik bir anın (5-10 mühendis ve 2 tasarımcı) kalitenin en iyi noktası olduğuna rahatlıkla katılıyorum."
Fey'in kurucu ortağı Dennis Brotzky şöyle diyor: "En küçük ve en odaklı ekipler en iyi sonuçları verir. Ekibinizi küçük tutun ve onlara zaman ve özgürlük verin."
Skillshare'in kurucusu Michael Karnjanaprakorn, "ekip boyutu büyüdükçe kalite ve hızın düştüğünü" söylüyor.
Rasmus Andersson şöyle diyor: "Genel olarak konuşursak, bir yazılım ürünü üzerinde çalışan kişi sayısı ile onun kalitesi (son kullanıcı açısından) arasında ters bir korelasyon olduğuna inanıyorum".
Microsoft'ta Başbakan olan Kyle Rubenok, "en iyi iOS tasarımının günümüzde yalnızca bağımsız/küçük ekip uygulamalarında bulunduğunu" söylüyor.
Cameron Moll, "kalite ve zanaatın personel sayısı kadar ölçeklenemediğini" söylüyor.
Box Baxley şöyle diyor: "Yaratıcılığın ölçeği hakkında hiçbir şey yok ve hiçbir zaman da olmadı. Üretim ölçekleniyor. Yaratıcılık ölçeklenmiyor."
Hardik Pandya şöyle diyor: "Büyük takımlardan korkmayın. Küçük ve kararlı takımlardan korkun."
Packy McCormick şöyle diyor: "Zevk, bir şirketin kaderini belirleyecek kararsız bir şeydir. Bir noktada büyüme baskıları, her ayrıntının mükemmel olmasını, her işe alınanın harika olmasını sağlamanın önüne geçebilir. Güven gibi zevki de inşa etmek bir ömür, yok etmek birkaç dakika alır."
Jasmine Friedl şöyle dedi: "Bu [kalite ölçümleri] işimize yarasa da, bunun küçük ekibimizi çok fazla aşamayacağını kabul ettik; örneğin, her gün gönderi yapan yüzlerce tasarımcıdan oluşan bir ekip, manuel incelemeler için muhtemelen bant genişliğine sahip olmayacaktır."
Paul Stamatiou, içinde bazı mücevherler bulunan zanaat hakkında bir makale yazdı:
"Kaliteli ürünler oluşturmanın zorluğu burada ortaya çıkıyor. Daha hızlı nakliye ile daha iyi nakliye arasındaki sürekli gerginlik. "Gönder, sonra yinele" döngüsüne düşmek bir tuzaktır. ... Bazı şeyler olur ve hayal ettiğiniz "hızlı takip eden" V1.1 sürümü veya V2.0 muhtemelen olmayacak. Her zaman işleri alt üst eden ve tüm planları değiştiren yeni parlak bir girişim, yeniden yapılanma veya yeni bir liderlik işe alımı vardır. Temizlemek için gelecekteki bir sürüme güvenmeyin bugünün karmaşası." "Kaliteye yönelik destek tepeden gelmezse, IC'lerin sorunları atlamaları ve raporlama zincirlerinin fark etmeyeceğini düşündükleri ayrıntılara biraz daha az dikkat etmeleri çok kolay olur."
1995 yılında "Triumph of the Nerds" adlı televizyon programına verdiği bir röportajda Steve Jobs şunları söyledi: "Aynı şeyin IBM veya Xerox gibi tekelleşen teknoloji şirketlerinde de olabileceği ortaya çıktı. IBM veya Xerox'ta ürün uzmanı olsaydınız, bu yüzden daha iyi bir fotokopi makinesi veya bilgisayar yapardınız. Ne olmuş yani? Tekel pazar payına sahip olduğunuzda şirket artık başarılı olmuyor. Yani şirketi daha başarılı kılabilecek kişiler satış ve pazarlama çalışanlarıdır ve sonunda şirketleri yönetirler. Ve ürün insanları karar alma forumlarından uzaklaştırılıyor ve şirketler harika ürünler yaratmanın ne anlama geldiğini unutuyor. Onları bu tekelci konuma getiren ürün duyarlılığı ve ürün dehası, iyi bir ürün ile kötü bir ürün arasında hiçbir anlayışa sahip olmayan bu şirketleri yöneten insanlar tarafından çürütülüyor. İyi bir fikri alıp onu iyi bir ürüne dönüştürmek konusunda hiçbir anlayışa sahip değiller.
Gergely Orosz şöyle diyor: "[Büyük bir teknoloji şirketinde] çok az sayıda kişi ve ekip, kullanıcıların %0,002'sini etkileyen düşük etkili sorunları düzelttikleri için ödüllendiriliyor. Ayrıca çok azı bunu yapmadığı için cezalandırılıyor. Herhangi bir Büyük Teknoloji'de, promosyonları ve performans incelemelerini teşvik eden teşvikler, şaşırtıcı derecede büyük miktarda karar alınmasına yol açıyor. Bu teşviklerin çoğu etki, geniş ölçekte gelir yaratma ve geniş ölçekte tasarruftur. Küçük sorunları düzeltmek bunların hiçbirine uymaz. Aslında, tek seferlik sorunları düzeltmek, en önemli sorunlardan biridir. yapılacak pahalı şeyler. Bu, kârları düşürür ve düşürür de.
Dan Luu şöyle diyor: "Ciddi teknik değerlendirmeler olmadan alınan teknik kararların yaygınlığı, şirketler üzerindeki iyi ürünler üretme yönündeki seçim baskısının bu kadar zayıf olmasının önemli bir nedenidir. Biraz baskı var, ancak başarılı şirketlerin genellikle işe yarayan bir ürün yapmak için dolaşması yeterince gürültülü, tıpkı yukarıdan Mongo örneğinde olduğu gibi, burada Mongo'nun açıkça sahte performans iddialarını yüksek sesle tekrarlama ve bariz şekilde yanlış doğruluk iddialarında bulunma kararı, iş açısından bakıldığında, odaklanmaktan daha üstündü. g fiili doğruluk ve performans hakkında; Kaynaklarını iş açısından önemli olan yerlere odaklayarak, ciddi kaynakları performansa ve doğruluğa ayırma hatasına düşen şirketleri geride bırakmayı başardılar.”
Arvind Narayanan şöyle diyor: "Bazı ürünler doğrudan son kullanıcıya satılıyor ve kullanılabilirliğe öncelik verilmesi gerekiyor. Diğer ürünler, endişeleri genellikle kullanıcının ihtiyaçlarından farklı olan bir aracıya satılır. Bu tür ürünlerin kullanılamaz çöp olarak sonuçlanması ZORUNLU DEĞİLDİR, ancak genellikle öyle olur.
Nick Lockwood şöyle diyor: “Gelişme, çabanın katlanarak arttığı Zeno paradoksuna benziyor. Aslında hiçbir zaman tamamlanmaya ulaşamazsınız, sadece ona daha da yaklaşırsınız, her birim çaba sizi biraz daha yakınlaştırır… bu gerçek, her özellik için *kesinlikle* geçerlidir. Bir ürünün yaşam döngüsünün herhangi bir noktasında, küçük bir hatayı veya kağıt kesiği düzeltmek, büyük bir yeni özelliği uygulamaya koymakla (veya daha doğrusu, son birkaç hata ve kağıt kesikleri hariç %80'ini uygulamakla) aynı (veya daha fazla) çaba olacaktır."
Alexandr Wang şöyle diyor: “Mühendisliğin sezgisel gerçeği: Büyük ekipler (>8 kişi) küçük ekiplerden daha az nakliye yapıyor. Sadece kişi başına daha az değil, genel olarak daha az!”
Dan Luu, Twitter'da şunları söyledi: "... büyük şirketlerde konuştuğum en yüksek etkiye sahip/en etkili kişilerin hepsinden duyduğum bir fikir: Büyük bir fark yaratabilirsiniz, ancak sürekli olarak kendi kendini sabote eden bir organizasyonla mücadele ediyorsunuz".
Cory Doctorow, Tiktok'un saçmaladığı makalesinde şunları söyledi: "Platformlar şu şekilde ölüyor: Birincisi, kullanıcılarına iyi geliyorlar; daha sonra ticari müşterileri için işleri daha iyi hale getirmek amacıyla kullanıcılarını kötüye kullanırlar; Sonunda, tüm değeri kendilerine geri almak için bu ticari müşterileri istismar ediyorlar. Sonra ölürler”.
George Kedenburg III bu konuyla ilgili "Zanaatın Maliyeti" başlıklı bir makale yazdı:
“Zamanla Instagram büyümeye ve gelişmeye devam etti. Ürün daha fazla rakip ve çalışan biriktirdikçe büyüdü ve karmaşıklaştı. Üç yıl geçti ve bunun, Facebook'tan kaçmak için ayrıldığım ortama giderek daha çok benzemeye başladığını fark ettim; ölçümlerin ve büyümenin, insanların sevdiği deneyimler yaratmaktan daha önemli olduğu bir yer." “Tüm dijital ürünlerin eninde sonunda ölçek için zanaattan vazgeçmesi kaçınılmaz görünüyor.” "Her ilave kişiyle zanaatın maliyeti artıyor." "Aradığım gizli sos gerçekten büyüklük ve yeteneğin mükemmel bir karışımıydı... 10 kişiyi uyum içinde tutmak 10.000 kişiyi uyum içinde tutmaktan çok daha kolay. Her ilave kişi, herkesin odaklanmasını ve senkronize kalmasını zorlaştırıyor."
Patrick McKenzie şunları yazdı: "...yazılım şirketleri büyüdükçe... nispeten basit yazılımların yapılmasını giderek zorlaştırıyorlar, bu da şaşırtıcı sonuçlara yol açıyor... Sadece bir açılış sayfasına ihtiyacınız var, ancak bir açılış sayfası oluşturma süreci dörtte üçü teslim süresi ve on altı inceleme gerektirir ve Hizmet Olarak Açılış Sayfası bir satın alma kartına sığar ve iki saat sürer..."
Adam Stoddard, geniş ölçekte zanaat hakkında yazdı ve şunları söyledi: "Finanse edilen start-up'ların ve halka açık teknoloji şirketlerinin, yüksek büyüme motorunu çalışır durumda tutması gerekiyor, bu da kaçınılmaz olarak giderek daha fazla kullanıcı çekmeye çalışan giderek daha büyük ve daha karmaşık ürün tekliflerine yol açıyor. Hiçbir ekip bunu tek başına başaramaz; bu da doğrudan birbirinden kopuk ve/veya rakip ekiplere ve süreç tarafından doldurulan sürekli bir vizyon erozyonuna yol açar."
Joel Beukelman şunları söyledi: "Google'da yaklaşık 8 yıl çalıştıktan sonra, geniş ölçekteki ürünlere derin bir saygı duyuyorum, ancak benim 0,02 dolarım, bir ekip çok büyüdüğünde bir miktar ışıltı kaybı oluyor."
Ürün ve Mühendislik Direktörü Claire Vo bu konu hakkında bir yazı yazdı. Bazı alıntılar:
"Ekibinizin boyutunu ve ölçeğini büyütmeyle ilgili hemen hemen her şeyin, en önemli şey üzerinde anında ve zararlı etkileri vardır: harika ürünler oluşturmak." “… yüksek ölçekli ve güvenilir teslimat için toplantılar, süreç, politika ve işletim modelleri gereklidir VE YİNE de bu şeylerin en kötü etkilerini şirketlerinden aktif ve agresif bir şekilde ayıklamayı unutan ekipler, kısa süre sonra bundan pişman olacaktır.”
Linear'ın kurucu ortağı Karri Saarinen kalite hakkında bir yazı yazdı ve şunları söyledi: "Şirketler büyüdükçe kalite konusunda çoğu zaman zorluk yaşarlar ve genellikle kaliteden vazgeçerler. Bunun temel nedeni, kalitenin kolayca ölçülemeyen veya tanımlanamayan bir şey olmasıdır. Şirketler ölçeklendikçe çalışma veya karar verme biçimleri daha çok ölçümlere dayalı oluyor."
Linear ile kalite hakkında yapılan bir sohbette Dick Costolo şunları söyledi: "En iyi ürün ekipleri, mümkün olduğu kadar küçük kalacaktır. olası. Her geçen gün daha fazla insanı işin içine kattıkça, ürünün geleceğin ne olabileceğine dair tekil ve basit bir vizyonun sonucu gibi görünmesi ve hissettirmesi çok zorlaşıyor."
Özel kalite çabalarına sahip şirketler
Birçok şirket kaliteye önem verdiklerini ancak bu konuda özel bir çaba göstermediklerini söylüyor. İşte bunu yapanlardan bazıları.
Automattic'te bir Kalite Direktörü görev yapmaktadır. Lance Willett'in bana rol hakkında söyledikleri şunlar:
Hem büyük resme (strateji: kültür, zihniyet, tutarlılık) hem de günlük ayrıntılara (yürütme: hata düzeltme, otomatik test ve kalite ölçümleri) dikkat ediyorum. Teknik kalite için kültür değişimini yönlendirmeye yardımcı olmak için üst düzey yönetici olarak oturuyorum, temel kalite ölçümleri hakkında CEO'ya ve yönetim kurulumuza rapor veriyorum (düşünün: Core 4) ve aynı zamanda uygulamalı QualityOps ekibine liderlik ediyorum. Rolüme, tüm ortamı göz önünde bulundurarak herhangi bir üründe/uygulamada yazılım değişikliklerini kendim gönderebilen bir "tam yığın lideri" olarak yaklaşıyorum. Lance Willett, Automattic Kalite Direktörü
Lance'in rolü hakkında daha fazla bilgiyi buradan edinebilirsiniz.
GitLab'ın bir "UX Paper Cuts" ekibi var ve bunu şu şekilde tanımlıyorlar:
UX Paper Cuts ekibinin benzersiz bir kapsamı vardır; GitLab ürünü genelinde küçük ama etkili kullanılabilirlik sorunlarını belirlemek ve düzeltmekten sorumluyuz… Varsayılan olarak, UX Paper Cuts ekibi yeni özellik çalışması üstlenmez ve ekip başka bir Grup için kaynak olarak kullanılmaz. Bunun yerine ekip, ürünün tamamında kullanılabilirlik ve erişilebilirlik sorunlarına, tasarım tutarsızlıklarına ve güncel olmayan kullanıcı arayüzüne odaklanıyor. https://about.gitlab.com/direction/foundations/ux-paper-cuts/
HubSpot bir “Uyum Stüdyosu” oluşturdu ve bunu şu şekilde tanımlıyor:
Cohesion Studio, HubSpot genelinde kullanıcı deneyimini iyileştirmeye, ürünlerimizin kullanımını daha hızlı ve daha kolay hale getirmeye odaklanmıştır. Bu ekip, tasarım sistemi ekibi ile ürün ekiplerimiz arasında yatay bir katman olarak çalışır. Bu ekibin görevi HubSpot'un uçtan uca yolculuklarını değerlendirmek, takip etmek ve birleştirmektir. https://www.linkedin.com/posts/hayhughes_im-excited-to-be-hiring-principal-product-activity-7216988238492704768-JsEm
Linear'ın 2022'de arayüz tasarımını iyileştirmeye ayırdığı bir ay vardı: "Yılın geri kalanında tek odak noktamız cilalama olacak. Yeni özellik çalışması yok, yalnızca yaşam kalitesinde iyileştirmeler var."
Ayrıca hata düzeltmeleriyle ilgili kalıcı bir politikaları vardır:
Birkaç ay önce Linear'da hataları giderme şeklimizi değiştirdik. Hatalara diğer her şeyin üstünde öncelik verdik. Sabah uyandığınızda atanmış hatalarınız varsa, bunlar giderilmeden önce başka hiçbir şey yapmazsınız. https://x.com/artman/status/1825809356228555031
Son olarak, hata olmayan değişiklikler için "Kaliteli Çarşamba günleri" vardır:
Biraz daha iyi çalışabilecek şeyler için ayrı bir devam eden sürecimiz var. Her ekip üyesinin, önceki hafta üründe biraz iyileştirdiği en az bir şeyi sergilediği kaliteli çarşambalarımız var. https://x.com/artman/status/1825812042072121544
Ron Goldin ve Meta'daki diğer bazı kişiler kalite ölçümlerini tanıttı:
Meta'dayken, bazı meslektaşlarım ve ben, diğer şeylerin yanı sıra önemli yolculuklarımız için sayısal bir Craft puanını tanımlamaya, ölçmeye, ölçmeye ve raporlamaya çalıştığımız bir "Kalite" programı kuracak kadar ileri gittik. https://rongoldin.substack.com/p/third-kinds-of-design-craft
Windows 11'in kalitesiyle ilgili kamuoyunun tepkisinin ardından Microsoft, aşağıdakileri geliştirmek için özel bir çaba gösterdiğini duyurdu:
Performansa, güvenilirliğe ve iyi tasarlanmış deneyimlere odaklanarak bu yıl Windows 11 kalitesinde çıtayı yükseltme planımız aşağıda yer almaktadır. Bu alanların Windows'u nasıl deneyimlediğiniz üzerinde anlamlı bir etkisi vardır: ne kadar hızlı başlatılıp yanıt verdiği, gerçek iş yükleri altında ne kadar kararlı olduğu ve deneyimin ne kadar tutarlı ve düşünceli hissettirdiği. https://blogs.windows.com/windows-insider/2026/03/20/our-commitment-to-windows-quality/
Operate'te Give a Damn™ girişimini yeni başlattık; ayrıntılarla uğraşmaya zaman ayırdık. https://x.com/joebell_/status/1951290350313566514
Shopify kaliteye odaklanmak için bir ekip kurdu:
… bazen kaliteye özel olarak odaklanmak için alana ihtiyaç duyarsınız. Shopify'daki yeni ekibin yaptığı da tam olarak bu. Ekibimiz Shopify yöneticisine yatay olarak bakmaya odaklanmıştır… Görsel tasarım ayrıntılarının ayarlanmasından sayfaların veya bileşenlerin temelden yeniden yapılandırılmasına kadar kalite sorunlarını ele alıyoruz. https://ux.shopify.com/how-we-think-about-ux-quality-428d6607f4c6
Sonos bir kişi atadı “kaliteli ombudsman”.
Yeni bir rol yaratıyoruz: Kalite Ombudsmanı. Bu kişi, çalışanların kalite ve müşteri deneyimiyle ilgili endişelerini dile getirmeleri için açık bir yola sahip olmalarını sağlayacaktır. Ombudsperson doğrudan üst düzey liderliğe rapor verecek, yılda iki kez rapor yayınlayacak ve düzenli olarak Sonos yönetim kuruluna sunum yapacak. https://www.sonos.com/en-us/blog/commitments
Stripe, Malthe Sigurdsson'u "Zanaat Şefi" olarak işe aldı:
Zanaat, güzellik ve kaliteye odaklanmaya devam etmemize yardımcı olmak için Katie Dill'in ekibinde "El Sanatları Başkanı" olarak Stripe'a geri dönüyorum. https://x.com/malthe/status/1796219917806760092
Zed'in yılda iki kez "kalite haftası" vardır. Web sitelerinde bunu nasıl tanımlıyorlar:
… periyodik olarak "Kalite Haftası" dediğimiz etkinlikleri düzenliyoruz. Bu süre zarfında, özellik eklemeleri üzerindeki çalışmayı durduruyoruz ve Zed'de yalnızca kullanıcıların sıkıntı yaşadığı noktalar üzerinde çalışmaya dönüyoruz… Az miktardaki çalışma ile potansiyel olarak büyük etkiyi dengelemeye çalışan sorunları bulmaya odaklanıyoruz. Zed'in paniğe kapılabileceği durumları azaltmaya öncelik veriyoruz. Kalite Haftasının genel hedefi daha istikrarlı ve rafine bir Zed sunmaktır. https://zed.dev/faq#quality-week
Arayüz yaşam kalitesi iyileştirmeleri
İşte bir arayüzde yapabileceğiniz bazı yaşam kalitesi iyileştirmeleri.
Fare her zaman kendi sınırları içinde değilse menünün kapanmadığı, iç içe menülerdeki cömert fare yolları. Yanlış tuşa bastığınız anda çoklu tuş kısayolunun iptal edilmediği klavye kısayolları için çakal zamanı. Birisinin listenin sonuna ulaştığını göstermeye yardımcı olmak için kayan liste görünümlerinde uzatma/sıçrama hareket efektleri. Genişleyen ve daraltılan tüm öğeler için sorunsuz ve hızlı genişletme ve daraltma animasyonları (animasyon olmamasının aksine). Genişletme ve daraltma animasyonlarını, animasyonu tetikleyen öğenin yönünden başlatmak, böylece sanki o öğeden uzağa doğru genişliyormuş gibi hissettirir. Bir yerden diğerine hareket eden öğeler için akıcı ve hızlı animasyonlu hareket (animasyonun olmamasının aksine). Görüşünüzün kenarındaki öğelerin ortaya çıktığını veya değiştiğini size bildiren animasyon. Menüler ve diğer açılır öğeler anında açılır ancak kaybolmaları biraz daha uzun sürer. Görsel olarak dengesiz öğelerin optik olarak ayarlanması, böylece düzgün hizalanmış görünmeleri sağlanır. Metin içeren bir öğe "düzenleme" moduna değiştirilirse, metni mod değiştikçe aynı yerde tutun. Etkileşimin amacı bu olmadığı sürece, öğeleri, o öğenin yakınında veya onunla etkileşimin sonucu olarak hareket ettirmeyin. Bir listeye öğeler eklenir veya listeden çıkarılırsa öğelerin görsel olarak aynı yerde kalması için öznel kaydırma konumunu koruyun. Menü eylemlerinin imlece göre her zaman aynı yerde olması için bağlam menülerini açın. Cep telefonlarında seçilen alan için doğru klavye türünü açın. Bir şeye tıklamak, farenin bulunduğu yerde yeni bir arayüz açarsa, kişinin kazara tekrar tıklaması ihtimaline karşı, mevcut fare imleci konumunun altına riskli bir şey koymayın. Nesne kalıcılığı: Birden fazla görünümde yer alan öğeler, hareket etseler veya şekil/boyut değiştirseler bile bir görünümden diğerine geçişler boyunca varlığını sürdürür. Açıkça talep edilmediği sürece kişinin girdiği bilgiler, o kişinin ekrandan ayrılması durumunda asla kaybolmaz. Hareketli bir öğenin (örneğin, kaydırılabilir yatay bir konteyner yığını) doğal konumları varsa, onu bu konumlara oturtun. Bir şeyde yapılan değişiklikleri gerçek zamanlı olarak gösterin veya öğe görünmüyorsa, seçenekler değiştikçe değişikliklerin önizlemesini gösterin. Açılışı geciktirme örn. bir araç ipucu, ancak fare daha sonra bir araç ipucuna sahip olan komşu bir öğeye hareket ederse, yeni araç ipucunu anında gösterin.
[← anthonyhobday.com]
