Kilkudziesięcioosobowa organizacja z dużą rotacją. Stawiają nową stronę. Znajomy znający się na IT spada z nieba i oferuje pomoc. Tworzy własną platformę do zarządzania treścią (tzw. CMS), którego nie może przestać zachwalać. Szybszy od innych, bardziej bezpieczny, o wiele lepiej napisany kod strony. No i on jest Twórcą.

Wyczuwam problem. Informuję Prezesa, jakie mogą być konsekwencje takiej decyzji. Co, jeśli będziecie chcieli później coś zmienić? Co, jeśli nie będziecie wiedzieli jak to dokładnie działa? Co, jeśli ta osoba nie będzie miała potem dla Was czasu? „Nie, nie, on szybko odpisuje na maile i wszystko nam robi tak, jak będziemy chcieli”.

Nie mijają dwa lata. Do organizacji dołącza nowa osoba znająca się na IT. Patrzy na stronę i wylicza możliwe usprawnienia i innowacje, które chętnie by wprowadziła, tylko czy ta strona jest na popularnym WordPressie? Nie. Czy jest napisana w jakimś popularnym frameworku? Nie. Czy macie dostęp do kodu? Nie. Wiele pomysłów upada, chęć kolegi do zmiany organizacji na lepsze zaczyna topnieć pod naporem piętrzących się przeszkód. Mógłby siąść i swobodnie popracować nad stroną, jednak jeśli ma już ciągle prosić kogoś o ustawienie każdej rzeczy, czekać na odpowiedź, czekać aż ktoś dorobi funkcjonalność, której teraz nie ma albo naprawi coś, co powinno działać dawno temu, to po prostu się odechciewa.

 

Jasne, że możesz korzystać z pomocy znajomych, którzy chcą Ci pomóc z IT. Zrobisz dla nich coś dobrego. Nauczą się przy okazji jak robić strony czy aplikacje, poćwiczą na realnym przykładzie, którego ktoś faktycznie potrzebuje. Jednak po radosnej fazie tworzenia przychodzi też faza utrzymania, która jest już mniej przyjemna. „Nie dość, że zrobiłem im to za darmo/za grosze, to jeszcze ciągle mają jakieś uwagi, coś im się nie podoba, ciągle coś by tam zmieniali. Siedzę i wprowadzam te zmiany godzinami, chociaż już od dawna nie powinienem się tym zajmować i o tym zapomnieć.” – może pomyśleć twórca.

 

Czy nie masz korzystać z pomocy znajomych, którzy chcą poćwiczyć na Twojej organizacji IT? Ależ proszę. IT za darmo lub za grosze to przecież nie lada gratka. Tylko bądź świadomy, na co się piszesz. A na co się piszesz?

 

Niewątpliwe plusy:

  • Jest bardzo tanio lub wręcz za darmo – normalnie musiałbyś mocno potrząsnąć portfelem,
  • I tak nie znasz się na tym IT, a ktoś zdejmuje Ci problem z głowy i to jeszcze z wielką ochotą,
  • Tworzysz lub utrzymujesz dobre relacje ze znajomym uszczęśliwiając go realnym przykładem swojej organizacji, na którym on może ćwiczyć.

 

Wiedz jednak, że decydujesz się też stawić czoła minusom:

  • Jeśli ktoś uczy się na Tobie, to pewnie, jak to w procesie uczenia, popełni błędy. Coś może nie działać lub przestać działać.
  • Utrzymanie boli. Kiedy chcesz naprawiać lub zmieniać coś, co działa już na tzw. produkcji, towarzyszą temu mniej atrakcyjne emocje niż w radosnym procesie wymyślania i tworzenia. Wszystko, co zostało naobiecywane, piękne wizje przyszłości i spełnionych marzeń teraz konfrontują się z rzeczywistością. Twórca może denerwować się nawet sam na siebie, że czegoś nie dopatrzył albo, że jakaś zmiana idzie wolniej niż by chciał. Nerwy zdarzają się po obu stronach, bo Ty też przecież czekasz, na niekiedy bardzo ważną dla Twojej organizacji zmianę.
  • Utrzymanie trwa. Jeśli ktoś uczył się na Tobie, istnieje ryzyko, że ma swoje inne sprawy lub nie przygotował idealnej konstrukcji oprogramowania. Kiedy system się rozrasta, jego konstrukcja z czasem może bardziej przypominać zbity z desek przez nastolatka domek na drzewie, gdzie rzeczy trzymają się cudem, na sznurek lub taśmę klejącą. Wielu wyznaje zasadę – „skoro działa, to lepiej nie ruszać”. Niestety czasem lęk przed grzebaniem przeważa potrzeba rozbudowania o ważną rzecz. Wtedy dodanie czegoś do tak misternej konstrukcji może spowodować, że wszystko się „sypnie”. Zamiast dodać jedną rzecz, twórca musi poprawić też wszystko naokoło, żeby się to czegoś trzymało. Dlatego małe zmiany trwają czasem długo.
  • Oby nie wpadł pod tramwaj. Pomyśl jak ważnym zasobem jest dla Ciebie strona, aplikacja, system, który przygotowała, zna i utrzymuje jedna osoba. Co jeśli, z jakiegoś powodu przestanie być ona dostępna? Jeśli się upierasz – OK – ale uświadom sobie konsekwencje.

 

Co możesz zrobić, żeby zmniejszyć ryzyko?

  • Nie wyważaj otwartych drzwi. Jeśli istnieje już rozwiązanie na Twój problem, a zakładam się, że pewnie Twój problem z IT miało przed Tobą już wiele wiele osób, to na pewno istnieją na to rozwiązania. Będzie to tańsze niż tworzenie wszystkiego od zera. Jest teraz taki wybór, że głowa mała. Oczywiście może być tak, że zrobienie prostego lub bardzo skomplikowanego systemu wyjdzie taniej, kiedy ktoś napisze to pod Ciebie, jednak za każdym razem warto, aby była to świadoma decyzja i kalkulacja.
  • Wybieraj popularne rozwiązania, technologie. Po co? Będzie łatwiej znaleźć kogoś innego, kto również je zna i będzie w stanie rozwijać stronę czy aplikację. Będzie to też tańsze niż wynajmowanie specjalisty z bardzo wąskiego grona znającego niszową technologię.
  • Znajdź inne osoby znające się na IT i zapytaj ich niezależnie o opinię na temat rozwiązania, technologii, podejścia – chociażby posłuchaj ich zdania na ten temat, zanim wyrobisz sobie własne. Możesz stwierdzić, że inny znajomy jest negatywnie nastawiony do tego pomysłu z innych powodów. Jeśli tak, zapytaj jeszcze kolejnego. Po prostu posłuchaj innych opinii.
  • Lepszy ogólnie doświadczony, ale uczący się nowej technologii niż uczący się w ogóle. Programista, który od dawna pracuje w zawodzie, ale uczy się nowej technologii zna już wiele dobrych praktyk tworzenia oprogramowania wyniesionych z wcześniejszych projektów. Błędy popełniał już od dawna i uczył się na nich. Jeśli decydujesz się na zupełnie początkującą w branży osobę, będzie uczyła się na Tobie. Jeśli masz wybór – bierz doświadczonego.
  • Im bliżej, tym lepiej. Skoro już decydujesz się na takie rozwiązanie, lepiej jest chociażby mieć znajomego blisko. Takiego, którego często widujesz. Jeśli osoba taka będzie spędzała czas w Twojej organizacji, pozna ludzi, dla których to robi, lepiej zrozumie co jest dla Was ważne. Wprowadzanie poprawek też powinno pójść sprawniej, kiedy będzie miał od Was informację zwrotną na bieżąco. Im dalszy człowiek, tym łatwiej odwrócić się na pięcie i zniknąć z Twojego życia i firmy.

 

Jeszcze na koniec dwie moje żenujące historie z młodości. Zabawne stały się dopiero z perspektywy czasu :)

Jednej znajomej tworzyłam kiedyś stronę, która padła ofiarą ataku hakerskiego. Ktoś podmienił główną stronę wiejskiej szkoły i wyświetlał pod tym adresem arabskie hasła i dziwne zdjęcia. Nieźle się wystraszyliśmy. Cóż, brak odpowiednich zabezpieczeń młodego entuzjasty HTMLa.

Drugiej znajomej tworzyłam cały system do zarządzania głównymi procesami w firmie – sprzedaż WWW dla klientów, zarządzanie produktami, zarządzanie informacjami sprzedażowymi dla pracowników i panel podsumowań finansowych dla Pani Prezes J Radochy co nie miara. Nauczyłam się robić sesje w PHP, koszyk zakupów i inne cuda. Niestety sypało błędami, kiedy próbowałam coś rozbudowywać. I nikt mi nie powiedział, że są już na to gotowe rozwiązania :P

 

Jeśli korzystasz z pomocy, to znaj cenę uszczęśliwiania ludzi z IT i cenę niskiej ceny :)

Wiele takich historii kończy się tak, że pracę i tak trzeba wykonać od nowa.

Hania Tomaszewska
8 lat temu odkryłam, że analiza biznesowa to genialna rzecz. Od tamtej chwili zbieram doświadczenia w różnych firmach, branżach i projektach. Pracuję na etacie, prowadzę bloga, tworzę kursy, prowadzę szkolenia i konsultacje. Pomagam analitykom doskonalić warsztat pracy i rozwijać się, managerom układać procesy i rozwijać pracowników oraz przedsiębiorcom, aby rozwiązania IT wspierały ich działalność.

2 KOMENTARZE

  1. W świecie systemów „militarnych” od dziesięcioleci praktykuje się tzw. podejście COTS – Commercial of-the- shelf, czyli integracja rozwiązań z gotowych, dostępnych na rynku (fakt, dość specyficznym) komponentów. Z powodzeniem można je stosować również w świecie cywilnych rozwiązań IT. Nie ma żadnych przeciwwskazań. Należy tylko zmienić podejście: celem ma być rozwiązanie problemu biznesowego, a nie wyprodukowanie nowego oprogramowania, czego nie kochają nasi „kuzyni po fachu” – programiści. Świat nieuchronnie zmierza w tym kierunku, co powinno być dobrą wiadomością zarówno dla nas, analityków, bo wzrasta zapotrzebowanie na analizę integracji, jak i programistów, bo wzrasta zapotrzebowanie na nowe „gotowe” produkty , w tym XaaS. Era rozwiązań „kastomowych” powoli przemija, choć zawsze ostaną się nisze tak specyficzne, że bez „programistycznej złotej rączki” się nie obejdzie.
    Bardzo poręczną metodą rozstrzygnięcia kwestii „kupić+integrować” vs. „wyszydełkować” nowe oprogramowanie jest kalkulacja tzw. Total Cost of Ownership (TCO) planowanego rozwiązania, ale uwaga: ważnym jest, by kalkulacja była rzeczywiście „total” (na ile to praktycznie możliwe), w tym, z uwzględnieniem różnych ryzyk – np. kosztów awarii, konieczności reperacji/modyfikacji, braku dostępu do dokumentacji, pozyskania know-how, i innych – najlepiej w dłuższej perspektywie (3-5 lat). Często wtedy okazuje się, jak słuszna bywa stara mądrość, że „biednych nie stać na posiadanie rzeczy tanich” lub „co nagle to po diable”.

  2. Cóż za wnikliwa analiza zagadnienia, jestem pod wrażeniem : ) Aż dziw bierze, ile w sieci jest firm które posiadają strony bez dostępu do narzędzi administracyjnych oraz informacji kto takie uprawnienia posiada ; ) Zdaje się, że w większości to wynik, wyżej opisanych sytuacji..

ZOSTAW ODPOWIEDŹ