<?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>PM Stories &#187; удобство</title>
	<atom:link href="http://pmstories.com/bg/tag/%d1%83%d0%b4%d0%be%d0%b1%d1%81%d1%82%d0%b2%d0%be/feed/" rel="self" type="application/rss+xml" />
	<link>http://pmstories.com/bg</link>
	<description>Истории от света на софтуерното производство и управлението на проекти</description>
	<lastBuildDate>Wed, 04 Apr 2012 16:48:39 +0000</lastBuildDate>
	<language>en</language>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
		<item>
		<title>6 съвета за повишаване на ефективността на програмистите</title>
		<link>http://pmstories.com/bg/2008/09/04/programmers-performance/</link>
		<comments>http://pmstories.com/bg/2008/09/04/programmers-performance/#comments</comments>
		<pubDate>Thu, 04 Sep 2008 15:14:42 +0000</pubDate>
		<dc:creator>Майк Рам</dc:creator>
				<category><![CDATA[Разработка на софтуер]]></category>
		<category><![CDATA[ефективност]]></category>
		<category><![CDATA[комфорт]]></category>
		<category><![CDATA[мотивация]]></category>
		<category><![CDATA[програмисти]]></category>
		<category><![CDATA[производителност]]></category>
		<category><![CDATA[удобство]]></category>

		<guid isPermaLink="false">http://pmstories.com/bg/2008/09/04/programmers-performance/</guid>
		<description><![CDATA[Програмистите са особено племе. Хем са най-обикновени служители (т.е. не изпълняват никакви ръководни функции), хем са високо квалифицирани, скъпи и трудно заменяеми. Това принуждава мениджмънта да се опитва да &#8220;изстиска&#8221; максимална производителност от тях. Само че, поради навик или поради ограничено мислене, единственият механизъм, който повечето мениджъри прилагат, е увеличаване на работното време. За съжаление, [...]]]></description>
			<content:encoded><![CDATA[<p style="text-align: center"><img src="http://pmstories.com/bg/wp-content/uploads/2008/09/developer-2-1.jpg" alt="Developer" /></p>
<p>Програмистите са особено племе. Хем са най-обикновени служители (т.е. не изпълняват никакви ръководни функции), хем са високо квалифицирани, скъпи и трудно заменяеми. Това принуждава мениджмънта да се опитва да &#8220;изстиска&#8221; максимална производителност от тях. Само че, поради навик или поради ограничено мислене, единственият механизъм, който повечето мениджъри прилагат, е увеличаване на работното време. За съжаление, той винаги води до изтощаване &#8211; физическо и психическо &#8211; и до напускането на програмиста, което едва ли е бил целения резултат.</p>
<p>Ето няколко съвета, които ако не пряко, то косвено могат също да доведат до повишаване на производителността на програмиста, без да разрушават неговата мотивация или здраве.</p>
<p><strong>1. Поддържайте съвременни хардуерни конфигурации.</strong></p>
<p>Съвременните информационни технологии се развиват с главоломна скорост. Един компютър, който миналата година е бил последен писък на технологията, днес вече е не само морално остарял, но и не достатъчно ефективен. Ако някои процедури, като компилирането, например, отнемат по 5 минути, това води не само да чиста загуба на време (особено ако тази дейност се извършва по няколко пъти на ден), но и прекъсва творческата мисъл на програмиста. Понякога изчакването на подобна операция може да го изнерви, с което допълнително се нарушава работния му ритъм. Връщането в режим на креативно мислене, може да отнеме до половин час на всяко едно прекъсване. Като вземем предвид и факта, че цената на хардуера е значително по-ниска от заплатата на програмиста, ще разберем, че наистина няма смисъл да се пести от разходите по техническото оборудване, защото качествения хардуер несъмнено води до по-висока производителност.</p>
<p><strong>2. Не карайте програмистите да &#8220;откриват топлата вода&#8221;.</strong></p>
<p>Купете всички компоненти, визуални контроли и библиотеки, които екипът прецени, че могат да свършат работа. Щом едно нещо е разработено от други хора и може да влезе в употреба &#8211; купете го, вместо да карате вашите програмисти да го разработват наново. Възползвайте се от труда и времето, които други хора са инвестирали, вместо да ги инвестирате и вие. Не карайте вашия екип да открива топлата вода отново, а ги фокусирайте върху специфичните особености на предметната област, която автоматизирате.</p>
<p><span id="more-188"></span><strong>3. Създайте комфорт на работното място.</strong></p>
<p>Работата на програмиста е свързана с целодневно седене на едно място и взиране в екрана на монитора. Поради това, удобните бюра и столове, качествените монитори, клавиатури и мишки, са <a href="http://spriipomisli.blogspot.com/2007/09/blog-post_18.html" title="Компютърна ергономия" target="_blank">естествено необходими</a> за качествената работа на програмистите. Един човек, който страда от болка в ставите или в кръста поради неудобна мишка или стол, не може да работи качествено. За да работи максимално ефективно, човек трябва да бъде здрав. Качествените мебели гарантират доброто здраве на екипа.</p>
<p>Към тази точка трябва да се добави доброто проветрение и отопление на офиса.</p>
<p><strong>4. Не губете времето на хората излишно.</strong></p>
<p>Някои мениджъри изпитват някакво нарцистично желание да говорят дълго и безцелно пред хората и затова организират чести, продължителни и безполезни срещи, на които присъствието на целия екип е задължително. Това е сериозен принос към намаляване на ефективността на програмистите. За да го избегнете, спазвайте следните правила:</p>
<ul>
<li>Организирайте екипни срещи само ако са крайно наложителни</li>
<li>На срещите поканете само хората, които имат отношение към темата</li>
<li>Изгответе предварителен дневен ред и се придържайте строго към него</li>
<li>Планирайте срещите за не повече от 30 минути</li>
</ul>
<p><strong>5. Погрижете се за професионалното обучение и развитие на екипа</strong></p>
<p>Много често, още при постъпването си на работа, хората биват засипани със задачи и тяхното ежедневие още от първия ден се превръща в &#8220;гасене на пожари&#8221;. Случва се така, че дори и да могат да решат някой технически проблем, доста програмисти не разбират смисъла на това, което правят. Отделно, новите технологии, които се появяват на пазара, често биват игнорирани под претекст, че имаме твърде много работа.</p>
<p>Изключително важно е, за да могат програмистите да се развиват професионално и да могат да си вършат работата с разбиране, да се създаде система на наставничество (mentorship). Хората с повече опит и знания трябва да ги предават на по-младите си колеги, обучавайки ги в процеса на работа. За целта, при планиране на задачите, винаги трабва да се оставя време както за обучение в предметната област на фирмата, така и за разучаване и тестване на новите продукти, които излизат на пазара. Твърде вероятно е някой нов продукт да може да реши нашите технологични проблеми и да ускори производителността на екипа.</p>
<p><strong>6. Правете ревюта на кода (code reviews)<br />
</strong></p>
<p>Ревютата на кода са отдавна доказана добра практика в програмирането, въпреки че все още не се практикува достатъчно масово. Този подход не само създава унифициран стил в писането на код, но и дава възможност да се отстраняват съществени греши още в зародиш, спестявайки изключително ценно време и ресурси от по-късните фази. Чрез ревютата на кода програмистите могат и да обменят идеи, които да доведат до измислянето на ефективни решения, ускоряващи процеса на работа или повишаващи качеството на разработвания продукт.</p>
<p>Сигурно вие можете да се сетите и за други добри идеи, които биха довели до повишаване на производителността на програмистите, вместо традиционното удължаване на работния ден. Ще се радвам да ги споделите в коментар по-долу.</p>
<p><em>Гласувайте за тази статия в <a href="http://svejo.net/" target="_blank">Svejo.net</a>:</em> </p>
<p><img src="http://www.feedburner.com/fb/images/pub/feed-icon32x32.png" align="left" vspace="10" width="32" height="32" hspace="10" /><em>Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се за съдържанието му <a href="http://feeds.feedburner.com/PmStoriesBg" rel="alternate" type="application/rss+xml">чрез RSS feed</a> или <a href="http://www.feedburner.com/fb/a/emailverifySubmit?feedId=1527753&amp;loc=en_US">по имейл</a></em>.</p>
<h3  class="related_post_title">Вижте и тези публикации:</h3><ul class="related_post"><li><a href="http://pmstories.com/bg/2011/10/25/classic-mistakes-demotivation/" title="Класическите грешки: Демотивация на екипа">Класическите грешки: Демотивация на екипа</a></li><li><a href="http://pmstories.com/bg/2011/02/20/those-who-risk-win/" title="Да си се похваля или &#8220;който рискува &#8211; пичели&#8221;">Да си се похваля или &#8220;който рискува &#8211; пичели&#8221;</a></li><li><a href="http://pmstories.com/bg/2009/07/10/funny-computer-quotes/" title="Петък &#8211; ден на майстора. Забавни компютърни цитати">Петък &#8211; ден на майстора. Забавни компютърни цитати</a></li><li><a href="http://pmstories.com/bg/2008/11/13/what-experienced-pms-know/" title="Какво знаят опитните проджект мениджъри?">Какво знаят опитните проджект мениджъри?</a></li><li><a href="http://pmstories.com/bg/2008/11/04/1000-leva-results/" title="Хиляда лева за мотивация. Резултати от анкетата">Хиляда лева за мотивация. Резултати от анкетата</a></li></ul>]]></content:encoded>
			<wfw:commentRss>http://pmstories.com/bg/2008/09/04/programmers-performance/feed/</wfw:commentRss>
		<slash:comments>7</slash:comments>
		</item>
		<item>
		<title>Промяната &#8211; необходимото зло или естествена форма на прогреса</title>
		<link>http://pmstories.com/bg/2008/02/27/change-necessary-evil/</link>
		<comments>http://pmstories.com/bg/2008/02/27/change-necessary-evil/#comments</comments>
		<pubDate>Wed, 27 Feb 2008 10:54:23 +0000</pubDate>
		<dc:creator>Майк Рам</dc:creator>
				<category><![CDATA[Лидерство]]></category>
		<category><![CDATA[Лични]]></category>
		<category><![CDATA[Управление на проекти]]></category>
		<category><![CDATA[навик]]></category>
		<category><![CDATA[планиране]]></category>
		<category><![CDATA[промяна]]></category>
		<category><![CDATA[страх]]></category>
		<category><![CDATA[удобство]]></category>

		<guid isPermaLink="false">http://pmstories.com/bg/2008/02/27/change-necessary-evil/</guid>
		<description><![CDATA[Промяната е нещо, което повечето хора не обичат. Рутината и навика лесно завладяват нашето съзнание и винаги се чувстваме по-удобно в познатите коловози на ежедневието, отколкото в плашещите дебри на непознатото. Промяната е най-големият страх за всички проджект мениджъри. Голяма част от методологиите и теориите на управлението разчитат, че нещата ще бъдат относително стабилни. Плановете, [...]]]></description>
			<content:encoded><![CDATA[<p>Промяната е нещо, което повечето хора не обичат. Рутината и навика лесно завладяват нашето съзнание и винаги се чувстваме по-удобно в познатите коловози на ежедневието, отколкото в плашещите дебри на непознатото.</p>
<p>Промяната е най-големият страх за всички проджект мениджъри. Голяма част от методологиите и теориите на управлението разчитат, че нещата ще бъдат относително стабилни. Плановете, които правим постоянно, имат по-голяма стойност, ако обстоятелствата не се променят.</p>
<p>Така е, но животът постоянно ни показва, че е динамичен и променлив и <strong>колкото повече се съпротивляваме</strong> срещу този факт и не искаме да приемем промяната, която се случва около нас, <strong>толкова повече страдаме</strong>.</p>
<p><span id="more-124"></span>Този, който приеме промяната и я използва, има по-голям шанс за успех от онзи, който си затваря очите за нея или яростно я отрича. Промяната е това, което движи прогреса. Понякога е досадно неудобство, което нарушава собствения ни комфорт, а друг път е тежък стрес, който може да ни доведе до отчаяние, но в крайна сметка, това е животът и този, който не го разбира, губи.</p>
<p>Попаднах на един пост, озаглавен <a href="http://13c4.wordpress.com/2007/02/24/50-reasons-not-to-change/" target="_blank">50 причини да не се промениш</a>, където авторите са събрали най-популярните оправдания за това да отречеш промяната и са ги представили като една стена от бележки. Колко пъти сте чували (или изричали):</p>
<ul>
<li>Това не може да стане</li>
<li>Нямам време</li>
<li>Твърде сложно е</li>
<li>Твърде скъпо е</li>
<li>И така си ни е добре</li>
<li>Това не е моя работа</li>
</ul>
<p>Дали тези оправдания не са защитна реакция на човек, който не иска да види промяната или просто се страхува от нея?</p>
<p><em>Гласувайте за тази статия в <a href="http://svejo.net/" target="_blank">Svejo.net</a>:</em> </p>
<p><strong><u>Рекламно съобщение:</u> Посетете <a href="http://pmstories.com/bg/2008/02/20/spm-fundamentals-march/">курса по основи на управлението на софтуерни проекти</a>, който ще се проведе на 13.03.2008 г. в София. </strong><strong>Повече информация за него можете да намерите <a href="http://pmstories.com/bg/2008/02/20/spm-fundamentals-march/" target="_blank">тук</a>, в блога <a href="http://spriipomisli.blogspot.com/2008/02/blog-post_26.html">Спри и помисли!</a> и на официалния сайт на <a href="http://www.rammsoft.com/en/2008/02/20/spm-fundamentals-march/" target="_blank">RammSoft</a>.</strong></p>
<p><img src="http://www.feedburner.com/fb/images/pub/feed-icon32x32.png" align="left" height="32" hspace="10" vspace="10" width="32" /><em>Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин <a href="http://feeds.feedburner.com/PmStoriesBg" rel="alternate" type="application/rss+xml">чрез RSS feed</a> или <a href="http://www.feedburner.com/fb/a/emailverifySubmit?feedId=1527753&amp;loc=en_US">по имейл</a></em>.</p>
<h3  class="related_post_title">Вижте и тези публикации:</h3><ul class="related_post"><li><a href="http://pmstories.com/bg/2009/02/04/moscow-method/" title="Приоритизация на изискванията по метода MoSCoW">Приоритизация на изискванията по метода MoSCoW</a></li><li><a href="http://pmstories.com/bg/2008/11/13/what-experienced-pms-know/" title="Какво знаят опитните проджект мениджъри?">Какво знаят опитните проджект мениджъри?</a></li><li><a href="http://pmstories.com/bg/2008/09/04/programmers-performance/" title="6 съвета за повишаване на ефективността на програмистите">6 съвета за повишаване на ефективността на програмистите</a></li><li><a href="http://pmstories.com/bg/2008/08/27/ba-every-day/" title="Ежедневието ми на бизнес аналитик">Ежедневието ми на бизнес аналитик</a></li><li><a href="http://pmstories.com/bg/2007/12/18/how-to-estimate-the-projects-budget-2/" title="Как оценяте бюджета на един проект? Резултати от анкетата">Как оценяте бюджета на един проект? Резултати от анкетата</a></li></ul>]]></content:encoded>
			<wfw:commentRss>http://pmstories.com/bg/2008/02/27/change-necessary-evil/feed/</wfw:commentRss>
		<slash:comments>1</slash:comments>
		</item>
	</channel>
</rss>

