分类： 项目管理
2007-12-05 11:19:51
1、编程的第一要务是先把事情分析清楚，事件先后的逻辑关系和依赖关系搞清楚，然后再去代码实现。一接到任务就开始Coding的程序员，通常就是加班最多的程序员。
我十分同意这个观点，要想写程序首先要知道你要做什么，获取了你要做什么而且知道要做的东西如何分解成小问题，他们之间的关系是什么你才能想出如何去实现它，还不知道自己做什么就去做，能做好才怪。
2、不是搬来一本“管理制度”给每个员工读一遍就要可以的了。
此话太经典了，制度不是用来读的，而是用来执行的，已不制度首先是根据公司的组织结构订立的，势能够执行的制度，然后是制度下发了要认真学习并认真执行，不执行的制度就是废纸一张。没有确定的组织机构，又如何能指望做出来的管理制度“合用”呢？没有制度，你没有办法和依据来惩戒员工，因此是管理者的过失；有了制度而没有惩戒他，是执行者和监督者的过失；一而再、再而三地犯错，又一而再、再而三地被惩戒，那就是教而不改，就真正是员工的品性和素质的问题了。
3、按照微软的惯例，授命项目经理的同时，会有“产品经理”、“开发经理”、“市场经理”以及“文档化和培训负责人”
实际上这时一个项目开发应该具有的角色设置，而实际上我们中小型项目是没有这些设置的，通常是 本书作者下边讲到的开发经理和项目经理合二为一。
4、协议并不能建立管理者与被管理者的信任，而只是确保了这种关系。
经典，但是有时候这中维系是必要的。
5、禀性难移，要改变一个人都难，何况是改变一个团队的既定习惯。
是呀，真是很难改变一个人的习惯和禀性，太难了。亲人和朋友都很难改变，更何况是同事。
6、重要角色的更替通常是极具风险的，例如项目经理或者开发经理；频繁的开发人员的调度也会直接影响到工程的质量和进度。
是呀，一个团队如果不能保证团队的稳定，怎么去保证项目的正常完工，一个项目团队的建立就要独立于其他项目专心去做才能保证计划时间内正常完成开发任务，而我们的企业真的能做到这点的有几个？大多都是一个人身兼数职，好象大家能力超群一般。而实际上每个人的能力和精力是有限的。
7、开发人员最好不要直接面对客户。项目经理有这样的一种优势：他可以不用了解C语言，也可以用一种非C的语言来与客户交流(比如说汉语)。
是的，与客户的沟通要有一个即懂得开发又懂得交流的人，这就是项目经理要做的工作，因为它不仅要和客户沟通，而且他要和开发人员沟通，它既能听懂客户的需求，又能把客户的需求清楚地告诉开发人员，是开发人员能知道怎么去开发。开发人员如果直接面对客户可能什么需求都不能开发。因为他们听不懂客户的需求，觉得客户提出的需求都不能开发。
8、咨询公司除了把问题搞得更加复杂之外，他们仍然需要面对最直接的问题：与客户如何交流？
太经典了，前不久竞标一个项目，他们就请了咨询公司，结果本来简单的需求搞复杂了，结果客户多花钱还没有适合的方案。
9、书中对UML的论述太经典了，用甲骨文和UML对比简直经典及了。（P48）
这样的论述实在是太有说明性了，我想没有人看不懂。
10、减少沟通和保障沟通质量的问题
客户和你的时间都是宝贵的，所以要用有限的时间解决关键的事情，所以要在沟通之前做好所有准备，把问题提前提出来，做好充分的准备工作，只有这样你才能更好完成既定的沟通。
11、维护旧项目比做新项目更难，许多人深有同感。然而这些“有同感”的人又何曾想过，自己在做“新项目”的时候，要为“项目维护”这种还不存在的角色，留下一个沟道、对话的渠道呢？
是呀，这也许是中国做项目人的通病，我们再写文档的时候总是在考虑他没有用，可是有谁考虑过对不是参与这个项目的人文档对他们是多么的重要。维护一个没有任何文档，甚至原程序都不全有程序还没有注释的程序那真是还不如自己开发快。
一些参考的记录内容有：
需求阶段：与谁联系，联系方式、过程、结果以及由此引发的需求或变更；
设计阶段：如何进行设计、最初的构架、各个阶段的框架变化、因需求变更导致项目结构上的变化(有助于了解构架的可扩充性)；
开发阶段：每一种技术选型的过程、每一种开发技巧的细节和相关文档、摘引的每一段代码、算法、开发包、组件库的出处和评测；程序单元的测试框架；每一个设计和构架变更所导致的影响；
测试阶段：还记得测试用例和测试报告吗？那是最好的history之一。
12、项目经理的工作，就是要去组织这个工程中的各个角色，使得分工明确，步调一致，共同地完成这个项目。
项目经理更多的是组织协调而不是开发，他所知道的并不一定比开发人员多，但是他要懂得的面要广，要能很好的理解需求并能很好的讲解需求，同时能够有很好的协调能力和分配能力。能够根据资源计划开发计划。他的角色更侧重于协调。即协调客户又要协调团队。
13、在一个团队中，失去了组员的信任比失去老板的信任更为可怕。所以回顾每一个项目，或者项目中的每一个阶段，以及与每一个团队成员交流的细节，是你的日常工作。
说的很对，因为老板不会给你干活，而团队成员是要天天给你干活的，是你的项目能够正常完成的必要资源。当你的成员不再信任你，不再听从你的分配你的项目如何去做？记得有个故事大致是这样，两个吃人怪物应聘工作，他们要留下来只能通过试用期的考核，就是不能吃人，快到试用期结束的时候，两个人实在受不了了，于是就从领导开始吃，吃经理，有一天他的同伴吃了个普通员工，结果老板知道了，把他们辞退了。于是一个同伴就抱怨他说：“你干嘛要吃员工，吃经理多好，经理不干活，老板发现不了，你吃了员工没有人干活了，老板能发现不了吗”。我说的这个故事和原版有出路，大致是这个意思，讲的一个道理是要维护好给你干活的人。
附书：
文件:
大道至简.2005.11.06.pdf
大小:
928KB
下载:
下载
