相信做嵌入式的码哥们在参与一定数量的产品设计和生产之后，都会发现一个问题，如果没有一个负责的产品经理，就会陷入到产品延期、沟通缺失、目标不清晰、需求不明确等等的问题，我目前也是达到了这样一个状态，为了解决这一问题，就开始对项目管理进行了一定的学习。
注：以下内容是在研读完《人月神话》和《IT项目经理成长手记》之后的一些心得。
时间是决定一个产品存亡的核心因素
项目开发时间是一个硬指标，由于不同公司和团队受到开发能力以及部件、框架积累的影响，单位时间的开发能力是一定的，所以不同团队在固定时间之内能推进的项目进度是不同的，针对一个目标明确的项目需要根据团队的实际能力对时间进行预估，才能保证在预计时间之内能够将项目进度推进到预期的程度。
项目时间划分十分重要
针对嵌入式项目，涉及的门类较多，如硬件设计、驱动开发、功能开发、应用开发、UI开发等，故一开始的时间规划能够在一定程度上保证项目的功能稳定性，不会在交付时翻车（在交付时翻车是非常伤心的问题，首先是甲方会怀疑团队的开发能力，其次是对后续项目的推进会有直接影响）。
若要按时按质进行交付（按量是需要根据团队的能力定量），则需要完备的规划、完备的测试，尽量缩短编码时间。较为合理是时间规划为：
- 1/3的规划时间
- 1/6的编码时间
- 1/4的部件测试时间（该部分时间为部件测试+debug+再次测试）
- 1/4的系统测试时间（该部分时间为系统测试+debug+再次测试）
项目管理者的心态
对事：
项目管理者需要正视自己的心态，需要学会先问自己，再问他人；
遇到问题优先分析自己的原因，并提出有效的处理方案；
针对复杂问题优先考虑战略层面，再考虑执行层面；
出现多种说法时，自己优先对一手资料进行调研，判断；
预先设想最坏的结局；
犯错后总结经验，争取不重犯之前犯过的错误；
项目开始就一定要看到结果，无论是阶段性结果还是最终结果；
保持乐观。
对人：
与人沟通优先理解对方的想法；
评价一个人优先评判缺点、后评判缺点；
有问题当面谈，不背后硕人坏话；
明白员工满意度来源于项目学习的新东西，知道和鼓励其成长，可能效果会更好。
对代码：
代码的变量定义应明确易读；
代码设计分为三层，驱动层、功能层、应用层；
驱动层应与被驱动对象的数据手册严格对应；
驱动层应善于使用结构体、枚举量、使驱动配置明确易读；
驱动层针对硬件接口、延时应有对应的port文件，便于理解和不同平台的移植；
驱动层应有对应的开发手册和使用指南。
功能层应有双向接口，一边对驱动层（调用），一边对应用层（被调用）；
功能层应对功能进行详细描述，使用指南；
功能层的接口寄存器应该简单明了（如AD则直接反馈AD对应物理量等）；
应用层多为逻辑构建，应多使用状态机的设计方案，不同代码有对应的状态图；
应用层应该和一开始的设计规划一一对应；
应用层功能面向对象，便于理解。
阶段管理+里程碑
设定里程碑并明确交付内容是按计划推进项目进程的重要方法；
在每次里程碑完成时，对项目管理者、项目执行者都是一个关键节点，一是激励相关人员、二是便于项目管理、三是从总体视角确认下一里程碑。
阶段管理是为了保证里程碑能在容忍时间内达到，通过对参与人员的工作进度的工作内容评价当前的任务完成比例，明确当前工作方向是否偏移，在下一阶段如何校正。
工作执行
工作执行有两个层面
1、开各位参与者自觉遵守、按质按时按量完成已经商议好的工作内容
2、根据各参与者的实际贡献进行考核，反馈到绩效奖金
本文内容由网友自发贡献，版权归原作者所有，本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容，请联系:hwhale#tublm.com(使用前将#替换为@)
