Definiowanie ról zawodowych we wdrożeniach AEM
W przypadku każdej dużej implementacji platformy Digital Experience (a w szczególności w przypadku AEM), znacznie przekroczyliśmy punkt, w którym można by oczekiwać, że "webmaster" lub "jack-of-all-trades" będzie w stanie skutecznie pełnić wszystkie wymagane role. Tak więc, omówione w naszym odcinku podcastu tutaj, a następnie wyszczególnione (i miejmy nadzieję regularnie aktualizowane) poniżej, są podstawowymi rolami projektu AEM oraz ich obowiązkami i mocnymi stronami. Ale także (a czasem o wiele ważniejsze), czy jest to rola, którą zazwyczaj pełni się wewnętrznie, czy też jest to rola, którą zazwyczaj zleca się agencji lub dostawcy rozwiązań.
Dostępny również w serwisie Apple Podcasts oraz jako podcast audio lub wideo w serwisie Spotify.
Krótkie podsumowanie ról, które podejmujemy w podcaście:
Właściciel produktu / właściciel witryny
Właściciel produktu lub właściciel witryny jest głównym punktem odpowiedzialności za treść i funkcjonalność wdrożenia, zazwyczaj na poziomie dyrektora lub wiceprezesa w firmie. W przypadku witryn AEM, zazwyczaj AEM obsługuje ".com" tej firmy. Spośród wszystkich ról jest to jedyna, która zasadniczo nigdy nie jest zlecana podmiotowi spoza firmy.
Więcej informacji na 7:11 w podcaście
AEM Solution Architect (również Multi-Solution Architect)
[podjęte na stronie 9:45].
Architekt rozwiązań, w przeciwieństwie do powyższego właściciela produktu, prawie zawsze pochodzi od dostawcy lub agencji. Ich zadaniem jest dogłębne zrozumienie zestawu problemów, bolączek, wymagań, personelu, celów, budżetów, pożądanych umiejętności i wskaźników sukcesu danej firmy, a następnie zaprojektowanie rozwiązania, które faktycznie je spełnia i które można zrealizować. Architekt rozwiązań dla AEM jest już zazwyczaj architektem AEM, który ma również doświadczenie w rozwoju, operacjach i powiązanych umiejętnościach potrzebnych do zaprojektowania całego działającego rozwiązania.
"Architekt wielu rozwiązań" staje się potrzebny, gdy rozwiązywany problem obejmuje wiele odrębnych rozwiązań, takich jak "AEM i Adobe Experience Platform" lub "Sitecore + SAP Commerce" lub "AEM Assets + AEM Forms".
Jako uwaga - architekci rozwiązań są niezbędni, aby dobre rozwiązanie zostało sprzedane, ale rozwiązania mają tendencję do bycia płytkimi i słabo przemyślanymi, gdy architekt rozwiązań kończy jako "techniczny sprzedawca" zamiast kogoś, kto spędził czas z brudnymi rękami i ma na swoim koncie wiele sukcesów (i porażek).
Odkryłem również, że architekt rozwiązań musi być w stanie nosić kapelusz "bufora sprzedaży" (omówiony na stronie 11:00), aby móc upewnić się, że właściwe produkty są kupowane we właściwym czasie, a nie tylko dlatego, że brzmiały krzykliwie lub dlatego, że zespół sprzedaży firmy XYZ powiedział "AI" odpowiednią liczbę razy w przekonującej prezentacji sprzedażowej.
Architekt AEM
Architekt AEM jest prawdopodobnie jedną z najtrudniejszych ról do dokładnego i spójnego zdefiniowania, ponieważ cechy, których projekt lub zespół potrzebuje w "Architekcie AEM" są bardzo zróżnicowane. [Zobacz 15:48] Muszą być w stanie:
- Zna AEM lepiej niż ktokolwiek inny w zespole
- Przede wszystkim powinni wiedzieć wszystko, do czego zdolny jest AEM, a także powinni wiedzieć, gdzie narysować granicę tego, do czego AEM nie jest zdolny lub czego nie powinien robić. Jedynym sposobem na zdobycie tego jest doświadczenie, a to doświadczenie prawdopodobnie nie powinno być "szczęśliwą ścieżką". Powinni byli widzieć, jak AEM kilka razy staje w płomieniach.
- Powinni posiadać umiejętności miękkie w zakresie zarządzania projektami, zarządzania personelem, usuwania błędów personelu, a także być dobrzy jako "deflektor sprzedaży", a czasami jako "akcelerator sprzedaży", gdy narzędzia naprawdę MUSZĄ zostać nabyte, aby zespół odniósł sukces. [Zob. 21:29].
AEM Front-End Developer & AEM Back-End Developer
Znacznie łatwiejsze do zdefiniowania, choć zastanawiamy się, czy programista FE i programista BE mogą być tą samą osobą, czy też sensowne jest rozdzielenie tych ról. [25:00].
AEM Forms Developer
"Formularze AEM" to nie to samo, co "formularze wykonane w AEM", choć jest to absolutnie mylące. AEM Forms to niesamowity produkt, który jest oddzielną jednostką SKU od AEM Sites i jest mocno wykorzystywany przez większe firmy do dokładnego wykonania real-deal digital transformation.
AEM Devops Engineer / Sysadmin
Praca polegająca na administrowaniu systemem i operacjach na AEM - niezależnie od tego, czy jest to AEM on-premise, czy zarządzany przez Adobe 6.5, czy AEM jako usługa w chmurze - jest czymś, co ZAWSZE wymaga kogoś doświadczonego w AEM. Ktoś zawsze musi zajmować się monitorowaniem, niezawodnością, konserwacją, CI/CD, wdrażaniem i wydajnością - w przeciwnym razie dochodzi do przestojów i słabej wydajności witryny.
Prawdopodobnie włożyliśmy więcej pracy niż zwykle w omawianie tej konkretnej roli, od historii wojennych związanych z administrowaniem systemem w AEM, po dyskusje na temat tego , czy samoobsługowy AEM nadal istnieje. Nie można po prostu wystarczająco podkreślić, że nawet jeśli jakakolwiek usługa twierdzi, że jest "w pełni zarządzana", chyba że zarządza konkretnie TWOJĄ STRONĄ (co generalnie nie ma miejsca), musisz upewnić się, że ta rola jest odpowiednio utrzymywana.
Pełne tematy poruszone w tej dyskusji na temat ról AEM
- 0:00 - Wprowadzenie & Odbiorcy (rekruterzy & Właściciele witryn AEM)
- 2:36 - Zarządzanie projektem w witrynie innej niż AEM
- 3:24 - Dyskusja na temat monolitów i rozwiązań kompozytowych
- 4:45 - Czy istnieje prosty "czy powinienem zatrudnić personel AEM"?
- 7:11 - Rola: definiowanie właściciela witryny AEM lub właściciela produktu
- 9:45 - Rola: definiowanie architekta rozwiązań lub architekta rozwiązań AEM
- 11:00 - Architekt rozwiązań jako bufor sprzedaży ""
- 15:00 - Oddzielenie planowania "" od projektów wdrożeniowych "
- 15:48 - Rola: definiowanie architekta AEM
- 16:48 - Różnica między "lead developer" a "architect"
- 18:10 - Umiejętności miękkie "" architekta
- 21:29 - Architekt nosi również czapkę "Sales Deflector"
- 22:20 - O konsultowaniu architektów & etycznej potrzebie zwolnienia się z pracy
- 23:47 - Architekt jako akcelerator sprzedaży ""
- 25:00 - Rola: definiowanie AEM Developer (i front-end vs back-end)
- 29:05 - Rola: AEM Forms Developer (i prawdziwy Digital Tranformation)
- 32:09 - Role: AEM Assets Developer & Architekt informacji
- 33:31 - Rola: AEM Quality Assurance (QA)
- 36:28 - Rola: Autorzy AEM
- 39:45 - Rola: AEM Devops / administrator systemu AEM
- 44:20 - Maxim of Website Dashboarding
- 45:50 - Rola AEM devops polegająca na zapewnieniu zakupu odpowiedniego oprzyrządowania & używany
- 46:45 - Czy administracja systemem AEM musi mieć doświadczenie w AEM?
- 48:55 - Czy musisz mieć obsługę AEM we własnym zakresie?
- 51:44 - Role: Adobe Commerce, Hybris, Adobe Experience Platform, SEO
- 53:50 - Decydować się na firmę wewnętrzną czy outsourcing?
Zachęcamy do wysłuchania naszego podcastu i skontaktowania się z nami, jeśli chcesz porozmawiać o tym, jak nowe modele infrastruktury mogą sprawdzić się w Twoim środowisku! Prosimy o kontakt!
Prelegenci podcastów
Tad Reeves
Główny architekt w Arbory Digital
Tad pracuje z produktami Adobe od 2010 roku i ma bogate doświadczenie w zakresie infrastruktury stron internetowych. Począwszy od 1996 roku, nosił prawie każdy kapelusz w dostarczaniu stron internetowych, od architektury rozwiązań po zarządzanie produktem, i ma ponad dwie dekady doświadczenia. Uwielbia to, że Arbory daje mu możliwość dostarczania uczciwych i skutecznych rozwiązań, nawet jeśli oznacza to kwestionowanie dominujących perspektyw sprzedaży. Kiedy Tad nie pracuje, lubi jeździć na rowerze górskim i odkrywać przyrodę ze swoją żoną & 3 dzieci.
Hank Thobe
Dyrektor ds. realizacji biznesowej w Arbory Digital
Hank uzyskał certyfikat praktyka biznesowego AEM w 2022 roku, specjalizując się w interfejsie użytkownika i przepływach pracy. Wkrótce potem przyjął rolę wykonawcy w Zaxby's jako kierownik projektu w ich zespole DevOps. W przeszłości pomógł uruchomić startup technologiczny o nazwie InstantOrder, który obsługiwał restauracje typu mom-and-pop z zamawianiem jedzenia online i zapoczątkował jego motywację do innowacji. Obecnie Hank lubi chodzić na plażę, podróżować, spędzać czas na łonie natury i uprawiać sporty wewnętrzne.
Podoba ci się to, co usłyszałeś? Masz pytania dotyczące tego, co jest dla Ciebie odpowiednie? Chętnie porozmawiamy! Skontaktuj się z nami
Więcej odcinków podcastu, które mogą Ci się spodobać
Czy monolity są złe? Jaka jest różnica między monolitycznym, kompozytowym i mikrousługowym systemem CMS?
Jak rozwiązać stały problem świeżości pamięci podręcznej i opóźnień systemu zaplecza w każdym nowoczesnym systemie CMS (zwłaszcza AEM lub Edge Delivery)? W tym odcinku rozmawiamy z Michałem Cukiermanem, CTO Dynamic Solutions i współzałożycielem StreamX - cyfrowej siatki doświadczeń do radykalnego i niezawodnego przyspieszania skomplikowanych dynamicznych żądań treści z wielu systemów składowych, które składają się na nowoczesne wdrożenie CMS.
To nie hiperbola, że jeśli nie włożyłeś znacznego wysiłku w ponowne przemyślenie całego stosu dostarczania witryny w ciągu ostatnich kilku miesięcy, będziesz chciał to zrobić. Więc proszę - przestań czytać to teraz, włóż słuchawki i weź ten podcast na spacer i zastanów się, jak może on wpłynąć na twoje środowisko!