Herkese selam! Adım Lyudmila Makarova, UBRD'de geliştirme müdürüyüm ve ekibimin üçte biri "genel uzmanlardan" oluşuyor.
Kabul edin: Her Teknik Lider, ekibinde çapraz işlevsellik hayalini kurar. Bir kişinin üç kişinin yerini alması ve hatta bunu teslim tarihlerini geciktirmeden verimli bir şekilde yapabilmesi çok güzel. Ve daha da önemlisi kaynakları korur!
Kulağa çok cazip geliyor ama gerçekten öyle mi? Hadi anlamaya çalışalım.
Kimdir o, beklentilerimizin öncüsü?
"Genel uzman" terimi genellikle geliştirici-analist gibi birden fazla rolü birleştiren ekip üyelerini ifade eder.
Ekibin etkileşimi ve çalışmalarının sonucu, katılımcıların mesleki ve kişisel niteliklerine bağlıdır.
Zor beceriler konusunda her şey açıktır, ancak yumuşak beceriler özel ilgiyi hak etmektedir. Çalışana bir yaklaşım bulmaya ve onu en yararlı olacağı göreve yönlendirmeye yardımcı olurlar.
Bilişim sektöründe her türlü kişilik tipi hakkında pek çok makale bulunmaktadır. Deneyimlerime dayanarak BT uzmanlarını dört kategoriye ayıracağım:
1. “Evrensel – Yüce”
Bunlar her yerde. Her zaman çok aktiftirler, ilgi odağı olmak isterler, sürekli meslektaşlarına yardıma ihtiyaçları olup olmadığını sorarlar ve hatta bazen sinir bozucu bile olabilirler. Onlar yalnızca yaratıcılığa yer açacak ve gururlarını eğlendirebilecek anlamlı görevlerle ilgilenirler.
Hangi konularda güçlüler:
- karmaşık sorunları çözebilir;
- sorunun derinliklerine dalın, “kazın” ve sonuçlara ulaşın;
- sorgulayıcı bir zihne sahip olmak.
ancak:
- duygusal olarak kararsız;
- kötü yönetiliyor;
- değiştirilmesi çok zor olan kendi sarsılmaz bakış açılarına sahipler;
- Birinin basit bir şeyi yapmasını sağlamak zordur. Kolay görevler, her şeye kadir olanın egosunu incitir.
2. “Evrensel – Bunu çözeceğim ve yapacağım”
Bu tür insanların sadece bir kılavuza ve biraz zamana ihtiyacı var - ve sorunu çözecekler. Genellikle DevOps'ta güçlü bir geçmişe sahiptirler. Bu tür genelciler tasarımla uğraşmazlar ve yalnızca deneyimlerine dayalı bir geliştirme yöntemini kullanmayı tercih ederler. Görevin uygulanması için seçilen seçenek hakkında teknik liderle kolayca tartışabilirler.
Hangi konularda güçlüler:
- bağımsız;
- Strese dayanıklı;
- birçok konuda yetkin;
- bilgili - onlarla her zaman konuşacak bir şeyler vardır.
ancak:
- sıklıkla yükümlülükleri ihlal eder;
- her şeyi karmaşıklaştırma eğilimindedir: çarpım tablosunu parçalara göre integral alarak çözmek;
- işin kalitesi düşük, her şey 2-3 kez çalışıyor;
- Son teslim tarihlerini sürekli değiştiriyorlar çünkü gerçekte her şeyin o kadar basit olmadığı ortaya çıkıyor.
3. “Evrensel – tamam, bırak ben yapayım, çünkü başka kimse yok”
Çalışan çeşitli alanlarda bilgilidir ve ilgili deneyime sahiptir. Ancak bunların hiçbirinde profesyonel olmayı başaramıyor çünkü çoğu zaman mevcut görevlerdeki boşlukları tıkamak için bir cankurtaran halatı olarak kullanılıyor. Esnek, verimli, kendini talepte görüyor ama öyle değil.
Pratik ideal bir çalışan. Büyük olasılıkla en çok sevdiği bir yön var, ancak yetkinliklerin bulanıklaşması nedeniyle gelişme gerçekleşmiyor. Sonuç olarak, kişi sahipsiz kalma ve duygusal olarak tükenme riskiyle karşı karşıya kalır.
Hangi konularda güçlüler:
- sorumlu;
- Sonuç odaklı;
- sakinlik;
- tamamen kontrollü.
ancak:
- düşük düzeyde yeterlilik nedeniyle ortalama sonuçları göstermek;
- karmaşık ve soyut sorunları çözemez.
4. “Çok yönlü biri, işinin ustasıdır”
Geliştirici olarak ciddi bir geçmişi olan bir kişinin sistem düşüncesi vardır. Bilgiçlik taslayan, kendisinden ve ekibinden talepkar. Onu ilgilendiren herhangi bir görev, eğer sınırlar tanımlanmazsa süresiz olarak büyüyebilir.
Mimariyi iyi tanıyor, teknik uygulama yöntemini seçiyor, seçilen çözümün mevcut mimari üzerindeki etkisini dikkatlice analiz ediyor. Mütevazı, iddialı değil.
Hangi konularda güçlüler:
- yüksek kalitede iş gösterin;
- herhangi bir sorunu çözebilecek kapasiteye sahip;
- çok verimli.
ancak:
- başkalarının görüşlerine karşı hoşgörüsüz;
- maksimalistler. Her şeyi doğru yapmaya çalışırlar ve bu da geliştirme süresini artırır.
Pratikte elimizde ne var?
Rollerin ve yetkinliklerin en sık nasıl birleştirildiğini görelim. Başlangıç noktası olarak standart bir geliştirme ekibini ele alalım: PO, geliştirme yöneticisi (teknoloji lideri), analistler, programcılar, test uzmanları. Ürün sahibini ve teknik lideri dikkate almayacağız. Birincisi teknik yeterlilik eksikliğinden kaynaklanmaktadır. İkincisi, takımda sorunlar varsa her şeyi yapabilmeli.
Yetkinlikleri birleştirmek/birleştirmek/birleştirmek için en yaygın seçenek geliştirici-analisttir. Test analisti ve "üçü bir arada" da çok yaygındır.
Kendi ekibimi örnek alarak size genel uzman arkadaşlarımın artılarını ve eksilerini göstereceğim. Takımımda bunlardan üçte biri var ve onları çok seviyorum.
PO, mevcut bir ürüne yeni tarifeler uygulamak için acil bir görev aldı. Ekibimde 4 analist var. O sırada biri tatildeydi, diğeri hastaydı ve geri kalanı stratejik görevlerin yerine getirilmesiyle meşguldü. Eğer bunları çıkarırsam, kaçınılmaz olarak uygulama son tarihlerini sekteye uğratacaktır. Tek bir çıkış yolu vardı: gerekli konu alanında uzman, çok yönlü bir geliştirici-analist olan "gizli silahı" kullanmak. Ona Anatoly diyelim.
Onun kişilik tipi “evrensel – çözeceğim ve yapacağım”. Elbette uzun süre "görevlerinin birikmiş olduğunu" açıklamaya çalıştı, ancak benim güçlü iradeli kararımla acil bir sorunu çözmek için gönderildi. Ve Anatoly bunu yaptı! Sahnelemeyi yapıp uygulamayı zamanında tamamladı ve müşterileri memnun etti.
İlk bakışta her şey yolunda gitti. Ancak birkaç hafta sonra bu ürün için yeniden iyileştirme gereksinimleri ortaya çıktı. Artık bu sorunun formülasyonu "saf" bir analist tarafından gerçekleştirildi. Yeni gelişmeyi test etme aşamasında, yeni tarifeleri birbirine bağlarken neden hata yaptığımızı uzun süre anlayamadık ve ancak o zaman tüm karışıklığı çözdükten sonra gerçeğin özüne inebildik. Çok zaman harcadık ve son teslim tarihlerini kaçırdık.
Sorun, pek çok gizli anın ve tuzağın yalnızca steyşın vagonumuzun kafasında kalması ve kağıda aktarılmamasıydı. Anatoly'nin daha sonra açıkladığı gibi, çok acelesi vardı. Ancak en olası seçenek, zaten geliştirme sırasında sorunlarla karşılaşmış olması ve bunu hiçbir yere yansıtmadan bunları atlamasıdır.
Başka bir durum daha vardı. Artık yalnızca bir testçimiz var, dolayısıyla bazı görevlerin genel uzmanlar da dahil olmak üzere analistler tarafından test edilmesi gerekiyor. Bu nedenle şartlı Fedor'a bir görev verdim - “evrensel – tamam, bırak ben yapayım, çünkü başka kimse yok”.
Fedor "üçü bir arada", ancak bu görev için zaten bir geliştirici tahsis edildi. Bu, Fedya'nın yalnızca bir analist ile bir test uzmanını birleştirmesi gerektiği anlamına geliyor.
Gereksinimler toplandı, spesifikasyon geliştirmeye sunuldu, test etme zamanı geldi. Fedor, sistemin "avucunun içi gibi" değiştirildiğini biliyor ve mevcut gereklilikleri kapsamlı bir şekilde araştırdı. Bu nedenle test scriptleri yazmakla uğraşmadı, “sistemin nasıl çalışması gerektiği” konusunda testler yaptı ve bunu kullanıcılara aktardı.
Test tamamlandı, revizyon üretime geçti. Daha sonra sistemin yalnızca belirli bakiye hesaplarına yapılan ödemeleri askıya almakla kalmayıp, aynı zamanda buna katılmaması gereken çok nadir dahili hesaplardan yapılan ödemeleri de engellediği ortaya çıktı.
Bunun nedeni, Fedor'un "sistemin nasıl çalışmaması gerektiğini" kontrol etmemesi, bir test planı veya kontrol listesi hazırlamamasıydı. Zamanlamadan tasarruf etmeye ve kendi içgüdülerine güvenmeye karar verdi.
Sorunlarla nasıl baş ederiz?
Bu gibi durumlar ekip performansını, sürüm kalitesini ve müşteri memnuniyetini etkiler. Bu nedenle dikkat edilmeden ve nedenlerinin analizi yapılmadan bırakılamazlar.
1. Zorluklara neden olan her görev için sizden birleşik bir form doldurmanızı rica ediyorum: "düşüşün" gerçekleştiği aşamayı tanımlamanıza olanak tanıyan bir hata haritası:
2. Darboğazlar belirlendikten sonra soruna etki eden her çalışanla bir beyin fırtınası oturumu yapılır: "Neyi değiştirmeli?" (geriye dönüp baktığımızda özel durumları dikkate almıyoruz), bunun sonucunda belirli eylemlerin (her kişilik tipine özel) son teslim tarihleriyle doğduğu ortaya çıkıyor.
3. Ekip içindeki etkileşim için kurallar getirdik. Örneğin, bir görevin ilerleyişi hakkındaki tüm bilgilerin proje yönetim sistemine mutlaka kaydedilmesi konusunda anlaştık. Geliştirme süreci sırasında eserler değiştirildiğinde/tanımlandığında, bunun bilgi tabanına ve teknik spesifikasyonların son versiyonuna yansıtılması gerekir.
4. Kontrol her aşamada (geçmişteki sorunlu aşamalara özel dikkat gösterilir) ve bir sonraki görevin sonuçlarına göre otomatik olarak yapılmaya başlandı.
5. Bir sonraki görevin sonucu değişmediyse, o zaman söz konusu generali kötü başa çıktığı role koymuyorum. Bu roldeki yetkinlikleri geliştirme yeteneğini ve arzusunu değerlendirmeye çalışıyorum. Cevap bulamazsam kendisine daha yakın olan görevi ona bırakıyorum.
Sonunda ne oldu?
Geliştirme süreci daha şeffaf hale geldi. BUS faktörü azaldı. Hatalar üzerinde çalışan ekip üyeleri daha motive olurlar ve karmalarını geliştirirler. Yayınlarımızın kalitesini yavaş yavaş artırıyoruz.
Bulgular
Genelci çalışanların artıları ve eksileri vardır.
Avantajları:
- sarkan bir görevi istediğiniz zaman kapatabilir veya acil bir hatayı kısa sürede çözebilirsiniz;
- bir sorunu çözmeye yönelik bütünleşik bir yaklaşım: icracı, soruna tüm rollerin perspektifinden bakar;
- genelciler neredeyse her şeyi eşit derecede iyi yapabilirler.
Dezavantajları:
- BUS faktörü artar;
- Rolün doğasında olan temel yeterlilikler aşınır. Bundan dolayı işin kalitesi düşüyor;
- son teslim tarihlerinde değişiklik olasılığı artar, çünkü Her aşamada kontrol yoktur. Bir "yıldız" yetiştirmenin riskleri de vardır: Çalışan, kendisinin bir profesyonel olduğunu daha iyi bildiğinden emindir;
- mesleki tükenmişlik riski artar;
- projeyle ilgili pek çok önemli bilgi yalnızca çalışanın "kafasında" kalabilir.
Gördüğünüz gibi daha birçok eksiklik var. Bu nedenle, genel uzmanları yalnızca yeterli kaynak yoksa ve görev oldukça acilse kullanıyorum. Veya bir kişi, başkalarının sahip olmadığı yeterliliklere sahiptir ancak kalite tehlikededir.
Bir görev üzerinde ortak çalışmada rol dağılımı kuralına uyulursa işin kalitesi artar. Sorunlara farklı açılardan bakarız, görüşümüz bulanık olmaz, her zaman taze düşünceler ortaya çıkar. Aynı zamanda, her ekip üyesi mesleki gelişim ve yetkinliklerini genişletmek için her türlü fırsata sahiptir.
En önemli şeyin sürece dahil olduğunu hissetmek, işini yapmak, yetkinliklerinin kapsamını giderek arttırmak olduğuna inanıyorum. Bununla birlikte, bir ekipteki genel kişiler fayda sağlar: Asıl önemli olan, farklı rolleri etkili bir şekilde birleştirmelerini sağlamaktır.
Herkese “zanaatlarının evrensel ustalarından” oluşan, kendi kendini organize eden bir ekip diliyorum!
Kaynak: habr.com