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