web2.0 社区激励模型的一些探讨

cloudward — Mon, 18 Dec 2006 09:57:00 GMT

这是一个非正式稿，我慢慢整理思路

今天看了飞扬新锐的一篇关于《web2.0群组社区运营的思考》的文章，文章对社区群组的激励模型交待了自己的一些看法和将要实施的一些措施，我觉得很有价值，这里推荐给大家。

我的一些想法：

1. 现实中的激励模型经过适当抽象，某种程度是可以搬到虚拟社区的，这样大家更加熟悉，同时也是经过验证的模型，一定程度避免了自己创造激励模型的“履行风险”

2. 社区在基本架构未成型前，不宜在激励模型方面考虑太多。这类似初创企业，如果掏出厚厚的《企业章程和管理制度》，必然给员工（社区居民）造成心理压力和快速适应上的瓶颈。激励应该是循序渐进的，让用户有个参与并逐渐认识到需要激励的过程。（现实生活其实类似，如果员工未曾充分认识到激励的需要，这种激励制度其实只是一个摆设）

3. 敏捷！——很多激励未必按照我们管理者的想象，多尊重社区居民的看法和意见。

偷懒，转载关于日构建和敏捷项目管理的对话

cloudward — Wed, 29 Nov 2006 14:17:00 GMT

这是某个时候在MSN群我自己的一段对话，没想到被人收录了，我再拷贝回来，或许可以给大家一些更好的提示：

以下为与cloundward 以及leon的msn群谈话实录：

cloudward@gmail.com (285273 ,22:24) 说:
一方面需要领导重视这个问题，关系到团队的工作效率；另外，需要很好的软件工程实践基础，以及对配置管理的精通。
cloudward@gmail.com (285273 ,22:25) 说:
csdn把文章丢了，所以才搬到 donews 上来
ginger547 说:
不是简单的把代码管理起来找一个软件在固定的时间运行编译打包吗？我想的是不是太简单了
cloudward@gmail.com (285273 ,22:27) 说:
恩，远非这样。如何分包？如何自动同步更新构建产品？如何在构建的同时实现单元测试，代码覆盖测试？如何实现统一的配置部署环境？
cloudward@gmail.com (285273 ,22:28) 说:
这些问题对于小产品是看不到的，但是对于一个数十人、百人的团队，就是非常重要的问题。否则小小一个核心组件版本的变化，即可影响大量上层模块的运行、调试。
cloudward@gmail.com (285273 ,22:29) 说:
另外，大型软件的测试是不能完全依赖 “测试部门的“，最好的代码质量控制是放在开发上，从源头尽量保证代码的质量。
ginger547 说:
你这样说我好象理解的更深刻了你说的这个过程也很需要单元测试你是指在构建的过程中测试先行只有测试通过的才能构建是不是
cloudward@gmail.com (285273 ,22:29) 说:
这样，就会引入“所谓代码审计“
cloudward@gmail.com (285273 ,22:30) 说:
另外，如果还要考虑对团队的开发效率进行测量，那么还会涉及“代码统计和分析“
ginger547 说:
你说的后一个问题不太好确定吧比喻说有很差的程序员可能需要100行完成的代码高级程序员只需要10行这个工作量怎么确定
cloudward@gmail.com (285273 ,22:32) 说:
现在单元测试架构已经非常成熟了，难的是如何保证大家都去写单元测试，如何统一执行测试并得到可观的，对软件质量的评测标准。
ginger547 说:
你所谓的单元测试架构是指的 junit或者敏捷中的测试驱动吗？
cloudward@gmail.com (285273 ,22:33) 说:
个别差异没有意义，但是，你可以看到类似模块的a组代码比b组明显高，而单眼测试通过率也高，那就是b有问题了。
cloudward@gmail.com (285273 ,22:33) 说:
对，测试驱动对于真正的产品级研发非常有价值
Leon (李梁) (288238,22:33) 说:
项目管理中强调的是“过程管理”，很多"质量"无法保证，所以只能从“过程”来保证。
ginger547 说:
leon好象说的不敏捷吧敏捷不是重人轻过程的吗？
cloudward@gmail.com (285273 ,22:35) 说:
敏捷是“灵活的”但是，灵活的东西需要对过程更精细的理解
cloudward@gmail.com (285273 ,22:35) 说:
本质上，两者没有矛盾，只是针对不同的项目，可能需要区别对待。
Leon (李梁) (288238,22:36) 说:
敏捷中，更加强调过程
ginger547 说:
有了单元测试用例日构建也将更加准确可用这是肯定的可是想明白一个最简单的问题那cloud你到底在你的项目中用了一些什么来保证日构建的完成呢你总结过吗
ginger547 说:
这个我就不太明白了我看的所有的资料都没有说到这个观点敏捷更重视过程！
cloudward@gmail.com (285273 ,22:37) 说:
做了就知道了！
ginger547 说:
？。。。保密？

Leon (李梁) (288238,22:38) 说:
有些东西不太好解释
cloudward@gmail.com (285273 ,22:38) 说:
有些内容是需要体验的
Leon (李梁) (288238,22:38) 说:
软件开发是一个不透明的过程，每块就像一个一个的黑盒子
Leon (李梁) (288238,22:38) 说:
强调过程，就是尽量使这黑盒子变小
ginger547 说:
你们说的是敏捷吧我现在最想知道是你在日构建过程中的实现办法呵呵
Leon (李梁) (288238,22:38) 说:
变得可控
Leon (李梁) (288238,22:40) 说:
项目的管理和程序员的能力不一样，管理的方式也不一样。日构建不是适合所有的项目。
Leon (李梁) (288238,22:41) 说:
对整个开发管理的要求很高。如果强行执行“日构建”，很有可能搞个”肌肉拉伤“之类的

ginger547 说:
那有什么必须要的知识吗？比喻说 cloud刚才说的单元测试用例是必须要用的了还有什么一个很大的ant build吗
cloudward@gmail.com (285273 ,22:43) 说:
好的日构建，都是自己根据需要研发的。虽然业界有些产品，比如Finalbuilder,ant等，但是，这些本质上是提供一种工具，而工具如何灵活运用到研发上，需要精心设计。
cloudward@gmail.com (285273 ,22:44) 说:
你需要熟悉各种工具，ant, perl,php , javac, cmd script等。
cloudward@gmail.com (285273 ,22:44) 说:
另外，设计者本身需要对大团队中的协同问题有非常深刻的理解
cloudward@gmail.com (285273 ,22:45) 说:
比如，分包，如何划分更合理
Leon (李梁) (288238,22:45) 说:
工具很重要，但是不是最重要的。
ginger547 说:
看来这个日构建对项目的贡献很大可是要求也是颇高啊怪不得cloud要说必须大项目才有意义呢
cloudward@gmail.com (285273 ,22:47) 说:
大-->分包-->分别构建-->解决依赖关系-->解决构建时间关系-->解决代码质量-->解决项目协同-->解决项目管理
cloudward@gmail.com (285273 ,22:48) 说:
这是一个不断可以提升的过程
ginger547 说:
在代码日构建的过程中也需要解决代码质量的问题吗？我感觉这点有点牵强
cloudward@gmail.com (285273 ,22:49) 说:
非常重要
ginger547 说:
洗耳恭听
cloudward@gmail.com (285273 ,22:50) 说:
代码的质量包罗哪些呢：1,风格/命名 2. 注释 3.逻辑严密 4.错误引用 5.接口依赖/耦合过重 6. metric 等。
cloudward@gmail.com (285273 ,22:51) 说:
这些问题多数只能在源头控制，功能测试是无效的
cloudward@gmail.com (285273 ,22:51) 说:
团队的技术力量/经验参差不齐，如何控制？
cloudward@gmail.com (285273 ,22:52) 说:
这是现实的问题
ginger547 说:
你的意思还是集中在在构建的测试过程中可以发现一些源头问题我这点明白了
cloudward@gmail.com (285273 ,22:52) 说:
可以发现大量的源头问题
ginger547 说:
其实我感觉这个日构建的过程中是对开发人员的一种不信任是象老师似的每天检查你的作业日构建过了一个合格的老师保证每一个学生每天提供的代码都是正确的可运行的单元测试通过的

cloudward@gmail.com (285273 ,22:54) 说:
对，你理解很正确，摆脱人为因素，给出一个公平和科学的监测手段。
Leon (李梁) (288238,22:55) 说:
"日构建"就是"过程".
ginger547 说:
我感觉软件开发的整个过程中的管理完全采取的是西方的思想，采用的是：假设你不对，你做的不好，我采用一种措施来证明你做的对，你做的好的过程。
cloudward@gmail.com (285273 ,22:57) 说:
难道你有更好的“东方式”解决方案？
Leon (李梁) (288238,22:58) 说:
尽量减少黑盒子在过程中的长度，强调“过程”不是能改进质量，而是尽量提前发现问题。
Leon (李梁) (288238,22:58) 说:
所以在强调“过程”的同时，也要强调优秀的人才
Leon (李梁) (288238,22:58) 说:
这也很重要
cloudward@gmail.com (285273 ,22:59) 说:
敏捷的含义，所以在于对过程的精确理解，从而未雨绸缪。我的同事有个很好地比喻，叫“小步快跑”
ginger547 说:
呵呵现在还不敢说其实我也很同意这种办法中国式的老好人的方式不适合在高智商的开发人员之间使用就应该假设你是敌人我来证明你确实是朋友的态度而且使用的检测手段越是毒辣得到的结果越是正确
Leon (李梁) (288238,23:01) 说:
这个好比在汽车组装厂，螺丝拧紧，这个过程就是扳手扳360度，你的过程做到了，就假设你的质量达到了。
ginger547 说:
发现并修改问题不就是从另一个侧面改进了软件质量吗
ginger547 说:
那我问一个更模糊的问题用什么来证明过程的正确性呢？难道是让假设好用的车跑两圈没问题就是好用的过程？这也就是为什么有试车环节的原因吗？
Leon (李梁) (288238,23:02) 说:
你说的是最后一个过程了。
Leon (李梁) (288238,23:03) 说:
我们假设，汽车流水线假设500个过程，每个都走一遍，每个过程的输入输出结果按照文档要求了，汽车最后下先一定能开出厂。
Leon (李梁) (288238,23:04) 说:
过程也是在不断的优化和调整的。
ginger547 说:
这我就清楚了其实过程也是允许出错的第一辆车也肯定不是生产出来就能跑的呵呵
Leon (李梁) (288238,23:05) 说:
对
Leon (李梁) (288238,23:05) 说:
这就是所谓的“过程改进"

今天重读这个故事，与往日不再相同

cloudward — Wed, 29 Nov 2006 12:29:00 GMT

转载这个故事：

你开着一辆车。

    在一个暴风雨的晚上。
    你经过一个车站
    有三个人正在等公共汽车。
    一个是快要死的老人，好可怜的。
    一个是医生，他曾救过你的命，是大恩人，你做梦都想报答他。
    还有一个女人／男人，她／他是那种你做梦都想嫁／娶的人，也许错过就没有了。
    但你的车只能坐一个人，你会如何选择？

老人
老人快要死了，你首先应该救他？然而，每个老人最后都只能把死作为他的终点站。

救命恩人
你先让那个医生上车，因为他救过你，你认为

帮助项目成功——日构建（2）

cloudward — Tue, 15 Aug 2006 11:28:00 GMT

（本文写于2004年，因 DONEWS丢失再转贴这里。）

日构建在XXX部门的应用经历
日构建未来构想
“没有最好，只有更好”，这是对日构建系统的要求。未来的日构建一方面要解决目前日构建实施中已经显现出来的问题，另一方面，则要挖掘出更深的内涵。
1. 流程全自动化
流程全自动化的意义是节省维护的人力成本，同时加快构建的反馈。日构建的理想状态是按需构建，即任何时候有构建需要，日构建则启动，并以最短时间产生输出。当然实际情况是构建需求可能并不统一，同时输出与构建启动存在一定的时间差。平衡一下，我们希望以更短的构建周期来达到构建反馈的作用。
设想中构建流程的发起可以是时刻触发，也可以是命令触发，还可以是自动侦测触发，即当发现有任何新的提交，则触发构建。一旦触发，全自动的流程应该在无人监管的情况下正常产生目标输出。
2. 构建流程可定制
构建存在多个流程，这是实践中发现的需求。有时候可能只需要对个别项目进行全部构建既可，有时候只需对项目的部分工件进行局部构建既可，有时候可能只需要对最终输出替换某个元数据，等等。日构建的构建应该可以定制为不同种类的流程任务，并辅以不同的项目，部件作为构建参数，当有特定要求时，只需要选择某种流程任务，并指定参数既可完成。
3. 更高易用性
目前的日构建为各种构建需求提供了一系列的构建命令，这种基于命令的构建方式虽然灵活性非常高，但是不易记，难使用。目前的构建只能针对某个项目进行处理，无法提供批命令作用一组项目或者一组工件。未来改进措施是提供类似PT的菜单命令，并扩展支持复合命令，提高灵活性和易用性，争取让每个人都可以较容易学会使用，以便进一步推行“替死鬼”制度。
4. 可插拔的审计和统计处理框架
审计和统计属于附属在日构建上的“扩展”功能，正是这种“扩展”功能是日构建走出了普通构建的定义，成为产品和过程的一个有效控制手段，并为基于敏捷理论的项目管理提供是实践方案。审计和统计的功能必定随着项目需要而存在较多的变化，因而日构建应该需要支持可插拔的审计和统计处理模块，以便提供足够的适应性和可扩展性。
5. 数据和报表分离，提供更多管理决策信息
目前的日构建虽然也采用了数据和视图分离的设计原则，但是构建输出数据还是以文件形式存放，不便于数据共享。未来的日构建输出需要部分改造为输入到数据库，并且形成历史信息库，比如每日构建各个项目的构建信息，单元测试，甚至性能测试的数据信息等。这样基于每日开发进度信息和状态形成的数据库，可以直接提供管理层最真实、最有价值的信息，为项目管理、技术决策提供直接依据。这个功能对XXX的敏捷化管理应该非常充满吸引力。进一步，这个数据库还可以与DMP结合起来，发挥更大的价值。
6. 与统一环境的结合
日构建的输出已经成为不同工作人员的工作输入。目前的日构建输出需要人手工同步到标准服务器，并且手工控制版本。未来设想日构建的系统可以作为一个外挂模块直接集成到统一环境中去（关于统一环境的未来设想请参看本人的另一篇文章），这样管理人员可以通过统一环境直接搭建各种测试环境，开发人员可以借助统一环境直接更新自己想要的版本组件。
7. 补丁管理
一旦XXX面世，即将面临各种补丁管理。日构建应该能够很好支持补丁的打包和发放。

敏捷软件开发管理实践（一）——让人的资源多起来

cloudward — Tue, 15 Aug 2006 11:04:00 GMT

（这是本人2004年关于敏捷软件项目管理的一个创作系列，（一）这篇因为donews丢失，再补贴这里，其他三篇可以在前面看到）

1 让人的资源多起来

软件项目开发的核心资源就是人，在一定的项目规模和资本规模下，人的资源是受限的。项目中考虑人的资源常常以人数来计，但是实际中我们都清楚，工作量是以任务来分解和总和的。这就说明人和任务之间存在一个关系，这个关系就是角色。

1.1 角色（Role）

角色是对工作任务的职责抽象，与具体的职位有着区别。一般情况下，角色和职位是多对一的关系。敏捷风格的项目管理认为在产品（软件）开发过程中，成员所承担的角色虽然有其固定的一面，但是可以赋予它更多变化来改变工作的分配模式。举例来说，A的职位是项目经理，但是同时也是优秀的设计师，那么，可以认为A承担了项目经理和设计师两个角色。

在软件开发管理中，角色其实非常丰富。常见的角色如：项目经理、需求分析师、系统设计师、开发工程师、测试工程师。对于大型项目，比如基于J2EE的项目，根据实际项目中的技能需求，需要各种类似专家的角色，比如人机界面工程师，部署工程师，配置管理员，DBA等。

敏捷的项目管理中要求角色不是固定的，一人可以担任多个角色，这样才可以充分利用已有的资源。如同电网的电力资源一样，资源的存在和分布有时是难以改变的，但是其是否充分利用依赖如何调度。

角色是项目中任务的具体承担对象，从角色角度而不是职位角度考虑资源的分配，有利于合理分工，保持资源的平衡。对于存在多个项目并行工作的情况，这一点非常有意义。我们知道，一个公司的DBA不会太多，多个项目并行工作的时候，可能各个项目都需要DBA的协助，但是从人员编制上，DBA可能仅隶属于某个具体的项目组。这个时候如何解决资源的分配呢？同样，优秀的架构师对于整个公司来说也会是稀缺资源，我们如何让这些稀缺资源发挥更大的作用呢？当然，可以考虑从人力资源编制上解决这个问题，比如成立独立于跨项目组的专门的架构师组，总体设计组等。但是，实际情况往往是人力资源制度的改革步伐永远会远远落后于实际需要。况且，从资源模型本身来看，资源本质上是与角色捆绑的而不是与职位捆绑的。

<图〉

从管理的角度，我们希望资源可以最佳利用。绕过人力资源编制，实际上可以采取特殊的运作模式来达到这一目的。方法就是，赋于比职位多得多的角色，让人具备多个可分配的单位。在这一点可以用CPU的多线程来比喻。

案例：

2001年的时候，公司有Milkyway和Apollo两个项目在同时运行，两个项目都是电子政务项目，采用J2EE技术实现。当时公司是首次接手电子政务项目，对于Web页面所需要的大量美工虽有考虑，但是最终只招聘到一个合适人选。在Milkyway项目组中，大家都知道开发人员Alen喜好摄影，其实是一个图形制作爱好者，Photoshop高手。当美工资源已经成为事实上的开发瓶颈时，我给领导提出了一个建议：是否可以让Alen也充当美工角色呢？可以在开发任务上为Alen消减一半，让他有另一半的时间去让我们的工作产品漂亮起来。后来跟Alen商量让他兼美工这一角色，他愉快地答应了。我想，对于一个图形制作爱好者来说，还有什么工作比干自己喜欢的事情更愉快呢！

1.2 虚拟团队(Virtual Team)

虚拟是相对现实而言。虚拟团队一经发明，已经在互联网上广泛流传。所谓虚拟团队，是指没有实际的组织形态，但是有具体的任务目标；团队成员虽然来自各方，但是为着共同的任务目标而进行工作。

虚拟团队和实际团队比较，优势在于：组建灵活，反应快捷。

实际的团队往往根据长远的任务目标而设立，一经设立，成员即往往有了固定的身份。比如，项目组往往根据产品模块的任务目标而设立，一般来说在项目的生命周期中会一直存在下去。但是实际的项目工作开展过程中，一方面存在很多跨项目组的工作要做，另一方面存在很多短期的任务需要调度资源完成，这个时候固定的团队就难以胜任工作任务的分配。

虚拟团队本质上是根据任务对资源的临时性组建。前面我们已经通过角色把资源独立化了，现在通过虚拟团队，我们可以把独立的资源再通过任务目标而集中起来。

案例：

在上面谈到的Milkyway和Apollo两个项目案例中，当Milkyway项目推进到开发完成60%的时候，系统的基础框架已经基本可以在浏览器中看到。这个时候，架构师发现系统的响应很不理想，这个发现其实并不出乎意外。尽管公司是首次接手基于Web的项目，根据多年的经验还是预测到了可能存在的性能瓶颈。目前的任务就是需要立即组织部分专家来诊断性能瓶颈的准确所在，并敦促项目组成员调整代码。可是面临的问题是公司的测试工程师并不熟悉基于Web项目的性能测试，如何寻着额外的资源呢？另外，还有一个问题，性能问题来源于架构和代码，需要对系统结构和代码最熟悉的系统设计师和开发人员参与才行。这个时候Apollo项目正进入详细编码开始阶段，根据任务分配情况，管理层觉得部分设计师可以抽调部分时间来参与Milkyway项目的性能优化。为此，成立了Milkyway项目性能优化虚拟团队。

Milkyway性能优化虚拟团队

组成成员：

1. 所有Milkyway项目的开发成员和设计师

2. Apollo项目组的Wiki和Polo（两位经验丰富的设计师）

负责人：

Wiki担任负责人和组织者。

目标：

全方位优化Milkyway的性能，达到客户认可的各项系统响应时间指标

任务：

1. 一周内给出Milkyway项目的性能测试报告和性能优化具体指标

2. 三周内给出一期优化分析报告

3. 持续跟踪性能，从第四周起，每两周给出性能测试报告

执行：

1. Milkyway的所有成员需要配合Wiki的组织工作，并接受安排的合理任务

2. Milkyway项目经理Cobo协助Wiki安排工作

测试部经理Anny，配合Wiki安排测试设备和数据准备。

贝趣网(www.babyqu.com)最新改进功能——成长日记

cloudward — Tue, 15 Aug 2006 10:18:00 GMT

写下孩子成长过程的点点滴滴，这是一份责任，也将是每个父母都可以完成的“著作”！

贝趣网(www.babyqu.com)最近系列改进工作

cloudward — Fri, 07 Jul 2006 18:36:00 GMT

1. 接受风信子的建议，所有参选过“今日宝贝”的照片和参选口号可以翻阅。这样便于参与者明确知道自己提交的东西是否被成功接纳，同时也便于与其它参选者进行某种意义的比较，获得更多分享的乐趣。

2. 把宝宝相册和家庭相册真正做到了既分离、又关联。这样，一方面可以集中呈现纯粹的宝宝世界，另一方面，也能够让大家一起来分享家庭的趣味。随着数码相机的进一步普及，以及网络走进手机，家电，未来相册的网络化趋势不可避免。

3. 开发了“爱我就加我”这一个宝宝主页的好友添加功能。这只是一个简单的群体关系，便于彼此熟悉的朋友更紧密地交流，未来，贝趣还会进一步开发更大范围群体的关系圈。

4. 开发了“大家都来凑热闹”功能，这是为了让更多的宝宝有表现的机会。因为各种排名总是只能让少数宝宝处在万众瞩目的位置，而更多的宝宝可能藏在网站里面。贝趣一直认为“每个宝宝都是闪亮的明星”，所以，要想尽更多办法，让其他宝宝，让优秀的照片有更多机会呈现出来。

5. 开

创建了一个电子商务研究交流MSN群 msn3997@bbqun.com

cloudward — Mon, 26 Jun 2006 20:16:00 GMT

我一直觉得交流非常重要，尤其是网络领域，三个臭皮匠，也能碰撞出很多火花！
论坛面向主题、交流太慢，难以适应现在的节奏。
QQ群很好，不过很多“白领”不用，所以放弃了QQ群
昨天正好学会了创建MSN群，也想玩玩新鲜
今天被人点化，领悟：群体交流的成功在于彼此能够增加价值！要做到这一点不容易，就像donews一样。
为了更好交流，认真交流，创建了一个Wiki 用户大家维护联系方式，URL地址是： http://e-club.pbwiki.com
有对电子商务的研究和实践感兴趣、又乐于分享和交流的同行朋友可以给我消息，加入 3997群。

MSN也有群可以玩了，而且很酷

cloudward — Sat, 24 Jun 2006 10:26:00 GMT

昨天接收Mimi Li的邀请，加入了她创建的大学同学MSN群，才知道MSN也可以提供群的服务了。

其实大家都可以创建群：只要访问这个地址：http://bbqun.com/

群创建后，就可以通过web或者这个群内的以'!'开头的各种命令来邀请用户加入！

图中显示：可以敲入 !all 命令显示所有在线的人，可以通过 !add 邀请新的好友。

MSN的很多服务都以奇特的各种插件和第三方网站提供出来，让人有些摸不准其安全性。当然，这些也让我们

看到了一个开放的接口。不过，在“流氓软件”盛行的今天，这些开放未必是件好事，诸位MSN 白领们可要当心了。

祝贺又一个程序员证实了自己的价值

cloudward — Sat, 24 Jun 2006 09:30:00 GMT

新闻：Fishman获得千万美元融资

Fishman的个人主页

Fishman的经历介绍——《FishMan - 从程序员到CEO》

技术人员在中国的成长道路开始越来越像国外了，而这一切，源自创业投资环境的逐渐好转。中国

工商开始关注网上交易了

cloudward — Sat, 17 Jun 2006 08:50:00 GMT

对电子商务感兴趣的朋友建议阅读这篇文章《商务部关于网上交易的指导意见》，相关分析报道请查询 “《网上交易》意见稿发布个人开网店须工商“点头””

不管这件事情是否会在不久将来进行，但是这是一个信号。国家对网上交易的鼓励和规范是“两手抓”，这在《指导意见》一文中有明显提示。此举有关人士可能认为会妨碍中国电子商务的自由发展，我看未必。我个人认为，当前阻碍网上交易发展的最大问题就是“诚信”问题，如果《指导意见》中界定的出卖人和服务平台提供商都能够在工商进行有效登记，这对于保障买受人的交易安全是非常有意义的事情。

电子商务的快捷、方便对于所有人来说，是不争的事实；既然快捷、方便，那就不要担心没有人去想卖，没有人去想买。注意，这里说是“想卖”，“想买&rdquo

宝宝明天满月了

cloudward — Sun, 11 Jun 2006 22:11:00 GMT

阳阳出生时因为忙，忘记通过blog与大家分享这份升级的快乐了。明天，阳阳就要满月了。快一个月的阳阳会有些什么样的本领呢？经过我亲眼证实，这个小生命已经会：

cloudward's blog

社区用户驱动与产品设计（补充）

创业团队中技术与市场的平衡

网络社区功能设计的一些思路要点

web2.0 社区激励模型的一些探讨

偷懒，转载关于日构建和敏捷项目管理的对话

今天重读这个故事，与往日不再相同

帮助项目成功——日构建（2）

敏捷软件开发管理实践（一）——让人的资源多起来

1 让人的资源多起来

1.1 角色（Role）

贝趣网(www.babyqu.com)最新改进功能——成长日记

贝趣网(www.babyqu.com)最近系列改进工作

创建了一个电子商务研究交流MSN群 msn3997@bbqun.com

MSN也有群可以玩了，而且很酷

祝贺又一个程序员证实了自己的价值

工商开始关注网上交易了

宝宝明天满月了

cloudward's blog

社区用户驱动与产品设计（补充）

创业团队中 技术 与 市场的平衡

网络社区功能设计的一些思路要点

web2.0 社区激励模型的一些探讨

偷懒，转载关于日构建和敏捷项目管理的对话

今天重读这个故事，与往日不再相同

帮助项目成功——日构建（2）

敏捷软件开发管理实践（一）——让人的资源多起来

1 让人的资源多起来

1.1 角色（Role）

贝趣网(www.babyqu.com)最新改进功能——成长日记

贝趣网(www.babyqu.com)最近系列改进工作

创建了一个电子商务研究交流MSN群 msn3997@bbqun.com

MSN也有群可以玩了，而且很酷

祝贺又一个程序员证实了自己的价值

工商开始关注网上交易了

宝宝明天满月了

创业团队中技术与市场的平衡