Chciałbym bowiem rozstrzygnąć, co w projektach IT jest najważniejsze: szybko, tanio, czy dobrze. Tych zaś, co pragną wszystkiego tego na raz, odsyłam do Pana Kazia - znajomego speca od wykończeń wszelakich. U niego zawsze jest tanio, fachowo i na termin

Zastanawiałem się, jak lepiej rozumieć myśli i intencje innych osób. W moim najnowszym artykule „Mind Reading w praktyce” analizuję tajniki czytania ludzkiego umysłu, przedstawiając skuteczne techniki oraz praktyczne zastosowania tej umiejętności. Pokazuję, jak możesz wykorzystać zdobytą wiedzę w codziennych interakcjach i życiu zawodowym, aby budować silniejsze relacje i efektywniej komunikować się z otoczeniem.

Jeden z ostatnich Event Stormingów zajął 5 osobowej grupie 6 spotkań po 3h. W sumie mamy 90 osobogodzin. Do estymacji przyjmę stawkę godzinową dla analityka pracującego na umowie b2b, czyli ok. 85PLN/h netto. Zatem koszt cyklu warsztatów szacuję na 7 560PLN + koszty prowadzenia. Czy to dużo czy mało?

Podejmowanie decyzji w zespole może być skomplikowane, ale odpowiednie podejście potrafi przekształcić wyzwania w sukcesy. W moim najnowszym artykule „Jak podejmować decyzje w zespole” dzielę się sprawdzonymi strategiami i praktycznymi wskazówkami, które pomogą Twojemu zespołowi osiągać lepsze rezultaty. Dowiesz się, jak skutecznie komunikować się, angażować wszystkich członków oraz unikać typowych błędów w procesie decyzyjnym.

Agile Coach - co może pójść nie tak? :)

Przedstawiam szczegółowe case study dotyczące usprawniania procesów dostarczania w zespole. Dowiedz się, jakie strategie zastosowałem, aby zwiększyć efektywność i satysfakcję klientów. Zachęcam do przeczytania pełnej analizy!

Lubię story pointy, mam do nich sentyment. To fajny pomysł, którego zastosowanie omówiłem już we wspomnianym artykule. Z drugiej strony uważam, że choćby koncepcja była najświętsza, to jeśli nie wytrzymuje próby rzeczywistości, trzeba ją odrzuć. Tako i przyszła kreska na story pointy.

Któryś z ThoughtWorks Technology Radar zaleca organizacjom przetestowanie podejścia diagrams as code, czyli tworzenie diagramu "z palca" w tekście, zamiast wyklikiwania go w jakimś wizualnym narzędziu. W tym artykule chciałbym rozszerzyć tą koncepcję, że nie tylko diagrams, lecz i cała dokumentacja powinna być pisana tak jak kod.

Kontynuując świecką tradycję, z okazji Nowego Roku publikuję post inny refleksyjny i trochę "od czapy". Trzymasz się?