Claude ile Yaptığın Çalışmayı Ekibinle Nasıl Paylaşırsın

Şu an bir iş arkadaşın kampanya brifini hazırlarken kullandığın Claude akışını istediğinde, muhtemelen nihai çıktıyı Slack'e kopyalayıp işi bitmiş sayıyorsun. Cevabı akıl yürütmenin hiçbiri olmadan alıyor; böylece bir dahaki sefere ayarlaması gerektiğinde yeni bir sohbet açıp senin bağlamını sıfırdan yeniden kuruyor.

Düzeltmeye değer kısım bu. Devrettiğin değerli şey çıktı değil. Bağlam.

Paylaşabileceğin en yararlı şey Claude'un cevabı değil. Claude'u o cevaba götüren her şey.

Claude çalışmasını ne zaman paylaşmalı (ve ne zaman paylaşmamalı)

Her Claude konuşması bir iş arkadaşını hak etmez. Paylaşmanın bir maliyeti var: birinin senin bağlamını okuması, çerçevelemeni anlaması ve üzerine kurabilmeden önce kurulumuna güvenip güvenmeyeceğine karar vermesi gerekir. Bu yalnızca iş bir yere gidiyorsa değer.

Şu durumlarda paylaş:

• Çıktı zaman içinde birden fazla kişi tarafından gözden geçirilecekse (bir konumlandırma belgesi, bir rapor yapısı, bir kampanya brifi).
• Birden fazla ekip üyesi aynı temel çalışmanın varyasyonlarını üretmek zorundaysa (farklı kitleler, farklı biçimler, aynı altta yatan araştırma).
• Mevcut görevden daha uzun yaşayacak bir şey kuruyorsan, bir üslup kılavuzu, bir araştırma özeti ya da yinelenen bir rapor şablonu gibi.

Şu durumlarda paylaşmakla uğraşma:

• Görev tek seferlik ve atılabilir bir şeyse, tek bir e-postayı yeniden yazmak ya da bir makaleyi özetlemek gibi.
• Hâlâ dağınık, keşif aşamasındaysan ve konuşma çıkmaz sokaklarla doluysa. Önce toparla, yoksa kimse neyin önemli olduğunu söyleyemez.
• İş arkadaşı, soruyu Claude'a kendi bağlamıyla kendisi sorarak aynı cevaba daha hızlı ulaşabilecekse.

İyi bir kural: Slack'te “ben şunu yaptım ve nedeni şu” diye açıklayan bir paragraf yazmaya zahmet edecek olsan, iş paylaşılabilirdir. Zahmet etmeyecek olsan, muhtemelen devredilecek kadar henüz bitmemiştir.

Ekibinin gerçekten kullanabileceği paylaşımlı bir Proje kurmak

Bir Claude Projesi, iş süreklilik gösterdiğinde doğru kaptır; ama yalnızca bir meslektaşın soğuk soğuk içeri girip katkıda bulunmaya başlayabileceği şekilde kurarsan. Bu, onu bir sohbet geçmişi yığını olarak bırakmak yerine baştan biraz yapısal iş yapmak demektir.

1. Projeye kökeninin değil amacının adını ver. “3. Çeyrek Kampanya Brifi”, “Pazarlama Sohbeti 4”ü yener. Birinin açmadan önce ne için olduğunu bilmesi gerekir.
2. Önce sabitlenmiş bir bağlam belgesi ekle. Herhangi bir konuşma olmadan önce Projenin bilgi tabanına kısa bir brif koy: bu Projenin ne için olduğu, kimin kullandığı, “bitti”nin neye benzediği.
3. Kaynak malzemeyi ekle, kaynak malzemenin özetlerini değil. Proje bir ürün lansmanıyla ilgiliyse, üç cümlelik yorumunu değil gerçek ürün şartnamesini ekle. İş arkadaşlarının iddiaları doğrulaması gerekir, yalnızca senin okumana güvenmeleri değil.
4. İnsanların onu nasıl kullanması gerektiği konusunda beklenti belirle. “Her taslak için bu Proje içinde yeni sohbetler aç, sabitlenmiş brifin üzerine yazma” gibi tek satırlık bir not sonradan karışıklığı önler.
5. Onu kendin bir yabancı olarak dene. Projeyi taze aç ve sor: bu görevle ilgili hiçbir hatırası olmayan biri sonraki adımın ne olduğunu çözebilir mi? Çözemezse eksik olanı ekle.

Bu kurulum süreci, Projelerin kalıcı olması gereken bağlam için iyi çalışmasının nedeniyle aynıdır: bağlam Projenin kendisinde yaşar, bir kişinin kafasında ya da bir konuşmanın kaydırma geçmişinde değil.

Bir konuşmayı mı bir Projeyi mi paylaşmak: hangi kap

Farklı sorunları çözerler ve yanlışını seçmek yaygın bir sürtünme kaynağıdır.

Tek bir konuşmayı şu durumlarda paylaş:

• Tek seferlik bir devirse. Birinin bir karara nasıl vardığını görmesi, sonra devam etmesi gerekir.
• Görevin net bir bitiş noktası varsa ve kimsenin önümüzdeki ay bu bağlama dönmesi gerekmeyecekse.
• Belirli bir akıl yürütme çizgisini tam olarak gerçekleştiği gibi korumak istiyorsan, kimse onu bulandıran yeni akışlar eklemeden.

Şu durumlarda bir Proje kur:

• Birden fazla kişi birkaç oturum boyunca katkıda bulunacaksa.
• Bağlamın (marka sesi, kaynak belgeler, önceki kararlar) yalnızca bir değil birçok farklı istek için yeniden kullanılabilir olması gerekiyorsa.
• İşin gelişmesini bekliyorsan. Birkaç kişi aynı akışa ilgisiz sorular attığında tek bir konuşma çabuk kullanılmaz hâle gelir.

Hangisinin geçerli olduğundan emin değilsen, bunun bir anlık görüntü mü yoksa bir çalışma alanı mı olduğunu sor. Bir anlık görüntü, korunmaya değer zamanda bir andır. Bir çalışma alanı, insanların sürekli geri döneceği bir yerdir. Bu, yeni sohbet, Proje ya da eski bir akışı sürdürme arasında seçim yapmak konusundaki aynı ayrımdır; yalnızca bireysel düzey yerine ekip düzeyinde uygulanır.

Ekibinin alıp kullanabileceği bağlamı yazmak

Claude ekip iş akışlarındaki tek en büyük başarısızlık, birine bir Proje verip ham sohbet geçmişinden düşüncelerini tersine mühendislik yapmasını beklemektir. Bunun yerine bağlamı yaz. Beş dakika sürer ve diğer herkese bir saat kazandırır.

İyi bir devir notu üç soruyu yanıtlar:

• Zaten neyi denedim? Yalnızca işe yarayanları değil, işe yaramayan yaklaşımları da ekle. Bu, bir iş arkadaşının bir çıkmaz sokağı yeniden denemesini önler.
• Şu an gerçekten ne işe yarıyor? Mevcut taban olarak ele alınması gereken belirli taslağı, kararı ya da çıktıyı göster.
• Sonraki adım ne? Birinin inceltmesi, genişletmesi ya da tamamen yeni bir yön başlatması gerekip gerekmediğini tahmin etmesine bırakma.

İşte paylaşımlı bir Projenin en üstüne sabitlendiğinde iyi çalışan bir biçim:

Devir notu için prompt:

Bu konuşmayı, bu işe sıfırdan devam edecek bir iş arkadaşı için
özetle. Şunları ekle:
1. Özgün hedef, tek cümleyle.
2. Hangi yaklaşımların denenip reddedildiği, her biri için bir
   satırlık gerekçeyle.
3. Mevcut en iyi taslak ya da cevap, tamamen alıntılanmış.
4. Belirli sonraki adım, görev olarak ifade edilmiş (örneğin
   “ikinci paragrafı sıkılaştır”, “geliştirmeye devam et” değil).
200 kelimenin altında tut. Nezaket sözleri ya da çekinceler ekleme.

Bu, bir iş arkadaşının kırk mesajı kaydırmak yerine otuz saniyede okuyabileceği bir not üretir. Aynı fikrin yeniden kullanılabilir bir sürümü için, biçimi daha derinlemesine ele alan yeniden yazmayı bıraktığın, yeniden kullanılabilir bir bağlam özeti hazırlamak yazısına bak.

Ekibin Claude'un çıktısını incelttiğinde geri bildirimi yönetmek

Bir iş arkadaşı bir Claude taslağını elle düzenlediğinde, o düzenleme tüm iş akışındaki en değerli bağlam parçası olur ve yinelemeye devam etmek için Claude'a döndüğün anda kaybetmesi kolaydır.

Çözüm, insan düzenlemelerini yalnızca bir sonraki taslakla değiştirilecek bitmiş bir ürün olarak değil, girdi olarak ele almaktır.

1. Yalnızca son sürümü değil, farkı kaydet. Bir iş arkadaşının gözden geçirilmiş taslağını Claude'a geri yapıştırmadan önce, kısaca bile olsa neyin değiştiğini ve nedenini not et (“ikinci paragrafı kestim, eylem çağrısını sıkılaştırdım, tonu daha az resmî yaptım”).
2. Yalnızca yeni metni değil, gerekçeyi de prompt'a geri besle. Claude'dan düzenlemeyi yeni ham madde olarak kabul etmek yerine düzenlemenin yönünde devam etmesini iste.
3. Düzenleme kalıcı bir tercihi yansıtıyorsa sabitlenmiş bağlamı güncelle. İş arkadaşın her zaman sıfatları kesiyorsa, bu her turda yeniden keşfedilecek bir şey değil, Proje brifine eklenmeye değer bir üslup kuralıdır.
4. İlerlemeden önce sonraki taslağın düzenlemeye saygı gösterdiğini doğrula. “Bu, geçen turdaki daha sıkı eylem çağrısını koruyor mu” gibi hızlı bir kontrol gerilemeleri erken yakalar.

Bu devir için yararlı bir prompt:

İşte önceki taslak ve iş arkadaşımın geri gönderdiği düzenlenmiş
sürüm. İkisini karşılaştır ve kısa bir listede neyin değiştiğini
ve her değişikliğin neden yapıldığını düşündüğünü söyle. Sonra
bir sonraki bölümü, özgün taslakla değil bu değişikliklerle
tutarlı olacak şekilde yazmaya devam et.

[özgün taslağı yapıştır]
[düzenlenmiş taslağı yapıştır]

Bu, tüm ekibin muhakemesinin iş el değiştirdiğinde sıfırlanmak yerine aynı yönde birikmesini sağlar. Bu, tek bir mali raporu hem yönetim kurulu hem ekip için yeniden şekillendirmek ile aynı mantıktır: altta yatan tek bir taslak, her seferinde baştan başlamadan farklı okuyucular için incelmiş ve yeniden biçimlendirilmiş.

Yaygın iş birliği tuzakları ve bunlardan nasıl kaçınılır

Üç örüntü, Claude ekip iş akışlarındaki sürtünmenin çoğunu açıklar. Her birinin gerçek zamana mal olmadan yakalayabileceğin tanınabilir bir anı vardır.

• Sessiz devir. Bir Projenin ya da konuşmanın bağlantısını hiçbir not eklemeden, kişinin “sadece bir göz atacağını” varsayarak paylaşırsın. Slack'e bağlamsız bir bağlantı yapıştırmak üzere olduğun anda dikkat et. Göndermeden önce iki cümle ekle.
• Bağlam kayması. A kişisi brifi inceltir, B kişisi dünden beri açık bir sekmesi olduğu için eski, önbelleğe alınmış bir sürümden çalışır. Bu, ikisi de kendinden emin duyulan çelişkili çıktılar üreten iki kişi olarak görünür. Çözüm, sabitlenmiş bağlam belgesini tek doğruluk kaynağı yapmak ve Proje dışındaki her kopyayı geçici saymaktır.
• Bir Projeyi grup sohbeti gibi ele almak. Biri paylaşımlı Projeye ilgisiz sorular atmaya başlar (“bu arada, şu diğer e-postayı yazmama da yardım eder misin?”) ve bağlam konu dışı akışlarla seyrelir. Beyan edilen amacıyla net bir ilişkisi olmayan konuşmalar biriktiren bir Projeye dikkat et. Bu olduğunda başka bir yerde yeni bir sohbet ya da ikinci bir Proje açma zamanıdır.

Bunların hiçbiri bir Claude sorunu değil. Tesadüfen Claude içinde ortaya çıkan koordinasyon sorunlarıdır. Her durumda çözüm aynı: bağlamı açık hâle getir, tek yerde tut ve sonraki adımın bariz olduğunu varsaymak yerine ne olduğunu yüksek sesle söyle.

Okumaya devam et

• Projelerle Çalışmak: Kalıcı Bağlam: Projelerin bağlamı oturumlar arasında nasıl koruduğuna daha derin bir bakış için; bu sürecin tamamının dayandığı temel.
• Yeniden Yazmayı Bıraktığın, Yeniden Kullanılabilir Bir Bağlam Özeti Hazırlamak: yalnızca ekip paylaşımının ötesinde çalışan bir devir notu biçimi istiyorsan.
• Bir Kampanya Hedefini Tek Sayfalık Bir Brife Dönüştürmek: bu sürecin desteklemek için kurulduğu iş birliği çıktısının somut bir örneği olarak.