Kaynak kontrol sistemimizden ekibimden temel bir yeterliliğe sahip olmamasını beklemeli miyim?

Şirketim Subversion'dan Git'e yaklaşık üç ay önce geçti. Geçiş öncesinde haftalarca önceden haberimiz vardı. Git'i daha önce (ya da herhangi bir DVCS'den önce) hiç kullanmadığımdan, Pro Git 'i okudum ve biraz zaman harcadım. depolar ve oyun oynar, böylece değiştiğimizde minimum acıyla çalışmaya devam edebilirim. Şimdi varsayılan olarak 'Git adam' değilim.

Birkaç istisna dışında, takımımın çoğu Git'in nasıl çalıştığını bilmiyor. Örneğin, dalları hala kaynak kodun tam kopyaları olarak görüyorlar ve hatta repoyu birden fazla klasöre (dal başına bir tane) klonlayacak kadar ileri gidiyorlar. Genellikle Git'e korkutucu bir kara kutu olarak bakarlar.

Günlük çalışmamızdaki kaynak kontrolün temel niteliği göz önüne alındığında (Git'in bize verdiği saçma güç miktarından bahsetmemeli), onunla belirli bir yeterlilik seviyesine ulaşamayan herhangi bir devin sorumluluk .

Ekibimin en azından Git'in içeride nasıl çalıştığını ve en temel çekme/birleştirme/basma işlemlerinin ötesinde nasıl kullanılacağını anlamalarını beklemeli miyim? Yoksa sadece hiçbir şeyden bir şey mi çıkarıyorum?

48
Şirket aktif olarak teklifte bulunmadı, ancak istendiğinde eğitim için para ödüyorlardı. Bir çiftimiz topun yuvarlanmasını sağlamak için bir kahverengi çanta oturumu hazırlıyoruz.
katma yazar johannes, kaynak
@Caleb Bu övünme değildi. Ne münasebet.
katma yazar johannes, kaynak
@Jeroen Çoğu Xcode kullanıyor, ancak biz Kule lisanslarımız uygun. Birkaçımız iTerm + Oh My Zsh kullanıyoruz.
katma yazar johannes, kaynak
Şirket Git konusunda herhangi bir eğitim verdi mi?
katma yazar yannis, kaynak
Git şubelerinin "temel yeterlilik" in bir parçasıyla nasıl çalıştığını anlama derdim ...
katma yazar Prasad, kaynak
Üretken olmayan herhangi bir dev bir sorumluluktur. Genel olarak üretken olduklarını varsaymak, Git'i bilmek veya bilmemek önemsizdir. Günün sonunda bu sadece başka bir araçtır.
katma yazar MrFox, kaynak
Takım arkadaşlarınız Git'e erişmek için hangi araçları kullanıyor? İyi GUI araçları onu kullanmaya yardımcı olabilir.
katma yazar Sean Bone, kaynak
Eğer takım arkadaşlarınız Git'i anlayamıyorsa, kaynak kontrolünden daha büyük problemleriniz var.
katma yazar Lance Hibbeler, kaynak
Umarım iyi depo yedekleriniz vardır.
katma yazar Evan, kaynak

8 cevap

Profesyonellik, doğal olarak, geliştiricinin, yeni ve yabancı olmasına rağmen (hatta istenmeyen) bile, ekibinin standart araçlarına aşina olmasını zorunlu kılar.

Ancak, yazınızdaki birkaç şey beni durdurur.

Değiştirme işleminden önce haftalarca önceden bildirimde bulunduk.

Haftalar? Kaynak kontrolünü değiştirmek çok önemlidir. Böyle bir değişikliğe yol açan bildirimin ay olması gerekirdi.

Birkaç istisna dışında, ekibimin çoğu Git'in nasıl çalıştığını bilmiyor.

Yani, şirketiniz o zaman çok az kişi, ne zaman anladıysa, bir kaynak kontrol sistemine geçti?

Başka bir bağlam olmadığı sürece, tüm hareketin düşünülmediği sanılıyor (hareket, seçim değil - büyük bir git hayranıyım).

49
katma
Moox ile aynı fikirdeyim. Sadece SVN, CVS veya Performance gibi dağıtılmamış bir SCM'deki bir iş akışından Git'teki eşdeğer bir iş akışına geçmek, en fazla birkaç saatlik bir çalışma meselesidir. Ayrıca, benim deneyimime göre, bir değiştirme teknolojisini kullanıma sunma konusunda sağladığınız kurşun süresi ne kadar uzun olursa, LESS muhtemelen insanların bu konuda hız kazanmasına yardımcı olur. Biri Cuma günü gelip "Pazartesi günü Git'e geçiyoruz" demeliydi.
katma yazar i.raynov, kaynak
"Onlara GIT attı" gibi görünüyor "yerine" Yeni bir revizyon kontrol sistemi başlattı "- GIT, kaynak kontrolü yapan bir programdır. Bu bir kaynak kontrol sistemi değildir - kullanım kılavuzları, eğitim, bakım programları, yaşam döngüsü yönetimi vs. gerektirir. Lütfen bir yedeklemeniz olduğunu söyleyin.
katma yazar RegressForward, kaynak
Kesinlikle kimseden kurtulmak istemiyorum; Sadece depoyu kullanan insanlar için endişeleniyorum çünkü aracı öğrenmek için zaman ayırmadılar. Şirketin geçiş yapmadan önce herkesi hızlandırması için acı çekmesi gerektiğine katılıyorum.
katma yazar johannes, kaynak
Verilen. Hemen hemen hiç kimsenin anlamadığı bir sisteme geçtiler. Geçiş öncesinde eğitim vermek akıllıca olurdu. Ancak Git'i bir haftadan daha az bir pratikle kullanmakta rahat ettim. İşe yarıyormuşum gibi hissetmiyorum , bu yüzden diğerlerinden de pratik yapmalarını beklemenin uygun olup olmadığını merak ediyorum.
katma yazar johannes, kaynak
@JoshuaSmith Standartları veya geliştirme araçlarını değiştirirken, daima "Geride Çocuk Yok" stilinde bir geçiş yapmalısınız. Ekip sadece en yavaş üyesi kadar hızlı hareket edebilir, bu yüzden geçiş gerçekleşmeden önce işlerin mümkün olan en düşük seviyeye kadar net ve açık yapıldığından emin olun. İstediğiniz kadar çok kişi olarak bir yükümlülüğü etiketleyebileceğinizden emin olun, ancak “borçlardan” kurtulmak, özellikle de bir kaynak kontrol aracı kadar önemsiz olan bir şey yüzünden yapmak zor ve dağınık bir şeydir.
katma yazar maple_shaft, kaynak
Git'in nasıl çalıştığını öğrenmek çok önemsiz. Nasıl kullanılacağını öğrenmek kesinlikle bir ay sürmez. Bence basit bir şekilde "Çocuklar, git'i birkaç hafta içinde kullanacağız. Nasıl kullanılacağını öğrenmek için birkaç saat ayırın, çevrimiçi ortamda bir sürü kaynak var.", Fazlasıyla yeterli olurdu.
katma yazar Mike Partridge, kaynak
Sahip olduğun iş akışını bulup yeni VCS'nin sunduğu ilkellerle eşleştiren kimse oldu mu? Alıştığınız komutlara benzeyen komutlarla kendinizi ayağınızdan vurmak oldukça kolaydır ve gerçekten böyle bir şeyi düzenleyen birine ihtiyacınız vardır. Bu değişiklikten sorumlu olan adam nerede?
katma yazar Evan, kaynak

Git'i çalıştığım yerle tanıştırıyoruz ve doğal olarak direniş oldu. Yeni bir proje içindi, şimdi iki depo tutuyoruz.

Sorunun bir kısmı, kullandıkları kişi kendileri için çalıştığında, insanların farklı bir SCM'ye geçmenin faydalarını görmeyecekleri. Birkaç saatlik bir seans için ekibimizle birlikte oturduğumuzda, projelerimizden kullanım durumlarını göstereceğimiz ve Git'in nasıl kolaylaştırdığı konusunda yardımcı oldu. Örneğin, bize yardımcı olan şeyler:

  • Denemeyi teşvik etmek için yerel şubeler
  • Hataları kolayca izlemek için Git bisect
  • sık sık başkalarını rahatsız etmeden taahhüt eder
  • Şubeler arasında hızlı geçiş

Bunların her biri, önceki SCM'mizle karşılaştığımız bir sorunu çözdü ve böylece insanlar Git'i daha fazla takdir edebildi.

Diğer bir şey, insanların gitmelerini ve bunun hakkında kitaplar okumasını bekleyemeyeceğinizdir, çünkü çok az şey olacaktır. Belki işlerini bitirmeleri, başka sorumlulukları veya çeşitli nedenleri olması gerekir.

Bu nedenle, 'Git uzmanı' olarak oturup oturup insanların kullanması için mümkün olduğunca kolay hale getirmeniz gerekiyor. SCM sistemiyle uğraşmak yerine kod yazmak istiyorlar.

Git'in CLI şifreli ve önemsiz problemleri (sen ve ben) insanların çalışmasını engelleyeceğiz. İşte ekibimizde olanlar: (sizce bunlar oldukça yetenekli geliştiricilerdir):

  • Windows'ta SSH ile Git yaygın bir sorundu.
  • İnsanlar birleştirir, birleştirir, ancak birleştirmez. Bu yüzden grafik çok kafa karıştırıcı bir karışıklık olurdu
  • Windows'taki performans sorunu "git durumunu" 15 saniye sürdü
  • Yeni bir dalın nasıl çekileceği çözülemedi. Üzerinde çalıştıkları her şeyden ayrılacak olan bir "git checkout -b" yapacaklardı
  • Tutulmadaki EGit ezici bir menüye sahipti. Herkese ilk başta komut satırını kullanmalarını söyleyerek bitti
  • Önceki öğeye dayanarak, git mergetool birleştirme ve ayarlama
  • "git add" ve "git commit" ve "git push" arasındaki farklar konusunda karıştı.

Hala biraz direnç alıyoruz, ancak insanlar kesinlikle faydalarını görebiliyorlar. Rehberlik için birkaç Git kişisine sahip olmak ve yardım etmeye istekli olmak çok önemlidir. Ayrıca reset/rebase/- amend/etc gibi hoş şeyler öğretmekten de kaçınırdım. çoğu insan Git'i SVN gibi kullanacağından, eğer isterlerse keşfetmelerini sağlamak daha iyidir.

34
katma
@Joshua: İnek işçinizin durumu göz önüne alındığında, muhtemelen uzun zamandan beri bir git kitabı talep etmiş ve günlük işlerimin temel görevlerini yerine getirmek için yeterince okudum. Yine de unutmayalım ki git güreşmek için bir canavardır .
katma yazar Lawrence Johnston, kaynak
Burada kız arkadaşlarımdan daha çok çocuğum var ve teknik kitaplar okudum. Bununla birlikte, idare edebileceğim büyük bir hanım var, iki eski hanımla uğraşmak, uğraşacak bir bahçem, sürekli büyüyen teknik olmayan kitaplardan oluşan bir yığın kitap ve yapmak için eğlenceli ve bir sürü başka şeyler değil. Bu yüzden ya teknik bir kitap ilgimi çekmeli ya da değerli okuma zamanımı (çoğunlukla 120 dakikalık işe gidip gelme) iyi bir romandan geçirmek için çok kötü bir şekilde sunduğu bilgiye ihtiyacım var. Ve yıllar geçtikçe öğrenmeye devam etmek için çoğu devin çok daha az istekli olduğunu öğrendim.
katma yazar Lawrence Johnston, kaynak
@JoshuaSmith, insanların düzenli olarak kitap okumak için zamanlarının olmasını beklerseniz, bir tahminde bulunma tehlikesiyle karşı karşıya kalacağım: Çocuğunuz yok, değil mi?
katma yazar hao, kaynak
@JoshuaSmith, bazı geliştiricilerin yeni teknolojiyi öğrenmeleri için duydukları ilgisizliği gerçekten anlamadım. Daha önce yeteneklerimde “geride” kaldım ve işlerini değiştirmek veya sahip olduğunuzu geliştirmek bile gerçekten sorun yaratıyor.
katma yazar Ronnie, kaynak
Bir geliştirme ekibinin yöneticisiyken, ekibime ruby hakkında bazı kitaplar verdim, onlara okumalarını ve yakutları öğrenmek için zaman ayırmalarını söyledim (saate göre). Hala çok fazla başlangıç ​​direnci vardı, ancak bir jr gördükleri zaman. ekibi Ruby'yi kucakladı ve bir miktar tehdit gördü, gerçekten etkilediler. Sonunda tüm şirket yeni teknolojiyi benimsedi ve genel olarak yeni teknolojilere daha açık hale geldi (şu anda çok fazla mobil yapıyorlar).
katma yazar Ronnie, kaynak
@JoshuaSmith, evet öyle diyebilirim - bir çalışanın kendi zamanında yaptığı herhangi bir şey ekstradır, zorunlu değildir. Bu yüzden anahtarlama satın alın, aracı kullanmaları için yeterli bilgi sağlamanız ya da çalışma sırasında kendileri öğrenmeleri için yeterli zaman vermeniz gerekir (genellikle bu sadece öğle yemeği eğitimi seansı olsa bile eğitim şeklinde sağlanır). Şimdi, eğer çalışanlar serbestse, sözleşmeleri sırasında değil, kendilerini eğitmiş olmaları için bir durum var. Çalışanlar, eğitim gibi belirli faydalar beklerler ve bunlara iş değişikliği uygulanarak strese alınmazlar.
katma yazar gbjbaanb, kaynak
@ ZJR: Başka bir yorumda, şirketin teknik kitap satın alma konusunda sıkıntı yapmadığını söyledim. İnsanların eğitim için kendi paralarını harcamak zorunda kalmasını beklemiyorum. Aynı şekilde, bir dev olarak, 24 saat öğrenme konusunda ısrar ediyorum. Bu soruyu ilk başta sordum, çünkü ekip arkadaşlarının ücretsiz olarak öğrenilebilecek materyallerden yararlanamadığını, saate veya başka türlü göremediklerini görüyorum.
katma yazar johannes, kaynak
@gbjbaanb Yeterince adil. Henüz ağzımı açmadım, bu yüzden belki de bu düşünceleri kendime saklarım. Geri dönüşünüz için teşekkür ederiz.
katma yazar johannes, kaynak
@Matsemann Kimse bir şey okumak için yönetim tarafından istenmez (ve ben patron değilim). Sorum şu ki, profesyonel geliştiricilerin kendi araçlarıyla üretken olmaları için yine de bunu yapmalarını beklemiyor muyum?
katma yazar johannes, kaynak
Çocuklarım var (biri gerçekten, 2. perşembe günü olacak). Zaman bulmayı başardım. Okumayla ilgili yorum, SCM'mizin ne olduğu dışındadır ve mutlaka kitap olmak zorunda değildir. Demek istediğim, devs olarak mesleğimizin sürekli öğrenmeyi talep etmesiydi. Aynı anda ufak tefek şeyler olsa bile kendimden ve ekibimden bunu bekliyorum.
katma yazar johannes, kaynak
@maple_shaft Bu takımdaki arkadaşlarım ile nadiren hayal kırıklığına uğradım (son işim farklı bir hikayeydi). Genellikle buradaki insanlar profesyoneldir ve birlikte çalışmaktan zevk alırlar. Ve evet, kendim ve çevremdekiler için yüksek beklentilerim var. Yine de bu konuda salak değilim. Bu muhtemelen naif, ama hepimiz birbirimizden mükemmellik istersek kaçınılmaz olarak gelişeceğimizi hissediyorum.
katma yazar johannes, kaynak
"İnsanların gitmesini ve kitap okumasını bekleyemezsiniz" dışında, bunların hepsine katılıyorum. İnsanların düzenli bir şekilde okumalarını bekliyorum tamamen (yalnızca SCM'leriyle ilgili değil).
katma yazar johannes, kaynak
@Kyralessa Trende işten ve trenden önce ve yatmadan önce geliştirici kitapları okudum. Bir kızım var...
katma yazar FlipTack, kaynak
@JoshuaSmith İnsanlardan beklentilerin yüksek olduğu görülüyor. Meslektaşlarınızda sık sık hayal kırıklığına uğradığını düşünüyor musunuz?
katma yazar maple_shaft, kaynak
@JoshuaSmith Senle çalışmayı umursamayacağım biri gibi görünüyorsun :)
katma yazar maple_shaft, kaynak
@BillLeeper doğru dedin: saatin üzerinde + onlara kitap verdi . Buradaki bağlamdan, OP'nin etrafındaki insanların boş zamanlarında okumak için belirtilmemiş kitaplar satın almaları gerektiği konusunda ikna olduğu görülüyor.
katma yazar ZJR, kaynak
@JoshuaSmith Beni yanlış anlamayın, bu tür beklentilerim olmasını çok isterdim ve onlara tutulduğumda iyiyim. Sadece iddialarımı, Git'i kurumsal bir ortamda tanıtan (sınırlı da olsa) deneyimlerime dayandırıyorum.
katma yazar Peter Cordes, kaynak
@JoshuaSmith insanlar bu kitapları okumak için para alıyor mu? Patronum bana “teknolojiyi değiştirdiğimizi, önümüzdeki ay boş zamanlarında öğrenmeni bekliyorum” demesini söylesem çok kızardım.
katma yazar pintoch, kaynak

Proficient vs. Git-mania

Temel yeterlilik gibi bir terim, farklı insanlar için farklı anlamlara gelebilir. Birçok insanın git-mania var gibi görünüyor (bunda yanlış bir şey yok). Birçoğumuz, kendimizin ve diğer insanların kaynak kontrolüne olan dikkatsizliği yüzünden gerçekten kötü bir şekilde yakıldık.

Neden Önemlidir (Çok)

Kaynak kontrol araçları kritiktir, çünkü suiistimal sadece bir kişiyi değil bütün takımı yavaşlatabilir. Git kötüye kullanımı, SVN, CVS ve diğer sistemleri kötüye kullanmaktan daha az problemli olmalıdır. Tarihsel olarak, dosyaları kilitleyen sistemlerin beceriksiz kullanımı özellikle sorunluydu ve şirketler, ayrı derleme ekipleri kiraladılar; böylece birisi belaya girdiğinde, yarayı depoya götürebilecek kaynak kontrolünden başka hiçbir şey yapmayan akıcı bir uzman vardı. Bu kısmen git'in arkasında bulduğun tutkuların bir kısmını açıklıyor.

Temel yeterlilik neye benziyor?

Bazı somut kriterler şunlardır:

  • Without reference to documentation:

    • Can add files, commit changes, push and pull updates.
    • Can view status and revision activity.
    • Can branch and merge quickly and without introducing errors.
    • Can use checkout appropriately.
    • Create commit comments that meet the group's criteria for comments.
    • Diff changes between working copy and archive.
  • With documentation:

    • Add users and credentials for local repo.
    • init a local repo.
    • Administer remote repo.
    • Configure ignored files, generate PKI public/private key pairs.
    • Move and delete files.
    • Use bisect to find the change that introduced a particular bug.

Git'e dair katı bir zihinsel model ve yönetilmekte olan kod, hatalardan kaçınmak için çok önemlidir.

Gelişmiş uzmanlık/uzmanlık için ne eklerdiniz?

Akıcı kullanım, geliştiriciler ve muhtemelen ekibinizin diğer bazı üyeleri için esastır. Git gibi araçlar genel gider ve neredeyse otomatik olabilecekleri bir seviyede öğrenilmelidir. Yılda binlerce kez tekrarlanan git komutları kullanılarak üretilen zaman ve dikkat dağınıklığı en aza indirgenmiştir.

Her zaman uzman kullanıcılar olacak ve neredeyse her komutu hemen hemen her seçenekle kullanan ekibinizin bazı üyeleri olacaktır. Benim tavsiyem, ekip üyelerinin, öğrenim için ROI projede başka bir şey yapma değerinin altına düşene kadar öğrenmeyi devam ettirmeleri (ve diğer araçları) teşvik etmeleri ve ana sınırlama mevcut durumdaki mevcut kalemlere ayak uydurmaya devam etmeleridir. sürat.

13
katma

GIT, bir işi yapmak için adil bir araçtır ve en büyük sorunlarından biri, birçok GIT müjdecisinin tüm GIT kullanıcılarının nasıl çalıştığını en iyi noktaları anlayan kaporta uzmanları altında olmasını beklemeleridir. Bu GIT'in en büyük zayıflığı - onu kullanmak için nasıl çalıştığını bilmeniz gerekiyor. GIT ile ilgili tarif yok, GIT uzmanı olmanız veya kullanmamanız bekleniyor. Pro-GIT’i okumanız harika, kuruluşunuzun yatırımını en üst düzeye çıkarmak için bir "goto" GIT guruuna (veya iki) ihtiyacı var, çünkü her geliştirici GIT Guru olmak istemiyor - bu da sorun değil.

Takımın GIT'i nasıl kullandığını bilmesi gerekir (aslında GIT'in nasıl çalıştığını değil, iş akışının kullanması gereken GIT bölümlerini nasıl kullanacaklarını bilmeleri gerekir). Her geliştiriciden, kullandıkları her araçla ilgili her ayrıntıyı bilmesini beklemek zarar vericidir. İş akışınızı destekleyen bir tarif defteriniz yoksa, GIT'i konuşlandırmadınız, geliştiricilere bıraktınız.

Git'e nasıl çalışacağımı bildiğim sürece, GIT'in nasıl çalıştığını bir maymun vermiyorum.

11
katma
Tüm yapmak istediğiniz tek şey, Marka X'te kullandığınız bir iş akışından Git'teki bir iş akışına geçiş yapmak.
katma yazar i.raynov, kaynak
Ve özel bir eğitime ihtiyaç duyuluyor ... ve yine ne Linus hiç kimsenin git tüm teknik özelliklerini benimsemesini beklemiyor, bu yüzden iki emir sınıfı var: porselen ve sıhhi tesisat.
katma yazar ZJR, kaynak

Evet.

“Şirket” in hangi aracı seçtiğine bakılmaksızın, geliştirme ekibinizin aracı nasıl kullanacağını öğrenmek için biraz zaman harcaması gerekir. Hiçbir şey, bir araçtan korkan veya görmezden gelen bir grup geliştiriciden daha fazla üretkenlik yaratamaz. Eğer yanlış kullanıyorlarsa veya ona karşı çalışıyorlarsa, sorunlar ortaya çıkacak ve erkeğe giderken, pisliği temizlemekle görevlendirileceksiniz.

Git, birçokları için zorlu bir geçiştir, bu nedenle zorunlu bir oturma oturumu eğitim seansı olabilir. Bu, insanların sahip olduğu sorunların çoğunu gidermeye yardımcı olmalıdır.

10
katma
Şirketler, özellikle büyük şirketler, bazen teknolojiyi zorlamalıdır. Tt, aynı zamanda, bir kuruluşta zaten ilk hareketi yapan ve aracı tamamen kullanan bir ekip olabilir.
katma yazar Ronnie, kaynak
"Hiçbir şey, bir araçtan korkan veya cahil olmayan bir grup geliştiriciden daha fazla üretkenlik yaratamaz." Bu nedenle, muhtemelen bir şirket, ekibin eğitilmediği ve anlamadığı bir araçla yaşamaya deli olur.
katma yazar Jaydee, kaynak

Git'i sadece kişisel bir ortamda kullandım, profesyonel olarak değil, sahip olduğu gücü ve merkezi olmayan bir kaynak kontrolü fikrini sevsem de önemli sorunları var. Git sızdıran soyutlama var ve basit şeyler yapmak için birden fazla komut gerekiyor (örneğin bir değişiklik yapmak için: git add, git commit, sonra git push). Ayrıca belgelerin bir kısmı rebase komut açıklamasında olduğu gibi eksik ve/veya kafa karıştırıcı ... "Lokal portu yerel güncellenen yukarı akış kafasına atar". Bunun ne anlama geldiğine dair hiçbir fikrim yok ve şu anda kararları hareket ettirebileceğini ve tarihini onunla yeniden yazabileceğini bilmeme rağmen (başka bir sıkıntı ... neden bunu yapmana izin verilmeli? ??) açıklama. Takımınızla ilgili bazı okumalar ve sizin tarafınızdan verilen bazı eğitimlerin daha iyi olduğunu düşünüyorum.

3
katma

Eğitim ve anlayış minimum gereksinimlerdir. Sorumlu biri, ekibinizin nasıl kullanacağı konusunda bir plan olduğundan emin olmalıydı. Kurallar olmadan yeni bir programlama dili kabul etmezsiniz. Sürücünün eğitimi, yolun belirlenmiş kuralları dahil edildiğinde çok daha etkilidir.

2
katma

Yok hayır; Aşağıdakileri beklemenin mantıklı olduğunu düşünüyorum:

  1. Günlük işler (taahhüt, itme, çekme, dallanma, birleştirme, ikiye ayırma vb.) elle tutmadan yapın.
  2. Tekrarlanan talimatlar olmadan rutin olmayan işler yapın. (Birkaç tekrarlama tamam - Birisinin ismi gerçekten yapışmadan 2-3 kez önce buluşmalıyım.)

Eğer # 1'i yapamazlarsa, katılımın eğitim kısmı muhtemelen yetersizdi. # 2 yapamıyorlarsa, önce çok üzülmeden önce her şeyi yeterince net bir şekilde açıkladığınızdan emin olun.

1
katma
@JimmyHoffa güncellendi.
katma yazar user1306322, kaynak
@JimmyHoffa Cevabım : "Hayır, işte makul şekilde beklemeniz gereken bir minimum"; Sadece bu kesin sözlerle söylemedim.
katma yazar user1306322, kaynak
@JimmyHoffa Sanırım cevabımı yanlış anladınız. Günlük/rutin görevlerinde yetkin olmaları ve diğer işleri oldukça hızlı bir şekilde almaları gerekir. Birkaç muhtemel sebep tanımladım, ancak herhangi bir düzeltici işlem yapmaktan uzak durmaya çalıştım. Satır aralarını okuyorsun ve gördüğün buysa, fazladan değer veriyorsun.
katma yazar user1306322, kaynak
Oh, senin bir "evet" olduğunu ima ettiğini düşündüm, bu önsözü içine koy ve soruyu ele alıyor, yoksa sadece mantıklı gelmiyor
katma yazar Jimmy Hoffa, kaynak
Hayır, soru şu: "Ekibimin temel bir uzmanlık düzeyinden daha fazlasına sahip olmasını beklemeli miyim ..." ve "Evet, işte neden" dedin ya da "Hayır, işte neden" dedin. Bir soruyu bir soruyla cevapladın. Cevabınızın düşünceli olduğunu ve içeriğin yararlı olduğunu takdir ediyorum ama yine de soruyu evet ya da hayır olarak cevaplamalısınız ve neden evet ya da hayır olduğunu düşündüğünüzü desteklemeye çalışmalısınız ... O zaman cevabınızı aşağıda bulabilirsiniz. . Mantıklı olmak?
katma yazar Jimmy Hoffa, kaynak
Bu gerçekten sorunun cevabı değil; Soru, yeterliliklerini nasıl geliştireceği değil, başkalarından ne düzeyde bir yeterlilik beklemesi gerektiği idi. @MyName ile yorum yaparken bana konuyu yanıtladığınızı düzelttiğinizi bildirdiğinizde aşağı oy kullanacağım.
katma yazar Jimmy Hoffa, kaynak