Bir programcı olarak iş kurallarını benimsememi ve anlamamı nasıl hızlandırabilirim?

Bir süredir geliştiriciyim. Dışarıdaki en iyilerden uzakım. (Bu odada tek başıma otururken, burada en iyisi olup olmadığımı merak ediyorum.) Ancak, araçlarımı anlamaya başladım ve akıl yürütme ve öğrenme yeteneğime güvenmeye geldim.

Yeni bir işe başlarken her zaman bildiğim bir dilse kod tabanını öğrenebileceğime inanıyorum. Bildiğim bir dil veya çerçeve değilse, kavramları öğrenecek kadar kavrayabileceğime inanıyorum (ve sadece belgeleri okuyabilirim). Bu, programcı olarak yetenek setimizin bir parçası ve bu standarda göre yaşayabildiğim için gurur duyuyorum.

Tüm bunlar için, - en büyük zayıflığımdan biri, çalıştığım müşteri için iş kurallarını hızlı bir şekilde öğrenmek ve içselleştirmek - ücretli bir çalışan veya yüklenici olsam da. Kod tabanları ile iyiyim, ancak belirli bir işletme için iş kuralları ve süreçleri her zaman tam olarak anlamak için biraz zaman alıyor gibi görünüyor. (Örnek olarak, bu, kurumsal uygulamaları yeniden yazarken bir trip olabilir.)

Bir geliştirici olarak, iş kurallarını ve süreçlerini hızlı ve verimli bir şekilde özümsemenin en iyi yolu nedir? Bir konu uzmanı olmadan veya sadece müşteri, şirket veya iş ile yıllarca deneyime sahip olmadan mümkün mü?

Benim için, kod tabanlarını okuyarak ve anlayarak.

Bunu iki temel nedenden dolayı söylüyorum:

1. İnsanlar berbat. Ah, kasıtlı olarak değil (genellikle), ama iş dünyasında insanların iş kuralları hakkında genellikle farklı bir anlayışa sahip olduklarını gördüm. Ve herkesin kendi zihinsel modeli vardır, bu da size iletmeye çalışırken sadakatini kaybeder. Ancak kod yalan söylemez. İnsanlar, işlerin nasıl çalışması gerektiği hakkında ne istediklerini düşünebilirler , ancak kod doğrudur.

2. Önce bir temel oluşturun. Herkesin bu işe özgü terim ve süreçlerin ne olduğuna dair kendi zihinsel modeli varsa, sizinkini nasıl oluşturursunuz? Benim için ve birçok programcı için zihinsel modellerimi en iyi koddan inşa ediyorum. Kod kalıpları vardır. Kod soyutlamaları vardır. Kod alma ve ondan zihinsel bir model oluşturma konusunda çok deneyimim var. Ben şeyler var neyi en azından belli belirsiz bir şekle sahip ve onlar ile nasıl, bir kez daha sonra ben iş adamları konuşabilirsiniz. Sonra doğru soruları sorabilirim ve cevaplarını bulmacanın içine daha iyi sığdırabilirim.

Kendiniz için çok zor olma. Bazen neden onlara iş "kuralları" demeyi zahmet ettiler acaba ama sanırım onlara "başka şeyler yaptığımız sürece, tipik olarak bir şeyler yaptığımız yolları" diyoruz ki, onları farklı şekilde yapıyoruz "muhtemelen onlara hakaret eder. İş dağınık. Müşterilerin, yasal kurumların, muhasebe, düzenlemeler, satıcılar, çalışanlar, yöneticiler ve yerel yönetimin ihtiyaçlarını dengeliyorlar. Her zaman bir nedenleri yoktur.

Bence en iyi yol, olabildiğince çok iş insanıyla zaman geçirdiğinizden emin olmaktır. Teknik pozisyondaki bazı insanlar için bu zor olabilir.

1. Zaman ayırın ve onlara saygılı olun, ancak olabildiğince çok olsun.
2. Soru sorman gerekecek. Programcılar gibi düşünmüyorlar ve her şeyi yıkıyorlar ve bilginin birbiriyle nasıl ilişkili olduğunu tam olarak anlıyorlar.
3. Anladığınız gibi sahte olma. Eğer diğer iş adamları kadar bilseydiniz, her iki işi de yaparlardı. Bkz. # 2.
4. Doküman beklemeyin. Hiç alırsanız çok övgü sunun.
5. Eleştiriye devam et. İşlemler ve prosedürler fazlalıklara ve diğer potansiyel inn verimliliklerine sahip olabilir, ancak bunun bir nedeni olabilir. Nedenini öğrenin, ama "Bunu hep böyle yaptık" derken şok olmayın.
6. Nazik olun, nazik olun ve atıştırmalıklarınızı paylaşın. İnsanlarla uğraşıyorsun. Merhaba de. Nasıl yaptıklarını sorun. Neden sektöre girdiklerini, şirkette ne kadar süredir bulunduklarını sorun.

Programcı denen bir boşluk değilsin, sen bir insansın. İşlerini kolaylaştırmak için orada olduğunuzu bilmelerini sağlayın. Ne yazık ki, kahraman veya keçi olabilirsiniz. Bu bizim işimizin doğası.

Edward Burger ve Michael P. Starbird'ün Etkili Düşünmenin 5 Unsuru adlı bir kitap okumanızı tavsiye ederim. Genel olarak yeni kavramları anlamakla ilgili ama bence bu durum için geçerli.

İşte kitaptan bazı ilginç noktalar:

Temel konularda uzmanlaşın

Temel bilgileri bilmiyorsanız, anlayışınızı titrek bir temel üzerine inşa edeceksiniz. Bu yüzden kimsenin sormadığı aptalca soruları sormanız gerekiyor.

Hatalar rehberiniz olsun

Bazen anlamadığınız eksiklikleri ortaya çıkarabilmeniz için açıkça yanlış olan sorular sormaya yardımcı olur. (Örn: Yani yöneticilerin her belgeye erişimi var mı? Ah. Neden?)

Öğretin veya başkalarına açıklayın

Başka birine öğretmeye çalıştığınızda, anlamakta zorlandığınız yerleri ortaya çıkarmaya başlayacaksınız.

Umarım yardımcı olur!

Geliştirici olarak, işi doğrudan koda, veri yapılarına, olası sınıflara, vb. Derhal kodlamaya başlıyorum ve bilgi eksikliği beni sık sık refaktörlere götürüyor. Her refactor beni bu işi anlamamda çok fazla boşluk olduğunu düşündürüyor .

Bunu nasıl çözmeye başladım?

Kendimi fonksiyonel analiz ve önceki aşamalarda yapılan tüm belgeleri okumaya zorlarım. Müşteri veya son kullanıcı olduğum için yapmaya çalışıyorum . Bu tür uygulama ve gereksinimlerle müşterinin ne aradığını anlamam gerekiyor. Ama olduğum cihazdan uzak durmam gerekiyor.

İşimiz bize müşterilerin sahip olmadığı büyük bir beceri sağlıyor. Koşullu yapılarda başkalarının yapmadığı bir şekilde düşünüyoruz. Bu yüzden gereksinimleri karşılamaya başladım. Çelişkileri veya tutarsızlıkları aramak . Anladıklarımın etrafında biraz beyin fırtınası. Varsayımsal senaryolar oluşturmak.

Beni sorulara ve kuşkulara götürüyor. Herkesi yazdım ve sonunda şüphelerimi çözebilecek kimseyle bir toplantı yaptım.

Özetle bakış açımı değiştiriyorum. Soruna başka bir açıdan bakmaya çalışıyorum. Ama süreçteki bazı geliştiricilerin becerilerini koydum. Ne çözülecek iyi bir grup soru ve şüpheyle sonuçlanır. Çözüldükten sonra, iş hakkındaki anlayışım daha derin.

Etüt> Şüpheler> Sorular> Cevaplar> Anlama (döngüyü tekrar tekrar)