Systemy informatyczne – nietypowe kłopoty

Kłopotliwe systemy informatyczne

Praktycznie każdy szef IT ma gdzieś z tyłu głowy niepokojącą myśl o jednym (lub kilku) problematycznym systemie informatycznym. Myśl ta na co dzień pozostaje w uśpieniu, ale niestety od czasu do czasu powraca, przywołana jakimś problemem, awarią lub kolejnym natarczywym pytaniem działu biznesowego o nową funkcjonalność. Ale nawet jeśli żadne z takich zdarzeń nie wystąpi, to sama świadomość, że pojawić się może, niejednokrotnie nie daje spać spokojnie.

Źródła i rodzaje kłopotliwych systemów

Kłopotliwe systemy informatyczne mają różne pochodzenie i różną naturę. Możemy jednak wyróżnić kilka najczęściej spotykanych grup. Podział nie jest ścisły i niektóre systemy wpadają w więcej niż jedna kategorię, ale mimo to pogrupowania ułatwia zrozumienie, z czym konkretnie w danym przypadku przychodzi się nam mierzyć.

Systemy, które nigdy nie działały dobrze

Są takie systemy. Najzwyczajniej w świecie nigdy nie działały do końca dobrze i stale sprawiają problemy. Może nawet do części wad niektórych użytkownicy zdążyli się już przyzwyczaić a nawet wypracować sobie metodologię pracy pozwalającą na ich obejście. Ale nie zmienia to faktu, że takie systemy potrafią zmrozić krew w żyłach pracownikom działów technicznych, którzy mają pewne wyobrażenie o tym, co może się dziać „pod maską”.

Systemy przestarzałe

Podobnie ma się sprawa z systemami starymi, które kiedyś działały bez zarzutu, ale od jakiegoś czasu szwankują. Niektóre operacje trwają coraz dłużej, czasem pojawiają się dziwne komunikaty o błędach, coraz częściej konieczne staje się resetowanie serwera. W normalnych okolicznościach tego typu problemami zająłby się dostawca. Ale w przypadku starych systemów dostawcy nie zawsze mają na to ochotę, a czasem nawet już nie istnieją. Jeśli mamy szczęście, godzą się odsprzedać czy nawet oddać za darmo kody źródłowe, ale co z tego, jeśli nawet z nimi nie udaje się uruchomić systemu? Albo jeśli postawiony ze źródeł system okazuje się znacząco różnić od wersji używanej na produkcji? A programiści na rynku pracy jakoś nie palą się do pracy z archaicznymi technologiami.

Systemy „egzotyczne”

Kolejną kategorię stanowią systemy napisane w technologiach „egzotycznych”. Tutaj również głównym problemem jest brak na rynku pracy specjalistów znających daną technologię, bez różnicy, czy mówimy o języku, platformie czy frameworku. Kłopoty pojawiają się na ogół wtedy, gdy odchodzi ostatni specjalista tej egzotyki. Często jest to głównym autorem systemu, który w swoim czasie był zagorzałym entuzjastą tego rozwiązania. Niestety odchodząc zabrał ze sobą cała wiedzę o działaniu tego systemu.

Systemy „rozgrzebane”

Specyficzną kategorię stanowią systemy „rozgrzebane”, czyli takie, które zostały rozpoczęte, ale z jakiegoś powodu nie udaje się ich ukończyć. Mogą to być zarówno systemy zlecone zewnętrznemu dostawcy lub też wytworzone zespołem własnym. W tym pierwszym przypadku, przy dobrze skonstruowanej umowie, problemem mogą być tylko opóźnienia, choć nierzadko system został częściowo lub nawet w całości opłacony, a uzyskanie zwrotu poniesionych kosztów może być bardzo trudne lub nawet niemożliwe. W przypadku systemu tworzonego własnymi siłami na szali często leży prestiż działu technicznego i jego szefa.

Do „rozgrzebania” systemu dochodzi w różnych okolicznościach, lecz najczęściej projekt można zaklasyfikować do jednej z poniższych grup:

  • Projekt okazał się zbyt trudny technicznie (w skrajnych przypadkach postawione cele mogą być w ogóle niemożliwe do osiągnięcia), przy czym trudność polega na rozwiązaniu skomplikowanego problemu lub też na odpowiednim doborze i implementacji algorytmów obliczeniowych. Zwykle głównym problemem jest niewydolność (powolne działanie) systemu. Poprawienie wydajności wymaga specjalistycznych umiejętności, pozwalających zlokalizować wąskie gardła systemu oraz oszacować złożoność i ewentualnie zoptymalizować zastosowane algorytmy.
  • Projekt jest obszerny, to znaczy ma bardzo dużą bazę kodu, którą trudno w całości ogarnąć jednej osobie. Przy złych założeniach projektowych skutkować to może sporymi problemami w modyfikacjach i rozbudowie. Na przykład dość często okazuje się, iż wprowadzenie jednej drobnej zmiany w jednym z modułów systemu skutkuje błędami lub nieoczekiwanym działaniem innych modułów. Szukanie błędów w tej sytuacji bywa bardzo trudne i często wymusza głębsze uporządkowanie kodu projektu.
  • Projekt wchodzi w obszary wykraczające poza kompetencje technologiczne zespołu programistycznego. Zwykle ma to miejsce, gdy pojawia się konieczność takiej czy innej formy wymiany danych czy szeroko pojętej integracji z innym systemem informatycznym. Jeśli zewnętrzny system tylko narzuca jaką technologię rozwiązania, to nawet jeśli nie jest ona w zespole znana, problem jeszcze nie jest duży. Prawdziwe schody zaczynają się gdy integracja jest obsługiwana przez zewnętrzny system w teorii. Do tego dochodzi nieaktualna dokumentacja (lub jej całkowity brak) i ograniczone możliwości wyegzekwowania jej od dostawcy.
  • Osobnym, dość szczególnym wariantem „rozgrzebania” systemu są opóźnienia prowadzące do braku możliwości ukończenia systemu zgodnie z przyjętym planem. Może to wynikać z błędnego oszacowania czasu realizacji, ale również z „niespodzianek”, na jakie można się natknąć na każdym etapie prowadzenia projektu programistycznego. Należą do nich nie tylko niedoszacowania czasochłonności, również nie do końca uzgodniona z klientem specyfikacja bądź zwyczajnie duża trudność tematu. W przeciwieństwie do sytuacji wcześniej opisanych zespół może doprowadzić do zakończenia projektu, lecz niestety wiadomo już, że bez dodatkowego wsparcia zostaną przekroczone założone terminy.

Niebezpieczeństwa

Jak wspomnieliśmy na wstępie, kłopotliwy system wisi nad szefem IT jak miecz Damoklesa. W każdej chwili może przestać działać prawidłowo lub nawet w ogóle. Do tego użytkownicy, obserwując drobne problemy czy nieprawidłowości, zaczynają wątpić w poprawność funkcjonowania programu, zwłaszcza gdy zwracane przez niego wyniki różnią się od ich oczekiwań. Pojawiają się naciski ze strony działów biznesowych, ale problem nie znika. IT powoli czuje, że grunt powoli zaczyna się palić pod nogami.

W przypadku praktycznie każdego kłopotliwego systemu najbardziej bazowym źródłem kłopotów jest brak (teraz lub na etapie jego projektowania lub tworzenia) dostatecznie kompetentnej osoby. Jest to sytuacja, wysoce niekomfortowa, gdy nie ma w zespole nikogo, o kim z pełnym przekonaniem można by powiedzieć, że wie, co i dlaczego się w systemie dzieje. Nie ma nikogo, kto potrafiłby w rozsądnym czasie ustalić, skąd się wziął dany objaw (błąd) ani określić, jak go skutecznie (i szybko) usunąć.

W takiej sytuacji system z czasem przestaje odpowiadać na zmieniające się uwarunkowania biznesowe i organizacyjne. Jeśli mówimy o systemie wewnętrznym. Bo niestety gorzej jest, gdy problem dotyczy systemu realizowanego dla zewnętrznego klienta. Opóźnienia w realizacji nierzadko niosą wówczas ze sobą konsekwencje w postaci kar umownych oraz uszczerbek na prestiżu. O kosztach wynikających z przedłużonej realizacji nawet nie wspominając.

Zmienić, naprawić, a może porzucić?

Ok, mamy problematyczny system, wiemy co to oznacza i na co może nas narazić. Zanim zaczniemy rozwiązywać problem, przeanalizujmy pokrótce możliwe kierunki działania. Otóż kłopotliwy system możemy:

  • naprawić,
  • zastąpić,
  • przepisać,
  • porzucić,
  • zignorować.

Naprawa

Naprawa może oznaczać bardzo różne rzeczy, w zależności od natury problemu. Może to być poprawienie implementacji, zmiana konfiguracyjna, optymalizacja nieefektywnych algorytmów albo też ukończenie „rozgrzebanego” projektu. Zazwyczaj oznacza pewne nakłady inwestycyjne, przy czym w przypadku kłopotliwych systemów często nie da się a priori określić, jak będą one duże, przynajmniej dopóki nie zainwestuje się sporego nakładu czasu w diagnostykę. Nierzadko cała procedura wygląda tak, że 90% czasu zajmuje szukanie błędu, a 10% jego usunięcie. Jest to kierunek najczęściej praktykowany, zwykle nie bez racji.

Przepisanie systemu

Pewnie niejednokrotnie spotkaliście się z opinią, że system łatwiej napisać od początku niż uratować. W istocie częstą praktyką jest utworzenie nowego systemu, który zastępuje ten problematyczny. Zazwyczaj wiąże się to ze zmianą technologii użytej do implementacji.

W zależności od sytuacji może to być mniej lub bardziej korzystne rozwiązanie. Jeśli system jest utworzony we współcześnie szeroko stosowanej technologii, zwykle jego przepisywanie nie ma większego sensu (za wyjątkiem systemów wyjątkowo źle zaprojektowanych). W przypadku starych lub niszowych technologii warto przeprowadzić rachunek zysków i strat, poprzedzony zbadaniem problemów i oszacowaniem kosztów ich naprawy.

Należy w tym miejscu ostrzec przed, że niejednokrotnie niedoświadczeni programiści próbują przykładowo poprawić efektywność programów poprzez zmianę technologii, nie badając uprzednio źródeł niewydajności. Nowy, jakoby szybszy, język programowania czy „nowocześniejsza super wydajna biblioteka” na niewiele się zda, jeśli rzeczywisty problem z wydajnością nie został prawidłowo zdiagnozowany. Nierzadko bowiem okazuje się, że dobry specjalista jest w stanie szybko i przy niewielkich kosztach naprawić system, niewiele w nim zmieniając.

Z drugiej strony czasem naprawa jedynie odsuwa rzeczywisty problem na później, bo w dłuższej perspektywie problemy z brakiem specjalistów od danej technologii dadzą o sobie znać. Dlatego w pewnych sytuacjach przywrócenie systemu do dobrego stanu jest pierwszym krokiem jego przepisania na nowszą technologię. W końcu stary (sprawnie działając) system jest najlepszą możliwą formą specyfikacji.

Porzucenie

Z żadnego systemu nie rezygnuje się łatwo. Wszak porzucenie świadczy o podjętych w przeszłości błędnych decyzjach lub o bezradności wobec aktualnych problemów. Jednakże warto w analizie możliwości uwzględnić także ten scenariusz.

W swojej praktyce nierzadko mieliśmy do czynienia z systemami, których wdrożenie nie było poprzedzone rzetelną analizą potrzeb. Często także nie było podyktowane pragmatyką. Czasem „góra” podejmowała decyzję o „unowocześnieniu”, które w danym przypadku dla pewnych firmowych procesów było całkowicie zbędne. Kończyło się to tak, że pracownicy niechętnie (lub wcale) używali systemu, który nie spełniał swej funkcji.

Co więcej, w takich przypadkach system może poprawnie działać, ale i tak będzie postrzegany jako źle działający lub niepoprawnie wykonany, bo w końcu nie przynosi oczekiwanych efektów. Dopiero uważniejsza analiza procesów firmowych pozwala ujawnić, że system nie tylko nie pomaga, ale czasem wręcz przeszkadza pracownikom.

Zwykle potrzeba nieco czasu, aby decydenci dojrzeli do decyzji o porzuceniu takiego rozwiązania. Pomaga w tym świadomość, że sztuczne utrzymywanie przy życiu nietrafionego pomysłu wiąże się ze stałymi kosztami.

Zignorowanie problemu

Ostatnim z możliwych kierunków, który niczego nie wymaga, bo „dzieje się sam”, jest ignorowanie problemu. Nie musimy chyba wyjaśniać, iż jest to najgorsza możliwa decyzja, znacząco zwiększająca ryzyko problemów. Czasem dość znacznych. Jeśli z jakiegoś powodu nie jesteśmy w stanie podjąć decyzji o dalszym postępowaniu z systemem, warto zasięgnąć opinii u specjalisty, który to ułatwi.

Rozwiązanie – jakie mamy opcje

Jeśli zapadła już decyzja o naprawie bądź przepisaniu kłopotliwego systemu, musimy zdecydować również o sposobie działania. Zasadniczo mamy do wyboru dwie możliwości, każda z zestawem wariantów:

  • działanie własnym zespołem,
  • działanie zewnętrznym dostawcą.

Działanie własnym zespołem

W przypadku notorycznych kłopotów z systemem informatycznym pierwszym odruchem kierowników jest zwykle myśl „znajdźmy od tego człowieka/ludzi”. Często oznacza to zatrudnienie nowego człowieka.

Zatrudnienie

Na ogół proces zatrudniania zaczyna się od określenia, kogo chcielibyśmy pozyskać. W przypadku kłopotliwych systemów na ogół myślenie idzie według schematu „mamy problem z systemem napisanym w technologii X, musimy zatem znaleźć seniora z doświadczeniem w tej technologii”. Do tego zwykle pojawiają się mniej lub bardziej krytyczne parametry  związane z doświadczeniem ze stosowanymi w firmie narzędziami programistycznymi, metodologią zarządzania projektami itp. Do tego mile widziane jest doświadczenie w systemach klasy K, gdzie K oznacza system, z którym mamy problem.

Cóż, nie byłoby to złe podejście, jednakże zazwyczaj ono nie chce działać. Decydując się na zatrudnienie specjalisty, trzeba zdawać sobie sprawę z problemu, przed jakim stajemy. Prawdziwi spece nie są łatwo dostępni na rynku pracy, do tego często są kapryśni i mają wielkie oczekiwania względem pracodawców. Sam proces znalezienia potencjalnie dobrego pracownika może dość długo trwać. Do tego szansa na znalezienie kogoś, kto opanował wymagany przez nas repertuar technologiczny w połączeniu z daną klasą systemów może być marginalna.

Dział HR czy też zewnętrzna pośrednicząca w procesie zatrudnienia firma rekruterska w przypadku specjalistów nie tylko ma ograniczone bardzo pole manewru. Rekruter często nie jest w stanie zrozumieć, jaka jest rzeczywista potrzeba działu technicznego. Skutkuje to tym, że przez wstępną selekcję kadrowców przechodzą często osoby nie rzeczywistych spełniające wymogów, a które trzeba później zweryfikować już z udziałem i przy sporym zaangażowaniu przedstawicieli działu technicznego.

Niestety że rzeczywiste umiejętności i kompetencje nowo zatrudnionego pracownika weryfikują się dopiero po pewnym czasie pracy. Zapewne każdy szef IT miał doświadczenia ze świetnie zapowiadającym się kandydatem, który pomimo świetnego CV miał trudności z podstawowymi zagadnieniami. Albo technicznie był rewelacyjny, jednakże z takiego czy innego powodu współpraca z nim kompletnie się nie układała.

Zatrudnienie nowego człowieka bywa świetnym rozwiązaniem, lecz niestety sam proces szukania odpowiedniego specjalisty i weryfikacja jego umiejętności może zająć dużo cennego czasu. Do tego zatrudnienie nieodpowiedniej osoby może rodzić masę problemów. A nawet jeśli mieliśmy szczęście i znaleźliśmy „perełkę”, to takiego pracownika trzeba jeszcze w firmie zatrzymać, co nie zawsze jest proste. No i czasem chciałoby się (choćby ze względów budżetowych) specjalistę na krótszy kontrakt, a nie każdy kandydat jest zainteresowany współpracą na krótką metę.

Pośrednicy (HR i body leasing)

Niszę rynkową generowaną przez wyżej opisane problemy zagospodarowują firmy body leasingowe i pośrednictwa HR, które w ostatnich latach wyrastają jak grzyby po deszczu. Pozwalają na szybkie uzupełnienie zespołu o nowych programistów.

Ich usługa jest w gruncie rzeczy dość podobna – mają bogaty wybór ludzi na różnym poziomie i z różnym doświadczeniem. Różnica polega na tym, że pracownik pozyskany przez agencję body leasingu formalnie jest w niej zatrudniony, a rozliczany jest z czasu przepracowanego na rzecz klienta. Pośrednicy nie zawsze rozwiązują problem ze znalezieniem odpowiedniego człowieka, często wręcz zrzucając odpowiedzialność za wybór i weryfikację kandydatów na klienta.

Niemniej jednak firmy body leasingowe oferują kila korzyści, takich jak łatwiejsza rezygnacja z danego człowieka czy (przynajmniej teoretycznie) możliwość szybkiego uzyskania zastępstwa czy łatwość kontraktowania na krótki czas.

Praktyka pokazuje, że pośrednictwo najlepiej sprawdza się jako źródło pracowników z małym i średnim doświadczeniem (poziom junior i middle), kiedy bardziej od doświadczenia liczy się liczba rąk na pokładzie. Niestety kadrowcy w firmach HR i body-leasingowych mają takie same problemy z pozyskaniem wysokiej klasy specjalistów jak wszyscy inni. Stąd też w przypadku kłopotliwych systemów zastosowanie tego źródła jest mocno ograniczone.

Działanie zewnętrznym dostawcą

Czasem ze względów organizacyjnych, zwłaszcza w dużych firmach, łatwiej szefowi IT łatwiej jest uzasadnić opłacenie faktury niż zatrudnienie kolejnego człowieka. Ale to tylko jeden z powodów, dla których warto sięgnąć po zewnętrznego dostawcę usług programistycznych. Ważny jest również biznesowy charakter współpracy, po którym oczekiwać można większej elastyczności niż w przypadku zatrudnienia, nierzadko korzystniejszych warunków i oczywiście wyższego profesjonalizmu.

Na rynku jest mnóstwo firm działających w branży IT. Ich oferta i model działania często skrajnie się różnią. Jak spośród nich wybrać tę właściwą, która pomoże rozwiązać problemy? Jest kilka kwestii, na które należy zwrócić szczególną uwagę. Omówmy zatem dostępne opcje.

Outsourcing programistyczny

Częstym sposobem zaspokojenia potrzeb na prace programistyczne jest outsourcing. W klasycznym wydaniu polega on na zleceniu realizacji prac zewnętrznej firmie. Zwykle dostawca zapewnia nie tylko siłę roboczą w postaci zespołu programistów, lecz również zajmuje się kierowaniem projektem. Projekty zazwyczaj realizowane są w ramach z góry ustalonego zakresu za ustaloną z góry stawkę.

Tego rodzaju usługa świetnie sprawdza się przy takich projektach, przy których dość łatwo jest określić, jaka praca jest do wykonania, w szczególności przy rozwiązaniach tworzonych od zera. Niestety w sytuacji, gdy już mamy system, który sprawia problemy, zwykle się nie sprawdza. Wynika to oczywiście z faktu, że zakres prac do przeprowadzenia na ogół jest w tym przypadku nieoczywisty, a dużą część prac zajmuje właśnie diagnostyka.

Handlarze CV

W tym punkcie chcemy jeszcze zwrócić uwagę, iż ł szukając dostawcy outsourcingu dość łato trafić na firmy chwalące się setkami czy nawet tysiącami programistów dostępnych od ręki. Niestety tego typu dostawcy zazwyczaj są jedynie „handlarzami CV”, świadczącymi usługę, która jest dokładnie tym samym, co omówiony wcześniej body leasing. Dysponują dużą bazą ludzi, o których w zasadzie nic nie wiedzą, lub których kompetencje sprawdzili jedynie pobieżnym testem. W gruncie rzeczy nie biorą na siebie żadnej odpowiedzialności, bo klient sam sobie wybiera programistów.

Outsourcing kompetencyjny

Między innymi z powodu konieczności odróżnienia się od body leasingu zawoalowanego pod hasłem outsourcingu stosunkowo niedawno zaczął się wybijać termin outsourcingu kompetencyjnego. Słowo „kompetencyjny” ma w przypadku tej usługi kluczowe znaczenie. Mimo że model rozliczeń jest taki sam jak w body leasingu, to inna jest oferta i model działania. W pewnym uproszczeniu można powiedzieć, że zwykle body leasing idzie w ilość programistów w ofercie, natomiast outsourcing kompetencyjny stawia na jakość.

Dostawcy outsourcingu kompetencyjnego mają zazwyczaj mniej ludzi, ale za to o wyższych kwalifikacjach. Nierzadko są to wysokiej klasy specjaliści, którzy przeszli przez wiele projektów i mogą się pochwalić bogatym doświadczeniem. Z założenia mają się sprawdzić tam, gdzie nie sprawdzą się ludzie z typowej oferty body leasingowej.

Outsourcing kompetencyjny może być dość dobrym (czasem nawet najlepszym) rozwiązaniem w przypadku naprawdę trudnych projektów, zwłaszcza jeśli wziąć pod uwagę możliwość rozliczania godzinowego. Dzięki tej usłudze możemy dostać „komandosa”, którego zrzucamy w sam środek projektu z określonym celem. Jeśli tylko znajdziemy odpowiedniego człowieka do naszego zadania, możemy zakładać, że cel ten zostanie osiągnięty.

Team leasing

Rozwinięciem koncepcji outsourcingu kompetencyjnego i body leasingu jest team leasing, czyli udostępnianie klientowi całych zespołów programistycznych. Różni dostawcy różnie rozumieją tę usługę, można się jednak po niej spodziewać czegoś więcej niż tylko body leasingu grupy programistów. Musi wśród nich być również ktoś o kompetencjach kierowniczych.

Osoba kierownika jest kluczowa w team leasingu. To właśnie on będzie odpowiadał za realizację prac, będzie pokierować zespołem a także ustalać z klientem cele i sposoby ich realizacji. Nierzadko również to kierownik będzie dobierał sobie współpracowników do danego projektu lub wymieniał ich w trakcie. W końcu nie na każdym etapie projektu potrzebne są wszystkie dostępne w zespole kompetencje.

Właśnie płynnego możliwość dostosowywania składu zespołu do pojawiających się w projekcie potrzeb stanowi największą siłę tej usługi. Jest to szczególnie istotne w przypadku kłopotliwych systemów, w których nie zawsze wiadomo, na jaką niespodziankę się trafi.

Specyfika trudnych problemów programistycznych

Omówiliśmy już dostępne na rynku usługi programistyczne i ich przydatność przy kłopotliwych systemach. Warto teraz zwrócić uwagę na kilka istotnych aspektów związanych z rozwiązywaniem trudnych problemów programistycznych.

Powiększanie zespołu

Przede wszystkim nie zawsze powiększanie zespołu programistycznego prowadzi do oczekiwanych efektów. Niestety praktyka pokazuje, że im większy zespół programistyczny, tym… wolniejszy postęp prac. Pojawia się coraz więcej problemów z komunikacją, niejasny staje się podział obowiązków, rośnie liczba nieporozumień i wzajemnych animozji w zespole.

Określanie problemu

A co, jeśli trudno jest ustalić jaki dokładnie problem jest do rozwiązania? Wbrew pozorom nie jest to sytuacja rzadka. Rozbudowane systemy, korzystające z wielu technologii są trudne do ogarnięcia umysłem, a czasem wyjątkowo oporne, jeśli chodzi o debugowanie. Jak wtedy szukać rozwiązania, jeśli nie mamy nikogo, kto mógłby określić problem? Właściwe zdefiniowanie problemu bywa najtrudniejszym elementem jego rozwiązania.

Określanie potrzeb

Dodatkowo w przypadku kłopotliwych systemów, na których się skupia się niniejszy artykuł, nie zawsze nie wiadomo, jaki właściwie specjalista może nam pomóc. Odruchowe „potrzebujemy seniora od technologii X” niestety nie zawsze działa.

Zdarzało nam się trafiać do klientów, którzy całkiem błędnie określali swoje potrzeby. Szukali czegoś zupełnie innego, niż w rzeczywistości potrzebowali. Trudno ich winić. Charakterystyczne jest, że rynek nie definiuje jasno usługi rozwiązywania trudnych problemów informatycznych czy naprawiania kłopotliwych systemów. Szukający rozwiązania często nie wiedzą, co wpisać w wyszukiwarkę, aby choćby trochę zbliżyć się do znalezienia właściwej oferty.

To nie technologia rozwiązuje problemy

Jednym z elementów niewłaściwego określania potrzeb jest określenie technologii rozwiązania. Bierze się to z dość powszechnego lecz naiwnego przekonania, że to technologia rozwiązuje problemy informatyczne. Nic bardziej błędnego. To zawsze człowiek rozwiązuje problemy. Nawet najnowocześniejszy język programowania czy framework nie pomoże, jeśli znajdzie się w rękach nieumiejętnego programisty.

Na co zwrócić, szukając dostawcy?

I teraz przechodzimy do sedna. Nie trudno się domyślić, iż będąc dostawcą usług team leasingu i outsourcingu kompetencyjnego, będziemy kierować Twoją uwagę w tym kierunku. Jeśli faktycznie mierzysz się z kłopotliwym systemem i dobrnąłeś do tego akapitu, jest duża szansa, że zgodzisz się, iż jest to właściwy kierunek. Ale tylko pod warunkiem znalezienia kompetentnego dostawcy.

Jak znaleźć dostawcę na własne potrzeby?

Jak już zostało to wspomniane wcześniej, znalezienie dostawcy specjalizującego się w kłopotliwych systemach może być bardzo trudne. Wpisywanie w wyszukiwarkę haseł typu „outsourcing kompetencyjny” czy „software house” na ogół powoduje, że toniemy w wynikach (i reklamach) firm dostarczających nie takie usługi, jakich szukamy. Zapewne znajdziemy też dostawców, którzy będą twierdzić, że mają rozwiązanie na każdy nasz problem. I zapewne część z nich będzie miała rację. Ale jeśli wybierzemy źle, narazimy się na koszty i opóźnienia. Należy zatem wybierać mądrze. Na co zwrócić największą uwagę?

Aktualnie pierwszym i często najlepszym sposobem wstępnej weryfikacji potencjalnego dostawcy jest jego strona internetowa. Można na niej znaleźć wiele użytecznych informacji. Dostawcy chwalą się referencjami, technologiami, w których pracują, modelem prowadzenia projektów itd. Zachowując odpowiednią dozę rezerwy można również przyjąć, że najlepsi dostawcy pojawiają się najwyżej w wynikach wyszukiwarek (przy czym warto rozróżnić między wynikiem wyszukiwania a reklamą).

W naszej opinii najcenniejsze z praktycznego punktu widzenia są dwie kategorie informacji: technologie, w których działa dostawca oraz jego doświadczenie.

Wszechstronność czy specjalizacja?

Większość firm informatycznych dość jasno określa, w jakich technologiach (lub stackach technologicznych) pracuje. Często jest to bardzo konkretny zestaw, nierzadko poparty certyfikatami czy tytułami oficjalnego partnerstwa. Po takiej firmie można się spodziewać perfekcyjnego opanowania danej technologii i zwykle na takim przekonaniu nie zawiedziemy się.

Jednakże warto się zastanowić, czy system lub problem, z którym się aktualnie mierzymy, faktycznie pasuje do profilu tak wyspecjalizowanej firmy? Czy taka jednak specjalizacja nie będzie zbyt ograniczająca? Czy dostawca działający stale w danej technologii nie będzie automatycznie poszukiwał rozwiązań właśnie w niej, samodzielnie zawężając sobie przestrzeń możliwych rozwiązań?

Technologiczna wszechstronność idzie (przynajmniej w teorii) w parze z większą elastycznością myślenia o problemach i możliwościach ich rozwiązywania. Po dostawcy działającym w wielu kierunkach można oczekiwać, że będzie dostosowywał rozwiązanie do problemu, nie problem do rozwiązania.

Czy jednak z drugiej strony brak specjalizacji nie oznacza powierzchownej znajomości technologii? Owszem, może (lecz nie musi!) tak być.

Wbrew obiegowej opinii znajomość konkretnej technologii jest przy kłopotliwych systemach drugorzędna. W zdecydowanej większości problematycznych projektów największa trudność tkwi nie w braku znajomości składni języka czy konkretnej biblioteki.

Popatrzy na to z tej strony: czy łatwiej jest wejść w chaotycznie napisany i nieudokumentowany projekt czy też w dobrze opisaną i świetnie udokumentowaną technologię? No właśnie. Kogoś takiego szukasz. Kogoś, kto zna wiele technologii, ale może bez problemów wejść w nową, jeśli to będzie konieczne. Specjalistów od technologii X na rynku (a może i w firmie) masz dużo, a mimo to problemy dalej są nierozwiązane.

Ok, wiemy już, że warto wybierać spośród „wielotechnologicznych” dostawców. Jak zatem do tego podejść? Można przypuszczać, że nie każdy dostawca spełniający to kryterium będzie dobry w rozwiązywaniu nieszablonowych problemów. Co zatem jeszcze brać pod uwagę, kierując się wyborem?

Doświadczenie i referencje

Właściwie jedynym rozsądnym kryterium jest doświadczenie. Warto zatem zwrócić uwagę na listę klientów potencjalnego dostawcy. Większość z nich chwali się nimi na stronie.

Oczywiście sama lista dostawców to zazwyczaj za mało, bo nie informuje w ogóle o randze problemów, z którymi firma się mierzyła. Tu z pomocą przyjść mogą być zarówno referencje jak i success stories.

Niekoniecznie chodzi o to, by znaleźć dostawcę, który mierzył się z identycznym problemem jak nasz. Czasem to zresztą w ogóle niemożliwe. Lepszym podejściem jest znalezienie dostawcy, który w swej działalności zmierzył się z wieloma różnorodnymi problemami. Można się po nim spodziewać szerokich horyzontów i dużych kompetencji w rozwiązywaniu nietypowych problemów. Jeśli wśród technologii lub projektów pojawiają się takie, które można by nazwać nietypowymi lub nawet egzotycznymi, tym lepiej.

Należy przy tym pamiętać, że ze strony nie dowiemy się wszystkiego. Klienci często wymagają od dostawcy zachowania poufności. A nawet jeśli takich zapisów nie ma w umowie, to czasem jest kwestią etyki i dobrych praktyk biznesowych, by nie ogłaszać publicznie, z jakim problemami mierzył się klient. Nawet jeśli success story przedstawia anonimową firmę, często uważny czytelnik może odkryć, o kogo chodzi.

Rozmowa

Zdecydowanie najpewniejszym sposobem weryfikacji potencjalnego dostawcy jest rozmowa telefoniczna, a jeszcze lepiej osobiste spotkanie. Co więcej, powinno się ono skupiać na Twoim kłopotliwym systemie. Dobry dostawca z bogatym doświadczeniem z pewnością sam wskaże na podobne problemy, z którymi przyszło mu się mierzyć w przeszłości. Jeśli część z nich będzie dotyczyć „wyprowadzania na prostą” problematycznych projektów programistycznych, to możemy być praktycznie pewni, że dobrze trafiliśmy.

O nas

Na koniec pozwolę sobie na kilka słów o ImpiCode. Naszą największą siłą jest doświadczenie we wchodzeniu w już istniejące projekty i rozwiązywanie nietypowych problemów. Mamy ekspertów od rozmaitych technologii, rozwiązaliśmy wiele nietypowych problemów. Naszą domeną jest ratowanie kłopotliwych systemów, wyprowadzanie ich na prostą i obejmowanie ich długoterminową opieką, aby już więcej nie sprawiały problemów.

Pomagamy na wielu polach:
+ przeprowadzamy optymalizacje nieefektywnych systemów,
+ naprawiamy usterki i usuwamy awarie,
+ robimy integracje,
+ świadczymy SLA dla systemów innych dostawców.
+ przepisujemy stare systemy na nowsze technologie,
+ pomagamy przejąć projekty i kody źródłowe od innych dostawców.

Jeśli masz właśnie na głowie kłopotliwy system, zadzwoń. Sprawdzimy, jak możemy Ci pomóc.

Dodaj komentarz

Twój adres email nie zostanie opublikowany. Pola, których wypełnienie jest wymagane, są oznaczone symbolem *