W poprzed­nim arty­ku­le (Ile jest tych wyma­gań na sys­tem ERP) pisa­łem, że nad­mier­ne sku­pia­nie się na szcze­gó­łach nie tyl­ko nie wno­si nicze­go do pro­jek­tu ale nie raz wręcz go nisz­czy. Dotyczy to zresz­tą ogól­nie pro­jek­tów ana­li­tycz­nych, nie tyl­ko w dzie­dzi­nie IT.

Na stro­nach jed­ne­go z bar­dziej poczyt­nych ser­wi­sów o ana­li­zie IT – http://​www​.moder​na​na​lyst​.com – poja­wił się jakiś czas temu cie­ka­wy arty­kuł o ana­li­zie SWOT. Autor opi­su­je jak tę ana­li­zę prze­pro­wa­dzić, ja opi­szę jak jej użyć w ana­li­zie sys­te­mo­wej orga­ni­za­cji i spe­cy­fi­ko­wa­niu wyma­gań. We wstę­pie arty­ku­łu czytamy:

Much of the busi­ness of busi­ness ana­ly­sis is in the deta­ils, and most busi­ness ana­ly­sts are by natu­re deta­iled, sys­te­ma­tic thin­kers. Occasionally most orga­ni­za­tions, tho­ugh, have times when they can?t see the forest for the tre­es. That is when the high-level, bro­ad-ran­ge view that SWOT Analysis affords is just as use­ful in avo­iding costly errors as unam­bi­gu­ous requ­ire­ments. (What is SWOT Analysis?).

W dużym uprosz­cze­niu: wie­lu ana­li­ty­ków sku­pia się od razu na szcze­gó­łach, bo to natu­ral­ne ele­men­ty nasze­go bez­po­śred­nie­go oto­cze­nia, nie potra­fią spoj­rzeć na orga­ni­za­cję z dale­ka, nie potra­fią dostrzec lasu patrząc na poje­dyn­cze drze­wa”. Analiza SWOT pozwa­la spoj­rzeć na pro­blem z innej, wyż­szej per­spek­ty­wy, sze­rzej, dzię­ki cze­mu jest bar­dzo uży­tecz­na w uni­ka­niu kosz­tow­nych błę­dów jaki­mi są nie­jed­no­znacz­ne wymagania. 

Jednym z zabój­ców pro­jek­tów” (a kon­kret­nie ich budże­tów i har­mo­no­gra­mów) są tak zwa­ne wyma­ga­nia osie­ro­co­ne i wyma­ga­nia nie­od­kry­te na eta­pie ana­li­zy. Są to odpo­wied­nio wyma­ga­nia zgło­szo­ne do spe­cy­fi­ka­cji i zre­ali­zo­wa­ne, z któ­rych następ­nie nikt nie korzy­sta, oraz te odkry­wa­ne dopie­ro na eta­pie wdro­że­nia. Nie da się zapro­jek­to­wać” lasu myśląc o drze­wach bo celem jest las, a nie kon­kret­ne drzewa. 

Jeden pro­jekt może mieć jeden cel, jeże­li jed­nak celem” ma być każ­dy kolej­ny krok, podróż nigdy się nie kończy.

Wymagania o jakich pisa­łem w poprzed­nim arty­ku­le to wyma­ga­nia wobec roz­wią­za­nia, któ­rym było jakieś opro­gra­mo­wa­nie”. Jednak to dru­gi etap ana­li­zy. Generalnie naj­pierw ana­li­zu­je się i defi­niu­je wyma­ga­nia biz­ne­so­we, a potem dopie­ro wyma­ga­nia wobec roz­wią­za­nia, wie­dząc już jakie warun­ki musi ono speł­niać. Przykładowym wyma­ga­niem biz­ne­so­wym może być pod­nie­sie­nie jako­ści obsłu­gi klien­ta (co by to tu teraz nie mia­ło zna­czyć), a dopie­ro reko­men­do­wa­nym roz­wią­za­niem może być, np. opro­gra­mo­wa­ne CRM albo reor­ga­ni­za­cja dzia­łu sprze­da­ży (co z resz­tą wie­le firm robi znacz­nie czę­ściej niż kupu­je nowy CRM ;)).

Wiele firm rzu­ca się na pro­jek­ty od razu z zało­że­niem, że musi­my mieć nowe opro­gra­mo­wa­nie”. Co nie raz bywa dużym błę­dem i masą zmar­no­wa­nych środ­ków. Jak się przed tym ustrzec?

Warto popa­trzeć na orga­ni­za­cję i kon­kret­ny pro­blem z pew­nej per­spek­ty­wy, z wyż­sze­go pozio­mu abs­trak­cji, niż tyl­ko sto­jąc mię­dzy biur­ka­mi widząc kon­kret­ne spra­wy i ludzi się nimi zaj­mu­ją­cy­mi. Narzędziem pozwa­la­ją­cym wznieść” się na wyż­szy poziom abs­trak­cji jest wła­śnie ana­li­za SWOT. Analiza ta pole­ga na ziden­ty­fi­ko­wa­niu czte­rech klu­czo­wych ele­men­tów wpły­wa­ją­cych na orga­ni­za­cję : czyn­ni­ki zewnętrz­ne jaki­mi są oka­zje i zagro­że­nia oraz czyn­ni­ki wewnętrz­ne czy­li sil­ne i sła­be stro­ny orga­ni­za­cji. Tu waż­na infor­ma­cja, ana­li­za SWOT to ana­li­za cze­goś kon­kret­ne­go” w okre­ślo­nym śro­do­wi­sku”. Czynniki wewnętrz­ne opi­su­ją to coś”, zaś czyn­ni­ki zewnętrz­ne opi­su­ją śro­do­wi­sko tego cze­goś”. Można tak ana­li­zo­wać orga­ni­za­cję (np. fir­ma i jej oto­cze­nie ryn­ko­we) czy też pro­duk­ty pro­jek­tów (np. kon­kret­ne opro­gra­mo­wa­nie w fir­mie) ale nie sam pro­jekt wdro­że­nio­wy czy pro­ces (one nie są czymś”).

Analiza SWOT może być ele­men­tem ana­li­zy sys­te­mo­wej orga­ni­za­cji. Analiza SWOT to np. wstęp do opra­co­wa­nia reko­men­da­cji w odpo­wie­dzi na pro­blem biz­ne­so­wy. SWOT to iden­ty­fi­ka­cja i wpływ okre­ślo­nych ele­men­tów, pozo­sta­je oce­na tego jaki, i na co. Dlatego ana­li­za SWOT sta­ła się czę­ścią tak zwa­ne­go Modelu Motywacji Biznesowej (BMM). Model ten pozwa­la lepiej zro­zu­mieć oto­cze­nie pro­ble­mu” oraz śla­do­wać” ele­men­ty ziden­ty­fi­ko­wa­ne w ana­li­zie SWOT na kon­kret­ne pro­ce­sy biz­ne­so­we i struk­tu­rę organizacyjną.

SWOT

(dia­gram BMM: ana­li­za SWOT i przej­ście na pro­ce­sy biz­ne­so­we opr. wła­sne autora).

Z poprzed­nich moich arty­ku­łów wie­my, że wyma­ga­nia wobec roz­wią­za­nia (w tym wobec opro­gra­mo­wa­nia) mają swo­je źró­dło w pro­ce­sach biz­ne­so­wych i ich wyko­naw­cach. Jednak spi­sa­nie ich w posta­ci dekla­ra­tyw­nej listy pod­czas warsz­ta­tów i wywia­dów, pro­wa­dzi do powsta­nia dłu­giej i prak­tycz­nie nie­we­ry­fi­ko­wal­nej listy o jakiej pisa­łem w Ile jest tych wyma­gań na sys­tem ERP.

Lekarstwem na pro­blem jest wery­fi­ka­cja (two­rze­nie) listy wyma­gań wobec roz­wią­za­nia. Weryfikacja (dia­gram powy­żej) pole­ga na tak zwa­nym śla­do­wa­niu. Śladowanie to wywo­dze­nie każ­de­go wyma­ga­nia z pier­wot­nej potrze­by, jaką jest tak­ty­ka, któ­rą przy­ję­to by osią­gnąć cel. Taktyka ma swo­je źró­dło w stra­te­gii (tak­ty­ka imple­men­tu­je stra­te­gię). Strategia (jej skon­stru­owa­nie) jest odpo­wie­dzią na oka­zję ryn­ko­wą, któ­ra jest przy­czy­ną, dla któ­rej podej­mu­je­my dzia­ła­nia ryn­ko­we. Okazja ryn­ko­wa daje szan­sę na zysk” (pro­dukt dają­cy docho­dy) w posta­ci dostar­cze­nia swo­je­mu oto­cze­niu war­to­ści doda­nej. Warto tu zwró­cić uwa­gę na to, że ele­men­ty ana­li­zy SWOT tak­że powin­ny mieć swo­je uza­sad­nie­nie w posta­ci iden­ty­fi­ka­cji zewnętrz­nych i wewnętrz­nych czyn­ni­ków wpły­wu. Słabe stro­ny oraz zagro­że­nia powin­ny iden­ty­fi­ko­wać ryzy­ka pro­jek­tu. Analizę uzna­je­my za zakoń­czo­ną po ziden­ty­fi­ko­wa­niu wszyst­kich zna­nych klu­czo­wych czyn­ni­ków wpły­wu i ryzyk. Analiza taka jest ele­men­tem ana­li­zy sys­te­mo­wej orga­ni­za­cji.

Wielu wła­ści­cie­li firm, ich zarzą­dy, pomi­ja ten etap w pro­jek­tach z uwa­gi na swo­je prze­ko­na­nie, że ich dotych­cza­so­we dzia­ła­nia i chęć ich kon­ty­nu­acji, nie wyma­ga­ją żad­nej korek­ty, ocze­ku­ją poda­nia na tacy opi­su narzę­dzia, któ­re­go – jak sądzą – potrze­bu­ją. Zachowują się jak pacjen­ci, któ­rzy mimo, że ostat­nie bada­nia robi­li wie­le lat temu, nie dopusz­cza­ją myśli, że lekarz może im prze­pi­sać na gorącz­kę coś inne­go niż kolej­ną aspi­ry­ną. Bywa, że zbyt póź­no odkry­wa­ją, że tym razem to nie było kolej­ne przeziębienie.

Praktyka poka­zu­je, coś bar­dzo cie­ka­we­go: zamiast pro­wa­dzić żmud­ne i kosz­tow­ne wywia­dy, sesje warsz­ta­to­we, burze mózgów, któ­rych pro­duk­tem jest dłu­ga lista dość przy­pad­ko­wych pomy­słów na wyma­ga­nia”, war­to docho­dzić do listy wyma­gań meto­dą od ogó­łu do szcze­gó­łu, wła­śnie od pozio­mu ana­li­zy SWOT (opar­tej na wizji i misji orga­ni­za­cji). Takie podej­ście od razu, naj­krót­szą dro­gą, pro­wa­dzi – przez model pro­ce­sów biz­ne­so­wych – do bar­dzo spój­nej i kom­plet­nej, bez nad­mia­ro­wych (osie­ro­co­nych) wyma­gań, spe­cy­fi­ka­cji wyma­gań wobec roz­wią­za­nia. Każde wyma­ga­nie ma swo­je uza­sad­nie­nie (śla­do­wa­nie) w stra­te­gii, nie ma ryzy­ka, że coś pomi­nie­my, bo tu wery­fi­ka­to­rem jest model pro­ce­su (kom­plet­na i spraw­dzo­na lista czyn­no­ści). Koszty uzy­ska­nia spe­cy­fi­ka­cji wyma­gań tą meto­dą, są znacz­nie niż­sze niż tra­dy­cyj­ny­mi (wywia­dy) meto­da­mi bo: nie anga­żu­je­my cza­su całych zespo­łów pra­cow­ni­ków na wywia­dy i warsz­ta­ty, ryzy­ko bar­dzo kosz­tow­nych pomi­nięć i nad­mia­rów jest mini­mal­ne, licz­ba ite­ra­cji w takim pro­jek­cie zbli­ża się do JEDNEJ! i nie trze­ba odkry­wać wyma­gań meto­dą kosz­tow­nych pro­to­ty­pów na eta­pie przed­wcze­snej imple­men­ta­cji. Jedyny pro­blem” to jej prze­pro­wa­dze­nie, mimo poku­sy”, roz­po­czę­cia pro­jek­tu od razu bo nie ma cza­su na ana­li­zę, i szko­da na to pieniędzy”.

Jarosław Żeliński

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.

Ten post ma 16 komentarzy

  1. jacek2v

    Trochę to zaczy­na przy­po­mi­nać 5‑latki PRLu 🙂
    Łatwo jest popaść w fik­cyj­ne misje i wizje, nie­zwią­za­ne z rzeczywistością.

    1. Jaroslaw Zelinski

      Z per­spek­ty­wy zarzą­dza­nia są to klu­czo­we ele­men­ty, wręcz szkol­na wie­dza, któ­rą nie­ste­ty pomi­ja­ją inży­nie­ro­wie… dla inży­nie­ra pro­jekt jest faj­ny z same­go fak­tu, że jest, dla inwe­sto­ra nie­ko­niecz­nie… Najgorsze w wie­lu pro­jek­tach jest to, że w odpo­wie­dzi na pyta­nie dla­cze­go Pan to robi” zapa­da cisza…wtedy już moż­na robić cokol­wiek. Ja zawsze pytam: sko­ro napi­sa­li­ście tu te 73 wyma­ga­nia, dla­cze­go nie jest ich 50 lub 100? Pytanie zło­śli­we: Dlaczego licz­ba wyma­gań jest pro­por­cjo­nal­na do cza­su trwa­nia sesji warsztatowych?

  2. jacek2v

    Moim zda­niem to pod­sta­wo­wy błąd w zarzą­dza­niu, że wyzna­cza się fik­cyj­ne misje, cele, wizje itp. nie wery­fi­ku­jąc ich z rze­czy­wi­sto­ścią – patrz 5‑latki PRL, albo misje http://​cmor​se​.org/​m​i​s​s​i​o​n​g​en/, albo http://​www​.stra​te​gic​de​ve​lop​ment​.com/​d​i​l​b​e​r​t​-​m​i​s​s​i​o​n​-​s​t​a​t​e​m​e​n​t​.​php

    Co do pyta­nia to nie zawsze tak jest. Zauważyłem, że po pew­nym cza­sie (>3h) ilość wyma­gań nie rośnie – poja­wia zmę­cze­nie:) Ale na poważ­nie to naj­czę­ściej powo­dem jest brak kon­cen­tra­cji na celu.
    Ja pro­po­nu­ję inne pyta­nie: Dlaczego koszt (i czas) pro­jek­tu jest wprost pro­por­cjo­nal­ny do ilo­ści zaan­ga­żo­wa­nych osób po stro­nie klienta?

    1. Jaroslaw Zelinski

      O ile są fik­cyj­ne to masz rację…
      Bo brak kon­cen­tra­cji na celu jest wte­dy gdy celu nie ma :), a jest nim wła­snie misja, stra­te­gia i tak­ty­ka 🙂 roz­wią­za­nia problemu.
      Dlaczego koszt pro­jek­tu jest wprost pro­por­cjo­nal­ny do ilo­ści zaan­ga­żo­wa­nych osób po stro­nie klien­ta? To jest złe pyta­nie bo koszt zawsze zale­ży od ilo­ści ludzi zaan­ga­żo­wa­nych :), dla­te­go ja nie dopusz­czam, by tych ludzi i robo­czod­nió­wek było z byt wie­lu, po stro­nie dostaw­cy tak­że. Jest na to dosko­na­łe lekar­stwo: umo­wy fixed pri­ce :), u tyl­ko takie tole­ru­ję u dostaw­ców oprogramowania.

  3. natur

    Całkowicie się zga­dzam z Panem Jarosławem. Ostatnio, pod­czas prze­pro­wa­dzo­ne­go wywia­du ze spe­cja­li­stą ds. IT(inżynier wyko­nu­ją­cy pro­jekt) usły­sza­łem, że stra­te­gia, cele tak­tycz­ne i ope­ra­cyj­ne to jest coś, co musi być, ale on(informatyk) tego nie rozu­mie i dla nie­go jest to beł­kot. Dotarcie do stra­te­gii i misji fir­my jest to pierw­szy krok dla analityka.
    Panie Jarosławie, mam jed­nak do Pana pyta­nie. Czy ist­nie­je jakaś meto­dy­ka ana­li­zy SWOT. Chciałbym prze­pro­wa­dzić taką ana­li­zę, ale nie­ste­ty nie umiem” – czy­li nie wiem na jakie czyn­ni­ki zwró­cić uwa­gę. Jest jakiś tem­pla­te” do prze­pro­wa­dza­nia ana­li­zy SWOT?

    1. Jaroslaw Zelinski

      No algo­ryt­mu nie ma ale są dobre prak­ty­ki”, w każ­dej krat­ce jed­na cecha plus ewen­tu­al­nie dwie lub trzy uzu­peł­nia­ją­ce. Zanim zacznie­my ana­li­zę SWOT musi­my dys­po­no­wać nazwą i kon­tek­stem tego co jest ana­li­zo­wa­ne” i to musi być JEDNA RZECZ. Linkowany na począt­ku arty­kuł jest czymś w rodza­ju takie­go opi­su jak” (choć jest trosz­kę roz­wle­kły). Dużą pomo­cą jest zebra­nie klu­czo­wych czyn­ni­ków wpły­wu (wewnętrz­ne i zewnętrz­ne) nie zmie­nia to fak­tu, że SWOT może zro­bić biz­nes” lub ja z biz­ne­sem” albo ja” po wyko­na­niu ana­li­zy biz­ne­so­wej. Może poku­szę się o taki opis :). I jesz­cze jed­no: stra­te­gia, cele tak­tycz­ne i ope­ra­cyj­ne to jest coś, co musi być, ale on(informatyk) tego nie rozu­mie i dla nie­go jest to beł­kot” to fakt i powód dla któ­re­go nie ma sen­su by ludzi z IT czy­nić ana­li­ty­ka­mi wyma­gań w pro­jek­cie bo dla IT wyma­ga­nia biz­ne­su to zawsze beł­kot”.

  4. jacek2v

    Przy umo­wach fixed pri­ce, zawsze pytam o skład zespo­łu po stro­nie klienta 🙂

    1. Jaroslaw Zelinski

      I słusz­nie :), ja dodat­ko­wo dokład­nie opi­su­ję do cze­go ja się zobo­wią­zu­ję a do cze­go klient. Drugie jest sil­niej­sze” od pierw­sze­go ;). Innymi sło­wy: nie pod­pi­su­je umów, w któ­rych klient do nicze­go się nie zobo­wią­zu­je, bo powi­nien co naj­mniej dostar­czyć co naj­mniej raz okre­ślo­ne dane wejściowe ;). 

  5. jacek2v

    Tu cho­dzi­ło mi o aspekt wyce­ny – czym więk­szy zespół, tym wię­cej pra­cy (np. uzgodnień).

    1. Jaroslaw Zelinski

      To fakt, pyta­nie czy więk­szy zespół to to samo co lep­szy pro­dukt koń­co­wy.… bo ja tu bym polemizował 🙂

  6. jacek2v

    Myślę, że jeśli to jest pro­por­cjo­nal­ne to odwrotnie 😀
    Czyli czym więk­szy zespół (ana­li­tycz­no-eks­perc­ki), tym pro­dukt koń­co­wy gorszy.

    1. Jaroslaw Zelinski

      Ale ja prak­tycz­nie dokład­nie to napi­sa­łem :). Swoim klien­tom zawsze mówię, że wiel­kie obra­zy czy rzeź­by two­rzą poje­dyn­czy ludzie, pró­ba skró­ce­nia cza­su ich powsta­nia poprzez doda­nie kolej­nych współ­au­to­rów” jedy­nie pod­no­si koszt, two­rzy cha­os i pro­wa­dzi do znacz­ne­go pogor­sze­nia jako­ści koń­co­we­go pro­duk­tu. Owszem, wykoń­cze­nie moż­na powie­rzyć zespo­ło­wi (wypeł­nia­nie plam far­ba, kon­tu­rów któ­re stwo­rzył Michał Anioł a Kaplicy Sykstyńskiej) ale naj­pierw musi powstać całe dzie­ło: pro­jekt z ręki jed­ne­go autora.

  7. Michal

    Z tym beł­ko­tem dla ludzi z IT to ja się do koń­ca nie zga­dzam. Oczywiście jest spo­ra gru­pa, któ­ra pre­zen­tu­je taką posta­wę, ale ta gru­pa to głów­nie pro­gra­mi­ści – niko­mu nie ujmu­jąc, to nie jest ele­ment ich pra­cy i wca­le się od nich tego nie wyma­ga. Jednakże jakoś nie potra­fię sobie wyobra­zić osób pro­jek­tu­ją­cych na pod­sta­wie ana­li­zy biz­ne­so­wej czy zaj­mu­ją­cych się QA czy (w sumie w Polsce dość nowym zagad­nie­niem) UX, któ­rzy nie czu­ją” biz­ne­su. Bez zro­zu­mie­nia biz­ne­su nie moż­na dobrze wyko­nać swo­jej pra­cy w powyż­szych obszarach.

    Co do same­go arty­ku­łu no to przy­dał­by się jesz­cze jakiś prze­pis jak ten Top Management prze­ko­nać do tego żeby jed­nak nie upie­ra­li się przy tej aspi­ry­nie poda­wa­nej od lat. Niestety z tego typu sytu­acja­mi spo­ty­kam się na co dzień, a że obec­ny klient to orga­ni­za­cja budże­to­wa to pod­wa­ża­nie celo­wo­ści jest wręcz nie­for­mal­nie zabro­nio­ne – nie­mal­że ude­rza w honor zle­ce­nio­daw­cy (no bo prze­cież on wie co robi), a nie­ste­ty prak­ty­ka lat ubie­głych nie daje zbyt wie­le do myśle­nia pomi­mo tego, że zle­ca­ne roz­wi­nię­cia sys­te­mu nie zawsze były pasmem sukcesów.

    1. Jaroslaw Zelinski

      ” jakiś prze­pis jak ten Top Management prze­ko­nać do tego żeby jed­nak nie upie­ra­li się przy tej aspi­ry­nie” – dyplo­ma­cja i jesz­cze raz dyplo­ma­cja 🙂 czy­li ja koń­czę na reko­men­da­cjach i sygna­li­zu­je ryzy­ka. Żaden lekarz nie ma pra­wa przy­mu­su ale powi­nien infor­mo­wać o poten­cjal­nych skutkach. 

    2. natur

      Może źle się wyra­zi­łem. Podjąłem się stwo­rze­nia stra­te­gii infor­ma­ty­za­cji pew­nej spół­ki. Temat bar­dzo obszer­ny i pra­co­chłon­ny, ale stwier­dzi­łem, że spró­bu­ję wraz z dwo­ma współpracownikami. 

      Umówiłem się na spo­tka­nie ze spe­cja­li­stą ds. IT w danej spół­ce i zaczę­li­śmy roz­mo­wę. Próbowałem mode­ro­wać tą roz­mo­wę w celu zdo­by­ciia potrzeb­nych infor­ma­cji. Oprócz tego, że zdo­by­łem wie­dzę na temat sta­nu ogól­ne­go IT w fir­mie (spe­cja­li­sta podał bar­dzo wie­le potrzeb­nych fak­tów). Ponieważ oso­ba, z któ­rą roz­ma­wia­łem była bar­dzo kom­pe­tent­na, to stwier­dzi­łem, że war­to zapy­tać o stra­te­gię orga­ni­za­cji i w jaki spo­sób dział IT wpi­su­je się” w tą stra­te­gię i wte­dy usły­sza­łem tą odpowiedź:
      Ja wiem, że takie coś ist­nie­je i jest waż­ne, ale dla mnie to są rze­czy zbęd­ne i nie­zro­zu­mia­łe – bełkot”.

      Szkoda tyl­ko, że w więk­szo­ści pol­skich śred­nich spół­kach nawet kie­row­nic­two na pozio­mie dyrek­to­rów nie wie jaka jest stra­te­gia spół­ki i jakie są cele tak­tycz­ne spółki.

      Zgadzam się ze stwier­dze­niem, że pro­gra­mi­sta czy spe­cja­li­sta ds. IT nie musi znać stra­te­gii. Dlaczego? dla­te­go, że to nie jest klu­czo­we w jego pra­cy, on raczej ope­ru­je na celach operacyjnych.

    3. Jaroslaw Zelinski

      Nawiązując do tezy: Zgadzam się ze stwier­dze­niem, że pro­gra­mi­sta czy spe­cja­li­sta ds. IT nie musi znać stra­te­gii. Dlaczego? dla­te­go, że to nie jest klu­czo­we w jego pra­cy, on raczej ope­ru­je na celach ope­ra­cyj­nych.”, ale szef IT powi­nien bo jest czę­ścią kadry kie­row­ni­czej i powi­nien znać i rozu­mieć stra­te­gię fir­my, któ­ra repre­zen­tu­je oraz umieć oce­nić czy to co robi (lub pla­nu­je robić) wspie­ra tę stra­te­gie czy jej szko­dzi. Jeżeli fir­ma nie ma sze­fa IT„a jedy­nie spe­cja­li­stę od spra­wa ope­ra­cyj­nych” (któ­ry nie poczu­wa się do stra­te­gii) to nie powi­nien on się w ogó­le mie­szać (ten spe­cja­li­sta) w pro­ces jakiej­kol­wiek ana­li­zy wyma­gań, a w szcze­gól­no­ści kie­ro­wać nim.

Dodaj komentarz

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