„Przykro nam, ale podjęliśmy decyzję o zakończeniu naszej współpracy” – taki komunikat może ściąć z nóg. Zwłaszcza jeśli przyjdzie do nas od software house’u z którym współpracowaliśmy od wielu lat. Co doprowadziło nas do takiej sytuacji? Dlaczego nasz wieloletni partner zapewniający nam obsługę IT, nagle się wycofał? Dlaczego zostawił nas na lodzie? Będziemy musieli mieć nerwy ze stali, żeby zmierzyć się z odpowiedziami na te pytania.
Niezależnie od tego, czy działamy jako start-up, czy też średnie przedsiębiorstwo z dłuższym stażem na rynku, musimy odpowiedzieć sobie na te trudne pytania. Co skłoniło firmę informatyczną do zostawienia nas samych z naszymi problemami? Co doprowadziło naszego IT partnera do stanu, w którym stwierdził, że ma już dosyć?
Powód nr 1: Brak budżetu na zapewnienie jakości oprogramowania
Innymi słowy – nie przewidujemy inwestowania w dobry software, ale oczekujemy wspaniałych rezultatów. W praktyce liczymy na to, że firma IT wprowadzi nowe funkcje do naszego produktu, ale nie zauważamy, że doskonalenie i wdrażanie nowych rozwiązań niesie ze sobą dodatkowe koszty. Zamykamy się na argument naszych partnerów, że sporą część budżetu pochłaniają rozbudowane testy automatyczne, czy też aktualizacje użytych bibliotek i pluginów. Wpadamy w pułapkę oszczędzania na własnej ofercie i tym samym pogrążamy się w długu technologicznym. Co oznacza ten dług? W największym skrócie — nasz grzech zaniechania dobrej analizy i projektowania. Zabieramy się za produkt niedostatecznie przygotowani. Po drodze ignorujemy wołania firmy IT, która bezskutecznie próbuje nas namówić na zwiększenie budżetu na niezbędne aktualizacje. Pokonanie długu pochłania czas, zasoby, i pieniądze, i na końcu musimy mierzyć się z bolesną myślą, że polegliśmy. Naszym specjalistom informatycznym pozostaje tylko rozłożyć bezradnie ręce w geście „a nie mówiliśmy?”.
Powód nr 2: Bardzo sztywne określenie zakresów prac
Jesteśmy w środku kryzysu naszego projektu IT. Wpadliśmy w dług technologiczny i bardzo długo udawaliśmy, że go nie ma. W końcu uznaliśmy, że musimy się zabrać za naprawienie błędów i wyprowadzenie projektu z powrotem na właściwe tory. Nasz partner proponuje nam możliwe rozwiązania i szeroki zakres prac, który trzeba też dostosować do dynamicznie zmieniającego się środowiska technologicznego. Oczywiście duży nakład pracy i perspektywa jej zwielokrotnienia oznacza podbicie finansowej stawki, co już niekoniecznie nam odpowiada. Mamy pomysł na to, żeby naprawić błędy taniej i wytyczamy bardzo sztywny zakres prac. Partner cierpliwie wyjaśnia, że to podejście jest tylko pozornie oszczędne i w dalszej perspektywie przełoży się na jeszcze większe nakłady i opóźnienia. Nie dajemy się przekonać. Docieramy do ściany zarówno z projektem, jak i ze współpracą z naszą firmą IT.
Powód nr 3: Zły model biznesowy produktu
Przygotowaliśmy i wdrożyliśmy produkt, w który zainwestowaliśmy sporo nakładów finansowych. Nawiązaliśmy długofalową współpracę z firmą IT, która pod kątem technicznym dostarczyła nam sprawnie działający produkt. Jesteśmy bardzo zadowoleni z efektu, ale po jakimś czasie stwierdzamy, że inwestycja nam się nie zwraca, a nasz produkt nie wywołał żadnej reakcji na rynku. Konsultujemy się z naszymi partnerami i słyszymy to, czego nie chcemy słyszeć. Dowiadujemy się, że przegapiliśmy duże zmiany na rynku i nasz produkt nie jest już w stanie skutecznie walczyć o uwagę odbiorcy. Nie zareagowaliśmy odpowiednio, a nasza strategia marketingowa i model biznesowy, które opracowaliśmy kilka lat temu już się postarzały. Nasze założenia były za bardzo sztywne i zostaliśmy daleko w tyle z technologią i marketingiem naszego produktu. Nadrobienie zaległości wymaga tytanicznej pracy, ogromnego budżetu, i przewartościowania całego założenia projektu. Nie jesteśmy na to gotowi. Pojawia się frustracja i bezsilność.
Powód nr 4: Oprogramowanie – nie chcemy uczestniczyć w procesie
Mamy super pomysł na oprogramowanie i znajdujemy firmę, której chcemy to powierzyć. Mówią do nas niezrozumiałym językiem, niepotrzebnie komplikują stworzenie tego, co chcemy wypuścić na rynek. Produkt jest prosty i zrealizowanie go nie powinno stwarzać większych problemów. Zlecamy, płacimy, nie musimy się angażować w proces, bo mamy specjalistów, którzy znają się na tym lepiej niż my. Software house tłumaczy nam znaczenie bliskiej współpracy, wspólnego projektowania, testowania i wdrażania. Nie chcemy w tym uczestniczyć, wolimy otrzymać gotowy i przetestowany produkt. Ku naszemu zdziwieniu firma rezygnuje z naszego zlecenia.
Powód nr 5: Scrum? Po co nam scrum?
Mamy duży projekt i chcemy umówić się z wykonawcą na z góry ustaloną cenę. Firma szacuje nam czas pracy na wiele miesięcy i zwraca uwagę, że w projekcie jest dużo luk i niedoskonałości, które mogą przysporzyć sporych problemów w trakcie realizacji. Sugerują nam metodykę scrum i wdrażanie kolejnych etapów po efektywnej i zwinnej pracy w sprintach. Mamy jednak z góry zaplanowany budżet i boimy się, że sukcesywne wdrażanie podbije nam cenę wykonania. Upieramy się przy sztywnej cenie za całość zlecenia. Jednocześnie nie przyjmujemy argumentów, że przy tak złożonym projekcie, jak zmienią się założenia, to cały kod trzeba będzie pisać od początku. Nasz software house wycofuje się z rozmów.
Powód nr 6: Przesadziliśmy ze skalą
Udało nam się pozyskać duży budżet. Mamy ambicje na stworzenie wielkiego systemu i jesteśmy zdecydowani na działanie. Nasz software house buduje nam system zgodnie ze specyfikacją. Wdrażamy projekt i nagle stajemy oko w oko z ogromnymi kosztami utrzymania takiego rozwiązania. Pojawia się duży problem finansowy i musimy szukać oszczędności. Niestety w najgorszym miejscu, czyli właśnie w kosztach funkcjonowania systemu.
Światełko w tunelu – jak tego wszystkiego uniknąć?
Powyższe czarne scenariusze niestety nie należą do rzadkości. Na szczęście możemy uczyć się na (cudzych lub swoich) błędach i uniknąć sytuacji, kiedy nasz software house zostawia nas w samym środku kryzysu. Przygotujmy się dobrze do projektu i pamiętajmy o:
• aktualizowaniu oprogramowania
• unikaniu długu technologicznego
• elastycznym zakresie prac w kryzysie
• ciągłym monitorowaniu naszej grupy docelowej i sytuacji na rynku
• dostosowywaniu naszej strategii marketingowej i biznesowej do dynamicznie zmieniającej się rzeczywistości
• merytorycznej współpracy z firmą IT przy tworzeniu produktu
• wybraniu metodyki Scrum
• odpowiedniej skali projektu.
