一、项目经理和项目管理流程的价值
芯片或者复杂智能硬件基础上的软件开发是一项复杂的系统工程，它需要不同模块和专业的分工和协作，随着公司发展、项目和开发人员增多，在软件内部各部门以及软件和其上下游（芯片/硬件/测试/市场等）之间的协同和沟通工作将成为整个项目交付的关键路径。此时因为跨部门的沟通渠道不畅或流程缺失通常会带来一系列问题：比如项目进度延误（进度管理），前期需求不明确、中后期需求变更频繁（范围管理），前期交付标准不清晰、后期交付质量不达标（质量管理），部门间职责不清、关键事项丢球漏球无人check、研发士气低落（资源/沟通管理），成本超支（成本管理）等。
而初创公司由于团队是新组建的特点，上述问题可能会更加突出，主要原因是团队成员来自不同背景的公司，在研发流程和习惯甚至一些专业术语、文档撰写逻辑上都存在差异，如果没有建立统一的规范，造成项目前期团队文化打磨时间长影响效率；另外初创公司对产品的快速交付有较大的压力，对研发进度和产品交付周期有较高的要求，而上述的公司可能的问题就会对项目的交付形成掣肘，虽然各个部门都在努力奋战，但整体产出效果并不明显。
为解决以上问题就需要一位经验丰富的项目经理从软件整体交付的角度出发，对公司现有流程进行梳理和总结，对已得到证明的项目管理理论（PMP/ACP）和过往的实践经验进行裁剪和定制，逐步建立一套完整但轻量的的研发/项目管理体系和流程来建立跨部门、跨专业协同和沟通的渠道和规范。项目经理从项目的范围、进度、成本、质量四个方面按PDCA循环的流程不断监控项目状态，并通过风险/沟通/干系人等方面的协同管理，分析出当前项目状态和存在的重大问题，并组织资源解决实际状态和目标之间的差异，从而使项目受控。对于开发和测试人员来讲项目经理是喊号子的人，统一大家的步伐，使各个模块的分力能够合成最大的合力，推动项目的正常快速前进，保证项目的交付。
公司维度的项目管理流程体系建立后，项目的过程文档使得项目变得可回溯，项目中或者项目结束后通过对问题的回溯把人的问题转化为流程缺失或不健全的问题，进而去补全和优化流程。然后通过另外的项目检验这些流程，最终形成组织过程资产，再去指导新的项目和新的项目成员。长此以往，就建立了研发/测试人员对这套流程和体系的整体认识，进一步减少沟通成本，提高工程效率，保证新项目的正常交付。
二、项目管理体系在的芯片和互联网硬件公司的探索
以下项目管理理论在传统瀑布模式（芯片公司）和敏捷模式（互联网+智能硬件产品）两种形式下的不同展现和探索。
2.1 芯片公司的瀑布模式
X讯是一家芯片Turkey方案厂商，它有一套成熟的产品开发流程。流程是一种系统化的管理方法，是建立在对以往成功经验的总结，通用流程是对项目共性的总结，提取出了工程过程的一致性，而在执行具体项目时要注意处理好共性和个性之间的关系，处理好经验和创新之间的平衡。这套管理系统通过产品开发流程协同了市场、产品、芯片、硬件、软件、测试、售后等各个部门，完成了项目最终的turnkey solution交付。同时在具体项目的实践中一定程度上也推动了流程优化和组织能力提升。
分解到软件的子开发流程和项目管理模式，一脉相承的思想是要建立结构化的项目管理流程，将整个软件产品的开发过程纳入一个逻辑框架中，以保证相关人员能有共同的认识，知晓项目的每个里程碑、知道如何相互协调好配合。
软件的具体开发阶段如下：
1、需求定义/风险评估/储备技术提前开发阶段
2、FPGA/Zebu验证阶段（verification）
pre-silicon verification阶段目标是通过测试左移提前发现芯片设计问题，软件需要关注代码在验证环境和芯片环境存在的不同，以便代码后续移植
3、BringUp（芯片/硬件/软件）和Pre-PTR0
post-silicon validation：ATE -> 小code -> 大code
4、PTR0（项目准入阶段）
5、PTR1（全功能和功耗测试阶段）
DDR/CPU固定频点，保证稳定调试软件功能
6、PTR2（功能/功耗/性能/稳定性调优阶段）
逐步打开和合入DFS/DVFS/CPU hotplug/thermal策略等系统级feature， 同步进行稳定性测试和性能测试，比如高低温/mp4软硬解播放/掉电测试/adb push/Monkey/MTBF等
7、PTR3（RC阶段，支持alpha客户量产）
在上述的每个阶段，都有准入和准出的标准，包括必要的文档/测试报告和评审结论，比如PTR0阶段的检查项目和准出标准如下表
通过上述每个检查项的准备，将项目的状态/工作包/风险和计划进行了充分的梳理和确认，在项目前期各个部门明晰了工作责任/计划、识别了风险并形成了应对方案，将极大的保证了项目的如期成功交付（特别是软件部分）。
2.2 互联网+智能硬件产品的敏捷探索
X户是一家有互联网基因的机器人产品公司，在机器人量产之后，我们根据公司的实际情况对敏捷开发模式进行裁剪和改善，在整体为Scrum框架并且遵照3355仪式的情况下，探索出了软件版本列车的"班车"和"搭车"制度、四级灰度制度、需求评审和需求变更流程、用户反馈流程等；在开发过程中也吸收了kanban（看板）、XP（极限编程）等一些开发实践来提高工程效率。
互联网开发模式讲究小步快跑、快速迭代业务，快速试错，通过用户反馈来优化业务设计和流程；而机器人的系统和算法是底层能力，对稳定性要求高，需要充分验证和尽量少更新；为了解决“快业务”、“稳系统”、“准算法”之间的矛盾，我们制定了版本列车规则，系统和算法需要满足一定的条件（专项测试流程）才能进入版本列车，具体如下：
业务：采用“班车制”，Scrum两周一个版本，班车不晚点；
系统：“搭车制”，对于轮毂驱动、底层时序等相关修改，专项压测通过后才能“搭车”->系统测试；
算法：“搭车制”，视觉/语音/SLAM算法更新后，需要经过研发自测->专项测试->系统测试。
这样在整体版本为敏捷模式的情况下，将系统/算法也纳入流程，统一了版本节奏，减少了开发/测试中的人的因素的影响，通过这个流程和例行的仪式来代替人的个例沟通，极大的减少了沟通成本和因沟通渠道不畅或个体原因造成的返工。
在版本灰度制度上，整体有四级灰度（参见下表），一个月两个版本，一个稳定版（主要修bug/少量feature），一个开发版（大量feature/新鲜功能体验），稳定版本会全量发布，开发版进行到三级灰度（客户可以申请进入此灰度名单）。
通过四级灰度和稳定版/开发版的版本纵深，既满足了业务快速迭代的需求，保证了稳定版全量时rom的验证的时间，确保了版本质量。
