<?xml version="1.0" encoding="UTF-8"?>
<rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:wfw="http://wellformedweb.org/CommentAPI/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
	xmlns:slash="http://purl.org/rss/1.0/modules/slash/"
	>

<channel>
	<title>...prosto do celu &#187; zespół</title>
	<atom:link href="http://www.michalski.eu/index.php/tag/zespol/feed" rel="self" type="application/rss+xml" />
	<link>http://www.michalski.eu</link>
	<description>Paweł Michalski</description>
	<lastBuildDate>Thu, 25 Feb 2010 14:23:32 +0000</lastBuildDate>
	<generator>http://wordpress.org/?v=2.9.2</generator>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
			<item>
		<title>Jak krytykować by wzmocnić zespół</title>
		<link>http://www.michalski.eu/index.php/202/jak-krytykowac-i-chwalic</link>
		<comments>http://www.michalski.eu/index.php/202/jak-krytykowac-i-chwalic#comments</comments>
		<pubDate>Sat, 13 Feb 2010 10:02:51 +0000</pubDate>
		<dc:creator>Pablo</dc:creator>
				<category><![CDATA[Systemy informatyczne]]></category>
		<category><![CDATA[Zarządzanie]]></category>
		<category><![CDATA[krytyka]]></category>
		<category><![CDATA[pochwała]]></category>
		<category><![CDATA[praca zespołowa]]></category>
		<category><![CDATA[problemy]]></category>
		<category><![CDATA[zespół]]></category>

		<guid isPermaLink="false">http://www.michalski.eu/?p=202</guid>
		<description><![CDATA[Często pod wpływem emocji krytykujemy współpracowników lub podwładnych. Krytyka, mimo iż czasami  potrzebna powinna być konstruktywna. Tylko konstruktywna krytyka ma szanse przynieść w przyszłości owoce w postaci lepszej współpracy w zespole. Błędne stosowanie krytyki lub jej nadużywanie może bowiem spowodować narastanie napięcia i doprowadzić do ślepego wzajemnego wytykania sobie błędów.
Jak więc krytykować aby nieść korzyści [...]]]></description>
			<content:encoded><![CDATA[<div id="attachment_250" class="wp-caption alignright" style="width: 310px"><a href="http://www.michalski.eu/wp-content/uploads/2010/02/liny.jpg"><img class="size-medium wp-image-250 " title="Zespół" src="http://www.michalski.eu/wp-content/uploads/2010/02/liny-300x225.jpg" alt="" width="300" height="225" /></a><p class="wp-caption-text">photo © Natthawut Kulnirundorn for openphoto.net</p></div>
<p>Często pod wpływem emocji krytykujemy współpracowników lub podwładnych. Krytyka, mimo iż czasami  potrzebna powinna być konstruktywna. Tylko konstruktywna krytyka ma szanse przynieść w przyszłości owoce w postaci lepszej współpracy w zespole. Błędne stosowanie krytyki lub jej nadużywanie może bowiem spowodować narastanie napięcia i doprowadzić do ślepego wzajemnego wytykania sobie błędów.</p>
<p>Jak więc krytykować aby nieść korzyści dla siebie i innych? Myślę, że dobrze będzie to opisać w oparciu o przykład z życia wzięty:</p>
<p>W pewnym przedsiębiorstwie informatycznym programista dostaje premię pomniejszaną o pewna wartość zależną od ilości popełnionych błędów w danym miesiącu. Im wyższej kategorii błąd, tym większe potrącenie z premii. Taki sposób premiowania programisty ma na celu doprowadzenie do sytuacji gdzie programista dokładnie się zastanawia nad pisanym kodem i nad jego rzetelnym testowaniem. W ten sposób nie powinien dopuścić do pojawienia się problemów w systemie u klientów.</p>
<p>Pewnego razu w systemie pojawia się &#8220;błąd aplikacji uniemożliwia pracę&#8221;. Błąd taki jest w firmie błędem &#8220;newralgicznym&#8221;, za który jest potrącana spora część premii. Przełożony programisty dostaje sygnał od zdenerwowanego klienta. I sam pod wpływem emocji wpisuje programiście, do systemu kontrolującego pracę w firmie, błąd newralgiczny ze skąpym opisem: &#8220;Nie da się składać zamówień&#8221; . Programista widzi w systemie &#8220;sucho&#8221; opisany błąd. Analizuje sprawę i okazuje się, że błąd występuje w wyjątkowych, specyficznych okolicznościach, których nie dało się odtworzyć w warunkach testowych.</p>
<p><span id="more-202"></span></p>
<p>Co się dzieje:</p>
<ul>
<li>jest wściekły bo błąd występuje w specyficznym przypadku (nie mógł wyjść w trakcie standardowych testów i nikt nie przewidział tego w trakcie opisywania założeń),</li>
<li>wiedząc, że nie jest możliwe aby taki błąd powstał po jego modyfikacjach kodu programu, który modyfikował w ciągu ostatnich kilku dni &#8211;  ma poczucie niesprawiedliwości,</li>
<li>w jego głowie zmienia się cel tego zadania, z: &#8220;zrobić łady formularz za który ktoś go pochwali&#8221;, na obarczony złością: &#8220;udowodnić, że szef nie ma racji&#8221;,</li>
<li>cel zostaje osiągnięty pozostaje satysfakcja z&#8230;? nie, niestety nie z poprawy błędu tylko z pokazania, że &#8220;się szefie myliłeś bo to nie mój błąd tylko projektanta!&#8221;,</li>
<li>po godzinach gdy spotykają się z innymi pracownikami przy piwie obgadują jak to szef wytyka błędy na siłę i jaki to &#8220;on jest w ogóle nie dobry&#8221; itd.</li>
<li>pewnego dnia pracownik dostaje ofertę pracy u konkurencji za większą stawkę, nie zastanawia się co zrobić, możliwe, że nawet nie prosi o rozmowę tylko od razu wypowiada umowę o pracę,</li>
<li>w sytuacji gdy nowy pracodawca chciał by wykupić ludzi  lub wiedzę z opisywanej firmy nie będzie miał z tym  problemu, bo można kilka osób na raz zabrać konkurentowi do siebie.</li>
</ul>
<p>Dlatego ważne jest aby dokładnie zastanowić się nad sposobem w jaki się krytykuje. Mimo, że to nie jest proste. Powinniśmy starać się pamiętać, że:</p>
<ul>
<li>krytyka powinna być stosowana natychmiast po udowodnieniu błędu,</li>
<li>powinna być konstruktywna (powinna sugerować rozwiązanie),</li>
<li>musi umożliwiać naprawę błędu,</li>
<li>ma być skierowana na problem, a nie na osobę (mów &#8220;<em>to&#8221;</em> a nie &#8220;<em>ty&#8221;</em>, mów &#8220;<em>źle zrobione&#8221;</em>, a nie &#8220;<em>źle zrobiłeś&#8221;)</em>.</li>
</ul>
<p>Pamiętając o tych zasadach, przedstawiony wcześniej przykład z programistą mógłby wyglądać w ten sposób:</p>
<ul>
<li>po zgłoszeniu błędu przełożony idzie do programisty i pokazuje gdzie leży problem,</li>
<li>programista jest równie jak przełożony zdziwiony, więc analizują problem razem,</li>
<li>programista widzi wsparcie i zainteresowanie nietypowym problemem (nie jest sam, ma się kogo doradzić i komu pochwalić się, że znalazł problem i sposób jego rozwiązania),</li>
<li>przełożony widząc, że błąd jest natury losowej uśmiecha się i dziękuje pracownikowi za szybkie jego rozwiązanie,</li>
<li>po godzinach pracy pracownicy się spotykają przy piwie i jeden z nich narzeka na szefa, ale programista mówi, że pewnie szef jest zmęczony bo był ciężki dzień, opowiada o tym jak pomógł mu dzisiaj rozwiązać problem&#8230;</li>
<li>dalej w sytuacji gdy konkurencja kombinuje jak wykraść zasoby firmy pracownicy widząc w osobie szefa dobrego człowieka nie dadzą się łatwo przekonać na zmianę pracodawcy i jest duża szansa, że ktoś nawet szefa poinformuje o próbach podkupienia przez konkurencje.</li>
</ul>
<p>To trochę przesadny opis ale może przynajmniej odrobinę przybliża konsekwencje nieodpowiedniego stosowania dwóch potężnych narzędzi jakimi są: KRYTYKA (i pochwała). Trzeba też pamiętać, że zasoby ludzkie to w większości firm najważniejszy zasób, a jednocześnie najbardziej delikatny. Komputer, pieniądze i produkty się na Ciebie nie obrażą, a ludzie tak. Pieniądze i meble same nie odejdą, a ludzie tak.</p>
]]></content:encoded>
			<wfw:commentRss>http://www.michalski.eu/index.php/202/jak-krytykowac-i-chwalic/feed</wfw:commentRss>
		<slash:comments>371</slash:comments>
		</item>
	</channel>
</rss>
