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

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

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.

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.

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.

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 ...

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.

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.

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 .

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.

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).

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.

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.

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.

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?

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.

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.

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 .

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.

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.

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).

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.