zarządzanie projektami – Jarosław Żeliński IT-Consulting

Marsz ku klęsce – Poradnik dla projektanta systemów

Post author:Jarosław Żeliński
Post published:1 stycznia 2022
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:4 stycznia 2022

Lektura na Nowy Rok... Co prawda wydana w 2007 roku, ale właśnie sobie o niej przypomniałem.. Ta książka Yourdona leży u mnie na półce niemalże od dnia jej wydania, gdy ją przypadkiem upolowałem, zaraz po jej ukazaniu się w księgarniach. Napisanie o niej odkładam od lat, bo praktycznie nie ma tam obrazków UML, opisów wzorców itp.. Od jej przeczytania mówię sobie: jutro o niej napiszę... i to trwało do tego momentu. To książka w całości napisana prozą, bez obrazków, w której autor dzieli sie swoimi przemyśleniami na temat architektury systemów,…

Czytaj dalej

Konformizm w projektach

Post author:Jarosław Żeliński
Post published:5 czerwca 2014
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:27 sierpnia 2014

Na koniec największy mit: analiza jest prosta, wystarczy wiedzieć jak ją wykonać i mieć właściwe wzorce dokumentów. Nic tej tezy nie potwierdza, a tak wielu próbuje... Znam masę przypadków, gdy ktoś uznał, że przyuczona grupa pracowników sama wykona analizę wymagań, w końcu to tylko spisywanie potzreb. Niestety nie znam żadnego przypadku gdzie, na bazie tak spisanych wymagań, projekt zakończył się sukcesem. Jest zresztą prosty sposób na ocenę jakości dokumentu opisującego wymagania: skonfrontowanie go z tym co w końcu powstało.

Czytaj dalej

Jak skonstruować umowę Agile?

Post author:Jarosław Żeliński
Post published:30 grudnia 2013
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:30 grudnia 2013

Czy się to komuś podoba czy nie, jak na razie, nie ma żadnych "zwinnych umów", są umowy zlecenia (umowa starannego działania) i o dzieło (umowa efektu). Zaś w kwestii zakwalifikowania danej umowy do jednej z powyższych, decyduje jej treść a nie tytuł. Umowa Zlecenia, co ciekawe, nie zawiera pojęcia "licencji" czy "praw", te zawiera umowa o dzieło (tak zwana umowa efektu). Tak więc polecam Państwu krótkie konsultacje z prawnikiem, przed zawarciem "zwinnej umowy", by ocenić jakie ryzyko podejmujecie, bo w umowie zleceniu, wykonawca - pracując i pobierając wynagrodzenie - nie podejmuje żadnego ryzyka, nie licząc, możliwości zerwania trwającej umowy z wykonawcą (co niestety bardzo często ma miejsce w przypadku projektów programistycznych). W takich umowach 100% ryzyka bierze na siebie Klient.

Czytaj dalej

Dlaczego tradycyjne metody zarządzania nie działają w projektach internetowych?

Post author:Jarosław Żeliński
Post published:18 września 2013
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:19 września 2013

Jest dość liczna grupa ludzi uważająca, że w Internecie nie obowiązują ani prawa fizyki, ani prawa ekonomii ani nawet zdrowy rozsądek. W kwestii inżynierii oprogramowania ludzie Ci straszą świat projektów "mitycznym wodospadem" jak kiedyś dzieci straszone były Babą Jagą. [dzień po napisaniu: po dyskusji - patrz treść pod tym wpisem - a autorem cytowanego tu artykułu, doszliśmy do wniosku, że nie różnimy się zbytnio w poglądach, jednak zbytnie uproszczenie treści miało prawo wprowadzić mnie w błąd, jednak mój artykuł pozostanie w pierwotnej treści bo polemizuje głównie z pewnym mitem a…

Czytaj dalej

Bezpieczny jak email czyli wcale

Post author:Jarosław Żeliński
Post published:9 sierpnia 2013
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:9 sierpnia 2013

Korzystanie z własnego repozytorium daje ochronę bo: my nim administrujemy, w przeciwieństwie do sieci Internet, nie da się go "podsłuchiwać", i co najważniejsze: dokumenty są w sposób jednolity skatalogowane, wersjonowane itp. Jeżeli jedyne miejsce z dokumentami, ich wersjami itp, to nasze skrzynki pocztowe, to znaczy, że nikt nie ma wiarygodnej, kompletnej wiedzy o projekcie.

Czytaj dalej

nie istnieją proste rozwiązania złożonych problemów

Teoria a praktyka – czyli kompetencyjna tragedia

Post author:Jarosław Żeliński
Post published:13 maja 2013
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:12 września 2018

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).

Czytaj dalej

Sabotaż dokumentacyjny

Post author:Jarosław Żeliński
Post published:24 kwietnia 2013
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:25 listopada 2020

Dwa lata temu cytowałem: Jakie są najczęstsze problemy w nieudanych projektach? [...] 83% projektów korzysta z dokumentów tekstowych oraz arkuszy kalkulacyjnych do przechowywania wymagań, 40% projektów korzysta z emaili do zbierania wymagań i komunikacji z klientem.Brzmi to dla Was znajomo? (źr. Raport Jama Sofware ? O wymaganiach). Dzisiaj będzie kontynuacja powyższego o tym, dlaczego część projektów kosztuje znacznie więcej niż mogła by kosztować, dlaczego pewne projekty nigdy nie przekroczą pewnego progu jakości. Dzisiejszy wpis adresuje dla wszystkich sponsorów projektów, którzy chcą wiedzieć co zjada ich pieniądze jak szarańcza plony... To lista antywzorców.…

Czytaj dalej

No to była mała porażka… piszę ku przestrodze

Post author:Jarosław Żeliński
Post published:16 kwietnia 2012
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:19 kwietnia 2012

Nie będę tu opisywał szczegółów tego projektu, ważne są wnioski a nie ta czy inna firma:pominięcie któregokolwiek etapu projektu analitycznego, w szczególności pierwszego, powoduje, że całość staje się nieweryfikowalna, ryzyko rośnie, ukrycie prawdziwego celu projektu przed analitykiem (jest to możliwe, jeżeli dojdzie to tego co powyżej) powoduje, że większość jego czasu pracy nie służy projektowi, po zanegowaniu efektów pracy analityka, obrona takiego projektu jest niemożliwa bo brak kluczowego narzędzia: śladowanie (przypomnę, że usunięto pierwszy etap - zdefiniowanie celu). Co było prawdziwym celem projektu? Okazało się, że "nie chcemy by przetarg wygrała firma XXX i jej produkt". W trakcie pierwszych problemów z "uznaniem" specyfikacji wymagań dostałem listę wad posiadanego oprogramowania. Ku mojemu zaskoczeniu były tam nawet błędy rachunkowe (inne tu pominę, choćby niezgodność programu z prawem). Pytam: jakim cudem to zostało odebrane i zapłacone? Cóż...

Czytaj dalej

HARD FACTS ON BUSINESS ANALYSIS

Post author:Jarosław Żeliński
Post published:15 listopada 2011
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:21 września 2022

? 70% of all project failures are as a result of poor requirements. ? There is a 60% time and cost premium to be paid on projects with poor quality requirements. ? As the projects get more interdepartmental and complex, the failure rate rises. ? It costs 80 times as much to fix defects after delivery, than at the specification stage. ? 74 per cent of all companies have immature requirements practices. ? Large scale systems project fail with alarming regularity. A typical project over-ran its budget by 189% and over-ran its schedule by 222%. ? Average project has about 30% rework. This means that for every Kshs 1,000,000, Kshs 300,000 is spent redoing something that was thought to be complete. ? The average company with low requirements maturity wastes 34% of the organization?s IT development budget. ? 68% of companies simply did not use the necessary competency in requirements discovery at the start of their project to assure project success. Source: IAG Business Analysis Benchmark, 2008 (za HARD FACTS ON BUSINESS ANALYSIS | LinkedIn).

Czytaj dalej

Po co dokumentować – wnioski po dyskusji na forum

Post author:Jarosław Żeliński
Post published:26 listopada 2010
Post category:Analizy biznesowa i projektowanie oprogramowania
Post last modified:5 września 2022

Dokumentacja stanowi także element zarządzania wiedzą. Gdy nie ma dokumentacji nowy człowiek w zespole zajmuje czas kolegów, którzy muszą mu "opowiedzieć" o projekcie, jak jest dokumentacja, czyta ją sam nie obniżając efektywność pracy kolegów.Tak więc dla jasności: nie neguję typowej dla SCRUM czy XP wersji postępowania, a tylko wskazuje na sytuacje gdy preferowane są inne. Co do Agile podsumuję moje podejście: PMI czy Prince2 to dla mnie raczej formalny spis treści "projektu" ale dla każdego rzeczywistego projektu sam dobieram te elementy tego spisu, które mi pomogą i tak pojmuję zwinność projektową.

Czytaj dalej

Koniec treści

Nie ma więcej stron do załadowania