Spotkanie 4

Egzamin

Prezentacja z ostatniego spotkania (część o PMBOKu dodam w kolejny weekend)

Tak, jak się umawialiśmy plan na nasze ostatnie spotkanie wygląda następująco:
1) Powtórzenie (30-40 minut; omówię wszystko, co się przyda na egzaminie)
2) Egzamin (dokładniej opisany post niżej)
3) Zamówienia z ewaluacji (w pierwszej kolejności omówienie ryzyka wg PMBOK)

Pytania (i powtórzenie) będą obejmować:
a) Ryzyko a kontekst projektu (powiązanie projektu ze strategią i oczekiwaniami stron)
b) Identyfikację ryzyk
c) Ocenę ryzyk
d) Postępowanie z ryzykiem (typy)
e) Plan zarządzania ryzykiem i dalsze kroki
f) Ryzyko związane z zespołem projektowym
g) Wybór metodyki zarządzania projektami
h) Harmonogramowanie
i) Wymagania i zakres
j) i nad tym się jeszcze zastanawiam ;)

Wiem o 2 osobach, które nie mogą być na egzaminie.
Jeśli komuś jeszcze coś wypadnie proszę o kontakt mailowy (zbigniew.misiak[at]gmail.com).

Tak w odpowiedzi na pytanie jednej osoby z grupy – strona jest robiona dla Państwa, więc zostaje również po zakończeniu kursu. Jeśli trafię na coś, co uznam za potencjalnie interesujące dla Państwa, to będę dorzucał nowe treści.

Spotkanie 3

Prezentacja – spotkanie 3

Ład korporacyjny i jego wpływ na IT – Michał Kossowski

---

Co będzie na spotkaniu 3?
Plany są takie:
* ITIL, COBIT oraz jaki wpływ na IT ma wdrażanie frameworków
[o poprowadzenie tej części dla Państwa poprosiłem swojego szefa. Michał spędza sporo czasu na projektach europejskich, więc myślę, że będzie mógł Państwu opowiedzieć sporo ciekawych rzeczy]
* Omówienie tego, co będzie na egzaminie
* Jeśli zostanie nam trochę czasu, to (w odpowiedzi na zamówienia z komentarzy) chciałbym poszerzyć to jak PMBOK podchodzi do ryzyka.

Na wypadek gdyby kogoś miało nie być info o egzaminie:
Tak, jak się umawialiśmy egzamin będzie na ostatnich zajęciach i będzie to w formie testu. Planuję 10 pytań i 20 minut czasu (tak więc zostanie nam czas na omówienie zagadnienia, które Państwo zamówią).
Pytania będą w formie krótkiego case’u z odpowiedziami typu tak/nie. W ramach przygotowania można przejrzeć prezentacje i materiały, które wrzuciłem dla Państwa na stronę, ale postaram się, aby zdrowy rozsądek wystarczył.

Przykładowe zadanie:
Razem z zespołem właśnie skończyliście szacowanie pracochłonności nowego projektu. Twój projekt ma już doświadczenia z projektami programistycznymi tego typu, więc w oparciu o dane z poprzednich projektów udało się ustalić, że na 90% skończycie w 8 miesięcy, a na 100% w 9 miesięcy. Wariant najbardziej optymistyczny to 7 miesięcy. Gdy zakomunikowałeś to swojemu szefowi wyraźnie sposępniał. “Hmmmm… Nie myślałem, że to zajmie aż tak długo i obiecałem klientowi, że będzie to za 3 miesiące. Mam pomysł – mamy sporo praktykantów z nowej rekrutacji. Jeśli dostaniesz 3 razy większy zespół to dasz radę?”.
Abstrahując od kwestii politycznych – czy mówisz:
(Tak) zgodzisz się na skrócenie terminu i przyjęcie praktykantów (nie znasz tych ludzi, ale wiesz, że znajomość potrzebnej do tego projektu technologii nie jest zbyt powszechna) w nadziei, że więcej osób pozwoli szybciej zakończyć projekt
(Nie) tłumaczysz, że większy zespół nie oznacza, że szybciej skończycie i proponujesz rozwiązanie, które pozwoli dostarczyć klientowi przynajmniej część potrzebych funkcjonalności w 3 miesiące, co pozwoli szefowi zachować twarz, Twojemu zespołowi oszczędzi niepotrzebnego stresu, a firmie na dłuższą metę utraty reputacji terminowych i solidnych dostawców.