Podczas negocjacji cen projektów oprogramowania dostosowanego, strony A i B najczęściej uzgadniają jednostki w następujący sposób:„Człowiek i niebo“: Ile inżynierów, ile dni pracy, jaka stawka za dzień. Ten model działa tylko w sytuacji, gdy wymagania są stabilne i granice dostawy są jasno określone; gdy jednak zasady na miejscu często się zmieniają, narzędzia AI znacznie podnoszą wydajność kodowania, a klient nadal dokonuje odbioru „na zasadzie nakładania ludzi”, konflikt nieuchronnie wybuchnie — strona druga uważa, że wymagania się rozrastają, a strona pierwsza twierdzi, że „ludzi nie przybyło, a produktu też nie ma więcej”.
Sygnał polityczny: od sprzedaży głowów do sprzedaży wyników
We wrześniu 2026 roku Ministerstwo Przemysłu i Technologii Informacyjnej opublikowało „Plan wdrożenia specjalnej akcji +sztuczna inteligencja oprogramowanie”, w którym wielokrotnie wspomniano o przekształceniu modeli produkcji oprogramowania oraz rozwoju usług „model jako usługa” i „inteligentny agent jako usługa”, przy czym wyraźnie zaznaczono, że do 2028 roku w kluczowych branżach zostaną stworzone wzorcowe aplikacje oprogramowania opartego na inteligentnych agentach. Dokument nie odrzuca personalizowanego programowania, ale jasno wskazuje kierunek:Oceniając wartość oprogramowania, coraz częściej kieruje się efektywnością, a nie tylko liczbą zainwestowanych dni pracy.。
Dla przedsiębiorstw, które wdrażają systemy ERP, MES, CRM oraz systemy zarządzania branżowego, oznacza to, że jeśli w umowie nadal będzie zapisane jedynie „XX osób × XX dni”, po uruchomieniu systemu łatwo wpadnie się w spór: „kod został napisany, ale biznes nie potrafi go wykorzystać”. O wiele bardziej zrównoważonym sposobem jest podział dostawy naOdbieralne wyniki biznesowe。
Logika biznesowa: kroki milowe są bardziej szczegółowe niż dni pracy.
Przekształć projekt z „płatności etapowych” na „płatności krokowe”; każdy krok musi jednocześnie spełniać cztery warunki:
- Scenariusz biznesowy: Kto to używa i jakie operacje rozwiązuje (na przykład „magazynier skanuje kod QR przy przyjęciu towaru” zamiast „zakończono moduł przyjęcia towaru”).
- Zakres danych: Jakie dane główne, pola stanu i zakres uprawnień są objęte, oraz jakie są zasady próbkowania.
- Skrypt odbiorczy: Na podstawie podanych danych testowych, które procesy zostaną przeprowadzone oraz jakie dokumenty lub raporty zostaną wygenerowane.
- Obsługa wyjątków: Jak system informuje w przypadku awarii, kto ma prawo do modyfikacji i czy zostają zapisane ślady.
Kamień milowy nie powinien przekraczać2–4 tygodnieJeden; zbyt długi i zostanie odesłany do „czarnego pudełka” w rozwoju. Typowy przykład podziału: dane główne i uprawnienia → zamknięty cykl podstawowych dokumentów → raporty i rozliczenia → interfejsy oraz przejście na nową platformę.
Logika projektowa: zakres, zmiany i „inteligentne wsparcie” zostały wpisane do umowy
AI wspomagane kodowanie, automatyczne generowanie przypadków testowych oraz inteligentne uzupełnianie dokumentacji zmienią zużycie czasu pracy na wykonanie tej samej funkcji, aleNie zmienia automatycznie złożoności biznesowej. W umowie i specyfikacji wymagań zaleca się wydzielone wyróżnienie:
- Linia bazowa (Baseline): Lista funkcji + lista zadań poza zakresem (Out of Scope), zmiany muszą być wprowadzane na podstawie formularza zmian.
- Zmiana zasad naliczania cen: Nowe kroki milowe są wyceniane według „scenariusza + skryptu akceptacji”, a nie na podstawie dodatkowych dni pracy.
- Inteligentne wsparcie graniczne: Które etapy mogą być usprawnione za pomocą AI (generowanie kodu, szkic dokumentów), a które muszą zostać podpisane ręcznie (bezpieczeństwo, zgodność z przepisami, zobowiązania wobec stron zewnętrznych).
- Przypisanie osadzonej wiedzy: Kto posiada dokumentację procesową, konfiguracje i skrypty, aby uniknąć przestojów w obsługiwaniu po przekazaniu?
Rozwój i wdrożenie: automatyzacja i obserwowalność procesów验收
Aby „orientacja na wynik” była realizowalna, strona techniczna musi współpracować w trzech kwestiach:
- Wprowadzenie przypadków testowych do magazynu: Każdy szczytowy punkt odpowiada grupie testów automatycznych lub półautomatycznych, które można powtarzać w ramach regresji.
- Ochrona środowiska i izolacja danych: Dane w środowisku UAT mogą być zresetowane, aby uniknąć sytuacji, gdy „przepuszczalność występuje wyłącznie w środowisku demonstracyjnym”.
- Obserwowalny dziennik logów: Kluczowe operacje są rejestrowane w dzienniku audytu, co pozwala w przypadku sporów na prześledzenie, kto i co zmienił.
Jeśli projekt zawiera agenta lub silnik reguł, weryfikacja powinna zostać rozszerzona oMechanizm kontroli w czasie rzeczywistym: Przypadkowo wprowadzane przypadki graniczne, aby sprawdzić, czy odrzucenie odpowiedzi, eskalacja do obsługi manualnej oraz blokada uprawnień są zgodne z projektem, a nie tylko patrzeć na „możliwość czatowania”.
Trzy typy najczęstszych sporów i ich zapobieganie
Spór pierwszy: „Wszystkie funkcje zostały zaimplementowane, dlaczego zatem pracownicy nie korzystają z systemu?”— Profilaktyka: przypisanie milestone’ów do stanowisk operacyjnych i zapisywanie się na szkolenia; podczas odbioru przeprowadzanie inspekcji na miejscu, a nie tylko prezentacja w formacie PPT.
Spór drugi: „Dlaczego trzeba dopłacić za dodanie małej wymagania?”— Zapobieganie: w formularzu zmiany należy wyraźnie zaznaczyć wpływy na kroki realizacyjne, skrypty i terminy prac; dopiero po podpisaniu przez obie strony można przystąpić do rozwoju.
Spór trzeci: „AI zwiększyło efektywność, czy można zredukować liczbę ludzi?”— Zapobieganie: kontrakty odróżniają „koszty realizacji” od „stopnia złożoności biznesowej”; korzyści z podniesienia efektywności mogą być widoczne w całkowitej cenie lub czasie realizacji, jednak standardy odbioru nie są obniżane.
Rekomendacja pilotażowa: zacznij od jednego modułu zamkniętego cyklu
Nie musisz czekać na całkowite przepisanie kontraktu w systemie. Wybierz jeden.2–3 tygodnie umożliwiają zamknięty cyklmodułów (takich jak przyjęcie i wydanie towarów, zgłaszanie pracy w formularzu zleceń, aprobowanie kosztów), stosuje się nowy szablon do podpisywania aneksów: wymienia się scenariusze, skrypty, wyjątki oraz węzły płatności. Po sprawdzeniu poprawności działania rozszerza się tę praktykę na cały projekt. Ocenia się sukces, patrząc naCzy formularz zmiany skraca czas spierania się?、Czy wskaźnik sukcesu pierwszego przejścia UAT wzrósł?, a nie na to, ile dni pracy zaniżyła strona B. Dobrze wybrane moduły pilotażowe sprawią, że zmiana umowy na całość projektu będzie bardziej przekonująca.
Ludzie i czas nie znikną w jednej nocy, ale zmieniają się z „jedynego podmiotu ustalającego cenę” na „referencję do szacowania kosztów”. Wpisanie punktów przełomowych i skryptów odbiorczych do umowy to podstawowa umiejętność, dzięki której oprogramowanie dostosowane do potrzeb nadal może dostarczać wiarygodne rezultaty w kontekście „sztuczna inteligencja + oprogramowanie”.
Z współpracą przy stałej cenie całkowitej i zwinnej iteracji
Odbiór krok po kroku nie wyklucza agilności: każdy Sprint nadal może dostarczyć demonstracyjny przyrost, alePłatność i formalne przyjęcieZawieszono na większym kamieniu milowym. W kontrakcie o stałej cenie szczególnie należy wyraźnie zaznaczyć „punkt zamrożenia zakresu” – po którym przeglądzie nowe wymagania podlegają procedurze zmiany, aby uniknąć dodawania funkcji w sposób ustny. W przypadku modułów zawierających agentów inteligentnych zaleca się przeprowadzenie oddzielnego przyjęcia na kamieniu milowym pod kątem „wersji reguł + procentu przejścia kontroli próbkowej”, bez łączenia ich z uruchomieniem całego systemu w ramach jednego, uniwersalnego terminu.
Dane branżowe wskazują, że około % projektów oprogramowania kończy się niepowodzeniem.Jedna trzeciaPochodzi to z niejasności w zakresie wymagań i kryteriów odbioru, a nie z samej realizacji technicznej. Najpierw sprecyzować w umowie, co rozumie się pod pojęciem „coś uznano za zakończone”, co jest bardziej wartościowe niż spory o to, czy AI zastąpił kilku programistów. Podczas kolejnego przeglądu projektu warto zadać pytanie: gdyby jutro cała strona B miała urlop, czy potrafimy na podstawie skryptów ocenić, czy aktualny milestone został osiągnięty – jeśli nie da się odpowiedzieć, oznacza to, że kryteria odbioru nadal nie są wystarczająco jasno sformułowane. Wpisanie milestone’ów do umowy nie ma na celu utrudniania pracy stronie B, ale pozwala obu stronom dyskutować na tej samej płaszczyźnie o tym, czy rzecz została wykonana. W przypadku projektów, w których efektywność poprawiona przez AI są szczególnie wyraźne, należy jeszcze wcześniej jasno to ustalić.