Patronunuzla konuşmalı ve böyle bir geri dönüş düşünüldüğünde her seferinde sizi aramasını istemelisiniz. Patronunuz meşgul ama onu dinlemek için zaman ayırabilirse, sizi dinlemek için zaman ayırabilir. Bu tersine dönmeler tekrar tekrar tartışmasız bir şekilde devam ederse, sizin yeterliliğiniz hakkındaki algısı renklenecek ve performans inceleme sırasında kendiniz hakkında bazı hoş olmayan geri bildirimler duyabilirsiniz.

Bu noktada önceliğiniz özetliyor. tek kelimeyle: ERİŞİM. O ofiste bir geri dönüşü tartışırken, kesinlikle patronunuzun odasında veya ofisinde olmanız gerekir. Orada değilseniz, bir şeyleri neden yaptığınızı ya da neden yaptığınız seçimleri yaptığınızı açıklama şansınız olmaz. Söylediklerinizi tartışsanız bile yaptığınız değişiklikleri geri alabilirler ancak yetkin bir profesyonel olarak güvenilirliğinizle uğraşamazlar. İş arkadaşınızın deliliğinin bir yöntemi varsa, bunu işitmeniz ve buna meydan okumalısınız, böylece ilgili fikirlerin adil bir şekilde duyulmasına dayalı bir karar verilsin

patron zamanı olmadığı ve sizin uzaktan çalıştığınızı söylüyor. Erişim TALEP etmelisiniz. Patronunuzun sizi Skype'a bağlaması ve onu düzeltmek için bir GotoMeeting veya telekonferans ayarlaması zarar vermez. Sanırım bu sitede olduğunuzu, çünkü her şeyi yeniden yapmak zorunda kalmak bir yana, saatlerce ve günlerce çalışmanızın yok edilmesinden bıktınız ve bıktınız. Dolayısıyla, patrona katılmanız gerektiğini belirtmeniz gerekir çünkü bu iş akışı verimsizdir. Patron size karşı sabırsızlanırsa, performans inceleme sırasında veya daha önce hangi yaklaşımı istedikleri konusunda aydınlanmak istemezsiniz

Buluşma günündeki tartışmanızın konusuna gelince: patronunuza bir dahaki sefere kodunuz hakkında konuşup onu geri döndürdüğünde, tartışmanın bir parçası olduğunuzu soruyorsunuz. Bu sizin kodunuzdur ve meslektaşınızın hangi kod parçasını geri almak istediğini bilirsiniz, böylece tam olarak tartışma konusunu ve ne söyleyeceğinizi bilirsiniz. Tartışmayı teknik yönlere odaklayın. İş arkadaşınızın kişiliğinin daha az çekici yönleri hakkında konuşmanıza gerek yok. Kendi profesyonel güvenilirliğinizi oluşturuyor ve ileri sürüyorsunuz, bu olmadan ileride bir sesiniz olmayacak

Vietnhi Phuvan'ın cevabı harika ama bence önce yapılacak bir şey var: İş arkadaşınızla konuşun.

Meslektaşınızın bu proje üzerinde yıllardır çalıştığını söylüyorsunuz ama sonra onun yapmadığı bir şeyi yapıyorsunuz Katılmıyorum. Belki daha önce görmemiştir ama sorun budur. Ürün ve kod tabanı hakkında daha iyi bir bilgiye sahip olması çok muhtemeldir.

Düzeltmenizi / özelliğinizi uygulamadan önce, tasarımınızın mimari ile iyi bir şekilde bütünleşip bütünleşmeyeceğini ona tekrar kontrol etmelisiniz. kötü tepki verebilecek şüpheli herhangi bir şey görmediğinden emin olmak için hızlı bir kod incelemesi isteyebilirsiniz.

Teknik olarak onun kadar iyi olabilirsiniz, ancak kesinlikle hakkında daha fazla bilgi sahibidir. ürün ve dolayısıyla onun görüşü büyük olasılıkla uygulanacak olan fikir olacaktır (bunun adil olup olmaması başka bir konudur).

Bunu yaparsanız, patronunuzla ilgili herhangi bir sorun kalmaz. . İş arkadaşınız bu parmağı kaldırdığında hala bu oluyorsa, Vietnhi Phuvan'ın cevabını uygulayın.

Not: Eğer uzaktan çalışıyorsanız. Bir skype vb. Sorabilir veya daha resmi bir inceleme yapabilirsiniz.

Bu durumda, zaman boşa gidiyor.

Öncelikle, yalnızca gereksiz değil, aynı zamanda bir iş arkadaşınız tarafından kabul edildiği gibi kaldırılması gerekecek kadar kötü olan özellikleri uygulamakla zaman kaybediyorsunuz.

İkinci olarak, iş arkadaşınız kod konularında patronunuzun zamanını boşa harcıyor.

Etkileşimler, geliştirme sürecinizde çok yanlış bir şey olduğunu gösteriyor.

1. Biletleri kim giriyor sisteme mi? Biletleri kim inceliyor ve onaylıyor? Onları kim atar? Çoğu bilete ne olur? Geliştirme sürecine kim rehberlik ediyor? Kimin vizyonu uygulanıyor? Müşteri kimdir?
2. Geliştiriciler neden biletleri "geri almak" için patrona gidiyor? Geliştiriciler neden birbirlerine gitmiyor, sorunları tartışmıyor ve sonra patrona birleşik bir yüz sunmuyor? Geliştiriciler neden bu kararları alma yetkisine sahip değil?

Boşa giden işler, özellikle de nadir olmadığında, önemli bir sorun.

patron ve aşağıdaki noktalardan ve önerilerden birini veya birkaçını yapın:

• "Daha sonra kaldırılan birkaç görevi uyguladım. Üzerinde çalışmak üzere olduğum görevin olduğunu nasıl doğrulayabilirim? İş arkadaşımın hakkında çok şey biliyor gibi göründüğü görevlerin benden ziyade ona verilebilmesi için görev atamanın daha iyi bir yolu var mı? Haftalık veya günlük bir standup yapabilir miyiz? Üzerinde çalışmayı düşündüğümüz görevleri tartışan toplantı, böylece belirli bilgilere sahip olanların belirli bir göreve katılabilmesi için? "
• " Geri dönüşlerin getirilmeden önce ekip üyeleri arasında tartışılması için süreci ayarlayabilir miyiz Bu, iş yükünüzü hafifletmeli ve hepimizi aynı sayfaya götürmelidir. "
• " Her görevi, asi olmadan önce en az iki geliştirici tarafından onaylatabilir miyiz? Görevlerin yararlı olduğundan emin olmak için hazırlandı ve herhangi bir geri alma işlemi, onu onaylayanlarla yapılan tartışmaları da içermeli, böylece kurs düzeltmelerini bireysel yerine ekip olarak yapabilir miyiz? '

Dürüst olmak gerekirse ciddi bir iletişim eksikliği var gibi görünüyor. Bunun nedeni liderlik veya vizyon olmaması olabilir.

Yukarıdaki öneriler alınmazsa ya onunla yaşayabilir ya da ekibinizin çok ihtiyaç duyduğu iletişimler olmaya çalışabilirsiniz.

Bunun gibi bir şey olduğunda - ister siz ister başka biri olsun - aşağıdakilerden birini veya birkaçını deneyin:

1. Bileti kaldırılan kişiyle konuşun. Onlara arka planı neden kaldırdıklarını sorun. Bilet ile özellik listesi arasında bir çelişki olup olmadığını veya bunun ürün için sahip oldukları kişisel bir vizyon olup olmadığını öğrenin.
2. Bileti oluşturan kişiyle konuşun. Yukarıdaki adımda öğrendiğiniz bilgileri aktarın ve bunun farkında olup olmadıklarını öğrenin. Onlara biletin hangi özelliği veya sorunu yönetmesi gerektiğini sorun.
3. Tüm bu bilgilerin tasarım belgelerinde yer aldığından emin olun.

Esasen bir bilgi merkezi ve bilgileri ve ekibin vizyonunu aktif olarak hareket ettirirsiniz, böylece herkes aynı sayfada olur. Bu, genellikle süreç değişiklikleri veya onayı olmadan yapılabilir, ancak zaman alıcıdır.

Son olarak, insanları görevleri kaldırmaktan caydırmak istiyorsanız, görev hakkında uzun bir konuşma yapın. Sandalyenizi ofisine getirin ve neler olup bittiğini tam olarak anladığınızdan emin olmak için onlarla birlikte işin özüne girin. Çabuk saygısız bir cevabı kabul edip devam etmeyin, proje için sahip olduğunuz genel vizyonu ve anlayışınızı gerçekten anlamak istediğinizi gösterin.

Bu üç şeyi başarır - birincisi, onların zamanını harcarsınız ve sonunda, sizinle konuşmaya zaman ayırmaya değmedikçe, muhtemelen kaymasına izin vermenin daha iyi olacağını öğrenirler. İkincisi, onların ürün / proje vizyonunu kazanacaksınız ve umarım zamanla vizyonunuzu kazanacaklardır. Üçüncüsü, aranızdaki ilişki umarım iyileşir ve doğrudan patrona değil de size gitmeyi bırakırlar.

Her zaman arkadaş canlısı ve alçakgönüllü olun, ancak ürünün / projenin vizyonunu anladığınız şey için savaşın. Projeyi tanımladıkları belli olursa, onlarla konuşmak ve bu bilgiyi yaymak takımı birleştirmek için en iyi seçeneğiniz olacaktır.

Son olarak, tüm bu konuşmalar size hangi biletlerin sizin tarafınızdan geldiği konusunda bir fikir vermelidir. reddedebilecekleri masa. Daha sonra öldürmeye çalışacakları bir bilet gibi görünüyorsa, üzerinde çalışmadan önce onlara bileti sorun.

Soru: İş arkadaşım gerçekten sinir bozucu bir şey yapıyor ve ben onunla bunun hakkında konuşmadım. Ne yapmalıyım?

Cevap: Onunla bunun hakkında konuşun. (Ve kendisi onu kastediyor, diğer çalışanlarınız, patronunuz veya patronu veya İK değil.)

Profesyonel bir işyerinde her zaman cevap budur. Ve tabii ki, bu konuşmaya her zaman dikkatli ve profesyonelce giriyorsunuz. Cevabın büyük kısmının bu kadar basit olması gerektiğini düşünüyorum.

Bununla birlikte, ele alınması gereken bir başka yan konu daha var. Hemen bir sonuca varmaktan nefret ediyorum, ancak iş arkadaşlarınızın katkılarınızın süper olmadığını düşünme olasılığı var, bu yüzden onlara gerçekten saygı duymuyorlar. Yukarıdaki doğrudan sohbeti yaptıktan sonra, katkılarınızın bir çeşit emici olup olmadığı hakkında doğrudan bir soru sormak isteyebilirsiniz ve bu yüzden bu oluyor. Bunu yapmalısınız çünkü bu, birçok insanın kendilerini büyütmekten son derece rahatsız olduğu bir şey. İletişimi geliştirerek bu sorunu 'çözebilirsiniz', ancak bu daha ciddi sorunu tespit etmekte başarısız olabilirsiniz.

Değişikliklerinizden bazılarının kötü olduğunu düşünürlerse, bunun üzerine gitmeniz gerekir. Yine de bu problemi çözmek tamamen farklı bir problem ve bence burada tartışmak için biraz fazla uzak.

Vietnhi'ye ... itibarınızı korumaya nasıl başlayacağınıza katılıyorum.

Ayrıca daha iyi bir süreç istemelisiniz. Süreç değişikliğini savunmanın gerçek ayrıntılarını bırakacağım ve hedeflere odaklanacağım.

Kodunuz testleri geçerse bu son teknoloji geliştirme dalı için yeterince iyi olmalıdır (geliştirme dalının tanımına göre), onu serbest bırakmamak için bazı iyi nedenler bile var. Şirketiniz sürüm kontrolünü pantolonunun koltuğuna göre uçurmadığı sürece, değişikliği geri almak bana aşırı bir tepki gibi görünüyor. Biraz kaynak kontrolünü nasıl kullandığınıza bağlıdır, ancak genel olarak konuşursak, eğer bir sorun varsa, onu geri döndürmesine gerek yoktur, sadece almamalı .

Sizin kod testleri geçemez, ardından işleminizin zarar vereceği yerlere ulaşmasını durdurması gerekir. Muhtemelen meslektaşınızın onu tersine çevirerek başarmaya çalıştığı şey bu - ama bir süreç sorunu var. Sorunları önlemek için onu geri döndürmesi gerekiyorsa, o zaman çok geç, zaten sorunlara neden olabileceği yerdedir. Bu kod incelemesini commit'den sonra değil öncesinde talep edebilirsiniz (bu saçmadır, ama belki de kaynak kontrolünü kullanma şekliniz saçmadır ve bu yüzden en iyisi budur). Daha fazla şube kullanabilirsiniz, böylece meslektaşınız kodu geri almadan kodu görebilir ve bundan şikayet edebilir.

Test / biletleme sistemini değiştirebilirsiniz, böylece mevcut bileti çözen ancak başka nedenlerden ötürü kötü olan bir değişikliğe doğru yanıt, değişikliği geri almak yerine "diğer nedenleri" yakalayan testler eklemek ve orijinal bileti sıfırdan yeniden yapın. Özellikle, önceden bilinen gereksinimlere göre çalışırken aynı zamanda yönetimden yeni bir gereksinim bulursa, o zaman bir tür gereksinim değiştirme sürecinden geçmelidir (belki sadece yeni bir çağrı açarak, "gereksinimler değişti"). Bu süreç, yalnızca önceki gereksinimlere dayanan tüm işleri bir kenara atmak olmamalıdır: Bu, yeni gereksinimleri ele almanın iyi bir yolu değildir.

Ayrıca, düzenli olarak yığın halinde yaptığınız bir konumdaysanız işe yaramaz olduğunu bilmeden çalışmak, o zaman gün için işe başlamadan önce daha fazla iletişime ihtiyacınız var. Yani bunu aramalısın. Tesis dışında olmak, sabahları yüksek sesle "Bu sorunu çözmek için yeniden paylaşıcıyı kullanacağım" deme fırsatınız olmadığı anlamına gelir ve orada daha uzun süredir bulunan tüm eski zamanlayıcılar için "aargh, bunu yapamazsın, yenileyici tükürük ve kefalet teliyle bir arada tutulur ve baskıya dayanmaz" diye inlemeniz gerekir.

İş arkadaşınızdan patronu rahatsız etmemesini isteyebilirsiniz önce kodunuzla ilgili bir sorun olduğunda, sorunun ne olduğunu söylemeniz yeterlidir. O zaman daha iyi bir çözümü karşılıklı olarak tartışabilir ve bunu patrona götürebilirsiniz. "Bunun geri alınması gerekiyor" demek, "ForOhFor'un dünkü bütün günü boşa gitti" demeye çok benziyor ki bu kimseyi iyi yansıtmıyor. Meslektaşınız aynı fikirde olmayabilir, ancak reddederse, o zaman en azından, sadece katılmadığı konulara karşı şaşırtıcı derecede agresif olan bir iş akışını takip etmek yerine, sizi bilerek alt ettiğine dair olumlu kanıtlara sahip olursunuz.

Şirketin büyüklüğü hakkında hiçbir şey bilmiyorum, ancak tahmin ettiğim şey şu:

Bu adam, daha iyi bir geliştirici olmasanız bile kendini tehdit altında hissediyor. Bir kişinin küçük bir projede veya küçük bir şirkette tek kodlayıcı olmanın uygun olacağı ekonomik açıdan pek çok durum olduğundan eminim, bu projedeki tek işçi olduğu gerçeği BÜYÜK bir kırmızı bayrak olmalıdır.

Şu anlama geliyor ...

• Şirket, yazılım geliştirmeye fazla ağırlık vermiyor. Öyleyse, daha iyi bir sürece ve daha büyük bir ekibe doğru yürürsünüz. Ayrıca, başka geliştiricilerle çalışarak daha iyi hale gelmek için böyle yalnız bir durumdan hangi iyi geliştirici kaçmaz ki?

• Muhtemelen sizi istedikleri için getirdiler projedeki hızı artırın (efsanevi adam ayı, kimse?) ve çok özel proje / kod tabanı bilgisini yayarak "veri yolu faktörünü" düşürmek. Eğer bir "takım oyuncusu" olsaydı, bunu fark ederdi ve patrona gidip değişikliklerinizi geri almak yerine, sizi oturur ve sistem hakkında nasıl daha iyi bir mantık yürüteceğinizi anlamanıza yardımcı olur ya da önceden ... tasarım tartışmaları falan.

• İşleri kendi bildiği gibi yapmaya alışkındır ve değişime dirençlidir. En iyi senaryo, harika bir geliştirici olması, ancak işi garipleştiren topal bir sosyal varlık olmasıdır. En kötü durum, tüm bu topal parçaların hala doğru olmasıdır - ayrıca tasarım kararları ve / veya iyi uygulamalar konusunda her zaman haklı olmayabilir.

Diğerlerinin de belirttiği gibi bu durum muhtemelen zamanla itibarınızı zedeleyecektir. Muhtemelen başka bir yerde olmak istersiniz.

Küçük değişiklikler oluşturmaya başlayın. Tüm bir alt sistemi yeniden yazmak ve ardından bunu taahhüt etmek yerine, yol boyunca her bir küçük adımı yerine getirin. "Yöneticinin kulağına sahip olan adamı" her adımda yöneticiye gitmeye ve yaptığınız değişikliklerin zararlı olduğunu söylemeye zorlayın. Yöneticinin herhangi bir mantığı varsa, tüm "Ama [x]" ve "Çünkü [y]" yorucu hale gelir ve yönetici, işe yaramaz tarafın kodunuzun zararlılığıyla ilgili söylentilerini hemen gözden düşürmeye başlar.

Kurumsal türlerle nasıl başa çıktığım konusunda oldukça trolish'im. Bazı kurumsal dalkavuklar iyi fikirlere karşı muhalif görünürken kötü fikirlere karşı itiraz ediyorum, çünkü bunlar değişimi temsil ediyor ... Bu yüzden, daha az bir strateji geliştirdim. Tek çözüm (referans olarak, kurumsal cehennemde hiçbir zaman tam olarak düzgün bir şekilde yürütemedim) sistemi çürütülemeyecek kadar az iyi fikirlerle spam yapmaktır.

Tüm bunlar başarısız olursa, Amerikan şeyini yap. Büyük bir sorunu önceden çözün ve çözümü ona yavaşça gönderin, böylece senaryo 1 gerçekleşsin, ancak bu şekilde çürütmek çok daha imkansız hale gelir. Bu arada parayı al ve kaç. Yavaş çalışın, hızlı para kazanın. Pislik yöneticisi bunu tüm organizasyona getirdi.