AI powinno uczyć się, jak pracujesz
Projektując Snappy PM, pojawił się bardzo naturalny pomysł: skoro mamy AI, dlaczego nie pozwolić mu przeczytać historyczne projekty firmy i automatycznie wygenerować workflow szyty na miarę? Brzmi sensownie — i bardzo AI-native. Ale w miarę budowania zmieniliśmy zdanie: to, że coś wydarzyło się w przeszłości, nie znaczy, że powinno się tak dziać w przyszłości. AI pilnie uczące się historii może po prostu zautomatyzować wczoraj.
Kiedy po raz pierwszy projektowaliśmy Snappy PM, pojawił się bardzo naturalny pomysł:
Skoro mamy AI, dlaczego nie pozwolić AI przeczytać historyczne projekty firmy i automatycznie wygenerować Workflow, który należy do tej firmy?
Brzmi sensownie.
I bardzo AI-native.
Ale w miarę jak budowaliśmy dalej, zmieniliśmy zdanie.
Bo AI potrafi łatwo sprawić, że prosta rzecz wygląda na bardzo sprytną.
Patrzy na przeszłe projekty firmy i może z nich wydestylować wiele Stages, Rules, Roles i Exceptions.
Ale problem polega na tym:
To, że coś wydarzyło się w przeszłości, nie znaczy, że powinno się tak dziać w przyszłości.
Historyczne procesy firmy mogą już zawierać wiele przypadkowych, nieefektywnych, a nawet błędnych praktyk.
Jeśli AI bardzo pilnie nauczy się tej historii, końcowym rezultatem może być po prostu:
Automating yesterday.
Dlatego nowa wersja Snappy PM dokonała bardzo ważnego uproszczenia.
Nie pozwalamy już AI wymyślać State Machine dla każdej firmy.
Podstawowy szkielet projektu to pięć Phases:
Requirement Capturing
Scoping & Design
Implementation or Manufacturing
Deployment or Installation
Closing
Ta część pozostaje stabilna.
Tym, czego AI naprawdę powinno się uczyć, są znaczące różnice między firmami.
Na przykład:
Które Phases cię dotyczą?
Jakiego rodzaju Quotations zwykle używasz?
Jakie są twoje Payment Terms?
Które Documents są twoimi własnymi standardowymi szablonami?
Czy masz Inventory?
Czy klient ma do czynienia z tą firmą, czy z inną Sales Company w grupie?
To jest:
How you work.
Więc Snappy może przeczytać przeszły projekt, zrozumieć przyzwyczajenia i dokumenty firmy, i zaproponować sugestie.
Ale daliśmy mu jeszcze jedną zasadę:
Evidence or default.
Jeśli AI uważa, że firma pracuje w określony sposób, powinno umieć nam powiedzieć:
w jakich prawdziwych dokumentach to zobaczyłem.
Jeśli nie ma dowodów, używane są proste, stabilne ustawienia domyślne platformy — zamiast pozwalać AI zgadywać.
Coraz bardziej czuję, że to bardzo ważna granica w projektowaniu produktów AI.
Najcenniejsze w AI niekoniecznie jest:
pozwalanie AI decydować o wszystkim.
Chodzi o wiedzę:
co powinno pozostać stabilne, a co może być uczone.
Accounting rules powinny pozostać stabilne.
Główny Project Flow powinien pozostać stabilny.
Granice uprawnień powinny pozostać stabilne.
Podczas gdy dokumenty, przyzwyczajenia, szablony i konkretne sposoby pracy firmy mogą być uczone.
Dlatego teraz wolimy opisywać Snappy PM tak:
AI learns how you work.
It doesn't invent how you should work.
AI powinno obniżać koszt dostosowania się firmy do oprogramowania.
A nie tworzyć nową warstwę złożoności, a potem wymagać, by firma dostosowała się do AI.
SnapLedger, your life easier.
Ważna granica w projektowaniu produktów AI: wiedzieć, co powinno pozostać stabilne, a co może być uczone. Zasady księgowe, główny przepływ projektu i granice uprawnień powinny pozostać stabilne; dokumenty, przyzwyczajenia, szablony i konkretne sposoby pracy firmy mogą być uczone. A gdy AI twierdzi, że firma pracuje w określony sposób, powinno umieć pokazać, w jakich prawdziwych dokumentach to zobaczyło — evidence or default.
Gdyby AI uczyło się sposobu pracy twojej firmy wyłącznie z waszych przeszłych projektów, które nawyki wiernie by odtworzyło — a które zawstydziłyby cię, gdyby zostały zautomatyzowane?
AI uczy się, jak pracujesz. Nie wymyśla, jak powinieneś pracować.
Otrzymuj Founder Diary + aktualizacje regulacyjne dla Twojego kraju
E-mail, gdy Richard opublikuje nowy wpis, oraz zmiany w przepisach ważne tam, gdzie mieszkasz. Bezpłatnie, z możliwością rezygnacji w każdej chwili.