Zarządzanie · 3 min czytania
Ten o trójkącie projektu w erze AI
Zakres, czas, jakość i koszt: ten model projektu ma kilka dekad. Czy AI naprawdę go nie zmienia, czy zmienia coś, czego jeszcze nie umiemy zmierzyć?
W erze AI niektóre rzeczy pozostają niezmienione. Ale czy na pewno?
Na czym polega model czterech czynników?
Zakres, czas, jakość i koszt są ze sobą powiązane: zmień jeden, a pozostałe odpowiedzą. Ten model ma już kilka dekad. Tak działały projekty w 1990 roku i tak powinny działać dziś.
Chcesz więcej funkcji w tym samym terminie? Zapłacisz większym zespołem albo niższą jakością. Chcesz skończyć szybciej przy tym samym budżecie? Musisz oddać część zakresu. Nie ma ruchu, który poprawia wszystkie cztery naraz. Dlatego dobre zespoły świadomie wybierają, co trzymają na sztywno, a co zostawiają ruchome. Na przykład przy stałej cenie zamknięte są koszt, termin i jakość, a ruchomy zostaje tylko zakres.
Co AI zmienia w tym modelu?
Na pierwszy rzut oka AI przesuwa dwa czynniki naraz. Kod powstaje szybciej i taniej. Funkcję, która kiedyś zajmowała tydzień, da się mieć w szkicu w jedno popołudnie.
Gdyby model działał tak jak dotąd, coś musiałoby za to zapłacić. A jednak nikt nie zgłasza, że płaci. Zespoły raportują, że robią więcej w tym samym czasie, a koszty nie rosną.
Ale zaczynam się zastanawiać, czy AI faktycznie nic w tym modelu nie zmienia, czy zmienia, ale coś, czego jeszcze nie umiemy zmierzyć.
Który czynnik może płacić po cichu?
Najczęściej jakość, bo jest najtrudniejsza do zmierzenia w krótkim terminie. Zakres widać w backlogu, czas w kalendarzu, koszt w budżecie. Jakość widać dopiero po miesiącach: w liczbie incydentów, w tempie, w jakim rośnie złożoność, w tym, ile trwa wprowadzenie nowej osoby do kodu.
Są pierwsze sygnały, że coś się tu dzieje. Raport DORA z 2024 roku pokazał, że wraz z większym wykorzystaniem AI w zespołach spada stabilność dostarczania. Analizy repozytoriów wskazują, że rośnie udział kodu, który jest zmieniany lub usuwany wkrótce po napisaniu, a maleje udział kodu przenoszonego i porządkowanego.
Drugi kandydat to zakres. Skoro dodanie funkcji jest tanie, łatwo dodać ich więcej, niż ktokolwiek potrzebuje. Każda z nich to jednak kod do utrzymania, testowania i rozumienia przez kolejne lata. Szybciej powstający wynik nie oznacza jeszcze lepszego rezultatu u użytkownika.
Jak sprawdzić, co odpuszcza w Twoim projekcie?
Patrzeć dłużej niż jeden sprint. Jeśli tempo dostarczania rośnie, a liczba poprawek, incydentów i pracy nad długiem technicznym rośnie razem z nim, model wciąż działa, tylko rachunek przychodzi później.
Warto też zapytać zespół wprost, czy rozumie kod, który oddaje. Kod, którego nikt nie rozumie, jest kosztem odłożonym w czasie.
Jak to wygląda u Was? Który z tych czterech czynników odpuszcza pierwszy, odkąd AI weszła do projektu?
Bibliografia
- Barnes, M. (1969). Time, Cost and Quality. Koncepcja „żelaznego trójkąta” projektu.
- Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK Guide).
- DORA (2024). Accelerate State of DevOps Report 2024. Google Cloud.
- GitClear (2024). Coding on Copilot: 2023 Data Suggests Downward Pressure on Code Quality.
💬 Dołącz do dyskusji na LinkedIn → Komentuj i podziel się swoim podejściem
Tomasz Żelezny
Scrum Master · Agile Coach
Pomagam zespołom robić mniej rzeczy naraz i kończyć więcej. Piszę o przepływie pracy, decyzjach i o tym, gdzie znika wysiłek zespołów.
Twój zespół może więcej niż dowozi.
Zobacz, jak pomagam