sloganı:
Koca, kirli çocuklara bakarak karısına der ki: Peki bunları yıkayalım mı, yoksa yenilerini mi doğuralım?
Kesimin altında ekip liderimiz ve RAS Ürün Geliştirme Direktörü Igor Marnat'ın programcıları motive etmenin özellikleri hakkındaki makalesinin ikinci kısmı yer alıyor. Yazının ilk bölümüne buradan ulaşabilirsiniz -
Yazının ilk bölümünde Maslow piramidinin iki alt düzeyine değindim: fizyolojik ihtiyaçlar, güvenlik ihtiyaçları, rahatlık ve istikrar ihtiyaçları ve bir sonraki üçüncü düzeye geçiyorum:
III - Ait olma ve sevgi ihtiyacı
İtalyan mafyasının adının “Cosa Nostra” olduğunu biliyordum ama “Cosa Nostra”nın nasıl çevrildiğini öğrendiğimde çok etkilendim. İtalyancadan çevrilen “Cosa Nostra”, “Bizim İşimiz” anlamına geliyor. Motivasyon açısından isim seçimi oldukça başarılı (mesleği bir kenara bırakalım, bu durumda sadece motivasyonla ilgileniyoruz). Bir kişi genellikle bir ekibin parçası olmak, büyük, ortak bir iş yapmak ister.
Orduda, donanmada ve her türlü büyük paramiliter oluşumda aidiyet ve sevgi ihtiyacının karşılanmasına büyük önem verilmektedir. Ve gördüğümüz gibi mafyada. Bu anlaşılabilir bir durumdur, çünkü çok az ortak noktası olan, başlangıçta benzer düşüncelere sahip insanlardan oluşan bir ekip oluşturmayan, zorunlu askerlik yoluyla (gönüllü olarak değil) bir araya getirilen, farklı eğitim düzeylerine sahip, farklı kişisel değerlere sahip insanları zorlamanız gerekir. , kelimenin tam anlamıyla hayatlarını, ölümcül risk altında, ortak bir amaca adamak, hayatınızı bir silah arkadaşına emanet etmek.
Bu çok güçlü bir motivasyon; çoğu insan için daha büyük bir şeye ait olduğunu hissetmek, bir ailenin, bir ülkenin, bir ekibin parçası olduğunuzu bilmek son derece önemli. Orduda üniformalar, çeşitli ritüeller, geçit törenleri, yürüyüşler, pankartlar vb. bu amaçlara hizmet eder. Hemen hemen aynı faktörler her takım için önemlidir. Semboller, kurumsal marka ve kurumsal renkler, gereçler ve hediyelik eşyalar önemlidir.
Önemli olayların ilişkilendirilebilecekleri kendi görünür düzenlemelerinin olması önemlidir. Günümüzde bir şirketin kendi ürünlerine, ceketlerine, tişörtlerine vb. sahip olması bir norm haline geldi. Ancak şirket içindeki ekibi öne çıkarmak da önemlidir. Çoğu zaman, sürüm sonuçlarına göre tişörtler yayınlıyoruz ve bunlar sürümde yer alan herkese dağıtılıyor. Bazı etkinlikler, ortak kutlamalar veya tüm ekibin katılımıyla yapılan aktiviteler bir diğer önemli motivasyon unsurudur.
Dış niteliklere ek olarak, bir takıma ait olma duygusunu etkileyen başka faktörler de vardır.
Birincisi, herkesin anladığı ve önemine ilişkin bir değerlendirmeyi paylaştığı ortak bir hedefin varlığı. Programcılar genellikle harika bir şey yaptıklarını ve bu harika şeyi ekip olarak birlikte yaptıklarını anlamak isterler.
İkinci olarak, ekibin tüm ekibin bulunduğu ve yalnızca kendisine ait olan bir iletişim alanına sahip olması gerekir (örneğin, messenger'da sohbet, periyodik ekip senkronizasyonları). İş sorunlarına ek olarak, resmi olmayan iletişim, bazen dış olayların tartışılması, konunun aydınlatılması - tüm bunlar bir topluluk ve ekip duygusu yaratır.
Üçüncü olarak, ekip içinde iyi mühendislik uygulamalarının başlatılmasını ve şirkette kabul edilenlerle karşılaştırıldığında standartları yükseltme arzusunu vurgulayacağım. Sektörde kabul gören en iyi yaklaşımların önce ekipte, sonra şirket genelinde tanıtılması, ekibe bir şekilde diğerlerinden önde olduğunu hissetme fırsatı verir, yol gösterir, bu da aidiyet duygusu yaratır. harika bir takıma.
Aidiyet duygusu aynı zamanda ekibin planlama ve yönetime katılımından da etkilenir. Ekip üyeleri proje hedeflerini, çalışma planlarını, ekip standartlarını ve mühendislik uygulamalarını tartışmaya ve yeni çalışanlarla görüşmeye dahil olduklarında, katılım, ortak sahiplenme ve iş üzerinde etki duygusu geliştirirler. İnsanlar, pratikte uyumlu olsalar bile, başkaları tarafından önerilen kararlardan ziyade, kendileri tarafından alınan ve dile getirilen kararları uygulamaya çok daha isteklidirler.
Doğum günleri, yıldönümleri, meslektaşların hayatlarındaki önemli olaylar - ortak bir pizza, ekipten gelen küçük bir hediye, sıcak bir katılım ve minnettarlık duygusu verir. Bazı şirketlerde şirkette 5, 10, 15 yıllık çalışma için küçük anma tabelaları verilmesi adettendir. Bir yandan bunun beni yeni başarılara pek motive ettiğini düşünmüyorum. Ama açıkçası hemen hemen herkes onu unutmadıkları için memnun olacak. Bu, bir gerçeğin varlığının motive etmekten ziyade yokluğunun motivasyonu düşürdüğü durumlardan biridir. Katılıyorum, LinkedIn'in size sabah hatırlatması ve iş yerinizdeki 10. yıl dönümünüzü kutlaması, ancak şirketten tek bir meslektaşın sizi tebrik etmemesi veya hatırlamaması oldukça utanç verici olabilir.
Tabii ki önemli bir nokta takımın kompozisyonundaki değişiklik. Ekipten birinin gelişi veya ayrılışı önceden duyurulsa bile (örneğin, bir şirket veya ekip bülteninde veya bir ekip toplantısında), bunun kimseyi yeni başarılara özellikle motive etmediği açıktır. Ancak güzel bir günde yanınızda yeni birini görürseniz veya eski birini görmezseniz, bu bir sürpriz olabilir ve ayrılırsanız kesinlikle tatsız olabilir. İnsanlar sessizce ortadan kaybolmamalı. Özellikle dağınık bir takımda. Özellikle de işiniz başka bir ofisten aniden ortaya çıkıp ortadan kaybolan bir meslektaşınıza bağlıysa. Bu tür anlar kesinlikle ekibi önceden ayrı ayrı bilgilendirmeye değer.
İngilizce'de adı verilen önemli bir faktör mülkiyet (“Sahip olma” kelimesinin birebir çevirisi anlamını tam olarak yansıtmamaktadır). Bu bir sahiplenme duygusu değil, daha ziyade projeniz için bir sorumluluk duygusudur; kendinizi ürünle ve ürünü kendinizle duygusal olarak ilişkilendirdiğinizde hissettiğiniz duygudur. Bu kabaca “Full Metal Jacket” filmindeki denizcinin duasına karşılık geliyor: “Bu benim tüfeğim. Bunun gibi pek çok tüfek var ama bu benim. Tüfeğim benim en iyi arkadaşımdır. O benim hayatım. Hayatıma sahip olduğum gibi ona da sahip olmayı öğrenmeliyim. Ben olmadan tüfeğim işe yaramaz. Tüfeğim olmadan işe yaramazım. Tüfeğimi doğru dürüst ateşlemeliyim. Beni öldürmeye çalışan düşmandan daha isabetli atış yapmalıyım. O beni vurmadan önce ben onu vurmalıyım. Öyle olsun… ".
Bir kişi bir ürün üzerinde uzun süre çalıştığında, onun yaratımının ve gelişiminin tüm sorumluluğunu üstlenme fırsatına sahip olduğunda, çalışan bir şeyin “yoktan” nasıl doğduğunu, insanların onu nasıl kullandığını gördüğünde bu güçlü duygu ortaya çıkar. Bir proje üzerinde uzun süre birlikte çalışan ürün ekipleri, kısa bir süre için bir araya gelen ve montaj hattı modunda çalışan, bir projeden diğerine geçiş yapan ve tüm projenin tam sorumluluğunu üstlenmeyen ekiplere göre genellikle daha motive ve uyumludurlar. Ürün başından sonuna kadar.
IV. Tanınma ihtiyacı
Nazik bir söz de kediyi memnun eder. Herkes yaptığı işin öneminin ve olumlu değerlendirmesinin farkına vararak motive olur. Programcılarla konuşun, onlara periyodik geri bildirimde bulunun, iyi yapılan bir işi kutlayın. Geniş ve dağınık bir ekibiniz varsa, periyodik toplantılar (bire bir toplantılar da denir) bunun için mükemmeldir; ekip çok küçükse ve yerel olarak birlikte çalışıyorsa, bu fırsat genellikle takvimde özel toplantılar olmadan sağlanır (periyodik olmasına rağmen). hepsi bire kadar Hala gerekli, sadece daha az sıklıkta yapabilirsiniz). Bu konu, menajer-tools.com'daki yöneticilere yönelik podcast'lerde iyi bir şekilde ele alınmaktadır.
Ancak kültürel farklılıkları da akılda tutmakta fayda var. Amerikalı meslektaşlarının aşina olduğu bazı yaklaşımlar Rus yaklaşımlarla her zaman işe yaramayacaktır. Batı ülkelerindeki ekiplerde günlük iletişimde kabul edilen nezaket düzeyi, başlangıçta Rusya'daki programcılara aşırı görünüyor. Rus meslektaşlarının bazı açık sözlülük özellikleri, diğer ülkelerdeki meslektaşları tarafından kabalık olarak algılanabilir. Etnik gruplar arası bir takımda iletişimde bu çok önemlidir; bu konuda çok şey yazıldı; böyle bir takımın yöneticisinin bunu hatırlaması gerekir.
Programcıların bir sprint sırasında geliştirilen özellikleri gösterdiği özellik gösterileri, bu ihtiyacı gerçekleştirmek için iyi bir uygulamadır. Bunun, ekipler arasındaki iletişim kanallarını temizlemek, ürün yöneticilerini ve test uzmanlarını yeni özelliklerle tanıştırmak için mükemmel bir fırsat olmasının yanı sıra, geliştiricilerin çalışmalarının sonuçlarını göstermeleri ve yazarlıklarını belirtmeleri için de iyi bir fırsattır. Bir de topluluk önünde konuşma becerilerinizi geliştirin elbette ki bu asla zararlı değildir.
Ortak ekip buluşmalarında, özellikle seçkin meslektaşlarımızın önemli katkılarını sertifikalarla, anma tabelalarıyla (en azından nazik bir sözle) kutlamak iyi bir fikir olacaktır. İnsanlar genellikle bu tür sertifikalara ve anma işaretlerine çok değer verir, taşınırken bunları yanlarında götürür ve genellikle mümkün olan her şekilde onlarla ilgilenirler.
Ekibin çalışmasına, birikmiş deneyime ve uzmanlığa daha önemli, uzun vadeli bir katkıyı işaretlemek için sıklıkla bir not sistemi kullanılır (yine ordudaki askeri rütbe sistemiyle bir benzetme yapılabilir; tabiliğin sağlanması da bu amaca hizmet etmektedir). Çoğu zaman genç geliştiriciler omuz askılarına yeni yıldızlar kazandırmak için iki kat daha fazla çalışırlar (yani asistan geliştiriciden tam zamanlı geliştiriciye geçiş vb.).
Çalışanlarınızın beklentilerini bilmek çok önemlidir. Bazıları yüksek notla, örneğin mimar olarak atanma fırsatıyla motive olurken, diğerleri ise tam tersine notlara ve unvanlara kayıtsız kalıyor ve maaş artışını şirketten tanınmanın bir işareti olarak görüyor. . İnsanlarla iletişim kurarak ne istediklerini ve beklentilerini anlayın.
Takım adına daha yüksek düzeyde bir güven anlamına gelen bir tanınma gösterisi, daha fazla hareket özgürlüğü veya yeni çalışma alanlarına katılım sağlanmasıyla sağlanabilir. Örneğin, bir programcı belirli bir deneyim kazandıktan ve belirli sonuçlara ulaştıktan sonra, özelliklerini spesifikasyona uygun olarak uygulamanın yanı sıra, yeni şeylerin mimarisi üzerinde de çalışabilir. Veya doğrudan geliştirmeyle ilgili olmayabilecek yeni alanlara katılın - test otomasyonu, en iyi mühendislik uygulamalarının uygulanması, sürüm yönetimine yardımcı olma, konferanslarda konuşma vb.
V. Biliş ve kendini gerçekleştirme ihtiyacı.
Birçok programcı, hayatlarının farklı aşamalarında farklı türde programlama etkinliklerine odaklanır. Bazı insanlar makine öğrenimi yapmayı, yeni veri modelleri geliştirmeyi, iş için birçok bilimsel literatür okumayı ve sıfırdan yeni bir şeyler yaratmayı sever. Bir diğeri, mevcut kodu derinlemesine incelemeniz, günlükleri, yığın izlerini ve ağ captcha'larını günlerce ve haftalarca incelemeniz ve neredeyse hiç yeni kod yazmamanız gereken mevcut bir uygulamada hata ayıklamaya ve desteklemeye daha yakındır.
Her iki süreç de büyük bir entelektüel çaba gerektirir ancak pratik çıktıları farklıdır. Programcıların mevcut çözümleri destekleme konusunda isteksiz olduklarına, daha ziyade yeni çözümler geliştirme konusunda motive olduklarına inanılmaktadır. Bunda bir parça bilgelik var. Öte yandan, birlikte çalıştığım en motive ve birlik içinde çalışan ekip, mevcut bir ürünü desteklemeye, destek ekibi onlarla iletişime geçtikten sonra hataları bulup düzeltmeye kendini adamıştır. Adamlar tam anlamıyla bu iş için yaşadılar ve cumartesi ve pazar günleri dışarı çıkmaya hazırdılar. Bir zamanlar, ya 31 Aralık akşamı ya da 1 Ocak öğleden sonra, başka bir acil ve karmaşık sorunla hevesle uğraşmıştık.
Bu yüksek motivasyona birçok faktör etki etti. Birincisi, sektörde büyük bir isme sahip bir şirketti ve ekip de kendisini bu şirketle ilişkilendirmişti (bkz. “Bağlılık İhtiyacı”). İkincisi onlar son sınırdı, arkalarında kimse yoktu, ürün ekibi yoktu o zamanlar. Onlarla müşteriler arasında iki düzeyde destek vardı, ancak sorun onlara ulaştığında geri çekilecek hiçbir yer yoktu, arkalarında kimse yoktu, tüm şirket onların üzerindeydi (dört genç programcı). Üçüncüsü, bu büyük şirketin çok büyük müşterileri (ülke hükümetleri, otomobil ve havacılık şirketleri vb.) ve birçok ülkede çok büyük ölçekli tesisleri vardı. Sonuç olarak her zaman karmaşık ve ilginç problemler, basit problemler önceki seviyelerin desteğiyle çözüldü. Dördüncüsü, ekibin motivasyonu, etkileşimde bulundukları destek ekibinin profesyonel seviyesinden büyük ölçüde etkileniyordu (çok deneyimli ve teknik açıdan yetenekli mühendisler vardı) ve hazırladıkları verilerin kalitesine, yaptıkları analizlere her zaman güveniyorduk. , vesaire. Beşincisi ve bence en önemli nokta da bu; takım çok gençti, tüm oyuncular kariyerlerinin başındaydı. Büyük ve karmaşık bir ürünü incelemek, kendileri için yeni olan ciddi sorunları yeni bir ortamda çözmekle ilgileniyorlardı, çevredeki ekiplerin, sorunların ve müşterilerin seviyesini profesyonelce eşleştirmeye çalışıyorlardı. Projenin mükemmel bir okul olduğu ortaya çıktı, herkes daha sonra şirkette iyi bir kariyer yaptı ve teknik liderler ve üst düzey yöneticiler oldu, adamlardan biri şu anda Amazon Web Services'te teknik yönetici, diğeri sonunda Google'a geçti ve hepsi içlerinden bazıları bu projeyi hala sıcaklıkla hatırlıyor.
Bu ekip arkalarında 15-20 yıllık tecrübeye sahip programcılardan oluşsaydı motivasyon farklı olurdu. Yaş ve deneyim elbette %100 belirleyici faktörler değildir; hepsi motivasyonun yapısına bağlıdır. Bu özel durumda, genç programcıların bilgi ve gelişim arzusu mükemmel sonuçlar verdi.
Genel olarak daha önce de defalarca belirttiğimiz gibi programcılarınızın beklentilerini bilmeniz, hangisinin faaliyet alanını genişletmek veya değiştirmek istediğini anlamanız ve bu beklentileri dikkate almanız gerekir.
Maslow'un piramidinin ötesinde: sonuçların görünürlüğü, oyunlaştırma ve rekabet, saçmalık yok
Programcıların motivasyonuyla ilgili mutlaka belirtilmesi gereken üç önemli nokta daha var ama onları Maslow'un ihtiyaçlar modeline çekmek çok yapay olur.
Birincisi sonucun görünürlüğü ve yakınlığıdır.
Yazılım geliştirme genellikle bir maratondur. Ar-Ge çalışmalarının sonuçları aylar, bazen yıllar sonra ortaya çıkıyor. Ufkun çok ötesinde bir hedefe gitmek zordur, işin miktarı dehşet vericidir, hedef çok uzaktadır, net değildir ve görünmez, “gece karanlık ve dehşetle doludur.” Ona giden yolu parçalara ayırmak, en yakın ağaca görünür, ulaşılabilir, ana hatları net ve bizden uzak olmayan bir yol yapmak ve bu yakın hedefe gitmek daha iyidir. Birkaç gün veya hafta çabalayıp, sonucu alıp değerlendirmek, sonra yolumuza devam etmek istiyoruz. Bu nedenle iş küçük parçalara bölünmelidir (çevik sprintler bu amaca iyi hizmet eder). Çalışmanın bir kısmını tamamladık - kaydettik, nefes verdik, tartıştık, suçluyu cezalandırdık, masumu ödüllendirdik - bir sonraki döngüye başlayabiliriz.
Bu motivasyon bir dereceye kadar oyuncuların bilgisayar oyunlarını tamamlarken yaşadıklarına benzer: her seviyeyi tamamladıklarında periyodik olarak madalyalar, puanlar, bonuslar alırlar; buna "dopamin motivasyonu" denebilir.
Aynı zamanda sonucun görünürlüğü tam anlamıyla önemlidir. Listedeki kapalı bir özellik yeşile dönmelidir. Kod yazıldıysa, test edildiyse, yayınlandıysa ancak programcının görebileceği görsel durumda bir değişiklik yoksa, kendini eksik hissedecek, tamamlanma duygusu olmayacaktır. Sürüm kontrol sistemimizdeki ekiplerden birinde, her yama birbirini takip eden üç aşamadan geçti; derleme oluşturuldu ve testler geçti, yama kod incelemesinden geçti ve yama birleştirildi. Her aşama görsel olarak yeşil bir onay işareti veya kırmızı çarpı işaretiyle işaretlendi. Geliştiricilerden biri kod incelemesinin çok uzun sürdüğünden şikayet ettiğinde meslektaşlarının hızlanması gerekti, yamalar birkaç gün boyunca askıda kalıyordu. Bu onun için gerçekte neyi değiştirir diye sordum. Sonuçta kod yazıldığında, build derlendiğinde ve testler geçtiğinde, eğer yorum yoksa gönderilen yamaya dikkat etmesine gerek yok. İş arkadaşları bunu kendileri inceleyecek ve onaylayacaklardır (eğer yine yorum yoksa). "Igor, üç yeşil onay işaretimi mümkün olan en kısa sürede almak istiyorum" diye yanıtladı.
İkinci nokta ise oyunlaştırma ve rekabet.
Ürünlerden birini geliştirirken mühendislik ekibimizin, açık kaynaklı ürünlerden birinin topluluğunda önemli bir yer edinerek ilk 3'e girme hedefi vardı. O zamanlar, birinin topluluktaki görünürlüğünü değerlendirmenin nesnel bir yolu yoktu; katılımcı büyük şirketlerin her biri, kendisinin bir numaralı katkıda bulunan kişi olduğunu iddia edebiliyordu (ve periyodik olarak iddia ediyordu), ancak katılımcıların katkısını karşılaştırmanın gerçek bir yolu yoktu. zaman içindeki dinamiklerini kendi aralarında değerlendirmek. Buna göre takım için bazı papağanlarda ölçülebilecek, başarı derecesini değerlendirebilecek vb. bir hedef belirlemenin bir yolu yoktu. Bu sorunu çözmek için ekibimiz, şirketlerin ve bireysel katılımcıların katkısını ölçmek ve görselleştirmek için bir araç geliştirdi. . Motivasyon açısından bakıldığında bunun sadece bir bomba olduğu ortaya çıktı. Kendi ilerlemelerini ve meslektaşları ile rakiplerinin ilerlemesini sürekli izleyenler yalnızca mühendisler ve ekipler değildi. Şirketimizin üst yönetimi ve tüm büyük rakipler de güne stackalytics ile başladı. Her şey çok şeffaf ve görsel hale geldi, herkes ilerlemelerini dikkatle izleyebildi, meslektaşlarıyla karşılaştırabildi vb. Mühendislerin, yöneticilerin ve ekiplerin hedef belirlemesi rahat ve kolay hale geldi.
Herhangi bir niceliksel ölçüm sistemini uygularken ortaya çıkan önemli bir nokta, bunları uyguladığınız anda sistemin otomatik olarak bu niceliksel ölçümlerin gerçekleştirilmesine niteliksel olanların zararına öncelik vermeye çalışmasıdır. Örneğin, tamamlanan kod incelemelerinin sayısı ölçümlerden biri olarak kullanılır. Açıkçası, kod incelemesi farklı şekillerde yapılabilir; testleri kontrol ederek, onu kendi tezgahınızda çalıştırarak, belgeleri kontrol ederek karmaşık bir yamayı kapsamlı bir şekilde incelemek ve kontrol etmek için birkaç saat harcayabilir ve karmanızda artı bir inceleme alabilirsiniz veya Birkaç dakikalık yamalar içinde birkaç düzine körü körüne tıklayın, her birine +1 verin ve artı yirmi karma kazanın. Mühendislerin yamalara o kadar hızlı tıkladıkları ve CI sisteminden otomatik yamalara +1 verdikleri komik durumlar vardı. Daha sonra şakalaştığımız gibi, "git, git, Jenkins." Taahhütler durumunda, kod biçimlendirme araçlarıyla kodu gözden geçiren, yorumları düzenleyen, noktaları virgülle değiştiren ve böylece karmalarını artıran birçok kişi de vardı. Bununla başa çıkmak oldukça basittir: Sağduyulu davranırız ve niceliksel ölçütlere ek olarak temel niteliksel ölçütleri de kullanırız. Ekibin çalışmasının sonuçlarının kullanım derecesi, dışarıdan katkıda bulunanların sayısı, test kapsamı düzeyi, modüllerin ve tüm ürünün kararlılığı, ölçek ve performans testinin sonuçları, çekirdek incelemeyi alan mühendislerin sayısı kayışlar, projelerin temel projeler topluluğuna kabul edilmiş olması, mühendislik sürecinin farklı aşamalarının kriterlerine uygunluk - tüm bunlar ve diğer birçok faktör, basit niceliksel ölçümlerle birlikte değerlendirilmelidir.
Ve son olarak üçüncü nokta: Saçmalık yok.
Geliştiriciler çok akıllı insanlardır ve iş alanlarında son derece mantıklıdırlar. Uzun ve karmaşık mantıksal zincirler oluşturmak için günde 8-10 saat harcıyorlar, böylece bu zincirlerdeki zayıf noktaları anında görebiliyorlar. Bir şey yaparken herkes gibi onlar da bunu neden yaptıklarını, neyin daha iyiye doğru değişeceğini anlamak isterler. Ekibiniz için belirlediğiniz hedeflerin dürüst ve gerçekçi olması son derece önemlidir. Kötü bir fikri bir programlama ekibine satmaya çalışmak kötü bir fikirdir. Bir fikir, eğer ona kendiniz inanmıyorsanız veya aşırı durumlarda, katılmama ve bağlanma gibi içsel bir duruma sahip değilseniz (katılmıyorum ama yapacağım) kötüdür. Bir zamanlar bir şirkette, unsurlarından biri geri bildirim sağlamaya yönelik elektronik bir sistem olan bir motivasyon sistemi uyguladık. Çok para yatırdılar, insanları eğitim için Amerika'ya götürdüler, genel olarak sonuna kadar yatırım yaptılar. Bir keresinde eğitim sonrasında yapılan bir sohbette yöneticilerden biri astlarına şunları söyledi: “Fikir fena değil, işe yarayacak gibi görünüyor. Ben size elektronik geribildirim vermeyeceğim ama siz bunu çalışanlarınıza verin ve onlardan talep edin.” İşte bu, daha fazla hiçbir şey uygulanamaz. Bu fikir elbette hiçbir şeyle sonuçlanmadı.
Kaynak: habr.com