Dzisiaj krótko. Frustracja dostawców oprogramowania chyba narasta, bo teksty takie jak poniżej, pojawiają się coraz częściej. Rzecz w tym, że rynek IT to nie tylko firmy ja te, reprezentowane przez autora tego tekstu, który słusznie zauważa, że:

1) Specyfikacje są napisane bardzo ogólnikowo. Trudno rozeznać się co autor miał na myśli.To jeden z największych problemów w IT, znany jako problem huśtawki. Kto bowiem pisze OPZ (Opis Przedmiotu Zamówienia) czy też SIWZ (Specyfikację Istotnych Warunków Zamówienia)? ? najczęściej dostaje to zadanie urzędnik. Urzędnik zarabia znacznie poniżej średniej w branży IT. Nawet jeśli to informatyk, na co przy zarobkach urzędników szansa jest minimalna) to jest mała szansa, że zna się i na stronach internetowych, aplikacjach mobilnych, hostingu i wszystkich rozwiązaniach SaaS. Pierwsza opcja to, że przeklei to co znajdzie w internecie (w innych przetargach). Druga opcja, to że wybierze dostawce i dostanie specyfikację od niego. A zapewniam Was, że dostawca zadba, by w OPZ czy SIWZ znalazły się zapisy preferujące jego rozwiązanie. Istnieje opcja trzecia, czyli wynajęcie niezależnego konsultanta. Zdarzało mi się być w takiej roli. Naprawdę tylko bardzo świadomi klienci wiedzą, że niezależny konsultant musi być dobrze wynagradzany za swoją niezależność i ekspercką wiedzę. Dostępność konsultantów jest też bardzo niewielka a mało która instytucja ma na nich przewidziane budżety. (źr: Milion złotych za stronę www. Jak wyglądają przetargi? | INNPoland.pl).

Od siebie dodam, że w moich oczach to nie tyle problem w wynagrodzeniu urzędnika, a w tym, że pisanie OPZ to nie jest jego rola i kompetencja. Literatura przedmiotu (rola urzędu w Państwie) zawiera wiele różnych rozważań na ten temat,

ja jednak zgadzam z autorami, którzy twierdzą, że rolą urzędu jest wykonywanie prawa i wszelkie działania urzędnika powinny być stosowaniem prawa. Jeżeli jakieś działanie nie jest stosowaniem prawa, urzędnik powinien zasięgać opinii biegłego.

Urzędnicy (referenci) powinni być z wykształcenia prawnikami (prawo administracyjne) z powodów oczywistych: stosowanie prawa wymaga jego rozumienia. Polecam doskonały artykuł, którego fragment zacytuję:

Jeżeli twój prawnik rozumie kontrakt lepiej niż twoi ludzie z biznesu, oznacza to że zarówno prawnik może mieć problem z tłumaczeniem prawnych komponentów całej transakcji, ale także że twój biznes w niewłaściwy sposób komunikuje prawnikowi cele i założenia biznesu, którego umowa dotyczy. Może czas coś z tym zrobić? (źr.  https://www.linkedin.com/pulse/tw%C3%B3j-prawnik-rozumie-kontrakt-lepiej-ni%C5%BC-twoi-ludzie-warchol-lewicka/ )

W sądzie sprawa jest “czysta”: sędzia nie może wydawać opinii innych niż prawne, kwestie specjalistyczne musi zlecać biegłemu (dowód z opinii biegłego).

Ludziom wmówiono, że osobą właściwą do opisu wymagań na oprogramowanie jest przyszły użytkownik. Nic bardziej błędnego: ma on takim sam konflikt interesu jak dostawca oprogramowania. Swego czasu pisałem:

Ogłaszający taki przetarg zapłaci za:

  1. prawo korzystania z Aplikacji (w ustalonej firmie np. licencji),
  2. wszelkie konieczne usługi poprzedzające normalne użytkowanie Aplikacji,
  3. jeżeli na rynku nie jest oferowane wymagane oprogramowanie, zostanie ono ?napisane? na podstawie Specyfikacji specjalnie dla Zamawiającego.

[…] To co nazy­wa­my Opi­sem Przed­mio­tu Zamó­wie­nia jest czymś wię­cej niż tyl­ko Spe­cy­fi­ka­cja opro­gra­mo­wa­nia. Dobrą prak­ty­ką jest roz­dzie­la­nie tych trzech powyż­szych ele­men­tów, ogrom­ną wygo­dą jest jeże­li są to odręb­ne umo­wy lub odręb­ne załącz­ni­ki Umo­wy głów­nej. Spla­ta­nie razem tych aspek­tów naj­czę­ściej pro­wa­dzi do nie­po­ro­zu­mień, pro­ble­mów z inter­pre­ta­cją umo­wy w cza­sie spo­rów. W skąd­inąd cie­ka­wym arty­ku­le pew­na kan­ce­la­ria wska­zu­je przy­czy­ny, a jako roz­wią­za­nie pro­ble­mu wska­zu­je jedy­nie pra­wo do wyco­fa­nia sie z umo­wy:Nie ma recep­ty na popraw­ne opi­sa­nie przed­mio­tu świad­cze­nia. Jeśli mamy roz­bu­do­wa­ne, pre­cy­zyj­ne spe­cy­fi­ka­cje, to i tak musi­my w umo­wie opi­sać zarzą­dza­nie zmia­ną, ze szcze­gól­nym uwzględ­nie­niem roli ana­li­zy. (źr. Przedmiot Zamówienia – instrukcja nie tylko dla prawników, na zupę pomidorową | | Jarosław Żeliński IT-Consulting)

Biorąc pod uwagę powyższe oraz to, że mowa tu o produktach inżynierskich (oprogramowanie) rekomenduje się:

  1. Opracowanie OPZ w postaci precyzyjnych schematów blokowych i wzorów matematycznych, jest zawsze lepsze niż niejednoznaczny opis wykonany językiem naturalnym, ten może być co najwyżej uzupełnieniem lub komentarzem. Ideałem jest tu precyzyjna dokumentacja techniczna (projekt techniczny). Należy pamiętać, że taki OPZ (w odróżnieniu od SIWZ) jest zawsze przedmiotem prawa autorskiego (Koralewski, 2014).*
  2. OPZ, będący dokumentem technicznym, specjalistycznym, nie musi być zrozumiały dla prawnika, a nie raz nawet dla samego Zamawiającego.
  3. Jeżeli sam zamawiający nie potrafi stworzyć poprawnego OPZ, powinien najpierw zlecić usługę opracowania OPZ, a potem dopiero szukać dostawcy tego, co opisano w tym OPZ. (Urząd Zamówień Publicznych, 2009).
  4. Usługa techniczna, oczekiwany sposób jej świadczenia, i jakość, to także przedmiot zamówienia, skuteczną praktyką jest więc umieszczenie ich opisu w OPZ a nie w treści umowy.(Urząd Zamówień Publicznych, 2009)

Nieco ponad dwa lata temu napisałem, że od lat stosuję w swoich analizach i projektach (między innymi) różnego rodzaju diagramy. Pomagają one ustalić precyzyjnie wszelkie aspekty i prawne i projektowe (źr. Opis przedmiotu zamówienia | | Jarosław Żeliński IT-Consulting)

Powyższe to kilka zebranych myśli, w odpowiedzi na tekst autora cytowany na początku. Ja adresuję ten tekst Zamawiającym, bo to oni są beneficjentami tego co zamawiają i są także sponsorami swoich, niejednokrotnie, porażek. Jak słusznie zauważa autor: na własne życzenie.

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).

Dodaj komentarz

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