Geliştiriciler iş alanını anlamalı mı, yoksa şartname yeterli mi olmalı?

Alanında anlaşılması gerçekten zor olan bir şirket için çalışıyorum çünkü elektronik alanında yüksek teknoloji var, ancak bu karmaşık bir alandaki herhangi bir yazılım geliştirmesine uygulanabilir.

Üzerinde çalıştığım uygulama, etki alanında deneyim olmadan anlaşılması zor olan birçok bilgi, grafik ve metrik görüntüler. Geliştirici, belirli bir grafiğin bu tür ölçümleri göstermesi gerektiğini belirtmek gibi yazılımın ne yapması gerektiğini açıklamak için bir teknik özellik kullanır ve bu ölçüm aşağıdaki aritmetik formüldür.

Bu şekilde, geliştirici işi ve bu görevi ne yaptığını gerçekten anlamadı. Eğer şartname gerçekten ayrıntılıysa, bu tamam olabilir, ancak değilse veya yazar bir kullanım durumunu unuttuğunda, geliştiricinin bir çözüm bulması oldukça zordur.

Öte yandan, her geliştiriciyi tüm iş yönleriyle eğitmek çok uzun ve zor olabilir.

Detaylı şartnameye daha fazla önem vermeli miyiz (fakat bildiğimiz gibi, kusursuz şartname mevcut değil) ya da tüm geliştiricileri işletme alanını anlamaları için eğitmeli miyiz?

EDIT: cevabınızı, şirketin harici geliştiricileri kullanabileceğini ve tüm etki alanında bir oluşumun yaklaşık 2 hafta olabileceğini unutmayın.

Şartname neredeyse hiçbir zaman yeterli değildir. Alan bilgisine sahip olmayan geliştiriciler, şartnamenin hatalı olduğunu (çoğu yerde sık sık meydana geldiğinde) işaret edemez ve kötü tasarım seçimleri yapar.

Tecrübelerime göre, şimdi 3 farklı sektörde çalıştığım için, etki alanı hakkında fazla bir şey bilmeme başlayabilirsiniz, ancak sonunda bunu öğrenmeniz gerekir ve birileri daha ayrıntılı olarak anlamak zorunda kalacaktır.

Temel sorun, müşteri geliştirici empedansına bağlıdır: bir şey isterler, ancak onu gördüklerinde bileceklerdir ve siz onların problemini çözmek isteyeceksiniz ama o sorunun ne olduğu hakkında her zaman net bir fikir elde edemezsiniz. Onların (müşterinin) sektörüne (geliştiricisine ait) ilişkin alan bilgisi ne kadar fazla olursa, belirsiz olan "istekleri" somut "sorunlara" çevirebilir ve çözebilirsiniz.

Bir anekdot örneği olarak, önceki işim bitki yönetim yazılımını içeren kimya endüstrisindeydi. Etki alanı hakkında etkili bir şekilde sıfır bilgisiyle başladım, ancak üst düzey geliştirici ve müşteriler tarafından bana sunulan alt sorunları çözmek için gereken kodu uygulayabildim. Zamanla, endüstriyi öğrenmek için çaba sarf ettim, böylece müşterinin seviyesinde daha kolay iletişim kurabilecektim. Sektörlerini anladığım gibi, asıl sorunların ne olduğunu anlamaya başladım. "Bu modüldeki tüm veri değerlerini izlemeliyiz" gibi şeyler söylediklerinde, bunu gerçekten demek istedikleri şeye çevirebilirim: "Bu sensörün ürettiği, X günleri için depolanan her değerin tarihsel kaydını tutmamız gerekir tutma, ancak daima o sensörden gelen en son okumalara dayanarak değerlendirilir. "

Bu yüzden evet, birisinin alan bilgisine ve tercihen bir geliştiriciye ihtiyacı vardır, çünkü alan problemleri kod problemleri değildir ve ikisi arasında çeviri önemsiz değildir. Sonunda, ekibinizde kalmaya değer geliştiriciler etki alanını seçmelidir, böylece kodlarının nüansları hakkında daha bilinçli seçimler yapabilirler.

Projenin bir kısmının etki alanı bilgisinin oldukça eksiksiz olması gerekir. Bu kişi geliştirici olabilir veya olmayabilir.

Çevik projelerde müşteri proje sahibi o kişidir ve ekiple birlikte ve işbirliği içinde çalışırlar. Çevik olmayan projelerde, ekibin birisinin bu bilgiyi edinmesi gerekir, ancak genellikle değil, bu nedenle Çevik olmayan projelerin başarısızlığa eğilimli olmasının bir nedenidir.

Çok fazla mükemmel cevap var. Kendimi ekliyorum çünkü onları okuduktan ve aradıktan sonra kimsenin kilit bir konudan bahsetmediğini buldum: böcekler .

Eğer takım yeterli yetki ve alan uzmanlığına sahip yeterli sayıda insanla donatılmazsa, er ya da geç böcek kaçınılmaz olarak içeri girecektir. Alan hakkında bir bilgi verildiğinde, imkansız veya duyusal olmayan değerler / sonuçlar / ilişki vardır. Bir spesifikasyonun açıkça belirtildiğini umabiliriz, ancak gerçekte ulaşabileceğiniz en iyisi en belirgin olanlardan kaçınmaktır (faiz oranları negatif olursa beni uyarır ya da bunun gibi şeyler - bu olabilir ya da bir hata olabilir, ancak kayda değer olmak için yeterince garip).

Bu, seçimlerin nedenlerini anlamakla yakından ilgilidir ve en iyi durumlarda, aynı zamanda daha iyi bir yazılıma da yol açar (çünkü bir isteğin arkasındaki nedeni gerçekten bilen biri varsa, verilen bir şeyi kabul etmek yerine, onu düşünebilir). ).

Einstein'ın "Ama düşünce ve fikirler, formüller değil, her fiziksel teorinin başlangıcıdır" demiştir, bunun bir soyut formül değil, fikir açısından düşündüğüdür ...

Sadece İngilizce bilen birini ve bir odada sadece Japonca bilen birini koyarsanız, kendi dillerinde uzman olmalarına rağmen Japoncadan İngilizceye çeviri yapamazlar. Aynı nedenle, etki alanı bilgisi olmayan uzman programcılar bile, yazılım geliştirme konusunda uzman olmayan en iyi etki alanı uzmanına 24x7 erişime sahip olduklarında bile, neye ihtiyaç duyduklarını anlamada güçsüzdürler.

Spesifikasyon, alan gereksinimlerinin "Japonca" sını programlama gereksinimlerinin "İngilizcesine" çevirme girişimidir. Çeviri kalitesini Google çeviri ile karşılaştırdığınızda elde edersiniz, bugün şanslı gününüzdür; çoğu zaman kalite sadece orada değildir, bu nedenle en azından bir miktar etki alanı bilgisi edinmenin bir yolu yoktur . Biraz ısrarla, proje sonunda size iyi bir "tercüman" yapar, böylece şirketinize olan değeriniz önemli ölçüde artar. Çoğu zaman, bu süreçte de çok eğleniyorsunuz, bu yüzden bir kazan-kazan durumu.

İş bilgisinin bir yönü olmadan, soru sormayan ve özelliklerin söylediklerini dikkatsizce kodlayan geliştiricilerle karşılaşırsınız. İyi düşünmek için "Düşünürler" in sadece klavyeye basabilecek insanlar değil inanıyorum. Sadece “Ne” yaptığınızı değil, “Neden” i ve daha büyük resme nasıl uyduğunu anlamak, geliştirme ekibine daha fazla memnuniyet sağlamanıza yardımcı olur.

Bence etki alanı bilgisini edinmeye çalışmalısın. Özellikler, son ürünün ne yapması gerektiğini ve ürünün doğrulanması için gerekli olduğunu söyleyen kontrol listesidir. Geliştirici olarak , çözmeye çalıştığınız asıl sorunun ne olduğunu anlamaya çalışmalısınız . Alan bilgisini almak bunu anlamanıza yardımcı olacaktır.

Değişen parçaların ne olduğunu anlayacağınız (kural kümesi söylenecek) ve ayrı olarak yerleştireceğiniz gibi kolayca tasarlamanıza ve kodlamanıza yardımcı olacaktır. Bu konuda usta olmanıza gerek yoktur, ancak son kullanıcıyla kendi dilinde konuşabilir .

Temel bilgileri ile bir araba sürebilirsin; Ancak sürüşün tadını çıkarmak istemeniz durumunda, tam olarak nasıl kullanılacağı hakkında daha fazla bilgi edinmeniz gerekir. Diğer işlemlerde olduğu gibi, etki alanını anlamak zorunlu değildir, ancak bunu yaparken eğlencelidir .

Bence bu işi bilen bir geliştirici altın ağırlığına değer.

İşletmenin bazı gereksinimlere sahip olduğu ve bazı iş analistlerinin bunları teknik gereksinimlere dönüştürdüğü "geleneksel" bir senaryoda , geliştirici kaçınılmaz olarak gerçekleşebilecek iki şeyden oluşur:

1. Birden fazla başarısızlık noktanız var. İş analisti, mükemmel olarak çevrilmiş tüm iş gereksinimlerini alamamış olabilir ve / veya geliştirici bunları teknik şartnameye mükemmel bir şekilde çeviremez. "Odanın etrafındaki sır" senaryosunda bir değişken. Sadece iletişimin açılımları.

2. İşletme sahibi, işletme analisti veya geliştiricisinin biri veya tümü, normal olarak düşünmeyecekleri önemli öğeleri kaçırmak için organizasyon için yeni. İşletmeyi iyi tanıyan tecrübeli geliştirici, ürünü daha eksiksiz hale getirmek için insanları bu rollerde eğitmeye yardımcı olabilir.

Spesifikasyondaki her bir özelliğin değeri, spesifikasyonun değerine ne kadar yakın uygulanması gerektiği ve spekülasyon özelliklerinin herhangi bir kombinasyonunun karşılanmasının maliyeti arasında neredeyse her zaman bir takas vardır. Çoğu zaman iyi değiş tokuşlar ancak yukarıdakilerin hepsini gerçekleştirme bilgisi tek bir kişi veya gerçek yazılım mimarı ve / veya kodlayıcı dahil olmak üzere yakın çalışan bir ekipte mevcut olduğunda yapılabilir.

Bu kadar yerelleştirilmiş bilgi ve hatta içgüdüsel hisler olmadan, sonuç kolayca yazılı özellikleri çok yakından karşılayan çok maliyetli neredeyse işe yaramaz bir ürün olarak sonuçlanabilir.

Yukarıdaki sorunlara sahip olmayan bir özellik yaratmanın maliyeti, mimar ve / veya kodlayıcıları daha az kesin olmayan ayrıntılı bir spesifikasyonla çalışmak için yeterli alan bilgisine sahip olmak için eğitmekten daha büyük olabilir (yasallıkların ve iş sözleşmelerinin buna izin verdiği varsayılarak).

Evet geliştiricilerin işi bir dereceye kadar bilmesi gerekir. Her dakika detayını bilmek zorunda değiller, ancak X'in raporunun ne için kullanıldığı ve iş sürecinde nasıl kullanıldığı hakkında temel bir anlayışa sahip olmaları gerekir. Geliştiricileriniz işletme hakkında ne kadar çok anlarsa, o kadar iyi bir çözüm üretebilirler.

Tecrübelerime dayanarak *, sorun alanı hakkında iyi bir bilgiye sahip olan ve iyi yazılım geliştirme bilgisi olan tek bir kişinin, bir sorun için en iyi çözümü bulması, biri sorun alanında mükemmel bir bilgiye sahip ve biri mükemmel bir bilgiye sahip Yazılım geliştirme, birlikte çalışma.

Tek bir bireyin beyninde gerçekleşen iletişimin, bireyler arasındaki iletişimden çok daha hızlı ve daha iyi olduğu basit gerçeğine dayanıyor.

* Bu soruyu cevaplamak için çizdiğim ana deneyim (başlangıçtan 'bakım moduna' kadar) bir muhasebe yazılımı paketi geliştirmek için harcanan 10 + yıl. Yazılım geliştirme konusundaki bilgilerim oldukça iyi olmasına rağmen, meslektaşlarımla karşılaştırıldığında, genellikle sorun alanını anlamadaki yetersizlikten dolayı kendimi özürlü hissettim.

İş dünyasından gelen, ticaretin temellerini öğrenmeye çok az ilgi gösteren geliştiricilerle çalışan biri olarak cevap vermek istiyorum, bazen bu temel bilgileri bilmemekten gurur duyuyor gibi görünüyor: Sorun şu ki: geliştiriciler, sonuçta ilk bakışta (yaflanamayan sonuçlar, yanlış işaretler vb.) hatalar göremeyecektir; bu, ya detaylı test durumları (yakın zamana kadar geliştirmediğimiz) ya da sonuçların sürekli denetlenmesini gerektirir. Bilgilendirici, iletişimi kolaylaştırmak için yazılım geliştirmenin temellerini öğrenmeye istekli olduğum kadar, geliştiricilere de aynısını yapmaya teşvik ediyorum.

Zorunda değilsin, ama neden istemesin ki?

İsteksiz olan ve özellikle etki alanını bir dereceye kadar öğrenemeyen herhangi bir programcı için endişelenirim. Bir süre sonra "fildişi kod kulesinden" çıkmak önemlidir.

Nasıl kullanıldığını ve hangi amaç için korkunç bir iş gibi göründüğünü hiç bilmeden kod yazmak. Katedralleri kurarken kim tuğla kırmak ister?

Bir geliştiricinin ne kadar fazla ilgiliyse ve iş dünyasında o kadar kıdemli hale geldikçe o kadar önemli hale gelir, en azından orta seviye alan bilgisine sahip olmak veya o sektörün kritik olabilecek daha hassas alanları geliştirici ekibi tarafından anlaşılmaz.

Bununla birlikte, bir şartname alt seviye görevler için yeterli olmalıdır. Kısacası, işgücünüzü daha düşük bir seviyeye yükseltmek en iyisidir. Dünyadaki en iyi polyglot programcısı olabilirler, ancak konuyu oldukça derinlemesine anlayamazlarsa, başarısızlığa veya ölüm yürüyüşü programlamasına her zaman mahkum olurlar.

Her zaman bir spesifikasyon olmalı - tüm geliştiricilerin etki alanı uzmanı olmasını bekleyemezsiniz. Aynı zamanda, geliştiriciler ne için olduğunu gerçekten anlamadan kör bir spekülasyon izlerlerse, sonuç gerçekten müşterilerin istediği şey olmayabilir. Genellikle bir geliştirici biraz iyi (ancak uzman olmayan) bir anlayışa sahip olduğunda, teknik özelliklerde hata ve ihmalleri yakalayabiliyorlar. Ayrıca nihai ürünü daha iyi hale getirebilecek sürece katkıda bulunabilir ve geri bildirimde bulunabilirler.

Geliştiricilere daha iyi bir anlayış kazandırmak ve özellikleri yazmak için müşterileri ve geliştiricileri arasında irtibat kurmak olan bazı etki alanı uzmanlarını işe almaya değer olabilir.

Her iki şekilde bir cevap vermek bu zor düşünüyorum.

Serbest çalışan bir geliştiricinin, geliştirdikleri her uygulamanın arkasındaki işi (veya bilimi) nasıl anlayabildiğini görmek zor. Bu durumda, geliştiricinin teknik özellik veya işletme modeli hakkında doğru soruları sormanın, işi gerçekten anlamaktan daha önemli olduğunu bilmesinin daha önemli olduğunu düşünüyorum.

Öte yandan bir şirket geliştiricisi, bir süredir aynı işletmede olduklarını varsayarsak, birkaç ay sonra (ya da belki yıllarca) işletmenin nasıl çalıştığını öğrenmiş olmalı. Büyük takımda, işi geliştiricilerden daha net anlayan bir mimar da olabilir.

Yalnız geliştiricilere sahip olan KOBİ'lerde geliştiricinin, yanlış bir şey yapmamak ve uygulamaktan kaçınmak için mal sahipleri / yöneticileri ile sık sık görüşmesi önemlidir.

Dolayısıyla, bunun hakkında düşünmenin pek çok yolu vardır, ancak anahtar her durumda aynıdır: iletişim .

Yazılım geliştirme bildiğim tek meslektir, sadece kendi mesleğinizde yetkin olmanızı değil, çalıştığınız mesleğin temel bir anlayışına sahip olmanızı gerektirir. Müşterilerle iletişim kurmak için etki alanını yeterince anlamış olmak önemlidir. Müşterinin dilinde diğer geliştiriciler. Bir geliştirici olarak, sizi eğitmek için her zaman başkalarına güvenemezsiniz. Bazen, genellikle tipik çalışma saatleri dışında defalarca kişisel araştırmalarla kendi başınıza rampa yapmak zorunda kalırsınız.

Burada ne demek istediğinizi gerçekten anlıyorum çünkü bir turizm sektöründeki şirket olarak aynı sorunla karşılaştık. Küçük bir geliştiriciyken, bir kolejde turizm okuyordum. Öyleyse, bir bilgisayar bilimi geçmişinden gelmediğimi, ancak turizm bilgimin yüksek olduğunu tahmin edebilirsiniz.

O zamanlar diğer yazılım şirketleri ile ilişkili olarak ürünler üretiyorduk, fakat alana özel bilgi çok eksikti. Tanımladığınız gibi, birçok çapraz kesilen kaygı gibi, turizm endüstrisinde bir ürün inşa ediyorsanız, bunu doğru yapmak gerçekten zor.

Dolayısıyla bu hareket uzun vadede çok fazla kötü sonuç verdi. Ardından ileriye doğru büyük bir adım attık ve projenin iş bölümünden ziyade sadece gelişmeye odaklanmaya başladım. Endüstriyel bilgiye ve programlama bilgisine sahip olduğum için proje her zamankinden daha verimli bir şekilde büyüyor. Bahsetmiyorum bile, madalyonun her iki tarafında da deneyime sahip olduğum için kararları daha hızlı yapabiliriz.

Sorunuza somut bir cevap olarak, benim görüşüme göre kesinlikle evet. Ekibinizin üzerinde çalıştığı proje uzun vadeli bir proje ise, o zaman zorlu yola çıkın ve personelinizi alana özgü temel ve detaylar konusunda eğitin.

Bir geliştirici bir şirkette / endüstride uzun süre kalırsa, yavaş ama kesin bir şekilde "işi" öğreneceklerdir.

Bazı şirketler "işletme" konusunda eğitim almayı kabul eder ve sağlar. Finansal şirketler buna iyi bir örnektir.

İşi ne kadar çok öğrenirseniz, kullanıcılarınızla konuşmak o kadar kolaylaşacaktır. Size daha fazla güven hissedecekler. Kullanıcı için beklendiği gibi yapmazsa, sistemin yanlış gittiği yönlerini daha kolay anlayacaksınız.

Sorunuzu yanıtlamak için, teknik özellik ASLA benim deneyimim için yeterli değil. Sık karşılaşılan sorun, genellikle yeterli bilgi içermemesi ve hızlı bir şekilde eski kalmasıdır.

İş alanı deneyimi, bazı şirketler için zorunlu olabilir. İşe alım alanında tecrübeli geliştiriciler arıyorlar. Hatta bazı şirketler bunu gerçek teknoloji becerilerinden daha yükseğe koyuyor. (Mali deneyim yok, röportaj çok yaygın değil, kesinlikle İngiltere'de.)

Kişisel deneyime göre, teknik özellikte sizinle birlikte çalışan ekipte çalışan bir kişi olduğu sürece bu özellik yeterli olacaktır.

Çok özel bir sektörde çalışıyorum: Yayın medyası için yazılımlar üretiyoruz. Yayıncılık hakkında çok az şey biliyorum ama kodları biliyorum ve verileri biliyorum ve proje yönetimi ekibinde yayıncılığı anlayan iyi insanlar var. Bu formül son birkaç yıldır müşterilerin hoşlanacağı iyi bir işlevsellik bulmam için yeterince iyiydi.