Na począ­tek histo­ryj­ka. Stolarz ma zwy­kły mło­tek, któ­re­go uży­wa do wbi­ja­nia gwoź­dzi. Prosty mło­tek to trzo­nek i pro­sty pobi­jak. W mia­rę roz­wo­ju fir­my poja­wia się pro­blem: sto­la­rze mają pro­blem z otwar­ciem piwa pod­czas pra­cy, zaczy­na­ją szu­kać spo­so­bu, czę­sto odbi­ja­ją kap­sle młot­kiem, nie raz uszka­dza­jąc butel­kę. Z uszko­dzo­nej butel­ki picie jest nie­bez­piecz­ne więc odpo­wie­dzial­ni pra­cow­ni­cy, w takich przy­pad­kach, muszą iść do skle­pu po dru­gie piwo. Powoduje to stra­tę cza­su i spa­dek wydaj­no­ści. Pojawia się wyma­ga­nie biz­ne­so­we: popra­wić wydaj­ność sto­la­rzy w pro­ce­sie prac budow­la­nych. Strategia: uspraw­nić narzę­dzia. Taktyka: zapro­jek­to­wać mło­tek, któ­ry nie uszka­dza kap­slo­wa­nych bute­lek pod­czas otwierania.

Analityk musi zro­zu­mieć pro­blem i zapro­po­no­wać rozwiązanie

No to do robo­ty: czyn­no­ści wyko­ny­wa­ne przez sto­la­rzy w pro­ce­sie kon­stru­owa­nia drew­nia­nych kon­struk­cji to wbi­ja­nie gwoź­dzi (czy­li ogól­nie pobi­ja­nie”) oraz otwie­ra­nie kap­slo­wa­nych bute­lek z piwem. Obie czyn­no­ści ma reali­zo­wać mło­tek” (przy­ję­ta tak­ty­ka roz­wią­za­nia pro­ble­mu). Czynności te więc sta­ją jego, młot­ka, przy­pad­ka­mi użycia.

Młotek świad­czy jed­ną usłu­gę: wspar­cie sto­la­rza w czyn­no­ściach, któ­rych nie moż­na wyko­nać dłoń­mi. Decydujemy (decy­zja pro­jek­to­wa), że oba przy­pad­ki uży­cia (usłu­gę tę) będzie reali­zo­wa­ła głów­ka młot­ka (kla­sa usłu­go­wa), a nie np. trzo­nek zakoń­czo­ny otwie­ra­czem. Tak więc na bazie wyko­ny­wa­nych czyn­no­ści i wie­dzy, że ma to być to samo narzę­dzie pra­cy, uzna­je­my, że mło­tek ma mieć dwa przy­pad­ki uży­cia: pobi­ja­nie oraz odkap­slo­wa­nie. Projektujemy mło­tek, model dzie­dzi­ny ma dwie kla­sy: trzo­nek i głów­ka. Główka to usłu­go­wa kla­sa i będzie mia­ła dwie ope­ra­cje: pobi­ja­nie i otwie­ra­nie kap­slo­wa­nych bute­lek.
Implementacja (obraz po lewej) to dzie­ło pro­du­cen­ta narzę­dzi: mło­tek typu dru­gie­go. Jak widać głów­ka świad­czy usłu­gę (trwa­ły meta­lo­wy ele­ment robo­czy) uży­tecz­ną do pobi­ja­nia i otwie­ra­nia bute­lek (ma dwie operacje).

Co więc mamy? Wymaganie biz­ne­so­we, pro­dukt wraz z tym jakie usłu­gi potra­fi świad­czyć, przy­pad­ki uży­cia czy­li to, do cze­go fak­tycz­nie moż­na (chce­my) użyć tego młot­ka oraz pro­jekt realizacji.

Czynności w pro­ce­sie biz­ne­so­wym (model biz­ne­so­wy) mapu­ją się na przy­pad­ki uży­cia pro­duk­tu (model – [[pro­jekt jako czar­na skrzyn­ka]] – tego produktu).

Jednak nicze­go nie wie­my o tym, co nale­ży zro­bić do cza­su, gdy ktoś nie opra­cu­je pro­jek­tu pro­duk­tu. Autor pomy­słu zawarł w pro­jek­cie dwa ele­men­ty: trzo­nek i dwu-funk­cyj­ną głów­kę czy­li dwie kla­sy dzie­dzi­no­we i ich ope­ra­cje (głów­ka: Uderz oraz Zerwij kap­sel i trzo­nek: połącz dłoń z głów­ką młot­ka). Implementacja (design, dobór mate­ria­łów itp. to inży­nier­ska robo­ta” czy­li reali­za­cja pro­jek­tu. Tu są reali­zo­wa­ne wyma­ga­nia poza-funk­cjo­nal­ne np. mło­tek ma wytrzy­my­wać 1 mln. ude­rzeń, nie może ważyć wię­cej niż 1,5 kg.

Można było sto­la­rza zaopa­trzyć w stan­dar­do­wy otwie­racz do bute­lek, jed­nak mamy tu ogra­ni­cze­nie stra­te­gicz­ne: nie chce­my powięk­szać licz­by przed­mio­tów w wypo­sa­że­niu sto­la­rza. Tak więc tak­ty­ka musia­ła być taka jaką tu wybrano.

Mam nadzie­ję, że ten pro­sty przy­kład obra­zu­je tak­so­no­mię” (kla­sy­fi­ka­cję) wyma­gań. Sam kie­dyś mie­wa­łem z tym pro­blem, szcze­gól­nie gdy pro­jekt się rozrastał.

Problemem więk­szo­ści pro­jek­tów pro­gra­mi­stycz­nych jest nie tyle lista wyma­gań (choć może być nie­kom­plet­na lub nie­spój­na, jeże­li powsta­nie jako dekla­ra­tyw­na lista ręka­mi pra­cow­ni­ków), pro­ble­mem pro­jek­to­wym jest zamia­na wyma­gań na usłu­gi sys­te­mu i pro­jekt ich realizacji.

Co więc mamy w pro­jek­tach, któ­rych celem jest dostar­cze­nie oprogramowania:

  1. wyma­ga­nia biz­ne­so­we – wyma­ga­nia wzglę­dem nowe­go lub zmie­nia­ne­go mode­lu biz­ne­so­we­go lub stra­te­gii czy­li co chce­my osią­gnąć w orga­ni­za­cji,
  2. wyma­ga­nia pro­duk­to­we – to cze­go ocze­ku­je­my od nowe­go pro­duk­tu (narzę­dzia pra­cy) czy­li jak to chce­my osią­gnąć (zapa­dła ewen­tu­al­na decy­zja o potrze­bie posia­da­nia sto­sow­ne­go produktu),
  3. usłu­gi pro­duk­tu – to co pro­dukt potra­fi zro­bić dla jego użyt­kow­ni­ka czy­li co pro­dukt powi­nien umieć”,
  4. pro­ces biz­ne­so­wy – lista czyn­no­ści jakie wyko­nu­ją przy­szli użyt­kow­ni­cy pro­duk­tu czy­li kie­dy będzie­my uży­wać pro­duk­tu,
  5. przy­pad­ki uży­cia wywo­dzo­ne z pro­ce­sów – to do cze­go użyt­kow­nik chce użyć pro­duk­tu,
  6. model pro­duk­tu – struk­tu­ra opi­su­ją­ca wewnętrz­ne ele­men­ty pro­duk­tu (modu­ły) i ich moż­li­wo­ści (ope­ra­cje jakie potra­fią wyko­nać) oraz ich wza­jem­ną współ­pra­cę (sce­na­riu­sze współ­dzia­ła­nia), pozwa­la­ją­cą na wyko­na­nie usłu­gi (zre­ali­zo­wa­nie kolej­nych przy­pad­ków uży­cia) czy­li jak powi­nien być skon­stru­owa­ny pro­dukt (jego obiek­to­wy model – dzie­dzi­na sys­te­mu); model pro­duk­tu to wyma­ga­nia dzie­dzi­no­we.
Tu pora na kon­klu­zję: wyma­ga­nia wyma­ga­niom nie­rów­ne, nie impli­ku­ją tak­że roz­wią­za­nia i jego jako­ści, więc jedy­nym spo­so­bem jed­no­znacz­ne­go zamó­wie­nia” opro­gra­mo­wa­nia jest opi­sa­nie tego jak powi­nien być skon­stru­owa­ny pro­dukt.

Odpowiedzialność za wyma­ga­nia w pro­jek­tach programistycznych

Projekty pro­gra­mi­stycz­ne i ana­li­za poprze­dza­ją­ca ich reali­za­cję, powin­ny być dosto­so­wa­ne (poczy­nio­ne pew­ne zało­że­nia) do dostęp­nej na ryn­ku tech­no­lo­gii i metod wytwa­rza­nia opro­gra­mo­wa­nia. Wśród nich są meto­dy obiek­to­we ana­li­zy i pro­jek­to­wa­nia oraz obiek­to­we języ­ki pro­gra­mo­wa­nia i szkie­le­ty opro­gra­mo­wa­nia (fra­me­wor­ki), pozwa­la­ją­ce na imple­men­ta­cję pro­jek­tów wyko­na­nych w obiek­to­wym paradygmacie.

Wydaje się, że obiek­to­we meto­dy są naj­sku­tecz­niej­sze w przy­pad­ku opro­gra­mo­wa­nia dla biz­ne­su. Bardzo popu­lar­ny i chy­ba naj­star­szy obiek­to­wy wzo­rzec pro­jek­to­wy to wzo­rzec [[Model, View, Controller (MVC)]]. W dużym uproszczeniu:

  • Model opi­su­je dzie­dzi­nę systemu,
  • View opi­su­je to co widzi użytkownik,
  • Control­ler ste­ru­je tym wszystkim.

Stosuję ten wzo­rzec do podzia­łu zadań (odpo­wie­dzial­no­ści) w pro­jek­tach z nastę­pu­ją­cy­mi konsekwencjami:

  1. View (widok): klient zama­wia” for­mu­larz (papier/ekran), bo klient wie co chce mieć”,
  2. Analityk two­rzy Model Dziedziny: 100% obiek­tów dzie­dzi­no­wych z regu­ła­mi (atry­bu­ty i ope­ra­cje biznesowe),
  3. Analityk dostar­cza listę wyma­gań poza-funk­cjo­nal­nych (ocze­ki­wa­ne wydaj­ność, bez­pie­czeń­stwo, dostęp­ność itp.),
  4. Developer imple­men­tu­je Model Dziedziny two­rząc opro­gra­mo­wa­nie, z pomo­cą uży­wa­ne­go szkie­le­tu opro­gra­mo­wa­nia roz­wią­zu­je pro­ble­my poza-funk­cjo­nal­ne lub zgła­sza ogra­ni­cze­nia ich realizacji.

I tak mamy: 100% inter­fej­su użyt­kow­ni­ka zama­wia użyt­kow­nik (sam lub z pomo­cą spe­cja­li­stów), 100% wyma­gań funk­cjo­nal­nych reali­zu­je Model Dziedziny (pro­jekt ana­li­ty­ka-pro­jek­tan­ta), 100% wyma­gań poza-funk­cjo­nal­nych reali­zu­je deve­lo­per (pro­jekt i imple­men­ta­cja). Developer tak­że imple­men­tu­je model dzie­dzi­ny z pomo­cą tech­no­lo­gii jakiej używa.

A jeże­li klient powie: nie mamy tych wzo­rów doku­men­tów i ekra­nów! To pierw­szy sygnał, że nie ma pod­staw do zama­wia­nia jakie­go­kol­wiek opro­gra­mo­wa­nia, bo naj­pierw trze­ba wie­dzieć co się chce”.

Jak to zro­bić? Tu kła­nia się ana­li­za biz­ne­so­wa: mode­lu­je­my pro­ce­sy biz­ne­so­we, dla każ­de­go z nich usta­la­my wej­ście oraz efekt (pro­dukt) czy­li wła­śnie owe wzo­ry doku­men­tów”. Po upo­rząd­ko­wa­niu tego i upew­nie­niu się, że nie ma w tym bała­ga­nu (powtór­ki, bra­ki, nie­kon­se­kwen­cje, sprzecz­no­ści itp.) może­my pytać o goto­we opro­gra­mo­wa­nie lub zama­wiać” jego wytwo­rze­nie. Produktem pra­cy ana­li­ty­ka powin­ny być, poza mode­la­mi pro­ce­sów bo one są narzę­dziem a nie celem, obiek­to­wy model dzie­dzi­ny czy­li model tego jaki­mi infor­ma­cja­mi i jak zor­ga­ni­zo­wa­ny­mi ope­ru­je orga­ni­za­cja, oraz to jak pra­cow­ni­cy tej orga­ni­za­cji chcą się komu­ni­ko­wać z opro­gra­mo­wa­niem (źro­dłem infor­ma­cji jest jed­nak klient).

Mamy czy­sty podział odpo­wie­dzial­no­ści i łatwość roz­li­cze­nia pro­jek­tu. Na czym pole­ga haczyk? Klient nie może uni­kać odpo­wie­dzial­no­ści za skut­ki swo­ich decy­zji i udzie­la­nych infor­ma­cji. Ale też, co jest klu­czo­we: Analityk musi zro­zu­mieć pro­blem i zapro­po­no­wać rozwiązanie. 

Jednak nie jest rolą ana­li­ty­ka wyko­na­nie opro­gra­mo­wa­nia! To jak – tech­no­lo­gia – ma to zostać zre­ali­zo­wa­ne” jest decy­zją deve­lo­pe­ra. Ma dużo pra­cy. Nie zapo­mi­naj­my, że kod reali­zu­ją­cy tak zwa­ną logi­kę biz­ne­so­wą to led­wie kil­ka pro­cent cało­ści kodu apli­ka­cji, jed­nak nie zapo­mi­naj­my tak­że (pro­gra­mi­ści), że zła logi­ka biz­ne­so­wa dys­kwa­li­fi­ku­je całe to opro­gra­mo­wa­nie z pro­ste­go powo­du: sta­je się nieprzydatne.

___

Po wie­lu dys­ku­sjach na szko­le­niach pre­zen­tu­ję zgod­ny z UML dia­gram przy­pad­ków uży­cia dla młotka:

Jarosław Żeliński

Jarosław Żeliński: autor, badacz i praktyk analizy systemowej organizacji: Od roku 1991 roku, nieprzerwanie, realizuje projekty z zakresu analiz i projektowania systemów, dla urzędów, firm i organizacji. Od 1998 roku prowadzi samodzielne studia i prace badawcze z obszaru analizy systemowej i modelowania (modele jako przedmiot badań: ORCID). Od 2005 roku, jako nieetatowy wykładowca akademicki, prowadzi 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. Prawa autorskie: Zgodnie z art. 25 ust. 1 pkt. 1) lit. b) ustawy o prawie autorskim i prawach pokrewnych zastrzegam, że dalsze rozpowszechnianie artykułów publikowanych w niniejszym serwisie jest zabronione bez indywidualnej zgody autora (patrz Polityki Strony).

Ten post ma 10 komentarzy

  1. Hania Wesołowska

    Znakomity case! 🙂

    Analityk musi zro­zu­mieć pro­blem i zapro­po­no­wać roz­wią­za­nie.”. Jasne, wte­dy mamy pew­ność, że robi­my opro­gra­mo­wa­nie, któ­re poma­ga. Czasem jed­nak klient nie chce dzie­lić się pro­ble­mem lub dla uspraw­nie­nia pra­cy poda­je roz­wią­za­nie wg swo­jej wie­dzy. Wtedy tra­ci­my kon­tro­lę: cza­sem się ono spraw­dzi, innym razem nie.

    A jeże­li klient powie: nie mamy tych wzo­rów doku­men­tów i ekra­nów! To pierw­szy sygnał, że nie ma pod­staw do zama­wia­nia jakie­go­kol­wiek opro­gra­mo­wa­nia, bo naj­pierw trze­ba ?wie­dzieć co się chce?.”. Gorzej, kie­dy wycią­ga cokol­wiek potwier­dza­jąc do same­go koń­ca eta­pu wytwa­rza­nia, że to wła­śnie odpo­wied­nie ekra­ny, a potem zmie­nia­jąc zdanie 🙂

    1. Jarek Żeliński

      Często spo­ty­kam się z sytu­acją, w któ­rej spon­sor pro­jek­tu zawie­ra umo­wę, a jako źró­dło infor­ma­cji” wyzna­cza zwy­kłych” pra­cow­ni­ków, przy­szłych użyt­kow­ni­ków sys­te­mu. To naj­więk­szy błąd, roz­kła­da­ją­cy pro­jek­ty. Niestety wie­lu kon­sul­tan­tów i pro­gra­mi­stów firm dostar­cza­ją­cych (two­rzą­cych) opro­gra­mo­wa­nie wła­snie taka meto­dę for­su­je jako naj­lep­szą… to trosz­kę jak by zle­cić opra­co­wa­nie wyma­gań na nowy sys­tem wyna­gro­dzeń wyna­gra­dza­nym pra­cow­ni­kom… Projekty, w któ­rych źró­dłem infor­ma­cji o wyma­ga­niach są wyż­sze kadry kie­row­ni­cze są obło­żo­ne znacz­nie mniej­szym ryzykiem.

      Ale nie ma obo­wiąz­ku zawie­ra­nia umo­wy”… a powyż­sze to nie­ste­ty coś, po czym ja znaj­du­ję pracę… 

  2. Sławomir Niemiec

    Z moje­go doświad­cze­nia zaob­se­wo­wa­łem rów­nież, że nie­któ­re fir­my decy­du­ją się na two­rze­nie zaple­cza ana­li­ty­ków biz­ne­so­wych, wśród wła­snych pra­cow­ni­ków. Doskonale rozu­miem, że część wie­dzy jest zbyt waż­na, wręcz stra­te­gicz­na, aby łatwo prze­ka­zy­wać ją na zewnątrz. Niestety, cza­sa­mi zada­rza się, że wewnętrz­ni ana­li­ty­cy, peł­nią dodat­ko­wo w ora­gni­za­cji wie­le innych ról, dopie­ro zaczy­na­ją gro­ma­dzić sto­sow­ną wie­dzę, nie mają doświad­cze­nia, a powie­ża im się pro­jek­ty o zna­cze­niu stra­te­gicz­nym dla fir­my. Jakie są tego skut­ki…? na tym forum i czy­tel­ni­kom nini­je­sze­go blo­ga z pew­no­ścią nie muszę opisywać.

    1. Jarek Żeliński

      Swego cza­su powie­dzia­łem pew­ne­mu Prezesowi, gdy mnie zapy­tał Po co mi Pana usłu­gi, mam swój cały dział IT i ana­li­ty­ków od wie­lu lat”. Odpowiedziałem: Co by Pan powie­dział o leka­rzu, któ­ry przez kil­ka­na­ście lat leczy wyłącz­nie Pana, jak oce­nił­by Pan prak­ty­kę i róż­no­rod­ność doświad­cze­nia, wie­dzę oso­bi­ste­go leka­rza? Jakim spe­cja­li­stą jest mecha­nik, któ­ry całe życie ma do czy­nie­nia wyłącz­nie z wła­snym samochodem?”

  3. roan

    Kilka wąt­ków, z któ­ry­mi moż­na moc­no dyskutować
    źró­dło infor­ma­cji”: myślę, że ani wyż­sze kie­row­nic­two ani, sze­re­go­wi pra­co­wa­ni­cy nie są w sata­nie nie­za­leż­nie dostar­czyć kom­ple­tu infor­ma­cji. Po pierw­sze każ­dy trzy­ma swo­ją per­spek­ty­wę, a po dru­gie wystę­pu­ją sil­ne ten­den­cje do upięk­sza­nia” rze­czy­wi­sto­ści. Rozwiązaniem jest zan­ga­żo­wa­nie obu szcze­bli, czy to poprzez nie­za­leż­ne mode­lo­wa­nie pro­ce­su, czy cho­ciaż jego weryfikację(zaczynamy od pra­cow­ni­ka i dys­ku­tu­je­my z kie­row­nic­twem + wspól­ne wyjaśnienia)
    wewnętrz­ni ana­li­ty­cy vs. zewnętrz­ni” – tu kom­plet­nie się nie zgo­dzę z uogól­nie­niem, wszyst­ko zale­ży od kom­pe­ten­cji i doświad­cze­nia. Miałem oka­zje obser­wo­wać obie stro­ny z obu per­spek­tyw i róż­nie to bywa­ło. Rozwiązanie jest gdzieś po środ­ku, są rze­czy kto­re lepiej zro­bi zewnętrz­ny ana­li­tyk, są takie któ­re wewnętrz­ny no i zda­rza­ją się przy­pad­ki, że współ­pra­ca daje super efekty.

    Pozdrawiam M

    1. Jarek Żeliński

      Co do źró­dła infor­ma­cji” to praw­da, dla­te­go zawsze model pro­ce­su jest wery­fi­ko­wa­ny z jed­ny­mi i dru­gi­mi, jed­nak nie dopusz­czam” do poboż­nych życzeń. Obie stro­ny infor­mu­ję, że nale­ży wyka­zać” na pro­ce­sie sens i potrze­bę każ­de­go wyma­ga­nia. Modele są tu klu­czo­wym narzę­dziem pra­cy (a nie spo­wiedź use­ra czy userstory). 

      Co do ana­li­ty­ków wewnętrz­nych, zewnętrz­nych i ana­li­ty­ków dostaw­cy”. Jeżeli uzna­my, że nie dys­ku­tu­je­my o pozio­mie ich kom­pe­ten­cji (nie pod­wa­ża­my ich kom­pe­ten­cji), to pozo­sta­ją rze­czy, na któ­re zwra­ca­ją uwa­gę moi klienci:
      – jeże­li poja­wia­ją się jakieś ogra­ni­cze­nia ana­li­tyk dostaw­cy lob­bu­je na korzyść mar­ży dostaw­cy a ana­li­tyk kupu­ją­ce­go na korzyść potrzeb kupu­ją­ce­go, oso­bi­ście uwa­żam, że tu racje ma ten, któ­ry pła­ci” bo to jemu ma to opro­gra­mo­wa­nie pomagać.
      – jeże­li cho­dzi o kwe­stie ana­li­tyk wła­sny lub zewnętrz­ny u kupu­ją­ce­go, to po pierw­sze: zewnętrz­ny nie jest niczy­im pod­wład­nym i nie musi z nikim trzy­mać”, a to ryzy­ko jest pra­wie pew­ne (w koń­cu to pra­cow­nik tej fir­my); nie­je­den pro­jekt zabi­ły kom­pro­mi­sy wyni­ka­ją­ce wyłącz­nie z tego, że wła­sny ana­li­tyk” ma wszyst­ko poza jed­nym: jego nie­za­leż­ność = 0. Praktycznie na każ­dym szko­le­niu zamknię­tym sły­szę: Pan może ale my nie może­my tego powie­dzieć prze­ło­żo­nym, my tam po pro­jek­cie zosta­nie­my”, ale jeże­li pro­jekt doty­czy roz­wo­ju opro­gra­mo­wa­nia, wła­sny ana­li­tyk jest nie­oce­nio­nym part­ne­rem dla zewnętrz­ne­go (o ile wła­sne­mu testo­ste­ron do gło­wy nie uderzy :)) 

      Ogólnie bazu­ję na blo­gu w 100% na ryzy­kach róż­nych kom­bi­na­cji i sytu­acji, ale owszem nie da się wyklu­czyć wyjąt­ków, któ­re wyła­mu­ją się powyż­szym zarzu­tom”. Jednak moim zda­niem nale­ży uznać fakt, że te ryzy­ka (opi­sy­wa­nych tu pato­lo­gii) ist­nie­ją i owo­cu­ją ponu­ry­mi statystykami…

  4. roan

    Ryzyko głu­pie­go kom­pro­mi­su” jest poważ­ne i na pew­no się mate­ria­li­zu­je, ale poważ­ne ryzy­ka wystę­pu­ją rów­nież w przy­pad­ku zewnętrz­ne­go ana­li­ty­ka np. chęć zbyt szyb­kie­go zamknię­cia kon­trak­tu, przy­dzie­la­nie w póź­niej­szych eta­pach pro­jek­tów mniej kom­pe­tent­nych zaso­bów itp…

    Z moje­go doświad­cze­nia wyni­ka, że bar­dzo dobrze spraw­dza się model z sil­nym i umo­co­wa­nym lide­rem wewnątrz orga­ni­za­cji, któ­ry umie­jęt­nie korzy­sta i z zewnętrznych(wnoszących świe­że spoj­rze­nie i inne podej­ście) i wewnętrznych(znających i rozu­mie­ją­cych orga­ni­za­cję) sił analitycznych.

    Oczywiście taka współ­pra­ca stwa­rza pew­ne wyzwa­nia, ale dobra orga­ni­za­cja pra­cy da w rezul­ta­cie win-win.

  5. Michał Marciniak

    W opi­sy­wa­nym przy­pad­ku zasto­so­wał­bym moje ulu­bio­ne, acz­kol­wiek nie­zbyt wyra­fi­no­wa­ne narzę­dzie ana­li­zy – 5 WHY („ale po co?”). W efek­cie otrzy­ma­li­by­śmy dogłęb­ne roz­po­zna­nie pro­ble­mu i potrzeb użyt­kow­ni­ka. Następnie ana­li­tyk powi­nien zapro­po­no­wać poten­cjal­ne roz­wią­za­nia, oczy­wi­ście uzu­peł­nio­ne o kom­plek­so­wą ana­li­zę SWOT każ­de­go z nich. W powyż­szym przy­pad­ku mamy case już roz­pra­co­wa­ny.. ale czy lep­szym roz­wią­za­niem dla spon­so­ra pro­jek­tu, nie było­by tutaj piwo w puszce” 🙂 ??

    1. Jaroslaw Zelinski

      Dręczenie ludzi meto­dą «5 x why” zakła­da, że w koń­cu z nich to wycią­gnie­my”… co nie­ste­ty rzad­ko jest praw­dą. Tej pusz­ki piwa na pew­no tą meto­dą klient nie wykon­cy­pu­je”. Puszka piwa jed­nak odpa­da, bo to pro­jekt roz­wo­ju młot­ka. Owszem do roz­wa­że­nia jest oddzie­le­nie tych dwóch dzie­dzin od sie­bie ale ana­li­za wska­zu­je, że celem jest narzę­dzie a dwie dzie­dzi­ny: sto­lar­ka i spo­ży­wa­nie piwa. 

      Analizy SWOT to testy zaist­nia­łych pomy­słów (pro­dukt, fir­ma, …) a nie szu­ka­nie roz­wią­zań. Analiza SWOT to narzę­dzie z obsza­ru ana­li­zy wyko­ny­wal­no­ści. Owszem spo­ty­kam doku­men­ty, że każ­de wyma­ga­nie jest pod­da­wa­ne ana­li­zie SWOT ale to już raczej prze­rost for­my nad treścią. 

      Czy piwo w pusz­cze” było by tu lep­sza dla spon­so­ra? Piwo i jego spo­sób pako­wa­nia jest tu cał­ko­wi­cie poza zakre­sem pro­jek­tu, to ele­ment oto­cze­nia na któ­ry nie mamy wpły­wu. Wymaganie brzmi: kapsel :). 

      Ale poru­szy­li­śmy cie­ka­wy temat: kto ma wie­dzieć co ma powstać? Naście lat doświad­cze­nia, i kolej­ne lata, utwier­dza­ją mnie w prze­ko­na­niu, że użyt­kow­nik nie powi­nien być pro­jek­tan­tem: ani domów, ani samo­cho­dów, ani samo­lo­tów ani opro­gra­mo­wa­nia. Może być tym, kto zgło­si uwa­gi do roz­wią­za­nia, któ­re dostał. Dlaczego? Po pierw­sze to nie jego rola w pro­jek­cie, jestem prze­ciw­ni­kiem tezy, że odpo­wie­dzial­ność za nie­po­wo­dze­nie pro­jek­tu ma być zrzu­ca­na na use­ra któ­ry nie wie cze­go chce”, on nie jest pro­jek­tan­tem. User sto­ry pra­wie zawsze pro­wa­dzi to efek­tów dosta­łem dokład­nie to cze­go chcia­łem a nie to cze­go potrze­bu­ję”.… Żaden ofi­cer bez­pie­czeń­twa” nie pyta się cze­go chce user”, tyl­ko dosta­je wyma­ga­nia biz­ne­so­we i pro­jek­tu­je poli­ty­kę bez­pe­czeń­stwa, user musi się do niej sto­so­wać… i chy­ba obaj wie­my dla­cze­go: więk­szość roz­wią­zań tech­no­lo­gicz­nych chro­ni use­rów przed nimi samymi 🙂 …

Dodaj komentarz

Witryna wykorzystuje Akismet, aby ograniczyć spam. Dowiedz się więcej jak przetwarzane są dane komentarzy.