Na stro­nie por­ta­lu analizawymagań.pl uka­zał się bar­dzo inte­re­su­ją­cy i war­to­ścio­wy wpis: wywiad z praw­ni­kiem, Łukaszem Węgrzynem. Zaczyna się tak:

Jakie są naj­częst­sze przy­czy­ny pro­ble­mów w umo­wach wdro­że­nio­wych i jakie są ich skut­ki z punk­tu widze­nia spo­rów sądo­wych na pol­skim ryn­ku IT?

Stosunkowo naj­częst­szym powo­dem spo­rów jest legen­dar­ny już zakres, a kon­kret­nie trud­ność w odpo­wie­dzi na pyta­nie o co tak napraw­dę się umówiliśmy.

Powodów takie­go sta­nu rze­czy jest wie­le. Jednym z nich jest mię­dzy inny­mi nie­wła­ści­wie wyko­na­na ana­li­za przed­wdro­że­nio­wa. Analiza to jeden z pod­sta­wo­wych załącz­ni­ków umo­wy wdro­że­nio­wej, wyzna­cza­ją­cy jej zakres, a zatem to, co ma zostać w wyni­ku pod­pi­sa­nia umo­wy zrealizowane.

Nierzadko ana­li­zy przed­wdro­że­nio­we posłu­gu­ją się gene­ral­ny­mi poję­cia­mi lub poję­cia­mi, któ­rych zna­cze­nie nie jest wystar­cza­ją­co jasno i pre­cy­zyj­nie okre­ślo­ne. Taka sytu­acja skut­ku­je z kolei dużą dowol­no­ścią inter­pre­ta­cyj­ną, a tym samym powo­du­je, że stro­ny umo­wy wcho­dzą w spór co do wła­ści­we­go brze­mie­nia kon­kret­nych zapi­sów ana­li­zy, któ­re decy­du­ją o zakre­sie umo­wy, czy­li o tym, co zosta­nie lub nie zosta­nie w wyni­ku umo­wy zrealizowane. 

Kolejna przy­czy­na pro­ble­mów nie jest zwią­za­na z tym ?CO? mamy zro­bić, ale ?JAK? to mamy zro­bić. W prak­ty­ce spro­wa­dza się do sytu­acji, w któ­rej stro­ny nie­wy­star­cza­ją­co jasno i pre­cy­zyj­nie opi­sa­ły w umo­wie poszcze­gól­ne eta­py prze­bie­gu wdro­że­nia. To bar­dzo czę­sty pro­blem, w rezul­ta­cie któ­re­go stro­ny zaczy­na­ją się prze­rzu­cać odpo­wie­dzial­no­ścią co do reali­za­cji kon­kret­nych dzia­łań nie­zbęd­nych dla wła­ści­wej, a co naj­waż­niej­sze efek­tyw­nej reali­za­cji pro­jek­tu wdro­że­nio­we­go. Stad już tyl­ko krok do eska­la­cji spo­ru i cał­ko­wi­tej klę­ski pro­jek­tu. (Źródło: Rola ana­li­zy w umo­wie wdro­że­nio­wej- wywiad z Łukaszem Węgrzynem)

W powyż­szym cyta­cie (a gorą­co pole­cam cały wywiad) wytłu­ści­łem kil­ka klu­czo­wych tez.

Zakres pro­jek­tu to fak­tycz­nie klucz, przede wszyst­kim MUSI być zamknię­ty. Zaraz ode­zwą się zwo­len­ni­cy zwin­ne­go Agile.. ale poję­cie ​„zamknię­ty zakres pro­jek­tu” to nie żaden wodo­spad, zamknię­ty zakres pro­jek­tu ozna­cza tyl­ko i wyłącz­nie to, że ist­nie­je (zawar­to w umo­wie) kry­te­ria pozwa­la­ją­ce stwier­dzić, że (czy?) umo­wę wykonano.

Niewłaściwie wyko­na ​„ana­li­za przed-wdro­że­nio­wa” to nic inne­go jak doku­ment mają­cy wady opi­sa­ne wyżej i poni­żej w dal­szej części.

Bardzo waż­ne: nie tyl­ko CO ale tak­że JAK. Z [[BABoK]] wie­my, że poza tak zwa­nym opi­sem pro­duk­tu jako czar­nej skrzyn­ki (nasze CO chce­my), war­to wyko­nać tak­że opis tak zwa­ne bia­łej skrzyn­ki czy­li opi­sać ​„Jak to ma dzia­łać”. Bez tego ska­zu­je­my się na masę nie­ja­sno­ści brak kry­te­rium odbio­ru (co testować??).

Celem moim jest dzi­siaj przede wszyst­kim zachę­ce­nie Państwa do lek­tu­ry tego wywia­du i tyl­ko trosz­kę uzu­peł­nie­nie i słów Pana praw­ni­ka. Wywiad koń­czy się zaś tak:

Proszę o 5 klu­czo­wych rad dla osób, któ­re zaj­mu­ją się przy­go­to­wy­wa­niem umów wdrożeniowych.Z oczy­wi­stych wzglę­dów będzie to wyso­ko­po­zio­mo­we spojrzenie.
1.Po pierw­sze im jaśniej i pro­ściej tym lepiej.
2.Po dru­gie nie tyl­ko ?CO? ale rów­nież ?JAK.
3.Po trze­cie wła­ści­wy opis pro­ce­dur współ­dzia­ła­nia stron. Nie zosta­wiaj­my sza­rych stref, wzglę­dem któ­rych trud­no okre­ślić któ­ra ze stron jest za nie odpowiedzialna.
4.Po czwar­te kary umow­ne powin­ny sty­mu­lo­wać, nie para­li­żo­wać. Dobrze opi­sa­ny mecha­nizm kar umow­nych, opar­ty na obiek­tyw­nie wyli­czal­nych para­me­trach to napraw­dę rzad­kość w kon­trak­tach wdrożeniowych.
5.I po pią­te, pisz­my kon­trak­ty któ­re odpo­wia­da­ją zało­że­niom biz­ne­so­wym. Tak co do zakre­su pro­jek­tu, jak i spo­so­bu jego reali­za­cji. W prze­ciw­nym wypad­ku przy­go­tuj­my się na szu­fla­dy peł­ne umów.

(Źródło: Rola ana­li­zy w umo­wie wdro­że­nio­wej- wywiad z Łukaszem Węgrzynem)

Dodam od siebie:

1. umo­wa nie może być nie­zro­zu­mia­ła, żad­ne tłu­ma­cze­nia i bran­żo­wym (tak praw­ni­czym jak i infor­ma­tycz­nym) języ­ku nie są dopusz­czal­ne, w razie potrze­by słow­nik pojęć acz­kol­wiek ja oso­bi­ście pre­fe­ru­ję jasne wysła­wia­nie się i defi­nio­wa­nie listy trud­nych słów i korzy­sta­nie z nich w umowie.

2. Z moje­go doświad­cze­nia: nie lista wyma­gań na set­ki pozy­cji a pro­jekt, dokład­nie tak jak zama­wia się budow­le: kró­ki opis i rysun­ki tech­nicz­ne (w IT sko­men­to­wa­ne dia­gra­my UML).

3. Podstawa to plan komu­ni­ka­cji w pro­jek­cie i narzu­co­ne narzę­dzia (nie mail a współ­dzie­lo­ne na rów­nych pra­wach repo­zy­to­rium dokumentów).

4. Wysokie kary umow­ne budu­ją wyłącz­nie ase­ku­ra­cyj­ne, pozba­wio­ne samo­dziel­ne­go dzia­ła­nia pro­jek­ty, koń­czą­ce się w sty­ku ​„każ­dy zro­bił co miał zro­bić tyl­ko, że nie nie mamy”. Osobiście pre­fe­ru­ję umo­wy bez żad­nych kar umow­nych ale z pra­wem wypo­wie­dze­nia przez każ­da ze stron w dowol­nym momen­cie za roz­li­cze­niem prac wykonanych.

5. Umowa powin­na być rela­tyw­nie pro­sta, opar­ta na celach biz­ne­so­wych wdro­że­nia, każ­dy pro­jekt to odkry­wa­nie pro­ble­mów w toku prac, biz­ne­so­wy cel pro­jek­tu bywa cza­sem jedy­nym ​„świa­teł­kiem w tunelu”.