Partnerzy technologiczni i produktowi
Dla dostawców oprogramowania i firm produktowych, które potrzebują zespołu inżynierskiego obok własnego przez lata, a nie przez jeden sprint. Moduł, którym zarządzamy od początku do końca, platforma, którą pomagamy utrzymywać, albo drugi zespół niosący roadmapę, której nie mogą Państwo obsadzić, z tymi samymi osobami, które zostają na tyle długo, by poznać dziedzinę.
Inaczej niż zakup projektu
Projekt ma koniec i z tego wynika wszystko, jak jest obsadzany: osoby są przydzielane, dziedzinę poznaje się na tyle, by skończyć, a wiedza odchodzi razem z nimi. Produkt się nie kończy. Od zewnętrznego zespołu potrzebuje ciągłości, zainteresowania tym, by architektura przetrwała kolejne dwa lata, oraz ludzi, którzy się sprzeciwią, gdy skrót kosztuje później więcej, niż dziś oszczędza.
Taką relację opisuje ta strona. Handlowo zwykle wygląda jak dedykowany zespół; partnerstwem czyni ją to, że odpowiadamy za wynik w Państwa produkcie, a nie za listę zgłoszeń.
Za co zwykle odpowiadamy
Moduł, którym zarządzamy od początku do końca
Jedna ograniczona część Państwa produktu: warstwa integracji, strona raportowa, panel administracyjny, klient mobilny. Odpowiadamy za nią w Państwa bazie kodu, według Państwa architektury, i za jej defekty, a nie za liczbę zgłoszeń.
Drugi zespół przy roadmapie
Wszystko, co wiedzą Państwo, że należy zbudować, a czego nie mogą obsadzić. Równoległy zespół pracujący w Państwa repozytoriach i rytuałach, więc roadmapa posuwa się na dwóch frontach, zamiast być repriorytetyzowana do jednego.
Platforma pod spodem
Infrastruktura chmurowa deklarowana w Terraform, pipeline'y, środowiska, observability, praca nad bazami danych i bezpieczeństwem. To, na co zespół produktowy nigdy nie ma czasu, a czego brak odczuwa co tydzień.
Rozwój starego produktu
Produkt, który się sprzedaje, ale przestał dawać się zmieniać. Dotąd dziewięć przejęć, najstarsze napisane w 2008 roku, zawsze zaczynających się od przeglądu bez zmian w kodzie i pisemnej listy ryzyk, a nie od propozycji przepisania.
Co sprawia, że długie partnerstwo działa
Ludzie, którzy zostają
Współpraca trwa tu latami, a nie sprintami, a wiedza o dziedzinie zostaje przy tych samych ludziach. Najgorszym wynikiem dla partnera jest dwukrotne płacenie za tę samą krzywą uczenia się.
Państwa architektura, nie nasza
Jesteśmy przyzwyczajeni do podejmowania tego, na czym produkt już działa, zamiast kierować go ku temu, co akurat znamy. Zespół partnerski, który wciąż proponuje przepisanie, to zespół partnerski, który przestał być przydatny.
Zasady, które przetrwają przekazanie
Testy trafiają razem z funkcją, build kończy się zerem ostrzeżeń, bezpieczeństwo działa w modelu „odmowa domyślna” (deny-by-default), a infrastruktura jest kodem. Kod napisany w ten sposób to kod, który Państwa inżynierowie mogą przejąć.
Jeden właściciel każdego faktu
Wartości pochodne są obliczane raz i używane wszędzie. W produkcie, w którym pracuje kilka zespołów, zduplikowana prawda to błąd, który znajduje się po sześciu miesiącach i którego nie da się wytłumaczyć klientowi.
Zastępstwo po naszej stronie, bez doliczania
Przegląd architektury, drugie spojrzenie na pull requesty i zastępstwo na czas urlopu pochodzą od BigTree108, a nie z Państwa budżetu.
Państwa prawa własności intelektualnej przez cały czas
Każdy specjalista przenosi rezultaty swojej pracy na spółkę przed dostępem, a te są przenoszone dalej na Państwa, więc nic w długim partnerstwie nie komplikuje kwestii tego, kto jest właścicielem produktu.
Prowadzimy własny produkt
Wszystko, czego używamy wewnętrznie, od rekrutacji i wdrożenia pracowników po rejestrowanie czasu, umowy i fakturowanie, to jedna platforma na stosie, który oferujemy partnerom: .NET w Azure Functions, Angular, Azure SQL, Terraform. To nie jest pozycja do portfolio; to system, od którego zależy firma, a z własnymi decyzjami architektonicznymi żyjemy dość długo, by wiedzieć, które z nich były błędne.
Ten osąd właśnie kupuje partner produktowy. Studium przypadku opisuje, co ten system robi i jak jest zbudowany.
Jak się zaczyna
Od czegoś małego i odwracalnego. Jeden inżynier przy wydzielonym fragmencie Państwa backlogu albo przegląd bez zmian w kodzie tej części produktu, z którą czują się Państwo najmniej komfortowo, dostarczony jako pisemna lista ryzyk w kolejności według wpływu na produkcję. Oba to tani sposób sprawdzenia, czy czytamy Państwa bazę kodu tak, jak chcieliby Państwo, żeby czytał ją partner.
Dalej zwykle powstaje dedykowany zespół, który rośnie wraz z roadmapą. Jeśli w końcu woleliby Państwo mieć zespół na własność, Build-Operate-Transfer to ci sami ludzie z przeniesieniem zapisanym w umowie.
Potrzebują Państwo drugiego zespołu przy produkcie?
Prosimy o przesłanie produktu, tej części roadmapy, która wciąż się opóźnia, i, jeśli to możliwe, linku do repozytorium. Nasze pozostałe pytania, podejście i wycenę otrzymają Państwo w ciągu jednego dnia roboczego.