Depresje programisty CRM

Dynamics CRM, Różne takie

Do napisania tego tekstu skłoniła mnie dyskusja z jednym z moich młodszych kolegów, zajmujących się (podobnie jak niżej podpisany) tworzeniem rozwiązań opartych o platformę Dynamics CRM. Rozmowa ta wynikła z poczucia rozczarowania, które mój rozmówca odczuwał z w związku ze swoimi zadaniami w pracy. Wyżej wymienione odczucie najlepiej odda następujący cytat: „Wszyscy wokół [czyt. koledzy-programiści] zajmują się ciekawymi rzeczami, a ja napierd[auto-cenzura] kolejne pluginy…” (tekst cytuję z pamięci, więc jest on na pewno częściowo przekręcony). Wniosek z tej rozmowy był taki, że developerem CRM jest być kiepsko. Jest to praca nudna i dająca niewielkie możliwości wykazania się, w przeciwieństwie do developerów „customowych” aplikacji (którymi to w domyśle jest być świetnie :)).

Jako programista i architekt rozwiązań opartych o platformę Dynamics CRM pracuję już prawie 10 lat. W tym czasie miałem przyjemność poznać wielu interesujących ludzi zajmujących się programowaniem i rozbudowywaniem funkcjonalności omawianego systemu. Podeście do tworzenia aplikacji XRM można podsumować jednym zdaniem: „Ile osób, tyle opinii” :O. Po jednej stronie barykady stoją programistyczni puryści, którzy nie widzą różnicy pomiędzy tworzeniem kodu aplikacji XRM a jakiegokolwiek innego kodu (czyli wszystkie standardy, metodyki i powszechnie znane dobre praktyki powinny być wg. nich zachowywane). Po drugiej stronie panuje natomiast przekonanie, że ponieważ CRM jest gotową aplikacją, jego rozbudowa ma być przede wszystkim szybka i – o ile tworzony kod jakoś się uruchamia i działa – wszystko jest w najlepszym porządku. Dla tej strony wszystko, co nie przekłada się w bezpośredni sposób na dostarczenie określonej funkcjonalności, jest tylko developerską fanaberią.

Osoby, które zajmują się CRM-em od strony funkcjonalnej, od kilku lat są mocno dopieszczane przez producenta systemu i „jadą” na fali nieprzerwanego entuzjazmu. Microsoft stale rozbudowuje swój produkt, dodaje do niego nowe funkcjonalności oraz narzędzia pozwalające na ich modyfikacje. Z punktu widzenia developera sytuacja może wyglądać jednak nieco inaczej. W ostatnich latach Redmontowo zaniedbało rozwój narzędzi programistycznych oraz mechanizmów, za pomocą których możemy rozszerzać możliwości systemu. Pisałem już o tym na blogu w tekstach: „Goodbye (Dynamics) XRM?” oraz „Goodbye (Dynamics) XRM? Epilog”.

Każdy developer chciałby tymczasem:

  • Budować rozwiązania z wykorzystaniem najlepszych dostępnych praktyk oraz narzędzi.
  • Mieć możliwość ciągłej nauki i zwiększania swojego „skilla”.

Co się wiąże z powyższym? Moim skromnym zdaniem praca przy wdrożeniach Dynamics CRM w roli developera może dać nam możliwość 100-procentowego spełnienia ww. oczekiwań. Wszystko zależy oczywiście od tego jak pewne kwestie w projekcie, w którym uczestniczymy, zostaną zaplanowane i zorganizowane, a także od tego, czy będziemy umieli uargumentować konieczność wdrożenia pewnych praktyk i narzędzi. Praktyki te z punktu widzenia tzw. „biznesu” mogą wydawać się mocno kosztowne i niewnoszące wartości dodatniej. Pamiętajmy jednak o tym, że osoby z działów sprzedaży rzadko kiedy wybiegają myślami w przyszłość dalej, niż do końca roku fiskalnego (niestety…). Tymczasem cykl życia systemu, który implementujemy, będzie z całą pewnością dłuższy.

Oczywiście może się również zdarzyć, że trafimy na toczący się projekt, na którym naszym jedynym zadaniem będzie dostarczanie i rejestrowanie w systemie kolejnych bibliotek .NET i JavaScript. Nie jest to jednak problem platformy tylko samego projektu, na którym z różnych przyczyn nie zrealizujemy naszych programistycznych oczekiwań. Mimo wszystko, nawet opisana powyżej sytuacja nie uniemożliwia nam pisania kodu z wykorzystaniem najlepszych standardów, wzorców projektowych, czy metodyk testowania kodu.

Każdy developer ma z pewnością pewne wyobrażenie swojego idealnego projektu. W projekcie tym zaimplementowana i wdrożona zostanie przemyślana, wielowarstwowa architektura. Kod będzie wykorzystywał powszechnie znane wzorce projektowe, np. repozytoria, wstrzykiwanie zależności, fabryki, itp… Całość tworzonego rozwiązania będzie oczywiście w pełni testowalna za pomocą testów jednostkowych i integracyjnych. Platforma Dynamics CRM/XRM (a mam tu na myśli przede wszystkim tworzone dla niej biblioteki .NET i JS) w żaden sposób nie blokuje nam możliwości implementacji wszystkich wymienionych powyżej technik. Szczerze mówiąc, w przypadkach, w których liczba pluginów, procesów worflow, czy też własnych akcji w projekcie jest większa niż mityczne „kilka”, nie bardzo widzę inną możliwość niż stosowanie omawianych powyżej praktyk. W innym przypadku kod przybierze szybko postać potwora spaghetti a sama aplikacja stanie się niezwykle trudna w utrzymaniu.

Z innej beczki…

Co w przypadku, gdy jesteśmy specjalistami od back-endu oraz integracji systemowej? Z całą pewnością w czasie wdrożenia CRM wykorzystamy w 100% nasze umiejętności.

Jeżeli natomiast specjalizujemy się w elementach front-end i frameworkach JavaScipt? Doskonale się składa, ponieważ mechanizm zasobów sieciowych CRM umożliwia nam tworzenie nowoczesnych komponentów za pomocą Silverlight (dawniej) lub HTML5/JavaScript.

Budujemy portale internetowe lub systemy CMS? Hasło „portal dla klientów” pojawia się na co drugim wdrożeniu CRM.

Tworzymy nałogowo usługi sieciowe (web services)? Praktycznie każde wdrożenie CRM związane jest z budową fasady, opartej właśnie na tej technologii. Trafiają się również projekty, gdzie przy okazji wdrożenia CRM tworzona jest cała szyna danych albo silnik procesów.

Jesteśmy specjalistami od tworzenia aplikacji mobilnych? Również możemy wykorzystać naszą wiedzę na wdrożeniu CRM (chociaż własny, tworzony od zera klient mobilny nie trafia się niestety równie często jak portal :().

Tworzymy aplikację typu desktop-client? Okazje tego typu również trafiają się przy okazji wdrożeń MS CRM. Przykładem mogą być aplikacje typu Desktop Agent dla centrów obsługi telefonicznej lub interfejsy użytkownika dla wszelkich niestandardowych komponentów integracyjnych.

To, jakie prace będziemy wykonywać, zależy w rzeczywistości od konkretnego projektu, w którym przyjdzie nam uczestniczyć. Uważam również, że praca developera w firmie zajmującej się wdrożeniami CRM, z uwagi na multum wymienionych powyżej możliwości, może być o wiele ciekawsza niż trzaskanie projektów WWW, z których każdy oparty jest na tym samym frameworku lub CMS’ie.

iDV0L5lo_400x400Oczywiście, swoisty syndrom wypalenia i zniechęcenia może być jak najbardziej uzasadniony. Wyobraźmy sobie sytuację, w której przychodzimy do nowej firmy i trafiamy na projekt wdrożenia CRM, w którym nigdy nie były zachowywane żadne standardy pracy. Kod jest bałaganiarski, stworzony bez jakiegokolwiek „pomyślunku” i architektury (typowy przykład: cała logika aplikacji zaszyta w metodach Execute interfejsu IPlugin). Standardy nazewnictwa nie są zachowywane (albo każdy programista ma swoje własne), o testach jednostkowych lub jakichkolwiek innych procesach/narzędziach podnoszących standard wytwarzanego kodu możemy oczywiście zapomnieć. Dodatkowo, już na początku otrzymujemy informację, że na refactoring nie ma czasu, ponieważ klient jest nerwowy i cały czas oczekuje dostarczania nowych funkcjonalności. Testy jednostkowe są oczywiście zbędne i krzywo-postrzegane (ponieważ zjadają cenny czas, który programista mógłby poświęcić na trzaskanie kolejnych pluginów).

Wydaje się Wam, że opisana powyżej sytuacja jest czymś wyjątkowym i trzeba mieć dużego pecha, żeby trafić do takiego projektu? Niestety mam wrażenie, że tak nie jest. W sytuacji, w której jedynym kryterium wyboru dostawcy oprogramowania jest cena, na rynku dochodzi do swoistych wynaturzeń. W jaki sposób najłatwiej jest bowiem „obciąć” koszty wdrożenia? Sprawa jest banalnie prosta. Nie zatrudniamy do projektu doświadczonych programistów, którzy na dodatek będą obarczeni wszystkimi typowymi „wadami” (wymądrzanie się, kwestionowania realności wycen, chęć zaprojektowania porządnej architektury i pisania kodu zgodnie z powszechnie przyjętymi standardami). Preferowanym rozwiązaniem jest często zatrudnienie dwóch studentów, którzy będą „trzaskać” kod po nocach (tak jak umieją, a niestety bezpośrednio po studiach umieją zazwyczaj niewiele) i skleją rozwiązanie, które będzie jako tako działać. To, że rozwój takiego systemu będzie niezwykle utrudniony a każda zmiana funkcjonalna powodować będzie kłopoty, nie jest problemem. Ważne, że fakturka zostanie wystawiona.

Na szczęście w firmie, w której obecnie pracuję, całość organizacji strony technicznej projektów wygląda już całkiem nieźle (zresztą, cały czas pracujemy nad ulepszaniem tego procesu). Patrząc natomiast wstecz, nie od razu Kraków zbudowano i „przewalczenie” pewnych kwestii w przeszłości wymagało określonego nakładu pracy oraz stosownej argumentacji.

Jeżeli natomiast, drogi programisto, pomimo podejmowanych prób nie widzisz jakichkolwiek szans na poprawę swojej sytuacji, „twardogłowa” kadra zarządzająca nie rokuje nadziei, tkwisz od lat w tym samym projekcie, który sprowadza się do łatania kolejnych dziur w systemie (gdzie dodatkowo, każda łata w jednym miejscu powoduje wystąpienie problemów w innym), a jakość dostarczanego rozwiązania jest ostatnią kwestią na której komukolwiek zależy, wówczas… sam musisz sobie odpowiedzieć, co zrobić :).

Moim skromnym zdaniem, na tego typu klimaty po prostu szkoda naszego życia.

Total Views: 1181 ,

One thought on “Depresje programisty CRM

  • Dobry wpis! Miałem okazję pracować trochę z CRMem i więcej z SharePointem i miałem podobne wrażenie 😉

Comments are closed.