规划
1、让项目组养成一个好的工作习惯，适当的框架是必须的；
2、明确目标是该阶段的第一要务，建设项目组的一致性。
需求
1、升级项目开发，用户提出较多新业务时，一定做好新建设系统与前期版本的差异分析；
2、用户需求要在规格中尽可能详尽的描述，并和用户反复确认，对跨部门的业务，要进行跨部门的串讲，理清楚所有业务关系；
4、用户会指挥你，这很正常，注意你自己的节奏是在你的控制中；
5、过程是小好，结果是大好，一堆的小好，到了结果可能是大不好，要处理好原则和非原则问题；
6、不是所有的问题都能够达成一致理解，大家寻找理论上合理的解决方案。
公司关系
1、及时汇报工作，让关心项目的干系人知道我们到了哪里
2、其他人没有你清楚项目真正的问题在那里，要不要其烦的解释你遇到问题和需要的帮助；
3、一定要对非业务需求给予足够的重视，包括性能指标、运行平台和技术要求；
4、界面需求一定要做细致，并和用户通过原型确认，把可操作的原型尽可能早的提供给用户进行体验性确认；
5、必须专职的人员负责需求，并统一的接口和用户进行需求管理方面的工作；
6、用户提交书面的用户说明书是必须的，协助他们理清楚他们的业务要求，否则后期的变更将没有办法控制，找不到任何依据；
7、没有资源充足的项目，合理配置和搭配团队，建立合理的工作规范。
8、在新手独立承担工作之前，一定采取一定方式的培训，尽管会影响项目初始的进度；
9、该控制的资源不能控制，就别干了，即使干，也要把最后的结果及时告诉你的领导
项目管理
1、及早制定可执行的尽可能简单的规范，并在项目组中达成一致理解；
2、工作模板是必须，但前提是使用，不要做复杂的模板；
4、在技术使用上不要忽视任何技术细节，技术上真正的问题花费的时间都比他看上去要多；
5、公共的技术问题，需要专人负责。
用户关系
1、对待用户的要求，要有足够的耐心，只要他说的是需求方面的问题，我都有义务替他们解决；
2、用户的要求不是所有的都合理，我们任务是让他自己认识到这点，否则沟通是无效的；
3、和用户沟通要有一个底线，有些事情你怎么做他都不会满意，因为他不是要的结果，守住底线；
6、把业务模式转变成技术模型，要尽快验证模型的实现，不要冒险使用过多的新技术。
编码
1、编码规范是必须的，规范不是限制大家创造，是要告诉大家需要统一的工作成果模式；
2、你的用户可能痴迷于形式过于内容，你必须尽早的和他就规范达成一致，并在项目中监控规范的执行；
3、持续构建是你编码控制过程利器，一定要使用，不要怕在初期耽误的进程，开始牺牲一点进度是没有问题的；
3、需要帮助的时候要提前大招呼，并进行跟踪，否则大家没有时间关注你的问题；
4、营销和销售必须成为你的后盾，你只是负责把事情做好，其他的可能是越处理越糟
1.2
序号
经验
1
制定好计划，并和每一个干系人确认；及时跟踪和检查计划的执行情况，并做好计划变更工作
2
树立专家的形象，提出你的意见和建议，并把它写成文档；要不厌其繁的和用户确认需求，并要求用户及时签署需求确认
3、做一件事情之前，要让所有的项目干系人明白我们要做什么，并对采用的方法、过程、规范和工具达成一致理解；
4、计划制定之后，必须要根据项目情况变更，并跟踪执行情况；
5、检查和审查是项目中必须的工作，制定阶段审核计划并执行是必要的，不管进度有多紧张；
6、及时报告遇到的困难和项目问题，通报可能风险，让所有的项目干系人来参与；
人员
1、人员计划是最核心的计划，合适的人，做合适的事；
2、规划合理的人员结构，对项目必备的资源做一个评估，在沟通的基础上安排项目工作，做到人尽其才；
3、外部资源使用上，必须有计划，对其交付的成果必须及时验证；
4、尽量控制人员流动，大家结合成一个团队；
5、调整项目过程，适应不同的人员配置；
6、无论资源配置多么紧张，必须有两个“游击人员”
8
其实大家都做的不错，一定记住表扬他们
9
相信每一个人，但要控制和限制，中肯的指出她还有要改进的地方
10
重视配置管理，会为我们带来无穷的效益
11
任何时候别忘记征求客户的意见，可能她不是技术专家
12
建立尽可能简单的沟通流程
13
分层次管理，让大家进行好的自我管理
14
主动及时反馈是必须的，让领导放心－回报
测试
1、定义好测试范围和方法，和用户和干系人说明测试的进程，测试后产品的情况；
2、定义好发布流程和缺陷管理的方法和流程
3、关注边界和异常流程测试
4、一个大系统的质量属性测试是复杂的，需要投入高技术的人员，及早沟通可能设计缺陷
5、关键环节上的测试提前设计，可以对开发有指导作用，也可以叫做“测试驱动开发过程”。
设计
1、架构设计理论指导是必要的，在架构设计时不要太关注细节
2、尽可能早的把设计的架构实现，不是一直讨论其中的细节
3、如果在架构考虑使用第三的任何工具，首先必须有足够的原型支持，否则没有办法控制技术风险
4、设计要到适当的粒度，不能过度设计，也不能设计不足，建立统一的框架时必须的
5、如果用户很关注技术，也比较了解技术，可以和他们交流设计的过程、方法和产品，但必须告诉他们并直接记录说明他在设计中做的决策，由他最终负责
7、必要的培训是必须考虑的，一对一的培训是最高效的在线培训方式；
8、不要只是低头拉车，要停下来总结一下，这样才能走的更好；
9、项目范围和系统范围很不同，项目范围更广执行更加复杂。
技术
1技术公关团队，是解决技术问题最好的方法；
3、如果可以不从头开始，就不要从头开始，站在巨人的肩膀上很重要；
4、把编码过程依据业务级别分阶段执行，在每一个阶段执行完成后，进行总结和分析
5、建立专门的编码支持小组，特别在编码第一个阶段的投入是必须的，带来的好处是无穷的
6、代码清单和发布说明必须严格控制，测试组一定严格执行约定的接收标准，这样开发人员的责任性和交付产品质量才能够由更加充分的保证。
7、在集成测试持续构建的过程中，测试人员要和开发人员及时进行沟通，分类问题进行促进
经验和教训
1.1
分类
经验教训
合同
1、在启动项目时，一定对项目合同进行评审，对合同的附件和正文中的内容，各项目干系人达成一致理解，并对有异议的部分进行记录并制定对策。
2、对合同中规定的管理相关的内容，要在计划中细化，并和用户达成一致理解，减少项目执行过程中不必要的沟通带来的执行被动。
3、项目范围要和公司合同负责部门、直属领导和用户重新审查，并对项目中的例外、假设和限制条件进行风险分析，编制第一个风险列表。
3
每人制定一周最优完成工作的计划，并附有风险列表；项目经理根据项目组成员提交的列表，制定项目风险前十名，并提出规避风险的方法
4
框架设计要尽可能早的开始，并至少让两个人参与
5
如果项目组达到了十个人或以上，不要让每个人参与编码工作，至少应该有两个“高手”来复查代码
6
测试时间不能压缩
7
要试图要每个人认识到，她在项目组中有多重要和不可或缺，她是项目团队中主力成员