文档介绍：因为讨论的大意就是说,产品没有技术知识,所以经常和技术人员有矛盾,比如像我的亲身经历那样,就是产品想出来的东西,不是无法实现,就是天马行空,所以,有很多次被我们压回去,就是因为想法不够完备和无法实现。      所以,我觉得信管,如果学好了,真的有它的价值的。因为信管必须要有产品的创新触觉,也必须有技术的实践能力。这样出来的产品或许就会更好。所以读信管的看完这个可以自行斟酌一下专业的路怎么走,真能胜任这个职位的人数缺口还是蛮大的。努力吧~以下是前一段时间,在UCD讨论组上面,和一些朋友进行的讨论。——————————————————————–程序员总是想尽量精简或者是按照自己的程序编写方便来完成一些功能,有时候就是,为了完成功能,并没有考虑到产品设计上,未来可能会发生的变化,等到变化来临时,又找出借口来说,这个功能会影响XXX,无法做,或者很难做,以此来刁难。做产品的时候,总是想一开始就做一个大而全的东西,别人有的我要有,别人没有的我也要有,总是先模仿同类的其他网站,这样很难有自己的特色。程序员做的不是自己想做的,所以他们总是消极怠工,或者是代码考虑不周全,留下了未来的一大堆隐患,或者是本来可以很快完成的任务,他说是很复杂,这个需要做很久,以此来表达自己的不满和抱怨,反正我又没打算一直干下去。如果是程序员自己给自己写程序,就不会这样,开发速度很快,考虑也很细致,倾尽自己所能,以表现自己的技术高超。或许是技术团队,没有一个顶尖的leader来领导程序员?或许是没有一个优秀的产品经理来让程序员信服?还是有其他一些矛盾?好像每个公司,都有一些和程序员的矛盾,这个如何能尽量避免呢?我想可以让部分关键程序员前期介入,参与产品需求分析和设计。这样的设计也兼顾了很多实际的条件,更有实现的可能性。程序员的参与度高,对需求的理解也到位些,责任感、成就感也强吧。是有这样的问题,我们现在的做法是,产品设计阶段就让技术人员参与,然后经过多次和技术人员讨论形成最终的开发文档,技术人员根据开发文档制定开发计划,这样的好处是不会让技术人员觉得产品与我无关,没有体现我的价值,其实技术的前期参与也可以提出很多建设性的建议。另外,对于不同类型的程序员需要不同的对待,有些程序员在产品开发过程中有非常多的建议和想法,对产品的控制欲望很强,这样的程序员需要我们投入更多的耐心,和他探讨问题,这样的程序员一旦你和他达成一致,他们的开发和合作会非常好。我个人比较喜欢和这样的程序员沟通。还有写程序员非常严格按照你的产品文档开发,对产品本身没有太多的想法,这样就需要我们把文档写的尽量详细,因为如果有考虑不周全的地方,他们也会按文档开发。总之,遇到这样的问题还是多找自身的问题,充分调动大家的积极性把产品做好才算一个合格的产品经理同意。做好一个产品不能仅仅是产品经理的事情,产品经理最重要的一个功能就是调度起跟产品有关的人的积极性,让所有人都发挥其最大的力量。所以,我觉得“控制”对产品经理来说至关重要。设计的前期我觉得要经常和技术人员沟通,可以让一些对设计有兴趣有想法的开发人员加入进来,他们可以从技术可行性上给予帮助。不过有个问题就是,技术人员也许不懂UCD,而且他们经常是从程序的角度去思考和设计产品,这个时候就需要我们去把握和掌控产品设计。有些程序员对产品设计可以说丝毫兴趣没有,他们只管自己的代码是否漂亮