你不知道的前端软技能，反制职场PUA

注意：以下方法论不适用于偷工减料，仅用于受到多方PUA时反制PUA，切记！！！

前端怎么battle甲方？

甲方是爸爸

• 深挖甲方诉求，搞清楚真正的需求和隐藏需求，防止频繁返工
  • 甲方说我想要一匹马(诉求)，其实是想要更快的交通工具(需求)
• 理清主要需求和次要需求，看能不能先上主要需求，再排次要需求的工期
  • 甲方需求100条，条条都重要
• 无法实现要耐心说明原因，并给出替代方案，防止甲方再次异想天开
  • 甲方要手机壳根据心情变色
• 必要需求迎难而上，逃离舒适区容易获得技术突破
  • 甲方想要手机端操作的同时，PC端同步变化
• 力有不逮向上汇报或者请教大佬
  • 硬撑导致问题，后果很严重
• 事必回复，及时回复，服务至上
  • 甲方不是煞笔，是衣食父母啊
  • 甲方不懂技术，要用他听得懂的语言讲道理

一句话需求

• 耐心询问，深挖真正需求和主次需求和隐藏需求
• 先出解决方案，征询甲方同意
• 排期并给出详细工时评估表(防止battle和压缩)
• 甲方反复修改，先尝试劝他放弃；不接受再给出详细工时评估表，时间能接受就做，不接受就砍需求
• 总之：不怕麻烦才能避免麻烦！正面麻烦才能解决麻烦！

前端怎么battle产品？

产品倒排时间

• 给出详细工时评估表力证事实不可能(最好先跟leader确认工时没问题，防止challenge)
• 让产品去：1.延期 2.砍次要需求 3.协商人力资源

产品频繁修改需求

• 评估是否是当前需求的调整，新需求放下一期或重新评估工时
• 评估是否合理并确有改善，不合理拒绝，合理也要对改动重新评估工时
• 每次改动增加评估工时并通知产品，排期顺延，不同意顺延请看"产品倒排时间"

排期冲突怎么办

• 协调双方PM当面battle排期先后，或者向上协调资源。
• 将两个PM和前端的矛盾转移成两个PM的矛盾！

前端怎么battle设计？

别人能做为啥你不能做

• 如果确实能提高用户体验，要尽可能的满足！
• 如果没有明显改善并且费时间，告知时间不够所以暂时不做

频繁修改设计

• 如果确实能提高用户体验，要尽可能的满足！
• 严禁每次修改一点点，要让设计出修改文档并根据文档评估工时
• 和产品沟通增加设计优化工时，而不是bug fix

前端怎么battle后台？

接口文档没写完，你先开发一部分

• 拒绝开发！
• 没有接口文档怎么mock？通知PM接口文档给出时间delay，可能导致项目delay
• 可以先开发，但不保证工期
• 提高自己：提前1-2天询问能否按时给出，提前抛出问题，保证项目进度可控

接口没写完，你先联调一部分

• 拒绝联调！
• 如果项目紧急通知产品，后台接口文档给出时间delay，可能导致项目delay
• 可以先联调，但不保证工期
• 提高自己：提前1-2天询问能否按时给出，提前抛出问题，保证项目进度可控

接口数据没清洗没组装

• 拒绝组装清洗！
• 不清洗可能导致数据泄露，从数据安全角度让他必须清洗
• 后台不组装导致请求次数增多、接口数据量增大，影响页面秒开率、浪费流量
• 尝试沟通增加BFF层，做数据清洗组装，拓宽前端业务范围和技术广度

假数据没有自己去mock

• 开发阶段接口文档齐全可以mock
• 联调阶段必须造假数据，否则拒绝联调

前端怎么battle测试？

• 让她先看原型图确认是不是设计缺陷，和产品确认好怎么改
• 教他看network分清楚是前端BUG、后台BUG不要每次都先找前端
• 帮测试养成好的习惯比什么都重要

前端怎么battle领导？

详细工时评估被领导质疑

• 每一条依次过工时，质疑的地方给出理由
  1. 有前置条件
  2. 有技术难点
  3. 多部门协同
  4. 新接手代码不熟悉业务和代码
  5. 不确定因素
• 总工时乘以1.2~1.5的缓冲系数才是最终工时
  1. 有可能请假
  2. 有可能有紧急任务
  3. 有可能有无聊的会议
  4. 有可能有需求修改
  5. 防止delay
  6. 代码优化
  7. 写单元测试和冒烟测试

绩效不及心理预期

• 拉业务方佐证业务价值成果
• 拉工时和任务单、任务量佐证工作量
• 开分享会分享项目中的难点解决方案，延伸业界解决方案，扩大业务成果
• 反思是不是表达沟通不到位，PPT做的不够好
• 环比同组成员是不是都太优秀了
• 是不是自己工作太简单了没难度
• 都不是，那你被PUA了赶紧跑路吧

前端怎么battle下属(PUA)？

• 打工人何必为难打工人
• 三十年河东三十年河西莫欺少年穷
• 求求你做个人吧

撕天撕地撕空气，撕破伤口、

• 不怕麻烦才能避免麻烦！正面麻烦才能解决麻烦！
• 详细工时评估表力证事实不可能，工时事先跟leader保持一致防止challenge
• 拒绝之前想好易实现的替代方案
• 累死累活不会换来赞美，不要做不会思考的代码机器
• 三十六计走为上计，此处不留爷自有留爷处

深度思考

• 前端需要和项目组的每一个人对接，沟通的工作量远远大于代码量，好的沟通提效非常明显！
• 现状是：甲方是爸爸、产品大于天、设计主导用户体验、后台主导业务逻辑、测试保证产品质量，前端没有话语权，被动接受并执行项目组任何人的指令
• 前端如何掌握话语权？时间管理！前端通过时间节点管理掌控整个项目的主动权和话语权。
  • 对甲方：什么时间节点需求梳理完毕？
  • 对产品：什么时间节点出原型图终稿？
  • 对设计：什么时间节点交付UI稿、交互稿？
  • 对后台：什么时间节点交付接口文档？接口什么时候后台自测？什么时间节点接口可以联调？
  • 对测试：什么时间节点交付冒烟测试用例？什么时间节点测完？

天不生我罗小猪，时间管理如长夜！剑来！！！

(卑微小编求点赞求关注，欢迎评论battle)