Okładka książki "Web Content Management"

Recenzja książki „Web Content Management”

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):

Książka "Web Content Management" - sugerowane części do przeczytania dla poszczególnych ról w projekcie
Książka „Web Content Management” – sugerowane części do przeczytania dla poszczególnych ról w projekcie

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.

O autorze

Marek Berkan Marek Berkan: programista, entuzjasta tworzenia oprogramowania, zarządzania zespołami technicznymi. Prywatnie motocyklista, kolarz MTB, biegacz, żeglarz, rekreacyjny wspinacz, zamiłowany turysta. Witryny: , , .

Dodaj komentarz

Twój adres e-mail nie zostanie opublikowany. Wymagane pola są oznaczone *