产品策划设计和程序员之间的矛盾

那天看到了一篇分享，说的是产品策划/设计和技术人员之间的矛盾该怎么解决的讨论总结，忽然，我想到了，可能这就是信管这个专业之因此出现的缘由吧~

       由于讨论的大意就是说，产品没有技术知识，因此常常和技术人员有矛盾，好比像个人亲身经历那样，就是产品想出来的东西，不是没法实现，就是天马行空，因此，有不少次被咱们压回去，就是由于想法不够完备和没法实现。

       因此，我以为信管，若是学好了，真的有它的价值的。由于信管必需要有产品的创新触觉，也必须有技术的实践能力。这样出来的产品或许就会更好。因此读信管的看完这个能够自行斟酌一下专业的路怎么走，真能胜任这个职位的人数缺口仍是蛮大的。努力吧~

如下是前一段时间，在UCD讨论组上面，和一些朋友进行的讨论。

 

——————————————------------------------------------------------------------------------------------------------------————————–

 

程序员老是想尽可能精简或者是按照本身的程序编写方便来完成一些功能，有时候就是，为了完成功能，并无考虑到产品设计上，将来可能会发生的变化，等到变化来临时，又找出借口来讲，这个功能会影响XXX，没法作，或者很难作，以此来刁难。

作产品的时候，老是想一开始就作一个大而全的东西，别人有的我要有，别人没有的我也要有，老是先模仿同类的其余网站，这样很难有本身的特点。

程序员作的不是本身想作的，因此他们老是消极怠工，或者是代码考虑不周全，留下了将来的一大堆隐患，或者是原本能够很快完成的任务，他说是很复杂，这个须要作好久，以此来表达本身的不满和抱怨，反正我又没打算一直干下去。

若是是程序员本身给本身写程序，就不会这样，开发速度很快，考虑也很细致，倾尽本身所能，以表现本身的技术高超。

或许是技术团队，没有一个顶尖的leader来领导程序员？
或许是没有一个优秀的产品经理来让程序员信服？
仍是有其余一些矛盾？

好像每一个公司，都有一些和程序员的矛盾，这个如何能尽可能避免呢？

 

我想可让部分关键程序员前期介入，参与产品需求分析和设计。这样的设计也兼顾了
不少实际的条件，更有实现的可能性。程序员的参与度高，对需求的理解也到位些，责
任感、成就感也强吧。

 

是有这样的问题，咱们如今的作法是，产品设计阶段就让技术人员参与，而后通过屡次和技术人员讨论造成最终的开发文档，技术人员根据开发文档制定开发计划，这样的好处是不会让技术人员以为产品与我无关，没有体现个人价值，其实技术的前期参与也能够提出不少建设性的建议。

另外，对于不一样类型的程序员须要不一样的对待，有些程序员在产品开发过程当中有很是多的建议和想法，对产品的控制欲望很强，这样的程序员须要咱们投入更多的耐心，和他探讨问题，这样的程序员一旦你和他达成一致，他们的开发和合做会很是好。我我的比较喜欢和这样的程序员沟通。还有写程序员很是严格按照你的产品文档开发，对产品自己没有太多的想法，这样就须要咱们把文档写的尽可能详细，由于若是有考虑不周全的地方，他们也会按文档开发。

总之，遇到这样的问题仍是多找自身的问题，充分调动你们的积极性把产品作好才算一个合格的产品经理

 

赞成。作好一个产品不能仅仅是产品经理的事情，产品经理最重要的一个功能就是调度起跟产品有关的人的积极性，让全部人都发挥其最大的力量。因此，我以为“控制”对产品经理来讲相当重要。

设计的前期我以为要常常和技术人员沟通，可让一些对设计有兴趣有想法的开发人员加入进来，他们能够从技术可行性上给予帮助。不过有个问题就是，技术人员也许不懂UCD，并且他们常常是从程序的角度去思考和设计产品，这个时候就须要咱们去把握和掌控产品设计。

有些程序员对产品设计能够说丝毫兴趣没有，他们只管本身的代码是否漂亮，这些程序员最怕的就是你开发过程当中变动需求，这就要求咱们前期需求明确，指定完善的开发文档，深刻到产品的各个细节。

 

对于不一样的研发，是要有不一样的协调方法。
我还有一个我的的小经验，就是不只要和研发的同窗协调好，更应该先和测试的同窗搞好关系。在个人工做圈子里，我了解到大多数研发对于产品消极的处理都是与测试team的考核有直接关系。
因此，我平时会和测试、研发同窗常常一块儿沟通，最大的目的就是指望你们在遇到问题的时候首先能一块儿了解问题，而不是互相推卸责任。
固然，在这个过程当中PM要把握测试的纬度和实现的程度。

 

产品、设计、前端工程师、程序员相互之间责任的推卸是一个很严重的问题，随着分工的越细，这种矛盾有些时候就越明显，可是不分工又没有办法达到相对的专业化。身兼多职的人，就会有所抱怨。

和产品打交道最直接的不知道是否是设计师？

产品 -> 设计师 -> 前端工程师 -> 程序员 -> 测试人员

整个的流程是并行，仍是串行有交叉？我认为应该整个Team对项目都有所理解，而不是仅仅是各司其职。

 

这些程序员最怕的就是你开发过程当中变动需求，这就要求咱们前期需求明确，指定完善的开发文档，深刻到产品的各个细节。”

不过产品的改动或变动，直接影响到，后续全部人的变化，这也多是你们比较抵触的缘由，可是有些时候，某些改动又是必须的。

整个Team成员的相互认知，承认，对矛盾的激化能起到很好的降温做用，多沟通是一个很好的解决办法，只是这种沟通是经过会议，仍是私下的午饭、上下班路上、闲聊，仍是其余方式呢？

有时候，程序员的一个建议，产品没法拿出很好的建议来反驳，可是产品又不想按程序员的想法来作；
或者是程序员提出一个改动，能够省下很多的开发时间（不管省下来的时间，他干什么了。），同时对产品的影响不大，他都但愿产品能作出让步，若是这个时候产品说，你必须这么作，很强势，程序员就会有抵触情绪，对于这种程序员如何沟通？

 

“有时候，程序员的一个建议，产品没法拿出很好的建议来反驳，可是产品又不想按程序员的想法来作；”通常遇到这种状况我会根据建议用原型开发工具把建议用原型实现，而后和程序员一块儿站在一个使用者的角度去走流程，看看是否合理，这时能够多找几我的，立刻你们就会发现哪一种方案更好，咱们公司主要作手机软件开发，通常程序员的建议能够反应到产品的表现层，因此这个方法好用，若是原型开发能够实现一些交互效果会更好，可是不知道这个办法是否具备通用性。程序员不是咱们的敌人，不要总想着驳倒对方，若是你们都能站在最终产品的角度不少问题都会解决，这须要咱们作产品的多去包容，明确本身的的最终目标是什么。

 

如何与程序员沟通有时候是一个至关棘手的问题，无论是UI guideline得制定仍是实施过程当中，因为UI的一个决定可能须要程序员大量工做来解决，碰到比较强硬的程序员就不得不要求PM来进行支持，可是这终究不是完善的解决办法，完善的解决办法是，对于一些道理很明显而程序员出于自身利益的考虑而拒绝合做的能够书面详细列举利弊直接要求PM来支持你UI的工做，而对于两难选择，能够经过创建目标用户群来反馈用户的意见，这个是程序员永远没法反驳的，固然有时候用户群可能会站在程序员这一边，咱们天然以用户意见为最终指导，起码能够按部就班。真正重视用户体验的公司是会支持你创建目标用户群并进行Usability调查的，而这也是咱们不少UI 目前缺少的经验。但愿你们能多多共享这方面的实际经验。与用户站在一块儿才会使软件真正为人所称赞而不是成为用户发泄怨愤的替罪羊。

 

恩，我就碰到过程序员在设计上坚持本身的建议，这个时候最有力的说服根据就是用户反馈—一个以目标用户群的可用性测试结果。

否则就只能是高层定夺了

 

我也常常碰到这样的问题。
这样的问题不只仅发生在产品和技术之间，一样也会发生在市场和产品之间

我以为在流程上应该能够解决一部分问题，在造成产品相关文档的时候，好比MRD，PRD，这些文档出来后，能够跟市场部门的运营计划一块儿讨论，或者产品
部门内部讨论PRD的时候，可让技术人员参与进来，这样其实在产品需求肯定的过程当中，就同时考虑了产品运营需求和技术调研，也能让市场和技术的同事更
有了解产品自己。

在合理的流程下，还须要的，就是产品经理对产品的把握和控制了，产品经理必定要考虑到多方面的因素，至少在这个团队里，你就是这个产品的专家，你须要说
服你的同事怎么去作这个产品，须要提出运营的建议，须要及时的跟进，改进产品。无论技术人员怎么怠工，或者思想怎么懒散，只要产品真正是在向好的方向发
展，好比是在赢利，或者使用人数是在增长，或者其它相关数值是在你们的努力下一步步上升，那么这就是一个成功的流程，你们合做就是成功的。相信有过一两
次这样的成功合做的经验，之后，技术部门的同事们也不会再消极怠工了，对于代码的热情也会一步步提起来。市场部的同事也同样，对于产品来讲，全部与产品
相关的人就是一个团队，产品经理须要很好的去调动你们，使产品的开发过程变成一种良性的成长过程，只有这样，才会越作越好。

 

这个问题个人作法：
1 PM与RD本就应该关系很是密切，若是PM和RD关系很差，那只能说PM沟通交际能力不过关，
问下本身：和RD交往多很少，常常一块儿吃饭吹牛不，别说做为PM你连交际费都木。

2 RD有一个惯性：就是若是PM不懂技术，他就会有点瞧不起你的想法，因此嘛，我都十分关注技术，
对技术也很熟悉，公司不少小工具，小程序都是偶本身开发的，偶虽然不是一个优秀的CODER，可是
对技术了解很普遍，这样你常常和技术交流，其乐融融载，还会有啥矛盾，固然让技术参与产品前期
是很是必要的。OVER。。

 

良好的沟通、充分调动你们积极性都是颇有必要的。可是问题依然会出现，咱们如何解决？

下面有一些工做心得与你们分享，FIY。

或许是技术团队，没有一个顶尖的leader来领导程序员？
咱们来看一下产品经理的的职责：
一、市场调研
二、产品定义及设计
三、项目管理
四、产品宣传
五、产品市场
六、产品生命周期管理
……
仅靠产品经理我的来解决问题，显然不够现实。有必要在相关工做环节制定相关可用性工做流程。无规矩不以方圆！有了工做流程的保证，才可以更好的解决现有问题和后续未知问题。

FIY：如下流程比较适合软件开发团队，针对团队大小，可适当调整流程。

一、规划需求阶段可用性工做流程
可用性规划、界面原型、可用性概要需求、可用性需求评审、可用性详细需求
二、设计开发环节可用性工做流程
详细需求、界面和交互支持、界面和交互检查、可用性专题、专题分析设计、可用性需求评审
三、测试环节可用性工做流程
可用性发版指标、可用性测试、可用性缺陷修复、可用性问题支持、可用性缺陷验证、可用性发版报告
四、可用性实验工做流程
制定计划、实验准备、可用性实验、实验分析

以上的流程，也是在工做中慢慢总结理出来的。问题每一个开发团队都会有，仅靠良好的沟通和调动你们积极性去处理问题，确定会被累死，效果也不明显。可用性工做的开展不是一两我的的工做，咱们须要用咱们专业的可用性知识，在合理的工做流程中去影响规划、需求、开发、测试人员甚至是老板。

 ---------------------------------

　　每一个公司都但愿有一个杰出的产品战略，能使公司先于其余任何公司进入一个新兴市场;或者但愿有一个这样的产品战略，能为公司源源不断地提供具备竞争优点的优秀产品。一个有效的产品战略可以激励人们开发出成功的产品;相反，即使是最好的开发努力也会因低效的产品战略而付诸东流。不管是杰出的仍是低效的产品战略，它们都是产品开发的起点，都在许多重要的方面影响着产品开发。

　　产品战略是基于战略高度对产品机遇的前瞻性认识。若没有这种前瞻性认识，公司就会被迫在看不到各类机遇的全貌的状况下，做出开发新产品和对现有产品进行更新换代的决策。这样一来，一些二流的产品可能被开发了出来，而更好的机会却被忽视了。若是有行之有效的产品开发战略，那么，企业在决定投资开发新产品时，它就能确信已全盘考虑了全部的主要机遇。

　　产品(战略)规划的四个层次

　　一、产品战略愿景

　　是一个明确方向和内容的愿景，它对下一层次产品平台战略的性质、时间安排和竞争定位进行指导

　　二、产品平台战略

　　是共同技术要素的一个集合，特别是一系列产品实施过程当中采用的核心技术。产品平台开发的过程包括产品平台概念的评估、产品平台规划和产品平台开发。

　　三、产品线战略

　　来自产品平台战略，是一个分时间段的、有条件的计划，为一个产品线肯定开发产品的顺序。这个顺序是按时间分阶段的，贯穿整个产品平台和产品线的生命周期。并且，它能够根据对市场、竞争要求和资源情况的变化而改变。

　　四、产品开发战略

　　单项新产品的开发则是产品线战略的具体实施。