产品经理的职责是发现问题和解决问题，但这些指的都是在产品上。如果在日常工作中出现了问题，比如在缺少UI和测试的团队里，产品经理如何做下去？
在业务主导的体系里做产品，不像互联网公司那样如鱼得水，尤其当你所在的团队缺这少那时，产品经理经常是身兼三职，这种情况在一些传统企业或者初创公司尤甚。
我曾接触过一家做信用评级的头部企业，他们只负责自己招一个产品经理，其余的开发全部外包。而在UI和测试方面，B端产品，尤其是企业内部自用的产品，对样式要求不高，所以UI忽略；用户量不大，所以测试忽略；甚至有些地方，早期可能连产品人员都没有。
一方面是缺东少西，团队配置不完善，另一方面是业务方想看到的完美体验，在骨感现实与完美期望间如何平衡，确实是考验产品经理能力的地方。
01 完善自身能力体系
先问大家一个问题，如果是你所在的团队中缺少这两个角色，或者缺少其中一个角色，你会怎么办，测试和功能验证还可以点点看看，但样式界面如何美化呢。
每个人都各有所长，维度参差不齐，但有心就好。比如在做产品原型时，你是会做高保真还是简单的线框图，并不是说孰好孰坏，因为这要根据具体情况而定。
对于产品经理而言，能做高保真的一定能画线框图，相反，能画线框图的确不一定做得了高保真。尤其当你到了一定程度时，画高保真并不会比简单线框额外花费多少时间。
为什么要说高保真的原型产出，因为在没有UI的团队里，高保真原型可以给开发提供很多借鉴，而如今，各种各样的元件库也为大家提供了很多素材。
02 不必将界限划清晰
在没有专职测试的时候，开发人员需要自测一部分，产品人员也需要验证一部分，这就使得原本有专人测试的工作就要平衡到两个角色去承担，现实中无法避免。
而在没有专职UI的时候，你可以选择对外说不对样式负责，也可以试着了解一些样式搭配，倒不必具体到规范参数那些细节，至少协调好看还是能看出来的。
如果有能力的，或者有一些UI知识储备的，亲自动手做一些设计也未尝不可，至少也能根据自身产品定位和类型，给前端找出一些参考样式，这应该不难。
话说回来，在那些没有UI的团队，样式欠缺是必然，样式好看才是惊喜。
在可以尝试的地方，多做一些探索和努力，毕竟作为产品经理，产品整体质感好，也有你的荣耀。
03 该回绝时表明态度
也有人说，如果我将上述都做了，还是受累不讨好，对方还以不完美为借口百般挑剔怎么办，那么这个时候，就应该让对方明白，你已经尽力。
其实上面说的不必将界限划清晰，指的是对于产品经理自身成长来说，不必仅局限在这一个框框内，看看相邻岗位的一些知识，不说精通，至少熟悉。
但毕竟术业有专攻，创业的时候可以一个人顶一个团队，但在公司里工作，为了避免背锅，这一点还是丑话说在前面比较好。
让对方明白当前的客观现实以及自己所做的努力，所以不要以考核专业人员的标准来要求，尤其当要求和评判不合理时，表明自己的态度，否则你会越干心里越委屈。
04 寄希望于自己
都说产品和开发沟通难，但有些时候，产品和业务沟通也难，就像那个经典的例子，你问用户想要什么，他永远会说想要一匹更快的马，直到出现了汽车。
在你调研业务人员的需求时，对方未必就是真实需求的全部，你需要自己做更深的思考以及进一步的梳理。
而当对方向你提出一些产品意见时，除了业务逻辑方面，其他样式方面通常会比较笼统，当你进一步询问时，可能对方也说不出所以然。
所以很多时候，业务方说不出来哪里不好，或者需要什么，倒不如先做出来然后再讨论，不然大家都比较形而上，争执没有任何意义。
结语
写这篇文章的原因是最近自己在工作中经历的情况，本来是叙事的方式阐述了一遍，但我不想文字中有太多的情绪。
倾诉一遍不会解决任何问题，基于事件的理性思考，才会给自己以及看这篇文章的人带来一些帮助，在未来受益。
最近一个很大的感受就是，说很容易，做很难。不论是在调研需求梳理业务时，亦或是后期大家提出的建议上。
说的时候任谁都能说出几句，不全面但听着也有道理，而真正做的时候，不仅要求全面，还要求能落地，这个过程也是真正考验产品经理能力的地方。
雄关漫道真如铁，而今迈步从头越。
一起加油，共勉！
