Jak ważna jest wiedza domenowa a wiedza techniczna?

Pracuję nad aplikacją do zarządzania transakcjami i ryzykiem i chociaż na tle C # zostałem poproszony o pracę nad pakietami SSIS. Teraz mogę z tym żyć. Problem w tym, że zbyt duży nacisk kładzie się na zrozumienie biznesu. Handel (dokładniej Handel Energią) jest OGROMNYM obszarem, a zrozumienie każdego jego fragmentu jest przytłaczające. Ale przez ostatnie dwa miesiące pracowałem nad zrozumieniem warunków biznesowych - Mark To Market, Metryki ryzyka, Pozycje, PnL, Grecy, Instrumenty, Struktura książki ... każdy drobiazg (rozumiesz). Teraz IMHO, to jest praca licencjata. Pewnie, że programiści bardzo dobrze rozumieją biznes, ale gdzie wyznaczasz granice?

Kiedy rozmawiałem na ten temat z moim menedżerem, prawie wyśmiewał mnie, mówiąc, że każdy może nauczyć się technologii w ciągu tygodnia. To trudniejszy biznes. Moim długoterminowym dążeniem jest pozostać po stronie technicznej, prawdopodobnie zostać architektem (jeśli to możliwe). Gdybym tak bardzo skoncentrował się na biznesie, zdobyłbym tytuł MBA!

Chcę wiedzieć, czy mylę się, czy jestem zbyt naiwny, jeśli chodzi o zrozumienie znaczenia firmy, czy też moja frustracja jest uzasadniona?

Zadaniem programisty jest tłumaczenie wymagań języka naturalnego na implementacje języka maszynowego. Nie możesz tego zrobić skutecznie, jeśli jesteś biegły tylko z jednej lub z drugiej strony. O ile nie piszesz kompilatorów lub oprogramowania do kontroli wersji, prawie każde zadanie programistyczne wymaga znacznej wiedzy pozaprogramowej.

Benjol i twój menedżer mają rację, ale pozwól mi rozwinąć:

nauka domeny biznesowej to sposób, w jaki dodajesz wartość procesowi i zwiększasz swoją wartość dla firmy

na tym polega różnica między programistą kodującym małpy a programistą

Jest takie powiedzenie, które pochodzi z mojego uniwersyteckiego Wydziału Informatyki:

Jeśli chcesz zbudować oprogramowanie dla geologów, musisz najpierw zrozumieć geologię. Jeśli chcesz zbudować oprogramowanie dla fizyków, musisz najpierw zająć się fizyką. Jeśli chcesz zrozumieć biznes, najpierw musisz nauczyć się rozmawiać o biznesie.

Przez cały czas słyszę ludzi mówiących, że tworzenie oprogramowania to dziedzina kreatywna. Uważam, że jest to do pewnego stopnia prawdziwe. Wymaga kreatywności, ponieważ aby rozwiązać szereg problemów, trzeba widzieć poza ramką.

Nie znaczy to, że możesz po prostu usiąść i och, tak twórczo budować, co chcesz. To nie jest klasa sztuki, to inżynieria, a twoi klienci i interesariusze będą oczekiwać, że stworzysz coś, co rozwiąże ich problemy, a nie coś, co będzie po prostu „fajne”.

Aby rozwiązać problem, najpierw musisz go zrozumieć. Musisz wejść w głowy użytkowników i zrozumieć, jak myślą.

Niezależnie od tego, czy tworzysz oprogramowanie dla finansów, marketingu, sprzedaży, geologii, fizyki, czy jakiejkolwiek innej dziedziny obsługiwanej przez oprogramowanie, musisz stać się częścią tej dziedziny.

Z tego właśnie powodu, oprócz mojego stopnia informatyki, uzyskałem także stopień biznesowy; wywarło to ogromny wpływ na moją zdolność do komunikowania potencjalnych rozwiązań i dostarczania udanych produktów.

Jeśli chcesz dowiedzieć się więcej o tym, czego bym szukał, zatrudniając inżyniera oprogramowania biznesowego, zapoznaj się z próbką ogłoszenia o pracy inżyniera biznesowego , którą napisałem jako odpowiedź na inne pytanie.

Możesz przetrwać bez dużej wiedzy na temat domeny lub kontaktu z klientem jako programista niskiego poziomu, ale architekt oprogramowania to ktoś, kto bardzo dobrze zna domenę i aktywnie komunikuje się ze wszystkimi zainteresowanymi stronami.

Moim zdaniem jesteś w błędzie i zbyt naiwny.

Jak powiedział kierownik (nieco nonszalancko), każdy może nauczyć się technologii w ciągu tygodnia. Jedyną rzeczą, która wyróżni Cię i sprawi, że będziesz przydatny dla Twojej firmy, jest Twoja wiedza biznesowa. A im trudniej, tym więcej będziesz wart.

Oczywiście, jeśli okaże się, że ten konkretny biznes jest przytłaczająco nudny, możesz poszukać czegoś innego. Ale jeśli twoim pomysłem na raj jest zhakowanie małych stron php, strzeż się: będą robić to tysiące dzieciaków ze skryptami.

Poważnie: „Jestem tylko programistą, nie myl mnie z faktami”, po prostu tego nie przerwie.

Pracuję również w handlu energią. Wiedza biznesowa stanowi 90% pracy. Nie da się tego obejść - to skomplikowana sprawa.

Jeśli przynajmniej nie rozumiesz podstaw handlu i rynków, na których pracujesz, będziesz walczył bez względu na to, jak dobry jesteś programista.

Pracuję z niektórymi licencjatami, którzy po prostu nie są w stanie sprostać wymaganiom. Muszę polegać na własnych umiejętnościach analitycznych i zrozumieniu wiedzy biznesowej, aby wykonać zadanie.

Myślę, że jeśli pracujesz w sklepie, który sprzedaje oprogramowanie do handlu energią, twoje doświadczenia mogą się różnić - ale w korporacyjnym handlu energią IT nacisk kładziony jest na zrozumienie rynku i tego, jak oprogramowanie może w pierwszej kolejności rozwiązać problemy firmy.

Rzeczywiste zastosowane technologie i ich wdrożenie zajmują odległą chwilę.

Facet powyżej, który napisał komentarz do Excela, nie wie, jak trafny jest jego komentarz. Handlowcy często budują własne małe aplikacje do handlu w Excelu / VBA (to wszystko, co wiedzą), a następnie IT dziedziczy te programy.

Chciałbym odbudować niektóre z tych aplikacji w „właściwym” języku, ale nie zawsze jest to priorytet.

Jeśli rozwijasz się dla firmy, w rezultacie będziesz mieć jaśniejsze i bardziej szczegółowe pojęcie zasad biznesowych niż ktokolwiek inny w firmie. Niekoniecznie dlatego, że jesteś mądrzejszy niż wszyscy, przychodzi, ponieważ jest to jedyny sposób na wykonanie pracy.

Twoja reakcja może brzmieć „Ale co robią analitycy biznesowi?”

Analitycy biznesowi odbywają długie spotkania z klientami, starając się uzyskać od nich wymagania, które są wystarczająco jasne, aby mógł z nimi pracować programista. Patrzę na sposób, w jaki mają do czynienia z klientami i jestem wdzięczny, że nie muszę tego robić.

Lubię rysować analogie między tworzeniem oprogramowania a architekturą. Oba są sztukami stosowanymi. Oba wymagają skomplikowanego modelowania w umyśle. Aspekt, który odnosi się do tego pytania, jest taki, że pisanie oprogramowania bez wiedzy biznesowej jest jak projektowanie budynku bez zrozumienia stylu życia i potrzeb mieszkańców. Myślę, że wielu z nas widziało (a nawet mieszkało / pracowało) budynki, które mogą wyglądać pięknie i nowocześnie, a co więcej z zewnątrz, po prostu nie nadają się do użytku od wewnątrz. (W najgorszym przypadku nie są nawet mili: - ((())

Aktualizacja

Komentarz Gaurav:

ciekawi mnie, w jakim stopniu programista powinien starać się zrozumieć domenę biznesową. Powinien przejść całą drogę, czy jest jakaś linia do narysowania.

Nie sądzę, aby można było narysować linię w ogóle. O ile nie ma części aplikacji / domeny, których nigdy nie musisz dotykać (a więc rozumieć). Które jest IMHO bardzo rzadkie w prawdziwym życiu, w dłuższej perspektywie. Każda aktywna część aplikacji otrzyma raporty o błędach i żądania funkcji. Zmieniają się także domeny, zmieniają się odpowiednie przepisy, zasady podatkowe, polityki, nawyki - krótko mówiąc - rzeczywisty świat. Należy to również uwzględnić w oprogramowaniu.

Ale nawet bez zewnętrznych próśb o zmiany, testowanie jednostkowe i refaktoryzacja starszego kodu wymaga również zrozumienia odpowiednich obszarów domeny. W przeciwnym razie po prostu „zamrozisz” bieżące zachowanie aplikacji, nie wiedząc, czy rzeczywiście jest poprawne.

Aktualizacja 2

co jeśli [...] programista często zmienia domenę biznesową, nad którą pracuje?

To oczywiście oznacza, że ​​znaczna część inwestycji (twojego czasu i pieniędzy pracodawcy) na zdobycie wiedzy biznesowej jest tracona :-( Jeśli wiesz, że to się stanie, oczywiście może nie warto zagłębiać się zbyt głęboko konkretną domenę. Pamiętaj jednak, że domeny nie są całkowicie różne, istnieją podstawy, których można użyć ponownie między różnymi domenami. A co najważniejsze, zdobyte podejście projektowe oparte na domenie jest wielokrotnego użytku.

Pracuję w sektorze bankowym od ponad dziesięciu lat, opracowując aplikacje transakcyjne i zgadzam się, że ważne jest, aby programiści dobrze rozumieli biznes. Ale raz po raz, podczas procesu rozmowy, jeśli dana osoba nie ma dobrej wiedzy na temat biznesu, nie przechodzi przez drzwi.

Doprowadziło to do opracowania znacznej liczby krytycznych aplikacji i systemów przez osoby posiadające silną wiedzę biznesową, ale słabą do średnich umiejętności technicznych. Te systemy zawsze są źle zaprojektowane, które ciągle się psują, są pełne błędów, nie skalują się, prawie niemożliwe do naprawienia bez zepsucia czegoś, i to jest tak, jeśli projekt nie zostanie anulowany z powodu niewystarczających umiejętności technicznych, aby go zdobyć do produkcji.