Serwis korzysta z plików cookies.
        LOGOWANIE  /  REJESTRACJA      

10+3 główne powody, dla których projekty systemów się nie udają. Część II

Paul Dorsey

20 wrzesień 2015 roku

Trzynaście lat temu napisałem artykuł zatytułowany 10 powodów, dla których projekty systemów się nie udają. To był mój najczęściej czytany artykuł. Został wykorzystany na Harvardzie, dzięki czemu moja firma opracowała system finansowo-budżetowy dla rządu Etiopii. Dziesiątki profesjonalistów, absolwentów i pracowników naukowych zadawało mi pytania na jego temat. Ostatnio polska organizacja  zajmująca się zarządzaniem projektami poprosiła mnie o zgodę na przedrukowanie tekstu w swoim czasopiśmie. Pomyślałem, że będzie to dobra okazja do powrotu do tego tematu i jego ponownego przejrzenia.

Jestem zaskoczony niezmienną aktualnością tego artykułu. Projekty IT nadal nie udają się w z tych samych powodów, z których nie udawały się dekadę temu. Jednakże sądzę, że artykuł zasługuje na aktualizację z dwóch powodów. Po pierwsze, kolejna dekada mojej obecności w biznesie to uczestnictwo w większej ilości i większych projektów. Po drugie, świat zmienił się od czasu, kiedy napisałem ten artykuł. Wtedy architektura sieci internetowej była w fazie szybkiego wzrostu, choć jeszcze nie w pełni nastała jej era.

Dziesięć sposobów na gwarantowaną porażkę projektu budowy systemu

Poniższa lista była inspirowana rzeczywistymi błędami napotkanymi w prawdziwych projektach budowy systemu.

     1. Nieużywanie dokładnej metodyki, ponieważ pisanie kodu jest jedyną istotną sprawą.

Użycie uporządkowanej metodyki budowy systemu jest jednym z krytycznych czynników sukcesu w tego rodzaju projekcie. Z tego powodu, kilka lat temu, wraz z Peterem Koletzke zaproponowaliśmy metodę CADM (Case Application Development Method) jako następcę tradycyjnej metody CASE, którą wprowadził Richard Barker. CADM oparta jest na kilku centralnych koncepcjach. Po pierwsze, do budowy oprogramowania zastosowano podejście właściwe inżynierii produkcji. Takie podejście zwraca uwagę na punkty kontroli jakości, wskazując, gdzie w cyklu życia budowy oprogramowania (SDLC – Software Development Life Cycle) te punkty występują oraz jakiego rodzaju kontrole są niezbędne dla zapewnienia, aby każda faza została przez projekt z powodzeniem ukończona przed uzyskaniem gotowości do przejścia do fazy następnej. Jednoznacznie określone punkty kontroli jakości muszą być wskazane w każdym projekcie, który ma zakończyć się sukcesem. Na przykład, weryfikacja prawidłowości modelu formalnego po ukończeniu modelu danych jest często pomijanym krokiem, czego się później nierzadko żałuje. Z drugiej strony, w CADM punkty kontroli jakości były eliminowane tam, gdzie występowały naturalne punkty kontrolne. Na przykład przeprowadzenie migracji danych pomaga zweryfikować wiele aspektów architektury fizycznej bazy danych.

Drugim wielkim filozoficznym składnikiem CADM jest ścieżka audytu dla wymagań systemu. Włączyliśmy możliwość śledzenia wymagań poprzez SDLC, począwszy od ich gromadzenia, poprzez analizę, aż po ostateczne testy odbiorowe użytkownika na końcu całego procesu.

     2. Opracuj plan projektu, postępując wstecz od nieprzekraczalnego terminu ostatecznego.

Postępowanie wstecz od ustalonego terminu zakończenia projektu jest pewną drogą do gwarantowanej porażki systemu i niestety drogą bardzo powszechną w społeczności IT. Bywa, że menedżerowie podejmują decyzje o tym kiedy nowe lub zmodernizowane systemy powinny być gotowe, nie mając niezbędnej wiedzy technicznej dla prawidłowego określenia, czy to jest, czy nie jest osiągalne w danym czasie. Żaden projekt nie przeszedł całkiem gładko od Strategii do Implementacji. W SDLC jest wiele miejsc, gdzie harmonogramy mogą ulec odchyleniu:

  • Nieudana analiza skutkująca nowymi krytycznymi wymaganiami, które nie zostały uwzględnione w trakcie budowy systemu
  • Nieudana migracja danych
  • Niewłaściwa ocena klimatu politycznego organizacji względem projektu
  • Brak zatwierdzeń na wszystkich poziomach społeczności użytkownika.

Powinno się ustalić realistyczny terminarz ukończenia projektu budowy systemu, ale też spodziewać się że niektóre terminy ostateczne mogą się przesunąć, gdyż nieuchronnie pojawią się nieoczekiwane komplikacje. Próby dotrzymania ustalonych terminów na siłę doprowadzą do ścinania zakrętów, co znacznie zwiększy zagrożenia w projekcie. Nawet jeśli system powstanie, zwykle jego jakość jest niska, gdyż kolejne aplikacje tworzone są jedynie po to, aby doprowadzić projekt do końca..

     3. Nie przejmuj się modelem danych. Po prostu stwórz potrzebne tabelki.

Model danych jest jądrem systemu. Bez starannie opracowanego modelu danych, każdy system jest z góry skazany na fiasko, a przynajmniej na rozminięcie się z potrzebami i wymaganiami użytkownika.

Zawsze mnie zaskakuje, gdy zatrudniam programistę z kilkuletnim doświadczeniem, który nigdy nie widział modelu danych. A nawet jeśli pracował z modelami danych, nigdy nie widział, aby ktokolwiek starannie je audytował.

Równie mocno zaskakuje mnie, gdy w dużej instytucji finansowej nie ma żadnego modelu danych systemu, który zawiera kilkaset tabel. Gdy audytuję taki system, znajduję liczne wady o krytycznym charakterze, które pozwalają na wprowadzanie złych danych. W takich systemach, migracja danych do nowego systemu może zająć wiele miesięcy, ponieważ duża liczba przenoszonych danych wymaga oczyszczenia.

W najgorszym znanym mi przypadku, każdy z projektantów tworzył własne tabele i obsługujące je aplikacje. Wprawdzie projektant wiodący wszedł później, żeby zmusić te różne kawałki do współpracy. Nie trzeba chyba mówić, że system nigdy nie został ukończony.

Modele danych powinny znajdować się pod bezpośrednią kontrolą projektanta wiodącego. Każdy podsystem powinien być zintegrowany z całością przed rozpoczęciem budowania.

Modele powinny być projektowane i audytowane, i ponownie audytowane, i jeszcze raz audytowane, aż nie zostanie ani jeden ukryty błąd. Audyty najpierw powinny być przeprowadzone przez projektanta wiodącego. Dopiero potem powinien być wprowadzony zewnętrzny audytor, który przeprowadzi dodatkowy audyt.

     4. Zatrudnij projektanta wiodącego, który nigdy nie zbudował podobnego systemu. Zatrudnienie właściwego człowieka jest zbyt kosztowne.

Osoba obsadzona w roli Projektanta Wiodącego musi być doświadczona. On, czy też ona, powinni mieć w dorobku podobne, zakończone sukcesem projekty. Rola projektanta wiodącego jest podobna do roli wprawnego chirurga serca. Nie będziesz oczekiwał od lekarza rodzinnego, że przeprowadzi zabieg chirurgiczny mózgu lub dokona anestezji. Co do osoby odpowiedzialnej za techniczne aspekty projektu, krytyczne znaczenie ma posiadanie doświadczenia z budową systemów podobnego typu.

Oczywiście, taki zasób jest całkiem kosztowny – nie tak drogi jak nieudany projekt, ale mimo to drogi. Muszę przyznać, że zadziwiają mnie menedżerowie, którzy łatwo wsadzą pięciu lub dziesięciu konsultantów biorących 700 dolarów za dzień, ale odmówią przyznania, że dobre prowadzenie projektu będzie kosztowało kilka razy więcej. Mają więc duży zespół, który tworzy zły system za bardzo wysoką stawkę godzinową.

Moim ulubionym przykładem jest duża organizacja z 80 programistami, którzy nie mogli wyhodować systemu. W istocie, według menedżera, dokonany postęp był niewielki. Jednakże, ta sama organizacja nie chciała wprowadzić starszego projektanta wiodącego, który mógłby stworzyć solidne środowisko programistyczne oraz wyzwolić produktywność owych 80 programistów.

     5. Zatrudnij czterdziestu programistów żeby przyspieszyć pisanie kodu

Więcej nie zawsze znaczy lepiej. Jest to prawdziwe zwłaszcza w przypadku zespołów programistów. Projekt z kilkoma wprawnymi programistami, ostrożnie nadzorowanymi przez właściwego projektanta wiodącego, ma znacznie większe szanse powodzenia, niż taki, w którym hordy programistów dzień po dniu wyrzucają z siebie góry kodu.

W pewnym projekcie, gdzie byłem zatrudniony jako projektant wiodący, pracowało 40 osób. Zapytano mnie, których z nich potrzebuję, żeby projekt zakończył się sukcesem. Powiedziałem „20 osób mniej”. Myśleli, że żartuję, ale mówiłem serio. Jednakże była to firma doradcza, gdzie przerób był ważniejszy od wydajności.

     6. Zbuduj system w Javie, nawet jeśli większość zespołu myśli że Java to gatunek kawy,  a ty nie masz zamiaru kiedykolwiek umieścić systemu w sieci Web.

„Właściwe narzędzie do właściwej pracy.” To motto jest prawdziwe przy budowaniu systemów informatycznych, tak samo jak przy budowaniu domów. Jednym z problemów dla architektów systemów jest fakt, że dostępne narzędzia wielce wpływają na sposób, w jaki tworzy się systemy. Nawet podstawy procesu programowania są pod wpływem wybranych narzędzi. Upewnij się, że dostępne doświadczenie jest zgodne z wybranymi narzędziami programistycznymi.

Presja na Javę oraz Web z pewnością przyczyniła się do całkiem nowej kategorii niepowodzeń systemów. Pomimo wszystkiego, co się dzieje, nikt  nie zauważył, że środowisko Javy jest wciąż relatywnie niedojrzałe. Ciągle musimy się wiele nauczyć o Javie i programowaniu dla sieci web.

Jeden z klientów poinformował mnie ostatnio o zamiarze udostępnienia swoim klientom formularzy w sieci. Jednakże, ich baza użytkowników składała się z 20 użytkowników zlokalizowanych w tym samym budynku, lecz używających dwóch sieci. Taki system mógłby być łatwo wsparty przez prosty system klient-serwer, za stosunkowo niewielkie pieniądze. Inne przedsiębiorstwa ustanowiły oficjalne polityki, przewidujące iż nowe programy będą tworzone w Javie, bez względu na koszty tej decyzji czy też umiejętności programistów.

     7. Trzy miesiące przed wejściem systemu w życie, zleć młodszemu programiście przeprowadzenie migracji danych.

Faza migracji danych w projekcie może pochłonąć nawet do 30% łącznego czasu zasobów projektu. Typowo, ilość uwagi poświęconej temu w istniejących jest bardzo mała. Koszt migracji danych wydaje się być niewidzialny, do czasu aż będzie za późno. Najpowszechniejszym mankamentem w planowaniu migracji danych jest zainwestowanie w zbyt nieliczne zasoby. Wiele harmonogramów projektów pokazuje migrację danych na tle całego wysiłku programistycznego jako pojedyncze zadanie. Jednakże pod koniec projektu stanie się ewidentne, że migracja danych jest w istocie odrębnym projektem, wysoce uzależnionym od kilku modułów dostawczych właściwego projektu programistycznego.

Z tych powodów, bardzo ważne jest w każdym projekcie wyprzedzające zaplanowanie migracji danych. W szczególności, zastosowanie bardziej ogólnych, generycznych struktur danych, co jest pożądane z uwagi na wydłużenie okresu życia systemu, może spowodować znacząco bardziej złożone problemy przy migracji danych, aniżeli zaimplementowanie tradycyjnych rozwiązań.

Jako świadek licznych nieudanych projektów, nauczony gorzkimi doświadczeniami, wiem, że czekanie ze zleceniem komuś przeprowadzenia migracji danych do chwili, gdy koniec projektu ma nastąpić za trzy miesiące, nieuchronnie sprawi iż projekt się nie powiedzie.

     8. Przeskocz fazę testowania, ponieważ projekt jest mocno opóźniony.

Wdrożenie systemu do produkcji bez odpowiedniego przetestowania, jest jak skok do basenu bez sprawdzenia, czy jest w nim woda. Żaden system nie został stworzony kompletnie bez błędów. Czas spędzony na dogłębnym testowaniu systemu zanim pójdzie on do produkcji, może w dłuższej perspektywie oszczędzić wiele czasu.

W fazie testowej, powinno się opracować plan testów, opisujący nie tylko testy do przeprowadzenia, ale również sposoby postępowania w przypadku niepowodzeń lub niezgodności. Zwłaszcza w przypadku dużych systemów, oczekiwanie z rozpoczęciem testów aż do końca fazy budowania, jest niewykonalne. Musi być jakaś zakładka. Każdy z modułów, dostrojony i przetestowany na poziomie jednostkowym, jest dosyć stabilny, żeby móc zaplanować testy formalne.

Niekoniecznie prawdą jest, że każdy test lub niezgodność testów prowadzi do modyfikacji systemu jeszcze przed produkcją. W fazie testowej konieczne jest przeprowadzenie ponownego audytu procesu projektowania, przeprowadzenie testów na poziomie systemu i użytkownika, przeprowadzenie audytu jakości dokumentacji, przetestowanie wewnętrznych procedur sterowania, backupu oraz przywracania, i w każdym względzie upewnienie się co do sprawności systemu przed skierowaniem go do środowiska produkcyjnego.

Wiodący kontroler jakości powinien opracować plan testów. Użytkownicy powinni wziąć udział w określeniu przypadków do testowania, by mogli napisać skrypty testowe oraz scharakteryzować oczekiwania wobec systemu. Plan testów składa się z dwóch składników: podejścia oraz projektu. Podejście obejmuje techniki i narzędzia testowania, role i odpowiedzialność, metody wykrywania i rejestrowania błędów, proces kontrolowania zmian, proces ponownego testowania oraz opis środowiska testowego. Część dotycząca projektu obejmuje cele testu, testowane przypadki oraz skrypty. Plan testów jest ramą, w której przeprowadzane są testy różnego poziomu lub typu, tj. testy systemu oraz testy odbiorowe użytkownika. Powinno opracować się plan każdego typu testów.

W pewnym projekcie, w ramach którego pracowałem, firma nalegała na zrobienie testów poprzez przekazanie systemu do produkcji i pozwolenie klientom na znalezienie błędów. Kiedy system pełen błędów został skierowany do produkcji, klienci wpadli w furię.

     9. Zmień program, aby uwzględnić nowe krytyczne wymagania odkryte podczas końcowego programowania.

Ważne jest, aby zapobiegać rozpoczęciu „pełzania zakresu” w projekcie. Zawsze będą nowe wymagania do uwzględnienia, nieco lepsze sposoby zmodyfikowania twojego modelu danych i lepsze sposoby zaprojektowania aplikacji. Jeżeli nie ustanowiłeś formalnej zasady, która zapobiega „wpełznięciu” do programu większości dobrodusznych sugestii dotyczących możliwych udoskonaleń, twój program nigdy nie będzie ukończony. Kiedy już zamrozisz jakiś moduł dostawczy w dowolnej fazie procesu CADM, nie będzie on już zmieniony. Jedyny wyjątek od tej reguły występuje wówczas, gdy w architekturze programu zostanie odkryta pomyłka, która przeszkodzi w skierowaniu programu do produkcji. Jeśli nie egzekwujesz twardo i konsekwentnie reguł dotyczących tego, jakie zmiany są do zaakceptowania i mogą być wprowadzone, wówczas program będzie opóźniony o tygodnie, miesiące, albo w ogóle nie trafi do produkcji.

Kto decyduje o tym, co będzie zrobione i kiedy? W ciągu cyklu życia systemu powinien istnieć zespół zarządzający złożony z liderów projektu, przedstawicieli wyższego kierownictwa, jednego lub dwóch użytkowników, oraz, być może, administratora bazy danych (o ile w zespole nie ma nikogo z doświadczeniem w tej dziedzinie). Ten mały zespół zarządzający kontroluje proces CADM i albo dokonuje wszystkich przeglądów zadań, albo je deleguje odpowiednim osobom. Proces przeglądu i zapewnienia jakości jest krytyczny dla sukcesu procesu CADM i oba te procesy powinny być realizowane przez najlepszych. Oczywiście kluczową zasadą jest, że nikt nie może przeprowadzać przeglądu jakości jego lub jej własnej pracy.

W trakcie przechodzenia przez każdą fazę projektu, jest coraz więcej i więcej powodów do zmartwień, jeśli chodzi o zmiany we wcześniejszych fazach. W fazie analizy musisz się martwić tylko o zmiany w fazie strategicznej; podczas gdy w fazie projektowania, musisz się martwić o zmiany wymagań dla programu oraz o zmiany zakresu z fazy strategicznej. W każdej fazie, będziemy identyfikować wszystkie duże moduły dostawcze z wcześniejszych faz, oraz omawiać wpływ zmian na każdy z tych modułów. Idealnie byłoby, gdyby informacja przedstawiona była w gigantycznej macierzy, ze wszystkimi modułami dostawczymi wzdłuż jednej osi, i wszystkimi fazami wzdłuż drugiej, tak, aby jasno można byłoby zobaczyć wpływ zmiany każdego modułu na każdą z faz.

Systemy nie są dziełami sztuki, toteż gdy skończone, nie zawisną w galerii. Ze swej natury są strukturami ewoluującymi, które nieuchronnie wymagają poprawiania oraz kolejnych wersji. Każde wymaganie nie musi zawierać się w Wersji 1. Znacznie lepiej jest mieć system, który jest wystarczający i działa, niż doskonały system, który nigdy nie został ukończony.

     10. Kup gotowy program z półki i dostosuj go…  znacząco.

Jedyna skuteczna droga dla wdrożenia gotowego oprogramowania z półki sklepowej wymaga podjęcia na początku decyzji, że zamierzasz dostosować swój biznes tak, aby pasował do ograniczeń gotowego oprogramowania. Takie pakiety zazwyczaj narzucają określony sposób prowadzenia biznesu oraz oferują odpowiadający mu zestaw możliwości. Dlatego musi być podjęta decyzja, że pakiet jest dostatecznie dobry i że nie będzie dostosowywany.

Jeśli nie przestrzegasz tej filozofii, implementacja gotowego pakietu nie będzie ani tańsza, ani mniej ryzykowna niż budowanie systemu od podstaw. Słyszałem wiele straszliwych historii dotyczących wdrażania wielkich, znanych systemów ERP, aniżeli dotyczących systemów innego rodzaju.

Ostatnio, wracałem samolotem wraz z menedżerem, który opowiadał swoją straszliwą historię. Jego firma ma obroty rzędu 30 mln dolarów rocznie. Dwa lata temu sprzedano im duży, dobrze znany system ERP. Projekt był zamierzony na dwa lata i wart dwa miliony dolarów. Po dwóch latach i czterech milionach dolarów, projekt był ukończony  w 10-15%.

Konkluzje

Aby zapewnić sukces projektowi, należy pamiętać o kilku czynnikach:

  • Nie ścinaj zakrętów dla zasady. W dłuższej perspektywie skutkuje to niepowodzeniem systemu lub uzyskaniem systemu o niedostatecznych walorach, który nie zaspokoi potrzeb użytkownika.
  • Audytuj każdy duży moduł dostawczy i dąż do dokładności i poprawności.
  • Ostrożnie monitoruj wsparcie najwyższego kierownictwa dla projektu. Upewniaj się, że kierownicy są świadomi postępów zespołu.
  • Zabezpiecz dla projektu prawidłowego projektanta wiodącego.

Nie ma darmowych obiadków w inżynierii oprogramowania. Jeśli nalegasz na utrzymywanie niskich kosztów oraz pośpiech, wówczas pojawi się niska jakość, a ryzyko niepowodzenia będzie wyższe, niezależnie od tego, jak dobrze projekt będzie zarządzany.

Trzy dodatkowe powody, dla których projekty systemów się nie udają

     11. Nie jesteśmy lepsi w zmniejszaniu wskaźników niepowodzenia projektów IT (ale jesteśmy znacznie lepsi we łganiu na ten temat).

Najważniejsze jest tutaj to, że projekty doznają niepowodzeń równie często, co i przed dekadą. Pomimo zatem wszelkiego postępu, wciąż doprowadzamy nasze projekty do porażki. Nic się nie zmieniło w tym względzie.

Co się zmieniło, to sposób, w jaki przedstawiamy nasze niepowodzenia. Po pierwsze, obecnie więcej projektów to projekty gotowe, z półki, zatem klienci są zmuszeni do wydania milionów (lub dziesiątków milionów) dolarów z góry. Kiedy już inwestycja takiej wielkości została dokonana, trudno jest ją porzucić. Jeszcze trudniej zaś przyznać się do niepowodzenia. Wyobraź sobie, że jesteś menedżerem (lub co gorsza obieralnym urzędnikiem) i zmarnowałeś dziesiątki milionów dolarów, za które niewiele jest do pokazania. Sprawa wygląda mniej niekorzystnie, gdy pomożesz dostawcy zwalić wszystko na „zmiany w biznesie”, „zmiany zakresu” czy też „napotkanie nieprzewidzianych trudności”, niż gdy przyznasz, że tyle pieniędzy zostało zmarnowanych.

Ponieważ środowisko Java EE oraz kultura ograniczonego zaufania do baz danych przyczyniają się do wydłużenia czasu programowania i znacznie wyższych kosztów, rutynowo oglądam projekty, które dziesięć lat temu chętnie przyjąłbym do realizacji w jeden rok za kilka dolarów, dzisiaj zaś są to wieloletnie projekty z budżetami dziesięć i więcej razy wyższymi od tego, co uważam za uzasadnione. Dodatkowo, ledwie działające prototypy są często dostarczane dopiero po roku lub nawet później.

Czy projekt, (który dziesięć lat temu moglibyśmy zrealizować szybciej niż przez rok za dwa miliony dolarów, używając technologii klient-serwer) ukończony o czasie i poniżej budżetu (gdy budżet wynosi 30 mln dolarów a czas realizacji zajmuje pięć lat) jest sukcesem? Z pewnością był to sukces firmy konsultingowej oraz dostawcy gotowego pakietu oprogramowania.

     12. Nie odnosimy sukcesów w projektach, gdyż ich architektura jest zbyt złożona.

W starych czasach filozofii klient-serwer, jeden programista potrafił zaprojektować bazę danych, zbudować ekrany oraz raporty, umieścić je na dyskietce 3,5” oraz na komputerze klienta w czasie krótszym niż pół godziny.

Architektura współczesnych programów, korzystających z Java EE, jest znana z tego, że ma więcej ruchomych części niż kosztowny samochód sportowy. Programy te są trudne do zbudowania, jeszcze trudniejsze do utrzymania, a dodatkowo każdy z projektów opartych o Java EE jest zbudowany odmiennie od pozostałych projektów.

Kiedy system jest ukończony, istnieje wysokie prawdopodobieństwo, że będzie wyglądał jakby działał do czasu testu obciążeniowego lub skierowania go do produkcji, gdzie natychmiast zawiedzie.

     13. Niepowodzenie projektu jest spowodowane przez integratorów systemów, którzy właściwie nie „integrują systemów”.

Więcej pokładów biurokracji w projekcie to zazwyczaj zła rzecz. Zdarza się to najczęściej w dużych projektach (i prawie zawsze w dużych kontraktach rządowych). Jeśli główny (generalny) wykonawca nie wykonuje żadnej technicznej pracy, lecz tylko koordynuje wysiłki podporządkowanych uczestników projektu, wówczas projekt jest prawdopodobnie zagrożony katastrofą.

Pomimo wszelkich fantazji zorientowanych na usługi, oprogramowanie nie integruje się samoczynnie, bez zewnętrznej pomocy. Ktoś pracujący nad projektem musi przyjąć rolę głównego projektanta. Ta osoba właściwe musi odpowiadać za wszystkie techniczne aspekty projektu.

Projekt bez architekta, który jest prawdziwie odpowiedzialny, jest niczym statek bez kapitana. Nie trzeba dodawać, że ten architekt powinien wiedzieć, jak zbudować system.

 

Paul Dorsey

Założyciel i prezes Dulcian, Inc. (http://www.dulcian.com/), firmy konsultingowej doradzającej użytkownikom produktów Oracle. Dulcian specjalizuje się w hurtowniach danych, budowie systemów webowych i klienckich, oraz w produktach wspierających środowisko Oracle. Jest współautorem książek z serii Oracle Press, zatytułowanych Oracle Designer Handbook, Oracle Developer Forms and Reports: Advanced Techniques and Development Standards – razem z Peterem Koletzke, oraz Oracle8 Design Using UML Object Modeling – z Josephem Hudicka. Jest także zastępcą redaktora naczelnego SELECT Magazine i prezesem nowojorskiej Oracle Users’ Group. Prowadzi również blog pod adresem http://dulcian.com/category/blog/. Kontakt emailem (pdorsey@dulcian.com)

 

Tłumaczenie: Jacek Kobiela

 

Artykuł publikowany w magazynie „Zarządzanie Projektami” Nr 4(4)/2013

Podobne





Logo w stopce
KONTAKT

Portal zarzadzanieprojektami.org, Gdański Park Naukowo-Technologiczny
ul. Trzy Lipy 3, 80-172 Gdańsk
E-mail: biuro@e-zp.org
tel.: (+48) 501 794 318
Copyright © 2016. Wszystkie prawa zastrzeżone.
Projekt i wykonanie Interaktywna PIQUA