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

现在整理出来和大家分享一下。

——————————————————————–

无影说：

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

做产品的时候，总是想一开始就做一个大而全的东西，别人有的我要有，别人没有的我也要有，总是先模仿同类的其他网站，这样很难有自己的特色。

程序员做的不是自己想做的，所以他们总是消极怠工，或者是代码考虑不周全，留下了未来的一大堆隐患，或者是本来可以很快完成的任务，他说是很复杂，这个
需要做很久，以此来表达自己的不满和抱怨，反正我又没打算一直干下去。

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

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

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

moneya说：

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

liyi2008说：

是有这样的问题，我们现在的做法是，产品设计阶段就让技术人员参与，然后经过多次和技术人员讨论形成最终的开发文档，技术人员根据开发文档制定开发计划，这样的好处是不会让技术人员觉得产品与我无关，没有体现我的价值，其实技术的前期参与也可以提出很多建设性的建议。

另外，对于不同类型的程序员需要不同的对待，有些程序员在产品开发过程中有非常多的建议和想法，对产品的控制欲望很强，这样的程序员需要我们投入更多的耐心，和他探讨问题，这样的程序员一旦你和他达成一致，他们的开发和合作会非常好。我个人比较喜欢和这样的程序员沟通。还有写程序员非常严格按照你的产品文档开发，对产品本身没有太多的想法，这样就需要我们把文档写的尽量详细，因为如果有考虑不周全的地方，他们也会按文档开发。

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

张锐说：

同意。做好一个产品不能仅仅是产品经理的事情，产品经理最重要的一个功能就是调度起跟产品有关的人的积极性，让所有人都发挥其最大的力量。所以，我觉得“控制”对产品经理来说至关重要。

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

有些程序员对产品设计可以说丝毫兴趣没有，他们只管自己的代码是否漂亮，这些程序员最怕的就是你开发过程中变更需求，这就要求我们前期需求明确，指定完善的开发文档，深入到产品的各个细节。

wangjuea说：

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

无影说：

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

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

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

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

同意张锐说的”这些程序员最怕的就是你开发过程中变更需求，这就要求我们前期需求明确，指定完善的开发文档，深入到产品的各个细节。”

不过产品的改动或变更，直接影响到，后续所有人的变化，这也可能是大家比较抵触的原因，但是有些时候，某些改动又是必须的。

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

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

liyi2008说：

“有时候，程序员的一个建议，产品无法拿出很好的建议来反驳，但是产品又不想按程序员的想法来做；”一般遇到这种情况我会根据建议用原型开发工具把建议用原型实现，然后和程序员一起站在一个使用者的角度去走流程，看看是否合理，这时可以多找几个人，马上大家就会发现哪种方案更好，我们公司主要做手机软件开发，一般程序员的建议可以反应到产品的表现层，所以这个方法好用，如果原型开发可以实现一些交互效果会更好，但是不知道这个办法是否具有通用性。程序员不是我们的敌人，不要总想着驳倒对方，如果大家都能站在最终产品的角度很多问题都会解决，这需要我们做产品的多去包容，明确自己的的最终目标是什么。

j.chen@oocl.com说：

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

张锐说：

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

不然就只能是高层定夺了

ronaldo说：

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

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

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

赵宁说：

这个问题我的做法：
1 PM与RD本就应该关系非常密切，如果PM和RD关系不好，那只能说PM沟通交际能力不过关，
问下自己：和RD交往多不多，经常一起吃饭吹牛不，别说作为PM你连交际费都木。

2 RD有一个惯性：就是如果PM不懂技术，他就会有点瞧不起你的想法，所以嘛，我都十分关注技术，
对技术也很熟悉，公司很多小工具，小程序都是偶自己开发的，偶虽然不是一个优秀的CODER，但是
对技术了解很广泛，这样你经常和技术交流，其乐融融载，还会有啥矛盾，当然让技术参与产品前期
是非常必要的。OVER。。

刘丰说：

良好的沟通、充分调动大家积极性都是很有必要的。但是问题依然会出现，我们如何解决？

下面有一些工作心得与大家分享，FIY。

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

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

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

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

再搬出一个老问题：
请问一下你周围的需求、开发、测试人员、老板，可用性在你们公司是做什么的？如果他们回答不出，那你就需要好好思考思考，该如何开展这项工作了！o(∩_∩)o

搜狗输入法是我目前用过的输入法中，最方便的输入法，不得不鼎力推荐。
目前只支持Symbian S60 第三版，支持第二版的即将发布，期待中，我的Nokia6600就是第二版的系统，我等着你。

短信下载
发送“2”至“10666666”获取下载地址，即可轻松拥有最新版的搜狗手机输入法。
WAP下载
通过手机浏览器访问http://shouji.sogou.com，根据版本支持型号选择适合您手机的搜狗手机输入法下载。
电脑直接下载
通过电脑下载适合您手机的sis安装包，再传输到您的手机上进行安装。
http://shouji.sogou.com/download.php

mysql 分组 group by, 排序 取每条记录中，时间最大的一条记录

SELECT A.* FROM test A,
(SELECT aid, MAX(day) max_day FROM test GROUP BY aid) B
WHERE A.aid = B.aid AND A.day = B.max_day
ORDER BY a.install DESC

以下是 test 表，测试sql

CREATE TABLE IF NOT EXISTS `test` (
`id` int(10) unsigned NOT NULL auto_increment,
`install` int(10) unsigned NOT NULL,
`day` int(10) unsigned NOT NULL,
`aid` int(10) unsigned NOT NULL,
PRIMARY KEY (`id`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8 AUTO_INCREMENT=12 ;

INSERT INTO `test` (`id`, `install`, `day`, `aid`) VALUES
(1, 1232, 20080808, 1),
(2, 2321, 20080809, 2),
(3, 1236, 20080810, 3),
(5, 4212, 20080809, 1),
(6, 2312, 20080810, 1),
(7, 1432, 20080811, 1),
(8, 2421, 20080808, 2),
(9, 4245, 20080811, 2),
(10, 5654, 20080810, 2),
(11, 412, 20080808, 3);

还是看实际代码吧？

http://www.d5s.cn/example/js/js_flash.html 正常

http://www.d5s.cn/example/js/jquery_flash.html 出错

一个使用的是 document.getElementById(’XXX’).innerHTML = str;

另一个使用    $(”#XXX”).html(str);

结果，使用了jquery方法，会出现一些BUG在IE，其他浏览器未发现。

我之前也写过一篇文章： http://www.d5s.cn/archives/79

我以为 是使用jquery造成的，看来是jquery对object做了特殊处理，到底做了什么处理呢？我还不清楚，希望哪位js达人告诉我。