一、Pd的问题
1、其他团队无权给开发同学指派工作
ZZZ随意给开发ZYX安排工作，详情参考SP的对话。
2、pd内部需求没有对标，让开发改来改去。
这个平台很纠结，两个pd，CY和ZZZ没有内部一致，各提各的需求，一个说做，一个说不做，他们内部都不沟通好。随便扔需求，测试只会看prd，但是改了东西，或者口头约定的，没有及时更新到prd。菜单改一下，去掉工作菜单，工作划出窗口加返回按钮。
3、前期需求模糊，不明确
展示规则需要考虑，比如数据很多，如何只显示一两个？是取第一个，还是最后一个？
4、需求变更
之前和CY确认过的需求细节，前端给过不同的处理方案，他选A，我就做了A，后面做好了，说改成B。比如工作是否需要反选？之前说的功能，prd评审会议上达成一致说暂时不做，后面又说要做，比如保存关系。
5、临时加需求
比如预警号存在，需要画出关系图。
6、刚入职
不熟悉流程，在最后阶段才提需求。之前达成一致不做的东西，后面都说要做，应该进行prd封版。
【建议】：开发同学可以接受临时的新增需求或者更改需求，但是不应该太多，1-2个即可，太多，pd同学就应该严重反思。如果加新需求，评估修改成本，对现有功能的影响。
ZZZ更了解用户需求，CY的流程化做的很好，prd也写的认真。
二、Ued的问题
ued不会主动给前端，每次都前端催着要设计图，iconfont。
1、设计太理想
没有考虑数据很多或者很少的情况，怎么展示；
tips展示，未考虑；
关系类型多个，只画了一个；
2、字体大小没有统一
图表设计，12px大小，应该保持统一。
3、未结合功能
设计图轨迹巡航与旧功能不一致，没有重启的功能。
4、ued更新太频繁
本期改了5版ued，单单首页的图片，前端配合改了8-9次，其他细节就不做陈述了，日后希望不要多次修改ued。之前开发配合ued加了交互，结果pd直接把功能隐藏了，浪费感情。
【建议】：ued设计了什么，麻烦内部先进行评审，再和其他团队评审。ued定版问题，最多修改几次？第一次第二次疏漏考虑不周，希望不要有第三次！前期是一个探索规范，配合修改的过程，后期应该拿着建立的规范去实践，尽量不要停留在原始地带。
开发同学可以接受少部分ued修改，但是不应该太多，3-4个即可，太多，ued同学就应该严重反思。
三、后端接口
接口不会主动给前端，每次都是前端自己去梳理接口，然后后端回复。
1、字段问题
字段对不上，字段返回缺失或新增，与之前接口定义不符，没有及时告诉前端；
2、字段规范
字段返回需要规范一下，比如status是1，2，不要用01，02；
3、接口太多
一段静态信息，分了不同接口请求，多达6个接口；
事先沟通，问后端哪些地方是多个接口的？很多时候，都是前端调用多个接口获取一块信息。
后端应该做一个接口合并啊。
4、接口变更
临时改接口，加字段，这是客户提的，如果能事先考虑，会更好；
5、探坑预知
链路的整体思考继续加强，权限问题要考虑；
6、评审太容易
prd评审太粗糙，需要严格把关。
7、技术方案评审
没有进行技术方案评审，因为接口80%复用老接口。
8、接口联调太迟
8.22才和后端进入联调，前端8月初开始开发，联调太晚。
四、测试问题
1、信息不一致
测试以prd为标准去测试功能，发现差距较大，事先不知道或没注意群里pd和开发达成的一致，或做了一些功能妥协及延期交付。
2、没有去关注需求变更
Prd没及时更新，测试同学没有去关注需求的变化；
3、沟通歧义
Prd作为标准，但是功能设计有漏洞，走不通，测试同学会理解为是开发的bug。
测试同学认真负责，具有产品思维。
4、bug录入
描述不够详细。
5、没有进行测试用例评审
6、bug归属问题
有些逻辑可以在前端写，也可以在后端写，比如排序，后端没有排序，输出数据有问题，bug划给前端了。需要达成一致，后面明确什么在前端做，什么在后端做。
五、前端问题
这个项目从评审，到开发，到测试阶段，出现一些沟通问题，信息不对称问题，事先说的不做，后面到做，再后面说去掉，再后面说加回来，这个过程，我身在其中，感受非常相当深刻，沟通出现歧义，我有很大的非常大的责任，后面一定会严格吸取教训。
1、评审问题
• prd评审太粗糙，需要严格把关，探坑；
• ued评审太粗糙，需要严格把关，探坑；
2、人力问题
• 人力资源不稳定，有一点小影响；
• 学习能力偏弱，不够努力和认真。之前MZK比较缺乏搬运旧代码的能力和勇气。
• 缺乏深入思考努力，做东西不够细致。做东西不够完整，没有深入思考，是否做好了，有些粗心，WH做的比较好。
3、代码提交问题
• 本地报错没解决就提交了，影响其他同学的开发；
• 没有当天提交代码，没有做到早上pull，下班push，建议多次提交，不要一天只提交一次；
• 出现提交冲突，先自己新建分支，确定功能没问题，然后合并到总分支。
4、代码问题
• 代码格式化，eslint报错；
• 给自己的代码加注释；
• 箭头函数没有去掉，遍历没有加key；
• 文件路径问题，避免部署错误；
• 功能开发缺失，bug比较多；
5、沟通问题
• 理解歧义，出现反复修改；
• 前端做了很多交互和功能，要么没联调，被隐藏了，要么联调了，也被隐藏了；
• 减少钉钉闲聊，最好当面沟通或者电话沟通；
• 演示版本没有发挥探坑作用，前端团队提供了一个演示版本，并钉钉群里周知了，提供操作说明，详见20180823日报，当时没有收到任何反馈；
6、自测不充分
事先不知晓testlink上面有写好的测试用例，没有走冒烟测试用例，入参错误，边界问题不该出现。
7、人员考核
根据bug数量来考核，人员培训，code review。
六、简言之
这个过程，我们做了很多无用功，比如花了大量时间做一些东西，最后被隐藏了。后面前端和后端要沟通好，哪些可以实现，然后都奔着能实现的东西去做，一起做好，实现不了的，没时间做的，就降低优先级，重心不要偏移。要保证一个版本，如果出现多个版本，让pd重新设计，研判平台只能保证一个版本，避免走927中台部署多应用的老路。