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!
+160% ofert pracy na analityka w 2019
Z pozdrowieniami dla tych, którzy pytają czy analitycy biznesowi wyginą 😉 Marta Steiner (Head of Product & Marketing at No Fluff Jobs): Business Analysis, Project Management i Support to trzy dziedziny, które w 2019
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 🙂