Jest dość licz­na gru­pa ludzi uwa­ża­ją­ca, że w Internecie nie obo­wią­zu­ją ani pra­wa fizy­ki, ani pra­wa eko­no­mii ani nawet zdro­wy roz­są­dek. W kwe­stii inży­nie­rii opro­gra­mo­wa­nia ludzie Ci stra­szą świat pro­jek­tów ​„mitycz­nym wodo­spa­dem” jak kie­dyś dzie­ci stra­szo­ne były Babą Jagą.

[dzień po napi­sa­niu: po dys­ku­sji – patrz treść pod tym wpi­sem – a auto­rem cyto­wa­ne­go tu arty­ku­łu, doszli­śmy do wnio­sku, że nie róż­ni­my się zbyt­nio w poglą­dach, jed­nak zbyt­nie uprosz­cze­nie tre­ści mia­ło pra­wo wpro­wa­dzić mnie w błąd, jed­nak mój arty­kuł pozo­sta­nie w pier­wot­nej tre­ści bo pole­mi­zu­je głów­nie z pew­nym mitem a nie tym autorem]. 

Poniżej kolej­ny tego typu ​„star­szak” o zna­mien­nym tytu­le ​„Dlaczego tra­dy­cyj­ne meto­dy zarzą­dza­nia nie dzia­ła­ją w pro­jek­tach inter­ne­to­wych?” Szczerze mówiąc jak to czy­tam, natych­miast przy­po­mi­na mi się sta­re i wykpi­wa­ne w cza­sach sta­li­now­skich, obo­wiąz­ko­we wypra­co­wa­nie w szko­le na temat ​„Dlaczego kocha­my Lenina” (bo, że go nie kocha­my wte­dy nie wcho­dzi­ło w grę).

Tu mamy dość cie­ka­wy przy­kład zastra­sze­nia, autor cyto­wa­ne­go arty­ku­łu uwa­ża, że pro­jek­ty inter­ne­to­we rzą­dzą się inny­mi prawami:

Mamy pomysł, ustal­my zakres oraz har­mo­no­gram na naj­bliż­sze 7 mie­się­cy, reali­zu­je­my pro­jekt i na koń­cu wpro­wadź­my pro­dukt na rynek. Oczywiście za nie­ma­łe pie­nią­dze. Czy war­to tak szcze­gó­ło­wa pla­no­wać swo­je nowe przed­się­wzię­cia? Czy war­to tak dłu­go dopiesz­czać swój pomysł?

Jaką sku­tecz­ność w prze­wi­dy­wa­niu przy­szło­ści mają spe­cja­li­ści? Takie pyta­nie zadał sobie przed 10 laty Philip Tetlock, zna­ny ame­ry­kań­ski psy­cho­log. Przez dobrych kil­ka lat zbie­rał wśród mię­dzy­na­ro­do­wej śmie­tan­ki ana­li­ty­ków opi­nie na temat przy­szłych wyda­rzeń eko­no­micz­nych i poli­tycz­nych. Udało mu się uzy­skać ponad 82 tys. eks­perc­kich prze­po­wied­ni. (Dlaczego tra­dy­cyj­ne meto­dy zarzą­dza­nia nie dzia­ła­ją w pro­jek­tach internetowych?).

Drobne iro­nie w sty­lu ​„za nie­ma­łe pie­nią­dze” to pró­by mani­pu­la­cji, któ­re pomi­jam. Po pierw­sze autor powo­łu­je się wyni­ki bada­nia, któ­re potwier­dza, że meto­dy heu­ry­stycz­ne się nie spraw­dza­ją jako meto­da pro­gno­zo­wa­nia, fakt zna­ny od daw­na w krę­gach nauki (pisa­łem o tym w Mucha…) i fak­tem jest, że takie (na bazie wie­dzy z okre­sów minio­nych) pro­gno­zo­wa­nie nie ma sen­su. Tu z auto­rem peł­na zgo­da. Ale jak się to ma do pro­jek­tów pro­gra­mi­stycz­nych? Nijak się nie ma, bo takich pro­gnoz nikt roz­sąd­ny nie robi w projekcie.

W inży­nie­rii opro­gra­mo­wa­nia nie pro­gno­zu­je się , bo to dome­na biz­ne­so­wa, w inży­nie­rii opro­gra­mo­wa­nia dąży się do zro­zu­mie­nia isto­ty pro­ble­mu imple­men­ta­cji. Czy ana­li­za i pro­jek­to­wa­nie to dłu­gie, szcze­gó­ło­we i zbęd­ne pla­no­wa­nie? Nie. Analiza ma za cel zro­zu­mie­nie i pod­ję­cie decy­zji o spo­so­bie imple­men­ta­cji. Jeżeli moż­na tu mówić o pla­no­wa­niu to raczej w kate­go­riach ​„jak pla­nu­je­my zaim­ple­men­to­wać” to roz­wią­za­nie (któ­rym jest speł­nie­nie wyma­gań biznesu).

Owszem, moż­na pro­wa­dzić imple­men­ta­cje meto­dą pro­to­ty­pów, błą­dząc, z nadzie­ją, że szyb­ko (przy­pad­kiem) stwo­rzy­my dobre roz­wią­za­nie. Ale to w szcze­gól­no­ści trud­no zapla­no­wać (a nawet start-upy maja budże­ty). Czy to jest tań­sze? Nie sądzę. Nazywam to syn­dro­mem LOTTO: szyb­ka decy­zja bez pla­no­wa­nie daje pew­ne szan­se na odkry­cie popraw­ne­go roz­wią­za­nia, jed­nak to to samo co uzna­nie, że moż­na gra­jąc w LOTTO zaro­bić na bie­żą­ce życie aż do śmier­ci. Owszem, jest to moż­li­we, ale uda­je się nie­licz­nym (i wie­my dlaczego).

Start-upy nie­wąt­pli­wie mają swo­je pra­wa, i tu autor ma racje, twier­dząc, że ​„nie ma cza­su”, jed­nak nie praw­dą jest, że:

Problem jest tyl­ko taki, że wszyst­ko, co na począt­ku usta­li­li­śmy to zwy­kłe prze­wi­dy­wa­nia naszych ?inter­ne­to­wych eko­no­mi­stów?. Całe nasze uza­sad­nie­nie biz­ne­so­we (model biz­ne­so­wy) jest prze­wi­dy­wa­niem, cały nasz zło­ty trój­ką pro­jek­tu (czas, zakres, budżet) jest prze­wi­dy­wa­niem. A jak dobrze wie­my, dzię­ki bada­niom Tetlocka, ludzie prze­wi­dy­wać dobrze nie potra­fią. Szczególnie w nowych warunkach.

Łączenie ​„trój­ką­ta pro­jek­to­we­go” z pro­gno­za­mi biz­ne­so­wy­mi jest albo nie­po­ro­zu­mie­niem, albo nie­wie­dzą, albo cyni­zmem: model biz­ne­so­wy nie jest pro­gno­zą, model biz­ne­so­wy to opis spo­so­bu gene­ro­wa­nia war­to­ści doda­nej. Prognozą może być co naj­wy­żej plan przy­cho­dów z tej działalności.

Bo po pierw­sze w two­rze­niu mode­lu biz­ne­so­we­go, nie ma mowy o prze­wi­dy­wa­niu przy­szło­ści a o ana­li­zie gru­py doce­lo­wej. Wskazany zaś trój­kąt pro­jek­to­wy (zakres, ter­min, budżet) to plan wytwo­rze­nia kon­kret­ne­go opro­gra­mo­wa­nia (wspie­ra­ją­ce­go ten model biz­ne­so­wy). Owszem, tu – model biz­ne­so­wy – moż­na się pomy­lić, ale to nie pomył­ka pro­gno­zo­wa­nia tyl­ko np. zła decy­zja mar­ke­tin­go­wa. Teza, że np. ​„moje kape­lu­sze będą mia­ły duży zbyt w gro­nie sno­bów”, to nie pro­gno­zo­wa­nie a plan mar­ke­tin­go­wy. Prognozowaniem było by stwier­dze­nie, że ​„sprze­daż kape­lu­szy dla sno­bów osią­gnie 10 tys. szt. w cią­gu naj­bliż­sze­go roku” i tu fak­tycz­nie moż­na się nie­źle pomy­lić. Nie zmie­nia to fak­tu, że kape­lusz to kape­lusz i nale­ży go zapro­jek­to­wać i wytwo­rzyć, opro­gra­mo­wa­nie wspo­ma­ga­ją­ce sprze­daż kape­lu­szy przez inter­net (jego funk­cjo­nal­ność) nie zale­ży od ilo­ści sprze­da­ży (poza wydaj­no­ścią cało­ści) tyl­ko od tego co i jak chce­my sprzedawać.

Jednak nie zmie­nia to fak­tu, że pro­gram wspie­ra­ją­cy sprze­daż tych kape­lu­szy wyma­ga pew­nej ana­li­zy by zapro­jek­to­wać model dzie­dzi­ny tego opro­gra­mo­wa­nia, tu błąd kosz­tu­je cza­sem tyle, że wyma­ga­ny refak­to­ring (bez któ­re­go nie zre­ali­zu­je­my np. kolej­nej nowej potrzeb­nej funk­cjo­nal­no­ści) ad-hoc pisa­ne­go opro­gra­mo­wa­nia zabi­je budżet całe­go pro­jek­tu. To wyglą­da mniej wię­cej tak (źr. Znaczenie ma nie wiel­kość pro­jek­tu…):

Powyżej wykres poka­zu­ją­cy kosz­ty chwi­lo­we (linia cią­gła) i nara­sta­ją­ce (linia prze­ry­wa­na) pro­jek­tu two­rze­nia i utrzy­ma­nia opro­gra­mo­wa­nia. Linia zie­lo­na to pro­ces z dobrze opra­co­wa­nym pro­jek­tem na począt­ku, czer­wo­na to pro­jekt ​„na żywioł”. 

Racje ma autor pisząc, że w przy­pad­ku start-upów może być dużym ryzy­kiem inwe­sto­wa­nie w pro­jek­to­wa­nie cze­goś co może oka­zać się nie­wy­pa­łem, jed­nak trze­ba pamię­tać, że jeże­li pro­jekt wypa­li, pra­wie na pew­no będzie wyma­gał wte­dy refak­to­rin­gu, by krzy­wa utrzy­ma­nia była jed­nak bliż­sza tej zie­lo­nej (niskie kosz­ty sta­łe to więk­sza marża).

Wodospad, któ­rym się ​„star­szy dzie­ci” to przede wszyst­kim nie ​„linio­wy” pro­jekt na lata (czy jak u auto­ra cyta­tów: 7 mie­się­cy start-up). Wodospad dzi­siaj to jedy­nie uzna­nie, że trzy fazy: ana­li­za, pro­jek­to­wa­nie, imple­men­ta­cja, są nie­roz­łącz­ne z czy­ste­go roz­sąd­ku. Prawda jest, że każ­da pro­gno­za wią­że się z ryzy­kiem, jeże­li uzna­my że jest ono duże (a z regu­ły jest), to nie pla­nu­je­my jak kiedyś:

(typo­wy struk­tu­ral­ny pro­ces), tyl­ko dzie­li­my pro­jekt na eta­py (kolej­ne funk­cjo­nal­no­ści) o dłu­go­ści na tyle krót­kiej, by błę­dy pro­gno­zy były akcep­to­wal­ne i nie nisz­czy­ły pro­jek­tu. Wtedy pro­jekt cha­rak­te­ry­zu­je się takim cyklem:

(źr. Mega pro­jek­ty…)

U auto­ra cyta­tów znaj­dzie­my bar­dzo podob­ny wykres, z jed­ną róż­ni­cą: tam jest to szu­ka­nie roz­wią­za­nia meto­dą pro­to­ty­pów, czy­li każ­da dotych­cza­so­wa pra­ca idzie do kosza. W tym przy­pad­ku, jest to prze­my­śla­ny pro­ces, powsta­ły już kod nie jest wyrzu­ca­ny, ale to wyma­ga dobre­go pro­jek­tu (szkie­le­tu archi­tek­tu­ry), obiek­to­wych metod i zasto­so­wa­nia wzor­ców analitycznych.

Autor arty­ku­łu pisze:

Mamy okre­ślo­ny cel biz­ne­so­wy. Nie wie­my, nie zna­my i nie mamy łatwe­go dostę­pu do naj­waż­niej­sze­go udzia­łow­ca ? użyt­kow­ni­ka, nie wie­my, co zro­bić, żeby speł­nić cel biz­ne­so­wy (zakres), tym samym nie wie­my, ile to będzie kosz­to­wać (budżet) i na kie­dy się uda go osią­gnąć (czas).

Wiemy nato­miast, że na pew­no będą zmia­ny i trze­ba jak naj­szyb­ciej z pro­duk­tem pro­jek­tu wejść na rynek.

Współczuję każ­de­mu, kto w tak eks­tre­mal­nych warun­kach, przy tak wiel­kim stop­niu nie­pew­no­ści musi tra­dy­cyj­ny­mi meto­da­mi reali­zo­wać projekt.

Od razu przy­po­mnę, że da się nowo­cze­sny­mi meto­da­mi two­rzyć opro­gra­mo­wa­nie odpo­wia­da­ją­ce powyż­szym wyma­ga­niom: to ma już nawet nawet ład­ną nazwę: SOLID gdzie klu­czo­wą cechą jest to, że tak pro­jek­to­wa­ne i wyko­ny­wa­ne opro­gra­mo­wa­nie jest ​„zamknię­te na zmia­ny i otwar­te na roz­sze­rze­nia” (nie mylić zmian kodu ze zmia­ną stra­te­gii sprze­da­ży), ozna­cza to, że kod nie wyma­ga zmian (refak­to­ring, odrzu­ca­nie pro­to­ty­pów) a pozwa­la na roz­sze­rze­nia (nowe wyma­ga­nia). Metody obiek­to­we to nic inne­go jak odpo­wiedź na powyż­sze potrze­by. Jeżeli autor miał na myśli tra­dy­cyj­ne meto­dy w rodza­ju ​„baza danych i funk­cje” to jestem po jego stro­nie, też współczuję.

Paradoksalnie to co opi­sa­łem jest tań­sze, bo nie­mal­że nic nie idzie do kosza. Każdy etap jest krót­ki więc ​„pra­wie pew­ny”, nie­mal­że żad­na pra­ca nie idzie na mar­ne, sys­tem nie wyma­ga per­ma­nent­nej refak­to­ry­za­cji. Co tu jest waż­ne: zacho­wu­je­my cykl: ana­li­za, pro­jek­to­wa­nie, imple­men­ta­cja. Są to wte­dy krót­kie ite­ra­cje, ale zawsze kodo­wa­nie poprze­dza­my ana­li­zą dzie­dzi­ny. Druga waż­na rzecz: nie da się tak pro­wa­dzić pro­jek­tu meto­da­mi struk­tu­ral­ny­mi (naj­pierw baza danych, potem funk­cje) bo model bazy danych z zasa­dy obej­mu­je całą dzie­dzi­nę pro­ble­mu, a tej, jak słusz­nie zauwa­ża autor, nie zna­my (dłu­go­ter­mi­no­wa prognoza). 

Druga wer­sja (opi­sa­na powy­żej) jest rela­tyw­nie tania, moż­na prze­rwać w dowol­nym momen­cie i nie prze­in­we­sto­wać. Jednak rezy­gna­cja z ana­li­zy, któ­rej celem jest zro­zu­mie­nie pro­ble­mu i zde­cy­do­wa­nie o spo­so­bie imple­men­ta­cji to szu­ka­nie kło­po­tów takich jak ten:

Jak wyglą­da takie «wzor­co­we” pro­jek­to­wa­nie opi­sa­łem w arty­ku­le Plansza do gry w szachy…

Na koniec co nie­co o ryzyku:

Tak więc nie ma metod jedy­nie słusz­nych (zwin­ne i nie­zwin­ne, itp.) , są tyl­ko ade­kwat­ne do sytu­acji projektowej.

Nie ma sen­su stra­sze­nie ludzie pro­ble­ma­mi inży­nie­rii opro­gra­mo­wa­nia z przed 30 lat (meto­dy struk­tu­ral­ne ana­li­zy i pro­jek­to­wa­nia, kosz­tow­ny water­fall)!. Mamy dziś rok 2013, dobrze roz­wi­nię­te meto­dy obiek­to­we ana­li­zy, pro­jek­to­wa­nia, mode­lo­wa­nia, imple­men­ta­cji. Aplikacje biz­ne­so­we moż­na wręcz linio­wo two­rzyć i roz­wi­jać, wystar­czy chcieć przejść na inne meto­dy pra­cy niż te, któ­rych (nie­ste­ty) nadal uczą na stu­diach: ​„funk­cje + struk­tu­ry danych = opro­gra­mo­wa­nie” bo to prehistoria.

Tak zwa­ne pro­jek­ty inter­ne­to­we to tak­że opro­gra­mo­wa­nie, tu tak­że obo­wią­zu­ją ​„pra­wa fizy­ki i eko­no­mii oraz roz­są­dek”. Jeżeli coś je odróż­nia o innych to uży­ta tech­no­lo­gia ​„inter­ne­to­wa” a i to coraz mniej, bo obec­ne opro­gra­mo­wa­nie biz­ne­so­we to coraz częściej„system dostęp­ny przez internet”…

Na pew­no wszel­kie start-up’y to pro­jek­ty ​„inne”, ale to wyni­ka z ich natu­ry biz­ne­so­wej (ryzy­ko powo­dze­nia) a nie tech­no­lo­gicz­nej. Mylenie tych pojęć pro­wa­dzi do wnio­sku, że np. nowy samo­chód pro­to­ty­po­wy kon­stru­uje się ina­czej niż ​„standardowy”.…nie, ina­czej pla­nu­je się finan­so­wa­nie ale deska kre­ślar­ska pozo­sta­je ta sama…

A na tytu­ło­we pyta­nie odpo­wiedź brzmi: nie ist­nie­je taki problem.