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 ~

 待续···

项目经理应该知道的97个事件（后感）