<?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/%d0%bf%d1%80%d0%be%d0%b8%d0%b7%d0%b2%d0%be%d0%b4%d1%81%d1%82%d0%b2%d0%be-%d0%bd%d0%b0-%d1%81%d0%be%d1%84%d1%82%d1%83%d0%b5%d1%80/feed/" rel="self" type="application/rss+xml" />
	<link>http://pmstories.com/bg</link>
	<description>Истории от света на софтуерното производство и управлението на проекти</description>
	<lastBuildDate>Mon, 10 May 2010 14:20:06 +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>10-те най-важни грешки в разработката на софтуер, според InfoWorld Tech Watch</title>
		<link>http://pmstories.com/bg/2007/07/22/10-biggest-mistakes-in-software-development/</link>
		<comments>http://pmstories.com/bg/2007/07/22/10-biggest-mistakes-in-software-development/#comments</comments>
		<pubDate>Sun, 22 Jul 2007 15:20:00 +0000</pubDate>
		<dc:creator>Майк Рам</dc:creator>
				<category><![CDATA[Класически грешки]]></category>
		<category><![CDATA[Разработка на софтуер]]></category>
		<category><![CDATA[Управление на проекти]]></category>
		<category><![CDATA[Грешки]]></category>
		<category><![CDATA[производство на софтуер]]></category>

		<guid isPermaLink="false">http://pmstories.com/bg/2007/07/22/10-%d1%82%d0%b5-%d0%bd%d0%b0%d0%b9-%d0%b2%d0%b0%d0%b6%d0%bd%d0%b8-%d0%b3%d1%80%d0%b5%d1%88%d0%ba%d0%b8-%d0%b2-%d1%80%d0%b0%d0%b7%d1%80%d0%b0%d0%b1%d0%be%d1%82%d0%ba%d0%b0%d1%82%d0%b0-%d0%bd%d0%b0/</guid>
		<description><![CDATA[Наскоро, в блога InfoWorld Tech Watch открих един пост, озаглавен 10 mistakes to avoid in software development (&#8220;10 грешки, които да избягваме в софтуерното производство&#8221;), където цитират резултатите от едно проучване на Forrester Research, публикувани наскоро. Въпреки, че принципно съм съгласен с това, че списъкът представя едни от най-важните грешки, които могат да доведат всеки [...]]]></description>
			<content:encoded><![CDATA[<p>Наскоро, в блога <a href="http://weblog.infoworld.com/techwatch/">InfoWorld Tech Watch</a> открих един пост, озаглавен <a href="http://weblog.infoworld.com/techwatch/archives/012722.html">10 mistakes to avoid in software development</a> (&#8220;10 грешки, които да избягваме в софтуерното производство&#8221;), където цитират резултатите от едно проучване на <a href="http://www.forrester.com/rb/">Forrester Research</a>, публикувани наскоро. Въпреки, че принципно съм съгласен с това, че списъкът представя едни от най-важните грешки, които могат да доведат всеки проект до неуспех, ще навляза в малко по-дълбоки детайли и ще коментирам всяка една от тях.</p>
<p>Ето го и самият списък с 10-те грешки, които трябва да избягваме при разработката на софтуер (Както и в други постове, не съм превел оригиналния текст, за да не бъда обвиняван в идиотски превод. Вярвам, че няма да се затрудните с това.):</p>
<p><span id="more-22"></span></p>
<ol>
<li><span style="font-weight: bold">Never committing to project success</span>. Това е твърде очевидно и тривиално. Естествено е, че ако не си отдаден на успеха, няма да го постугнеш. Не виждам никаква мъдрост тук.</li>
<li><span style="font-weight: bold">Freezing the schedule and budget before a project is sufficiently understood</span>. За съжаление, това се случва винаги и навсякъде, особено у нас. Според мене, това е основният проблем на управлението на софтуерни проекти: какво да направим, когато ни питат за оценка на времето и цената, или пък ни карат да подпишем договор за това, при положение, че въобще не сме наясно какво точно трябва да се прави в даден проект?</li>
<li><span style="font-weight: bold">Overscoping a solution</span>. Да, това е грешка, но аз мисля, че тя се случва все по-рядко в наши дни.</li>
<li><span style="font-weight: bold">Circumventing the application development organization altogether</span>. Тук може би ще трябва да сложа някакъв превод, за да стане ясен и коментара ми. Доколкото знанията ми по английски се простират, това трябва да се преведе така: <span style="font-style: italic">&#8220;Заобикаляне на организацията по разработка на приложения&#8221;</span>. Не мисля, че това винаги е грешка, особено ако човек е наясно какво прави. Понякога даже е наложително да се прескочат всички правила, особено ако си бил &#8220;насаден&#8221; на проект от типа &#8220;Death March&#8221;. Истинският въпрос, все пак е: Можеш ли дори и при тези обстоятелства да доведеш проекта до успех?</li>
<li><span style="font-weight: bold">Underestimating the complexity of a problem</span>. Обикновено това е най-важната причина за подписване на договори с ниски бюджети и съкратени срокове. За съжаление, тази грешка най-често се прави от висшия мениджмънт, най-вече поради това, че не се консултират с екипа си (или му нямат доверие). Вярвам, че всяка компания трябва да инвестира повече време преди да подпише договор или да даде някакво обещание, през който период да се проведе задълбочено проучване на нуждите и проблемите на клиента, за да се придобие по-вярна представа за сложността на задачата.</li>
<li><span style="font-weight: bold">Being stingy with subject-matter experts, in which their participation is not sufficient</span>. Това е резултат от предишната грешка.</li>
<li><span style="font-weight: bold">Choosing the wrong project leadership</span>. Or the wrong leaders. Or the wrong managers. Or the wrong customers (Can there be wrong customers?) Без превод.</li>
<li><span style="font-weight: bold">Distrusting managers who have had tasks delegated to them</span>. Мисля, че липсата на доверие към когото и да е в една фирма или екип, е ключова грешка.</li>
<li><span style="font-weight: bold">Jumping into development without enough research</span>. Отново, това се случва поради подценяване на проблема, който трябва да се реши с дадения проект.</li>
<li><span style="font-weight: bold">Suppressing bad news, in which dialogue is insufficient</span>. Сучайно да познавате мениджър, който обича да чува лоши новини?</li>
</ol>
<p>Някои могат да кажат, че съм скептик или песимист. Не, не съм такъв човек. Виждам, че в нашата индустрия има много проблеми, но въпреки това обичам професията си. Наистина искам да открием кои са най-големите грешки, които правим, да изследваме причините за тяхното появяване и да измислим план как да ги предотвратим. Което е много трудно. И когато анализираме нашите грешки, трябва да бъдем по-конкретни, особено когато търсим причините за тяхното възникване.</p>
<p><span style="font-weight: bold"></span><img vspace="10" align="left" width="32" src="http://www.feedburner.com/fb/images/pub/feed-icon32x32.png" hspace="10" height="32" /><em>Ако харесвате статиите в този блог и се интересувате от тематиката, която разглеждаме, за да си гарантирате, че няма да изпуснете публикация, абонирайте се напълно безплатно за нашия бюлетин <a rel="alternate" type="application/rss+xml" href="http://feeds.feedburner.com/PmStoriesBg">чрез 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/2008/11/13/what-experienced-pms-know/" title="Какво знаят опитните проджект мениджъри?">Какво знаят опитните проджект мениджъри?</a></li><li><a href="http://pmstories.com/bg/2008/04/04/bad-technical-presentation/" title="Как не се прави презентация">Как не се прави презентация</a></li></ul>]]></content:encoded>
			<wfw:commentRss>http://pmstories.com/bg/2007/07/22/10-biggest-mistakes-in-software-development/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
