On 15/01/2013 22:28, Gotfryd Smolik news wrote:
> Ja tak z pozoru offtopicznie:
>
> On Thu, 27 Dec 2012, boryspower wrote:
>
>> Przykład: Stworzenie aplikacji do fakturowania
>
> 1. Przeczytać ustawę o VAT i stwierdzić że nic się z tego nie rozumie
> 2. Spytać "fachowca" jak ma być
> 3. Stwierdzić że coś nie pasuje
> 4. Sprawdzić to i owo w internecie
> 5. powtórzyć 1. i stwierdzić że "fachowiec" był niedouczony ;)

Oczywiście może się tak zdarzyć, ale w takiej sytuacji błąd był
wcześniej, już na etapie rekrutacji i twoim problemem nie jest jak
tworzyć oprogramowanie, tylko jak znaleźć douczonych fachowców.

W ogólnym przypadku założenie, że inżynier oprogramowania po
przeczytaniu ustawy i sprawdzeniu tego i owego w internecie będzie
mądrzejszy od fachowca jest dość ryzykowne.

> Potem można zabrać się za rozważania jak program ma działać.
>
> Nie, *NIE* żartuję - wziąłeś doskonały przykład, niemal wzorcowy,
> na to jak można wtopić na błędach założeń :)
> Policzenie choćby tylko VAT (a niekoniecznie jest to jedyny
> podatek który musi być ujawniany na dokumencie) jest dopuszczalne
> na wiele sposobów, w tym takich trudniejszych do wymyślenia,
> ale *niekiedy* napotyka na ograniczenia (trzeba zastosować
> się do któregoś spośród tych wielu)

Oczywiście z druiej strony założenie, że fachowiec usiądzie i napisze od
ręki specyfikację, w której będzie wszystko, co potrzeba. Raczej trzeba
się nastawić na to, że fachowiec powie jak ma być, proramista napisze
program, który to właśnie robi, potem fachowiec powie, że może być
jeszcze inaczej, i programista to zaimplementuje, potem fachowiec powie,
że tak, jak mówił na początku, że ma być, to nie może być jak cośtam itd.

> i wtedy na .podatki pojawia
> post w kategorii "a u głupka kontrahenta nie chcą poprawić f-ry
> bo twierdzą że system nie pozwala" :P
>
> Nie, nie mam na myśli stawki itede :)
>
> Obstawiam że takich przypadków jest sporo - coś co wydaje się
> proste zawiera pułapki które później trudno usunąć.

Natomiast inżynier oprogramowania powinien wiedzieć jak robić programy,
z których dowolne pułapki można łatwo usunąć.

> Taka aplikacja, dobrze zrobiona ale mająca działać bez wsparcia
> "24h na dobę czas dostarczania poprawki 2h" ;) np. powinna
> umożliwiać wpisanie dokumentu w 100% ręcznie lub ręczne
> poprawienie wszystkich pól, bo nie sposób przewidzieć która
> z kombinacji "metod" może wyskoczyć.
> Uczciwie - przewidziałbyś?

Uczciwie jest tak: albo świadczysz usługę "mówicie nam co program ma
robić, a my dostarczamy program, który robi właśnie to", albo usługę
"nasi analitycy analizują wasze potrzeby i powiedzą wam, co program
powinien robić i jak, a wy się zgodzicie albo nie".

Uczciwe świadczenie tej drugiej usługi, zwłaszcza w opcji "24h bez
wsparcia, poprawki w 2h" wymaga odpowiedniej kombinacji doświadczenia i
zatrudnienia kompetentnych analityków, co pozwoli ci to przewidzieć.

>> - jak przygotować dokumentację/opis projektu
>
> Tak żeby był tam zapis "zgodnie z przepisami", co daje do ręki
> narzędzie do doprowadzenia wykonawcy do rozpaczy ;)
> (patrz p.1 :), polecam osobiście zajrzeć do treści)

Jeśli bierzesz na siebie takie zobowiązanie, to musisz zatrudnić
analityka (czy nawet kilku), który powie ci, co jest zgodne, a co
niezgodne z przepisami i to ostatecznie trafia do specyfikacji. Jeśli
nie chcesz wziąć na siebie tego ryzyka, to szukasz klienta, który sam ma
księgowych, prawników czy kogo tam, którzy określą zgodność z przepisami.

do góry

Gotfryd Smolik news <s...@s...com.pl> wrote:
> Ja tak z pozoru offtopicznie:
>
> On Thu, 27 Dec 2012, boryspower wrote:
>
>> Przykład: Stworzenie aplikacji do fakturowania
>
> 1. Przeczytać ustawę o VAT i stwierdzić że nic się z tego nie rozumie
> 2. Spytać "fachowca" jak ma być
> 3. Stwierdzić że coś nie pasuje
> 4. Sprawdzić to i owo w internecie
> 5. powtórzyć 1. i stwierdzić że "fachowiec" był niedouczony ;)

Skąś to znam. W pewnej dużej firmie tylko ja miałem i znałem komplet jej
wewnętrznych przepisów ;)

do góry

W dniu 2013-01-16 08:51, Andrzej Jarzabek pisze:
> On 15/01/2013 22:28, Gotfryd Smolik news wrote:
>> Ja tak z pozoru offtopicznie:
>>
>> On Thu, 27 Dec 2012, boryspower wrote:
>>
>>> Przykład: Stworzenie aplikacji do fakturowania
>>
>> 1. Przeczytać ustawę o VAT i stwierdzić że nic się z tego nie rozumie
>> 2. Spytać "fachowca" jak ma być
>> 3. Stwierdzić że coś nie pasuje
>> 4. Sprawdzić to i owo w internecie
>> 5. powtórzyć 1. i stwierdzić że "fachowiec" był niedouczony ;)
>
> Oczywiście może się tak zdarzyć, ale w takiej sytuacji błąd był
> wcześniej, już na etapie rekrutacji i twoim problemem nie jest jak
> tworzyć oprogramowanie, tylko jak znaleźć douczonych fachowców.
>

Tylko co jak takich fachowców nie ma lub nie da się sprawdzić czy są
douczeni, bo dziedzina jest nowa. Naiwnością jest myślenie że znajdę
dobrego fachowca i zrobi mi dobrze. Żeby wybrać tego douczonego muszę
mieć szczęście albo samemu się douczyć.



> W ogólnym przypadku założenie, że inżynier oprogramowania po
> przeczytaniu ustawy i sprawdzeniu tego i owego w internecie będzie
> mądrzejszy od fachowca jest dość ryzykowne.
>

W drugą stronę również. Ale razem mają większe kompetencje niż każdy z
osobna, należy to "tylko" wykorzystać.

>> Potem można zabrać się za rozważania jak program ma działać.
>>
>> Nie, *NIE* żartuję - wziąłeś doskonały przykład, niemal wzorcowy,
>> na to jak można wtopić na błędach założeń :)
>> Policzenie choćby tylko VAT (a niekoniecznie jest to jedyny
>> podatek który musi być ujawniany na dokumencie) jest dopuszczalne
>> na wiele sposobów, w tym takich trudniejszych do wymyślenia,
>> ale *niekiedy* napotyka na ograniczenia (trzeba zastosować
>> się do któregoś spośród tych wielu)
>
> Oczywiście z druiej strony założenie, że fachowiec usiądzie i napisze od
> ręki specyfikację, w której będzie wszystko, co potrzeba. Raczej trzeba
> się nastawić na to, że fachowiec powie jak ma być, proramista napisze
> program, który to właśnie robi, potem fachowiec powie, że może być
> jeszcze inaczej, i programista to zaimplementuje, potem fachowiec powie,
> że tak, jak mówił na początku, że ma być, to nie może być jak cośtam itd.
>
>> i wtedy na .podatki pojawia
>> post w kategorii "a u głupka kontrahenta nie chcą poprawić f-ry
>> bo twierdzą że system nie pozwala" :P
>>
>> Nie, nie mam na myśli stawki itede :)
>>
>> Obstawiam że takich przypadków jest sporo - coś co wydaje się
>> proste zawiera pułapki które później trudno usunąć.
>
> Natomiast inżynier oprogramowania powinien wiedzieć jak robić programy,
> z których dowolne pułapki można łatwo usunąć.

Dowolne i łatwo: to chyba nie inżynier. To jest słownictwo menadżera.
Oczywiście w zależności od projektu konkretne pułapki można taniej lub
drożej likwidować/omijać. Ale może też należało by oszacować ryzyko
awarii i potencjalne koszty i wdrożyć zabezpieczenia niekoniecznie
programistyczne. Tylko prawnicy i matematycy mogą skutecznie twierdzić
że wszystko można na 100% przewidzieć.

>
>> Taka aplikacja, dobrze zrobiona ale mająca działać bez wsparcia
>> "24h na dobę czas dostarczania poprawki 2h" ;) np. powinna
>> umożliwiać wpisanie dokumentu w 100% ręcznie lub ręczne
>> poprawienie wszystkich pól, bo nie sposób przewidzieć która
>> z kombinacji "metod" może wyskoczyć.
>> Uczciwie - przewidziałbyś?
>
> Uczciwie jest tak: albo świadczysz usługę "mówicie nam co program ma
> robić, a my dostarczamy program, który robi właśnie to", albo usługę
> "nasi analitycy analizują wasze potrzeby i powiedzą wam, co program
> powinien robić i jak, a wy się zgodzicie albo nie".
>

Jeżeli zamawiający potrafi samodzielnie wykonać usługę ale chce ją
taniej to wybierze wariant pierwszy. Jeżeli nie zależy na efekcie (np
decyzja została narzucona , chce pogrążyć wykonawcę itd) to wybierze
wariant drugi.
Jeżeli usługa jest nietrywialna i istotna dla obu stron to uczciwie
będzie współpracować. Wykonujący i zamawiający wzajemnie nabywają od
siebie nowych kompetencji. Ryzyko też powinno być podzielone, ale nie
wiem czy równo, solidarnie czy uczciwie?


> Uczciwe świadczenie tej drugiej usługi, zwłaszcza w opcji "24h bez
> wsparcia, poprawki w 2h" wymaga odpowiedniej kombinacji doświadczenia i
> zatrudnienia kompetentnych analityków, co pozwoli ci to przewidzieć.
>

Jak masz kompetencje to właściwie oszacujesz ryzyko i koszty, jeżeli nie
to to jest hazard i albo się uda albo nie.



>>> - jak przygotować dokumentację/opis projektu
>>
>> Tak żeby był tam zapis "zgodnie z przepisami", co daje do ręki
>> narzędzie do doprowadzenia wykonawcy do rozpaczy ;)
>> (patrz p.1 :), polecam osobiście zajrzeć do treści)
>
> Jeśli bierzesz na siebie takie zobowiązanie, to musisz zatrudnić
> analityka (czy nawet kilku), który powie ci, co jest zgodne, a co
> niezgodne z przepisami i to ostatecznie trafia do specyfikacji. Jeśli
> nie chcesz wziąć na siebie tego ryzyka, to szukasz klienta, który sam ma
> księgowych, prawników czy kogo tam, którzy określą zgodność z przepisami.
>

A skąd ten analityk ma niby wiedzieć to jest zgodne a co nie jak tego
nie wiedzą sami twórcy ustawy. To dopiero wiadomo po jakimś czasie jak
pojawią się orzeczenia, praktyka. A program musi być tworzony tu i teraz.

Rozwiązaniem jest współpraca wszystkich stron: klienta, analityków
programistów. Tyle że nie taka jak się zazwyczaj słyszy: klienta: że coś
jest niedoprecyzowane (przecież pisze "zgodnie z przepisami"), analityka
że ktoś czegoś nie przedstawił (nikt nie mówił o takim przypadku),
programistę ("ja nie znam się na przepisach"). Nie powinno być ostrego
podziału kompetencji kiedy każde naruszenie granic jest zamachem na
niezależność. Jak każdy weźmie fragment odpowiedzialności za cudze błędy
to może nie powstanie "ziemia niczyja" kiedy projekt pada lecz nikt nie
ma wyrzutów sumienia.


--
Darek

do góry

On 17/01/2013 17:12, darekm wrote:
> W dniu 2013-01-16 08:51, Andrzej Jarzabek pisze:
>> On 15/01/2013 22:28, Gotfryd Smolik news wrote:
>>> Ja tak z pozoru offtopicznie:
>>>
>>> On Thu, 27 Dec 2012, boryspower wrote:
>>>
>>>> Przykład: Stworzenie aplikacji do fakturowania
[...]
>> Oczywiście może się tak zdarzyć, ale w takiej sytuacji błąd był
>> wcześniej, już na etapie rekrutacji i twoim problemem nie jest jak
>> tworzyć oprogramowanie, tylko jak znaleźć douczonych fachowców.
>
> Tylko co jak takich fachowców nie ma lub nie da się sprawdzić czy są
> douczeni, bo dziedzina jest nowa.

No faktycznie, wystawianie faktur o coś, co wymyślili wczoraj.

> Naiwnością jest myślenie że znajdę
> dobrego fachowca i zrobi mi dobrze. Żeby wybrać tego douczonego muszę
> mieć szczęście albo samemu się douczyć.

Naiwnością jest myślenie, że jak nie potrafisz znaleźć fachowców, to
będziesz potrafił się sam nauczyć na tyle, żeby stworzyć poprawnie
działający program - tym bardziej na podstawie takiego myślenia dawanie
klientom jakichkolwiek gwarancji.

>> W ogólnym przypadku założenie, że inżynier oprogramowania po
>> przeczytaniu ustawy i sprawdzeniu tego i owego w internecie będzie
>> mądrzejszy od fachowca jest dość ryzykowne.
>
> W drugą stronę również. Ale razem mają większe kompetencje niż każdy z
> osobna, należy to "tylko" wykorzystać.

Na pewno dobrze jest, jeśli programista może się dopytać czy podzielić
wątpliwościami, ale założenie, że wyłapie błędy analityka jest, jak
pisałem, ryzykowne. Z drugiej strony jeśli ma tracić czas na czytanie
ustaw, to IMO lepiej, żeby przeczytał sobie książkę o ATDD albo nauczył
się jakiegoś narzędzia typu FitNesse albo Cucumber.

>>> Obstawiam że takich przypadków jest sporo - coś co wydaje się
>>> proste zawiera pułapki które później trudno usunąć.
>>
>> Natomiast inżynier oprogramowania powinien wiedzieć jak robić programy,
>> z których dowolne pułapki można łatwo usunąć.
>
> Dowolne i łatwo: to chyba nie inżynier. To jest słownictwo menadżera.
> Oczywiście w zależności od projektu konkretne pułapki można taniej lub
> drożej likwidować/omijać. Ale może też należało by oszacować ryzyko
> awarii i potencjalne koszty i wdrożyć zabezpieczenia niekoniecznie
> programistyczne. Tylko prawnicy i matematycy mogą skutecznie twierdzić
> że wszystko można na 100% przewidzieć.

Nic mi nie wiadomo o prawnikach ani matematykach, ale w praktyce
tworzenia oprogramowania nie ma znaczenia, czy absolutnie zawsze łatwo,
tylko właśnie ryzyko.

>> Uczciwie jest tak: albo świadczysz usługę "mówicie nam co program ma
>> robić, a my dostarczamy program, który robi właśnie to", albo usługę
>> "nasi analitycy analizują wasze potrzeby i powiedzą wam, co program
>> powinien robić i jak, a wy się zgodzicie albo nie".
>
> Jeżeli zamawiający potrafi samodzielnie wykonać usługę ale chce ją
> taniej to wybierze wariant pierwszy. Jeżeli nie zależy na efekcie (np
> decyzja została narzucona , chce pogrążyć wykonawcę itd) to wybierze
> wariant drugi.

Rzeczywistość jest raczej trochę bardziej skomplikowana. Po pierwsze -
druga opcja będzie zwykle droższa. Po drugie istotne jest, dlaczego
klient w ogóle zamiawia oprogramowanie, skoro do tej pory nie miał
funkcjonował. Bywa tak, że związane jest to ze zmianą potrzeb czy
sytuacji, i może być tak, że zamiawiający nie ma dobrego rozeznania w
tej noowej sytuacji - więc bardziej mu się np. opłaci zamówić
oprogramowanie z analizą, niż samemu zatrudniać analityków.

Z drugiej strony między umiejętnością wystawiania faktur a umiejętnością
stworzenia oprogramowania do wystawiania faktur też jest raczej przepaść.

> Jeżeli usługa jest nietrywialna i istotna dla obu stron to uczciwie
> będzie współpracować. Wykonujący i zamawiający wzajemnie nabywają od
> siebie nowych kompetencji. Ryzyko też powinno być podzielone, ale nie
> wiem czy równo, solidarnie czy uczciwie?

Oczywiście, że współpraca jest jak najbardziej pożądana, ale dobrze jest
też mieć wspólne rozumienie tego, co jest sprzedawane i kto za co
odpowiada. A może nawet jest to w umowie.

>> Uczciwe świadczenie tej drugiej usługi, zwłaszcza w opcji "24h bez
>> wsparcia, poprawki w 2h" wymaga odpowiedniej kombinacji doświadczenia i
>> zatrudnienia kompetentnych analityków, co pozwoli ci to przewidzieć.
>
> Jak masz kompetencje to właściwie oszacujesz ryzyko i koszty, jeżeli nie
> to to jest hazard i albo się uda albo nie.

Jak właściwie oszacujesz ryzyko i koszty, to też jest hazard i albo się
uda, albo nie. Na tym właśnie polega ryzyko.

>> Jeśli bierzesz na siebie takie zobowiązanie, to musisz zatrudnić
>> analityka (czy nawet kilku), który powie ci, co jest zgodne, a co
>> niezgodne z przepisami i to ostatecznie trafia do specyfikacji. Jeśli
>> nie chcesz wziąć na siebie tego ryzyka, to szukasz klienta, który sam ma
>> księgowych, prawników czy kogo tam, którzy określą zgodność z przepisami.
>
> A skąd ten analityk ma niby wiedzieć to jest zgodne a co nie jak tego
> nie wiedzą sami twórcy ustawy. To dopiero wiadomo po jakimś czasie jak
> pojawią się orzeczenia, praktyka. A program musi być tworzony tu i teraz.
>
> Rozwiązaniem jest współpraca wszystkich stron: klienta, analityków
> programistów.

A jak oni wszyscy mają dojść do tego, co jest zgodne, a co nie, jak tego
nie wiedzą sami twórcy ustawy?

W rzeczywistości przecież jakoś firmy działają, faktury wystawiają i
podatki płacą. W praktyce firma przecież nie wymaga nieomylnego
księgowego czy nieomylnego prawnika, tylko takiego, który wystaczająco
rzadko się myli, jak i potrafi powiedzieć kiedy się jedzie po bandzie. I
tego samego wymagasz od analityka.

Pytanie jednak - jak zwykle - o kasę. Czas analityków, a zwłaszcza
dobrych analityków, kosztuje. Jeśli zamawiający ma księgowego, który wie
wystarczająco dużo o wystawianiu faktur i może poświęcić odpowiednio
dużo czasu na uzgadnianie specyfikacji, to może szukać tańszej opcji
wykonania pod dyktando bez analizy. Bez analizy nie znaczy, że
programiści czy menedżerowie nie będą wypytywać, sugerować, czy
znajdować prawdopodobne dziury w specyfikacji, tylko że jak mimo to
program wystawi fakturę niezgodną z przepisami, to wykonawca będzie mógł
powiedzieć, że program jest zgodny z uzgodnioną specyfikacją, a on tylko
to obiecywał - o niezgodność z przepisami zamawiający może mieć
pretensje do swojego księgowego.

I jeśli ktoś nie potrafi zatrudnić analityków albo odróżnić douczonych
od niedouczonych, to nie powinien prowadzić biznesu polegającego na
usłudze "z analizą" - bo przecież programista może przeczytać ustawę i
poprawić babole niedouczonego analityka.

> Tyle że nie taka jak się zazwyczaj słyszy: klienta: że coś
> jest niedoprecyzowane (przecież pisze "zgodnie z przepisami"), analityka

Jeśli wykonawca zobowiązał się zrobić "zgodne z przepisami", to powinien
mieć analityków od tego. Jeśli nie potrafi takich zatrudnić, nie
powinien się zgadzać na taki zapis.

> że ktoś czegoś nie przedstawił (nikt nie mówił o takim przypadku),
> programistę ("ja nie znam się na przepisach"). Nie powinno być ostrego
> podziału kompetencji kiedy każde naruszenie granic jest zamachem na
> niezależność.

Jest różnica między kwestią, czy programista powinien wyrażać
wątpliwości, sugerować czy wypytywać (się zgadzam, że powinien), a tym,
czy powinien wgłębiać się w ustawy i interpretacje - IMO niekoniecznie
powinien, a jeśli ma być to odpowiedź na problem, że analityk jest
niedouczony, to moim zdaniem problem ten ma lepsze rozwiązania.

> Jak każdy weźmie fragment odpowiedzialności za cudze błędy
> to może nie powstanie "ziemia niczyja" kiedy projekt pada lecz nikt nie
> ma wyrzutów sumienia.

Jak każdy weźmie fragment odpowiedzialności, to w razie problemów każdy
będzie miał inne zdanie na temat, który dokładnie fragment kto wziął.

do góry

W dniu 2013-01-18 00:06, Andrzej Jarzabek pisze:
> On 17/01/2013 17:12, darekm wrote:
>> W dniu 2013-01-16 08:51, Andrzej Jarzabek pisze:
>>> On 15/01/2013 22:28, Gotfryd Smolik news wrote:
>>>> Ja tak z pozoru offtopicznie:
>>>>
>>>> On Thu, 27 Dec 2012, boryspower wrote:
>>>>
>>>>> Przykład: Stworzenie aplikacji do fakturowania
> [...]
>>> Oczywiście może się tak zdarzyć, ale w takiej sytuacji błąd był
>>> wcześniej, już na etapie rekrutacji i twoim problemem nie jest jak
>>> tworzyć oprogramowanie, tylko jak znaleźć douczonych fachowców.
>>
>> Tylko co jak takich fachowców nie ma lub nie da się sprawdzić czy są
>> douczeni, bo dziedzina jest nowa.
>
> No faktycznie, wystawianie faktur o coś, co wymyślili wczoraj.

Właśnie że wymyślili i to nie raz. Zagadnienie fakturowania nie jest tak
banalne jak się większości wydaje, twierdzę że jest bardziej
skomplikowanie niż to co zwyczajowo nazywa się Elektronicznym Obiegiem
Dokumentów.

Ale to tylko na marginesie, to tylko przykład (abstrakt) zagadnienia,
który (niby) wszyscy znają więc mogą się wypowiadać.

>
>> Naiwnością jest myślenie że znajdę
>> dobrego fachowca i zrobi mi dobrze. Żeby wybrać tego douczonego muszę
>> mieć szczęście albo samemu się douczyć.
>
> Naiwnością jest myślenie, że jak nie potrafisz znaleźć fachowców, to
> będziesz potrafił się sam nauczyć na tyle, żeby stworzyć poprawnie
> działający program - tym bardziej na podstawie takiego myślenia dawanie
> klientom jakichkolwiek gwarancji.
>

No właśnie, sam nie umiem i możliwe że nie wybiorę douczonego a jednak
firmy realizują projekty.

>>> W ogólnym przypadku założenie, że inżynier oprogramowania po
>>> przeczytaniu ustawy i sprawdzeniu tego i owego w internecie będzie
>>> mądrzejszy od fachowca jest dość ryzykowne.
>>
>> W drugą stronę również. Ale razem mają większe kompetencje niż każdy z
>> osobna, należy to "tylko" wykorzystać.
>
> Na pewno dobrze jest, jeśli programista może się dopytać czy podzielić
> wątpliwościami, ale założenie, że wyłapie błędy analityka jest, jak
> pisałem, ryzykowne. Z drugiej strony jeśli ma tracić czas na czytanie
> ustaw, to IMO lepiej, żeby przeczytał sobie książkę o ATDD albo nauczył
> się jakiegoś narzędzia typu FitNesse albo Cucumber.
>

Tu jest różnica: wg Ciebie programista nie może(nie musi, nie powinien)
interesować się ustawami bo od tego jest analityk

Nie zakładam że wszystkie błędy wyłapie (bo że takowe będą to pewne) ale
jak mu się uda to jest zysk, a jak mu zabronię (zniechęcę, uniemożliwię)
to tego zysku nie będzie.


>
>>> Uczciwie jest tak: albo świadczysz usługę "mówicie nam co program ma
>>> robić, a my dostarczamy program, który robi właśnie to", albo usługę
>>> "nasi analitycy analizują wasze potrzeby i powiedzą wam, co program
>>> powinien robić i jak, a wy się zgodzicie albo nie".
>>
>> Jeżeli zamawiający potrafi samodzielnie wykonać usługę ale chce ją
>> taniej to wybierze wariant pierwszy. Jeżeli nie zależy na efekcie (np
>> decyzja została narzucona , chce pogrążyć wykonawcę itd) to wybierze
>> wariant drugi.
>
> Rzeczywistość jest raczej trochę bardziej skomplikowana. Po pierwsze -
> druga opcja będzie zwykle droższa. Po drugie istotne jest, dlaczego
> klient w ogóle zamiawia oprogramowanie, skoro do tej pory nie miał
> funkcjonował. Bywa tak, że związane jest to ze zmianą potrzeb czy
> sytuacji, i może być tak, że zamiawiający nie ma dobrego rozeznania w
> tej noowej sytuacji - więc bardziej mu się np. opłaci zamówić
> oprogramowanie z analizą, niż samemu zatrudniać analityków.
>
> Z drugiej strony między umiejętnością wystawiania faktur a umiejętnością
> stworzenia oprogramowania do wystawiania faktur też jest raczej przepaść.
>

Ale mając błędne wyobrażenie jak w danym przypadku wystawia się faktury
też się nie stworzy dobrego oprogramowania.


>> Jeżeli usługa jest nietrywialna i istotna dla obu stron to uczciwie
>> będzie współpracować. Wykonujący i zamawiający wzajemnie nabywają od
>> siebie nowych kompetencji. Ryzyko też powinno być podzielone, ale nie
>> wiem czy równo, solidarnie czy uczciwie?
>
> Oczywiście, że współpraca jest jak najbardziej pożądana, ale dobrze jest
> też mieć wspólne rozumienie tego, co jest sprzedawane i kto za co
> odpowiada. A może nawet jest to w umowie.
>

Ktoś powiedział że umowa jest na czas wojny, w normalnej współpracy się
jej nie używa


>>> Uczciwe świadczenie tej drugiej usługi, zwłaszcza w opcji "24h bez
>>> wsparcia, poprawki w 2h" wymaga odpowiedniej kombinacji doświadczenia i
>>> zatrudnienia kompetentnych analityków, co pozwoli ci to przewidzieć.
>>
>> Jak masz kompetencje to właściwie oszacujesz ryzyko i koszty, jeżeli nie
>> to to jest hazard i albo się uda albo nie.
>
> Jak właściwie oszacujesz ryzyko i koszty, to też jest hazard i albo się
> uda, albo nie. Na tym właśnie polega ryzyko.

To nie to samo. Ryzyko jest zawsze. Każdy z projektów może wyjść albo
nie, ale statystycznie łącznie przy prawidłowych szacunkach jesteś do
przodu.

>
>>> Jeśli bierzesz na siebie takie zobowiązanie, to musisz zatrudnić
>>> analityka (czy nawet kilku), który powie ci, co jest zgodne, a co
>>> niezgodne z przepisami i to ostatecznie trafia do specyfikacji. Jeśli
>>> nie chcesz wziąć na siebie tego ryzyka, to szukasz klienta, który sam ma
>>> księgowych, prawników czy kogo tam, którzy określą zgodność z
>>> przepisami.
>>
>> A skąd ten analityk ma niby wiedzieć to jest zgodne a co nie jak tego
>> nie wiedzą sami twórcy ustawy. To dopiero wiadomo po jakimś czasie jak
>> pojawią się orzeczenia, praktyka. A program musi być tworzony tu i teraz.
>>
>> Rozwiązaniem jest współpraca wszystkich stron: klienta, analityków
>> programistów.
>
> A jak oni wszyscy mają dojść do tego, co jest zgodne, a co nie, jak tego
> nie wiedzą sami twórcy ustawy?

To jest sztuka

>
> W rzeczywistości przecież jakoś firmy działają, faktury wystawiają i
> podatki płacą. W praktyce firma przecież nie wymaga nieomylnego
> księgowego czy nieomylnego prawnika, tylko takiego, który wystaczająco
> rzadko się myli, jak i potrafi powiedzieć kiedy się jedzie po bandzie. I
> tego samego wymagasz od analityka.
>

Zgadza się że wymagam, ale czy otrzymam? Im dłużej współpracuję, im dana
osoba lepiej mnie zna tym większa szansa że porada będzie właściwa,
choć jednocześnie może się zasklepić tylko w jednostronnym rozumieniu
problemów.

> Pytanie jednak - jak zwykle - o kasę. Czas analityków, a zwłaszcza
> dobrych analityków, kosztuje.

Jeżeli ktoś jest dobry to też efektywniej pracuje, więc niekoniecznie
usługa musi być droższa.

Jeśli zamawiający ma księgowego, który wie
> wystarczająco dużo o wystawianiu faktur i może poświęcić odpowiednio
> dużo czasu na uzgadnianie specyfikacji, to może szukać tańszej opcji
> wykonania pod dyktando bez analizy. Bez analizy nie znaczy, że
> programiści czy menedżerowie nie będą wypytywać, sugerować, czy
> znajdować prawdopodobne dziury w specyfikacji, tylko że jak mimo to
> program wystawi fakturę niezgodną z przepisami, to wykonawca będzie mógł
> powiedzieć, że program jest zgodny z uzgodnioną specyfikacją, a on tylko
> to obiecywał - o niezgodność z przepisami zamawiający może mieć
> pretensje do swojego księgowego.
>
Przecież nie mówię o tym, aby coś robić bez analizy. Natomiast przyczynę
upatruję w tym co można przeczytać między wierszami: wykonawca otrzymał
specyfikację i tak zrobił program, nieistotne dla niego jest to czy to
jest dobre dla zamawiającego, czy się analityk pomylił, analogicznie
pozostałe strony. I nie mówię o ewentualnych roszczeniach po katastrofie
tylko o normalnym realizowaniu projektu. Nie należy zakładać że ustawy
są czytelne, specyfikacja jednoznaczna a implementacja bezbłędna. W
każdym są nieprawidłowości, z których większość przy dobrej woli
wszystkich można obejść. Jeśli nie to jest to porażka wszystkich i
kończy się polowaniem na czarownice.

> I jeśli ktoś nie potrafi zatrudnić analityków albo odróżnić douczonych
> od niedouczonych, to nie powinien prowadzić biznesu polegającego na
> usłudze "z analizą" - bo przecież programista może przeczytać ustawę i
> poprawić babole niedouczonego analityka.
>

Nie ma takich to zupełnie nie potrafią oraz takich co potrafią na 100%
bezbłędnie. W wielu przypadkach nie da się też powiedzieć że ktoś jest
bezwzględnie lepszy, bardziej douczony. Wiec powyższa zasada jest
bezużyteczna.

>> Tyle że nie taka jak się zazwyczaj słyszy: klienta: że coś
>> jest niedoprecyzowane (przecież pisze "zgodnie z przepisami"), analityka
>
> Jeśli wykonawca zobowiązał się zrobić "zgodne z przepisami", to powinien
> mieć analityków od tego. Jeśli nie potrafi takich zatrudnić, nie
> powinien się zgadzać na taki zapis.
>

Kogo to obchodzi? handlowiec zawrze umowę na każdych warunkach, prawnik
sprawdzi tylko kary umowne, bo nie zna kompetencji własnej firmy a
programisty i tak nikt nie zapyta czy np ma wolne moce przerobowe.
Karykaturalne ale do pewnego stopnia prawdziwe.


>> że ktoś czegoś nie przedstawił (nikt nie mówił o takim przypadku),
>> programistę ("ja nie znam się na przepisach"). Nie powinno być ostrego
>> podziału kompetencji kiedy każde naruszenie granic jest zamachem na
>> niezależność.
>
> Jest różnica między kwestią, czy programista powinien wyrażać
> wątpliwości, sugerować czy wypytywać (się zgadzam, że powinien), a tym,
> czy powinien wgłębiać się w ustawy i interpretacje - IMO niekoniecznie
> powinien, a jeśli ma być to odpowiedź na problem, że analityk jest
> niedouczony, to moim zdaniem problem ten ma lepsze rozwiązania.
>
po pierwsze niekoniecznie niedouczony (może się pomylił, może nie
zapytał, może nie skojarzył)
po drugie przedstaw to rozwiązanie

>> Jak każdy weźmie fragment odpowiedzialności za cudze błędy
>> to może nie powstanie "ziemia niczyja" kiedy projekt pada lecz nikt nie
>> ma wyrzutów sumienia.
>
> Jak każdy weźmie fragment odpowiedzialności, to w razie problemów każdy
> będzie miał inne zdanie na temat, który dokładnie fragment kto wziął.

Nie zrozumiałeś. Ten fragment odpowiedzialności nie rodzi skutków
prawnych (może tylko moralne) bo inaczej było by to tylko przesunięcie
granic a chodzi aby były "zakładki". Nie mogą dwie osoby (dwa zespoły)
odpowiadać za to samo.


--
Darek

do góry

On 18/01/2013 10:23, darekm wrote:
> W dniu 2013-01-18 00:06, Andrzej Jarzabek pisze:
>> On 17/01/2013 17:12, darekm wrote:
>>>
>>> Tylko co jak takich fachowców nie ma lub nie da się sprawdzić czy są
>>> douczeni, bo dziedzina jest nowa.
>>
>> No faktycznie, wystawianie faktur o coś, co wymyślili wczoraj.
>
> Właśnie że wymyślili i to nie raz. Zagadnienie fakturowania nie jest tak
> banalne jak się większości wydaje, twierdzę że jest bardziej
> skomplikowanie niż to co zwyczajowo nazywa się Elektronicznym Obiegiem
> Dokumentów.
>
> Ale to tylko na marginesie, to tylko przykład (abstrakt) zagadnienia,
> który (niby) wszyscy znają więc mogą się wypowiadać.

Ja się nie wypowiadam, czy jest skomplikowane, czy nie, bo się nie znam.
Odnoszę się tylko do tego, czy da się znaleźć fachowców. Jakby się nie
dało, to by nie było płatników VAT, bo nikt by nie potrafił wystawić
faktury.

>> Naiwnością jest myślenie, że jak nie potrafisz znaleźć fachowców, to
>> będziesz potrafił się sam nauczyć na tyle, żeby stworzyć poprawnie
>> działający program - tym bardziej na podstawie takiego myślenia dawanie
>> klientom jakichkolwiek gwarancji.
>
> No właśnie, sam nie umiem i możliwe że nie wybiorę douczonego a jednak
> firmy realizują projekty.

To, że ty nie umiesz nie znaczy, że nikt nie umie.

>> Na pewno dobrze jest, jeśli programista może się dopytać czy podzielić
>> wątpliwościami, ale założenie, że wyłapie błędy analityka jest, jak
>> pisałem, ryzykowne. Z drugiej strony jeśli ma tracić czas na czytanie
>> ustaw, to IMO lepiej, żeby przeczytał sobie książkę o ATDD albo nauczył
>> się jakiegoś narzędzia typu FitNesse albo Cucumber.
>
> Tu jest różnica: wg Ciebie programista nie może(nie musi, nie powinien)
> interesować się ustawami bo od tego jest analityk

Może się interesować, czym chce. Według mnie nie powinien musieć.

> Nie zakładam że wszystkie błędy wyłapie (bo że takowe będą to pewne) ale
> jak mu się uda to jest zysk, a jak mu zabronię (zniechęcę, uniemożliwię)
> to tego zysku nie będzie.

Może być zysk czasu.

Poza tym mi nie tyle chodzi o to, co ja zabronię lub do czego zniechęcę
programistę.

>> Z drugiej strony między umiejętnością wystawiania faktur a umiejętnością
>> stworzenia oprogramowania do wystawiania faktur też jest raczej przepaść.
>
> Ale mając błędne wyobrażenie jak w danym przypadku wystawia się faktury
> też się nie stworzy dobrego oprogramowania.

Zależy jak szeroko pojmujemy określenie "błędne". Jeśli błędne znaczy
również np. niepełne, to jak najbardziej można.

>> Oczywiście, że współpraca jest jak najbardziej pożądana, ale dobrze jest
>> też mieć wspólne rozumienie tego, co jest sprzedawane i kto za co
>> odpowiada. A może nawet jest to w umowie.
>
> Ktoś powiedział że umowa jest na czas wojny, w normalnej współpracy się
> jej nie używa

Jeśli klieent i wykonawca mają rozbieżne wyobrażenia na temat tego, za
co jeden płaci drugiemu, to wojna jest całkiem prawdopodobna.

>>> Jak masz kompetencje to właściwie oszacujesz ryzyko i koszty, jeżeli nie
>>> to to jest hazard i albo się uda albo nie.
>>
>> Jak właściwie oszacujesz ryzyko i koszty, to też jest hazard i albo się
>> uda, albo nie. Na tym właśnie polega ryzyko.
>
> To nie to samo. Ryzyko jest zawsze. Każdy z projektów może wyjść albo
> nie, ale statystycznie łącznie przy prawidłowych szacunkach jesteś do
> przodu.

Prawdę mówiąc nie wierzę w takie szacunki.

>>> A skąd ten analityk ma niby wiedzieć to jest zgodne a co nie jak tego
>>> nie wiedzą sami twórcy ustawy. To dopiero wiadomo po jakimś czasie jak
>>> pojawią się orzeczenia, praktyka. A program musi być tworzony tu i
>>> teraz.
>>> Rozwiązaniem jest współpraca wszystkich stron: klienta, analityków
>>> programistów.
>> A jak oni wszyscy mają dojść do tego, co jest zgodne, a co nie, jak tego
>> nie wiedzą sami twórcy ustawy?
>
> To jest sztuka

Znaczy, nie ma żadnego argumentu na to, że wszyscy razem dojdą lepiej
niż douczony analityk.

>> W rzeczywistości przecież jakoś firmy działają, faktury wystawiają i
>> podatki płacą. W praktyce firma przecież nie wymaga nieomylnego
>> księgowego czy nieomylnego prawnika, tylko takiego, który wystaczająco
>> rzadko się myli, jak i potrafi powiedzieć kiedy się jedzie po bandzie. I
>> tego samego wymagasz od analityka.
>>
>
> Zgadza się że wymagam, ale czy otrzymam?

To samo pytanie można zadać w przypadku dowolnego księgowego, prawnika
czy kogo tam odpowiadającego za zgodność faktur z przepisami. Czy w
zasadzie kogokolwiek (odpowiednio do zadania).

>> Pytanie jednak - jak zwykle - o kasę. Czas analityków, a zwłaszcza
>> dobrych analityków, kosztuje.
>
> Jeżeli ktoś jest dobry to też efektywniej pracuje, więc niekoniecznie
> usługa musi być droższa.

Jest nominalnie droższa. Czy jest sumarycznie droższa, to zależy -
analityk, który efektywnie mówi ci rzeczy, które już wiesz,
niekoniecznie ci się opłaca. Dlatego też pisałem, czasem sensowna jest
usługa "z analizą", czasem bez.

> Przecież nie mówię o tym, aby coś robić bez analizy. Natomiast przyczynę
> upatruję w tym co można przeczytać między wierszami: wykonawca otrzymał
> specyfikację i tak zrobił program, nieistotne dla niego jest to czy to
> jest dobre dla zamawiającego, czy się analityk pomylił, analogicznie
> pozostałe strony.

A ja natomiast nie mówię o tym. Jeśli założysz, że wykonawca, analityk,
programista, i kto tam jeszcze starają się zrobić tak, żeby klient był
zadowolony, to nadal niekoniecznie czytanie i interpretowanie ustaw
przez programistę jest najlepszym sposobem na osiągnięcie tego celu.

>> I jeśli ktoś nie potrafi zatrudnić analityków albo odróżnić douczonych
>> od niedouczonych, to nie powinien prowadzić biznesu polegającego na
>> usłudze "z analizą" - bo przecież programista może przeczytać ustawę i
>> poprawić babole niedouczonego analityka.
>
> Nie ma takich to zupełnie nie potrafią oraz takich co potrafią na 100%
> bezbłędnie. W wielu przypadkach nie da się też powiedzieć że ktoś jest
> bezwzględnie lepszy, bardziej douczony. Wiec powyższa zasada jest
> bezużyteczna.

Żey zasada była użyteczna nie potrzeba takich, co zupełnie nie potrafią
ani takich, co potrafią na 100%. Wystarczy, że są tacy, co potrafią na
99% i tacy, co potrafią na 1%.

> Kogo to obchodzi? handlowiec zawrze umowę na każdych warunkach, prawnik
> sprawdzi tylko kary umowne, bo nie zna kompetencji własnej firmy a
> programisty i tak nikt nie zapyta czy np ma wolne moce przerobowe.
> Karykaturalne ale do pewnego stopnia prawdziwe.

Współczuję doświadczeń.

>> Jest różnica między kwestią, czy programista powinien wyrażać
>> wątpliwości, sugerować czy wypytywać (się zgadzam, że powinien), a tym,
>> czy powinien wgłębiać się w ustawy i interpretacje - IMO niekoniecznie
>> powinien, a jeśli ma być to odpowiedź na problem, że analityk jest
>> niedouczony, to moim zdaniem problem ten ma lepsze rozwiązania.
>>
> po pierwsze niekoniecznie niedouczony (może się pomylił, może nie
> zapytał, może nie skojarzył)
> po drugie przedstaw to rozwiązanie

Dla firmy? Po pierwsze, żeby potrafić ocenić kompetencje zatrudnianych
specjalistów. A jak się nie potrafi, to nie prowadzić działalności
wymagającej tych kompetancji. Po drugie żeby oszacować ryzyko i
zatrudnić tylu analityków i o takich kompetencjach, żeby to ryzyko można
było uznać za dopuszczalne - żeby jak jeden się pomyli, to drugi go
poprawił. Jeśli zatrudnienie takiej ilości analityków czyni interes
nieopłacalnym, to znowu - nie prowadzić danej działalności.

Dla inżyniera oprogramowania? Kolaboracja przy tworzeniu specyfikacji z
przykładami, stosowanie przy tym skutecznych metodologii i narzędzi,
częste dostarczanie działającego oprogramowania, dostarczanie
najbardziej wartościowej funkcjonalności w pierwszej kolejności,
porządny projekt, czytelny kod, TDD, prostota, prostota, prostota,
utrzymanie tego wszystkiego przy zmieniającej się specyfikacji przez
refaktoryzację.

do góry

W dniu 2013-01-22 23:42, Andrzej Jarzabek pisze:
>> Ale to tylko na marginesie, to tylko przykład (abstrakt) zagadnienia,
>> który (niby) wszyscy znają więc mogą się wypowiadać.
>
> Ja się nie wypowiadam, czy jest skomplikowane, czy nie, bo się nie znam.
> Odnoszę się tylko do tego, czy da się znaleźć fachowców. Jakby się nie
> dało, to by nie było płatników VAT, bo nikt by nie potrafił wystawić
> faktury.

To tylko dowód na to że tacy istnieją. Czy wszyscy z nich byli
fachowcami w momencie jak rozpoczynali pracę w tej dziedzinie? Pytanie
jak ich wybrać pozostaje otwarte.

>
>>> Naiwnością jest myślenie, że jak nie potrafisz znaleźć fachowców, to
>>> będziesz potrafił się sam nauczyć na tyle, żeby stworzyć poprawnie
>>> działający program - tym bardziej na podstawie takiego myślenia dawanie
>>> klientom jakichkolwiek gwarancji.
>>
>> No właśnie, sam nie umiem i możliwe że nie wybiorę douczonego a jednak
>> firmy realizują projekty.
>
> To, że ty nie umiesz nie znaczy, że nikt nie umie.

Ale ja też bym chciał umieć. A inne firmy będą mi przeszkadzać (nie
zawsze pomogą np w wyborze kandydata), a kandydaci potrafią dobrze
udawać że wiedzą.

>
>>> Na pewno dobrze jest, jeśli programista może się dopytać czy podzielić
>>> wątpliwościami, ale założenie, że wyłapie błędy analityka jest, jak
>>> pisałem, ryzykowne. Z drugiej strony jeśli ma tracić czas na czytanie
>>> ustaw, to IMO lepiej, żeby przeczytał sobie książkę o ATDD albo nauczył
>>> się jakiegoś narzędzia typu FitNesse albo Cucumber.
>>
>> Tu jest różnica: wg Ciebie programista nie może(nie musi, nie powinien)
>> interesować się ustawami bo od tego jest analityk
>
> Może się interesować, czym chce. Według mnie nie powinien musieć.

Widzę pewien dysonans. Programiście każdy może zgłaszać błąd bo wszyscy
wiedzą co program ma robić. Ale ten nie może nikomu, a szczególnie
analitykowi, bo ten jest nieomylny, perfekcyjny. Czyli najlepszy
programista to jak żołnierz - nie pyta się dlaczego.

>
>> Nie zakładam że wszystkie błędy wyłapie (bo że takowe będą to pewne) ale
>> jak mu się uda to jest zysk, a jak mu zabronię (zniechęcę, uniemożliwię)
>> to tego zysku nie będzie.
>
> Może być zysk czasu.

Dostarczę program szybciej ale z większą liczbą błędów?


>
> Poza tym mi nie tyle chodzi o to, co ja zabronię lub do czego zniechęcę
> programistę.
>
>>> Z drugiej strony między umiejętnością wystawiania faktur a umiejętnością
>>> stworzenia oprogramowania do wystawiania faktur też jest raczej
>>> przepaść.
>>
>> Ale mając błędne wyobrażenie jak w danym przypadku wystawia się faktury
>> też się nie stworzy dobrego oprogramowania.
>
> Zależy jak szeroko pojmujemy określenie "błędne". Jeśli błędne znaczy
> również np. niepełne, to jak najbardziej można.
>

Można co bo nie rozumiem?

> Prawdę mówiąc nie wierzę w takie szacunki.
>
>>>> A skąd ten analityk ma niby wiedzieć to jest zgodne a co nie jak tego
>>>> nie wiedzą sami twórcy ustawy. To dopiero wiadomo po jakimś czasie jak
>>>> pojawią się orzeczenia, praktyka. A program musi być tworzony tu i
>>>> teraz.
>>>> Rozwiązaniem jest współpraca wszystkich stron: klienta, analityków
>>>> programistów.
>>> A jak oni wszyscy mają dojść do tego, co jest zgodne, a co nie, jak tego
>>> nie wiedzą sami twórcy ustawy?
>>
>> To jest sztuka
>
> Znaczy, nie ma żadnego argumentu na to, że wszyscy razem dojdą lepiej
> niż douczony analityk.
>

Niż idealny analityk to zgoda. Zazwyczaj jednak ma się do czynienia z
nie ideałami. I proszę nie przesadzaj w drugą stronę. To nie ma być
demokratycznie ustalanie specyfikacji.


>>> W rzeczywistości przecież jakoś firmy działają, faktury wystawiają i
>>> podatki płacą. W praktyce firma przecież nie wymaga nieomylnego
>>> księgowego czy nieomylnego prawnika, tylko takiego, który wystaczająco
>>> rzadko się myli, jak i potrafi powiedzieć kiedy się jedzie po bandzie. I
>>> tego samego wymagasz od analityka.
>>>
>>
>> Zgadza się że wymagam, ale czy otrzymam?
>
> To samo pytanie można zadać w przypadku dowolnego księgowego, prawnika
> czy kogo tam odpowiadającego za zgodność faktur z przepisami. Czy w
> zasadzie kogokolwiek (odpowiednio do zadania).
>
No właśnie.

>> Przecież nie mówię o tym, aby coś robić bez analizy. Natomiast przyczynę
>> upatruję w tym co można przeczytać między wierszami: wykonawca otrzymał
>> specyfikację i tak zrobił program, nieistotne dla niego jest to czy to
>> jest dobre dla zamawiającego, czy się analityk pomylił, analogicznie
>> pozostałe strony.
>
> A ja natomiast nie mówię o tym. Jeśli założysz, że wykonawca, analityk,
> programista, i kto tam jeszcze starają się zrobić tak, żeby klient był
> zadowolony, to nadal niekoniecznie czytanie i interpretowanie ustaw
> przez programistę jest najlepszym sposobem na osiągnięcie tego celu.
>

Same starania mogą nie wystarczyć. Zakładam że każdy poprawnie wykonuje
swoje zadania, z typową jakością (dobrze, ale nie idealnie). odpowiednio
dobrane sprzężenie zwrotne (np. przepływ informacji od programisty do
analityka) podnosi stabilność czyli pewność osiągnięcia celu. W luźnych
strukturach takie sprzężenie występuje naturalnie, natomiast tam gdzie
jest bardzo sformalizowana hierarchia jest stosunkowo ograniczone.


>>> I jeśli ktoś nie potrafi zatrudnić analityków albo odróżnić douczonych
>>> od niedouczonych, to nie powinien prowadzić biznesu polegającego na
>>> usłudze "z analizą" - bo przecież programista może przeczytać ustawę i
>>> poprawić babole niedouczonego analityka.
>>
>> Nie ma takich to zupełnie nie potrafią oraz takich co potrafią na 100%
>> bezbłędnie. W wielu przypadkach nie da się też powiedzieć że ktoś jest
>> bezwzględnie lepszy, bardziej douczony. Wiec powyższa zasada jest
>> bezużyteczna.
>
> Żey zasada była użyteczna nie potrzeba takich, co zupełnie nie potrafią
> ani takich, co potrafią na 100%. Wystarczy, że są tacy, co potrafią na
> 99% i tacy, co potrafią na 1%.
>
>> Kogo to obchodzi? handlowiec zawrze umowę na każdych warunkach, prawnik
>> sprawdzi tylko kary umowne, bo nie zna kompetencji własnej firmy a
>> programisty i tak nikt nie zapyta czy np ma wolne moce przerobowe.
>> Karykaturalne ale do pewnego stopnia prawdziwe.
>
> Współczuję doświadczeń.
>
To są cudze doświadczenia, ja za nie płaciłem choć mogę korzystać.

>>> Jest różnica między kwestią, czy programista powinien wyrażać
>>> wątpliwości, sugerować czy wypytywać (się zgadzam, że powinien), a tym,
>>> czy powinien wgłębiać się w ustawy i interpretacje - IMO niekoniecznie
>>> powinien, a jeśli ma być to odpowiedź na problem, że analityk jest
>>> niedouczony, to moim zdaniem problem ten ma lepsze rozwiązania.
>>>
>> po pierwsze niekoniecznie niedouczony (może się pomylił, może nie
>> zapytał, może nie skojarzył)
>> po drugie przedstaw to rozwiązanie
>
> Dla firmy? Po pierwsze, żeby potrafić ocenić kompetencje zatrudnianych
> specjalistów. A jak się nie potrafi, to nie prowadzić działalności
> wymagającej tych kompetancji.

Większość firm które się rozwija nie stosuje się do tego. Pojawia się
nowa możliwość to się z niej korzysta z takimi ludźmi jakimi się
dysponuje. Jak się uda to do już się prowadzi działalność z
wystarczającymi kompetencjami (bo to czego brakowało to nabyli)

Po drugie żeby oszacować ryzyko i
> zatrudnić tylu analityków i o takich kompetencjach, żeby to ryzyko można
> było uznać za dopuszczalne - żeby jak jeden się pomyli, to drugi go
> poprawił. Jeśli zatrudnienie takiej ilości analityków czyni interes
> nieopłacalnym, to znowu - nie prowadzić danej działalności.
>

j.w.
Po co drugi analityk jak wiem że mój inżynier oprogramowania ma pewne
doświadczenie tam, gdzie analityk wydaje się słabszy

To co piszesz jest bardzo dobre dla działających firm. Przy takim
nastawieniu nikt nowy się nie pojawi, nie będzie konieczne zmagać się z
nową konkurencją a ze starą ustalono podział runku.


> Dla inżyniera oprogramowania? Kolaboracja przy tworzeniu specyfikacji z

Czyli jednak zakładasz współpracę z analitykiem przy tworzeniu
specyfikacji? Bo jeżeli tak to w zasadzie mamy to samo zdanie.



--
Darek

do góry

On 25/01/2013 10:34, darekm wrote:
> W dniu 2013-01-22 23:42, Andrzej Jarzabek pisze:
>>> Ale to tylko na marginesie, to tylko przykład (abstrakt) zagadnienia,
>>> który (niby) wszyscy znają więc mogą się wypowiadać.
>>
>> Ja się nie wypowiadam, czy jest skomplikowane, czy nie, bo się nie znam.
>> Odnoszę się tylko do tego, czy da się znaleźć fachowców. Jakby się nie
>> dało, to by nie było płatników VAT, bo nikt by nie potrafił wystawić
>> faktury.
>
> To tylko dowód na to że tacy istnieją.

Jeśli istnieją, to zapewne można ich zatrudnić.

> Czy wszyscy z nich byli fachowcami w momencie jak rozpoczynali pracę
> w tej dziedzinie?

Nie mam pojęcia, ale jestem w stanie sobie wyobrazić, że są ścieżki
kariery nie wymagające rozpoczynania pracy jako analityk od faktur nie
wiedząc nic o wystawianiu faktur. Na przykład można zacząć od tego, że
się skończy jakieś studia czy kurs, a potem się pracuje ileś czasu na
stanowisku, na którym się samemu te faktury wystawia.

> Pytanie jak ich wybrać pozostaje otwarte.

Myślę, że trzeba się znać lub mieć wspólnika, który się zna. Jak się
tego nie ma, to myślę, że nie należy prowadzić takiego biznesu.

>>> No właśnie, sam nie umiem i możliwe że nie wybiorę douczonego a jednak
>>> firmy realizują projekty.
>>
>> To, że ty nie umiesz nie znaczy, że nikt nie umie.
>
> Ale ja też bym chciał umieć.

To sobie chcij, tylko że jak się to ma do tematu dyskusji?

> A inne firmy będą mi przeszkadzać (nie
> zawsze pomogą np w wyborze kandydata), a kandydaci potrafią dobrze
> udawać że wiedzą.

Nie rozumiem w ogóle twojego problemu. Komu mają te firmy (i jakie firmy
w ogóle) przeszkadzać? I przed kim kandydaci mają udawać? Zazwyczaj jest
tak, że jak się przyjmuje kogoś do pracy, to rozmowę przeprowadza ktoś,
kto się dobrze zna na temacie.

>>> Tu jest różnica: wg Ciebie programista nie może(nie musi, nie powinien)
>>> interesować się ustawami bo od tego jest analityk
>> Może się interesować, czym chce. Według mnie nie powinien musieć.
>
> Widzę pewien dysonans. Programiście każdy może zgłaszać błąd bo wszyscy
> wiedzą co program ma robić. Ale ten nie może nikomu, a szczególnie
> analitykowi, bo ten jest nieomylny, perfekcyjny. Czyli najlepszy
> programista to jak żołnierz - nie pyta się dlaczego.

Pewnie, że może pytać, ale musi też się liczyć z odpowiedzią "tak ma
być, nie będę tłumaczyć dlaczego". I nie chodzi o to, że jest nieomylny,
tylko o to, że jego omylność jest wliczonym w działalność ryzykiem.

>>> Nie zakładam że wszystkie błędy wyłapie (bo że takowe będą to pewne) ale
>>> jak mu się uda to jest zysk, a jak mu zabronię (zniechęcę, uniemożliwię)
>>> to tego zysku nie będzie.
>>
>> Może być zysk czasu.
>
> Dostarczę program szybciej ale z większą liczbą błędów?

Może wcale nie z większą, ale powiedzmy nawet, że tak. Otóż jeśli
studiowanie ustaw i wypytywanie analityka dlaczego jest jak jest
spowoduje, że zaimplementowanie danego kawałka funkcjonalności zajmie
cztery tygodnie zamiast dwóch, to program będzie dwa tygodnie wcześniej
oddany do testów a może nawet wdrożony do produkcji, co dać może tyle,
że znalezionych zostanie więcej błędów, niż znalazłby programista
czytający ustawę.

>>> Ale mając błędne wyobrażenie jak w danym przypadku wystawia się faktury
>>> też się nie stworzy dobrego oprogramowania.
>>
>> Zależy jak szeroko pojmujemy określenie "błędne". Jeśli błędne znaczy
>> również np. niepełne, to jak najbardziej można.
>
> Można co bo nie rozumiem?

Można stworzyć dobre oprogramowanie. Powiedzmy istnieje 150 sposobów na
wystawienie faktury, nie znaczy to, że program, który ma "błąd"
polegający na tym, że nie obsługuje 135 z nich nie jest dobrym
oprogramowaniem.

>>>> A jak oni wszyscy mają dojść do tego, co jest zgodne, a co nie, jak
>>>> tego nie wiedzą sami twórcy ustawy?
>>> To jest sztuka
>> Znaczy, nie ma żadnego argumentu na to, że wszyscy razem dojdą lepiej
>> niż douczony analityk.
>
> Niż idealny analityk to zgoda. Zazwyczaj jednak ma się do czynienia z
> nie ideałami. I proszę nie przesadzaj w drugą stronę. To nie ma być
> demokratycznie ustalanie specyfikacji.

Nawet jeśli douczony nie znaczy idealny, to nadal nie ma żadnego
argumentu. No i odnosiłem się do tego, że przedstawiłeś temat jako
niepojęty, w któym nic się nie da wiedzieć. Jeśli tak jest i głupek
wioskowy może mieć rację równie dobrze co fachowiec, to żadnych
fachowców nie potrzebujesz, ale też bez sensu żeby programista czytał
ustawę, skoro nawet twórca ustawy nie wie, co znaczy jej treść - niech
zrobi po uważaniu, najlepiej tak, żeb było najprościej.

Tylko że oboje dobrze wiemy, że w rzeczywistości tak nie jest. Nawet to,
czy twóca ustawy ją rozumie, czy nie, jest nieistotne - istotne są
praktyczne konsekwencje wystawiania takich a nie innych liczb na
fakturach. I analityk jest od tego specjalistą, żeby wiedzieć, jaka jest
praktyka: co się powszechnie robi i urząd się nie czepia, do czego się
jednak czepia, jak interpretują to sądy i tak dalej.

>>>> podatki płacą. W praktyce firma przecież nie wymaga nieomylnego
>>>> księgowego czy nieomylnego prawnika, tylko takiego, który wystaczająco
>>>> rzadko się myli, jak i potrafi powiedzieć kiedy się jedzie po
>>>> bandzie. I tego samego wymagasz od analityka.
>>>
>>> Zgadza się że wymagam, ale czy otrzymam?
>>
>> To samo pytanie można zadać w przypadku dowolnego księgowego, prawnika
>> czy kogo tam odpowiadającego za zgodność faktur z przepisami. Czy w
>> zasadzie kogokolwiek (odpowiednio do zadania).
>>
> No właśnie.

Dość oczywistym jest, że prowadzenie dowolnego biznesu wiąże się z
ryzykiem, i częścią tego ryzyka są ludzie, którzy mogą nie wykonać lub
źle wykonać swoje obowiązki, bądź dlatego, że nie potrafią, bądź z
innego powodu. Jak się nie potrafi zrekrutować takich, którzy
przynajmniej potrafią, to prowadzenie danej działalności jest bardzo
mocno ryzykowne i tyle.

>> A ja natomiast nie mówię o tym. Jeśli założysz, że wykonawca, analityk,
>> programista, i kto tam jeszcze starają się zrobić tak, żeby klient był
>> zadowolony, to nadal niekoniecznie czytanie i interpretowanie ustaw
>> przez programistę jest najlepszym sposobem na osiągnięcie tego celu.
>
> Same starania mogą nie wystarczyć. Zakładam że każdy poprawnie wykonuje
> swoje zadania, z typową jakością (dobrze, ale nie idealnie). odpowiednio
> dobrane sprzężenie zwrotne (np. przepływ informacji od programisty do
> analityka) podnosi stabilność czyli pewność osiągnięcia celu. W luźnych

Przepływ informacji jest jak najbardziej potrzebny, ale on też jest
możliwy bez czytania ustaw przez programistę.

>>> Kogo to obchodzi? handlowiec zawrze umowę na każdych warunkach, prawnik
>>> sprawdzi tylko kary umowne, bo nie zna kompetencji własnej firmy a
>>> programisty i tak nikt nie zapyta czy np ma wolne moce przerobowe.
>>> Karykaturalne ale do pewnego stopnia prawdziwe.
>>
>> Współczuję doświadczeń.
>>
> To są cudze doświadczenia, ja za nie płaciłem choć mogę korzystać.

Skoro za nie płaciłłeeś, to tym bbardziej współczuję.

>>> po pierwsze niekoniecznie niedouczony (może się pomylił, może nie
>>> zapytał, może nie skojarzył)
>>> po drugie przedstaw to rozwiązanie
>>
>> Dla firmy? Po pierwsze, żeby potrafić ocenić kompetencje zatrudnianych
>> specjalistów. A jak się nie potrafi, to nie prowadzić działalności
>> wymagającej tych kompetancji.
>
> Większość firm które się rozwija nie stosuje się do tego.

Na jakiej podstawie tak uważasz?

> Pojawia się
> nowa możliwość to się z niej korzysta z takimi ludźmi jakimi się
> dysponuje.

No więc zauważ, że np. z nowych możliwości związanych np. z
nowelizacjami ustawy o VAT większość przedsiębiorstw na świecie nie
korzysta poprzez oferowanie oprogramowania do fakturowania. Powiesz
może, że powinienem tutaj brać nie przedsiębiorstwa na świecie, tylko w
Polsce (nadal większość nie korzysta, a z drugiej strony przecież nic
nie broni zagranicznej firmie produkować programu do wystawiania faktur
w Polsce), a poza tym powinienem brać pod uwagę tylko firmy "w branży",
czyli w tym przypadku już produkujące opgramowanie do fakturowania.
Tylko że właśnie bycie "w branży" oznacza, że się ma już i ewentualnie
potrafi zrekrutować ludzi posiadających kompetencje i mniej więcej wie,
jakie można usługi oferować dysponując tymi ludźmi.

> Po co drugi analityk jak wiem że mój inżynier oprogramowania ma pewne
> doświadczenie tam, gdzie analityk wydaje się słabszy

Jak ma, to dobrze, i zapewne takiego doświadczenia nabędzie pracując w
danym temacie. Z drugiej strony jeśli ma dopiero czytać ustawy i spędzić
dużo czasu na pytaniu analityka "dlaczego", to może da się lepiej
wykorzystać jego czas.

> To co piszesz jest bardzo dobre dla działających firm. Przy takim
> nastawieniu nikt nowy się nie pojawi, nie będzie konieczne zmagać się z
> nową konkurencją a ze starą ustalono podział runku.

Większość nowych firm dość szybko bankrutuje, wtapiając oszczędności
założycieli. Sensownym punktem wyjścia do ograniczenia tego ryzyka jest
rozkręcanie interesu z luźmi, którzy się znają na tym, na czym się
trzeba znać.

W ukłądzie, o którym mówię, odniesiebnie sukcesu przez nową firmę jest
jak najbardziej możliwe, np. w scenariuszu gdzie doświadczeni analitycy
(albo chociaż spece od faktur) dogadują się z doświadczonymi inżynierami
oprogramowania i zakładają spółkę.

>> Dla inżyniera oprogramowania? Kolaboracja przy tworzeniu specyfikacji z
>
> Czyli jednak zakładasz współpracę z analitykiem przy tworzeniu
> specyfikacji? Bo jeżeli tak to w zasadzie mamy to samo zdanie.

Współpraca to jedno, czytanie ustaw przez programistów to zupełnie inna
sprawa.

do góry

Dnia Sun, 27 Jan 2013 00:41:30 +0000, Andrzej Jarzabek wyszeptal:

> On 25/01/2013 10:34, darekm wrote:
>> W dniu 2013-01-22 23:42, Andrzej Jarzabek pisze:

>> Czy wszyscy z nich byli fachowcami w momencie jak rozpoczynali pracę w
>> tej dziedzinie?
>
> Nie mam pojęcia, ale jestem w stanie sobie wyobrazić, że są ścieżki
> kariery nie wymagające rozpoczynania pracy jako analityk od faktur nie
> wiedząc nic o wystawianiu faktur. Na przykład można zacząć od tego, że
> się skończy jakieś studia czy kurs, a potem się pracuje ileś czasu na
> stanowisku, na którym się samemu te faktury wystawia.

Część szkół biznesowych opiera się na tym modelu, z pominięciem ostaniej
linijki.

>>>> No właśnie, sam nie umiem i możliwe że nie wybiorę douczonego a
>>>> jednak firmy realizują projekty.
>>>
>>> To, że ty nie umiesz nie znaczy, że nikt nie umie.
>>
>> Ale ja też bym chciał umieć.
>
> To sobie chcij, tylko że jak się to ma do tematu dyskusji?

Dobry analityk potrafi zatuszować swoje błędy. Na dodatek im
lepszy, tym trudniej znaleźć kogoś, kto to zweryfikuje. Analityk
to nie szef, który ma prawo robić błędy - więc jak nie mając
żadnego analityka z dziedziny zatrudnić analityka który zweryfikuje
kolejnych? Poważnie pytam.

>> A inne firmy będą mi przeszkadzać (nie
>> zawsze pomogą np w wyborze kandydata), a kandydaci potrafią dobrze
>> udawać że wiedzą.
>
> Nie rozumiem w ogóle twojego problemu. Komu mają te firmy (i jakie firmy
> w ogóle) przeszkadzać? I przed kim kandydaci mają udawać? Zazwyczaj jest
> tak, że jak się przyjmuje kogoś do pracy, to rozmowę przeprowadza ktoś,
> kto się dobrze zna na temacie.
>
>>>> Tu jest różnica: wg Ciebie programista nie może(nie musi, nie
>>>> powinien) interesować się ustawami bo od tego jest analityk
>>> Może się interesować, czym chce. Według mnie nie powinien musieć.
>>
>> Widzę pewien dysonans. Programiście każdy może zgłaszać błąd bo wszyscy
>> wiedzą co program ma robić. Ale ten nie może nikomu, a szczególnie
>> analitykowi, bo ten jest nieomylny, perfekcyjny. Czyli najlepszy
>> programista to jak żołnierz - nie pyta się dlaczego.
>
> Pewnie, że może pytać, ale musi też się liczyć z odpowiedzią "tak ma
> być, nie będę tłumaczyć dlaczego". I nie chodzi o to, że jest nieomylny,
> tylko o to, że jego omylność jest wliczonym w działalność ryzykiem.

Fochy też są wliczone? Nie wiem dlaczego, ale najczęściej w moim
doświadczeniu dobrze radziły sobie firmy, które utrzymują jakiś standard
kultury. Co oczywiście każdy inaczej rozumie, niektórzy uważają
kwiecistą mowę za szczyty niedościgłe, inni traktowanie firmy jako My
a nie "ten #$%#%^ analityk/programista".

>>>> Nie zakładam że wszystkie błędy wyłapie (bo że takowe będą to pewne)
>>>> ale jak mu się uda to jest zysk, a jak mu zabronię (zniechęcę,
>>>> uniemożliwię) to tego zysku nie będzie.
>>>
>>> Może być zysk czasu.
>>
>> Dostarczę program szybciej ale z większą liczbą błędów?
>
> Może wcale nie z większą, ale powiedzmy nawet, że tak. Otóż jeśli
> studiowanie ustaw i wypytywanie analityka dlaczego jest jak jest
> spowoduje, że zaimplementowanie danego kawałka funkcjonalności zajmie
> cztery tygodnie zamiast dwóch, to program będzie dwa tygodnie wcześniej
> oddany do testów a może nawet wdrożony do produkcji, co dać może tyle,
> że znalezionych zostanie więcej błędów, niż znalazłby programista
> czytający ustawę.

To jest jeden z modeli, ja go nazywam UMLowym. Drugi jest taki, że
programista rozumie co robi. Właśnie po to, żeby nie musiał czytać ustaw
istnieje obieg informacji, tu: analityk pytany przez programistę.

Rozumiejąc kontekst społeczny pytania analityka jako tego wyżej przez
programistę jako tego niżej dodam, że może warto zatrudniać ludzi, którzy
wiedzą, jaką spełniają w danym momencie rolę. Istnieją różne modele
współpracy analityków i programistów, również (?) takie, gdzie analityk
mówi, dlaczego A jest niemożliwe, a programista dlaczego B jest
niemożliwe - a wtedy najczęściej trzeba kreatywnie wypracować
jakieś rozwiązanie C.

>>>>> A jak oni wszyscy mają dojść do tego, co jest zgodne, a co nie, jak
>>>>> tego nie wiedzą sami twórcy ustawy?
>>>> To jest sztuka
>>> Znaczy, nie ma żadnego argumentu na to, że wszyscy razem dojdą lepiej
>>> niż douczony analityk.
>>
>> Niż idealny analityk to zgoda. Zazwyczaj jednak ma się do czynienia z
>> nie ideałami. I proszę nie przesadzaj w drugą stronę. To nie ma być
>> demokratycznie ustalanie specyfikacji.
>
> Nawet jeśli douczony nie znaczy idealny, to nadal nie ma żadnego
> argumentu. No i odnosiłem się do tego, że przedstawiłeś temat jako
> niepojęty, w któym nic się nie da wiedzieć. Jeśli tak jest i głupek
> wioskowy może mieć rację równie dobrze co fachowiec, to żadnych
> fachowców nie potrzebujesz, ale też bez sensu żeby programista czytał
> ustawę, skoro nawet twórca ustawy nie wie, co znaczy jej treść - niech
> zrobi po uważaniu, najlepiej tak, żeb było najprościej.

Nie zauważyłem wcześniej argumentacji o niezatrudnianiu analityków,
a tylko o rozmowie pomiędzy pracownikami. Oczywiście to żaden argument.

> Tylko że oboje dobrze wiemy, że w rzeczywistości tak nie jest. Nawet to,
> czy twóca ustawy ją rozumie, czy nie, jest nieistotne - istotne są
> praktyczne konsekwencje wystawiania takich a nie innych liczb na
> fakturach. I analityk jest od tego specjalistą, żeby wiedzieć, jaka jest
> praktyka: co się powszechnie robi i urząd się nie czepia, do czego się
> jednak czepia, jak interpretują to sądy i tak dalej.

Nie znam się na wystawianiu faktur, ale większość oprogramowania
ma opcję ręcznej modyfikacji i późniejszego sprawdzania spójności danych
księgowych. Wie to, jak niektórzy mówią, "każdy głupek". Analitycy wciąż
mają najwięcej do zrobienia w doprowadzeniu całości do stanu, który
będzie pozwalał użytkownikowi lawirować pomiędzy przepisami, ale
programista ma swoją rolę, której analityk za niego nie spełni. M.in.
jak napisać system, który potrafi wyjść z sytuacji, w której dane
zostały z powodu błędu - jakiegokolwiek - doprowadzone do stanu,
w którym wymaga on poprawienia. Bez współpracy analityków i programistów
to się nie uda. Współpraca polega na tym, że obie role znajdują
w proponowanych rozwiązaniach błędy, które wymagają korekcji.

>>> A ja natomiast nie mówię o tym. Jeśli założysz, że wykonawca,
>>> analityk,
>>> programista, i kto tam jeszcze starają się zrobić tak, żeby klient był
>>> zadowolony, to nadal niekoniecznie czytanie i interpretowanie ustaw
>>> przez programistę jest najlepszym sposobem na osiągnięcie tego celu.
>>
>> Same starania mogą nie wystarczyć. Zakładam że każdy poprawnie wykonuje
>> swoje zadania, z typową jakością (dobrze, ale nie idealnie).
>> odpowiednio dobrane sprzężenie zwrotne (np. przepływ informacji od
>> programisty do analityka) podnosi stabilność czyli pewność osiągnięcia
>> celu. W luźnych
>
> Przepływ informacji jest jak najbardziej potrzebny, ale on też jest
> możliwy bez czytania ustaw przez programistę.

Ale najczęściej zawodzi, gdy ktoś mówi "tak ma być" i nie jest prezesem
i nie zrobi przy tym jakiegoś przyjaznego gestu.

>>>> Kogo to obchodzi? handlowiec zawrze umowę na każdych warunkach,
>>>> prawnik sprawdzi tylko kary umowne, bo nie zna kompetencji własnej
>>>> firmy a programisty i tak nikt nie zapyta czy np ma wolne moce
>>>> przerobowe. Karykaturalne ale do pewnego stopnia prawdziwe.
>>>
>>> Współczuję doświadczeń.
>>>
>> To są cudze doświadczenia, ja za nie płaciłem choć mogę korzystać.
>
> Skoro za nie płaciłłeeś, to tym bbardziej współczuję.

Współczuję Wam obu :)

>> Pojawia się nowa możliwość to się z niej korzysta z takimi ludźmi
>> jakimi się dysponuje.
>
...
>> Po co drugi analityk jak wiem że mój inżynier oprogramowania ma pewne
>> doświadczenie tam, gdzie analityk wydaje się słabszy
>
> Jak ma, to dobrze, i zapewne takiego doświadczenia nabędzie pracując w
> danym temacie. Z drugiej strony jeśli ma dopiero czytać ustawy i spędzić
> dużo czasu na pytaniu analityka "dlaczego", to może da się lepiej
> wykorzystać jego czas.
>
>> To co piszesz jest bardzo dobre dla działających firm. Przy takim
>> nastawieniu nikt nowy się nie pojawi, nie będzie konieczne zmagać się z
>> nową konkurencją a ze starą ustalono podział runku.
>
> Większość nowych firm dość szybko bankrutuje, wtapiając oszczędności
> założycieli. Sensownym punktem wyjścia do ograniczenia tego ryzyka jest
> rozkręcanie interesu z luźmi, którzy się znają na tym, na czym się
> trzeba znać.
>
> W ukłądzie, o którym mówię, odniesiebnie sukcesu przez nową firmę jest
> jak najbardziej możliwe, np. w scenariuszu gdzie doświadczeni analitycy
> (albo chociaż spece od faktur) dogadują się z doświadczonymi inżynierami
> oprogramowania i zakładają spółkę.

Jeżeli mogę spytać: czy to prawda, że często takie firmy powstałe przez
pączkowanie pozostają jako podwykonawcy? I chciałbym też zauważyć, że
powstają firmy, które z początku mają dwóch pracowników, studentów,
którzy są jednocześnie prezesami.

>>> Dla inżyniera oprogramowania? Kolaboracja przy tworzeniu specyfikacji
>>> z
>>
>> Czyli jednak zakładasz współpracę z analitykiem przy tworzeniu
>> specyfikacji? Bo jeżeli tak to w zasadzie mamy to samo zdanie.
>
> Współpraca to jedno, czytanie ustaw przez programistów to zupełnie inna
> sprawa.

Programiści z zasady nie czytają ustaw. Nie ma nich UMLa, a ustawy
są napisane po chińsku ;). Programista to taki konwerter UMLa
na kod, czasami wyjdzie kupić coś do jedzenia - tylko dzięki temu
wiadomo, że to jednak człowiek. pl.comp.programming?

Argument nie jest "czy programista zna ustawę lepiej niż analityk
ds. Opisanych w Ustawie" tylko, jak widzę, "programista ma nie czytać
ustaw" i "ma nie pytać analityka dlaczego tak". Nawet jak faktycznie
coś zauważy.

Dla poparcia cytat:

AJ:
Raczej trzeba
się nastawić na to, że fachowiec powie jak ma być, proramista napisze
program, który to właśnie robi, potem fachowiec powie, że może być
jeszcze inaczej, i programista to zaimplementuje, potem fachowiec powie,
że tak, jak mówił na początku, że ma być, to nie może być jak cośtam itd.

--
Edek

do góry

On 14/02/2013 22:28, Edek Pienkowski wrote:
> Dnia Sun, 27 Jan 2013 00:41:30 +0000, Andrzej Jarzabek wyszeptal:
>
>
>>>>> No właśnie, sam nie umiem i możliwe że nie wybiorę douczonego a
>>>>> jednak firmy realizują projekty.
>>>> To, że ty nie umiesz nie znaczy, że nikt nie umie.
>>> Ale ja też bym chciał umieć.
>>
>> To sobie chcij, tylko że jak się to ma do tematu dyskusji?
>
> Dobry analityk potrafi zatuszować swoje błędy. Na dodatek im
> lepszy, tym trudniej znaleźć kogoś, kto to zweryfikuje. Analityk
> to nie szef, który ma prawo robić błędy - więc jak nie mając
> żadnego analityka z dziedziny zatrudnić analityka który zweryfikuje
> kolejnych? Poważnie pytam.

Założyć spółkę z kolegą, który się na tym zna.

>> Pewnie, że może pytać, ale musi też się liczyć z odpowiedzią "tak ma
>> być, nie będę tłumaczyć dlaczego". I nie chodzi o to, że jest nieomylny,
>> tylko o to, że jego omylność jest wliczonym w działalność ryzykiem.
>
> Fochy też są wliczone?

Czas weryfikuje to, czy analityk raczej faktycznie się zna i
przynajmniej jak stanowczo twierdzi, że jest tak a nie śmak, to
najczęściej faktycznie nie jest śmak, czy jednak wali fochy jak mu ktoś
wytyka błędy. Czy da się tego z góry uniknąć? Może najlepiej nie
zatrudniać asertywnych, dynamicznych, pewnych siebie, wertykalnie
zintegrowanych dupków z przerostem ego?

> Nie wiem dlaczego, ale najczęściej w moim
> doświadczeniu dobrze radziły sobie firmy, które utrzymują jakiś standard
> kultury.

Jak dla mnie elementem tej kultury jest też szacunek dla
współpracowników i nie zakładanie z góry, że skoro mamy różnicę zdań
związanych z ich specjalnością, to ja mam rację, a oni są niedouczeni.

>>> Dostarczę program szybciej ale z większą liczbą błędów?
>>
>> Może wcale nie z większą, ale powiedzmy nawet, że tak. Otóż jeśli
>> studiowanie ustaw i wypytywanie analityka dlaczego jest jak jest
>> spowoduje, że zaimplementowanie danego kawałka funkcjonalności zajmie
>> cztery tygodnie zamiast dwóch, to program będzie dwa tygodnie wcześniej
>> oddany do testów a może nawet wdrożony do produkcji, co dać może tyle,
>> że znalezionych zostanie więcej błędów, niż znalazłby programista
>> czytający ustawę.
>
> To jest jeden z modeli, ja go nazywam UMLowym. Drugi jest taki, że
> programista rozumie co robi.

Rozumie, co robi, ale niekoniecznie zna dziedzinę równie dobrze, co
analityk. Jeśli analityk powie programiście, żeby zrobił źle, to
programista rozumiejąc, co robi, nadal tworzy program z błędem.

> Właśnie po to, żeby nie musiał czytać ustaw
> istnieje obieg informacji, tu: analityk pytany przez programistę.

Jak najbardziej, ale jeśli analityk przekazał już programiście
informację potrzebną do implementacji programu, i możne nawet
wytłumaczył dlaczego i po co na tyle, na ile da się szybko wytłumaczyć,
to spędzanie dodatkowo potencjalnie długiego czasu na szczegółowym
tłumaczeniu dlaczego tak, a nie inaczej, wydaje mi się mało produktywne.
Jeśli analityk mimo zgłoszonych wątpliwości jest pewien, że tak jak
mówi, jest dobrze, to lepiej albo wypuścić program robiący właśnie tak i
ewentualnie potem poprawić, albo zatrudnić lepszego analityka.

> Rozumiejąc kontekst społeczny pytania analityka jako tego wyżej przez
> programistę jako tego niżej dodam, że może warto zatrudniać ludzi, którzy
> wiedzą, jaką spełniają w danym momencie rolę. Istnieją różne modele
> współpracy analityków i programistów, również (?) takie, gdzie analityk
> mówi, dlaczego A jest niemożliwe, a programista dlaczego B jest
> niemożliwe - a wtedy najczęściej trzeba kreatywnie wypracować
> jakieś rozwiązanie C.

Pełna zgoda. Ale przecież też programista może powiedzieć, że coś jest
niemożliwe bez konieczności tłumaczenia analitykowi teorii obliczeń,
teorii złożoności, założeń paradygmatów programistycznych, problemów
wynikających z duplikacji, synchronizacji wątków albo Liskov
Substitution Principle. Dla analityka też powinno wystarczyć, że jak
programista mówi "niemożliwe/trudne/niepraktyczne", to jest pewien limit
pytania "dlaczego" po którym sensowną odpowiedzią będzie tylko "uwierz
mi, że tak właśnie jest".

>> Nawet jeśli douczony nie znaczy idealny, to nadal nie ma żadnego
>> argumentu. No i odnosiłem się do tego, że przedstawiłeś temat jako
>> niepojęty, w któym nic się nie da wiedzieć. Jeśli tak jest i głupek
>> wioskowy może mieć rację równie dobrze co fachowiec, to żadnych
>> fachowców nie potrzebujesz, ale też bez sensu żeby programista czytał
>> ustawę, skoro nawet twórca ustawy nie wie, co znaczy jej treść - niech
>> zrobi po uważaniu, najlepiej tak, żeb było najprościej.
>
> Nie zauważyłem wcześniej argumentacji o niezatrudnianiu analityków,
> a tylko o rozmowie pomiędzy pracownikami. Oczywiście to żaden argument.

Była argumentacja, że analityk nic nie wie, bo nikt nic nie wie. Otóż
nawet jeśli nikt nie wie na dany temat wszystkiego, to są tacy, co
wiedzą więcej on innych. No chyba że chcesz zatrudnić specjalistę od
diety różowych jednorożców.

>> Przepływ informacji jest jak najbardziej potrzebny, ale on też jest
>> możliwy bez czytania ustaw przez programistę.
>
> Ale najczęściej zawodzi, gdy ktoś mówi "tak ma być" i nie jest prezesem
> i nie zrobi przy tym jakiegoś przyjaznego gestu.

Można wprowadzić zasadę, że kto mówi "tak ma być" stawia kolejkę :)

>> W ukłądzie, o którym mówię, odniesiebnie sukcesu przez nową firmę jest
>> jak najbardziej możliwe, np. w scenariuszu gdzie doświadczeni analitycy
>> (albo chociaż spece od faktur) dogadują się z doświadczonymi inżynierami
>> oprogramowania i zakładają spółkę.
>
> Jeżeli mogę spytać: czy to prawda, że często takie firmy powstałe przez
> pączkowanie pozostają jako podwykonawcy?

Nie wiem jak często, na pewno nie tak, że "prawie zawsze". Ja się raczej
spotkałem z sytuacjami, że idą do klientów firm, dla których poprzednio
pracowali.

> I chciałbym też zauważyć, że
> powstają firmy, które z początku mają dwóch pracowników, studentów,
> którzy są jednocześnie prezesami.

Chyba większość takich firm bankrutuje albo się rozpada?

> Argument nie jest "czy programista zna ustawę lepiej niż analityk
> ds. Opisanych w Ustawie" tylko, jak widzę, "programista ma nie czytać
> ustaw" i "ma nie pytać analityka dlaczego tak". Nawet jak faktycznie
> coś zauważy.

Nie mój argument.

> Dla poparcia cytat:
> AJ:
> Raczej trzeba
> się nastawić na to, że fachowiec powie jak ma być, proramista napisze
> program, który to właśnie robi, potem fachowiec powie, że może być
> jeszcze inaczej, i programista to zaimplementuje, potem fachowiec powie,
> że tak, jak mówił na początku, że ma być, to nie może być jak cośtam itd.

Przecież nie dlatego, że programista nie może pytać dlaczego, tylko
dlatego, że życie jest skomplikowane.

do góry