为什么项目会出现这样的情况呢？单就这个项目来说，先抛开人员的能力问题来讲，我觉得就项目管理方面来讲，有以下几方面的问题：
1， 对项目的评估不足（包括项目的复杂度，风险，人力投入等）
在项目开始的时候，过于乐观，认为技术不是问题，因为对项目的技术风险，人员的投入都没有进行充分地评估，就急急忙忙码代码了。
2， 项目计划制定得过过于宏观，没有仔细做好任务分解
我认为项目经理最重要的任务，就是将项目进行分解，做详细的开发与验证计划。这些恰恰是这个项目欠缺的。项目经理认为，只要我们给了业务流程，再把原型图给到前后端，就不需要再制定项目计划了。由于没有深入到具体的操作层面，把质量和进度的风险把握到细节。如果项目中不能够及时调整和规避风险，很容易到出结果的时候已经为时过晚。所以项目计划也是一个不断渐进明细的过程。
3， 项目监控不到位
项目监控不是一会松一会严就能做好的。项目监控应该有固定的频率和方法。这位老板最严厉的时候要求开发人员用什么番茄工作法，每十五分钟填一次日志，我真心觉得这除了增加开发人员的工作量以外，没有别的用处了啊。这位老大严格起来像疯子，宽松起来就更像疯子了，前端没有按照要求完成任务，他帮前端开脱，后端没有完成任务，他帮后端开脱。这样忽左忽右的态度，研发人员无法适应。
项目计划阶段是制定完整的项目计划，并最后确定项目的目标和范围，指导后阶段项目执行，是项目成功的重要保证。对于复杂的项目，在各领域、各层次都需要进行全面细致的计划工作。
两次世界大战时期德国都被打败，但德军的作战形象依然是令人望而生畏的，素质优秀，战斗力强大。德军的大脑总参谋部发挥着核心性作用，他们有一项特长，就是在战前制定周密的计划，比如一战时的施里芬计划，二战时对波兰、法国的闪击战计划，对苏联的巴巴罗萨计划。德国人制定作战计划时的详细和刻板是让人难以想象的，甚至每一支部队有多少人力，匹配多少武器装备，补给的运输计划等都非常详尽。
一位著名的德国将领曾经坦率地说“战前必须制定作战计划，但战争一旦开始，所有计划必须作废，听炮火的声音指挥部队方向。”他想说计划没有用？当然不是。计划的目的是为了统筹复杂的事务，事先制定计划有重大价值，首先制定计划的过程就是明确战略方向，统一上上下下意志和决心，盘点资源家底的过程；第二点，通过细化执行计划可以形成小型的执行模块，在计划执行过程中虽然整体计划调整，但各个小型执行单元仍然能够高效推动；第三点，如果事先有计划，应变者就有一个资源框架可以利用，制定计划、执行计划、调整计划这一系列动作中，资源是最重大的约束和限制条件。
德国军队以善于做计划闻名，制定计划也造就了德国基层指挥官的高素质，一方面他们被强有力的计划约束目标和行为，一方面他们根据战地瞬息万变的局势发展，作出有针对性的调整和部署。
德国军队的战斗力构建经验告诉我们，没有计划是万万不行的，有计划不执行，不应变也是不行的。
那么我们来说说如何预防进度拖延
明确目标和需求： 在项目启动阶段确保对项目目标和需求有清晰的了解。这有助于避免在项目执行过程中因为需求变更而导致的拖延。
制定详细计划：制定详细的项目计划，包括里程碑、任务分配、时间表等。合理规划工作量和时间，确保所有相关方都对项目的时间表有共识。
风险评估和管理： 在项目计划中加入风险评估和管理步骤。提前识别潜在风险，制定相应的应对计划，以减少可能的拖延。
团队合作与沟通：保持良好的团队合作和沟通非常重要。确保团队成员明确任务、进度和项目目标，及时沟通问题，避免信息断层。
追踪和监控进度： 定期追踪项目进度，确保项目按计划进行。使用项目管理工具来监控任务的完成情况，及时发现并解决潜在的问题。
阶段评审： 在项目的关键阶段进行评审，确保项目在每个阶段都符合质量标准和目标。这可以帮助早期发现问题并进行纠正。
合理分配资源：确保项目获得足够的资源，包括人力、资金和设备。合理分配资源可以减少项目拖延的风险。
采用迭代开发模型：对于大型硬件项目，考虑采用迭代开发模型。这样可以在项目早期交付部分功能，减小项目整体失败的风险。
技术验证和原型测试： 在项目早期进行技术验证和原型测试，以验证关键技术和功能。这有助于在项目后期减少因技术问题而导致的拖延。
灵活应对变更：虽然尽量避免变更是重要的，但有时变更是不可避免的。建立一个合理的变更管理流程，确保变更不会导致不必要的拖延。
需求与计划的变更管理
其中最重要的措施我们分解分析如下：
【措施1、用人】
《曾国藩家书》中有许多关于用人之道的精辟见解，简而概之：广揽、慎用、勤教、严绳。
1. 广揽，通过各种途径挖掘各方面人才。
要想广揽人才，首先要有科学的择才态度。“英雄莫问出处”这话虽然简单，但真正在选人时几人能真正摘掉有色眼镜，不问学历，不问出身？曾氏帐下各种人才俱至，这首先得益于曾国藩独到的识才艺术。
2. 慎用，合适的人要用在合适的岗位上。
很多人会广揽人才，但能用好人才的却不多。曾国藩虽然广揽人才，但在人才的使用上却非常谨慎。他善于从细节上判断一个人的品性德行，从而对人才形成全面的判断。
曾国藩在主政两江时，很多乡亲好友前来投奔他，但他都是给足盘缠要他们回去。他说：好马劣马不能同槽喂食，否则好马也会变劣马。我的两江总督府是一个人才府，如果平庸之才也进了人才府，那么真正的人才就会寒心而走人。
3. 勤教，就是经常培训、教育。
曾国藩很善于通过书信、面谈及饭前闲谈对部属进行培训、教育。书信好理解，曾国藩家书洋洋洒洒几百万字，无所不谈。面谈相当于今天的绩效面谈，总结成绩，指出不足，探讨改进方法，促进部属成长。这些培训方法让曾国藩帐下很多人受益匪浅，这在100多年前相当难得。
4. 严绳，就是通过建立健全规章制度来管理和督促部属。
制度不健全，好人干坏事；制度完善了，坏人也做好事。100多年前的曾国藩就明白了这个道理，并进行了丰富的实践，可叹今人还在这个问题上认识不清。
这8个字中，“勤教”是最难的。这也是华为说的：“先固化、再僵化、再优化”，这个过程，需要主管、项目经理下足够的功夫。例如“例会”、“问题跟踪”，很多很多次的动作才能形成一个习惯，很多很多的习惯才能形成一种传统，很多很多的传统才能形成一种文化。华为的流程文化，也是很长时间的历练才能形成，并且有大量人的智力和体力的投入。
所以在初创团队中，要想建立一套“规章制度”、“规范”、“流程”，这些文档网上都有，流程建立的核心是“人”，流程执行的核心也是“人”。华为的IPD流程，网上有很多文章，照搬肯定不行的，关键是吸收精髓，然后为我所用。
项目经理的人选就尤为重要，项目经理的选人也非常重要，这是为什么华为让研发人员去负责招聘，而不是交给猎头公司和HR，是有原因的。
所以老话说得好：“兵熊熊一个，将熊熊一窝”，初创团队的CEO、大公司的项目经理，决定项目和公司的生死。
【措施2、把牢需求，从源头控制进度】
从上图可以看到，产品的开发之前，需要有一个收集产品需求的流程。这个流程，保证了两点：
1、需求是有依据的
2、需求有基线，归档并跟踪
3、需求有讨论，不是一言堂，不是拍脑袋。
需求控制出了问题的话，就会出现范围蔓延。
范围蔓延从内部和外部都有可能发生。由于开发人员往往出于主动性，会把自己放置在用户的角度思考，会按照自己想法臆想需求，往往就会出现需求的范围蔓延，无端的增加了很多原本没有讨论过的需求；一些定制项目的硬件开发周期比较长，客户很可能在开发过程中随意的提出一些不合理的需求；有些老板和领导在开发过程中发现了新的价值点或者新的商业机会，也会忍不住要提出新需求。
为了避免需求在开发过程中的走样，我们需要进行“范围管理”。项目范围的管理也就是对项目应该包括什么和不应该包括什么进行相应的定义和控制。它包括用以保证项目能按要求的范围完成所涉及的所有过程，包括：确定项目的需求、定义规划项目的范围、范围管理的实施、范围的变更控制管理以及范围核实等。项目范围是指产生项目产品所包括的所有工作及产生这些产品所用的过程。项目干系人必须在项目要产生什么样的产品方面达成共识，也要在如何生产这些产品方面达成一定的共识。
范围管理的目的是在项目开发过程中，出现范围蔓延。范围的蔓延，势必影响项目的质量、时间和成本。所以，我们需要制约项目的需求蔓延，制约一个项目需求蔓延，就的条件是确定项目“约束条件”——范围、需求、时间、成本、质量。范围的蔓延，势必影响项目的质量、时间和成本。
范围管理
【措施3、拆解关键动作，保证计划落实】
在项目中大家可能都经历过以下几个场景
案例一：销售和客户签好了合同，产品迟迟交付不不来，销售抱怨研发硬件团队太不靠谱
大家去饭店吃饭，点了菜等了良久，却迟迟不上菜，心里急的好像热锅上的蚂蚁。产品交付延期给客户的感知就是如此，销售人员催你“赶紧供货啊”，可你还有好多问题没有解决完，这时后悔当初不应该把计划排的这么激进。一个难解的技术问题就导致这个计划达不成了，客户催，销售着急，可你也没办法啊。
所以硬件计划一定要靠谱，计划不靠谱，别人就会觉得硬件项目经理不靠谱。
案例二：单板回来了，软件调试没有准备好，下一步测试活动迟迟开展不了
项目进度紧张，等着设备抢占市场，硬件工程师加班加点，提前完成了PCB投板工作，还加速完成了单板加工，第一批单板产出时间比原计划早了两周。单板回来了，发现底软的同事还没有完成调试软件的准备，基础模块调通整整花了一周时间，大家都在等待中，这一周测试活动都没法开展。硬件工程师心里急啊，那些省出来的时间都是团队成员辛苦努力的成果，可在单板调试这里阻塞延误了一周，太可惜了。
后来，我们的团队在制定计划时对，项目开发中耦合关系重点清楚，什么时候硬件给制作PCB的工程师，什么时候单板能回来，软件什么时候能提供可以用于测试的软件包，试制验证BOM什么时候能稳定，这些都是重点讨论的内容。
案例三：老板觉得你的计划不够细，要求你细化到天，排计划费时费力，指导意义差
老板对你负责的项目非常重视，5个月内一定要把产品交出来，他自己来审核项目计划，你把准备好的计划拿出来给他看，他觉得不太满意，他给你提了新的要求：“小明，这个项目对公司的很重要，提前一天都是有价值的，你这个计划还是太粗了，尽快拉大家再讨论一下，我们的计划一定要细化到天，要以天为颗粒度制定执行计划。”对这个任务你直挠头，不过老板的指令一定要执行啊，于是你连夜拉着团队成员把计划进行拆解，终于排出了细化到150天工作计划。可项目一开始时就发现问题了，计划颗粒度太细了，很难执行，绑住了工程师的手脚；项目早期，特别是项目开始的时候内外部环境条件很大，项目计划需要修正的地方很多，一个过分细化的计划，每次调整耗时耗力。最后这个“精细”的计划被束之高阁，大家都觉得之前排的计划好用，时间颗粒度大并不影响执行，可以在周例会上对齐刷新，特别是关键任务准备开始时，可以针对关键任务拆解细致。
总结以上的几个案例，项目有序开展就是靠项目计划指引，计划是项目的节拍器，计划首要是要靠谱，按照承诺的时间点交付；好的计划会在各团队耦合点上充分进行讨论，做好充分的准备，避免因为互相之间的等待消耗时间；制定一个好的计划一定是分层分级，逐步明晰的，不要追求项目一开始就制定一个完美精细的计划，我们要保证的是方向正确，逐步调整，利于执行。
立项评审通过后，就正式立项了。从项目的开始到项目关闭，项目管理者始终都会奋战在一线。项目开发主要的几个阶段：
项目启动（概念）→项目计划→项目开发与验证→项目发布→项目关闭
项目启动:启动阶段说白了就是拉人成立山头的过程。告诉大家，我有番号了，是正规军，你们都跟着我干吧，面包洋酒都会有的。于是SE，测试经理，硬件，软件，结构，RQA，配置经理统统都来了，来给开发代表打工了。开发代表介绍立项材料，需求，大概可以花多少钱，多长时间内要完成。然后大家一起评估下工作量，看看时间是很紧张呢还是很很紧张呢。
这个阶段必须要完成一些基础的配置：比如项目编码申请，创建项目基本信息，记录预算分摊关系等等。
项目计划：华为的项目计划包括很多个独立的计划：开发与验证计划，版本计划，版本转维计划，测试计划，质量策划，还有子项目计划（硬件，软件，结构，逻辑等等）。
做这么多计划的核心，其实还是那句话，将一个庞大的项目切分成模块，各个模块的负责人再来根据模块的具体情况，手上的资源情况，制定进一步的计划。开发代表这个时候要做好的就是各方的沟通协调工作，特别是有依赖关系的几个模块，在计划上就一定要衔接好，还要充分考虑可能出现的风险，留出部分的预估时间。
项目开发与验证：这个阶段的重点工作其实就是跟踪与监控了，定期检视各个子项目的进展情况，是否有突发的风险，需要新引进的物料是否能按时走完流程，一些特定客户需要的认证准备，等等。还是一句话，跟踪和监控需要有序有力地进行，任何不确定的因素都要想办法确定下来，不给后面的发布埋雷。大多数的项目经理都会用到的一个管理工具推荐给大家《任务跟踪表》。
项目发布：按照计划执行对内对外的发布，项目验收，做好各方位的交接工作。其实只要项目的进度偏差不是太大，也没有出现重大的bug攻关不下，到了发布这个阶段，基本上大家都可以稍稍松口气了。当然，还是不能大意。这个时候，更多的是跟各方的一个交接动作。
项目关闭：关闭遗留问题，项目编码停用，文档归档，经验教训总结等。该奖励的奖励，该打板子的打板子。(此处,可以说明华为年终奖与此挂钩)
这几个主要的阶段介绍完了，看上去是不是还是蛮简单的。实际上在整个的项目管理的过程中，还穿插着大量的风险管理，需求变更管理，团队成员的即时激励等等工作，有时候紧急，有时候可以缓缓，但是都需要开发代表妥善的解决。我对一件事情印象很深，就是我当时所在的整个小组都被借到另外一个产品线去做服务器的开发项目，就是因为当时这个项目的硬件经理不给力，直接被开发代表撤换，然后又没有合适的人力投入，开发代表就通过种种办法，硬是完成了不可完成的任务。从团队的磨合到解决前期留下的各种问题，天天都是忙飞了，这种进度和强度，都是很大的。
好的管理是“过程管理”
【措施4、统筹方法】
1、用好跟踪工具，并与绩效挂钩。
开发代表,只是负责项目群，对产品的各个版本的交付负责，所以他负责在整个产品的各个版本交付的时候，有很多工具PMM（类似于Redmine系统，web的项目管理软件）、缺陷库、问题跟踪表、燃尽图。这些工具，很多初创团队都有在用，但是是否落实在实处？就看计划的严肃性和绩效管理是否挂钩。这样的话，大家都重视计划，胜则举杯相庆，败则拼死相救。
2、计划制定，要严谨，并用统筹方法分配进度。
我们以“智能电源盒”项目作为例子，一起看看如何分层管理，逐步明晰一个项目计划。
1、先定目标，做出整体计划，设置里程点
项目开始阶段，硬件项目经理为了统一全团队目标，设定了整体计划，这个计划除了定好项目的起点和终点以外，最重要的是定义我们项目中的里程碑节点。这就好像长跑中我们把20公里的跑步总长度分为几个为几公里长度的小目标，一个个目标跑出来，每跑一个看一下离之前的时间目标差距有多大，再根据体力情况和时间目标进行调整。
在做智能电源盒这个项目的时候，我们就是立项，设计和计划，单板投板，研发验收，客户验收这5个关键节点，每个节点都有一个可考察、可量化的目标。在项目执行的过程中，如果各个节点进度或质量差距很大，那就要对项目亮红灯预警了。
智能电源盒项目整体计划的设置
| 序号 | 里程碑点 | 里成碑时间 | 阶段性目标 |
| 1 | 立项通过 | 2月10日 | 项目立项通过，确定项目的交付范围、整体计划、质量目标、资源要求。 |
| 2 | 总体设计 计划细化 | 3月15日 | 1、硬件总体设计完成，确定设计方案 2、项目计划细化。 |
| 3 | 单板回板 | 4月7日 | 硬件详细设计完成，单板加工回板，整机等关键配套回板。 |
| 4 | 研发验收 | 6月15日 | 产品研发阶段测试验证活动完成，质量问题全部解决。 |
| 5 | 客户验收 | 7月15日 | 设备小批量交付，在客户现成适用验收，软件功能优化。 |
2、分层细化项目计划，跟随项目开展逐步明晰项目计划
立项完成后，整体目标已经明确，随着项目总体设计逐步深入，对项目难度、关键风险也更加清楚了，这时候项目经理把硬件、整机、软件三个团队责任人召集在一起，分单板硬件开发计划、整机结构开发计划、产品软件开发计划三个部分，共同讨论，细化项目计划。
例如在硬件开发计划里，电源盒里3块PCB单板的投板回样时间，单元测试完成时间，功能测试完成时间等，硬件改板时间等进行细化。制定的计划是否合理依赖三点，首先是通过参与设计并结合自己的经验深入理解项目难度，接着要掂量团队执行能力是否能达成目标表；另外，对和别的团队依赖关系要琢磨透了，比如这个项目中强电控制板试装和整机验证结果就影响5月中旬单板改板能否投出去，单板硬件责任人就要把什么时间必须完成试装和测试的要求提明确，从整机工程师那里拿一个承诺。
总结一下，对准整体计划制定的目标，项目计划需要通过集体讨论分层或分模块进行细化，并随着项目的开展逐步明晰。
3、找到计划中的关键路径，集中精力管理
硬件项目经理的精力是非常宝贵的，纵使你有三头六臂，也很难把项目计划中的每个细节都关注到，需要把有限的精力投入到最关键的地方。我们在这里推荐的就是在计划中标定出“关键路径”，之所以关键就是这些事务或工作中耦合关系多、执行难度大、延期风险高，对项目达成目标影响较大的，因为关键，值得项目经理集中精力管理。
在智能电源盒项目里，我们标定出两个关键路径。
关键路径①：是整机设计和初样验证的，对这种外观有定制要求，硬件集成度高，还有特殊环境适应性和安规要求的产品，整机设计、打样、试装问题解决一定要先于单板验证完成，把整机的问题先暴露出来。
关键路径②：项目开展各种验证后，要收集全发现的问题，完成单板的“定稿”。越是接近硬件项目的收官阶段，越是要冷静，把问题和风险收集全，判断项目的质量水平，完成整机、单板BOM、单板改板等工作，进入最后的项目冲刺阶段。
这些可能会影响项目成败的关键事务在项目制定计划时就要标定出来，项目执行阶段特别关注，“特事特办”，确保成功。
4、关注依赖关系，关注风险
智能电源盒的项目如火如荼的开展到5月第一周，整机试装已经完成，单板的调试和单元测试已经完成，经过硬件工程师内部对现阶段测试结论的评审，结论是PCB1需要通过改板解决发现硬件问题，PCB2、PC3两块模组单板只要优化BOM就能够解决所有硬件问题，同时，整机试装问题和EMC测试问题都已经在优化解决。现阶段，只要我们能保证PCB1顺利改板完成，落实PCB2和PCB3的单板BOM优化，我们就有信心项目准时顺利交付了，因此改板成为这个阶段最关键的工作，我们把主要的项目成员聚集到一起，再次去对齐计划，确保最后的交付工作万无一失。
| 序号 | 工作内容 | 完成时间 | 责任人 | 状态 |
| 1 | 硬件验查漏补缺，如智能电源模块上强电控制板预留的蓝牙模块、语音模块验证。 | 5月10日 | 老付 （硬件） | Open |
| 2 | 软件功能相关测试查漏补缺，分析一下尚未完成集成验证的软件功能，那些和硬件相关，那些和 | 5月12日 | 小美 （软件） | Open |
| 3 | 测试项评审，包括单元测试、整机测试、功能测试、软件相关项测试全部投板前的评审，全部发现的问题都已经解决。 | 5月12日 | 老付 （硬件） | Open |
| 4 | 新物料准备，如变压器需要重新修改，解决已经发生的EMC问题，新变压器的修改要求和首批物料的采购要求 | 5月13日 | 小明 （硬件） | Open |
| 5 | 物料清单优化，要把已经发现的问题上通过BOM修改优化。 | 5月13日 | 小明 （硬件） | Open |
| 6 | 原理图/PCB改板投板：PCB1改板投板前做修改点集中评审，先核对是否所有修改点都已经落入PCB改板，再分析修改点是否对已经完成验证的功能、性能有影响。 | 5月14日 | 小明 （硬件） | Open |
| 7 | PCB改板投板后，优化钢网，为改板单板汇报试制做准备。 | 5月17日 | 小时 （整机） | Open |
项目计划的执行不会是一帆风顺的，错综复杂的耦合关系会让项目在等待中消耗时间，出乎意料的风险会让延期措手不及，风险管理时项目执行中必要一环，在智能电源盒中通过一张风险管理表格，我们提早就开始预测项目风险，并提前准备应对措施。
智能电源盒中两个风险管理的例子
| 序号 | 关键风险/依赖 | 规避措施 | 责任人 |
| 1 | 单板物料缺乏，软件、整机很多活动无法开展 | 1、提前稳定BOM，做好研发阶段芯片备料。 2、单板投板后催料PCB加工，联系生产资源，下线后空运送到研发。 | 小明 （硬件） |
| 2 | 单板上市前要完成准入测试 | 1、预约认证机构资源，完成专业认证。 2、联系客户，约定时间进行客户现场验证。 | 小时 （整机） |
【措施五】跟踪闭环
记住解决问题的思路，然后所有的活动，模板，管理方法都要根据自己项目的实际情况进行制定和修改。
别人的火点不燃自己的灯。
在项目各个阶段都需要进一步根据实际情况，细化近期计划。否则阶段内的计划不完成，总体计划注定完成不了。
没有计划万万不行，但辛苦制定好的计划束之高阁更不行。坚定执行制定好的计划，监督执行效果，对偏差及时变更，在项目交付过程应对变化不断的刷新，计划要方便管理，
1、制定好的第一版计划先要基线化，确保有据可依
制定好的计划对团队外是承诺，对团队内是目标。充分讨论达成一致后，要把这个达成一致的计划进行基线，比如标定好版本号，放到团队文件夹里。这个基线完成后，团队下一步的行为有据可依，如果计划有变更，就说明变更原因，升级版本号。
2、计划要监督执行，发现延期时要“喊出来”
计划是团队运作的行为依据，项目经理要盯着团队成员的执行情况，如果有人延期了，要及时提醒他“嘿，你落后了”，也要提醒项目组其他成员“注意一下他的延期对你有没有影响”。我们在项目中常常会陷于技术事务的处理，忽略了抬头看目标，因此项目计划及时监督和例行对齐在项目运作中就很重要，例如，可以利用项目周例会对齐进展，对于投板这样紧急关键的事务甚至可以每天早上站会花10分钟对齐计划，让信息快速传递。
3、计划要赶得上变化
项目的中我们随时都要是应对变化，客户需求变更了，关键技术问题迟迟解决不了，团队关键成员离开了，项目费用不够了，你要随时对这些变化保持“敏感”，而最危险的就是对变化视而不见，死板的沿着固有路线执行。
已有的计划给了我们方向感，也给了我们一个资源框架，当你意识到变化时，就要主动开始调整计划。比如，如果某个模块关键技术问题难以解决，就要重新审视一下，下一步工作事务中是不是有和这个模块不耦合的，拿出来提前开展，不要让局部事务延期的影响蔓延；如果团队关键成员离开了，就要看他负责的事务是否能拆解到别的团队成员里，如果分解了这些事务就要根据工作量的情况和团队成员的能力重新调整执行策略。
最后，计划变化后要及时知会全团队相关的成员，利用好周例会或每日站会，做好广而告之“计划调整了”。
4、资源保障是计划能够执行的依赖
计划再完美，都是靠人来执行，项目中想要计划走的下去就是把人力保障好，下图中我们是智能电源和制定计划时的人力估计，根据事务预估每个月需要投入多少人，如果老板说“放心干，咱们有人”，那这个计划执行的成功率就高很多。
硬件项目还要额外关注费用，硬件单板要钱，专业实验的温箱预定要钱，产品认证要求，项目每走一步都有花钱的地方，同样，这个也需要你做好费用预算，留好费用。正所谓兵马未动，粮草先行，资源都有了，你放手干就行了。
遗留问题——勤跟踪、要闭环
了解全流程开发，可以了解这本书
有没有一本书读后，相当于华为工作十年经验？