CSCW: Bilgisayar Destekli İşbirlikçi Çalışma Neyi Çözer, Nerede Tıkanır
CSCW, insanların birlikte çalışmasını yazılımla desteklemeye çalışan araştırma alanının adı. Terim 1984'te doğdu ve kırk yılda ürettiği en kullanışlı bulgu teknik değil, örgütsel: işbirliği araçlarının çoğu kötü yazıldığı için değil, ek işi yapan kişiyle faydayı gören kişinin farklı olması yüzünden ölüyor. Bir aracı ekibe sokmadan önce sorulacak asıl soru da bu.
Terim nereden çıktı
Irene Greif ve Paul Cashman 1984'te yirmi kişilik bir atölye düzenledi. Katılımcılar tek bir disiplinden gelmiyordu: bilgisayar bilimciler, ofis otomasyonu satıcıları, psikologlar, yönetim araştırmacıları. Ortak dertleri şuydu: bilgisayar, tek kişinin işini hızlandırmayı iyi öğrenmişti. Birkaç kişinin aynı işi paylaşmasını hiç bilmiyordu.
O dönemin somut sıkıntısı bugün tuhaf geliyor. İki farklı firmanın e-posta sistemi birbirine mesaj geçiremiyordu, ortak bir dosyayı iki kişinin aynı anda açması veri kaybı demekti, ve "belgeyi kim güncelledi" sorusunun makine tarafında bir cevabı yoktu. CSCW başlangıçta bu boşluğu tarif etmek için icat edilmiş bir şemsiye terimdi.
Alan sonra ikiye ayrıldı. Avrupa tarafı işin sosyolojisine, ofis etnografisine ve yöntem tartışmasına yöneldi; Kuzey Amerika tarafı satılabilir ürüne, yani groupware'e. Bugün kullandığımız araçların çoğu ikinci koldan çıktı, ama neden çalışmadıklarına dair en iyi açıklamalar birinci koldan geldi.
Groupware'in asıl arızası
Jonathan Grudin 1988'de basit bir gözlem yayımladı ve alan o gözlemden hâlâ kurtulamadı: groupware, ek emeği isteyen kişiyle faydayı toplayan kişi ayrıştığında başarısız olur.
Kanonik örnek otomatik toplantı planlayıcısıdır. Sistemin çalışması için herkesin takvimini eksiksiz ve güncel tutması gerekir. Bu, on kişilik bir ekipte on kişiye günlük bir angarya bindirir. Karşılığında toplantı ayarlama derdinden kurtulan tek kişi vardır, o da genellikle yöneticidir. Yük tabana yayılır, fayda tepede toplanır. Kimse sabote etmez, sadece takvimini doldurmaz, ve sistem birkaç hafta içinde güvenilmez hale gelir.
Aynı kalıbı her yerde görürsünüz. Satış temsilcisi CRM'e veri girer, raporu satış müdürü okur. Geliştirici wiki'ye yazar, faydayı altı ay sonra gelen yeni ekip üyesi görür. Zaman takip yazılımını dolduran ile çıktısına bakan asla aynı kişi değildir. Kaynak metinlerin "merkezi bilgi havuzu kurun, herkes aynı sayfada olsun" tavsiyesi burada sessizce çöker: ortak havuz kendi kendini doldurmaz, birinin ödediği bir maliyettir.
İşe yarayan araçların ortak özelliği
Bu asimetriyi aşmanın bildiğim iki yolu var, ve tutan araçların hepsi bunlardan birini kullanıyor.
Birincisi, aracın tek kullanıcıya da değer vermesi. Git'i kimse "ekip işbirliği için" kullanmaya başlamaz; tek başına çalışırken bile geri alınabilir bir geçmiş verdiği için kullanır, paylaşım ondan sonra bedava gelir. Google Dokümanlar da öyle: tek kişilik bir metin editörü olarak zaten iş görüyor. Takvim uygulamalarının 1980'lerde tutmayıp 2010'larda tutmasının sebebi de yönetim baskısı değil, telefondaki hatırlatıcıdır. Takvimi doldurmanın karşılığı nihayet dolduran kişiye döndü.
İkincisi, katılım maliyetini neredeyse sıfıra indirmek. Slack tek kişilik bir ekipte anlamsızdır, yani birinci testi geçemez. Buna rağmen yayıldı, çünkü kullanıcıdan istediği şey zaten yapmakta olduğu davranıştı: mesaj yazmak. Ek alan doldurma, etiketleme, kategori seçme yok.
Bir araç ne tek kullanıcıya değer veriyor ne de katılımı bedavaya getiriyorsa, o araç ancak zorlamayla ayakta durur. Zorlamayla ayakta duran sistemlerin verisi de genelde yalancıdır: alanlar doldurulmuştur, ama içleri boştur.
Uzaktan çalışma neyi değiştirdi
Coğrafya problemini çözdü, asimetri problemini çözmedi. Hatta ağırlaştırdı, çünkü ofiste bedava olan bilgi akışı artık birinin yazması gereken bir şey.
Pratik sonuç şu: dokümantasyonu ayrı bir görev olarak tarif eden her süreç uzun vadede çürüyor. Çalışan tek yaklaşım, kaydı işin kendi çıktısı haline getirmek. Kararı toplantı sonrası ayrı bir belgeye yazmak yerine kararın alındığı yere, yani ilgili konunun altına yazmak. Değişikliğin gerekçesini commit mesajına ve pull request açıklamasına koymak, sonra ayrıca "teknik dokümantasyon" başlığı açmamak. Böyle kurulduğunda yazan kişi ekstra bir iş yapmaz, sadece yapacağı işi görünür bir yerde yapar.
Senkron ve asenkron tercihinde de net bir tarafım var. Varsayılan asenkron olmalı, çünkü asenkron iletişim yazıya döküldüğü için kendiliğinden arşivlenir. Senkron toplantı, kararın hangi yöne gideceği gerçekten belirsizse ve tartışmanın kendisi işin bir parçasıysa değerlidir. Durum güncellemesi için toplantı kurmak, on kişinin zamanını bir kişinin okuma kolaylığına harcamaktır. Grudin'in gözlemi burada da aynen geçerli.
Kaynak