<?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>潜心于现在，未来 &#187; 读书札记</title>
	<atom:link href="http://blog.yamone.com/category/reading-note/feed/" rel="self" type="application/rss+xml" />
	<link>http://blog.yamone.com</link>
	<description>率性之谓道</description>
	<lastBuildDate>Fri, 07 May 2010 14:12:12 +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://blog.yamone.com/reading-note/the-mythical-man-month-reading-note1/</link>
		<comments>http://blog.yamone.com/reading-note/the-mythical-man-month-reading-note1/#comments</comments>
		<pubDate>Wed, 23 Jan 2008 05:25:31 +0000</pubDate>
		<dc:creator>Amom</dc:creator>
				<category><![CDATA[读书札记]]></category>
		<category><![CDATA[软件开发]]></category>
		<category><![CDATA[人月神话]]></category>

		<guid isPermaLink="false">http://blog.yamone.com/?p=22</guid>
		<description><![CDATA[



这几天在上下班的路上一直在读《人月神话》，目前已经读完了10章，感觉收获了一些东西。这本书给我的最深的感受就是对味，你在项目里碰到的种种不爽之处，你所参与过的失败项目的原因，几乎都在这里被娓娓到来。当然，感受到这些的前提是你已经参与过大量的大大小小的项目。
实际上，抛开技术方面而就项目沟通、管理来说，各行各业的项目在很多问题上是一样的。我觉得最大的问题在于当项目的管理者（不管是间接还是直接的）的所作所为不是单纯的为了项目本身的目标抑或是在某种情形下忘记了项目真正的目标。这种时候，项目开始慢慢偏离轨道，最后不知道驶向了何方！
另外，困难比较多的一些项目就是那些牵扯了太多部门的项目。在这些项目里，沟通成为最大的问题，这不仅导致了项目的进度，还会牵涉到项目的技术方案，限制某些技术问题的解决办法。我在07年下半年参与的一个项目就属于此种类型。这个系统需要部署在各个业务系统上， 这些业务系统分别属于同一部门的不同小组以及不同部门来管理，我们的技术方案选择在我看来也是比较局限。另外在最初开发阶段，情况最复杂的前端插件被分配 给了一个没有太多相关经验的开发者来做。种种的原因导致此项目延期两次，在项目总结的时候我们讨论了这些问题，但大家没有得出什么特别一致的经验教训。今 天在人月中读到试验工厂，我想或许是对于上面提及的项目的一个好的解决方法，但需要项目经理极大的魄力来决定这样做。因为需要对于试验工厂投入巨大的资 源，有点想研制新药一样。再者，在那个项目中，我们的项目进度估算存在问题，其实很多的项目经理和开发者都缺乏准确估算的方法和经验，在这方面，我也需要更多的学习和实践来提高。
人月是一本好书，因为这里提及了很多的经验教训，值得一读！
]]></description>
			<content:encoded><![CDATA[<div>
<p>这几天在上下班的路上一直在读《<a title="人月神话" href="http://www.douban.com/subject/1102259/" target="_blank">人月神话</a>》，目前已经读完了10章，感觉收获了一些东西。这本书给我的最深的感受就是对味，你在项目里碰到的种种不爽之处，你所参与过的失败项目的原因，几乎都在这里被娓娓到来。当然，感受到这些的前提是你已经参与过大量的大大小小的项目。</p>
<p>实际上，抛开技术方面而就项目沟通、管理来说，各行各业的项目在很多问题上是一样的。我觉得最大的问题在于当项目的管理者（不管是间接还是直接的）的所作所为不是单纯的为了项目本身的目标抑或是在某种情形下忘记了项目真正的目标。这种时候，项目开始慢慢偏离轨道，最后不知道驶向了何方！</p>
<p>另外，困难比较多的一些项目就是那些牵扯了太多部门的项目。在这些项目里，沟通成为最大的问题，这不仅导致了项目的进度，还会牵涉到项目的技术方案，限制某些技术问题的解决办法。我在07年下半年参与的一个项目就属于此种类型。这个系统需要部署在各个业务系统上， 这些业务系统分别属于同一部门的不同小组以及不同部门来管理，我们的技术方案选择在我看来也是比较局限。另外在最初开发阶段，情况最复杂的前端插件被分配 给了一个没有太多相关经验的开发者来做。种种的原因导致此项目延期两次，在项目总结的时候我们讨论了这些问题，但大家没有得出什么特别一致的经验教训。今 天在人月中读到试验工厂，我想或许是对于上面提及的项目的一个好的解决方法，但需要项目经理极大的魄力来决定这样做。因为需要对于试验工厂投入巨大的资 源，有点想研制新药一样。再者，在那个项目中，我们的项目进度估算存在问题，其实很多的项目经理和开发者都缺乏准确估算的方法和经验，在这方面，我也需要更多的学习和实践来提高。</p>
<p>人月是一本好书，因为这里提及了很多的经验教训，值得一读！</p></div>
]]></content:encoded>
			<wfw:commentRss>http://blog.yamone.com/reading-note/the-mythical-man-month-reading-note1/feed/</wfw:commentRss>
		<slash:comments>0</slash:comments>
		</item>
	</channel>
</rss>
