<?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%82%d0%b5%d1%85%d0%bd%d0%b8%d0%ba%d0%b8/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>Техники за събиране на изисквания</title>
		<link>http://pmstories.com/bg/2008/01/29/requirements-gathering-techniques/</link>
		<comments>http://pmstories.com/bg/2008/01/29/requirements-gathering-techniques/#comments</comments>
		<pubDate>Tue, 29 Jan 2008 11:30:08 +0000</pubDate>
		<dc:creator>Майк Рам</dc:creator>
				<category><![CDATA[Бизнес анализ]]></category>
		<category><![CDATA[събиране на изисквания]]></category>
		<category><![CDATA[техники]]></category>

		<guid isPermaLink="false">http://pmstories.com/bg/2008/01/29/requirements-gathering-techniques/</guid>
		<description><![CDATA[Наскоро ми попадна една статия, озаглавена 10 техники за събиране на изисквания. Tom Mochal е много авторитетен експерт в областта на проджект мениджмънта и аз много ценя неговото мнение, но някои от нещата, описани в тази статия ми изглеждат съвсем тривиални, като обсъждане с един човек, обсъждане с двама човека и обсъждане с 3-4 човека.
По-интересно [...]]]></description>
			<content:encoded><![CDATA[<p>Наскоро ми попадна една статия, озаглавена <a href="http://blogs.techrepublic.com.com/10things/?p=287" target="_blank">10 техники за събиране на изисквания</a>. Tom Mochal е много авторитетен експерт в областта на проджект мениджмънта и аз много ценя неговото мнение, но някои от нещата, описани в тази статия ми изглеждат съвсем тривиални, като обсъждане с един човек, обсъждане с двама човека и обсъждане с 3-4 човека.</p>
<p>По-интересно за мен беше това, че той посочва някои техники, които ми се струва, че не са толкова популярни, а според мен са изключително ефективни. Затова реших да се спра на тях и ги разгледам по-детайлно.</p>
<p><span id="more-108"></span></p>
<ul>
<li><strong>Наблюдение</strong>. Много често клиентът идва и ни представя своето виждане за това как трябва да изглежда новия продукт и какво трябва да прави без да може да обясни какъв точно е настоящият бизнес процес в неговата компания, нито как той ще се промени и подобри с внедряването на новото софтуерно решение. Един от най-ефективните подходи за разучаване на бизнес процеса, както и за навиците и нивото на техническа грамотност на потребителите, е просто да стоиш до тях и да наблюдаваш техните ежедневни действия. При наблюдението може много лесно <strong>да се видят недостатъци в работата, прекалено сложни или направо ненужни действия, които биха могли да бъдат отстранени, както и да ни хрумнат много идеи за подобряване на ефективността на процеса</strong>, а и оттам реална печалба за клиента от внедряване на новото софтуерно решение. Още по-добрият вариант е ако бизнес анализаторите сами имат възможността да поработят в условията, в които работи реалния потребител.<br />
За съжаление, много често сме притиснати от кратки срокове, особено във фазата на анализа (което е голяма грешка!) и рядко използваме този механизъм за събиране на информация.<br />
Понякога самият клиент, под предлог, че неговият процес е секретен, не ни разрешава достъп до хората, които го практикуват. В такива случаи трябва дебело да подчертаем пред него, че това е риск за правилното разбиране на заданието и съответно за успешното реализиране на проекта. Ако в последствие забележим трайна тенденция у клиента към укриване на информация, добре е да се замислим дали неговата цел е успешното завършване на този проект или нещо съвсем друго.</li>
<li><strong>Brainstorming</strong>. Поредната непреводима на български дума. Брейнстормингът е техника, която работи успешно в много случаи и анализът на изискванията е един от тях. По време на такава сесия, хората са освободени от задръжки и успяват да развихрят въображението си максимално, което <strong>води до генерирането на огромно разнообразие от идеи</strong>, някои от които могат да се окажат изключително ефективни. Много често възложителят сам не е в състояние да измисли изискванията към продукта, защото самият продукт ще трябва да работи в среда, която в момента не съществува &#8211; един нов процес, който тепърва трябва да бъде измислен. <strong>Брейнстормингът е много ефективен начин да помогнем на нашия клиент да изясни за себе си какво трябва да се направи</strong>, за да бъде продуктът успешен.</li>
<li><strong>Разработване на прототип</strong>. Този метод е един от най-добрите в софтуерния бизнес, но за сметка на това е и един от най-скъпите. Най-добре приложим е в проекти, където се разработва нещо съвсем ново и уникално като концепция и където <strong>качеството на резултата е по-важно от цената</strong>. Разработката на софтуер е много специфичен бизнес и една от най-важните му характеристики е неговата абстрактност &#8211; той не може да се види и да се пипне, още по-малко докато е в процес на разработка. Затова, каквото и да си говорим с клиента, каквито и спецификации да обсъждаме, винаги съществува една голяма вероятност да не сме се разбрали правилно и в момента, в който му представим нашия продукт, той да се окаже неприятно изненадан. Разработката на прототип ни предпазва от това, като ни <strong>дава възможността на един много ранен етап да покажем &#8220;на живо&#8221; възможностите на поръчания продукт</strong>. Когато потребителят го &#8220;пипне&#8221; и усети, тогава ще има много по-ясна представа дали това, което ще получи, е точно това, което му трябва и ако не е &#8211; ще има възможността да коригира изискванията си достатъчно рано, че те да могат да бъдат имплементирани.</li>
</ul>
<p>Тези техники не са единствените възможни, но са изключително ефективни. За съжаление, има много случаи, в които не ни се удава възможност да ги ползваме, особено в проекти, за които се прави търг, и в които много рядко се дава възможност за общуване с клиента преди да се подаде официалната оферта с техническото предложение и цената. Много често се налага да правим анализ на процесите след като имаме подписан договор и поети ангажименти, което ни поставя в много неприятна ситуация.</p>
<p>Ще се радвам да споделите примери от вашата практика &#8211; какви методи ползвате и дали винаги успявате да ги приложите?</p>
<p><em>Този пост е достъпен и <a href="http://pmstories.com/en/2008/01/29/requirements-gathering-techniques/">на английски език</a>. </em></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" 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/05/14/careful-with-the-requirements/" title="Внимавайте с изискванията на клиента!">Внимавайте с изискванията на клиента!</a></li><li><a href="http://pmstories.com/bg/2010/03/15/good-news-for-ba/" title="Добри новини за онези, които се интересуват от бизнес анализ">Добри новини за онези, които се интересуват от бизнес анализ</a></li><li><a href="http://pmstories.com/bg/2009/07/29/iiba-updates-certificate-exam/" title="Международният институт по бизнес анализ обновява сертификационният си изпит">Международният институт по бизнес анализ обновява сертификационният си изпит</a></li><li><a href="http://pmstories.com/bg/2009/02/02/iiba-bulgarian-chapter/" title="Българската секция на Международния институт по бизнес анализ е вече факт">Българската секция на Международния институт по бизнес анализ е вече факт</a></li><li><a href="http://pmstories.com/bg/2008/12/02/the-benefits-of-business-analysis/" title="Ползата от бизнес анализа">Ползата от бизнес анализа</a></li></ul>]]></content:encoded>
			<wfw:commentRss>http://pmstories.com/bg/2008/01/29/requirements-gathering-techniques/feed/</wfw:commentRss>
		<slash:comments>4</slash:comments>
		</item>
	</channel>
</rss>
