Właśnie ruszyła rekrutacja na kolejny rok studiów podyplomowych na Akademii Koźmińskiego. Oferujemy specjalizację Zarządzanie projektami IT oraz Zarządzanie wymaganiami i analiza biznesowa. Oba kierunki w znacznej części składają się z praktycznych warsztatów, symulacji i ćwiczeń. (więcej…)
Konsekwencją rozpoczęcia prac na nie zamkniętych wymagań bywa ich pełzanie, czyli postępujące zmiany zakresu. Pełzanie zakresu jest jedną z najczęstszych patologii projektowych, czyli fundamentalnych źródeł ich niepowodzenia. Projektów nie patologii, bo te ostatnie mają się świetnie.
Wyobraźcie sobie, że zamówiliście w stoczni statek, stocznia entuzjastycznie zamówienie przyjęła i zaczęła kleić kadłub, budować kabinę, kupować takielunek, bo jako krytyczny postawiliście warunek oddania łodzi przez lipcem. Wszak zamierzacie zabrać ją na wakacje. Po miesiącu szkutnik pojawia się u was, dumnie prezentując zdjęcia nieukończonego kadłuba i coś wam zaczyna zgrzytać. Niepojące wrażenie, że ten kadłub jest za szeroki i brakuje dwóch pozostałych, wszak oczywistym jest, że chodziło wam o trimaran. Jednak zapał szkutnika zaraża i was, i postanawiacie nie robić z tego afery. Po prostu zgłaszacie drobne zmiany tu i tam. Mówicie, że przydałyby się wsporniki, że może dałoby się ten kadłub trochę zwęzić. W końcu rzucacie niewinną uwagę, że można by rozpiąć siatkę między kadłubami. I wtedy, na miesiąc przed wakacjami, stoczni zapala się żółta lampka. Jakimi kadłubami? Może to przejęzyczenie w e-mailu. Ponieważ jest mało czasu do końca projektu, lampka z żółtej zostaje przełączona na zieloną, a siatki postanawia się rozpiąć na tym jednym kadłubie. Wygląda to dziwacznie, ale skoro klient chce, to kto mu zabroni. Ty z kolei jesteś zadowolony, bo zgłosiłeś oficjalnie kwestię trzech kadłubów (trimaran ma ich aż trzy) e-mailem, a dostawca nie zaoponował. I wreszcie spotykacie się na koniec czerwca, wpadacie sobie w ramiona. Dostawca odsłania z dumą swoje dzieło, a twoja szczęka z hukiem uderza o deski pokładu.
Powyższy fragment pochodzi z książki na temat prowadzenia firmy projektowej, którą właśnie piszę o roboczym tytule Project Inc.
Zdjęcie tytułowe zapożyczono z Wikipedii
Analiza wymagań obfituje w techniki zbierania i specyfikowania potrzeb klientów, bądź użytkowników nowych produktów, bądż usług, bądź rozwiązań. Jednak wsłuchanie się w głos klienta może zaowocować zebraniem sążnistej listy. Przegląd ofert konkurencji może ten spis oczekiwań dodatkowo wydłużyć do rozmiarów książki telefonicznej. Zdarza się, właściwie zawsze tak się zdarza, że nie jesteśmy w stanie ich wszystkich zaimplementować w naszym rozwiązaniu. A to ze względu na ograniczenia czasowe, wszak projekt musi się kiedyś skończyć, a to finansowe, wytworzenie produktu nie może kosztować więcej niż cena za niego możliwa do osiągnięcia, a to technicznie, bo po prostu może fizycznie nie dać się zaimplementować wszystkiego. Wtedy z pomoca przychodzi zgrabna metoda syntezy wymagań do najlepszej możliwej kombinacji. Metoda owa zwana Quality Function Deployment, w niezwykle drobiazgowy sposób pozwala ustalić balans między ograniczeniami, działaniami konkurencji, a potrzebami klienta. Jednak niezwykład drobiazgowość domku jakości, tak po polsku bywa nazywana QFD, gubi jej amatorów. Poniżej proponuję podejście uproszczone, choć moćno inspirowane QFD.
Właśnie skończyliśmy prace nad naszymi najnowszymi symulacjami szkoleniowymi. Obie były przygotowywane na potrzeby dużego programu szkoleniowego w jednej firm IT dotyczącego 400 analityków i wdrożeniowców. Obie są powiązane ze sobą i ilustrują dwie odmienne perspektywy patrzenia na projekt informatyczny. Spojrzenie ze strony analityka i wdrożeniowca.
Analiza biznesowa to coraz bardziej modny termin o dość pojemnym znaczeniu. Pierwotnie dotyczył analizy finansowej i marketingowej nowych przedsięwzięć. Z czasem projekty informatyczne go zawłaszczyły. Poniżej można znaleźć przegląd perspektyw rozumienia tego terminu i przykładowe techniki stosowane w jego obszarze.
Od dwóch miesięcy powstaje nasza najnowsza symulacja szkoleniowa pod roboczą nazwą Samoloty. Symulacja na temat współpracy analityków z wdrożeniowcami we wspólnych projektach. “Projektach”, bo tym razem uczestnicy będą mieli za zadanie wykonać 4 projekty w dwa dni.
Ciekawe jest to, że symulacja powstaje w ramach programu szkoleniowego dla jednego z naszych klientów. Klient potrzebował narzędzi szkoleniowych dla 400 analityków i wdrożeniowców, a my zaproponowaliśmy, aby przeszkolić ich razem, bo przecież razem pracują w dziesiątkach projektów. I tak ruszyliśmy z wymyślaniem Samolotów.
Szacujemy, że prace nad szkoleniem potrwają jeszcze dwa miesiące i będziemy mieć nową grę w ofercie. (aktualizacja: właściwie to już ja mamy)
Zapisz się na nasz newsletter
