Przejęcie cudzych projektów w IT to temat budzący mieszane uczucia. Dla wielu Software House’ów jest to wyzwanie, które często kończy się frustracją. Jakie są przyczyny, że firmy IT niechętnie angażują się w cudze projekty? Dlaczego klienci wysyłają niedoprecyzowane specyfikacje, oczekując cudów? Dzisiaj zgłębimy ten temat i omówimy, z jakimi trudnościami mierzą się programiści, gdy ktoś inny rozpoczyna projekt.
Pierwszym problemem, który napotykają Software House'y, jest brak dokładnych specyfikacji od klientów. Wyobraź sobie, że klient zgłasza się z pytaniem: „Ile kosztuje aplikacja?”. Niestety, często nie dostarcza żadnych szczegółów, poza tym, że aplikacja ma być kalendarzem na iOS. Takie podejście, choć powszechne, znacząco utrudnia wycenę projektu. Bez informacji o funkcjonalnościach, wyglądzie czy celach biznesowych, Software House musi działać w ciemno, co jest równoznaczne z „rzucaniem kulą w płot”.
Często spotykanym zjawiskiem w branży IT jest lęk klientów przed ujawnieniem swoich pomysłów. Obawiają się, że firma technologiczna „ukradnie” ich koncept. W rezultacie specyfikacje projektów są niekompletne, co w dłuższej perspektywie generuje problemy na każdym etapie realizacji. Prawda jest jednak taka, że Software House'y obsługują setki projektów i pomysł, choćby najbardziej innowacyjny, bez odpowiedniego wdrożenia, marketingu oraz zarządzania, nie ma większych szans na sukces.
Statystyki nie są łaskawe – na sto projektów dwa mają szansę na funkcjonowanie dłużej niż kilka miesięcy. Głównym powodem jest nie tylko brak specyfikacji, ale także brak strategii marketingowej. Nawet świetnie zaprojektowana aplikacja nie osiągnie sukcesu bez promocji. Klienci często zapominają, że sam produkt to dopiero początek drogi, a rynek szybko weryfikuje jego sensowność.
Innym wyzwaniem, które Software House'y napotykają, jest konieczność pracy nad starymi systemami, które zostały stworzone lata temu, często przez jednoosobowe działalności gospodarcze. Kiedy taka firma znika z rynku, klient zostaje z nieaktualnym systemem, który nie spełnia współczesnych standardów technologicznych. Praca nad takimi projektami to jak próba przywrócenia do życia przestarzałego auta – da się to zrobić, ale wiąże się to z wieloma wyzwaniami, które nie zawsze są warte poniesionych kosztów.
Przejęcie cudzego projektu oznacza konieczność głębokiej analizy kodu, wdrożenia zespołu i stworzenia kopii zapasowych. To proces wymagający nie tylko zaangażowania, ale i czasu, co generuje koszty. Klient musi liczyć się z tym, że takie projekty nie są szybkie do realizacji. Dodatkowo, brak odpowiednich dokumentacji może wydłużyć czas wdrażania i podnosić koszty.
Na końcu warto zadać sobie pytanie – czy opłaca się ratować stary system? Często najlepszym rozwiązaniem jest refaktoryzacja, a nawet stworzenie nowego systemu od podstaw, który będzie spełniał współczesne standardy i będzie łatwy w utrzymaniu. Stare technologie to koszmar każdego programisty, a projekty w nowych technologiach czekają w kolejce – dlaczego więc tracić czas na przestarzałe rozwiązania?
Przy podejmowaniu decyzji o współpracy nad starym projektem, kluczowe jest ustalenie, czy klient jest gotowy zainwestować odpowiednie zasoby w modernizację. Bo jeśli nie, to może lepiej odpuścić i zająć się czymś nowym.
Przejęcie projektów IT stworzonych przez inne firmy lub programistów to temat, który wzbudza liczne kontrowersje w branży technologicznej. Na pierwszy rzut oka może wydawać się to prostym zadaniem, jednak rzeczywistość często okazuje się bardziej skomplikowana. Dlaczego Software House'y podchodzą do takich projektów z rezerwą? Problem tkwi w specyfikacjach, braku odpowiedniej dokumentacji, a także w kosztach i czasie niezbędnym na wdrożenie się w obcy kod.
W tym FAQ rozwiejemy najczęstsze wątpliwości dotyczące przejmowania cudzych projektów przez firmy IT. Dowiesz się, z jakimi wyzwaniami mierzą się zespoły programistyczne oraz co sprawia, że klienci mają często nierealistyczne oczekiwania wobec takich współprac. Jeśli jesteś właścicielem firmy poszukującej wsparcia w modernizacji starego systemu lub wdrożeniu nowej aplikacji, ten przewodnik pomoże Ci lepiej zrozumieć procesy zachodzące po stronie Software House'u.
Przejęcie cudzego projektu wymaga dogłębnej analizy kodu, zapoznania się z technologią i zrozumienia zamierzeń klienta. Brak dokumentacji, przestarzałe technologie i konieczność modernizacji często generują dodatkowe koszty i opóźnienia, dlatego wiele firm unika takich wyzwań.
Jednym z głównych problemów są niesprecyzowane specyfikacje dostarczane przez klientów. Często klienci mają ogólne wyobrażenie o projekcie, ale nie dostarczają szczegółów dotyczących funkcjonalności, co utrudnia wycenę. Brak takich informacji prowadzi do błędnych oszacowań kosztów i czasu realizacji.
W wielu przypadkach bardziej opłacalnym rozwiązaniem jest stworzenie nowego systemu od podstaw niż próba naprawienia starego. Praca na przestarzałych technologiach może być czasochłonna i kosztowna, dlatego firmy IT sugerują często refaktoryzację lub całkowitą wymianę systemu.
Koszty przejęcia cudzego projektu zależą od stanu technicznego systemu, dostępnej dokumentacji, a także skomplikowania funkcji. Zazwyczaj firmy IT rezerwują pewien budżet na wstępną analizę, a kolejne etapy realizacji są wyceniane po dokładniejszym zapoznaniu się z kodem i wymaganiami.
Dlaczego IT nie lubi przejmować cudzych projektów oraz z jakimi specyfikacjami czasami piszą do nas klienci z prośbą o wycenę. Jedziemy. Cześć! Witajcie w piątek. Dzisiaj będzie podsumowanie ostatnich dwóch tygodni, bo w zeszły weekend miałem gości. Miałem delegację z Warszawy. Nie miałem kiedy ani montować. Z drugiej strony nie miałem też głowy do nagrywania. No i trzecia rzecz, że ostatnio jakiś taki ruch się zrobił w interesie, że jak jadę samochodem, to nie mam czasu coś do was powiedzieć, tylko oddzwaniam na wszystkie telefony, których nie odebrałem w ciągu dnia. To znaczy się, że jest dobrze, znaczy się, że będą pieniążki. A właściwie pieniądze będą, bo mam nadzieję, że będą dłużej konkretne. A teraz już przechodząc do rzeczy poważnych. Dwie ciekawe z mojej perspektywy oczywiście rzeczy związane z prowadzeniem projektów IT. Jedna sprawa dotyczy wycen, dotyczy ofert oraz specyfikacji, jakie dostaję od klientów. I to żebym nie był gołosłowny to Wam wrzucę screeny. Oczywiście wytnę to co tam wycięte być powinno. Natomiast zobaczcie, poproszę aplikację. Czy robicie aplikację, ile taka aplikacja kosztuje, co ta aplikacja ma robić, jak ma wyglądać, na jaki system? Mnóstwo zmiennych, ale no dobra, odpisuje, wiadomo, wszystkie szczegóły z prośbą o dopytanie, z prośbą o doszczegółowienie, o jakąś specyfikację, jakiś brief, do czego ona ma służyć, jak ma działać, jakie są jej założenia, jaki jest cel biznesowy, cokolwiek. No i dostaję w odpowiedzi aplikacja to ma być kalendarz na iOS i więcej nie powiem. Klienci się boją, że jak przyjdą do nas z pomysłem, to my im go ukradniemy. Jakby z jednej strony rozumiem ten lęk, a z drugiej strony jako osoba, która prowadzi software house i obsługuje ileś tam dziesiątek pomysłów czy miesięcznie, czy tygodniowo, czy rocznie, nie robią na mnie wrażenia, bo pomysł z pomysłem, dopóki nie zostanie zrealizowany, nie zostanie napisany soft, nie zostanie uruchomiony. Marketing nie ma całego pionu zarządzania w tej firmie to 90% pomysłów, jak nie 95, jak nie 99 z reguły upada albo na etapie jeszcze samego właśnie wyceny projektu, albo już po zrobieniu okazuje się, że no dobra, jest aplikacja, jest coś tam, ale nie ma do tego marketingu i nikt o tym nie wie, że coś takiego w ogóle na świecie istnieje. I nawet jeżeli to jest, to i tak jest tyle zmiennych rynkowych i konkurencji, o której być może ktoś nie wie, że jeżeli ktoś z ulicy ma naprawdę jakiś pomysł i uważa, że on jest innowacyjny, to chyba dwa takie przypadki mam, gdzie rzeczywiście udało się go zrealizować i powiedzmy jakoś on tam funkcjonuje. Nie mam oczywiście wglądu w finanse danego projektu, danej firmy, natomiast wiem, że funkcjonuje, że działa, że są użytkownicy, klienci zadowoleni, no i spoko. Natomiast to jest naprawdę mniejszość. I gdybym miał powiedzieć, jak bardzo mniejsza mniejszość 2%, czyli na sto projektów dwa projekty dochodzą do skutku, są realizowane i działają powiedzmy w ciągu trzech miesięcy czy roku, jeszcze po starcie. Jak widzicie, ciężko mi jest oszacować na zasadzie poproszę kalendarz i nie mogę powiedzieć nic więcej, ale ma on być na iOS i ma być proste od tysiąca do miliona złotych. Taką daję wycenę, taką robię ofertę. No i wiadomo, że to jest rzucanie kulą w płot, a klient z jakiegoś powodu nie chce powiedzieć więcej. Nie znam się, zarobiony jestem, nie będę w to wnikał, dlaczego tak jest. Szanuję, że klient chce coś tam zatrzymać sobie w tajemnicy, natomiast nie jestem w stanie jakby więcej mu pomóc. No właśnie z wcześniej wymienionych względów i powodów. Drugi temat też śmieszny i śmieszny, ale z którym się dość często spotykam. To jest kwestia przychodzi jakaś firma, dostaje leada, dostaje kontakt i ktoś potrzebuje wsparcia. W jakimś starym systemie była jakaś firma postawiła jakiś system, ten system działał, ale później okazuje się, że ta firma tak naprawdę była jednoosobową działalnością gospodarczą, która po prostu jakiś system napisała, później go trochę rozwijała. Jeżeli coś tam było trzeba supportować, również była dostępna. Ale jak to jest z jednoosobowymi działalnościami gospodarczymi? Raz ktoś jest, raz go nagle nie ma. No i dzwoni. Odzywa się ktoś, kto mówi, że potrzebuje wsparcia, bo ma taki system napisany już z 10 15 lat temu. Ktoś mu go tam wpisał, ktoś mu go tam rozwijał. No ale ta osoba się z jakiegoś powodu zawinęła. Nie ma supportu, nie ma nic, co by można było. Nie ma nikogo, kto by mógł ten system poratować, rozwinąć, coś w nim zmienić. No i się okazuje, że ok, mówię, możemy podjąć rękawicę, zobaczymy co tam tak naprawdę jest. Poproszę o dostęp do FTP, dostęp do panelu CMS, Link do strony. Przede wszystkim spisanie co tak naprawdę ma być tam do zrobienia. Zobaczymy, oszacujemy, być może będziemy w stanie pomóc. No bo tutaj wiadomo, nigdy gwarancji jako takich nie mam. No i rzeczywiście wchodzę, patrzę, widzę już strona nie responsywna, w starych technologiach napisana. Dostałem screeny panelu administracyjnego, też widać, że świeżością on nie wieje. Jedyne co jestem w stanie zrobić na dzień dobry, to poprosić o dostępy do kodu po to, żeby wdrożyć swoich programistów, żeby oni się tam trochę rozejrzeli. Jak to działa? Co tak naprawdę jest do zrobienia, Co trzeba zmodyfikować, żeby uzyskać efekt, o który chodzi klientowi? Natomiast też od razu piszę, że to zajmie na pewno trochę czasu. Wdrożenie się w ten projekt, oszacowanie zmian, zobaczenie czy ktoś jakiś bugów nie nasadził w kodzie takich, że no teraz już po prostu trzeba by je usunąć, bo można jakieś dane wykraść albo cokolwiek innego. Do tego konfiguracja całego środowiska repozytorium po naszej stronie. Jak coś się stanie, czego my nie ogarniemy w projekcie, który nie jest nasz, to przydałby się jakiś backup. Trzeba by mieć jakąś kontrolę wersji. Do tego mówię, że ok. Proponuję na razie ustalić jakiś budżet, który mamy na rozeznanie się w ramach tego projektu. Jeżeli będziemy w stanie w ramach tego budżetu zacząć wprowadzać jakieś zmiany i być może już nie wiem, część banerów pozmieniać, część jakichś rzeczy mechanicznych ok, oczywiście to zrobimy, no bo dlaczego nie? Natomiast jeżeli się okaże, że no technologia będzie dla nas zbyt stara. Nie wierzę w to. Natomiast jakby Zakładam też taki scenariusz, że chłopaki powiedzą, że. Dominik. My się tego nie chcemy tykać, bo boimy się, że jak coś spierdzielimy, to my później tego nie będziemy w stanie uratować, nie będziemy w stanie tego jakby na nowo postawić i serwisu tak naprawdę opublikować, żeby on działał chociażby tak, jak do tej pory działał. Więc taki scenariusz również biorę pod uwagę. Całe przedsięwzięcie oszacowałem wstępnie na to, że ok, bierzemy tam z 20 25 godzin na to, żeby rzeczywiście się z tym systemem zapoznać, przygotować właśnie kwestie związane z backupami, przygotować wszystkie kwestie związane z repozytorium, rozejrzeć w kodzie, przygotować to, co można przygotować, zrealizować też te zagadnienia, o które klient prosi, jeżeli będą w zasięgu od razu, od początku klienta nastawiłem, że ok, to potrzebujemy te 20 25 godzin na takie prace wstępne. Co będziemy mogli zrobić później, będę w stanie tak naprawdę odpowiedzieć w momencie, kiedy już ten pierwszy etap będziemy mieli za sobą. Natomiast przyjmijmy sobie, że na te prace później, nazwijmy to, rozwojowe, potrzebny będzie drugie tyle godzin po to, żeby chociaż klient wiedział, z jakiego rzędu kosztami musi się to liczyć. W naszym przypadku wiadomo, po prostym przeliczeniu stawki godzinowej jest to budżet jakby pierwszego etapu 5000, drugiego etapu około 10%. Nie są to małe pieniądze i od razu też klientowi zasugerowałem, że to nie jest skomplikowana strona. To jest katalog produktów. Może w tym budżecie warto się zastanowić, czy nie przejść już na jakiś nowy silnik, na jakieś nowe rozwiązanie, gdzie za taką samą kwotę albo stosunkowo niewiele większą będzie miał już rozwiązanie, które będzie responsywne, dostosowane do współczesnych technologii, dostosowane do współczesnych urządzeń. No i tak naprawdę znowu będzie miał je na lata. No i będzie miał je wspierane przez nas. No bo my tą całą kontrolę wersji, te wszystkie elementy, wiadomo, robimy i spinamy tak, żeby później móc serwisować, utrzymywać i rozwijać. Każdy serwis więc ma tak naprawdę zapewnione bezpieczeństwo na lata. No i na nowy serwis oczywiście otrzymuje gwarancję, więc jak cokolwiek się będzie działo ma nas. Poprawiamy, naprawiamy, ratujemy jeżeli jest taka potrzeba. Na co klient stwierdził, że niestety to jest prosty serwis. To jest stary serwis. On takiego budżetu na to nie przewiduje. No i właściwie dlaczego tak drogo? Przecież tutaj wystarczy jakieś proste rzeczy, On chce, żeby pozmieniać. No i oczywiście wytłumaczyłem, dlaczego tak drogo. Wytłumaczyłem właśnie te wszystkie zależności związane z przygotowaniem środowisk deweloperskich. Wytłumaczyłem kwestie odpowiedzialności, gwarancji za wprowadzane nawet zmiany. No i z całą tą informacją klienta zostawiłem. I tak się później zacząłem zastanawiać, czy to, czy to w ogóle był dobry pomysł, że ja się w to zaangażowałem, zamiast powiedzieć, że nie, nie wspieramy starych systemów, bo z jednej strony wiem, że u mnie chłopaki będą miały takie co trzeba w jakimś badziewiu grzebać, coś tam szukać, zmieniać. To wszystko nie działa już tak po nowoczesnemu. No to tak jakbyście mieli wsiąść do samochodu. A propos samochodu np. Do Kijowa po Audi jest przeskok, a to jest ten sam rocznik plus minus, A co dopiero jakbyście mieli wsiąść do samochodu sprzed 15 czy 20 lat po tym, jak jeździcie najnowszą klasą. Nie no, nagle się robi tak ciężko. No więc moi deweloperzy mają tak samo. No więc to jest jedna sprawa. Więc jakby taka trochę ogólnie niechęć developerów do robienia w starych technologiach, gdzie projektów w nowych technologiach mamy po czubek nosa, a właściwie po czubek głowy, chyba tak się mówi. No a druga rzecz to właśnie kwestia związana ze wszelkiego rodzaju odpowiedzialnościami i potem takim, no ekonomicznym uzasadnieniem projektu. Bo jak się okazuje, to moje spotkania z klientem, moje tam rozmowy, analiza tego wszystkiego trwa, a co za tym idzie kosztuje. No i na razie wiadomo, że za takie rzeczy klienta nie obciążamy. No bo to jest jakby trochę, no w naszym interesie, żeby klienta wprowadzić, przeprowadzić przez cały ten pierwszy etap projektu. No ale znowu, no nie jest moją rolą go namawiać na to, żeby on koniecznie jakby ten system ratował, jakbym miał go na co dzień. Spokój. Jakbym miał go na coś namawiać, to raczej na refactoring i odświeżenie tego systemu i na napisanie być może go od nowa. Albo uproszczenie do jakiejś tam wersji innej katalogu produktów. I niekoniecznie z nami, bo jakby mi nie zależy na tym, żeby łapać wszystkie zlecenia z rynku musi obsługiwać moja firma, nie. Jeżeli ktoś da taniej, zrobi szybciej, nie ma problemu. To jakby o to chodzi. W rynku można znaleźć sobie dostawcę takiego jakiego się chce, ale czy ratować stary serwis? Odradzałbym, No ale tutaj jakby decyzja jest standardowo po stronie klienta to zdecyduje. Zobaczymy. Natomiast tak jak sobie nad tym myślę, to chyba trochę żałuję jakby czasu, który poświęciłem na to. Widzę, że klient jest trochę niezadowolony, trochę zniesmaczony, że takie duże pieniądze za jakieś proste zmiany w starym systemie, który jakby było na pewno prosto napisane, można to było chyba zrobić inaczej. No to takie dwie ciekawostki ode mnie, czyli specyfikacje i wsparcie starych systemów, czyli coś, co w IT uwielbiamy I cóż pozostaje mi życzyć Wam miłego weekendu i mam nadzieję, że przyszły tydzień będzie dla mnie o tyle łaskawszy, że będę w stanie wrzucać Wam jakieś rzeczy codziennie, a nie tylko kurde z partyzanta w piątek. Po drodze jeszcze gdzieś tam na szybko, żeby coś do Was ciekawego powiedzieć, a nie zginąć w czeluściach internetowych YouTube'a. A, no i ostatni temat z dzisiaj to jak widzicie jeżdżę Kia Sportage, rocznik 2023, dziesięć tysięcy kilometrów przebiegu. No i nie, nie wracam do swojego Audi. Jednak nie podobają mi się SUV y ani z perspektywy kierowcy, ani z perspektywy osiągów. Ale cóż, lepszy taki zastępczy niż żaden. I autobus, trolejbus albo tramwaj. Kończę. Trzymajcie się. Cześć. Jeszcze mi melodyjka zagrała zajebiście.