前段时间看到很多小伙伴在群里讨论，由于特殊时期，公司预算缩水，所以有的把UI省去，有的把测试省去，以此来节约成本压力。
看到有位同学说其实这没啥，因为自己所在的公司目前除了产品经理和程序员外，没有UI和测试，很多人都对此很好奇，其实这在很多公司很常见。
01
由移动互联网的迅速发展带来了互联网行业岗位的细分，原本的链条顺序是产品-UI-开发-测试-上线，而有的公司如果是内部员工使用的产品往往会省去UI，以能用为主。
外加内部用户容错率通常比较高，所以从成本考虑可能不会单独招个测试人员，因为普通的测试很多角色都能做。
两年前的那波所谓寒冬，一个之前同事就说他们公司已经把测试优化掉了，所以这项工作自然就落到了产品经理的身上。
正常来说，产品经理可能是最熟悉这个产品的人，所以常规测试阶段也会由产品经理做一些复核，而从节省成本，同时没有太多用户压力的情况下，测试很容易被替代。
02
没有测试或者UI对公司来说是节省了成本，可对产品经理自身而言则是被拽去了更多精力。
比如我之前带过一条产品线，麻雀虽小 五脏俱全，产品设计完成后，UI出图，测试则准备测试用例，开发进行技术搭建。
开发到可以测试的阶段，UI负责验收交互和样式，测试负责验收功能和需求，产品也会随机测一测，然后统一到测试那边进行修复跟进。
所以开发后期直到上线前，产品经理已经能差不多抽出身来去思考新的产品内容，而不必陷在开发和bug解决的跟进上。
因此，公司岗位的缺失有利也有弊，虽然职责不全会让产品经理一人干三人的活儿，但同时也让产品经理陷入到琐碎里难以有更多精力规划大局。
03
作坊式的开发不规范，但却一直存在。其实没有UI和测试的团队我也经历过，这个时期如果团队价值观不统一就会引发很多问题，比如产品经理和开发的矛盾。
没有了UI去画页面以及复核样式，没有了测试去验证bug的修复，所有这些都是产品经理一人多担，所以开发会觉得可能是产品要求太高，故意为难。
现在回想这个阶段，每次开发说可以测试时，我打开页面内心都会有巨大落差，是的，是巨大。
对于样式问题，完整的流程是产品-UI-前端，没有UI，所以既需要产品往下做一步也需要前端往上做一步，共同把UI方面补全。
比如产品经理需要把原型做得高保真一些，而开发没有现成的东西可用，就需要自己找一些控件并且细调样式问题。
很多时候样式问题开发不愿意改嫌麻烦，但正如那句话所说，没有人愿意通过丑陋的外在去了解你的内涵，既然有达到优秀的实力，就不要设定止步及格的预期。
04
除了样式和测试之外，比较常见的还有开发过程中对需求的遗漏，比如开发完后的产品，常常会发现很多需求细节的遗漏，对照需求文档发现很多漏掉的内容，这就说明开发没有逐步对照自检。
我个人比较不能同意“明明知道这个问题存在但就是不想改，等用的过程中被用户发现然后吐槽”。如果是产品思考层面的缺陷被吐槽我可以接受，但由于不自律所产生的问题我不能接受。
很多时候如果研发过程中严格按照需求文档去做，问题出现的数量会少一半，而没按需求去做的结果就是测试问题增多，修复时间变长，开发完再改动使得修复更复杂，从而整体时间拖长。
对于产品和开发的关系，有人戏谑是天敌，但我觉得应该从不同的角度去看。产品不能没有开发，否则就是一堆图纸，开发也不能没有产品，否则难以发挥效用。
产品从各处调研来的需求形成产品设计，不能开发的时候打点折扣，修复bug的时候打点折扣，最终都没达到产品的预期，更别说超越用户期待了，相反，产品要通过开发赋予生命力，形成可用好用并且超越预期满足需求的产品，对用户产生切实的价值。
产品和开发，可以相辅相成，但不相爱相杀。
