Günaydın.
Duyuru
(Resim:
Stefan Mintert
)
Stefan Mintert, yazılım geliştirmede şirket kültürünü geliştirmek için müşterileriyle birlikte çalışıyor. Şu anda liderlikte en büyük potansiyeli görüyor; hiyerarşik seviyeden bağımsız olarak Bazı yön değişiklikleriyle bir kariyer yolunun ardından bu potansiyelden yararlanmayı kendine görev edindi. Birkaç yıllık danışmanlık deneyimine sahip bir BT geçmişinden gelen, başlangıçta kendi yazılım geliştirme şirketini kurdu. Liderliğin öğrenilmesi gerektiğini ve iyi rol modellerinin nadir olduğunu buldu. Müşterilerinin yazılım geliştirmede en büyük desteğe ihtiyacının kod üretiminde değil liderlik olduğu ortaya çıktı. Dolayısıyla Kutura şirketinin nereye doğru gittiği onun için açıktı: ürünleri geliştiren insanların gelişip büyüyebilmesi için liderliği geliştirmek. Stefan, 1994'ten bu yana iX'te uzun süredir serbest çalışan olarak Haberler için yazıyor.
Bazen insanlar bana özellik geliştirmenin nesinin bu kadar kötü olduğunu soruyor. Özellikleri isteyen ve ihtiyaç duyan biri varsa yanlış bir şey yoktur. Peki sizin işinizde de durum gerçekten böyle mi? Bu, meşhur özellik fabrikasında zar zor fark edilir. Pek çok kişi için, üçüncü tarafların yararlı gördüğü biletleri dağıtmak doğru görünmüyor. Çalışmanızın ne kadar değerli olduğunu değerlendirmek birçok nedenden dolayı zor olabilir. Bunun bir nedeni: Bir ürün üzerinde değil, ürünün bir bileşeni üzerinde çalışıyorsunuz.
Örnek olarak bir arabanın gelişimini (basit görünüm) kullanmayı seviyorum. Geliştirmenin üç takım halinde gerçekleştiğini varsayalım: biri motor için, biri gövde için, biri de şasi için. Her takım sadece işini yapıyorsa ve tamamlanmış araba hiçbir yerde görünmüyorsa, bu aslında araba geliştirme değildir. Üç revizyonun her birinde yalnızca bireysel bileşenleri görebilirsiniz ve bunlar orijinal sorunu çözmez (“İnsanları A'dan B'ye Alma”). Ayrıca (araba) alıcılarına arabanın durumunu nasıl bulduklarını soramazsınız.
Otomobille ilgilenen şirket içi paydaşlar için bu, üç incelemeden geçmeleri ve bileşenleri zihinsel olarak entegre etmek için biraz hayal gücü kullanmaları gerektiği anlamına geliyor.
Bu çalışma şeklinin o kadar saçma olduğunu düşünüyorum ki, her zaman şirketlerin bu aşamayı çoktan geride bıraktığını düşünüyorum. Çevik bağlamda ölçeklendirme çerçeveleri, diğer şeylerin yanı sıra açıklanan senaryodan kaçınmak için birbirlerine yardımcı olur. Ancak yine de izole bileşen ekipleriyle karşılaşıyorum. Dolayısıyla şu soru ortaya çıkıyor: Böyle bir ekibin üyesi olarak silodan çıkmak için ne yapabilirim?
İşte denenmiş ve test edilmiş bazı ipuçları:
Birinci. Diğer bileşen ekiplerinin incelemelerine veya benzer toplantılarına gidin. Özenle inşa edilmiş siloların sınırlarını (yani departman/ekip sınırlarını) aşmanız gerekiyorsa hassasiyet göstermeniz gerekiyor. Başkalarının rahatsız olması da mümkündür. Bu durumda öncelikle dinleyip dinleyemeyeceğimi soruyorum. Çoğunlukla sorun yok. Çok nadiren reddedilmeyle karşılaşıyorum.
Şu ana kadar ekiplerin nasıl koordine edildiğine de dikkat etmekte fayda var. Bilgiyi bir yerden başka bir yere kim taşıyor? Görevleri bileşen biletlerine kim bölüyor? Burada pek çok rol gündeme geliyor. Belki ürün sahibi veya yazılım mimarı bunu yapıyordur? Ayak parmaklarına basmamak için bu kişiyle konuşun!
İkinci aşamada, diğer bileşen ekiplerinden meslektaşlarınızı incelemenize davet edebilirsiniz. Bu daha sonra kendi insanlarınız arasında tahrişe neden olabilir. Ayrıca bu durumda toprağın önceden hazırlanmasına yardımcı olur. Ekip arkadaşlarınıza, inceleme sırasında komşu ekiplerden geri bildirim almak istediğinizi söyleyin.
Her iki davranış da kabul edildikten sonraki adım, eksiksiz ve entegre ürünü hayranlıkla izleyebileceğiniz bir toplantı düzenlemeye veya bu toplantıya davet edilmeye çalışmaktır. Çoğu durumda bu zaten mevcuttur çünkü sonuçta entegrasyonu birisinin yapması gerekir. Kalite kontrol departmanı, test departmanı veya benzeri bir departman varsa onların çalışmaları hakkında bilgi edinmek iyi bir fikirdir. Belki entegrasyonun gerçekleştiği yer burasıdır.
Nadir durumlarda geliştirme sırasında yeterli entegrasyonun olmadığını buldum. Plan, entegrasyonun ancak tüm bileşenler hazır olduğunda gerçekleşeceği yönündeydi. Odak noktası arayüz çalışmasıydı ve bileşen ekipleri uzun bir süre boyunca özel olarak taklit arayüzlere karşı test edildi. Umarım bu istisnadır.
Çözüm
Şansımız varsa bu blog yazısı kimsenin ilgisini çekmeyecek. Ancak, birden fazla ekibin tek bir ürün veya hizmet üzerinde çalıştığı ve ekip üyelerinin üzerinde çalıştıkları ürünün tamamına ilişkin kendi (!) deneyimlerine sahip olmadığı şirketlerin hala var olduğunu görmek beni hayrete düşürüyor. Ancak hiç kimsenin bir sonraki şirket yeniden yapılanmasını beklemesine gerek yok.
Sadece ekibinizin içinde kalmayın, şirket içi ağınızı kurun ve diğer ekiplerle fikir alışverişinde bulunun! Fayda sağlayacak olan yalnızca ürün geliştirme değildir. Siz de entegre ürün bağlamında katkınızı deneyimlediğinizde kendinizi çok daha iyi hissediyorsunuz.
(kendim)
Haberin Sonu
Duyuru
(Resim:
Stefan Mintert
)
Stefan Mintert, yazılım geliştirmede şirket kültürünü geliştirmek için müşterileriyle birlikte çalışıyor. Şu anda liderlikte en büyük potansiyeli görüyor; hiyerarşik seviyeden bağımsız olarak Bazı yön değişiklikleriyle bir kariyer yolunun ardından bu potansiyelden yararlanmayı kendine görev edindi. Birkaç yıllık danışmanlık deneyimine sahip bir BT geçmişinden gelen, başlangıçta kendi yazılım geliştirme şirketini kurdu. Liderliğin öğrenilmesi gerektiğini ve iyi rol modellerinin nadir olduğunu buldu. Müşterilerinin yazılım geliştirmede en büyük desteğe ihtiyacının kod üretiminde değil liderlik olduğu ortaya çıktı. Dolayısıyla Kutura şirketinin nereye doğru gittiği onun için açıktı: ürünleri geliştiren insanların gelişip büyüyebilmesi için liderliği geliştirmek. Stefan, 1994'ten bu yana iX'te uzun süredir serbest çalışan olarak Haberler için yazıyor.
Bazen insanlar bana özellik geliştirmenin nesinin bu kadar kötü olduğunu soruyor. Özellikleri isteyen ve ihtiyaç duyan biri varsa yanlış bir şey yoktur. Peki sizin işinizde de durum gerçekten böyle mi? Bu, meşhur özellik fabrikasında zar zor fark edilir. Pek çok kişi için, üçüncü tarafların yararlı gördüğü biletleri dağıtmak doğru görünmüyor. Çalışmanızın ne kadar değerli olduğunu değerlendirmek birçok nedenden dolayı zor olabilir. Bunun bir nedeni: Bir ürün üzerinde değil, ürünün bir bileşeni üzerinde çalışıyorsunuz.
Örnek olarak bir arabanın gelişimini (basit görünüm) kullanmayı seviyorum. Geliştirmenin üç takım halinde gerçekleştiğini varsayalım: biri motor için, biri gövde için, biri de şasi için. Her takım sadece işini yapıyorsa ve tamamlanmış araba hiçbir yerde görünmüyorsa, bu aslında araba geliştirme değildir. Üç revizyonun her birinde yalnızca bireysel bileşenleri görebilirsiniz ve bunlar orijinal sorunu çözmez (“İnsanları A'dan B'ye Alma”). Ayrıca (araba) alıcılarına arabanın durumunu nasıl bulduklarını soramazsınız.
Otomobille ilgilenen şirket içi paydaşlar için bu, üç incelemeden geçmeleri ve bileşenleri zihinsel olarak entegre etmek için biraz hayal gücü kullanmaları gerektiği anlamına geliyor.
Bu çalışma şeklinin o kadar saçma olduğunu düşünüyorum ki, her zaman şirketlerin bu aşamayı çoktan geride bıraktığını düşünüyorum. Çevik bağlamda ölçeklendirme çerçeveleri, diğer şeylerin yanı sıra açıklanan senaryodan kaçınmak için birbirlerine yardımcı olur. Ancak yine de izole bileşen ekipleriyle karşılaşıyorum. Dolayısıyla şu soru ortaya çıkıyor: Böyle bir ekibin üyesi olarak silodan çıkmak için ne yapabilirim?
İşte denenmiş ve test edilmiş bazı ipuçları:
Birinci. Diğer bileşen ekiplerinin incelemelerine veya benzer toplantılarına gidin. Özenle inşa edilmiş siloların sınırlarını (yani departman/ekip sınırlarını) aşmanız gerekiyorsa hassasiyet göstermeniz gerekiyor. Başkalarının rahatsız olması da mümkündür. Bu durumda öncelikle dinleyip dinleyemeyeceğimi soruyorum. Çoğunlukla sorun yok. Çok nadiren reddedilmeyle karşılaşıyorum.
Şu ana kadar ekiplerin nasıl koordine edildiğine de dikkat etmekte fayda var. Bilgiyi bir yerden başka bir yere kim taşıyor? Görevleri bileşen biletlerine kim bölüyor? Burada pek çok rol gündeme geliyor. Belki ürün sahibi veya yazılım mimarı bunu yapıyordur? Ayak parmaklarına basmamak için bu kişiyle konuşun!
İkinci aşamada, diğer bileşen ekiplerinden meslektaşlarınızı incelemenize davet edebilirsiniz. Bu daha sonra kendi insanlarınız arasında tahrişe neden olabilir. Ayrıca bu durumda toprağın önceden hazırlanmasına yardımcı olur. Ekip arkadaşlarınıza, inceleme sırasında komşu ekiplerden geri bildirim almak istediğinizi söyleyin.
Her iki davranış da kabul edildikten sonraki adım, eksiksiz ve entegre ürünü hayranlıkla izleyebileceğiniz bir toplantı düzenlemeye veya bu toplantıya davet edilmeye çalışmaktır. Çoğu durumda bu zaten mevcuttur çünkü sonuçta entegrasyonu birisinin yapması gerekir. Kalite kontrol departmanı, test departmanı veya benzeri bir departman varsa onların çalışmaları hakkında bilgi edinmek iyi bir fikirdir. Belki entegrasyonun gerçekleştiği yer burasıdır.
Nadir durumlarda geliştirme sırasında yeterli entegrasyonun olmadığını buldum. Plan, entegrasyonun ancak tüm bileşenler hazır olduğunda gerçekleşeceği yönündeydi. Odak noktası arayüz çalışmasıydı ve bileşen ekipleri uzun bir süre boyunca özel olarak taklit arayüzlere karşı test edildi. Umarım bu istisnadır.
Çözüm
Şansımız varsa bu blog yazısı kimsenin ilgisini çekmeyecek. Ancak, birden fazla ekibin tek bir ürün veya hizmet üzerinde çalıştığı ve ekip üyelerinin üzerinde çalıştıkları ürünün tamamına ilişkin kendi (!) deneyimlerine sahip olmadığı şirketlerin hala var olduğunu görmek beni hayrete düşürüyor. Ancak hiç kimsenin bir sonraki şirket yeniden yapılanmasını beklemesine gerek yok.
Sadece ekibinizin içinde kalmayın, şirket içi ağınızı kurun ve diğer ekiplerle fikir alışverişinde bulunun! Fayda sağlayacak olan yalnızca ürün geliştirme değildir. Siz de entegre ürün bağlamında katkınızı deneyimlediğinizde kendinizi çok daha iyi hissediyorsunuz.
(kendim)
Haberin Sonu