Zarządzanie produktem · 3 min czytania
Ten o enkapsulacji
Enkapsulacja w organizacji: system chowa złożoność, a firma wystawia ją na zewnątrz. Dlaczego zmiana przekrojowa wymaga rozmów z wieloma zespołami.
W projektowaniu systemów jest enkapsulacja: nie wystawiamy złożoności na zewnątrz. Moduł ma interfejs, a to, co dzieje się w środku, nie jest sprawą wywołującego. Organizacji, które te systemy budują, ta zasada jakoś nie dotyczy. Jeśli doświadczyliście pracy w dużej organizacji, wiecie, z iloma zespołami trzeba pracować, żeby załatwić swoje zadanie.
Weźmy zespoły podzielone według domen biznesowych. Dopóki zmiana mieści się w jednej domenie, wszystko działa. Teraz zmiana przekrojowa: firmy mają kupować na fakturę z NIP. Każdy zespół musi coś dołożyć:
- Konto klienta: dane firmy przy profilu.
- Cennik: ceny netto obok brutto.
- Koszyk: pole NIP i jego walidacja.
- Zamówienia: nowy typ klienta, firma zamiast osoby.
- Faktury: faktura VAT na firmę zamiast paragonu.
Żeby wprowadzić tę zmianę, muszę porozmawiać z każdym z tych zespołów osobno.

I każda z tych rozmów jest trochę inna. Jeden zespół chce zgłoszenia w swoim backlogu, drugi zaprasza na refinement, trzeci pyta, dlaczego ma to być ważniejsze od jego celów na kwartał. Za każdym razem tłumaczę kontekst od początku, bo nikt poza mną nie widzi całej zmiany. Ustalenia z jednym zespołem zmieniają to, o co muszę poprosić kolejny, więc część rozmów odbywam dwa razy.
Samo napisanie kodu to może kilka dni. Rozmowy, notatki, uzgadnianie wymagań i pilnowanie, żeby wszyscy mieli tę samą wersję, kosztują więcej niż kod. Ten wysiłek nie trafia na żadną tablicę i nikt go nie mierzy.
W kodzie nazwalibyśmy to wyciekającą abstrakcją. Żeby coś zrobić, muszę znać wewnętrzną budowę organizacji: kto za co odpowiada, z kim i w jakiej formie rozmawiać, czyj priorytet jest ważniejszy. Ta wiedza nie ma nic wspólnego z problemem klienta.
W środowisku skalowanym rozmów przybywa szybciej niż zespołów. Frameworki skalowania dokładają kolejne warstwy synchronizacji: wspólne planowanie, tablice zależności, spotkania koordynacyjne. Zależności lepiej widać, ale ktoś nadal musi je przegadać jedna po drugiej.
W dobrze zaprojektowanym systemie złożoność zostaje w środku i nie wycieka do tego, kto z niego korzysta. Wywołuję jeden interfejs i nie muszę wiedzieć, ile modułów pracuje po drugiej stronie.
Dlaczego więc w strukturze organizacji jest inaczej?
💬 Dołącz do dyskusji na LinkedIn → Komentuj i podziel się swoim podejściem