Typowe kłopoty z systemami IT

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ść. Nawet jeśli żadne z takich zdarzeń nie wystąpi, to sama świadomość, że może się pojawić, 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ż jedną kategorię, ale mimo to pogrupowanie ułatwia zrozumienie, z czym konkretnie w danym przypadku przychodzi nam się mierzyć.

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

Są takie systemy, które 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 pewną metodologię pracy pozwalającą na ich obejście. Nie zmienia to jednak 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ę. Zdarzają się nawet programy, których producenci już nie istnieją. Jeśli mamy szczęście, dostawcy 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? Należy też podkreślić, że programiści na rynku pracy wcale 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 od tej egzotyki. Często jest on głównym autorem systemu. W swoim czasie mógł on być zagorzałym entuzjastą tego rozwiązania. Niestety, odchodząc zabiera ze sobą całą wiedzę o działaniu systemu.

Systemy "rozgrzebane"

Specyficzną kategorię stanowią systemy "rozgrzebane", czyli takie, które zostały rozpoczęte, ale z jakiegoś powodu nie udało się ich ukończyć. Mogą to być zarówno systemy zlecone zewnętrznemu dostawcy lub też wytworzone przez własny zespół. W pierwszym przypadku, przy dobrze skonstruowanej umowie, problemem mogą być tylko opóźnienia. Ale nierzadkie są sytuacje, że system został częściowo lub nawet w całości opłacony, a uzyskanie zwrotu poniesionych kosztów może być bardzo trudne lub wręcz 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 w dłuższej perspektywie konieczne może być głębsze uporządkowanie (refactoring) 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 narzuca tylko jedną 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 tylko w teorii, a w praktyce "coś nie działa". 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, ale 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. Szef IT powoli czuje, że zaczyna mu się palić grunt 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 dzieje się w systemie. Nie ma osoby, która potrafiłaby w rozsądnym czasie ustalić, skąd wziął się dany objaw (błąd) oraz określić szybki i skuteczny sposób jego usunięcia.

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 uszczerbku 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ć lub 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 poświęci się sporego czasu na 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 tym, że niejednokrotnie niedoświadczeni programiści próbują 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 naprawa czasem 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 pierwszym krokiem do przywrócenia systemu do dobrego stanu jest jego przepisanie na nowszą technologię. W końcu stary (sprawnie działający) 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) korzystali z 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 dokładniejsza 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, która znacząco zwiększa ryzyko występowania 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.

Rozwiązanie - jakie mamy opcje

Po podjęciu decyzji o naprawie bądź przepisaniu kłopotliwego systemu, musimy zdecydować 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 pracownika.

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. Dodatkowo 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 nie działa. Decydując się na zatrudnienie specjalisty, trzeba zdawać sobie sprawę z problemu przed jakim stajemy. Prawdziwi profesjonaliści 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 trwać dość długo. Do tego szansa na znalezienie kogoś, kto opanował wymagany przez nas repertuar technologiczny w połączeniu z daną klasą systemów może być minimalna.

Dział HR czy też zewnętrzna pośrednicząca w procesie zatrudnienia firma rekruterska w przypadku specjalistów nie tylko ma bardzo ograniczone pole manewru, ale również 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 niespełniające wszystkich wymogów, a które trzeba później zweryfikować już z udziałem i przy sporym zaangażowaniu przedstawicieli działu technicznego.

Niestety wiadomo, ż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 rewelacyjnego CV miał trudności z podstawowymi zagadnieniami. Mógł być również technicznie 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. Dodatkowo zatrudnienie nieodpowiedniej osoby może rodzić masę problemów. 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. Czasem chciałoby się (choćby ze względów budżetowych) pozyskać specjalistę na krótszy kontrakt, a niestety nie każdy kandydat jest zainteresowany współpracą na krótkim kontrakcie.

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ą one na szybkie uzupełnienie zespołu o nowych programistów.

Usługa body leasingu i pośrednictwa HR 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ą kilka 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 możliwości stosowania tego źródła są mocno ograniczone.

Działanie zewnętrznym dostawcą

Czasem ze względów organizacyjnych, zwłaszcza w dużych firmach, łatwiej jest szefowi IT uzasadnić opłacenie faktury niż zatrudnienie kolejnego człowieka. Nie jest to jedyny powód, dla którego 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ę między sobą 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 to rozwiązanie 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ść łatwo 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

Czasem pod hasłem outsourcingu kryje się w istocie firma body leasingowa. Z tego powodu, aby wyróżnić się na rynku, niektóre firmy zaczęły promować termin "outsourcing kompetencyjny". 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ą pochwalić się 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ę, jednak można się 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 kierować zespołem, a także ustalać z klientem cele i sposoby ich realizacji. Nierzadko to właśnie kierownik będzie dobierał sobie współpracowników do danego projektu lub wymieniał ich w trakcie. W końcu nie na każdym etapie potrzebne są wszystkie dostępne w zespole kompetencje.

Właśnie płynna 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ą się natrafi niespodziankę.

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ą, podział obowiązków staje się niejasny oraz rośnie liczba nieporozumień i wzajemnych animozji w zespole.

Określanie problemu

Co zrobić, jeśli trudno jest ustalić jaki dokładnie problem jest do rozwiązania? Wbrew pozorom taka sytuacja nie zalicza się do rzadkości. 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 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 skupia się niniejszy artykuł, nie zawsze 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 za to 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 definiowania 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, ponieważ 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ć uwagę, szukając dostawcy?

I teraz przechodzimy do sedna. Nietrudno 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. 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ć wynik wyszukiwania od reklamy).

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 się nie zawiedziemy.

Jednakże warto zastanowić się nad tym, czy system lub problem, z którym aktualnie mierzymy się, faktycznie pasuje do profilu tak wyspecjalizowanej firmy? Czy taka 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, a 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 przy kłopotliwych systemach jest 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.

Popatrzmy 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. Musisz znaleźć 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 nadal pojawiają się problemy.

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 należy jeszcze wziąć 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 klientów to zazwyczaj za mało, bo nie informuje w ogóle o randze problemów, z którymi firma zmierzyła się. Tu pomocne mogą być zarówno referencje jak i success stories czy case studies.

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 swojej 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. 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 jakimi 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.

Rozmowa pozwoli Ci poznać potencjalnego dostawcę nie tylko poprzez stawianie pytań. Paradoksalnie o wiele istotniejsze powinno być, jakie pytania zostaną zadane Tobie. Czy rozmówca jest wnikliwy i pyta o szczegóły? Czy podnoszone przez niego kwestie świadczą o znajomości tematu, czy raczej o ignorancji? I przede wszystkim - czy czujesz, że możesz się z dostawą porozumieć? Naprawa problematycznego problemu to zwykle nie sprint, lecz maraton. To bardzo istotne, by mieć dory kontakt z dostawcą od samego początku.