Zeszły (2019) rok był dla mnie powrotem z e-commerce do projektów portali opartych o CMS – pracowałem przy utrzymaniu i rozwoju wdrożeń opartych o system ActiveContent (autorski produkt e-point S.A. oparty na platformie Java). Postanowiłem sprawdzić jak z tego typu projektami radzi sobie “reszta świata” i w ten sposób trafiłem na książkę “Web Content Management” napisaną przez Deane’a Barker’a i wydaną w 2016 roku przez wydawnictwo O’Reilly Media (to te od “zwierzątek na okładkach”…).

Książka ta nie “odmieniła mojego życia”, jednak, po pierwsze: potwierdziła że większość funkcjonalności które oferuje nasz CMS, a także praktyk i problemów z którymi spotykamy się pracując z naszymi klientami jest normalna – z takim samymi problemami borykają się inne firmy wdrażające systemy tego typu. Po drugie: książka ta wydaje mi się doskonałym punktem wejścia dla nowych pracowników rozpoczynających przygodę z projektami opartymi o systemy CMS.

Kariera Deana z systemami CMS rozpoczęła się w 1999 roku. Treść książki abstrahuje od technologii, kodu programistycznego oraz stara się nie wymieniać jakichkolwiek konkretnych produktów CMS. Jednak w przykładach padają wzmianki o Drupal, WordPress oraz Episerver. Sądząc po aktualnej informacji, że od października 2019 rozpoczął on pracę jako dyrektor odpowiedzialny za strategię w Episerver, to wcześniejsze związki firmy Blend Interactive (pracuje w niej od 2005) musiały być silniejsze niż z innymi dostawcami.

Dla kogo jest ta książka?

Książka jest podzielona na 3 części: podstawy, przegląd funkcjonalności oraz proces wdrożenia projektu wraz z powiązanymi aspektami organizacyjnymi i biznesowymi. W szczególności ta ostatnia część zawiera wiele bezcennych informacji “od kuchni”, do których normalnie trzeba dochodzić latami, popełniając przy tym szereg błędów. Z myślą o moich kolegach i koleżankach pozwoliłem sobie na propozycje wskazówki którzy czytelnicy z którymi częściami książki powinni się obowiązkowo zapoznać (oczywiście zachęcając też do przeczytania całości):

Jak widać na powyższym zestawieniu, książkę można czytać z kilku perspektyw:

• producenta systemu CMS, żeby dowiedzieć się jakie funkcje powinien posiadać system i na jakich aspektach niefunkcjonalności zależy klientom i firmom wdrażającym,
• klienta wybierającego spośród istniejących produktów, żeby wiedzieć na jakie funkcje, aspekty organizacyjne i biznesowe zwracać uwagę oraz jak wybrać i współpracować z firmą wdrażającą aby projekt zakończył się sukcesem i ze współpracy były zadowolone obie strony,
• firmy wdrażającej (integratora), żeby wiedzieć jak zarekomendować najlepszą platformę CMS i model współpracy dla klienta.

Aby ułatwić wybór platformy, część rozdziałów kończy się listą pytań jakie należy zadać w trakcie rozpoczynania projektu, np.

• czy nowy system ma zastąpić istniejący,
• czy wymagana jest migracja treści,
• czy klient sam będzie uzupełniał brakujące treści,
• czy są gotowe wyniki analizy przedprojektowej (nowa mapa strony, projekty graficzne/UX unikalnych ekranów, opis pochodzenia danych w poszczególnych miejscach na ekranach i dodatkowych funkcjonalności, opis integracji).

Opisane “trudniejsze” aspekty techniczno organizacyjne

Autor opisuje wiele aspektów techniczno-organizacyjnych które trzeba tłumaczyć (niekiedy parokrotnie) każdej nowej osobie nietechnicznej przychodzącej do projektu (przez co będę uparcie polecać tą książkę 🙂 ), np.:

• podział na treść zarządzaną bezpośrednio na środowisku produkcyjnym przez część administracyjną (redaktorzy, super-użytkownicy) i treść będącą częścią kodu aplikacji wymagającą aktualizacji (wgrania) wersji, np. szablony, CSS, JavaScript, niektóre lokalizacje,
• podział na funkcjonalność dostarczaną przez platformę (od producenta), funkcjonalności zaimplementowane dla konkretnego wdrożenia (od firmy wdrażającej) oraz aspekty związane ze środowiskiem uruchomieniowym (od firmy hostingowej) oraz związany z tym podział odpowiedzialności i wzajemnych zależności.

Zadania składające się na wdrożenie portalu

W części związanej z procesem implementacji portalu i aspektami biznesowymi wymieniany jest szereg zadań składających się na poprawnie prowadzony projekt, które często są niezauważane, niedoceniane i niechętnie rozliczane przez klientów:

• konfiguracja środowisk developerskich, testowych, repozytorium kodu, systemów budowania,
• przygotowanie i parokrotne testowanie procesu migracji treści,
• szkolenia dla redaktorów, administratorów, wsparcie przy rozwiązywaniu ich bieżących problemów i odpowiadanie na pytania,
• projektowanie i konfiguracja środowiska produkcyjnego,
• przygotowanie i przeprowadzenie procesu uruchomienia produkcyjnego, często wymagającego koordynacje wielu zespołów,
• szczegółowych testów i wysiłku wielu dodatkowych osób przed momentem uruchomienia nowego portalu,
• przygotowanie dokumentacji post-projektowej i instrukcji dla użytkowników,
• zarządzanie całością projektu, organizowanie spotkań, przygotowywanie raportów z postępów,
• wewnętrzny marketing do organizacji klienta mający na celu poznanie i “polubienie” nowego narzędzia,
• zakładanie kont i konfiguracja uprawnień w nowym systemie,
• testy obciążeniowe i testy bezpieczeństwa,
• zaplanowanie i konfiguracja redirectów pomiędzy starymi adresami URL a nowymi,
• konfiguracje certyfikatów SSL,
• wsparcie przy zmianie wpisów w adresach DNS.

Dlaczego warto wybrać komercyjną platformę wdrażaną przez specjalizowaną firmę

Wymienione w różnych fragmentach książki powody (z uzasadnieniem) to:

• w dużych organizacjach CMS jest narzędziem dla działu marketingu i to ten zespół decyduje o zakupie, dział IT raczej tylko weryfikuje ofertę pod względem jakości i bezpieczeństwa
• w porównaniu do komercyjnych “monolitów”, darmowe platformy z darmowymi pluginami od społeczności, mogą mieć sporo wad:
  • niższa jakość kodu,
  • niespójne UI dla administratorów/redaktorów,
  • zagrożenia bezpieczeństwa,
  • dodatkowo rozproszona odpowiedzialność za błędy w systemie w trakcie utrzymania,
  • cykl wytwórczy różniący się od cyklu rozwoju głównej platformy – brak wsparcia nowszych wersji może blokować możliwość aktualizacji tejże platformy do kolejnej “dużej” wersji, to ważna wada z perspektywy utrzymania całego systemu
• wybór zewnętrznej firmy do wdrożenia CMS zamiast wewnętrznego IT jest dlatego uzasadniony, bo taka firma może prowadzić od 10 do 100 takich projektów rocznie, a wewnętrzne IT prowadziłoby jeden na 5 lat

Współpraca z firmą wdrożeniową

Rozdział “Working with External Integrators” musi wynikać z różnych niezbyt dobrych doświadczeń przy wdrożeniach… Można go podsumować rekomendacją dla klientów: “szanuj dostawcę swego, mógłbyś mieć gorszego”. Brak dobrego przygotowania i prowadzenia prac po stronie zespołu klienta (profesjonalizmu), wymaganie wykonywania darmowych konsultacji oraz ciągłe naciskanie szybsze tempo prac i niższe koszty może doprowadzić do sytuacji że w organizacji dostawcy ten dokładnie klient będzie postrzegany jako “ten najgorszy”. W efekcie prace dla niego będą miały najniższy priorytet, będą unikać go najlepsi pracownicy i w efekcie sytuacja będzie się dalej pogarszać, w najgorszym wypadku do wypowiedzenia współpracy.

Trochę różnych ciekawych informacji

Ciekawsze rzeczy których dowiedziałem się (lub utwierdziłem w domysłach) czytając tę książkę:

• pierwszymi znanymi “content managerami” byli pracownicy bibliotek, począwszy od Biblioteki Aleksandryjskiej (300 r. p.n.e.) 🙂
• systemy CMS z definicji służą do organizacji cyklu edycyjnego (przygotowania i publikacji) treści przez ludzi do czytania przez ludzi (nie-maszyny)
• podstawowymi funkcjami systemu CMS są:
  • edycja treści (modelowanie danych, agregacja danych we wzajemnych zależnościach jak drzewo nawigacji, listy newsów, itp.),
  • zarządzanie procesem edycyjnym (workflow, uprawnienia, wersjonowanie),
  • publikacja treści do poszczególnych kanałów (w tym praca na szablonach HTML i “ubieranie” poszczególnych fragmentów)
• dodatkowymi i/lub opcjonalnymi funkcjami, które mogą być też “wynoszone” do zewnętrznych systemów są:
  • wielojęzyczność,
  • personalizacja,
  • analityka (np. integracja z Google Analytics),
  • formularze,
  • zarządzanie i edycja plikami binarnymi (DAM),
  • zarządzanie adresami URL (? – IMO to część agregacji),
  • obsługa wielu witryn,
  • API dla zewnętrznych usług,
  • architektura dla pluginów rozszerzających funkcjonalność bazową,
  • raporty,
  • wyszukiwarka,
  • wsparcie społeczności dla programistów i redaktorów (powinno się to traktować jako funkcję przy wyborze systemu).
• moduł (lub osobny system) DAM (ang. Digital Assets Management) służy nie tylko do przechowywania dokumentów, obrazków i filmów, ale także ma wbudowane narzędzia do ich edycji, np. zmiany formatów, rozmiarów, możliwość prostej edycji plików video, itp.
• niektóre platformy mają tryby “tłumaczenia” umożliwiające edycje dokumentu w dwóch językach wyświetlanych jednocześnie, obok siebie,
• niektóre platformy mają wtyczki (ang. plugin) do integracji z zewnętrznymi platformami tłumaczeniowymi przez format XLIFF wpięte w taki sposób, że workflow edycji bazowej wersji uruchamia workflow tłumaczenia po stronie tamtej platformy, a zakończenie tłumaczenia tam uruchamia workflow akceptacji w platformie CMS (pluginy te do popularnych platform CMS są dostarczane za darmo przez firmy zajmujące się tłumaczeniami)
• w produktach dostępnych na rynku, także komercyjnych, nie wszystkie dostępne funkcjonalności są takiej samej jakości, bo mogą być rzadko używane i od dawna nierozwijane, a ich obecność wynika wyłącznie z chęci pokazania “że są” na potrzeby marketingu i porównania z konkurencją
• przykłady narzędzi zewnętrznych do Marketing Automation: Marketo (obecnie posiadane przez Adobe), Pardot (obecnie posiadane przez Salesforce) i HubSpot
• przykłady narzędzi zewnętrznych do tworzenia formularzy: FormSite i Wufoo
• przykłady raportów tworzonych przez platformę CMS: strony w przygotowaniu (ang. draft), strony zaplanowane do publikacji, strony “wygaśnięte” (ang. expired), strony z nieaktualnymi linkami, zadania przypisane do bieżącego użytkownika, zadania “opóźnione”

…. a na koniec pieniądze, czyli ile to kosztuje w USA

• analiza przedprojektowa (zakres wspomniany wyżej) jest osobno płatną usługą wykonywaną często przez firmę specjalizującą się w analizie i projektowaniu interfejsu użytkownika, często inną niż firma wdrażająca później CMS
• koszt jednorazowego zakupu licencji średnich systemów CMS wahają się od $20.000 – $80.000, a dużych, jak Adobe CQ przekraczają $250.000, a model licencjonowania może zależeć od:
  • ilości redaktorów (użytkowników części administracyjnej),
  • ilości serwerów na których działa środowisko produkcyjne,
  • ilości witryn obsługiwanych przez system (unikalnych adresów domenowych),
  • włączonych funkcjonalności,
  • ilości treści, np. stron.
• koszt zakupu subskrypcji rocznej waha się od 18 do 22% w/w kosztu zakupu jednorazowego, tak aby był równowartością 4-6 lat działania systemu
• koszt wdrożenia systemu CMS zwyczajowo wynosi 3-4 razy koszt licencji
• koszt roboczogodziny członka zespołu dla klienta wynosi w USA $150, co przy aktualnym kursie dolara 3,82 daje 4.584 zł/MD 🙂

Podsumowanie

Jak wspomniałem na wstępie, książka ta powinna stać się lekturą wprowadzającą dla wszystkich nowych członków zespołów zajmujących się tworzeniem systemów CMS lub pracujących przy takich systemach jako redaktorzy.