Rynek zbytu jest głównym weryfikatorem stopnia powodzenia podejmowanego przedsięwzięcia. To on ocenia, czy produkt nań wniesiony okrzyknięty zostaje mianem przełomowego dzieła czy raczej okazuje się kiczem niedostosowanym do realiów i potrzeb użytkowników. W głównej mierze jednak przekaz ów nie jest zero-jedynkowy i stawia twórców przed trudną decyzją: zmienić repertuar, grać głośniej czy zamilknąć w ogóle?
Na początek aksjomat – nie ma oprogramowania bez defektów. Mimo rosnącej świadomości na temat istotności testowania produktu, nawet najdociekliwsze oko testera nie jest w stanie konkurować z pomysłowością i nieprzewidywalnością zachowań osób eksploatujących software. Rezultaty tych eksploracji nierzadko przyprawiają o ból głowy programistów próbujących załatać lukę w systemie czy aplikacji. O tym wszystkim wiedzą wytwórcy oprogramowania na każdym stopniu firmowej hierarchii. Na kim spoczywa więc największa odpowiedzialność za ewentualne luki znalezione w finalnej wersji aplikacji?
Na pewnym etapie testowania oprogramowania testerzy częstokroć spotykają się z oporem osób odpowiedzialnych za projekt jako całość. Opór ów można najczęściej streścić słowami godnymi szefa grupy archeologów: „Długo jeszcze będziecie przy tym grzebać? Wszystko już chyba znaleźliście, prawda?”. Co bardziej empatyczny lider zapyta z nieukrywaną troską: „Jak myślicie, dużo jeszcze znajdziecie tych bugów?”. Niestety, ani archeologia, ani tym bardziej wróżenie z kuli nie leży w gestii testerów, toteż ci, wykonując pracę sumiennie, nie ustaną, póki nie zgłoszą wszystkiego, co wyda im się podejrzane, niepożądane lub po prostu bezsensowne. Oni przecież tylko wykonują polecenia przychodzące z góry.
Samo wytwarzanie oprogramowania różni się znacząco od rodzaju rynku oraz grupy docelowej użytkowników, tych pośrednich, jak i końcowych. Innym restrykcjom będzie podlegać produkt z branży medycznej, który będzie musiał być solidnie udokumentowany, sprawdzony i pobłogosławiony akredytacją ciał certyfikujących, inaczej wydana zostanie gra komputerowa przeznaczona na różne konsole i komputery, a zupełnie inną kwestią są proste strony dla wędkarzy niepodlegające niemal żadnym restrykcjom. Istnieje natomiast wspólny mianownik dla każdego rodzaju cyfrowego tworu – warsztat programistyczny. Ten warsztat opiera się o liczne godziny spędzone na poznawaniu wzorców projektowych, doskonaleniu umiejętności analitycznego podejścia do problemów czy nauce nowych i zgłębianiu już znanych języków i frameworków. Jeśli więc poczynione zostanie założenie, iż programista nie sabotuje projektu i rzeczywiście rozwija projekt zgodnie ze sztuką, czy uznać można, że ponosi odpowiedzialność za defekty znalezione dopiero na rynku?
Powyższe dywagacje rozszerzyć można o role i pozycje architektów, analityków biznesowych, projektantów UI oraz UX, marketingowców oraz wszelkiej maści kierowników szczebla dowolnego. Konkluzja będzie zwykle ta sama: „Czy to moja wina, że nie zadziałało to czy to?”, co w linii prostej prowadzi do starej jak świat spychologii będącej dość naturalnym mechanizmem obronnym – wyparcia. Dużym błędem jest poprzestawanie tylko na szukaniu winowajcy, a jeszcze większym – znajdowanie kozła ofiarnego. Takie działanie jest zaprzeczeniem tego, na co defekt przychodzący z rynku powinien otwierać oczy, czyli na budowanie wspólnej, a nawet współdzielonej odpowiedzialności za dostarczany produkt, jako całość, od A do Z. Jest to tylko mały krok w tworzeniu zgranego zespołu, ale wskazuje osobom zawiadującym rytmem firmowej orkiestry na istotę zwalczania odpowiedzialności rozproszonej. Miarą dojrzałości współpracowników będzie więc stopień zaangażowania w nieprawidłowości, których bezpośrednimi autorami nie są oni sami. Czy w takim razie orkiestra, która pomyliła partytury, może naprawić swoje błędy i uratować koncert? Z pewnością, jednak trzeba pamiętać, że nawet najpiękniej sprzedany i zagrany koncert może nie wystarczyć, by uratować filharmonię przed upadkiem.