12 lat z CRM-em. Perspektywa inżyniera-programisty

W styczniu roku Pańskiego 2018 stuknęło mi 12 lat pracy zawodowej. Uściślę – pracy zawodowej, polegającej na wdrożeniach systemów informatycznych w oparciu o platformę Dynamics CRM firmy Microsoft.  Tak naprawdę to owych, przepracowanych przeze mnie lat upłynęło już 13. Ponieważ jednak pierwszy rok „kariery” spędziłem jako stażysta, zajmując się mocno odmiennymi technologiami od tych, którym w większości poświęcony jest ten blog, pozwolę sobie nie uwzględnić go w tytule artykułu.

Rok pierwszy – SAP, Pivotal i Visual Basic 6 (!)

Będąc jeszcze studentem, w czasie wakacji zostałem stażystą w dużej (obecnie nieco podupadłej) polskiej grupie kapitałowej. Pierwszym (i jak się okazało ostatnim) projektem, na który trafiłem, było wdrożenie systemu Pivotal CRM i SAP dla dużej firmy z branży budowlanej. W czasie pracy na wspomnianym projekcie zajmowałem się tworzeniem rozszerzeń dla wymienionego powyżej systemu CRM. Projekt był trudny, a używane technologie mocno wiekowe (Visual Basic 6 i Action Script). Z perspektywy czasu oceniam jednak to doświadczenie niezwykle pozytywnie. Po pierwsze poznałem wówczas wielu bardzo fajnych ludzi, którzy pojawiali się później w moim zawodowym życiu wielokrotnie. Po drugie, było to moje pierwsze doświadczenie oraz możliwość zobaczenia „od środka” jak wygląda wdrożenie systemów CRM i ERP.

Niestety, w wyniku reorganizacji firmy, mój zespół został rozwiązany po zakończeniu projektu. Trafiłem wówczas do jednostki organizacyjnej, której członkowie specjalizowali się we wdrożeniach pakietu aplikacji biznesowych Oracle E-Business Suite. Szybko jednak stwierdziłem, że PL/SQL i w szczególności Oracle Forms nie są technologiami, z którymi chcę spędzić kolejne lata życia.

„Hey, I’m Microsoft…” (2006-2011)

W 2006 roku udało mi się ukończyć studia na Wydziale Elektrycznym Politechniki Warszawskiej (specjalność: Inżynieria Komputerowa). W tym samym czasie rozpocząłem pracę w firmie Microsoft w dziale Consulting Services na stanowisku (niespodzianka) konsultanta.

To właśnie w czasie pracy w polskim oddziale Microsoftu zetknąłem się po raz pierwszy z systemem Dynamics CRM, wówczas noszącym jeszcze nazwę Microsoft CRM. Co ciekawe, rozpoczynając pracę w omawianej organizacji, absolutnie nie zamierzałem kontynuować mojej przygody z systemami CRM. Pracę w Microsoft rozpocząłem od projektów związanych z zarządzaniem elektroniczną tożsamością użytkownika (Identity Management). Kilka miesięcy po mnie, do Microsoftu dołączył również mój przełożony z poprzedniej firmy. Jego pierwszym zadaniem była organizacja… CRM-owego zespołu (tadaaam!!!) w ramach Microsoft Services. Byłem wtedy typowym, mało-asertywnym juniorem i pomimo wcześniejszych założeń dałem wciągnąć się w macki CRM-owej ośmiornicy. Co zresztą w ostatecznym rozrachunku wyszło mi na dobre :).

W czasie pracy w Microsoft miałem okazję pracować na wdrożeniach systemu CRM w wersjach 3.0 i 4.0. Wersje te (oczywiście on-premise, o chmurze nikt jeszcze wówczas nie słyszał) były dużo prostsze w porównaniu z tymi, dostępnymi obecnie na rynku. W samej pracy z systemem Dynamics CRM urzekły mnie natomiast:  z jednej strony bardzo konsekwentne i zunifikowane narzędzia oraz metody dostosowań i rozszerzeń (w porównaniu z np. ówczesnym SharePointem),  z drugiej strony możliwość pracy niepolegającej jedynie na pisaniu kodu, ale również na konfiguracji około systemowych lub zależnych od niego komponentów, możliwości bezpośredniego kontaktu z klientem i tym wszystkim, co związane jest z projektami wdrożeń systemów CRM. Ograniczone możliwości ówczesnego CRM API, brak sensownych narzędzi oraz frameworków, ułatwiających development w języku JavaScript, niespecjalnie wówczas mi przeszkadzały. Młodość, wiadomo… :). Wszystko było wówczas nowe i fascynujące.

Ciekawostką jest to, że w czasach, o których piszę, CRM był na tyle nowym i nieznanym produktem, że często osoby pracujące w polskim oddziale Microsoftu nie zdawały sobie sprawy z jego istnienia. Kilka cytatów z pamięci: „CRM? Czy to jakiś dodatek do SharePointa?„, „My tu systemu operacyjne, pakiety biurowe i SQL Server sprzedajemy…„.

Dlaczego zdecydowałem się na odejście z Microsoftu, wymarzonego miejsca pracy dla wielu osób z branży IT? Powodem numer jeden była konieczność ciągłych podróży. Dział, w którym pracowałem, realizował większość projektów poza granicami Polski. O ile na początku bardzo mi się to podobało (wiadomo, nowe miejsca, ludzie, mieszkanie w dobrych hotelach i chodzenie na kolacje projektowe :)) to z czasem stało się mocno uciążliwe i w praktyce nieakceptowalne. Z kolei w Polsce, w dziedzinie realizowanych  przez mój dział, dynamicsowych projektów, panowała zupełna posucha. Na polskim rynku, w świadomości klientów istniało wówczas dwóch producentów oprogramowania dla biznesu: Oracle i SAP. Dodatkowo w pierwszym dziesięcioleciu 21. wieku możliwości rozwoju dla osoby o profilu technicznym w polskim oddziale Microsoft były mocno ograniczone. Moje możliwości kontynuowania kariery w Microsoft wyglądały wówczas następująco: życia na walizkach, albo zmiana roli na sprzedażową lub sprzedażowo-podobną (wszelkiego rodzaju ewangeliści, technical-account mangerowie” i tym podobne), albo „cześć”. Wybrałem to ostatnie.

CRM Mastah (2011-2017)

Po odejściu z Microsoft trafiłem do niewielkiej wówczas firmy (dziś powiedzielibyśmy: „startupu”), która specjalizowała się we wdrożeniach systemu Dynamics CRM.  Z perspektywy czasu muszę powiedzieć, że była to bardzo dobra decyzja. W czasie pracy w omawianej organizacji miałem możliwość spróbowania pracy w niemalże wszystkich rolach, które możemy wyodrębnić na projektach wdrożeniowych (programista, tester, analityk, project manager, architekt). Rozwinąłem się również jako specjalista od systemu CRM, programista, a także z uwagi na częstą, bezpośrednią pracę z klientem końcowym, jako konsultant.

W tym czasie system CRM przeszedł w tym czasie ogromną rewolucję. Moim pierwszym projektem po zmianie pracy był rozwój aplikacji zbudowanej w oparciu o wersję 4.0. Następnie nastąpił wysyp tematów tworzonych oparciu o moją ulubioną, office’o-podobną wersję 2011, poprzez zupełnie przebudowaną 2013, a skończywszy na pierwszych wdrożeniach w chmurze opartych o platformę Dynamics CRM 2016 i Dynamics CRM 365.

W tym czasie przeszedłem również (wraz z organizacją) swoistą ewolucję jako architekt-programista. Gdy rozpoczynałem pracę, tworzenie rozszerzeń do systemu CRM sprowadzało się do zasady „siadamy i piszemy” (każdy jak potrafi). W czasie kilku lat, które spędziłem w omawianej organizacji, wypracowaliśmy sobie szereg wzorców projektowych, narzędzi, frameworków oraz praktyk pozwalających na dostarczanie projektów zgodnie z powtarzalnymi schematami. Rozpoczynając od prostych projektów, opierających się głównie o klasy statyczne, poprzez w pełni obiektowe podejście, na koniec dopracowaliśmy się firmowego frameworka wykorzystującego najnowsze, wybrane wzorce i praktyki z dziedziny inżynierii oprogramowania.

Ponownie, jeżeli było tak dobrze, to dlaczego postanowiłem zmienić pracę? Pierwszym powodem było to, że w czasie kilku lat spędzonych w omawianej organizacji nie rozwinęła się ona zgodnie z moimi oczekiwaniami. Rozpoczynając pracę, miałem wrażenie, że będziemy drugim, polskim Facebookiem :D. W którymś momencie niestety coś pękło i po pięciu latach doszedłem do wniosku, że ciągle realizujemy praktycznie te same projekty, tyle że dla innych klientów. Co więcej, w ostatnim okresie mojej pracy, były to głównie projekty utrzymaniowe, co jakoś nigdy specjalnie mnie nie bawiło. Na to wszystko nałożyło się (w moim przekonaniu) wiele nietrafionych decyzji osób zarządzających tejże firmą, ich podejście i niezrozumienie współczesnych metod tworzenia oprogramowania („testy jednostkowe = marnowanie roboczo-godzin”, „ciągła integracja = niepotrzebny kaprys developerów”),  a także ogólne „zmęczenie materiału” z mojej strony. Po pięciu latach spędzonych na wdrażaniu systemu obsługującego proces sprzedaży („na oko”, jakieś 80% moich projektów dostarczonych w tym czasie) postanowiłem, że czas na coś nowego…

A może tak coś innego? (2017-?)

Po pięciu latach spędzonych na projektach realizowanych dla polskich klientów czułem się nieco wypalony. Niestety z perspektywy dostawcy muszę z przykrością stwierdzić, że większość tego, co mówi się po organizacjach korzystających z usług integratorów w Polsce, nie mija się z prawdą. Przeciętny polski klient jest klientem mocno roszczeniowym, nierozumiejącym technologii oraz procesów związanych z jej implementacją w organizacji. Dodatkowo zupełnie nie odnajduje się on w partnerskim modelu współpracy z dostawcą (preferuje raczej model: „master”-„slave”). Co więcej, nie jest specjalnie skory do ponoszenia kosztów związanych ze zmianami w specyfikacji i często potrafi uciekać się do szantażu („albo dostaniemy jakąś nieopisaną w specyfikacji funkcjonalność lub zmianę gratis, albo nie zapłacimy za całość”). Oczywiście zdarzają się chwalebne wyjątki, jednak ogólne wrażenie pozostaje…

Zachęcony pozytywnymi wrażeniami z projektów, realizowanych w czasie pracy w Microsoft, zatrudniłem się więc w firmie, realizującej projekty na rynek duński. Na razie, moje wrażenia są umiarkowanie pozytywne i cieszę się, że mogę pracować w organizacji, która z jednej strony odnosi sukcesy, a w której nikomu nie trzeba tłumaczyć jaka wartość wynika z pisania testów jednostkowych lub ciągłej integracji. Więcej informacji o realizowanym przeze mnie projekcie możecie znaleźć w tym miejscu: https://bulldogjob.pl/articles/686-building-xrm-solutions-for-danish-nature-agency

Summa summarum

Miało być o Dynamics CRM-ie, a wyszło bardziej o mnie :). Spróbuję jednak w kilku zdaniach podsumować, w jaki sposób wyglądała ewolucja systemu oraz ewolucja sposobu jego dostosowań i wdrożeń. Rozpoczynając pracę z platformą (wersja 3.0) – miałem do czynienia z prostą aplikacją webową, wykorzystującą SQL Server jako repozytorium danych. Możliwości jej rozbudowy były mocno ograniczone (proste skrypty w języku JavaScript oraz będące pierwowzorem pluginów, bilbioteki tzw. „calloutów”). Kolejna wersja systemu (2011) była wersją mocno „office-like”, która wykonała największy krok, w temacie możliwości programowania systemu (nowoczesne API JavaScript, pluginy, mechanizm workflow oparty o Windows Workflow Foundation). Kolejne wersje systemu z punktu widzenia programisty były już bardziej ewolucją i rozbudową istniejących mechanizmów niż rewolucją. Ta ostatnia dokonała się jednak w obszarze interfejsu użytkownika, który wyewoluował z office’o-podobnego, pop-upowego maleństwa w nowoczesny UI, wspierający pracę na urządzeniach mobilnych, obsługiwanych za pomocą dotyku. Oczywiście po drodze zdarzały się wpadki lub jawne pomyłki (niesławna wersja 2013), ale cóż… błędów nie robi tylko ten, kto nie robi nic.

W czasie tych wszystkich lat dokonała się również swoista rewolucja w sposobach tworzenia rozszerzeń do systemu. Pierwszy kod, rozszerzający jego możliwości, który tworzyliśmy na początku tego wieku, sprowadzał się do „wypełniania” logiką metody „Execute” pluginów lub też ewentualnie wykorzystywaniu kilku klas statycznych. Za repozytorium kodu uchodził wówczas dedykowany udział na dysku sieciowym lub (w późniejszym okresie) – SVN. Rozwój systemu oraz skali realizowanych projektów wymusił zmianę podejścia do pisania kodu (podejście w pełni obiektowe) oraz jego przechowywania. Repozytorium (w moim przypadku był to powszechnie obecnie „hejtowany” TFS) stało się obowiązkowym narzędziem, podobnie jak coraz bardziej rozbudowane oraz wykorzystujące stosowane współcześnie wzorce projektowe (Factory, Repository, Comman,  Dependency Injection i wiele innych), które sobie wypracowywaliśmy. W międzyczasie okazało się, że tworzenie kodu dla systemu Dynanamics CRM, który wspiera testy jednostkowe, nie wymaga żadnej wiedzy tajemnej i faktycznie wnosi dużą wartość i poprawę jakości dostarczanych rozwiązań.

Ostatnim krokiem mojej programistyczno-dynamicsowej ewolucji było zastosowanie procesów ciągłej integracji w projekcie wdrożeniowym, co umożliwia nam wdrożenie nowej wersji aplikacji (solucje, biblioteki, komponenty zależne, procesy, serwisy itp.) na środowisko klienta za pomocą jednego kliknięcia (przy jednoczesnej kontroli jakości, polegającej na automatycznym uruchamianiu testów), integracja z systemami zewnętrznymi za pomocą mechanizmu wirtualnych encji (pisałem już tym na blogu tutaj: http://xrmlabs.piotrgaszewski.pl/2018/03/09/dynamics-365-ce-wirtualne-encje-i-protokol-odata-v4/ i tutaj: http://xrmlabs.piotrgaszewski.pl/2018/07/09/moje-boje-z-wirtualnymi-encjami/), wykorzystanie GIT-a jako repozytorium kodu oraz zastąpienie JavaScriptu w projektach językiem TypeScript (http://xrmlabs.piotrgaszewski.pl/2017/09/27/programowanie-dynamics-365-w-jezyku-typescript-z-wykorzystaniem-xrmdefinitelytyped/)

Nie zgadzam się również z obecnymi w Internecie opiniami głoszącymi koniec Dynamics 365 jako platformy dla programistów. Faktycznie, stworzenie rozszerzeń systemu w obszarach, wymagających w przeszłości pisania kodu w językach C# lub JavaScript, jest obecnie możliwe do realizacji za pomocą narzędzi dostosowań (czyli przysłowiowa, nielubiana przez programistów „klikologia”). Jest to jednak naturalna kolej rzeczy, związana z ewolucją systemu, jego rozbudową funkcjonalną i integracją z innymi usługami w chmurze Microsoft. Jednocześnie, w platformie pojawiło się w ciągu ostatnich lat tyle nowości technicznych, że żaden developer nie będzie się na pewno nudził (oczywiście, jeżeli nie utknie na projekcie „utrzymaniowym” systemu w wersji  4.0 ;)).

Plany, plany…

Po 12 latach spędzonych w towarzystwie systemu Dynamics CRM/Dynamics 365 nie mam zdecydowanie dość. Zmiany w platformie są na tyle duże i wprowadzane w niewielkich odstępach czasowych, że bardzo trudno jest ogarnąć je wszystkie i nie sposób się nudzić :). Jeżeli Microsoft nie strzeli sobie sam w stopę jakąś niemądrą decyzją, to przyszłość platformy będzie w dalszym ciągu rysować się z jasnych, optymistycznych barwach. Ja zdecydowanie zostaję na pokładzie! Do zobaczenia za kolejne 12 lat* ;).

* Oczywiście „do zobaczenia” z kolejnym podsumowaniem, a nie kolejnym wpisem na blogu :D.

Total Views: 688 ,
This Article Has 1 Comment
  1. Pingback: dotnetomaniak.pl

Dodaj komentarz

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