01. Problem zaczyna się od złego pytania
Wiele projektów technicznych zaczyna się od gotowego rozwiązania. Ktoś potrzebuje raportu. Ktoś chce aplikację. Ktoś proponuje wykorzystanie AI. Na pierwszy rzut oka wygląda to jak dobrze określona potrzeba.
Z perspektywy projektu to jednak często nie jest jeszcze problem. To jest pierwsza propozycja rozwiązania. Nie wiemy jeszcze, co naprawdę nie działa, kto odczuwa skutki, jak często sytuacja się powtarza i jakie decyzje są przez nią opóźniane.
02. Zatrzymać się przed implementacją
Na początku projektu bardzo łatwo uwierzyć, że kierunek został już wybrany. Skoro potrzebny jest raport, trzeba zrobić raport. Skoro ktoś mówi o aplikacji, trzeba zaprojektować ekran. Skoro pojawia się AI, trzeba szukać modelu.
W praktyce najważniejszy jest moment zatrzymania. Zanim powstanie architektura, trzeba zrozumieć proces. Co dzieje się krok po kroku? Gdzie powstaje informacja? Kiedy podejmowana jest decyzja? Co zajmuje najwięcej czasu? Gdzie najczęściej pojawiają się błędy?
03. Problem operacyjny to nie zawsze problem techniczny
W wielu projektach technologia staje się pierwszym podejrzanym. Brakuje systemu, modułu, integracji albo automatyzacji. Tymczasem bardzo często źródłem trudności nie jest brak narzędzia, lecz sposób, w jaki przebiega proces.
Problem może wynikać z powielania danych, braku właściciela informacji, niejasnej kolejności działań albo decyzji podejmowanych zbyt późno. Technologia pojawia się dopiero wtedy, gdy wiemy, co naprawdę wymaga zmiany.
04. Czego nie robimy
Nie zaczynamy projektu od wyboru technologii. Nie proponujemy automatyzacji tylko dlatego, że jest możliwa. Nie zakładamy, że pierwsza zgłoszona potrzeba jest rzeczywistym problemem. Nie budujemy funkcji tylko dlatego, że można je zbudować.
Każda z tych decyzji może przyspieszyć początek projektu. Każda może również znacząco wydłużyć jego rozwój, jeśli okaże się, że rozwiązanie powstało dla niewłaściwie zdefiniowanego problemu.
05. Od obserwacji do architektury
Architektura rozwiązania powinna wynikać z procesu, a nie z listy technologii. Najpierw trzeba zobaczyć, jak wygląda rzeczywista praca. Dopiero później można zdecydować, które dane są potrzebne, gdzie powinny być przechowywane i co warto zautomatyzować.
Obserwacja procesu
│
▼
Rozmowa z użytkownikami
│
▼
Identyfikacja problemu
│
▼
Analiza przyczyn
│
▼
Projekt architektury
│
▼
Implementacja
│
▼
Pomiar efektu Dzięki temu implementacja staje się konsekwencją wcześniejszych decyzji, a nie ich początkiem.
06. Efekt: mniej funkcji, więcej sensu
Dobrze zdefiniowany problem bardzo często prowadzi do prostszego rozwiązania. Nie dlatego, że projekt jest mniej ambitny, ale dlatego, że nie trzeba budować elementów, które nie rozwiązują rzeczywistego problemu.
07. Co można przenieść do innych branż?
Ten sposób pracy nie zależy od branży. Tak samo można analizować produkcję, logistykę, utrzymanie ruchu, administrację, kontrolę jakości czy raportowanie zarządcze.
W każdym przypadku początek jest taki sam. Najpierw trzeba zrozumieć proces. Dopiero później warto projektować system. Im wcześniej zostanie właściwie zdefiniowany problem, tym mniej zmian będzie potrzebnych podczas implementacji.
Perspektywa LOOKAS
Technologia odpowiada na pytania. Rolą inżyniera jest najpierw zadać właściwe.