Alan bilgisi ve teknik bilgi ne kadar önemlidir?

Bir Ticaret ve Risk Yönetimi uygulaması üzerinde çalışıyorum ve bir C # geçmişinden olmasına rağmen SSIS paketleri üzerinde çalışmam istendi. Şimdi bununla yaşayabilirim. İşin acısı, iş anlayışına çok fazla vurgu yapılması. Ticaret (Kesin olarak gerçekleşen Enerji Ticareti) BÜYÜK bir alandır ve her bir parçasını anlamak çok zor. Ancak son iki aydır, iş koşullarını anlamak için çalışıyorum - Mark To Market, Risk Metrikleri, Pozisyonlar, PnL, Yunanlılar, Araçlar, Kitap Yapısı ... her küçük detayı. Şimdi IMHO, bu bir BA'nın işidir. Geliştiricilerin işi anlamaları çok önemlidir, ancak çizgiyi nerede çiziyorsunuz?

Bu konuda müdürümle konuştuğumda, neredeyse herkesin bir teknolojiyi bir haftada öğrenebileceğini söyleyerek benimle alay ediyordu. Daha zor olan iş bu. Benim uzun vadeli arzum teknik tarafta kalmak, muhtemelen bir mimar olmak (mümkünse). İşe bu kadar odaklanmak isteseydim bir MBA yapmış olurdum!

İşin önemini anlama konusunda yanlış mı yoksa çok saf mı olduğumu veya hayal kırıklığımın haklı olup olmadığını bilmek istiyorum.

Bir programcının işi, doğal dil gereksinimlerini makine dili uygulamalarına dönüştürmektir. Sadece bir tarafta ya da diğerinde akıcıysanız, bunu etkili bir şekilde yapamazsınız. Derleyiciler veya sürüm kontrol yazılımı yazmıyorsanız, hemen hemen her programlama işi önemli miktarda programlama dışı bilgi gerektirir.

Benjol ve menajeriniz haklılar, ama ayrıntılı olarak açıklamama izin verin:

iş alanını öğrenme nasıl olduğunu sürecine değer katan ve iş için değerini artırmak

Bu, bir kod maymunu programcısı ile bir geliştirici arasındaki farktır

Üniversitemizin Bilgisayar Bilimleri Bölümünden gelen bir söz var:

Jeologlar için yazılım oluşturmak istiyorsanız, önce Jeolojiyi anlamanız gerekir. Fizikçiler için bir yazılım oluşturmak istiyorsanız, önce Fizik ile uğraşmalısınız. İşi anlamak istiyorsan, önce iş konuşmayı öğrenmelisin.

Burada, Yazılım Geliştirme'nin yaratıcı bir alan olduğunu söyleyen insanları sürekli dinliyorum. Bunun bir ölçüde doğru olduğuna inanıyorum. Bir dizi problemi çözmek için kutunun dışını görebilmek için yaratıcılığı içerir.

Bunun anlamı, sadece oturarak oturabileceğiniz ve oh ne istersen onu yaratıcı bir şekilde inşa edebileceğin. Bu, 's Mühendislik Sanat sınıf değil, ve müşterileriniz ve paydaşların bu çözer şey yaratmak beklemek olacak onların sorunları, sadece "serin" bir şey.

Bir sorunu çözmek için önce sorunu anlamalısınız. Kullanıcılarınızın kafasına girmeniz ve nasıl düşündüklerini anlamanız gerekir.

Finans, pazarlama, satış, jeoloji, fizik veya yazılımın desteklediği herhangi bir alan için yazılım oluşturuyor olsanız da, bu alanın bir parçası olmalısınız.

İşte bu nedenle, Bilgisayar Bilimleri dereceme ek olarak, aynı zamanda İşletme derecesi de kazandım; potansiyel çözümleri iletme ve başarılı ürünler sunma becerim üzerinde büyük bir etki yarattı.

Bir işletme yazılımı mühendisini işe alırken neleri arayacağım hakkında daha fazla bilgi edinmek istiyorsanız , başka bir soruya cevap olarak yazdığım bu İşletme Mühendisi İş İlanı Örneği'ne bakın .

Çok fazla alan bilgisi veya düşük seviye kodlayıcı olarak müşteri iletişimi olmadan hayatta kalabilirsiniz, ancak bir yazılım mimarı, alana çok aşina olan ve tüm paydaşlarla aktif olarak iletişim kuran bir kişidir.

Bence yanlış ve çok safsın.

Müdürünüzün dediği gibi (birazcık yanlış), bir hafta içinde herkes bir teknolojiyi öğrenebilir. Sizi öne çıkaracak ve sizi şirketiniz için faydalı kılacak tek şey iş bilginizdir. Ve ne kadar zorsa, o kadar değerlisin.

Açıkçası, eğer bu işin zihinle uyuşukça donuk olduğunu fark edersen, farklı bir şey arayabilirsin. Ancak, cennet fikriniz küçük php web sitelerini bir araya getiriyorsa, dikkat edin: Bunu yapan binlerce senaryo çocuğu olacak.

Cidden, "Ben sadece bir kodlayıcıyım, beni gerçeklerle karıştırmayın" sadece kesmeyecek.

Ben de Enerji Ticareti'nde çalışıyorum. İşletme Bilgisi işin% 90'ıdır. Bunu çözemezsin - bu karmaşık bir iş.

En azından ticaretin temellerini ve çalıştığınız pazarları anlamıyorsanız, ne kadar iyi bir kodlayıcı olursanız olun mücadele edeceksiniz.

Gereklilikleri doğru şekilde yerine getiremeyen bazı BA'larla çalışıyorum. İşi yapabilmek için kendi analitik becerilerime ve iş bilgisi anlayışına güvenmem gerekiyor.

Bence Enerji Ticareti yazılımı satan bir dükkan için çalışıyorsanız, deneyiminiz farklı olabilir - ancak Kurumsal BT enerji alım satımında temel olarak pazarın anlaşılması ve yazılımın öncelikle işletme sorunlarına nasıl çözüm sunabileceği üzerinde durulması gerekir.

Kullanılan gerçek teknolojiler ve uygulama uzak bir saniye geliyor.

Excel'in yorumunu yapan kişi yukarıdaki yorumunun ne kadar uygun olduğunu bilmiyor. Yatırımcılar genellikle kendi küçük işlem uygulamalarını Excel / VBA'da (hepsi biliyorlar) yaparlar ve ardından BT bu program karmaşasını devralır.

Bu uygulamaların bazılarını "uygun" bir dilde yeniden yapılandırmayı çok isterdim, ama bu her zaman bir öncelik değil.

Bir iş için gelişiyorsanız, iş kuralları hakkında şirketteki herkesten daha net ve ayrıntılı bir fikir edinmiş olursunuz. Bu zorunlu değil, çünkü herkes daha zeki, çünkü gelir çünkü işi yapmanın tek yolu budur.

Tepkiniz "İş analistleri ne yapar?" Olabilir.

İş analistleri, bir geliştiricinin çalışabileceği kadar açık ve net talepler almaya çalışan müşterileri ile uzun toplantılar yapar. Müşterilerle nasıl başa çıkmaları gerektiğine bakıyorum ve bunu yapmak zorunda olmadığım için minnettar hissediyorum.

Yazılım geliştirme ve mimarlık arasında analojiler çizmeyi seviyorum. Her ikisi de uygulamalı sanat. Her ikisi de kişinin zihninde ayrıntılı modelleme gerektirir. Bu soru için geçerli olan husus, işletme bilgisi olmadan yazılım yazmanın, sakinlerin yaşam tarzlarını ve ihtiyaçlarını anlamadan bir bina tasarlamak gibi olmasıdır. Bence çoğumuz güzel ve modern görünebilen ve dışarıdan değil, sadece içeriden kullanılamayan binalar gördük (hatta yaşadım / çalıştığımız) . (En kötü durumda, onlar bile iyi değil: - ((()

Güncelleştirme

Gaurav adlı kullanıcının yorumu:

merak ettiğim şey, bir geliştiricinin, iş alanını anlamak için ne kadar çaba göstermesi gerektiğidir. Tamamen o giderse, ya da çizilmesi gereken bir çizgi var.

Genel olarak herhangi bir yere bir çizgi çizebileceğinizi sanmıyorum. Uygulamanın / etki alanının parçaları olmadıkça, hiçbir zaman dokunmanıza gerek kalmaz. Uzun vadede IMHO olan gerçek hayatta çok nadir. Bir uygulamanın aktif kullanımda olan herhangi bir kısmı hata raporları ve özellik istekleri alır. Etki alanları, karşılık gelen yasalar, vergi kuralları, politikaları, alışkanlıkları - kısacası gerçek dünya - değiştiği gibi değişir. Bu da yazılımda takip edilmelidir.

Ancak dış değişiklik talepleri olmasa bile, birim testi ve eski kodu yeniden gözden geçirme, ilgili etki alanı alanlarının da anlaşılmasını gerektirir. Aksi halde, uygulamanın mevcut davranışını “gerçekten doğru olup olmadığını” bilmeden “dondurursunuz”.

Update2

[[]] geliştirici üzerinde çalıştığı işletme alanını sık sık değiştirirse?

Elbette bu, iş bilginizi kazanmak için yaptığınız yatırımın (zamanınızın ve işvereninizin parasının) büyük bir kısmının kaybolduğu anlamına gelir :-( Bunun olacağını biliyorsanız, elbette çok derine inmeye değmeyebilir. Ancak, etki alanlarının tamamen farklı olmadığını, farklı etki alanları arasında yeniden kullanılabilecek temellerin olduğunu ve en önemlisi, kazandığınız etki alanı odaklı tasarım yaklaşımının yeniden kullanılabileceğini unutmayın.

Bankacılık sektöründe on yıldan fazla bir süredir ticaret uygulamaları geliştirmek için çalışıyorum ve geliştiricilerin işi iyi anlayabilmelerinin önemini kabul ediyorum. Ancak, tekrar tekrar görüşme işlemleri sırasında, kişi işletmeyi iyi bilmiyorsa, kapıdan geçemez.

Bu, güçlü bir iş bilgisi olan ancak orta düzeyde teknik becerilere sahip olmayan bu insanlar tarafından geliştirilen çok sayıda kritik uygulama ve sistemin ortaya çıkmasına neden olmuştur. Bu sistemler her zaman, kötü bir şekilde tasarlanmış, sürekli çarpışan, böceklerle dolu, ölçeklenmeyen, bir şeyi kırmadan düzeltmek neredeyse imkansız olan bir projedir ve aslında proje almak için yetersiz teknik beceri nedeniyle proje iptal edilmezse üretime.