Zoom hızlı büyüme sırasında güvenliği nasıl önceliklendirdi?

Zoom, 2020’de hızlı kullanım artışının ardından güvenlik ve gizlilik sorunlarına odaklanmak için bu alanlarla ilgili olmayan yeni özellikleri 90 gün durdurdu. Böylece öncelik yalnız açıklamada kalmadı; ürün ve mühendislik işlerinin yönü değişti. Vakanın ofis hayatına öğrenimi şu: Kritik bir sorunu gerçekten öncelemek istiyorsanız hangi işin bekleyeceğini de seçmelisiniz. Her şeyi aynı anda sürdürüp en önemli sorunu çözeceğinizi söylemek, odağı belirsiz bırakabilir. Ayrıca bir düzeltme programının bitmesi, risklerin tamamen bittiği anlamına gelmez.

Öncelik değişikliği nasıl görünür hale geldi?

Yeni kullanıcılar bir ürünü farklı amaçlarla ve farklı bilgi düzeyleriyle kullanabilir. Önceden yönetilen bir ortamda uygun görünen düzen, genişleyen kullanımda başka ihtiyaçlar doğurabilir. Sorunu yalnız kullanıcının dikkatsizliğiyle açıklamak yetersiz olur.

Zoom CEO’su Eric Yuan’ın 1 Temmuz 2020 raporu, 1 Nisan’da başlayan programı anlatıyor. Güvenlik, gizlilik ve güven dışındaki yeni özelliklerin 90 gün durdurulduğu belirtiliyor. Uzman incelemeleri, hata bildirimi düzeni ve kullanıcıya yönelik ilerleme paylaşımları da programın parçasıydı. Şirket, bu sürenin sonunu devam eden güvenlik çalışmasının ilk adımı olarak değerlendiriyor.

Bu tarihli kayıt, bugün ürünün tüm koşullarını değerlendiren bir güvenlik incelemesi değil. Burada çalışma kararını okuyoruz: Kaynakların nereye ayrıldığı, hangi işlerin bekletildiği ve düzeltmenin nasıl takip edildiği. Öğrenim, kritik sorunla özellik talebini aynı sıraya koymamaktır.

İlk öğrenim: Öncelik, ertelenen işi de gösterir

Bir ekipte bütün işler “öncelikli” ilan ediliyorsa çalışanlar gerçek seçimi kendileri yapmak zorunda kalır. En çok ses getiren talep öne geçebilir. Kritik kontrol ise görünür sonucu az olduğu için geride kalabilir. Bu durumda başlığa yazılan öncelikle günlük çalışma ayrılır.

Sorunu seçtiğinizde mevcut iş listesini de inceleyin. Hangi geliştirme bekleyecek, hangi müşteri taahhüdü korunacak? Bunlar açık konuşulmalı. Ertelenen işin etkileneni ve tekrar bakılacağı zaman belli olsun. Kaynak yaratmak için başka yükü görünmez biçimde çalışana eklemeyin.

Çalışan olarak çakışmayı somut anlatabilirsiniz. Kritik dosya kontrolüyle yeni rapor tasarımının aynı saate sıkıştığını söylemek, genel yoğunluk şikayetinden daha çözülebilir olabilir. Yönetici hangi işin önce geleceğine karar verebilir. İşin etkisi ve süre ihtiyacı görünür olur.

İkinci öğrenim: Sorun bildirimiyle düzeltmeyi ayırın

Bir hatanın kaydedilmesi, düzeltilmiş olduğu anlamına gelmez. E-posta göndermek veya listeye satır eklemek gerekli olabilir, ama takip sahibi yoksa iş burada durur. Bildirimin değerlendirileceği ve sonuçlanacağı bir yol gerekir.

Kayıtta sorun, etki, geçici önlem ve sorumlu kişi ayrı bulunabilir. Her ayrıntıyı bütün çalışanlara açmak doğru olmayabilir; hassas bilgi uygun yetkili ortamda tutulur. Buna karşılık gerekli kullanıcıya hangi davranışın değişeceği anlaşılır biçimde iletilmelidir.

Hatayı yöneticiye haber vermek, bu ilk bildirimi hazırlamak için yardımcıdır. Ama hata bildiren kişi her zaman bütün düzeltmenin sahibi değildir. Görevlerin netleşmesi, hem çözümü hem çalışanı korur.

Üçüncü öğrenim: Düzeltme, kullanım sırasında sınanır

Bir değişiklik hazırlanmış olabilir. Yine de gerçek kullanıcı eski yöntemi sürdürüyor veya yeni adımı anlamıyorsa sorun devam edebilir. Düzeltme dosyasıyla uygulama sonucu ayrı kontrol edilir. Yeni düzenin gerçekten kullanılıp kullanılmadığını görün.

Bu kontrol tek seferlik olmak zorunda değildir. Aynı hata hangi koşulda tekrar oluşabilir? Yeni kişi başladığında açıklama yeterli mi? Kaynak değiştiğinde kontrol eski kalıyor mu? Sorun tekrarını yalnız dikkatsizlik olarak görmeden iş düzenini inceleyin.

5 Neden yaklaşımı, ilk açıklamada durmadan uygun soruları sormaya yardım eder. Ama tahmini nedenlerle kesin sonuç oluşturmayın. Gerekli kanıtı ve kontrolü seçmek önemlidir.

Yanlış ek gönderimi için dar düzeltme çalışması

Şöyle bir durum düşünün: Bir ofis ekibinde farklı müşterilere ait dosyaların karışma riski fark ediliyor. Aynı hafta yeni bir görsel rapor da hazırlanacak. Önce kritik sorunun kapsamı ilgili kişilerle değerlendirilir. Gerekli bildirim ve kurum prosedürü korunurken rapor tasarımı geçici olarak bekletilir.

Düzeltme notu şöyle olabilir: “Sorun: gönderim öncesinde müşteri ve ek eşleşmesi belirsiz. İncelenecek: dosya adları, ortak klasör ve son kontrol. Geçici düzen: ilgili gönderimlerde belirlenen kontrol sahibinin doğrulaması. Yeni tasarım: sonra ele alınacak.” Kontrol adımı kurumun mevcut güvenlik prosedürüyle birlikte ele alınır; gerekli bildirim ve sorumlular ayrıca belirlenir.

Ardından gerçek gönderim adımlarını inceleyin. Çalışan dosyayı hangi klasörden seçiyor? Aynı ada sahip kopyalar var mı? Son sürümün kaynağı açık mı? Hata yalnız isim benzerliğinden değil, işin aceleye sıkışmasından da doğabilir. Her olası nedeni aynı çözümle ele almayın.

Yeni düzen seçildiğinde örnek dosyalarla sınayın. Doğru müşteri ve sürüm seçilebiliyor mu? Kontrol gereksiz uzun mu? Bir başka çalışan adımı anlayabiliyor mu? Test, gerçek hassas bilgiyi daha fazla yere taşımadan uygun biçimde yapılmalı. Sorunu düzeltirken yeni risk oluşturmayın.

Sonrasında bir takip zamanı belirleyin. Yanlış dosya riski tekrar görülüyor mu, çalışanlar yeni kaynağı kullanıyor mu? Kontrol sahibi izinli olduğunda süreç nasıl ilerliyor? Sadece bir kişinin dikkatine bağlanan çözüm, değişen koşulda zayıflayabilir.

Görsel rapor işine dönüldüğünde ertelemenin neyi değiştirdiğini açıklayın. Kritik kontrol sayesinde daha sonra tasarım işi de güvenilir bilgiyle ilerleyebilir. Ancak bu sonuçları ölçmeden büyük tasarruf veya kusursuzluk iddiası üretmeyin. Yapılan karar ve görülen değişiklik yeterince değerli öğrenim olabilir.

Bugün iş listenizde görünür olmayan fakat önemli bir kontrol var mı, buna bakın. Hangi işin bekleyebileceğini etkilenen kişilerle konuşun. İşte problem çözme ve karar anlatımınızı geliştirmek için kariyer gelişim kursunun programını inceleyebilirsiniz.

Sık sorulan sorular

Yeni özellikleri durdurmak her sorunda gerekli mi?

Hayır. Sorunun etkisi, kaynak ihtiyacı ve mevcut taahhütler değerlendirilir. Vaka, gerçek önceliğin iş listesini değiştirebileceğini gösterir. Küçük bir hata için bütün geliştirmeyi durdurmak gerekmez; uygun kapsam ilgili kişilerle belirlenir.

Hata bildirimi yaptığımda görevim tamamlanır mı?

Rolünüze ve soruna göre değişir. Bildirimden sonra kimin takip edeceği netleşmeli. Sizin tamamlayacağınız bilgi ve gerekli kontrol varsa bunu yapın. Çözüm yetkiniz dışında kalıyorsa doğru sorumluya geçişi görünür tutun; sessizce kapatmayın.

Yeni düzeni nasıl anlatabiliriz?

Kullanıcının yapacağı değişikliği kısa ve açık yazın. Standart iş talimatı, adım ve kontrol noktasını düzenlemek için yardımcı olabilir. Hassas ayrıntıların erişimini kurumun paylaşım sınırları içinde tutun.

Program bitince takip de biter mi?

Bitmemeli. Düzeltmenin kullanıldığı ve tekrar riskinin nasıl izlendiği kontrol edilir. Tek seferlik uygulama, değişen veri veya yeni çalışanla eski hale dönebilir. Takip biçimini riskin ihtiyacına göre belirleyin; süreyi başarı kanıtıyla karıştırmayın.