fbpx

Klient, który wie, czego chce

4 komentarze

  1. Lukasz pisze:

    Ciekawy wywód, fajne spojrzenie na pracę u podstaw z klientem.

  2. kretes pisze:

    Jeśli już analityk myśli obiektowo, to dobrze, wszak wtedy łatwiej wykryć różnego rodzaju ułatwienia myślenia, które stosuje klient, a które nie są poprawnym przełożeniem jego dziedziny na obiektowe struktury.

    I jeszcze ten cytat:
    „czasem okazuje się, że poprawa komfortu pracy o 5% nie jest warta wysiłku programistów „

    Hmm.. ale to nie jest takie proste, że się mówi po prostu ‚nie, tego nie zrobimy :)’ – tłumaczenie się zawiłością rozwiązania też chyba nie jest takie proste. W jaki sposób to osiągasz?

    Racjonalny Developer

  3. Staram się skłonić klienta do przeanalizowania konsekwencji żądanej funkcjonalności, jej wpływu na inne elementy systemu. Czasem dochodzi on do wniosku, że rzeczywiście nie ma sensu czegoś robić. Jeśli się upiera i wtedy przedstawiam szacowania i kosztorys i proszę o wybranie co jest najważniejsze przy ustalonym budżecie (można zasugerować dodatkowa funkcjonalność spowoduje, że cena wykonania może wzrosnąć albo czas się wydłuży). Czasem jednak umowa już podpisana, klient się upiera (a jest to kluczowy klient), wtedy nie ma rady – robimy:)

  4. jkotor pisze:

    Co do praktyk, które opisujesz: do punktu 2 istnieje całkiem zmyślne narzędzie u konkurencji (ćwiczyłem to rok temu ze studentami)
    http://www.microsoft.com/expression/products/sketchflow_overview.aspx