İş arkadaşlarımı işleri doğru yapmanın zaman kazandıracağına nasıl ikna edebilirim?

Geçenlerde bir avuç programcı ile yeni bir şirkete başladım. Onun orta ölçekli bir şirket, yaklaşık 70 çalışanı ile, ama BT sadece 9-10 vardır ve benim yanında 3 "programcı" vardır. Ancak, bu adamlar çok sınırlı deneyime sahiptir ve gerçekten çok şey yapıyorlar. Örneğin, projelerimizden biri bir PHP web sitesidir. Kodun büyük bir kısmı 20.000 satırlık bir PHP denetleyicide saklanır ve PHP'de ~ 6000 satırlık JavaScript gömülüdür.

Burada ve orada küçük önerilerde bulunmaya devam ediyorum ama kimse dinlemiyor, herkes önerilerimi uygulamak için çok meşgul olduklarını söylüyor. Mesele şu ki, bu kadar meşgul olmamalılar ve işler doğru yapılsaydı olmazlardı. Zamanlarının çoğunu kırmaya devam eden şeyleri düzeltmek için harcıyorlar. Her proje doğru bir şekilde inşa edilmişse, hepsini kendim yapabilirdim.

Bu adamları veya yöneticiyi işlerin değişmesi gerektiğine ve değişen şeylerin bir sürü zaman kazandıracağına ikna etmek için hangi yaklaşımı benimsemeliyim? İşlerimi ikna etmeye çalışmayı atlamalı mıyım ve doğrudan doğruya yöneticiye gitmeli miyim, eğer bir şeyler doğru yapmaya başlarsa şirketin bir sürü paradan nasıl tasarruf edeceğine dair bir iş önerisi mi?

Özensiz çalışmanın birincil nedeninin, programcının dışında sadece umursamaz değil, bilgi eksikliği olduğunu buldum. Ne yazık ki pek çok ortamda, bilgi eksikliği açıkça tartışılmak yerine gözden geçirilmektedir.

Tartışma, büyüme ve programlama hakkındaki genel heyecanı teşvik etmek için başarıyla kullandığım bazı teknikler:

• Haftalık kahverengi çanta teknik oturumları (Bir konuyu araştırmasını ve sunmasını sağlayın).
• Küçük veya kıdemli üyeler arasında günlük veya haftalık bire bir mentörlük oturumları.
• Kod incelemeleri (hatalara işaret etmeyerek, öğrenmeye vurgu yaparak).

Öğrenme bulaşıcıdır. Öğrenmeyi teşvik eden bir ortamı teşvik ettiğinizde, sadece daha iyi geliştiriciler üretmekle kalmaz, aynı zamanda ekibinize başkalarına maaş alma yönteminden daha büyük bir şeyin parçası olduğunu gösterin.

Sr. PHP dev olarak işe alınmış ve işiniz bir şeyleri düzeltmek olduğunu gördükten sonra, bazı kas esneme zamanı olduğunu öneririz.

Eğer senin yerinde olsaydım, kodun iyi bir araştırmasını yapardım ve tekrar tekrar yapılan hataları görecektim. Ekiple bu şeyleri gözden geçirmek için her hafta toplantı saatini engelleyin. Parmakları veya ad adlarını işaret etmeyin, sadece bu görevin nasıl doğru bir şekilde yapılacağını gösterin.

Daha sonra, düzeltilmesi gerektiğini gördüğünüz için bir liste yapın. Hızlı ve kolaysa, yapın. Eğer hayatınızı kolaylaştırırsa ... yapın. Yapılması gereken tüm şeylerin bir listesini yapın ve onlar için bilet yapın ve insanların ne zaman döngüleri olduğunu görün. Birisi sorunlu bir alandaki bir hatayı düzeltiyorsa, nasıl düzgün bir şekilde düzeltileceğini öğrenin.

Büyük bir değişiklik gerektiriyorsa, ekip ve paydaşlarla birlikte oturun ve seçenekleri tartışın.

İnsanlara yardım edeceğiniz bir açık kapı politikasına sahip olun. Korkutmayan ve eğitmeyen biri olun. Hayır, "bu şekilde yapmalısın" ve daha fazlası "bu şekilde yapılsaydı daha iyi olurdu". Önerdiğiniz şekilde yapmanın avantajlarını ve yapıldığı yolun dezavantajlarını açıklayın. İnsanlar yollarının yanlış olduğunu söylemek yerine bir şey öğrendiklerini düşünürlerse bunu doğru şekilde yapmaya daha istekli olacaklar ve bunu söylediğiniz başka bir yolla yapacaklar.

Yönetimin Soruna Bakış Açısı Kusurların miktarıyla ilgili olarak gelişme zamanını kabul ettiyse, neden riske alasınlar ki? Uzun vadeli faydalar kısa vadeli hedeflerle çeliştiğinde, genellikle kaybederler. Onlardan kısa bir adım geri almalarını istiyorsun. Bunun uzun bir gecikmeye neden olacağını düşünebilirler. Bunları, ek avantajlarla birlikte olmayacağına ikna etmelisiniz. Eğer bir karmaşaya sahip olduklarını düşünmezlerse, onlardan her "düzeltme" ile yeni hataları hızlı bir şekilde tanıtmanın neden bu kadar uzun sürdüğünü açıklamalarını isteyin.

Kod kalitesi birçok koşul ve duruma bağlıdır. Satış, pazarlama ve yöneticiler, başarısız olan her son teslim tarihinin şirketin mega milyon girişim sermayesi yatırımcısında bir vuruşunu kaçıracağı anlamına gelmesini sağlayacaktır. Gerçek şu ki, bu özelliği gerçekten ihtiyaç duymayan müşterilerinizin% 1'ine kötü haberi vermek istemiyorlar. Aşırı oluyorum ve genellikle arada bir yere düşüyor, bu yüzden geliştiricilerin gerçek bir acil durumun ne olduğunu öğrenmeleri gerekiyor. Daha sonra, onları yapmak için zamana ihtiyaç duymak yerine doğru zaman almaya ikna etmek daha kolaydır. Riskleri anlamalısınız.

Harika bir roman gibi, kod ilk kez iyi yazılmıyor, ancak ne yazık ki hala çok sık yayınlanıyor. Bir kodlama standardı oluşturmak gibi temel bir şeyle başlayın. Herkesin bir tane vardır, ama çoğu sizin durumunuzda olduğu gibi, resmileştirilmemiştir veya çok katı değildir. "Ne istersen onu yap." bakımı çok kolay bir standarttır. Bir sonraki adım, standartlarınızı nasıl koruyacağınızı belirlemektir.

Önünüzde büyük bir görev var. Belki de birkaç büyük programcı, kodlarının kalitesinden ödün vermek ya da teknik borca ​​girmek zorunda kalmadıkları ölçüde yeteneklerini ve alışkanlıklarını geliştirdiler, ancak bekleyin ve bu melek yatırımcı herkesin zengin olacağına söz verdiğinde neler olacağını görün.

Uygun gördüğünüz gibi gerçekten iyi bir tasarım kullanan prototipi (veya tüm proje çok büyükse bazı modülü) oturtun ve yazın. Ardından ekiple sunun / tartışın. Örnekle ikna etmek daha kolay olabilir.

Bu süreçte, bazı araçların, kütüphanelerin, yaklaşımların veya benzerlerinin o kadar da iyi olmadığını keşfedebilirsiniz. Daima önce değerlendirin ve daha sonra ekibinizden bunu kullanmasını isteyin. Standart dışı araçlar etrafında ucuz pazarlama yapmaktan kaçının.