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:
- prawo korzystania z Aplikacji (w ustalonej firmie np. licencji),
- wszelkie konieczne usługi poprzedzające normalne użytkowanie Aplikacji,
- jeżeli na rynku nie jest oferowane wymagane oprogramowanie, zostanie ono ?napisane? na podstawie Specyfikacji specjalnie dla Zamawiającego.
[…] To co nazywamy Opisem Przedmiotu Zamówienia jest czymś więcej niż tylko Specyfikacja oprogramowania. Dobrą praktyką jest rozdzielanie tych trzech powyższych elementów, ogromną wygodą jest jeżeli są to odrębne umowy lub odrębne załączniki Umowy głównej. Splatanie razem tych aspektów najczęściej prowadzi do nieporozumień, problemów z interpretacją umowy w czasie sporów. W skądinąd ciekawym artykule pewna kancelaria wskazuje przyczyny, a jako rozwiązanie problemu wskazuje jedynie prawo do wycofania sie z umowy:Nie ma recepty na poprawne opisanie przedmiotu świadczenia. Jeśli mamy rozbudowane, precyzyjne specyfikacje, to i tak musimy w umowie opisać zarządzanie zmianą, ze szczególnym uwzględnieniem roli analizy. (ź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ę:
- 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).*
- OPZ, będący dokumentem technicznym, specjalistycznym, nie musi być zrozumiały dla prawnika, a nie raz nawet dla samego Zamawiającego.
- 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).
- 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.