Czy programiści muszą zrozumieć domenę biznesową, czy specyfikacja powinna być wystarczająca?

52

Pracuję dla firmy, dla której domena jest naprawdę trudna do zrozumienia, ponieważ jest to zaawansowana technologia w elektronice, ale dotyczy to każdego oprogramowania tworzącego złożoną domenę.

Aplikacja, nad którą pracuję, wyświetla wiele informacji, wykresów i wskaźników, które są trudne do zrozumienia bez doświadczenia w dziedzinie. Deweloper używa specyfikacji, aby opisać, co musi zrobić oprogramowanie, na przykład określając, że dany wykres musi wyświetlać tego rodzaju metryki, a metryka ta jest następującą formułą arytmetyczną.

W ten sposób programista tak naprawdę nie rozumie biznesu i co / dlaczego wykonuje to zadanie. Może to być OK, jeśli specyfikacja jest naprawdę szczegółowa, ale kiedy tak nie jest lub gdy autor zapomniał o przypadku użycia, deweloperowi trudno jest znaleźć rozwiązanie.

Z drugiej strony szkolenie każdego programisty we wszystkich aspektach biznesowych może być bardzo długie i trudne.

Czy powinniśmy przywiązywać większą wagę do szczegółowej specyfikacji (ale jak wiemy, idealna specyfikacja nie istnieje), czy też powinniśmy szkolić wszystkich programistów w zakresie rozumienia domeny biznesowej?

EDYCJA: pamiętaj, że w swojej odpowiedzi firma mogła korzystać z zewnętrznych programistów i że utworzenie wszystkich domen może trwać około 2 tygodni

Jerome C.
źródło
Dobrzy programiści przeważnie będą się szkolić.
kevin cline,
20
@kevincline: Nie wszystkie domeny nadają się do łatwego samokształcenia.
FrustratedWithFormsDesigner
Jak realistyczne jest posiadanie szczegółowej specyfikacji, która nie posiada wiedzy na temat domen? Istnieje również kompromis polegający na uzyskaniu bardziej szczegółowych informacji w specyfikacji, że może to potrwać dłużej, a zatem w niektórych przypadkach nie jest opłacalne.
JB King
22
Myślę, że im bardziej złożona domena, tym bardziej krytyczne jest to, że programiści ją rozumieją, i tym bardziej krytyczne jest, aby nie zlecać programowania na zewnątrz.
HLGEM,
3
Uwaga: s / developers / testers / w tym pytaniu i nadal jest aktualne.
joshin4colours

Odpowiedzi:

114

Specyfikacja praktycznie nigdy nie jest wystarczająca. Programiści, którzy nie mają wiedzy o domenach, nie mogą wskazać, kiedy specyfikacja jest błędna (częste przypadki w większości miejsc) i dokonywać złych wyborów projektowych.

HLGEM
źródło
52
+1 Ponieważ widziałem, jak to się dzieje w prawdziwym życiu. Starszy programista wielokrotnie prosił firmę o sprawdzenie wymagania, firma zapewniła zespół, że wymaganie jest poprawne, a następnie programista został zmuszony do zmieszania się następnego dnia po uruchomieniu, ponieważ biznes naruszał prawo stanowe w dwóch stanach.
Joshua Drake
9
lub spojrzeć na to z innej strony, wystarczająco szczegółowa specyfikacja jest kodem źródłowym i dlatego wymaga napisania przez programistę z wiedzą domenową
jk.
@Joshua - czy to nie przypadek, w którym znajomość domen nie miała większego sensu? - spodziewano się, że programiści wdrożą specyfikację niezależnie (przynajmniej do dnia paniki).
Steve314,
3
@ Steve314 w porządku. W trosce o intelektualną uczciwość deweloper przypomniał sobie przede wszystkim dyskusję dotyczącą implementacji oryginalnej funkcji, a nawet skomentował kod, aby nie usuwać tych informacji, zgodnie z jk. Przekonałem się, że znajomość domen często pomaga deweloperowi wiedzieć, gdzie są luki, a przynajmniej prawdopodobnie będą w specyfikacji, umożliwiając wyższą jakość i szybszy zwrot w celu zaspokojenia potrzeb biznesowych.
Joshua Drake
2
Właściciel firmy może zatrudnić programistę, ale ostatecznie specyfikacja leży w gestii dewelopera. Kiedy stoicie przed parlamentami stanowymi, nie możecie powiedzieć „Ale tak mi powiedziano” lub „męstwo intelektualne nie było wygodne”. To nie wystarczy. Zapamietaj to.
Ben DeMott,
63

Z mojego doświadczenia wynika, że ​​pracując obecnie w 3 bardzo różnych branżach, możesz zacząć, nie wiedząc wiele na temat domeny, ale w końcu musisz się jej nauczyć, a ktoś będzie musiał ją szczegółowo zrozumieć.

Zasadniczy problem leży w impedancji klient-programista: chcą czegoś, ale będą o tym wiedzieć tylko wtedy, gdy to zobaczą, a ty chcesz rozwiązać ich problem, ale nie zawsze możesz dokładnie zrozumieć, na czym polega ten problem. Im więcej wiedzy na temat ich branży (klienta) możesz przynieść (deweloperowi), tym łatwiej możesz przetłumaczyć niejasne „chce” na konkretne „problemy” i rozwiązać je.

Jako anegdotyczny przykład moja poprzednia praca dotyczyła przemysłu chemicznego obejmującego oprogramowanie do zarządzania instalacjami. Zacząłem od praktycznie zerowej znajomości domeny, ale byłem w stanie zaimplementować kod, którego potrzebowałem, aby rozwiązać pod-problemy przedstawione mi przez starszego programistę i klientów. Z czasem starałem się poznać branżę, aby móc łatwiej komunikować się na poziomie klienta. Gdy zrozumiałem ich branżę, zacząłem rozumieć, jakie były rzeczywiste problemy. Kiedy mówią takie rzeczy, jak: „musimy śledzić wszystkie wartości danych w tym module”, mogę to przełożyć na to, co one naprawdę oznaczają, czyli „musimy prowadzić historyczny zapis każdej wartości generowanej przez ten czujnik, przechowywany przez X dni retencja, ale zawsze oceniana na podstawie ostatniego odczytu z tego czujnika. ”

Tak więc, ktoś potrzebuje wiedzy o domenie, a najlepiej programisty, ponieważ problemy z domeną nie są problemami z kodem, a tłumaczenie między nimi nie jest trywialne. W końcu wszyscy programiści, których warto zatrzymać w zespole, powinni wybrać domenę, aby mogli dokonywać bardziej świadomych wyborów dotyczących niuansów swojego kodu.

CodexArcanum
źródło
7
Ukryte reguły - uważam, że są raczej normą niż wyjątkiem.
Preet Sangha,
16

Ktoś w projekcie musi mieć dość pełną wiedzę na temat domen. Ta osoba może być deweloperem lub nie.

W projektach Agile właścicielem projektu klienta jest ta osoba, która ściśle współpracuje z zespołem. W projektach nie zwinnych ktoś w zespole musi zdobyć tę wiedzę, ale zazwyczaj tego nie robi, co jest jednym z powodów, dla których projekty nie zwinne są tak podatne na awarie.

Dan Ray
źródło
+1, programiści (jak nie architekci systemu) nie powinni wymagać żadnej wiedzy w tej dziedzinie. W idealnej organizacji kodowanie powinno być wykonane w wystarczająco małych częściach, które nie wymagają żadnej wiedzy o produkcie końcowym. Ile jest „idealnych organizacji” na świecie ... Zazwyczaj jest to coś takiego: Dodaj funkcję objaśnioną jednym wierszem zawierającym frazy: no wiesz, tak jak na tej stronie, ...
Juha
1
Nie sądzę, że sam właściciel produktu posiadający wiedzę o domenie jest przepisem na sukces.
Casey
11

Istnieje wiele doskonałych odpowiedzi. Dodaję własne, ponieważ po ich przeczytaniu i przeszukaniu odkryłem, że nikt nie wspomina o kluczowym problemie: błędach .

Jeśli zespół nie otrzyma wystarczającej liczby osób posiadających wystarczającą wiedzę i kompetencje w dziedzinie, prędzej czy później błędy wkroczą nieuchronnie. Biorąc pod uwagę wiedzę w dziedzinie, istnieją niemożliwe lub niesensowne wartości / wyniki / relacje. Można mieć nadzieję, że specyfikacja wyraźnie je wskazuje, ale w rzeczywistości najlepszym, co możesz osiągnąć, jest uniknięcie najbardziej oczywistych (powiadom mnie, jeśli stopy procentowe staną się ujemne lub coś podobnego - to może być lub nie być błąd, ale jest na tyle dziwne, że warto na to zwrócić uwagę).

Jest to ściśle związane ze zrozumieniem powodów wyboru, aw najlepszych przypadkach prowadzi również do lepszego oprogramowania (ponieważ jeśli ktoś naprawdę zna przyczynę żądania, jest w stanie o tym pomyśleć, zamiast zaakceptować to jako dane ).

Pamiętaj, że Einstein powiedział „Ale myśl i idee, a nie formuły, są początkiem każdej teorii fizycznej” , to znaczy, że nie myśli się o abstrakcyjnych formułach, ale o ideach ...

Francesco
źródło
1
Tak, a wiele z nich to przedmioty (takie jak przykład z ujemnym zainteresowaniem), które są tak podstawowe dla domeny biznesowej, że nigdy nie przychodzi im na myśl, aby określić je, ponieważ „wszyscy” to wiedzą.
HLGEM,
10

Jeśli umieścisz w pokoju osobę znającą tylko angielski i osobę znającą tylko japoński, nie byłaby w stanie tłumaczyć z japońskiego na angielski, mimo że jest ekspertem w swoich językach. Z tego samego powodu nawet eksperci-programiści bez znajomości domen nie mają pojęcia, co muszą zbudować, nawet jeśli mają dostęp 24 godziny na dobę i 7 dni w tygodniu do najlepszego eksperta w dziedzinie, który nie jest również ekspertem w dziedzinie tworzenia oprogramowania.

Specyfikacja jest próbą przetłumaczenia „japońskiego” wymagań domeny na „angielski” wymagań programistycznych. Gdy uzyskasz jakość tłumaczenia porównywalną z jakością tłumaczenia Google, to twój szczęśliwy dzień; przez większość czasu, jakość jest po prostu nie istnieje, więc nie masz drogę pozyskania przynajmniej trochę wiedzy domeny. Z pewnym uporem sprawia, że ​​pod koniec projektu stajesz się porządnym „tłumaczem”, dzięki czemu Twoja wartość dla firmy znacznie wzrasta. Przez większość czasu dobrze się też bawisz, więc jest to sytuacja korzystna dla obu stron.

dasblinkenlight
źródło
„Z tego samego powodu nawet eksperci-programiści bez znajomości domen nie są w stanie ustalić, co muszą zbudować, nawet jeśli mają dostęp 24 godziny na dobę i 7 dni w tygodniu do najlepszego eksperta w dziedzinie, który nie jest również ekspertem w dziedzinie tworzenia oprogramowania”. - Nie. Programiści zdobywają wiedzę na temat domeny (częściowo), przeprowadzając wywiady z ekspertem w dziedzinie. Specjalista w dziedzinie może powiedzieć programistom, co chce zbudować. Programiści powinni dowiedzieć się wystarczająco dużo o domenie, aby móc omówić funkcje z ekspertem od domeny.
Marnen Laibow-Koser
@ MarnenLaibow-Koser Konieczność uzyskania przez programistów wiedzy o domenach jest drugą częścią mojej odpowiedzi. „Wiedza” może pochodzić od eksperta, książki, Internetu i tak dalej; dostęp do eksperta jest pomocny, ale nie instrumentalny.
dasblinkenlight
To nie jest mój główny punkt sporu. Moim głównym punktem sporu jest twoje twierdzenie, że dostęp do eksperta od domen nie pomoże programistom dowiedzieć się, co muszą zbudować. W rzeczywistości to właśnie ten dostęp najbardziej pomoże programistom - i wiem, ponieważ zrobiłem to właśnie w różnych projektach.
Marnen Laibow-Koser
8

Bez jakiegoś aspektu wiedzy biznesowej skończysz z programistami, którzy nie zadają pytań i bezmyślnie kodują to, co mówią specyfikacje. Uważam, że „Myśliciele” potrzebują dobrego oprogramowania nie tylko dla ludzi, którzy potrafią uderzać w klawiaturę. Zrozumienie nie tylko „tego, co robisz”, ale „dlaczego” i tego, jak pasuje do szerszego obrazu, zapewnia większą satysfakcję zespołowi programistów.

Michael Hayes
źródło
6

Myślę, że powinieneś spróbować zdobyć wiedzę na temat domeny. Specyfikacje to lista kontrolna z informacją o tym, co powinien zrobić produkt końcowy i jest wymagana do weryfikacji produktu. Jako programista powinieneś zawsze starać się zrozumieć, jaki jest prawdziwy problem, który próbujesz rozwiązać. Zdobycie wiedzy na temat domeny pomoże ci to zrozumieć.

Pomoże to w łatwym projektowaniu i kodowaniu, ponieważ zrozumiesz, co się zmienia (powiedzmy zestaw reguł) i umieścisz je osobno. Nie musisz być mistrzem, ale możesz rozmawiać z użytkownikiem końcowym w jego języku .

Możesz prowadzić samochód z podstawową wiedzą na jego temat; ale jeśli chcesz cieszyć się jazdą, musisz dowiedzieć się więcej o tym, jak z niej dokładnie korzystać. Podobnie jak w przypadku innych transakcji, zrozumienie domeny nie jest obowiązkowe, ale jest to przyjemne .

ManuPK
źródło
5

Myślę, że programista, który wie, że firma jest warta swojej wagi w złocie.

W „tradycyjnym” scenariuszu, w którym firma ma pewne wymagania, a niektórzy analitycy biznesowi tłumaczą je na wymagania techniczne, wówczas programista pracuje nad tymi, które nieuchronnie mają dwie rzeczy, które mogą się zdarzyć:

  1. Masz wiele punktów awarii. Być może analityk biznesowy nie przetłumaczył idealnie wszystkich wymagań biznesowych i / lub deweloper może nie przetłumaczyć ich idealnie na specyfikację techniczną. Wariant scenariusza „sekret wokół pokoju”. Tylko wymogi komunikacji.

  2. Jeden lub wszyscy właściciele firm, analitycy biznesowi lub deweloperzy są na tyle nowi, że brakuje im kluczowych elementów, o których normalnie by nie pomyśleli. Doświadczony programista, który dobrze zna biznes, może pomóc w edukacji ludzi na innych stanowiskach, aby produkt był bardziej kompletny.

Jesse C. Slicer
źródło
Zgoda. Jeśli nic więcej, Firma jest znacznie bardziej skłonna ponownie wezwać tego Dewelopera, po prostu dlatego, że Deweloper „zna liny”, a Firma nie musi tracić czasu na szkolenie nowego Programisty za każdym razem, gdy dział IT zdecyduje się wysłać swój najnowszy, ogólny programista, który może zabrać ze sobą wszystko, aby pracować nad najnowszym zestawem wymagań.
Phill W.,
3

Niemal zawsze trzeba dokonać kompromisu między wartością każdej funkcji w specyfikacji, tym, jak ściśle specyfikacja musi być wdrożona do wartościowej, a kosztem spełnienia dowolnej kombinacji funkcji specyfikacji. Często dobrych kompromisów można dokonać tylko wtedy, gdy wiedza na temat wykonywania powyższych czynności istnieje w jednej osobie lub w ściśle współpracującym zespole, w tym w rzeczywistym architekcie oprogramowania i / lub koderze.

Bez tak ekstremalnie zlokalizowanej wiedzy i być może nawet przeczucia, wynik może łatwo stać się bardzo kosztownym, prawie bezużytecznym produktem, który bardzo ściśle spełnia zapisaną specyfikację.

Koszt stworzenia specyfikacji, w której nie występują powyższe problemy, może często być wyższy niż szkolenie architekta i / lub programistów, aby dysponowali wystarczającą wiedzą na temat domeny do pracy z mniej szczegółową specyfikacją (zakładając, że pozwalają na to legalności i umowy biznesowe).

hotpaw2
źródło
2

Tak, programiści muszą znać branżę do pewnego stopnia. Nie muszą znać każdego szczegółu, ale powinni mieć podstawową wiedzę o tym, do czego służy raport X i jak jest on wykorzystywany w procesie biznesowym. Im więcej programiści rozumieją biznes, tym lepsze jest rozwiązanie.

Ryathal
źródło
2

Na podstawie mojego doświadczenia * jedna osoba z dobrą znajomością dziedziny problemowej i dobrą wiedzą na temat tworzenia oprogramowania jest bardziej skłonna do znalezienia optymalnego rozwiązania problemu niż dwie osoby, jedna z doskonałą znajomością dziedziny problemowej i jedna z doskonałą wiedzą rozwoju oprogramowania, współpraca.

Myślę, że sprowadza się to do prostego faktu, że komunikacja zachodząca w mózgu pojedynczej osoby jest wielokrotnie szybsza i lepsza niż komunikacja między jednostkami.

* Głównym doświadczeniem, które czerpię z odpowiedzi na to pytanie, jest ponad 10 lat spędzonych na opracowywaniu pakietu oprogramowania księgowego (od powstania do „trybu konserwacji”). Chociaż moja wiedza na temat tworzenia oprogramowania była całkiem dobra w porównaniu z moimi kolegami, często czułem się utrudniony z powodu niezrozumienia dziedziny problemowej.

Daniel Pratt
źródło
Zwykle stwierdziłem, że gdy jedna osoba samodzielnie rozwiązuje problem bez konsultacji z innymi, prowadzi to do największej rezygnacji z kodu. Nie możesz zapomnieć o uwzględnieniu innych w swojej architekturze oprogramowania ... Być może znasz dobrze domenę, ale oprogramowanie nie jest układanką, powinieneś być układem więcej niż kilka razy.
lepkość
2

Chciałbym odpowiedzieć jako ktoś pochodzący ze strony biznesowej, który współpracuje z programistami, którzy wykazują niewielkie zainteresowanie nauczeniem się podstaw handlu, czasami nawet wydają się być dumni z tego, że nie muszą wiedzieć o tych podstawach: Problem polega na tym, że programiści nie będą w stanie zobaczyć błędów w wyniku na pierwszy rzut oka (niepoprawne wyniki, błędne znaki itp.), co wymaga albo szczegółowych przypadków testowych (których nie opracowaliśmy do niedawna), albo stałego nadzoru nad wynikami. O ile jestem gotów nauczyć się podstaw tworzenia oprogramowania w celu ułatwienia komunikacji, chciałbym zachęcić programistów do zrobienia tego samego.

Owe Jessen
źródło
2

Nie musisz, ale dlaczego nie chcesz?

Byłbym zaniepokojony każdym programistą, który byłby niechętny, a szczególnie do pewnego stopnia nie był w stanie nauczyć się domeny. Ważne jest, aby raz na jakiś czas wyjść z „wieży z kości słoniowej”.

Pisanie kodu bez pojęcia, w jaki sposób jest używany i do jakiego celu brzmi po prostu okropnie. Kto chce po prostu łamać cegły, kiedy można budować katedry?

JeffO
źródło
2

Im bardziej zaangażowany staje się programista i im wyższy poziom w firmie, tym ważniejsze staje się posiadanie co najmniej średniej wiedzy domenowej lub bardziej zróżnicowane obszary tej branży, które mogą być krytyczne, nie zostaną zrozumiane przez zespół programistów.

Jednak specyfikacja powinna być wystarczająca dla zadań niższego poziomu. Krótko mówiąc, najlepiej jest wyszkolić pracowników na niższym poziomie. Mogą być najlepszym programistą polyglot na świecie, ale jeśli nie rozumieją problemu dość głęboko, zawsze są skazani na programowanie niepowodzenia lub marszu śmierci.

honoru krystan
źródło
++ 1 „Programowanie marszu śmierci”. To tak jak w USA historia smolistego dziecka .
Mike Dunlavey
1

Zawsze powinna istnieć pewna specyfikacja - nie można oczekiwać, że wszyscy programiści staną się ekspertami w dziedzinie. Jednocześnie, jeśli programiści ślepo postępują zgodnie ze specyfikacją, nie bardzo rozumiejąc, do czego ona służy, wynik może nie być tym, czego oczekują klienci. Często zdarza się, że gdy programista ma nawet całkiem przyzwoity (ale nie ekspercki) poziom zrozumienia, może wykryć błędy i pominięcia w specyfikacjach. Mogą również przyczyniać się i przekazywać informacje zwrotne na temat procesu, co może znacznie poprawić końcowy produkt.

Warto zatrudnić niektórych ekspertów domenowych, których zadaniem jest utrzymywanie kontaktów między klientami i programistami, aby pomóc programistom w lepszym zrozumieniu, a także pomóc w napisaniu specyfikacji.

FrustratedWithFormsDesigner
źródło
1

Myślę, że tak trudno jest odpowiedzieć w obu przypadkach.

Trudno zrozumieć, jak, powiedzmy, niezależny programista może zrozumieć biznes (lub naukę) za każdą tworzoną przez siebie aplikacją. W tej sytuacji myślę, że ważniejsze jest, aby deweloper wiedział, że zadaje właściwe pytania dotyczące specyfikacji lub modelu biznesowego, niż naprawdę rozumie sam biznes.

Z drugiej strony deweloper korporacyjny, zakładając, że od jakiegoś czasu jest w tej samej branży, naprawdę powinien był dowiedzieć się, jak działa firma po kilku miesiącach (a może latach). W dużym zespole możesz również mieć architekta, który rozumie biznes lepiej niż programiści.

W małych i średnich przedsiębiorstwach z samotnymi programistami ważne jest, aby deweloper często rozmawiał z właścicielami / menedżerami, aby uniknąć odejścia i wdrożenia niewłaściwej rzeczy.

Istnieje wiele możliwych sposobów myślenia o tym, ale klucz jest taki sam we wszystkich przypadkach: komunikacja .

ZweiBlumen
źródło
1
Jako freelancer zapewniam, że muszę rozumieć interesy moich klientów przynajmniej na tyle dobrze, aby inteligentnie z nimi rozmawiać o potrzebnych im funkcjach. Pomysł, że możesz napisać specyfikację bez zrozumienia biznesu, jest marzeniem. Pomysł polega na tym, że możesz napisać idealną specyfikację i rzucić ją „nad ścianą” deweloperowi.
Marnen Laibow-Koser
1

Tworzenie oprogramowania to jedyny znany mi zawód, który wymaga nie tylko biegłości w swoim zawodzie, ale także podstawowego zrozumienia zawodu, w którym pracujesz. Ważne jest, aby mieć wystarczającą wiedzę na temat domeny, aby komunikować się z klientami i inni programiści w języku klienta. Jako programista nie zawsze możesz polegać na innych, którzy cię szkolą. Czasami musisz przyjechać na własną rękę z osobistymi badaniami, często poza zwykłymi godzinami pracy.

John Ruf
źródło
3
Inżynierowie przemysłowi potrzebują tej podwójnej wiedzy, podobnie jak praktycznie wszyscy analitycy. Nie ogranicza się tylko do tworzenia oprogramowania.
HLGEM,
4
Pisarz techniczny ma tę samą sytuację.
Jennifer S,
1

Naprawdę rozumiem, co masz na myśli, ponieważ my, jako firma działająca w branży turystycznej, napotkaliśmy ten sam problem. Kiedy byłem młodszym programistą, studiowałem również turystykę na uczelni. Można się więc domyślać, że nie pochodzę z informatyki, ale moja wiedza turystyczna jest wysoka.

W tamtym czasie budowaliśmy produkty w powiązaniu z innymi firmami produkującymi oprogramowanie, ale brakowało wiedzy na temat konkretnej dziedziny. Jak już opisałeś, naprawdę trudno jest to zrobić poprawnie, jeśli budujesz produkt w branży turystycznej, ponieważ istnieje wiele problemów przekrojowych itp.

Ten ruch dał wiele złych rezultatów w dłuższej perspektywie. Następnie zrobiliśmy ogromny krok naprzód i zacząłem koncentrować się wyłącznie na rozwoju, a nie na części biznesowej projektu. Ponieważ mam wiedzę przemysłową i programistyczną, projekt staje się bardziej wydajny niż kiedykolwiek. Nie wspominając o tym, że możemy szybciej podejmować decyzje, ponieważ mam doświadczenie po obu stronach monety.

Jako konkretna odpowiedź na twoje pytanie, z pewnością tak w mojej osobistej opinii. Jeśli projekt, nad którym pracuje Twój zespół, jest projektem długoterminowym, wybierz trudną drogę i przeszkol swoich pracowników w zakresie podstawowych zasad i szczegółów dotyczących konkretnej dziedziny.

tugberk
źródło
1

Jeśli deweloper pozostanie w firmie / branży przez długi okres czasu, będzie powoli, ale z pewnością nauczy się „biznesu”.

Niektóre firmy uznają i prowadzą szkolenia z zakresu „biznesu”. Firmy finansowe są tego dobrym przykładem.

Im więcej uczysz się biznesu, tym łatwiej będzie rozmawiać z użytkownikami. Będą czuć do ciebie więcej zaufania. Łatwiej zrozumiesz dziwactwa, które mogą sprawić, że system się nie powiedzie, jeśli nie będzie on działał zgodnie z oczekiwaniami użytkownika.

Aby odpowiedzieć na twoje pytanie, specyfikacja NIGDY nie jest wystarczająca z mojego doświadczenia. Częstym problemem jest to, że często nie zawierają wystarczającej ilości informacji i szybko się starzeją.

Doświadczenie związane z domeną biznesową może być obowiązkowe dla niektórych firm. Poszukują programistów z doświadczeniem w dziedzinie. Niektóre firmy stawiają to nawet wyżej niż umiejętności techniczne. (Brak doświadczenia finansowego, żaden wywiad nie jest bardzo powszechny, z pewnością tutaj w Wielkiej Brytanii).

Ozz
źródło
Ostatni akapit jest szczególnie prawdziwy w domenach biznesowych, w których można wpaść w kłopoty prawne, jeśli system nie jest właściwie zbudowany.
HLGEM,
Nie zgadzam się: nie ma gwarancji, że kompetentny programista długoterminowy może nauczyć się „biznesu”. Nadal wymaga pewnej organizacji firmy, a szczególnie źle jest z zespołami satelitarnymi.
Darien
0

Z własnego doświadczenia wynika, że ​​specyfikacja jest wystarczająca, o ile w zespole pracuje ktoś, kto ma wiedzę w dziedzinie.

Pracuję w bardzo wyspecjalizowanej branży: produkujemy oprogramowanie dla mediów nadawczych. Prawie nie wiem nic o nadawaniu, ale znam kod i znam dane, a także mam dobrych ludzi w zespole zarządzającym projektem, którzy rozumieją nadawanie. Ta formuła była wystarczająco dobra przez ostatnie kilka lat, aby uzyskać dobrą funkcjonalność, którą lubią klienci.

Mason Wheeler
źródło