Etkili Yazılım Üretimi İçin Sekiz Kural

Kariyerim boyunca, birden fazla gerçek hayat yazılım projesine katıldım ve her düzeyde işlerin nasıl yapıldığını gözlemledim: karar verme, uygulamaları benimseme, ekip oluşturma, işe alma, beceri dağıtımı vb. Açıkçası, farklı yaklaşımlar farklı sonuçlar verdi. . Gelişim odaklı bir insan türü olarak, işimde bana yardımcı olacak en etkili uygulamaları ve en iyi pratik püf noktalarını fark ettim ve topladım.

Gözlemden öğrenmek, bunu yapmanın zor ve uzun bir yoludur. Bunun yerine bu bilgiyi daha önce kitaplardan almaktan son derece mutlu olurum. Ne yazık ki, konuyla ilgili hiçbir şey bulamadım. Ben de bu tür bilgiyi arayan diğer kişilerle deneyimlerimi paylaşmaya karar verdim. Umarım, bu onları birkaç yıllık kişisel araştırmadan kurtarır.

Bu makalede, 5-10 kat daha az bakım gerektiren sağlam ve güvenilir yazılım ürünleri üreterek ortalama endüstri performansını nasıl yenebileceğinizi öğreneceksiniz. Yalan söylemeden söyleyebilirim ki son 10-15 yılda ben (kişisel olarak da ekiplerim de) tüm beklentileri aştım ve arkamda bir çok başarı bıraktım. Yöneticiler daha mutlu olamaz.

Bir keresinde ekibim inanılmaz kısa bir zaman diliminde önemli bir projeyi hayata geçirdi ve bu proje için üst yönetim tarafından “Yüksek Performanslı Ekip” ödülüne layık görüldük. Bütün bunlar kendimizi yormadan gece ve hafta sonu geçirmeden. Sadece normal iş.

Görüyorsunuz, etkin yazılım üretim bilgisinin kendisi bir güçtür. Aslında sade kelimelerle anlatılsa bile pek çok kişinin kavrayamayacağı bir tür kara büyü. Ücretsiz olarak alacaksınız. Yazılım üretim sihirbazı olarak algılanmak istiyorsanız okumaya devam edin.

Bu kim için?

Burada önemli, önemli, önemli bir uyarıda bulunmama izin verin.

Bunu, verimlilik artışına ihtiyaç duyanlara hitap ediyorum. Hayattaki her şey verimlilikle ilgili değildir. Tüm yazılım projeleri de değildir. Performansınıza göre yargılanmadığınız durumlar vardır. Açıkçası, bu uygulamalar o zaman yardımcı olmaz.

Bu teknikler en çok ekip liderleri, mimarlar ve proje yöneticileri için faydalı olacaktır, ancak kıdemli yazılım geliştiriciler de bunlardan yararlanabilir.

Kural No. 1: BT Zihniyetini Anlayın

BT endüstrisi bilim, teknoloji, sanat ve iş dünyasının bir karışımıdır. Bu yönleri yeterince iyi bir düzeyde anlamadan orada gezinmek oldukça zordur. En büyük sorun, endüstrinin kendisinin oldukça karmaşık olmasıdır; bu nedenle, en iyi uygulamalar da karmaşıktır. Başarılı olmak için çok şey öğrenmeniz ve çok pratik yaparak bilginizi doğrulamanız gerekir.

İnanılmaz teknoloji güncelleme hızı, onu iki kat daha zor hale getiriyor. On yıl önce öğrendiğin hiçbir şeye artık ihtiyaç yok. Bu nedenle, hızlandırılmış bir hızda öğrenmeniz gerekir.

Yukarıdakilerin hepsini özetlersek, BT alanında başarılı olmanın doğuştan gelen becerilere veya duygulara değil, zor pratik örneklere dayandığını söyleyebiliriz. Asla “içgüdüyü takip etmeyin” veya sizinki de dahil olmak üzere yalnızca duyguya dayalı olarak inanmayın.

Evet ise, fikir düşünmeye değer. Aksi takdirde, bu yolu seçmenin ekibinizin hayatını nasıl daha iyi hale getirdiğine dair çok iyi ve çok ayrıntılı bir açıklama isteyin. Bu testi geçerse, ortamınıza uyduğunu deneysel olarak kanıtlayan hafif bir kavram kanıtı projesi planlayın.

Burada anlaşılması gereken önemli şey, yazılım problemlerini çözmenin birçok yolu olduğu için doğru ve yanlış çözüm olmadığıdır. Ancak, çözümün iyi ve kötü anlayışları vardır.

Bir kişi fikrini ayrıntılı olarak açıkça ifade edebilir veya diğer ekip üyelerini ikna etmek için bu çözümü benimsemekten ekibin başarısına bir bağlantı kurabilirse, o zaman bu kişinin vizyonuna güvenebilir ve yüksek başarı şansını umabiliriz.

Kural No. 2: Yazılım Üretimi ve Yazılım Geliştirme Metodolojilerini Karıştırmayın

Yazılım üretimi, yazılım geliştirmeye dayanır. Ancak, bu ikisinin tamamen farklı hedefleri, zihniyetleri ve uygulamaları vardır. Bu alemlerden birindeki bir sorunu diğerinin yöntemleriyle çözmeye çalışmak gülünç sonuçlar doğurur. Ayrımı anlamak ve bu dünyaların her biri için uygun yöntemleri kullanmak önemlidir.

Yazılım geliştirme, sanat ve zanaatın bir birleşimidir. Sanat bileşeni, otomasyon araçları ve yazılım geliştirme metodolojilerinden bağımsız olarak her zaman orada olacaktır. Bu nedenle, geliştirme görevlerini çözmek, maksimum konsantrasyon ve diğer tüm dikkat dağıtıcı sinyallerden korunma gerektirir.

Deneyimli bir geliştiriciyi motive etmenin en iyi yolu, onlara tüm insan faktörleri hariç tutularak saf teknik biçiminde bir görev sunmaktır. Tüm gereksinimler ayrıca teknik dilde ifade edilmelidir. Tek başlarına araştırma evrelerinde hedefe doğru ilerlemelerini sağlamak için kolayca doğrulanabilir olmalıdırlar.

Buna karşılık, yazılım üretimi daha çok işletme yönetimi alanındadır. Bir taraftan müşterinizin neye ihtiyacı olduğunu bilirsiniz, diğer taraftan emrinizde hangi ekip kaynaklarına sahip olduğunuzu bilirsiniz. Yani şimdi takım çabalarınızı hedefe ulaşmak için yönlendirmeye çalışıyorsunuz. Bu arada, ilerleme hızınızı da tahmin edebilir ve patrona çok yönlü bir plan sunabilirsiniz. Buradaki önemli beceriler, müşterinizin isteklerini anlamak, ekibinizin güçlü yanlarını anlamak ve resmi plan ve programları iletmek.

Bununla birlikte, takım liderleri, mimarlar, analistler ve proje yöneticileri gibi yazılım geliştirmedeki birçok rolün bu iki dünyada da iş ve teknoloji arasında bir köprü kurmada çalıştığını vurgulamak isterim. Bu rollerdeki insanlar, iki gerçeklik düzlemi arasında kolayca yürüyebilmeli ve ne zaman iş, ne zaman sanat konuşma zamanının geldiğini anlayabilmelidir.

Kural No. 3: Kalıcı Depolamayı İnsan Belleğinin Uzantısı Olarak Kullanın

İnsan hafızasının kapasitesi şaşırtıcı olsa da sınırları vardır. Bir şeyleri tahmin edilemez bir doğruluk ve süre ile hatırlarsınız ve unuttuğunuzda, istediğiniz zaman hatırlamanın bir yolu yoktur.

Bu nedenle, öngörülebilir bir hızda ilerlemek için kalıcı bellek depolama kullanıyoruz. Bu, gerçeklerden çok sonra ve diğer insanların kullanması için oluşturduğunuz kullanım kılavuzları gibi resmi belgelerle ilgili değildir. Bu, yazılım geliştirme sürecinden geçmenize yardımcı olan çalışma sırasında belgeleri tam anlamıyla belleğinizin harici uzantısı olarak kullanmakla ilgilidir.

Önemsiz olmayan görevlerle veya birden fazla kişiyi içeren görevlerle karşılaştığınızda, yol boyunca düşüncelerinizi ve planlarınızı belgelemenizi öneririm. Mümkün olduğunca ucuz yapmaya çalışın. Üzerinde şirket logosu bulunan resmi belgeler oluşturmayın. İyi bir araç, içinde proje alanınız olan bir şirket wiki'si olacaktır. Görevler veya problemler için özel sayfalar oluşturun (30 saniye). Ardından, bir fikriniz olduğunda veya başkalarıyla tartışmak üzere olduğunuzda onu güncelleyin.

Bir toplantıda “dur şunu bir bırakayım” deyin ve bunu yazılı olarak ifade etmek için 10-30 saniye ayırın. Yazı kapsamlı olmamalı, tam ve tutarlı olmalıdır, tıpkı fikrin tamamını kağıda aktarıyormuşsunuz gibi. Daha sonra, siz veya pasajınızı okuyan herhangi biri, onu şu anda anladığınız kadar net anlamalıdır. Bu numara çok zaman kazandırır, ancak anında belgelemenizi sağlar.

Bu teknik iki amaca hizmet eder.

İlk olarak, onu taşa sertçe bastırarak başarıya giden yolda ilerlemenizi kilitler. Artık birinin bir şeyi unutması, aynı şeyi tekrar tekrar tekrar etmesi veya zaten müzakere edilmiş olan aynı şeyi yeniden müzakere etmesi riski yok.

İkinci olarak, kafanızı karıştıran sorunu bir kenara bırakarak zihninizi boşaltırsınız. Şimdi zihniniz bir sonraki meydan okuma için aç. Ne bir üretkenlik artışı!

Bu, her boyuttaki proje veya görev için geçerlidir. Daha büyük alanlar için, projeniz geliştikçe kademeli olarak büyüyen bir sayfa hiyerarşisine sahip daha büyük alanlara sahip olacaksınız. Buradaki önemli kavram, hızlı bir bellek dökümü protokolü oluşturma görevinize başlamadan önce bir dokümantasyon alanı ve yapısı hazırlamaktır!

Teknolojik analojileri tercih eden insanlar için, zihnimizi muazzam işlem gücüne sahip ancak sınırlı operasyonel belleğe sahip bir işlemciye benzetebilirim. Esasen her seferinde bir şey hakkında düşünebilirsiniz. Bu benzetmede, belgeleriniz kalıcı depolama işlevi görürken, zihniniz karmaşık sorunları yinelemeli bir yaklaşımla çözer. Bir noktada, bir sonraki yinelemeye başlamaya, önceki belgeleri okumaya ve mevcut durumu operasyonel belleğinize yüklemeye, bir süre bunun hakkında düşünmeye ve yeni bulgularınızla kodu ve belgeleri güncellemeye karar verirsiniz. Tamamlanana kadar adım adım.

Yukarıda söylenenlerin hepsi, insanları aynı anda çok sayıda görevi yerine getirmeye teşvik etmiyorum. Aksine, ne kadar az göreviniz varsa o kadar iyi. Yine de pek çok çalışma durumu gerçekten insan tarafından optimize edilmiş değildir ve çoklu görev gerekebilir ve bunu bir şekilde halletmeniz gerekebilir. Yukarıdaki numara, onu daha iyi halletmeye yardımcı olur.

Kural 4: Resmi Zaman Tahmininde Zaman Kaybetmeyi Durdurun

Hiçbir proje birbirine benzemez. Bir daha benzer bir proje yaptığınızda farklı müşterileriniz, farklı hedefleriniz, farklı bir ekibiniz olacak; belki de farklı teknolojiler. Standart araçları ve bileşenleri kullansanız bile, bunların yapılandırmasını ve mimarisini özelleştirmeniz gerekecektir. Yazılım projelerini ele alırken, bunların %50 ile %100 arasında özel çalışma içerdiğini unutmayın. Araştırma, tartışma, düşünme, deneme ve diğer son derece öngörülemeyen faaliyetler gerektirirler. Uygulamada, yüzeyde tam olarak aynı proje türü olarak görünenler ile daha önce yaptığınız şeyler arasında muazzam bir fark yaşayabilirsiniz. Yeni bir proje tipinin uzantısı olarak, tam olarak tahmin etmek neredeyse imkansızdır.

Bu kadar öngörülemezse, proje yöneticilerinin nasıl bir proje takvimi sunması ve ona bağlı kalması gerekiyor?

Literatürde açıklanan bunu yapmanın resmi bir yöntemi vardır; yani, tüm projeyi daha küçük adımlara bölmek, her adımın ne kadar sürdüğünü tahmin etmek ve ardından bireysel parçaların çalışma uzunluklarını birleştirerek toplam proje uzunluğunu hesaplamak. MBA derslerinde öğretilen bu yöntemin arkasında tonlarca teori var.

Ne yazık ki, hiçbir matematik onu kurtaramaz. Bu yöntem, tamamen kullanılamaz ve pratik olmadığı ölçüde, ne kadar inanılmaz zaman alıcı olduğundan bahsetmiyorum bile, kesinlikle yanlıştır. Metodolojik fanatikler arasında bile, hiçbir ayarlama yapmadan resmi hesaplama yöntemlerini kullanan bir proje yöneticisi görmedim. Şirket bu tür bir yöntem kullanımını kesinlikle dayattığında bile! Aslında, en iyi performans gösteren yöneticiler, aşağıda açıklandığı gibi tamamen farklı alternatif yöntemler kullanır:

İyi bir proje yöneticisi, proje tipini, ortamı, ilgili kaynakları, organizasyon tipini ve fiili proje uzunluğunu etkileyen diğer tüm çalışma unsurlarını dikkate alır. Elbette hiç kimse yalnızca kendi hatalarından ders almak zorunda değildir. Bu tür gözlemler hem doğrudan hem de dolaylı olarak yapılabilir; örneğin kitaplar aracılığıyla ya da başkaları tarafından yapılan projeleri inceleyerek ya da sadece bilgi kişisini kişiye aktararak. Bu tür istatistiksel üst düzey bilgi, kişisel proje programı navigasyonunu geliştirir.

Yukarıda açıklanan yöntemin iki önemli sonucunu vurgulamak istiyorum.

İlk olarak, tahmin doğruluğu deneyimle artar. Sahip oldukları güçlü metodoloji ile donanmış deneyimsiz bir kişinin bu konuda başarılı olmasının hiçbir yolu yoktur. İkincisi, en iyi tahmin bile yalnızca istatistiksel olarak hala iyidir. Yani, belirli bir projenin dört ila on iki ay arasında bir süre alabileceği söylenebilir. Bunun doğru olduğunu varsayarsak, projenin sekiz aylık ortalama süresi boyunca devam etme olasılığının %50 olduğu anlaşılmalıdır.

İstatistiksel öngörüyü anlamak inanılmaz bir etkiye sahiptir. Akıllı bir yönetici, böyle bir projeye on iki aylık bir tahminde bulunur ve ardından erken tamamlayarak herkesi şaşırtabilir. Başka bir deyişle, hiç kimse bir ekibin proje takvimini bir güne kadar takip etmesini beklemez.

Proje yöneticilerine ve patronlarına genel tavsiye, resmi zaman tahmini metodolojileri üzerinde zaman kaybetmeyi durdurmak olacaktır. Bunun yerine, proje süresi hakkında istatistiksel bilgilerin toplanmasını teşvik edin ve bu bilgileri şirket genelinde paylaşın. Şirket çapında böyle bir yaklaşımın uygulandığı ve mucizevi tahmin kesinliği ile sonuçlanan şirketleri tanıyorum.

Kural No. 5: Görevleri Değiştirmenin Maliyetini ve Hokkabazlık Önceliklerini Anlayın

İnsan zihni, doğa tarafından inanılmaz bir şekilde tasarlanmıştır. İnanılmaz olsa da, sınırlamaları var. Başka bir deyişle, belirli alanlarda ve belirli bir görev türünde üstünlük sağlamak üzere tasarlanmıştır.

Bir geliştiricinin zihni, yazılım geliştirmede kesinlikle büyük bir varlıktır. Bir proje yöneticisi olarak, onu daha iyi anlamak ve onu en iyi performansı gösterecek bir konuma getirmekle ilgilenir miydiniz?

Çok fazla teoriden kaçınarak basit terimlerle ifade edelim. Unutmayın, teori sizi yalnızca kendi deneyiminizden veya başkalarından bir şeyler öğrenmeniz gerekmeden önce bir yere kadar götürür.

İnsan zihni, güçlü problem çözme ve fikir üretme potansiyeline sahiptir. Ne yazık ki, bu potansiyelden her zaman faydalanmak her zaman mümkün değildir, çünkü esas olarak fikir üretmeyi desteklemek için, sorunun tüm parçalarını aynı anda aktif hafızanızda bir arada tutmanız gerekir. Bu nedenle, bir görev genelleştirildiğinde veya önemsiz parçaları kesip aynı anda bellekte tutulan öğelerin sayısını azaltmak için yeniden formüle edildiğinde karmaşık problemlerin çözümü bir basitleştirme aşamasından geçer. Başka bir deyişle, ya çok dar bir karmaşık problemi ya da birden çok basit problemi çözebiliriz.

Yine de oran doğrusal değil. Aynı anda yaptığınız şeylerin sayısını artırmak, problem çözme yeteneklerinizi büyük ölçüde bozar. Bu yüzden insanoğlu her zaman rol ayrımını bir yaşam optimizasyonu olarak kullandı ve kullanacaktır. İki görev üzerinde ayrı ayrı çalışan iki kişi, her ikisinin de aynı anda iki görevde çalışmasına göre daha hızlı bir atılım yapacaktır.

Bir diğer önemli insan zihni özelliği, bilgisayarlar gibi görevler arasında anında geçiş yapamamasıdır. Gerçekten de, istediğiniz zaman bir şey hakkında düşünmeyi bırakamazsınız. Hemen tüm hızınızda yeni bir konsept düşünmeye başlayamazsınız. Bu tür zihinsel atalet, hava trafik kontrol operatörleri tarafından mükemmel bir şekilde gösterilmiştir. Radara bakıp bütün resmi görmelerine rağmen, hızlı çalışabilmeleri için yine de hafızalarına yüklemeleri gerekiyor. Yeni bir operatörün, bir vardiya değişiminde eskisini değiştirmeden önce ekranı izlemesi on dakika sürer.

Durumu daha da kötüleştiren şey, istediğimiz zaman bir şeyleri unutamıyor olmamız. Öğrendiğimiz her şey bizimle kalır ve zamanla yavaş yavaş kaybolur, yeni bilgiler için kullanabileceğimiz alanı işgal eder. Ve daha da kötüsü, bu etki bazen "bitmemiş bir iş" duygusuyla birleşir. Tamamlanmış ve gelecekte ihtiyaç duymayacağınız bir şeyi unutmak çok daha kolaydır. İşleri daha sonra bitirmek için bir kenara koyduğunuzda, beyniniz doğal olarak “ileride başvurmak üzere” olarak işaretlenen bilgilere tutunur, yeni bilgilerin yerini almasına izin vermek istemez.

Peki. Artık görevleri değiştirme fikrini özetlediğimize göre, bunun gerçek hayatta (deyim yerindeyse) bir düşünce deneyinde nasıl çalıştığını görelim.

On düzenli geliştiricinizin, kişi başına bir görev olmak üzere on düzenli görev üzerinde çalıştığını hayal edin. Onları dikkat dağıtıcı olmayan mükemmel bir ortama kapatabileceğimizi varsayarsak, her görev tek bir zihin tarafından belirli bir sürede çözülebilir. Her şey, en uzun tek görevi tamamlamak için gereken kadar sürecektir.

Şimdi aynı zihinsel deneyi tekrarlayalım. Bu sefer, (önemli) bir neden olmaksızın geliştiriciler arasında sürekli olarak görev atamaları değiştireceğiz. Her gün, her geliştirici üzerinde çalışacak yeni bir görev alır. Daha da iyisi, her saat başı değiştirelim. Sizce ne kadar sürede bitirirler? Belki asla.

İlk senaryodaki proje yöneticisi projeyi etkin bir şekilde yürütebildi. İkincisi onu “yürütmeyi” başardı, orası kesin… ölümünü kolaylaştırdıkları anlamında. Tebrikler. Bu proje öldürme tekniği ekstra etkilidir çünkü zaman kaybının yanı sıra çalışanların moralini de sıfıra düşürür.

Çoğu insan, onlara bu şekilde tamamen akademik bir şekilde sunulduğunda yukarıdaki örnekle aynı fikirde olacaktır. Ancak gerçek hayatta en ufak bir baskı altında aniden her şeyi unuturlar. Büyük patron bir ilerleme raporu talep ediyor veya müşteri belirli bir özellik uygulama tarihi soruyor - neredeyse herhangi bir harici olay, bir proje yöneticisinin ekibe acele etmesine ve endişelerini dile getirmesine neden olabilir, ardından bir dizi görev yeniden ataması ve öncelikli hokkabazlık gelebilir. Orada burada biraz zaman kazanmaya çalışmak, sonuçta projeyi daha da fazla yoldan çıkarmaktan başka bir şeyle sonuçlanmaz.

Bu, ne yazık ki oldukça sık gerçekleşen bir gerçek hayat senaryosu.

İyi bir yönetici ayağa kalkar ve duygusal şok dalgasını emerek ve onu gelecekteki üretken tartışma öğelerine dönüştürerek ekibi bu tür küçük rahatsızlıklardan korur. Bu kesinlikle duygusal olarak zor, ancak ekibi iyi çalışma ritminde tutmanın ve teslim etmelerine izin vermenin tek yolu bu.

Kural No. 6: Sistem Tasarımını Geliştirmenin Bir Yolu Olarak Mimari İncelemeleri Kullanın

BT endüstrisi, aşırı ve eksik mühendislik kavramlarıyla çalışır. Bir röportajda konu açıldığında herkes aşırı mühendisliğin kötü olduğunu söylüyor. Bunu yanıtlamak kolay çünkü sorunun kendisi olumsuz bir "fazla" anlamına gelen "fazla" anlamına geliyor. Gerçek pratik bilgi, mimarinizin ne zaman aşırı mühendislik haline geldiğini anlamak ve erken aşamalarda bundan kaçınmak olacaktır.

Size bununla ilgili denenmiş ve gerçek ipuçlarımdan birkaçını vereyim.

Her şeyden önce, gerekli tüm işlevleri sağlayan daha basit başka bir çözüm varsa, çözüm aşırı tasarlanmış sayılabilir. Bunun anlamı, daha basit bir çözüm bilmiyorsanız, sunabileceğiniz en basit çözüm hangisi olursa olsun, biri sizi yanlış kanıtlamadıkça gözünüzde en iyisidir.

Hayali mimarımız gerçekten çözümün mükemmelliği için çabalıyorsa, olağan mimari incelemesi bunun yeterince optimal olduğunu garanti eder. Ne yazık ki, mimari inceleme en az birkaç diğer nitelikli mimar gerektirir. Pek çok durumda kullanılamama veya pratik olmama tehlikesiyle karşı karşıyadır. Akran değerlendirmesinin yokluğunda, mimarlar yaygın hatalara eğilimlidir. Bunları tek tek gözden geçirelim ve her biri için olası çözümleri tartışalım.

En popüler hatalardan biri, akılda bir iş amacı olmadan tasarım yapmaktır. Herhangi bir iş etkinliğinin son tüketicinin memnuniyetine veya şirket başarısına veya benzer bir iş ihtiyacına bağlı olması gerektiği açıktır. Yine de, çoğu zaman, bu tür bir amaç olmadan tamamen veya kısmen tasarlanan mimariyi görebilirsiniz. Akıl yürütme ya yoktur ya da mümkün olduğunca çok sayıda modern zil ve ıslık kullanmaktan kaynaklanmaktadır.

Bu durumda mimar, tüketicinin ödediği şeyi yapmaz. Bunun yerine, kendi eğlenceleri ve zevkleri için havalı oyuncaklarla oynarlar. Bu, resmi endüstride hiçbir şekilde kabul edilemez. Ve yine de, yine de oldukça sık oluyor gibi görünüyor.

Bazen sorun, mimarın kişiliğinde ve belirli teknolojilere veya araçlara olan takıntısında yatmaktadır. Sadece onları kullanmayı seviyorlar ve hangi iş ihtiyaçlarını çözmeye çalıştıklarını tutarlı bir şekilde açıklayamıyorlar. Buna yakın, insanların küçük parçalardan bir şeyler inşa etmekten başka bir şey bilmediği başka bir durum. Elbette, herhangi bir dış olay, tasarım dünyasına dalma ve asla gerçek bir müşteriye geri dönmeme dürtüsünü tetikler. İlk tetikleyici geçerli bir iş girdisi olsa bile, gerçeklikten uzun süre kopmaları, sanat eserlerinin kullanışlılığını azaltır.

Bunun tedavisi çok basittir, ancak öz disiplin gerektirir. İyi bir mimar, neden gerekli olduğunu kendileri için açık ve dürüst bir şekilde cevaplayıncaya kadar asla kalem ve kağıda dokunmamalıdır. Böyle bir ihtiyaç farklı şekillerde gelebilir. Resmi bir gereklilik, ürün geliştirmeye yönelik örtülü bir ihtiyaç veya önceki tasarımı daha az etkili hale getiren yeni teknolojilerin ortaya çıkması olabilir. Her halükarda, mimarların kendileri itici gücü anladıkları sürece, resmi bir tetikleyici olmamalıdır. Daha sonra bu gücü tasarım kalitelerinin nihai doğrulaması olarak kullanabilirler.

Tespit edilmesi daha zor olan bir diğer sorun, blok mimari düşüncesiyle ilgilidir. Böyle bir zihniyete sahip insanlar her şeyin bir çaresi olduğuna inanırlar ve söz konusu çözüm her zaman bir yapı taşı olarak uygulanır. Başka bir deyişle, mimariyi bir bütün olarak değerlendirmeden işlevselliği doğrudan bileşenlere dönüştürürler. Bu tür bir işlevselliğe ihtiyaç duyulduğunda, sadece istenen işlevselliği sağlayan bir bileşeni sisteme ekleyebilirler. Çoğu zaman bu, resmi gereksinimleri karşılar ancak sistemi tutarsız bir durumda bırakır. Yeni blok, geliştirme, destek ve hatta şirketin lisanslama modeli için mevcut sistem uyumluluğu temelinde seçilmedi. Bu nedenle ekip, mevcut konfigürasyonu değiştirmeye veya bu işlevselliği mevcut sistem kapasitesi aracılığıyla uygulamaya çalışır. Sonuç olarak, sistem desteği ve bakımı kademeli olarak karmaşık bir kabusa dönüşüyor ve bunu yakından takip eden performans düşüşü.

Bu problem için basit bir çözüm yoktur, çünkü sistem mühendisliği bir sanattır ve yeni bir bileşenin eklenmesi gerekip gerekmediğini veya bundan kaçınılabileceğini tahmin etmek asla mümkün değildir. Muhtemelen en iyi uygulama, zaman içinde biriken bakım ve mimari sorunların birikmiş listesini tutmak ve ardından genel sistem mimarisinin periyodik incelemelerini yapmak olacaktır. Bu periyodik gözden geçirme, ortaya çıkan teknolojileri de dikkate alabilir. Bu nedenle, mimari incelemelerin genel amacı, sorunları düzeltmek değil, arzu edilen iyileştirmelerin ve sistemin bir bütün olarak potansiyel uygulanabilirliğini, modası geçmişliğin başgösteren kaçınılmazlığına karşı değerlendirmek olmalıdır.

Kural No. 7: Değer Veren Takım Oyuncuları

Çoğu BT sektörü uzmanına bir röportajda iyi takım oyuncuları olup olmadıkları veya bir takımda iyi çalışıp çalışmadıkları soruldu. Yine de, muhtemelen hiç kimse literatürde bunun için net bir tanım görmedi. Açıkçası, böyle bir kişi genel olarak takım başarısına katkıda bulunacaktır, ancak çok az kişi bu tür bir başarıyı sağlayan ayırt edici kişisel nitelikleri gerçekten tanımlayabilir.

Farklı seviyelerde çalışan birçok insanı gözlemledim ve onların kişisel niteliklerinin proje ilerlemesini nasıl etkilediğini gördüm. Takım çalışmasına en çok yardımcı olan kişisel niteliklerle ilgili aşağıdaki ipuçlarını sunmak istiyorum.

iletişim

İlk ve en önemli kalite, elbette, iletişim kurma yeteneğidir.

Sıfır iletişim yeteneğine sahip bir insan düşünün. Elbette ekip üyelerinden hiçbir geri bildirim almamak onları tamamen işe yaramaz hale getirir. Bu o kadar açıktır ki, görüşme sırasında hiç kimse bu beceriyi gerçekten ölçmüyor, bu da kişinin iyi konuşabildiği sürece becerinin yeterince iyi bir seviyede olduğu anlamına geliyor.

İletişim ikili bir evet/hayır becerisi değildir; daha çok bir bilgi aktarım penceresidir. Ne kadar geniş olursa, bilgi alışverişi o kadar hızlı ve net olur.

Bu pencerenin açıklık aralığı popülasyona göre büyük ölçüde değiştiğinden, böyle bir pencerenin genişliğinin ölçümü bir takım oyuncusunun önemli bir özelliğidir. Bu bağlamda bilgi iletmekten bahsettiğimizi, ancak düzgün konuşmaktan veya insanları teşvik etmekten veya onları konuşma ve iletişim yoluyla motive etmekten veya organize etmekten bahsettiğimizi unutmayın.

İletişim tarzı da önemsizdir. Bilgi sözlü, metinsel, resimli veya karışık bir şekilde iletilebilir. Kişi hızlı veya yavaş konuşabilir. Gözlerinize bakıp sürekli gülümsemek gibi arkadaş canlısı olabilirler ya da uzağa bakıp monoton bir sesle konuşabilirler. Stil, iş arkadaşınızla ilgili kişisel algınızı etkileyebilir, ancak ne anlama geldiklerini açıkça anladığınız sürece herhangi bir stil yeterlidir.

İletişim yeteneklerini tespit etme ve ölçme konusundaki pratik vakalara geçelim.

Genel olarak iletişim becerilerinin iki ana yönü vardır. Birincisi, bilgiyi paylaşma isteğidir. Bazı insanlar paylaşmaya heveslidir, bazıları ise bilgiyi saklamaya çalışır. Bu eğilim aşağı yukarı doğaldır, ancak kişisel motivasyon ve eğitim ile yavaş yavaş değiştirilebilir. Bir tür bilgi paylaşma istekliliği sergileyen kişinin gelecekte de bunu göstereceğini varsaymak güvenlidir. Bu özelliğin, bir adayın bir takımdaki gelecekteki başarısını tahmin etmede iyi olmasının nedeni budur.

Gerçek hayatta, bilgileri gizlemeye çalışan insanlar kolayca fark edilir. Genellikle gerçekten ihtiyaç duyulan herhangi bir şey yerine kasıtlı olarak yararsız bilgileri vermeye çalışırlar. Ya da bilgi akışını içe çevirmek için ön sorular sorarlar ve "bilmesi gereken" bir olaya verdikleri yanıtları en aza indirirler. Taktikleri ne olursa olsun, sonunda onlardan istediğiniz bilgiyi alamadığınızı veya bilgiyi almanın çok fazla çaba gerektirdiğini hissedeceksiniz.

Amacı anlamak önemlidir, çünkü bazı açık sözlü kişiler, sorunuzu daha iyi anlamak için size ön sorular sorabilir ve ardından cevabı sizin için en uygun şekilde iletebilir. Bilgileri gizlemek isteyen kişi, konuşmayı başka yöne çekmek için ek sorular soracak ve bunun yerine asla ilk sorunuza cevap vermeyecektir.

İletişim becerisinin bir başka parçası da dinleyiciye uyum sağlama yeteneğidir.

Farklı insanlar farklı bir konuyu anlama düzeyine, farklı iletişim tarzına ve hatta belirli ayrıntılara farklı ilgi gösterebilir. Bazı iletişimsel akıllı insanlar, dinleyicinin anlama yeteneğine bağlı olarak konuşma akışlarını değiştirir ve belirli bilgileri iletmek için cevaplarını hazırlar. Böyle bir hazırlıkta dinleyicinin ilgisini azaltmak için bazı ön sorular sorulabilir. İletişim farklılıklarını “çözme” yeteneği gerçekten harika bir beceridir, çünkü neredeyse tüm durumlarda anlayışa ulaşmamızı sağlar. Öte yandan, esnek konuşmacılar, bazen çözülemez yanlış anlama çıkmazlarında sıkışıp kalabilirler.

Güçlü ve Zayıf Yönleri Anlamak

Bir takım oyuncusu için gerekli olan başka bir kişisel kaliteye odaklanalım.

Çoğu insan, işbirliğini teşvik etmek ve üretkenliği artırmak için bir ekip ortamının ortalama çevredeki dünyadan daha arkadaş canlısı olması gerektiği konusunda hemfikirdir. Bu nedenle, bir ekibin her bir üyenin güçlü ve zayıf yönlerini anlaması, görevleri doğru bir şekilde dağıtması ve zayıf yönleri güçlü yönlerle kapatması önemlidir. Bu yolda ilk adım, tüm üyelerin becerilerini birbirlerine karşı dürüstçe ölçmesidir. Kendimizi koruyarak zayıf noktalarımızı başkalarından doğal olarak saklama eğiliminde olduğumuz için psikolojik olarak bu zor olabilir.

Dost canlısı ekip atmosferinin yardıma geldiği yer burasıdır.

Yani yeni üyenin takım kurallarına göre oynaması bekleniyor. Ne yazık ki, bazı insanlar dostane bir ortamda bile gardını indiremez. Hayatları boyunca yalnız kurtlar gibi davranırlar. Bu onlardan daha güçlü. Ne yazık ki, böyle bir tutum ekip çalışmasına katkıda bulunmaz.

Röportajda böyle yalnız kurtları tanımanın kolay bir tekniği var. Bir şey bilmediklerini asla kabul etmezler. Elbette insanlar ellerinden gelenin en iyisini yapmayı, tüm yeteneklerini ortaya koymayı ve her zor sorunu çözmeye çalışmayı severler. Ancak herkesin bir bilgi sınırı vardır. Sınırlarımız becerilerimizi şekillendirir. Sınırları kabul etmemek, adayların kendilerini her şeyde eşit derecede iyi, hiçbir şeyde iyi olmayan, her şeyi yapan bir Jack olarak sunmaları anlamına gelir.

Bir uzman kiraladığınızda, muhtemelen bu tür insanlardan kaçınmak istersiniz. Ayrıca, bu kibirli tutum genellikle başka bir kırmızı bayrak özelliği ile birlikte gelir: yardım isteme isteksizliği. Yardım isteme yeteneği, ekip çalışması için kesinlikle gereklidir. Onsuz, bu kadar hızlı ilerleyip gelişemeyiz. Böyle inatçı bir kişi, şirket kaynaklarını ve zamanını yakıp, zor görevlerle süresiz olarak savaşır, ancak asla ekip arkadaşlarını yardım için çağırmaz. Mülakatta bu tür adayları tespit etmenin kolay bir hilesi var. Onlara anlamsız bir soru sorun veya anlamsız bir terimden bahsedin. Normal, ideal olarak meraklı bir insan, bilmediklerini söyler ve ne olduğunu sorar. Savunmacı bir kişi, doğru ya da yanlış cevap olmadığını ve “bilmiyorum”un onları diskalifiye etmediğini vurgulasanız bile bunu asla yapmaz.

Kural No. 8: Ekip Çalışması Organizasyonuna Odaklanma

Ekip çalışması organizasyonu hakkında, yukarıdaki herhangi bir konuda olduğu kadar az bilgi var. Herkes ekip çalışmasının daha iyi olduğunu bilir, ancak bir ekibin nasıl oluşturulacağı ve sürdürüleceği bir sır olarak kalır. Bununla birlikte, ekip oluşturmanın tüm yönlerini kapsamak imkansız olsa bile, burada en azından birkaç anahtar ekip oluşturma tekniğini keşfedebiliriz.

Bina Uzmanlığı

Her BT projesi benzersizdir. Başarılı olmak için, kişinin proje özelliklerini öğrenmesi ve ustalaşması gerekir. Hem teknik hem de teknik olmayan bilgileri içerebilirler. Teknik olmayan bilgiye bir örnek, yönetim, müşteriler, teknik destek ekipleri vb. için kişisel bir ağ olabilir. Özel teknik bilgi, genel BT becerilerinin üzerine ek ayrıntılardır.

Örneğin, bir proje oluşturmak için Maven'i bilmeniz gerekebilir. Ancak, kesin yapı yapısı, mülklerin konumu ve filtreleme yine de projeye göre değişecektir. Her tür bilgide olduğu gibi, bu tür ayrıntılarda ustalaşmak zaman alır; kişi buna ne kadar çok zaman harcarsa, o kadar iyi performans gösterebilir. Zaman, sahip olduğunuz en değerli kaynaktır. Uzmanlıklarından yararlanmak ve onları daha da geliştirmek için ekip üyenizi mümkün olduğunca uzun süre aynı işlevsel alana odaklamak ve böylece ekip performansını sürekli iyileştirmek istiyorsunuz.

Ne yazık ki, bunu süresiz olarak yapmak mümkün değildir. Bir taraftan, insanlar sadece sıkılabilir. Diğer taraftan, beklenmedik bir şekilde projenizi riske atarak uzmanlıklarını kaybetme riskiyle karşı karşıyasınız.

Bakalım takım performansını çok fazla engellemeden olumsuzluklarla başa çıkmanın yolları var mı?

Ekip üyeleri arasında odak alanlarını dağıtın ve onların uzmanlıklarını geliştirmelerine izin verin. Bir noktada, bu proje kapsamında mantıklı olan yeterince yüksek bir seviyeye ulaşıyorlar. Ekstra öğrenme çabası bu noktada onu önemli ölçüde iyileştirmeyecektir. Motivasyon ve meydan okuma olmadan, akıllı insanlar sıkılır ve işlerinden nefret etmeye başlar.

Onlar için başka yerlerde öğrenme olanakları açarak bunu önleyin. Onları projelerden ve şirketin teknolojik yığınından haberdar edin ve yeni zorluklara kapı açın. İlgileri projenin kapsamı içindeyse, ekibinize meydan okumanın ve aynı zamanda faydalı ekip beceri setlerini genişletmenin çifte ödülünü alırsınız. However, any self development is good to avoid boredom, even if it doesn't intersect with immediate project needs. As long as the team expert brains are engaged, they keep supporting already-learned project areas in the back of their minds.

When leaving the company, team experts take a big portion of expertise with them. One of the countermeasures you can use is to widely disseminate documentation that can be updated on the fly. Think of the “persistent memory storage” mentioned earlier.

Still, a project manager would love to duplicate knowledge in team member heads if possible. Having two of every expert would be a simple solution for that, albeit twice as expensive. But there is a leaner way to do it. The trick is to let most of your developers develop expertise in multiple areas, so that each project aspect is covered by at least one deep expert. At the same time, chose a few senior members to grow the breadth along with the depth of their expertise. Usually, this role is best played by a team development lead or an architect. The team lead interacts with all team members and participates in all task implementations. They can tap into each and every aspect of the project, understanding all of its internals. This way, even if you lose one of the experts, the leader can take over and keep on the project progressing until you can hire and train the replacement.

Another flavor of same idea is to cross-train developers in adjacent areas, letting them to observe, learn, and occasionally try their peers' work. Keep in mind that this cross-training needn't be extensive, so it doesn't disrupt focus on developers' primary tasks and doesn't impede productivity. Developing expertise across leadership and cross-training developers builds you a cushion of protection against unforeseen life culprits and allow you some time to maneuver with project resources.

Minimizing Distraction

Software development is a chain of complex and creative problem solving. Even though, with industry development, these complex problems get more and more automated, the work doesn't become easier. It still involves a large amount of art and individual insight, which is very hard to predict and sometimes even harder to wrangle.

Developers are the edge of the weapon. Their concentration is equivalent to the hardness of the weapon's tip. Increase their focus and you'll cut through problems like a hot knife through butter. Distract them and you'll end up clumsily poking at the butter with a blunted stick.

This cannot be over emphasized: Non-problem-solving work can be intensified with motivation or extra effort. For problem solving work, you need maximum detachment from the mundane world. It is difficult to leave all everyday problems behind, and a good project manager should build a quiet development environment in both the physical and mental senses. A developer's workplace should be analogous to a sensory deprivation tank.

Physically, this is implemented as a closed work space. Every team member should have a cube at least where they can dive into solitude. It is preferable to avoid loud noises and aisle conversations. Quick interpersonal communications should be maintained by emails and chats. Large groups should use closed rooms for their meetings to not distract others. This is a pretty standard picture for office life as it used to be.

Unfortunately, the open space paradigm is being adopted more and more widely even in large offices. I would warn against his fad. Even worse, together with open spaces, top management encourages in-place team conversations. That is, in essence, shouting to a person in another row over an uninvolved team member's head. A developer that is interrupted by loud conversation twenty times a day won't have a shred of concentration left. Certainly a major performance killer.

Allowing for a Learning Curve

Knowledge itself is power. This is especially true for such a complex industry as IT. Every task here has its regular cycle: learn, research, implement. The learning phase in particular is invaluable. Not only does better understanding allow better and faster implementation, there are certain knowledge thresholds that must be passed in order to achieve something at all. Of course, there is no point in over-learning either. Each skill should match the production need and not much above it.

However, often, developers are pressured in the opposite direction; to stop learning and to do nothing but produce. Learning is perceived as wasted effort, as it doesn't move the task progress bar. This seems like a really easy problem to solve, sitting at home and reading this article. Yet in the real life, the slightest work pressure turns every manager into that demanding idiot who insists that everybody “stop learning and start doing something already.” I swear, I have heard those exact words so many times throughout my career… A good manager and team leader should understand that learning is an important part of the process even if it doesn't directly increment the progress bar.

Building a Competitive Development Workshop

The tips and tricks presented above are a subset of effective software production expertise. By understanding and applying them in real life, you'll improve your production effectiveness little by little. If you think they are largely unconnected and lacking a theoretical base, you are absolutely right.

I would like to highlight that building a competitive development workshop is not a single-discipline task. It requires knowledge and expertise in multiple adjacent areas. Building such expertise is a hard work. There is no single theoretical base or idea that would solve all your problems at once. Believing in such a silver bullet just serves to distract you from the real goal.

Try out these tips at work to see if they are worth adopting permanently. If you find them useful (or not), leave a comment below and share your experience!