Climbus Blog

Warto wspomnieć, że ludzie od Pylonsa jakiś czas temu uruchomili projekt zbierający dokumentację na temat różnych frameworków webowych napisanych w Pythonie. Jest to kolejny dowód na to, że Pylons wyróżnia się chęcią integracji różnych rozwiązań. Nie skupia się na samym sobie lecz stara się pomóc we wspólnym rozwoju tzw “web pythona”.

Na razie większość artykułów odnosi się do Pylonsa ale można liczyć, że w niedalekiej przyszłości pojawią się teksty o TurboGears, Paste itp.

Zachęcam do odwiedzania: http://docs.pythonweb.org/.

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… :-)