Problem pozornie prosty: jak doprowadzić do współpracy dwa skrajnie różne światy IT - operacje zarządzające usługami (ITSM) i rozwój zarządzający projektami (n.p. PMI)? Tak go przynajmniej naszkicował Bartosz Górczyński prezentujący wczoraj zagadnienie Potrzeby ITSM wobec PM. Słuchając wczorajszego wykładu doszedłem do wniosku, że to co w świecie małych organizacji jest trywialne, w rzeczywistości dużych korporacji nie musi być wcale takie oczywiste.
Jak to działa w rzeczywistości małej organizacji? (przykład z praktyki - 2007) Każdy projekt ma swojego kierownika i zespół projektowy. W skład zespołu projektowego wchodzi osoba z operacji (zwykle administrator), który konsultuje wszelkie pomysły zespołu projektowego i wspomaga realizację zadań w części operacyjnej. Na przykład organizuje środowisko rozwojowe tak, aby było identyczne z planowanym środowiskiem produkcyjnym. Mamy zatem ścisłą współpracę pomiędzy operacjami a rozwojem realizowaną przez "oficera łącznikowego" z operacji. Co ciekawe (sprawdzone!) "oficer łącznikowy" często tak utożsamia się z projektem, że "przepycha" pomysły rozwojowe w swoim pionie (operacyjnym) nawet na przekór swoim kolegom.
Dlaczego nie zastosować tego w dużych organizacjach? (Jeśli ktoś ma czas posłuchać całości podobnego seminarium z Poznania zapraszam na YouTube).
Jest nawet taka inicjatywa o nazwie DevOps, która wygląda dokładnie jak wyżej opisany przykład. Jest nawet "profesjonalna" nazwa naszego oficera łącznikowego pomiędzy operacjami i rozwojem: Release Coordinator.
A co Wy o tym sądzicie?
Subskrybuj:
Komentarze do posta (Atom)
Bardzo ciekawy temat...
OdpowiedzUsuńSpróbuję się odnieść może do tej prezentacji pana Bartosza na sposób, jaki ja rozumiem.
Od razu zrobię zastrzeżenie, że moje obserwacje dotyczą środowiska, w którym pracuję oraz wgląd w IT w kilku innych firmach i jak się to robi na Świecie, w wiodących firmach. Środowiska te to są środowiskami o mniejszym nacisku na bezpieczeństwo aplikacji (szeroko rozumiane) internetowych a szczególnej wadze położonej na szybkość tworzenia aplikacji oraz nadążania za konkruencją. Zaznaczam jednak, że ta różnica nie jest tak duża.
W prezentacji ładnie została wyartykułowana sytuacja, w której istnieją dwa światy pracujące w trybie pracy projektowej i procesowej. To ma kolosalne konsekwencje i rodzi tarcia pomiędzy tymi światami.
Tego niestety bardzo często nie rozumie/nie dostrzega ktoś siedzący wyżej w hierarchi managementowej i traktuje bardziej jako wzajemne wojny. W przypadku pana Bartosza, który wymienił banki, firmy energetyczne widać, że chyba nie do końca analizuje wszystkie rodzaje firm.
Objawia się to zdziwieniem, że ktoś może chcieć deployować szybko i często.
Continuous Delivery się to nazywa i wkroczyło to w świat IT z dużym rozmachem.
Pan Bartosz się tego boi. Ja twierdzę, że tego nie można się bać gdyż można to pogodzić. Release and Deployment robiony za pomocą gotowych narzędzi jenkins, github, hudson, puppet, chef, cfengine, itp...
Życzyłbym sobie aby w firmach, które z jednej strony realizują duży nacisk biznesowy a z drugiej starają się aby jakość usług była wysoka, poprzez procesowe utrzymanie; continuous improvement (site reliability engineering) było zrozumienie tej sytuacji i patrzenie perspektywiczne. Tutaj nie jest nawet rolą dyrektorów IT ale kogoś kto ma pod sobą całe IT umiejętność radzenia sobie z sytuacją.
Jak widze to radzenie sobie... Będę rzucał hasłami bo to tylko komentarz jest:
* unikanie siloizacji
* bliskość fizyczna zespołów projektowych i utrzymaniowych, aby mogli spotykać się na kawie i umieli szybko wyjaśnić sobie wzajemne animozje i aby zobaczyli, że wróg to nie jest ten tam na najwyższym piętrze, ale fajny kumpel i profesjonalista, siedzący obok
* devops - przenikanie się wzajemnie kompetencji (o tym dalej).
To, co napisałeś Mitchell "oficer łącznikowy" nie wiem czy się sprawdza. Ten oficer musiałby być bardzo elokwentny, empatyczny i mieć oczy dookoła głowy. Po prostu zbyt wiele się dzieje w świecie agile.
Podejrzewam, że świetnie mogą się tutaj sprawdzić podejście scrumowe, tak jak.np. "two pizza team" w Amazonie.
Albo podejście gdzie mamy głównie deveop-ów (Etsy, justin.tv, cloudera, omniti, itp.).
Na koniec - zacząłem pisać ten mój fajny komentarz w trakcie oglądania, ale pan Bartosz zrechabilitował się na koniec :-)
Napisał o świecie bez R&D oraz zero bug i chyba rozumie temat.
Nie ma się do czego przyczepić, poza być może zbytnim zbalansowaniem w kierunku twardego ITIL-a :-)