streber项目管理软件，新思路

听说这个软件有一段时间了。最近才刚刚拿起来看看。

新颖的思路：

1. 任何一个条目都是wiki，因此，可以发现，对于项目信息的组织方式其实可以非常的灵活。项目、公司、任务、主题都是wiki条目。
2. 从这一点来讲，系统仅仅提供了一个平台，如果想把系统用好的话，则需要项目团队又更规范的约定。
3. 另一方面，系统可以应对更多类型的项目，弹性非常大！
4. 可以上传文档进行文件管理，而且具有文件版本管理的功能。

遗憾：

1. 仍然缺乏全局的项目管理视图，例如全局的人员利用情况等。这样，这个软件就仍然只能定位于小团队项目管理。（团队不超过40人，同时进行的项目最好不超过5个）
2. wiki条目如何才能导出成文档呢？
3. 由于使用wiki，对团队成员要求略高。
4. 报告功能很弱。（例如最近非常时髦的Burndown Chart就没有提供）
5. 没有日历功能
6. 没有插件机制
7. 功能仍然不够全面，例如：风险管理，费用管理等等没有实现。

想劝劝我的一个朋友

最近正在想劝劝我的一个朋友找新的工作。

我的朋友正在我上半年所在的项目组，变成了副项目经理。工作压力非常大，每天加班工作的很辛苦。这几天给他打了电话，听说12月初，他老婆就要生了，他还在经常的加班到彻夜不归。

所以我非常想劝劝他赶紧换工作吧。

1. 工作压力大没有关系，但是这样的项目我非常清楚：痛苦指数会一直升上去，没有将下来的时候……
2. 工作负责任是对的（包括对自己的老板负责），但是其实单个人并没有那么的重要，地球没有谁都会继续转，大家还会生活的很好。
1. 你会发现，自己其实只是老板的工具。
2. 如果你干的真是革命工作，那么放弃了那么多也值得了。但现在呢？你是在为资本家打工啊。
3. 项目干好了又能怎么样呢？结果还不是客户的兔崽子们又去邀功了？
4. 项目组有多少人病重了？你的身体有谁来关心呢？
3. 20年后，你会为哪件事情后悔呢？是为了当初没有多些时间陪陪家人，还是为了当初没有多谢时间加班？

两个idea

1. redmine的新插件：Isotrol RequMNGT plugin 可以保存baseline！好功能！
2. redmine中的文档模块可以定义文档的类别，这样还是有比file模块有更强的管理功能！因此建议项目的管理文档都上传到文档模块。

心情很差

svbux倒闭了。

投资的1000块虽然不算多，但是也挺恶心的。

看看风声，其他的站也不安全。

两次教科书一般的SCRUM会议

上周五和本周二，我经历了两次教科书一样的SCRUM会议。

背景：

我准备在公司推进敏捷项目管理方法。想办法得到了软件开发部部门经理的支持。于是乎在新立项的G维护项目中进行实验。

上周五下午，是G维护项目的一次迭代汇报会议。

会议中，我帮助项目组成员回顾了已经完成的工作，同时分析了工作没有按照计划完成的原因。会议的效果如下：

1. 下一次迭代的估算时，每个成员每周流出1天的工作量来应付突发的事件。
2. 讨论出了若干实际的方法来解决项目中出现的沟通的问题。

本周二上午，是G维护项目的迭代规划会议。会议中：

1. 先约定了以后会议的一些常态规范和约定
2. 计算了本次迭代项目组所有可用工作量的小时数
3. 请产品经理按照优先级的顺序给大家讲解需求
1. 产品经理由于没有按照部门规定的用例格式书写需求条目，被部门经理严重批评
2. 过程中，我尽量的引导了所有项目组成员对需求条目进行讨论和澄清
4. 针对每一条需求，项目组成员进行了DELPHI的估算方式
1. 估算以小时数为单位，而不是功能点
2. 针对每一条的估算分割成了开发和测试两部分
5. 由于有另外一个产品经理的需求还需要占用项目组的时间，因此要求两个产品经理对需求条目进行合并，并对优先级进行了协调。
6. 项目组成员对本迭代的需求进行了认领
1. 开发经理也会承担一部分开发任务。按照原来的计划方式，开发经理会承担很多难度较大的需求条目。工作量过载会导致开发经理成为瓶颈。采用这样的计算方式，避免了出现上述的问题。其他的开发人员帮助开发经理分担了工作。
2. 测试人员只有一名，但是测试的工作量已经溢出，因此要求开发人员分担了一些测试执行的工作。
3. 最终达到了工作量的大致平衡分布。

当然，规划会议中也出现了一些问题：

1. 对于某一条需求，分割粒度不够。有两个开发人员估算了40小时，开发经理估算了20小时。按照一般的约定，应该由产品经理再次分割指16小时之内。但是强势的部门经理坚持认为该需求不能在分割了。基于当时的环境，我没有坚持。
2. 还是针对该条需求，开发人员的估算存在明显的分歧（包括部门经理在内），出现了短暂的紧张气氛。由于我意识到该条需求具有明显的潜在认领者（开发经理），因此我也没有坚持针对他的估算必须达成一致。
3. 针对于需求的描述格式。由于部门内部发布了用例的规范格式，因此当然要求产品经理进行遵守。但是针对这个特定的项目（用户的角色非常单一），我们都发现，描述功能比描述场景可能更加合适。因此，在日后的改进工作中，有必要发布用户故事的格式规范。
4. 在浏览需求条目时，发现了不同的需求条目之间存在着依赖关系，即某需求的开发的开始和估算依赖于另外一条需求。我在本次会议中没有处理这个情况。我觉得这其实是由于被依赖的需求条目还需要被拆分。但是，我准备在下一次迭代中再处理这种情况。
5. 本次规划中发现需求来源于两个产品经理。这一次虽然协调的比较顺利，但以后还是需要尽量避免。

虽然出现了一些问题，但是我还是对这两次会议非常满意了！关于部门经理非常强势的问题，由于本次实验部门经理也非常支持，因此我会在以后的私下聊天中，逐步改变部门经理的管理方式。

感谢以下一些图书的作者：

《SCRUM敏捷项目管理》

《SCRUM敏捷项目管理实战》

《硝烟中的SCRUM和XP》

《敏捷无敌》

《敏捷估计与规划》

Redmine又有了新的插件！

今天早上本来想试验一下redmine中的导出文档的功能。结果发现无法按照正确的编码导出PDF文件。可以导出CVS格式的文件，但是导出的字段也不完整。
于是上redmine主页查找相关的插件。结果发现出现了一些新的插件！

1. Isotrol Estimer plugin （基于功能点的估算，终于等到了……）
2. Isotrol RequMNGT plugin （需求管理）
3. Isotrol RiskMNGT plugin （风险管理）
4. Issue Due Date plugin （最终日期）
5. Issue Group plugin （分组）

上述插件显然是某个公司开发之后放上来的。正好是我目前最需要的一些功能！
有时间一定要好好研究一下！
对了，上周五下班前参加了软件部某个项目的周末迭代总结会议，不错，教科书一般的进程。

个人桌面维基软件的选择

目前还缺乏完美的产品：

• TiddlyWiki
• 优点：完整的语法支持，丰富的插件，非常好的便携性能，可以发布到户联网。
• 缺点：性能！（真要命）
• Tomboy
• 优点：非常好的性能和易用性，支持的格式还算够用，具有同步功能（联网或者本地）。
• 缺点：不支持内嵌图片，没有内容导出功能。
• Zim
• 优点：可以内嵌图片，能够到处成HTML等文件格式，编辑方便有快捷键，内容以TXT格式存储方便移动。
• 缺点：支持的格式是在是太少了！windows下面安装极其麻烦。

可以看出来，缺点都很要命！

有时间再看看wixi。

Welcome! Ubuntu 9.10

今天白天Ubuntu 9.10第一天发布，我也赶了一下时髦，DOWNLOAD了一份ISO。

准备今天晚上开始安装！

虽然非常仔细，但是还有遗漏

关于软件采购的事情，虽然前期的工作已经非常谨慎了，但是到了下午就要签合同了，仍然发现有一些问题没有确认清楚，例如：

1. 是否支持ORACLE数据库。因为有可能需要在客户现场的系统都是用统一的数据库系统。目前采购的软件如果需要部署在ORACLE上面的话，有可能需要价格在DOUBLE。
2. 能够提供什么样的接口与其他的系统进行集成。因为有可能本系统需要与客户方若干已有的系统进行集成，可能会仔细的安排各个系统各自的职责等等。
3. 是否能够提供可供二次开发的接口。这个也非常重要。

Firefox插件的选择

	FEBE	Sxipper	Xmarks	Lastpass
Configurations	o
Extensions	o
Bookmarks	o		o
Password	o	o	o	o
Auto Form		o		o
Online	box.net (GFW)		Xmarks (GFW) / Self Server	o
Offline	o	manual backup	o
Sync	On Time		Auto

结论：选择FEBE+Lastpass的组合，配合dropbox

这是一个哲学论断

如果一个系统足够复杂的话，那么中央总控式的管理方式注定崩溃。需要发挥系统中下层的自管理能力和主观能动性，才能保证良好运转。

范例1：

如果一个软件系统比较复杂的话，那么自顶向下的设计方式（即传统的面向过程的软件工程）注定失败，无法应对未知的变更。只有自底向上的设计开发方式（即面向对象的软件过程），才能演进方式的建立系统架构，才能保证系统结构的健壮性。

范例2：

对于软件开发项目来讲，传统的瀑布式项目管理方式很难保证项目的准确实施。只有最近出现的敏捷管理方式才能够最大程度的发挥团队成员的主观能动性，保证项目的成功。项目管理需要留给执行人员发挥个人能力的空间。

范例3：

在中国来讲，传统的计划经济体系注定无法满足社会发展的需要。所以需要市场体制来对经济的发展进行自我调节。

想来想去，觉得这是一个哲学论断。

采访张琳

刚刚看到CCTV-5的访谈节目，在演播室采访运动员张琳。席间记者对张琳的表现评论了一番之后，主持人请张琳说话。张琳说：讲的太好了，我没什么要说的了。

呵呵！

国内的体育记者绝大多数是这个特点：最重要的工作是表达自己的观点，而不是采访到被采访对象的观点。

另一方面说明：国内的媒体工作者，制造别人的想法已经成为一种习惯了。

取消使用instiki，完全转向redmine。正在看activeCollab和ProjectPier

最终决定，在redmine上面新建一个“项目管理制度”的公开项目。其中只包含wiki模块和文件管理模块。

这样，就可以不需要使用instiki系统了。

另外，经过猩猩的推荐，正在看另外的两个项目管理系统：activeCollab和ProjectPier。

决定退回到redmine+instiki了

考虑再三，决定还是退回到redmine+instiki了。

Jira虽然非常灵活，但是其以issue为主线的方式还是不能解决一切问题。例如：没有以项目为单位的文档管理，没有子项目的设置，其子任务的机制也比较简单；wiki不能以项目为单位分开。

redmine虽然不能建立子任务，但是如果能够在设置version是变换一下，变成里程碑的话，没有子任务估计也可以忍受。

然后就是有几个任务需要解决：

1. 参考jira，利用插件，多建立一些项目的图表。
2. 看看是否可以开发一个风险管理的插件。
3. 看看issue的过滤器能够多灵活？

准备再研究一下JIRA+CONFLUENCE

准备再研究一下JIRA+CONFLUENCE。以前说过这个组合的问题，不过现在再考虑应该更加充分的利用CONFLUENCE的功能。例如文档管理和风险管理是否也应该放在CONFLUENCE中。

因为JIRA和CONFLUENCE的灵活性、稳定性以及商业化实在是值得考虑的因素。另外最近JIRA也加入了一些转门针对敏捷开发的特性。

不过，其实不论是REDMINE或者JIRA+CONFLUENCE来讲，都仅仅是针对单个项目管理的工具。而我目前所面临的问题是需要进行项目群管理（Program Management）。如此说来，是否只能考虑昂贵的商业软件了呢？

项目管理软件选择陷入僵局！

项目管理软件的选择目前陷入僵局！

	Jira+Confluence	dotProject+PmWiki	Redmine+instiki
优势	灵活的ISSUE管理和自定义的过滤器	管理领域全面	功能适中
	基于登录的WIKI和完善的权限控制	内置讨论区	分项目的WIKI
	插件丰富	条目分类清楚（任务，时间，问题，风险，机构，部门，联系人）	插件丰富
劣势	没有分项目的WIKI	没有分项目的WIKI	instiki功能简单
	商业版，目前可以破解	缺乏自定义过滤器	任务分层必须使用插件实现，但是插件安装失败
	没有事件管理	插件少，缺少图表	插件安装困难，版本混乱

highlight出来的条目表示无法忍受的内容。

由此看来，目前只能选择jira组合，但是这个选择明显风险很大。

时间紧迫，该怎么选择呢？

其实，如果是独立的项目组的话，任何一款都可以。甚至xplanner和scrumworks等其他的软件也可以考虑。但是目前需要选择的是公司级别的系统，因此需要满足很多管理层的需求才可以。

成功安装jira & confluence

静下心来安装jira和confluence。今天一天的时间安装成功。剩下的就是进行配置了。

准备放弃redmine了

不得已只能放弃redmine了。

本来兴冲冲的在PMOSERVER上面安装了instantrails, redmine和instiki。也都能够正常运行了。问题是：

redmine的subtask插件怎么也安装不上！

今天一早终于查出：插件与redmine 0.8.4版本不兼容。作者自己也不知道怎么办！

唉，开源产品的问题啊。

这么看来，只能放弃redmine和instiki的组合了。

其他的组合是：

jira+confluence 或者 dotProject+PmWiki

dotProject + ~PmWiki

dotProject有两个问题一直非常困扰我：

# 我需要按照TaskType过滤查看任务，但是系统中似乎没有这样的功能。（我本来需要在TaskType区分是 功能、沟通、管理、缺陷等等）

# 系统的图表功能太有限了，之后甘特图。如果需要类似Buendown Chart的话，怎么办？

新公司的工作内容

到新公司一个多月了。作为项目办主任，头一个月的试用期主要完成了下面一些工作：

1. 工程部门和软件部门的项目现状的调研，其中包括多次参加各个项目的诊断会议，然后给出诊断报告。
2. 制定一个初步的软件开发项目管理过程指导书，同时给出相应的各种文档模板。
3. 制定项目办未来大约两年的工作内容规划，在规划中给出项目办的工作职责以及8个阶段的工作内容和预期效果。
4. 制定公司级别的项目管理团队绩效考核办法。
5. 另外的一个重要的任务，是老板吩咐了需要在公司建立项目管理信息系统。

关于项目管理信息系统，一开始想到的就是~VisualProject。但是最近几天听听老板的口风，看来在一开始还是不能立刻推荐给老板比较高端的商业软件。现在的策略是寻找低费用或者免费的产品，现在公司内部找一两个项目试运行。等到老板看到效果了之后，在酌情进行推荐。
关于PMIS (Project Management Information System)的选择，目前决定使用版本控制软件+项目管理系统+维基（作为门户）的组合。

• 版本控制软件选择了''Subversion''而不是目前公司通用的Visual Sourcesafe。


• 主要是考虑到为了以后能够更方便的配合项目管理系统。因为多数流行的低费用的项目管理系统都能够对Subversion或者CVS进行集成，而支持VSS的很少。


• 项目管理系统选择了''Redmine''而不是Jira或者dotProject。


• dotProject虽然功能非常强大，基于PHP部署方便，但是其定制能力有限，而且想要扩展的话也是源代码级别的。考虑到可能的功能的灵活性的要求，只能放弃了。（使用过程中发现~PHP5.3下面有无法解决的问题，总是显示错误提示，之后换用~PHP5.2.X，一切正常。好在基于WAMP进行试用，切换PHP的版本非常方便。）


• Jira其实是非常适合的产品。系统稳定，功能强大。可定制能力非常强！而且功能扩展也非常方便，有现成的N多插件可以选择，足以满足需要。而且可以和Confluence进行集成也很诱人。缺点是商业软件，破解繁琐。基于JAVA平台，因此试用时部署非常方便，但是在生产环境下的部署却比较麻烦。


• Redmine基于~RoR平台，部署非常方便。有插件机制因此也可以方便的进行扩展。Open Source所以实在不行也可以自己编写扩展。功能还算灵活，相比Jira配置简单，内置了WIKI和新闻发布。目前的问题是：功能不够复杂（呵呵，给老板看的时候需要更像一个庞大的系统），缺乏企业级的管理功能，不过通过插件应该可以弥补。性能如何目前还不肯定。


• 维基系统选择了''instiki''而不是~PmWIKI或者Confluence.




• Confluence应该是最适合企业应用的WIKI软件，况且能够和Jira完美配合。无奈是商业产品，破解困难。另外基于JAVA，生产环境下和Jira一同部署也比较麻烦。


• ~PmWIKI基于PHP系统，部署非常方便。另外自身功能也很不错，权限控制也比较灵活，能够应付企业应用。有非常丰富的插件可以选择，可扩展能力很强！


• instiki功能简洁，勉强满足需求。不过它也是基于~RoR平台的，因此在和Redmine同时部署的时候比较方便。

最近我就要在服务器上安装上述的系统了，因此后面会将安装过程和配置过程进行记录。

何时应该使用用例进行建模

当遇到下述情况时，用例是需求捕获的最好选择：

• 系统有功能性需求所主导。
• 系统具有很多类型的用户，系统对他们提供不同的功能（有很多参与者）。
• 系统具有很多接口（有很多参与者）。（我的理解：如果针对业务应用系统而言，意味着有很多操作界面。）

当遇到下述情况时，用例是一个糟糕的选择：

• 系统由非功能性需求所主导。
• 系统具有很少的用户。
• 系统具有很少的接口。（例如嵌入式系统或者算法复杂但接口很少的系统）

何时停止用例建模？

• 用例建模的基本原则是保持捕获到得信息量是必要的、最小的。这意味着，很多次要场景可能根本就没有说明——用例中的一行有关它们的描述可能让人足以理解系统的功能。

以上摘自《UML and the Unified Process: Practical Object-Oriented Analysis & Design》, Jim Arlow & Ila Neustadt

又被GFW恶心了

刚刚发现，picasaweb中的图片全部被GFW过滤掉了。

无语！

月盈则亏，水满则溢

上大学的时候，就曾经有一个同学和我说过：中国的腐败现象很难根治。

腐败现象不可怕，可怕的是老百姓们对待腐败的态度。

其实在你身边就有很多很多的各级政府腐败官员，但是你会发现身边老百姓们对待他们的态度并不是非常的痛恨这些腐败的官员，而是带着一种非常羡慕的心态。当教育孩子的时候经常会说：“你看，XXX家里的儿子当了官多好，家里面有很多钱。长大之后你也要当官啊。”

联想到软件开发项目，也会有一些类似之处。在项目当中犯了错误不可怕，关键在于如何认识这些错误和不足。当一个团队经历了长期的疯狂加班，项目管理一片混乱，然后提交了一个非常烂的成果之后，最可怕的是大多数人都认为这是非常正常的、软件开发项目就是这个特点。尤其是当这样的想法也来自于高层的领导的时候，这个团队就基本上无可救药了。

老板还经常抱有这样的想法：“我当初经历过N多XXX的项目，有很多很多大项目的经验，你们现在远不如我们当初艰苦与投入……”言外之意是项目做得不好是因为大家工作的还不够疯狂。客户的满意度来自于看到开发人员过度悲惨而产生的怜悯心态。

好像是的，老板们都经常会以以前做过很多更艰苦的项目而标榜，而不太思考这些艰苦是由什么原因而造成的。

今天下午的测试培训会议

下午突然听说老板找了一个IBM的专家来做测试的培训，于是应要求下楼听了听。
看见一个口齿不太清楚的人正在演示ppt。听了听内容，基本事实幼儿园级别的入门培训。从测试的一些基本概念到测试管理，简单讲了讲td的使用等等。
老板和测试人员们正在很崇拜的请教。
（下周就要进行UAT测试了，现在临时抱佛脚。）
中间讲到了目前应该怎么测试流程，专家建议仅仅找一个最主要的流程走通。（专家把物流系统当作简单的网上购物了。）
讲到目前测试人员太少，只有两个。专家说50多个开发人员起码需要有五六个测试人员嘛。现在需要将开发人员调入参与测试执行。（目前项目的状况，开发人员还都在满负荷地进行开发呢……五六个测试人员就够了吗？）
讲到测试人员目前介入得太晚了，不了解需求。专家说：这说明项目经理一开始就没有重视这件事情。现在需求人员应该没有什么事情了吧，也需要参与测试。（现在需求人员已经忙得不可开交了，天天在应对客户方面的各种各样的要求。项目刚刚立项的时候我就正式的和老板要求了：一定要在需求期间测试人员参与，一定要保证测试人员的数量和质量。结果呢？先后进入项目的6个测试人员迅速离职或者辞退了。然后老板说不要指望测试人员测试了，开发人员自己来吧。然后真正需要有经验的测试人员出具测试方案了，老板指派项目管理中心的专职SQA人员进行负责。）
讲到目前还有需求变更的情况出现，专家说项目经理对需求变更没有很好的进行控制。（专家知不知道项目组面对的是什么样的客户？）
可以看出，老板还是对测试一点概念也没有，进而发现老板对项目管理的内容实在是理解得太初级了。所以现在对这个山寨专家非常崇拜。
我私下问了问这个专家什么来历？据说：这位姓束的专家是IBM的高级项目管理顾问。原来也是联创的员工，是老板的老同事。而且据称也是位天才级人物。原来如彼。
总之，我晕！

面向对象设计背后的数据库设计（摘自"The Object Primer"）

1. 把对象映射到关系数据库

首先，类的属性将会映射成关系数据库中的0列或多列（最好使用相似的命名规范）。

对象的有些属性本身就是对象，它真实地反映了两个类之间的关联。

并非所有的属性都是持久的，有一些被用来进行临时计算。

2. 影子信息

影子信息（shadow information）是除了普通领域数据之外，对象需要维护的任何用于将它们自己持久化的数据。

一般如主键信息，特别是没有业务含义的代理主键。并发控制标记、时间戳、增量计数器。

3. 映射继承结构

将继承映射进关系数据库中，有3种主要的方法：

1. 把整个类层次映射到单张表中。
2. 把每个具体类映射成自己的表。
3. 把每个类映射成自己的表。

3种技术的对比

技术	优点	缺点
单表	方法简单 容易增加新的类：仅需要对额外的数据增加新列 通过简单改变行的类型来支持对象多态 数据访问是快速的，因为数据在一张表中 特殊报表是非常容易的，因为所有的数据都可以在一张表中找到	类层次的耦合增加了，因为所有的类都直接耦合到同一张表中。类中的变化可以影响表，这样就影响了层次结构中的其他的类以及他们的相关映射 数据库中潜在的空间资源的浪费，因为许多行将会是空行 当类型之间有严重的重叠式，表明类型变得复杂 对于大型层次结构，表增长得很快
每个具体类一张表	访问单张表中的数据时好的性能 生成特殊报表简单，因为一个类的所有数据都仅存处在一张表中	对类的修改需要我们修改他的表，及其任何子类的表。 无论何时对象改变了他的角色，就需要把数据拷贝到相应的表中。 支持多行信息，还要维护数据完整性，这很困难。
每个类一张表	映射简单，因为他是一对一的 容易支持对象多态，因为我们只在每种类型相应的表中有记录 修改父类和增加新子类非常容易，我们仅需要修改/增加一张表 数据大小的增长与对象数目的增长成正比	数据库中有多张表，每个类一张表（加上维护他们之间关系的表） 潜在的要花更多的阅读和读取数据的时间，因为我们需要访问多张表 特殊报表是困难的，除非我们增加视图来仿真待处理的表

4. 映射关系

对象模式中的关系是通过对象引用和操作的组合来实现的。而在RDB中，他们通过外键来维护。

映射关系的方式依赖于他的多重性：

1. 一对一关系

如果每个类都有一张表对应，那么这两张表之一需要实现一个外键。

第二种策略是简单的在单张表中存储两个类的数据。

2. 一对多关系

它的实现方式是在关系中多的那方面使用Hashset等集合，在一的这方面使用对象引用。

在数据库中，他是在关系中多的一方通过外键来实现。

3. 多对多关系

两个类之间的多对多的关系被映射成数据库内的关联表。

4. 迭代关系

也称为自反关系，它是指关系的两侧都是相同的实体。

我们可以使用非迭代关系相同的方式来映射它们。

功能驱动与用例驱动（关于用例、用户故事和特征的解释）

软件开发过程中，描述并分析需求会同时采用不同的角度和方式。例如功能分析和场景分析。

其中功能分析是指描述系统所应该具有的功能。场景分析是指在特定场景中用户的操作步骤以及系统给出的相应的反应。

功能分析文档所列出的清单一般会叫做“软件需求”或者“系统特征”。

场景分析文档所列出的内容一般就是“用例文档”

由此可见，RUP中所使用的用例驱动开发，XP中所使用的用户故事驱动开发以及特征驱动开发，表面上看起来是以其分割粒度的不同进行排列下来的。其实我们可以看出，用户故事和特征都是从功能分析的角度对系统的需求进行的描述。其与RUP所说的用例驱动完全使用了不同的分析方法。

这样我们就可以更好的理解XX驱动开发之间的区别在那里。

下面是功能驱动与用例驱动之间的对比表格：

功能驱动	用例驱动
当你有许多未密切相关的不同功能时，工作会进行得比较好。 让你可以较快想客户展示可运作的程序代码 是非常功能性驱动的。采用此方式，你不会忘记任何功能。 对具有许多未连接功能性片段的系统，进行的特别好。	当你的应用程序有许多流程与场景，而不是个别的功能性片段时，进行得比较好。 让你在每个开发阶段可以向客户展示较大的功能性片段。 是非常以用户为中心的。采用此方式，你将为用户使用此系统的所有方式编写程序代码。 对交易式系统（系统以冗长、复杂的流程定义而成），进行的特别好。

在实际需求分析的过程中，两种分析方式相辅相成，都有其独到的贡献，最好能够结合使用。

我理解，互联网类型的项目更适合功能驱动开发，而企业业务系统类型的项目更适合用例驱动的开发。

芜湖项目现场需求调研阶段总结

芜湖项目现场需求调研阶段，工作效率高，工作成果的质量也很好，现在总结如下：

1. 需求分析团队人员要尽量少，减少沟通成本。尽量只允许业务核心人员参与，这样能够以最快速度对业务流程进行确认。
   反观现在大平台的项目，需求分析阶段有30多个人参加，包括了国家局的人员和各省市的人员。分成了6个分析小组。诸多问题无法现场进行确认，因为参加的人多，因此大家都不作结论，只能会后通过EMAIL来回来去。由于分组很多，因此涉及到很多跨小组的问题进一步增加了沟通成本。
2. 需求讨论会议现场形成文档，由于文档形式上是共同创作完成，因此可以省略客户确认文档的过程。
   反观现在大平台的项目，会议之后，需求分析人员晚上加班形成需求访谈报告，需要客户确认，然后再形成需求规格说明书，再要求客户确认，这样效率非常差。
3. 关于需求分析的团队构成，建议如下：
   - 客户业务人员
   - 客户IT人员
   - 主力业务分析人员：主要负责需求分析工作，引导大家使用正确的方式和正确的方向进行需求分析工作。
   - 业务分析助理：主要使用合适的工具，现场进行文档撰写工作。也可以提出自己的建议。因此该人员也需要有一定的需求分析能力和文档撰写经验。
   - 项目助理：负责对会议中的各种未定事项以及决议进行跟踪，并且进行其他的一些辅助性工作。
   - 解决方案顾问团队：辅助角色，可以离线支持。主要对相关业务领域或者IT技术领域进行咨询工作。
   - 开发组组长以及主要设计人员
   - 系统实施负责人
4. 使用的工具建议如下：
   - 业务流程分析工具，以便团队成员能够在早期对业务流程有全貌的认识，如BPMN, EPC图等等
   - 快速互动原型工具，以便快速形成可以进行互动的动态系统原型，给客户良好的感受。推荐serena prototype composer或者axure rp等。
   - Sparx Enterprise architect，全面的项目模型管理，在此阶段主要使用到：用例分析，领域模型，需求条目管理等等。（在用例中需要填写senario条目，并且需要与需求条目进行关联）
   - Balsamiq Mockups，对操作页面进行设计。
5. 对目前的大平台，现在能想到的建议如下：
   - 分组尽量少，1~2各组，人员尽量少，减少沟通成本。
   - 现场形成文档。
   - 在早期需要有总体业务流程分析过程，然后在进入细节系统需求分析过程。
   - 使用上述的工具
   - 使用上述的团队组织结构
   

综上，发现上述经验并不太符合敏捷过程，反而与《人月神话》中的理论非常相似。起码，可以总结出来两点：1.架构（需求分析）是贵族专有的工作内容。2.需要组成外科手术型的团队结构。

芜湖出差，巡回取货项目的一些心得

五一之后到芜湖，客串巡回取货项目的项目经理，负责需求调研工作。整两周的时间，有如下一些心得体会：
出差两周，其中需求调研工作大约占用了6个工作日的时间。另外有2个工作日大约是各种各样的汇报。
工作进行的比较顺利。体验也很好，主要是可以按照自己比较推荐的方法来进行项目工作，大家都比较轻松，工作效率也很高。客户方也反映工作效率很高，工作很有成效。
开始的几天，使用serena prototype composer工具，项目组成员在同一个会议室中，主要讨论工作流程（与系统无关）。然后同样使用这个工具，讨论大致的系统操作流程，同时画出初步的系统界面。这个阶段成果效果非常好：大家对系统的总体概念已经形成，基本确认了系统范围。并且形成了可以进行互动的系统界面原型。
然后开始使用EA和Balsamiq Mockups配合进行用例分析与界面设计。在EA中复制了serena prototype composer中的工作流程，然后进行用例分析，在用例中进行场景senario步骤描述。针对每一个用例，至少使用Mockups软件绘制一张界面设计图。另外在EA中进行领域模型的设计。
综上，提供出一份真正对开发有帮助的需求文档。
经估算，这两周的需求分析工作定义出的系统需求大约需要5人团队开发3个月的时间的工作量。开起来也非常符合比例。当然这仅仅是估算的合理值，估计和客户方面进行协商之后，时间上又会变得非常不合理。

客户非常高兴的从我这里拿到了上述的三款设计工具。不过，真正重要的是需要会使用这些工具啊。

在出差期间，抽时间学习“Head First OOAD”，有如下收获：
终于对需求和用例明确的区分开了。需求大约总是以“系统应该可以xxx”这样的格式描述，主要描述系统所具有的功能和能力。用例侧重于描述某某场景senario下面的操作步骤。因此大约会是包括正常路径/可选路径/替代路径等等。

不过，在出差期间，本计划使用类似极限编程方式的增量开发，结果未遂。最终变成了类似ICONIX方式的过程。

另外，意外的发现，原公司上班时，结识的MOTO客户，现在正在作为甲方折磨着现在我的客户。现在我的客户天天折磨我们，同时他们也在被MOTO客户折磨着。……

软件开发过程DRY

依据RAILS框架所倡导的DRY (Don't Repeat Yourself)的思想，可以大大提高编程时的工作效率。如果能够由此推广开来，发现软件开发过程中有哪些工作内容是重复而浪费了，并能够有针对性的改善的话，是不是可以提高工作效率呢？
我们的现实情况是：需要满足客户以及老板和项目管理中心所谓正规软件工程所需要的标准过程，还有标准过程所要求的文档。所以，通常来讲，我们会按照这样的过程进行工作：

考虑以下一些方法：

1. 利用用例分析或者用户故事，来讲需求分析与需求传递和培训两个过程合并。
2. 考虑需求文档中的用例分析部分可以是主力需求分析人员带领开发团队共同完成。
3. 需求文档的工作量很大，并且变更之后的维护也是问题。因此考虑需求文档与测试用例进行结合，减少需求文档中的内容。
4. 使用某种形式的工具来自动生成规范格式的需求说明书。
5. 概要设计说明书中仅包含系统架构层面的设计工作。
6. 系统设计过程与测试案例编写过程融合（参考XP过程）。
7. 实用工具（例如javadoc）来自动由编码生成详细设计文档。
8. 现实存在详细设计过程，但是并不正规，仅仅产生一些中间产物文档，如界面草图、UML顺序图等等。

关于敏捷软件开发新的理解

前两天，在一次聊天中，我问了问未来开发组的组长：眼看设计过程就要结束了，项目启动到现在进行了3个月的时间，想一想，前一阶段我们所做的工作中，有百 分之多少是对后面的工作有意义的？开发组长无奈的苦笑了一下。显然大家心里面都有数，这个比例很不理想。尤其是设计文档中的模块设计部分，大量的工作量， 完全是为了设计文档能够评审通过。

对于敏捷软件开发，目前理解期最重要的目的是识别软件过程中没有必要的任务或者是性能低下的任务，然后去除之或者改进之。基于这个出发点回顾一下目前的情况：

1. 需求分析。唯一不变的就是变化。项目的早期集中时间进行需求分析然后确认基线，再等到真正动手开发某一模块的时候可能已经过去了一段时间，并且需求已经发生了变化。这样还需要对新的需求进行再次分析。在这样的情况下，前后的需求分析则存在工作量的浪费。
   1. 敏捷过程则是需求分析存在与整个项目的始终。细节的需求分析工作尽在真正开始代码之前才进行。虽然以后仍然有可能发生变化，但起码针对上面的情况做了优化。
2. 软件设计。目前的项目，设计阶段需要的交付物有：架构设计，概要设计，详细设计，物理模型设计，接口设计等等。设计的目的当然是为了能够知道开发。这一部分工作显然是必须的，但是能否优化呢？敏捷过程典型的对策是1.仅仅做足够的设计；2.测试驱动开发。
   1. 系统的架构设计是需要的。但是针对某一功能来讲，仅仅在开发之前才做相应的详细设计。设计仅仅做到能够指导开发的程度，对文档的格式要求比较宽松。
   2. 传 统的UML设计包括类图、顺序图、协作图、活动图、状态图等等。这个敏捷过程一般没有强制要求。XP过程中推荐以TDD和CRC分析来代替。其中CRC分 析基本上是UML协作图的替代物，但是更加强调团队共同完成。而TDD则是在保证了测试自动化的同时还能够对软件设计进行指导，做一件事达到两个效果，体 现其高效率。
3. 界面原型。我前面说过，希望能够在需求分析阶段就能够对系统的界面进行确认，还找了一些专业做页面原 型的辅助工具。现在看来，其实也存在浪费。其实更高效的做法是以最快的速度拿出开发出的成品或者半成品让用户进行确认（这样一来，唯一的问题是你能有多 快？;-) ）。界面草图有的时候是需要的，但是它变成了非常不正式的中间产物，不必要进行存档。
4. 重构。仔细想想，其实重构的工作对于任何一个项目来讲都是必须的。而现实是，如果没有采取全面的自动化测试的话，传统的软件开发项目没有能力也不敢进行深度的重构。而相反基于TDD的XP团队则更有勇气对软件进行彻底重构。
5. 集成。集成的工作量无法节省。敏捷过程的做法是持续集成——将工作量分散到整个软件生命周期。这样能够及时发现问题，并从感受上减少工作量。

我有一个朋友，看他上网打桥牌的时候，经常发现他的搭档在抱怨他发生了失误。而实际的情况是怎么样的呢？我的朋友是全国顶级桥牌赛事的前四名获得者。那些被抱怨失误的牌都是由于他的搭档的水平不够，对于他的精妙招数无法理解。
在软件开发领域，其实我们也正在处于我的朋友的搭档的水平。经历的项目越多，越会发现业内大师的很多理论的精妙之处。很多情况是：如果大师们的理论你认为有很大问题的话，其实是因为你的层次还不够。

现实很残酷

现在手头是这样的一个项目：

1. 为期7个月
2. 工作量分析的结果，项目团队需要60个人或者更多
3. 项目组中只有包括我在内的3个人有相关行业经验
4. 开发团队中有大约20多个人是刚刚招聘到位的
5. 对于所使用的技术，除了JAVA开发之外，JAVA开发框架、BPM/BRM引擎、B2B网管、字符终端开发等等都是项目组第一次使用
6. 项目组中几乎没有人有面向对象的设计和开发经验
7. 客户方面政治斗争严重

这是我所经历过的第二个死亡之旅项目。

考虑使用UberNote代替Google Notebook

刚刚发现一款新的Web应用：Ubernote

• 展现方式同Google Notebook非常相似
• 采用了不分层的Tag方式进行管理
• 可以对Note进行所见即所得的富文本编辑
• 可以多人合作共享Note
• 有浏览器插件，可以直接抓取网页。而且插件很丰富：Toolbar, Clip, Bookmark, Snap
• 居然能够直接从Atom导入现有的Google Notebook内容。
• 缺点是对于每一个Note不能折叠显示。
  

所以真的可以考虑切换过去？

另一个可选的替代方案是：TiddlyWiki + Clipmarks，只是Clipmarks的速度比较慢。

Google Notebook的备选替代品

Google Notebook停止开发了。虽然现在还能够使用，但是还是需要准备一些备选产品了。另外，Google Notebook的功能一切都好，唯一的问题是，不能存储网页篇幅很大的文章。
替代品列表：

1. Office OneNote 2007：非常好的产品，文字编辑非常灵活方便，支持表格。分类清晰，功能强大，能够直接抓取网页。不能支持在线同步，但是只需要配合Dropbox就可以完美解决。唯一的问题是商业产品，需要收费。另外只能基于Windows平台。
2. Evernote：也是业界很出名的产品。Tag方式的管理，支持全文搜索，能够直接抓取网页。有在线同步功能，同时还有桌面客户端。
   缺点是：体积庞大，免费版本每月有数据量的限制。并且不支持表格，编辑功能稍弱，不够灵活。
3. TiddlyWiki：体积小巧，功能灵活。基于Tag方式管理，可以安装第三方插件。开源。支持UBB方式的自定义格式，非常方便。配合Dropbox可以实现在线同步。单一的HTML文件，所以跨平台。
   缺点是：不支持直接抓取网页。

现在看，TiddlyWiki的方式很好。所以正在寻找能够直接抓取网页并能够在线同步的工具进行配合使用。

对面向对象以及极限编程新的理解

传统的面向过程的开发是自顶向下逐步细化的过程。这是非常符合人们习惯的思维方式的。所以自然由需求分析->概要设计->详细设计->编码->测试->发布的瀑布模式成为了最规范的软件过程。
而面向对象的开发是自底向上的过程。在这样的过程中，往往是先实现已经了解的局部。逐渐的随着过程的推进，系统的全貌浮出水面。而基于面向对象开发的特点，在这个过程中，前面的工作成果往往能够很好的进行复用，重构的成本也很低。自然而然的，开发的过程会形成多次的迭代。但是，在这个过程中，最重要的是需要按照面向对象的思维方式进行设计与开发。

基于上面的认识，在回顾XP的各项原则会发现，以前认为不现实的内容其实都是顺理成章的事情了。唯一的问题仅仅是现场客户的问题，不过这个在一定的程度上 面也能够克服。由此可见，当深入了解了面向对象的开发的精髓之后，XP的各项原则实际上都是面向对象过程的一些内在的需求而已。

极限编程的12个原则：

1. 计划的制定
2. 小版本
3. 简单设计
4. 测试驱动
5. 持续整合
6. 重构
7. 配对编程
8. 代码共享
9. 每周只工作40小时
10. 现场客户
11. 隐喻
12. 编码标准

关于OOD的一点点总结

很多成熟的设计过程摆在面前：用例驱动、XP用户故事、特征驱动FDD、模型驱动MDD、敏捷模型驱动、领域驱动、测试驱动等等等等……到底应该怎么设计呢？
简单的讲，过程内容会分为需求分析和设计。
需求驱动是最根本的，所以在需求阶段，所谓的各种驱动方法其实都是对需求的功能分解，以便日后进行分治的设计以及管理跟踪。
由Use Case -> User Story -> Feature其实是由粗到细对需求分解的不同粒度。
有了需求条目之后，针对每一个条目可以继续进行设计工作。
设计过程的目标其实很简单：

• 类的识别
• 类的结构（例如：继承、关联、聚合、依赖等等）
• 类的属性
• 类的方法
• 系统运行是类之间的消息传递关系。

前三项是在整个设计过程中不断进行更新的，是个逐步细化的过程。分析的早期就可以识别大部分实体类，而在模拟需求条目的场景的过程中，逐步识别边界类（主要来自于页面流程分析）和控制类。主要的工具就是UML类图。
后两项则是通过模拟每一个需求条目所描述的场景来设计类之间的消息传递关系。在这个过程中，自然的完成对类分配方法。主要使用的工具如顺序图、协作图或者CRC分析。

对于MDD, AMDD以及DDD来讲，感觉上是针对非常熟悉的业务需求或者非常有经验的分析设计人员，因此采用了更新颖的设计路径。

而TDD应该理解为一种辅助设计手段。

在Iconix过程中使用协作图

ICONIX过程步骤如下

1. 系统界面原型，初步的领域分析（识别实体类，分析类之间关系，但不添加属性和方法），用例分析（仅关注用例内部的主干流程与分支流程，而忽略诸如前置条件、后置条件等细节）。
2. 健壮性分析（分析用户与系统类之间的关系，在此期间识别边界类与控制类），更新用例，更新领域模型（添加部分类属性）。
3. 详细设计（根据健壮性分析图而细化成顺序图，在此过程中给类分配方法），细化领域模型成为类图（静态模型）。

查阅了一些资料之后，有一个想法：
可以尝试使用UML协作图来代替顺序图。
因为协作图的样子本来就与健壮性分析图非常相似。这样，第2、3步仍然保留，但是产出物可以合并，即直接在健壮性分析图上面进行更新而成为协作图。
协作图中主要表现的是在一个场景中对象所拥有的职责（即所用到的对象的方法）以及对象之间的关联。这样看来，协作图所起到的作用与XP过程中所推荐的CRC分析是完全吻合的。
另外，对于普通的业务系统来讲，系统对时间的敏感程度并不高，这就增加的忽略顺序图的可能性。

如上，系统分析与设计的产物则为：

• 页面流程图与页面布局原型
• 用例分析
• UML类图
• UML协作图
• 部署图与组件图（可选）
  

在哪一个阶段画出操作界面

今天上午项目组内部开了一个会议，讨论需求文档的模板。大部分内容大家都比较一致，比如分成功能性需求和非功能性需求。功能性需求中主要以用例分析为主线，辅助以各个层次的工作流程图以及系统流程图。另外加入业务实体的各种信息等等。
但是在一个问题上面，项目组成员与我的引导无法达成一致：多数项目组成员认为系统操作界面不是需求阶段的产物。而应该是系统概要设计甚至详细设计阶段的产品。理由如下：需求的主要内容应该集中于业务分析，而系统界面更接近于设计的工作。而且在需求阶段需要画出页面的话，需求文档的工作量过大，需求评审阶段如果包括界面的话，那么需求阶段的时间会过长。
我无法说服大家的固有习惯，甚至无法说服大家仅仅写一些重要业务的操作界面。最终只能以大家的多数意见为准了。

这种情况显然是项目组内部对当前的OOAD技术缺乏经验所导致的。我的观点与大家相反，确认操作页面的工作越早越好！

• 需求分析需要分为三个层次：战略目标需求（高层访谈），业务逻辑需求（中层访谈）以及操作需求（一线操作层访谈）。
• 操作页面的确认工作应该是在需求访谈过程中同步进行的，而不是项目组内部闭门想出界面，然后拿给客户进行评审。
• 画界面的工作不会因为推后而减少。
• 需求访谈中对界面的访谈与分析有可能比用例分析还要早一步。示意图方式的界面会很大的消除需求的歧义。会给用户最直观的感受，是我们认识系统的第一个门户。
• 更早的对操作页面进行确认会减少项目的风险。如果在概要设计评审的时候发现有一些界面设计的不合适，然后发现修改这些页面居然还会导致上一阶段的需求分析结果进行改动的话，这样的返工成本就要大很多了。时间压力也会更大。
  

现在公司的项目管理方式

由于手头的项目非常庞大（基本上是50人的团队，1500万的合同），对公司有战略意义，又是新老板来了之后的第一个大项目，因此，管理层对项目非常重视，老板会亲自关注细节。因此，该项目需要做的非常“规范”！当然，如何规范是针对现有公司的标准来讲的。具体特征表现在：

1. 严格按照需求->概要设计->详细设计->编码->测试->发布的模式对项目进行计划。
   （听起来是严格的瀑布模式，呵呵，连一次迭代也没有。不过对于现在的公司来讲，能做到已经不错了。以前是基本没有设计阶段的，而且这次也会基本忽略测试阶段。）
2. 设计过程要求严格，例如一定要先搞出来物理模型并进行评审。然后再对各个模块的输入输出进行严格的定义。
   （典型的面向过程的设计方式。我了解了一下，公司的整个软件部门似乎没有几个人使用过UML进行系统分析与设计，更不用说更加激进的CRC分析之类的了。所以，理所当然，技术人员多数觉得JAVA框架中的ORM一层基本没有什么作用。当你告诉他们OOAD的过程中，物理模型有可能是最后一步时，很多人难以接受。）
   （我想主要的原因很可能是：现在公司的管理层和技术骨干主要都是在90年代末期参加工作的，那时候国内正是面向过程的流行时期。所以大家都已经习惯于这样的设计方式。然后就是这样一代一代的延续下来……）
   
3. 对文档的要求非常严格：包括在项目的第一周就需要提交细化到半年后的某一天的详细项目计划。而且各种文档名目繁多。
   （大家都听说过滚动式规划，但是做起事来还是如此。最后都变成了交差。）
4. 项目计划的全部意义就是那个*.MPP文档。而且一般需要维护1000～2000行吧。
   （既然老板是这样认为的，所以也就没有人敢质疑该如何维护2000行的project文档。）
   
5. 项目管理制度中规定：项目组内部沟通以正式的书面沟通为主，口头沟通作为辅助。
   （学过PMP或者对敏捷开发有兴趣的人会很吃惊是吧？）
6. 加班将作为项目组工作的一种常态。加班的目的是为了营造紧张的项目组内部的气氛。
   （为了加班而加班！当然也有一部分原因是客户造成的。客户是国家机构，嘴里高喊“深入实践科学发展观”，做起事儿来完全“人有多大胆，地有多大产”。）
   
7. 项目经理每天会忙于收发EMAIL，制定各种管理制度，以及制作各种报告等等。
   

不过似乎也不是一无是处，例如：

1. 公司里面有一些强人自己包装了SPRING，开发了很好用的MDA框架。
2. 老板亲自拍板，调集了公司最强的开发资源进入项目组。
3. 暂时不用考虑项目成本问题。
   

当面临的问题是生存时，任何承诺都是骗人的。

Google宣布：停止Notebook应用的开发，并停止其接纳新用户。

这让我想起了上一次的互联网泡沫破裂时的情况：263的老板在前一天还在信誓旦旦说要保留免费服务，转天就开始全面收费。

那一次事件之后，我对国内互联网服务提供商的信用彻底失望，虽然我不是受害者。从那以后我尽量会选用国外的服务提供商。

现在，在全球金融危机的影响下，大若Google都要出现类似的问题了。只不过，比起263，Google采用了很道德的方式。可以理解，当公司面临的问题是生存时，很可能别无选择。

我其实是非常依赖网络服务的：

• Gmail
• Google Bookmark
• Google Docs
• Google Reader
• Google Site
• Google Calendar
• Google Notebook
• Clipperz
• Dropbox
• Meebo
• 等等

这一次，我可有些害怕了。正在考虑一些desktop替代品。例如：

MS OneNote, Firefox, Keepass, Pidgin等等。还是自己的硬盘上的东东可靠啊。

项目才刚刚开始，就收获了不少教训！

CNPL项目才刚刚开始第一周，就收获了不少教训。

上周一的时候项目刚刚启动，PMO的人找我谈话，希望我能配合工作。我当然满口答应。

周二的时候，收到PMO发来的邮件，让我周四就需要提交：人力资源管理计划以及项目实施方案两个文档。这两个文档我在之前都没有听说过，仔细看了看PMO发过来的例子，才发现项目实施方案其实就相当于PMP中所说的完整的项目管理计划了。

于是加班加点写了所有能写的内容，周四的时候发了出去。其实这个时候需求访谈才刚刚开始，项目组内所有的人全都整天在客户方进行需求访谈。所以现在只能有需求访谈计划。我在发出去的邮件中还详细的注明了所有无法填写的内容的说明。

很快PMO就回了邮件，找出了很多问题。而且最郁闷的是，老板也回了邮件，针对我所注明的无法填写的内容一一批驳。话里话外好像是在说我的工作态度有问题。

于是我在周五的时候找我的二老板抱怨了一下。看来是传到老板耳朵里了，老板马上打电话过来安抚。而且，我看了一下老板批驳的邮件，还好，仅仅是发送给了我和二老板，并没有发送给PMO。所以心里也还好过了些。

由此事件，得出了以下一些教训：

1. 我本来真的很重视PMO的工作，因为我有8年项目管理经验，我是PMP，而且我也曾经是上一个公司的PMO部门经理。但是，现在在这一家公司，PMO的需求的优先级并不高，是很有协调余地的。前几个月我还在感慨这个公司对项目管理不重视，PMO的人地位也很低。现在看，可怜之人必有可恨之处啊。只给我两天的时间让我完成庞大文档，而且时机也很是不对，这让我不可能保证质量完成工作。
2. 我犯了一个错误：在项目初期就应该非常重视如何将工作分配到下属手中。
3. 我犯了另一个错误，在分析干系人需求时，非常重视客户方面的满意度，反而忽视了老板的需求。我本不该犯这样的低级错误的，可能是因为在这个公司当前的管理能力下，我对自己的管理经验过分自信了，以后一定需要注意。
4. 现在的客户的习惯是，一旦项目启动，就会立刻需要所有相关的文档。现在的公司也受其影响，老板养成相同的习惯。所以为了应对这样的特殊情况，需要在项目早期就写出非常详细的项目计划（甚至需要计划到9个月之后的某以前需要干什么）。当然，这样的文档没有任何实际意义，仅仅为了交差。而随着需求访谈的进行，项目范围渐渐明确了之后，才需要真正用功编写能够实际应用的项目管理计划。
5. 现在的环境下，项目经理管理工作还有更多的内容，甚至包括长期出差人员的住宿问题、办公场地的桌椅等等细节问题。这些在书本上是找不到的。