转自：http://blog.appleap.com/?p=29

2008年被誉为中国互联网界的开放年。这一年中，校内、51、聚友、康盛创想、中国雅虎 等，都跟随facebook的脚步，各自推出独立的开放平台体系；谷歌也在积极推广自己的开放标准，天涯、一起网、MySpace都搭上了 OpenSocial的大篷车，国内也出现了一大批应用开发者和奇矩互动、热酷、Apptz等专业的应用开发公司。

但是，在繁荣的表象背后，有一些现象却值得我们关注：facebook自从2007年7月推出f8开放平台以来，到今年7月24日的f8大会，共吸 引了大约40 万开发人员为其创建了大约2.4万个应用程序，并且这个数字还在飞速增长之中。在中国，以最早推出开放平台的校内网为例，在将近半年的时间中，共吸引了 650名开发者为其创建了852个应用程序（数字来源于AppLeap.com）， 并且最近两个月的时间内应用数量增长缓慢。在美国，一些优秀的应用开发公司能够获得风投的青睐，而中等规模的应用开发者可以靠广告收入养活自己，而在国 内，应用开发者在享受了作品上线后，用户快速增长所带来的短暂狂欢之后，要开始面对昂贵的运营成本，以及缺乏有效营收手段的现实。校内、51开放平台的用 户条款不仅限制多多，而且朝令夕改，让许多应用开发者都感到无所适从，缺乏长期的安全感。最近两个月以来，随着经济形势日益严酷，开放平台似乎也步入了寒 冬的季节。

开放，忽悠了谁，又成就了谁？到底是什么原因导致开放平台没有像预期的那样成为开发者的盛宴？

来自平台方面的原因

今年7月8日，校内网举办新闻发布会，高调宣布开放平台的推出。在开始的一段时间中，新应用像潮水般涌入，校内网宣称每天提交审核的应用就有200 多个。但是，校内网出台的关于第三方应用程序开发与管理的协议，成了开发者口诛笔伐的焦点。在这份协议的第一版中，规定了第三方应用不得嵌入广告，不能引 导注册其他网站和包含跳出外站的链接，不能涉及招聘和旅游等与校内未来扩展方向相关的领域，甚至还规定了应用的产权也归校内拥有。虽然后来校内网对协议进 行了大规模的修订，去掉了一些明显不合理的条款，但从这件事情上，可以看出国内的平台经营者从一开始并没有完全摆正自己的心态。

从技术角度，对比facebook f8，可以看出国内开放平台在技术细节上的简陋。facebook一直在不断完善技术框架，提供更丰富的标记语言（FBML）和开放更多的API，努力给 应用更多发挥的空间及更紧密的嵌入体验。反观国内，开放技术标准的更新速度缓慢，校内最近一个XNML标签的添加还是在9月14日。举一个小小的例 子，facebook允许iframe型的应用通过代理的形式控制父窗口的尺寸，从而达到与父页面无缝整合的目的，这一点功能，国内任何一个平台目前都没 有提供。facebook提供的开放API共有69个，比51和校内加起来的两倍还要多。或许他们认为这些细节无足轻重，但态度的缺失使细节积少成多，用 户体验的差距就慢慢显露了出来。

来自应用方面的原因

校内开放平台的推出，让无数开发者的热情被点燃，他们的创意和激情终于找到了释放的出口，第一批应用的创意大多取自facebook，还有一些是通 过hack flash源码来实现的。国内应用开发者中有很多是刚刚毕业或在校的大学生，应用上线后用户快速增长所带来的新鲜感过后，就会因为运营压力的增大和收入手 段的匮乏而导致热情迅速冷却，一些应用经常出现无法访问的现象，这在一定程度上影响了校内网的整体用户体验。平台和应用在开放生态链当中本来是共生的关系，伤害了对方，最终也一定会影响到自己。

另一方面，对于国内的应用开发者来说，在当前比较恶劣的经济环境之，像rockyou和slide那样获得风险投资非常困难，实现收入的最重要手段 只能是广告。在广告市场相对比较成熟的美国，基于社交网络的广告联盟有很多，广告客户对于新媒体的尝试热情比较高；而在中国，社交网络对广告主的吸引力还 不足以支撑起一个商业模式，应用只能依靠嵌入adsense广告来赚钱，这种低效的方式远远不能将社交媒体的商业价值最大化，也很难养活得了专业的应用开 发团队。很多开发者把应用开发看成是掘金的手段，缺乏长期运营产品的心态，希望能以最快的速度推广和获取收入，这也导致应用开发的导向过于娱乐化，复制成 本很低且不具有不可替代性。高质量应用的缺失使应用开发者相对平台的整体议价能力非常弱。

中国SNS发展的客观环境

facebook和myspace是美国乃至世界上最主流的两家社交网站，在上网人群中的到达率非常高。在中国，SNS的竞争模式演变成了“群殴 ”，校内网、51、开心网等各占据一个细分市场，但任何一家都还不具备像facebook那样庞大的用户基数和强势的影响力。留给应用开发者的施展舞台本 身就不够广阔，再加上各平台之间对用户群的激烈争夺和相互渗透，使他们没有足够的精力持续投入到开放平台的建设中去。

理想中的平台和应用关系

平台和应用之间，不应该是老板和打工者的关系，而应该是在开放的环境中共同生存和利益共享的关系。作为平台，应该注重于建立和维护良好的开放生态环 境，让应用形成优胜劣汰的竞争机制。平台本身是规则的制定者，不适合再成为应用质量的裁判，而应该让用户用脚投票来决定。诚然，由于应用运行与平台之上， 应用的体验平台也需要负责，但平台应该将自己定位于监督者的角色，不轻易越过雷池一步。我们看到facebook在一年多来也对一些应用进行了打击，但他 们针对的是那些试图用非常手段获取超额利益，对整体生态环境造成破坏的应用。

开放平台走向何方

在一个缺乏诚实和信任的开放环境中，无论平台还是应用都难以得到井喷式的发展。中国的开放平台，经过了半年时间的发展，没有迎来一个欣欣向荣的开放时代，却走到了今天这样一个重要关口：发展或是沦落。

中国的开放平台行业，急需新鲜血液的注入，需要一个能够真正以开放的心态重新制定游戏规则的重量级平台，需要重视用户体验、不急功近利、更加成熟的应用开发者群体，需要一批认同社交网络和口碑营销价值，敢于尝试的广告主。

我们看到，在最庞大的白领社交群体中，正上演着真假开心网的PK大战，从宠物认养到养眼的真人秀，从争车位到抢房子，平台们已经把应用的开发的想象 力发挥到了极致。但是，用户的需求是更加多元化的，谁能够驾驭第三方开发者的智慧和想象力为自己服务，也许就能在这场残酷的PK大战中觅得先机。无论如 何，我还是愿意相信，互联网和社交网络最终将循着开放的道路向前发展，与其顾虑重重，不如应难而上，这毕竟是一次难得的历史机遇。

以下是前一段时间，在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

一直以来我都是以php函数的风格来写php，所有变量，函数，类都使用小写，单词之间以下划线隔开，一直比较排斥驼峰式的代码规范，个人觉得在大小写字母之间的书写代码，很麻烦，而且PHP自己的函数都是小写，为什么我不用这种格式呢？

良好的代码书写习惯 + 良好的注释习惯 + PhpDocumentor = 程序说明书

一个团队，必须有整齐的代码书写习惯，如果再配上统一的IDE开发环境，详细的任务编码流程，完善的代码测试（如：SimpleTest），那么整个团队的开发效率将会有很大的提高。

如果你的IDE是Eclipse，那么你可以很方便的进行代码测试，使用SimpleTest参考http://www.guogoul.com/2008/05/19/simpletest_1/

详情查看 »

如何使用PhpDocumentor，参考这篇文章就可以了

http://pkwbim-programming-note.blogspot.com/2008/01/phpdocumentor-0.html

不过，我还是在安装使用的时候，遇到了一点问题。

运行->cmd

进入 php所在目录 d:\php\ 执行go-pear.bat

system|local

输入local，然后根据提示，一步一步来，输入yes，然后就是一路“回车”

这样pear就安装好了

之后，就是安装PhpDocumentor了，

>pear help (查看pear的命令帮助)

>pear help install (查看 install命令的用法)

使用pear来安装，也可以直接下载 http://downloads.sourceforge.net/phpdocu/PhpDocumentor-1.4.2.zip?modtime=1206909537&big_mirror=0

>pear install -o phpdocumentor (安装phpdocumentor)

安装完毕后，进入 D:\php5\PEAR\PhpDocumentor

>phpdoc –parseprivate -o HTML:Smarty:PHP -f E:\web\db.php -t E:\web\doc

-f参数，指定db.php文件，生成文档

>phpdoc –parseprivate -o HTML:Smarty:PHP -f E:\web\ -t E:\web\doc

-d参数，指定目录，生成文档

如果注释是中文的，一定要执行 iso-8859-1 到 utf-8 的替换，否则生成出来是乱码。(把 \php5\PEAR\PhpDocumentor\phpDocumentor 里的（含子目录）的文件里的所有 iso-8859-1 的字串全部换成 utf-8)

指定 -o CHM:default:default 可以生成 chm，不过这个时候，还需要借助“HTML Help Workshop” 来编译成 chm，不过可恶的是，能通过 HTML Help Workshop 编译成chm，但是仍然是乱码，查看源文件后，代码中却是正常中文，暂时无解，或许使用其他软件可以编译成正常中文，还没有尝试

搜索了一下，发现相关的讨论比较少。

这是我找到的几篇文章

http://www.i170.com/Article/1001

http://canque.rssidea.com/popular_article_sort/

一篇文章一般具有一下属性：评论数C、支持数（顶）D、点击数V、发表了多少天T

假设一个评论5分、一个支持3分、一个点击1分；随着时间的延长，文章的重要程度应该降低。

而且时间也应该有一个范围，比如是100天，超过100天的文章就不用再计算了，即使再热门，也应该忽略了。

最后一篇文章得分：(5C+3D+1V)/T

这个值比较大的，就说明文章比较热门。

这是我的一些想法，希望朋友们指正。

http://blog.80s.net.cn/?p=448

http://www.yeeyan.com/articles/view/davidkoree/4409

1.如果一个方法可静态化，就对它做静态声明。速率可提升至4倍。2.echo 比 print 快。3.使用echo的多重参数（译注：指用逗号而不是句点）代替字符串连接。4.在执行for循环之前确定最大循环数，不要每循环一次都计算最大值。

5.注销那些不用的变量尤其是大数组，以便释放内存。

6.尽量避免使用__get，__set，__autoload。

7.require_once()代价昂贵。

8.在包含文件时使用完整路径，解析操作系统路径所需的时间会更少。 详情查看 »