Biznes jest częścią stacku technologicznego. Role produktowe wpasowują się w model backend-frontend tak samo jak role techniczne.

(Rola produktowa = product owner/project manager/product manager/&c.)

<— backend — frontend —>

infra - db - backend - frontend - qa - ba - ux - product

Role na lewo rozumieją jak system działa “z bliska”. Role na prawo rozumieją jak system działa “z daleka”. Ale ze względu na zupełnie sztuczny podział na role techniczne vs. nietechniczne wiele zespołów zakłada że istnieje jakaś niewidzialna bariera między tymi rolami która nie pozwala na to, żeby developer był jednocześnie zaangażowany produktowo.

Moim zdaniem różnica między analitykiem biznesowym a frontendem jest podobna jak między frontendem a bazodanowcem.

Jeśli jako FE nigdy nie zaglądasz do bazy danych albo nawet nie zdajesz sobie sprawy jak jest skonstruowana, to twoje postrzeganie całego systemu jest niekompletne i prawdopodobnie życzeniowe. Podobnie jeśli jesteś BA lub productem, to prawdopodobnie twoje postrzeganie jest poprzez swój własny model jak on powinien działać. (Abstrakcją tego modelu bywają tickety w Jirze.)

Jeśli jako FE widzisz coś w interfejsie to niekoniecznie reprezentacja w interfejsie przekłada się 1:1 na reprezentację w bazie danych. Jeśli BA/product widzi ticket w Jirze oznaczony jako done, to niekoniecznie acceptance criteria w tym tickecie przekładają się na działanie systemu.

Programiści i ogólnie role techniczne są ważne bo tylko oni są w stanie zrozumieć jak działa system “tak naprawdę,” tzn. według jakiego kodu jest wykonywany. Dla użytkowników systemu jego działanie jest odczuwane, i mapowane na ich własne modele.

(classical : romantic :: how it works : how it feels)

Umiejętność przekroczenia tej niewidzialnej bariery między rolą techniczną a nietechniczną jest supermocą. Jeśli jesteś w stanie używać systemu i zrozumieć jak działa i jak jest odczuwany przez użytkowników, jesteś warty znacznie więcej niż 0.5 FTE full-stacka i 0.5 FTE PMa.

W erze AI tym bardziej jest to doceniane.