Ekipte yavaş ve tanımsız bir meslektaşı ile nasıl başa çıkabilirim? [kapalı]

Yeni bir proje üzerinde çalışıyorum. Proje şöyle çalışır: Son kullanıcı, bir bağlantı kullanarak bir webapp'a erişebilir ve ağına birden fazla sistem ekleyebilir ve bu belirli sistem ayrıntılarını yönetebilir. Benim bölümüm ön ucu ve python ile yapılan web sunucusu ile ilgilidir. Python'um aslında tamamen c & c ++ 'da yapılan başka bir proje ile iletişim kuruyor. C / c ++ projesi tüm işlevleri yerine getiren ana uygulama. Python'um kullanıcıya istek gönderir ve kullanıcıdan gelen cevabı gösterir.

İşime çok aşinayım ve yakında bitireceğim. Çünkü bu fazla çalışmadı. Ve ben çalışmayı seven bir insanım. Çoğu zaman ofiste geçiriyorum ve yalnızca uykum geldiğinde eve gidiyorum.

C / c ++ uygulaması, 5 yıldan fazla deneyime sahip ve benden çok daha hızlı şeyler yapabilen başka bir meslektaşı tarafından yönetiliyor, ancak bunu asla yapmıyor. Yapmaktan hoşlanmıyor olabilir. Python'um onunla iletişim kurduğunda veya yanlış değerler verdiğinde uygulaması sık sık çöküyor. Hatalarla dolu. Uygulamam ona bağlı olduğundan, bunu yapmakta zorlanıyorum. Hataları düzeltmek yerine, işimi yavaşlatmamı istedi. Yöneticime işimin çok zamana ihtiyacı olduğunu söylememi istedi. Yöneticiyi kandırmamı istiyor ve hatta onun gibi yavaş çalışmamı bile zorluyor.

Proje toplantısı sırasında, yönetici ona böcekleri sorduğunda, her şeyi düzelttiğini ve iyi çalıştığını söylüyor. Meslektaşım olduğu için yöneticiye hiçbir şey anlatamadım. Meslektaşlarımla müdürümden daha iyi bir ilişkim olması gerektiği açık, çünkü çoğu zaman müdürle değil meslektaşlarımızla birlikte olacağız.

Yöneticiye bu konuda hiçbir şey söyleyemem, çünkü yönetici nedenini sorarsa, kendisinden şikayetçiye şikayetçi olduğumu düşünebilir. Ve toplantıda yalan söylemeye devam ediyor. Ve hatayı yavaşça düzelttiği için işimi bile yavaşlatıyor. Şimdi uygulamamın ön kısmı üzerinde çalışmayı ve bitirmeyi düşündüm, böylece projesini stabil hale getirebildi. Şimdi, yöneticime ön uç bölümümün çok fazla çalışma gerektirdiğini ve daha fazla zamana ihtiyacım olduğunu, sadece projeyi aşağı sürükleyebileceğini söylememi istiyor. Ve üzücü olan şu ki asıl menajerimiz ABD'ye gitti, bu yüzden geçici bir menajerimiz var ve bu adam proje hakkında çok fazla şey bilmiyor, bu yüzden c, c ++ onu kandırıyor.

Birisi bana bununla nasıl başa çıkacağımı önerebilir mi? Projeyi yakında bitirmek istedim. Onunla iyi bir ilişki sürdürerek bile çalışmasını nasıl sağlayabilirim?

Yorumlara verilen cevaplar:

Şirketi kasten yanlış yönlendiriyorsa, onu yönetime bildirmelisiniz.

Bu şirkette yeniyim ve diğer adam yıllardır orada. Ve meslektaşlarımı tanımaya yeni başladım. Doğrudan gidip ona şikayet edersem, diğer meslektaşlarımla iyi ilişkiler kurabileceğimi sanmıyorum. Onları yanlış yönlendirecek gücü bile var. Onun kötü bir adam olduğunu söylemiyorum, işi yapabilir, ama yapmıyor.

Şirketinizde herhangi bir hata izleme sistemi yok mu?

İşte gerçek hata takip sistemi yok. Şirket, projeyi en kısa sürede bitirmeye çalışır ve QA'ya verir. Ve daha sonra KG tarafından bildirilen hataları giderir.

Bu yüzden şirketler çalışanlara stok / seçenek ya da bir çeşit mülkiyet vermelidirler. Bu şekilde kelimenin tam anlamıyla adama "Bana parasal büyümeye mal oluyorsun ... para kazanmak istemez misin?" Diyebilirsin.

Şirket bana 2500 pay vermiş oldukları hisse opsiyonlarına sahip, çoğunlukla o da biraz daha fazla olurdu.

Kıdem, şüphenin bir miktar faydasını hak eder. Gerçekten önce onunla konuşmanız ve sorunu anlamaya çalışmanız gerekir. Derinliğinin dışında olabilir, ona yardım edebilirsin, bilmediğin değişkenler kolayca olabilir. Şimdi zor olabilir, ancak silahı atlayarak durumu daha da kötüleştirebilirsiniz.

Bunu bile yapıyorum, ilk önce uygulaması bir kerede birden fazla isteği yerine getirmiyordu, kendisine gönderilen istekleri yerine getirmek için bir kuyruk kullanıyordu. Ona bazı fikirlerimi bile önerdim. Zaten bu fikirlere sahip olduğunu ve bunları hayata geçireceğini söyledi. Onun açıklamaları: “Her şey yapmak için belli bir zaman gerektirir ve bu iki yıl içinde tamamlanması gerekebilecek bir proje ve bunu iki ay içinde bitirmemiz isteniyor”. Bu hata nedeniyle ilk birkaç hafta boyunca kodlamada zorlanıyordum. Ama şimdi o düzeltti. Ancak bir kullanıcı istekleri için tek bir kuyruk kullanıyor ve bu, bir kerede bir isteği işlediği için uygulamayı yavaşlatıyor.

QA bu süre boyunca ne yapıyor? Neden projenin durumunu raporlamıyor / onaylamıyorlar?

Yönetici, KG'ye ne zaman vereceğine karar veren kişidir. Şu an itibariyle, henüz QA'ya vermedi. Bu ay sonuna kadar vermemiz gerektiğini söyledi.

Kötü bir durumdasın, ayakkabılarının içinde olmak istemem. Meslektaşınızla çatışmaya girmeden halledebilmeniz pek mümkün değil.

Yapacağım şey bu:

• Suçtaki ortağı olma. Projenizin ya da projesinin durumu hakkında yalan söylemeyi reddetmek.

• Uygulamanıza (gerekirse boş zamanlarınızda) hata bildirimi uygulayın, böylece tüm hatalar e-posta yoluyla iş arkadaşlarınıza ve yöneticinize gönderilir. Hata, uygulamasından kaynaklanıyorsa, e-postada görünür olmasını sağlayın (e-posta konusuna [XYZ APP BUG] veya benzeri bir şey koyun).

• Hata veritabanını koru (hataları e-postayla göndermenin yanı sıra). Asıl amacının böceklerinizi takip etmek olduğunu, aslında çoğunlukla onun böceklerini takip edeceğinizi söyleyebilirsiniz . Diğer şeylerin yanı sıra, belirli bir hatayı gidermenin ne kadar sürdüğünü izlemesi gerekir.

• Uygulamasıyla tüm süreçler arası iletişimi testlerle kaptırın ("bunu size gönderdiğimde bana bunu geri vermelisiniz" stili). Her gün bu testleri yapan bir cron görevi kurabilirsiniz ve başarısız olursa, herkese e-posta gönderilir.

Temel olarak, onunla böcekler hakkında tartışarak zamanınızı boşa harcamamaya çalışın ve bunun yerine işinize odaklanın. Uygulaması bozulursa ve uygulamanız üzerinde çalışamazsanız ve yöneticiniz onunla hiçbir şey yapmazsa - bu bir yönetim sorunudur ve hata veritabanı, e-postalar ve test raporları ile kaplıdır.

Ancak, dikkat et ve onu küçümseme. Onun gibi uzun süre gevşeyen bir kandırmaca ya da iki kolunu yukarı kaldırabilir. Tüm takımı size veya başka şeylere karşı döndürebilir, ancak bu sizin özel durumunuza bağlıdır ve bu sorunun kapsamı dışında kalıyor.

Tartışmalı bir manzaraya atıyorum: Uyanık kalabilmeniz için saatlerce çalıştığınızı söylüyorsunuz. Belki de "Beni kötü görünüyorsun ve aslında istediğim kadar saat çalışıyorum" demekte özellikle haksızlık ediyor. Belki oradaydı ve bunu yaptı ve belki de yandı. Söz veriyorum, devam edersen yapacaksın.

Bir gece onunla bir şeyler içmek için dışarı çıkın ve profesyonelinizi temel alacak daha iyi bir kişisel ilişki kuramayacağınızı görün. Belki biraz daha koymaya karar verdiğinde ve biraz daha az koymaya karar verdiğinde, ikiniz birlikte daha iyi çalışabilirsiniz.

Yerinde olsam, bu "işim, işin" tutumuna da çok dikkat ederdim. İkiniz arasında, oraya çıkacak bir ürününüz var ve bu ürün için iyi olamaz, bu da şirket veya müşteri için iyi değildir ve her ikinizin de çalışması için para ödersiniz .

Ancak, yöneticinizle olan ilişkinizin önemini tekrar gözden geçirmeniz ve meslektaşınıza güvenmeniz konusunda dikkatli olmanız gerektiğine dair diğer görüşlere katılıyorum. Sadece şunu söylüyorum belki, sadece belki, kendi davranışlarına ve onunkilere bakmalısın.

Kayıtları tutmak. Onunla iletişim kurarken, ondan ne zaman yapmasını istediğini ve ne zaman (ne zaman) yaptığını sorduğun zaman her hatayı belgeleyin. Bu durumla başa çıkmanın tek yolu bu. Bu yüzden menajeriniz neden işlerin ilerlemiyor olduğunu sormaya başladığında, bir beyaz veya kötü meslektaşı olarak görülmeden açıkça gösterebilirsiniz.

Yükseltilmemiş başka bir olasılığı belirtmek isterim. İşini yavaşlatmanı istediğini söylüyorsun. Kelimenin tam anlamıyla "daha az saat çalış" ya da "bazı testler yaz, daha fazla test et, bazı belgeler yaz" ve "seni yavaşlatacağını düşündüğün" şeyler söylediğini mi demek istiyorsun? Günde 16 saat boyunca kod yazarken yeni insanların çalıştığını gördüm ve daha sonra, aslında geçersiz parametreler geçerken aradıkları koddaki hatalardan şikayet ediyorlar, dönüş değerlerini kontrol etmiyorlar vb. İş arkadaşınızın bunları düşündüğünü ekleyemem.

Bir dahaki sefere bir toplantıya katılacağınızı ve tüm kodunun yolunda olduğunu söyler, "ah, güzel, size bir saat önce söylediğim şeyi, çalışma günü olmayan bir tarihle XYZ'i aradığımda patladığı yeri" şimdi sabittir? " Üç şeyden biri olacak:

• Yalan söyleyecek ve böyle bir sorun olmadığını söyleyeceksiniz, “Öyle var! Bunu tartıştık! Size e-postayla gönderdim!” Diyeceksiniz. ve her şey bir yöneticinin dikkatine gelecek
• Aslında, kodunda bir hata olmadığını, kodunda bir hata olduğunu söyleyecektir, çünkü sadece çalışma günlerini geçmen gerekiyordu ve yakında ne düşündüğünü ama söylemediğini öğreneceksin.
• "Hayır, az önce bana bahsettiğim şeyle bugün ilgileneceğim, ama her şey yolunda" diyecek. Bunu söylerse, şimdilik ona teşekkür et.

Uzun hızlı kodlama günlerinizin iyi kod üretmediğini öğrenebilirsiniz ve birileri (belki de yöneticiniz) diğer geliştiricinin size sorunun ne olduğunu size açıklamasını sağlayabilir. Ya da onun rahat pozisyonunu koruman için seni kötü gösterecek yalancı bir yılanla çalıştığını öğrenebilirsin. Şeyleri açıklığa sokmak gerçekten bunu daha da kötüleştiremez. Veya ondan, politikaya kapılmadan dayanabilmeniz için yeterli harekete sahip olabilirsiniz.

Sahip olduğunuz politik bir problem. İlk önce yöneticinizin görüşü düşündüğünüzden çok, çok daha önemlidir. Bu adam gecikmelerden seni suçluyor ve sen de ona izin veriyorsun. Birisi otobüsün altına atılırsa kovulacak olan sensin. Müdürün bildiği kadarıyla, zamanında işi yapamayan kişi sensin .

Hata izleme, e-posta vb. Yoluyla yapabileceğiniz herhangi bir şekilde kendinizi koruyun, ancak bu onun gecikmesi değil gibi davranmaya devam etmeyin. Patrona asla sahte bir durum raporu verme, seni ısırmaya geri dönecek. Patrona, kodunun çalışmadığı durumlarda yaşadığınız (ve kanıtı gösterdiğiniz) hakkındaki gerçekleri söyleyin.

Sizden gevşemesini istemediği için kötü görünmemesini isteyen kişi bir yılandır (bu yılan topluluğuna bir hakarettir (ince Firefly referansı), orada bulunan tüm gerçek yılanlar için üzgünüm). Seni onun yerine otobüse atmak için her şeyi yapar. Ona güvenme.

İlk ve en önemli:

Meslektaşım olduğu için yöneticiye hiçbir şey anlatamadım.

İş arkadaşınız yüzüne yalan söylese bile, yöneticinizin gerçeği bildiğinden emin olabilirsiniz ve yapmalısınız. Odada 3'ünüzle bir toplantıda bir şey söylemek istemiyorsanız, bu tamamen anlaşılabilir bir durumdur. Ancak, en azından yöneticinizi (asıl, yalnızca geçici değil) kenara çekmeli ve çalışmanızın neredeyse bittiğini ve tüm uygulamanın başbakanlığa hazır olmadan önce diğer geliştiricinin sonundaki hata düzeltmelerini beklediğini söylemelisiniz. . İş arkadaşınızı yalan söylemekle suçlamayın, orada oturmayın ve patronunuzun eksik bilgilerle çalışmasına izin verin.

Durumlarını dürüstçe bildir. Çalışmanız başka bir geliştiricinin ucunda böcekler tarafından tutuluyorsa, C / C ++ 'da böcek bulduğunuzu ve bunları bildirdiğinizi (lütfen kağıt iz bırakan bir belge türü kullandığınızı söyleyin) belgeleyin.

Bu arada, devam et ve işini tamamla ve işini bitirdiğinde patronuna bildir. Yöneticiniz neden projenin geri kalanının hala çalışmadığını ve çalıştığını bilmek istiyorsa, onu diğer geliştiriciye yönlendirebilir ve belki de bunun çok karmaşık / büyük / çok fazla test gerektirdiğini / diğer geliştiricilerin çok fazla olduğunu söyleyebilirsiniz. meşgul / vb. Eğer C / C ++ 'ı biliyorsanız, ana uygulama mantığına yardımcı olabilirsiniz. Evet, diğer adamın işini yapacaksın, ama çalışanın çok çalıştığını ve üretken olduğunu ve diğerinin de patronun için daha değerli olmasından bahsetmediğini açıkça gösteriyor. Diğer geliştiriciye bazı şeyleri hızlandırma ve daha hızlı yapma konusunda baskı bile verebilir.

İş yerinde çok sayıda sorun var. Farkında olmak:

1. Diğer insanların motivasyonları hakkında varsayımlarda bulunuyorsunuz
2. Siz düşünceleri gerçeklerle renklendiriyorsunuz.
3. Yabancılar (başkası) tarihin farkında değiller ve meslektaşınızla ilgili hayal kırıklığınızın farkında değiller.
4. "Gotcha" oyununu oynuyorsanız, çocukça görünebilirsiniz. Meslektaşınız muhtemelen daha iyi oynayabilir - sonuçta hala bir işi var değil mi?

Bu nedenle, projenizin durumunu sunarken:

1. Diğer kişiden bahsetme.
2. Hataları veya kod ile ilgili sorunları bildirirken - geliştiriciyi değil. "FooBar () yöntemine yapılan çağrı, 2 döndürülüyorsa 1 döndürüyor" deyin. O zaman herhangi bir sorun kişisel bir saldırı değil, sadece kod hakkında konuşuyorsunuz, insanlardan değil.
3. kanıtladığın gerçeklere sadık kal.
4. Meslektaşınız savunma veya düşmanca davranırsa, sorular sorun. "Neden yapmam gerektiğini düşündüğünü anlamıyorum _ "
5. Sosyal olaylara veya yanlış fikirlere karşı haksız olun. Kişisel saldırı almamış gibi davran.
6. Herhangi bir statü toplantısından önceki gece çok uyuyun, böylece zihinsel olarak çeviksiniz.
7. Belge, belge, belge.
8. Bu adamdan ilginç bir problemde size yardım etmesini istemekten çekinmeyin, ona saygı duyduğunuzu hissederse size götürebilir. Bu ilişki kurma ile ilgili. ( bunun emme olmadığını unutmayın - bu başka bir şeydir)
9. Gerekirse gitmeye hazır olun, böylece ihtiyacınız yok ya da duygusal olarak kapana kısılmış olursunuz. Bu, aklınızı toplantılarda tutmanıza yardımcı olacaktır.

"Çalışmayı seven bir insanım. Çoğu zaman ofiste geçiriyorum ve yalnızca uykum geldiğinde eve gidiyorum."

Bu sağlıklı değildir ve kaçınılmaz tükenme nedeniyle yıllarca kaçabilme noktasına gelmediğiniz sürece çalışma arkadaşlarınızdan beklenemezsiniz. (Şirkette>% 10 veya 200 $ 'ın üstünde bir şey gibi bir şey). Çok çabuk gelişebileceği bir noktaya gelmek için uzmanlığı sürdürmek zaman alır. Zamanınızın bir kısmı uzmanlık geliştirme konusuna ayrılmalıdır.

"C / c ++ projesi, tüm işlevleri yerine getiren ana uygulama. Python'um, kullanıcıya isteğini gönderiyor ve kullanıcıdan gelen yanıtı görüntülüyor. ... Yapmaktan hoşlanmıyor olabilir."

Python, C / C ++ 'dan daha çevik bir dildir. Onun uygulaması tüm işlevleri içeriyor gibi görünüyor; Uygulamanız sadece kullanıcı arayüzü. Olmamasından daha büyük olasılıkla bunlar zorluk bakımından eşit değildir. Hızla kod üretmiyor olabilir; ancak kalite kodlaması miktar kodlamasından çok daha iyidir. Çalışmak istediği / beklendiği saatlerde ne kadar hızlı kodlayabileceği konusunda gerçekçi olmayan beklentilere sahip olabilirsiniz (tipik olarak ~ 40 saat hafta; ve yıllarca orada olsaydı, muhtemelen başkalarını yönetmek veya daha eskileri korumaya yardımcı olmak gibi başka görevler üstlenir). çalışma haftasının önemli bir bölümünü kaplayan projeler).

Onun için yalan söyleme; ama yine onu da eleştirmeyin. Sisteminin nasıl harika olduğu hakkında konuşun; bitene kadar daha fazla çalışmaya ihtiyacı var. Yöneticinize adlarını vermeden / suçlama atamadan doğru bir durum güncellemesi yapın. Sisteminin, uyması gereken aynı standarda uygun, sahte bir versiyonunu yazın. Otomatik bir test takımıyla sisteminizin takma sisteminizle mükemmel şekilde çalıştığından emin olun. Sonra sisteminiz bitebilir (örn., Canlı sistem hala buggy olsa bile)

Ardından, sistemi için dışarıdan çağrılan ve üzerinde anlaşılan standartlara uyan otomatik bir test takımı yazabilirsiniz. Örneğin, Foo'dan (1,2,3) daha fazla test "Bar 4 5 6" nın yanıtını verir. Bu, hataları tespit etmesine ve gelişimi boyunca hız kazanmasına yardımcı olabilir (ve koduyla uğraşması gerekmez). Bu şeyler yapıldıktan sonra, başka bir projeye / göreve geçebileceksiniz (örneğin, C / C ++ bölümlerinde ona yardımcı olmak gibi).

Diğerlerinin de belirttiği gibi, profesyonel davranmak, uzun vadeli kariyeriniz için en önemli şeydir. Ve dürüst olmak gerekirse, profesyonelce davrandığınız sürece, etrafınızdakiler nasıl olursa olsun, oldukça iyi durumda olacaksınız.

Bu durumda, dikkate almanız gereken birkaç husus vardır.

Öncelikle, belirtilen son tarihe kadar, istenen şartnamelere göre çalışan programınızdan sorumlu olduğunuzu anlamanız gerekir. Programınız başka birinin programı ile birlikte çalışıyorsa, aynı zamanda başka bir programın da aynı son tarihe kadar çalıştığından emin olmaktan siz sorumlusunuz. Bunu farklı bir şekilde ifade etmek için: Eğer diğer kişi son teslim tarihini özlüyorsa, o zaman projenin kendi bölümünüz zamanında olsa bile son tarihinizi kaçırdınız. Yönetim açısından buna girdilere sahip olmak denir .

Meslektaşınız bir toplantıda programının hatalarının giderildiğini beyan ettiğinde, onu derhal yöneticiye yanlış olarak ilan edemeyeceğinizi (yöneticiniz "iş arkadaşınızı otobüse atmak" olarak görür; çok kötü bir kariyer hareketi). Diğerleri ise, projenin asıl durumunu yöneticiye bildirmemin profesyonelce olmadığını belirtti. Her iki taraf da tamamen doğru.

Bu yüzden yöneticisinin önünde meslektaşı yalanlamak kötü ve aynı zamanda etmek kötüyse değil ona karşı, o zaman ne yapacağız?

Bu sorunun cevabı aslında oldukça basit: Yöneticinizle görüşmeden önce meslektaşınızla iyi konuşmanız ve yaklaşan toplantıda yöneticiye, yaşadığınız sorunları anlatmanız gerektiğini bildirmeleri gerekir. programlarını ve projenin tarafını zamanında teslim etme yeteneğini ve yaşadıkları sorunları çözmelerine yardımcı olmak için yapabileceğin bir şey olup olmadığını etkilediğini. Bu sohbeti , yöneticiye anlatacağınız toplantıdan en az iki gün önce ve tercihen tam bir hafta önceden yapmanız gerekir.

Çoğu durumda, meslektaşınıza programlarını belirli bir toplantıda risk olarak listelemek zorunda kalacağınızı söylemeleri, yaşadıkları sorunları çözmeleri için onları motive edeceklerini ve asla yöneticinizle hiç konuşmak zorunda kalmayacağınızı söylemek . Sorunların daha çok program odaklı olduğu yerlerde, meslektaşım sizinle sık sık hemfikir olur ve ikiniz birlikte yöneticiye gidebilirsiniz.

Asla benim için işleri çabucak düzeltemeyen bir meslektaşım olmadı ya da bu şekilde ifade edildiğinde endişelerime katılıyorum. Ancak bu gerçekleşirse, meslektaşınıza önceden uyarı vererek, müdürle konuşurken hala daha iyi bir konumda olacaksınız. Meslektaşınızla konuştuğunuz ve kendi başınıza bir çözüm bulmaya çalıştığınız ve bu toplantıda konuyu gündeme getirmeniz gerektiği konusunda onları önceden uyardığınızdan, meslektaşınız yaptıklarında şaşırmayacak ve yönetici kazanacak Sadece suçu değiştirmeye çalıştığını sanmıyorum.

Lütfen endişelerinizi meslektaşınıza veya yöneticinize ilettiğinizde, endişelerinizin meslektaşınızın kötü veriler döndüren programı (veya başka bir şey yapıyorsa) hakkında olduğunu; bunlar doğrulanabilir ve düzeltilebilir ölçülebilir şeylerdir. Endişeleriniz meslektaşınızın yavaş ya da belirsiz olması ile ilgili değildir ; bunlar gerçek veya gerçek olmayan ve patronun önünde bir toplantıya sokularak düzeltilmesi muhtemel olmayan ölçülebilir şeyler değildir.

Hangi hata takip sistemini kullanıyorsunuz? En azından böceklerin zaman içinde düzelmediklerini vurgulamak isterdim. Kodunuzun diğer katmandan girmeyi beklediği yerde, gecikmeler proje izleme belgelerinde vurgulanmalıdır. Bu da gerçekleşmiyor mu?

Bana burada yetersiz proje yönetimi varmış gibi geliyor. A) sizi etkileyen hataları izlemek ve b) tartışmaları yazılı olarak takip etmek gerekir.

Meslektaşınız, sizden isteksizliğini karşılamak için gelişim zamanınızı şişirmenizi istememelidir. Bir noktada, bu menajerin ile ele alınması gereken bir şeydir. İşler dururken, meslektaşınızı koruyorsunuz ve bu neredeyse kesinlikle geri tepecektir.

Bir meslektaşınla bir araya gelmenin yanlış bir tarafı yok, ama birinin patronuna her gün yalan söylemeni beklemesi gerekiyor. Ona bir insan olarak saygı gösteremedim ve bu kişiyi sıradan bir tanıdık olarak görmek istememiştim. Düşman olmak istiyor, devam et.

Ön uç yüzünden uygulama katmanındaki gecikmeleri nasıl tartışabilirsin? Bu yüzden bunu yaptın ki onlar ayrı olsunlar. Sırada ne var, birileri mobil ön uç oluşturmak istediğinden dolayı daha fazla gecikme yaşadı?

İşini tamamla. Uygulamasında başarısızlıkla karşılaştığınız sorunları belgeleyin. Ve sonra eve gitmek! Uykulu olup olmaman umrumda değil. Sahip olmaya değer bazı arkadaşlar bulun.

RC Martin (Bob Amca) tarafından "The Clean Coder" yazısını okudum. Kitabın asıl amacı, programcıların genel olarak fazla saygı duymadıkları, çünkü profesyonel davranmıyorlar . Bu, esas olarak projenin durumu hakkında yönetim ile etkili bir şekilde iletişim kurmamaları anlamına gelir.

Yalan söylemek kesinlikle çok çok kötü bir iletişim şeklidir. Meslektaşın çok profesyonelce davranıyor ve sen de öyle. Siz ikiniz programcıların algılarını geliştirmek için hiçbir şey yapmıyorsunuz.

Hemen yönetime gitmenizi tavsiye ederim. Ancak geçmişte çok dürüst olduğum için (bazı alakasız durumlarda) başım belaya girdi, bu yüzden tavsiyeme uymanız gerektiğinden emin değilim. Ayrıca, çoğu kişinin belirttiği gibi, belki de durum hakkındaki algınız, düşündüğünüz kadar doğru değildir.

Kod tabanına aşina değilseniz, başka bir projenin göreceli çabasını ve karmaşıklığını tahmin etmek zor ve mantıksızdır. Kodunun hataya açık olduğunu söylüyorsunuz, ancak geri kalanların tümü ile çok yüksek bir soyutlama seviyesinde harika bir formda olabilir ... Sorun şu ki, önünüzün ihtiyaç duyduğu tek kod bu!

Veya belki de kötü bir çalışandır ve şirketi bir gezintiye çıkarmaktadır. Söyleyemem ve bilmeniz gereken tüm bilgilere de güvenle sahip olabilirsiniz.

Bir orta taktik önerebilirim. Bir dahaki sefere karşılaştığınızda, kodunu sizi etkileyen büyük bir hatanın bazı ayrıntılarını getirin. Her şeyin yolunda olduğunu söylediğinde, kibarca ilerlemenizi engelleyen olağanüstü bir sorun olduğunu söyleyin .

Politik olarak, böyle söyleyerek hadi tam olarak doğru olmadığını iddia ederken, hala aptalca oynamaya ve savunmaya koyulmaya devam etmesine izin veriyor.

Yöneticiniz bir sonraki toplantıda sorun olup olmadığını sormalıdır. Olmazsa, bir hatayı düzeltmek için baskı ona düşer. Düzeltilirse, teşekkür edin, şimdi çok iyi çalışıyor ve yeni bir engelleyici buldunuz. Özellikle iyi olmak istiyorsanız, toplantıdan kısa bir süre önce koştuğunuzu söyleyin.

Yalan söylemiyorsun, kendi başına, ya da taraf tutmuyorsun. Sorunlara dikkat çekerek ve her şeyin yolunda gitmediği durumlarda meslektaşınızın yüzünü kurtarmasına izin vererek siyaset oynuyorsunuz.

Yöneticinizle konuşmak çok cazip, ama hangisiyle en çok çalışmak zorunda olduğunuzu unutma.

Pat'in cevabı harikaydı. % 100 katılıyorum. Patronla buluşma gizlice gitme. Ya meslektaşınızla 4 göz arasında götürün veya 3ünüzle de yapın. Fakat Pat'ın insanlara değil, kod meselelerine odaklanması önerisi doğru yoldur.

BTW, 40 saat / hafta yeterli ahbap. Motivasyonunu yüksek tutmalısın!

Entegrasyon testinde ikinize de yardım etmesini isteyin. Sorunun nerede gerçekleştiğini söyleyebilecek kişi olacaktır. Temptar'ın da belirttiği gibi, neden sorunları izlemek için bir excel olmadığını bile merak ediyorum! hiçbir takip olmadığından, her zaman olduğu gibi diğer adam her şeyin şu an için her şey yolunda olduğunu söyleyerek kaçıyor! bu şekilde çalışmıyor!

Bu sizin modülünüzün yapılması gerekiyorsa, tarafınızdaki gecikmeye neden olan şeyin üzerindeki Kırmızı bayrağı kaldırmanız gerekir. MERE Yıllarındaki Tecrübe'nin yapacak bir şeyi yoktur, sadece bilgisi ve yöneticinizin ısrar etmesi gereken şey budur. Dediğim gibi burada gerçekleşen projenin kötü bir yönetimi olduğunu hissediyorum.

1. Ek görevler isteyerek ve kuruluşa nasıl değer katabileceğinizi sorarak inisiyatif göstermek güven kazanmanın en iyi yoludur.

Yöneticiniz projeyi kimin yavaşlattığını anlamaya yetecek kadar teknik olmayabilir, ancak aktif olarak yeni görev arayışı arayan bir geliştiricinin mevcut görev sırasından esinlendiğini fark edecek kadar zekidirler. Bu, mevcut görevinizdeki diğerlerinden hata düzeltmeleri beklediğinizi açıkça belirtebileceğiniz bir sohbete yol açacaktır. Tartışmayı , boş zamanınızı verimli bir şekilde kullanarak, meslektaşınızın hata düzeltmeleri ile nasıl yavaşlattığını değil , organizasyona nasıl katma değer sağlayabileceğinize göre yapın.