日常工作角色

实习加工作已经快两年了，除了个人技术能力的提升，职场经验也逐渐丰富起来。回想自己初入职场的时候，刚拿到设计稿时一脸忐忑，预估排期不知定多少时间合适。觉得产品设计的不合理，找产品经理 PK，却被简单的说服，结果还是栽坑里。随着一个个项目的开发、上线、总结，曾经摔过的坑，化为了自己避坑的方式（虽然还是会掉进新坑），项目推进会顺畅许多。在带动个人开发效率提升的同时，也使得项目及团队合作的成员越发成熟，形成共赢。

下面我就围绕着前端开发与项目各个角色的合作谈起。

产品经理（PD/PO）

产品经理通常是一个项目中，最先接触角色。产品经理一头对接需求方，一头对接实施方（设计/开发），将需求转化为一个个功能点，交给实施方来实现。作为开发，经常会吐槽产品的设计天马行空、不明所以。出现这种情况的原因，很多时候确实是由于产品经理对于需求的理解不足或画蛇添足。但大多数情况下，产品经理还是发挥了很重要的作用的。这点，如果经历过没有产品经理的项目同学应该会深有感触：直接需求方，业务/商务/销售/老板等提过来的需求，往往需要多次“翻译”和确认才能真正的满足需求。

交互/视觉设计师

交互/视觉设计师根据产品经理设计的产品原型，设计并优化交互/细节，完善细节，极大提升了用户体验。通常情况下，设计师对于交互和视觉本身是最专业的，除非你有足够的事实理论依据，否则没必要就某一个交互或视觉设计与设计师争论不休，毕竟专业的人做专业的事。但是，在以下两点上，作为开发是需要着重关注的： 1、标准的一致性：由于种种原因，如标准规范的缺失、文档的缺失、人员的水平差异、沟通不足等等，会造成同一项目不同页面、甚至于同一页面的同一类功能，出现多种交互或者视觉样式。这不仅会影响开发的效率，本身也会降低用户体验。作为开发，尤其是在前端组件化流行的当下，往往会比设计师对交互或视觉规范更熟悉。这时候就需要善于分析，某些功能模块是否类似，是否可以使用同一种组件来实现。一旦判断可以，就要积极沟通，通常设计师是会愿意接受建议的。 2、通用性：这里的通用性，更多在组件设计中体现。比如，设计师对于不同场景的布局，可能给出多套尺寸，这时候可以建议，统一采用栅格布局，并与设计师确定几套栅格比。这样一来，就不需要再为不同的场景，专门编写几种宽度数值了。此外，在与设计师、包括产品经理讨论某个设计或功能点时，应当先从合理性角度分析，比如对于原始需求是否必要？是否存在过度设计？是否存在功能点的重复？切忌一下子从技术实现角度出发，往往会造成不少的无谓争论，比如那句经典口头禅：“这个需求很简单，怎么实现我不管”。只有当一个功能确定是需要的时候，才需要加入项目进度因素。这时候可以考虑或是技术实现困难需要延长开发周期，或是采用某些快捷实现方案，与设计师协商，略微调整设计。当然，不是所有的项目都配备有交互/视觉设计师。对于没有设计师的项目，一方面，借助现有组件的拼装，基本不需要太多的样式设计；另一方面，作为前端工程师，理应具备一定审美能力的，尤其是设计并编写一些交互动画的能力。所以无论有没有设计师，都可以在细节上做一些小的“自由发挥”，以提升最终用户体验。

后端开发

在目前采用较多的前后端分离模式下，项目有一个很重要的环节，即前后端联调。虽然同为开发，但因为关注点的不同，经常也会造成互相伤害的局面。对于前端来说，通常由于以下几点： 1、接口前端不友好，比如返回值的数据结构嵌套很深，或者需要多次请求后前端组装数据； 2、前端实现 vs 后端实现，比如分页、过滤、数值的计算等； 3、规范问题，如接口字段命名的一致性、是否符合同一命名标准、报错格式等； 4、缺少详细的 API 文档说明； 5、后端服务不稳定，或 BUG 太多。对于这些问题，一方面，可以通过技术手段来解决。比如，构建一套 API 管理系统，按规范定义 API，并且约束 API 开发者必须按照固定格式编写详细的文档才能发布 API；同时，提供测试环境，供后端自测；或是前端部署 BFF 层，合并 API 等等。另一方面，在遇到分歧时，前端开发者需要坚持几点原则： 1、后端 API 应尽可能不依赖于特定的前端界面。这不仅有利于 API 的复用性，也可避免前端过重的逻辑影响页面性能； 2、单点维护原则：有时候，确实有些逻辑或功能，放在前后端来做皆可，比如错误提示的翻译。这时候，秉持在一处维护的原则即可，而不是各自维护一套； 3、用户优先原则：后端在定义 API 时，更多的会考虑原子性；而前端是直接面对用户的，需要更多考虑用户体验。但不管前端还是后端，最终都是服务于用户的。所以，对于一些可能会影响用户体验的 API，要坚持用户优先，甚至可以拉上交互/设计同学，来推动问题的解决。此外，很多时候，前端作为项目路径的下游，往往比较的被动。这时候，需要学会去化被动为主动。比如，采取一些技术手段，如 mock 数据减少对后端开发进度的依赖。除了技术手段外，沟通问题的过程中，应该抱着共同寻找解决方案的心态，与后端一起分析问题并找出最佳方案，这样才有利于项目快速良好地推进。

测试

联调完成后，通常需要提测，进入项目上线前的测试阶段。进入这一环节，可能会被搞得特别郁闷：自己认为已经完善了的系统，还是被抓出了不少的 BUG。如果仅此而已，那其实还好，毕竟是自己的问题。但有时候，依据测试人员的不同，还会遇到很多意外情况。就我经历过的测试而言，发现测试人员大致可分为两类： 1、经验丰富的测试，能快速定位问题，并且较为准确的指给责任方，此外还会提一些交互或功能优化建议； 2、新手测试，不清楚问题原因，基本都先提给前端，或者对产品设计理解不够清楚，提一些无效 BUG；前者还好，除了会提一些你认为是新 Feature 的 BUG 让你来改；而后者，就需要有足够的耐心了。但是，我们可以换个角度来思考。第二种情况的测试，其实更接近真实用户在使用系统时的场景。与其不耐烦地强调是不是 BUG，不如思考一下，是否这部分的功能设计还需要优化？是不是会给真实用户带来困扰？甚至可以主动拉上产品经理，看看是否需要调整产品设计，或是作为需求下期迭代实现。这样一来，无形中，你就成为了项目优化的推动者。此外，对于测试提过来的问题，如果发现不是自己的 BUG，也不要简单地推掉。帮助测试拉相关方一道讨论，可以更高效地解决问题。

需求变更

“变更”对于开发者来说是最头疼不过的一件事了，往往一个看似很小的变更，可能牵扯出很多关联问题，大大影响开发效率。然而，现实情况是，无论是需求方、产品经理、交互/视觉设计师，甚至后端开发都可能提出变更。有些变更“看似”不可避免，比如开发途中收到用户反馈，希望增加某个功能；有些变更看似不必要，却又被强烈坚持，比如上线前，交互设计师觉得某个按钮位置不合适，需要调整。很多时候，看似不可避免的需求变更，往往可以在产品设计中来避免，或者采取更好的方式来解决，如放在下一期迭代。看似不必要的功能，也不是说一定不能增加。我认为，关键需要做好几点；第一，做好变更带来的影响范围的评估。对于一些大型的系统，产品设计上的一点小变更，可能会牵一发而动全身，特别是一些公共模块，比如计费。一些小变更，如果不做好范围评估，可能对其他模块产生影响，甚至是不可用；第二，评估好所需时间。通常，一个项目的上线节点是确定的。或者，会严格制定提测的时间，测试也会有自己的排期。一旦某一需求点变更，没有评估好时间，万一造成了延期，将会对整个项目的进度带来影响；第三，要权衡收益与时间。我们不应该刻板坚持说，需求开始已经定好了，这版任何需求变更我都不接受。毕竟，多数的变更，还是从优化产品的角度出发的。如果评估一个变更对上线时间没有什么影响，完全可以顺手改掉。但如果某个变更，可能是客户直接要求的，看似非改不可，但修改起来需要大大延长项目周期，这时候就需要做个权衡了，或是调整人力资源，或是调整技术方案。总之，对待变更，不是一味地拒绝，也不是轻易地接受，需要充分权衡利弊收益，做出合理判断。

复盘

“复盘”一词最初来源于围棋比赛，指一局棋局结束后，复演该局，分析整盘的胜负所在。对于一些大型项目，项目的结束做一下复盘，可以总结一些问题或经验，用来提升后续项目的效率。所以，进行复盘是很有必要的。比如，我接手过一个项目，项目的前期，产品经理提供的文档非常简洁（只有一页），但项目逻辑远比文档描述来的复杂。这导致，整个开发过程中，需要多次跟产品经理沟通确认需求。除此之外，在项目中途，视觉设计师还做了好几处视觉上的调整，以至于整个项目时间远比预估来得紧张。对于这个项目，当时做了一个复盘。复盘前，专门统计了一些数据作为依据，比如产品文档变更次数，设计稿变动点的数目等等。在会议中，秉持对事不对人的态度，列举事实依据指出影响项目效率的原因，并提出优化方案，如产品经理需要在项目开发前，准备好足够完善的文档；视觉设计师的视觉稿完成后，需要组织评审，尽可能避免在开发后，再做调整。通过优化方案的沉淀与推进实施，成功确保了后续项目，不再遇到相同的问题，从而提升了效率。

敌人&助手

我做的项目是谁的项目？在我刚开始工作的一段时间，对于接手的项目，我的理解，它们纯粹就是一个个任务。我需要考虑的，只是如何用代码去实现它们。但在现在，我会意识到，我最先考虑的，不是如何实现，而是为什么要做这个项目？具体来说，就是项目的需求本身为了解决什么问题？能带来什么收益？进而思考，产品的设计方案是否满足需求本身？是否是最佳的方案？是否会造成一些问题？换言之，在项目中，应当把自己看待成一个项目 owner，而不再仅仅是一个执行者。我的合作方，包括产品经理、设计师、后端开发、测试都是我的助手，帮助我一起把这个项目做好并推动它成功上线。当然，前提是，你需要主动去充分理解并认可这个项目，使它真正成为“我的项目”。这样一来，合作中遇到问题时，我会以对于项目积极的方向去努力，而不仅仅满足于完成自己部分的工作。比如，后端某个接口有问题，除了反馈给后端外，如果根据自己的经验做个判断，是不是 API GATEWAY 的问题，或者是不是某个字段取值不对之类的，可以帮助后端更快解决问题。这不仅有利于项目的整体进度，也能降低一个沟通成本，毕竟如果自己不提供足够的信息和建议，可能反而增加了沟通的频率，对自己的开发效率也会造成影响。总之，记住一点，合作方不是敌人，是我的助手，我们是为了相同目标，通力合作的伙伴。

成熟业务 vs 初创业务

在我经历过的所有项目中，既有比较成熟的产品业务，也有初创的产品业务，它们的整个开发过程，还是有比较大的不同的。对于成熟的产品业务，整个项目流程和角色分工，基本是比较完备的。但是，这并不代表开发过程一定顺风顺水。因为，一些既定的流程未必得到严格执行，或者某个角色专业度不足。这种时候，就需要对照前面提到的，与各个角色合作的方式。某些情况下，还会存在合作方自身存在一些问题，比如工作态度、负责程度等。这时候，可能就不是靠一己之力可以解决的了，而是需要记录相关过程，并及时将问题反馈至上级来解决。相比成熟业务，初创业务往往更关注“速度”。因为初创业务很可能处于市场探索期，需要快速完成产品推广市场；同时又要及时迭代，满足客户各种需求。这种情况下，整个研发流程或是角色分工，不一定会很完备。比如，不一定有专职测试，可能会由产品经理兼职；又或者，不一定有设计师，可能需要我们前端利用现成组件加一点审美能力自由发挥。显然，这种时候，想要事先制定一个严格完备的研发流程，往往不太现实。那么如何在这种条件下，确保开发效率呢？我认为，需要做到以下几点：第一、借助技术手段。比如，最常用的 mock 数据，实现前后端开发时间上的解耦。相比成熟业务，初创业务可能缺少很多基础设施，这就需要多做一些工程化的工作优化工作流，降低沟通成本。技术手段还体现在，借助一些现成的脚手架工具或完善的框架来快速搭建项目，如dva。第二、需要提高项目管理能力。最基本的一点，是要会评估需求优先级。对于前端开发来说，实现的功能中，除了调用后端 API 来实现的基本功能外，很大一部分是提升用户友好度的工作。对于初创业务，这一部分的弹性其实是比较大的。相比成熟业务，初创业务、特别是技术型的初创业务，用户对体验上的问题，容忍度相对是比较高的。所以，在项目时间比较紧张的时候，合理评估需求优先级，合理安排研发时间，对于确保项目如期上线至关重要。第三、要少抱怨、多建议。初创业务毕竟要同时面对项目周期紧、规范流程不完备、基础设施缺乏等不利因素，自然会遇到很多问题。这时候，不能只做问题的发现者，而是尽可能成为问题的解决者，至少也是问题的推动解决者，才有利于整个团队和项目。

总结

在我经历过的所有项目中，既有比较成熟的产品业务，也有初创的产品业务，它们的整个开发过程，还是有比较大的不同的。对于成熟的产品业务，整个项目流程和角色分工，基本是比较完备的。但是，这并不代表开发过程一定顺风顺水。因为，一些既定的流程未必得到严格执行，或者某个角色专业度不足。这种时候，就需要对照前面提到的，与各个角色合作的方式。某些情况下，还会存在合作方自身存在一些问题，比如工作态度、负责程度等。这时候，可能就不是靠一己之力可以解决的了，而是需要记录相关过程，并及时将问题反馈至上级来解决。相比成熟业务，初创业务往往更关注“速度”。因为初创业务很可能处于市场探索期，需要快速完成产品推广市场；同时又要及时迭代，满足客户各种需求。这种情况下，整个研发流程或是角色分工，不一定会很完备。比如，不一定有专职测试，可能会由产品经理兼职；又或者，不一定有设计师，可能需要我们前端利用现成组件加一点审美能力自由发挥。显然，这种时候，想要事先制定一个严格完备的研发流程，往往不太现实。那么如何在这种条件下，确保开发效率呢？我认为，需要做到以下几点：第一、借助技术手段。比如，最常用的 mock 数据，实现前后端开发时间上的解耦。相比成熟业务，初创业务可能缺少很多基础设施，这就需要多做一些工程化的工作优化工作流，降低沟通成本。技术手段还体现在，借助一些现成的脚手架工具或完善的框架来快速搭建项目。第二、需要提高项目管理能力。最基本的一点，是要会评估需求优先级。对于前端开发来说，实现的功能中，除了调用后端 API 来实现的基本功能外，很大一部分是提升用户友好度的工作。对于初创业务，这一部分的弹性其实是比较大的。相比成熟业务，初创业务、特别是技术型的初创业务，用户对体验上的问题，容忍度相对是比较高的。所以，在项目时间比较紧张的时候，合理评估需求优先级，合理安排研发时间，对于确保项目如期上线至关重要。第三、要少抱怨、多建议。初创业务毕竟要同时面对项目周期紧、规范流程不完备、基础设施缺乏等不利因素，自然会遇到很多问题。这时候，不能只做问题的发现者，而是尽可能成为问题的解决者，至少也是问题的推动解决者，才有利于整个团队和项目。