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:
(źr. Mega projekty…)
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ślony cel 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 metody w 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:
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.
Pisząc o projektach piszę o nich w kontekście BIZNESOWYM, a nie o projektach stricte programistycznych.
To czego dotyczył artykuł to tego, że w startupach (projektach internetowych – takie uproszczenia miałem na myśli) działanie modelu biznesowego to tylko hipoteza. Prognozujemy że on będzie działał. Jeśli na podstawie tej hipotezy potem tworzymy zakres projektu (czyli nasz trójką projektowy), to potem może się okazać że tworząc oprogramowanie (niezależnie jaką metodyką) zrobimy je świetnie od strony inżynierskiej. Tylko po co, jak biznesowo (po pierwszym zderzeniu z rynkiem) nie ma ono sensu.
Metoda Lean Sartup którą proponuję nie ma żadnego związki z tworzeniem architektury oprogramowania, czy sposobie podejście do projektu od strony informatycznej/inżynierskiej. Skupia się na jak najszybszym weryfikowaniu hipotezy modelu biznesowego, a nie wytwarzaniu oprogramowania.
Cieszę się, że końcowo właściwie się zgadzamy: “startupy to projekty inne z ich natury biznesowej, a nie technicznej” (więc wymagają one innego zarządzania biznesowego) oraz że nie warto mylić tych pojęć. Jeśli przyjrzy się Pan blogowi dokładniej, to zobaczy że jest on skierowany do młodych przedsiębiorców, a nie inżynierów, architektów czy project managerów systemów biznesowych. Tych zapraszam na http//analizait.pl/.
Tak to odebrałem, i tez sądzę że się zgadzamy, moje małe ’emocje” wzbudziło nie rozdzielenie tego “jawnie” :), co zresztą napisałem. Ludzie z reguły bardzo mylnie odbierają takie niedomówienia. Regularnie spotykam ludzi, łączących kwestie zarządzania firmą (biznesem) z narzędziami pracy jakie nabywają i warto to jawnie rozdzielać, bo potem są niespełnione nadzieje :).
Ciesze i dziękuje, że Pan odpisał 🙂
Cieszę się, że się zgadzamy 🙂 Przekaz artykułu, jego tytuł i użyte pojęcie “projektów internetowych” w wyrwaniu z kontekstu rzeczywiście może być niejednoznaczne. Artykuł był jednak rozszerzeniem tego co chwilę wcześniej prezentowałem na jednej z konferencji. Dla jej uczestników myślę, że był bardziej jednoznaczny 🙂
Ciężko byłoby mi w ogóle krytykować sam proces analizy i projektowania, bo prowadzę firmę która… właśnie tym się zajmuje 😉 (też Consulting IT).
Chętnie podyskutowałbym więcej na te tematy, ale internetowo pisane tekstów i komentarzy zajmuje strasznie długo czasu. Mam nadzieję, że będzie kiedyś okazja powymieniać poglądy na żywo 🙂
Też mam taka nadzieję :), niewątpliwie jednak prognozowanie heurystyczne nie ma sensu 😉 w takich wypadkach.
Metoda lean startup, czy Customer development sprawdza się nie tylko w startup’ach, a koncentruje się właśnie na rozwiązywaniu problemów, tyle że nie za pomocą analizy ale hipotez i eksperymentów “na tych”, którym ma służyć rozwiązanie problemu. Kluczem do sukcesu jest również MVP, którego poprawianie kosztuje zdecydowanie mniej niż zmiany dostarczonego oprogramowania.
Nie neguje podejścia preferowanego i opisanego przez Jarka, sam tak pracowałem i wiem że może być skuteczne. Nie mniej jednak na takie metody uważam że stać dzisiaj jedynie organizacje o stabilnej sytuacji rynkowej. Tak w skrócie 🙂
“koncentruje się właśnie na rozwiązywaniu problemów, tyle że nie za pomocą analizy ale hipotez i eksperymentów ?na tych?, którym ma służyć rozwiązanie problemu”. Mamy tu chyba nieporozumienie 🙂 ze słowami hipoteza i analiza, eksperyment rozumiemy tak samo :).
Hipoteza to nie losowo wybrane rozwiązanie a teoria powstała na bazie analizy, którą obalamy albo potwierdzany w praktyce. Rzecz w tym, że tu “analiza i budowanie hipotezy”, to nie kosztowna analiza setek czy tysięcy danych, tu “analiza” (hipotezy i jej dowodzenie) polega na zbadaniu relatywnie małej (nie raz bardzo małej) ilości danych i budowanie teorii (modele), która je wyjaśnia. Teraz albo uda się wskazać zdarzenie, którego ta kandydująca teoria (hipoteza) nie wyjaśnia (i obali hipotezę) albo nie, i do tego czasu dana teoria (model) jest prawdziwa. W inżynierii oprogramowania tym modelem jest model dziedziny systemu, w biznesie model biznesowy a to dwa różne modele (hipotezy). Ale o tym dalej.
I teraz: projektując oprogramowanie można analizować setki danych od użytkowników (ich wymagania, user story itp.), podejmować próby i tworzyć kolejne prototypy (to się często fałszywie nazywa formalnym procesem), albo na bazie niewielkiej ilości danych, opisujących zjawisko (tu organizację) starać się wychwycić i zamodelować logikę jej działania (tę którą chcemy zaimplementować) co się z reguły udaje ale wymaga to pewnego minimalnego czasu. Jaki jest problem? Pierwsza metoda nie wymaga zbyt wielu umiejętności poza cierpliwością do żmudnej pracy, to bardzo kosztowny proces bo zasobochłonny i długi. Drugi jest trudny (wymagane kompetencje analityka to stosowanie metod systemowych) ale droga do rozwiązania jest dość dobrze przewidywalna i trwa krócej, per saldo taki projekt – dobrze przeprowadzony – jest tańszy (poza wyjątkami przypadkowego znalezienia właściwego rozwiązania na samym początku metodą eksperymentów).
Ekonomicznie najgorsza metoda to rzucenie się od razu na kodowanie bez jakiejkolwiek analizy, bo przypadkowość jest tu największa a prawdopodobieństwo szybkiego znalezienia rozwiązania na początku tego procesu jest najmniejsze. Ogromna popularność tej metody wynika z tego, że to może robić praktycznie każdy i czasami się udaje (ale to pokusa jak LOTTO).
I tak: mając słaby model biznesowy (zła teoria) jakiekolwiek prognozy biznesowe są kiepskie, zaś analiza ogromnych ilości danych historycznych i badanie trendów nie działa, co autor już opisał. Jednak oprogramowanie to nie model biznesowy (rynkowy) tylko model narzędzia pracy, a to zupełnie co innego. Taki model zawsze można dobrze zrobić o ile ma się te minimum czasu. Problemem jest to, że nie raz czas wytworzenia oprogramowania nawet najlepszą metodą, jest dłuższy niż biznesowa perspektywa (okazja rynkowa) skorzystania z niego. I tu widzę problem decyzyjny menedżera: iść drogą zwinnego rzucenia się od razu na kodowanie bo jest szansa na sukces (nie znamy prawdopodobieństwa niestety), mała ale jak się uda to jest sukces, czy podejść pragmatycznie i zrezygnować czasem z niektórych zbyt ryzykownych start-upów. Tu faktycznie mamy małą ruletkę 🙂 i od tego są biznesmeni by w nią grali :D, byle świadomie.
Jarku, spodziewałem się takiej odpowiedzi. Słowem wyjaśnienia: za hipotezę przyjmuję przypuszczenie dotyczące rozwiązania problemu, które wymaga potwierdzenia, np za pomocą eksperymentów. Za analizę chciałbym przyjąć “idealny świat” opisywany przez Ciebie, ale niestety widziałem zbyt wiele bezużytecznych “analiz” i oprogramowania, którego nikt nie używa, bo nikt nie raczył zweryfikować z problemami użytkownika, w kontekście ich potwierdzenia i przyjętego rozwiązania, ufając swojej nieomylności i “analizom” i modelom dziedziny. Natomista model biznesowy traktuję jako zbiór hipotez do potwierdzonych problemów i ich rozwiązań.
Pozdrawiam
Rafal Kaminski
Ja mam za sobą projekty, gdzie przede mną szefowa sekretariatu wpisała do wymagań funkcję podpisywania orzeczeń sądowych przeterminowanym podpisem elektronicznym sędziego a w pewnej firmie dyrektor handlowy miał możliwość ominięcia limitu budżetowego wydatków. Ja nie opisuje świata idealnego, tylko świat w którym przełożony wydaje polecenia podwładnemu a nie odwrotnie. Wiele “upadłych” projektów, po których sprzątałem to były projekty, w których wymagania były efektem “oczekiwań użytkowników”, przypominały system wynagrodzeń ustalony oddolnie przez związki zawodowe. Wiem, że użytkownik może mieć wiedzę na temat jakichś elementów wygody pracy ale 2+2=4, wykrywam to i pilnuję by nie było 2+2=5. Zaczyna się często niepozornie np. od żądania (i zapisania a w wymaganiach) dopuszczenia ujemnych stanów magazynowych, kończy się na niewykonywalnym legalnie bilansie. Osobiście nie dopuszczam w projekcie braku logiki. Ja też regularnie widuję bezużyteczne analizy, generalnie dlatego, że to nie żadne analizy a stenogramy z warsztatów i wywiadów. Modele dziedziny jakie w nich widują to bezwartościowe obrazki odwzorowujące ten stenogramy albo taki bełkot jak np. ten (ten człowiek uczy analityków!): Szkolenie UML. Jeżeli to masz na myśli, to masz rację, to bezwartościowe analizy.
P.S.
Takie słowa jak hipoteza czy teoria mają swoje znaczenie w j. polskim i warto je stosować by nie popadać w nieporozumienia. Zmorą, nie tylko, dokumentów analiz jest ich niejednoznaczność…