Gdy przychodzi ktoś do Was i chce byście zaprogramowali (napisać program pod mikrokontroler, czy podobne) mu układ, który pełni takie i takie funkcje, to jak do tego podchodzicie ? Wymagacie, by zamawiający napisał wyczerpujący opis zapotrzebowania, czy rozmawiacie ustnie i ustalacie główne cechy projektu? Jak to wygląda? A może jest jakaś literatura na ten temat, coś z rodzaju organizacji projektowania, produkcji...?! U mnie dochodzi do tego, że 50% czasu poświęconego na projekt to czas związany z określeniem "co tak właściwie układ ma robić"? Też tak macie? A może to normalne... :-)
żeby przeczytał ze zrozumieniem. Zaznaczam, że jak zamkniemy specyfikację, to klamka zapadła i wszelkie zmiany są _niemożliwe_ chyba, że dadzą się łatwo i szybko wykonać (tzw. zmiany kosmetyczne), ale o tym ja decyduję.
Po oddaniu programu zmiany będą nowym projektem.
Niestety bardzo często zamawiający po prostu nie wie jak dokładnie ma działać i trzeba wysiedzieć. Wtedy staram się minimalizować ten czas (za który oczywiście zamawiający płaci). Nie uzgadniam specyfikacji przez GG, maila. Jedynie przez telefon (ew, skype) lub na żywo. Staram się możliwie dużo tworzenia specyfikacji przerzucić na zamawiającego (bo za to on nie płaci).
W zupełnie badawczych przypadkach są po prostu kolejne etapy, ale mały odsetek klientów stać na takie R&D.
A jak postępujesz w kwestii cen ? Z góry określasz cenę za dany produkt (program), czy jakoś inaczej, bo nie zawsze z góry da się wszystko przewidzieć i czasami pojawiają się nieprzewidziane trudności. A jak produkt "niewypali", tzn. w ogóle nie uda się go uruchomić (czy podobne..) to wtedy co? Kto płaci za poświęcony czas?
-podzielę na etapy i będziemy po kolei oddawać kawałki i się rozliczać To w zaleznosci od projektu
Nieprzewidzane trudnosci traktuje jak doswiadczenie kupowane od zycia :-)
Tu zawsze staram sie systematyzowac projekt. Co to znaczy w ogole nie da sie uruchomic? Brak zasilania? Zawsze jest jakas przyczyna. Jesli etapem jest na przyklad (jak ostatnio) mobilne lacze radiowe, wykonalem pomiary BER w zaleznosci od odleglosci. I wyniki byly takie, ze zasieg jest taki a taki. Jesli chce Pan lepszy zasieg, trzeba lepszy (drozszy sprzet). I teraz albo mi zaplaca za czas albo sie zegnamy.
Staram sie uswiamiac klientom, ze za badania i pomiary trzeba zaplacic. Wielu wydaje sie, ze za 200 zlotych zrobie im urzadzenie, ktore na rynku kosztuje 250. Z takimi w ogole nie rozmawiam, szkoda czasu. Jesli jest powazny, to sie dogadamy.
Brutalna prawda jest taka, ze jesli to jedyne zrodlo utrzymania, to za wszystko placa klienci. Bezposrednio lub posrednio. Za spalone uklady, naprawy sprzetu, szukanie w kodzie zapomnianego przecinka, za wszystko. Niestety, malo kto to rozumie.
IMHO wazna jest wiarygodnosc. Ze nie starasz sie wciskac kitu, tylko sprzedajesz dobra, solidna rzecz, za ktora warto zaplacic. Kiedys robilem urzadzenie bateryjne, gdzie w specyfikacji napisalem: czas dzialania na baterii: conajmniej 8 godzin. Klient z rozczarowaniem: a u innych jest do 20 godzin... Na to ja: _DO_ 20. Tak jak 5W PMPO Tak jak spalanie 3/100km Tak jak 3% w skali roku Tak jak juz od 20zl/mies ... A moje urzadzenie w kazdych warunkach, przy kazdym rodzaju uzytkowania
8 godzin musi dzialac. No wiec jak Pan woli, mam przedstawic fakty, czy opowiedziec bajeczke?
Pouczony smutnym doswiadczeniem staram sie spisac umowe. W naszym sadownictwie i tak sie nie wygra, ale jakas presja na klienta jest. Co do samego projektu staram sie mozliwie duzo ustalic mailem, chocby dla wlasnej wygody nie zapomnienia o czyms. Niestety brak umowy owocuje tym, ze klient najpierw bardzo zainteresowany potem sie wycofuje, a ja zostaje z projektem, na ktory poswiecilem kilka tygodni i troche kasy. Mam dosc zawracaczy glowy. Jedyny zysk z takich nie zfinalizowanych projektow to wieksza wprawa np. w programowaniu uK.
Ja tu widze problem tego typu, że zamawiający m.in. dlatego, że nie programuje, nawet nie uświadamia sobie na jakie wątpliwości natrafi programujacy uP.... Oczywiście można się o wszystko wypytać, ale tak czy owak ciężko to idzie. Zależy też o jakie zlecenie chodzi: czy o gotowy układ, czy tylko np. o program do uP.
A jak z kosztem podzespołów, osobno je wliczasz do wynagrodzenia za dany projekt ? A gdy piszesz tylko program, to za czyje pieniądze budujesz prototyp na swój użytek, ten do testów ? (pewnie klienta, ale pytam...)
Koszt podzespolow jest tak maly (zwykle) ze mozna sobie darowac. Pisze oczywiscie na podstawie swojego skromnego doswiadczenia. Atmelek, ktorymi sie bawie kosztuje kilka zl. Jak bym mial zainwestowac w kosc za przynajmniej kilkadziesiat zl, to bez umowy bym sie nie zabieral. Zreszta wogole bez umowy wole sie za nic nie zabierac.
Moje dotychczasowe osiagniecia dzialaja na plytce prototypowej, ktora sobie sam poczynilem, jak trzeba cos dostawic, to na plytce uniwersalnej i juz. Oczywiscie jak trzeba by bylo cos powaznego przygotowac to mozna zainwestowac w np. jakis starter kit z firmy. Najwazniejsze to spisac umowe, zeby potem nie zostac z masa prototypow po szufladach i pustkami na koncie.
A jak mamy podchodzić? :-) Jak do normalnego małego zlecenia komercyjnego.
Na początku nie interesują mnie szczegóły techniczne, chcę poznać planowane zastosowanie zamawianego oprogramowania i z nieformalnej rozmowy staram się zbudować sobie wyobrażenie oczekiwań klienta. Następnie zaczynam wplatać istotne w moim przekonaniu szczegóły w ten obraz ogólny i podczas konsultacji sprawdzam, w jakim stopniu kłóci się to z wizją klienta, w razie istotnych różnic odpowiednio koryguję swoje wyobrażenia. Gdy już ustalimy wspólną wersję obrazu docelowego programu, to _ja_ opracowuję finalną wersję opisu potrzeb klienta i przedstawiam mu ją do zatwierdzenia.
W świecie rzeczywistym żaden klient indywidualny nie napisze Ci dostatecznie spójnego zestawu wymagań, byś mógł go użyć jako podstawy do rozpoczęcia prac nad oprogramowaniem, a jeśli nawet by się taki zdarzył, to jest spora szansa, że go opacznie zrozumiesz. I jest to w porządku, bo poniżej pewnego pułapu złożoności i ceny oprogramowania umiejętność wyczerpującego przedstawienia problemu nie jest klientowi do niczego potrzebna. On jest fachowcem w swojej dziedzinie i nawet nie przyjdzie mu do głowy zwrócenie uwagi na pewne oczywiste dla niego sprawy, na których Ty się wyłożysz. To Ty masz wyrobić sobie pewne wyobrażenie o problemie i modyfikować je w opraciu o fachową wiedzę klienta. Innymi słowy, musisz wiedzieć, że klient wie, że Ty rozumiesz problem. Gdy dojdziesz do tego etapu, to reszta będzie już prosta.
Jaka organizacja produkcji? ;-) Jak liczny zespół ma realizować to zlecenie? Bo jeśli więcej niż kilkanaście osób, to obawiam się, że nikogo poniżej instytucji lub średniej firmy nie będzie stać na wasze usługi -- w takim przypadku sytuacja wygląda zupełnie inaczej, klient zazwyczaj zatrudnia osobę umiejącą sformułować wymagania, a i sumy nie wyrażają się w pojedyńczych tysiącach złotych. Jeśli zaś
-- czego się domyślam -- oprogramowanie masz pisać Ty sam, ewentualnie ze współautorem, to co właściwie chcesz organizować?
W tej sytuacji jest to najzupełniej normalne. Nie staraj się tego przyspieszyć, bo naprawienie w fazie zaawansowanych prac programistycznych błędu popełnionego na etapie projektu bywa niezwykle kosztowne i to Ty za to zapłacisz.
Z całym szacunkiem, ale sądzę, że nie miałeś nigdy do czynienia z _poważnym_ klientem, np. zamawiającym system o złożoności w osobolatach przekraczającej Twoją oczekiwaną długość życia.
Może mówiąc bardziej konkretnie, miałem napisać tylko program do uP, a teraz wychodzi na to, że mam jeszcze rysować schematy, w ogóle "nadzorować" pomysł całego urządzenia... Nie jest to nic nadzwyczajnego, ale samo się nic nie robi, i by dawać klientowi sensowne wnioski, to ja muszę na to poświęcić czas, bo trzeba wszystko doczytać i się jeszcze nad tym zastanowić. Nie mam nic naprzeciwko, ale jak się z tego rozliczać ?! Na godziny czy jak? Przecież żaden super elektronik, też nie zna wszystkich not katalogowych na pamięć i wszystko trzeba doczytać... Nawiasem, człowiek uczy się całe życie i na przyszłość, będę te relacje ustawiał jakoś sensowniej... :-)
Piotr Wyderski snipped-for-privacy@mothers.against.spam-ii.uni.wroc.pl> pisze:
Mądrze prawisz.
A ja mam do Ciebie pytanie, jak byś postąpił z klientami mądrzejszymi od kury :-) klient potrzebował czujnika temperatury z dokładnością do 0.2-0.5 stopnia i upierał się na DS18B20, bo ktoś mu powiedział że jest wypasiony i ma dokładność 0.0625 stopnia. Próby wytłumaczenia, że dokładność to nie to samo co rozdzielczość albo że 0.5 stopnia mu nie jest potrzebne nie dały rezultatu.
Jak najlepiej z takim gościem postąpić?
Zrobiłem tak, że zastrzegłem, że nie biorę odpowiedzialnośći za rozrzut czujników.
Koniec końców dostał urządzenie i oczywiście w wodzie z lodem nie wskazywało 0.000 stopnia i mlaskał nad tym strasznie.
Pokazałem PDFa do dallasa i skończyło się. Był to fizyk-teoretyk zaślepiony przez kompputery i widać słowo "cyfrowy czujnik" padło mu na mózg.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.