3 camp i po 3 campie:) Było naprawdę sympatycznie. Dla tych, którzy chcieliby przypomnieć sobie tamte chwile i sjady, wrzucam prezentację 🙂 Do zobaczenia przy następnej okazji!
Chciałbyś zarabiać więcej? Pewnie już czeka wymarzony samochód, mieszkanie albo to, co coś, co zawsze chciałeś zrobić, ale brakowało Ci pieniędzy. Jak jednak przekonać szefa? Jak znaleźć odpowiednią firmę? Jak awansować?
W ramach działalności koła naukowego Zarządzanie IT na Politechnice Gdańskiej będziemy wspólnie uczyć się i przygotowywać do wybranego certyfikatu z zakresu analizy i zarządzania projektami. Zobacz zestawienie certyfikatów, zagłosuj i przyłącz się do nas!
Ze stanami, statusami mamy do czynienia w zamówieniach, wizytach, ubezpieczeniach, obiegu dokumentów, czyli w praktycznie każdym systemie. Bywa, że tworzymy listę stanów, ale już nie zawsze pamiętamy jednoznacznie określić wszystkie możliwości przejść między
0 komentarzy do “Prezentacja z tech.3campa”
Jedna z lepszych prezentacji na tym 3campie. Ja jako ciekawostkę podałbym, że klienci często na pierwszym spotkaniu mówią, że chcą mieć system robiący „to i to” i jaka będzie cena 🙂 I jak tu powiedzieć klientowi, że cenę pozna po akceptacji zakresu projektu ?;-)
Dziękuję:) Miło słyszeć.
O, tak:) Czasami też spotyka się maile z treścią długości zdania, dwóch i ile to będzie kosztowało?
I stały branżowy żart, kiedy osoba spoza branży pyta: „Ile kosztuje zrobienie strony?” Od 100 zl do milionów??
Nie mam akurat okazji uczestniczyć w ofertowaniu i dogadywaniu szczegółów wycen. Gdybym jednak miała to wytłumaczyć spróbowałabym od wyjaśnienia, że najpierw trzeba wiedzieć, co jest do zrobienia, potem to można wyceniać. Dla niektórych to wystarczająco racjonalne i zrozumieją.
Innym może przez analogię do budownictwa? Ile kosztuje wybudowanie budynku? No może to być przecież garaż na 1 samochód, a może być wielki, ekskluzywny kompleks.
Wyjątkowo nieustępliwym można (o ile się da) przygotować samodzielnie propozycję zakresu i ją wycenić, a później, po dokładniejszej analizie zastrzec sobie prawo do zmiany i mieć nadzieję, że gładko przejdzie ten etap 🙂
Wydaje mi się, że na początku projektu, po kilku spotkaniach z klientem, dochodzi się do przedziału wartości projektu, w jakim będziemy się poruszać. Na tym etapie klient może albo od razu zrezygnować z dalszych prac albo zgodzić się na widełki i kontynuować projekt. Może się okazać, że po wstępnej analizie projekt przekroczy kilkukrotnie zakładany budżet i klient się po prostu przestraszy. Wtedy, tak jak wspomniał Tomasz, klient zapłaci za analizę z której wynika, że jak go nie stać, to najlepiej jakby korzystał z Excela 😉
Ciekawi mnie jeszcze jedno. Wiadomo, że umowy podpisuje się na złe a nie na dobre czasy. Czy uchylicie rąbka tajemnicy i zdradzicie, ile % prowadzonych przez Was projektów „wymaga” w końcu interwencji prawników z uwagi na fakt, że klient zakceptował projekt, system został wykonany zgodnie z projektem i klient albo nie chce odebrać systemu tłumacząc, że nie tak sobie go wyobrazał lub na koniec projektu każe zmienić system, aby dzialał w nieco inny sposób i nie chce ponosić dodatkowych kosztów z tego tytułu?
U nas na razie 0 😉 Dobre dokumentowanie pracy nie powinno budzić niejednoznaczoności wymagającej interwencji prawników. Z drugiej strony może jeszcze za mało projektów widziałem 😉
W sieci dostępny jest obrazek, który ma już swoje lata, ale cały czas dobrze opisuje to, o czym piszesz: http://www.blog.gdaq.pl/2009/02/jak-z-powodzeniem-realizowac-projekty-informatyczne/
Mam nadzieję, że firm z właściwym podejściem jest jednak więcej 😉
Umowy można jeszcze aneksować 🙂 ale się tym nie zajmuję i szczegółów nie znam.
Na pewno makiety/prototypy (czasem grafiki) czy jakieś rysunki ekranów i przepływów między nimi zmniejszają zagrożenie usłyszenia „nie tak sobie wyobrażałem…”. Jeśli klient w jakiś sposób zobaczy jak to wygląda, to się tak często nie zdarza, żeby mu bardzo nie pasowało. Co innego działanie systemu, ale to już nie jest to, co klient widzi i sobie „inaczej wyobraża”. To już są bardziej „namacalne” rzeczy, które łatwo udowodnić, jeśli zostały zapisane w specyfikacji:)
My mamy na to kilka sposobów. To najpopularniejsze
1) zadajemy kilka pytań np. właśnie o cele systemu, które pokazują że „to i to” nie ma sensu
2) przedstawiamy w jaki „inny” sposób można pracować nad projektem i na podstawie rzeczywistych case’ów pokazujemy jak to wyszło. Czyli np. że zamiast drogiego dedykowanego oprogramowania, wystarczy… wdrożyć Google Aps (pytanie ile firm IT jest gotowe na takie rekomendacje ;)).
3) przy upartym kliencie przedstawiamy co dokładnie zrobimy. Czyli system będzie wyglądać tak i tak (nie wiemy czy Wam to będzie odpowiadać), będzie kosztował tyle i tyle. ALE… na początku projektu i tak zrobimy analizę biznesową i potem przystąpimy do negocjacji (no chyba że zostaniemy przy pierwotnej wersji)
4) z klientami „końmi” po prostu nie podejmujemy współpracy ;). A poważnie – z niektóry po prostu nie da się porozumieć i nie ma sensu podejmować współpracy.
Wbrew pozorom większość klientów ma rzeczywisty problem i rzeczywiście szuka pomocy. Potrzebne jest dobre zrozumienie w jakiej sytuacji się znajdują i czego naprawdę potrzebują. Może się okazać, że osoba która przychodzi z projektem ma związane ręce i musi uzyskać taką pobieżną wycenę, bo wymagają tego od niej ludzie „z góry”. Wie, że powinno się projekty robić inaczej, ale nie może. I na takie sytuacje są sposoby 😉 Trzeba tylko dowiedzieć się o tym problemie. Jeśli się jednak na siebie nawzajem poobrażamy, to nic z tego nie wyjdzie.
Trzeba też pamiętać, że klient czasem rzeczywiście wie co mu jest potrzebne i potrafi dostarczyć na początku projektu dokładne wymagania. Tak, są tacy klienci 🙂