Tim Lister - kitapların ortak yazarı

• "İnsan faktörü. Başarılı Projeler ve Ekipler" (orijinal kitabın adı "Peopleware")
• "Ayılarla Vals Yapmak: Yazılım Projelerinde Riski Yönetmek"
• “Adrenalin çılgınlığı ve desenlerle zombileştirilmiş. Proje ekiplerinin davranış kalıpları"

Bu kitapların hepsi kendi alanlarında klasikler olup, meslektaşlarımızla birlikte yazılmıştır. Atlantik Sistemler Birliği. Rusya'daki meslektaşları en ünlüsü - Tom De Marco и Peter Hruschkabirçok ünlü eserin de yazarıdır.

Tim'in yazılım geliştirmede 40 yıllık tecrübesi var; 1975'te (bu habrapostu yazanların hiçbiri bu yıl doğmamıştı), Tim zaten Yourdon Inc.'in başkan yardımcısıydı. Artık zamanını danışmanlık yaparak, öğreterek ve yazarak geçiriyor ve ara sıra ziyaret ediyor. raporlarla dünya çapında konferanslar.

Tim Lister ile Habr'a özel bir röportaj yaptık. DevOops 2019 konferansının açılışını yapacak ve kitaplar ve daha fazlası hakkında birçok sorumuz var. Röportaj konferans program komitesinden Mikhail Druzhinin ve Oleg Chirukhin tarafından yürütülüyor.

Michael: Şu anda ne yaptığınız hakkında birkaç kelime söyleyebilir misiniz?

Tim: Atlantik Sistemler Birliği'nin başkanıyım. Loncada altı kişiyiz ve kendimize müdür diyoruz. Üçü ABD'de ve üçü Avrupa'da - bu yüzden Loncaya Atlantik deniyor. O kadar yıldır birlikteyiz ki sayamazsınız. Hepimizin uzmanlık alanları var. Son on yıldır veya daha fazla süredir müşterilerle çalışıyorum. Projelerim sadece yönetimi değil aynı zamanda ihtiyaç belirleme, proje planlama ve değerlendirmeyi de içeriyor. Kötü başlayan projeler genellikle kötü sonuçlanıyor gibi görünüyor. Bu nedenle, tüm etkinliklerin gerçekten iyi düşünülmüş ve koordine edildiğinden, yaratıcıların fikirlerinin birleştirildiğinden emin olmakta fayda var. Ne yaptığınızı ve nedenini düşünmeye değer. Projeyi tamamlamak için hangi stratejilerin kullanılacağı.

Yıllardır danışanlarıma çeşitli şekillerde danışmanlık yapıyorum. İlginç bir örnek, diz ve kalça ameliyatı için robot üreten bir şirkettir. Cerrah tamamen bağımsız hareket etmez, bir robot kullanır. Açıkçası burada güvenlik önemlidir. Ancak sorunları çözmeye odaklanmış insanlarla gereksinimleri tartışmaya çalıştığınızda... Garip gelebilir ama ABD'de var FDA (Federal İlaç İdaresi), bu robotlar gibi ürünlere lisans veriyor. Bir şey satmadan ve onu yaşayan insanlar üzerinde kullanmadan önce lisans almanız gerekiyor. Koşullardan biri gereksinimlerinizi, testlerin neler olduğunu, bunları nasıl test ettiğinizi, test sonuçlarının ne olduğunu göstermektir. Gereksinimleri değiştirirseniz, tüm bu devasa test sürecinden tekrar tekrar geçmeniz gerekir. Müşterilerimiz gereksinimlerine uygulamaların görsel tasarımını da dahil etmeyi başardılar. Gereksinimlerin bir parçası olarak doğrudan ekran görüntüleri vardı. Bunları ortaya çıkarmamız ve bu programların çoğunun dizler ve kalçalar, kamerayla ilgili tüm bu şeyler vb. hakkında hiçbir şey bilmediğini açıklamamız gerekiyor. Gerçekten önemli bazı temel koşullar değişmediği sürece, gereksinim belgelerini hiçbir zaman değişmeyecek şekilde yeniden yazmamız gerekiyor. Eğer görsel tasarım ihtiyaçlar arasında değilse ürünün güncellenmesi çok daha hızlı olacaktır. Bizim işimiz diz, kalça, sırt operasyonlarıyla ilgilenen unsurları bulup ayrı belgelere çekip bunların temel gereksinimler olacağını söylemek. Diz ameliyatlarıyla ilgili izole edilmiş bir gereksinimler grubu oluşturalım. Bu, daha istikrarlı bir gereksinimler dizisi oluşturmamıza olanak tanıyacaktır. Belirli robotlar hakkında değil, ürün serisinin tamamı hakkında konuşacağız.

Çok fazla iş yapıldı, ancak yine de önceden haftalarca ve aylarca tekrarlanan testleri gereksizce veya ihtiyaç duymadan geçirdikleri yerlere ulaştılar, çünkü kağıt üzerinde açıklanan gereksinimleri, sistemlerin oluşturulduğu gerçek gereksinimlerle örtüşmüyordu. FDA onlara her seferinde şunu söylüyordu: İhtiyaçlarınız değişti, artık her şeyi sıfırdan kontrol etmeniz gerekiyor. Ürünün tamamının yeniden kontrol edilmesi işletmeyi öldürüyordu.

Yani, kendinizi ilginç bir şeyin en başında bulduğunuzda harika görevler ortaya çıkıyor ve ilk eylemler oyunun diğer kurallarını belirliyor. Bu erken faaliyetin hem yönetimsel hem de teknik açıdan iyi çalışmaya başladığından emin olursanız, harika bir projeyle sonuçlanma şansınız vardır. Ancak bu kısım raydan çıktıysa ve yanlış bir yere gittiyse, temel anlaşmaları bulamıyorsanız... hayır, bu projenizin mutlaka başarısız olacağı anlamına gelmez. Ama artık “Harika iş çıkardık, her şeyi gerçekten etkili bir şekilde yaptık” diyemeyeceksiniz. Bunlar müşterilerle iletişim kurarken yaptığım şeyler.

Michael: Yani projeleri başlatıyorsunuz, bir tür başlangıç ​​yapıyorsunuz ve rayların doğru yönde ilerlediğini mi kontrol ediyorsunuz?

Tim: Ayrıca bulmacanın tüm parçalarını nasıl bir araya getireceğimiz konusunda da fikirlerimiz var: Hangi becerilere ihtiyacımız var, onlara tam olarak ne zaman ihtiyaç var, ekibin çekirdeği nasıl görünüyor ve bunun gibi temel şeyler. Tam zamanlı çalışanlara ihtiyacımız var mı yoksa yarı zamanlı birini işe alabilir miyiz? Planlama, yönetim. Şunun gibi sorular: Bu özel proje için en önemli olan nedir? Bu nasıl başarılır? Bu ürün veya proje hakkında ne biliyoruz, riskleri neler, bilinmeyenleri nerede, tüm bunlarla nasıl başa çıkacağız? Tabii o anda birisi “Peki ya çevik?!” diye bağırmaya başlıyor. Tamam hepiniz esneksiniz ama ne olmuş yani? Proje tam olarak nasıl görünüyor, projeye uygun bir şekilde nasıl çıkaracaksınız? "Yaklaşımımız her şeye yayılabilir, biz bir Scrum takımıyız!" diyemezsiniz. Bu saçmalık ve saçmalık. Bundan sonra nereye gideceksin, neden işe yaramalı, ne anlamı var? Müşterilerime tüm bu sorular hakkında düşünmeyi öğretiyorum.

19 yıllık çeviklik

Michael: Agile'da insanlar genellikle hiçbir şeyi önceden tanımlamamaya çalışırlar, ancak kararları mümkün olduğu kadar geç almaya çalışırlar ve şöyle derler: Biz çok büyüğüz, genel mimariyi düşünmeyeceğim. Bir sürü başka şeyi düşünmeyeceğim; bunun yerine müşteriye şu anda işe yarayan bir şey sunacağım.

Tim: Çevik metodolojilerin şunlardan başlayarak olduğunu düşünüyorum: Çevik Manifesto 2001 yılında sektörün gözünü açtı. Ama öte yandan hiçbir şey mükemmel değildir. Ben yinelemeli gelişimden yanayım. Yineleme çoğu projede çok anlamlıdır. Ancak düşünmeniz gereken soru şu: Ürün bir kez piyasaya sürüldüğünde ve kullanıldığında ne kadar dayanır? Bu, başka bir şeyle değiştirilmeden önce altı ay dayanacak bir ürün mü? Yoksa uzun yıllar işe yarayacak bir ürün mü? Elbette isim vermeyeceğim ama... New York'ta ve finans camiasında en temel sistemler çok eskidir. Bu harika. Onlara bakıyorsunuz ve keşke zamanda geriye gidip 1994'e dönebilseydiniz ve geliştiricilere şunu söyleyebilseydiniz diye düşünüyorsunuz: "Ben gelecekten, 2019'dan geldim. İhtiyacınız olduğu sürece bu sistemi geliştirin. Genişletilebilir hale getirin, mimariyi düşünün. Daha sonra yirmi beş yıldan fazla bir süre boyunca geliştirilecektir. Eğer gelişmeyi biraz daha ertelerseniz, büyük resimde kimse bunu fark etmeyecektir!” Uzun vadede bir şeyleri tahmin ederken, toplamda ne kadara mal olacağını düşünmeniz gerekir. Bazen iyi tasarlanmış mimari gerçekten buna değerdir, bazen de değmez. Etrafımıza bakıp kendimize şu soruyu sormalıyız: Böyle bir karar için doğru durumda mıyız?

Yani "Biz çeviklikten yanayız, müşterinin kendisi bize ne almak istediğini söyleyecektir" gibi bir fikir süper saflıktır. Müşteriler ne istediklerini bile bilmiyorlar, dahası ne alabileceklerini de bilmiyorlar. Bazıları argüman olarak tarihi örnekleri göstermeye başlayacak, bunu zaten gördüm. Ancak teknik açıdan ileri düzeydeki insanlar genellikle bunu söylemezler. Şöyle diyorlar: “Yıl oldu 2019, elimizdeki fırsatlar bunlar ve bunlara bakış açımızı tamamen değiştirebiliriz!” Mevcut çözümleri taklit edip biraz daha güzel ve daha taranmış hale getirmek yerine bazen çıkıp şöyle demeniz gerekir: "Burada yapmaya çalıştığımız şeyi tamamen yeniden keşfedelim!"

Ve çoğu müşterinin sorunu bu şekilde düşünebileceğini sanmıyorum. Sadece sahip oldukları şeyleri görüyorlar, hepsi bu. Daha sonra “bu işi biraz daha basitleştirelim” gibi isteklerle ya da genellikle ne diyorlarsa geliyorlar. Ama biz garson ya da garson değiliz, bu yüzden ne kadar aptalca olursa olsun sipariş alıp mutfakta pişirebiliriz. Biz onların rehberleriyiz. Onların gözlerini açıp şunu söylemeliyiz: Hey, burada yeni fırsatlarımız var! İşinizin bu kısmının yapılma şeklini gerçekten değiştirebileceğimizin farkında mısınız? Agile'ın sorunlarından biri, neyin fırsat, neyin sorun olduğu, hatta ne yapmamız gerektiği, hangi mevcut teknolojilerin bu özel duruma en uygun olduğu konusundaki farkındalığı ortadan kaldırmasıdır.

Belki de burada aşırı şüpheci davranıyorum: Çevik topluluğunda pek çok harika şey oluyor. Ancak insanların bir proje tanımlamak yerine tereddüt etmeye başlamasıyla ilgili bir sorunum var. Burada şunu soracağım; ne yapıyoruz, nasıl yapacağız? Ve bir şekilde sihirli bir şekilde müşterinin herkesten daha iyi bilmesi gerektiği ortaya çıkıyor. Ancak müşteri, yalnızca birisi tarafından halihazırda inşa edilmiş şeyler arasından seçim yaptığında en iyisini bilir. Bir araba satın almak istiyorsam ve aile bütçemin büyüklüğünü biliyorsam, yaşam tarzıma uygun bir arabayı hızla seçeceğim. Burada her şeyi herkesten daha iyi biliyorum! Ancak lütfen birisinin arabaları zaten yaptığını unutmayın. Yeni bir arabanın nasıl icat edileceğine dair hiçbir fikrim yok, uzman değilim. Kişiye özel veya özel ürünler yarattığımızda müşterinin sesini dikkate almak gerekiyor ama artık tek ses bu değil.

Oleg: Çevik Manifesto'dan bahsettiniz. Konunun modern anlayışını dikkate alarak bir şekilde güncellememiz veya revize etmemiz gerekiyor mu?

Tim: Ona dokunmazdım. Bence harika bir tarihi belge. Demek istediğim odur. 19 yaşına giriyor, yaşlı ama zamanında devrim yaptı. İyi yaptığı şey, bir tepkiyi tetiklemesi ve insanların onun hakkında fısıldaşmaya başlamasıydı. Muhtemelen 2001 yılında sektörde henüz çalışmıyordunuz ama sonra herkes süreçlere göre çalıştı. Yazılım Mühendisliği Enstitüsü, yazılım tamlık modelinin (CMMI) beş seviyesi. Bu tür derin antik efsanelerin size bir şey anlatıp anlatmadığını bilmiyorum, ama o zaman bu bir atılımdı. İlk başta insanlar, süreçlerin doğru kurulması durumunda sorunların kendiliğinden ortadan kalkacağına inanıyorlardı. Ve sonra Manifesto ortaya çıkıyor ve şöyle diyor: "Hayır, hayır, hayır; biz süreçleri değil, insanları esas alacağız." Biz yazılım geliştirmenin ustasıyız. İdeal sürecin bir serap olduğunu anlıyoruz, olmuyor. Projelerde çok fazla kendine özgülük var, tüm projeler için tek bir mükemmel süreç fikri hiçbir anlam ifade etmiyor. Sorunlar, her şeyin tek bir çözümü (merhaba, nirvana) olduğunu iddia edemeyecek kadar karmaşıktır.

Geleceğe bakmayı düşünmüyorum ama insanların artık projeler hakkında daha fazla düşünmeye başladığını söyleyebilirim. Çevik Manifesto'nun hemen ortaya çıkıp şunu söyleme konusunda çok iyi olduğunu düşünüyorum: “Hey! Bir gemidesiniz ve bu gemiyi kendiniz sürüyorsunuz. Bir karar vermeniz gerekecek; tüm durumlar için evrensel bir tarif önermeyeceğiz. Siz geminin mürettebatısınız ve yeterince iyiyseniz hedefinize giden bir yol bulabilirsiniz. Senden önce başka gemiler vardı, senden sonra da başka gemiler olacak ama yine de yolculuğun bir bakıma benzersiz.” Bunun gibi bir şey! Bu bir düşünme biçimidir. Benim için güneşin altında yeni bir şey yok, insanlar daha önce de yelken açtılar ve yine açılacaklar ama sizin için bu sizin ana yolculuğunuz ve size tam olarak ne olacağını söylemeyeceğim. Bir takımda koordineli çalışma becerisine sahip olmalısınız ve eğer gerçekten bunlara sahipseniz her şey yoluna girecek ve istediğiniz yere ulaşacaksınız.

İnsanlara yönelik yazılımlar: 30 yıl sonra

Oleg: Peopleware Manifesto kadar bir devrim miydi?

Tim: İnsanlar... Tom ve ben bu kitabı yazdık ama böyle olacağını düşünmemiştik. Bir şekilde birçok insanın fikrinde yankı buldu. Bu, şunu söyleyen ilk kitaptı: yazılım geliştirme çok insan yoğun bir faaliyettir. Teknik doğamıza rağmen biz aynı zamanda büyük, hatta devasa, çok karmaşık bir şey inşa eden insanlardan oluşan bir topluluğuz. Kimse tek başına böyle şeyler yaratamaz, değil mi? Böylece "ekip" fikri çok önemli hale geldi. Ve sadece yönetim açısından değil, aynı zamanda bir sürü bilinmeyenle dolu gerçekten karmaşık, derin sorunları çözmek için bir araya gelen teknik insanlar için de. Kişisel olarak benim için bu, kariyerim boyunca büyük bir zeka sınavı oldu. Ve burada şunu söyleyebilmeniz gerekiyor: evet, bu sorun tek başıma halledebileceğimden daha fazlası, ancak birlikte gurur duyabileceğimiz zarif bir çözüm bulabiliriz. Ve sanırım en çok yankı uyandıran fikir bu oldu. Zamanın bir kısmında kendi başımıza, bir kısmında bir grubun parçası olarak çalıştığımız ve çoğu zaman kararların grup tarafından verildiği fikri. Grup problem çözme, hızla karmaşık projelerin önemli bir özelliği haline geldi.

Tim'in çok sayıda konuşma yapmasına rağmen bunların çok azı YouTube'da yayınlanıyor. 2007 tarihli “İnsan Yazılımlarının Geri Dönüşü” raporuna bakabilirsiniz. Kalite elbette arzulanan çok şey bırakıyor.

Michael: Kitabın yayımlanmasından bu yana geçen 30 yılda herhangi bir şey değişti mi?

Tim: Buna birçok farklı açıdan bakabilirsiniz. Sosyolojik açıdan konuşursak... bir zamanlar, daha basit zamanlarda siz ve ekibiniz aynı ofiste oturuyordunuz. Her gün yakınlaşabilir, birlikte kahve içebilir ve iş hakkında konuşabilirsiniz. Gerçekten değişen şey, ekiplerin artık coğrafi olarak farklı ülke ve saat dilimlerine dağılabilmesi, ancak hâlâ aynı sorun üzerinde çalışıyor olmaları ve bu da tamamen yeni bir karmaşıklık katmanı eklemesidir. Bu kulağa eski tarz gelebilir ama hepinizin bir arada olduğu, birlikte çalıştığı ve bir meslektaşının yanına gidip "bakın ne keşfettim, bunu nasıl buldunuz?" diyebileceğiniz yüz yüze iletişim gibisi yoktur. Yüz yüze görüşmeler, resmi olmayan iletişime geçiş için hızlı bir yol sağlar ve bence çevik tutkunlarının da bundan hoşlanması gerekir. Ayrıca endişeleniyorum çünkü gerçekte dünya çok küçük hale geldi ve artık her şey dağınık ekiplerle kaplı ve her şey çok karmaşık.

Hepimiz DevOps'ta yaşıyoruz

Michael: Konferans program komitesi açısından bile Kaliforniya'da, New York'ta, Avrupa'da, Rusya'da insanlarımız var... Singapur'da henüz kimse yok. Coğrafya farkı oldukça büyük ve insanlar daha da fazla yayılmaya başlıyor. Eğer geliştirmeden bahsediyorsak, devop'lar ve ekipler arasındaki engellerin kaldırılması hakkında bize daha fazla bilgi verebilir misiniz? Herkes sığınaklarında oturuyor diye bir kavram var, şimdi sığınaklar çöküyor, bu benzetmeye ne diyorsunuz?

Tim: Bana öyle geliyor ki son teknolojik gelişmelerin ışığında devops büyük önem taşıyor. Önceden, geliştiricilerden ve yöneticilerden oluşan ekipleriniz vardı, çalıştılar, çalıştılar, çalıştılar ve bir noktada yöneticilere gelip onu üretime sunabileceğiniz bir şey ortaya çıktı. Ve burada sığınakla ilgili konuşma başladı, çünkü yöneticiler bir nevi müttefiktir, en azından düşman değil, ancak onlarla yalnızca her şey üretime geçmeye hazır olduğunda konuştunuz. Onlara bir şeyle gidip şöyle dediniz mi: bakın ne uygulamamız var ama bu uygulamayı yayınlayabilir misiniz? Ve şimdi tüm teslimat konsepti daha iyiye doğru değişti. Demek istediğim, değişiklikleri hızlı bir şekilde gerçekleştirebileceğinize dair bir fikir vardı. Ürünleri anında güncelleyebiliriz. Dizüstü bilgisayarımdaki Firefox açılıp şöyle dediğinde her zaman gülümserim: Hey, arka planda Firefox'unuzu güncelledik ve bir dakikanız olur olmaz buraya tıklar mısınız, size en son sürümü vereceğiz. Ben de "Ah evet bebeğim!" Ben uyurken, bilgisayarımda bana yeni bir sürüm sunmaya çalışıyorlardı. Bu harika, inanılmaz.

Ancak zorluk şu: Yazılımı güncellerken bu özelliğe sahipsiniz, ancak insanları entegre etmek çok daha zor. DevOops'un açılış konuşmasında dile getirmek istediğim şey şu ki, artık şimdiye kadar sahip olduğumuzdan çok daha fazla oyuncumuz var. Tek bir takımda yer alan herkesi düşünürseniz…. Bunu bir ekip olarak düşündünüz ve bu, programcılardan oluşan bir ekipten çok daha fazlası. Bunlar test uzmanları, proje yöneticileri ve bir grup başka insandır. Ve herkesin dünya hakkında kendi görüşleri vardır. Ürün yöneticileri proje yöneticilerinden tamamen farklıdır. Yöneticilerin kendi görevleri vardır. Tüm katılımcıların neler olup bittiğinin farkında olmaya devam etmeleri ve çıldırmamaları için koordine etmek oldukça zor bir sorun haline geliyor. Grubun görevleri ile herkes için geçerli olan görevleri ayırmak gerekir. Bu çok zor bir iştir. Öte yandan, her şeyin yıllar öncesine göre çok daha iyi olduğunu düşünüyorum. Bu tam olarak insanların büyüdüğü ve doğru davranmayı öğrendiği yoldur. Entegrasyon yaptığınızda, yazılımın son anda kutudan çıkan bir kutu gibi sürünmemesi için yeraltında bir gelişme olmaması gerektiğini anlıyorsunuz: mesela, burada ne yaptığımıza bakın! Buradaki fikir, entegrasyon ve geliştirmeyi yapabilmeniz ve sonunda düzgün ve yinelemeli bir şekilde ortaya çıkmanızdır. Bütün bunlar benim için çok şey ifade ediyor. Bu, sistemin kullanıcıları ve müşteriniz için daha fazla değer yaratmayı mümkün kılar.

Michael: Devops'un tüm fikri, anlamlı gelişmeleri mümkün olduğu kadar erken sunmaktır. Dünyanın giderek hızlanmaya başladığını görüyorum. Bu hızlanmalara nasıl uyum sağlanacak? On yıl önce bu yoktu!

Tim: Elbette herkes daha fazla işlevsellik istiyor. Hareket etmenize gerek yok, daha fazlasını toplayın. Bazen bir sonraki artımlı güncellemenin faydalı bir şey sunması için yavaşlamanız bile gerekebilir - ve bu tamamen normaldir.

Koşmanız, koşmanız, koşmanız gerektiği fikri en iyisi değil. Kimsenin hayatını bu şekilde yaşamak istemesi pek mümkün değil. Teslimatların ritminin projenin kendi ritmini belirlemesini isterim. Eğer sadece küçük, nispeten anlamsız şeylerden oluşan bir akış üretirseniz, bunların hiçbir anlamı kalmaz. İşleri mümkün olduğu kadar erken bir zamanda piyasaya sürmeye çalışmak yerine, lider geliştiriciler ve ürün ve proje yöneticileriyle tartışmaya değer olan şey stratejidir. Bu mantıklı mı?

Desenler ve anti-örüntüler

Oleg: Genellikle kalıplardan ve anti-örüntülerden bahsedersiniz ve projelerin yaşamı ile ölümü arasındaki fark da budur. Ve şimdi devops hayatımıza giriyor. Projeyi anında sonlandırabilecek kendi kalıpları ve anti kalıpları var mı?

Tim: Desenler ve anti-örüntüler her zaman meydana gelir. Konuşacak bir şey var. "Parlak şeyler" dediğimiz bir şey var. İnsanlar yeni teknolojiyi gerçekten ama gerçekten seviyorlar. Havalı ve şık görünen her şeyin parlaklığı karşısında büyüleniyorlar ve soru sormayı bırakıyorlar: Bu gerekli mi? Neyi başaracağız? Bu şey güvenilir mi, bir anlamı var mı? İnsanların tabiri caizse teknolojinin en ileri noktasında olduğunu sık sık görüyorum. Dünyada olup bitenler karşısında hipnotize olmuş durumdalar. Ancak yaptıkları yararlı şeylere daha yakından bakarsanız, çoğu zaman işe yarar hiçbir şeyin olmadığını görürsünüz!

Biz de az önce yoldaşlarımızla bu yılın, insanların aya ayak basmasının elli yıl dönümü olduğunu, yıldönümü olduğunu konuşuyorduk. Bu 1969'daydı. İnsanların oraya ulaşmalarına yardımcı olan teknoloji 1969'un teknolojisi bile değildi, daha ziyade 1960 ya da 62'ydi çünkü NASA yalnızca güvenilirliği konusunda iyi kanıtları olan şeyleri kullanmak istiyordu. Ve böylece ona bakıyorsunuz ve anlıyorsunuz - evet ve bunlar doğruydu! Hayır, hayır ama teknolojiyle sorun yaşıyorsunuz çünkü her şey çok fazla zorlanıyor, tüm çatlaklardan satılıyor. Her yerden insanlar bağırıyor: “Bakın bu ne biçim şey, bu dünyanın en yeni şeyi, en güzel şeyi, herkese yakışan şey!” İşte bu kadar... genellikle tüm bunların sadece bir tuzak olduğu ortaya çıkar ve sonra hepsinin atılması gerekir. Belki de bunun nedeni benim zaten yaşlı bir adam olmam ve insanların en iyi teknolojileri yaratmanın tek, en doğru yolunu bulduklarını söylemeleri karşısında bu tür şeylere büyük bir şüpheyle bakmamdır. O anda içimden bir ses uyanıyor: “Ne dağınıklık!”

Michael: Gerçekten de bir sonraki sihirli çözümü ne kadar sıklıkla duyduk?

Tim: Aynen öyle, bu da olağan bir durum! Mesela... bu zaten dünya çapında bir şaka haline gelmiş gibi görünüyor, ancak burada insanlar sıklıkla blockchain teknolojisinden bahsediyor. Ve aslında bazı durumlarda mantıklıdırlar! Gerçekten olayların güvenilir kanıtına ihtiyacınız olduğunda, sistemin çalıştığına ve kimsenin bizi kandırmadığına, güvenlik sorunlarınız olduğunda ve tüm bunlar birbirine karıştığında, blockchain mantıklı olur. Peki Blockchain'in artık dünyayı kasıp kavuracağını, yoluna çıkan her şeyi silip süpüreceğini söylediklerinde? Daha fazla hayal et! Bu çok pahalı ve karmaşık bir teknolojidir. Teknik olarak karmaşık ve zaman alıcıdır. Tamamen algoritmik olarak da dahil olmak üzere, her seferinde matematiği en ufak değişikliklerle yeniden hesaplamanız gerekir... ve bu harika bir fikir - ancak yalnızca belirli durumlar için. Tüm hayatım ve kariyerim bununla ilgiliydi: çok özel durumlarda ilginç fikirler. Durumunuzun tam olarak ne olduğunu anlamak çok önemlidir.

Michael: Evet, “hayatın, evrenin ve her şeyin” asıl sorusu: Bu teknoloji veya yaklaşım sizin durumunuza uygun mu, değil mi?

Tim: Bu soru zaten teknoloji grubuyla tartışılabilir. Hatta belki bir danışman bile getirebiliriz. Projeye bir göz atın ve anlayın; şimdi eskisinden daha iyi, doğru ve faydalı bir şey yapacak mıyız? Belki sığar, belki uymaz. Ancak en önemlisi, sırf birisi ağzından kaçırdı diye böyle bir kararı varsayılan olarak vermeyin: “Bir blockchain'e şiddetle ihtiyacımız var! Az önce uçakta bir dergide onun hakkında bir şeyler okudum! Cidden? Hiç komik bile değil.

Efsanevi “mühendis yetiştirir”

Oleg: Artık herkes devop uyguluyor. Birisi internette devops hakkında okuyor ve yarın işe alım sitesinde başka bir boş pozisyon beliriyor. "mühendis yetiştirir". Burada dikkatinizi çekmek istiyorum: Sizce bu “mühendis yetiştiren” kavramının yaşam hakkı var mı? Devops'un bir kültür olduğu ve burada bir şeylerin anlamı olmadığı yönünde bir görüş var.

Tim: Şöyle böyle. O zaman hemen bu terimle ilgili bir açıklama yapsınlar. Onu eşsiz kılacak bir şey. Bunun gibi bir açık pozisyonun arkasında benzersiz bir beceri kombinasyonunun olduğunu kanıtlayana kadar, onu satın almayacağım! Yani, bir iş unvanımız var, "mühendis yetiştiriyor", ilginç bir unvan, evet, sırada ne var? İş unvanları genellikle çok ilginç bir şeydir. Diyelim ki "geliştirici" - yine de nedir bu? Farklı organizasyonlar tamamen farklı şeyler ifade eder. Bazı şirketlerde yüksek kaliteli programcılar, diğer şirketlerdeki özel profesyonel test uzmanları tarafından yazılan testlerden daha anlamlı testler yazar. Ne yani, onlar artık programcı mı yoksa testçi mi?

Evet, iş unvanlarımız var ama eğer yeterince uzun soru sorarsanız, sonunda hepimizin problem çözücü olduğumuz ortaya çıkıyor. Biz çözüm arayan insanlarız ve bazılarının bazı teknik becerileri var, bazılarının ise farklı becerileri var. DevOps'un nüfuz ettiği bir ortamda yaşıyorsanız, geliştirme ve yönetimin entegrasyonuyla meşgul olursunuz ve bu aktivitenin oldukça önemli bir amacı vardır. Ancak tam olarak ne yaptığınız ve neyden sorumlu olduğunuz sorulduğunda, insanların tüm bunları çok eski zamanlardan beri yaptığı ortaya çıkıyor. "Mimariden ben sorumluyum", "Veritabanlarından ben sorumluyum" vb., her neyse, görüyorsunuz - bunların hepsi "devops"tan önceydi.

Birisi bana iş unvanını söylediğinde pek dinlemiyorum. Aslında neyden sorumlu olduğunu size söylemesi daha iyi olur, bu konuyu daha iyi anlamamızı sağlayacaktır. En sevdiğim örnek, bir kişinin “proje yöneticisi” olduğunu iddia etmesidir. Ne? Bunun hiçbir anlamı yok, hâlâ ne yaptığını bilmiyorum. Bir proje yöneticisi bir geliştirici, dört kişilik bir ekibin lideri, kod yazan, iş yapan, takım lideri haline gelmiş, insanların kendi aralarında lider olarak tanıdığı biri olabilir. Ayrıca bir proje yöneticisi, bir projede altı yüz kişiyi yöneten, diğer yöneticileri yöneten, programların hazırlanmasından ve bütçelerin planlanmasından sorumlu olan bir yönetici olabilir, hepsi bu. Bunlar tamamen farklı iki dünya! Ancak iş unvanları aynı gibi görünüyor.

Bunu biraz farklı çevirelim. Hangi konuda gerçekten iyisin, çok fazla tecrüben var mı, yeteneğin var mı? Görevi halledebileceğinizi düşündüğünüz için neyin sorumluluğunu alacaksınız? Ve burada birisi hemen inkar etmeye başlayacak: hayır, hayır, hayır, proje kaynaklarıyla hiç uğraşma isteğim yok, bu benim işim değil, teknik bir adamım ve kullanılabilirliği ve kullanıcı arayüzlerini anlıyorum, anlamıyorum Ordular dolusu insan yönetmek istiyorsam, işe gitsem iyi olur.

Bu arada, bu tür beceri ayrımının işe yaradığı yaklaşımın büyük bir savunucusuyum. Teknisyenlerin kariyerlerini istedikleri kadar geliştirebilecekleri yer. Ancak yine de teknisyenlerin şikayet ettiği organizasyonlar görüyorum: Proje yönetimine girmem gerekecek çünkü bu şirketteki tek yol bu. Bazen bu korkunç sonuçlara yol açar. En iyi teknoloji uzmanları hiç de iyi yöneticiler değildir ve en iyi yöneticiler teknolojiyle baş edemez. Bu konuda dürüst olalım.

Şimdi buna çok fazla talep olduğunu görüyorum. Eğer bir teknisyenseniz, şirketiniz size yardımcı olabilir, ancak ne olursa olsun, gerçekten kendi kariyer yolunuzu bulmanız gerekiyor çünkü teknoloji sürekli değişiyor ve onunla birlikte kendinizi de yeniden keşfetmeniz gerekiyor! Sadece yirmi yılda teknolojiler en az beş kez değişebilir. Teknoloji tuhaf bir şey...

"Her Konuda Uzman"

Michael: İnsanlar bu kadar hızlı teknoloji değişimiyle nasıl başa çıkabilir? Karmaşıklıkları artıyor, sayıları artıyor, insanlar arasındaki toplam iletişim miktarı da artıyor ve "her konuda uzman" olamayacağınız ortaya çıkıyor.

Tim: Sağ! Teknolojide çalışıyorsanız, evet, kesinlikle belirli bir şey seçip onu derinlemesine incelemeniz gerekir. Kuruluşunuzun yararlı bulduğu (ve belki de gerçekten yararlı olacağı) bazı teknolojiler. Ve eğer artık bununla ilgilenmiyorsanız - bunu söyleyeceğime asla inanmazdım - belki de teknolojinin daha ilginç veya çalışmaya daha uygun olduğu başka bir kuruluşa geçmelisiniz.

Ama genel olarak evet haklısın. Teknolojiler her yöne aynı anda büyüyor, kimse “Ben var olan teknolojilerin uzmanıyım” diyemez. Öte yandan teknolojik bilgiyi tam anlamıyla özümseyen ve buna deli olan sünger insanlar da var. Böyle birkaç insan gördüm, kelimenin tam anlamıyla nefes alıyorlar ve yaşıyorlar, onlarla konuşmak faydalı ve ilginç. Sadece organizasyon içinde olup bitenleri incelemekle kalmıyorlar, genel olarak bunun hakkında konuşuyorlar, aynı zamanda gerçekten harika teknoloji uzmanları, çok bilinçli ve amaçlılar. Asıl işleri ne olursa olsun, dalganın zirvesinde kalmaya çalışıyorlar çünkü onların tutkusu Teknoloji hareketi, teknolojinin teşviki. Aniden böyle biriyle tanışırsanız, onunla öğle yemeğine çıkmalı ve öğle yemeğinde çeşitli güzel şeyleri tartışmalısınız. Herhangi bir organizasyonun bu türden en az birkaç kişiye ihtiyacı olduğunu düşünüyorum.

Riskler ve belirsizlik

Michael: Onurlu mühendisler, evet. Vakit varken risk yönetimine değinelim. Bu röportaja, hataların korkunç sonuçlara yol açabileceği tıbbi yazılımlarla ilgili bir tartışmayla başladık. Daha sonra bir hatanın maliyetinin milyonlarca dolar ve muhtemelen birkaç insanın hayatına mal olduğu Ay Programından bahsettik. Ama şimdi sektörde tam tersi bir hareket görüyorum, insanlar riskleri düşünmüyor, tahmin etmeye çalışmıyor, gözlemlemiyor bile.

Oleg: Hızlı hareket edin ve eşyaları kırın!

Michael: Evet, hızlı hareket edin, bir şeyleri kırın, giderek daha fazla şeyi, ta ki bir şeyden ölene kadar. Sizin bakış açınıza göre, ortalama bir geliştirici risk yönetimini öğrenmeye şimdi nasıl yaklaşmalı?

Tim: Burada iki şeyin arasına bir çizgi çekelim: riskler ve belirsizlik. Bunlar farklı şeyler. Belirsizlik, herhangi bir zamanda kesin bir cevaba ulaşmak için yeterli veriye sahip olmadığınızda ortaya çıkar. Örneğin, bir projenin çok erken bir aşamasında, birisi size “işi ne zaman bitireceksiniz” diye sorarsa, oldukça dürüst bir insansanız, “Hiçbir fikrim yok” diyeceksiniz. Sadece bilmiyorsun ve bu sorun değil. Henüz sorunları incelemediniz ve takıma aşina değilsiniz, onların becerilerini bilmiyorsunuz vb. Bu belirsizliktir.

Riskler, potansiyel sorunların halihazırda tespit edilebildiği durumlarda ortaya çıkar. Böyle bir şey olabilir, olasılığı sıfırdan büyük ama yüzde yüzden az, arada bir yerde. Bu nedenle, gecikmeler ve gereksiz işlerden proje için ölümcül sonuçlara kadar her şey olabilir. Sonuç; arkadaşlar, şemsiyelerimizi toplayalım ve sahilden çıkalım, hiçbir zaman bitiremeyeceğiz, her şey bitti, nokta diyorsunuz. Bu şeyin işe yarayacağını varsaymıştık ama hiç işe yaramıyor, artık durmanın zamanı geldi. Bunlar durumlar.

Çoğu zaman, problemler zaten ortaya çıktığında, problem şu anda meydana geldiğinde çözülmesi en kolay olanıdır. Ancak bir sorun tam önünüzde olduğunda risk yönetimi yapmıyorsunuz; sorun çözme, kriz yönetimi yapıyorsunuz. Eğer bir lider geliştirici veya yöneticiyseniz, gecikmelere, zaman israfına, gereksiz maliyetlere veya tüm projenin çökmesine neden olabilecek ne olabileceğini merak ediyor olmalısınız. Bizi durdurup yeniden başlamamızı sağlayacak şey nedir? Bütün bunlar işe yaradığında onlarla ne yapacağız? Çoğu durum için geçerli olan basit bir cevap vardır: Risklerden kaçmayın, onlar üzerinde çalışın. Riskli bir durumu nasıl çözebileceğinizi, onu sıfıra indirebileceğinizi, sorundan başka bir şeye nasıl dönüştürebileceğinizi görün. Şunu söylemek yerine: Sorunları ortaya çıktıkça çözeceğiz.

Belirsizlik ve risk, uğraştığınız her şeyin ön saflarında yer almalıdır. Bir proje planı alabilir, belirli kritik riskleri önceden inceleyebilir ve şunu söyleyebilirsiniz: Bununla şimdi ilgilenmemiz gerekiyor, çünkü bunlardan herhangi biri ters giderse, başka hiçbir şeyin önemi kalmayacak. Akşam yemeği pişirip pişiremeyeceğiniz belli değilse, masanın üzerindeki masa örtüsünün güzelliğinden endişelenmemelisiniz. Öncelikle lezzetli bir akşam yemeği hazırlamanın tüm risklerini tanımlamanız, onlarla ilgilenmeniz ve ancak o zaman gerçek bir tehdit oluşturmayan diğer tüm şeyleri düşünmeniz gerekir.

Tekrar soralım, projenizi benzersiz kılan şey nedir? Bakalım projemizi neyin raydan çıkarabileceğine bakalım. Bunun gerçekleşme olasılığını en aza indirmek için ne yapabiliriz? Genellikle onları %100 etkisiz hale getirip vicdan rahatlığıyla şunu ilan edemezsiniz: "İşte bu, bu artık bir sorun değil, risk çözüldü!" Bana göre bu yetişkin davranışının bir işaretidir. Bir çocuk ile bir yetişkin arasındaki fark budur; çocuklar ölümsüz olduklarını, hiçbir şeyin ters gidemeyeceğine, her şeyin yoluna gireceğine inanırlar! Aynı zamanda yetişkinler, üç yaşındaki çocukların oyun alanında nasıl atladığını izliyor, hareketleri gözleriyle takip ediyor ve kendi kendine "ooh-ooh, ooh-ooh" diyor. Yakınlarda duruyorum ve çocuk düştüğünde onu yakalamaya hazırlanıyorum.

Öte yandan bu işi bu kadar sevmemin nedeni riskli olmasıdır. Bir şeyler yapıyoruz ve bunlar riskli. Yetişkin bir yaklaşım gerektirirler. Coşku tek başına sorunlarınızı çözmez!

Yetişkin mühendislik düşüncesi

Michael: Çocuklarla örnek iyidir. Sıradan bir mühendissem çocuk olmaktan mutluyum. Peki daha yetişkin düşüncesine nasıl geçilir?

Tim: Hem yeni başlayan hem de yerleşik bir geliştirici için eşit derecede işe yarayan fikirlerden biri bağlam kavramıdır. Ne yapıyoruz, neyi başaracağız. Bu projede gerçekten önemli olan nedir? Bu projede kim olduğunuz önemli değil, ister stajyer ister baş mimar olun, herkesin bağlama ihtiyacı vardır. Herkesin kendi işlerinden daha geniş ölçekte düşünmesini sağlamalıyız. "Ben kendi parçamı yapıyorum ve parçam çalıştığı sürece mutluyum." Hayır ve yine hayır. İnsanlara, içinde çalıştıkları bağlamı hatırlatmak her zaman faydalıdır (kaba olmadan!). Hep birlikte başarmaya çalıştığımız şey. Projenizde her şey yolunda olduğu sürece çocuk olabileceğinize dair fikirler - lütfen bunu yapmayın. Bitiş çizgisini geçersek, onu yalnızca birlikte geçeceğiz. Yalnız değilsin, hepimiz birlikteyiz. Projedeki tüm insanlar, yaşlı ve genç, proje için tam olarak neyin önemli olduğu, şirketin hepimizin başarmaya çalıştığı şeye neden yatırım yaptığı hakkında konuşmaya başlarsa... çoğu çok daha iyi hissedecektir çünkü kendi çalışmalarının diğer herkesin çalışmaları ile nasıl bağlantılı olduğunu görecekler. Bir yandan kişisel olarak sorumlu olduğum parçayı anlıyorum. Ancak işi bitirmek için diğer insanlara da ihtiyacımız var. Ve eğer gerçekten işin bittiğini düşünüyorsanız, projede her zaman yapacak işlerimiz vardır!

Oleg: Nispeten konuşursak, Kanban'a göre çalışıyorsanız, bazı testlerde darboğazla karşılaştığınızda, orada yaptığınız işi (örneğin programlamayı) bırakıp test uzmanlarına yardım edebilirsiniz.

Tim: Kesinlikle. Bence en iyi teknisyenler, eğer onlara yakından bakarsanız, bir nevi kendi kendilerinin yöneticileridirler. Bunu nasıl formüle edebilirim...

Oleg: Hayatınız sizin yönettiğiniz projenizdir.

Tim: Kesinlikle! Yani sorumluluk alıyorsunuz, konuyu anlıyorsunuz ve kararlarınızın onların işlerini etkileyebileceğini gördüğünüzde insanlarla temasa geçiyorsunuz, bunun gibi şeyler. Bu sadece masanızda oturup işinizi yapmakla ve hatta etrafınızda olup bitenlerin farkına bile varmamakla ilgili değil. Hayır hayır hayır. Bu arada Agile'ın en iyi yanlarından biri kısa sprintler önermiş olmaları, çünkü bu şekilde tüm katılımcıların durumu açıkça gözlemlenebilir, hepsini bir arada görebilirler. Her gün birbirimiz hakkında konuşuyoruz.

Risk yönetimine nasıl girilir?

Oleg: Bu alanda herhangi bir resmi bilgi yapısı var mı? Örneğin ben bir Java geliştiricisiyim ve eğitim yoluyla gerçek bir proje yöneticisi olmadan risk yönetimini anlamak istiyorum. Muhtemelen önce McConnell'in "Bir Yazılım Projesinin Maliyeti Ne Kadardır" kitabını okuyacağım, sonra ne olacak? İlk adımlar nelerdir?

Tim: İlki projedeki insanlarla iletişim kurmaya başlamaktır. Bu, meslektaşlarıyla iletişim kültürünün anında gelişmesini sağlar. Her şeyi gizlemek yerine varsayılan olarak açarak başlamalıyız. De ki: Bunlar beni rahatsız eden şeyler, bunlar beni geceleri ayakta tutan şeyler, bugün gece uyandım ve şöyle dedim: Tanrım, bunu düşünmem lazım! Başkaları da aynı şeyi görüyor mu? Grup olarak bu potansiyel sorunlara yanıt vermeli miyiz? Bu konulardaki bir tartışmayı destekleyebilmeniz gerekir. Çalıştığımız önceden hazırlanmış bir formül yok. Mesele hamburger yapmak değil, mesele tamamen insanlarla alakalı. “Cheeseburger yaptım, cheeseburger satarım” hiç bizim işimiz değil, o yüzden bu işi çok seviyorum. Eskiden yöneticilerin yaptığı her şeyin artık takımın malı haline gelmesi hoşuma gidiyor.

Oleg: Kitaplarda ve röportajlarda insanların grafikteki sayılardan çok mutluluğa önem verdiklerini anlattınız. Öte yandan, ekibe devops'a geçiyoruz ve artık programcının sürekli iletişim kurması gerektiğini söylediğinizde, bu onun konfor bölgesinin çok dışında olabilir. Ve şu anda diyelim ki çok mutsuz olabilir. Bu durumda ne yapmalı?

Tim: Tam olarak ne yapacağımı bilmiyorum. Bir geliştirici çok yalnız kalırsa, işin neden yapıldığını anlamazlar, sadece işin kendilerine ait kısmına bakarlar ve benim "bağlam" dediğim şeye girmeleri gerekir. Her şeyin birbirine nasıl bağlı olduğunu bulması gerekiyor. Ve tabii ki resmi sunumları veya buna benzer şeyleri kastetmiyorum. Meslektaşlarınızla işin yalnızca sorumlu olduğunuz kısmı hakkında değil, bir bütün olarak iş hakkında iletişim kurmanız gerektiği gerçeğinden bahsediyorum. Burası fikirlerinizi, çalışmalarınızın birbirine iyi uyum sağlaması için ortak anlaşmaları ve ortak bir sorunu birlikte nasıl çözebileceğinizi tartışmaya başlayabileceğiniz yerdir.

Uyum sağlamalarına yardımcı olmak için genellikle teknisyenleri eğitime göndermek isterler ve eğitim hakkında tartışırlar. Bir arkadaşım eğitimin köpekler için olduğunu söylemekten hoşlanıyor. İnsanlara yönelik eğitimler var. Bir geliştirici olarak öğrenmenin en iyi yanlarından biri akranlarınızla etkileşimde bulunmaktır. Birisi bir konuda gerçekten iyiyse, onu çalışırken izlemeli veya onunla işi hakkında falan konuşmalısınız. Bazı geleneksel Kent Beck sürekli olarak aşırı programlamadan bahsediyordu. Komik çünkü XP çok basit bir fikir ama pek çok soruna neden oluyor. Bazıları için XP yapmak, arkadaşlarının önünde çıplak soyunmaya zorlanmak gibidir. Ne yaptığımı görecekler! Onlar benim meslektaşlarım, sadece görmekle kalmayacaklar, aynı zamanda anlayacaklar! Korkunç! Bazı insanlar ciddi anlamda tedirgin olmaya başlıyor. Ancak öğrenmenin nihai yolunun bu olduğunu anladığınızda her şey değişir. İnsanlarla yakın çalışıyorsunuz ve bazı insanlar konuyu sizden çok daha iyi anlıyor.

Michael: Ancak tüm bunlar sizi konfor alanınızın dışına çıkmaya zorluyor. Bir mühendis olarak konfor alanınızın dışına çıkıp iletişim kurmalısınız. Bir problem çözücü olarak kendinizi sürekli zayıf bir pozisyona sokmalı ve neyin yanlış gidebileceğini düşünmelisiniz. Bu tür işler doğası gereği sıkıntı yaratacak şekilde tasarlanmıştır. Kendinizi bilinçli olarak stresli durumlara sokarsınız. Genellikle insanlar onlardan kaçar, insanlar mutlu çocuklar olmayı sever.

Tim: Ne yapılabilir, çıkıp açıkça şunu söyleyebilirsiniz: “Her şey yolunda, halledebilirim! Rahatsız olan tek kişi ben değilim. Çeşitli rahatsız edici şeyleri hep birlikte ekip olarak tartışalım! Bunlar bizim ortak sorunlarımız, onlarla baş etmeliyiz, anlıyor musunuz? Bence kendine özgü dahi geliştiriciler mamutlar gibidir, ortadan kayboldular. Ve bunların önemi çok sınırlıdır. İletişim kuramazsanız iyi bir katılım sağlayamazsınız. Bu nedenle sadece konuşun. Dürüst ve açık olun. Bunun birisi için hoş olmayan bir durum olduğu için çok üzgünüm. Düşünebiliyor musunuz, yıllar önce Amerika Birleşik Devletleri'ndeki ana korkunun ölüm olmadığını, ama bilin bakalım ne oldu? Topluluk önünde konuşma korkusu! Bu, bir yerlerde yüksek sesle iltifat etmektense ölmeyi tercih eden insanların olduğu anlamına geliyor. Ve ne yaptığınıza bağlı olarak bazı temel becerilere sahip olmanızın yeterli olduğunu düşünüyorum. Konuşma becerileri, yazma becerileri - ancak yalnızca işinizde gerçekten ihtiyaç duyulan kadar. Analist olarak çalışıyorsanız ancak okuyamıyor, yazamıyor veya konuşamıyorsanız maalesef projelerimde yapacak hiçbir şeyiniz kalmayacak!

İletişimin fiyatı

Oleg: Bu şekilde dışa dönük çalışanları çalıştırmak çeşitli nedenlerden dolayı daha pahalı değil mi? Sonuçta çalışmak yerine sürekli sohbet ediyorlar!

Tim: Sadece herkesi değil, takımın çekirdeğini kastettim. Veritabanlarını ayarlama konusunda gerçekten harika olan, veritabanlarını ayarlamayı seven ve hayatının geri kalanında veritabanlarınızı ayarlamaya devam edecek biri varsa ve işte bu kadar, harika, böyle devam edin. Ama ben projenin kendisinde yaşamak isteyen insanlardan bahsediyorum. Ekibin çekirdeği, projeyi geliştirmeyi hedefliyordu. Bu insanların gerçekten birbirleriyle sürekli iletişim kurması gerekiyor. Ve özellikle projenin başlangıcında, riskleri, küresel hedeflere ulaşmanın yollarını ve benzerlerini tartışırken.

Michael: Bu, uzmanlığa, becerilere veya çalışma biçimlerine bakılmaksızın projeye dahil olan herkes için geçerlidir. Hepiniz projenin başarısıyla ilgileniyorsunuz.

Tim: Evet, projeye yeterince daldığınızı, görevinizin projenin gerçekleşmesine yardımcı olmak olduğunu hissediyorsunuz. İster programcı, ister analist, ister arayüz tasarımcısı olun, herhangi biri. Her sabah işe gelmemin sebebi bu ve yaptığımız da bu. Yetenekleri ne olursa olsun tüm bu insanlardan biz sorumluyuz. Bu, yetişkinlere yönelik sohbetler yapan bir grup insandır.

Oleg: Hatta konuşkan çalışanlardan bahsederken devops'a geçmesi istenen insanların, özellikle de yöneticilerin bu yepyeni dünya vizyonuna itirazlarını simüle etmeye çalıştım. Ve siz danışmanlar olarak bu itirazların, bir geliştirici olarak benden çok daha iyi farkında olmalısınız! Yöneticileri en çok endişelendiren şeyin ne olduğunu paylaşın?

Tim: Yöneticiler mi? Hm. Çoğu zaman, yöneticiler sorunlardan dolayı baskı altındadır, acilen bir şeyi serbest bırakma ve teslimatı yapma vb. ihtiyacıyla karşı karşıya kalırlar. Sürekli bir konu hakkında nasıl tartıştığımızı, tartıştığımızı izliyorlar ve şöyle görüyorlar: konuşmalar, konuşmalar, konuşmalar... Başka hangi konuşmalar? İşe geri almak! Çünkü konuşmak onlara iş gibi gelmiyor. Kod yazmıyorsunuz, yazılımı test etmiyorsunuz, hiçbir şey yapmıyorsunuz; neden sizi bir şeyler yapmaya göndermiyorsunuz? Sonuçta teslimat zaten bir ay içinde!

Michael: Git biraz kod yaz!

Tim: Bana öyle geliyor ki iş konusunda değil, ilerlemenin görünür olmamasından endişe ediyorlar. Başarıya yaklaşıyormuşuz gibi görünmek için klavyedeki tuşlara bastığımızı görmeleri gerekiyor. Sabahtan akşama kadar tüm gün. Bu bir numaralı sorundur.

Oleg: Misha, bir şey düşünüyorsun.

Michael: Kusura bakmayın, dalıp gittim ve bir geçmişe dönüş yakaladım. Bütün bunlar bana dün gerçekleşen ilginç bir mitingi hatırlattı... Dün çok fazla miting vardı... Ve hepsi çok tanıdık geliyor!

Maaşsız hayat

Tim: Bu arada iletişim için “mitingler” düzenlemeye hiç gerek yok. Demek istediğim, geliştiriciler arasındaki en faydalı tartışmalar sadece birbirleriyle konuştuklarında gerçekleşir. Sabah bir fincan kahveyle içeri giriyorsunuz ve beş kişi toplanmış, öfkeyle teknik bir konuyu tartışıyordu. Benim için bu projenin yöneticisi bensem, sadece gülümseyip bir yere gidip işimle ilgili konuşsunlar daha iyi. Zaten mümkün olduğunca işin içindeler. Bu iyiye işaret.

Oleg: Bu arada kitabınızda neyin iyi neyin kötü olduğuna dair bir sürü not var. Bunlardan herhangi birini kendiniz kullanıyor musunuz? Nispeten konuşursak, artık bir şirketiniz var ve alışılmışın dışında bir şekilde yapılandırılmış bir şirket...

Tim: Alışılmışın dışında ama bu cihaz bize çok yakışıyor. Birbirimizi uzun zamandır tanıyoruz. Biz birbirimize güveniriz, ortak olmadan önce birbirimize çok güvenirdik. Mesela hiç maaşımız yok. Sadece çalışıyoruz ve örneğin müşterilerimden para kazanıyorsam tüm para bana giderdi. Bundan sonra kuruluşa üyelik ücreti ödüyoruz ve bu şirketin kendisini desteklemek için yeterli. Ayrıca hepimiz farklı konularda uzmanız. Mesela muhasebecilerle çalışıyorum, vergi beyannamelerini dolduruyorum, şirketin her türlü idari işini yapıyorum ve kimse bana bunun için para ödemiyor. James ve Tom web sitemizde çalışıyorlar ve onlara da kimse ödeme yapmıyor. Aidatınızı ödediğiniz sürece kimse size ne yapmanız gerektiğini söylemenin aklına gelmeyecek. Örneğin Tom artık eskisinden çok daha az çalışıyor. Artık başka ilgi alanları var; Lonca için olmayan bazı şeyler yapıyor. Ama aidatını ödediği sürece kimse yanına gelip "Hey Tom, işe git!" demeyecek. Aranızda para olmadığında meslektaşlarınızla anlaşmak çok kolaydır. Ve şimdi ilişkimiz farklı uzmanlıklarla ilgili temel fikirlerden biri. Çalışıyor ve çok iyi çalışıyor.

En iyi tavsiye

Michael: “En iyi tavsiyeye” dönecek olursak, müşterilerinize defalarca söylediğiniz bir şey var mı? 80/20 ile ilgili bir fikir var ve bazı tavsiyeler muhtemelen daha sık tekrarlanıyor.

Tim: Bir zamanlar Ayılarla Vals gibi bir kitap yazarsanız tarihin akışını değiştireceğini ve insanların duracağını düşünmüştüm, ama... Bakın, şirketler çoğu zaman kendileriyle ilgili her şey yolundaymış gibi davranıyorlar. Kötü bir şey olduğu anda bu onlar için bir şok ve sürprizdir. “Bakın sistemi test ettik, hiçbir sistem testinden geçmiyor, üstelik bu da üç aylık plansız bir çalışma, bu nasıl olabilir? Kim biliyordu? Ne yanlış gidebilir? Cidden buna inanıyor musun?

Mevcut duruma çok fazla kızmamak gerektiğini anlatmaya çalışıyorum. Bu konuyu konuşmamız, neyin yanlış gidebileceğini gerçekten anlamamız ve gelecekte bu tür olayların yaşanmasını nasıl önleyeceğimizi anlamamız gerekiyor. Bir sorun ortaya çıkarsa onunla nasıl mücadele edeceğiz, onu nasıl kontrol altına alacağız?

Bana göre bunların hepsi korkutucu görünüyor. İnsanlar karmaşık, sinir bozucu sorunlarla uğraşırlar ve en iyisini umarak en iyisini umduklarında "en iyinin" gerçekten gerçekleşeceğini sanmaya devam ederler. Hayır, bu şekilde çalışmıyor.

Risk yönetimini uygulayın!

Michael: Sizce kaç kuruluş risk yönetimiyle ilgileniyor?

Tim: Beni çileden çıkaran şey, insanların riskleri yazıp, ortaya çıkan listeye bakıp işe gitmeleri. Aslında onlar için riskleri belirlemek risk yönetimidir. Ama bana göre bu, şunu sormak için bir neden gibi geliyor: tamam, bir liste var, tam olarak neyi değiştireceksin? Bu riskleri dikkate alarak standart eylem dizilerinizi değiştirmeniz gerekir. İşin en zor kısmı varsa, onu halletmeniz ve ancak o zaman daha basit bir şeye geçmeniz gerekir. İlk sprintlerde karmaşık sorunları çözmeye başlayın. Bu zaten risk yönetimine benziyor. Ancak genellikle insanlar bir risk listesi derledikten sonra neyi değiştirdiklerini söyleyemezler.

Michael: Peki bu şirketlerin kaçı risk yönetimiyle ilgileniyor, yüzde beş?

Tim: Ne yazık ki bunu söylemekten nefret ediyorum ama bu çok önemsiz bir kısım. Ama beşten fazla, çünkü gerçekten büyük projeler var ve en azından bir şey yapmazlarsa var olamazlar. En az %25 olursa çok şaşıracağımı söyleyelim. Küçük projeler genellikle bu tür sorulara şu şekilde yanıt verir: Sorun bizi etkiliyorsa çözeriz. Daha sonra başarılı bir şekilde başlarını belaya sokarlar ve sorun yönetimi ve kriz yönetimi ile meşgul olurlar. Bir sorunu çözmeye çalıştığınızda sorun çözülmediğinde kriz yönetimine hoş geldiniz.

Evet, sık sık şunu duyuyorum: “Sorunları ortaya çıktıkça çözeceğiz.” Elbette yapacağız? Gerçekten karar verecek miyiz?

Oleg: Bunu safça yapabilir ve önemli değişmezleri proje başlatma belgesine kolayca yazabilirsiniz ve eğer değişmezler bozulursa projeyi yeniden başlatın. Çok dağınık çıkıyor.

Michael: Evet, bana öyle geldi ki riskler tetiklendiğinde proje basitçe yeniden tanımlandı. Güzel, bingo, sorun çözüldü, artık endişelenme!

Tim: Hadi sıfırlama düğmesine basalım! Hayır, bu şekilde çalışmıyor.

DevOops 2019 Açılış Konuşması

Michael: Bu röportajın son sorusuna geliyoruz. Bir sonraki DevOops'a bir açılış konuşmasıyla geliyorsunuz, anlatacaklarınızın sır perdesini aralayabilir misiniz?

Tim: Şu anda altısı çalışma kültürü ve kuruluşların söylenmemiş kuralları hakkında bir kitap yazıyor. Kültür, kuruluşun temel değerleri tarafından belirlenir. Genellikle insanlar bunu fark etmez, ancak uzun yıllar danışmanlık sektöründe çalıştığımız için bunu fark etmeye alışkınız. Bir şirkete giriyorsunuz ve kelimenin tam anlamıyla birkaç dakika içinde neler olduğunu hissetmeye başlıyorsunuz. Biz buna "lezzet" diyoruz. Bazen bu koku gerçekten çok güzel, bazen de öyle. Farklı organizasyonlar için işler çok farklıdır.

Michael: Ben de yıllardır danışmanlık yapıyorum ve neyden bahsettiğinizi çok iyi anlıyorum.

Tim: Aslında açılış konuşmasında değinmeye değer şeylerden biri de her şeyin şirket tarafından belirlenmediğidir. Siz ve ekibiniz, bir topluluk olarak kendi ekip kültürüne sahipsiniz. Bu, şirketin tamamı olabileceği gibi ayrı bir departman, ayrı bir ekip de olabilir. Ama siz söylemeden önce, biz neye inanıyoruz, önemli olan şu... Belirli eylemlerin ardındaki değerler ve inançlar anlaşılmadan bir kültürü değiştiremezsiniz. Davranışı gözlemlemek kolaydır ancak inançları araştırmak zordur. DevOps, işlerin giderek daha karmaşık hale geldiğinin harika bir örneğidir. Etkileşimler giderek daha karmaşık hale geliyor, hiç de netleşmiyor veya netleşmiyor, bu nedenle neye inandığınızı ve etrafınızdaki herkesin neye sessiz kaldığını düşünmelisiniz.

Hızlı sonuç almak istiyorsanız işte size güzel bir konu: Kimsenin “Bilmiyorum” demediği şirketleri gördünüz mü? Bir kişiye bir şey bilmediğini itiraf edene kadar kelimenin tam anlamıyla işkence yaptığınız yerler var. Herkes her şeyi bilir, herkes inanılmaz bilgilidir. Herhangi bir kişiye yaklaşıyorsunuz ve o, soruyu anında cevaplamak zorunda kalıyor. "Bilmiyorum" demek yerine Yaşasın, bir grup bilgini işe aldılar! Bazı kültürlerde ise “Bilmiyorum” demek genellikle çok tehlikelidir; bir zayıflık işareti olarak algılanabilir. Tam tersi herkesin “Bilmiyorum” diyebildiği organizasyonlar da var. Orada bu tamamen yasaldır ve eğer birisi bir soruya yanıt olarak saçmalamaya başlarsa, şu cevabı vermek tamamen normaldir: "Neden bahsettiğini bilmiyorsun, değil mi?" ve her şeyi şakaya dönüştürün.

İdeal olarak sürekli mutlu olabileceğiniz bir işte çalışmak istersiniz. Kolay olmayacak, her gün güneşli ve keyifli olmayacak, bazen çok çalışmanız gerekiyor, ancak durumu değerlendirmeye başladığınızda şunu göreceksiniz: vay be, burası gerçekten harika bir yer, burada çalışırken kendimi iyi hissediyorum, hem duygusal hem de entelektüel olarak. Bir de danışman olarak gittiğinizde üç ay dayanamayacağınızı, dehşet içinde kaçacağınızı anında anladığınız firmalar var. Raporda bundan bahsetmek istiyorum.

Tim Lister bir açılış konuşmasıyla gelecek "Karakterler, topluluk ve kültür: Refah için önemli faktörler"2019-29 Ekim 30 tarihlerinde St. Petersburg'da gerçekleşecek olan DevOops 2019 konferansına. Bilet satın alabilirsiniz resmi web sitesinde. DevOops'ta sizi bekliyoruz!

Kaynak: habr.com