说来也巧，最近的2份工作，虽然职位都还是产品，但是岗位却被划分在了技术部门，并且部门的领导人还都是开发。
这和以往的经历是完全不同的，以前的产品部门，大部分都是独立的部门。产品和技术也都是平级部门，没有上下级关系。双方之间还能够在某些方面碰撞出一些火花，产生出一些新的想法。 那如果产品，归属到技术部门，并且直属领导还是开发的情况下，有些事情，就没有想象中那么简单了。 如果你也有相同的处境，希望对你能够有所帮助。 一.遇到的问题 先来说说这样的情况下，我们在工作中可能会遇到的问题。 1.考虑问题出发点不同 产品和技术，有些时候，天然就是天平的两端，需要我们去权衡。甚至更多的时候，产品和技术，是完全相反的方向。 我们做产品，大部分情况下，考虑的都是用户的使用场景、页面的交互和所谓的用户体验。 我们更多时候，是站在用户的角度去考虑问题，我们所想的是流程实现是否顺畅，用户能否最快的得到想要的结果。 有时候，我们甚至会为了一些小的细节而纠结很久，有时候我们会为了一个文案的提示而徘徊半天。最终的目的，就是为了能够让用户使用起来有“爽感”。为了达成这个目标，无论多么的难捱，我们也乐于其中。 但是这些在技术眼里，那都不叫事，因为这不是他们所关注的。他们所关注的，在我看来，是所谓的实现方式和实现成本。甚至有些时候，他们会考虑所谓的系统复用性。 比如，我们常见的问卷填写，其中非常基础的问题“您的性别”，一般情况下，在我们产品的理解里，这个选项就只有2种：男、女，如果个性一点的，最多还加一个“其它”。 那这个问题，在技术的眼里是什么呢？就是这个字段，有多少值的问题。我们实际遇到的情况就是，他们会给我默认一个“请选择”。听到这个选项，你是不是和我一样的“不解”。 在我们的概念中，请选择，怎么会是可选择的值呢，完全就不能够理解。但是，当前技术老大给出的解释，就是这个所谓的“请选择”，也是值的一部分。 如果在其他公司，这个问题可能就不是问题，产品和技术商量呗，按照行业标准来说，最后的结果肯定也是不会出现“请选择”这个值的。 但是，如果你的领导是技术出身，问题就不一样了，考虑的点也就不一样了，最后也只能妥协了。 2.对工作排期评估不同 对工作的难度评估，一般的正常流程是什么呢？ 按照我以前经验，传统的正排期方式，应该是产品会先根据用户的需求，梳理出相应的流程，在流程确定后，再评估原型、设计、开发、测试、上线等各个环节所需要花费的时间，并且还要加上最后的缓冲时间，这样才能确定最终的时间点。 如果是倒排期，那也比较简单，根据确定的最终时间点，各个部门各自领取任务，然后给出在这个时间点前，各个能够做到的最大程度。 以上2种方式，无论是结构还是方法，都是被业内所能够接受的，大部分的项目管理工具，也都是按照这种模式来配置的。 但是如果要让技术来排期，那他们所考虑的点就完全不是以上的情况了，这就完全是看个人的经验了。对于他们来说，因为他们自己就十分清楚开发工作的具体内容，所以在评估的时候，有一种天然的低估趋势。 而这样的低估趋势，就会经常造成产品上线的时间要比最初评估的时间要晚。 当然，所谓的“低估”，其实和技术评估的当事人有很大的关系，没有普适性。 但是，产品和技术，在评估工作排期上的差异，却是真正存在的。而且，在一般情况下，起主导的应该是产品或者项目，技术人员会作为决策辅助。 但是，如果你的领导是技术出身，你能决定的就少了，什么时候做完，也不是你能决定的了。 3.技术的优先级高于功能优先级 就像之前提到的，产品和技术，永远都是天平的两端，在一般的公司里，这2个部门基本会是平级的存在。双方互相成长，相爱相杀。 产品在做任何功能前，一般都会有一个自己的主观判断，就是这个功能实现起来到底复杂程度如何、需要花多久的时间、能够带来比较高的投入产出比。虽然我们不知道里面具体的实现逻辑，但是我们起码需要它实现起来的判断，这是一个产品经理的基本素养，也是一个产品经理该有的体面。 如果更近一步，在做产品之前，我们能够找开发同学深入了解下，则能够加深我们对所要实现的功能的认知。 有了这样的前提，接下来产品考虑的问题，更多的是体验层面的感知。毕竟术业有专攻，底层的逻辑就让技术去把控，产品需要从上面一层去深挖。我们所考虑的点，也更多的是功能本身以及该功能所能够给产品整体带来怎样的提升和升华。 但是，技术考虑问题的点，可就不是功能了。说实话，我们产品所说的A功能、B功能，对开发同学而已，都没有什么实际的价值。怎么现实，怎么快速的实现，怎么既能够快速而又能够复用的实现，才是他们关心的点。 比如下面这张图，产品要的功能是会飞的鸟，开发实现了，你不能说不对，只能说也行。
虽然上面的例子是极端，但是它却很好的说明了问题。 如果在其他产品和技术平级公司，这样的情况是基本不会出现的，毕竟产品还有起码的操守和底线。 但是，如果你的领导是技术，这种情况就很难说了，更有甚者，很多时候，产品做功能都是在现有技术能实现的条件下去规划的，就更谈不上所谓的优先级问题了。 二.解决的方案 前面说到了我们会遇到的问题，接下来要说的就是我们该如何解决问题了。 1.不能改变就是适应 这句话虽然听起来有点被动，但是很多时候，在实际工作中，我们真的是无能为力。 所处的位置不同，所考虑的问题不同，所看待的角度不同，这样也就形成了所谓的认知差异。 这里说的能够改变，其实包含了2点，一是环境，二是人。 先来说环境，其实就是工作选择，如果你有机会去选择一个领导不是技术的公司，那自然是最好。但是，如果好巧不巧，你的情况和我一样，那你能怎么办呢？要么你就重新换份工作，要么就努力让自己去适应。 再来说人，其实就是你的领导。如果你有绝对的能力，能够出色的做好所谓的“向上管理”，能够让你的领导能够因为你的出现而有所改变，那将是比较完美的方式。但是，很可惜，现实工作中，这样的概率很低，你能改变领导的机会很渺茫。 所以，试着去改变自己，改变自己与领导相处的方式，改变自己对职业的认知。 千万别误会，我这不是在PUA。一直以来，我都是这样的看法，那就是不要在工作中抱怨，如果你干的不爽了，你换份工作就行了，换一份你自己干的爽的工作就行了，何必天天在那苦苦坚持呢！如果你暂时还走不了，那就适应吧。 2.在限制范围内尽量做到最好 那是不是就说，既然我们什么都改变不了，那就躺平吧，反正说啥也没用。千万别，这样是摆烂，对谁都没好处。 我们要做的是，在我们力所能及的范围内做到最好，在我们有限的控制权限内做到问心无愧。 在各种不可能的情况下，做出来让自己满意的产品，才是你自己的本事。 还是说到上面问卷的例子吧，如果性别选择中的请选择，已经注定是选项了，那是不是就不能再抢救一下了呢。其实未必，比如还可以从设计上，将“请选择”和“男女”完全分开，给用户一种统一的体验感。又或者是，前端控制，“请选择”直接不显示出来，减少对用户的干扰。 办法总比困难多，这虽然是一句鸡汤，但是我愿意喝。 其实有时候想想，产品经理，不就天然是这种角色吗？ 我们习惯了在各种想法之间碰撞，我们习惯了在各种流程之间梳理，我们习惯了在各种交互之间磨合，我们习惯了在各个部门之前周旋。 我们天然就带着“不服”和“折腾”的属性，我们也自然的能够在限制下做到最好。 3.坚守产品的底线 何谓“产品的底线”，就是无论如何你都不愿意妥协的那些点、不背离行业主流标准、不干扰用户正常使用。 但是这个很难一句话说的清楚，因为每个人的底线都不一样。 试想一下，有没有哪个瞬间，别人让你改动的某个需求，会莫名的突然引起你的不适，让你久久不能平静，那个点，可能就是你的底线。 我们需要让领导知道有这样的存在，也要让领导知道这是我们作为产品经理的根本。说实话，如果连这个根本都没有了。那也真的不太适合做产品。 还记得有次APP改版，因为一个接口的调用问题，导致在某个页面会加载超过10秒，页面会一直转圈。在产品验收的时候，并没有通过。然后领导就说这个问题一时半会解决不了，可以先在页面上放个“数据加载中，请稍等”的字样。这在技术的眼里是可行的，但是在产品的眼里却是糟糕的。我也向领导表达了，如果就这样上线，肯定会给用户带来非常不好的体验，哪怕是多等1秒，都是对用户的挑战。最终的发版，是在解决了那个问题之后。这里，就是我作为产品经理的坚持。 所以，有时候，坚持一下，可能结果就不一样。 一些想说的话 其实作为产品经理，有时候我们的选择权很小很小。 都是戴着镣铐跳舞，比的就是谁能多出一份同理心。 都是在妥协中磨合，拼的就是谁能够顶住这份压力。
------ End ------
