Genç ve ölmekte olan bir proje nasıl kaydedilir?

Bunu anonim olarak gönderiyorum çünkü potansiyel sorunlara girmek istemiyorum.
Büyük bir problemim var.
Geçenlerde bir yaşından küçük bir takıma katıldım. Projeye başladığım aydan beri buradayım. Şirket yapısı şöyle:

• Sahip (teknik olmayan)
  • Proje Yöneticisi (teknik olmayan)
    • Baş Geliştirici (Teknik, ancak kötü)

Bu proje, Baş Geliştirici'nin korkunç bir mimari tasarladığı ASP.Net kullanan bir web sitesidir. Sözlerime bir göz atmanız gerekecek, ancak temel olarak, web sayfaları oluşturmak için gerekli olan yöntem, Hata Ayıklama modunda VPN üzerinden tek bir web sayfasında bize 3+ dakika yükleme süresi vermektir.

Diğer çalışma arkadaşlarının günlerini daha fazla sayfaların yüklenmesini gerçek gelişmeden bekleyerek kabul ettikleri noktaya geldi.

Şimdi asıl sorun bu. Proje Yöneticisi teknolojiyi bilmiyor ve kabul ediyor. Özel olarak Baş Geliştirici'ye uygulama mimarisinde doğru seçimleri yapma konusunda güvendiğini belirtti.

Ekipteki hiç kimse, Sahiplerin görüşünün ne olacağını bilmiyor, ancak herkes bu ekonomide (özellikle kendim) dalgalar yapmaktan korkuyor.

Sen ne yapardın?

Bu sorun, teknik olmayan terimlerle proje yöneticisine gösterilebilir. Sitenizi Başbakanın önündeki bir tarayıcı penceresine koyun ve bir süre onunla oynamasını isteyin. Yaklaşık iki sayfa yüklendikten sonra, söylediğiniz kadar kötü bir şey varsa, baş geliştirici halı üzerinde çağrılmalıdır.

PM neden kötü olduğunu anlamak için özel bir geliştirme bilgisine sahip olmayabilir, ancak kendisi için genel bir web sitesi kullanıcısı olarak görebilir. Benzer bilgileri gösteren diğer siteler, zamanınızın çok kısa bir bölümünde yüklenir ve sizinkiler, yan odada bulunan sunucudan yerel ağ üzerinden yüklenir.

Bu uçmazsa, sahibine gidin. Sahibinin para adamı, ama kimsenin ziyaret etmeyeceği yavaş bir web sitesinin == para olmadığını çok çabuk görebilecektir. Aynı gösteriyi hazırlayın ve ilk sayfa yüklenmeden önce çok daha fazla halının üzerinde PM ve Lider araması gerekiyor.

Bir erkeğin dalga yaratmasından endişe ediyorsanız, endişelerini dile getirmek için birden fazla geliştiriciye sahip olun. Dürüst olmak gerekirse, sizinki kadar düz bir şirkette, geliştirdiğiniz ürün bir bomba ise, ister konuşun ister sessiz olun, işsizsiniz. Bu şekilde baktığınızda, şirkette birkaç hafta veya aydan fazla kaybedecek bir şeyiniz yok. Bu bir sorunsa, bazı "diş hekimi randevuları" planlayın ve endişelerinizi yayınlamadan önce yeni bir iş arayın, bu nedenle bu işi kaybederseniz bir sonraki pazartesi başlayacaksınız.

İfadelerinizin doğru olduğunu varsayarsak, beceriksiz bir Baş Geliştirici ve beceriksiz bir Proje Yöneticiniz vardır (en azından ekibin becerilerini alamayacağı derecede). İnce. Dünyanın her yerindeki her takımdaki geliştiricilerle tam olarak aynı seçeneklere sahipsiniz.

1. Şirketin sağlığına önem vermeden iş yapıyor musunuz?

2. Başka bir yerde iş arayın.

3. Lead, PM ve Owner'a makul önerilerde bulunun ve benimsenmelerini umuyoruz.

Yukarıdakilerin herhangi bir kombinasyonunu aynı anda yapmakta özgürsünüz.

Projenin sağlığını agresif bir şekilde sigortalamak istiyorsanız, boş zamanlarınızda yeni bir çerçeve oluşturmak için diğer geliştiricilerle çalışmanız ve ekibin geri kalanına neden daha üstün olduğunu ve eski çalışmanın onun lehine olmak.

Aslında şirkette ortak olan lider geliştiricinin yazılımın "çekirdeğini" yarattığı ve doğrudan onunla çalışan yakın bir arkadaş dışında, diğer geliştiricilerin çekirdek.

"Güçler" her modül gibi kurallar da oluşturmuş olabilirler, çünkü bu şekilde daha temizdir. Ve bunun sonucunda, var olan açılır listeler, ayrı bir tablo yerine veritabanındaki tablolardan "DISTINCT" seçilerek oluşturuldu.

Uygulama ekibi işi halletmek zorunda kaldığı ve ürün kutudan çıkmayacağı için etrafta bir dizi kötü yama vardı. Bu yamalar, düzelttikleri kadar çok soruna neden oldu ve her yükleme için özelleştirildi (saldırıya uğradı).

Benim yaklaşımım, çekirdeğin desteklemediği ve onun için küçük, iyi, genel bir yama yazmadığı özelliğin küçük bir kısmını almaktı. Uygulama ekibini tatmin eden, ancak "Düşüncemizi tamamen değiştirmemiz gerekiyor" kadar tehdit edici olmayan bir şey. Uygulama ekibi ve çekirdek geliştiriciler arasındaki düşmanlık nedeniyle, uygulama ekibini yaklaşımımın saldırılarından daha iyi olduğuna ikna etmek aylar aldı. Ama bir kez onları dinleyeceğimi ve onları desteklemek için ek ayarlamalar yapacağımı gördüklerinde, çok sevindiler ve benim tarafımda. Baş geliştiricinin yamayı kabul etmesi bir ay daha sürdü, ancak bir kez yaptıktan sonra, sistemin diğer bölümlerini tasarlamanın daha iyi yolları hakkında hepimiz arasındaki iletişimi gerçekten açtı.

İnsanların düşüncelerini değiştirmek için asla kısa bir yol değildir, özellikle de onlarla sivil bir ilişki sürdürmeniz gerekiyorsa. Ancak doğru yaklaşırsanız, patronunuza hakaret etmeden saygı kazanabilirsiniz.

Umarım yardımcı olur!

Çok basit cevap ve çözüm. Herkesin sorunun farkında olduğu anlaşılıyor. Bu nedenle, soruna işaret ederek etrafınızda dolaşmanın kimseye bir önemi yoktur. Aslında sadece bir sızlayıcı gibi görünmenizi sağlar. Değer katmak istiyorsanız, çözümü belirtmeniz ve çözümünüze geçmek için iş vakasını oluşturmanız gerekir. Daha sonra sorunu ilgili bir çözümle gösterebilirsiniz. Bir demo da çözümünüzü kanıtlamak için uzun bir yol kat edecektir. Tabii ki, bu kendi zamanınızda çalışmak anlamına gelebilir, ancak hepsi sizin de ne kadar önemli olduğuna bağlıdır.

Her şeyden önce, VPN yapılandırmasında bir şey değil, bir uygulama mimarisi sorunu olduğundan, gerçeklerinizden emin olmanızı şiddetle tavsiye ederim. Kötü yapılandırılmış VPN'lerin bu soruna neden olduğunu gördüm. Uygulamanın ofis içinde bu kadar yavaş olduğunu kesin olarak biliyor musunuz?

Ağı dışladıysanız, KiethS önerisiyle gidip PM'nin sayfayı yukarı çekmesini istiyorum.

Kulağa iş gibi geliyor, ya da en azından proje kısa bir süre sonra sona erecek. Bırakma gibi kısa bir sürede kendimi olabildiğince çabuk uzaklaştırmaya çalışırdım. Gönüllü / talepte bulunan diğer projelerde çalışma. Umarım zamanla, bu felakete daha az ve çalışma şansı olan diğer projelere daha fazla zaman harcarsınız. 'Projede çalışmayan adam' olarak düşünülmek istemezsiniz. Her şey itibarınızı korumakla ilgilidir.

Ürün sahibi iyi bir ürün mü istiyor, istemiyor mu? Cevabın "Evet" olduğundan şüpheleniyorum ... ve bu yüzden konuşmanız gerekiyor. Mevcut mimariyi belgelemeniz ve daha sonra (iyi imperik verilerle), ürünün uygun performans beklentilerini karşılamadığını göstermeniz gerekir. İş arkadaşlarınızın kötü performans gösterdiğini bildiğini söylüyorsunuz - iyi ... ya müşteri? Onlar ne diyorlar? Bir performans ölçüm aracı kullanın ve neyin bu kadar uzun sürdüğünü belirleyin. Birçok araç, her bir işlev çağrısının ne kadar sürdüğünü göstermeye bile gidecektir. Tüm bu verilerden, proje yöneticinizle konuşmanız için yeterli mühimmatınız ve işlerin neden olması gerektiği gibi olmadığı ve ürünün hızını arttırmak için bazı büyük yeniden düzenleme işlemlerinin nasıl gerekli olabileceği konusunda teknik ipucunuz olmalıdır.

Sonra (sadece Başbakanla ve liderle konuştuktan sonra), bu bazı değişiklikler yapmaya başlamak için yeterli OLMALIDIR. Başbakan bu noktada ikna olmamışsa, buranın gerçekten olmak istediğiniz bir yer olup olmadığına karar vermeniz gerekir. Eğer öyleyse, muhtemelen sahibi ile bir toplantı. Değilse, özgeçmişinizi hazırlayın.

Yolun her adımını belgelediğinizden emin olun.

Teknik açıdan yukarıdaki önerileri kabul ediyorum. Öte yandan, bunun teknik bir sorundan ziyade bir ilişki meselesi olduğunu hissediyorum.

Düzgün bir rota izlemek istiyorsanız, baş geliştirici ile konuşmak uygun bir seçim olacaktır. Yine de ofiste konuşmazdım. Dışarıda bir kahve içmek işleri biraz resmi olmayan ve daha rahat hale getirecektir.

Bu işe yaramazsa, önce PM sonra da sahibiyle konuşmayı deneyebilirsiniz.

Hiçbiri işe yaramazsa, yeni bir iş aramanızı öneririm.

Dürüstlük - ve toplayabildiğin kadar incelik.

Baş geliştirici ile başlayın ve gerekiyorsa çalışın. Kişiliğinin daha iyi taraflarını anlamaya çalışın - Eğer devleri problemleri çözmeyi seviyor / günü kurtarmayı seviyor / verimli olmayı seviyor / vb. Bu konuda sorunu ifade ediyorsa - geçmişte ek motivasyon olarak başarılı olmuşlardır.

Eğer bazı dalgalar yapmıyorsanız muhtemelen suda ölmüşsünüzdür.

Sorunları, proje yöneticisi ve sahibinin anlayabilmesi için ölçülebilir ve teknik olmayan bir düzeye getirmek mümkün müdür?

Örneğin, 3+ dakikanın yavaş yükleme süresinden bahsettiniz, spesifikasyonda bir yerde bir performans gereksinimi olduğunu varsayalım, "1sn içinde yüklenecek sayfa" kadar basit bir şey. Böyle bir şey ölçülebilir ve çürütülemez. Bu sorunun temel nedeninin tehlikeli mimari olduğu tespit edilirse, proje yöneticisi ve / veya sahibinin bazı değişiklikleri zorlamak için adım atması gerekir.

Değilse, şirketinizde ilk analizin kötü yapıldığı sistematik bir sorununuz var ve bu tür sorunları yakalamak için yeterli süreç yok. Atlama gemisi düşünün!

Gerçek erkekler kızgınlık veya duygu olmadan konuşurlar. İşte bu hile.

Birinin konuşmak için sizinle çapraz olabilmesinin tek geçerli nedeni, kırgın olarak karşılaşmanızdır:

KURŞUN GELİŞTİRİCİNİN YAPABİLECEĞİ MÜCADELESİ YOK. Bunun olacağını biliyordum, ama kimse beni dinlemedi.

buna karşılık

Kod modeli yanlıştır çünkü bakımı ve yavaşlaması zordur. Bunun ilerlemesi konusunda stratejik olmamız ve bu iki sorunu düzeltmemiz gerekiyor.

Birincisi yok etmek için bir savaştır, ikincisi barış için bir savaştır ve uzun vadede bir kişinin dürüst olduğu için saygı duymasını sağlar.

Eğer proje yöneticisi bunu ateşe vereceğini düşündüğü bir ön plan olarak görürse,

Uygulamadan sorumlu olmadığım şeylerden beni sorumlu tutmayın. Ben sadece dürüstüm.