Utrzymanie i rozwój systemu
To jest pytanie, które blokuje najwięcej decyzji, i zadajesz je słusznie. Ten rozdział odpowiada, co dokładnie zostaje u Ciebie po projekcie, kto to rozwija i co się stanie, jeśli przestaniemy pracować razem.
Przejechaliśmy się już na dedykowanym oprogramowaniu
Znam to zdanie i słyszę je na co drugim spotkaniu. Firma zamówiła system szyty na miarę, dostała go z opóźnieniem, a potem został z nią kod, który rozumiał jeden zespół u dostawcy.
Dokumentacji nie było albo rozjechała się z rzeczywistością po pierwszym kwartale. Każda zmiana kosztowała tyle, co nowy moduł. Zmiana dostawcy nie wchodziła w grę, bo nikt inny nie chciał tego dotknąć.
Jeśli tak wyglądało Twoje ostatnie doświadczenie, masz pełne prawo pytać, czym to się różni. Reszta tego rozdziału jest odpowiedzią.
Jak powstaje kolejny moduł
Nic z tego nie stoi u mnie i nic z tego nie wymaga mojej zgody, żeby z tego korzystać.
Praca zaczyna się od zapisu, nie od kodu. Opisujemy proces w modelu firmy: co się dzieje, w jakiej kolejności, kto co zatwierdza i co jest wyjątkiem. Dopiero z tego zapisu agenci budują moduł, a ja sprawdzam, czy to, co powstało, odpowiada zapisowi.
Konsekwencja jest praktyczna. Zmiana wymagania to zmiana akapitu w modelu i ponowne wygenerowanie tego, co z niego wynika. Nie jest to zgłoszenie, wycena i miejsce w kolejce u dostawcy.
Ta sama metoda pozwala robić rzeczy, których wcześniej nie opłacało się zamawiać. Proces obsługiwany przez jeden dział, rzadko i niewielkim nakładem, przestaje być za drobny, żeby mieć własny moduł.
Fabryka oprogramowania po Twojej stronie
Docelowo firma nie kupuje każdej zmiany na zewnątrz. Ma u siebie zestaw narzędzi i agentów, który z zapisu procesu potrafi zrobić działający moduł. W branży nazywa się to Dark Software Factory — fabryka oprogramowania, która pracuje bez człowieka nadzorującego każdy krok.
Nie jest to zespół programistów, którego trzeba zatrudnić. To narzędzia plus jedna rola: ktoś, kto rozumie proces i umie go opisać na tyle dokładnie, żeby powstał z tego moduł.
Tej roli można nauczyć kogoś, kogo już masz. To jest długi koniec tej drogi, a nie warunek pierwszego kroku.
Dlaczego Linux i otwarty stos pod modelami AI
Wybór stosu nie jest kwestią gustu, tylko rachunku na trzech pozycjach: ile kosztuje uruchamianie modeli, kto kontroluje to, co się z nimi dzieje, i czy ktoś inny może to po mnie przejąć.
Otwarty stos wypada dobrze na wszystkich trzech. Modele, biblioteki i narzędzia do pracy z nimi powstają na Linuksie i tam działają najtaniej. Nie ma opłaty za każdego użytkownika ani za każde wywołanie. A system stojący na otwartych komponentach może przejąć każdy zespół, nie tylko ten z odpowiednim certyfikatem partnerskim.
To nie znaczy, że jest jedynym wyborem. Jeśli Twoja firma stoi na Microsofcie, ta sama architektura daje się zbudować tam i ma inne zalety. O tym jest następny rozdział.
Aktywem jest specyfikacja, nie kod
W tamtym modelu trwałą rzeczą był kod, a wszystko poza nim było jego opisem. Tutaj jest odwrotnie. Zmiana idzie od modelu w dół, nie od kodu w górę.
- Trwałym artefaktem jest cyfrowy model firmy: procesy, obiekty, reguły i uprawnienia, spisane w formie, którą da się przeczytać.
- Kod powstaje z niego, jest udokumentowany i da się go wygenerować jeszcze raz.
- Zmiana wymagania to zmiana akapitu w modelu i ponowne wygenerowanie tego, co z niego wynika. Nie zgłoszenie, wycena i miejsce w kolejce u dostawcy.
- Proces obsługiwany rzadko i przez jeden dział przestaje być za drobny, żeby mieć własny moduł.
Twoim trwałym aktywem jest specyfikacja, nie kod.
Cztery rzeczy, wszystkie po Twojej stronie
Po projekcie masz w ręku cztery rzeczy. Nic z tego nie stoi u mnie i nic z tego nie wymaga mojej zgody, żeby z tego korzystać.
Cyfrowy model firmy
Procesy, obiekty, reguły i uprawnienia, w formie czytelnej dla człowieka. Możesz go przeczytać bez pomocy programisty.
Repozytorium
Kod i pełna historia zmian, na Twoim koncie i pod Twoją kontrolą.
Infrastruktura
Miejsce, w którym system stoi: u Ciebie, w Twojej chmurze albo w wybranym centrum danych.
Dokumentacja decyzji
Architektura i uzasadnienia: co wybraliśmy, dlaczego i co odrzuciliśmy.
W klasycznym modelu klient zostawał z kodem,
który rozumiał jeden zespół u dostawcy.
Tutaj zostaje zapis firmy, który czyta właściciel.Krzysztof Majchrzycki · AI Business Partner
Odpowiedź ma trzy części
To jest pytanie, które blokuje najwięcej decyzji, i zadajesz je słusznie.
- Ja projektuję i pilnuję, żeby powstało to, co zaprojektowane. Buduje podwykonawca, którego wybieramy wspólnie i który pracuje na Twoim repozytorium.
- To, co zostaje, można przeczytać. Nowy dostawca nie musi odgadywać intencji z kodu — dostaje zapis firmy i historię decyzji.
- Jeśli przestaniemy pracować razem, nie tracisz nic poza mną. Model, kod i infrastruktura stoją u Ciebie od pierwszego dnia, nie od momentu zakończenia współpracy.
Darmowy poradnik transformacji AI
dla Twojej Firmy
Sześć rozdziałów, pytania diagnostyczne, cyfrowy model firmy
i roadmapa proces po procesie.
Bez NDA i bez rozmowy sprzedażowej.
