Yönetici her demo sonrasında ihtiyaç şartnamesini değiştirmeye devam ediyor [kapat]


21

Çalışma ortamımın arka planı

Yöneticimin arka planı veya bilgisayarları veya yazılımı hiçbir şekilde anlamadığı. Yaşamında kodu herhangi bir biçimde (10 fit veya daha kısa bir fiziksel mesafeden bile) görmemiş olması muhtemeldir.

Orada hiç kimse ben hayata geçirmesi istendi ben ne karmaşıklığını anlıyor. Yarı-hardcode ise kimsenin bilmeyeceği noktaya.

On Joel'in testi biz inanılmaz skor 0 puan.

Problemler

  • Yönetici ve zaman zaman diğer "kıdemli" ihtiyaç şartnamesini değiştirmeye devam ediyor. İyi mühendislik yapılırsa ve yamalı "düzeltmeler" yapılmadığında, temel tasarımda değişiklik yapılması gereken değişiklikler.
  • Koda bakacak hiç kimse yok (muhtemelen hiç kimse nasıl yapılacağını bilmediğinden veya yapılması gerekse bile), bu da hiç kimsenin yapamayacağı anlamına gelir:
    • Sorunun karmaşıklığını veya çözümün zerafetini takdir edin.
    • Yaklaşıma iyileştirme öner.
    • Kodun kalitesini takdir edin.
    • Kodun nerede geliştirilebileceğini gösterin.
  • Dilbilgisi açısından anlam ifade eden ancak başka bir anlam ifade etmeyen bir çok jargon kullanılır.
  • Bir yazılım şirketi gibi hissetmiyor, davranmıyor veya çalışmıyor.

Soru

Ne yapılmalı? Özellikle de kodumdaki gelişmeleri işaret edecek hiç kimse olmadığı için.

Güncelleştirme

HLGEM'in (ve muhtemelen başkalarının) sorusuna cevap vermek için denemek ve düzeltmek için ne yaptığımla ilgili soruyu. Redmine'ı kurmayı ve kaynak kontrolünü herkese tanıtmayı önerdim. Dağıtılmış (git veya mercurial) önereceğimi, ancak merkezi olanlar hakkında konuşup ekibin karar vermesine izin vereceğimi söyledim. Yanıt, işlerin yapıldığı ve haftalar içinde gerçekleştirileceği idi. Bunu görmedim, şirketin diğer bölümlerinin kullanıp kullanmadığını da bilmiyorum.


36
bariz bir cevabı ortaya çıkarmak için: RUN !!
keppla

3
Önemli bir şey yoksa, bize yeni bir iş aramaya başladığımızı söylemiyorsunuz.
Zachary K,

11
“Yönetici ve diğer zamanlarda“ kıdemli ”gereksinim şartnamesini değiştirmeye devam ediyor.” Spesifik olmak, Joel'in testinden 1 puan alır. : P
R. Martinho Fernandes,

11
Hiçbir teknik, teknik olmayan yöneticiler nedeniyle Joel Testinde 2'den az puan alamaz. Sizin ve ekibin diğer teknik üyelerinin puanınızı yükseltmek için teknik olmayan menajerlerden girdi almadan yapabileceğiniz birçok şey var. Bunu sadece yöneticiden suçlamak için hiçbir mazeretin yok.
maple_shaft

6
Sanırım satış ekibiniz de yazılım yönetimi olarak var, sempati duyuyorum.
wildpeaks

Yanıtlar:


30

Kısa versiyon :

Koşmak.


Biraz daha uzun versiyon :

Eğer yönetici bir projeyi nasıl çalıştırılacağını bilmeyen ve üst düzey onunla birlikte giderse, o zaman bir şeyler sabitleme şansı yanında var.

Yazılım projelerini yönetmek için bir yöneticinin yazılım hakkında bir şeyler anlaması gerekir. Yöneticiler olmazsa, önce öğrenmeleri gerekir. Yönetiminizi ve üst düzeylerinizi her şeyi yanlış anlamalarına ikna edebilme şansınız nedir? Onlara bir şeyler öğretme şansın nedir?

Bir zamanlar benzer bir durumdaydım (sadece yaşlılar yoktu). Korkunç bir yılın ardından istifa ettim ve asla geriye bakmadım (iğrenme dışında).


3
Bu teklif için +1: "Yönetici bir programın nasıl çalıştırılacağını bilmiyorsa ve kıdemli bununla devam ederse, bir şeyleri düzeltme şansınız yoktur."
maple_shaft

17

... ihtiyaç şartnamesini değiştirmeye devam edin. İyi mühendislik yapılırsa ve yamalı "düzeltmeler" yapılmadığında, temel tasarımda değişiklik yapılması gereken değişiklikler.

Gerçek dünyaya benziyor. Bu her zaman, her yerde olur. Evet berbat ama bir tür çevik tavırla katlanılabilir. Ayrıca, bir yazılım iyiliği ölçüsü de erişilebilirliğidir. Bir meydan okuma olarak al.

Dilbilgisi açısından anlam ifade eden ancak başka bir anlam ifade etmeyen bir çok jargon kullanılır.

Yine, o kadar yabancı gelmiyor ;-)

Uygulamamın istendiği şeyin karmaşıklığını anlayan kimse yok.

Sen bile değil Bunu anlarsan, o zaman aynada bunu anlayan bir kişi var. Dolayısıyla, şirketinizin refahına ilişkin sorumluluğunuz muhtemelen unvanınızın önerdiğinden daha ağırdır. Sorunları anlıyorsanız ve yöneticiniz anlamadıysa , şirketi doğru bir şekilde yönetebilmeleri için yönetimi açıklığa kavuşturmak sizin sorumluluğunuzdadır. En yakın yöneticilerinizin teknik olarak yetkin olması gerektiğini ( belki de sizin kadar yetkin olmak zorunda değilsiniz - yöneticileriyken, sen uzmansın - ama en azından birazcık yetkin), ama açıkça belli değilse, varsaymak mantıklı olabilir. Onlara yardım edebilirsin, neden yapmıyorsun?

Basit bir kaçan çözüm, şirkete geçmektir. Ancak başka bir seçenek olarak Joel testinin öğelerini uygulamayı düşünün. 5'ten itibaren olan maddeler yönetim ile daha fazla işbirliği gerektirse de, 1-4 arasındakiler, kimseye sormadan bunları kurabileceğiniz şekildedir.

Bununla birlikte, SE’deki hiç kimse sizin durumunuzu tam olarak bilemez. Beceriksiz gerizekalılarla dolu bir şirkette olmanız ve böyle bir karmaşadan iyi bir şey çıkmanız herkes için çok fazla olabilir. Durumu kendin değerlendirmelisin.


Peki ya biri benim hatalarımı işaret ediyor? Gelişmeme ve öğrenmeme yardım ediyor.
Orman Avcısı,

4
@ Jungle Hunter: Elbette her şeyin kolayca kurulduğu bir şirkette olmak daha kolay olurdu, herkes zaten akla gelebilecek en iyi uygulamaları takip ediyordu, böylece sadece çırak olabilir ve başkalarını taklit edebilirsiniz. Ancak sorumluluğu üstlenerek ve şirketinizi geliştirmede aktif olmanızla da çok şey geliştirebilir ve öğrenebilirsiniz. Geliştirme ve öğrenme, sonuçta kendi ellerinizdedir. Diğer insanlar yardım edebilir, ama patronun onlardan biri olmak zorunda değil.
Joonas Pulakka,

Evet haklısın. İyileştirmeye çalışıyorum, ancak çabalarımın iyileştirilmeye çalışılmasından daha fazla şikayet edildiğini düşünüyorum. Dürüst olmak gerekirse çabalarım ikisi de, ama bakalım onları ikinci yarıyı görmeye götürebiliyor muyum - iyileştirme girişimi.
Orman Avcısı,

@ Jungle Hunter: Görüyorum ki, şikayet etme ve iyileştirme arasındaki çizgi bulanık olabilir . Fakat hiçbir zaman yapıcı tarafa yaslanmaya zarar vermez.
Joonas Pulakka

4
@Joonas: VCS'yi tanıttığım, kod incelemeleri yaptığım, C ++ seminerleri verdiğim ve kod kalitesini artırmak için yaptığım şirketlerde bulundum. Ve OP'nin tarif ettiği gibi bir şirkette bulundum. Umutsuz bir durumsa, yenilgiyi kabullenmeli ve başarılı olmanıza izin vererek mücadelenizin ödüllendirildiği bir iş aramalısınız.
sbi

16

Yorumlardan birinde bunun ilk işin olduğunu söylüyorsun. Yöneticiler, tecrübelerime göre özel bir yazılım dükkanı dışında hiçbir yerde teknik değildir. Bu hayatın bir parçası, sadece buna alış.

Ağlıyor ve sızlanıyorsunuz çünkü çözümlerin zerafetini takdir edecek kimse yok. Buradaki asıl sorun, çözümlerin zarafetini takdir edecek hiç kimsenin olmadığı, ancak çözümlerin neredeyse sandığınız kadar iyi olmadığını size öğretecek hiç kimsenin olmamasıdır. Neredeyse tüm yeni programcılar gerçek becerilerini abartıyorlar. Akıl hocası olmadan, daha iyi uygulamalar yapmana yardım edecek kimse yok. Mentorluk yapacak kimse yoksa, o zaman yerel kullanıcı gruplarına katıl, aktif olarak katıl ve oraya akıl hocasını bul. Daha da iyisi, sonunda daha iyi bir iş bulmanıza yardımcı olur.

Joel sınavında sıfır aldın mı? Tek kodlayıcı sizseniz (ve sizin yazdıklarınızdan geliyorsa) neden kaynak kontrolü kullanmıyorsunuz? Seni önleyen nedir? Tek kodlayıcı siz değilseniz, neden kod incelemeleri yapabilecek kimse yok? Tüm geliştiricilerimiz kod incelemesi yapar, özellikle yöneticiler teknik değilken bir yönetim işlevi değildir.

Gereksinimler hemen hemen her yerde değişiyor. İşletmelerin ihtiyaçları sürekli değişiyor ve programcı olmayanlar genellikle programın bir şeyleri alana kadar ne yapacaklarını göremiyor. O zaman ihtiyaç duydukları şeyin olmadığını anlarlar. Bu nedenle Agile gerçekten ortaya çıktı çünkü eski yöntemler bu değişikliği iyi idare edemediler.

Yönetim verileri kendileri girmek istemese bile hata izlemeyi ayarlayın. Birisi size bahsettiğinden, yeni hata / özellikler girmekten sorumlu olun. Yöneticiye, size 27 başka şey için bir değişiklik yapılmasını istediğinde bir değişiklik istediğini söyleyebilmeye gerçekten yardımcı oluyor ve işte bu listedeki listeden hangisi, bu yeni değişikliği yerine getirmek için öncelikli listeden aşağı gitmemi istiyor. Gözden geçirme zamanında yardımcı olacaktır, çünkü uyguladığınız hata düzeltmeleri ve özelliklerin sayısını sayabilirsiniz. Herkes kullanmıyorsa, en azından kendi işin için yapabilirsin. Herhangi bir yazılımı yüklemenize izin vermezse, bir Excel elektronik tablosu kullanın. Biraz inisiyatif al. Sonuçları gösterdikten sonra, diğerleri daha çok ilgilenecektir. Bir kişi için çok fazla iş olduğunu düşünüyorsanız, hata izleyici bunu kanıtlamanıza yardımcı olacaktır.

Cilalı görünümlü demolar provde etmeyin! Demolar, bir kağıda kurşun kalemle çizilmiş gibi görünmelidir. Arayüz ne kadar parlak görünürse, teknik olmayan kişi de bittiğini düşünüyor.

Örneğin, en iyi uygulamaları ve semi_hard kodunu takip etmemeniz durumunda kimse bilmeyecek olsa da, bilecek ve özensiz, kötü alışkanlıklara gireceksiniz. Bir sonraki işinde bu sana iyi hizmet etmeyecek. Bu yüzden, koşullar altında yapabileceğiniz en doğru yola yakın şeyler yapın. Testler yazdığınızdan emin olun (bunu geliştirme zamanının bir parçası olarak düşünün ve bunu özel olarak tahminin bir parçası olduğunu söylemeseniz bile yönetime verdiğiniz tahminde bulunma vakti koyun) ve emin olmak için bu testi kullanın. sonraki değişiklikler başka bir şeyi bozmaz.

Bunu büyümek ve gelişmek için paha biçilmez bir fırsat olarak görmeniz gerekir. Gerçek kodlamada, birçok insanın kariyerinizin o aşamasında sahip olduğundan daha fazla özgürlüğe sahipsiniz. Dolayısıyla bunu başarılı bir şekilde uygulanmış projelerden oluşan bir portföy oluşturmak için bir fırsat olarak düşünün. Bir sonraki işi aramaya başladığınızda, kurumlu kaynak kontrolü, kurucu hata takibi, X sayısıyla başarılı proje uygulamaları yarattı vb.

Ayrıca beklentileri yukarı doğru nasıl yöneteceğinizi öğrenmek için burada büyük bir fırsatınız var. Bu kariyerinin geri kalanında işe yarayacak kadar üzücü. Burada bunu yapmaya çalışırken kaybedecek hiçbir şeyin yok, işler zaten iyi değil. Ancak daha sonra daha iyi yerlerde size yardımcı olacak politik becerileri öğrenebilirsiniz. Fayda-maliyet analizi yapmayı öğrenin. İş alanını anlamayı öğrenin, böylece onlarla konuşurken ikna edici olabilirsiniz. Şirkete faydaları ve kar açısından konuşmayı öğrenin. Her bir görevin tahminde bulunun ve waht yönetimi size vermese bile uyuşmasalar bile, iş tahmin etme becerinizi geliştirmek için neyi tahmin ettiğini ve gerçekte ne yaptığını not edin. Bir keresinde tahminlerinizin yönetiminkinden daha doğru olduğunu gösterdikten sonra, Tahmininin çok düşük olduğunu söylediklerinde dinleme olasılıkları daha yüksek olacaktır. Ancak, önce hem daha doğru tahminlerin hem de en önemlisi, projeleri sunma ve çalışmalarını sağlama yeteneğinden önce bir kayıt oluşturmak zorundasınız. Yine bu, kariyerinizde ilerlerken sahip olmak için iyi bir beceridir.

Her şeyden önce pasif olmayın ve iyileştirmenin yukarıdan gelmesini bekleyin.


1
Bu cevabın çok yararlı kısımları var. Ve hissettiğim bazı şeyler durumumu anlama konusunda yanlış. Mesela, her iki vakayı da belirtiyorum, iyi olduğu zaman takdir edecek kimse yok. Yanlış anladığımda kimsenin umrunda değil. Kaynak kontrolü kullanıyorum ama 2-3 kişilik bir takımda başka kimse yok. Kod, paylaşıldığında pendrives ve Airdrop kullanılarak paylaşılır. Eğer yorumu okuyordum, sanırım dizüstü bilgisayarımda sadece benim tarafımdan kullanılan Redmine kurulumundan da bahsetmiştim. Ve git ile aynı. Bunları herkes için uygulamaya çalıştım. Benim seviyem, üniversiteden yeni çıkmış. Kıdemli kodlaması gerekiyordu ama yazmıyor.
Orman Avcısı,

Bir parça kaydı yapmak için tavsiyede bulunacağım. Evrimde genel konuşmadan daha fazla özgürlüğüm olduğunu hatırlayacağım. Beklentileri ve diğer politik ve yumuşak becerileri yönetmeyi öğrenebilirim.
Orman Avcısı,

3
Sarkıklara kod vermeyi bırak. Kodunuzu istiyorlarsa, onlara kaynak kontrolünde olduğunu söyleyin ve nasıl kullanacaklarını gösterin.
Hugo

1
@JungleHunter Kodunuzu istediklerinde, onlara çalışmayan bir değişiklikle yarı yolda olduklarını söyleyin, ancak kaynak kontrolünden en son kararlı sürümü alabileceklerini söyleyin.
Kirk Broadhurst

1
@HLGEM "Ağlıyor ve sızlıyorsun"? Çok sert, yalnız bunun için aşağı oy.
Ben H

6

Yerinde olsam başka bir iş bulmaya çalışırdım. Niye ya? Bence biliyorsun ki, maalesef, menajerin "iyi değil". Yine de menajerinle bir şeyler yapmaya çalışmalısın.

Ayrılmak istemiyorsanız ve / veya kimseyle konuşmayacaksanız, kendiniz bir şeyler bulmak zorunda kalacaksınız. Şirkette kimse kodunuzu bilmiyorsa, yöneticinizin gereksinimleri karşıladığınızı nasıl bilmesi gerekir? Sadece söylüyorum.


Sadece bir demoya bakıyor. Diyelim ki, bu şekilde bu şekilde değiştirelim. Ve sonra bir jargon seli var.
Orman Avcısı

2
@ Jungle, demolara zor girmezdim o zamanlar onları gördüklerinde çılgınca değişmeye mecbur olduklarından. Her şeyden önce görsel bir insan gibi geliyor. Onun için farklı kullanım durumlarında ekran görüntüleri çizmeyi denediniz mi? Bu, işlevsel prototiplerden daha bir araya getirmek için çok daha kolay olabilir.
maple_shaft

@maple_shaft: Bunun mükemmel bir fikir olduğunu düşünüyorum.
Orman Avcısı

1
@maple_shaft: Ya da belki de vaktinden önce teslim etmek yerine, sonuna kadar teslimat. ;)
Orman Avcısı

1
Ortaokuldaki iş tavsiyesi ...

4

Yöneticinizle ve bununla ilgili yaşlılarla konuşun . Sorunlarınızı açıklayın ve çözümler önerin. Konuşmayı biraz hazırlayın böylece iletmek istediğiniz genel mesajı öğrenin.

Konuşmadan sonra biraz zaman verin . Bir şeylerin değişip değişmediğine bakın. Olmazsa, değişiklikleri kendiniz uygulamaya çalışın ve yöneticinize ve değişikliklerin olumlu sonuçlarını üstlere gösterin .

Konuşma yardımcı olmazsa ve değişiklikleriniz reddedilirse, o yerde ne kadar çalışmak istediğinizi kendiniz değerlendirmek zorundasınız. Evet, iş kötü olabilir, ama belki de maaş iyidir ve sadece 5 dakikalık bir ücretiniz var mı? İşinizin olumlu yönleri olumsuzdan ağır basıyor mu? Yapmazlar, yeni bir iş aramaya başlardım.


1
Konuştum. Biletleme sistemi kurmayı teklif ettim, sürüm kontrolü tanıtmak, ancak umursamıyor. Ya da anlayın. Ya da her ikisi de. Ben onunla güvenilir bir özellik olması hakkında konuştum ve o kabul eder. Yine de onu değiştirir. Veri odaklı değil. (Oh ve sorumu metnin vurgusunu kaldırdım.)
Jungle Hunter

2
@ Jungle: O zaman ASAP'ı çalıştır.
sbi

1
Sbi ile aynı fikirdeyim, eğer daha önce vurulmasını istemediyseniz, yasal olarak dışarı çıkıp kendi başınıza bunu yapabilirdiniz. Sen zaten odayı kaybettin ve senin durumunda olsaydım aramaya başlardım.
maple_shaft

3

Sorununuz bilet sistemleri ve sürüm kontrolü TEKNİK meselelerdir ve bunu teknik olmayan bir yöneticinin girişinden bağımsız olarak yapmanız gerekir. Bu, teknik olarak en iyi uygulama olarak kabul edilmeli ve bu ayarları yapmazlarsa, bunun gerçekleşmesi için kendiniz üstlenmelisiniz.

Teknik olmayan bir yöneticiden hata izleme, kaynak kontrolü ve sürekli entegrasyonun faydalarını anlamasını bekleyemezsiniz. Bu yüzden teknik değiller, bilmeleri ya da umursamadıkları, etki alanı ve işletme bilgisi uzmanları oldukları. Sağlamaları gereken tek şey yüksek seviye yön ve şartlar.

Benim de teknik olmayan bir menajerim var ve Joel Test skorunu 4'ten 8'e yükseltebildim, çünkü gittim ve yaptım ve izin istemedim.

Grubunuzun güçlü bir teknik lidere ihtiyacı var ve kimse plakaya adım atmadı.

Http://community.rallydev.com/ adresine göz atın, onlar mükemmel bir Agile proje yönetimi ve Arıza izleme işi yapan bir topluluk sürümüne sahipler. Tek başına bu Joel puanınızı artıracak ve size kurulum için NO sunucu alanı veya zaman mal olacak.


Evet! Bu bence asıl mesele. Güçlü bir teknik liderimiz yok.
Orman Avcısı

2

Bu, sizin ve diğer "kıdemli" nin temelde kodlayan tek kişi olduğunuz küçük bir mağaza ise , "Joel Testini" yerine getirmek için ne yapılması gerektiğini yöneticiye belirtmek sizin sorumluluğunuzda olabilir .

Gereksinimlerdeki değişiklikler her zaman orada olacaktır ve işiniz çevik kalkınmanın temel ilkelerinden olan onları benimsemektir :

Gelişmekte olan geç bile, değişen gereksinimleri karşılayın. Çevik süreçler, müşterinin rekabet avantajı için koşum değişikliklerini gerçekleştirir.

Ancak değişen gereksinimlere uyum sağlamak, diğer çevik ilkeleri takip etmek anlamına da gelir. Yönetim düzeyinde, bu, yöneticinin müşteriye tüm bu değişikliklerin bir bedeli olduğunu şeffaf bir şekilde sunabilmesi gerektiği anlamına gelir: ya projenin kapsamı son teslim tarihlerini karşılamak için değiştirilmeli ya da son tarihler kaydırılmalıdır (ikincisi tavsiye edilmez).

Bu, yöneticinizin tüm gereklilikleri karşılayan proje olduğu bir proje ise, o zaman sizin çevik müşterinizmiş gibi davranmalı ve onlara aynı şeyi açıklamalısınız (kapsam <--> son teslim tarihi uzlaşıyor) ).

Ancak, küçük bir şirketteki geliştiricinin düzeyinde, kodlama bölümünün çevik önerilere uygun olmasını sağlamak sizin sorumluluğunuzda olduğunu söyleyebilirim.

Bunlar kesinlikle yapmanız gereken bazı adımlar ve muhtemelen bunları kendiniz yapmanız gerekecek:

  • sürüm kontrol sistemine sahip olmanız gerekir (küçük bir takıma ayarlamak bir gün sürer)
  • Eğer gerekir sık sık bültenleri yapabilirsiniz sağlamak için inşa komut dosyaları (oldukça hızlı da kurmak)
  • Eğer gerekir (bu kodlama bir yoldur ve zor olabilir bu yüzden sıkı bağlı projenin ortasında eklemek için, radikal tüm tasarım dikte) otomatikleştirilmiş birim testleri kullanmak
  • otomatik yapım ve testlerin yanı sıra fonksiyonel ve GUI testlerinin (yazması biraz daha zor) olmasını sağlamak için sürekli bir entegrasyon sistemi de kurabilirsiniz.

Yerel olarak kendi makinenizde bir SVN deposuna sahip olabileceğinizi unutmayın. Basit bir TODO listesi fakir bir insanın hata takip sistemi olarak görev yapabilir (biraz aşırı, ama hey). Ve derleme komut dosyaları olmaması için hiçbir bahane yoktur.

Ayrıca, kapsam / son ödeme uzlaşmalarıyla ilgili herhangi bir açıklama yapmadan önce, birinin de belirli bir özelliğin ne kadar zaman alacağı konusunda tahminlerde bulunması gerekir. Bu genellikle çevik dünyada "ideal günlerde" yapılır, yani her bir özelliğin göreceli çabasını tahmin etmek için elinizden gelenin en iyisini yapmanız gerekir ve ardından gerçek kodlama hızınızı kullanarak ne kadar iyi tahmin edildiğini (ve "eğriyi" uygun şekilde ölçeklendirirsiniz) kullanın. ).


Çünkü "müşterinin rekabet üstünlüğü" anahtardır. Bugün daha sonra ona müşteriyi etkilemek için neden bunu yaptığını sordum. : |
Orman Avcısı

Kendim için yerinde git / mercurial var. Ama şu anda testi manuel olarak yapıyorum. Otomatik birim testlerine bakmalıyım.
Orman Avcısı,

1

Takımınızda eksik sorumluluk katmanları olduğunu düşünüyorum. Bir proje yöneticisi, sistem analisti, iş analisti ve geliştiricileri bulunmalıdır. Proje Yöneticisi rolü, müşteri-proje iletişim stratejisinin tanımlanmasından ve uygulanmasından sorumludur (diğer görevlerin yanı sıra).

Yöneticilerin kod veya karmaşıklığı anlamalarına gerek yoktur. Anlama ihtiyacı, kaynakları, maliyeti ve riski.

Kaynak kodu sürümleri, kod kalitesi, karmaşıklık, vb. PM sorumluluğu veya Kıdemli Geliştiricinindir.

Çözüm:

1-Proje ekibi yapısını ve sorumluluklarını tanımlar

2-Yöneticiyi kötü yönetime bağlı yazılım arızaları konusunda eğitin - Teknik detaylardan uzak durun. Bazı örnekleri googling ile bulabilirsiniz.


"Teknik detaylardan uzak durun." Direnmeye çalışacağım. ;) Bunu işaret ettiğiniz için teşekkür ederiz.
Orman Avcısı,

0

Özellikle de kodumdaki gelişmeleri işaret edecek hiç kimse olmadığı için.

Kod incelemeleri oluşturmayı denediniz mi? Böylece koda bakan insanlar olabilir. Yasaya bir yapı kazandırmaya yardımcı olacak sözleşmeler ve standartlar var mı? Bu, elbette ki oradaki tek geliştirici olmadığını farz ediyor.

Muhtemelen harika bir yerden daha az bir yerdeyken, sonunda çalışıyor gibi görünüyor mu? Projeler bitiyor mu ve işler ilerliyor mu? İşler yapılıyor mu? Koli Bandı Programcısı okumak isteyebileceğiniz Joel makalesi olacaktır.


Takımımı, koduma bakabilecek kişilerden birine değiştirmeyi düşünüyorum. Veya kodumu incelemek için oradaki kişilerle iletişim kurmaya çalışın. Sorularda söylediğim gibi, şu anda bunu yapacak kimse yok.
Orman Avcısı,

0

Seçenek 1 - onlara “bu projede yaptığınız tüm değişikliklerle birlikte, onu devreye aldığımızda sistem çok yavaş çalışacak” veya “müşteri bunu çözemez” deyin. Yöneticileriniz spagetti kodunu umursamıyor ama müşteriyi umursuyorlar. Problemi, kod yazma açısından değil, neyi anladıkları ile ilişkilendirin.

Seçenek 2 - onlara istediklerini verin. Bir şeyden şikayet ettikleri zaman 'ama istediğin şey' diyorsun.


"Koşmadan" tam olarak bunu yapacağım. Değişim istiyorlarsa onlara burada küçük bir değişiklik olmadığını söyleyeceğim ve orada çok daha fazla zaman alacaktır. Müşteri mutlu görünmüyorsa, şikayet edecek bir şeyleri olmayacak çünkü onlara istediklerini verdim.
Orman Avcısı

jungle avcısı - Herkes işini bırakma seçeneğine sahip değildir, bazen durumu aşmanız gerekir. Delilikle başa çıkmanın en iyi yolunu, onu çılgın insanlara geri döndürmektir. Sadece çılgınlar kendi çılgınlıklarına karşı çıkabilirler. iyi şanslar.
jqa
Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.