Salesforce, AppExchange ile üçüncü taraf geliştiricilerin uygulamalarını kendi müşterilerine ulaştırabileceği bir alan açtı. 2005'teki karar, her özel ihtiyacı ana ürün ekibinin çözmesine alternatif oluşturuyor. Öğrenim, temel ürünü korurken başka uzmanların katkısına uygun alan hazırlamak. Siz de ortak çalışmada hangi ihtiyacın içeride çözüleceğini, hangi parçanın dışarıdan eklenebileceğini ve kaliteyle desteğin kimin sorumluluğunda kalacağını ayrı düşünmelisiniz. Açık ekosistem, kuralsız ekleme yapmak değildir.
2005 kararı hangi imkanı oluşturdu?
Salesforce'un resmi tarihçesinde, Eylül 2005'te AppExchange'in tanıtıldığı belirtiliyor. Üçüncü taraf geliştiriciler kendi uygulamalarını Salesforce müşterilerine açabilecek bir yere kavuşuyor. Böylece ana ürünle farklı uzmanların hazırladığı ek uygulamalar aynı müşteri ilişkisine bağlanabiliyor.
Bu tarihsel karar, şirketin bütün sonraki büyümesini tek başına açıklamaz. Güncel uygulama koşullarının tamamını da bu kısa tarihçeden öğrenemeyiz. Vakanın öğrettiği soru daha küçük ve kullanışlı: Temel yapının yanında farklı ihtiyaca cevap veren katkılara nasıl alan açılır? Her şeyi içeride geliştirmekle her şeyi kontrolsüz dışarıya bırakmak arasında başka düzenler bulunabilir.
İlk öğrenim: ortak ihtiyaçla özel ihtiyacı ayırın
Bir ürün bütün müşteriler için aynı temel işi yapabilir. Fakat farklı sektör veya görevlerde özel ihtiyaçlar doğar. Her isteği ana ürüne eklemek karmaşıklığı artırabilir. Hiçbir isteği almamak da önemli kullanım alanlarını dışarıda bırakabilir. Önce hangi ihtiyacın gerçekten ortak olduğunu araştırmak gerekir.
Ofiste bir rapor sistemi bunun örneği olabilir. Bütün ekiplerin kaynak ve dönem bilgisi ortak; bazı ekiplerin özel açıklama alanı vardır. Temel yapıyı her özel istekle değiştirmek, başka kullanıcıların işini zorlaştırabilir. Eklenebilecek parçayla korunacak çekirdeği ayırmak daha uygun olabilir.
Bu sınır değişmez değildir. Sık görülen özel ihtiyaç zamanla ortak hale gelebilir. Ancak ilk talepte hemen bütün yapıyı değiştirmek yerine kullanım örneklerini izlemek yararlıdır. Hangi ihtiyacın tekrar ettiği ve kimlere fayda sağladığı görünür olsun. Ürün kararını sadece en yüksek sesli talep yönlendirmesin.
İkinci öğrenim: katkı verecek kişi için yol hazırlayın
Başka uzmanların çözüm geliştirmesi için neye erişebileceğini ve nasıl çalışacağını bilmesi gerekir. Belirsiz bir davet yeterli olmaz. Hangi bilgi, biçim ve sınır kullanılacak? Katkının nasıl sunulacağı anlaşılır olmalı. Böylece ortaklaşa üretim, herkesin ayrı varsayımla ilerlediği bir iş olmaktan çıkar.
Ofis içinde uzman katkısı için de aynı ihtiyaç var. Bir ekip şablona bölüm eklemek istiyor; fakat alan adlarını veya kaynak düzenini bilmiyor. Başlangıç açıklaması ve uygun örnek verilirse gereksiz tekrar azalabilir. Hazırlanan katkı daha kolay karşılaştırılır.
Bir işi çalışma arkadaşınıza öğretmek, katkı yolunu açmak için faydalıdır. Sadece dosyayı göndermek yerine örnek gösterilir, birlikte denenir ve bağımsız kullanım kontrol edilir. Bilgi paylaşımı, katkı verecek kişinin işe başlayabilmesini sağlar.
Üçüncü öğrenim: katkı artınca sorumluluk da düzenlenmeli
Dışarıdan veya başka ekipten gelen parça kullanılırken hata çıkabilir. Kimin kontrol edeceği ve kimin düzelteceği açık değilse kullanıcı ortada kalır. Katkı kolaylığıyla kalite sorumluluğunu aynı anda düşünmek gerekir. Ek alan açmak, temel standardı bırakmak demek değildir.
Güncelleme de önemli bir sorudur. Ana yapı değiştiğinde ek parçalar uyumlu kalacak mı? Eski sürümün kullanılmasını kim fark edecek? Sahibi belli olmayan katkılar zamanla destek yükü yaratabilir. Başlangıçta basit görünen çözüm, düzenli bakım gerektirebilir.
Çalışma anlaşması yapmak, teslim ve kontrol sorumluluğunu görünür hale getirebilir. Kullanıcı açısından tek deneyim oluşurken ekipler arasında görevler ayrı kalabilir. Bu ayrı görevlerin bağlantısı açık olsun.
Katkıyı bulabilmek de bir ihtiyaçtır
Çok sayıda ek parça olduğunda kullanıcı uygun olanı nasıl seçecek? Katkının adı tek başına yeterli olmayabilir. Amaç, uygun kullanım ve güncellik bilgisi görünür olsun. İlk bakışta benzer görünen iki parça farklı koşulları karşılayabilir. Yanlış seçimin sonucu, gereksiz destek veya hatalı iş olabilir.
Ortak çalışma alanında katkı sahibi ve son kontrol tarihi bulunması yararlı olabilir. Bu bilgi güncelleme sorusunun kime sorulacağını gösterir. Ancak tarih yazılması içeriğin otomatik doğru olduğu anlamına gelmez. Örnek iş ve uygun kontrol de korunmalıdır.
Yeni katkı geldiğinde mevcut parça aynı ihtiyacı zaten karşılıyor mu, araştırın. Aynı çözümün farklı adlarla çoğalması ekosistemi zenginleştirmek yerine aramayı zorlaştırabilir. Katkıya açık olmakla gereksiz tekrar biriktirmek farklıdır. Ekiplerin iyi örnekleri paylaşırken ortak alanın düzenine de katkı vermesi önemlidir.
- İhtiyacı ayırın
Temel ürünle özel kullanım ihtiyacını farklı değerlendirin.
- Katkıyı açın
Dışarıdan hangi parçanın eklenebileceğini seçin.
- Kaliteyi koruyun
Uyum, destek ve güncelleme sorumluluğunu açık tutun.
Uygulama: ortak rapora uzman katkısı açın
Bir şirketin bütün departmanlar için ortak faaliyet raporu kullandığını düşünün. Her ekip özel tablo eklemek istiyor. Ana şablon sürekli değiştiği için karşılaştırma zorlaşıyor. Temel alanları koruyup ek bölüm düzeni hazırlayabilirsiniz.
Örnek katkı notu şöyle doldurulur:
Korunan çekirdek: dönem, kaynak, ana sonuç ve açık risk alanı.
Eklenebilir parça: ekip ihtiyacına uygun açıklanmış tablo.
Gerekli bilgi: tablo amacı, alan adı ve veri kaynağı.
Kontrol: ana toplamla ilişki ve okuyucu için anlaşılabilirlik.
Sahip: ek bölümün güncelliğini takip edecek ekip.
Değişiklik: ana rapor alanı değişirse ek bölümün uyumu kontrol edilecek.
Bu düzen herkesin ayrı rapor hazırlamasından farklıdır. Ortak yapı korunur; özel ihtiyaç belirli yerde anlatılır. Katkı verecek ekip hangi sınır içinde çalışacağını bilir. Ana rapor sahibi de her ayrıntıyı kendisi geliştirmek zorunda kalmaz.
İlk denemede bir ek bölüm seçin. Okuyucu hangi bilginin ortak sonuç, hangisinin yerel açıklama olduğunu ayırt edebiliyor mu? Aynı sayı farklı anlamda kullanılıyor mu? Sorumlu kişi değiştiğinde bölüm nasıl sürdürülecek? Bu sorular ilk örnekte çözülürse sonraki katkılar daha tutarlı olabilir.
Kalite için rapor teslim kontrolünü koruyun. Katkı sayısının artması, bilgilerin doğru olduğu anlamına gelmez. Kullanıcıya daha çok seçenek sunarken gereksiz araştırma yükü yaratmayın. Uygun parçayı bulabilmesi de düşünülmeli.
Salesforce vakası, her şirketin uygulama mağazası kurmasını gerektirmiyor. Uzman katkısına açık ama temel kalitesini koruyan çalışma düzenini düşündürüyor. Kendi işinizde katkı ve sorumluluğu daha iyi bağlamak için kariyer gelişim kursunun programını inceleyebilirsiniz.
Sık sorulan sorular
AppExchange hangi yılda başladı?
Resmi tarihçe Eylül 2005'i gösteriyor. Yazı tarihsel ürün kararına odaklanıyor. Güncel başvuru, ücret veya uygunluk koşulları ayrı kontrol edilmelidir.
Her özel ihtiyaç ana ürüne eklenmeli mi?
Hayır. Ortak ihtiyaçla özel kullanım alanı ayrılabilir. Katkının daha uygun yerde sunulması temel yapıyı karmaşıklaştırmadan yardımcı olabilir.
Küçük ekip katkı düzenini nasıl kurabilir?
Temel alan, eklenebilir parça ve kontrol sahibi seçilebilir. Çalışma anlaşması bu sorumlulukları baştan konuşmaya yardım eder.
Daha fazla katkı otomatik olarak daha iyi sonuç mu?
Değil. Uyum, doğruluk ve bulunabilirlik gerekir. Kullanıcının hangi parçayı neden seçeceğini anlaması önemlidir. Gereksiz seçenek de yük yaratabilir.
