序
掘金上面有很多组件库相关的文章，彷佛没有哪个前端没有写过组件库。
项目本身没有什么大的技术难度，不过涉及到的东西还是非常多的，包括项目的立项，人力资源的分配，后期的维护。项目的开发反而是难度最低的，尤其对于前端而已，需求明确之后，东西总是能够实现的，不讨论质量。而其他方面，无论卡再哪一步，都会让你的项目毫无价值。
就像这一篇对于项目的立项过程。
不提供业务价值的项目就是毫无价值的东西
既然网上已经有很多和业务组件库相关的文章了，我这个专栏中和其他的有什么不同呢？
第一：我会事无巨细的把我们团队完成整个业务组件库的整个过程都描述出来，合并包括如下内容：
- 业务组件库的立项，开发计划书的业务背景怎么写？架构图如何画？思维导图怎么画？它们各自要承担的作用是什么？人员如何分配？如何确保项目的后期维护？
- 业务组件库项目的各种规范包括代码规范、提交规范
- 业务组件库的基础配置，文件目录结构，实现组件的按需加载，CSS实现样式隔离
- 业务组件库的组件例子
- 开发过程中碰到的各种坑点。
下面的内容包括项目立项的过程。
立项
作为一个开发，项目要立项，你需要得到两个人的支持，一个是你的主管，一个是你的部长。想要成事，就必须要经过他们的同意。
如何可以得到他们的同意呢？这就需要我们换位思考，他们需要什么？我们要做的事情能不能满足他们的需要？我们能不能表达清楚呢
首先，我们需要明白，我们开发和公司的关系是什么。公司是一大堆资产的集合，程序员依托于公司而生存，对于公司而已，程序员也不不是人，是资产。既然是资产就有高有低。公司想要发展，就需要将这些资产结合起来，创造更高的资产，公司才能够得到成长。
用比较专业的词来形容，就是员工与公司既是雇佣关系又是合作关系，你为公司创造价值，公司给你晋升发挥的平台，两者是相辅相成的，缺一不可，不可分割的整体。
那我们从上面这个认知可以得到什么信息呢？
- 公司并不在意你要做什么具体的事情，公司关心的是你做的事情能不能带来超过你需要的资产的价值
- 只要能够将自身的发展和公司发展相结合，那么我们也可以做一些更有意义的事情
所以我们的目的就很直接了，如何在实现自己的想法的时候，需要给领导画饼，我们的东西实现之后会创造的价值是多少。
想到一个题外话，不知道在哪里看到的。说想要得到技术上的提升，你需要模仿比你水平搞一个层次的，想要升职，就需要想象自己的上一级的人面对同样的问题是如何思考的
1 说服主管
主管可能比你更加的了解现在团队的问题。所以我们在面对主管的时候，方向就是将具体实现的技术计划一一告知。甚至可能是相互商量的一个关系，标题用说服确有不妥。
不过即便如此,也不能够空口来说，还是需要工具来承载我们要沟通的想法的。
这个工具就是，项目开发计划书。
包括下面这些内容：
- 项目的背景（为什么要这么做）
- 目的(做这玩意儿能够给业务带来什么)
- 对标(画饼，和现在已经存在的产品会有什么不同)
- 组件的范围(思维导图)
- 架构图(项目目录结构)
- 任务目标(要达到什么样的效果)
- 项目的背影：用于和主管同步思想，达成共鸣，有了共鸣，后边的才能够更加好的沟通。
- 目的：能够解决当前的什么问题，对于业务组件库来说，其实其他团队都有了现成的例子，阻碍并不大。
- 对标：让领导能够知道我们做这件事情的差异。
- 组件的范围：我们需要做的东西有哪些。
- 架构图：最大的作用是要给领导表明，我们已经经过了深度的思考，并且技术上具备有了可行性。
- 任务目标：吹牛，我们要达到的目标，比如说增效百分之50。
对于架构图的理解，我会在下一篇文章进行描述
2 确定任务边界
公司的现状:
- 已经有了UI组件库团队，而且他们也实现了一些可以直接使用的业务组件。
就想之前说的，我们在公司的时候就是一个个资产。如果你这个资产是花100元买来的，做的东西创造了180元的价值，那么对于公司而言就是正面的。如果另外一个100元的资产做的东西和你的一样，那么你们两个200元的资产创造的价值仅仅是180元。
所以说，公司是不运行这样的事情发生的，不然公司将不复存在。
领导最忌讳的自然就是重复造轮子，那么和UI组件库的团队确定任务的边界就显得非常的重要。
所以需要和对方的团队确定它们现在有了哪些业务组件，它们未来的计划是什么。
由此我们可以很直接的得出，在和对方沟通之前，我们需要做的准备有这些。
- 明确对方做了什么业务组件
- 分析我们业务组件库面向的多个业务项目的共性，看看哪些是可以抽离出来的
第一点我们很容易就能够得出结论，第二点是最重要的，也是最麻烦的。
我们除了需要将当前项目中的共性给抽离出来之外，还需要和对应业务项目的产品 确定未来可能的共性业务。所以说，在这个阶段，我们需要做的事情有两点：
- 抽离出现有项目的共性
- 确定未来的共性业务组件
当准备好我们需要的做的组件之后，方可和组件库的团队进行沟通。并和他们确定两件事情：
- 他们将来计划实现负责的是那些组件
- 这些组件他们的实现的截止时间是啥时候
3 确认任务优先级
当任务边界确定了之后，我们就可以和各个业务项目的产品进行沟通，确定任务优先级。
如何确定优先级呢？
有一个基本的方法论可供参考，下面优先级由高到低
- 业务团队还没有实现的
- 对应组件需求有所变更的
- 现存的业务组件待优化的
- 不常用的
- 其他
第一点和第二点其实是一样的，目的都是为了节省人力成本。其他的无需多言。
4 制定实行计划
任务的优先级确定之后，其实已经完成了部分的计划。人力资源的申请。
现状是：
- 每个迭代都是有业务任务的，如果需要将任务分配给其他小伙伴就需要和产品确定业务组件库的优先级，P1还是P2。 由于业务组件库是服务于业务的，所以有一点是业务的任务优先级更加的高。
- 设计是另外一个部门，业务组件库还需要单独去对接设计
所以我们作为负责人，在制定了开发的计划之后，还需要在每次迭代中，对人力资源分配的争夺。争夺的对象就是产品。
为了在和产品的争取更多的资源中，我们需要做两手准备为增加胜算：
第一、我们需要更加深度的参与到用户故事中。将自己的对于业务的理解尽量达到和产品一致的程度。降低双方的信息差。只有这样，才能够在需求确认的时候据理力争。
第二、争取主管的支持。这个不用多说。(或许这个才是最重要的)
其他的方法方式，可以参考我的另外一篇文章，产品经理不靠谱怎么办 - 掘金 (juejin.cn), 可供参考。
5 说服部长
部长的关注不在于具体的实现，而会对成本更加的具象化。除了项目开发计划书之外，还需要体现出人力的分配，时间的分配，以及完成之后可能会带来的价值。
比如说：
- 2022年11月2日进入alpha测试
- 2023年3月1日投产
这个价值更加具体一点就是你么你完成了这个业务组件库可以给业务项目带来多大的效率上的提升，最好是有具体的数字化的目标。
比如说：
- 效率，整体效率提升50%，单个模块/功能的工作量每人天减少30%
- 性能，FCP,LCP,LVP提升30%，页面体积减少50%
- 质量，前端缺陷率，降低60%
承载内容的形式就不会是文档了，而是PPT。
在得多主管和部长的同意后，才能够进行项目的开发。
自此，前期繁琐而有必要的项目准备工作就已经完成了。
总结
为了让项目可以成功的开展，作为项目的负责人需要和UI部门沟通需求和排期，需要和UI组件库负责人沟通确认任务的边界，需要和产品争取人力资源，需要提高开发技术书获得主管的同意，然后提高未来的业务价值给部长，如下图：
在完成这些，你才可以去搭建项目，确定规范这些项目基建。
当然，整个过程其实还是有所简化，如果你的团队在之前已经有了一定的基建。
比如说脚手架，那么你可能还需要和脚手架的负责人沟通，确认现有的脚手架是否能够支撑业务组件库。如果不行的话，需要和主管、脚手架负责人开会确认谁来提供，如果确定是自己，那么是否需要提高业务 组件库的模板放入脚手架之中。
比如说在确定任务的优先级的时候，还需要确认现有的业务替换成新的业务组件库的时间成本，人力成本，我们画的饼是否能够填得饱对应业务项目的产品。如果没有办法说服业务项目的产品，不提供排期来使用上业务组件库，那么我们做的东西是毫无意义的。
所以说，搞定部长能够让我们的项目立项，但是想要项目的顺利开展，争取主管的大力支持才是重中之重。
下一篇文章，会详细描述项目开发计划书怎么写，包括思维导图和架构图怎么画。
开启掘金成长之旅！这是我参与「掘金日新计划 · 2 月更文挑战」的第 1 天，点击查看活动详情
