Project Managment

Pachollini, 26. října 2007, 22:04

Přednáška Petra Přibyla o project managmentu pro mne byla nejzajímavější z těch, co jsem od lidí ze Seznamu zatím slyšel. Možná to je tím, že jsem project managment nikdy nestudoval, ale občas s ním přicházím do styku. Tady jsou mé poznámky z přednášky, surové, ale třeba někomu k něčemu budou. Ucelenější a stručnější text napsal Honza Bednář na blog Ataxa: Projektové řízení dle Seznamu

Teorie

Praxe

Jak jsme to dělali v Seznamu

Seznam dnes

  1. Vize – Ivo, ale může s ní přijít kdokoliv
  2. Zadání – dělá projektový manažer, schvaluje vedení; mikroanalýza – za kolik to asi uděláme a kdy to asi bude, dělají programátoři, odhad, kdy to asi bude – možnost pozastavení projektu
    • Cíle akceptované akcionáři projektu; definovat i co není cílem projektu
    • Termíny … vždycky podhodnocené
    • Náklady
    • Odpovědné osoby – projektový manažer, vedoucí programátorů, další lidé
  3. Specifikace – nástroj projektového managera: jak to má vypadat a co to má dělat; v Seznamu průměrně 30 stránek, mapy asi 100; specifikace se tvoří cca 1–4 týdny, ale může to trvat i déle (zejm. grafické návrhy – čeká se na nápad grafiků)
    • Obsahuje
      • Funkční popis výsledků – jak to bude vypadat a fungovat; popis procesů – např. u fakturačního systému – kudy půjde faktura
      • Popis cílového stavu – máme novou službu, potřebujeme 4 lidi, co na to budou dohlížet, jednoho na telfonický support , 20 serverů, 2 přidáváme každý měsíc … jak to bude fungovat
      • Grafické návrhy – hodně práce – dělají se uživatelské testy, cizeluje se to – polovina nákladů na přípravu; řeší se i rozpal písma etc.
      • Business analýza – jak to bude vydělávat, jaký bude obchodní model – zpracovávají nebo dozorují ji spíš obchodníci
      • Marketingový plán – jak se to bude propagovat, kdy etc.
    • Nástroje
      • Slovní popis – nesmí to být moc dlouhé – čím kratší, tím lepší; rozdělení na část pro vedení / programátory; čím více prostoru pro fantazii programátorů, tím víc se budou chodit ptát
      • Sitemap – jak to bude fungovat
      • UML – na procesy
      • Grafické návrhy – na ně koukaj všichni, popisy nikdo nečte
    • Zvažte
      • Rozsah specifikace X náklady na projekt
      • Rozsah X míra neurčitosti – během vývoje se mění zadání, posouvají cíle etc. – příliš podrobná specifikace => hodně se toho vyhodí při změnách
      • Rozsah X stabilita cílů
      • Rozsah X počet čtenářů
      • Úplná X rozdílová specifikace … v Seznamu se rozdílové moc nedělají, ledaže tým, který to dělá teď, je stejný, jako ten, co to dělal předtím
  4. Oponentura specifikace
    • Proč
      • Prevence chyb a opomenutí
      • Pohled 3. osoby – najde věcí, který člověk, který je do toho zahrabaný, přehlédne
      • Potenciál nových nápadů
    • Pravidla
      • Oponent nese spoluzodpovědnost za předmět oponentury
      • Akceptované podmínky je autor povinen zapracovat do specifikace
      • Oponent kontroluje zapracování připomínek
    • Oponentů může být víc, oponentura trvá cca. týden
  5. Implementační analýza – temná strana síly – vývojáři se zataženými roletami
    • Cíle
      • Návrh implementačního postupu a architektury aplikace … už víme, jak to bude se železem a zdroji
      • Možnost korekce návrhu (železo to neutáhne)
      • Přesný odhad implementační náročnosti – efektivita zpracování, škálovatelnost
      • HW sizing – objednání HW dopředu – zpoždění
      • Projektový plán
    • Algoritmický postup, konfigurační soubory a parametry, popis rozhraní – zamyšlení, jak to bude fungovat
    • (Seznam má asi 15 adminů a 10 dohledářů – vše musí být stejně konfigurovatelné, stejně zdokumentované)
  6. Oponentura implementační analýzy – od vývojářů a adminů
  7. Projektový plán
    • Rozdělení práce na dílčí úkoly (max. 2 člověkodny na úkol), WBS – Work Breakdown Structure – strom procesu, většinou se daří dobře odhadnout, mění se spíš při změně cílů
    • Závislosti dílčích úkolů, kritická cesta – nejkratší čas, za který se to dá stihnout … kvůli závislostem – Seznam používá MS project
    • Přiřazení zdrojů – kolik programátorů, kolik času, kolik je tam státních svátků, kolik dovolených etc.
      • přehazování úkolů mezi lidmi
      • nebezpečí: zkracování času, který je přidělen jednotlivým úkolům – nedělat
    • Určení postupu, milníků, termínů – přidat minimálně 20% rezervu (přiznat týmu – budou na to hřešit, nepřiznat – budete za zlý)
    • Gantův diagram
    • Podléhá schválení akcionářů – opět podepsat – nové termíny etc.
    • Řešení Seznamu
      • WBS na zdi
      • Projektový plán v MS Projectu (používá se jen na projektový plán, na nic jiného)
      • Výjimečně Mind Maps – spíše ve fázi vize
      • … založeno na zkušenostech
      • na jednodušší projekty má tento postup relativně vysoké náklady na režii
    • Zabere to 1–5 člověkodní
  8. Implementace
    • kontroluje se plnění projektového plánu
    • změny do projektového plánu se zanáší 1x za 1–2 dny, zanáší je vedoucí implementace nebo projektový manager; sleduje se zpoždění a překročení rozpočtu
  9. Testy
    • Funkční testy
      • Většinou ručně bez pomocných nástrojů
      • Bez formalit, pouze Issue Tracking (Mantis – PHP webová aplikace, Trac – nově se na něj přechází, spolu se Subversion)
      • Testy v tzv. produktovém prostředí – „my jsme tam zrovna něco opravovali, proto to nefungovalo“ => dev servery, testovací servery v kanceláři – kopie produkčních – v podstatě kompletní kopie Seznamu, ale v některých případech s méně daty => produkční testy; věci se instalují debianími balíčky, které se instalují stejně na testovací servery jako na produkční servery
      • Konečnou zodpovědnost má projektový manager
      • Externí testeři – honorováni za nalezenou chybu dle závažnosti –> pro managery: je dobré je nenechat najít moc kritických chyb
      • Uživatelské testy na funkční aplikaci – bude o tom samostatná přednáška; někdy se uživatelské testy dělají už před aplikací – na grafických návrzích nebo prototypu – nákladné, moc se nedělají
    • Zátěžové testy
      • V režii vývojářů
      • Pravidlo: vždycky testy výkonu databáze (Hammerhead), testy zátěže webu (simulace uživatelů)
      • Vzorek dotazů: access logy
      • Alespoň 30% rezerva, vždycky to musí být škálovatelné
      • Simulovaný provoz: web se umístí ven, dá se na stávající stránky jako iframe, aby byla stejná zátěž – při jiné verzi to nemusí být úplně vypovídající
    • Bezpečnostní audity – řeší externisti, kteří to testují před spuštěním (bez znalosti backendu)
  10. Rollout plán
    • Podrobný dokument – jak to zprovoznit – konfigurovat, administrovat etc. – např. pro případ havárie serveru; přímo příkazy, které se mají spouštět
    • Obsahuje časovou osu
    • Nastavení monitorování a grafování komponent (výkon serverů, počet dotazů do db etc.)
    • Instalace pomocí debianích balíčků
  11. Údržba
    • Okamžikem spuštění začíná další práce – nové připomínky, bugy, nápady
  12. Vyhodnocení
  13. Co se ještě může dít
    • Uživatelské testy již v úvodu
    • Prototyp aplikace
    • Betaprooz – může hodně změnit plán
    • Rollback – všecko se odvolá, návrat k původní verzi – důležité stanovit, kdy je ještě rollback možný

Co vy na to?

zobrazit všechny komentáře

Aktuální Seky

.