1. 团队
一般团队都是由不同角色的人员组成，有负责产品需求规划的产品人员，有负责按需求方案完成视觉，交互的设计人员，有负责落地产品人员需求方案的研发人员，有负责控制需求实现质量的测试人员，以及更外围的市场、运营、品牌人员等等。每个人各司其职，只负责一个产品的某一局部的工作。
越来越细化的分工，这是由行业大环境所决定的。回顾10年前的模式，所有研发仅仅有一个角色“研发”：一个人大包大揽，干掉所有老板吩咐的“活”儿。而不是像现在分化有：
- 专门负责应用层的服务器工程师
- 专门负责页面展示的前端工程师
- 专门负责数据处理的数据工程师
- 专门负责推荐系统的推荐算法工程师
- 专门负责视觉风格定义的视觉设计师
- 专门负责产品人机交互的交互设计师
- 专门负责运维部署应用的运维工程师
- 专门负责服务器维护工作的系统工程师
- 专门负责产品安全控制的安全工程师
- 专门负责产品多媒体交互的多媒体工程师
- 专门负责不同客户端的AOS, iOS, PC工程师
- …
如此细化分工的好处很明显，不同角色工作更加聚焦，可更加深入的完成职责工作。相反的，过于细化的分工也不是只有优势，没有劣势，通常看的见的问题有：
- 不同角色间的灰度区域容易被忽略，无人问津
- 个人素质决定了最终质量
- 沟通协作成本指数级上升
- 产品研发效率有一定程度的损耗
问题存在即要考虑解决方案，大千世界往往万物都是生生不息，往复轮回的。所谓”合久必分”，”分久必合”。至今软件领域又过了一个10年后，关于敏捷，关于全栈等开发模型又被提了出来。
关于全栈，在我所在公司实际岗位对应的就是：产品工程师。它的具体岗位职责，能力要求，适用场景主要是以下几点:
岗位职责：
根据内外部需求，充分利用现有平台，工具等资源，策划，设计，开发，测试，交付一项完整功能或者一个产品，并且E2E为该功能或产品用户体验负责。
岗位能力要求：
- 产品策划、交互设计
- 前后端技术开发能力
- 测试及质量保障能力
- 项目管理能力（通用）
岗位适用场景：
- 云计算、大数据等技术性产品研发
- 业务中后台系统开发
从这些基本定义看，这个产品工程师就是面向云计算/大数据类而生的中后台系统全栈研发，对产品/功能负责，全权负责各个环节，是一个具有全局视野及全领域执行落地能力的人员。
但是每件事都具有两面性，个人总揽固然有明显的效率提升，但仅限单一任务，多任务单人并行总不是办法，个人的“带宽”毕竟有限。团队的意义即在于分工高效协作，如果达不到此目的，说明需要考虑团队成员组成与团队是否磨合不足的问题了。
我认为激发团队的自主性尤为重要，我把它总结为一句口号：
做每件事都在力所能及范围内多“走“一步。
这个听起来容易，真当做起来可能就没那么简单了。
2. 产品
产品职责在于需求规划与迭代演进路线设计，就这一点从我这几年的个人观察来看，也不是所有产品经理能做到位的。他们不是在纯粹追求“老板”式需求，就是在个人臆想中任意飞翔，可以说没几个人能真正站在用户角度看待问题。这样的思考和行动方式决定了很难做出高质量的需求。
我以为高质量的需求需要体现以下几点：
- 前后需要有连贯性
- 属于用户现有/未来潜在的真实需求
- 需求内部逻辑严密，考虑周全细致
以上三点简化表达就是：需求设计连贯性，需求价值真实性，需求逻辑严密性。下面我来细化地说明一下。
2.1 需求设计连贯性
产品功能是由一个又一个的需求集合，如同搭建积木组合一般组装而成，每个需求不是孤立的存在，而是相互关联的。从这个角度讲，需求的设计就必须有一定的连贯性。
我们在做产品设计需求时总会频繁遇到这样一个困境：需求所在的上一个版本是一个玩法 ，需求所在的下一个版本又是另一个玩法。这样随意更改玩法的做法，真是让团队各位成员苦不堪言。
很多研发/测试同学往往会在会议中质疑这种调整的意义，甚至有时会直接引起争吵。这在一定程度上降低了团队的凝聚力，但产品同学类似这种“想一出是一出”的奇异想法真的有价值嘛？这种不连贯的需求设计真的好嘛？这里我认为产品同学需要认真思考清楚，宁缺勿烂。
2.2 需求价值真实性
需求价值主要有两个来源：
- 来自一线终端用户的建议反馈转化而来的需求
- 来自产品同学规划设计的需求
需求价值主要体现在其所依托功能所能带给用户的帮助大小，帮助大的往往需求价值较高，帮助小的往往需求价值相对就较低。这也就是为什么需求被放入“池子”后，立即就有了P0/P1/P2之分，甚至有时还需要有唯一的优先排序。
用有限的时间做满足用户需求价值高的事情尤其重要。
上面所说两类价值来源，我们往往在评估时需要额外小心提防非“真实性”的需求价值陷阱。不要在自我认知上过分固执，而导致价值真实性偏离。花了巨大精力完成的需求，没有哪个人会愿意接收毫无价值的结果。
我认为解决以上问题的方法有很多，较常使用的有：
- 用户调研
- 数据测试与分析
- 运营介入
通过上面的方法，可能还是无法杜绝非真实性需求，但我认为在一定程度上可以有效预防。投入多一些，往往收获也会更多。
2.3 需求逻辑严密性
说到逻辑，这方面理科生往往会比文科生更有优势。良好的思考逻辑，推理逻辑，路径设计逻辑等都为需求严密性提供了强有力的保障。真实场景中不乏有很多因需求逻辑设计不够严密，导致快上线时才发现严重逻辑漏洞，团队成员只能跟着加班调整错误，为此付出了巨大的代价。
团队成员间信任感往往是通过小需求的设计逐渐建立起来的。
如果说一位产品同学真正做到以上三点，那么整个需求质量就会显著上升。它带来的不仅是团队沟通成本的降低，更多的是团队整体效率的提升。大家再也不必为需求本身的连贯性，真实性，严密性而争吵，才能真正协力提高产品功能体验上，做出真正有价值的产品。
当然要做到以上方面，产品同学的“多走一步”必不可少。与用户沟通更频繁些，与开发多碰头确认可行性等等方式，都更有利于提供一个好的氛围，团队成员携手向前进军，创建用户真正所需的价值功能。
3. 设计
如果产品是灵魂，那么设计就造就了看的见摸的到的躯体。让灵魂有所依托，可以为人们所用。
设计往往是在底层玩法角度给产品以生机与活力。表现于简洁一致的视觉风格，信息架构统一完整，交互简洁与体验合理顺畅。但在我看来，很多时候交互，视觉同学往往为了华丽而颠覆传统，很多时候甚至牺牲可用性而去追求所谓的酷炫，真的是本末倒置，大大的错误。
一切不以可用性为保证的设计都应极力避免。
设计是为了保障功能满足用户需求的情况下，尽可能地优化体验。这个时候，如果不牢记使命而天马行空，或照搬照抄，最终结果往往是顾此失彼。完美的体验没达到，反而让用户对功能的使用产生疑惑，造成口碑下滑的问题。
好的设计是一个不断打磨的过程，往往不是一蹴而就。需要进行很多时间的方案对比，用户调研，数据反馈等测试后才能最终确认自己的“风格”。每个产品功能定位，体验设定不同，需要有属于自己专属的设计元素与体验标准，深度挖掘核心价值，才是设计之道。
因此，我认为好的设计是一个循序渐进的过程，一步一步将产品打磨成用户期望看到的样子，而不是我们需要它呈现的样子，这点尤其重要。
有基本的可用性保障，再配合以整齐统一的交互规范体系，辅以完善的视觉风格设计，我想一个好产品应该具备的好设计元素就圆满了。 设计没有最好，只有更好，因此这也要求设计人员不断打破边界，尝试变化，演进设计，让设计自己说话，让用户感受这种变化，让美好不断延续。
说到设计在团队中的作用，我想它主要起一个指导作用。设计的每一个细节，指导了研发如何构建功能。设计的每一个场景，指导了测试如何验证功能。它是一个重要的存在，细节设计不足，场景覆盖不足，都会导致大量的后期修复成本，会让团队进入泥潭，无法脱身。
在某些方面来说，设计的重要性甚至高于产品需求本身。需求只是主干，设计才是细节，而细节才真正决定了产品的命运。做好细节才是设计之本，产品之本。
4. 研发
说到研发，大家往往会有一个基本认识是：一根筋。只会从实现角度考虑问题，而不是会站在用户角度思考。
其实我认为研发并不是没站在用户角度看，而是看问题的方式不同。每个研发都有一个产品心，当他在产品角度看功能时，会考虑的更多，而这种提前设计往往因需求的变化而不得不进行取舍。运气好的话，架构设计符合产品迭代，运气不好的话，这种超前眼光会导致一笔笔的技术债，时间到了总得偿还。
因此，研发如何更好的通过自身优势来看待需求，设计。这就要求我们要把握需求的核心，在一个时期只关注核心流程。
用户思维模型的植入需要我们打破角色壁垒，
与产品、设计多交流沟通各种细节在技术实现上的差异，让大家互通有无。
这也正是研发“多走一步”的核心。
技术人员的“多走一步”着重体现在与上游的细节沟通上，让需求玩法更严密，设计更符合用户预期，这是我们能做的一小步，但却会体验在产品上的一大步。
如果能在更早的流程阶段发现问题并设计解决方案，往往比在更晚阶段解决所需要的成本小很多。那既然如此，我们就应不断在更早发现问题并解决，而不是留到最后。
当产品需求不明确，交互设计少页面，视觉设计不完整时，我们就要大喊一声”NO”，我们需要更多的细节，让其他环节能够听到并落实，这才是研发之道。
5. 测试
在软件行业，测试工作往往代表着最后一道防线，最终的结果直接反映在产品质量层面。一个好产品往往经过严密，完整，系统的测试。构建一道严密，完整，系统的测试体系的重要性不言而喻。
在我看来，通常意义的UI功能测试其实不应占据测试的主体。测试工作更多需要花在用例场景设计，快速测试方法选择，测试结果验证与通知上，以及必要的自动化过程。
然而，现实中我们的测试过程却重在人肉测试覆盖。这种大量重复的，时间成本巨大的方式竟然还在大行其道。虽然它对测试人员的要求很低，但这种测试人才配比可能在产品快速上升期时成为一种定时炸弹。大量的新功能带来更严峻的测试任务挑战，而这些挑战我认为光靠不断的堆人是无法根本解决的。
我以为一个可参照的测试体系模型是这样的：
50%：用例设计
30%：测试方法选择
20%：测试结果验证与通知
10%：自动化过程
让测试同学的主观能力体现在用例设计，测试方法选择上。通过工具解决测试验证与通知，再用自动化根本解决主干的重复测试工作。解放生产力还是得需要我们学会去使用工具，用对用好工具。
这样才能让测试同学的大脑，将注意力关注到用例本身。用例设计可以发现产品的逻辑漏洞，填补未知的内容。而这些往往才是真正需要人类来解决的问题。测试层面的“多走一步”讲的就是这一点。
6. 后记
一个团队的人员产出质量决定了产品的质量。
假如：
产品：质量80%
设计：质量80%
研发：质量80%
测试：质量80%
那么最终产品的质量是
0.8 * 0.8 * 0.8 * 0.8 * 100% = 40.96%
“多走一步”是一种团队协作理念，每个人多提升一些，产品就会好一些。
团队成员在关注本职工作的同时，需要站在为用户服务的好产品角度来思考问题。发现目前功能需求/设计/实现中的种种缺陷，查漏补缺式迭代演进。以创造好产品为己任，不断调动自身的工作积极性，以无比专注之心来打磨产品。
我想办法总比困难多，齐心协力，做好一个产品没那么容易，但其实也没那么困难，往往只需“多走一步”罢了。