Od pomysłudo cyfrowegoekosystemu

01. Jeden odpowiedzialny partner

Gdy różne elementy środowiska technicznego prowadzą różni dostawcy, klient często sam koordynuje ludzi, problemy i odpowiedzialność.

Strona, CRM, serwer, poczta i integracje wpływają na siebie w codziennej pracy.

Przejmujemy koordynację techniczną i odpowiedzialność za wynik — z jednym punktem kontaktu.

• Jedno miejsce odpowiedzialności
• Szybsze ustalanie przyczyn
• Mniej czasu na koordynację

Koordynacja techniczna pozostaje po naszej stronie.

02. Potrzeba przed kodem

Najdroższy system niekoniecznie lepiej rozwiązuje zadanie.

Różnica między dużym wdrożeniem a właściwym rozwiązaniem często wychodzi dopiero po rozmowie z osobą, która będzie podejmować decyzje na podstawie produktu.

Doprecyzowujemy potrzebę. Architekturę projektujemy, gdy jest już jasna.

• Potrzeba kształtuje architekturę
• Minimalnie zbędnych czynności dla zespołu
• Skala rozwiązania wynika z zadania

Doprecyzowujemy zadanie, zanim zbudujemy rozwiązanie.

03. Infrastruktura jako część produktu

Gotowy interfejs to jeszcze nie gotowy produkt.

Częsta sytuacja: development jest skończony, interfejs działa, firma jest gotowa do startu — i dopiero wtedy wychodzi, że środowisko nigdy nie zostało zaprojektowane.

Gdzie aplikacja działa, jak się ją wdraża, jak robi się kopie zapasowe, jak monitoruje, kto ma dostęp i jak odtwarza się usługę — to należy do tego samego projektu co sama aplikacja.

• Środowisko uruchomieniowe od początku
• Kopie zapasowe i monitoring nie są dodatkiem po premierze
• Mniej niespodzianek w pierwszym miesiącu

Produkt jest gotowy, gdy gotowe jest też środowisko, w którym ma działać.

04. Po wdrożeniu

Po wdrożeniu wymagania stają się jaśniejsze niż w testach.

Przed startem produkt przeglądają programiści i kilka osób z zespołu. Gdy ludzie zaczynają z niego korzystać codziennie, pojawiają się potrzeby, których testy nie ujawnią w całości.

Widać, które czynności użytkownicy omijają, jakich danych potrzebują liderzy i które funkcje okazały się nieużywane.

Wsparcie zachowuje kontekst projektu i pozwala rozwijać produkt bez szukania nowego wykonawcy przy każdej zmianie.

• Kontekst projektu pozostaje po premierze
• Zmiany bez poszukiwania nowego wykonawcy
• Rozwój trwa razem z firmą

Uruchomienie otwiera etap codziennej eksploatacji.

05. Ocena biznesowa

Nie proponujemy dużego systemu tylko dlatego, że taki system istnieje.

Ustalamy, które czynności ludzie naprawdę potrzebują codziennie — i dopiero wtedy wybieramy skalę rozwiązania.

Funkcja zasługuje na miejsce, gdy ludzie z niej korzystają w pracy. Dopracowana prezentacja sama w sobie nie czyni jej użyteczną.

• Narzędzie wynika z potrzeby
• Korzyść oceniana przed wdrożeniem
• Szczera rada: robić / poczekać / nie robić

Dobra inżynieria czasem oznacza robić mniej — precyzyjniej.

06. Zaprojektowane na wzrost

Staramy się nie budować rozwiązania, które jutro trzeba będzie wyrzucić.

Na starcie często wystarcza prostsze rozwiązanie. Gdy firma rośnie, zmieniają się role, więcej osób potrzebuje dostępu, a raportowanie i automatyzacja się rozrastają.

Dobra architektura nie próbuje odgadnąć całej przyszłości firmy. Jej zadaniem jest zostawić miejsce na nowe procesy, role i integracje — bez przebudowy tego, co już działa.

Gdy architektura uwzględnia wzrost, nowe możliwości można dodawać stopniowo, bez kosztownej wymiany całego układu.

• Miejsce na wzrost zespołu i rynku
• Nowe procesy bez pełnej wymiany
• Rozszerzalne integracje i role

Środowisko cyfrowe powinno wytrzymać rozwój firmy.