Müşteriyle ilk toplantıda sorulacak beş soru

Bir projenin maliyetinin çoğu, kimse teklif yazmadan önce, ilk toplantıda belirlenir. Anlaşılan şeyler yüzünden değil, sorulmayıp varsayıma dönüşen ve üç ay sonra genelde cuma günü ortaya çıkan şeyler yüzünden. Listemi beş soruya indirdim. Sıkıcılar, kırk dakika sürüyorlar ve bana benimsediğim her araçtan daha çok zaman kazandırdılar.

İlk toplantı ne işe yarar

İlk toplantı, karşınızdaki kişiyle aynı sistemi tarif edip etmediğinizi anladığınız yerdir. O kişi bir yıldır bu sorunun içinde yaşıyor ve artık fark etmediği şeyleri biliyor. Siz bu tip projelerde genelde nelerin ters gittiğini biliyorsunuz ve bunlardan hangisinin burada geçerli olduğu hakkında hiçbir fikriniz yok. Toplantı, onun bilgisini sizin kısıtlarınıza çevirir.

Bu da söylenen kadar ima edileni de dinlemek demek. "Raporlar pazartesileri gidiyor" cümlesinin içinde zamanlanmış bir iş, bir alıcı listesi, birinin bağımlı olduğu bir format ve durduğunda telefon edecek bir kişi vardır. Beş soru, bu imaları hâlâ ucuzken açığa çıkarmak için var.

1. Başarı hangi sayı

Sayıyı, bugünkü değerini ve nereden okunacağını isteyin. "Daha hızlı" şuna dönüşür: "en büyük hesapta export bir dakikanın altında bitecek, panelden ölçülecek". "Daha çok satış" şuna dönüşür: "haftada yirmi tamamlanmış sipariş daha, şu an baktığımız aynı ekrandan sayılarak".

Sonra herkesin atladığı soruyu sorun: hangi sonuç size bu işi başarısız saydırır. Alt sınır hedeften daha dürüsttür ve sonunda sizi asıl onunla değerlendirirler.

Bugünkü değeri kimse bilmiyorsa bunu toplantıda söyleyin. Ölçmek ilk teslim edilecek iş olur; bu, sonradan yutulacak bir eksiklik değil, gerçek bir iş kalemidir. Aynı alışkanlık optimize etmeden önce ölçmekte de geçerli: üzerinde anlaştığınız bir başlangıç noktası olmadan iyileşmeyi gösteremezsiniz.

2. Şu an ne çalışıyor da bozulmamalı

Yeni iş, zaten yükümlülükleri olan bir sistemin üstüne konur. Listeyi toplantıda, yüksek sesle isteyin:

• Zamanlanmış işler: gece, hafta, ay hangi iş koşuyor ve koşmadığında kim fark ediyor.
• Entegrasyonlar: içeri veri kim gönderiyor, dışarı veri kim çekiyor, durursa ilk hangi taraf arar.
• Rapor ve export'lar: kime gidiyor, hangi formatta, aşağı tarafta bu dosyayı parse eden biri var mı.
• El ile yapılan rutinler: birinin her sabah doldurduğu tablo, hiçbir diyagramda görünmese de sistemin parçasıdır.
• Yedek ve geri dönüş: en son ne zaman yedek alındığı değil, en son ne zaman bir yedekten geri dönüldüğü. Bu ayrı bir sorudur ve genelde ayrı bir cevap alır; sıfır baytlık yedek yazısında anlattığım şey tam olarak budur.

Bu listede dokunma ihtimaliniz olan her kalem ya bir kısıttır ya bir migration. İkisi de iştir. Canınızı yakanlar ise hiç bozulmadığı için kimsenin aklına gelmeyen maddelerdir.

3. Veri ve hesaplar kimin

Kimin erişimi var diye değil, kimin erişim verebileceğini sorun. Bu ikisi sandığınızdan daha sık farklı kişiler çıkar ve takviminizi belirleyen birincisidir.

Tek tek geçin: alan adı kaydı, DNS, sunucu veya bulut hesabı, veritabanı, ödeme hesabı, analitik, uygulama mağazası kaydı, sistem bildirimlerinin düştüğü posta kutusu. Her biri için kayıtlı sahibi kim, bugün kim kullanıcı ekleyebilir, bu genelde ne kadar sürüyor.

"Bakacağız" geçerli bir cevaptır ve aynı zamanda bir takvim bilgisidir. Sahibi belirsiz bir hesap, bitireceğiniz bir iş değil, gireceğiniz bir sıradır; pazartesi başlayacak bir projenin iki hafta sonra başlamasının en yaygın sebebi de budur. Erişim taleplerinin aynı hafta açılmasını isteyin, mümkünse sözleşme imzalanmadan önce, çünkü başlatması bedava ve her şeyle paralel ilerler.

Erişim isterken kendi kullanıcınızı isteyin, birinin kullanıcı adını ve şifresini değil. Paylaşılan hesap üç ayrı sorun üretir: kimin ne yaptığı log'dan okunamaz, o kişi izne çıkınca iş durur, ve iş bittiğinde erişimi temiz şekilde kapatmanın yolu olmaz. Ayrılırken hangi erişimlerin kapatılacağını da aynı toplantıda söyleyin; bu cümle güven kazandırır ve sonradan kimsenin aklına gelmez.

Bu sorunun diğer yarısı teknik değil hukuki: veri kimin, nerede durabilir ve içindeki insanlara ne söz verilmiş. Bunu ilk toplantıda duymak, bir denetim sırasında duymaktan çok daha ucuzdur.

4. Daha önce ne denendi, neden durdu

Neredeyse her projenin bir öncülü vardır. Doğrudan sorun ve ona ne olduğunu da sorun, çünkü durma sebebi hangi duvara doğru gittiğinizi söyler. Bütçe bitmiştir. İşi sahiplenen kişi gitmiştir. Şirket dışından bir kural o yaklaşımı imkânsız kılmıştır. Bir tedarikçi cevap vermeyi bırakmıştır.

Bu sebeplerin çok azı teknik ve hiçbiri daha iyi kod yazarak çözülmüyor. Önceki deneme bir departman verisini hiç vermediği için durduysa, bağımlılık riskinizi daha ilk hafta öğrenmiş olursunuz.

Geriye ne kaldıysa isteyin: repo, şema, yarım migrate edilmiş tablo, birinin yazdığı doküman. Yarım kalmış sistem, üstüne inşa etseniz de yerine yenisini koysanız da bir kısıttır ve zor kısımların nerede olduğunu öğrenmenin genelde en hızlı yoludur. Dürüst cevap, eski sistemin bir süre yenisiyle yan yana yaşaması gerektiğiyse, bu bir hayal kırıklığı değil bir plandır ve tek seferlik bir geçişle değil küçük ve geri alınabilir adımlarla yürür.

5. Anlaşmazlıkta kim karar veriyor

Açıkça sorun: sizin tarafta iki kişi farklı şeyler isterse kim karar veriyor ve bu ne kadar sürüyor. Ardından kararın geçerli sayılması için kime danışılması gerektiğini ve sonradan kimin veto edebileceğini sorun.

Projeler nadiren zor problemlerde tıkanır. Üç kişinin de "o karar bende değil" sandığı bir cevabı beklerken tıkanır. İsmi önceden bilmek iki haftalık beklemeyi bir güne indirir. Ayrıca en kötü anda gelen soruyu kime soracağınızı da söyler: bir şey yarı migrate edilmişken ve seçim bugün yapılmak zorundayken.

Dürüst cevap "kimse hızlı karar veremiyor" ise buna göre kurgulayın. Açık soruları tek kısa listede toplayın, tarih ve varsayılan koyun: "perşembeye kadar cevap gelmezse X'i yapacağız, sürüm çıkana kadar geri alınabilir."

Cevapları aynı gün yazın

Bir gün içinde, aynı beş başlıkla ve cevapları duyduğunuz haliyle tek sayfa gönderin:

Başarı:    en büyük hesapta export 60 saniyenin altında, panelden ölçülür.
           Başarısızlık: çeyrek sonunda hâlâ 3 dakikanın üstündeyse.
Bozulmaz:  gecelik fatura işi, finansa giden haftalık rapor, partner beslemesi.
Sahipler:  alan adı ve DNS pazarlamada, sunucu hesabı IT'de,
           ödeme hesabının sahibi cumaya kadar netleşecek.
Önceki:    geçen yıl içeride bir deneme, veri sahibi değişince durmuş.
           Eski şema veritabanında duruyor, salt okunur.
Karar:     operasyon müdürü, iki gün içinde; fatura formatını değiştiren
           her şey için finansa danışılıyor.
Açık:      ödeme hesabının sahibi kim, eski şema silinebilir mi.

Düz metin, şablon yok, antetli kâğıt yok. Altına tek satır ekleyin: yanlış anladığınız bir şey varsa yazılı olarak düzeltsinler. Düzeltmeler işin özü, çünkü yanlış duyduğunuz versiyon inşa edeceğiniz versiyondu.

Aynı sayfayı her ara değerlendirmeye götürün. Altı hafta sonra biri hedefi farklı hatırladığında, ki hatırlayacak, konuşma kimin hafızasının daha iyi olduğu üzerine değil bir metin üzerine olur.

Nelere dikkat etmeli

• Beş soruyu acele sormak. İçinde sessizlikler olan kırk dakika, birine okunan yirmi dakikalık kontrol listesinden iyidir.
• Sıfatı cevap saymak. Daha hızlı, daha temiz, daha modern, daha güvenli: bunlar cevap değil, sorunun başlangıcıdır.
• Erişim sorusunu idari bulup atlamak. İlk aydaki gecikmelerin en güvenilir kaynağı odur.
• Notu sözleşme gibi yazmak. Metin savunma belgesine benzemeye başladığı anda insanlar düzeltmeyi bırakır ve kimsenin düzeltmediği not hiçbir işe yaramaz.

Bu beş sorunun hiçbiri zekice değil. İşe yaramalarının sebebi, bir projede normalde örtük kalan kısımları, cevaplar planı hâlâ değiştirebilecekken aynı konuşmaya taşımaları. Yakından izlediğim proje çöküşlerinin çoğu, herkesin korktuğu zor teknik problem yüzünden olmadı; bu beş sorudan biri hiç yüksek sesle sorulmadığı için oldu.