之前看过一个段子，说的是IT从业者鄙视链，大概是这样：架构鄙视全栈，全栈鄙视后端，后端鄙视前端，前端鄙视测试，测试鄙视产品，产品鄙视运营......
笑过之后，有点悲哀，合计 我们项目管理从业者根本都没在链上~同样悲哀的还有广大的UIUE从业者们。。。
其实说起来一个项目团队，做UI、UE的跟做项目管理的人心思有点雷同，都孤独。比起团队浩浩荡荡的开发大军、测试大军、产品大军，我们的力量一样的略显单薄~~
今天我们单开一篇，单聊一下，我们的大U-交互。
如题，我们的交互类需求啥时才能不被功能需求挤压？
话说，这是一个真实的呐喊，码这几个字儿时候，我脑补了一下，团队周会时我们团队交互总监说这句话时，严肃而又为委屈的表情~
确实，项目进展到不同阶段，对需求价值的定位和优先级划分标准是不同的。
产品面市前，团队最大的压力是尽快产品上线让客户和用户看到。所以，这个阶段基本是以“功能”为主的。快速将功能实现，质量检测符合。推向市场。接受市场反馈，迅速调整，优化，不断进化，完善。
产品面市后，经历了一波市场检验。接下来要做的就是不断优化了。优化的重点便不仅仅是功能了。同样重要的还有性能、安全、交互等不一而足。需要经过漫长的市场调研反馈，客户行为数据等进行分析后得出优化重点。
但是这里面有一个问题，我们都知道推向开发的需求都是产品经理触发的。产品经理对于功能设计、性能优化可以评估优先级。那么对于交互类需求如何与功能、性能等一些列需求并排站好，等待翻牌呢？翻牌的依据是什么呢？
这里面包含两层意思：第一，要不要与功能等一起。第二，产品经理是否有足够的能力区别出功能需求和交互需求哪个更有价值一些。
这是一个走到这一步才会发现的问题。当我们集所有精力终于将产品1.0版本上线时，走了一阵交互总监发出了如题的委屈呐喊！这时候团队也开始挠头了。我们的团队有三位产品经理，一名交互总监。经过协商，最终我们确定后续的交互类需求单独由交互总监进行梳理，梳理的依据来源商户访谈、用户画像、用户行为数据等。然后迭代需求梳理时候，不管是产品经理梳理的需求、交互总监梳理的交互需求、还是技术故事，我们都拿出来一起各业务组负责人进行统一评估。
执行一段发现挤压情况依然难以避免。我们又开辟了专区。交互总监单独盯着交互需求的集中实现。性能问题由产品和测试单独拉一个专区实现。实现完毕合入主干，赶上哪个迭代在哪个迭代进行发布。
以上，是我们团队结合自己的实际情况作出的调整。你的企业有遇到这个问题吗，你们怎么解决的呢？
以上，感谢阅读。感兴趣可以加微信：js_alice
转载请微信先告知，谢谢~
网友评论