1 用户及早参与项目，向用户展示所有能展示的东西。
2 高质量的代码远比速度重要（速度不差距太大的情况线下）
3 兼容性，项目完成日期前之前完成项目。
4 需求分析 类1
5 复杂问题/吸收器，复杂性转化成简单软件。
6 保持代码洁净，极早修改有问题的代码。
7 培养人才，而不是寻找技能精通的人。
8 需求分析员与项目实施之间的交流。
9 尽量使用现有的开发工具，站在巨人的肩膀上。
10 与客户进行面对面进行需求分析，不应该与中间者交流。
11 （一知半解0.0）
12 如何寻找人才
13 优秀开发人员才是王道
14 分模块定负责人（工作流）
15 严格执行工作流程（即使流程未跟上，也要坚决执行）
16 完美不是指无可增，而是指无可减 -----少就是多原则
17 ~无~
18 商品的价值决定软件的价值，从而决定项目组的价值。
19 业务分析人员可作为项目经理的代理
20 20分钟定理（开发人员要20分钟才能进入状态），同一个开发人员参与多个项目，效率降低50%
21 项目经理的存在于解决各种问题。
22 无为而治。开发人员在上网不代表人有问题，反思管理方式。
23 聪明代码很难维护。聪明=复杂=难以维护
24人为因素。经验论不行，减少环境对开发人员的压力。
25 ~
26 （笔记看不清楚了 0.0#）
27 估算 ---- 软件开发人员的风险估算
28 ~
29 ~
30 加班不是目的，成果才是目的。
31 同30
32 用户的表面问题透过现象看本质，本质问题才是关键。
33 完成与文档相关---项目的重点在于文档的完备。
34 二八定律，2分钟开发，8分钟维护。
35 ~（讲了个大道理，泛泛而谈）
36 5W what when where why who
37 自我救赎
38 会议的救赎
39 开发新软件时，想改变现有流程时，考虑流程的安全性。
40 ~
41 缓冲时间，时间节点设定的重要性。
42 bug是不可避免的
43 实行站会
44 方法论在实际效果可能不太顺利。（方法论在项目开发中是行不通的，只可以借鉴）
45 ~
46 一件文件的任务需求由一个人负责
47 需求永远在变化。
48 建立可持续的团队，跑马拉松而不是冲刺。
49 时间--成本--范围 是一个三角关系。
50 同49
51 项目范围的重要性。
52 ~
53 成员的差异
54 合同纠纷，法律是万不得已的手段。
55 评估的标准，解决了团的价值取向。
56 项目管理---一套流程 方法是通用的，比如借鉴医疗和民航。
57 要现在不要马上。“零件”现象
58 不可过于追求速度
59提高士气的几种方法。
60 团队
61 提高团队的效率，为团队服务。
62 改变不可避免
63 危机意识，可以应对危机的团队。
64 系统集成---说明文档的重要性。
65 分布在不通地方的开发人员，沟通需要很大的重视。
66 胸有成竹？
67 清晰的条款等于长久的友谊（与甲方）
68 最好的估算人员是那些做实际工作的人
69 沟通
70 ~
71 ~
72 ~
73 ~
74 范围改变经常发生，要适应它。（最好具有***必须具有，之间的区别）
75 购买现场软件的一些建议。
76 面对不同赞助人的方式。
77 不应该承诺过多的功能。
78 每个项目经理都是管理者，控制变化。
79 事件重要性与紧急性的划分。（尽量做到重要，但是不紧急才是关键点）
80 ~
81 状态的假象，完成是由客户决定的，而不是状态报表。（客户的认可）
82 公众演讲，精简、重点。
83 士气。
84 项目利益相关者。
85 计划的真实意义。
86 团队信息交流通道。
87 管理交付品。
88 取长补短，项目经理不是万能。
89 时常召开即时会议，取消徒劳的会议。
90 ~
91 ~
92 减轻开发人员状态报表 or 提高开发人员的热情。
93 完全控制有时会出现反效果。（万能道理）
94 分享（例会），分享自己的技术给团队。
95 ~
96 ~
97 ~
待续···
原文地址：http://www.cnblogs.com/lanlianggui/p/6723267.html
