2007年03月27日

飞扬新锐《社区用户驱动与产品设计》对社区用户参与的一些驱动进行了部分概括。分析用户驱动其实非常重要,这是产品设计的灵魂。一个能提供差异化竞争力的社区产品,必定是对用户原始需求的认真、细化的分析和理解所创造的。

飞扬在文中最后的总结 互联 网从未改变需求,所谓需求的创造,无非是有人可以深刻理解,并且成功加以转化,归根结底还是产品对驱动的转化。“ 这句话很深刻。

我个人想把飞扬的 几个驱动 的名字改改,使之更加中性一点。

“虚荣”–〉“被重视和关注”

“利益”–〉“谋求当下和潜在的机会”

至于”异性“,我个人觉得,这个驱动可以归属于 以上两个。

我再补充一些,我感觉到的驱动:

a.  ”情感维系”
     用户与社区互动较长时间后,形成了对社区的持久的“情感”,这个情感可能包括对站长个人魅力的崇拜,对站长事业的理解和支持,对网络其他用户或者某些用户所形成的群体认同 或者 价值认同。这批用户是社区真正的核心。

b. "学习型驱动“
    对于持续创新型的社区,存在一批同行用户,是本着”学习“的目的来参与社区的,在参与的过程中与社区共同成长。他们也可能有自己的其他实践,或者竞争产品。

 于加新 的观点我近来比较认同,的确存一个无驱动。就是存在一些用户,他们未曾体验过类似或者相似的社区,偶然来到你的社区便安家了,然后便先入为主 适应了。这部分用户需求不明确,但是用户的量在某些领域却相当可观,比如说 babytree.com 这样的面向特殊人群/大众用户 的社区。

对于社区的设计,我觉得对 社区用户的认识 和对 产品表达的技巧 是两个最重要的方面。

2007年03月23日

首先是在 wealink小没 的个人公告中看到了《 uuzone挂了》 ,才知道UUZone 已经出了问题。

后来相续在很多Bloger中看到了相关的话题,包括 贝贝客 的创办者 艺叔 的一篇《UUZONE关闭的启示:建立能赚1分钱的持续赢利的模式比什么都重要》。

我对UUZone 不是很了解,但是倒是经常去看看,因为UUZone 经常有些很好的 技术想法,对于我这个技术出身的人来说,有着特殊的吸引力。2006年杭州的第二届网志年会的时候,我还见过 老冒,当然,也见过同样对技术比较重视也在努力实践的诸多站长们,比如 抓虾的老大,E都市的老大,还有 客齐集的 王建硕,他们谈论着marshup , openid ,这些我很感兴趣。

技术出身,对技术比较了解,眼界和知识面可能也更多局限于技术,我倒是很有自知之明。贝趣是我从传统ERP软件 转入互联网后的 折腾的第一网站。当初想做的时候,我只是觉得技术上自己还可以实现自己的想法,而真正吸引我下决心 辞职来折腾的,还是  直觉和一种本能的冲动——能够通过互联网 把高楼林立中孤立的妈妈宝宝们沟通连接起来,这难道不是一件很值得去做的事情。

当然,做项目也必须考虑市场,自己经济上还没有自我解放,同事朋友们也都深陷 不动产 的 泥潭。尽管创业发财的梦想都很大,但是,也都非常清醒认识到 从一开始就需要把  “养活自己” 放在第一位。

1年多过去了,贝趣从 知识+ 电子商务的尝试 发展到 社区+电子商务 的尝试,再退化为一个单纯的社区。我很真切感知道,创业中存在大量不可预知的变数 和 难以奋争到的资源。现在我在babytree.com, 也同样是参与了从无到有,从方向直觉到实现蓝图 的一个过程,我的体会更深刻了。资源是创业过程中的关键问题。
对于一个创业者,你能够拥有多少资源,可能在于你当前的积累,也可能在于你从现在开始朝这个方向的努力。这个问题是值得探讨的。

回到这篇文章的主题:技术和市场的平衡,这个平衡在创业公司中其实是资源的平衡。因为小团队,技术上的人力投入和市场营销的人力和精力投入都是在一个很有限的范围来运作。正因为有限,运作的技巧就显得更加重要。我做产品出身,很清楚产品实现中存在的诸多敏捷的措施。而对于市场,更存在大量“四两拨千斤” 的灵动性。 可是,真正的成功是要能够在 你所获得的 时机中 尽可能 优化团队各方面 的效率而产出 有绝对竞争力的成果——这就是抓虾的成功,blogbus的成功,pplive的成功 等等。

2007年03月19日

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

前段时间在 babytreekeso 分享了他对社区的理解,keso 把社区的关系概念化为“人与人”,“人与信息”,“信息与信息”三重关系。

这三重关系虽然很显然易见,但是,对我的思路影响却很大。我觉得这三重关系把社区的功能设计方向一下子清晰化了许多,为大家在以后的社区设计、社区发展的同行交流中也提供叙述的 一个逻辑思路。

我自己总结了一些社区功能设计的思路要点,在这里与大家分享,希望大家继续补充。

一、人与人的关系
 
        0. “人与人的关系”是社区的核心

 1. 人与人的关系的建立 可能是一种直接建立过程,更可能是一种间接建立过程。

           前者指在社区里,A 偶然认识了B, 然后触发了A与B的后续信息交流。这一点成立的原因是 人往往是好奇的,而在社区中这好奇没有带来坏处。这一点对于
新用户/新社区来说,非常重要。

           后者指,在社区里,更通常的是A 通过信息 认识了B。由于这种认识是在一个信息环境下建立的,具有选择性,目标性、甚至是“功利性”。

        2. 人在社区中是关系网络的节点,意味着 有两种截然不同的需求。一种是主动性需求,由A发出;一种是被动性需求,施加到A身上。这两种需求需要相互平衡。

           主动性需求包括:A 想在社区中干什么?A希望社区给他带来什么?假设所有用户的这些需求累计起来是集合 Set1, 而Set1中可能作用到A 自己身上的是 Set2

           被动性需求包括:Set2是累计的被动性需求,但是Set2中可能存在 A 自己不希望的。比如,A希望知道好友B的任何活动信息,但是A 可能不希望自己的活动信息为B所知。

        3. A与B的关系维护是通过信息来达成的,信息需要一些触发点,增加触发点,可以促进信息交流的频度。触发点有多种类型

            存在某些普适性的触发点,比如 生日、节日
           
     存在一些仅适合A,B之间的触发点,比如 A,B 的共同兴趣,这些触发点往往同 A与B 之间的历史交流 有关系。

        4. 关系维护的深度 处决于 A B 之间历史交流沉淀下来的 价值影响 和 认同度。

        5. 关系维护需要面对 内外界的多种影响,外部影响包括:个体变动、价值迁移;内部影响包括:新鲜感丧失,维护代价增长 等

二、人与信息的关系
 
       0. “人与信息的关系”服务于“人与人的关系”。           

       1. 人是主动方,寻找信息的过程,是信息逐渐被过滤的过程。过滤的方式可能很多:搜索、结构化导航、人际传播 等

       2. 寻找信息的代价越少越好

       3. 潜在兴趣的挖掘能够 提供 用户一种持久的 新鲜感

       4. 能够很好区别不同信息的重要性, 必要的时候把决策权交给用户

三、信息与信息的关系

       0. “信息与信息的关系”服务于“人与信息的关系”

       1. 信息a与信息b 在社区中的关系并不是稳定的,关联程度处决于 阅读的人 C 对 a的作者A 和 b的作者B 之间反映在内容上的认同度。

       2. 信息与信息可能直接通过keyword/tag/category 去关联,也可能通过 信息–人–信息,信息—人—-人—信息去关联。

       3. 信息与信息的关系应该围绕着 社区中人的主要需求 去组织

 

 

2006年12月18日

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

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

我的一些想法:

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

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

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

(未完)

2006年11月29日

这是某个时候在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) 说:
这就是所谓的“过程改进"

转载这个故事:

你开着一辆车。

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

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

    救命恩人
    你先让那个医生上车,因为他救过你,你认为这是个报答他的好机会。同时有些人认为一样可以在将来某个时候去报答他。

    梦中情人
    但是你一旦让医生上了车,你可能永远不能遇到那个让你这么心动的人了。

    最后结果

    “给医生车钥匙,让他带着老人去医院,而我则留下来陪我的梦中情人一起等公交车!”

    是否我们从未想过要放弃自己手中已经拥有的优势(车钥匙)?有时,如果我们能放弃一些我们的固执、狭隘和一些优势的话,我们可能会得到更多。

其实这个不是不值得进行逻辑上的推敲,但是,它是一种抽象,创业后重读,我有了一些新感悟:

1. 决策会面临很多矛盾;不决策就不需要面临这些矛盾。

2. 在各种矛盾中,你可能努力表现的聪明、智慧些,你可能要权衡利弊;你也可以选择作“傻子”,但是这可能是大智慧。

3. 看《大敦煌》后,知道“牺牲自己喂老虎”是大智慧,因为这个举措可以流传了几千年,感化无数人!

2006年08月15日

(本文写于2004年,因 DONEWS丢失再转贴这里。)

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

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

1       让人的资源多起来

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

1.1    角色(Role

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

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

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

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

<图〉

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

2001年的时候,公司有MilkywayApollo两个项目在同时运行,两个项目都是电子政务项目,采用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项目组的WikiPolo(两位经验丰富的设计师)
负责人:
Wiki担任负责人和组织者。
目标:
         全方位优化Milkyway的性能,达到客户认可的各项系统响应时间指标
任务:
1.          一周内给出Milkyway项目的性能测试报告和性能优化具体指标
2.          三周内给出一期优化分析报告
3.          持续跟踪性能,从第四周起,每两周给出性能测试报告
执行:
1.          Milkyway的所有成员需要配合Wiki的组织工作,并接受安排的合理任务
2.          Milkyway项目经理Cobo协助Wiki安排工作

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

“我们为你一生能做的第一件事——就是给你一个完整的童年回忆“。

 

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

贝趣团队非常重视对孩子们的点滴纪录功能,并诚挚希望父母们用心去纪录,让更多的人可以产生交流,相互学习。一个孩子的成长,很大程度是在父母的影响下塑造了自己的个性和世界观;而对于初为父母的你们,什么可以影响你们?

交换一个苹果,每个人获得的还是一个苹果!交换一个思想,每人获得两个思想! 

  新版宝宝成长日记的改进:

  1. 提供一个类似播客的大日历,每个日期格现实当天的日记。点某个日期格即可在当日记日记
  2. 日记新增“天气“,“心情“,“宝宝表现”,从而赋予日记更多信息描述。尤其是“宝宝表现”,将在未来成为一种激励宝宝上进的手段!值得期待!!
  3. 日记采用博客的编辑输入框,可以类似这篇blog 一样,提供近似完美的多媒体现实和预定义图画插入,以及与宝宝相册的关联。这样,就可以把宝宝的照片和日记关联起来,提供一个全面的宝宝生活纪录。(尚未完成)
  4. 允许评论,这样可以有更多交流!
  5. 提供更为人性化的日记查找和浏览功能(尚未完成)

  未来我们还会提供宝宝日记出版,站内日记量最多,最好的若干《宝宝成长日记》,贝趣可以免费为其印刷,那可是嵌入各个时期照片,图文并茂的珍贵档案哟!

 来贝趣,享乐趣,贝趣因你更精彩! 

2006年07月07日

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

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

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

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

5. 开发了站内信件的语音提示。尽管,贝趣提供了“好妈咪群”让大家自由交流,提供了宝宝主页留言,但是依然有必要提供一种比较私密的沟通手段,既可以交流,又可以活跃网站的氛围,于是就开发了这个功能。从近日几天的运作来看,这种站内信件还是别有情趣的。