Amazon, AWS ile farklı bir müşteri ihtiyacını nasıl iş modeline dönüştürdü?

Amazon, S3’ün 2006 lansmanında kendi web ağı için kullandığı ölçeklenebilir depolama imkanını yazılım geliştiricilerinin erişebileceği bir hizmet olarak sundu. Farklı müşteri ihtiyacı, içerik depolamak için altyapıyı baştan kurmak zorunda kalmamak. Ofise taşınabilecek öğrenim, içeride iyi yaptığınız bir işin başka kişiye de değer sağlayıp sağlamadığını araştırmak. Ancak çalışan bir iç çözüm, açıklama ve destek hazırlanmadan otomatik olarak hizmete dönüşmez.

Bir ekip tekrar eden sorunu çözer ve işe yarayan küçük bir düzen kurar. Diğer ekip de benzer sorun yaşar. Paylaşım fırsatı buradadır; fakat ilk ekibin bildiği ayrıntılar ikinci ekip için açık olmayabilir.

S3’ün 2006 lansmanı ne sunuyordu?

Amazon’un 14 Mart 2006 açıklaması, S3’ü geliştiricilere depolama altyapısı sağlayan hizmet olarak duyuruyor. Amazon’un kendi ağı için kullandığı ölçeklenebilir altyapıya erişim ve basit hizmet arayüzü vurgulanıyor. Tasarımın sınırlı özelliklerle sadelik ve güvenilirliğe odaklandığı belirtiliyor.

Bu tarihli bir lansman anlatımı; bugünkü hizmetin bütün özellikleri veya fiyatları değildir. Vakanın önemli tarafı kapasitenin yeni kullanıcı ihtiyacına açık biçimde sunulması. İçeride işe yarayan bir imkan, dışarıda kullanılabilir bir hizmete dönüştürülüyor.

Birinci öğrenim: Çözümün altındaki ortak sorunu bulun

Bir dosya veya araç hazırladığınızda benzer sorun başka yerde de olabilir. Ama aynı aracın adını duymak yeterli değildir. Hangi problem çözüldü ve hangi koşulda işe yaradı? Bu bilgiyi açın.

Örneğin tedarikçi karşılaştırma tablonuz yalnız belirli ürünlerde işe yarıyor olabilir. Başka ekip için aynı tabloyu paylaşmadan önce onların kararını öğrenin. Ürün türü, kontrol ve veri kaynağı değişiyorsa eski çözümün bir bölümü kullanılabilir, diğer bölümü değişmelidir.

Çözümü kendi ekibinizin terimleriyle anlatmak yeni kullanıcıyı zorlayabilir. Ortak problemi günlük dille açıklayın. Araç özelliklerinden önce kişinin hangi işi yapacağını söyleyin. Böylece paylaşım, dosya dağıtmak değil ihtiyaç çözmek olur.

İkinci öğrenim: İlk kullanım için gizli bilgiyi açığa çıkarın

İç ekip bir dosyanın hangi alanını değiştirmemesi gerektiğini bilir. Yeni kullanıcı bunu bilmiyorsa formülü bozabilir. Normal veriyi ve istisnayı ayıran bilgi açıklamada görünür olmalı.

Doldurulmuş küçük örnek hazırlayın. Beklenen giriş, sonuç ve kontrolü gösterin. Açıklaması olmayan boş şablon, kullanıcının kendi tahminiyle hareket etmesine neden olabilir. Hazırlayan kişi yanında olmadan kullanımı sınayın.

Standart iş talimatı yazma yaklaşımı, başlangıç koşulu ve istisnayı görünür hale getirir. Fakat talimatın uzun olması başarı değildir; kullanıcı gerçek görevde gereken bilgiyi bulabilmeli.

Üçüncü öğrenim: Hizmetin bakımını da düşünün

İç çözümü başkalarına açınca destek soruları ve değişiklik ihtiyacı artabilir. Şablonu hazırlayan kişinin işi bu yeni yükü taşıyacak mı? Güncel sürümü kim koruyacak? Bunları ilk paylaşımdan önce konuşun.

Her kullanıcı için ayrı kopya düzenlerseniz bakım zorlaşabilir. Ortak ihtiyaçları ve özel gereklilikleri ayırın. Tek bir çekirdek düzeni koruyup gerçekten farklı olan bölümü açıklamak daha kullanışlı olabilir.

Kullanım sınırlarını açık yazın. Verinin türü, erişim koşulu ve geçerli onay düzeni değişiyorsa yeni kullanıcı bunları bilmeli. İçeride izinli olan bir bilgiyi başka gruba otomatik taşımayın. Ortak dosya izinlerini mevcut şirket düzenine göre koruyun.

İç çözümün varsayımlarını görünür yapın

Bir ekip hazırladığı tabloyu kullanırken hangi kaynağın güvenilir olduğunu bilir. Yeni ekip aynı bilgiyi bilmiyorsa yanlış veriyi doğru kabul edebilir. Paylaşım açıklamasında dosyanın altında kalan varsayımları ortaya çıkarın. Dönem, kapsam ve geçerli kaynak belirtilsin.

Yeni kullanıcının ihtiyaç duyduğu değişikliği hemen şablona eklemeyin. Ortak ihtiyaç mı, tek dosyaya özel durum mu? Her istek çekirdek düzeni büyütürse diğer kullanıcılar için zorlaşabilir. Özel değerlendirme gereken alanı ayırmak bazen daha uygundur.

Hizmetin sahibini de tanımlayın. Şablonu kim düzeltecek, yeni sürüm nasıl duyurulacak ve eski örnekler ne olacak? Sürüm değişince bütün kullanıcılar aynı anda güncellemeyebilir. Yanlış kullanımın kaynağı bu geçiş olabilir. Destek notunda hangi sürümün sorulduğu belli olsun. Böylece iç kapasiteyi paylaşırken bilgi ve bakım ilişkisi de paylaşılır. Dosya tek başına değil, anlaşılır kullanım koşullarıyla birlikte değer sağlar.

Ofiste doldurulmuş hizmete dönüşüm örneği

Şöyle bir durum düşünün: Satın alma ekibiniz teklifleri toplam maliyet üzerinden karşılaştıran bir tablo kurdu. Başka departmanlar da kullanmak istiyor. Siz paylaşım planını hazırlıyorsunuz.

Yeni kullanıcıya sadece dosyayı göndermeyin. Bir örneği kendi başına yapmasını isteyin. Hangi alanı yanlış anlıyor, hangi maliyeti eklemeyi unutuyor? Bu gözlemler paylaşımın ne kadar hazır olduğunu gösterir.

Örnek sonrasında tabloyu sınırsız talebe açmak yerine uygun kullanım alanlarını belirtin. Yeni ihtiyacın ortak şablona eklenmesi mi, ayrı uzman değerlendirmesi mi gerektiğini düşünün. Her sorunun tabloyla çözülmesi beklenmez.

İç hizmetin değerini nasıl görebilirsiniz?

Dosyanın kaç kez indirildiği başlangıç bilgisi verir. Ama kullanıcı doğru karşılaştırmayı yaptı mı, eksik koşulu fark etti mi ve son kararı uygun kişiye taşıdı mı? Bunlar gerçek görevle daha yakından ilgilidir.

Sık gelen destek sorularını ayrı listeleyin. Aynı alan sürekli yanlış anlaşılıyorsa açıklamayı veya düzeni değiştirin. Her seferinde kişisel mesajla düzeltmek, paylaşımın kalıcı sorununu gizleyebilir. Bir işi çalışma arkadaşınıza öğretme yazısı bağımsız kullanımın nasıl sınanacağını anlatır.

Amazon S3 vakası size her iç aracı yeni işletmeye dönüştürmeyi önermez. Tekrarlayan bir kapasitenin başka kullanıcının ihtiyacını karşılayabileceğini düşündürür. İhtiyacı, kullanım koşulunu ve destek yükünü birlikte değerlendirmek daha iyi paylaşım kararı verir.

Bu tür problem çözme ve anlatma yetenekleri için kariyer gelişim kursunun programını inceleyebilirsiniz.

Sık sorulan sorular

S3 lansmanı bütün AWS hizmetlerinin başlangıcı mı?

Bu yazı 2006 S3 lansmanını inceliyor. AWS’nin bütün ürün tarihçesini tek olay olarak anlatmıyor. Tarihli depolama hizmeti, kapasiteyi başka kullanıcıya sunma örneği olarak ele alınıyor.

İçeride çalışan araç başka ekipte de işe yarar mı?

Olabilir, fakat ihtiyaç ve koşullar karşılaştırılmalıdır. Aynı isimli görev farklı veri ve kontrol gerektirebilir. Küçük bir örnekle kullanımı sınamak, doğrudan kopyalamaktan daha yararlıdır.

Yeni hizmet için ilk ne hazırlanmalı?

Kullanıcının ilk görevi, gerekli giriş ve kontrol. Bunun yanında güncel kaynak ve yardım noktası belirtilmelidir. Özellik listesinden önce kullanımın nasıl başlayacağını açıklayın. İş talimatı kullanım koşulu ve kontrolü açıklamak için yararlıdır.

Paylaşımın başarılı olduğu nasıl anlaşılır?

Kullanıcının işi doğru tamamlayabilmesi ve gerekli durumda yardım alabilmesiyle. İndirme sayısı veya beğeni tek başına yeterli değildir. Bakım ve destek yükünü de birlikte değerlendirin.