CTO’ya yalan söyleyip krizden sıyrılma olayı
(GrumpyOldDev.com)- Fortune 500 şirketindeki büyük bir müşteri projesi, bir vendor ürününe bağımlı şekilde başladı; ancak gerçekte yarı mamul ürüne yakın bir yazılımdı ve ağır özelleştirme gerektiriyordu
- Vendor entegrasyonu, esnek olmayan bir paket ile özel geliştirmelerin dezavantajlarını aynı anda yarattı ve Ağustos teslimatının ardından Ekim çıkışını yetiştirmeye çalışan bir entegrasyon death march’ına dönüştü
- Tüm müşteri işlemlerini tek bir dev JSON belgesinde saklayan tasarım performans sorunları yarattı ve MongoDB’nin o dönemki belge başına 16MB sınırı, gerçek veri dönüşümünde ölümcül bir kısıt olarak ortaya çıktı
- Şirket, sorunu müşteriden ve vendor’dan gizleyerek çıkışı bir ay erteledi ve 3 kişilik iç ekiple vendor entegrasyonunun yerine geçecek bir skunkworks yeniden yazımını yaklaşık 2 ay içinde gerçekleştirdi
- Noel’den hemen önce CTO tatilde çalışılmasını emredince ekip lideri, zaten bitirilmiş işleri her gün hâlâ sürüyormuş gibi raporlayarak geliştiricilerin dinlenmesini sağladı; ekip de Ocak test takvimini ve çıkışı yetiştirdi
Vendor ürünüyle başlayan hatalı tasarım
- Fortune 500 şirketinde CTO, kişisel bağlantısı olan önemli bir müşteri için büyük bir proje teslim etmeyi taahhüt etti
- Çekirdek kısımlar büyük bir teknoloji hizmetleri şirketine outsource edildi ve vendor, ağır işlerin çoğunu halledecek bir ürünü olduğunu iddia etti
- Gerçekte ürün, gereksinimlere kabaca uyuyordu; yani istenen davranışı elde etmek için ağır özelleştirme gerekiyordu
- Sonuç olarak vendor yazılımı ile özel yazılımın dezavantajları birlikte ortaya çıktı
- Asıl tasarım amacı dışında işler yapmaya zorlanan esnek olmayan bir paket haline geldi
- Vendor’ın ana kod tabanından fork edildiği için bakım maliyeti arttı ve bir gün desteğin bitmesi ihtimali doğdu
- Projeye dahil olanlar bu yaklaşımın iyi olmadığını görüyordu; ancak CTO’ya doğrudan raporlama zincirinin sık sık değiştiği bir ortamda durum toplantıları “harika fikir, patron” havasında geçiyordu
Takvim gecikmesi ve ölümcül veri yapısı
- İç geliştirme ekibi projenin diğer bölümlerini kendi geliştirdi; vendor ise yaz boyunca ürünün yakında entegre edilebilir hale geleceğine söz verdi
- Ağustos’ta vendor ürünü teslim edilince, Ekim çıkışını hedefleyen bir entegrasyon death march’ı başladı
- Eylül’de çıkışı engelleyecek seviyede bug’lar ortaya çıktı
- Vendor ürünü, tüm müşteri işlemlerini tek bir dev JSON belgesi içinde JSON kayıtları olarak saklıyordu
- Test verisi biriktikçe performans giderek yavaşladı
- Her yeni işlem eklendiğinde veritabanından tüm JSON belgesi okunuyor, ardından sonuna yeni kayıt ekleniyordu
- Vendor, işlem alanlarına indeks eklenirse bunun çözülebileceğini söyledi ve bu yaklaşım kısa süreliğine işe yarıyor gibi göründü
MongoDB 16MB sınırı ve gizli yeniden yazım
- Daha büyük sorun, vendor’ın seçtiği veritabanının MongoDB olması ve o dönemde MongoDB’de belge başına 16MB sınırı bulunmasıydı
- Ekim’de dönüşüm ekibi gerçek müşteri verilerini yüklemeye başlayınca 16MB sınırına takılmaya başladılar
- Şirket, bu sınırı müşteriden gizleyerek sistemi bir ay gecikmeli canlıya alma kararı verdi
- Aynı anda vendor entegrasyonunun yerini alacak bir skunkworks projesi başlatıldı
- Vendor’a da bu durum söylenmedi
- Yani hem müşteriden hem de teknoloji partnerinden temel durum gizlenmiş oldu
- Başta vendor tarafında yaklaşık 70 kişi çalışırken, içteki alternatif işe sadece 3 kişi atandı
- 1 kişi veritabanı tasarımı
- 1 kişi veritabanıyla arayüz kuran backend’in geliştirilmesi
- 1 kişi iş mantığı ve web servislerinin geliştirilmesi
Tatil death march’ı öncesindeki karar
- Müşteriye, Ocak ayında test edilecek yeni bir sürüm verileceği ve ilk canlıya geçişte kabul edilen en kritik kusurların düzeltileceği bildirildi
- Ancak tüm çekirdek sistemin yaklaşık 2 ay içinde yeniden yazıldığı müşteriye söylenmedi
- Orijinal proje canlıya çıkana kadar 1 yıldan uzun sürmüştü; ama yeniden yazımın, tatil dönemi dahil olmak üzere 3 kişi tarafından yapılması gerekiyordu
- Aralık ortasına doğru projedekilere talep değil emir olarak tatilde çalışma bildirildi
- Ekip üyelerinin çoğu zaten 6 aydır haftada 60–80 saat çalıştığı için tükenmişlik durumundaydı
- Yazılım çıkışları, sahne performansına benzer bir baskı ve ödül duygusu verir
- Aylar ya da yıllar boyunca hazırlanan sonucun çıkış gününde gerçek kullanıcılara ulaşması söz konusudur
- Geliştirici, “başardım” hissi ve kullanıcı tepkileri üzerinden güçlü bir tatmin yaşar
- Yazılım çıkışı, içe dönük insanlar için canlı performansa benzer gelebilir
CTO’ya yalan rapor verip ekibi dinlendirdikleri hafta
- Noel yaklaşırken 3 kişilik ekip, bir ay içinde alternatif yazılımı neredeyse tamamladı
- Hâlâ toparlanacak özellikler vardı; ancak ekip tükenmezse Ocak test takvimi yetiştirilebilecek durumdaydı
- CTO tatilin iptal edilmesini emredince ekip lideri görünüşte “Tamam” diye yanıt verdi
- Gerçekte ise 3 geliştiriciye “Bir hafta dinlenin. Ben hallederim” dedi
- Ekip lideri her sabah zorunlu durum toplantısına girip CTO’ya, aslında geçen ay bitirilmiş işleri hâlâ sürüyormuş gibi raporladı
- “Ekip çok sıkı çalışıyor. Bugün entegrasyon milestone #73’e ulaştık”
- “Dün ekip iyi ilerleme kaydetti ve bir web servisini daha tamamladı”
- Geliştiriciler bir hafta sonra yeniden enerji toplamış halde geri döndü
- Ekip Ocak takvimini yetiştirdi, iyi bir çıkış gerçekleştirdi ve kısa bir süreliğine rock yıldızı gibi hissetti
- Geriye dönüp baktığında, bunun The Beatles’tan çok Herman’s Hermits’e benzediğini ama yine de güzel hissettirdiğini anlatıyor
1 yorum
Hacker News görüşleri
“Teslim tarihi odaklı” olduğu gerekçesiyle tatilini iptal edip çalışmaya devam eden biriyseniz, bunu bizzat yaşamış biri olarak artık aptallık etmeyin demek isterim.
Çok çalışmanın takdir edilmesi özellikle durmayı zorlaştırır, ama sonunda o zamanın tamamından pişman olursunuz.
Bir şirket, ürün satabilmek için çalışanlarının hafta sonlarını ve izinlerini doğal olarak kullanabileceği bir düzen kurmuşsa, bugünkü sorunlu dünyayı yaratmaya katkıda bulunuyor demektir.
Çok kişi böyle yaparsa daha da çok kişinin böyle yapması gerekir; kimse yapmaz ve bu talebin baştan saçma olduğunu davranışlarıyla gösterirse şirket, CEO’nun cebi acısa bile gerçekçi tahminler yapmak zorunda kalır.
Tatil planınızı bildirin, yerinize bakacak kişiyi ayarlayın, ekip takvimine ekleyin, devir teslimi yapın ve sonra sadece dinlenin.
Projeler gelir geçer, takvimler kendiliğinden de sarkar.
Tatilinizi proje takvimine göre oynatmaya başlarsanız hayatınız boyunca tatile çıkamazsınız.
İstisna olsa olsa yıl sonu, çeyrek sonu, vergi sezonu gibi yoğun dönemlerin açıkça bilindiği rollerde o sırada ortadan kaybolmanın uygunsuz olduğu durumlardır.
Kuzenim, kötü yönetilen bir projeyi bitirmek için Eylül 2023’ten Ocak 2024’e kadar neredeyse her gün gece 1’e kadar çalıştı; yalnızca Noel’de izin yaptı, o da dini tatil olduğu için çalışanlar dava açmasın diye direktörün izin vermesindendi.
Önemli şeyleri kaçırdı ve stresten yaklaşık 20 pound verdi.
Şirketin yeni sisteme geçmesi gereken sıkışık bir son tarihi vardı; bunu 5 yıl önceden bildikleri halde önceki yıla kadar başlamamışlardı.
Son tarih kaçarsa sözleşme dışı maliyetler milyonlarca doları bulacaktı; ekip sonunda tarihi tutturdu ama ödülleri birkaç hafta sonra pozisyonun kaldırıldığı gerekçesiyle işten çıkarılmak oldu.
Şimdi 50’lerini geçmiş halde, iş aramak için en kötü dönemde iş bulmaya çalışıyor.
Kendilerini değerli ve önemli hissetmeye bağımlılar; işten çıkınca da yapacak başka işleri yok.
Bazı vakalarda ödül alan çalışanların o karmaşada kısmen sorumluluğu da vardı.
Ancak dördüncüden sonra odadaki üst düzey yöneticiler şirkette yapısal bir sorun olduğunu fark etti.
Genç insanlar bunu okuyorsa, bu tür hikâyelerin böyle ilerlemesi şirkete ve şansa çok büyük ölçüde bağlıdır.
Sağlıklı bir şirkette dış kaynakla uygulama geliştirme yönteminin kendisi muhtemelen hiç başlamazdı.
Çünkü deneyimli birinin daha başlamadan sonucu öngörebileceği kadar bariz bir başarısızlık kalıbıydı.
Daha erken bir aşamada insanlar CTO’ya her şeyin iyi gittiği yalanını söylemek yerine, iyi gitmediğini söylerdi.
Projeyi kurtarmak için daha akıllı ya da yaratıcı bir yol gerekseydi, CTO ile, belki müşteriyle de birlikte ayarlama yapılırdı.
Ekip zaten tükenmişlik yaşarken tatil günlerinde uzun saatler bastırılmazdı.
Yönetici ya da lead, projenin başarısı ve ekibin sağlığı için üst yönetime karşı çıkar, gerekirse ekibin tatilde dinlenmesi gerektiğini savunurdu.
“Yarı sağlıklı” organizasyonlarda yöneticiler bilerek muğlak davranabilir ya da bilgiyi eksik aktarabilir; bunun iyi mi kötü mü olduğu duruma göre değişir.
Ama bu hikâyede olduğu gibi bir yönetici ya da lead komuta zincirinin üstüne tekrar tekrar açıkça yalan söylediyse, şirket sağlıklı olsun olmasın bu genellikle çok kötü görülür.
Elbette böyle bir durumu sonradan kolları bağlayıp değerlendirmek çok daha kolaydır.
Zor bir pozisyonda ya da aşırı çalışmış halde herkes hata yapabilir; yine de benzer çetin bir duruma yeniden atıldığınızda daha iyi tepki verebilmek için senaryoyu görüp öğrenmenin anlamı var.
Böyle bir şirketteyseniz yeni iş aramaya başlamak iyi olur.
Üst kademedeki çürüme bu seviyedeyse düzeltilemez ve zaten sizi CTO da yapmazlar.
Son 25 yıldır çalışıyorum, bir kez bile görmedim.
Düzeltmesi bir buçuk yıl sürdü; bu süre içinde “iç çamaşırı” gönderildiği gerekçesiyle satışı geri alamıyorduk.
Aslında iç çamaşırı satmıyor, yalnızca ağ hizmeti satıyorduk; buna rağmen müşteriye yardım edebilmek için sistemin sipariş sürecini kapatmasını beklemek zorundaydık.
O yönetim kurulu üyesi bir yıl sonra ayrıldı ve aptal CEO’yu kandırdığı için epey memnun olmuştur diye düşünüyorum.
Ben sonunda oradan kovuldum ve o panik içindeki şirkete hiç acımıyorum.
“Çözümü” dışarıya yaptırmaya çalışıp herkese yalnızca daha fazla acı çektiren aptallardı.
Gerçekten çözülmesi gereken sorunlar da var ama yarısı sadece “şirket içinde yapmayıp para tasarrufu ediyoruz” hissi vermek için üretilmiş çöpten ibaret.
Sonunda en başta yapmadığınız çöpü ayakta tutmak için sözleşme bedeli ödemeye devam ediyorsunuz.
Sorunları saklamadan olduğu gibi söylemekten bahsediyorum; bu gerçekten nadir bir şey.
Microsoft’un güvenlik notlarına bakmak bile yeterli.
Tatillerde death march olmaması, bir bankada ya da FAANG’de çalışıyorsanız bir ölçüde doğru.
“Startup kültürü” olan bir şirketteyseniz bunu unutun.
Gerçekte işin içine kendi çıkarınız girince işe bakışınız oldukça hızlı değişiyor; ama böyle bir fırsatı elde edip bunu görebileceğiniz şirket sayısı pek fazla değil bence.
Kimse bilmeden, gecenin bir yarısı kuralları bükerek gerekli işi yaptığım çok oldu; yetkin insanlar arasında da bu yolu izleyen çok kişi var.
Hatta bankalarda bile buna tanık oldum.
Şirketin ya da ekibin değerinden daha büyük bir finansal bahse girmediğiniz sürece birçok şey görmezden gelinebilir.
Ya işi başarıp terfi edersiniz ya da terfi ihtimalinizi kendiniz azalttığınız için yeni bir iş aramaya başlarsınız.
“Tedarikçinin ürünü, tüm müşteri işlemlerini devasa bir JSON belgesinin içindeki JSON kayıtları olarak saklıyordu; yeni bir işlem eklemek için veritabanından tüm JSON belgesini okuyup sonuna yeni kaydı ekliyordu” kısmının kulağa çılgınca gelmesi normal
Benzer şekilde bir fonun potansiyel yatırım hedefi için teknik due diligence desteği verdiğim olmuştu; o startup’ın kullanıcı tablosunda bilet/rezervasyon verileri de birlikte duruyordu
Bir bilet bir sütundu; bu yüzden en aktif kullanıcının tüm geçmişinde 5 bileti varsa 5 sütun gerekiyordu
İncelediğimiz sırada zaten 500’den fazla sütun vardı ve “ölçeklenmek” için yatırım arıyorlardı
Elbette çözülebilir bir sorun ama tahmin edileceği gibi her şey ters yüz edilmiş bir şekilde tasarlanmıştı; en bariz “bu da ne böyle” anı buydu
Yatırım alamadılar
Tüm müşteri ve ürün veritabanı, düz metin parolalarla birlikte birkaç megabaytlık herkese açık tek bir
.jsdosyasında tutuluyordu; 2000’lerin başındaki internet hızlarında uygulamanın herhangi bir şey yapmadan önce o dosyanın tamamını yüklemesi gerekiyorduÜstelik uygulama tek bir dev dosyaydı ve dizinde
index.1.js,index.final.js,index.newest.js,index.45.jsgibi adlarla dolu dosyalar vardıEn iyi uygulamaları bilecek kadar deneyimim vardı; CEO’ya gidip CTO’yu işten attırdım ve
git,mysql, sunucu tarafı mantık ve gerçek bir yapıyla sistemi yeniden kurmaya başladımSonra tüm bunların çalıştığı Windows sunucusu hacklenip porno sunucusuna dönüştü; ben o sunucuyu hiç görmemiştim ve yönetici yetkim de yoktu ama nedense sorumlusu ben oldum
İlk birkaç iş gerçekten öğreticiydi
Stanford mezunu olmakla övünen kıdemli bir mühendis o sistemi tasarlamıştı
Yayına alınırsa ölçeklenmeyeceğini gerçek operasyon verilerine dayanarak uzun uzun tartıştım ama kimse dinlemedi; yayından birkaç hafta sonra çöktü
Kısa süre sonra ekip değiştirdim; en kötüsü de o kıdemli mühendisin sonunda terfi etmesi ve sistemin tamamen yeni bir ekibe devredilip onların boğuşmasına bırakılmasıydı
Tüm sistem tasarımı korkunçtu; nedenini tahmin edebilirsiniz
Yöneticileri gösterişli akşam yemekleri ve seyahatlerle tavlayıp berbat ürünü teslim ediyorlar, böylece ileride de kendilerine ihtiyaç duyulmasını sağlıyorlar
Hikâyenin kendisinde CTO hiçbir şeyden habersizdi
Onun açısından bakınca sonunda her şey yoluna girmiş gibi görünüyor
Haftada 80 saat çalışan geliştiriciler hariç herkes için kazanç
Bu hikâyedeki her şey bozuk; başkahramanın yaklaşımı da dahil
Bir ekip liderinin insanlara izin verip bunu yalanla gizlemesi tamamen kabul edilemez ve şirketin işten çıkarabileceği alanın epey içine girer
Hatta fiilen haklı nedenle fesih bile mümkün görünüyor
Yine de üst yönetim o kadar raydan çıkmış görünüyor ki muhtemelen üstü kapatılır, hatta övgü bile alabilir
Bulunduğu ortama göre davranmış gibi görünüyor
Yeni ekip liderlerine tavsiyem şu olurdu: burada gurur duyulacak bir şey yok; daha iyi seçenek, insanların fazla mesai yaptığını açıkça sorun haline getirip tedarikçiye normal standartlar uygulanmasını ya da proje kapsamının normal çalışma haftasına göre yeniden değerlendirilmesini talep etmektir
Böyle bir durumu bir şekilde yürür hale getirirseniz, hiçbir kazanç olmadan sadece insanlar tükenir ya da işten çıkarılabilir
Aile geçindirmek için gerçekten çaresiz bir durumda değilseniz, ekip liderinin sorumluluğu ekibinin makul çalışma saatlerini çılgın taleplerden korumaktır
Bu, işten atılmayı göze alacağınız bir tepedir; yalan söylenecek bir tepe değil
Dolayısıyla performansı etkilemediyse ekip liderinin insanlara izin vermesi, hatta yalan söylemesi bile gayet kabul edilebilir
Paylaşılsaydı yönetim ne yapardı? Projeyi daha da öne çekerdi
Kendi şanı için başkalarını daha da sert çalıştırmak isteyenlere bir ders vermek gerekir
Tam olarak kimin gününü kurtardılar?
Çöp teslim eden berbat tedarikçinin mi?
Etrafını evet efendimcilerle doldurmuş ve şirkette neler olduğundan açıkça habersiz olan CTO’nun mu?
İliklerine kadar çalıştırılıp sonra “sorun yok, sana bir hafta izin verdim ya” denilen geliştiricilerin mi?
Çalışanları umursamayan bir şirketin keyfi son teslim tarihine yetişmek için herkese yalan söyleyen başkahramanın mı?
Bu hikâyenin her anında içim ürperdi
Ben çalışkan biriyim; müşteri için yayına geçişi sorunsuz yapmak adına ara sıra ekstra çalıştığım da oldu ama bu hikâye saf delilik
Bazen daha fazla zaman harcamak, yöneticinizle aranızda bir güven ilişkisi olduğu ve her zaman gerçeği söyleyebileceğinizi bildiğiniz için mümkündür
Aslında suçlamasız kültürün temel kavramı budur ve ancak herkes gerçeği söylediğinde mümkündür
Aptal bir CTO’nun son teslim tarihine yetişmek için delirmiş gibi yalan söylemek kelimenin tam anlamıyla akıl kârı değil
Böyle bir durumdaysanız hemen çıkıp daha iyi bir iş bulmalısınız
“Gurur ve başarı hissi” ile tükenmişlik mi?
“Ocak takvimini de tuttuk, harika şekilde yayına aldık ve kısa süreliğine rockstar olduk” kısmındaki “biz” açıkça ben demek
Şanslı olmuş olabilirim ama doğruyu söylediğim için hiç kovulmadım; ayrıca doğruyu tutturmak daha kolaydı.
“Kritik yoldaki üçüncü taraf bir kütüphanede bug var. Bug’a denk gelmeyi zorlaştırabiliriz ama vendor düzeltmeden biz düzeltemeyiz” ya da “Kullanıcı artışı, performans sorununu beklediğimizden erken ortaya çıkardı. Düzeltmesi 2 ay sürecek; bu sırada altyapıya üç kat harcayarak hafifletebiliriz ya da performans yüzünden müşteri kaybedebiliriz” ya da “En büyük müşteri ilk iterasyonu aldıktan sonra ne istediğini ancak anladı. Bizim yapacağımızı sandığımız şeyden tamamen farklı. Onu yapıp gelir elde edebiliriz ya da hayalin peşinden gidip ölebiliriz” demek gibi.
Tekrar söylüyorum, şanslı olmuş olabilirim ama dürüstlük benim için iyi işledi.
Bu yüzden başkalarının da dediği gibi “inceleyeceğim” deyip sonra yavaşça kenara iterler ya da angarya işlere verirler.
İkinci seçenek, ağzını kapatıp onların uzun süre debelenip başarısız olmasını izlemektir.
Genelde yaklaşık 1 yıl sürer ama 2-3 ay içinde kapandığını ve sonraki çeyrekte liderliğin fiilen kesildiğini de gördüm.
Biri fikrini sorarsa endişelerini diplomatik biçimde anlatabilirsin; sormazsa sessiz de kalabilirsin.
Asıl mesele, senden daha üstteki birinin övgüyü toplamak istediği plandaki sorunları aktif biçimde işaret edip etmeyeceğindir.
Bunu söylediğin anda, kendi muhakemelerinin sorgulandığını hissedip bunu kişisel saldırı olarak algılarlar.
Düşman yaratmadan yapmak son derece zordur; düşmanlar uzun süre kalır ve tek bir düşmanın vereceği zarar, birkaç arkadaşla telafi edilemeyecek kadar büyük olabilir.
Bu yüzden oyunu oynamak gerekir.
Kahramanın zaten bitmiş işler hakkında yalan söylüyor olması gerçekten önemli bir ayrıntı.
Her sabah CTO ile zorunlu death march durum toplantısına girip “ekip sıkı çalışıyor”, “bugün milestone entegrasyon noktası #73’ü tutturdum”, “dün iyi ilerleme kaydettik ve bir web servisini daha bitirdik” diyordu ama gerçekte bunlar önceki ay zaten tamamlanmış işlerdi.
Bir açıdan bakınca bu, düşük taahhüt verip yüksek teslimat yapmak gibi görünüyor.
Henüz bitmemiş bir işin bittiği yalanını söyleseydi bu çok daha kötü hissettirirdi.
Kesinlikle daha riskli olurdu; ekip döndüğünde “burada ticket’lar var ama CTO’ya bunların zaten bittiğini söyledim, o yüzden acele edin” demek de ekip açısından iyi olmazdı.
Geliştiricilerle yönetim arasındaki etkileşim bilgi asimetrisi ve güven eksikliği yüzünden ciddi şekilde zarar görüyor.
Şu anda çok eski bir compiler üzerinde çalışan bir codebase’i güncelleme projesi yapıyorum.
1 yıldır üzerinde çalışıyoruz ve sistemin büyük parçaları bitti ama oldukça önemli bir bölüm hâlâ duruyor.
Yönetim süreci anlamıyor ve projenin sonunda başarılı olacağına dair güveni de yok.
Yazılım projelerinin, özellikle de dönüşüm işlerinin uzun bir başarısızlık geçmişi olduğu için tedirgin olmalarını suçlamıyorum.
İlerleme toplantılarını haftada bir yapıyorduk, şimdi haftada ikiye çıktı; böyle olunca hızlanacağını düşünüyor gibiler.
Çoğunlukla kendileri doğrudan katılmıyor, orta kademe yönetici aracı rolünü üstleniyor.
Geliştirici açısından bakınca bunun elbette olacağı açık; şahsen başarıdan hiç şüphe etmedim.
Sadece sistem büyük ve eski olduğu için süre belirsiz.
Kalan şey yıllar değil aylar; 80/20 kuralını da biliyorum ama zaten o %20’nin oldukça içine girmiş durumdayız.
Yönetim için durum tamamlandı/tamamlanmadı diye ikili olduğu için ilerlemeyi ölçmeleri zor ve söylediklerimize “güven” yok.
Bunu anlayabiliyorum.
1 yıl boyunca hiçbir şey yapmamış olsak ve sadece toplantı yapmış olsak bunu bilemezlerdi.
Sabit fiyatlı sözleşme olduğu için bizim uzatmak için bir nedenimiz yok ama riskin tamamı onların üzerinde.
Zaten çok para harcadılar ve kaygılılar.
Dış teknik uzmanların tavsiyesine dayanarak iyi teknik kararlar aldılar ama hâlâ yeterince emin değiller.
Sonuçta proje başarısız olursa darbeyi onlar alacak, biz görece daha az etkileneceğiz.
Kolay bir çözüm yok.
Yöneticiler teknik olmalı demekle de olmuyor; o teknoloji onların ana işi de değil.
Daha fazla danışman çağırmak da içlerini ısıtmayacak.
Yapabileceğimiz en iyi şey devam edip teslim etmek.
Bir aylık parçalar bile olur; ayrıntılandırıp her şeyi alt görevlere bölmek yeterli.
Mükemmel olmak zorunda değil, pürüzlü kısımlar olabilir.
Her parçaya sevimli ve eğlenceli isimler vermeyi öneririm.
Örneğin tango, çaça, vals gibi klasik dans isimleri iyi olur.
Yöneticilerle bir toplantı ayarlayın, üst düzey yöneticileri de dahil edin ve orta kademe yöneticilerden günlük stand-up’lara gözlemci olarak katılmalarını isteyin.
Herkesi ayakta tutarak toplantının kısa bitmesini sağlayın ve listedeki işlere göre ilerlemeyi takip edin.
Bir iş eklenmesi ya da biraz gecikmesi, genel olarak hedefe yakın gidiyorsanız insanları şaşırtmaz.
İkimiz de gerçek deploy’un büyük eşik olduğunu biliyoruz ama hazır olana kadar bunu onlara söylemenize gerek yok.
Gecikme yönetimi kaygılandırır; bunu anlıyorum ama daha fazla toplantı yapmak işi hızlandırmaz.
PM’in her gün 30 dakika check-in yapıp “destek olmak ve projeyi tekrar rayına sokmak için gerekenleri sağlayacağım” demesi yardımcı olmaz.
Gereken tek şey toplantıların azalmasıdır.
Engel yalnızca zamandır; zamanın engel olmasının nedeni de en başta üst yönetimin gerçekçi olmayan bir takvimde ısrar etmesidir.
Sonuçta geliştiricilere güvenmediklerini göstererek, doğru geliştiricileri seçtiklerine dair kendi yönetim becerilerine de güvenmediklerini göstermiş oluyorlar.
Kendi işlerinin temel bir parçasında çok kötüler.
1 yıllık bir proje tamamlandı/tamamlanmadı diye ikili bir durumda olmamalı.
Ele alınabilir ilerleme göstergeleri olmalı.
Üst yönetimin teknik olması gerekmez ama hiyerarşinin bir yerinde ilerlemeyi anlaşılabilir bir formata çevirebilecek biri mutlaka olmalı.
Tedarikçi hakkında kesin olarak bildiğim iki şey affedilmesi zor
Biri, temel mantığı Mongo kayıtlarının sonsuza kadar büyümesine bağımlı hâle getirmiş olması; diğeri ise ortalamanın biraz üstünde üç kişinin bilinçli çabasıyla yaklaşık 3 ayda bunun yerini alabilecek bir şey yapabilmesiydi
O tedarikçinin Fortune 500 müşterileriyle iş yapar hâle gelmiş olması, bu müşteriye benzer kurumların çok da büyük olmayan yazılım işleri karşısında bile kendilerini ne kadar çaresiz hissettiğini gösteriyor
Aslında o projenin kapsamı, buradaki bazılarının hobi projesi olarak bile yapabileceği gibi görünüyor
Bu yüzden Retool'un teknik liderler arasında popüler olup mühendisler arasında her zaman öyle olmamasını da anlıyorum
Aynı boşluğu dolduracak başka nasıl ürün yaklaşımları olabilir, merak ediyorum
Elektronik tablolar sayesinde alt kademedeki herhangi biri, kurumda başka kimseyle uğraşmadan birkaç gün içinde neredeyse çalışan kaba bir araç prototipi yapabiliyordu
Elektronik tablolardan önce, üstleri ikna edip IT departmanının talebi üstlenmesini sağlamak gerekiyordu; sırf bu süreç bile en az 3 ay sürüyordu
Sonra birkaç çeyrek daha bekleyip, Cobol ya da C gibi bir şeyle yazılmış, gereksinimlerle uyuşmayan, neredeyse çalışan kaba bir uygulama alırdınız
Birkaç geliştirici ve birkaç destek personeli kullanıcılarla buluşmaya gitti; geliştiriciler büyük bir sorunu çözecek yeni bir aracı 6 aydır geliştiriyordu
Ama o gün, son kullanıcıların onu ilk kez gördüğü gündü
Çok geçmeden eyalet sınırını geçip geri dönüyorduk ve geliştiriciler başları öne eğik hâldeydi
Bildiğim kadarıyla o proje bir daha kimsenin ağzına alınmadı
İşi yeni başlayanlara yaptırıp kıdemli geliştirici saat ücretiyle faturalandırma yöntemi
İnsanların yapay zeka tarafından oluşturulmuş başlık görselleri kullanmayı bırakmasını isterdim
Daha baştan dikkatim dağılıyor
Şu kod monitörün arkasında mı?
Peki arkadaki sandalyenin sırtlığında da kod mu var? Yoksa oturan şey dev bir iPad mi?
Yapay zeka görseli kullanacaksanız en azından tamamen tuhaf ve delice görünmemesi için biraz uğraşmalısınız
Bu tür görseller kelimenin tam anlamıyla birkaç saniyede üretiliyor; seçtikleriniz arasındaki en iyisi bu muydu?