Jako programista mogę przyspieszyć przyjęcie i zrozumienie reguł biznesowych?

Od jakiegoś czasu jestem programistą. Daleko mi do najlepszych. (Siedząc samotnie w tym pokoju, zastanawiam się, czy jestem tu najlepszy). Jednak zrozumiałem swoje narzędzia i zaufałem mojej zdolności rozumowania i uczenia się.

Rozpoczynając nową pracę, zawsze wierzę, że mogę nauczyć się podstawy kodu, jeśli jest to język, który znam. Jeśli nie znam znanego języka ani frameworka, uważam, że potrafię zrozumieć pojęcia wystarczające do nauki go (i po prostu przeczytać dokumentację). Jest to część naszego zestawu umiejętności programistów i jestem dumny, że mogę sprostać temu standardowi.

Mimo wszystko - jedną z moich głównych słabości jest nauka i internalizacja reguł biznesowych dla klienta, dla którego pracuję w szybki sposób - niezależnie od tego, czy jestem płatnym pracownikiem czy kontrahentem. Nie mam nic przeciwko bazom kodów, ale reguły i procesy biznesowe dla konkretnej firmy zawsze wydają mi się trochę zajmować. (Na przykład może to być tripup podczas przepisywania aplikacji korporacyjnych).

Jako programista, jaki jest najlepszy sposób na szybkie i wydajne przyswojenie reguł i procesów biznesowych? Czy jest to możliwe bez bycia ekspertem merytorycznym lub po prostu wieloletniego doświadczenia z klientem, firmą lub firmą?

Dla mnie jest to poprzez czytanie i rozumienie baz kodów.

Mówię to z dwóch kluczowych powodów:

1. Ludzie są do dupy. Och, nie umyślnie (zwykle), ale w biznesie zauważyłem, że ludzie często subtelnie różnie rozumieją reguły biznesowe. I każdy ma swój własny model mentalny, który z kolei traci wierność, gdy próbuje ci go przekazać. Ale kod nie kłamie. Ludzie mogą myśleć, co chcą, o tym, jak powinny działać, ale kod jest poprawny.

2. Najpierw zbuduj fundament. Jeśli więc każdy ma swój własny model mentalny tego, czym są te specyficzne dla biznesu warunki i procesy, to jak je zbudujesz? Dla mnie i oczekuję od wielu programistów, moje modele mentalne buduję najlepiej z kodu. Kod ma wzorce. Kod zawiera abstrakcje. Mam duże doświadczenie w pobieraniu kodu i budowaniu z niego modelu mentalnego. Raz mam przynajmniej mgliste kształt co rzeczy istnieją i jak odnoszą się one, wówczas mogę rozmawiać z ludźmi biznesu. Następnie mogę zadać właściwe pytania i lepiej dopasować ich odpowiedzi do układanki.

Nie bądź dla siebie zbyt surowy. Czasami zastanawiam się, dlaczego w ogóle nazywają ich „regułami biznesowymi”, ale myślę, że nazywanie ich „sposobami, które zwykle robimy, chyba że są inne rzeczy, które mają zastosowanie, a następnie robimy je inaczej” prawdopodobnie ich znieważą. Biznes jest bałagan. Żonglują potrzebami klientów, agencji prawnych, księgowości, przepisów, sprzedawców, pracowników, menedżerów i władz lokalnych. Nie zawsze mają powód.

Myślę, że najlepszym sposobem jest upewnienie się, że spędzasz czas z jak największą liczbą ludzi biznesu. Może to być trudne dla niektórych osób na stanowiskach technicznych.

1. Budżetuj swój czas i szanuj ich, ale zdobądź jak najwięcej.
2. Musisz zadawać pytania. Nie myślą jak programiści, wszystko psują i mają pełne zrozumienie, w jaki sposób informacje odnoszą się do siebie nawzajem.
3. Nie udawaj, jak rozumiesz. Gdybyś wiedział tyle samo, co inni ludzie biznesu, zmusiliby cię do wykonywania obu prac. Zobacz # 2.
4. Nie oczekuj dokumentacji. Oferuj wiele pochwał, jeśli kiedykolwiek je dostaniesz.
5. Powstrzymaj się od krytyki. Procesy i procedury mogą mieć zwolnienia i inne potencjalne usprawnienia, ale może to być powód. Dowiedz się, dlaczego, ale nie zdziw się, gdy powiedzą: „Zawsze tak robiliśmy”.
6. Bądź uprzejmy, uprzejmy i dziel się przekąskami. Masz do czynienia z ludźmi. Powiedz cześć. Zapytaj, jak się mają. Zapytaj, dlaczego weszli do branży, jak długo pracują w firmie.

Nie jesteś pustką zwaną programistą, jesteś osobą. Poinformuj ich, że jesteś tam, aby ułatwić im pracę. Niestety możesz być bohaterem lub kozą. Taka jest natura naszej działalności.

Poleciłbym przeczytać książkę Edwarda Burgera i Michaela P. Starbirda zatytułowaną 5 elementów skutecznego myślenia. Jest to związane ze zrozumieniem nowych koncepcji w ogóle, ale myślę, że dotyczy to tej sytuacji.

Oto kilka interesujących punktów z książki:

Opanuj podstawy

Jeśli nie znasz podstaw, zbudujesz swoje zrozumienie na chwiejnych podstawach. Musisz więc zadać te głupie pytania, których nikt inny nie zadaje.

Niech błędy będą twoim przewodnikiem

Czasami pomaga zadawać pytania, które są wyraźnie błędne, abyś mógł odkryć swój brak zrozumienia. (Np .: Masz na myśli, że administratorzy mają dostęp do każdego dokumentu? Och. Dlaczego?)

Naucz lub wyjaśnij to innym

Kiedy spróbujesz nauczyć go kogoś innego, zaczniesz odkrywać, gdzie masz problemy ze zrozumieniem.

Mam nadzieję, że to pomaga!

Jako programista zdałem sobie sprawę, że bezpośrednio tłumaczę biznes na kod, struktury danych, możliwe klasy itp. Przechodzę od czegoś abstrakcyjnego i często nieokreślonego do czegoś konkretnego, z „kształtem”. Natychmiast zaczynam kodować, a brak informacji prowadzi mnie do częstych refaktorów. Każdy refaktor każe mi myśleć, że istnieje zbyt wiele luk w moim rozumieniu biznesu .

Jak zacząłem to rozwiązywać?

Zmuszam się do przeczytania wszystkich dokumentów wykonanych podczas analizy funkcjonalnej i wcześniejszych faz. Staram się to robić tak, jak byłem klientem lub użytkownikiem końcowym . Muszę zrozumieć, czego szuka klient przy takiej aplikacji i wymaganiach. Ale muszę trzymać się z daleka od dev Jestem.

Nasza praca zapewnia nam ogromne umiejętności, których klienci nie mają. Myślimy w strukturach warunkowych w sposób, w jaki inni tego nie robią. Zaczynam więc konfrontować wymagania. Poszukiwanie sprzeczności lub niespójności . Trochę mózgu krąży wokół tego, co zrozumiałem. Formułowanie hipotetycznych scenariuszy.

Doprowadziło mnie to do pytań i wątpliwości. Zapisuję każdego z nich i wreszcie umawiam się z każdym, kto może rozwiązać moje wątpliwości.

Podsumowując, zmieniam punkt widzenia. Próbuję spojrzeć na problem z innej perspektywy. Ale włożyłem w to trochę umiejętności deweloperów. Co kończy się sporą ilością pytań i wątpliwości do rozwiązania. Po rozwiązaniu moje rozumienie biznesu jest głębsze.

Badanie> Wątpliwości> Pytania> Odpowiedzi> Zrozumienie (powtarzaj cykl w kółko)