Project management: the dark side

Odchudź ją trochę bo długo się ładuje :) Szare litery na czerwonym tle mało widoczne, no i kod kropkowy na stronie? Przecież kurcze już ktoś jest na tej stronie :)

widać że nie ma za duzo na stronie... za mało treści jak dla mnie... zero zachęty do kontaktu

Strona nie jest zła, ale jakoś te logo mi nie pasuje;/ nie wiem dlaczego, ale tak jest ;/

Gratulacje za FWA strona bardzo dobra, tak trzymać... pozdrawiam

strona super/wypas ...... <br /> <br /> jednak zniesmacza mnie fakt, ze \"agencja\" Thetoke pokazuje prace innej agencji jako swoje ....... troszke to nienormalne. Ze strony uzytkownika, wyglada to jakby to thetoke zrobil w calosci te prace .... przeciez i tak wiekszosc osob nie czyta tekstu, ktory znajduje sie o poziom nizej niz prace (na kolejnej podstronie)......<br /> troszke zalatuje ;) endorfine.pl<br /> <br /> sama realizacja - najwyzszy poziom ... wow

Zgadzam się :)

One man army... ;)

No Panie Darku, strona na medal !

@Zbigniew<br /> <br /> Dla pełnej jasności - wszytstkie prace z portfolio Thetoke.com, wykonane dla byss.pl i naszych Klientów, były współtworzone przez Pana Darka w godzinach pracy - przy biurku w naszej siedzibie :).

konkret!

Przecież w opisach jest napisane za co Pan Darek odpowiadał, w niewielu przypadkach jest to design z tego co widzę:)

ładny site, ja tam wierze w Pana Darka, fajne interfejsy, choć liniowa wersja przypomina <a href="http://www.cooliris.com/" target="_blank">cooliris</a> do wyszukiwania obrazów, ale może się czepiam<br /> <br /> wizerunkowo ciekawie to wygląda, że strony agencji interaktywnej powstają na freelansie, ciekawe co robi sama agencja :]]]

Super. I Pan Darek sam to tak te wszystkie sajty zrobił? Bo w większości opisów z tego wynika...

Genialne, znakomity przykład tego, że jednak można ogarniać wiele dziedzin na światowym poziomie!

swietne, gratulacje ....

Miazga ;]

baaardzo dobre!

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.

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ść. <br /> <br /> A jak wiadomo - każdy hak czy obejście, prędzej czy później, kopnie cię w ...<br /> <br /> 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.

@Dominik<br /> 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 ;)<br /> <br /> 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.<br /> 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.<br /> <br /> A \"wieczne aktualizacje\" wynikają właśnie z braku zarządzania zmianą.

<blockquote>zarządzanie projektem to przede wszystkim zarządzanie zmianami. </blockquote><br /> <br /> 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).<br /> <br /> 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ą\" ;)

<blockquote>ale na którymś kursie z PM padła taka kwota</blockquote><br /> 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ń:)

<blockquote>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.<br /> </blockquote><br /> <br /> <br /> i dokładnie się z tym zgadzam. Organizacja pracy swojej i zespołu, weryfikacja zasobów... kalkulowanie \"na chłodno\" i bez żadnych asap\&#039;ów ;)<br /> Zadania, zasoby, terminy, decyzje, testy, wdrożenie...<br /> <br /> z tym \"90%\" dla porażek to bym sobie pozwolił nie zgodzić się

<blockquote>@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ę</blockquote><br /> <br /> Biedny taki człowiek, który oprócz: speca, deadline\&#039;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\" :)<br /> <br /> Wiem, że zamysł wypowiedzi był trochę inny, ale tak mi się nasunęło....z doświadczeń własnych :(

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. <br /> <br /> 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.<br /> <br /> 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.<br /> <br /> 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.

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. <br /> <br /> <br /> <br />Grunt to chociaż próbować uczyć się na błędach i jak już powiedział Karol Tyde - rozmawiać i rozmawiać.

<blockquote>@Dominik: \"Beta forever!\" - zresztą gdzieś ostatnio czytałem o jakimś proteście przeciwko \"wiecznym betom\"</blockquote><br /> <br /> Ciekawe ile \&#039;bet\&#039; robi się dla lansu. Żeby pokazać, że \&#039;rozmawiamy z userami o ostatecznym kształcie projektu\&#039;. A potem i tak przychodzi jakiś menago ii mówi: to mi wyrzucić bo kolor jest zbyt różowy, a tamto usuńcie bo się rozmyśliłem i jednak nie jest fajne:) <br /> I szlag trafia szczytne idee wielu bet i sugestii userów. Nie to, że wiem to z doświadczenia w interactive. Po prostu w PR jest tak samo:)<br /> <br /> <blockquote>@ Dominik: Dlaczego? Aby projekt został zakończony sukcesem muszą zostać spełnione łącznie trzy warunki: projekt musi zostać zakończony w założonym terminie, w ramach założonego budżetu i zgodnie z zakresem.</blockquote><br /> <br /> Dla mnie po prostu projekt jest skończony kiedy realizujemy cele. Tylko że czasem celów nie ma, albo są źle zdefiniowane:)

To co Dominik napisał to w dużej mierze \"oczywista oczywistość\".<br /> <br /> 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.<br /> <br /> 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.<br /> <br /> Przydałaby się dyskusja nt. tego jak unikać właśnie takich wpadek, obsuw etc. Kształcić PM\&#039;ó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ą...<br /> <br /> 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.

\&#039;Podobno\&#039; z projektami jest tak:<br /> - 30% wogole nie jest zrealizowanych - totalna porażka<br /> - 30% jest zrealizowanych z niedotrzymaniem jednego lub kilku zmiennych (koszt, jakość, zakres, czas) - połowicznych sukces<br /> - 30% kończy się sukcesem - dotrzymanie wszystkich czynników<br /> <br /> Specjalnie 30+30+30

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.<br /> <br /> Natomiast zaplanowanie prac jest osobną historią i faktycznie często fakt, ze jest to najważniejsza i najbardziej pracochłonna część pracy, umyka osobom, które powinny być najbardziej zainteresowane sukcesem projektu. W efekcie tego rozpoczyna się projekty ? na hurra? (bo klientom zwykle się śpieszy), a potem jest łatanie tego, czego wcześniej nie było czasu doprecyzować. Przez to na koniec, kiedy powinniśmy już tylko wszystko elegancko testować i wprowadzać drobne szlify, zaczyna się gorączka odkrywania niedomówień, niedoróbek, praca po godzinach i nerwy. W efekcie projekt wcale nie kończy się szybciej niż gdyby ten sam czas poświęcić na początku na precyzyjne określenie paru ważnych aspektów ? choćby zakresu ;)

Zbyt powierzchownie potraktowałeś temat. Project manager to nie wszystko.<br /> <br /> W wielu przypadkach, największy problem stanowią ludzie, którzy wiedzą mniej a mogą więcej (powiało korporacyjnym klimatem). Im mniejszy team tym większa szansa na utrzymanie założeń jakościowych.

@ Dominik: mam podobne doświadczenia z wielu projektów :) dlatego kiedy tylko to możliwe staram się działać w trybie \"Getting Real\" chłopaków z 37Signals:<br /> http://gettingreal.37signals.com/toc.php<br /> <br /> Oczywiście czasami projekt wymaga bardzo rozbudowanej dokumentacji projektu, i czasami mam wrażenie, że sama w sobie jest celem ;). W takich przypadkach podejście \"getting real\" nie ma sensu. <br /> <br /> Metoda Rafała Agnieszczaka \"Weź to kurwa zrób!\" również wydaje się interesująca ;).

Mam doświadczenia z obu stron barykady - jako PM i jako handlowiec. W mojej opinii im bardziej projekt rozwija firmę dostawcy, tym większe ryzyko, że będzie dla niej nierentowny. Wynika to z faktu, że często nie sposób dobrze oszacować ryzyka w takim projekcie, a sfinansować wszystkich ryzyk z pieniędzy klienta się nie da (w końcu mamy konkurencję). Często zresztą świadomie podejmujemy projekty, dla których z góry dopuszczamy, że będą nierentowne - wtedy trudno mówić, że projekt który nie zmieścił się w budżecie od klienta, jest nieudany. <br /> <br /> <br /> <br />W mojej opinii, poza tzw. \"triple constraints\", czyli budżet-zakres-harmonogram, jest jeden warunek \'sine qua non\' powodzenia projektu - zadowolony klient. Znam projekty, które przekroczyły budżet, skończyły się 100% opóźnieniem i nie zrealizowały całego zakresu, a mimo to klient był bardzo zadowolony! Czyż to nie jest udany projekt?

Ok, dzięki za odpowiedź :-) Ps. dobrze, że liczby mylą Ci się z kwotami :-) Wielu liczb życzę na plusie.<br /> <br /> A co do \"beta google\", a sprawdzał ktoś czy produkty które na siebie zarobiły mają już zdjęte beta? Może co nie zarobi jest betą?

@Przemek: nie pamiętam dokładnie, ale na którymś kursie z PM padła taka kwota, zresztą z mojego doświadczenia wynikają podobne procenty - zawsze \"coś wychodzi\" - czyli dodajemy lub usuwamy coś z zakresu projektu (\"bo klient zapomniał\" albo nie ma czasu i się \"tnie\" po funkcjonalnościach lub przekłada \"na później\") a szacowane wcześniej do harmonogramu zasobu, są jakby o połowę za małe (bo zwykle harmonogram dopasowuje się do terminu a nie odwrotnie).<br /> <br /> @Dominik: \"Beta forever!\" - zresztą gdzieś ostatnio czytałem o jakimś proteście przeciwko \"wiecznym betom\"

Dominik, skąd te \"podobno 90%\"?

<blockquote>No chyba, że wyjściem z tej sytuacji jest nie kończenie projektów i trzymanie wszystkiego w tak zwanej \"becie\"?</blockquote><br /> A co powiesz na kończenie projektów i trzymanie w tak zwanej \"becie\" nawet kilka lat? -> Google :)