Na blogu prof. Andrzeja Sobczaka ukazał się kolejny ciekawy artykuł, w którym autora zauważa, że:
Presja na uzyskiwanie jak najlepszych wyników w jak najkrótszym czasie powoduje bardzo duży nacisk na tzw. Time 2 Market (T2M) ? czyli jak najszybsze wprowadzanie produktu na rynek (biznes coraz częściej godzi się, że będzie to produkt nie do końca przetestowany, dopracowany,? ? ale będą dzięki temu pierwsi na rynku i wyprzedzą w ten sposób konkurencję ? zgodnie z zasadą ?kto nie ryzykuje, ten nie pije szampana?).
Dążenie do skrócenia T2M powoduje, że zmiany realizowane w organizacjach (czy to biznesowe, czy też technologiczne) mają charakter nieskoordynowany, punktowy, metodą ?na sznurki?. Skutkuje to tym, że realizacja tych zmian prowadzi do uprawienia realizacji fragmentu procesu biznesowego, pozwala na wprowadzenie nowego produktu na rynek, dostarcza nowej funkcjonalności dla departamentu/linii biznesowej. Ale organizacja rozpatrywana jako całość traci na tym. Po pierwsze rosną koszty utrzymania tak wdrożonych rozwiązań (czy to organizacyjnych, czy też IT). Po drugie coraz więcej czasu poświęcane jest na koordynację/uzgadnianie/wyjaśniania elementów, które od samego początku powinny ?składać się? w jedną całość. Wreszcie organizacja postrzegana holistycznie zmniejsza swoją elastyczność (rośnie jej entropia) (Źródło: Manifest nowego ładu zarządzania zmianami biznesowymi | Architektura Korporacyjna)
Myślę, że naciski na skracanie T2M to tylko czynnik narzucający wymagania. SJP mówi, że strategia to ?przemyślany plan działań w jakiejś dziedzinie?. Czym jest więc architektura korporacyjna (AK) dla strategii? A może czym powinna być strategia dla AK? AK zawiera w sobie architekturę aplikacji, które są jej ? AK- częścią. Jeżeli uznajemy (jeżeli) pryncypia takie jak ?aplikacja powinna być zamknięta na zmiany i otwarta na rozszerzenia?, to dlaczego by nie uznać, że ?architektura korporacyjna (także) powinna być zamknięta na zmiany i otwarta na rozszerzenia?? Wtedy strategia organizacji stanowiła by rodzaj polityki tworzenia i rozszerzania AK. Oczekujemy zwinności od aplikacji, oczekujmy tez od AK?.
Czy to się da? Myślę, że tak. W końcu dowolnie złożony system IT można sprowadzić do relatywnie małej liczby komponentów (to tylko kwestia poziomu hermetyzacji szczegółów). Z drugiej strony podział systemu na odrębne aplikacje jest sztuczny, wynika wyłącznie z zakresu projektu ich dostawców. To znaczy, że poszczególne komponenty można podzielić na te wolno-zmienne kluczowe, tak zwane domenowe, komponenty obsługujące scenariusze biznesowe oraz te obsługujące dialog użytkownika z systemem i oferujące użytkownikom usługi aplikacyjne (np. portale intranetowe). Szybkozmienny biznes nie raz wymusi nowe usługi, to czy będzie to zmiana w istniejącym czy nowy komponent to polityka budowy i zarządzania zmianą AK, powinna ona pomóc podjąć decyzje czy będzie on zamiast wprowadzania kolejnej (po co??) modyfikacji, efemerydą realizującą określoną logikę biznesową w określonym, mającym początek i koniec, okresie czasu.
Strategia organizacji to długo terminowe cele i polityka ich realizacji, konkretne roczne czy kwartalne działania to taktyki a nie strategia… Co więc robić? Przede wszystkim opisać strategię i politykę jej realizacji (strategia to plan ale polityka to reguły działania a nie opis działań). Polityka ta powinna wyznaczać także sposób budowy AK, która musi pozwolić na realizowanie strategii. Mają politykę, zbudować AK w zgodzie między innymi z zasadą, że ?architektura korporacyjna powinna być zamknięta na zmiany i otwarta na rozszerzenia?.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Wczoraj podczas spotkania, miałem ciekawą rozmowę z przedstawicielami jednego z producentów systemów ERP. Okazało się, że mają bardzo podobne do moich doświadczenia i wnioski: podczas wdrożenia systemu ERP potrzebny im jest ktoś, jeden, kto zna i rozumie jak działa dana firma, a nie setki stron dokumentacji czy stenogramy z dziesiątków godzin warsztatów z przyszłymi użytkownikami. Do tego firma ta – nabywca systemu ERP – powinna mieć, nie szczegółowo opisane dziesiątki detalicznie opisanych procesów i ich wariantów, procedur czy setki i tysiące nie raz wymagań, a strategię i taktykę, z której wynika (da się wyczytać) rola oprogramowania ERP w firmie: taktykę czyli opis realizacji strategii firmy z pomocą planowanego do wdrożenia systemu ERP. Ta taktyka, to opis tego kiedy i po co oprogramowanie ma wspierać pracownikw organizacji. To, jak się to będzie odbywało w szczegółach, zostanie opracowane przez dostawcę (wykonawcę) konkretnego produktu, to dostawca gotowego oprogramowania opracowuje koncepcję wdrożenia, na podstawie dokumentu opisującego taktykę użycia tego oprogramowania i wymagania biznesowe (oprogramowanie dedykowane wymaga dodatkowo zaprojektowania i udokumentowania logiki biznesowej jaką ma ono realizować).
I co teraz? Teraz potrzebne jest źródło spójnej wiedzy o organizacji, jej strategii i taktyce w którą ma się wpasować oprogramowanie ERP. Któż jest tym źródłem? [[Product owner]].
Pytane teraz brzmi: kim jest i członkiem czyjego zespołu jest (powinien być) „product owner”? Tu zacytuję ostani akapit mojej ciepłej jeszcze recenzji książki:
…na ile wizja produktu uprawnia jej posiadacza do aktywnego kierowania projektem wraz z kierownikiem projektu (Scrum Master), ale to pozostawiam czytelnikom i praktykom. Jedno moim zdaniem jest pewne: nie ma sensu by zespół developera kontaktował się, z tabunem przyszłych ?userów?, ma sens by dostawał spójną wiedzę o tym co tak na prawdę ma powstać.
Autor powyższej książki nie daje wprost odpowiedzi na to pytanie, jednak milcząco zakłada też, że to zespół dostawcy „walczy” ze zjawiskiem i product owner jest członkiem tego zespołu, nie zmienia to faktu, że wymagana od niego wiedza i zrozumienie tego, do czego user będzie używał oprogramowania, powinna być taka jak opisałem wyżej.
Co usłyszałem po raz kolejny (podobne rozmowy z dostawcami oprogramowania nie raz już prowadziłem) od przedstawicieli dostawcy systemu ERP? Potrzebują bardzo zwięzłej i spójnej dokumentacji (ale raczej 50-ciu stron niż setek, że nie wspomnę o kilku tysiącach (tak – widywałem takie) i po stronie klienta (jednej) osoby, która ten dokument zna, rozumie, ma dostęp do kluczowych osób w organizacji. Najchętniej do autora tego dokumentu… Dostawcy oprogramowania jak dostają listę setek pozycji wymagań podzielonych w mało zrozumiały sposób na funkcjonalne i poza funkcjonalne (i inne) raczej sobie z tych specyfikacji dworują niż cieszą się z ich otrzymania (pomijam, ze nie czytają w całości). Po co są więc robione? Bo zamawiający postrzega swoją pracę przez pryzmat jej złożoności, wariantowości, nie patrzy z perspektywy narzędzia a tym właśnie jest oprogramowanie. To tak jak by cieśla lub stolarz opisał wymagania na młotek ciesielski w postaci setek stron „user story” o tym jak, do czego i kiedy używa(łby) młotka.. dla analityka projektanta taki opis (a konkretnie jego skąpa część) ma sens, dla konstruktora – żadnego, ten raczej oczekuje rysunku technicznego wykonawczego.
The role of Product Owner (Scott Ambler, Agile Modeling)
Powyższy diagram to poglądowy model roli product ownera (PO) autorstwa jednego z moich ulubionych „zwinnych analityków”: Scott’a Amblera (Scott Ambler). Niewątpliwie można dywagować czy PO to „pracownik” dosatwcy czy kupującego ale tu chyba część wątpliwości rozwieją słowa jednego z moich klientów, postrzegam go jako jednego z lepiej zarządzających ryzykiem biznesowym, znanych mi, prezesów firm: „Panie Jarku nie wiem czy jest Pan lepszym czy gorszym specjalistą od ludzi dostawcy, zatrudniłem Pana bo przełożonym tamtych jest Prezes tamtej firmy”.
Where Do Product Owners Come From? The goods news is that there are several viable options for where Product Owners may come from: Business analyst. Although a traditional business analyst could fill the role of product owner, there is a risk that they will fall into their old habits of communicating via documentation. Keep in mind that what agile teams really need are people with agile analysis skills who are empowered to make decisions. So, a better option is an empowered agile business analyst. (za The Product Owner Role: A Stakeholder Proxy for Agile Teams).
Tak więc nasuwa się wniosek, że rolę PO powinien pełnić ten człowiek, który właśnie skończył analizę biznesową i napisał raport z niej. Raport, który zawiera specyfikacją wymagań (najlepiej w formie jak opisana powyżej). W zasadzie nadzór autorski nad realizacją taktyki wdrożenia systemu ERP (oprogramowania w ogóle) to nic innego jak „bycie product ownerem” w projekcie na etapie jego realizacji a SCRUM faktycznie, na dzisiejsze czasy, wydaje się być najlepszą metodą zarządzania takimi projektami a utrzymywanie aktualności dokumentu analizy biznesowej i wymagań w toku projektu prowadzi do tego, że po zakończeniu projektu mamy „niechcący” kompletną i aktualną dokumentacje stanu uzyskanego w toku wdrożenia.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Pełny tytuł książki to: Enterprise Architecture As Strategy: Creating a Foundation for Business Execution.
Bardzo ciekawa książka, autorzy dzielą się wynikami badan jakie prowadzą od 1995 roku a dotyczącymi sposobów opisywania i modelowania organizacji. Zaryzykuje tezę, że jednak opisywania gdyż w książce stosowane są nieformalne metody opisu (autorskie niesformalizowane schematy blokowe) jednak nie stanowi to gorszej jakości książki, gdyż autorzy dość wyczerpująco opisami swoje przemyślenia. We wstępie przyznają, że kluczowym „odkryciem” było dla nich to, że nie da się analizować złożonych systemów, jakimi są duże organizacje, bez „wzniesienie” się ponad szczegóły.
Opisują krok po kroku jak stworzyć i wdrożyć strategię zarządzania bazującą na architekturze korporacyjnej, którą definiują jako:
logika zorganizowania procesów biznesowych i zasobów IT, odzwierciedlająca wymagania na integrację i standaryzację jakie stawia model operacyjny organizacji
Autorzy podkreślają, że nie jest to projekt IT, zwracają uwagę, że kluczowy błąd jaki sami na początku popełniali, to brnięcie w szczegóły. Tworzenie monstrualnej ilości szczegółowej dokumentacji (do czego mają skłonność IT i firmy doradcze) niczemu nie służy. Na przykładzie kilku dużych korporacji, pokazują krok po kroku ja zbudować model i jak używać go jako narzędzia zarządzania podejmowania decyzji. Dedykowany rozdział poświęcili outsourcingowi.
Książka adresowana jest do wyższych kadr kierowniczych i takim też jest napisana językiem.
Enterprise Architecture As Strategy: Creating a Foundation for Business Execution Hardcover August 1, 2006, Harvard Business Press by Jeanne W. Ross (Author), Peter Weill (Author), David Robertson (Author) Amazon
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Ty razem krótko. Natchnął mnie artykuł kolegi, tu fragment tego artykułu:
Przede wszystkim nie istnieje coś takiego jak ?strategia krótkoterminowa?. Otóż jest to klasyczny oksymoron ? ?przenośne zestawienie pojęć o przeciwstawnym, wykluczającym się wzajemnie znaczeniu, np. spieszyć się powoli, sucha woda; antylogia, epitet sprzeczny?[1]. […] Nie dajmy sobie robić wody z mózgu. Nie istnieją te wszystkie ?strategie? albo nie są strategiami. To jest opis sposobu działania, plan działań, który nie jest strategią. Przyrównując do wojny, nie są to strategie, tylko taktyki pozwalające na wygranie poszczególnych bitew. Nie powinno się tego stosować nawet w odniesieniu do pojedynczej kampanii. To kampania komunikacyjna powinna być podporządkowana strategii marketingowej. (źr. Strategia krótkoterminowa | Filozofia marketingu).
W tym miejscu, tradycyjnie, przytaczam słownikowe definicje pojęć:
strategia ?przemyślany plan działań w jakiejś dziedzinie? ?dział sztuki wojennej obejmujący przygotowanie i prowadzenie wojny oraz poszczególnych jej kampanii i bitew? (Słownik języka polskiego).
taktyka ?sposób postępowania mający doprowadzić do osiągnięcia celu? ?dziedzina sztuki wojennej obejmująca teorię i praktykę prowadzenia walki przez jednostki różnych rodzajów wojsk? (Słownik języka polskiego).
Nie usuwałem definicji z dziedziny wojskowości, bo te terminy mają wojskowy rodowód. Jak widać, jest pewna różnica między strategią a taktyką. Tak więc wojny to raczej lata i ogólne założenia ich wygrywania – strategia ich prowadzenia. Poszczególne bitwy są konsekwencją zastosowanej taktyki, to raczej tygodnie lub co najwyżej miesiące. Patrząc więc teraz na te definicje przez pryzmat np. wiedzy o II Wojnie Światowej, jaką mamy np. ze szkoły podstawowej, widać, że zwrot „strategia krótkoterminowa” brzmi podobnie niemądrze jak „chwilowa wojna światowa”.
Stosowanie określonych terminów zgodnie z ich właściwymi znaczeniami ma głęboki sens. Rzecz w tym, by budowany „opis” (np. biznes plan, prospekt emisyjny, kontekst projektu IT), był nie tylko „powszechnie zrozumiały” ale o to by w ogóle miał jakiś sens. Bo to, że „ładnie i mądrze brzmi” w korporacyjnej dokumentacji to na dłuższą metę za mało.
Pojęcia te, strategia i taktyka, mają swoje odzwierciedlenie także w sformalizowanej formie w tworzeniu modelu motywacji biznesowej (BMM). Tu użyto oba te terminy i pokazano typowy kontekst ich użycia:
Jak widać (powyższy diagram wykonany zgodnie z regułami notacji BMM (http://www.omg.org/spec/BMM/) formalne, standardowe definicje i ich użycie w tym modelu, także pokazują, że taktyka to działania realizowane w relatywnie krótkim okresie, celem jest wspieranie przyjętej strategii organizacji. Ta ostatnia, to długoterminowo ustalane reguły biznesowe, które wyznaczają taktykę działania. Strategia działania jest konsekwencją misji organizacji, wspiera realizację celów. Taktyka to osiąganie konkretnych i mierzalnych działań na rzecz celów biznesowych.
Kolejnym etapem analizy biznesowej i planowania jest analiza SWOT, którą także dokumentujemy (można) notacją BMM, co opisałem już wcześniej w artykule A po co nam ten SWOT.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
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 nie tym autorem].
Poniżej kolejny tego typu „starszak” o znamiennym tytule „Dlaczego tradycyjne metody zarządzania nie działają w projektach internetowych?” Szczerze mówiąc jak to czytam, natychmiast przypomina mi się stare i wykpiwane w czasach stalinowskich, obowiązkowe wypracowanie w szkole na temat „Dlaczego kochamy Lenina” (bo, że go nie kochamy wtedy nie wchodziło w grę).
Tu mamy dość ciekawy przykład zastraszenia, autor cytowanego artykułu uważa, że projekty internetowe rządzą się innymi prawami:
Mamy pomysł, ustalmy zakres oraz harmonogram na najbliższe 7 miesięcy, realizujemy projekt i na końcu wprowadźmy produkt na rynek. Oczywiście za niemałe pieniądze. Czy warto tak szczegółowa planować swoje nowe przedsięwzięcia? Czy warto tak długo dopieszczać swój pomysł?
Jaką skuteczność w przewidywaniu przyszłości mają specjaliści? Takie pytanie zadał sobie przed 10 laty Philip Tetlock, znany amerykański psycholog. Przez dobrych kilka lat zbierał wśród międzynarodowej śmietanki analityków opinie na temat przyszłych wydarzeń ekonomicznych i politycznych. Udało mu się uzyskać ponad 82 tys. eksperckich przepowiedni. (Dlaczego tradycyjne metody zarządzania nie działają w projektach internetowych?).
Drobne ironie w stylu „za niemałe pieniądze” to próby manipulacji, które pomijam. Po pierwsze autor powołuje się wyniki badania, które potwierdza, że metody heurystyczne się nie sprawdzają jako metoda prognozowania, fakt znany od dawna w kręgach nauki (pisałem o tym w Mucha…) i faktem jest, że takie (na bazie wiedzy z okresów minionych) prognozowanie nie ma sensu. Tu z autorem pełna zgoda. Ale jak się to ma do projektów programistycznych? Nijak się nie ma, bo takich prognoz nikt rozsądny nie robi w projekcie.
W inżynierii oprogramowania nie prognozuje się , bo to domena biznesowa, w inżynierii oprogramowania dąży się do zrozumienia istoty problemu implementacji. Czy analiza i projektowanie to długie, szczegółowe i zbędne planowanie? Nie. Analiza ma za cel zrozumienie i podjęcie decyzji o sposobie implementacji. Jeżeli można tu mówić o planowaniu to raczej w kategoriach „jak planujemy zaimplementować” to rozwiązanie (którym jest spełnienie wymagań biznesu).
Owszem, można prowadzić implementacje metodą prototypów, błądząc, z nadzieją, że szybko (przypadkiem) stworzymy dobre rozwiązanie. Ale to w szczególności trudno zaplanować (a nawet start-upy maja budżety). Czy to jest tańsze? Nie sądzę. Nazywam to syndromem LOTTO: szybka decyzja bez planowanie daje pewne szanse na odkrycie poprawnego rozwiązania, jednak to to samo co uznanie, że można grając w LOTTO zarobić na bieżące życie aż do śmierci. Owszem, jest to możliwe, ale udaje się nielicznym (i wiemy dlaczego).
Start-upy niewątpliwie mają swoje prawa, i tu autor ma racje, twierdząc, że „nie ma czasu”, jednak nie prawdą jest, że:
Problem jest tylko taki, że wszystko, co na początku ustaliliśmy to zwykłe przewidywania naszych ?internetowych ekonomistów?. Całe nasze uzasadnienie biznesowe (model biznesowy) jest przewidywaniem, cały nasz złoty trójką projektu (czas, zakres, budżet) jest przewidywaniem. A jak dobrze wiemy, dzięki badaniom Tetlocka, ludzie przewidywać dobrze nie potrafią. Szczególnie w nowych warunkach.
Łączenie „trójkąta projektowego” z prognozami biznesowymi jest albo nieporozumieniem, albo niewiedzą, albo cynizmem: model biznesowy nie jest prognozą, model biznesowy to opis sposobu generowania wartości dodanej. Prognozą może być co najwyżej plan przychodów z tej działalności.
Bo po pierwsze w tworzeniu modelu biznesowego, nie ma mowy o przewidywaniu przyszłości a o analizie grupy docelowej. Wskazany zaś trójkąt projektowy (zakres, termin, budżet) to plan wytworzenia konkretnego oprogramowania (wspierającego ten model biznesowy). Owszem, tu – model biznesowy – można się pomylić, ale to nie pomyłka prognozowania tylko np. zła decyzja marketingowa. Teza, że np. „moje kapelusze będą miały duży zbyt w gronie snobów”, to nie prognozowanie a plan marketingowy. Prognozowaniem było by stwierdzenie, że „sprzedaż kapeluszy dla snobów osiągnie 10 tys. szt. w ciągu najbliższego roku” i tu faktycznie można się nieźle pomylić. Nie zmienia to faktu, że kapelusz to kapelusz i należy go zaprojektować i wytworzyć, oprogramowanie wspomagające sprzedaż kapeluszy przez internet (jego funkcjonalność) nie zależy od ilości sprzedaży (poza wydajnością całości) tylko od tego co i jak chcemy sprzedawać.
Jednak nie zmienia to faktu, że program wspierający sprzedaż tych kapeluszy wymaga pewnej analizy by zaprojektować model dziedziny tego oprogramowania, tu błąd kosztuje czasem tyle, że wymagany refaktoring (bez którego nie zrealizujemy np. kolejnej nowej potrzebnej funkcjonalności) ad-hoc pisanego oprogramowania zabije budżet całego projektu. To wygląda mniej więcej tak (źr. Znaczenie ma nie wielkość projektu…):
Powyżej wykres pokazujący koszty chwilowe (linia ciągła) i narastające (linia przerywana) projektu tworzenia i utrzymania oprogramowania. Linia zielona to proces z dobrze opracowanym projektem na początku, czerwona to projekt „na żywioł”.
Racje ma autor pisząc, że w przypadku start-upów może być dużym ryzykiem inwestowanie w projektowanie czegoś co może okazać się niewypałem, jednak trzeba pamiętać, że jeżeli projekt wypali, prawie na pewno będzie wymagał wtedy refaktoringu, by krzywa utrzymania była jednak bliższa tej zielonej (niskie koszty stałe to większa marża).
Wodospad, którym się „starszy dzieci” to przede wszystkim nie „liniowy” projekt na lata (czy jak u autora cytatów: 7 miesięcy start-up). Wodospad dzisiaj to jedynie uznanie, że trzy fazy: analiza, projektowanie, implementacja, są nierozłączne z czystego rozsądku. Prawda jest, że każda prognoza wiąże się z ryzykiem, jeżeli uznamy że jest ono duże (a z reguły jest), to nie planujemy jak kiedyś:
(typowy strukturalny proces), tylko dzielimy projekt na etapy (kolejne funkcjonalności) o długości na tyle krótkiej, by błędy prognozy były akceptowalne i nie niszczyły projektu. Wtedy projekt charakteryzuje się takim cyklem:
U autora cytatów znajdziemy bardzo podobny wykres, z jedną różnicą: tam jest to szukanie rozwiązania metodą prototypów, czyli każda dotychczasowa praca idzie do kosza. W tym przypadku, jest to przemyślany proces, powstały już kod nie jest wyrzucany, ale to wymaga dobrego projektu (szkieletu architektury), obiektowych metod i zastosowania wzorców analitycznych.
Autor artykułu pisze:
Mamy określonycel biznesowy. Nie wiemy, nie znamy i nie mamy łatwego dostępu do najważniejszego udziałowca ? użytkownika, nie wiemy, co zrobić, żeby spełnić cel biznesowy (zakres), tym samym nie wiemy, ile to będzie kosztować (budżet) i na kiedy się uda go osiągnąć (czas).
Wiemy natomiast, że na pewno będą zmiany i trzeba jak najszybciej z produktem projektu wejść na rynek.
Współczuję każdemu, kto w tak ekstremalnych warunkach, przy tak wielkim stopniu niepewności musi tradycyjnymi metodami realizować projekt.
Od razu przypomnę, że da się nowoczesnymi metodami tworzyć oprogramowanie odpowiadające powyższym wymaganiom: to ma już nawet nawet ładną nazwę: SOLID gdzie kluczową cechą jest to, że tak projektowane i wykonywane oprogramowanie jest „zamknięte na zmiany i otwarte na rozszerzenia” (nie mylić zmian kodu ze zmianą strategii sprzedaży), oznacza to, że kod nie wymaga zmian (refaktoring, odrzucanie prototypów) a pozwala na rozszerzenia (nowe wymagania). Metody obiektowe to nic innego jak odpowiedź na powyższe potrzeby. Jeżeli autor miał na myśli tradycyjne metodyw rodzaju „baza danych i funkcje” to jestem po jego stronie, też współczuję.
Paradoksalnie to co opisałem jest tańsze, bo niemalże nic nie idzie do kosza. Każdy etap jest krótki więc „prawie pewny”, niemalże żadna praca nie idzie na marne, system nie wymaga permanentnej refaktoryzacji. Co tu jest ważne: zachowujemy cykl: analiza, projektowanie, implementacja. Są to wtedy krótkie iteracje, ale zawsze kodowanie poprzedzamy analizą dziedziny. Druga ważna rzecz: nie da się tak prowadzić projektu metodami strukturalnymi (najpierw baza danych, potem funkcje) bo model bazy danych z zasady obejmuje całą dziedzinę problemu, a tej, jak słusznie zauważa autor, nie znamy (długoterminowa prognoza).
Druga wersja (opisana powyżej) jest relatywnie tania, można przerwać w dowolnym momencie i nie przeinwestować. Jednak rezygnacja z analizy, której celem jest zrozumienie problemu i zdecydowanie o sposobie implementacji to szukanie kłopotów takich jak ten:
Jak wygląda takie «wzorcowe” projektowanie opisałem w artykule Plansza do gry w szachy…
Na koniec co nieco o ryzyku:
(Karl Popper)
Tak więc nie ma metod jedynie słusznych (zwinne i niezwinne, itp.) , są tylko adekwatne do sytuacji projektowej.
Nie ma sensu straszenie ludzie problemami inżynierii oprogramowania z przed 30 lat (metody strukturalne analizy i projektowania, kosztowny waterfall)!. Mamy dziś rok 2013, dobrze rozwinięte metody obiektowe analizy, projektowania, modelowania, implementacji. Aplikacje biznesowe można wręcz liniowo tworzyć i rozwijać, wystarczy chcieć przejść na inne metody pracy niż te, których (niestety) nadal uczą na studiach: „funkcje + struktury danych = oprogramowanie” bo to prehistoria.
Tak zwane projekty internetowe to także oprogramowanie, tu także obowiązują „prawa fizyki i ekonomii oraz rozsądek”. Jeżeli coś je odróżnia o innych to użyta technologia „internetowa” a i to coraz mniej, bo obecne oprogramowanie biznesowe to coraz częściej„system dostępny przez internet”…
Na pewno wszelkie start-up’y to projekty „inne”, ale to wynika z ich natury biznesowej (ryzyko powodzenia) a nie technologicznej. Mylenie tych pojęć prowadzi do wniosku, że np. nowy samochód prototypowy konstruuje się inaczej niż „standardowy”.…nie, inaczej planuje się finansowanie ale deska kreślarska pozostaje ta sama…
A na tytułowe pytanie odpowiedź brzmi: nie istnieje taki problem.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Na blogu mojego kolegi pojawił się bardzo inspirujący wpis, zakończony prowokacją :):
Oczywiście ? jest to moja propozycja podejścia do tematu. Będę wdzięczny za Państwa opinie. (Strategia, model biznesowy, architektura korporacyjna ? jak to powiązać? | Architektura Korporacyjna).
Charakter mam taki, że na niektóre prowokacje odpowiadam :). Odpowiadam na swoim blogu, a nie bezpośrednio koledze na stronie jego bloga, gdyż zbyt duży tekst mi się „zrobił” :).
W projektach patrzę na pojęcia omówione w artykule chyba nieco (ale nie wiele) inaczej. Najpierw, zamiast cytatów z literatury, definicje słownikowe:
wizja: czyjeś wyobrażenie jakichś zdarzeń mających zajść w przyszłości, zwykle przedstawiane w książce lub w filmie,
misja: posłannictwo, ważne odpowiedzialne zadanie do spełnienia
strategia: przemyślany plan działań w jakiejś dziedzinie,
taktyka: sposób postępowania mający doprowadzić do osiągnięcia celu,
Z perspektywy definicji przytaczanych w wyżej cytowanym artykule, nie widzę tu kolizji. Nadając kontekst biznesowy tym pojęciom, wizja to wyobrażenie pewnej hipotetycznej postaci świata (np. rynku). Misja to „nasze zadanie”, to czego się podejmujemy by tę Wizję urzeczywistnić. Strategia biznesowa to nic innego jak plan działań, przyjęty jako sposób realizacji wizji. Taktyka to sposób realizacji tego planu czyli implementacja strategii.
Gdybym miał w ten sposób opisać swoją działalność to napisał bym:
Moja wizją są projekty, realizowane w sposób sprowadzający ich ryzyko do zera. Misją moją jest zdobywanie i krzewienie wiedzy pozwalającej realizować projekty idealne. Strategia jaka przyjąłem, to samodzielne studia, wykonywanie zawodu analityka i dzielenie się zdobytą wiedzą. Taktyka dzielenia się wiedzą to prowadzenie szkoleń, wygłaszanie referatów na konferencjach i prowadzenie bloga.
Ponad sześc lat temu pisałem o modelu biznesowym:
Poprawnie wykonany model biznesowy opisuje i definiuje zarazem:
Wygląda więc na to, że model biznesowy to w zasadzie taktyka realizacji (jakiejś ustalonej ) strategii (rynkowej).
Połączenie pojęć: misja, wizja, strategia, taktyka oraz architektura korporacyjna, jak je wykonać? W artykule Nowa specyfikacja Business Motivation Model 1.2 znajdziemy taki oto diagram:
Przedstawia on między innymi powyższe pojęcia i ich wzajemne powiązania. Jak widać, są to pojęcia zgodne z przytaczanymi definicjami (polecam lekturę specyfikacji modelu pojęciowego i notacji BMM). Wizja to stan końcowy, misja jest elementem zbioru „środków służących do osiągania wizji”. Mamy tu: misję oraz powiązaną z nią strategię i taktykę (jako implementację strategii).
Gdzie tu Architektura Korporacyjna? Andrzej Sobczak (autor cytowanego artykułu) przytacza taką definicję:
architektura korporacyjna (w jednym z jej ujęć) to formalny opis struktury i funkcji komponentów korporacji, wzajemnych powiązań pomiędzy tymi komponentami oraz pryncypiów i wytycznych zarządzających ich tworzeniem i rozwojem w czasie. Przy czym komponent korporacji definiowany jest jako dowolny element korporacji, który służy do jej konstruowania; mogą to być ludzie, procesy, fizyczne struktury jak również systemy informatyczne. (Strategia, model biznesowy, architektura korporacyjna ? jak to powiązać? | Architektura Korporacyjna).
I teraz warto zwrócić uwagę na to, że „formalny opis struktury i funkcji komponentów korporacji, wzajemnych powiązań pomiędzy tymi komponentami” to struktura organizacyjna. Dalej mamy opis „pryncypiów i wytycznych zarządzających ich tworzeniem i rozwojem w czasie” czyli wizje, misję, strategię oraz taktykę firmy, decyzje jej Zarządu. Patrząc na stwierdzenie, że „komponent korporacji definiowany jest jako dowolny element korporacji, który służy do jej konstruowania; mogą to być ludzie, procesy, fizyczne struktury jak również systemy informatyczne” należy uznać, że strukturę organizacyjną należy uzupełnić wiedzą o narzędziach jakie Ci ludzie dostają by pomagały im realizować ich zadania, czyli między innymi systemy informatyczne (tak, one są jedynie narzędziami).
Pozostał nam fakt, że to powinien być „formalny opis”. Zaglądamy do Encyklopedii PWN i czytamy:
język formalny: (inform.) język złożony ze wszystkich słów (wyrażeń) uzyskiwanych za pomocą ściśle określonych reguł;
Czyli potrzebna jest notacja (system pojęciowy: przestrzeń nazw). Jak widać mamy do dyspozycji BMM, który „pasuje” do omawianego problemu. Uzupełniona systemami pojęciowymi „dziedzinowymi” czyli BPMN (procesy biznesowe powiązane z zasobami) oraz UML (struktury i systemy) mam kompletny i spójny pojęciowo (dba o to organizacja OMG) zestaw narzędzi stanowiący w moich oczach odpowiedź na tytułowe pytanie.
I teraz moja konkluzja: bazując na „brzytwie Ockhama” podjąłem próbę sprawdzenia czy przypadkiem odpowiedź na tytułowe pytanie sformułowane przez Andrzeja, już nie istnieje… Odnoszę wrażenie, że właśnie prace OMG, ich wynik, są chyba odpowiedzią na to pytanie. Faktem jest, że nie wprost, ale chyba analizując te systemy pojęciowe, architekturę korporacyjna oraz BMM, można uznać, że tytułowe powiązanie istnieje. Opisałem to z nieco innej strony w artykule Architektura Korporacyjna z OMG.
BIO: Od roku 1991 roku, nieprzerwanie, realizuję projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzę także samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzę wykłady i laboratoria (ontologie i modelowanie systemów informacyjnych, aktualnie w Wyższej Szkole Informatyki Stosowanej i Zarządzania pod auspicjami Polskiej Akademii Nauk w Warszawie. Oświadczenia: moje badania i publikacje nie mają finansowania z zewnątrz, jako ich autor deklaruję brak konfliktu interesów.
Strona używa plików cookie, aby zapewnić Ci wygodę przeglądania poprzez zapamiętywanie Twoich preferencji i powtarzających się wizyt. Klikając "Akceptuj wszystko", wyrażasz zgodę na użycie WSZYSTKICH plików cookie. Jednakże, możesz odwiedzić "Ustawienia plików cookie", aby zapewnić kontrolowaną zgodę.
Ta strona korzysta z plików cookie, aby poprawić wygodę podczas podczas przeglądania witryny. Pliko cookie, które są sklasyfikowane jako niezbędne, są przechowywane w przeglądarce, ponieważ są niezbędne do działania podstawowych funkcji witryny. Używamy również plików cookie stron trzecich, które pomagają nam analizować i zrozumieć, w jaki sposób korzystasz z tej witryny. Te pliki cookie będą przechowywane w przeglądarce tylko za Twoją zgodą. Możesz również zrezygnować z tych plików cookie. Ale rezygnacja z niektórych z tych plików cookie może mieć wpływ na wygodę przeglądania.
Niezbędne pliki cookie są absolutnie niezbędne do prawidłowego funkcjonowania witryny. Ta kategoria obejmuje tylko pliki cookie, które zapewniają podstawowe funkcje i zabezpieczenia strony. Te pliki cookie nie przechowują żadnych danych osobowych.
Wszelkie pliki cookie, które mogą nie być szczególnie potrzebne do działania witryny i są wykorzystywane w szczególności do gromadzenia danych osobowych użytkowników za pośrednictwem analiz, reklam i innych treści osadzonych, są określane jako niepotrzebne pliki cookie. Wymagane jest uzyskanie zgody użytkownika przed uruchomieniem tych plików cookie w witrynie.
Functional cookies help to perform certain functionalities like sharing the content of the website on social media platforms, collect feedbacks, and other third-party features.
Cookie
Duration
Description
__atuvc
1 year 1 month
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
__atuvs
30 minutes
AddThis sets this cookie to ensure that the updated count is seen when one shares a page and returns to it, before the share count cache is updated.
bcookie
2 years
LinkedIn sets this cookie from LinkedIn share buttons and ad tags to recognize browser ID.
bscookie
2 years
LinkedIn sets this cookie to store performed actions on the website.
language
session
This cookie is used to store the language preference of the user.
lidc
1 day
LinkedIn sets the lidc cookie to facilitate data center selection.
na_id
1 year 24 days
The na_id is set by AddThis to enable sharing of links on social media platforms like Facebook and Twitter.
ouid
1 year 24 days
Associated with the AddThis widget, this cookie helps users to share content across various networking and sharing forums.
vc
1 year 24 days
The vc cookie is set by addthis.com on sites that allow sharing on social media.
Performance cookies are used to understand and analyze the key performance indexes of the website which helps in delivering a better user experience for the visitors.
Analytical cookies are used to understand how visitors interact with the website. These cookies help provide information on metrics the number of visitors, bounce rate, traffic source, etc.
Cookie
Duration
Description
at-rand
never
AddThis sets this cookie to track page visits, sources of traffic and share counts.
browser_id
5 years
This cookie is used for identifying the visitor browser on re-visit to the website.
CONSENT
2 years
YouTube sets this cookie via embedded youtube-videos and registers anonymous statistical data.
uid
1 year 24 days
This is a Google UserID cookie that tracks users across various website segments.
uvc
1 year 1 month
Set by addthis.com to determine the usage of addthis.com service.
Advertisement cookies are used to provide visitors with relevant ads and marketing campaigns. These cookies track visitors across websites and collect information to provide customized ads.
Cookie
Duration
Description
di2
1 year 24 days
AddThis sets this cookie on sites that allow sharing on social media. It is used to track user behaviour anonymously, to create usage trends that will improve relevance to their services and advertising.
loc
1 year 1 month
AddThis sets this geolocation cookie to help understand the location of users who share the information.
um
1 year 24 days
Set by AddThis for registering the user's sharing of content through social media.
VISITOR_INFO1_LIVE
5 months 27 days
A cookie set by YouTube to measure bandwidth that determines whether the user gets the new or old player interface.
YSC
session
YSC cookie is set by Youtube and is used to track the views of embedded videos on Youtube pages.
yt-remote-connected-devices
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt-remote-device-id
never
YouTube sets this cookie to store the video preferences of the user using embedded YouTube video.
yt.innertube::nextId
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.
yt.innertube::requests
never
This cookie, set by YouTube, registers a unique ID to store data on what videos from YouTube the user has seen.