项目中有时会有一些任务的时间是不可控的，不可控的原因在于该工作完全受制于他人。意思就是如果其他人没有做好，比如前后端同步开发，前端通常可能会快一些，然后要等后端提供接口，这个时候联调工作是没办法开展的，也不知道什么时候可以，自己就会很被动，走走停停，既浪费时间精力，也容易没有任何产出。这种通常是其他人还没做好的情况，最怕的是那一种，比如设备那边说已经很OK了，现在可以开发了，然后去试用了，发现还是不行，然后一下子不知道该干嘛了，也不知道什么时候可以改好，等的话可能要很久，就浪费时间了，不等的话可能一下子就修复好可用了，自己完全处于左右为难的状态。 之前有APP项目就是这样的情况，本来APP功能已经开发好了，然后测试阶段，设备经常出现问题，可以用但是又不稳定，经常测到一半就测不下去了，然后反馈给到设备那边，改了好几次，觉得可以了，又继续测试了，后来还是不行。反复多次我才醒悟苗头不对，不能再这样下去了，立马中止项目测试，和设备那边沟通，设备需要确保完全没有问题，再继续这个项目的工作，可以说是血的教训。 这个问题之所以会造成那么大的影响，是因为我们在和他人协作的时候，没有和对方明确一个具体的时间节点，而是很含糊地回答道：“等某某完成了我才可以对接”，然后再问一句：“那他什么时候可以做完呢？过几天吧”，到底是几天？哪一天的？不知道呢。这样是有隐患的，因为这些模糊的信息，负责对接的开发同事完全就是看天吃饭了，任何结果完全是随机的。过几天，可能是一天，也可能是两天，甚至是一周或者更多，再者，项目负责人调整项目任务的时间也会变得很困难。 我们需要和对方明确一个具体的时间节点，比如前端同事需要问下后端的同事，接口是哪一天可以提供使用，而这个使用的意思，基本上是自测过的，不说一个Bug都没有，至少是相对稳定的。我们知道这个具体的时间节点之后，就可以先安排其他事情了，项目开发工作的开展就会很清晰，而不是完全混乱的。

在项目当前版本的功能开发任务都完成之后，人就空出来了，通常这个时候，项目负责人还有很多繁琐的工作要做，比如项目内部验收、提交测试申请和版本发布等等。为了给项目成员找事情做，就匆匆忙忙安排下个版本的任务，然后项目成员只是简单了解下需求，就开始敲代码了。前期的需求分析、方案设计、开发计划，项目负责人是没有时间系统地去梳理的，这就容易造成项目成员在新功能开发过程中，需求理解有偏差，加上当前版本发布时间节点不明确，目标感也不强。 项目负责人的开发任务应比项目成员提前3天左右时间结束，这个时候项目的其他功能还在继续开发，项目负责人可以借机着手准备下个阶段的任务（之所以是下个阶段，而不是下个版本，是因为有可能不是迭代这个项目了），将需求进行梳理分析，编写方案设计和制定开发计划，等到其他项目成员开发任务完成之后，就接着下个阶段的任务进行，项目负责人这时再回到当前项目，去做内部验收和提交测试申请，整个衔接是很清晰顺畅，不至于那么被动，捉襟见肘。

储能行业正站在新的风口浪尖，一份《新型储能制造业高质量发展行动方案》为我们揭开了这个领域未来发展的神秘面纱。这份方案不仅描绘了储能行业的发展蓝图，更给相关企业指明了前进的方向，释放出巨大的市场潜力和发展机遇。今天，咱们就来聊聊这份方案透露出的储能行业机会点，以及企业应该重点关注的方面。 1. 储能技术创新：突破瓶颈，引领未来 技术创新是储能行业发展的核心驱动力。方案强调要发展多元化新型储能本体技术，包括锂电池、钠电池、液流电池等，以及高效集成和智慧调控技术、全生命周期多维度安全技术。这就好比是给储能行业打造更强大的“心脏”和更聪明的“大脑”。 2. 产业布局优化：集聚发展，形成合力 方案提出要加强产业布局规划，引导企业向资源富集、应用场景丰富地区聚集，培育先进制造业集群。这就像把分散的力量整合起来，形成一个强大的拳头，共同出击市场。企业可以借此机会参与区域产业集群建设，享受政策支持和产业集聚效应，降低生产成本，提高市场竞争力。 3. 产业链协同发展：上下游联动，打造闭环 引导优化供需关系，加强产业链上下游企业供需对接，形成协同联动机制。企业要主动与上下游伙伴建立稳定合作关系，实现资源共享、优势互补，共同开拓市场。同时，创新商业模式，如共享储能、储能租赁等，满足不同用户需求。 4. 标准制定与知识产权保护：掌握话语权，守护创新成果 在提升标准体系支撑水平和加强知识产权保护运用方面，企业要积极参与新型储能标准制定，争取在标准中体现自身技术和产品特点，提升行业话语权。同时，强化自身知识产权保护，培育高价值专利，借助知识产权运营提升经济效益。 5. 市场应用拓展：多领域开花，释放潜力 方案推动储能产品在电源侧、电网侧、用户侧等多领域应用。企业要针对不同应用场景，开发定制化储能解决方案，扩大市场份额。比如在新能源富集地区，支持新型储能支撑可再生能源大规模消纳；在用户侧，推动储能产品在数据中心、工业园区等场所的应用。 6. 国际拓展：走向世界，提升影响力 方案鼓励企业拓展国际市场，参与国际标准制定。企业可利用政策支持，提升国际影响力，参与全球储能项目建设，推动储能产品出口，融入全球新能源产业格局。 7. 企业应重点关注的方面 储能企业要想在竞争中脱颖而出，必须抓住技术创新、产业布局、产业链协同、标准制定、市场应用拓展及国际拓展等关键机会点。重点关注技术研发、市场布局、产业链合作、标准合规、客户服务和国际合作等方面。 总之，新型储能制造业在政策推动下蕴含着巨大发展潜力，企业只要紧跟政策导向，抓住关键机会点，就能在激烈的市场竞争中脱颖而出，为推动行业高质量发展和实现碳达峰碳中和目标贡献力量，同时也能收获自身的发展和成长。

我们在制定项目计划的时候，如果只是把功能开发部分列出来，如下图所示： 可能会造成项目延期，在上一篇文章《05-项目为什么总是延期》中已经分析过了，这里就不再赘述了，我们现在要探讨的是，如何制定一个项目计划呢？ 在开始项目计划制定之前，可以先了解一下开发模式的相关知识，这部分主要是《【清华大学】项目管理的逻辑（全6讲）》里面的内容，有兴趣的可以去看一下，还是很不错的。 1. 瀑布式开发 预测型开发，在还没有开始着手编写代码前，就可以提前预知结果如何，之所以叫瀑布式，是因为整个开发流程都是有序的，就像水从上往下流，每一步做很到位就到下一阶段。 2. 迭代式开发 迭代式开发，顾名思义，就是一个版本接着一个版本进行迭代，先将项目整体框架搭建好，然后基础布局全部铺开，就好像画人物肖像一样，先勾勒草图，画出人物整体轮廓，然后才依次画出脑袋、眉毛、眼睛、鼻子、嘴巴等等，全部画出来之后，才是着色。 3. 增量式开发 增量式开发，咋听之下，与迭代式开发的意思一样，实际上是不一样的，增量式开发的意思是，每次只构建一点，每个阶段就交付一部分，然后组合在一起，还是用画人物肖像来举例子，一开始先画头发，画完之后上色，然后接着是眉毛，画好之后着色，以此类推，全部画好一个地方再接着画另一个地方，如下图所示： 4. 敏捷式开发 适应型开发，灵活性很高，需求可以随时提，然后放到需求池里，可能两周一个周期发一个版本。因为能干的活儿很有限，就像坐地铁一样，人很多，挤不上去那就下一趟，所以敏捷开发的思路就是，未必做得到，所以下个版本实现需求，可以有节奏地持续开发。 以上就是常用的开发模式，但是我们在实际应用中，应该怎么选择哪一种开发模式呢？为此有一个STACEY矩阵图可以作一些参考，如下所示： 从上图中可以知道，选择哪种开发模式，是基于需求和技术两个维度去评估的，所以项目负责人在编写项目需求与方案文档的时候，可能就可以做出判断了。说回我们自身，开发模式毕竟只是项目管理中的一种技巧，要深刻认识到它并不是万能的，如果掉入盲目迷信权威的陷阱，那么就太死板了，真正应用的时候，还是要考虑实际情况，在遵循基本原则的基础上，要明白事物变化的重要性，在变化的世界里使用不变的方法是不现实的，没有任何一种开发模式能够适用全部的项目。 现在部门按照项目来管理，每个人都比较清楚自己要做的事情，也没有那么多交叉的任务，所以变更理应很少才对，在制定项目计划的时候，我们可以把项目开发的周期全部列出，虽然项目计划通常都会有变更，但项目计划最好能够做到有始有终，把全部任务时间明确一下，然后项目交付时间基本就确定了，其中的任意环节有变更，很有可能是不会影响到项目交付时间的。我们可以把项目计划分为11个环节，如下所示： 需求分析 原型设计 方案设计 开发计划 开发阶段 下版计划（下一阶段任务计划） 内部验收 产品验收 测试阶段 模拟升级 正式发布 复盘会议 如下图所示，就是根据这11个环节制定的项目开发计划，虽然实际情况会有所出入，但是可以知道这个项目12月底基本上就可以交付了，有这样很清晰的时间节点，对于接下来的开发工作，会更有目标和方向感，其中经常出现任务变更，大多是在开发阶段，但是并不代表做好这个环节就没事了，接下来的环节如果遇到问题，也是会影响到项目交付的，所以怎么能管理好一个项目，是需要多方面去思考和解决问题的，并不是只做好开发任务环节就行了。

当前一个项目在开发新需求的时候，我们制定的计划只是列出功能开发的部分，并不是整个项目全部的周期，这就造成项目从开始到能够正式上线，时间规划是不全面、不清晰的（只是代码编写部分有时间计划），项目负责人基本上只会关注功能开发的部分，至于内部验收、Bug修复、测试周期和版本发布时间等等环节，有点听天由命，完全是看前一个环节进展的情况而定——前一个环节进展顺利，那就到下一个环节，进展不顺利就变更下个环节的时间，反复几次，项目上线的时间一拖再拖，遥遥无期。 之所以会这样，是因为在项目推进过程中，我们聚焦的一直是解决项目当前遇到的难题，为了解决这个难题，不断地调整项目任务计划时间，明天后天下周下个月等等。也许我们可以转换一下思路：项目推进过程中，以终为始，以最终结果为导向，聚焦项目上线发布这个目标。为了达成这个目标，我们要采取不同的做事情方式，也就是多维度思考如何解决问题。 导致项目进度受阻的问题有大有小，如果是不可抗力的情况（比如有的项目需要用到设备，结果设备完全用不了），那当然没有办法，但这种情况相对来说还是比较少的。其他的那些问题就要想一下，是不是当下一定要解决，或者说一定要从技术层面解决才行呢？那当然不是，我们的需求只是解决问题，问题解决了就行，并不关心用了什么方式。就好像要从广州到北京，需求只是要去到北京，并不在乎你怎么过去，是要坐飞机、坐动车、自己开车或者打车什么都可以，只要能到北京就行。 在项目推进过程中，项目负责人遇到问题时，以前可能是这样思考的：“这个问题解决起来很困难，可能需要5天的时间，我要问一下，项目计划能不能变更，调整一下上线的时间？“现在的话，如果是以终为始，可能就需要这样思考了：“这个问题解决起来很困难，可能需要5天时间，这个版本计划11月15日上线，时间有点紧张——这个功能是不是必须的？一定是这个版本要加的么？能不能下个版本？为什么需要5天的时间，有没有其他更好的解决方案？5天的时间里，我是不是可以先做其他事情？测试阶段、发版阶段还有没有什么潜在的问题？第三方编译走通过了么？时间有点赶，问题有点多，可能要动员一下，让大家知道现在时间有点紧张，加加班才行了，宁愿赶在前面，也不要后面遇到问题了没时间解决。” 我们倾向于哪怕只是一点点可能性，也要挣扎一下，不要那么容易就缴械投降。还是要回到小平同志说的那句话：“不管黑猫白猫，能捉老鼠的就是好猫。”