Slack, Glitch oyunu için çalışan ekibin kendi iletişim sorununu çözmek üzere geliştirdiği araçtan doğdu. Oyun sürdürülemediğinde ekip, bütün emeği kayıp saymak yerine günlük çalışmada değer sağlayan bu parçayı bağımsız ürün olarak değerlendirdi. Öğrenim, her başarısız projede gizli bir başarı bulunduğu değil. Eski hedefle ortaya çıkan araç, bilgi veya çalışma biçimini ayrı inceleyebilmek. Sizin tamamlanmayan bir işinizde de başka bir kullanıcıya yardım eden parça olabilir; bunu yeniden yatırım yapmadan önce sınamanız gerekir.
Oyun kapanırken hangi değer kaldı?
Slack’in kurucu ortağı Stewart Butterfield, 21 Ağustos 2013 tarihli röportajında Glitch üzerinde farklı şehirlerden çalışan ekibin kendi iletişim sistemini kurduğunu anlatıyor. Bu sistem mesajlaşmanın yanında iş bilgilerini, uyarıları ve destek kayıtlarını da bir araya getiriyordu.
Oyun sonlandırıldığında ekip bu çalışma biçiminden vazgeçmek istemedi. Kendi kullandıkları aracı başkalarının da kullanabileceği bir ürüne dönüştürmeyi seçtiler. Slack’in sonraki resmi anlatımı da Glitch’i şirketin kuruluş hikayesinin parçası olarak anıyor. Bu tarihli karar, her ürün değişiminin başarılı olacağını göstermez; belirli bir ekibin yeni bir ihtiyacı görmesini anlatır.
Burada ilginç nokta, ilk projenin başarısıyla ikinci ürünün değerinin aynı soru olmaması. Oyun müşterisiyle iş iletişimi müşterisi farklıydı. İçeride çalışan bir çözümün dışarıda ürün olabilmesi için yeni kullanıcı ihtiyacı ayrıca anlaşılmalıydı.
İlk öğrenim: Proje hedefini ve birikimi ayırın
Bir projeyi durdurmak, o projede öğrenilenlerin bütünüyle değersiz olduğu anlamına gelmez. Aynı zamanda bir şey öğrenmiş olmak, projeyi sürdürmek için yeterli gerekçe değildir. Bu iki yargı birlikte doğru olabilir. Bir hedefe ulaşamamışsınızdır, fakat tekrar kullanılabilecek bir araç geliştirmişsinizdir.
Bu ayrımı yapmak için projenin parçalarını isimlendirin. Hangi dosya yalnız bu müşteriye özgü? Hangi kontrol listesi başka işte de kullanılıyor? Hangi araştırma verisinin paylaşım izni var? Birikimi ayırırken hukuki hakları ve kurumun bilgi sınırlarını atlamayın.
Geçmiş emeğe duyulan bağlılık kolayca yeni denemeyi gereğinden fazla büyütebilir. “Bu kadar uğraştık, devam edelim” yerine yeni parçanın gelecekteki faydasını düşünün. Batık maliyet yanılgısı bu noktada eski harcamayla yeni kararı ayırmanıza yardımcı olur.
İkinci öğrenim: İç kullanıcı memnuniyeti ilk işarettir
Ekibin bir aracı her gün kullanması güçlü bir gözlemdir, ama herkesin aynı ihtiyacı olduğunu kanıtlamaz. Aracın işe yaraması, özel veri erişimine veya ekibin alışkanlığına bağlı olabilir. Dışarıdaki kullanıcı bunu bilmeden kullanabilecek mi? Aynı soruna gerçekten zaman veya para harcıyor mu?
Yeni kullanıcıya bütün ürünü anlatmak yerine işini anlamakla başlayın. Son benzer görevi nasıl yaptığını sorun. Hangi bilgi kayboldu, kimden tekrar istedi, nerede bekledi? Kendi çözümünüzü hemen övmek, karşı tarafın gerçek sorununu duymanızı zorlaştırabilir.
Sonra dar bir kullanımı deneyin. Örneğin bir dosya bulma aracı geliştirdiyseniz ilk denemeyi başka ekibin tek bir arşivinde yapabilirsiniz. Kullanıcıya yalnız memnuniyet sorusu yöneltmeyin. Dosyayı bulabildi mi, yanlış sürümü mü açtı, yeni düzeni sürdürmek için fazladan iş yaptı mı? Kullanımın bütünü önemli.
Üçüncü öğrenim: Yeni ürün eski projenin devamı değildir
Bir parçayı yeniden kullanmak, bütün eski özellikleri taşımayı gerektirmez. Hatta eski projenin ayrıntıları yeni kullanıcı için yük olabilir. Yeni ürünün neyi çözmeyeceğini belirlemek, neyi çözeceği kadar değerli olur. Gereksiz kapsamı erken sınırlayın.
Kurum içi bir şablonu farklı departmana açarken de aynı durum yaşanır. Her hücrenin açıklaması yoksa yalnız ilk ekibin bildiği kısaltmalar sorun oluşturur. İkinci kullanıcı için gereken destek, ilk sürümden farklıdır. Bu farkı kullanım sırasında öğrenmek gerekir.
- Parçayı ayırın
Biten projede tekrar kullanılan bir araç veya bilgiyi seçin.
- İhtiyacı sınayın
Başka bir ekibin aynı sorunla karşılaşıp karşılaşmadığını öğrenin.
- Küçük deneyin
Dış kullanıcıyla kısa ve bağımsız bir uygulama yapın.
İptal edilen toplantı projesinden kalan araç
Şöyle bir durum düşünün: Bir ekip, büyük müşteri etkinliği için konuşmacı ve onayları takip eden bir dosya hazırladı. Etkinlik iptal edildi. Dosyanın etkinliğe özgü davet listesi artık kullanılmıyor, fakat kimin hangi bilgiyi onayladığını gösteren bölüm satın alma ekibinin de işine yarayabilir.
Önce taşınabilecek parçayı ayırıyorsunuz: belge adı, kontrol sahibi, son görüş ve açık karar. Kişisel katılımcı bilgileriyle etkinlik bütçesini yeni denemeye taşımıyorsunuz. Dosyanın sahibi ve paylaşım izni netleştiriliyor. Yeni kullanım için aracı sadeleştirmenin ilk adımı bu sınırları öğrenmek oluyor.
Satın alma ekibinden bir çalışanla son sözleşme kontrolünü inceliyorsunuz. Onay mesajlarının farklı yazışmalarda kaldığını öğrenirseniz dosyadaki takip kısmı bir aday çözüm olur. Sorun buysa küçük bir sözleşme akışında deneyebilirsiniz. Sorun aslında yetkili kişinin bulunmamasıysa yeni tablo tek başına yardımcı olmayabilir.
Deneme notunuz şöyle olabilir: “Kullanım: tek yenileme dosyasının görüş takibi. Hariç: ödeme ve kişisel bilgi. Kontrol: yanlış belge sürümü veya belirsiz onay var mı? Karar: deneme sonunda devam, değişiklik veya bırakma.” Bu yaklaşım, dosyayı hemen şirket standardı ilan etmez. Dosyayı güncelleyecek kişinin zamanı da hesaba katılır. Yeni kullanıcı aracı faydalı bulsa bile her değişiklik için ilk ekibe dönüyorsa gerekli açıklama veya bakım düzeni henüz tamamlanmamış olabilir.
Yeni ekibin verdiği görüşlere göre gereksiz alanları çıkarın. İlk kullanıcıların sevdiği bir ayrıntıyı yeni kullanıcının istememesi başarısızlık değildir. Çözümün farklı bir ihtiyaca uyarlanmasıdır. Standart iş talimatı yazma yazısı, deneme olgunlaştığında gerekli açıklamaları düzenlemenize yardım edebilir.
Son aşamada yapılan işi öğrenim olarak kaydedin. Büyük proje iptal olmuş olsa bile problem tespiti, deneme ve sadeleştirme çalışması sizin gelişiminizi gösterebilir. Bunu abartılı bir başarı öyküsüne çevirmeden somut örneklerle anlatın. İş örnekleri üzerinden gelişiminizi düşünmek için kariyer gelişim kursunun programını inceleyebilirsiniz.
Sık sorulan sorular
Her başarısız projeden yeni ürün çıkar mı?
Hayır. Bazı projelerde yeniden kullanılacak değer olmayabilir. Araç veya bilgi olması da dış talebi kanıtlamaz. Önce başka kullanıcının ihtiyacını kontrol edin; yalnız eski emeği kurtarmak için yeni yatırım yapmayın.
İçeride kullanılan dosyayı dışarıya satabilir miyim?
Kurumun hakları, veri izinleri ve sözleşmeler kontrol edilmeden böyle bir adım atılmamalı. Genel hikaye size bu yetkiyi vermez. Öğrenimi düşünmekle işverene ait aracı kullanmak farklı konulardır; gerekirse ilgili kişiden açık izin alın.
Kullanıcı görüşünü nasıl dinleyebilirim?
Önce son gerçek uygulamasını sorun. Aracı gösterdiğinizde hangi adımda zorlandığını gözleyin. Aktif dinleme yaklaşımı, kendi fikrinizi savunmadan karşı tarafı anlamaya yardım eder. Övgüyü gerçek kullanımla karıştırmayın.
Bir denemeyi ne zaman bırakmalıyım?
Çözmek istediğiniz sorun oluşmuyorsa, kullanıcı başka bir ihtiyacı gösteriyorsa veya gerekli bakım değerinden fazlaysa yeniden değerlendirin. Başlamadan kontrol sorusu ve karar zamanı belirlemek, denemenin belirsiz biçimde uzamasını önler.
