To co Dominik napisał to w dużej mierze "oczywista oczywistość".

Chyba jeszcze w niewielu firmach z naszej branży są wdrożone z głową jakieś metody prowadzenia projektów. Trzeba też pamiętać, że projekty internetowe charakteryzują się dużą częstotliwością zmian. Tworzenie książkowych specyfikacji w wielu przypadkach mija się z celem, a jeśli takowe powstają to zanim projekt dojdzie do końca, to specyfikacja zmieni się trzy razy.

Nie mówiąc już o samym "etapie testowania", który bywa traktowany jako etap na dokończenie prac, zamiast na rzeczywiste gruntowne przetestowanie aplikacji. Efekt jest taki, że poprawki przeciągają się w nieskończoność, bo tu się coś opada, tutaj nierówno, a tutaj błąd zwraca a tamto to w ogóle inaczej miało działać. Zanim projekt się kończy okazuje się, że zajął dwa razy tyle czasu a po podliczeniu, był zupełnie nieopłacalny.

Przydałaby się dyskusja nt. tego jak unikać właśnie takich wpadek, obsuw etc. Kształcić PM'ów czy może sprzedawców? Klientów czy kadry zarządzające? A może wszystkich razem, by nauczyli się komunikować między sobą...

Zamiast naciskać by projekt jak najszybciej startował i byle szybciej skończył (efekt opisany powyżej), "sponsorzy projektów" powinni się pochylić i zastanowić jak ważne jest dobre omówienie projektu wewnątrz zespołu projektowego, a następnie znów omówienia go z klientem.

Mam wrażenie, że sam artykulik jest o rzeczach oczywistych. Złe/brak założeń, liczenie czasu programistów tylko w "idealnych" godzinach, bezkompromisowe podejście tam, gdzie ostateczny kształt jest kluczowy względem oczekiwań od modelu biznesowego to niestety ciągłe błędy wielu projektów.



Grunt to chociaż próbować uczyć się na błędach i jak już powiedział Karol Tyde - rozmawiać i rozmawiać.

Zgadzam się, że większość projektów kończy się porażką. Opowieści o względności ostatecznego wyniku, zadowoleniu klienta oraz kontroli zmian możemy włożyć między kartki.

Do tego dochodzi jeszcze kwestia, iż projekt projektowi nie równy. Jedni przygotowują landing page i to w jakiś sposób definiuje zakres projektu, inni projektują silnik systemu commerce i ponownie mowa o realizacji projektu. Oba przypadki łączy kryterium "złotej trójcy" tylko skala działania się różni, w wymiarze każdego z obszarów.

Dlatego ostateczne powodzenie zależy w jakim modelu prowadzimy sprzedaż naszych rozwiązań. Model sprzedaż > realizacja [account > project manager] w większości przypadków nie działa poprawnie (podobno jest taki projekt tylko nikt go nie widział). Te dwa etapy i ich koordynatorzy mają rozbieżne interesy: zadowolenie klienta vs efektywność wykonania.

Skutecznie działa model sprzedaży w postaci doradztwa, gdzie osoba odpowiedzialna za projekt konsultantem się zowie, wie jak: prowadzić relację z klientem, posiada wiedzę merytoryczną, rozumie implikacje swoich decyzji i deklaracji, a ostatecznie potrafi ogarnąć zakres projektu i poprowadzić jego realizację. Takich osób jednak jest zbyt mało jak na apetyt rozwoju sektora Internet.

@Zbigniew ...konsultantem się zowie, wie jak: prowadzić relację z klientem, posiada wiedzę merytoryczną, rozumie implikacje swoich decyzji i deklaracji, a ostatecznie potrafi ogarnąć zakres projektu i poprowadzić jego realizację

Biedny taki człowiek, który oprócz: speca, deadline'u, grafików, programistów, szefa "zgreda"....ogólnie całego Projektu - ma na głowie tłumaczenie Klientowi czym się różni pixel od centymetra, szerokość od wysokości, albo dlaczego "czerwony tekst nia niebieskim tle nie przejdzie" :)

Wiem, że zamysł wypowiedzi był trochę inny, ale tak mi się nasunęło....z doświadczeń własnych :(

Pozwolę sobie doprecyzować: ?porażka? nie jest chyba odpowiednim określeniem. Bo zarządzanie projektem to przede wszystkim zarządzanie zmianami. Jeżeli na bieżąco te zmiany uwzględniamy w budżecie i harmonogramie, nie możemy mówić o porażce czy też opóźnieniu. Na tym głównie polega praca PM-a podczas realizacji projektu.

i dokładnie się z tym zgadzam. Organizacja pracy swojej i zespołu, weryfikacja zasobów... kalkulowanie "na chłodno" i bez żadnych asap'ów ;)
Zadania, zasoby, terminy, decyzje, testy, wdrożenie...

z tym "90%" dla porażek to bym sobie pozwolił nie zgodzić się

ale na którymś kursie z PM padła taka kwota

co do tych 90% to raczej chodzi o wszystkie projekty IT, a w tym worku mamy zarówno stronki, jak równiez duże system informatyczne (np. ten z ktorego np ZUS korzysta bardziej lub mniej bardziej:)) Ja spotkałem sie też z inną zasadą, że im wiekszy budżet to tym wieksze prawdopodobieństwo porażki, a duży budżet z reguły = złożony projekt, a to = brak dokładnej specyfikacji. aha no i w takich projektach ze zmianami trzeba sobie radzić, ktore pojawiają sie pewnie tak raz na tydzień:)

zarządzanie projektem to przede wszystkim zarządzanie zmianami.

To zależny oczywiście od podejścia i stosowanej metodologii, a tych jak wiadomo jest wiele i wciąż ewoluują. Przyjmując, że większość projektów w branży interactive to krótki, co najwyżej kilkumiesięczne projekty, oczywiście można sobie pozwolić na "zarządzanie zmianą" i stosowanie takich metodologii jak choćby Scrum (co czasami ma duży sens).

Jednak zawsze na koniec dnia trzeba pamiętać, że praca zorientowana projektowo ma dostarczyć jakiś PRODUKT, a nie przerodzić się w np. aktualizację jeszcze nie istniejącej strony. Bo tym mi jakoś pachnie określenie "zarządzanie zmianą" ;)

@Dominik
Uwierz, że też chciałabym prowadzić tylko projety, w których wszystko jest z góry ustalone i niezmienne. Miałabym wtedy zdecydowanie mniej pracy ;)

A to, że w projektach zmiany są zawsze, jest naturalne. W końcu każdy projekt jest unikalny. Zawsze zdarzać się będzie, ze klient zmieni zdanie albo zorientuje się, ze jakaś dodatkowa funkcjonalność jest konieczna, lub po prostu zmieni się kontekst w jakim projekt powstaje.
Cała sztuka polega na tym aby móc wykazać, ze coś jest zmianą w stosunku do ustalonego wcześniej kształtu produktu końcowego i móc dzięki temu zweryfikować koszt oraz harmonogram.

A "wieczne aktualizacje" wynikają właśnie z braku zarządzania zmianą.

Zarządzanie zmianą to podstawa, ale przede wszystkim - dla wewnętrznej organizacji firmy. Utrzymanie niskiego kosztu zmiany, to jeden z najbardziej niedocenianych elementów powstawania projektów. A potem się okazuje, że najmniejsza zmiana w aplikacji to miesiące przebudowy albo hak na haku i coraz niższa jakość.

A jak wiadomo - każdy hak czy obejście, prędzej czy później, kopnie cię w ...

Iteracyjność mogłaby pomóc, ale zwykle Agile/SCRUM służy jako ładna wymówka na burdel panujący w organizacji. Do Agile trzeba odpowiednich ludzi i odpowiedniego procesu. W sytuacji przeciętnej agencji - rzadko się sprawdza.

Ciesze się że ciekawy temat poruszacie. Równiez i ja próbuję wypracować ten idealny model procesu twórczego, który owocuje ideałem w pierwszym podejściu :) Za każdym razem jednak natykam się na coś nowego, czego nie przewidziałem, a jak ktos tu juz zauwazył drogo to kosztuje. Czasami mi się wydaje, że zatrudnienie kolejnych ludzi do konkretnych rzeczy dałoby wyśmienity rezultat, jednak cena tych ludzi, dokładnie tych co wiedzą i rozumieją więcej niż potrzeba (na te szczególne okazje co się ciągle zdarzają) jest często niestety za duża.