月归档：十月 2008

以下是前一段时间，在UCD讨论组上面，和一些朋友进行的讨论。 现在整理出来和大家分享一下。 ——————————————————————– 无影说： 程序员总是想尽量精简或者是按照自己的程序编写方便来完成一些功能，有时候就是，为了完成功能，并没有考虑到产品设计上，未来可能会发生的变化，等到变 化来临时，又找出借口来说，这个功能会影响XXX，无法做，或者很难做，以此来刁难。 做产品的时候，总是想一开始就做一个大而全的东西，别人有的我要有，别人没有的我也要有，总是先模仿同类的其他网站，这样很难有自己的特色。 程序员做的不是自己想做的，所以他们总是消极怠工，或者是代码考虑不周全，留下了未来的一大堆隐患，或者是本来可以很快完成的任务，他说是很复杂，这个 需要做很久，以此来表达自己的不满和抱怨，反正我又没打算一直干下去。 如果是程序员自己给自己写程序，就不会这样，开发速度很快，考虑也很细致，倾尽自己所能，以表现自己的技术高超。 或许是技术团队，没有一个顶尖的leader来领导程序员？ 或许是没有一个优秀的产品经理来让程序员信服？ 还是有其他一些矛盾？ 好像每个公司，都有一些和程序员的矛盾，这个如何能尽量避免呢？ moneya说： 我想可以让部分关键程序员前期介入，参与产品需求分析和设计。这样的设计也兼顾了 很多实际的条件，更有实现的可能性。程序员的参与度高，对需求的理解也到位些，责 任感、成就感也强吧。 liyi2008说： 是有这样的问题，我们现在的做法是，产品设计阶段就让技术人员参与，然后经过多次和技术人员讨论形成最终的开发文档，技术人员根据开发文档制定开发计划，这样的好处是不会让技术人员觉得产品与我无关，没有体现我的价值，其实技术的前期参与也可以提出很多建设性的建议。 另外，对于不同类型的程序员需要不同的对待，有些程序员在产品开发过程中有非常多的建议和想法，对产品的控制欲望很强，这样的程序员需要我们投入更多的耐心，和他探讨问题，这样的程序员一旦你和他达成一致，他们的开发和合作会非常好。我个人比较喜欢和这样的程序员沟通。还有写程序员非常严格按照你的产品文档开发，对产品本身没有太多的想法，这样就需要我们把文档写的尽量详细，因为如果有考虑不周全的地方，他们也会按文档开发。 总之，遇到这样的问题还是多找自身的问题，充分调动大家的积极性把产品做好才算一个合格的产品经理 张锐说： 同意。做好一个产品不能仅仅是产品经理的事情，产品经理最重要的一个功能就是调度起跟产品有关的人的积极性，让所有人都发挥其最大的力量。所以，我觉得“控制”对产品经理来说至关重要。 设计的前期我觉得要经常和技术人员沟通，可以让一些对设计有兴趣有想法的开发人员加入进来，他们可以从技术可行性上给予帮助。不过有个问题就是，技术人员也许不懂UCD，而且他们经常是从程序的角度去思考和设计产品，这个时候就需要我们去把握和掌控产品设计。 有些程序员对产品设计可以说丝毫兴趣没有，他们只管自己的代码是否漂亮，这些程序员最怕的就是你开发过程中变更需求，这就要求我们前期需求明确，指定完善的开发文档，深入到产品的各个细节。 wangjuea说： 顶一下liyi2008，对于不同的研发，是要有不同的协调方法。 我还有一个个人的小经验，就是不仅要和研发的同学协调好，更应该先和测试的同学搞好关系。在我的工作圈子里，我了解到大多数研发对于产品消极的处理都是与测试team的考核有直接关系。 所以，我平时会和测试、研发同学经常一起沟通，最大的目的就是期望大家在遇到问题的时候首先能一起了解问题，而不是互相推卸责任。 当然，在这个过程中PM要把握测试的纬度和实现的程度。 无影说： 产品、设计、前端工程师、程序员相互之间责任的推卸是一个很严重的问题，随着分工的越细，这种矛盾有些时候就越明显，但是不分工又没有办法达到相对的专业化。身兼多职的人，就会有所抱怨。 和产品打交道最直接的不知道是不是设计师？ 产品 -> 设计师 -> 前端工程师 -> … 继续阅读 →