Yearly Archives: 2013

Read more about the article Nieudane wdrożenie systemu biznesowego – czy uczymy się na błędach innych

Nieudane wdrożenie systemu biznesowego – czy uczymy się na błędach innych

Jeżeli jednak okaże (analiza) się, że zakup programu ma pomóc, to należy opisać wymagania jakie taki program musi spełnić (wymagania wobec produktu). Te wymagania są podstawą do wyboru gotowego, dostępnego na rynku oprogramowania, lub decyzji o napisaniu dedykowanego, jeżeli poszukiwania nie dadzą pozytywnego rezultatu (ale etap szukania gotowego powinien dla zasady mieć miejsce). Dedykowane rozwiązanie wymaga jego zaprojektowania, to można (zalecane) zrobić przed wyborem wykonawcy lub zlecić wybranemu wcześniej wykonawcy. Wariant drugi naraża nas jednak na utratę panowania nad projektem bo wykonawca będzie forsował metody budujące mu marże a potem sam sobie świadczy nadzór autorski. Wbrew pozorom, angażowanie audytora projektu, który nie jest autorem dokumentacji wymagań nie wnosi nic, a komplikuje cały proces: taki audytor może jedynie ocenić zgodność działań projektowych z dokumentacją wytworzoną przez (audytowanego) wykonawcę, a w przypadku sporu i tak tu "władzę" ma autor projektu a nie audytor. I teraz: ogłoszenie przetargu na całość na początku tej drogi jest jak widać idiotyzmem bo nie mamy żadnej wiedzy by ocenić wynik pracy a dostawca żadnej by cokolwiek sensownie wyceniać. Pominięcie jakiegokolwiek z tych w/w opisanych etapów to podnoszenie ryzyka projektu, co mam na dzieję widać. Każde wymaganie może być zero jedynkowe na każdym z tych etapów, wystarczy chcieć i umieć. Owszem, można je dzielić na biznesowe itp... ale to tylko sztuczne podziały, po prostu podczas realizacji mamy już tylko etap i jego wymagania. (Nieudane wdrożenie systemu biznesowego - czyli uczmy się na błędach innych | LinkedIn). I tylko tu pojawia się pytanie jak w filmie MIŚ: a może to faktycznie ma być drogie i nieprzydatne a ja zupełnie bez sensu jestem tym zdziwiony?

Continue ReadingNieudane wdrożenie systemu biznesowego – czy uczymy się na błędach innych
Read more about the article User Stories, czym jest?

User Stories, czym jest?

Tak więc programista implementuje logikę biznesową, tę musi jednoznacznie udokumentować analityk, oraz zapewnia uzgodnioną jakość (wymagania pozafunkcjonalne). Ma więc dużo pracy... ale nie powinien podejmować prób wpływu na implementowaną logikę biznesową. Czyli np. "jako sprzedawca, dostaję od klientów zamówienia, na podstawie których muszę wystawiać faktury VAT", do tego analityk doda, np. po analizie otrzymanej partii dokumentów, strukturę zamówienia i faktury VAT oraz "algorytm" wyliczenia podatków. Jeżeli programista zaczyna "lepiej wiedzieć" od zamawiającego, forsując np. prostszą implementację, to znaczy, że przekroczył swoje kompetencje, sam sobie - jako developerowi - robi krzywdę psując to oprogramowanie bo klient i tak prędzej czy później na tych uproszczeniach "polegnie". Rolą analityka są także ewentualne negocjacje z zamawiającym, uproszczeń lub rozwinięć tego opisu. Czy analityk może być "pracownikiem" dostawcy? Jak sądzicie?

Continue ReadingUser Stories, czym jest?
Read more about the article Teoria a praktyka – czyli kompetencyjna tragedia
nie istnieją proste rozwiązania złożonych problemów

Teoria a praktyka – czyli kompetencyjna tragedia

Co jakiś czas czytamy o porażkach projektów w sferze publicznej, zapewniam, że są one nie takim rzadkim zjawiskiem w sferze prywatnej. Dlaczego nie czytamy o tym? Bo, na szczęście dla firm prywatnych, nie dotyczy ich ustawa o dostępie do informacji publicznej itp., projekt nabywa status "tajemnica korporacji"' i nikt nie wie poza tymi, co brali udział w projekcie. Miewam konsultacje, korepetycje, coaching itp. Pytany jestem często: "czy zdarza się Panu w projektach, że np. kierownik projektu mówi, że nie ważna jest jakość tych projektów tylko termin i protokół odbioru, klient i tak nie potrafi tego skontrolować". Powiem tak, zdarza mi się i wtedy odmawiam albo rezygnuje z udziału w projekcie, jednak ja nie mam umowy o prace i jestem nią szantażowany (jej utratą). Prawdę mówiąc nie wiem co mam tym ludziom mówić, poza powyższym oczywiście, ale i tak zawsze mówię: bądź uczciwy (co jest bardzo trudne).

Continue ReadingTeoria a praktyka – czyli kompetencyjna tragedia
Read more about the article Mucha – czyli jak staję się biurokratą

Mucha – czyli jak staję się biurokratą

Tak więc gdy trafisz na klienta myślącego prostymi schematami, opowiedz mu co proponujesz i nie narzucaj się. Klient, który "wie lepiej" - nie mówiąc Ci o tym - i tak pogrzebie Twoja pracę... A na początku zawsze ostrzegaj swoich klientów tak ja ja: "zanim zapytacie, bądźcie pewni, że chcecie poznać odpowiedź"... Niestety bywa tak, że klient na początku pokazuje, że przyjmuje z pokorą to co mówisz, a powie Ci o tym, że nie uznaje odpowiedzi dopiero jak ją pozna , wtedy jedynym co można zrobić jest wyjęcie segregatora, który zawiera zapisane wszystkie, zaakceptowane po drodze, kluczowe etapy tej współpracy... miej je zawsze. Drugim wyjście jest ... wyjście z tego projektu. Rada dla firm angażujących analityków: sprawdź czy przypadkiem angażowany analityk nie jest badaczem much... Rada dla angażowanych analityków: upewnij się, czy przypadkiem organizacja, która Cię angażuje, nie jest wioską szamana...

Continue ReadingMucha – czyli jak staję się biurokratą