AI uczyniła z szefa ds. realizacji założyciela firmy
Michael Gold przez 15 lat zajmował się zarządzaniem projektami, zanim AI dała mu możliwość, by w końcu stworzyć produkt programistyczny, którego zawsze chciał. Jego historia nie opowiada o tym, jak AI zamienia kierowników projektów w założycieli firm — chodzi w niej o usunięcie ostatniej wymówki tym, którzy już nimi byli.
Michael Gold
Dostęp do AI: AI dała nietechnicznemu założycielowi praktyczny sposób na prototypowanie oprogramowania, zmniejszając bariery bez zastępowania wiedzy technicznej.
Wiedza użytkownika: Bezpośrednie doświadczenie Michaela w zarządzaniu projektami wpłynęło na kształt Aria, uwzględniając praktyczne frustracje, przystępny projekt i ostrożne wykorzystanie AI.
Prototyp na weekend: Weekendowy prototyp potwierdził słuszność koncepcji, ale inżynierowie nadal byli niezbędni do zapewnienia bezpieczeństwa, architektury, rozliczeń i niezawodności.
Przewaga kierownika projektu: Kierownicy projektów już definiują pracę, zarządzają konkurującymi priorytetami i radzą sobie z niepewnością — są to umiejętności, które mogą wspierać przedsiębiorczość.
Zmiana na rynku: AI pozwala dziś praktykom przekształcać nagromadzone frustracje związane z oprogramowaniem w przetestowane produkty, zamiast czekać na plany rozwoju dostawców.
Kiedy Michael Gold miał 15 lat, prowadził własną firmę eventową, organizując wydarzenia dla 500 osób. Jego ojciec przez całe życie prowadził własną działalność. Przedsiębiorczość nie była w jego rodzinie tyle aspiracją, co czymś oczywistym.
A potem, gdzieś po drodze, z niej zrezygnował.
„Kiedy dorastałem, w pewnym sensie przestraszyłem się przedsiębiorczości” — powiedział mi. Zamiast tego zbudował karierę w zarządzaniu projektami: pracował w tej dziedzinie przez niemal 15 lat, zaczynając w branżach kreatywnych, a następnie przechodząc do sektora technologicznego. Około dwóch lat temu zaczął pracować jako niezależny konsultant, zakładając własną agencję zarządzania projektami i pełniąc funkcję zewnętrznego dyrektora realizacji projektów dla startupów oraz klientów korporacyjnych. Pod każdym względem była to udana ścieżka. Jednak przedsiębiorcza potrzeba nigdy całkowicie nie zniknęła. Po prostu uśpiła się.
Continue Reading for Free
Create a free account to finish this article, plus get ongoing access to timely insights and practical resources.
Have an account? Log In
Dorosłem i przestraszyłem się przedsiębiorczości.
W tym miesiącu, ponad dwie dekady po tamtych pierwszych wydarzeniach, Michael uruchomił produkt programistyczny Aria — narzędzie do automatyzacji usług profesjonalnych (PSA). Buduje je z niewielkim zespołem założycielskim, w którego skład wchodzi również jego żona Rachael, ilustratorka.
W ciągu ostatnich kilku miesięcy dwukrotnie przeprowadzałem wywiad z Michaelem i w obu rozmowach wciąż powracało to samo pytanie: co się zmieniło? Nie jest przecież programistą. Nigdy nim nie został. Zmieniło się to, że dzięki AI brak umiejętności programistycznych stał się mniejszym problemem niż wcześniej.
Zaczęło się od irytacji, nie od ambicji
Droga Michaela do tworzenia oprogramowania nie zaczęła się od biznesplanu. Zaczęła się od małych, znajomych frustracji.
Rachael stworzyła stronę jego agencji w Wixie, a każda zmiana musiała przechodzić przez nią. „Naprawdę nie znosiłem tego, że muszę polegać na niej we wszystkim” — powiedział. Podłączył więc stronę do narzędzia AI do programowania. „W ciągu godziny miałem tę samą stronę, ale teraz mogłem sam nią zarządzać”. Następnie, korzystając z programowania opartego na opisie efektu, stworzył własny system CRM, aby zastąpić subskrypcję za 100 dolarów miesięcznie, która wydawała mu się absurdem w przypadku jednoosobowej działalności. Nie była lepsza od prawdziwego rozwiązania — sam ci to powie — ale robiła to, czego potrzebował, a co najważniejsze: „tworzenie jej sprawiało mi naprawdę dużo frajdy”.
To doświadczenie nasunęło mu pytanie, którego wcześniej nigdy nie miał możliwości zadać:
„Narzędzie takie jak HubSpot musi mieć każdą możliwą funkcję, aby obsłużyć każdego możliwego klienta. Dlatego kosztuje tyle, ile kosztuje — ponieważ jest niesamowitym narzędziem. Ale jeśli potrzebujesz tylko 0,5% tego narzędzia, pojawia się pytanie: dlaczego płacę za pozostałe 99,5%?”
[HubSpot] kosztuje tyle, ile kosztuje, ponieważ jest niesamowitym narzędziem. Ale jeśli potrzebujesz tylko 0,5% tego narzędzia, pojawia się pytanie: dlaczego płacę za pozostałe 99,5%?
Każdy mały projekt sprawiał, że kolejny stawał się możliwy do wyobrażenia. Nie był to ktoś, kto postanowił zostać założycielem firmy tworzącej oprogramowanie. To był menedżer projektów rozwiązujący własne problemy i przy okazji po cichu odbudowujący utraconą pewność siebie.
Już wcześniej doświadczył problemu, który teraz rozwiązuje
Historycznie rzecz biorąc, problem z oprogramowaniem wyglądał tak: ludzie, którzy je tworzyli, i ludzie, którzy z jego powodu cierpieli, rzadko byli tymi samymi osobami. Stworzenie produktu wymagało programistów, projektantów UX i menedżerów produktu. Rola użytkownika końcowego sprowadzała się do zgłoszenia prośby o nową funkcję i nadziei na najlepsze. Odległość między osobą odczuwającą problem a osobą dostarczającą rozwiązanie wyznaczały zgłoszenie do działu wsparcia, portal próśb o nowe funkcje, opiekun klienta i cudzy plan rozwoju produktu.
Michael przez lata znajdował się po niewłaściwej stronie tej przepaści.
Osiem albo dziewięć lat temu dołączył do agencji, która tydzień przed jego rozpoczęciem pracy wdrożyła nową platformę PSA. Jego reakcja nie była umiarkowana. „Prawie odszedłem w okresie próbnym, bo uważałem, że to najgorsza rzecz na świecie. Tak bardzo tego nienawidziłem”.
Porozmawiał o tym z właścicielem. Chciał pozbyć się tego narzędzia. Wtedy wydarzyło się coś niezwykłego — trafił do planu testów beta produktu dostawcy. „Pomogłem im kształtować to narzędzie” — powiedział, a wraz z ulepszaniem produktu dzięki opiniom praktyków poprawiała się również jego relacja z nim. „Przeszedłem drogę od faceta, który prawie odszedł w okresie próbnym, do osoby, która ostatecznie zaczęła z niego korzystać, a następnie została jego wewnętrznym ambasadorem”.
To był stary model wpływu praktyków: mieć dość szczęścia, by trafić do programu beta, i kształtować z zewnątrz produkt należący do kogoś innego. Dodajmy do tego lata, które jego agencja spędziła na wdrażaniu u klientów narzędzi PSA, a okaże się, że Michael zna tę kategorię z każdego miejsca poza fotelem twórcy. Doskonale wie, gdzie te narzędzia zawodzą: przy nieporęcznym wdrażaniu i zimnych, pozbawionych radości interfejsach. „Nie sądzę, żeby którekolwiek narzędzia PSA były szczególnie atrakcyjne. Nie sądzę, żeby przebywanie w nich sprawiało przyjemność” — powiedział, dlatego Rachael jest częścią zespołu założycielskiego i dlatego „naprawdę chciał, aby Aria była ciepłym i przyjaznym miejscem”.
Nie sądzę, żeby którekolwiek narzędzia PSA były szczególnie atrakcyjne. Nie sądzę, żeby przebywanie w nich sprawiało szczególną przyjemność. Dlatego chciałem, aby Aria była ciepłym i przyjaznym miejscem.
Wie również, obserwując prawdziwe zespoły realizacyjne, a nie LinkedIn, że większość kierowników projektów wciąż nie korzysta ze sztucznej inteligencji — dlatego asystent Arii sygnalizuje problemy i pyta przed podjęciem działania, zamiast działać autonomicznie. „Agenci, niezależnie od tego, czy powinni nimi być, brzmią dla mnie groźnie” — powiedział. „Myślę, że łatwiej jest mieć przyjaznego asystenta, który po prostu stoi po twojej stronie”.
Żadna z tych obserwacji nie mogłaby powstać na podstawie wywiadów z użytkownikami przeprowadzonych przez zespół produktowy. To blizny po doświadczeniach. Michael nie zgaduje, co frustruje kierownika projektu w czwartek o 16:00. On sam nim był. Nowością nie jest to, że praktycy posiadają tę wiedzę. Nowością jest to, że wreszcie mogą bezpośrednio na jej podstawie działać.
Od prototypu do produktu
Dowód pojawił się w ciągu jednego weekendu. Kiedy jego współzałożyciel James rzucił pomysł, by sami zbudowali narzędzie PSA, Michael początkowo odmówił. To naprawdę złożone oprogramowanie, które przechowuje najbardziej wrażliwe dane operacyjne i finansowe firmy. „Nie ma mowy, żebym kodował narzędzie PSA za pomocą AI” — wspomina, że tak wtedy pomyślał.
Potem, nic nikomu nie mówiąc, usiadł przy klawiaturze. „Spędziłem 24 godziny na kodowaniu za pomocą AI. To bardzo uzależniające. I tak, dosłownie w ciągu jednego weekendu, miałem prototyp, który był narzędziem PSA robiącym wszystko, co powinno robić narzędzie PSA. A przynajmniej z pozoru tak to wyglądało”.
W ciągu jednego weekendu miałem prototyp, który był narzędziem PSA robiącym wszystko, co powinno robić narzędzie PSA. A przynajmniej z pozoru tak to wyglądało.
To ostatnie zdanie ma znaczenie, a Michael podkreśla to z naciskiem. Prototyp był początkiem pracy, a nie jej końcem. Minione miesiące obejmowały pracę programisty full-stack nad bezpieczeństwem, rozliczeniami i głębszą architekturą. Doświadczeni dyrektorzy techniczni sprawdzili kod i pełnią funkcje doradcze. Produkt niedawno przeszedł weryfikację bezpieczeństwa CASA Tier 2 przeprowadzoną przez niezależną firmę.
„Oczywiście nadal są błędy. Zatem pomysł, że po prostu zakodujesz narzędzie PSA za pomocą AI, jest kompletnym nonsensem”.
Pomysł, że po prostu zakodujesz narzędzie PSA za pomocą AI, jest kompletnym nonsensem.
Skoro więc AI nie zbudowała jego produktu, co zrobiła? „Nigdy nie byłbym w stanie zaprojektować tego za pomocą długopisu i kartki papieru”.
Warstwa tłumacząca zaczyna zanikać. Michael nie byłby w stanie napisać specyfikacji ani stworzyć makiety interfejsu użytkownika. Dziesięć lat temu oznaczałoby to koniec: pomysł pozostałby uwięziony w głowie praktyka, tak jak pomysły założycieli przez lata po cichu umierały w głowach kierowników projektów. Tym razem AI pozwoliła mu myśleć wizualnie i iteracyjnie, udoskonalając prototyp do momentu, w którym piętnaście lat zgromadzonych doświadczeń użytkownika przybrało przed nim konkretną formę. Coś, na co mógł zareagować, dopracować to i przekazać prawdziwym inżynierom.
Obecny sposób pracy nazywa „bardzo uporządkowaną wersją kodowania za pomocą AI”, w ramach której zajmuje się mniejszymi poprawkami i zmianami funkcji „pod nadzorem i zgodnie z zasadami ustalonymi przez osoby techniczne”.
„To, że nietechniczny założyciel startupu jest w stanie naprawdę stale rozwijać produkt, było niesamowite. Zastrzeżenie jest jednak takie, że musiałem współpracować z osobami, które miały większą wiedzę techniczną ode mnie”.
Czy przez cały czas chodziło o umiejętności PM-a?
Niedawno pisałem o zarządzaniu projektami jako zestawie umiejętności przedsiębiorczych, więc zadałem Michaelowi pytanie wprost: czy PM-owie są lepiej predysponowani do zostania założycielami niż osoby z innych środowisk?
Zgodził się z częścią tej tezy. PM-owie mają „większą skłonność do radzenia sobie ze stresem” — powiedział. Nieustannie przełączają się między kontekstami i żonglują równoległymi priorytetami, podczas gdy osoby z innych dziedzin mogą skupić się na jednej rzeczy. Co kluczowe, sami definiują swoją pracę: „PM zleci grafikowi zadanie do wykonania na dany dzień, podczas gdy PM musi ustalić, na czym to zadanie polega. I na tym właśnie polega przedsiębiorczość”.
Ale potem odwrócił moje założenie do góry nogami.
„Myślę, że ponieważ od początku byłem przedsiębiorcą, dlatego dobrze radziłem sobie z zarządzaniem projektami. Nie dlatego, że zarządzanie projektami doskonaliło moje umiejętności przedsiębiorcze. Myślę, że zawsze byłem przedsiębiorcą i dlatego zarządzanie projektami było dla mnie naturalnym wyborem”.
Myślę, że zawsze byłem przedsiębiorcą i dlatego zarządzanie projektami było dla mnie naturalnym wyborem.
Innymi słowy, zależność przebiega w odwrotnym kierunku. Zarządzanie projektami nie uczyniło z niego założyciela. To, że miał predyspozycje do bycia założycielem, sprawiło, że był dobrym kierownikiem projektu, a ten zawód stał się wygodnym miejscem do spożytkowania tej energii, podczas gdy rzeczywista bariera — zbudowanie czegoś — pozostawała zbyt wysoka.
Założyłbym się, że Michael nie jest wyjątkiem. Ilu praktyków ma za sobą dekadę doświadczeń związanych z narzędziami, których używają na co dzień, ale nie ma możliwości przekucia ich w coś więcej niż prośby o dodanie funkcji? Ilu z nich lubi brać odpowiedzialność za rezultaty, definiować pracę i ogarniać cały system? Ilu dokładnie wie, co jest nie tak z ich oprogramowaniem, a do niedawna nie miało sposobu, by pokazać komuś, jak powinno ono działać?
Dla tej grupy ostatnie dwa lata zmieniły sytuację. Nie dlatego, że AI przekształciła kierowników projektów w przedsiębiorców, lecz dlatego, że usunęła ostatnią wymówkę dla tych, którzy już nimi byli.
Jeśli chcesz dowiedzieć się więcej o tym, czym zajmowali się Michael i jego zespół, możesz sprawdzić to tutaj.
—--------
Chcesz otrzymywać więcej takich spostrzeżeń? Załóż bezpłatne konto DPM, aby posłuchać więcej ekspertów takich jak ci.
