Jak sprawić by pracownicy przejmowali się pracą?

Zarządzanie zespołem 05/09/2008 · Link

Natknąłem się na fajny artykuł na ten temat: How to Make Your People Accountable Moją uwagę przykuł punkt o tym, by pracownicy mieli realny wpływ na to, czy ich praca zakończy się porażką czy sukcesem ("They have substantial control over their ability to succeed or fail"). Z perspektywy osoby odpowiedzialnej za zespół wydaje się to oczywiste.

Z perspektywy osoby odpowiedzialnej za projekt (czyli za sukces lub porażkę całości, na którą składają się cząstkowe sukcesy/porażki poszczególnych prac) - jest to kontrproduktywne.

I problem polega na tym, że funkcja Project Managera łączy w sobie obie funkcje.

Jak przełamać w sobie mentalny opór i pozwolić ludziom na porażki - ciekawy temat.

Podyskutujmy... (5)

rafalowicz.pl -> projectcomplete.pl

Sprawy organizacyjne 28/02/2008 · Link

Jak prawdopodobnie zauważyliście, zdecydowałem się zmienić nazwę tej strony i przenieść ją pod inną domenę.

Wynika to z tego, że otwieram nowe przedsięwzięcie i zdecydowałem się uniezależnić nieco mój wizerunek od zarządzania projektami :)

Nowe przedsięwzięcie nazywa się Mój Startup i jest relacją z tworzenia nowej firmy. Od czasu do czasu będę zamieszczał tam notki dotyczące między innymi tego co tworzymy, naszych relacji z fiskusem, przygód z organizacją biura, podejścia do zarządzania w takim środowisku, sytuacji finansowej i różnych innych - słowem będzie to big brother z zakładania i tworzenia nowej firmy.

Od razu zastrzegam, że nie jestem ekspertem od nowych przedsięwzięć, więc nie będzie to poradnik, a tylko w miarę obiektywna relacja. Liczę wręcz, że może niektórzy z Was podzielą się ze mną wiedzą i doradzą w tym lub innym momencie.

Tę stronę gotów jest oddać w większym stopniu Wam - czytelnikom. Możecie dzielić się swoimi przemyśleniami na ogólnoostępnym jest forum, jeśli jesteście artykułów o zarządzaniu to możecie umieścić je w sekcji artykuły, a jeśli prowadzicie bloga o podobnej tematyce, to nie ma problemu, by zamieścić tu fragmenty Waszych notek (np. udostępnione z RSSa), co może dla Waszych stron stanowić dodatkową promocję. Jeśli bylibyście zainteresowani, to proszę o kontakt.

Od czasu do czasu będę też umieszczał notki o zarządzaniu projektami w części Blog Marka, ale do częstotliwości nie mogę się zobowiązać :)

Podyskutujmy... (1)

Wybór miejsca parkingowego

Różności 24/06/2007 · Link

"Kiedy pierwszy raz byłem w Szwecji jeden z kolegów podwoził mnie z hotelu do pracy każdego ranka. Był wrzesień, nieco chłodny i padał pierwszy śnieg. Przyjeżdżaliśmy wcześnie do firmy, ale parkowaliśmy daleko od wejścia (2000 pracowników dojeżdżało samochodami do pracy). Pierwszego dnia przemilczałem ten fakt, drugiego i trzeciego też. Ale pewnego ranka zapytałem:
- Czy masz przydzielone miejsce parkingowe? Zauważyłem, że parkujesz daleko od wejścia nawet wtedy, gdy nie ma innych samochodów na parkingu.
Na co on odpowiedział:
- Ponieważ przyjechaliśmy wcześniej, więc mamy chwilę na to, by się przespacerować, a ci, którzy przyjadą później, będą mieli mniej czasu, więc będą potrzebowali miejsca bliżej wejścia.
Wyobraźcie sobie moją minę."

Cytuję to za sympatycznym wpisem z artykułu Slow Down Culture (autorstwa nieznanego), którego przeczytanie w całości serdecznie Wam rekomenduję. Opisana scena obrazuje skandynawskie podejście do pracy (i życia), z którym miałem też szansę zetknąć się osobiście: myślenie nie tylko o sobie, duża doza zaufania do innych ludzi, spokój, cierpliwe planowanie, unikanie pośpiechu, staranność w działaniu. Dla nas sprawia to wrażenie działania flegmatycznego, ospałego, mało wydajnego, ale takie podejście pozwala na dużo lepsze "skupienie energii" i wykorzystanie kreatywnych rozwiązań, co w dzisiejszej gospodarce (również informatyce!) jest ważniejsze niż "szybkie bieganie z taczkami". Pewnie dzięki temu te kraje są w czołówce świata jeśli chodzi zarówno o komfort życia jak i produktywność.

Co prowokuje do ciekawych pytań, na przykład:

1. Jak ilość czasu spędzanego w pracy wpływa na Twoją efektywność? kreatywność? Czy masz w niej czas na "zwolnienie"?
2. Czy w pracy jesteś produktywny, czy tylko zajęty?
3. Przez jaki procent czasu wykonujesz prace, które w niewielkim stopniu przybliżają Cię do wytyczonych celów?
4. Gdzie są i z czego wynikają ograniczenia w efektywności optymalizacji opierającej się tylko na konkurencji? Jaka filozofia - współpracy czy konkurencji - jest dominująca w Twojej firmie?
5. Czy to co robisz na co dzień (w pracy i poza nią) jest życiem, czy budowaniem planów na życie? Na kiedy odkładasz prawdziwe życie?

Jak Wy to widzicie?

Podyskutujmy... (5)

Produktywność programistów - 10000 razy?

Różności 23/06/2007 · Link

Na swoim blogu Alex Barszczewski poruszył ciekawe zagadnienie zarządzania pracownikami o wyjątkowych umiejętnościach (patrz tutaj), który to artykuł gorąco polecam wszystkim menedżerom w naszej branży, bo z opisanymi w nim wyzwaniami z pewnością przyjdzie nam się spotykać.

Zgadzając się z głównymi tezami artykułu, zdziwiła mnie podana przez Alexa informacja, że programiści różnią się wydajnością nawet 10000 razy. Wow! Czy tak jest w istocie?

Ponieważ wątek "10^n razy" odbiega od głównego nurtu tamtej dyskusji postanowiłem zmierzyć się z nim tutaj.

Niektórzy programiści są 10.000 razy bardziej produktywni od innych

[Krzysiek] w komentarzu obszernie wyjaśnia skąd bierze się ta liczba. Wniosek z tego wywodu rozumiem następująco: różnice w różnego rodzaju umiejętnościach programistów są tak duże, że co jeden potrafi zrobić w rozsądnym czasie, inny może nie być w stanie zrobić w ogóle. Co dla mnie, jak i podejrzewam dla większości z Was, nie jest zapewne kontrowersyjną tezą.

Czy to specyfika pracy programistów? Jak to jest w innych zawodach? Weźmy Michała Anioła, Einsteina, Bono, Steve Jobsa, Churchilla, Ala Pacino etc. Przeciętny rzeźbiarz, fizyk, muzyk, polityk, aktor nie osiągnie - nawet mając 10000x więcej czasu - tego co oni. Nawet pan Kaziu, który super równo kładzie kafelki w łazience, nie da się zastąpić tysiącem przeciętnych fachowców. Ale nie mówi się, że produktywność rzeźbiarzy, fizyków, muzyków, polityków, aktorów, kafelkarzy etc różni się więcej niż tysiąckrotnie. Dlaczego?

Niektórzy programiści są w stanie napisać 10000 razy więcej kodu w tej samej jednostce czasu

Nie, nie o taką produktywność nam chodzi, prawda? Produktywność pracownika można pewnie odnieść do dwóch aspektów: czasu wykonania określonego zadania lub mierzalnych korzyści finansowych dla firmy.

Najpierw przyjrzyjmy się aspektowi czasu wykonania. Postawmy się w sytuacji menedżera zespołu, który ma konkretne zadanie do wykonania, np. wyszukanie w tekście wszystkich wystąpień słów z określonego zbioru. Menedżer taki przygląda się swojemu zepołowi: Tadek to zrobi w godzinę, Zosia w cztery, Wojtek w 1250 dni (10000 godzin).

Ups, chyba przesadziłem, nieprawda? Jeśli Wojtek nie jest w stanie tego zrobić w ciągu maksymalnie kilku dni, to w praktyce przyjmujemy, że nie jest on w stanie wykonać tego zadania w ogóle. I to jest zrozumiałe, trudno, ale mówienie, że jego produktywność jest mniejsza o x od Tadka nie ma sensu. Ich zakres umiejętności jest różny, tak jak różny jest zakres umiejętności Tadka i asystenta prezesa. (Zapewne ten asystent mając 1250 dni jest się w stanie nauczyć podstaw programowania i napisać ten kawałek kodu. To prawie 5 lat, więc nawet studia zdąży zrobić).

A więc przyjmując zdroworozsądkową cierpliwość menedżera, możemy z góry oszacować maksymalną różnicę tak rozumianej produktywności na około kilkadziesiąt (3d / 1h = 24). I to bez żadnych pomiarów!

Jeśli mówimy o finansowych korzyściach dla firmy, to produktywność pracownika w pewnych branżach może się różnić nawet więcej niż 10000 razy (Steve Jobs, Warren Buffett, Andre Agassi,...). Pewnie jest jakiś powód, dla którego do przebojów filmowych bierze się Matta Damona, Sandrę Bullock czy Julię Roberts pomimo ich ekstremalnych zarobków. Branże gdzie występuje taka różnica "produktywności finansowej" łatwo zidentyfikować na bazie różnic w dochodach pracujących w nich ludzi (sportowcy, aktorzy, biznesmeni, menedżerowie,...). Nie jest to więc cecha w żaden sposób specyficzna dla programistów.

Ale zaraz - czy to w ogóle dotyczy programistów? Nie potwierdzają tego raporty o rozpiętości zarobków programistów w porównaniu do wspomnianych rozpiętości zarobków aktorów, menedżerów, sportowców. Jak to więc jest? Czy naprawdę sukces rynkowy produktu zależy od umiejętności gwiazdora programisty?

Ten programista zarobi dla naszej firmy 10000 razy więcej pieniędzy

Dobre gry komputerowe odnoszą sukces, bo były "fajne" - miały dobry pomysł, fabułę, dopracowaną grafikę i dźwięk. Aplikacje internetowe, bo rozwiązywały jakiś istotny problem dla użytkowników (np. dostępu do swojej poczty z różnych miejsc, czy pisania pamiętników). Aplikacje desktopowe, bo były praktyczne, pomysłowe, wygodne. Nawet sukces google.com, firmy utożsamianej ze śmietanką programistów, bardziej opierał się na dobrym pomyśle na przeszukiwanie (page rank) i model biznesowy związany z reklamami (dopasowanie reklam do wyników wyszukiwania, wyświetlanie reklam na stronach użytkowników) niż na niesłychanie wyrafinowanym i misternym oprogramowaniu. A więc istotny jest pomysł, zrozumienie użytkownika, dopracowanie interfejsu i grafiki, właściwy model biznesowy, dobry marketing, etc. Te czynniki (a właściwie ich odpowiednia kombinacja), są w deficycie, a nie umiejętności zaprogramowania określonych funkcjonalności. Osoby będące źródłem kreatywnych pomysłów są "bardziej produktywni" (w finansowym znaczeniu) od osób mało twórczych. Osoby z dobrym zrozumieniem rynku - też. Liderzy potrafiący zmobilizować duże grupy ludzi do bardziej efektywnej pracy - też. Ale to nie muszą (i często nie są) programiści.

I wtedy porównywanie ich produktywności z produktywnością programistów to tak jakby mówić "jabłka są sto razy lepsze od kotleta".

Jedyna znana mi sytuacja, w której faktycznie czysto programistyczne umiejętności są finansowo wynagradzane znacznie powyżej standardu (co zapewne świadczy o wielokrotnie wyższej wartości pracy tych osób dla firmy), to sytuacja osób, które na przykład współtworzyły systemy billingowe dla operatorów telekomunikacyjnych. I ponieważ Ci operatorzy mają mnóstwo pieniędzy, a to są kluczowe dla nich systemy, więc są w stanie zapłacić duże pieniądze za szybkie wprowadzenie usprawnień. Ale nie mówimy tu o wydajności tych programistów, tylko o umiejętnym wykorzystaniu przez nich monopolu na bardzo specyficzną wiedzę. Są oni nie tyle super wydajnymi programistami ile biznesmenami, wykorzystującymi określoną sytuację rynkową.

Disclaimer

Niemniej, jeśli znacie programistów, którzy są choćby 100x bardziej wydajni od przeciętnych, to bardzo proszę, przekażcie im kontakt do mnie, może uda nam się znaleźć pomysł na współpracę?

Podyskutujmy... (11)

Jeśli chcesz zbudować statek...

Miękkie umiejętności 12/05/2007 · Link

"Jeżeli chcesz zbudować statek, nie przywołuj mężczyzn, żeby zdobyć drewno i rozdzielić pracę, ale rozbudź w nich tęsknotę za otwartym, nieskończonym morzem”
Antoine de Saint Exupéry

Podyskutujmy... (8)

Laboratorium

Różności 07/05/2007 · Link

Długi weekend spędziłem na wsi - bez laptopa, bez internetu, bez telefonu komórkowego. Mimo to o wiele więcej wrażeń. Bez codziennego pośpiechu i tysiąca informacji atakujących umysł zaczynają wyostrzać się zaniedbane zmysły: czuć chłód wieczora, powiew wiatru, zapach jeziora, świeżo ściętego drzewa, dymu z ogniska, szorstkość kloców drewna.

W mieście - klimatyzowane, jałowe powietrze o stałej temperaturze, jednaka gładka faktura przedmiotów - klawiatury, kierownicy, sztućców, zabawek w pokoju dziecka. Bezpiecznie, ciepło, komfortowo.

Może prawdziwe życie jest gdzie indziej? A tu jesteśmy tylko w trybach większej maszyny, utrzymywani w sterylnych warunkach, jak bakterie w fabryce jogurtu, byśmy dłużej mogli posłużyć?

Eeee, tylko taka depresja pourlopowa :)

Podyskutujmy... (2)

I started my own blog...

Różności 27/04/2007 · Link

Niektórzy dopiero zaczynają a ja już działam od ponad roku.

Z pozdrowieniami dla wszystkich czytelników i kolegów piszących blogi!

Podyskutujmy... (1)

Podyskutujmy o projektach informatycznych

Sprawy organizacyjne 19/04/2007 · Link

Startujemy z nową inicjatywą - forum dyskusyjnym.

Założenia

Serwis rafalowicz.pl ma służyć dzieleniu się wiedzą i wypracowywaniu pomysłów na to jak lepiej tworzyć oprogramowanie. Ale dobre pomysły rodzą się pomiędzy ludźmi i w związku z tym chciałbym oddać Wam tutaj miejsce, gdzie możecie się swobodnie wypowiadać.

W internecie jest mnóstwo miejsc gdzie można się zapytać o to, jak zmienić długość sesji w php, jak zrobić rozwijane menu w css, co to jest bean encyjny lub algorytm Forda-Fulkersona, zresztą google na wszystkie te pytania zna odpowiedź. Niewiele jest natomiast miejsc - zwłaszcza w polskojęzycznej części internetu - gdzie można podyskutować o tym jak ułożyć harmonogram projektu, co zrobić z programistą mającym przerośnięte ego, jak najlepiej negocjować z klientem i jak poradzić sobie z szefem rodem z Dilberta. Spróbujmy uzupełnić tę lukę.

Plan działania

Budujemy platformę na której można dyskutować na dowolny temat związany z:

• programowaniem,
• organizacją zespołów informatycznych,
• planowaniem i prowadzeniem projektów,
• zarządzaniem w informatyce,
• motywowaniem pracowników,
• zapewnieniem jakości,
• planowaniem kariery itp, itd.

Zachęcam do dzielenia się ciekawymi przemyśleniami z Waszej praktyki, jak i zadawanie pytań, na które natykacie się w swojej pracy - wśród czytelników tego serwisu jest sporo osób z dużym doświadczeniem, które z pewnością będą w stanie pomóc radą w wielu przypadkach. Jest to też dla Was szansa nawiązania ciekawych kontaktów zawodowych, które mogą zaowocować w przyszłości.

Kilka uwag

Żeby wypowiadać się na forum nie trzeba zakładać konta. Wpisy nie są też rutynowo moderowane. Proszę Was tylko, by przy wysyłaniu posta przepisać słowa wyświetlone na obrazku, by utrudnić automatyczne spamowanie.

Zastrzegam natomiast, że posty obraźliwe, naruszających prawo lub dobre obyczaje lub zawierające informacje o charakterze reklamowym (w tym linki do serwisów komercyjnych o ile nie mają ewidentnego związku z dyskusją merytoryczną) będą przeze mnie usuwane.

Pisząc post możecie pozostawić swój email. Nie będzie on nigdzie ujawniony, pozwoli natomiast innym użytkownikom skontaktować się z Wami bezpośrednio przy pomocy odpowiedniego formularza (dostępny po kliknięciu na ikonkę koperty przy podpisie). Formularz pozwalający przesłanie takiej prywatnej wiadomości również wymaga przepisania słowa z obrazka, więc nie powinniście obawiać się spamu.

Wątki na forum możecie śledzić korzystając ze strumienia RSS.

Mam nadzieję, że będzie to miejsce sympatycznej i kulturalnej dyskusji, wymiany poglądów, zasięgania opinii, proszenia o pomoc itp. Na początek zaproponowałem kilka tematów do dyskusji, reszta należy do Was. Pozdrawiam serdecznie,

Podyskutujmy... (2)

Najważniejsze 6 list 'najważniejszych 10 rzeczy'

Różności 28/03/2007 · Link

Listy "10 najważniejszych" cieszą się wyjątkową popularnością w internecie, wobec tego ku rozrywce czytelników pozwolę sobie wyjątkowo nie na swój własny wpis, a na przekład z angielskiego, za to aż sześciu (!) list dziesięciu najważniejszych dla programistów spraw, zebranych przez Jeffa Adwooda na jego blogu.

Jerry Weinberg: 10 przykazań nieegoistycznego programowania

1. Zrozum i zaakceptuj, że będziesz popełniał błędy
2. Ty to nie twój kod - nie traktuj problemów personalnie
3. Nie ważne jak dobrze znasz "karate", ktoś inny zna je lepiej - ucz się od innych
4. Nie przepisuj kodu bez konsultacji - pilnuj granicy między poprawianiem a przepisywaniem
5. Traktuj ludzi, którzy wiedzą mniej od ciebie z szacunkiem, poważaniem i cierpliwością
6. Jedyna stała we wszechświecie to ciągła zmiana
7. Prawdzi autorytet pochodzi od wiedzy nie od wysokości stołka
8. Walcz o to w co wierzysz, ale wdzięcznie przyjmuj porażkę
9. Nie bądź "komputerowcem w pokoju" - wyłaniającym się tylko po to by dokupić coca-coli
10. Krytykuj kod nie ludzi - bądź łagodny w stosunku do programisty a nie do programu.

Dare Obasanjo: 10 najważniejszych sygnałów, że twój projekt informatyczny jest skazany na porażkę

1. Zbyt wiele rzeczy próbuje się zrobić w pierwszej wersji
2. Duże uzależnienie od niesprawdzonej technologii
3. Konkurencja z innym wewnętrznym projektem, który jest kurą znoszącą złote jajka lub ma silnych popleczników
4. Zbyt mały zespół
5. "Złożone problemy wymagają skomplikowanych rozwiązań"
6. Schedule Chicken
7. Pełzające wymagania
8. Syndrom drugiego systemmu
9. Brak strategii wydania - jak przejść od demo do produktu
10. Chwytanie za rogi problemu, którego nie wiesz jak rozwiązać

Omar Shahine: 10 najważniejszych wskazówek dla pracujących w Microsofcie (lub gdziekolwiek indziej)

1. Proces nie zastąpi myślenia
2. Wyjdź z biura
3. Używaj swojego produktu (który później będą używać twoi klienci)
4. Napraw to co jest zepsute zamiast narzekać na to, co jest zepsute. Działania przemawiają głośniej niż narzekania.
5. Spraw by trudne problemy wyglądały prosto. Unikaj komplikowania prostych problemów
6. Używaj właściwego narzędzia do komunikacji z innymi
7. Naucz się popełniać błędy
8. Dbaj o prostotę
9. Wnoś wartość każdym działaniem
10. Używaj produktów innych zespołów

Michael McDonough: 10 najważniejszych rzeczy, których nie nauczono mnie w szkole projektowania

1. Talent to jedna trzecia sukcesu
2. 95 procent każdego kreatywnego zajęcia to gówniana robota - pozostałe 5% to 'fun'
3. Jeśli wszystko jest tak samo ważne, to nic nie jest naprawdę ważne
4. Unikaj przekombinowania problemu
5. Zacznij od tego, co wiesz. Potem pozbywaj się niewiadomych
6. Nie trać celu z oczu
7. Kiedy się rozpychasz, możesz łatwo stracić równowagę
8. Dobrymi intencjami piekło jest wybrukowane
9. Na finiszu liczy się tylko rezultat
10. Reszta świata też ma znaczenie - szanuj innych ludzi

Andres Taylor: 10 najważniejszych rzeczy, których nauczyłem się w ciągu 10 lat zawodowego tworzenia oprogramowania

1. Programowanie zorientowane obiektowo jest znacznie trudniejsze niż ci się wydaje
2. Trudnością w tworzeniu oprogramowania jest komunikacja
3. Naucz się odmawiać
4. Jeśli wszystko jest równie ważne, to nic nie jest ważne
5. Unikaj przekombinowania problemu
6. Poznawaj rzeczy dogłębnie, ale nie utknij w szczegółach
7. Zrozum pozostałe elementy machiny wytwarzającej oprogramowanie
8. Twoi koledzy są najlepszymi nauczycielami
9. Koniec końców liczy się stworzone oprogramowanie
10. Niektórzy ludzie to dupki

Steve Yegge: 10 najważniejszych książek

1. Pragmatyczny programista. Od czeladnika do mistrza
2. Refactoring: Improving the Design of Existing Code
3. Wzorce projektowe
4. Concurrent Programming in Java(TM): Design Principles and Pattern (2nd Edition)
5. Wyrażenia regularne
6. The Algorithm Design Manual
7. Język ANSI C
8. The Little Schemer
9. Kompilatory. Reguly, metody i narzędzia
10. WikiWikiWeb

Podyskutujmy...

Czy pompować koła azotem?

Relacje z klientem 27/03/2007 · Link

Praca większości z nas jest pracą usługową na rzecz konkretnego klienta. Klient ten jest dla nas zwykle głównym źródłem problemów. Ale czy pamiętacie jak było, gdy ostatnim razem byliście klientem?

Nadeszła już wiosna, co najłatwiej w dzisiejszych czasach zauważyć po kolejkach w warsztatach samochodowych, gdzie wymienia się opony na letnie. Sam też przyłączyłem się do tego grona i wybrałem się do warsztatu na umówioną dużo wcześniej wizytę.

Przytachałem z piwnicy opony, wcisnąłem do bagażnika samochodu i pojechałem. Warsztat do którego przyjechałem to jedna z tych nowoczesnych stacji szybkiej obsługi umieszczonych przy supermarketach.W warsztacie przywitał mnie sympatyczny pan i po odnalezieniu mnie na liście zaczął spisywać zamówienie. I tu czekało mnie kilka niespodzianek.

Zaproponowano mi wymianę zaworków. Pierwszy raz w życiu o tym słyszę (przyznaję - nie znam się na samochodach) - dopytuję się więc. Według obsługującego mnie sprzedawcy trzeba to robić raz na rok. Ups, mam kilkuletnią zaległość, wobec tego zamawiam. Następne pytanie - pompujemy powietrzem czy azotem? Ups, znowu nowość. Dopytuję się więc o różnice. Azot ma podobno lepsze właściwości. Guma się wolniej zużywa a poza tym ciśnienie mniej się zmienia przy zmianie temperatur. Tu zapala się światełko alarmowe - zużycie, hmmm... no może, ale przecież ciśnienie jest chyba niezależnie od rodzaju gazu (p=nRT/V). Biorę powietrze (za darmo).

Ale najciekawsze przede mną. Podczas wymiany mechanik uznaje moje letnie opony za sparciałe i proponuje zakup nowych. Zakup w przywarsztatowym sklepie - sześćset złotych. Pewnie bym się złamał, gdyby nie ten azot. Czujność się we mnie wzmogła - szybko konsultuję się telefonicznie i decyduję się na pozostanie przy moich starych letnich oponach.

Ale mechanik też nie jest miękki - odmawia wymiany! Twierdzi, że on ich nie wymieni, bo na takich oponach nie powinno się jeździć. Na prośbę o wyjaśnienie mówi, że on jest mechanikiem, na oponach się zna i że powinienem je zmienić. Ponieważ z natury jestem przekorny, więc też się uparłem. Do rozstrzygnięcia potrzebny był kierownik, który w ostateczności zgodził się na mój wariant, dając jednak wyraz swojemu niezadowoleniu.

Wyszedłem z poczuciem zniechęcenia i niesmaku. Po pierwsze czułem, że nie przedstawiono mi spraw rzetelnie. Oczekiwałbym wyczerpujących, wiarygodnych i prosto przedstawionych wyjaśnień, a tu od razu namawiano mnie na konkretne rozwiązanie. Co więcej w ogóle nie szanowano mojego zdania. To mój samochód, moje opony i moje bezpieczeństwo! Nawet jeśli znam się od mechanika gorzej, to ja chcę podjąć decyzję! Chętnie przyjmę rekomendację, ale za bezczelność uważam dezaprobatę ze strony mechanika w stosunku do mojego wyboru!

Klient w kontakcie z informatykiem jest w znacznie trudniejszej sytuacji niż kierowca z mechanikiem samochodowym. Często rozmowa dotyczy rzeczy, które dla programisty wydają się proste, oczywiste, jasne, natomiast dla klienta są trudne i bardzo abstrakcyjne. Klient znajduje się wtedy w bardzo niekomfortowej sytuacji: nie wie czego naprawdę potrzebuje (na cholerę mi ten azot?) i nie jest w stanie samodzielnie ocenić sytuacji (czy na pewno te opony są zużyte?). Ma poczucie tracenia kontroli, mimo tego, że to jego projekt, jego produkt, jego pieniądze. Szybko wyczuwa zniecierpliwienie programisty i odbiera to jako brak szacunku. Kończy się to niechęcią do informatyków, ograniczaniem kontaktów, brakiem zaufania.

Jak można najlepiej pomóc naszemu klientowi? No cóż - a czego oczekujemy od naszego mechanika?

Bezpiecznie jest działać według takiego ramowego scenariusza:

1. Przedstawienie możliwych opcji
2. Opisanie (zrozumiałym językiem!) ich zalet i wad
3. Przedstawienie rekomendacji ("Będąc na Pana miejscu zrobiłbym...")
4. Pozostawienia decyzji klientowi ("Ale to Twój projekt drogi kliencie, więc jaka jest Twoja decyzja?")

Podkreślam ten ostatni punkt, bo stanowił on zawsze spory dylemat dla mnie. Nie raz byłem w sytuacji, gdy miałem pewność, które rozwiązanie jest dla klienta jest najlepsze i w dobrej wierze namawiałem klienta do niego. Gdy nie udawało mi się go dobrze uzasadnić, to prowadziło to do szarpaniny, nadwyrężenia zaufania i jeszcze większych problemów przy następnej decyzji. Gdybym mógł wrócić do tamtych sytuacji, nie miałbym wątpliwości: lepiej byłoby, gdybym zaakceptował decyzję klienta nawet wtedy, gdy była ona sprzeczna z moim najgłębszym przekonaniem.

Zwłaszcza, że nie zawsze moje najgłębsze przekonanie okazywało się na koniec dnia słuszne :)

Pytania do Was:

1. Czy o profesjonalizmie świadczy twarde walczenie o najlepsze dla klienta rozwiązanie czy budowanie długofalowej relacji, nawet kosztem pojedynczych nieoptymalnych decyzji?
2. Jak zachować się w sytuacji gdy ewidentnie mamy przekonanie, że klient skłania się ku niewłaściwej decyzji?
3. Jak zachować się w sytuacji, gdy opcja najkorzystniejsza dla klienta jest sprzeczna z naszym interesem? Zwłaszcza gdy nie jesteśmy właścicielem firmy - jak godzić lojalność względem klienta i pracodawcy?
4. Jakie są Wasze doświadczenia z mechanikami? Hydraulikami? Dentystami? Lekarzami?

Podyskutujmy... (11)