Podejście do userów
Programowanie to prosta sprawa :-) Gorzej jest z komunikacją z użytkownikami. Pomijam tu kwestię tłumaczenia wymagań i oczekiwań na postać bardziej precyzyjną, technicznie możliwą do wykonania. Obecnie skupiam się bardziej na kwestii przyjmowania zleceń i poprawek. Bardzo mnie zastanawia jakie są granice godzenia się na pomysły i terminy wykonania proponowane przez użytkowników. Kiedy można się zgodzić na daną poprawkę a kiedy należy odmówić.
Jedna zasada jest prosta. Jeżeli coś obiecasz użytkownikowi musisz to wykonać w terminie. Żeby się nawet waliło musisz to zrobić bo dałeś słowo. Dlatego obiecywać trzeba z umiarem. Tylko jak znaleźć ten umiar. Jeżeli będziesz odmawiał zbyt często użytkownicy będą równie źli jak wtedy gdy coś obiecasz i nie zrobisz. A może nawet bardziej.
W swojej praktyce spotkałem różnych programistów. Często stosują prostą kolejkę FIFO. Pierwsze przyszło robię to i jak skończę to biorę następne. Śmieszniej jest jak programista stosuje kolejkę LIFO. Robi coś a gdy zadzwoni ktoś z jakimś problemem zostawia to co robił i zajmuje się kolejną sprawą. Potem kolejny telefon i sytuacja się powtarza. O problemy przy takim rozwiązaniu nie trudno. Tacy programiści powinni mieć nad sobą dyspozytora, który przydzieli im zadania i sprawdzi ich wykonanie. Czasami odłoży jedno zadanie i wpuści na chwilę inne.
Dyspozytor (np. team leader) lub samodzielny programista ma trudne zadanie. Musi mocno się namęczyć aby znaleźć złoty środek. Kiedy coś przyjąć, kiedy coś odłożyć a kiedy odmówić. Zależy to nie tylko od rodzaju projektu ale też od rodzaju użytkownika (wewnętrzny, zewnętrzny) a nawet od charakteru człowieka z którym ma do czynienia.
Pracowałem z użytkownikami wewnętrznymi oraz z zewnętrznymi i są to różne relacje. ciężko stwierdzić co jest lepsze, ciekawsze. Na pewno jest to inna współpraca i zachowania muszą być różne.
Tak więc poszukuję teraz odpowiedniego podejścia do użytkowników. Kawał pracy przede mną.
Przecież chodzi o to aby wszyscy byli zadowoleni… :-)