Twój projekt działa. Ale coś nie gra.

Może właśnie nowy zespół przejął projekt i nikt nie wie, kto za co odpowiada. Może decyzja architektoniczna czeka od tygodni, bo wszyscy zakładają, że ktoś inny się tym zajmie. Albo system ma być zmodernizowany, ale wszyscy boją się go tknąć.

To nie wyjątki. To codzienna rzeczywistość IT.

Co się dzieje, gdy nic się nie dzieje

Blokady rosną. Zespoły tracą tempo. Odpowiedzialność się przesuwa, aż nikt jej nie ponosi. To, co zaczyna się jako drobne tarcie, kosztuje na końcu miesiące, a czasem więcej.

Rozpoznawalne sytuacje

  • Zmiana systemu jest planowana, ale odpowiedzialność jest niejasna
  • Decyzje architektoniczne blokują jednocześnie wiele zespołów
  • Systemy produkcyjne muszą zostać szybko zmienione, a oceny się różnią
  • Oprogramowanie jest technicznie gotowe, ale odbiór i tak nie dochodzi do skutku
  • Stare systemy i nowe wymagania zderzają się ze sobą, a nikt nie rozwiązuje konfliktu

Przykład z praktyki

Zanonimizowane

Firma mediowa, 80 pracowników, stała tuż przed wymianą centralnego systemu redakcyjnego. Decyzja techniczna była podjęta, umowa podpisana. Ale trzy miesiące przed go-live nie było już jasnego partnera do rozmów: odpowiedzialny architekt odszedł z firmy, nowy zespół ledwo znał stary system, a dział merytoryczny nie ufał już zapewnieniom programistów.

Cztery tygodnie. W tym czasie wiedza została udokumentowana, odpowiedzialności na nowo rozdzielone, a format przekazania opracowany tak, że obie strony go rozumiały. Wdrożenie przebiegło planowo.

Żaden cud, żadna magia. Ktoś po prostu musiał uporządkować przestrzeń.

Jak to przebiega

01

Pierwsza rozmowa trwa 30 minut. Żadnego pitchu, żadnej prezentacji – słucham i zadaję pytania.

02

Potem decyduję, czy mogę pomóc. Jeśli tak, składam konkretną propozycję: co robię, jak długo, ile to kosztuje.

03

Typowe zlecenia trwają od dwóch tygodni do trzech miesięcy. Stawka dzienna na zapytanie.

Kim jestem

Pracuję od ponad 20 lat w projektach IT, głównie tam, gdzie coś się zacina.

Zaczynałem jako programista, potem architekt, a potem coraz częściej w roli, której nikt tak naprawdę nie ogłosił: ten, kto dba o to, żeby decyzje były podejmowane, przekazania realizowane, a konflikty rozwiązywane. Moje wykształcenie jest techniczne: elektrotechnika, studia fizyczne, rozwój .NET i architektura systemów w branżach takich jak media, logistyka, FinTech i przemysł.

Nie jestem konsultantem biznesowym. Nie przynoszę metodyki, którą stosuję wszędzie. Przynoszę ocenę techniczną, doświadczenie w trudnych sytuacjach przejściowych i umiejętność rozmawiania z ludźmi, którzy akurat ze sobą nie rozmawiają.

Co się u Ciebie zacina?

Napisz mi dwa, trzy zdania. Odpowiem w ciągu 24 godzin.

Lub bezpośrednio:

|