《产品策划设计和程序员之间的矛盾.doc》由会员分享，可在线阅读，更多相关《产品策划设计和程序员之间的矛盾.doc（4页珍藏版）》请在金锄头文库上搜索。
1、那天看到了一篇分享，说的是产品策划/设计和技术人员之间的矛盾该怎么解决的讨论总结，突然，我想到了，可能这就是信管这个专业之所以出现的原因吧 因为讨论的大意就是说，产品没有技术知识，所以经常和技术人员有矛盾，比如像我的亲身经历那样，就是产品想出来的东西，不是无法实现，就是天马行空，所以，有很多次被我们压回去，就是因为想法不够完备和无法实现。 所以，我觉得信管，如果学好了，真的有它的价值的。因为信管必须要有产品的创新触觉，也必须有技术的实践能力。这样出来的产品或许就会更好。所以读信管的看完这个可以自行斟酌一下专业的路怎么走，真能胜任这个职位的人数缺口还是蛮大的。努力吧以下是前一段时间，在UCD讨论
2、组上面，和一些朋友进行的讨论。程序员总是想尽量精简或者是按照自己的程序编写方便来完成一些功能，有时候就是，为了完成功能，并没有考虑到产品设计上，未来可能会发生的变化，等到变化来临时，又找出借口来说，这个功能会影响XXX，无法做，或者很难做，以此来刁难。做产品的时候，总是想一开始就做一个大而全的东西，别人有的我要有，别人没有的我也要有，总是先模仿同类的其他网站，这样很难有自己的特色。程序员做的不是自己想做的，所以他们总是消极怠工，或者是代码考虑不周全，留下了未来的一大堆隐患，或者是本来可以很快完成的任务，他说是很复杂，这个需要做很久，以此来表达自己的不满和抱怨，反正我又没打算一直干下去。如果是程
3、序员自己给自己写程序，就不会这样，开发速度很快，考虑也很细致，倾尽自己所能，以表现自己的技术高超。或许是技术团队，没有一个顶尖的leader来领导程序员？或许是没有一个优秀的产品经理来让程序员信服？还是有其他一些矛盾？好像每个公司，都有一些和程序员的矛盾，这个如何能尽量避免呢？我想可以让部分关键程序员前期介入，参与产品需求分析和设计。这样的设计也兼顾了很多实际的条件，更有实现的可能性。程序员的参与度高，对需求的理解也到位些，责任感、成就感也强吧。是有这样的问题，我们现在的做法是，产品设计阶段就让技术人员参与，然后经过多次和技术人员讨论形成最终的开发文档，技术人员根据开发文档制定开发计划，这样的
4、好处是不会让技术人员觉得产品与我无关，没有体现我的价值，其实技术的前期参与也可以提出很多建设性的建议。另外，对于不同类型的程序员需要不同的对待，有些程序员在产品开发过程中有非常多的建议和想法，对产品的控制欲望很强，这样的程序员需要我们投入更多的耐心，和他探讨问题，这样的程序员一旦你和他达成一致，他们的开发和合作会非常好。我个人比较喜欢和这样的程序员沟通。还有写程序员非常严格按照你的产品文档开发，对产品本身没有太多的想法，这样就需要我们把文档写的尽量详细，因为如果有考虑不周全的地方，他们也会按文档开发。总之，遇到这样的问题还是多找自身的问题，充分调动大家的积极性把产品做好才算一个合格的产品经理同
5、意。做好一个产品不能仅仅是产品经理的事情，产品经理最重要的一个功能就是调度起跟产品有关的人的积极性，让所有人都发挥其最大的力量。所以，我觉得“控制”对产品经理来说至关重要。设计的前期我觉得要经常和技术人员沟通，可以让一些对设计有兴趣有想法的开发人员加入进来，他们可以从技术可行性上给予帮助。不过有个问题就是，技术人员也许不懂UCD，而且他们经常是从程序的角度去思考和设计产品，这个时候就需要我们去把握和掌控产品设计。有些程序员对产品设计可以说丝毫兴趣没有，他们只管自己的代码是否漂亮，这些程序员最怕的就是你开发过程中变更需求，这就要求我们前期需求明确，指定完善的开发文档，深入到产品的各个细节。对于不
6、同的研发，是要有不同的协调方法。我还有一个个人的小经验，就是不仅要和研发的同学协调好，更应该先和测试的同学搞好关系。在我的工作圈子里，我了解到大多数研发对于产品消极的处理都是与测试team的考核有直接关系。所以，我平时会和测试、研发同学经常一起沟通，最大的目的就是期望大家在遇到问题的时候首先能一起了解问题，而不是互相推卸责任。当然，在这个过程中PM要把握测试的纬度和实现的程度。产品、设计、前端工程师、程序员相互之间责任的推卸是一个很严重的问题，随着分工的越细，这种矛盾有些时候就越明显，但是不分工又没有办法达到相对的专业化。身兼多职的人，就会有所抱怨。和产品打交道最直接的不知道是不是设计师？产品
7、 - 设计师 - 前端工程师 - 程序员 - 测试人员整个的流程是并行，还是串行有交叉？我认为应该整个Team对项目都有所理解，而不是仅仅是各司其职。这些程序员最怕的就是你开发过程中变更需求，这就要求我们前期需求明确，指定完善的开发文档，深入到产品的各个细节。”不过产品的改动或变更，直接影响到，后续所有人的变化，这也可能是大家比较抵触的原因，但是有些时候，某些改动又是必须的。整个Team成员的相互认知，认可，对矛盾的激化能起到很好的降温作用，多沟通是一个很好的解决办法，只是这种沟通是通过会议，还是私下的午餐、上下班路上、闲聊，还是其他方式呢？有时候，程序员的一个建议，产品无法拿出很好的建议来反
8、驳，但是产品又不想按程序员的想法来做；或者是程序员提出一个改动，可以省下不少的开发时间（无论省下来的时间，他干什么了。），同时对产品的影响不大，他都希望产品能做出让步，如果这个时候产品说，你必须这么做，很强势，程序员就会有抵触情绪，对于这种程序员如何沟通？“有时候，程序员的一个建议，产品无法拿出很好的建议来反驳，但是产品又不想按程序员的想法来做；”一般遇到这种情况我会根据建议用原型开发工具把建议用原型实现，然后和程序员一起站在一个使用者的角度去走流程，看看是否合理，这时可以多找几个人，马上大家就会发现哪种方案更好，我们公司主要做手机软件开发，一般程序员的建议可以反应到产品的表现层，所以这个方法
9、好用，如果原型开发可以实现一些交互效果会更好，但是不知道这个办法是否具有通用性。程序员不是我们的敌人，不要总想着驳倒对方，如果大家都能站在最终产品的角度很多问题都会解决，这需要我们做产品的多去包容，明确自己的的最终目标是什么。如何与程序员沟通有时候是一个相当棘手的问题，不管是UI guideline得制定还是实施过程中，由于UI的一个决定可能需要程序员大量工作来解决，碰到比较强硬的程序员就不得不要求PM来进行支持，但是这终究不是完善的解决办法，完善的解决办法是，对于一些道理很明显而程序员出于自身利益的考虑而拒绝合作的可以书面详细列举利弊直接要求PM来支持你UI的工作，而对于两难选择，可以通过建
10、立目标用户群来反馈用户的意见，这个是程序员永远无法反驳的，当然有时候用户群可能会站在程序员这一边，我们自然以用户意见为最终指导，起码可以循序渐进。真正重视用户体验的公司是会支持你建立目标用户群并进行Usability调查的，而这也是我们很多UI 目前缺乏的经验。希望大家能多多共享这方面的实际经验。与用户站在一起才会使软件真正为人所称赞而不是成为用户发泄怨愤的替罪羊。恩，我就碰到过程序员在设计上坚持自己的建议，这个时候最有力的说服根据就是用户反馈一个以目标用户群的可用性测试结果。不然就只能是高层定夺了我也经常碰到这样的问题。这样的问题不仅仅发生在产品和技术之间，同样也会发生在市场和产品之间我觉得
11、在流程上应该可以解决一部分问题，在形成产品相关文档的时候，比如MRD，PRD，这些文档出来后，可以跟市场部门的运营计划一起讨论，或者产品部门内部讨论PRD的时候，可以让技术人员参与进来，这样其实在产品需求确定的过程中，就同时考虑了产品运营需求和技术调研，也能让市场和技术的同事更有了解产品本身。在合理的流程下，还需要的，就是产品经理对产品的把握和控制了，产品经理一定要考虑到多方面的因素，至少在这个团队里，你就是这个产品的专家，你需要说服你的同事怎么去做这个产品，需要提出运营的建议，需要及时的跟进，改进产品。不管技术人员怎么怠工，或者思想怎么懒散，只要产品真正是在向好的方向发展，比如是在赢利，或者
12、使用人数是在增加，或者其它相关数值是在大家的努力下一步步上升，那么这就是一个成功的流程，大家合作就是成功的。相信有过一两次这样的成功合作的经验，以后，技术部门的同事们也不会再消极怠工了，对于代码的热情也会一步步提起来。市场部的同事也一样，对于产品来说，所有与产品相关的人就是一个团队，产品经理需要很好的去调动大家，使产品的开发过程变成一种良性的成长过程，只有这样，才会越做越好。这个问题我的做法：1 PM与RD本就应该关系非常密切，如果PM和RD关系不好，那只能说PM沟通交际能力不过关，问下自己：和RD交往多不多，经常一起吃饭吹牛不，别说作为PM你连交际费都木。2 RD有一个惯性：就是如果PM不懂
13、技术，他就会有点瞧不起你的想法，所以嘛，我都十分关注技术，对技术也很熟悉，公司很多小工具，小程序都是偶自己开发的，偶虽然不是一个优秀的CODER，但是对技术了解很广泛，这样你经常和技术交流，其乐融融载，还会有啥矛盾，当然让技术参与产品前期是非常必要的。OVER。良好的沟通、充分调动大家积极性都是很有必要的。但是问题依然会出现，我们如何解决？下面有一些工作心得与大家分享，FIY。或许是技术团队，没有一个顶尖的leader来领导程序员？我们来看一下产品经理的的职责：1、市场调研2、产品定义及设计3、项目管理4、产品宣传5、产品市场6、产品生命周期管理仅靠产品经理个人来解决问题，显然不够现实。有必要
14、在相关工作环节制定相关可用性工作流程。无规矩不以方圆！有了工作流程的保证，才能够更好的解决现有问题和后续未知问题。FIY：以下流程比较适合软件开发团队，针对团队大小，可适当调整流程。1、规划需求阶段可用性工作流程可用性规划、界面原型、可用性概要需求、可用性需求评审、可用性详细需求2、设计开发环节可用性工作流程详细需求、界面和交互支持、界面和交互检查、可用性专题、专题分析设计、可用性需求评审3、测试环节可用性工作流程可用性发版指标、可用性测试、可用性缺陷修复、可用性问题支持、可用性缺陷验证、可用性发版报告4、可用性实验工作流程制定计划、实验准备、可用性实验、实验分析以上的流程，也是在工作中慢慢总结理出来的。问题每个开发团队都会有，仅靠良好的沟通和调动大家积极性去处理问题，肯定会被累死，效果也不明显。可用性工作的开展不是一两个人的工作，我们需要用我们专业的可用性知识，在合理的工作流程中去影响规划、需求、开发、测试人员甚至是老板。
