Czy radzisz sobie z zarz

Zobacz także:

• Jak zhakowa 125,00 zł, (10,00 zł -92%)
• Biologika Sukcesji Pokoleniowej. Sezon 3. Konflikty na terytorium 117,27 zł, (12,90 zł -89%)
• Superinteligencja. Scenariusze, strategie, zagro 67,89 zł, (12,90 zł -81%)
• Regu 58,64 zł, (12,90 zł -78%)
• Socjotechnika. Sztuka zdobywania w 58,64 zł, (12,90 zł -78%)

Spis treści

Inżynieria platform dla nowoczesnych liderów. Skuteczne zarządzanie systemami i zespołami -- spis treści

Przedmowa

Wstęp

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?
  • Podsumowanie
• 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
  • Podsumowanie

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ść!
  • Podsumowanie
• 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
  • Podsumowanie
• 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
  • Podsumowanie
• 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
  • Podsumowanie
• 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
  • Podsumowanie
• 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ć
  • Podsumowanie
• 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
  • Podsumowanie
• 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ć
  • Podsumowanie

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
  • Podsumowanie
• 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
  • Podsumowanie
• 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
  • Podsumowanie
• 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
  • Podsumowanie: czym właściwie jest miłość, jeśli nie cierpieniem?

Uwagi końcowe