październik roku pamiętnego 2009, prawdopodobnie 26. Wielka mądrość na
czytelników pl.comp.www,pl.comp.lang.php spłynęła, gdy tako rzekł(a)
pakalk:

> To to wiem - ale czemu klient ma byc projektem, a nie userem?

Tam było założenie że klienci nie mogą wiedzieć o sobie nawzajem.
Prawdopodobnie (nie wiem, nigdy Mantisa na oczy nie widziałem) jeżeli
każdy klient będzie userem i projektem, to user B będzie widział
projekt B, ale nie będzie wiedział o istnieniu projektów A, C, D i E.
--
Niżej podpisany, zamieszkały w http://minio.xt.pl ,
Mirosław Zalewski

do góry

>Tam było założenie że klienci nie mogą wiedzieć o sobie nawzajem.
>Prawdopodobnie (nie wiem, nigdy Mantisa na oczy nie widziałem) jeżeli
>każdy klient będzie userem i projektem, to user B będzie widział
>projekt B, ale nie będzie wiedział o istnieniu projektów A, C, D i E.

Dobrze się domyślasz. Użytkownik "programista_Tomek" będzie miał rolę
wykonawcy we wszystkich projektach. Uzytkownik
"Jan_Kowalski_reprezentujący_firmę_X" będzie zaś "zgłaszającym" dla projektu
"witryny firmy X".

do góry

On Oct 26, 12:20 pm, "William Bonawentura" <n...@i...pl> wrote:
> >Tam było założenie że klienci nie mogą wiedzieć o sobie nawzajem.
> >Prawdopodobnie (nie wiem, nigdy Mantisa na oczy nie widziałem) jeżeli
> >każdy klient będzie userem i projektem, to user B będzie widział
> >projekt B, ale nie będzie wiedział o istnieniu projektów A, C, D i E.
>
> Dobrze się domyślasz. Użytkownik "programista_Tomek" będzie miał rolę
> wykonawcy we wszystkich projektach. Uzytkownik
> "Jan_Kowalski_reprezentujący_firmę_X" będzie zaś "zgłaszającym" dla projektu
> "witryny firmy X".

No ok, ale to sa userzy z uprawnieniami do projektow, a nie
projekty :P Ok - tak to rozumiem ;)

do góry

** fv <f...@c...com> wrote:

>> Poza tym nie możesz liczyć na to, że klient je sensownie wypełni - np.
>> załączy Ci złe pliki, niekompletny opis, ustawi priorytet na "NA
>> WCZORAJ!!!!!111", błędnie skategoryzuje, a całe zgłoszenie i tak będzie
>> dotyczyć czegoś na realizację czego w ogóle nigdy się nie zgadzałeś. Itd.

> I tutaj zmierzamy w ważnym kierunku, mianowicie zwiększania opłat za obsługę
> i trzeźwej eliminacji klientów, z którymi nie opłaca się pracować ;>

Oczywiście tak. Tzn. może nie tak drastycznie - należy podejść w sposób "my
wszystko zrobimy bo dla nas nie ma problemów ALE to będzie kosztowało
dodatkowo". Tak czy inaczej (no bo przecież skoro klient jest skłonny zapłacić
za komfort, w którym nie musi wypełniać formatek to czemu mamy się go pozbywać)
należy sobie zorganizować tzw. linie wsparcia, tzn. kogoś kto będzie różne
zamiary korygował, ukracał bez angażowania nas samych w te pierdoły. :)

W końcu programista nie jest od tego aby się zajmował obsługą klienta.

> Mając system bugtrackingowy (ja uwielbiam Jirę, ale ten Flyspray wygląda
> bardzo ciekawie jak na darmowy)

Jira jest faktycznie OK. Jak w ogóle produkty Atlassiana.

> można próbować umawiać się z klientem na ryczałtową opłatę miesięczną za
> załatwianie spraw. Opłata zależna od czasu reakcji ;-)

No typowa sensowna umowa dla nietrywialnego projektu definiuje zasady
współpracy, ale obawiam się, że kolega pytający nie ma jeszcze wypracowanych
takich nawyków pracowania zgodnie z umową. To raczej jest spotykane w większych
projektach gdzie pracuje więcej podmiotów (i każdemu z nich należy zapłacić za
byle pierdnięcie).

> Z moich doświadczeń wynika, że jeśli klient nie potrafi napisać o co mu
> chodzi, to ma jeszcze większy kłopot z zapłaceniem za wykonaną pracę.

99% ludzi zamawiających stronki nie ma pojęcia czego chce. Niestety. :)

> Co innego jeśli klient zmieni zdanie w czasie projektu

Wtedy się spisuje protokół różnic i dodatkowo wykonaną pracę wycenia dodatkowo.
To jest oczywiste niestety nie dla wszystkich.

(...)

> Pozwalając aby klienci traktowali nas jak niewolników a nie partnerów,
> dostajemy też niewolnicze stawki i warunki pracy. Pomyślcie o tym ;-)

Ta, ale aby sobie na to nie pozwolić to trzeba spisać stosowną umowę.

--
+ ' .-. .
, * ) )
http://kosmosik.net/ . . '-' . kK

do góry

Konrad Kosmowski pisze:
> ** fv <f...@c...com> wrote:
>
>>> Poza tym nie możesz liczyć na to, że klient je sensownie wypełni - np.
>>> załączy Ci złe pliki, niekompletny opis, ustawi priorytet na "NA
>>> WCZORAJ!!!!!111", błędnie skategoryzuje, a całe zgłoszenie i tak będzie
>>> dotyczyć czegoś na realizację czego w ogóle nigdy się nie zgadzałeś. Itd.
>
>> I tutaj zmierzamy w ważnym kierunku, mianowicie zwiększania opłat za obsługę
>> i trzeźwej eliminacji klientów, z którymi nie opłaca się pracować ;>
>
> Oczywiście tak. Tzn. może nie tak drastycznie - należy podejść w sposób "my
> wszystko zrobimy bo dla nas nie ma problemów ALE to będzie kosztowało
> dodatkowo". Tak czy inaczej (no bo przecież skoro klient jest skłonny zapłacić
> za komfort, w którym nie musi wypełniać formatek to czemu mamy się go pozbywać)
> należy sobie zorganizować tzw. linie wsparcia, tzn. kogoś kto będzie różne
> zamiary korygował, ukracał bez angażowania nas samych w te pierdoły. :)

> W końcu programista nie jest od tego aby się zajmował obsługą klienta.

IMHO to zależy od wielkości firmy. W większych firmach są do tego
odpowiednie działy, w mniejszych z reguły nie ma. W każdym razie
programista nie jest tym, który jest na "pierwszej linii ognia", ale
IMHO powinien znać, mimo wszystko, co najmniej podstawowe zasady obsługi
klienta. Na pewno mu to nie zaszkodzi.

>> można próbować umawiać się z klientem na ryczałtową opłatę miesięczną za
>> załatwianie spraw. Opłata zależna od czasu reakcji ;-)
>
> No typowa sensowna umowa dla nietrywialnego projektu definiuje zasady
> współpracy, ale obawiam się, że kolega pytający nie ma jeszcze wypracowanych
> takich nawyków pracowania zgodnie z umową. To raczej jest spotykane w większych
> projektach gdzie pracuje więcej podmiotów (i każdemu z nich należy zapłacić za
> byle pierdnięcie).

Umowy tego typu dotyczyć powinny każdego projektu, bez względu na
wielkość projektu. Spotykałem się z takimi umowami, w których był punkt
mówiący o tym, że jeśli nakład pracy jest znaczny, to klient będzie miał
to zgłaszane, po czym następuje wycena i ewentualna akceptacja, bądź nie
akceptacja prac do wykonania.

Rzecz jasna, nakład pracy oceniany jest przez wykonawcę. To daje pewien
"wentyl bezpieczeństwa", aby nie robić w nieskończoność projektu.

>> Z moich doświadczeń wynika, że jeśli klient nie potrafi napisać o co mu
>> chodzi, to ma jeszcze większy kłopot z zapłaceniem za wykonaną pracę.
>
> 99% ludzi zamawiających stronki nie ma pojęcia czego chce. Niestety. :)

Ale wie, czego nie chce :-)

--
Peter

do góry

Peter wrote:
> IMHO to zależy od wielkości firmy. W większych firmach są do tego
> odpowiednie działy, w mniejszych z reguły nie ma. W każdym razie
> programista nie jest tym, który jest na "pierwszej linii ognia", ale
> IMHO powinien znać, mimo wszystko, co najmniej podstawowe zasady obsługi
> klienta. Na pewno mu to nie zaszkodzi.

Sama wiedza mu nie zaszkodzi, ale kontakt z klientem już na pewno :P

do góry

Paweł Piskorz pisze:
> Peter wrote:
>> IMHO to zależy od wielkości firmy. W większych firmach są do tego
>> odpowiednie działy, w mniejszych z reguły nie ma. W każdym razie
>> programista nie jest tym, który jest na "pierwszej linii ognia", ale
>> IMHO powinien znać, mimo wszystko, co najmniej podstawowe zasady obsługi
>> klienta. Na pewno mu to nie zaszkodzi.
>
> Sama wiedza mu nie zaszkodzi, ale kontakt z klientem już na pewno :P

Kontakt z klientem jest czasem jednak potrzebny. Dlatego uważam, że
powinien jednak szkolić się z co najmniej podstawowego zakresu obsługi
klienta. Może się okazać, że przez wysłanie "głupiego majla" zepsuje
kontrakt :-( :P

--
Peter

do góry