频谱大数据——项目总结

1. 做项目和做产品是不一样的：

   • 做项目只有一个硬性要求：让项目保证《技术要求》全部达标；
   • 做产品在产品设计时就要在用户的角度上考虑，用户需要的是一个什么样的产品，都要有什么功能，想要什么样的体验，要让用户感觉到我们是切切实实的在替他考虑。自研产品是要拿来卖的，要让用户觉得物超所值，所以在产品设计上就要考虑展示更多的功能，显示更多的数据。有时候增加一个“包装”就可以达到1+1>2的效果，比如平安果。记事本也可以写程序，但为什么开发人员都用vscode，就是因为vscode站在开发人员的角度上去做这个产品，想到了开发过程中需要的功能，将它加上去，想到了开发过程中更为舒服的排版布局，将它加上去。

2. 在项目计划初期就要明确分工，然后每个模块的设计由该模块负责人来设计，如数据库的设计就应该是负责数据库的人员来设计，而非项目经理设计完成后交代下去。这样做的弊端：

   1. 增加沟通成本；
   2. 项目经理与数据库负责人付出了相同的劳动，增加了时间成本；
   3. 数据库负责人在数据库知识方面一般比项目经理要专业，可以更高效的做出设计方案

3. 对于项目经理来说，知识的广度很重要，只有项目经理的知识面足够广，在面对问题时才能给出更好的解决方案，面对客户的疑虑时也可以多方面考虑后给出最优的解决方案。

4. 对于一个应用程序，安装过程尽可能的做到让用户“傻瓜式安装”，服务环境可以通过放到应用安装程序中随着应用程序一起安装，数据库可以使用sqlit+二进制文件存储的方式实现，避免了mysql等数据库的安装与初始化的过程。

5. 项目开始的第一件事就是需求分析，汇总甲方的所有需求，挖出潜在需求，提炼出刚性需求并分析，产出需求分析文档，该文档需覆盖甲方所有的需求，并给出解决方案，然后在做设计。

6. 所有来的文件，不论是文档、程序还是文件，如果想修改，则拷贝一份去修改，不能直接修改原文件。进行文档的版本更新，保证其可追溯性。

7. 项目的文档，在评审前一定要组内过一遍，每个人都认可这个文档之后再安排文档评审

8. 项目的文档，将文档中各个模块的编写分下去，每个模块的文档需要每个模块的负责人编写，项目经理的职责是汇总。

9. 个人认为，最高效率的办公方式：

   1. 以项目小组为单位分配工作室，工作室内小组成员集同办公，为小组成员营造一个专心做当前项目的氛围，且能够大大提高沟通效率。
   2. 每个工作室一个白板，绘出项目的计划、当前情况、当前状态等信息。

10. 前后端分离，不仅仅是代码位置分离。后端是需求的映射，而不是前端页面展现形式的映射。不能前端更改每次都要修改后端，后端设计的时候看的是需求文档，而非UI图。

11. 每天拿出一小时来管理项目进度：晚上半小时检查小组成员项目完成情况和计划第二天小组成员要完成的任务；早上半小时分配任务，安排project。但并不是项目管理每天只需一小时，而是在一天中必要的时间点去和团队成员进行交流，与小组成员一起排除问题，研究技术途径以及查看任务完成状态并识别风险。

12. 遇到问题时，一定要先研究出多个解决方案，然后反复验证所有的解决方案，找到最优的可行的解决方案后，再去实现。一定不是找到一个方案就花时间去做，做到最后发现，这个方案不可行，那么时间就白白浪费了，增加了你项目的风险。

13. 遇到问题在找解决方案时，要从结果出发，沿着路线往自己擅长的领域推，而不是从自己会的小范围出发去解决思路，不能把自己局限起来。遇到问题后，首先可以看看别人是怎么解决的，我是不是可以借鉴。比如：我有一堆泥巴，需求是造一艘航母，如果从自己的小范围出发，那么就会花时间造一个泥巴船，花时间造完之后，发现并不是自己想要的，但时间已经浪费了，得不偿失。如果从造一艘航母出发，那么我会思考，别人是怎么造的，都需要什么，我可以得到什么，还需要学什么，或许整个过程也不会使用你擅长的泥巴，但把事情做好了，这就是能力。航母做好之后，你的能力和技术栈又提高了一个层次。

14. 遇到风险或问题，如果自己无法解决，一定要集思广益，叫上领导、小组成员以及能人异士一起讨论，一个人一个思路，这样解决问题会更快。

15. 一个项目一定要有进度计划，且是唯一的一个进度计划。所有的方案、文档、汇报中的进度描述必须是出自该进度计划，防止同一项目的多个文档中出现多个进度计划。

16. 项目风险点一定要提前想到。自己拿不准的任务，就是风险点，风险高的任务，优先级应该就高，应该提前安排，提高容错率。

17. UI设计的完成的标志是设计图达标，一个UI设计的任务，要分阶段产出。如一个UI设计任务，时间为3天，那么不能3天后给一张图就可以了，因为可能那张图你并不认可，那么就没有时间去修改了。所以正确的做法是，在第一天出一个草图，是项目经理通过的草图，也就是说中第一天的草图需要在下午三点左右就要出来，然后与项目经理去讨论，根据讨论结果进行更改，最终在下班前调整出来一个符合要求的版本，做任何事都要给自己留容错；第二天出一个基本的图，流程和第一天一样；第三天出一个完整的UI图，流程和前两天一样。将一个任务分解为三个任务，并分阶段产出，这样就很大程度上提高了任务的容错率。

18. 一定要复盘提升，站在第三方的角度上将项目的整个研发流程走一遍，客观的、多角度的去思考”为什么“。跳出自己的角色去分析问题会更容易发现问题。好的复盘是对整个流程的回顾，而非对结果的总结。因此，复盘是从过去汲取养分，用于未来的成长。有些人的十年经验也就是把一年的经验用了十年。

19. 日志打印功能一定要在开发初期编写完成，然后在开发的过程中按需调用，在可能出现问题的地方将问题写到log日志中，做到系统运行时出问题有在log日志中就能找到问题之所在，而不是去打断点或打印log一步一步的排查问题。

20. 写文档时，在评审之前也要叫上小组成员和领导一遍一遍的过，不能直接在评审会上拿出来，这样风险很大。

21. 如果项目分期，那么每一期完成之后要形成一个稳定版本。要尽量保证随时能够拿出来个稳定的版本，确定每一版本的完成情况。每一个大的版本有版本号，如1.0,2.0,3.0等，每一个小的版本也要有版本号1.1,1.2,2.1。并在版本介绍中说明项目需求完成情况。每一期都会有需求列表，在固定版本README.md文件中要有体现。

22. 项目管理中的绩效分配：

    1. 首先按照工时分配绩效是不合理的，因为同样的一个任务有的人需要一天完成，有的人仅需要半天完成，理论上来讲任务是一样的，两个人在这个任务上获得的绩效也要是一样的，而且在管理者角度上会更优先于将任务分配给后者。
    2. 其次按照完成的任务数量分配绩效也是不合理的，因为不能保证所有任务的量都相等，量大的任务和量小的任务不应该获得相同的绩效。
    3. 基于以上考虑，可以按照积分分配绩效（在project中对应为任务的“工时”），项目经理将每一个任务根据任务量进行积分赋值，然后进行任务分配。一个任务的积分是固定的，一个人需要一天完成，一个人需要半天完成，不论是谁来完成这个任务，所得到的积分是相同的。如果在任务分配时小组成员表示技术不熟，需要的时间较长，那么项目经理就可以考虑让会的人去做。这样可以让能力更高以及愿意付出的人得到更多积分，从而获得更多绩效（此时积分为衡量这个项目组成员对于这个项目的绩效的唯一标准），等到项目奖金下来之后，按照绩效进行奖金发放。这样既没有触及到员工的基本薪资收入，又可以提高员工的工作积极性与能力提升积极性，因为能力越强收入越高。
    4. 产出 = 效率 * 能力 * 时间。如果想要提高产出，那么首选一定是提升效率和能力，提升效率需要手段（绩效激励），提升能力取决于员工自身，如果说效率与能力到达瓶颈了，才会去考虑增加时间，因为增加时间所提高的产出是很低的，而且会降低员工的工作积极性或者提高了项目开发成本（加班费）。
    5. 每个项目的绩效根据完成时间而变化。如项目A领导决定3个月完成为标准，小组具体完成花费了3个月，那么每个人根据自己手里的积分都会拿到响应的标准绩效；如果小组具体完成花费了2个月，那么项目A的总绩效就会乘以一个大于1的系数，所有人拿到的绩效会更多，虽然积分是相同的，但是项目的绩效奖金总量增加了。但是如果小组具体完成花费了4个月，那么项目A的总绩效就会乘以一个小于1的系数，所有人拿到的绩效会减少，虽然积分是相同的，但是项目的绩效奖金总量减少了。

23. 只有被量化且被记录下来的才能叫需求，仅仅是客户的一个想法不能算是一个需求，后续调整的概率很大，而且会导致理解上的偏差，甚至差距越来越大。

24. 问题发现的越早，解决的成本越低。

25. 写文档是一个项目最重要的事。因为后来者都应该通过文档来了解整个项目，而不是通过口口相传。一个失败的项目示例：新同事接手一个项目后，项目没有需求文档，没有运维手册，没有用户操作手册，没有设计文档。项目一出现问题，都得打电话求助原来的开发者，关键是原来的开发者也记不清细节了。。。所有的流程都得靠看代码、走测试。

26. 前端开发上，那些全局的事件回调函数需要统一处理，比如全局点击，快捷键等

27. Vue开发：

    1. 每一个 Vue 组件(等同于模块)首先必须专注于解决一个单一的问题。

    2. 组件命名：有意义的，2-3个单词且具有可读性。如：

    3. 组件props原子化：

       1. <!-- 推荐 -->
          <range-slider
            :values="[10, 20]"
            min="0"
            max="100"
            step="5"
            :on-slide="updateInputs"
            :on-end="updateResults">
          </range-slider>
          
          <!-- 避免 -->
          <range-slider :config="complexConfigObject"></range-slider>
          

    4. props提供默认值并且使用type属性校验类型，使用props之前先检查该props是否存在。

    5. 避免将this赋值给其他变量，若真需要，考虑使用箭头函数解决。

    6. 各个组件应保持独立，哪怕是父子组件，谨慎使用this.$refs和this.$parent等API。如果一个组件需要访问其父组件的上下文，那么该组件将不能在其他上下文中复用。

28. vue开发先装volar插件，其优势：https://zhuanlan.zhihu.com/p/401160130

29. 在统计情况时（如小组成员1 2月份任务完成情况），先准备好模板，然后分别让小组成员按统一格式填写，会大幅度减少信息汇总所需时间。

30. 在开发时，遇到数据不同单位的情况，一定要保证整个项目中单位统一，如果显示界面需要变化，那么也仅仅在显示界面变化，切勿变化逻辑模块！！！

31. bug高发的js or ts：

    1. Number.toFixed()方法会将Number类型转为String类型
    2. 数据单位不统一，导致比较的判断不准确，建议整个程序同类数据使用同一个单位，必要时在显示时变更单位即可
    3. 使用anyscript导致模块和函数未能在接收参数这一步就把异常检查出来

32. 遇到问题后，抓准问题的根源，去找解决方案，而不是为了解决解决方案的问题而去解决问题。比如，用户想使用奇异值阈值算法对数据进行补全，找到的代码都是MATLAB代码，前端无法直接运行，然后就去研究如何将matlab代码转为js，发现转不了，然后去研究如何将matlab代码转为c，想转到c之后再转为js，前前后后花费了很长时间，但回过头来想，其实用户并没有让你去转代码，甚至都没有让你去研究奇异值阈值算法，他知识想用奇异值阈值算法进行数据补全，这才是我们要解决的问题。所以问题来到了js这边，只要我js能拿到奇异值阈值算法计算的结果即可，然后去看奇异值阈值算法都怎么能运行：1. 使用matlab运行（行不通）；2. 使用matlab将代码转为python运行（可以）；所以我们可以用python将算法打包为一个exe程序，后续用node运行exe程序，传入原始值，接收补全后的值，问题就解决了。

33. 企业的知识资产是积累来的，一个企业知识资产很少不可怕，可怕的是它不去积累。解决问题是一种能力，将解决问题的方法为我所用更是一种能力。同一个企业中，一批人遇到问题去百度不可悲，可悲的是下一批人再遇到这个问题还要去百度。

34. 分配任务要因人而异，能力强的成员安排挑战性更高的工作，可酌情给予更高的绩效分数，能力标准的员工安排基本的工作，按标准给绩效分数。比如，CV的工作给谁的都是需要相同的时间，所以避免资源浪费，CV工作完全可以给标准的员工。

35. 要识别出项目中所有的风险点，如果无法解决，尽早向项目发起人汇报，寻找解决办法。

36. 未雨绸缪永远都是正确的选择。在演示、部署之前准备好稳定的系统；在项目策划时识别出所有的风险点，尽早研究出解决方案。

37. 如果一个功能模块需要处理不同类型的数据，那么在设计时就要将不同数据的处理逻辑全部梳理清楚，并将共同处理方法封装起来，放到一个文件夹中统一管理，后续不可随意改动。然后每个类型的数据都有一条自己的处理流程，在此流程中按需获取公共方法，引用时可使用装饰器等手法在不改变原本方法的情况下按需调整方法使用，一定要保证后续系统维护时调整一个数据处理流程后，不可牵一发而动全身。