Meslektaşlar süreci ihmal ettiğinde nasıl ayakta durulur?

Karşılaştığım sorun:

1. Ekip üyelerim fonksiyonel / teknik belgeleri hazır olmayan projeler üzerinde çalışmaya başlar - şirket sürecimiz başlamadan önce bunların orada olmasını gerektirse bile.
2. Ekip üyelerim ucuz, yapılandırılmamış çözümleri kabul ediyor ve proje yönetimi 'sınırlı zamana sahip olduklarını' iki kez düşünmeden yazılıma gerçekten kötü korsanlıklar uygulayacaklar .
3. Ekip üyelerim, başka bir ekibin tamamlanmamış ve tamamlanmamış bir projesiyle birlikte çalışan projeler üzerinde çalışmaya başlar. (ekstra işlere neden olur).
4. Yazılımın geliştirmeleri ve tüm aşamaları düzgün bir şekilde planlanmamıştır ve arka uç geliştiricinin çalışmaya başlaması gerektiğinde genellikle ön uç / tasarım tamamlanmaz.

Bu sorunlar burada çalışmaya başladığımdan beri defalarca tartışıldı. Herkes hemfikirdi ve sonuç olarak , süreci uygulamamız gerekiyordu , bu da arka uç geliştiricinin her şey halledilmeden başlamayacağı anlamına geliyordu.

Bu sorunlar devam ediyor - işin kendisi ve bazı meslektaşlarımdan gerçekten rahatsız olduğum noktaya kadar gerçekten motive oluyorum.

Ekip üyelerim çok şikayet ediyorlar - ama sadece birbirlerine karşı. They keep on going - whatever the situation is. Sonuç?

1. Güvensizleşiyorum, belki de o benim?
2. İşlerin böyle gitmesi mi gerekiyor?

Benim sorum? How can I say no against work ignoring the process if everyone else seems to mindlessly accept?.

Bu her zaman orospu için bir şeyler arayan bazı can sıkıcı bir geliştirici gibi görünmeden.

Herkes gerçekten aynı fikirde mi?

Bir zamanlar süreçleri iyileştirmek istediğimiz bir durum yaşadım. Farklı bir Sürecin önerisini yaptık ve herkes aynı fikirde görünüyordu.

Ama sonra, bu süreci her takip etmek istediğimde, 'daha önemli meseleler' nedeniyle, ilk görüşte her zaman makul görünen bir istisna vardı. Dolayısıyla, Etkide, süreç hiçbir zaman fiili olarak izlenmedi, ancak herkes 'prensipte, süreci takip ediyoruz' diye düşündü.

Sorun şuydu: eğer bir iyileştirme teklif ederseniz, kim katılmıyor (kim iyileştirmeyi sevmiyor?). Ancak maliyetleri sunarsanız, genellikle çok fazla anlaşmazlık vardır. Ve bir şeyler yapmak için uygun yolu kaybetmek çoğu insan için büyük bir maliyettir.

Bunu göstermek için, Soruyu farklı şekilde ifade ettim: 'Lütfen yapmam gereken her şeye öncelik verin (özellikleri uygulamak, hataları kaldırmak, iyileştirilmiş işlemi takip etmek, masayı temizlemek, zamanında varmak').

Süreci takiben masanın temizlenmesi ve 5 dakika geç kalmamanın arkasında sona erdi. Yani, temelde, önerdiğimden tamamen farklı bir şey üzerinde anlaştılar.

Sorun, kalite için maliyet ödemek istememeleri olabilir. Bu onların eleştirmeni sızlanma olarak akılcı hale getirmelerine neden olabilir , ama benim deneyimime göre, öyle değil. Teknik borç o kadar görünür olmayabilir ve bunu koşullara atfetmek kolaydır, ancak sonunda gerçeklik ortaya çıkar.

Umarım, o zamana kadar bunu fark ettiler ya da siz İşleri değiştirdiniz.

Belki de sensin

Çok yapılandırılmış ve organize bir kodlama tarzını tercih ediyor gibi görünüyorsunuz, takım arkadaşlarınız daha "işleri hallet" yaklaşımına sahip gibi görünüyor. Şimdi bunun "boşa harcanan zamanın" birçoğuna yol açtığını söylüyorsunuz, bu yüzden belki de bazı yapılar düzenli ve özensiz iş için bir bahane yok. Bununla birlikte, yazılım projeleri akıcı olma eğilimindedir ve çok fazla yapının uygulanması da bir çok organizasyonel yüke neden olacaktır.

Belki de hepiniz ortada buluşmalı ve daha çevik ve etkileşimli, ancak yapılandırılmış bir yaklaşım denemelisiniz.

Bu insanlardan kim sorumlu? Birisi onları işe aldı ve birisi onları kovabilir / sorumlu tutabilir.

"Şirketim gerektiriyor ..." bir zorlama olmaksızın anlamsız.

Üretim sürecine izin vermeyen zaman talepleri yapamazsınız.

Bu kontrol eksikliği ve gerçekçi olmayan beklentiler kalitesizliğin nedenleri gibi görünüyor.

Aşağıdakilerden birini yapabilirsiniz: ayrılabilir, baş geliştirici olabilir, hiçbir şey yapamaz veya sizin gibi hissettiğiniz kişilerle çalışmaya başlayabilirsiniz. Birisi daha iyi bir yol bulana ve bunları değiştirene kadar herkesin doğru prosedürleri uygulayacağınızı bildiğinden emin olun. "Elma Şarabı Ev Kuralları" gibi geliyor.

İş arkadaşlarınızın tamamen farklı bir süreç izlemelerini istemiyorsunuz, sadece farklı kararlar vermelerini istiyorsunuz. Elbette, ne yapmaları gerektiğine dair kurallar (yönergeler?) Var ve onları görmezden geliyorlar. Ancak tarif ettiğiniz sorun, bir karar vermeleri (proje üzerinde çalışmaya başlamak veya bir spesifikasyonu reddetmek) ve devam etmeye karar vermeleri. Eğer kuralları hatırlatmaya devam ederseniz bu karar değişmez; kurallar sizin kadar önemli değil . Yararlı hissetmek istiyorlar ve hayır demek kendilerini faydalı hissetmiyor .

Davranışlarının değişmesini istiyorsanız, kurallara sürekli olarak hatırlatmak muhtemelen çok etkili değildir; sizi görmezden gelmelerine yol açar. Süreci takip ederken daha kullanışlı hissetmeleri için süreci değiştirmenin bir yolunu bulmaya çalışın. Bilgisayar korsanlarının üretim koduna geçmesini önlemek için bir tür kod incelemesi yapabilir, birbirinizin kodunu kontrol edebilir ve birbirinden öğrenebilir misiniz? Özelliklerin (docs / ext.interfaces / front-end) siyah-beyaz bitmiş / bitmemiş bir karardan ele alınma şeklini, geliştiricinin istediği spesifikasyonun sonuna yakın bir yerde daha işbirliğine dayalı bir işleme değiştirebilir misiniz? yardım bitirir mi? (Ve gereksinimlerin değişeceğini kabul etmelisiniz )

Çoğunlukla sen değilsin, onlar değil, süreç. Siz (ve Başbakanınız) insanların karakterlerine karşı çok fazla uğraşmak zorunda kalmadıkları şeyleri organize etmenin bir yolunu bulabilirseniz, süreç çok daha hızlı takip edilecektir.

Bu, takım liderimle kapalı bir kapı oturumuyla check-in yaptığım nokta hakkında. Umarım bu çok gayri resmi yapabilirsiniz kurşun ile yeterince iyi bir çalışma ilişkisi var.

Toplantının amacı , ekibin neden işleri yaptıkları gibi yaptığını anlamaktır. Herkes bir araya geldiyse, başını salladı, gülümsedi ve yeni bir süreci kabul ettiyse, neden hala değişmiyorlar? Muhtemelen umursamaz olmama veya yetersizlikten çok daha derine inme şansı yüksektir. İşyerinde çıplak gözle görülemeyen sürücüler olması muhtemeldir.

İş arkadaşlarınızın, eğer yapabilirlerse, daha az panik, daha az teknik borç ve daha fazla ürün kalitesi sağlayan bir süreç izleyeceklerini varsayarak toplantıyı başlatın - sonuçta kim istemez ki? Peki görünmeyen kuvvet nedir?

Görünüşe göre tasarım ve kullanıcı arayüzü prototipinin önündeki çalışmalardan önce çok fazla uygulama / entegrasyon var gibi görünüyor. Şirket, bu işi yapabilecek insanlara açık değil mi? Belki gönüllü olabilirsin. Paydaşlarla fikir birliği içinde bir sorun var mı? Belki de ekibiniz onlarla iletişim kurmanın yeni bir yolunu bulabilir veya varsayımları belgelemek için yeni bir yaklaşım benimseyebilir.

Eğer birisine başlayarak neden liderlik yaptığınızı sorarsanız, o zaman savunmasızlığı önleyen ve sorunlara ve çözümlere odaklanan bir tartışmanın kapısını açabilirsiniz.

Başka bir hile, bir şeyler yapmanın yeni bir yoluna öncülük yapıp yapamayacağınızı sormak olabilir. Ekibinizden destek alın, sorunu biraz zorlayın ve savunduğunuz yaklaşımı benimsemenize izin verin - "sistemi" satın alırken muhtemelen sorunlar ortaya çıkacaktır, bu yüzden arkanızdaki yönetimi istiyorsunuz. Ancak, daha üretken ve stressiz hale gelirseniz, şeylerin yolunu değiştirmek için iyi bir durum sağlarsınız ve muhtemelen savunucular kazanabilirsiniz.