W teorii podział jest klarowny i nie stwarza żadnych większych problemów. W praktyce, jak to w praktyce... „Wszystko zależy”. Wielu klientów, szukając wykonawcy produktu cyfrowego, często zadaje sobie pytanie: “Powinienem wybrać agencję interaktywną, czy zaawansowany technologicznie Software House?” No właśnie.
W teorii agencja interaktywna nie jest Software House’em, a Software House nie jest agencją interaktywną. W praktyce bardzo często agencje interaktywne posiadają część kompetencji profesjonalnego Software House`u, a Software House`y nabywają kompetencje agencji interaktywnych.
Zatem, czym się kierować, jakie kryteria uwzględnić, wybierając dostawcę oprogramowania?
Cierpliwości :) Nim odpowiem, podzielę się drobną, ale ważną obserwacją. Z naszych doświadczeń wynika, że wybór dostawcy oprogramowania częściej uwarunkowany jest osobistymi preferencjami niż racjonalnymi przesłankami. Dlaczego?
Zainteresowany zmianą Software House?
Bliższa koszula ciału, czyli jak wybrać software house?
Podczas gdy agencja interaktywna wywodzi się z potrzeb marketingowych swoich klientów i rozwija swoje kompetencje w kierunku technologii, Software House odbywa odwrotną drogę. Posiadając wiedzę o technologiach, nabywa kompetencje marketingowe.
Agencje interaktywne wzbudzają większe zainteresowanie Dyrektorów Marketingu, a klientami Software House`ów często są firmy zatrudniające CTO (Chief Technology Officer).
Przenikanie się zakresów kompetencji (technicznych z marketingowymi) jest dziś rynkową normą. Ma ono swoje ewidentne plusy (everything under one roof), ale ma także wyraźne minusy (not everything is under control).
Cierpliwości, co przez to rozumiem, wyjaśnię. Już za chwilę ;) Na razie wróćmy do Dyrektorów Marketingu i CTO.
Klient o większych kompetencjach technicznych (CTO) będzie w stanie ocenić jakość kodu aplikacji webowej. Klient o większych kompetencjach marketingowych nacisk położy przede wszystkim na ogólne wrażenie, jakie aplikacja robi. Na przykład, w jakim stopniu wpisuje się w branding, wizerunek firmy. W jakim stopniu jest z nim spójna.
W przypadku wyboru dostawcy oprogramowania wydaje się, że firma, którą reprezentuje CTO jest w lepszym położeniu niż przedsiębiorstwo mające marketingowo zorientowanego reprezentanta, prawda? I tak, i nie, to zależy.
Od czego? Raczej, od kogo? Zależy głównie… Od dostawcy oprogramowania. Tak jest, to on jest wszystkiemu winien! Nawet jeśli często jest klasycznym “winner`em”.
Jeśli agencja interaktywna, Software House gra czysto, oferuje wysoką jakość, dba o swojego klienta, to zarówno osoba “techniczna”, jak i “nietechniczna” będzie zadowolona ze współpracy. Jeśli producent softu zawala na całej linii, to jedyna różnica jest taka, że klient “techniczny” nieco szybciej odkryje, że jego oczekiwania nie są spełniane.
Na przykład, że aplikacja nie działa poprawnie. Nie jest rozwijana zgodnie z planem itd. Cierpliwości ;) O typowych problemach i typowych przyczynach zmiany producenta opowiem szczerzej już za chwilę.
Tymczasem wróćmy do głównego wątku, czyli do wrażenia, że nie wszystko idzie tak, jak powinno.
Jeśli sytuacja nie ulegnie poprawie, to bez względu na zakres kompetencji klienta, decyzja będzie jedna! “Zmieniamy dostawcę oprogramowania. Tym razem poszukamy jakiegoś Software House`u”.
Niby nic niezwykłego. Ale w takiej sytuacji nie tyle chodzi, by powiedzieć sobie: “No trudno, mieliśmy pecha”, ile o to, by nie popełnić kolejny raz tego samego błędu.
Pomożecie? Pomożemy! Zapraszamy do nas!
Nie zawsze pierwszy wybór okazuje się najlepszym z możliwych i w pewnym momencie trzeba po prostu zmienić firmę. Jasna sprawa. Nie jest to ani specjalnie trudne, ani specjalnie ryzykowne, w szczególności, gdy odpowiednio się do zmiany przygotujemy.
I właśnie dlatego dziś opowiem o sytuacji, w której znajduje się wiele firm. Po przeczytaniu tego artykułu będziesz super przygotowany do zmiany producenta oprogramowania.
Każdego tygodnia dostajemy po kilka zapytań. Najczęściej pytacie nas: “Planujemy zmienić obecny Software House na inny, co powinniśmy zrobić?”, “Chcemy przekazać nasz soft do innego Software House`u, ale nie wiemy, od czego zacząć. Co powinniśmy zrobić?”, “W jaki sposób możecie nam pomóc w kwestii zmiany dostawcy oprogramowania?” I to są bardzo dobre pytania, na które mamy dobre odpowiedzi ;)
Not everything is under control, czyli najczęstsze przyczyny rezygnacji z usług producentów oprogramowania
Bez względu na to, czy jesteś CTO, czy Dyrektorem Marketingu, CEO, Prezesem Spółki, Właścicielem Firmy ta sytuacja będzie Cię denerwować. Ileż razy można "prosić się drugiej strony" o poprawę czegoś?
Ile razy można prosić o e mail, telefon, wyjaśnienie, wskazanie terminu? Ileż razy nieotrzymanie odpowiedzi, nieoddzwonienie, niedotrzymanie deadline`u można uznać za wypadek przy pracy, który może się zdarzyć każdemu?
Jakość obsługi spada, jakość kodu spada, aplikacja, strony nie działają, jak na należy. Produkt nie jest rozwijany zgodnie z planem. A to przecież nie koniec problemów z tą firmą. Pewnie dlatego, zmiana agencji interaktywnej, software house`u jest dziś zjawiskiem powszechnym. Ma swoje przyczyny. Najczęściej chodzi o to, że dostawca:
- pracuje za wolno
- nie dotrzymuje terminów
- nie nadąża w rozwoju swoich kompetencji z zakresu technologii
- podnosi ceny, nie podnosząc jakości
- wiecznie “nie ma czasu” na rozwój Twojego projektu i w końcu zaczynasz myśleć, że jesteś 7 klientem w kolejce, zupełnie jak na infolinii.
“Ileż można?” - no właśnie, ileż można. Dostawca pracuje wolno, nie dotrzymuje terminów, bo albo zajmuje się czymś innym, albo dopiero uczy się rozwiązywać dany problem. Albo, co jest jeszcze gorsze, jego najlepszy specjalista właśnie zmienił pracę.
Analizujesz jakość kodu i łapiesz się za głowę. Nie jest za grosz czytelny, nie jest wydajny, o możliwości jego rozbudowy w przyszłości nawet nie chcesz myśleć. Może się także okazać, że wykonawca myśli, że się nie znasz.
A skoro się nie znasz, to pewnie bez różnicy Ci, czy zrobi dokumentację strony albo, czy odda program bez testów. Tylko zapomniał, że Ty także się uczysz i doskonale sobie zdajesz sprawę, że bez testów automatycznych nie można robić oprogramowania, bo to znacząco obniża jego jakość. Albo, że dokumentacja rozbudowanej strony to oczywista oczywistość.
Gdy pytasz, na przykład o możliwość zastosowania technologii Python do Twojego projektu, Project Manager zbywa Cię ogólnikami. Zupełnie, jakby sam nie do końca się orientował, czy ma to sens.
Znaczy się, któryś z Was czegoś nie wie, tylko dlaczego Ty masz za niewiedzę płacić? I to coraz więcej. A płacąc, coraz więcej i więcej, czekasz i czekasz, dokładasz do projektu... I nic. Nic się nie dzieje.
Zupełnie, jak w polskim filmie ;) Nie dostajesz dokumentacji projektu, a powinieneś ją mieć. Nie masz wyników testów, a powinieneś je mieć. Nie wiesz tak naprawdę, co się dzieje, na jakim etapie projektu jesteś, kiedy powstanie Twoje oprogramowanie… I tak dalej, i tak dalej. Wiele rzeczy powinieneś mieć, a nie masz. I raczej mieć nie będziesz.
Dobrze, zostawmy to. Wiadomo, o co chodzi. Wszystko miało być pod jednym dachem, tyle że dach przecieka, dochodzi do zwarcia. Pierwszego, trzeciego, trzydziestego trzeciego. Dość! Coś trzeba z tym zrobić! Tylko co? - pytasz siebie.
Zmienić! Tak nie powstanie nigdy profesjonalne oprogramowanie. Zmienić, jak najszybciej i jak najmądrzej. Czyli zgodnie z konkretnym planem. Opowiem o nim za chwilę. Cierpliwości ;)
Przygotowanie do zmiany producenta produktu cyfrowego
Co do zasady - zmieniaj zawsze na lepsze. Na lepszą obsługę, lepszą firmę w danej kategorii, działającą na danym rynku. Lepszą w produkcji aplikacji webowych, mobilnych, integracji systemów, tworzeniu rozwiązań dedykowanych, rozwiązaniach chmurowych itd.
Na polskim rynku specjalizują się w tym Software House`y. Nawet jeśli marketingowy charakter agencji interaktywnej jest Ci bliższy, wybierz Software House, który zapewni Ci Jakość, a nie Byle-Jakość. Stworzy oczekiwane przez Ciebie oprogramowanie.
Skoro agencja interaktywna nie jest Software House`em... To po prostu nim nie jest. Jest agencją interaktywną. Nie tylko z nazwy. I taką będzie na każdym rynku.
Produkt cyfrowy musi być przede wszystkim funkcjonalny, użyteczny, technologicznie aktualny i perspektywicznie rozwijany, bądź dobrze przygotowany do rozwoju.
No dobrze, idźmy dalej. Mamy jeszcze do omówienia kilka naprawdę konkretnych i ważnych kwestii, o które trzeba zadbać, zmieniając dostawcę oprogramowania.
Zmiana Software House to proces. Składają się na niego:
- kwestie organizacyjne (sposób przekazania kodu źródłowego do klienta)
- techniczne (depozyt kodu źródłowego, klucze dostępu)
- prawne (pola eksploatacji, możliwość modyfikacji kodu).
O ile kwestie prawne są bardzo zindywidualizowane, o tyle kwestie techniczne będą w większości przypadków wyglądały bardzo podobnie. Załóżmy, że podpisana przez Ciebie umowa nie rodzi prawnych dylematów i po zakończeniu współpracy zachowałeś prawo dostępu do kodu źródłowego oraz jego modyfikacji.
Jeśli kwestie prawne masz dopięte, możesz pomyśleć o kwestiach technicznych, bez których podjęcie pracy przez nowego producenta oprogramowania nie będzie możliwe. W pierwszej kolejności musisz sobie zapewnić dostęp do kodu źródłowego.
Dostęp do kodu źródłowego i dokumentacji oprogramowania
Zacznijmy od definicji i przybliżenia pojęcia kodu źródłowego, który jest po prostu zapisem operacji, wyrażonych w językach programowania, jakie ma wykonywać komputer. Operacje są dokonywane na danych pozyskanych lub posiadanych.
Warto jeszcze uściślić, że kod źródłowy, czyli taki, który będzie zrozumiały dla maszyny, jest kodem wynikowym, a więc musi być poddany kompilacji. Zazwyczaj składa się on ze zbiorów plików.
Wskazane jest ich konsolidowanie, a więc zebranie w ramach jednego pliku. Nie ma co się temu dziwić, duże projekty to setki, tysiące plików, które należy odpowiednio uporządkować, by szybko i łatwo z nimi, na nich pracować.
Dokonajmy jeszcze jednego uściślenia. Kod źródłowy obejmuje nie tylko program, ale także skrypty, biblioteki oraz dokumentację. Mając za sobą przybliżoną, ale za to niesłychanie praktyczną definicję możemy przejść do kolejnych kwestii.
Problem dostępu do kodu źródłowego to problem dysponenta kodu źródłowego, nośnika oraz formy, sposobu dostępu do niego (zabezpieczeń).
Dysponentem kodu źródłowego zazwyczaj jest firma, wykonawca, ale coraz częściej mamy do czynienia z sytuacją (w szczególności przy dużych i bardzo dużych projektach), w której kody źródłowe są deponowane (Software Escrow) u depozytariusza.
Depozytariusz (firma) jest stroną trzecią, która zobowiązuje się przechowywać, chronić dostępu do kodu i wydawać go w szczegółowo określonych w umowie sytuacjach.
Najczęściej chodzi o zabezpieczenie nabywcy oprogramowania przed utratą kodu źródłowego na skutek:
- bankructwa wykonawcy (czego wykluczyć nie może żadna firma)
- zaprzestania prac rozwojowych i utrzymaniowych
- awarii nośników (np. serwerów, na których jest przechowywany)
- fizycznego zniszczenia kodu (np. w wyniku sytuacji losowych, bądź kryminalnych - ataki hakerskie)
- oraz - last but not least - zwiększenia obustronnego zaufania. Wykonawca oddający do depozytu kod źródłowy i dokumentację oprogramowania nie może żądać ich zwrotu w dowolnym momencie.
Dostęp do kodu źródłowego jest więc nie tylko kwestią formalno-prawną. Jest także kwestią rynkowych wzorów Dobrych Praktyk. Dzięki którym obie strony są w stanie chronić swoje podstawowe interesy. Jeśli zatem nie zabezpieczyłeś się w ten sposób, wybierając pierwszego wykonawcę, tym razem powinieneś o tym pomyśleć.
Nie jest to absolutna konieczność, ale jest to praktyka zwiększająca poczucie bezpieczeństwa. Depozytariusz, w ramach możliwości określonych w umowie, stanowić będzie w sytuacjach konfliktowych namiastkę instytucji arbitrażu.
Jeśli zatem korzystasz już z usługi Software Escrow (z której korzysta coraz więcej firm) wystarczy, że Twoja firma poprosi o wydanie najbardziej aktualnej, kompletnej wersji kodu źródłowego wraz z pełną, kompletną dokumentacją.
Dostęp do kodu źródłowego to kwestia także nośnika. W przypadku Software Escrow będzie nią fizyczny nośnik w postaci płyty CD, dysku przenośnego. W pozostałych przypadkach dane są przechowywane na serwerach, do których dostęp jest zabezpieczony w postaci:
- loginu i hasła (FTP - File Transfer Protocol - jest to metoda nadal wykorzystywana, ale uznawana za coraz mniej profesjonalną, ryzykowną, nierekomendowaną)
- loginu i klucza (SSH - Secure Shell - jest to metoda o wiele bardziej bezpieczna i uznawana obecnie za standard).
Odejście od protokołu FTP na rzecz protokołu SSH jest motywowane bezpieczeństwem danych, które w tym drugim wariancie są chronione o wiele bardziej skutecznie.
W pierwszym przypadku login i hasło są przechowywane na serwerze, a dostęp do danych następuje po pozytywnej weryfikacji, porównaniu danych wprowadzonych w trakcie logowania z danymi znajdującymi się na serwerze. Niestety, jest to metoda wyjątkowo podatna na cyberataki.
Protokół SSH oparty jest na wygenerowaniu o wiele bardziej złożonych, unikalnych kluczy dostępu, w wariancie prywatnym i publicznym. Klucz publiczny jest zapisany na serwerze, natomiast prywatny jest zdeponowany w rękach właściciela kodu źródłowego. Dostęp do plików jest możliwy tylko dzięki kluczowi prywatnemu.
Klucze - prywatny i publiczny - muszą być zgodne, ale nie oznacza to, że są identyczne. Na tym polega różnica, przesądzająca o bezpieczeństwie. Dzięki temu Twoje dane (pomyśl o konsekwencjach wycieku danych osobowych, nie tylko danych osobowych Twoich, ale także Twoich klientów) są o wiele lepiej chronione.
Posiadanie loginów, haseł, kluczy pozwala już rozpocząć pracę nad aplikacją, ale by była ona sprawna i bezproblemowa Twój nowy Software House poprosi Cię także o dostarczenie dokumentacji projektu. Co powinna zawierać? Przede wszystkim kilka instrukcji, opisów i specyfikacji np.:
- instrukcję generowania kodu wynikowego, konfiguracji środowiska do takich działań
- opis struktur katalogów kodu źródłowego
- specyfikację środowiska sprzętowego i systemowego.
Kod źródłowy to struktura, która przez swoją złożoność i wielkość wymaga uporządkowania. Do zapanowania nad wynikami prac wielu programistów (nad dużymi projektami zazwyczaj pracują zespoły), używane są Repozytoria Kodu Źródłowego. Nie wchodząc w techniczne szczegóły, Repozytorium pozwala zapanować także nad przebiegiem całego procesu tworzenia oprogramowania oraz pozwala skuteczniej i wygodniej synchronizować prace.
Co jeszcze ważniejsze, służy ono do dokumentowania prac. Innymi słowy, mamy wgląd w historię wprowadzanych zmian. Mamy dostęp do informacji, do wersji poprzednich, dzięki czemu możliwe jest ich odzyskiwanie (np. wersji pozbawionych błędów, luk, konfliktów).
Zmieniając Software House, trzeba także pamiętać o zapewnieniu dostępu do Repozytorium Kodu. Dostęp do niego jest możliwy za pomocą loginu i hasła lub loginu i klucza.
Spokojnie, spokojnie!
Dla osoby “technicznej” wszystkie powyższe kwestie brzmią naturalnie i znajomo. Normalna sprawa, prawda? Otóż to. Tak w praktyce - no dobrze, w dużym, ale koniecznym, uproszczeniu - to wygląda. W przypadku każdej firmy.
Dla osoby “nietechnicznej” brzmi to może trochę onieśmielająco, ale spokojnie. Nie ma się czego bać ;) Naprawdę. W rzeczywistości chodzi o proste kwestie, z którymi sobie bez problemu poradzisz samodzielnie. W szczególnych przypadkach możesz skorzystać z pomocy przedstawiciela nowego Software House`u. Na przykład naszego :)
Pracowaliśmy z różnymi klientami i wiemy jedno. Ogólna orientacja w tej tematyce, którą właśnie nabyłeś, czytając ten artykuł, jest wystarczająca, by zmienić Software House. Nie potrzebujesz dodatkowych informacji.
Problemami, jeśli się pojawią, zajmiemy się. Bez obaw. Możesz zawsze do nas zadzwonić, spytać o niezrozumiałą dla Ciebie kwestię. Mając wsparcie techniczne (w osobach naszych programistów) oraz organizacyjne (w osobach naszych project managerów) nie będziesz musiał się o nic martwić.
Zakończysz współpracę. Podejmiesz nową. Twoja firma odzyska kontrolę nad projektem. Zobaczysz, że można podchodzić do pracy w zupełnie inny sposób. Jaki? O tym porozmawiajmy w wygodny dla Ciebie sposób. Napisz e mail. Zadzwoń. Na pewno Ci pomożemy!
