Część I. Czym jest inżynieria platform i dlaczego warto się nią zajmować? Rozdział 1. Dlaczego inżynieria platform staje się niezbędna? Definicja platformy i innych istotnych terminów Bagno nadmiernych uogólnień Jak utknęliśmy w bagnie nadmiernego uogólnienia? Przyczyna nr 1: eksplozja możliwości Przyczyna nr 2: zwiększone wymagania operacyjne Skutek: grzęźniemy w bagnie W jaki sposób inżynieria platform pozwala oczyścić bagno? Ograniczenie dostępnych usług elementarnych i zmniejszenie dodatkowego narzutu integracyjnego Redukcja kodu integrującego w obrębie aplikacji Centralizacja kosztów migracji Umożliwienie deweloperom aplikacji utrzymywania ich produktów Zwiększanie autonomii zespołów, aby mogły skupić się na budowaniu platform Czy stosowanie platform sprzyja innowacjom? Rozdział 2. Filary inżynierii platform Podejście oparte na starannym doborze funkcjonalności produktu Wytwarzanie abstrakcji programistycznych Główne rodzaje warstw abstrakcji: usługi platformy i ich API Grube klienty Dostosowania wykorzystywanych komponentów Integracja z rejestrami metadanych Dostarczanie rozwiązań dla szerokiego kręgu programistów aplikacji Platforma jako komponent fundamentalny Odpowiedzialność za całość platformy Zapewnienie wsparcia dla platformy Dyscyplina w działaniach operacyjnych Część II. Praktyki inżynierii platform Rozdział 3. Jak i kiedy zacząć? Kształtowanie współpracy wokół platformy w niewielkich przedsięwzięciach Powołanie zespołu inżynierii platform w miejsce luźnej współpracy Czy wprowadzenie scentralizowanej odpowiedzialności jest opłacalne? Dynamika zespołowa stała się przeszłością Skup się na rozwiązywaniu problemów, a nie na nowej technologii lub architekturze Strzeż się nowych inżynierów przybywających ze znacznie większych przedsiębiorstw Nie spiesz się z zatrudnianiem menedżerów produktów (i unikaj menedżerów projektów) Dodatkowe problemy związane z platformami integracyjnymi i oferującymi współdzielone usługi Transformacja tradycyjnej organizacji zajmującej się infrastrukturą Cała kultura pracy inżynierskiej musi zostać wymieniona Na początek zidentyfikuj najbardziej obiecujące obszary Nie myśl, że całą sprawę załatwi zatrudnienie kilku menedżerów produktu Zmień sposób utrzymywania produktów Zaktualizuj proces rekrutacyjny Zaktualizuj systemy motywacyjne Nie przesadzaj z liczbą menedżerów projektów Twój zespół będzie spędzał więcej czasu na rozmowach z klientami, a mniej na pisaniu kodu Przeprowadź niezbędną restrukturyzację Niech to będzie też radość! Rozdział 4. Formowanie wspaniałych zespołów platformowych Ryzyko związane z zespołami platformowymi o zbyt jednolitej specjalizacji Zbyt duże nastawienie na administrowanie systemami Zbyt duże nastawienie na programowanie Różnorodność ról inżynierów platform Inżynierowie oprogramowania Inżynierowie systemów Inżynierowie niezawodności Specjaliści systemowi Zatrudnianie inżynierów i docenianie ich pracy Dopuszczaj nazwy stanowisk charakterystyczne dla niektórych ról Unikaj tworzenia nowej struktury poziomów dla inżynierów oprogramowania Stwórz nie więcej niż jedną strukturę poziomów dla ról systemowych Jeżeli trzeba, stwórz nowy proces rekrutacyjny dla inżynierów oprogramowania platform Tylko w niewielkim stopniu zmieniaj proces rekrutacji w zależności od roli Sprawdzaj empatię dla klienta Po czym poznać znakomitego menedżera inżynierii platform? Doświadczenie w utrzymywaniu platform Doświadczenie w prowadzeniu dużych i długotrwałych projektów Przywiązywanie wagi do szczegółów Pozostałe role w zespołach platformowych Menedżerowie produktów Właściciele produktów Menedżerowie projektów i menedżerowie programów technicznych Rzecznicy deweloperów, redaktorzy techniczni i inżynierowie wsparcia technicznego Kształtowanie kultury zespołu inżynierii platform Podział platformy pomiędzy zespół deweloperski i SRE Mocne i słabe strony zespołu deweloperskiego Połączenie zespołów i wprowadzenie menedżera produktu Zaszczepianie kultury inżynierii platform Rozdział 5. Platforma jako produkt Głównym elementem kultury produktowej jest klient Cechy klientów wewnętrznych Współpraca z klientami wewnętrznymi Empatia dla klientów Pułapka masowej produkcji funkcjonalności Badanie potrzeb użytkowników i analiza rynku Identyfikowanie potencjalnych produktów platformy Ewolucja istniejących rozwiązań: wygładzanie kantów czy redefinicja problemu Badania rynku: potwierdzanie słuszności inwestycji Wskaźniki produktu Sukces w realizacji produktu: opracowanie strategii rozwoju produktu Wizja: odległa perspektywa czasowa Strategia: średnioodległa perspektywa czasowa Cele i wskaźniki: na ten rok Kamienie milowe: kwartalnie Plan dostarczenia produktu z punktu widzenia klienta Specyfikacja funkcjonalności Praktyka czyni mistrza Typowe porażki w realizacji produktu Niedoszacowanie kosztów migracji Przeszacowanie budżetu na zmiany, którym dysponują użytkownicy Przeszacowanie wartości nowych funkcjonalności, podczas gdy ich stabilność jest niska Zbyt wielu menedżerów produktów w porównaniu do rozmiaru zespołu inżynierów Menedżerowie produktów wykonują pracę menedżerów technicznych Rozdział 6. Utrzymanie platform Praktyki dyżurów Dlaczego ważny jest dyżur całodobowy? Dlaczego włączać specjalistów DevOps do wspólnego zespołu? Równomierne rozkładanie obciążenia dyżurami Praktyki wsparcia klienta Dlaczego inżynierowie platform powinni choć trochę zajmować się wsparciem użytkowników? Etap 1: wprowadzenie sformalizowanych poziomów wsparcia Etap 2: rozdzielenie wsparcia problemów niekrytycznych od dyżuru utrzymaniowego Etap 3: zatrudnienie specjalisty od wsparcia klienta Jak wspierać klientów w odległych strefach czasowych? Etap 4: działanie na dużą skalę poprzez osobną jednostkę wsparcia inżynierskiego Praktyki przeglądów incydentów i awarii Cele i gwarancje poziomów usług są obowiązkowe, budżety błędów są opcjonalne Zarządzanie zmianą Monitorowanie syntetyczne Przeglądy działań utrzymaniowych Rozdział 7. Planowanie i wdrażanie Planowanie długotrwałych projektów Wskazanie celów i wymagań w dokumencie propozycji Przejście od propozycji do planu działania Unikanie długotrwałego wysiłku Oddolne planowanie rozwoju produktu Utrzymanie podstawowej działalności Wytyczne zarządu Usprawnienia systemu Połączenie wszystkiego razem Skuteczne komunikowanie statusu prac Podstawy Jaką to ma wartość? Struktura aktualizacji na temat sukcesów i wyzwań Nie zapomnij o wyzwaniach! Niech Twój zespół napisze o sukcesach i wyzwaniach Rozdział 8. Reorganizacja architektury platform Dlaczego reorganizacja architektury jest lepsza od budowania kolejnej wersji? Różne mentalności inżynierów Mentalność wynika z potrzeb architektonicznych Dlaczego trudno jest zbudować kolejną wersję systemu, ale reorganizacja architektury jest możliwa? Bezpieczeństwo jako element architektury Mechanizmy kontrolne dla reorganizacji architektonicznej Kompatybilność Testowanie Środowiska niższych rzędów Podział na transze, stopniowe wdrożenia i wykorzystywanie poprzedniej wersji Planowanie reorganizacji architektury Krok 1: myśl z rozmachem o celach reorganizacji architektury Krok 2: uwzględnij koszty migracji Krok 3: wskaż istotne korzyści, jakie nastąpią w ciągu kolejnego roku Krok 4: zdobądź zgodę kierownictwa i bądź gotów cierpliwie czekać Rozdział 9. Migracje i wygaszanie platform Antywzorce migracyjne Inżynieria łatwiejszych migracji Wykorzystuj abstrakcje produktów minimalizujące ilość kodu integracyjnego i ograniczające liczbę wariantów Projektuj architekturę umożliwiającą transparentne migracje Wykorzystuj metadane do monitorowania wykorzystywanych zasobów Rozwijaj automatyzację, aby uniknąć ręcznego śledzenia postępów Dokumentuj sposoby przechodzenia na nowe rozwiązanie i wycofywania starego Skuteczna koordynacja migracji Ustalaj zakres, ograniczaj wpływ i określaj priorytety planowanych zmian Jak najwcześniej rozsyłaj informacje poprzez publiczne kanały Ostatnie 20% trzeba przepchnąć siłą Oszczędnie szafuj nakazami Wygaszanie platform Podejmowanie decyzji o momencie wygaszenia Koordynacja wygaszania Nie obawiaj się uzasadnionego wygaszania Rozdział 10. Zarządzanie relacjami z interesariuszami Analiza interesariuszy: mapa wpływu i zainteresowania Komunikacja z odpowiednią dozą transparencji Nie dziel się zbyt wieloma szczegółami Z rozwagą stosuj spotkania indywidualne Pamiętaj o ustaleniach i zobowiązaniach Na większą skalę stosuj spotkania koordynacyjne i zespoły doradcze klientów Intensyfikuj komunikację w trudnych okresach Odnajdywanie akceptowalnych kompromisów Klarownie komunikuj wpływ na działalność biznesową Czasami się zgadzaj, ale pod warunkiem kompromisu Odmawianie bez niszczenia relacji Kompromisy dotyczące nieoficjalnych platform Problemy z pieniędzmi: zarządzanie kosztami i budżetem Krok 1: zastanów się, kto będzie zyskiwał w przyszłości Krok 2: przypisuj prace do zespołów (nie stosuj podejścia indywidualnego) Krok 3: wychodź z propozycjami cięć i z przekonaniem broń obszarów, które chcesz zachować Część III. Jak rozpoznać sukces? Rozdział 11. Twoje platformy działają w harmonii Harmonia celu Dostosuj zespół przez odpowiedni dobór członków Dostosuj kulturę poprzez stosowanie wspólnych praktyk Dostosuj kulturę poprzez współpracę międzyzespołową Harmonia strategii produktu Zachęcaj do myślenia w kategoriach wielu platform, stosując niezależne zarządzanie produktami Zachęcaj do opracowywania architektury obejmującej wiele platform poprzez wprowadzanie niezależności głównych specjalistów Zbieraj opinie za pomocą ankiet klienckich dotyczących całej platformy Rozważnie rozwiązuj niezgodności poprzez restrukturyzację Harmonia planów Synchronizuj tylko większe projekty, a nie wszystkie szczegółowe zadania Stanowczo reaguj na brak zgodności Pełna harmonia jest efektem przywództwa kierującego się zasadami Powiązanie wszystkich elementów: osiągnięcie harmonii organizacyjnej Rozdział 12. Twoje platformy cieszą się zaufaniem Zaufanie do metod operacyjnych Wzmacniaj zaufanie przez angażowanie doświadczonych liderów Optymalizuj wzrost zaufania poprzez ustalanie kolejności przypadków użycia Zaufanie do dużych inwestycji Zaufanie do reorganizacji architektury buduj w oparciu o zgodę technicznych interesariuszy Zaufanie do nowych produktów buduj w oparciu o wsparcie sponsorów z kadry zarządzającej Podtrzymuj zaufanie, utrzymując stare systemy Aby zyskać zaufanie, musisz zachować elastyczność w określaniu, co jest "słuszne" Zaufanie do zdolności dostarczania zmian Wprowadź kulturę sprawnego działania Preferuj projekty, które uwalniają moce przerobowe zespołu Kwestionuj założenia dotyczące zakresu produktów Wszystko razem: opowieść o zbyt ściśle powiązanej platformie Rozdział 13. Twoje platformy skutecznie zarządzają złożonością Zarządzanie przypadkową złożonością wynikającą z koordynacji osób Zarządzanie złożonością nieoficjalnych platform Zarządzanie złożonością poprzez kontrolę wzrostu Zarządzanie złożonością dzięki odkrywaniu potrzeb produktowych Wszystko razem: równoważenie wewnętrznej i zewnętrznej złożoności Wypalenie z powodu operacyjnego utrzymywania systemów open source Próby (nieudane) zmiany reguł gry Nieoficjalne platformy wymuszają reset Realizacja nowego otwarcia Rozdział 14. Twoje platformy są uwielbiane Miłość po prostu działa Miłość może wyglądać jak sprytny trik Miłość może być oczywistością Wszystko razem: miłość sprawia, że użytkownicy stają się wspaniali czym właściwie jest miłość, jeśli nie cierpieniem?