Zbudować czy kupić: decyzja dotycząca narzędzi do zarządzania projektami w erze AI
Kupowanie jako domyślna opcja: Większość liderów woli kupować rozwiązania, chyba że konkretne problemy z przepływem pracy wymagają stworzenia niestandardowego narzędzia.
Kluczowe pytanie: Ustal, czy dany przepływ pracy ma kluczowe znaczenie dla wyróżnienia się na rynku, czy stanowi podstawową infrastrukturę — pomoże to podjąć decyzję o zakupie lub budowie.
Konieczność tworzenia: Firmy mogą potrzebować tworzyć własne rozwiązania, gdy nie istnieją odpowiednie gotowe opcje dla unikalnych przepływów pracy.
Wpływ kodowania na wyczucie: Narzędzia wspomagane przez AI, takie jak kodowanie na wyczucie, obniżają bariery dla osób nietechnicznych, umożliwiając im szybkie tworzenie funkcjonalnego oprogramowania.
Ukryte koszty: Tworzenie niestandardowego oprogramowania może prowadzić do długoterminowych problemów z utrzymaniem, przez co zakup często staje się bezpieczniejszą opcją.
Dla liderów projektów i operacji niewiele decyzji ma większe długoterminowe konsekwencje niż wybór między zbudowaniem własnego narzędzia a zakupem gotowego rozwiązania. Jeśli podejmiesz właściwą decyzję, Twój zespół otrzyma dokładnie taką infrastrukturę, jakiej potrzebuje, aby działać szybko i zachować spójność.
Jeśli decyzja okaże się błędna, albo utkniesz w rozbudowanym stosie SaaS, który nie pasuje do Twoich przepływów pracy, albo zostaniesz przytłoczony obowiązkiem utrzymania własnego systemu, którego nikt już w pełni nie rozumie. To pytanie zawsze było trudne. Teraz, gdy „vibecoding” sprawia, że osoby bez wykształcenia technicznego mogą łatwiej niż kiedykolwiek tworzyć funkcjonalne oprogramowanie, stało się ono bardziej złożone — i ciekawsze.
Domyślny punkt wyjścia: kup, chyba że masz powód, by tego nie robić
Większość doświadczonych liderów operacyjnych powie Ci, że zakup powinien być domyślnym rozwiązaniem, a budowa własnego narzędzia powinna być brana pod uwagę dopiero wtedy, gdy istnieje ku temu jasny i konkretny powód. Philip Stoelman, założyciel i dyrektor generalny Network Republic, ujmuje to wprost: „Domyślnie kupujemy, chyba że natrafimy na problem z przepływem pracy, którego żadne istniejące narzędzie nie potrafi rozwiązać bez licznych kompromisów. To uczciwy punkt wyjścia i sądzę, że większość liderów operacyjnych, którzy zajmują się tym wystarczająco długo, ostatecznie dochodzi do tego samego wniosku”.
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
Domyślnie kupujemy, chyba że natrafimy na problem z przepływem pracy, którego żadne istniejące narzędzie nie potrafi rozwiązać bez licznych kompromisów.
Logika jest prosta. Gotowe narzędzia zapewniają wsparcie, dokumentację, stałe aktualizacje oraz bazę użytkowników, która zdążyła już poddać produkt próbom w praktyce. Budowa własnego rozwiązania wymaga natomiast ciągłych inwestycji w rozwój, utrzymanie i wiedzę instytucjonalną. Abdullah Shoaib, dyrektor generalny i założyciel Energy Solutions, ujmuje to następująco: „Zwykle kupujemy, gdy rozwiązanie odpowiada na powszechną potrzebę biznesową i można je szybko wdrożyć. Rozważamy budowę własnego rozwiązania tylko wtedy, gdy dany proces stanowi przewagę konkurencyjną albo gdy istniejące narzędzia wymagają zbyt wielu obejść, które powodują nieefektywność”.
Zwykle kupujemy, gdy rozwiązanie odpowiada na powszechną potrzebę biznesową i można je szybko wdrożyć. Rozważamy budowę własnego rozwiązania tylko wtedy, gdy dany proces stanowi przewagę konkurencyjną albo gdy istniejące narzędzia wymagają zbyt wielu obejść.
Kluczowe pytanie: wyróżnik czy infrastruktura?
Jeśli zakup jest rozwiązaniem domyślnym, co przemawia za budową własnego narzędzia? Dla większości liderów odpowiedź sprowadza się do jednego pytania diagnostycznego: Czy ten przepływ pracy wyróżnia naszą firmę, czy jest tylko infrastrukturą?
Lizelle Balanco, menedżerka systemów biznesowych w Cloudflare, opisuje filtr stosowany przez jej zespół: „Nasze pierwsze pytanie zawsze brzmi: Czy jest to coś, co wyróżnia naszą firmę, czy po prostu coś, czego potrzebujemy do prowadzenia działalności? Jeśli jest to unikalny przepływ pracy, przewaga konkurencyjna lub proces, z którym istniejące rozwiązania nie radzą sobie dobrze, budowa własnego rozwiązania staje się poważną opcją do rozważenia”.
Nasze pierwsze pytanie zawsze brzmi: Czy jest to coś, co wyróżnia naszą firmę, czy po prostu coś, czego potrzebujemy do prowadzenia działalności?
Ciaran Burke, dyrektor operacyjny i współzałożyciel Swoop Funding, stosuje podobny podział: „Zaczynamy od prostego testu: czy ta funkcja jest kluczowa dla tego, jak się wyróżniamy, czy jest tylko podstawową infrastrukturą? Wszystko, co wiąże się z naszym silnikiem dopasowywania, przepływami pracy pożyczkodawców lub zastrzeżonymi danymi, budujemy samodzielnie; wszystko, co jest rozwiązaniem standardowym — CRM, system obsługi zgłoszeń, BI, komunikacja — kupujemy”.
Zaczynamy od prostego testu: czy ta funkcja jest kluczowa dla tego, jak się wyróżniamy, czy jest tylko podstawową infrastrukturą?
Wniosek płynący z wypowiedzi liderów jest spójny: standardowe funkcje powinny być obsługiwane przez standardowe narzędzia. Własne przepływy pracy — te, które odzwierciedlają sposób, w jaki firma faktycznie myśli i działa — to rozwiązania, których budowa ma sens.
Gdy luka jest zbyt duża, by ją ignorować: budowanie z konieczności
Czasami decyzja o zbudowaniu czegoś nie jest tyle wyborem strategicznym, ile praktycznym. Odpowiednie narzędzie po prostu nie istnieje, a żadna ilość konfiguracji nie sprawi, że gotowy produkt będzie robił to, co trzeba.
Dixie Willard, założycielka i główna strateg ds. projektów w Poised & Plumb, doszła do tego wniosku, pracując w branży projektowania wnętrz. Zapytana, czy gotowe narzędzie mogłoby rozwiązać jej problemy, odpowiedziała bez ogródek: „Nie ma takiego. Po prostu go nie ma. A istnieje wiele narzędzi, z których projektanci mogliby korzystać, ale one po prostu nie istnieją”. Następnie Dixie zaczęła pracować nad różnymi projektami tworzonymi za pomocą podpowiedzi, aby zaspokoić tę potrzebę.
Istnieje wiele narzędzi, z których projektanci mogliby korzystać, ale one po prostu nie istnieją.
Daniel Preston, założyciel LiveInCare USA, podchodzi do tego pytania w bardziej diagnostyczny sposób: „Pierwsze pytanie, które zadaję, brzmi: czy proces, który próbujemy obsłużyć, jest rzeczywiście unikalny? Jeśli proces jest powszechny, na przykład marketing e-mailowy, analityka, płatności lub funkcje CRM, zazwyczaj wolę kupić istniejące rozwiązanie”. Wniosek jest jasny — gdy proces jest rzeczywiście nietypowy, zakup przestaje być właściwą odpowiedzią.
Aniket Ghonge, starszy menedżer ds. łańcucha dostaw w Amazon, zetknął się z tą granicą osobiście, gdy istniejące narzędzia korporacyjne nie nadążały za jego potrzebami operacyjnymi: „Technologia CRM, z którą wówczas pracowałem, nie miała potrzebnych mi możliwości. Potrzebowałem czegoś, co pomogłoby mi zautomatyzować pracę, dało możliwość porównania wielu źródeł, a następnie wygenerowania końcowego planu popytu dla naszych nowych przewoźników”. Ghonge zbudował później system rozwiązujący ten niszowy problem, skracając czas pracy z 18 godzin do 1 godziny.
Gdy kodowanie za pomocą podpowiedzi zmienia kalkulację
Przez lata budowanie rozwiązania wiązało się ze znaczącą barierą wejścia: potrzebni byli programiści, czas i pieniądze. Narzędzia programistyczne wspomagane przez AI — platformy do kodowania za pomocą podpowiedzi, takie jak Replit, Cursor i inne — zaczęły w istotny sposób obniżać tę barierę. Dla kierowników projektów i liderów operacyjnych bez wykształcenia inżynierskiego możliwość stworzenia funkcjonalnego narzędzia za pomocą polecenia wprowadziła zupełnie nową opcję do procesu podejmowania decyzji.
Michael Gold, założyciel i tymczasowy szef realizacji projektów, niedawno przetestował to na własnym CRM: „Właśnie zbudowałem własny CRM za pomocą Replit, ponieważ korzystałem z Close, a jego koszt wynosił 100 USD miesięcznie. Nie będę kłamać i twierdzić, że jest lepszy od Close, ale jest darmowy — a przynajmniej Replit kosztuje 25 USD miesięcznie”. Opisany przez Golda kompromis — rozwiązanie mniej dopracowane, ale zdecydowanie tańsze i dostosowane do jego dokładnych potrzeb — to wybór, którego dokonuje coraz więcej praktyków.
Właśnie zbudowałem własny CRM za pomocą Replit, ponieważ korzystałem z Close, a jego koszt wynosił 100 USD miesięcznie.
More Articles
- Ile kosztuje oprogramowanie do zarządzania przepływem pracy?
- Zarządzanie projektami w przedsiębiorstwie: jak planować i wdrażać
- Ile kosztuje oprogramowanie do współpracy?
- Szablon planowania wydajności: szybciej planuj obciążenie zespołu
- Darmowy szablon wykresu Gantta do programu Excel i Arkuszy Google
Ukryte koszty budowania: perspektywa ostrzegawcza
Dostępność narzędzi do kodowania za pomocą podpowiedzi nie eliminuje ryzyka związanego z budowaniem — jedynie obniża próg początkowy. Długoterminowe koszty posiadania autorskiego oprogramowania pozostają, a doświadczeni konsultanci, którzy obserwowali klientów podążających tą drogą, szybko je wskazują.
Marissa Taffer, założycielka i prezeska M. Taffer Consulting, widziała organizacje wydające duże kwoty na niestandardowe rozwiązania, które nigdy nie powinny były wyjść poza tablicę: „Gdybym była zaangażowana od samego początku, myślę, że zaleciłabym kupno gotowego rozwiązania i dostosowanie go zamiast budowania tego, co zbudował mój klient”. Wspominając to doświadczenie, Taffer rozwija temat frustracji: „Często musiałam przechodzić przez administratora, żeby cokolwiek naprawić. Narzędzie nie było zbyt dobrze utrzymywane”. Opisywany przez Taffer problem z utrzymaniem — narzędzia, które powoli niszczeją, ponieważ nikt nie ma odpowiednich zasobów, by utrzymywać je w dobrym stanie — jest jednym z najczęstszych sposobów, na jakie zawodzą rozwiązania tworzone we własnym zakresie.
Gdybym był zaangażowany od samego początku, myślę, że zaleciłbym kupienie gotowego rozwiązania i dostosowanie go zamiast budowania tego, co zbudował mój klient.
Granica kodowania intuicyjnego: gdy prototypy stają się produktami
Wzrost popularności kodowania intuicyjnego sprawił, że pilnie trzeba na nowo zdefiniować ważną granicę: linię między prototypem a systemem produkcyjnym. Narzędzie stworzone w jedno popołudnie w celu zweryfikowania pomysłu to jedno. Narzędzie, od którego dwudziestoosobowy zespół codziennie zależy, to zupełnie co innego — a przejście od jednego do drugiego wymaga czegoś więcej niż tylko formułowania poleceń.
Tim Fisher, wiceprezes ds. sztucznej inteligencji w The Digital Project Manager, wyraźnie wyznacza tę granicę: „Jeśli zbudujesz coś, na czym ludzie polegają, musi się to stać czymś więcej niż tylko projektem stworzonym za pomocą kodowania intuicyjnego; muszą przejąć to osoby, które zawodowo zajmują się takimi rzeczami i wiedzą to, o co nawet nie wiesz, że trzeba zapytać. Wartość tych narzędzi dla osób niekodujących polega na tym, że pozwalają ominąć takie kwestie jak uzgodnienie wspólnego podejścia do pomysłu i przejść przez etap „czy to zadziała?”. „
Jeśli zbudujesz coś, na czym ludzie polegają, musi się to stać czymś więcej niż tylko projektem stworzonym za pomocą kodowania intuicyjnego; muszą przejąć to osoby, które zawodowo zajmują się takimi rzeczami i wiedzą to, o co nawet nie wiesz, że trzeba zapytać.
Ujęcie Fishera jest przychylne kodowaniu intuicyjnemu — i słusznie, bo rzeczywiście pozwala skrócić dystans między pomysłem a dowodem słuszności koncepcji — ale jednocześnie jasno pokazuje jego ograniczenia. Prototyp jest początkiem rozmowy o tym, czy budować, a nie gotowym rozwiązaniem.
Chcesz otrzymywać więcej takich spostrzeżeń? Zarejestruj się bezpłatnie w serwisie DPM, aby poznać opinie większej liczby ekspertów.
