Ben 5+ geliştiriciden oluşan bir takım lideriyim. Ben bir geliştiricinin olması (en diyelim A kodu anlamak kolay, temiz iyi yazıyor iyi bir programcı olduğunu). Ancak yönetmesi biraz zor ve bazen gerçekten iyi performans gösterip göstermediğini merak ediyorum.

1. Şirketimiz, geliştiricilerin, programcıları izleyecek kadar değil, paydaşları bu ilerlemeden haberdar tutmaları için kullandığımız böcek izleyicideki iş ilerlemesini belirtmelerini ister. Mesele şu ki, A yalnızca bir görev ilerlemesini güncellediğinde (belki de ilk çalışılmasından 3 hafta sonra) günceller ve bu, geliştirme haftasının ortasında neler olup bittiğini merak eden herkesi bırakır. Tekrarlanan araştırmalara rağmen alışkanlığını değiştirmezdi. (Tamam, geliştiriciler evraktan nefret ediyor, ben de öyle)
2. Son 2-3 aydır çeşitli olaylar nedeniyle çok sık izne ayrılıyor - ya hasta, ya da çok sayıda kişisel etkinliğe katılmak zorunda vb. (Tamam, kötü şeyler bir dizide oluyor. Bu sadece bir tesadüf)
3. Her ay için sprint veya yol haritası tanımlarız. Sprintin başlangıcında, geliştiricilerin her birinin bir sprint içinde yapması gereken iş miktarını tartışacağız ve geliştiriciler, her görev için ihtiyaç duydukları süreyi belirleyecekler . Genelde hepsini tamamlayamaz. (Sorun değil, geliştiriciler hatalarından dolayı düzenli olarak son tarihler kaçırıyorlar).
4. Ben Singapur merkezliyim. Önemli olup olmadığından emin değilim. Evet, Asyalıların suskun olduğu biliniyor, ama bu önemli mi?

Yukarıdaki olaylardan sadece bir veya iki tanesi meydana gelirse, A'nın performansının düşük olduğunu hissetmeyeceğim , ama hepsi birlikte oluyor. Bu yüzden , A'nın düşük performans gösterdiği ve belki de - Tanrı korusun - gevşemeyi hissediyorum .

Bu sadece programcı olarak yılların tecrübesine dayanan bir duygu. Ama yanılıyor olabilirim.

Her iki görevin de aynı olmaması nedeniyle bir programcının çalışmasını ölçmek oldukça zordur ve bir programcının şirketinize olan bağlılığını ölçmek için standart bir amaçtan yoksundur. Programcının işini yapıp yapmadığını ya da gevşemesini söylemek tamamen imkansızdır. Yapabileceğiniz tek şey, onlara güvenmek - evet, onlara güvenmek ve özerklik vermek, programcıların çalışabilmesi için en iyi yoldur, bunu biliyorum, bu nedenle programcılarınıza neden güvenmeniz gerektiğine dair bir konuşma yapmayın, teşekkür ederim. çok - ama güvenini kötüye kullanırlarsa, biliyor musun?

Sonuç:

Onun hakkında performansına dair algımla ilgili olarak onunla doğrudan konuşuyorum. En iyi seviyede performans göstermediği hissine sahip olduğumu önerdiğimde kızdı. Bunun tamamen haksız bir duygu olduğunu hissetti. Sonra bunun benim hislerim olduğunu ve hislerimin doğru olup olmadığını bilmiyordum. Bunların hiçbiri olmazdı ve tartışmaya derhal son verdi.

Ayrılmadan önce çok soğuk bir tonda "şirkete daha fazlasını vermeye çalışacağını" söyledi. Tepkileriyle şaşırmıştım. Bir şekilde onu kırdığıma eminim. Yine de, onunla çok açık konuşmam için yapılacak doğru şeyin olup olmadığından emin değilim.

Sorum şu: Programcılarınızın düşük performans gösterip göstermediğini nasıl söyleyebilirsiniz? Elbette benden daha iyi bilen tecrübe ekip liderleri var? 

Ekstra notlar:

1. Mikro yönetmekten nefret ediyorum. Dolayısıyla bizim yazılım sürecimiz için elimizde tek şey Sprint (görevlerin önceliklendirildiği ve atandığı ve ayın sonunda yapılan işlerin bir incelemesi). Geliştiriciler, işleri her gün devam ettikçe güncellemelerini ister.
2. Stand-up toplantısı ya da herhangi bir şey yok. Esas olarak, evden çalışma özgürlüğümüz var ve herkes bu özgürlüğü besliyor.
3. Son tarihi belirleyen kişi ben olmama rağmen, geliştiriciler her görev için bir tahmin sunacak ve karar vermeyi temel alarak belirli bir koşuya giren işleri belirleyeceğim. Sprint sonunda görevleri bitiremezlerse, bir sonrakine iteceğim. Bu yüzden teorik olarak kişi tüm sprint boyunca sadece 1 veya 2 görev yapabilir ve ardından kalan 99 görevi bir sonraki sprinte itebilir ve hala bunu haklı çıkardığı sürece iyi olacak - günlük iş ilerleme güncellemeleri biçiminde

Bu, çözülmesi şaşırtıcı derecede kolay bir problem olmalıdır.

Onunla ikinci bir toplantı yap. Ona, muhtemelen hatalı olan gerçeğe dair algınız olduğunu kabul ettiğinizi söyleyin. Öyleyse, "eğer öyleyse, o zaman algımı geliştirmek için birlikte çalışmamız gerekir." Sonunda bu sorunu çözmesi için ona meydan okuduğu için mikro yönetilen hissetmiyor.

Bu kesin şey uzun zaman önce başıma geldi. Benim için mesele, kimsenin sadece işimi yapmak için fazladan kredi aradığımı düşünme ihtimalini sevmemesiydi. Ve bu yeterince adildi, ancak herhangi bir personel üyesiyle bölüm müdürü arasında düzenli bir geri bildirim döngüsü olmalı.

Eğer yoksa o zaman bu problemleri yaşarsınız.

Düzenli, planlı, 1: 1'ler harika bir fikir. Ve insanların da belirttiği gibi, standupların evden çalışmaya dik durmaları gerekmez. Ancak bu üç soruyu içermelidir: Dün ne yaptın? Bugün ne yapmayı düşünüyorsun? Ve çoğu insanın unuttuğu şey ... Ne (eğer bir şey varsa) seni tutuyor?

Bunun anlamı, söz konusu olmalıdır ekip üyeleri birlikte çalışmak asla nerede durumları vazgeçirmek için deneyin. Daha önce de bu durumda çalıştım ve ekip içinde ve bunun dışında güvensizlik yaşadım. Hepinizin ofise geleceği düzenli bir gün geçirin. İnsanların süreçleri iyileştirme konusunda bazı fikirleri dile getirebilecekleri düzenli bir toplantı yapın.

Bunu bir satır raporlama etkinliği yapmayın. Sadece konuşma fırsatı bul. Öğrendiklerine şaşıracaksın. Mümkünse, bunu sosyal bir etkinliğe dönüştürün, çalışma zamanında birkaç egzersiz yapın ve yapıştırma çalışması yapın.

Burada birçok harika tavsiye var ve hiçbirinden uzaklaşmak istemiyorum, bu yüzden ayrı bir cevap olarak gönderiyorum.

Birincisi, sorunun kökenini keşfetmediğiniz bana (ve görünüşe göre diğerleri) açıkça belli oluyor . Bir semptoma bakıyorsun ve onu iyileştirmeye çalışıyorsun. Kendinle bu geliştirici arasında sürtünmeye neden olan şeyin ne olduğunu bulman gerek. Belki de fazla yetkili olursunuz (Ürün Sahibim kısa bir süre önce kendini bir proje üzerinde "Sonsuz Güç" olarak tanımladı ve bu, söylerken güldüğü halde bana saldırdı.) Belki de ciddi aile sorunları yaşıyordur (iş dışı her zaman açıklar). Orada bir kök sorun burada ve bunu bulana kadar, bu olacak değil sabitlenebilir.

İyi yakalama!

Eğer onun performansı daha iyi olabilirse, bunu belirlemeniz harika. Yine de, eğer kötü performansı karşılaştırmaya göre hala iyi bir performanssa, iyi bir geliştiriciyi kaybetmemek için dikkatli olmanız gerektiğini unutmayın. İyi geliştiriciler gelmek zordur ve iyi geliştiriciler çok özel şeyler gerektirir. Belki de gereksinimlerinin karşılanıp karşılanmadığını görmek için Joel Testine bir göz atın .

Sorunun Kaynağını Bulun

Yaptığı işle ilgili bir şeyden memnun değilse, o zaman sorunun kaynağını belirleyerek düzeltebilirsiniz. Açık konuşayım, programcınızın iyi kod yazdığını söylemiştiniz. Bu, programlamayı sevdiği anlamına geliyor. İş yerinde hüsrana uğradığı açıkça görülüyor (toplantı tanımlamanızdan) ve performansının olması gerektiği yerin altında olduğu, ancak varsaymadığınız konusunda haklısınız . Unutma ki birçok programcı sadece sosyal becerilere sahip değil.

Sen de Mükemmel değilsin

Unutma, bazen, özellikle içe dönük olanlar ile , kişilik çatışmalarına gireceksin . Bu bir kişilik çatışması olarak ortaya çıkıyorsa, performansta bir artış elde etmek için ne kadar ileri gitmek istediğinizi düşünün (bkz. 1)

Tüm bu dedi

Programcıları Yönetme hakkında bir blog yazısı yazdım. Bence okumalısın.

http://deltreey.blogspot.com/2012/07/managing-programmers.html

Bu yazının son bölümünü yeterince vurgulayamıyorum.

Geliştiricileriniz hiç iyi değilse, kodlamak isterler.

Programlayıcınız gevşiyor olsa bile gevşetmek istemiyor. Bu sorunun kökenini bulmak zorundasınız ve basitçe çözülemeyecek bir şey olduğu ortaya çıkmış olabilir ve onun gitmesine izin verilmelidir, ancak ne olursa olsun, tespit etmeden bilinçli bir karar veremezsiniz.

Birinin tanımladığınız gibi “biraz zor” olduğunu düşündüğünde, birinin nasıl performans gösterdiğini ve dev ekip üyelerinin verimliliğini etkileyen sorunların (nesnel veya öznel) olup olmadığını daha iyi anlamak için, sizinle birlikte düzenli bir 1: 1 uygulaması kullanmayı düşünün . Takım üyeleri, mükemmel bir makalede sunulan Güncelleme, Havalandırma ve Felaket :

... Her 1: 1'in derinden gizlenmiş acil felaketleri keşfetmek için zorlu bir mesele olduğunu öne sürmüyorum, ancak memnuniyetsizliğin sessizce ortaya çıkabileceği haftalık bir yer yaratmak istiyorsunuz. A: 1: 1, haftalık önleyici bakım yapma ve aynı zamanda ekibinizin sağlığını anlama şansınızdır.

... 1: 1'lerin başarılı rejimini çevreleyen ses sessizliktir. 1: 1 sırasında gerçekleşen tüm dinleme, sorgulama ve tartışma yönetimsel önleyici bakımdır. Bir projeye duyulan ilginin ne zaman azalmaya başladığını ve iş tatminsizliği olmadan harekete geçmeye başladığını göreceksiniz. İki çalışan arasındaki gerginliği duyacaksınız ve bir toplantıda bağırma maçına gelmeden önce bir tartışma düzenleyeceksiniz. Sağlıklı 1: 1 kültürüne ödülünüz, belirgin bir drama eksikliğidir .

_{Bahsedilen makalenin çok güçlü bir yanı, kendi yararına olması, faydaları açıklamanın yanı sıra, temelde birinin, başka kaynaklara girmeden düzenli 1: 1 uygulamaları uygulamaya başlamasını sağlayan bir dizi pratik öneri sunmasıdır. Ek bilgi zarar vermez, biliyorsunuz).}

Açıkçası, burada önemli bir iletişim sorunu var. Harika işler yapıyor olabilir, ancak ne yaptığını bilmediğinizi hissediyorsanız, bu başlı başına bir sorundur. Ve ne yaptığını bilmiyorsan, meslektaşları da bilmiyordur. Bu, iki haftalık eski kodunu kontrol ederken sorunlara neden olabilir. Özellikle benzer bir alanda çalışan biri varsa.

Bu tür çatışmaları en aza indirmek için her zaman güncellemeleri kontrol etmesini / düzenli olarak sunmasını her zaman önerebilirsiniz. Bu, isteğinizi "Ne yaptığınızı bilmiyorum" yerine, ekibe yardım etme açısından yönlendirebilir.

Stand-up'ların çok fazla nefret ettiğini biliyorum ama aslında aynı odada tutulmaları gerekmiyor. Günde bir kez yapılan hızlı bir arama veya grup Skype güncellemesi çok hızlıdır ve herkesi aynı sayfada tutar.

Şu anda Hindistan’dan İrlanda’da bir ekiple çalışıyorum ve her biriyle günlük olarak iletişim içinde olmadığımı hayal edemiyorum ve her birinin ne olduğunu kabaca biliyorum ya da çok hızlı bir şekilde öğrenebilirim.

Anlamsız

Günlük durum güncellemeleri anlamsız. İnsanların “bugün% 2,5 tamamlandı” şeklinde rapor vermeleri, “bugün% 3,74 tamam olduğumda” saçma.

Menfaat sahiplerine hiçbir değer sağlamaz ve işi yapan insanları rahatsız eder.

Onları çalışmalarına bırakın, rahatsız edilmeden.

Asılsız

Hangi temelde geliştirici A'nın 'düşük performans' yaptığını düşünüyorsunuz? İşi zamanında yapılıyorsa, bu yeterince iyi olmalı.

Mikro yönetmekten nefret ettiğini söylüyorsun, ama tam olarak tanımladığın şey bu.

Şirketimiz, geliştiricilerin, programcıları izleyecek kadar değil, paydaşları bu ilerlemeden haberdar tutmaları için kullandığımız böcek izleyicideki iş ilerlemesini belirtmelerini ister. ... Geliştiriciler, işleri her gün devam ettikçe güncellemelerini ister.

Bu anlamsız (yukarıya bakın) saçmalık. Ekibiniz hamburger çevirmiyor, teknik çözümler üretiyor. İlerleme doğrusal değildir, ne de kolayca ölçülebilir, hatta tahmin edilebilir. Öyle olsa bile, böyle günlük ölçümler veya tahminlerin değeri yoktur.

Tehlikeli

Geliştirici A'nın 'düşük performans gösterdiğini' hissetmenizin temelini yeniden keşfedin. Sizce daha iyisini yapabileceğini, ancak hangi delillere dayanarak?

Unhappy! = Düşük performans

Açıklandığı şekilde devam edin ve bir noktada geliştirici A, yeterince takdir edilmediğine, şirkete yeterince verdiğine ve başka bir şirket bulacağına karar verecektir. Çalışanların emeğinin son% 0.01'ini sıkmak, onları uzun vadeli tutmaktan çok daha az önemlidir.

Geliştiriciler, yaptıklarını belgeleme ve durumları güncelleme çabalarından nefret edebilir - ancak bu, profesyonel bir geliştirici olmanın bir parçasıdır. Sorun günlüğünüzdeki son güncellemelerinin, çalışmalarında gereksiz bir olumsuz algılamaya neden olduğunu belirtmeye çalışmanızı öneririm. İletişim kurma konusundaki başarısızlığının bir performans problemi olduğunu görmüyorsa - peki, onun takım lideri sensin; ona olduğunu söyle .

Tahmin ile ilgili olarak - bu klasik bir sorundur. Steve McConnell tarafından "Yazılım Tahmini - Kara Sanatın Ortadan Kaldırılması" bölümünü okumanızı tavsiye ederim. Bu durumda, geliştiricilerinizin çoğunun tahmin edemediği izlenimini veriyorsunuz. Bu ilginçtir, normaldir ve nadiren ele alınır. Bu bireyden ziyade tahmin sürecinde kendinizle ilgili bir sorun olduğunu öneriyorum.

Tahmin-ölçü gözden geçirme döngüsünü kapatmayı deneyin ve geliştirin. O zaman, geliştiricileriniz daha düzenli olarak gelirse ve bu kişi gelmezse, onun hakkında ne yapacağınızı düşünebilirsiniz.

Son olarak, stand up toplantısı yapın. Anlık İleti ile olsa bile. Tek istediğin herkesin "ne yaptığımı, bugün ne yaptığımı, herhangi bir sorunu" bilmesi. Sorun varsa, daha sonra tartışma için onları çevrimdışı duruma getirin. Daha önce de öyle yaptım ve o takım için başarılıydı.

İlk olarak, neden sprintleriniz o kadar uzun? Sprintler asla iki haftayı geçmemelidir. Bence senin sorunun büyük çoğunluğu orada yatıyor. Sprint süresini deneme bazında kısaltmanızı ve sorunuzu tekrar analiz etmenizi öneririm.

Peki ya check-in kodları? Her zaman kodunu kontrol ediyor mu? Şahsen programcıların gerçekten yönetim adamları olmadıklarını ve yönetmeye çalıştıkça daha fazla sinirleneceklerini düşünüyorum. Aslında, bu güncelleme görevlerini yapmaktan nefret ediyorum ve muhtemelen bu yüzden Başbakanların ve liderlerin orada olması gerekiyor. Ancak aynı zamanda, scrum toplantıları sırasında veya ne zaman bir araya geldiğimizde de bir statü veriyorum. Şimdi bir görev atadığınızda, onlar bir zaman çizelgesine bağlı mıdır yoksa zaman çizelgesini atayan siz misiniz?

Bu nedenle, birinin performans altında olup olmadığını söyleyebilmemin tek yolu taahhüt edilen zaman çizelgesini yapılan işin% 'si ile eşleştirmek. Şimdi, elbette, eğer biri iki sayı ekleyen bir yöntem yazmanın iki gün alacağını söylerse, bir sorun olduğunu biliyorsunuz, bu yüzden zaman çizelgesi her iki tarafça da gerçekçi ve anlaşmalı bir şey olmalı.

Bu şekilde yapın - Bir saat içinde bir parça kod yazabiliyorsanız, ona bir saat + biraz tampon verin. Bunu size o kadar sürede veriyorsa, sanırım siz iyi durumdasınız. Eğer o zaman onu sorgulamıyorsanız, daha sonra makul bir açıklama yapıp yapmadığına karar vermek size bağlıdır.

Yapabileceğiniz bir şey, XPlanner gibi bir şeyi sürüm aracıyla bütünleştirmek.

Gevşeyen birisini belirlemek için programlama mesleğinin doğası gereği diğer mesleklerden farklı olduğunu sanmıyorum. Bağırsaklarınızla gitmek zorunda kalabilirsiniz.

Şahsen, A'nın haftalarca güncelleme sağlamayı reddetmesinin garip olduğunu düşünüyorum. Evden çalışan bir programcıyım ve işverenim ile aramdaki ilerlemeyle ilgili günlük güncellemeler vermem gereken gizli bir sözleşme var. Bunlar "resmi" güncellemeler değil, sadece kısa bir e-posta veya anlık mesajlaşma olup, oluşturduğum yazılımla ilgili neler olduğunu bilmesini sağlar. Güncelleme yazmak bir veya iki dakikadan az sürüyor ve ikimiz için de kapanış sunuyor. Hata düzeltmeleri için bileti gün sonuna kadar hata izleyicimizde çözüldüğü şekilde işaretliyorum. Bunlar benim için zor prosedürler olmasa da, çok az evrak ile rahat bir çalışma ortamının tadını çıkarıyorum.

Gündelik güncellemeler bile ondan geldiği için takdir edilebilirdi, eminim. Görevinizde çok ama çok hoş görünüyorsunuz. Uzun bir süredir durduğundan şüpheleniyorsanız, onunla konuşmak için başka bir bahaneye ihtiyacınız yok.

Skype üzerinden veya bir sohbet odasında olsa bile günlük standuplar bu şekildedir, ancak bunu paydaşlar için bir güncelleme olarak görmezseniz bile. Günde bir kez bütün ekip ne üzerinde çalıştıklarını, ne gibi zorluklarla karşılaştıklarını ve daha sonra ne yapmayı planladıklarını söylemeye çalıştığında, birkaç kazanç elde edersiniz:

• İyi ya da kötü nedenlerle zaman harcıyor olsanız da, bir şeyin çok uzun sürmesi daha şeffaf olacak, geliştiricilerinizi ihtiyaç duyduklarında yardım istemeye teşvik edecek ve muhtemelen olması gerekmeyen araştırmalara girmeyeceklerdir. ya da ekibin geri kalanından gelen girdilerin bu sorunu daha hızlı çözmelerine yardımcı olacağı zaman, bu sorun için bir problem çözme.

• Bir yönetici olarak, insanların barikatlarla en sık nerede karşılaştığını görebilirsiniz, bu da daha iyi tahmin etmenize ve zaman / para harcıyor olan temel sorunları çözmenize yardımcı olur.

• IMO, ekibin, genellikle herkesin bazen göreceli olarak basit işleri bile yapmasının ne kadar sürdüğünü görebildiklerinde tahminlerden daha fazla fayda görmeyi öğrenmesine gerçekten yardımcı oluyor.

• Ekip üyeleriniz size daha sonra ne yapmayı planladıklarını söylediklerinde, öncelik sırasına göre iletilmesi gereken şeyler hakkında genellikle size hatırlatma yapılır.

Bu yüzden 'tamamlanma yüzdesini' unut. Sadece herkese, herkesle olduğu kadar dürüst olma, süreçte daha fazla tecrübe kazandıkça daha iyi / daha güvenilir tahminler yapma ve insanlara zihnine dönüşmeden rapor verme konusunda ilerleme kaydetmeleri için biraz daha motivasyon verme sürecini gerçekleştirin. - Gerçekten yapamayacağın bir şeye bir numara koyma alıştırması.

Üst yönetimin son teslim tarihlerinin her zaman etkilenmeyeceğini anladığı anlaşılıyor. Günlük standuplar yapmak size bu cephede daha fazla mermi verecektir çünkü neden vurulmadıklarına dair çok daha spesifik fikirlere sahip olacaksınız.

Ve onlara ilk şeyi yapma. Her zaman bir hata IMO. İnsanların, tüm sorunların ne olduğu konusunda daha güvenilir bir şekilde rapor verebilmeleri için IMO'ya, dişlerini tekrar problemlere batırmak için zamana ihtiyaçları var.

Sorumluluktan çok iletişim ile ilgili olan ve sadece hedefleri belirleyen hızlı standuplar, bence çevik işler yapan şeydir. Geri kalanı, özellikle yönetici / paydaş yılan yağı olarak görmeye başladığım Scrum'ı alabilir veya bırakabilirim.

Düşük performans?

Yoğunluk abbs ve bir kişinin kariyeri boyunca akar. Maliyetinden daha değerliyse, onunla konuşun ve işini kolaylaştırmaya çalışın. Veya başka bir yedek aramaya başlayın.

İletişim

Haftalık toplantılara güvenmeyin. Çoğu insan tam bir braindump yapmayacak. Daha fazla 1: 1 programlayın. Onlara işlerin nasıl yürüdüğünü, neler daha iyi yapabileceğinizi ve onların daha iyi yapabileceğini düşündüğünüzü sorun. Bazen konuşacak bir şey olmaz, ama sorun değil. Daha fazla 1: 1 alarak, bir şeyden bahsetmeyi hatırlama ihtimalini arttırırsınız.

Daha kalıcı bir iletişim yoluna sahip olmak

Ekstra bir angarya gibi hissetmemeniz durumunda insanlardan daha fazla bilgi edinebilirsiniz. Hepsi uzaktaysa, Hipchat veya IRC gibi günlüğe kaydetme yeteneklerine sahip bir sohbet programı kullanmalarını isteyin. Daha kalıcı bir iletişim yoluna sahip olmak, insanları daha fazla konuşmaya teşvik eder. Örnek alın ve sık sık konuşun, başkalarını da aynı şeyi yapmaya teşvik etmek. Günde en az bir kez, insanların projeleriyle nerede olduklarını söylemeleri. Bazen, yalnızca sohbete bakarak, işlerin nasıl geliştiğine dair bir fikir edinebilirsiniz.

Kaynak kontrolü

Herkesin günlük kodunu kontrol etmesini sağlayın. Git kullanıyorsanız, şirket deposundaki kendi şubelerine gitmelerini sağlayın. Komisyonlara bakarak, nasıl olduklarını söyleyebilirsiniz.

Araçları uçlardan ayırın

Paydaşlar güncellenmek istiyor? Paydaşlarla kendiniz anlaşın. Müdür olarak işinizin bir parçası bok şemsiyesi olmaktır, böylece kodlayıcılarınız çalışmalarına odaklanabilir. Sohbet kayıtlarına bakın ve taahhütte bulunun, ardından işlerin nasıl yürüdüğü hakkında bir özet yazın.

Bunlar benim önerilerim:

1. Yenilik: Maliyetleri düşürmek ve mevcut durumu iyileştirmek için kullanılan hayal gücü ve yaratıcılık.

2. Şirket: Başkalarının amaçlarına ulaşmalarına yardımcı olma isteği

3. Girişim: Rutin olmayan işleri ve görevleri denemek.

4. Seyirci: Devamsızlık veya gecikme, Standartların altında.

5. Uyarı: Yeni bilgileri ve durumları hızlıca anlama yeteneği

6. Doğruluk ve Kalite: Kod incelemeleri, zamanında teslimat, sorun oranı).