Zero nieudanych projektów od 2007 r. — reguły inżynierskie, na których opiera się ten bilans
Założyłem Software Tailor w 2006 r. Dziewiętnaście lat później spółka dostarczyła rozwiązania przez cztery odrębne cykle gospodarcze, sześciu klientom z listy Fortune Global 500 z branż farmaceutycznej, finansowej, rządowej, prawniczej, obronnej i energetycznej, z bilansem zero nieudanych projektów od 2007 r. Ta ostatnia liczba to ta, o którą najczęściej pytają inwestorzy i recenzenci zakupowi, i jedyna, która wymaga wyjaśnienia. Oto cztery reguły inżynierskie, na których opiera się ten bilans.
Reguła 1: jeden model dostarczania, bez rozmywania granicy usługa–produkt
Każdy projekt Software Tailor działa według tego samego modelu dostarczania — ściśle zakreślonej fazy pilotażowej, w której dostarczamy działające oprogramowanie, a następnie rozwinięcia, które klient finansuje (lub nie) na podstawie tego, co zostało dostarczone. Nie prowadzę odrębnej praktyki „usługowej”, dostarczającej w oparciu o dokumenty wymagań, ani odrębnej praktyki „produktowej”, dostarczającej w oparciu o roadmapy. Te dwie weszłyby ze sobą w konflikt; jedna zawsze subsydiowałaby drugą.
Jeden model oznacza, że każdy inżynier wie, jak wygląda „skończone”, zanim zacznie. To warunek wstępny braku porażek.
Reguła 2: dyscyplina doboru klientów — tylko klienci, dla których jesteśmy w stanie dostarczyć
Naszą grupę klientów dobieram — nie kieruję się oportunizmem. Sześciu klientów z listy Fortune Global 500 w 19 lat to nie powolny pipeline sprzedażowy; to zamierzony próg doboru. Każdy klient, którego przyjmujemy, musi przejść trzy testy przed kickoffem: jego problem jest taki, jaki już rozwiązywaliśmy, jego wewnętrzny sponsor jest osobą, która będzie korzystać z oprogramowania (a nie warstwą pośredników), a jego środowisko sprzętowo-danych pozwala nam dostarczać bez sześciomiesięcznej dygresji zakupowej.
Klient, który nie przejdzie któregokolwiek z tych testów, staje się skierowaniem do kogoś innego, a nie projektem. Jest to reguła, która najczęściej kosztuje nas przychód. Jest też tą, w której nie było wyjątku przez 19 lat.
Reguła 3: dyscyplina inżynierska zmapowana na uznane ramy
Na długo zanim zarządzanie ryzykiem AI miało własne ramy, reguły inżynierskie, które skodyfikowałem dla Software Tailor, pasowały do tego samego kształtu: kieruj pracą, mapuj ryzyka, mierz wyniki, zarządzaj zmianami. NIST AI RMF 1.0 [1] sformalizował ten wzorzec dla AI w 2023 r., a kwietniowy 2026 r. profil dla infrastruktury krytycznej [1] rozszerzył go na branże regulowane. Czytając te dokumenty, widzę, że nasza wewnętrzna dyscyplina mapuje się klarownie na te cztery funkcje.
Co to daje: każdy projekt jest audytowalny od początku do końca względem zewnętrznych ram, a nie tylko względem naszych własnych nawyków. Gdy zespół zakupowy pyta, jak decyduje się zakres fazy pilotażowej, odpowiedź jest tą samą odpowiedzią, jaką NIST udzieliłby w sprawie zarządzania ryzykiem — a zespół ds. zgodności klienta zinternalizował już ten słownik.
Reguła 4: zapisywalne, odzyskiwalne, odtwarzalne
Czwarta reguła wyprzedza słownik ścieżki audytu, którego używamy dziś dla AI Suite. Każdy projekt Software Tailor działa w stanie, w którym każdą decyzję, każdy artefakt, każdą wersję kodu można odtworzyć z wejść w systemie kontroli wersji. Nie jest to nic niezwykłego dla inżynierii oprogramowania w ogóle; nietypowe jest to, że stosujemy to do projektu, a nie tylko do bazy kodu. Decyzje sprintu, zmiany zakresu, akceptacje klienta — wszystko zapisywane, wszystko odzyskiwalne.
Ta dyscyplina jest powodem, dla którego nasze podejście do logów audytowych bez treści dla AI Suite powstało tak, jak powstało. Wzorzec wiersza audytu jest tym samym wzorcem, który już stosujemy do projektów. Słownik jest zapożyczony z ram zgodności; praktyka jest zapożyczona ze sposobu, w jaki dostarczamy.
Co przeniosło się do AI Suite
Linia Local AI Suite + AI Admin Console — zobacz Dlaczego dostarczamy AI w postaci instalowalnych plików binarnych, a nie chmurowego SaaS — to ta sama dyscyplina inżynierska zastosowana do linii produktów zamiast do zlecenia na zamówienie. Ten sam pojedynczy model dostarczania (instalatory desktopowe, które klient uruchamia we własnym środowisku), ta sama dyscyplina doboru kohorty klientów (branże regulowane z jasnymi ograniczeniami rezydencji danych), to samo mapowanie na ramy (obowiązki podmiotu stosującego z NIST AI RMF + EU AI Act), ta sama postura audytu zapisywalny-odzyskiwalny-odtwarzalny.
Zero nieudanych projektów od 2007 r. to nie slogan. To rezultat niewielkiej liczby reguł stosowanych bez wyjątku. Te same reguły regulują obecnie sposób, w jaki budowany jest AI Suite.
Źródła
- NIST. „AI Risk Management Framework (AI RMF 1.0).” nist.gov/itl/ai-risk-management-framework. Dostęp: 2026-07-15.
Powiązane artykuły
Sprawdź tę samą dyscyplinę na rzeczywistym obciążeniu.
Platforma AI on-premises jest zbudowana na tych samych regułach, które dały ten bilans — zapisywalna, odzyskiwalna, odtwarzalna, stosowana bez wyjątku. Wdróż ją na rzeczywistym obciążeniu we własnym środowisku i utrzymaj wobec niej ten sam standard.