Po co?

Każda orga­ni­za­cja, poza stan­dar­do­wy­mi pro­ce­sa­mi zwią­za­ny­mi z wysta­wia­niem i księ­go­wa­niem doku­men­tów, czy też typo­wy­mi rela­cja­mi z klien­ta­mi, pro­duk­cją, itp. reali­zu­je pro­ce­sy biz­ne­so­we sta­no­wią­ce spe­cy­fi­kę jej dzia­ła­nia i wyko­rzy­stu­je wła­sne wypra­co­wa­ne know-how, któ­re bar­dzo czę­sto decy­du­je o prze­wa­dze na ryn­ku. Standardowe pro­ce­sy obsłu­gi­wa­ne są stan­dar­do­wym opro­gra­mo­wa­niem. A takie jak?

Specyfika orga­ni­za­cji czę­sto imple­men­to­wa­na jest jako kasto­mi­za­cja dostar­czo­ne­go stan­dar­do­we­go opro­gra­mo­wa­nia jed­nak prak­ty­ka poka­zu­je, że kasto­mi­za­cja po pierw­sze bar­dzo czę­sto nisz­czy spój­ność pier­wot­ne­go, goto­we­go już opro­gra­mo­wa­nia i pod­no­si koszt jego wdro­że­nia. Po dru­gie kasto­mi­za­cja powo­du­je, że know-how Zamawiającego, wtło­czo­ne” w dostar­czo­ny, stan­dar­do­wy pakiet opro­gra­mo­wa­nia, prze­cho­dzi auto­ma­tycz­nie na wła­sność dostaw­cy opro­gra­mo­wa­nia kasto­mi­zo­wa­ne­go (wię­cej o pra­wach autor­skich i know-how).

Aby chro­nić swo­je know-how, wyma­ga­nia doty­czą­ce wła­snej, spe­cy­ficz­nej logi­ki biz­ne­so­wej nale­ży zre­ali­zo­wać ją jako odręb­ne, dedy­ko­wa­ne opro­gra­mo­wa­nie inte­gro­wa­ne z opro­gra­mo­wa­niem stan­dar­do­wym. Pozwala to zacho­wać wszel­kie pra­wa do tego kodu przy Zamawiającym. 

Większość pro­jek­tów, któ­rych celem jest dostar­cze­nie dedy­ko­wa­nych funk­cji w nowym opro­gra­mo­wa­niu, to pro­jek­ty któ­rych celem jest dostar­cze­nie kil­ku lub kil­ku­na­stu usług apli­ka­cyj­nych reali­zu­ją­cych logi­kę biz­ne­so­wą spe­cy­ficz­ną dla zama­wia­ją­ce­go oraz ich inte­gra­cja już posia­da­nym (lub pla­no­wa­nym) goto­wym opro­gra­mo­wa­niem stan­dar­do­wym. Koszt reali­za­cji dedy­ko­wa­nych kom­po­nen­tów to ok. 50 – 250 tys. net­to wraz z inte­gra­cją. Jest to war­tość niż­sza niż alter­na­tyw­ny koszt kasto­mi­za­cji wpro­wa­dzo­nych w typo­wy sys­tem ERP.

Jak?

Mowa o pro­jek­cie reali­zo­wa­nym w spraw­dzo­ny na świe­cie spo­sób. Całość ma dwie zasad­ni­cze fazy: ana­li­za i pro­jek­to­wa­nie oraz imple­men­ta­cja. Analiza i pro­jek­to­wa­nie ma jeden cel: zro­zu­mieć biz­nes i opi­sać logi­kę biz­ne­so­wą sta­no­wią­cą know-how Zamawiającego oraz opra­co­wać archi­tek­tu­rę reali­za­cji tej logi­ki oraz archi­tek­tu­rę całe­go sys­te­mu IT Zamawiającego (wszel­kie inte­gra­cje z inny­mi ist­nie­ją­cy­mi sys­te­ma­mi). Implementacja odby­wa się ite­ra­cyj­nie-przy­ro­sto­wo pod nad­zo­rem mery­to­rycz­nym (tyl­ko reali­za­cja logi­ki biz­ne­so­wej) Analityka-projektanta . 

W pro­jek­cie udział bio­rą: Zamawiający, Analityk-pro­jek­tant oraz Developer wyko­naw­ca. Zaangażowanie tych trzech pod­mio­tów obra­zu­je poniż­szy diagram:

Zamawiający na począt­ku pro­jek­tu udzie­la infor­ma­cji o celu jaki chce osią­gnąć. Początkowo Zamawiający jest dość inten­syw­nie anga­żo­wa­ny tak­że na pozio­mie Zarządu podej­mu­ją­ce­go decy­zje stra­te­gicz­ne. Dalej w toku pro­jek­tu wyzna­czo­ne oso­by wspie­ra­ją Analityka. Analityk, któ­ry jest tak­że pro­jek­tan­tem roz­wią­za­nia, na począt­ku wspól­nie z Zamawiającym, ana­li­zu­je pro­blem i pro­jek­tu­je roz­wią­za­nie. Na tym eta­pie deve­lo­per, jeże­li został już wybra­ny, udzie­la ewen­tu­al­nych kon­sul­ta­cji technicznych. 

Standardowo deve­lo­per jest wybie­ra­ny dopie­ro jak powsta­nie pro­jekt, bo dopie­ro w tym momen­cie, deve­lo­per jest w sta­nie zło­żyć ofer­tę . Projektem jest tu wyłącz­nie archi­tek­tu­ra roz­wią­za­nia, oraz usłu­gi apli­ka­cyj­ne i ich logi­ka biz­ne­so­wa, któ­re zosta­ną dostar­czo­ne jako pierwsze.

Od momen­tu roz­po­czę­cia Realizacji, Analityk-pro­jek­tant peł­ni rolę Właściciela pro­duk­tu (pro­duct owner) i zarzą­dza jego roz­wo­jem i zmia­ną, deve­lo­per sta­je się tak­że Kierownikiem pro­jek­tu. Dalsza pra­ca odby­wa się w cyklu iteracyjno-przyrostowym:

Dzięki takie­mu podej­ściu zacho­wu­je­my zale­ty tak zwa­ne­go zwin­ne­go podej­ścia (szyb­kie roz­po­czę­cie bez nad­mia­ru doku­men­ta­cji) i niwe­lu­je­my poważ­ną wadę podej­ścia zwin­ne­go jaką jest nara­sta­ją­cy cha­os struk­tu­ry sys­te­mu z powo­du pomi­nię­cia eta­pu opra­co­wa­nia prze­my­śla­nej jego archi­tek­tu­ry i poli­ty­ki roz­wo­ju. Typową kon­se­kwen­cją cha­osu w pro­jek­cie są nara­sta­ją­ce kosz­ty two­rze­nia sys­te­mu i bar­dzo duże kosz­ty póź­niej­sze­go utrzy­ma­nia i roz­wo­ju. Przed w tym wła­śnie chro­ni nas począt­ko­wa ana­li­za i pro­jekt archi­tek­tu­ry. Na eta­pie ana­li­zy czę­sto powsta­ją reko­men­da­cje zmian orga­ni­za­cyj­nych, gdyż nowe narzę­dzie pra­cy prak­tycz­nie zawsze wyma­ga korek­ty pro­ce­dur i instrukcji.

Jeżeli jesteś developerem, złóż ofertę…

Każdy mój pro­jekt zawie­ra etap wybo­ru deve­lo­pe­ra, kon­kurs ofert pro­wa­dzi Zamawiający a treść zapy­ta­nia zawie­ra opra­co­wa­ny prze­ze mnie Opis Przedmiotu Zamówienia. Jeżeli jesteś zain­te­re­so­wa­ny zło­że­niem ofer­ty zapisz się na new­slet­ter jako deve­lo­per.