Technical PM

DevSecOps, czyli bezpieczeństwo oprogramowania od pierwszej linii kodu… a nawet wcześniej

W tym artykule opisuję strategiczne elementy istotne w implementacji cyklu rozwoju bezpiecznego oprogramowania (ang. Secure Software Development Lifecycle, dalej SSDLC) w dużej organizacji. Sposób realizacji dużego projektu ma ogromne znaczenie dla późniejszego utrzymania produktów, jakie dostarcza. Im większe przedsięwzięcie, tym bardziej istotna staje się precyzja i dostosowanie metodyczne. Ktoś mógłby powiedzieć: „to trochę frazes”. Lecz podkreślam to, bo należę do osób, które uważają, że po pierwsze – kierownik projektu musi rozumieć merytorykę prowadzonego przez siebie projektu (są tacy, którzy to kontestują), a po drugie – im bardziej projekt jest skomplikowany, tym bardziej powinien podążać ścieżką dostosowania metodyki do specyfiki tego konkretnego wdrożenia.

Scrumban – różnice w stosunku do Scrum i Kanban

Czym jest Scrumban? Nazwa sama w sobie zawiera odpowiedź, z pewnością jest to miks zasad Scrum i Kanban. Pomysł na tyle prosty, że aż genialny – czemu mam tkwić w ograniczeniach Scrum, czy pływać w nieoznaczoności Kanban (np. role w projekcie, czas retrospektyw), jeśli mogę wykorzystać te dwa narzędzia i zbudować trzecie – bardziej przyjazne użytkownikowi i silne jak dwa inne rozwiązania razem wzięte?

Megaprojekty – megaważne – uczące – ciekawe

Dla Bostonu nie ma przyszłości. To jeden wielki korek. Każdej doby, już za chwilę,miasto będzie „stać” 14 godzin! Główną arterią miasta przejeżdża 200.000 samochodów dziennie i liczba ta będzie wciąż rosła. W krótkim okresie należy spodziewać się odpływu mieszkańców, a na pewno inwestorów, którzy po wylądowaniu na lotnisku Logana musieliby wiele godzin przedzierać się do miasta. A to wszystko dlatego, że gdy Boston był projektowany, nikt nie myślał o istnieniu motoryzacji. Przebudowywano je w latach pięćdziesiątych XX wieku, na bazie planów z lat dwudziestych. Uważano, że 75.000 samochodów dziennie – to przepustowość dróg, której nigdy nie da się zapełnić. Teraz jednak bostońskie autostrady są przepełnione. Szpecą miasto. Nie rozwiązały żadnych problemów komunikacyjnych, a ich stan techniczny powoli napawa trwogą.

Risk Management – for Beginners and not Only

Let’s start then with Risk Management as a crucial area for every PM. I would also dare to say that it is an area which distinguishes a good PM from “a common manager” who often gets into PM’s shoes for various reasons. He/she may feel proficient in business case, co-ordination or delegation, while risk management is then more or less neglected. I’ll give you a hint, as a person carrying out recruitment. If you are going for an interview for a PM role in a mature organization, be more than sure that this area will be thoroughly checked. With regret, I have to say that many of interviews showed that even experienced PMs have some difficulties with describing the process, they are not sure how to tailor it, or when quantitative analysis should be applied.

ERP – jak dobrze wybrać i efektywnie wdrożyć?

ERP – Enterprise Resource Planning – to metoda efektywnego planowania zarządzania całością zasobów przedsiębiorstwa. Jest to też określenie systemów informatycznych służących wspomaganiu zarządzania przedsiębiorstwem lub współdziałania grupy współpracujących ze sobą przedsiębiorstw, poprzez gromadzenie danych oraz umożliwienie wykonywania operacji na zebranych danych.

Portfolio or Program or… Hybrid?

A few times I was assigned to the role of Program Manager or Portfolio Manager with one main goal: organize or improve a group of different projects and make them manageable and reported to the customer in an organized way. One time it was internal tower reorganization, another time it was Projects’ Portfolio for an external customer. In both situations I was wondering how I should start and which of the two concepts: Portfolio Management or Program Management should be used to manage that situation.

Spojrzenie wstecz – dobre praktyki retrospektyw

Retrospektywy to spotkania przeznaczone do analizy sposobu pracy zespołu, identyfikacji usprawnień oraz wzmocnienia silnych stron. Jedna z zasad Manifestu Agile mówi, że zespoły w regularnych odstępach czasu zastanawiają się nad poprawą swojej efektywności, dostosowując lub zmieniając obecne praktyki i zachowania. Retrospektywy są więc naturalną częścią każdego zwinnego projektu.

Stawka większa niż projekt

Statystyki co roku są podobne. Co roku równie smutne i nie napawające nadzieją. Źródłowe przyczyny niezmienne i wciąż te same. Apele i nawoływania zdają się na nic i pozostają bez echa. Czy chodzi o statystyki utonięć w czasie kolejnych wakacji? A może o liczbę wypadków drogowych w czasie trwania policyjnej „Akcji Znicz”? Nic podobnego. Każdego roku firma doradcza PM Solutions Inc. ankietuje 160 firm i ponad 20 tysięcy przeprowadzonych przez te firmy projektów. Tzw. „powodzeniem” zakończyła się mniej niż połowa przedsięwzięć a blisko 40% skończyło jako „ewidentne porażki”. Codzienne rozmowy z wyższą kadrą kierowniczą, nie tylko firm branży IT, potwierdzają tę smutną prawdę o projektach, które osiadły na mieliźnie. I co roku wszyscy zastanawiamy się głośno „dlaczego tak się dzieje”?

Dlaczego sektor przemysłowy nie przyjmie Agile?

Od kilku lat Agile króluje w sektorze teleinformatycznym i dzisiaj ciężko znaleźć spotkanie rekrutacyjne, które nie zaczyna się od pytania o doświadczenia w Scrum. Ale zwinne podejście aktualnie to nie tylko IT, i w moim przekonaniu to właśnie w innych działach i sektorach zaczyna przynosić największe korzyści. Głównym powodem takiego stanu rzeczy jest zastosowanie Agile jako filozofii podejścia do projektów i organizacji, a nie (jak to często miało miejsce w IT) zastosowanie ról i technik Scruma. Faktem potwierdzającym, że zwinne podejście trafiło do najwyższych poziomów zarządczych jest zarówno poruszanie tej tematyki przez najważniejsze magazyny zarządcze jak Harvard Business Review (np.: z maja-czerwca 2018 roku), ale również coraz częstsze pytania Zarządów, Dyrekcji i innych działów o wdrożenie Agile.

Dlaczego zarządzanie zadaniami projektowymi jest niewystarczające?

Myśląc o realizacji projektu często koncentrujemy się na zarządzaniu zespołem, a zwłaszcza na komunikacji w zespole, dzieleniu się pracą i monitorowaniu postępów realizacji zadań. Jeśli realizujemy projekty samodzielnie to faktycznie aspekt zarządzania zespołem jest wiodący, ale zdecydowanie niewystarczający, aby efektywnie i skutecznie zarządzać całym projektem. W przypadku projektów realizowanych z podwykonawcami jest to jeszcze bardziej istotne.