外包团队经常缺失对用户体验的思考
我们可以在日常生活中发现很多缺乏精心设计的产品，他们的共同点是没能够与用户产生共鸣，不具备提供令人愉快的用户体验的能力。
这些产品给人们的观感更像是一系列功能的堆砌，而不是具有某种重要价值主张的产品。或者是这些产品的价值主张是基于某种在现实生活中不成立的假设而成立的。
这种现象在软件外包行业常常出现，很多外包公司的产品团队（甚至有些公司没有产品团队）通常围绕这软件交付或者资源最大化利用进行项目开发，他们往往专注于项目交付而忽略了产品设计，在我看来，这是对于敏捷开发的一种误解。
团队围绕软件交付或者最佳资源利用率进行优化，那么我们确实能够尽可能快的将产品上线，但代价往往是我们无法保证用户获得的将会是一种非凡的产品体验。
如何围绕用户体验组织团队
围绕用户体验组织团队，有两个关键行为要素。 第一个要素是跨职能团队验证，该团队的技能可能涵盖商务、产品、设计和技术等，负责初步验证和判断一个创意的产生是否能有效地创造用户价值。
第二个要素是“通过用户行为和数据再验证”，这也是经常被遗漏的一个思考维度。
请注意，在我们介绍第一个要素的时候，我们并没有说“让创意从产生到实现”，而是做“初步验证”。在很多的组织中，产品的迭代或更改在设计、编码、测试、交付上线后便被视为已完成。
但仅仅是将功能开发上线并不意味着本次迭代优化的结束，以这种方式思考的产品经理会缺失对该功能优先级的思考。缺失了对这个功能是否能够进一步推动产品使命的实现，还是仅仅增加功能混乱而满足了一小部分特殊需求的思考。
况且，即使我们新增的功能是用户真正需要的，但我们是否已经以最好的实现方式将功能落地了吗？在产品未正式上线，没有人能够确切地给出结论。
因此，在一个项目迭代过程中，使用“构建用户需求模型-评估测量模型准确度-学习复盘调整需求模型”的心态来指导产品开发是一种面向实际验证过的客户价值主张进行迭代的有效方式。在很多成熟产品中就经常采用AB测试的方式，为Web或App界面或流程制作两个（A/B）或多个（A/B/n）版本，在同一时间维度，分别让组成成分相同（相似）的访客群组（目标人群）随机的访问这些版本，收集各群组的用户体验数据和业务数据，最后分析、评估出最好版本，正式采用。
新功能上线应该是一个新的反馈循环的第一步，从这时候起，团队应该将更新的功能视为进一步的产品需求挖掘的推动者，这将使他们能够验证原始想法并不断优化用户体验。
追求用户体验意味着牺牲部分效率
随着一个产品的发展和迭代，产品体量越变越大，负责产品维护迭代的团队也在增加，不可避免的会出现许多规划和集成上的问题。一个小而美的产品团队可能很容易进行规划和集成，但随着更多团队成员的加入，其中的难度将成指数级增加。我们不可避免的需要花费大量的时间处理这些问题。
此外，对于维护产品不同功能模块或者系统的团队来说，对于同样的问题，可能会有不同的方法来处理，这就需要团队中的产品经理积极主动的进行沟通，并始终的保持信息同步，以便能够尽早的对此类问题做出共同的决策。
所有的这些问题的解决都意味着更多的时间投入，因此，为了更好的用户体验，团队将不得不牺牲部分产品迭代开发上的效率。
把团队视作产品进行打磨
没有适用于所有公司的通用组织形式，对于每一个产品来说，其最佳开发团队也大概率不同，且随着产品和公司的发展，市场环境的变化，对于一个产品团队的要求也可能发生变化。
因此，要想保持团队对于产品开发的最优效果，一种很有效的方法是将团队本身作为产品打磨，将组织团队的行为视为产品的迭代优化措施。
产品会有其使命诉求，我们的团队也是。例如我们以提高生产效率作为某个季度的团队建设目标，那么我们就可以执行各种团队组织活动，并通过实际的效果反向验证我们的组织活动的有效性，放大有效的行为，减弱甚至取消无效的行为，从而逐步的向团队目标迈进。
随着产品生命周期和市场的变化，团队会有不同的阶段性目标，而随着这些目标进行团队迭代和优化，将有助于我们保持一个优秀的团队。
李俊兴 广州芦苇信息科技有限公司COO
