Czego nie uczą na kursach programowania

Gdy byłem na kursie programowania, nikt nawet nie wspomniał o Discovery. Wszystko kręciło się wokół jak budować - języki, frameworki, architektury, best practices. Nikt nie mówił o tym co i dlaczego budujemy.

To trochę tak jakby uczyć kogoś budować domy, skupiając się tylko na tym jak mieszać cement i układać cegły, ale pomijając całkowicie rozmowę z klientem o tym, czy w ogóle chce dom, czy może woli mieszkanie.

Moment, który wszystko zmienił

W ostatnich miesiącach mocniej wszedłem w tematy produktowe. I to dało mi zupełnie nową perspektywę na to, jak działa tworzenie oprogramowania. Nagle zacząłem rozumieć:

  • Jak naprawdę działa firma - nie tylko mój zespół, ale cała organizacja
  • Na czym firma zarabia - i dlaczego to, co budujemy, ma znaczenie (albo nie ma)
  • O co martwi się leadership - i jak to przekłada się na priorytety w produkcie
  • Co jest naprawdę ważne w produkcie - a co tylko wydaje się ważne z perspektywy kodu
  • Ile osób ma wpływ na decyzje - i jak skomplikowany jest proces podejmowania decyzji

Discovery vs Delivery

Discovery odpowiada na pytanie „co chcemy zbudować i dlaczego” Delivery odpowiada na pytanie „jak to zrobimy”

Inżynierowie naturalnie skupiają się na delivery. To ich strefa komfortu - kod, testy, architektura, optymalizacja. Discovery zostaje zostawione innym - najczęściej Product Managerom. Jako lider techniczny widzę to codziennie w swoim zespole.

I tutaj jest haczyk: każda firma robi discovery, nawet jeśli nigdy nie użyje tego słowa. Może to być CEO podejmujący decyzje intuicyjnie, może to być zespół badawczy przeprowadzający wywiady z użytkownikami, może to być analiza danych. Formy są różne, ale proces zawsze istnieje.

A dlaczego to wszystko ma znaczenie? Bo zespół programistów to często najdroższy dział w firmie. Nie sales, nie marketing - engineering. I musimy być rentowni. Musimy budować rzeczy, które zarabiają, albo przynajmniej maksymalnie się do tego zbliżać. Właśnie dlatego dobre discovery jest tak kluczowe - pomaga podejmować lepsze decyzje o tym, co budować, a czego nie dotykać.

Techniki discovery, o których warto wiedzieć

Nie chcę tu robić tutoriala z product discovery, ale warto wiedzieć, że istnieją konkretne metody, które pomagają odpowiedzieć na pytanie “co budować”:

  • User interviews - rozmowy z użytkownikami (nie demo, nie sprzedaż - prawdziwe odkrywanie problemów)
  • Analiza konkurencji - zrozumienie co robią inni i gdzie są możliwości na rynku
  • Opportunity Solution Trees - mapowanie możliwości i rozwiązań
  • Assumption testing - testowanie naszych założeń zanim napiszemy kod
  • Story mapping - układanie historii użytkownika w spójną całość
  • Jobs to be Done - zrozumienie czego użytkownik naprawdę chce osiągnąć

Product Managerowie używają tych technik (i wielu innych), aby podejmować lepsze decyzje o tym, co budujemy.

Dlaczego to ważne dla liderów technicznych?

Zrozumienie discovery fundamentalnie zmieniło to, jak prowadzę zespół i podejmuję decyzje:

Lepiej tłumaczę kontekst zespołowi. Nie przydzielam już zadań typu “zrób funkcję X”. Wyjaśniam jaki problem rozwiązujemy, dla kogo i dlaczego akurat to. Zespół rozumie “dlaczego” - i to zmienia jakość tego co budujemy.

Podejmuję lepsze decyzje o priorytetach. Rozumiem jak nasza praca wpływa na cele firmy. Wiem kiedy można przyjąć dług techniczny dla szybkiej walidacji, a kiedy trzeba zainwestować czas w solidne rozwiązanie. Nie wszystko musi być perfekcyjne od razu.

Skuteczniej współpracuję z PM-ami. Rozmowy przestały być o “czy to technicznie możliwe” (prawie zawsze jest). Teraz rozmawiamy o trade-offach, o tym co przyniesie wartość szybciej, co pomoże nauczyć się czegoś o użytkownikach. Mówimy tym samym językiem.

Buduję zespół który myśli produktowo. Uczę inżynierów zadawać pytania: “Jaki problem to rozwiązuje?”, “Dla kogo to robimy?”, “Jak zmierzymy czy to działa?”. To zmienia dynamikę - z wykonawców stają się współtwórcami produktu.

Widzę gdzie marnujemy zasoby. Engineering to najdroższy dział. Każdy sprint, każdy inżynier-godzina to koszt. Dobre discovery pomaga nam nie tracić tego czasu na budowanie rzeczy, które i tak nikt nie użyje.

Discovery i delivery to para nierozłączna

Nie może być dobrego produktu bez obu tych elementów:

  • Bez discovery będziemy budować rzeczy, które nikogo nie obchodzą - perfekcyjnie napisane, ale bezużyteczne
  • Bez delivery będziemy mieli świetne pomysły, które w praktyce są zbugowane, powolne i frustrujące w użyciu

To jak dwie nogi - próba chodzenia tylko na jednej kończy się upadkiem.

Co z tym zrobić?

Jeśli jesteś liderem technicznym:

  • Weź udział w procesie discovery - nie czekaj aż PM przyniesie gotowe wymagania
  • Zabierz zespół na user interviews - niech zobaczą dla kogo budujemy
  • Rozmawiaj o metrykach - jak zmierzymy czy to co budujemy ma sens?
  • Tłumacz “dlaczego” - nie tylko “co” i “jak”, ale przede wszystkim “dlaczego”
  • Ucz zespół myśleć produktowo - zachęcaj do pytań o użytkowników i problem

Jeśli jesteś inżynierem:

  • Zapytaj swojego lidera/PM-a jak podjęto decyzję o danym feature
  • Poproś o udział w rozmowach z użytkownikami
  • Dopytuj o kontekst - dla kogo to robimy? Jaki problem rozwiązujemy?

Im lepiej rozumiesz discovery, tym lepszym stajesz się liderem technicznym. Bo budujesz nie tylko kod - budujesz produkty, które mają sens biznesowy. I zespół, który rozumie po co to wszystko.

Dobre delivery bez discovery to budowanie niewłaściwej rzeczy we właściwy sposób. Dobre discovery bez delivery to świetny pomysł, który nigdy nie ujrzy światła dziennego. Potrzebujemy obu.