Współpraca z klientem - jak to u was wygląda?

Po pierwsze - moim zdaniem ten post raczej pasuje w inne miejsce, a nie do Off-Topic.
Off-topic jest miejscem do gadania głupot i rzucania luźnych przemyśleń, a Twoje pytanie posiada dużo sensu i jest związane z pracą. Dlatego raczej dałbym to do "kariera", ewentualnie do "nietuzinkowe tematy".

A co do rozmów z klientami (oraz innymi "nietechnicznymi" osobami) - czasem trzeba mieć dużo cierpliwości, a z niektórymi rozmawiać jak z dzieckiem.

Nie używaj fachowych ani slangowych zwrotów - np. zamiast "frontend" lepiej mówić "na stronie" a zamiast "backend" używać określenia "na serwerze", nie SQL ale baza danych itp.

Staraj się używać porównań i analogii do rzeczy/technologii, które "przeciętne" osoby znają - np. porównaj do samochodu albo odkurzacza (wiem, że to może brzmieć dziwnie, ale naprawdę - działa). Często znajomi polewają ze mnie i mojego ulubionego tekstu "to jest zupełnie jak z samochodem" :D

Pytaj często, czy dana osoba rozumie o czym rozmwiacie, przy czym nie rób tego poprzez pytanie "czy rozumiesz" - bo wtedy prawie każdy pokiwa mądrze głową i powie, że tak, ale raczej poprzez zadawanie pytań w ten sposób, żeby rozmówca musiał się odwołać do czegoś, co było wcześniej omawiane.

Dużo też rysuj - jakieś strzałki, napisy itp. - możliwość zobaczenia czegoś wielu osobom ułatwia zrozumienie tematu.

Jak klient coś Ci mówi - powtarzaj to po nim. W ten sposób sprawdzisz, czy dobrze zrozumiałeś. Czyli - klient mówi, że chce "niebieskie kółko z lewej strony". Ty go wysłuchujesz, a następnie mówisz "rozumiem, że chcesz, żeby po lewej stronie było kółko koloru niebieskiego". W ten sposób się upewnisz, że się dogadaliście

Czasami dobrze jest po takim spotkaniu wysłać maila/stworzyć ticket, w którym opiszesz to, co ustaliliście. Dzięki temu masz to gdzieś zebrane, więc raczej żadna z rzeczy uzgodnionych nie ucieknie. Dodatkowo klient może się zapoznać z tymi ustaleniami i zweryfikować, czy na pewno o to mu chodziło. A jakby zaczął wydziwiać/czepiać się - mówisz że był wysłany mail i nie zgłaszał wtedy do niego zastrzeżeń, więc niech się teraz pójdzie udławić ;)

Wątek już został przeniesiony. Dzięki za trafne rady, na pewno z nich skorzystam. Zdecydowanie świetnie sprawdza się zawsze podsumowanie w mailu. Często spotykam też taką postawę, że "ja się nie znam, od tego jesteście wy, żeby się znać, zróbcie tak, żeby było dobrze" :). Wtedy zaczyna się zabawa w wyciąganie informacji od klienta, w zasadzie dla jego dobra przecież. To mnie dziwiło, że niby ktoś coś bardzo potrzebuje, ale ma w nosie funkcjonalność :/.

ale ma w nosie funkcjonalność

Na razie ma to gdzieś, ale jak zrobisz to po swojemu, to potem będzie miał 1000 uwag, wszystko jest źle i niezgodnie z oczekiwaniami ;)

I nieśmiertelne oburzenie : "Ale jak k... xxxx PLN mam zapłacić ?!!!! Za jeden przycisk ???!!"

Zamiast dawać ci radę jak tłumaczyć język klienta na język programistów (co jest na 100% niemożliwe tak samo jak niemożliwa jest komunikacja mrówki z człowiekiem) to dam ci inną radę. Klient to mrówka - nie wie czego chce i kierują nim proste instynkty. Więc postaraj się go uspokajać, schlebiać mu, pochwalać pomysły - daj mu się wykazać - a jak nie potrafi to wyszukaj jakieś success story i podsuwaj mu do przemyślenia. On przede wszystkim musi być pewien że projekt zmierza w dobrą stronę (nawet jeśli oznacza to ficzer na rok ;) )

Jak jest uparty i wymaga niemożliwego to argumentuj do jego kieszeni - tam zazwyczaj ukryta jest racjonalna część klienta. Z programistami nie szukaj porozumienia - my dobrze wiemy że wszystko jest osiągalne tylko wymaga a) czasu b) czasu. A to kosztuje i go zazwyczaj nie ma. Więc jak zapewnisz rozsądną ilość czasu programistom to będzie dobrze. A jak przekonać do tego klienta? No cóż, dlatego wybrałem rolę deva :D

• Po stronie klienta przydałaby się jedna osoba, z którą się kontaktujesz i tłumaczysz przez cały czas trwania projektu. W ten sposób masz jeden punkt styku z klientem.
• Wszystkie rzeczy ustalaj z tą jedną osobą, nie będzie w ten sposób zamieszania.
• Możesz zrobić jakieś przykładowe prototypy ekranów i wyjaśnić jak system będzie działać w prostych słowach. Ogólnie warto rysować jak najwięcej i pokażywać, bo rysunek więcej powie niż opowiadanie. To tak jak macanie cycków przez szybę;)
• Jak trafi się osoba mało wyedukowana informatycznie możesz wszystko tłumaczyć dokładnie "jak krowie na miedzy" aż do skutku. Osoba w końcu zrozumie, a i Ty utwierdzisz się czy wszystko idzie w dobrym kierunku.
• W miarę możliwości warto spotykać się twarzą w twarz, niż ustalać kwestie emailowo czy przez telefon. Na spotkania zapraszaj jak najmniej osób (zwłaszcza kobiet) to łatwiej pójdą ustalenia i nie będzie koncertu życzeń.
• Ustalenia dokumentować w postaci pisanej (email czy jakiś dokument), aby potem nie było niespodzianek, że system działa inaczej niż osoba myślała.
• Jeżeli ktoś mówi, że "ja się nie znam, od tego jesteście wy, żeby się znać, zróbcie tak, żeby było dobrze" to znaczy, że na poziomie biznesowym osoba nie wie co chce, a co dopiero co ma robić system.

Najzabawniejszą sytuację, jaką miałem. To jak przedstawiłem kosztorys, na to ile mniej więcej potrzebuje czasu, a klient mi na to "Jeśli sam będę testował aplikacje to będzie taniej?" ;)

A prawda jest taka, że jeśli nie jesteś z zamiłowania programistą, nie masz pojęcia o modelowaniu domeny, architekturze, nie potrafisz myśleć w kategoriach user case, diagramów klas, sekwencji użycia. Nie będziesz potrafić wyciągnąć niezbędnych informacji od klienta dla programisty.

Dzięki za wszystkie odpowiedzi, każda wiele wnosi. Wiadomo, każdy klient ma swoje wymagania i trzeba mu pomagać. Odnośnie jeszcze wycen - my zawyżamy też wyceny, kiedy klient już od samego początku jest bardzo roszczeniowy. Daje to dwie możliwości - albo nie skorzysta, a jeżeli się zdecyduje to przynajmniej za konkretny $$. Jeżeli już mamy się z kimś takim użerać, to przynajmniej musi się to opłacać.

W postępowaniu z klientem polecam nieśmiertelne prawo Murphego:

"Klient nigdy nie wie czego chce, za to wie, czego nie chce - tego, co właśnie mu wykonałeś"

;-)