No właśnie. Czy spotkaliście się już z taką sytuacją? Klient zmienia zamówienie co tydzień, nie może się zdecydować o co tak naprawdę mu chodzi. Jedyną informację jaką można od niego uzystkać to: "żeby było fajne". Jak sobie z tym radzić? </url>
0
0
odmówić mu współpracy. BO nawet jeśli dokończysz projekt to jesst duże prawdopodobieństow ze mu sie on nie spodoba i będzie żądał zmian, lub po prostu nie zapłaci za wykonaną prace, a co z tego wynika będziesz stratny. Nawet jak zapłaci to wielokrotna zmiana projektu pochłania dużo wiecej czasu niż wykonanie projektu zgodnie z pierwotnymi założeniami, więc tak czy inaczej jesteś stratny. No chyba że skasujesz klienta za ten dodatkowy czas.
0
W większości przypadków z klientem takim radzę podpisać umowę o dzieło, w której uwzględnimy np. stawkę roboczogodziny, ja osobiście prosze ich o złożenie zamówienia, ponieważ akurat mam firmę. Rozliczam się właśnie na roboczogodziny dlatego klient w na pierwszej rozmowie może poznać tylko widełki w jakich będzie cena. Najczęściej tak robie gdy nie wiem dokładnie jaki czas mi zejdzie nad projektem. Ostatni taki miałem to musiałem praktycznie pisać "zmutowany" katalog stron. Sam katalog napisać to chwilka, ale te mutacje były dosyć toporne :/ Po wykonaniu jakiś 25% klient dostaje fakturę z 14 dniowym terminem płatności(bo tyle trwa średni czas kończenia sporego projektu). Jeżeli nie płaci to oddaje sprawę do firmy windykacyjnej i mam po problemie, mniej mi trochę zapłacą, ale jestem i tak na plusie, a dalej się męczy z nim firma windykacyjna.
<ort>pÓÓÓÓki </ort>co jednego klienta tylko oddałem do windykacji. Niektórzy płacą po terminie, ale ja też nie lece tak od razu tylko czekam około 4 tygodni na pieniądze.
0
Wydaje mi sie że te sposoby nie rozwiązują problemu, nie można olać klienta kiedy jest podpisany kontrakt na soft np. z firmą Philips. Chodziło mi o sposoby wydobycia z klienta informacji na temat tego czego on chce.
0
Ja 'zazwyczaj' strasze klienta tym, ze wlasnie zerwe wspolprace, jezeli jest wyjatkowo niekonkretny. Fakt - zdarzylo mi sie to raz, oby nigdy wiecej (naiwny :P). Wydaje mi sie, ze mozna postraszyc klienta tym, ze beda wyzsze koszty, znacznie dluzszy czas realizacji, ze aplikacja bo tylu glebokich zmianach nie jest tak efektywna jak napisana od razu w jednym kierunku... Niestety nie zadziala jak sie klientowi nie spieszy i jak koszty w miare go nie przerazaja...
pozdrawiam
johny
0
Prosty sposob to stworzyc ankiete - czyli opcje ktore wg. Ciebie moglby sie znalezc etc. i na koncu pole uwagi w ktore on wpisuje to czego zabraklo w pytaniach.
Robisz projekt (na kartce) + prosty interfejs, pokazujesz mu.
Wrzucasz to do umowy i informujesz go (w umowie tez to wpisujesz), ze kazda zmiana bedzie odplatna. Jezeli nie zaplaci to jest to przestępstwo - kradzież.
Mozesz tez poprosic o zaplate z gory jakiejsc czesci. Jak sie nie zgodzi to ja bym zrezygnowal.
Sam mialem taka sytuacje (moj pierwszy projekt). Widzialem, ze kolo to olewa, napisalem mu prosty program i oddalem, poprosil o zmiany (niepotrzebnie sam prezentowalem program). Po wprowadzeniu zmian oddalem i mial tydzien na weryfikacje - nawet tego NIE wlaczyl przez ten czas :-) Potem juz go olalem.
0
W inzynierii oprogramowania jest takie pojęcie jak burza mózgów. Czyli siedzicie i nakreślacie plan co, jak, gdzie ma działać. Ty podajesz swoje rozwiązania on Ci musi powiedzieć co on chce. Później nakreślasz dokumentacje <ort>wg.</ort> wspólnych wytycznych i dajesz do zaparafowania przez klienta. Przez to klient więcej nie może jęczyć, że jednak chce co innego lub cos dalej dodać. Ok, możesz się zgodzić, ale obiążasz dalszymi kosztami klienta.
Lecz jeżeli jest to kolo upierdliwy i ciężko z nim wysnuć jakieś wnioski na wstępie to lepiej dać sobie spokój niż tracić czas i kase.
0
burza mózgów? przecież klient musi wiedzieć czego chce, przeciez to jego projekt- chyba, że jest w stanie zapłacić za wymyslanie za niego. Nie usmiecha mi sie zgadywanie co bedzie mu pasowalo!
Ty podajesz swoje rozwiązania on Ci musi powiedzieć co on chce.
IMHO odwrotnie, on podaje co masz zrobić, a ty mówisz jak możesz to zrobić
PS. po wg NIE ma kropki !
0
AklimX napisał(a)
burza mózgów? przecież klient musi wiedzieć czego chce, przeciez to jego projekt- chyba, że jest w stanie zapłacić za wymyslanie za niego.
Nie zrozumiałeś mnie. Chodzi o rozmowe z gościem. On Ci mówi co chce, Ty mu mówisz swoją wizje tego rozwiązania. On sie zgadza to nastepny etap.
PS. po wg NIE ma kropki !
Nie przejmuj sie tym tak mocno ;)
0
wcale nie musi :-P Mowi np. "Chce ladny program do liczenia powierzchni wielokatow".
I jak sie go pytasz o reprezentacje wierzcholkow to robi wielkie oczy, jak mu przedstawiasz kilka sposobow to nie moze sie zdecydowac, jednoczesnie nie chce zaplacic za zaprogramowanie kilku. Mowi tylko: "zrob tak, zeby bylo wygodnie". Asekurujac sie w ten sposob powoduje, ze moze Ci nie zaplacic za projekt gdy cokolwiek bedzie zle.
edit: jeszcze gorzej gdy powie chce sposob1, a gdy to zakodujez mowi, ze mial byc sposob2 bo on tak chce, dlatego trzeba miec jakas kartke z projektem i jego podpisem
0
"Musisz zmusić" klienta do współpracy. Jeżeli mimo wszystko klient jest tak upierdliwy jak mówisz to dałbym z nim sobie spokój. Chociaż na początku człowiek chwyta się każdego aby mieć jakiś grosz. To z tym może być ciężko, żeby lekką ręką odtrącać trutni.
0
Określcie podstawowe wymagania (takie które są pewne na 100%) -> wykonaj je -> i wg XP wrzucasz klienta do teamu realizującego -> małymi kroczkami robicie resztę -> jeśli stanie się członkiem zespołu i będzie musiał poświęcić swój czas to nie będzie chciał go marnotrawić :)
a jeśli nie chcesz XP tylko tradycyjne tworzenie, to spisz umowę, do której załącznikiem będzie specyfikacja :-) i po kłopocie :)
0
Miałem podobny problem z szefem w firmie. Miałem, znaczy się cały czas mam. Piszę program do monitoringu produkcji. Problem polega na tym, że mamy bardzo skomplikowany system, a co za tym idzie interface użytkownika. Tu miałem ten plus, że chociaż szef naszkicował jakie wyniki program ma dawać. Zrobiłem wersję testową, dosłownie sam interfejs. Wykresy itp. generowane były losowo. Dałem do testowania. po tygodniu zgłosił kilka uwag, poprawiłem i było ok. Co do samego działania programu to nie wnikał co i jak ma robić. Jego interesowały poprawne wyniki na końcu działania programu. Jeżeli chodzi o wyniki to zdaj się trochę na instynkt. Programista troszkę lepiej określi co jest potrzebne na wyjściu niż niezdecydowany użytkownik. Ważne jednak abyś trzymał go krótko. Pamiętaj im mniej swobody mu dasz tym lepiej dla wszystkich.
Dobrą opcją jest pokazać mu fragment tworzenia programu. Łatwiej mu będzie zrozumieć co możesz, czego nie możesz, jakie ma możliwości "wydziwiania" itp. Łatwiej będzie mu wówczas myśleć.
0
Przede wszystkim nie kazdy klient zna sie na komputerach, w szczegolnosci na zaawansowanych technologiach. Nie musi. Nie musi rowniez znac terminologii. Padlo w tym watku juz fajne zdanie - instynkt. Planujesz etapty projektu tak jak Ty to widzisz. Jezeli projekt jest wiekszy, nalezy rozpisac specyfikacje oraz wszelkie szczegoly. Jezeli klient zaakceptuje Twoja wizje, podpisujesz umowe, zmiany oraz rozszerzenia po podpisaniu, powinny byc dodatkowo platne.
mephir: stawka godzinna? Ale jak sie z tego rozliczasz? :) Tj. skad klient wie ile faktycznie godzin przepracowales nad projektem? Hmm... czy moze to jest tak: 10 dni, w tym 8 h. / 1 dzien = 80 h. ? W ten sposob?
0
Jeśli facet nie wie czego chce i gada, że może być dowolnie ale dobrze,
to prawdopod. jest tylko pośrednikiem i nie potrzebuje programu dla siebie,
lecz chce tym handlować... zrób to i sam handluj, po co pośrednik?
P.S. :-D
Proponuję przenieść ten temat do działu humoru. :-)
0
kolteciazr napisał(a)
P.S. :-D
Proponuję przenieść ten temat do działu humoru. :-)
Dlaczego do działu chumoru? Niezdecydowany koleś to nie jest śmieszne tylko frustrujące. Siedzisz, piszesz, testujesz a on ciągle coś zmienia. Nie wiem czy Ty lubisz takie sytuacje. Przeróbka kodu bywa czsami skrajnie uciązliwa.
0
Witam
Większość z was ma starsznie dziwne podejście co do współpracy z klientem.Zupełnie tak jakby klient w zleceniu to było zło konieczne. Zazwyczaj to ejst tak że programisci ,nie sa w ogole dopuszczani do rozmowy z klientem.
Z klientem kontaktują się analitycy(przynajmniej ja się z takim modelem wielokrotnie spotkałem), którzy sa odpowiednio wyszkolonym personelem ,iż sa w stanie wydobyć od klienta jego dokłądne wymagania co do systemu.(m. inn. nie wyzwią go od debila jeśli np. kierownik kwiaciarni ,ktora zamiawia system informatyczny zrobi wielkie oczy na pytanie czy system ma korzystac z wzorca fabryki a dana klasa ma być klasa abstrakcyjną). W spotkaniach z klientem (wczesniej wspomniana burza mózgów) oczywiscie czesto biora udział także inne osoby jak np kierownik projektu ,aczkolwiek ich rola w tym spotkaniu jest trochę inna. Gdy już wymagania klienta są znane, na ich podsatwie architekci opracowuja architekturę systemu oraz specyfikacje,którą moze być pzrekzana klientowi do akceptacji. I do piero teraz na podsatwie specyfikacji programisci tworzą system. (Generalnie rola progarmistów ejst tutaj wbrez pozorom najmniej istotna ,gdyż błedy na etapie ich pracy najłatwiej poprawić).
Systemy jest gotowy w danym terminie i przekazywany do testów u klienta.
Oczywiście cały proces przedstawiłem w bardzo wielkim uproszczeniu. Oczywiście ejst wiele metodyk prowadzenia projektu informatycznego, ten to tylko jedna propozycja.
W małego zlecenia ,które np. w domu robi jedna osoby oczyiście proces wygląda troche inaczej. Bo musi być ona jednoczesniej analitykiem , architektem i programistą. Tutaj bym sugerował taki model: zleceniodawac mowi ,że chce np. ładny program do liczenia pól wielokątów. Dokladnie okreslamy ograniczenia systemu: ile min-max wierzchołków może mieć wielokąt (na to klient łatwo moze sie zdecydować, nie musi znac metod obliczania ), określamy jaki ma być interfejs aplikacji i oczywiście zadowalające obydwie strony. Pobieramy zaliczkę i tworzymy pierwszy nie w pełni funkcjonalny prototyp aplikacji. Przesyłąmy go klientowi do tetsów i wtedy już na jako tako żywym organizmie jest mu łatwoej sprecyzowac sowje wymagania. Jesli to konieczne renegocjujemy warunki finansowe i powtarzamy cąły proces.
Oczywiście to tylko moja propozycja.
pzdr
0
(Generalnie rola progarmistów ejst tutaj wbrez pozorom najmniej istotna ,gdyż błedy na etapie ich pracy najłatwiej poprawić).
Z tym się niestety nie zgodzę, gdy programista dostaje specyfikację, to zwykle wykonuje ją dokładnie, bo jest to proces "czysto mechaniczny" i trudno się tu pomylić. Ewentualne błędy powstają wtedy na etapie analityków i architektów. W tym przypadku usunięcie błędów to już nie jest tak bezbolesny problem, jak myślisz. Zwykle wiąże sięto ze zmianą specyfikacji, czasem również architektury. Czasem zaczyna się wszystko prawie od nowa :-[ .
Tego typu problemy żadziej występują gdy koderzy nie są odcinani od klienta, właściwie to nigdy nie powinni być od nich odcinani. Często zdarza się, że analitycy nie wypytają klienta o wszystko, w końcu nie wiedzą z czym zetknęli siędo tej pory koderzy, albo po prostu nie zwrócą uwagi na mało istotny dla nich szczególik, dzięki któremu koderzy zrobią coś w inny sposób niż powinni.
Morał z tego jest taki, że sami koderzy powinni mieć wgląd w cały proces tworzenia, bo tylko wtedy nie trafi się sytuacja, że mają zrobić coś o czym nie mają pojęcia, lub rzeczy powiedzmy "niemożliwych".
"Nie ma rzeczy niemożliwych, jeśli nie musisz sam tego robić"
0
Z tym się niestety nie zgodzę, gdy programista dostaje specyfikację, to zwykle wykonuje ją dokładnie, bo jest to proces "czysto mechaniczny" i trudno się tu pomylić. Ewentualne błędy powstają wtedy na etapie analityków i architektów. W tym przypadku usunięcie błędów to już nie jest tak bezbolesny problem, jak myślisz. Zwykle wiąże sięto ze zmianą specyfikacji, czasem również architektury.
O tym właśnie pisałem.Praca ,którą wykonują analitycy i architekci ma o wiele wieksze znaczenie dla powodzenia projektu aniżeli sama implementacja rozwiązania(dlatego tez programisci z tego co wiem zarabiają odpowiednio mniej).
Co do uczestnictwa programistów w kontaktach z klientem, to oczywiście powinni brac w nim udział kierownik projektu oraz główny architekt(czy ktoś taki) ale nie ma potzreby aby zwykli programisci równiez kontaktowali sie bezpiosrednio z klientem. Oczywiście programisci mogą kontaktrować się z odpowiednikiem analityka z firmy zleceniodawcy ale raczej z nikim innym.
Morał z tego jest taki, że sami koderzy powinni mieć wgląd w cały proces tworzenia, bo tylko wtedy nie trafi się sytuacja, że mają zrobić coś o czym nie mają pojęcia, lub rzeczy powiedzmy "niemożliwych".
Pierwsza rzecz, to ejst to kalsyczny bład- to nie implementacja wymusza potzreby klienta ale potzreby klienta implementacje. Po drugie rzeczy absolutnie niemożliwe do zrobienia (np. klient chce znac wynik transakcji pzred jej zrealizowaniem) są wychwytywane przez analityków i (bardziej) przez architektów na etapie prohjektowania systemu.
PS.
Często zdarza się, że analitycy nie wypytają klienta o wszystko, w końcu nie wiedzą z czym zetknęli siędo tej pory koderzy
Co ma jedno do drugiego?
0
Często zdarza się, że analitycy nie wypytają klienta o wszystko, w końcu nie wiedzą z czym zetknęli siędo tej pory koderzy
Co ma jedno do drugiego?
Bardzo dużo. U nas w fimie często tak jest że pewne własności aplikacji stają się jasne dopiero na etapie implementacji. po prostu pewnych rzeczy nie da się / nie wolno zrobić. Może to zabrzmi dziwnie ale piszemy oprogramowanie dla prototypowych urządzeń które są projektowane od podstaw u nas firmie. Mamy połączenie mechanika-elektronika-komputer i bardzo często zdarza się że konstruktorzy lub elektronicy czegoś nie przewidzieli i dopiero koder wyłapuje niedoróbki które powodują że np. sterownik elektroniczny trzeba troszkę zmienić. Analityk daje tylko ogólne założenia projektu, dopiero koder jest w stanie powiedzieć co jest wykonalne z danych sprzętem a co nie. No ale może to wynikać ze specyfikacji naszej firmy.
0
Widzisz, wydaje mi się ,że w przypadku twojej firmy sytuacja wygląda trochę inaczej gdyż jak rozumiem zajmujecie się twozreniem fizycznych ukąłdów elektronicznych.
Jak możes zopisz dokaldnie jak ów proces dokładnie przebiega w twojej firmie
0
maniek_2 napisał(a)
W inzynierii oprogramowania jest takie pojęcie jak burza mózgów.
G...o prawda, pojecie wywodzi sie z psychologii spolecznej a nie z inzynierii oprogramowania :)
0
Malcolm napisał(a)
G...o prawda, pojecie wywodzi sie z psychologii spolecznej a nie z inzynierii oprogramowania :)
...co oczywiście wcale nie oznacza, że nie ma go w inżynierii oprogramowania, ale to chyba nie bardzo na temat...
Malcolm napisał(a)
No przeciez nie zaprzeczylem :)
Wiem :)
0
Malcolm napisał(a)
maniek_2 napisał(a)
W inzynierii oprogramowania jest takie pojęcie jak burza mózgów.
G...o prawda, pojecie wywodzi sie z psychologii spolecznej a nie z inzynierii oprogramowania :)
Ech człowieku, nie gadał bym tego z własnych przemyśleń. Miałem inżynierie oprogramowania i wiem co słyszałem na wykładzie więc proszę, sam nie gadaj głupot.
0
Poza tym w narzędziach typu CASE, wykorzystywanych w inzynierii oprogramowania jak np. Visio są odpowiednie moduły, gdzie mozna modelaować przebieg "burzy mózgów". Więc milcz jak jesteś nie pewny.
0
brodny napisał(a)
Malcolm napisał(a)
G...o prawda, pojecie wywodzi sie z psychologii spolecznej a nie z inzynierii oprogramowania :)
...co oczywiście wcale nie oznacza, że nie ma go w inżynierii oprogramowania, ale to chyba nie bardzo na temat...
No przeciez nie zaprzeczylem :) Podalem tylko zrodlo pochodzenia, bo takie plątanie pojec o ktorych kolega przypadkiem jednym uchem slyszal na jakims wykladzie nie przystoi w powaznej rozmowie ;)
maniek_2: polecam jeszcze wyklady z ekonomii, socjologii i psychologii spolecznej - troszke rozszerza horyzonty ;)
W sumie troche to na temat jest, opcja wykorzystania metody "burza mozgow" bylaby przydatna pod warunkiem, ze byloby wiecej osob niz 2. Choc w wypadku konfrontacji klient-wykonawca lepiej wypada zebranie czy tez wyciagniecie od klienta podstawowych zalozen i wykonanie prezentacji pol-gotowego produktu, ktory by je symulowal. Nastepnie rozmowa i dopracowanie zalozen.
Ale o tym juz byla mowa :)
0
Pawel-w napisał(a)
Widzisz, wydaje mi się ,że w przypadku twojej firmy sytuacja wygląda trochę inaczej gdyż jak rozumiem zajmujecie się twozreniem fizycznych ukąłdów elektronicznych.
Jak możes zopisz dokaldnie jak ów proces dokładnie przebiega w twojej firmie
Są dwie drogi postępowania:
I. Oprogramowanie dedykowane
Tutaj sprawa jest prosta, konstruktorzy projektują jakieś urządzenie lub najczęściej cały system kontrolno pomiarowy, elektronicy robią do tego sterowanie lub najczęściej stawiają całą szafe napchaną elektroniką no a my robimy software który nad tym wszystkim zapanuje. Software ma nie tylko sterować urządzeniami ale także zbierać wyniki pomiarów, robić reprezentacje graficzne tych pomiarów.
II. Oprogramowanie określane u nas jako komercyjne:
Jest to oprogramowanie które współpracuje z określonymi systemami różnych producentów. Przykładem może tu być TDS (Thermal Desorption Spectrometry). Program może pracować w kilku konfiguracjach sprzętowych np. spektrometr masowy SRS RGA + termolegurator PID Eurotherm lub spektrtometr SRS QMS + Eurotherm.
O ile w pierwszym przypadku to nasi konstruktorzy wiedzą jaką funkcjonalność ma mieć oprogramowanie to w drugim przypadku ostanie słowo w tej kwestii ma klient.
I tak np. TDS został zrobiony w podstawowej wersji, później został wysłany do instytutów na uczelniach i wtedy dopiero pojawiły się uwagi użytkowników, program został dostosowany do potrzeb użytkowników i znowu wysłany i tak w kółko Macieju. Metoda ta ma jedną wadę: niekiedy wymagania użytkowników są ze sobą sprzeczne, wtedy potrzebne jest wypracowanie kompromisu. Metoda ta zapewnia że produkt jest cały czas rozwijany, pojawiają się nowe pomysły odnośnie funkcjonalności itd. itp. Dodatkowo rozwój tego oprogramowania wspomaga pojawianie się nowych urządzen, np. w wersji 2.x TDS posiada możliwość dołączenia miernika próżni i również analizowania/zapisu odczytów z tego urządzenia.
0
Dyskusja za bardzo odbiegła od oryginalnego pytania, a brzmi ono:
No właśnie. Czy spotkaliście się już z taką sytuacją? Klient zmienia zamówienie co tydzień, nie może się zdecydować o co tak naprawdę mu chodzi. Jedyną informację jaką można od niego uzystkać to: "żeby było fajne". Jak sobie z tym radzić?
Zasadnicze pytanie w tej sytuacji brzmi: Czy klient może nie być zainteresowany swoim projektem ?
TAK ! Najlepsze porównanie jakie mi przychodzi do głowy to sytuacja w której muszę wyprowadzić psa na spacer. Robię to z konieczności i chociaż podejmuję pewne decyzje (mała czy duża trasa) to w gruncie rzeczy nie jestem tym spacerem zainteresowany.
DevilHimself, jeśli odkryjesz przyczynę dla której klient nie jest zainteresowany projektem to będziesz miał chyba szansę to zmienić. Być może klient nie wierzy w powodzenie projektu i jest skrajnie sceptyczny, być może nie dostrzega potencjalnych korzyści jakie ten system wniesie ...
Miałem taką sytuację między innymi w małym projekcie na zlecenie firmy produkującej i instalującej ścianki działowe dla powierzchni biurowych. Kierownik polskiego oddziału, tej międzynarodowej korporacji, chciał aplikację do wizualizacji takiej ścianki złożonej z różnych segmentów z różnymi elementami wykończenia.
Temat wydawał mi się bardzo ciekawy - zastanawiałem się czy nie spróbować przedstawiać tego w ujęciu 3D i miałem sporo różnych pomysłów ... miałem ich sporo aż do pierwszego spotkania, które było jednocześnie naszym jedynym spotkaniem analitycznym. Pan Jacek przedstawił mi, że chce coś fajnego, co będzie podobne do ich strony internetowej tylko tyle, że będzie interaktywne oraz będzie możliwość wydruku takiej wizualizacji lub zapisu do pliku.
To wszystko co udało mi się z niego wydusić. Podejrzewam, że byłem wtedy w podobnej sytuacji co Ty. Chociaż to trochę przykre ale postanowiłem, że jeżeli ten facet nie chce dopracowanej aplikacji dzięki której mógłby zostać doceniony w innych oddziałach to ja nie będę mu na siłę jej wciskał, po czym zabrałem się do spisywania jednej kartki specyfikacji wymagań.
Wymagania miały w tamtym projekcie postać krótkich ale szczegółowych punktów. Nikt chyba nie poruszył tej kwestii w dotychczasowej dyskusji ale wymagań nie da się spisać absolutnie precyzyjnie. To zawsze jest w jakimś zakresie kwestia dobrej woli i chęci dogadania się dwóch stron. W zasadzie mam wrażenie, że można by posilić się na matematyczny dowód na to, że nie istnieje nieskończenie precyzyjna dokumentacja ...
Ostatecznie klient podpisał umowę wraz z załączoną specyfikacją [w umowie był błąd przez co nie była ona formalnie wiążąca ale to szczegół :)] a ja klepnąłem kawałek softu nie będąc pewien czy spełnia on jego oczekiwania i czy kiedykolwiek będzie z niego korzystał. To był projekt po to, aby zarobić bo satysfakcji z niego niestety nie miałem.
pozdrawiam.
0
Kapustka napisał(a)
W zasadzie mam wrażenie, że można by posilić się na matematyczny dowód na to, że nie istnieje nieskończenie precyzyjna dokumentacja ...
Oj chyba tak, zawsze znajdzie sie cos, co nie zostalo sprecyzowane.
Kapustka napisał(a)
Ostatecznie klient podpisał umowę wraz z załączoną specyfikacją [w umowie był błąd przez co nie była ona formalnie wiążąca ale to szczegół :)] a ja klepnąłem kawałek softu nie będąc pewien czy spełnia on jego oczekiwania i czy kiedykolwiek będzie z niego korzystał. To był projekt po to, aby zarobić bo satysfakcji z niego niestety nie miałem.
Ja mialem podobna sytuacje z pewnym urzedem, ktory zapragnal miec stronke. Poniewaz robilem wczesniej strone dla innego urzedu to miedzy soba dogadali sie, ze tamten mi hurtem zaplaci za obydwie, a ja zrobie najpierw pierwsza, pozniej druga. Pierwsza zrobilem, hula calkiem ladnie. Poszedlem porozmawiac o tej drugiej i tez uslyszalem - taka fajna, zeby byla w kolorach firmowych, no i zeby miala to co powinna miec. Acha - sobie pomyslalem - wiem wszystko. Tez spisalem wszystko na jednej kartce, propozycje, pomysly roznych funkcjonalnosci, nastepnie sie spotkalismy i umowilismy sie, ze wysle layout do zaakceptowania przez zarzad. Layout wyslalem, dostalem odpowiedz, ze sie nie podoba. Odpisalem wiec z prosba o wiecej szczegolow (kolory, menu, jakis konkretny szczegol, itd.) Tu juz dostalem bardziej konkretna, ale moj grafik i tak mial wielkie pole do popisu, z czego nie byl specjalnie zadowolony. Wyslalem po raz drugi i ... po dwoch miesiacach dostalem maila z prosba o wyslanie jeszcze raz, bo sie zagubil. ... minelo miesiecy juz 4 od ostatniego kontaktu, ja w sumie chyba wszystko mam przygotowane, ale od nich ani slychu ani widu. Mnie to osobiscie malo obchodzi, bo mnie w zasadzie juz zaplacono. Nawal pracy mam, wiec nie prosze sie o jeszcze.
To chyba taki przyklad na to, ze klientowi moze sie nie chciec... bo np. ma zapisane w statucie i ma byc. JAK ma byc to juz nikt nie sprecyzowal, wiec byle po linii najmniejszego oporu.
Ja swoje wnioski z historyjki wynioslem, stratny na tym nie bylem, ale moze komus sie przyda taka wiedza.
pozdrawiam
johny
0
witam,
Z obserwacji swojeg szefa, poprzedniego i jeszcze poprzedniego wynika, że najważniejsze żeby się klient na coś zdecydował i podpisał sie pod dokładna analizą załóżeń najlepiej zrobioną przez niego samego, jak cos mu się potem nie podoba, tyciągamy papier i dopłaca za nadgodziny(często osobotygodnie).
Jak nie to sąd itp, firmy windykacyjne czy coś tam, takich problemów jeszcze nie miałem, ale za to kiedyś nas straszyli karam za opóźnienia w realizacji itp, pospotkamiu zarządu klienta i naszego PM, uzgodnili że kar nie zapłacimy, tylko że mamy t w końcu zrobić, bo jest im to koniecznie potrzebne :P
Tak więc, kwestia dogadania :)
Pozdrawiam.
PS. Projekt był baaardzo duży, a to o czym piszę to jakieś usprawnienie tylko.