克里斯的大空间|谈谈程，说说爱

近段时间在读 Self-Organizing Team 相关的东西，

自我组织和管理团队是一个比较大的课题， 涉及的范围覆盖了整个项目管理的过程。

我想大家应该对罗杰的4321模型印象深刻

chris 比较佩服罗杰同学能把复杂的问题分析得如此有条理有层次。

细数一下， 4321模型里面涉及了4个层次，10个方面的内容 。

而每个内容其实也可以展开来分析 。

由于练历尚浅，于是我觉得如果要对 “Self-Organizing Team ”这个课题有所作为，就要先选一些方面来深入思考、研讨。

于是chris打算专门谈谈目标感方面的话题。

今天读了一下《过度承诺 与 过度交付》 ，不禁震惊了一下。

文中主要讲到项目管理过程中的两种情况， 过度承诺 与 过度交付 。

过度承诺， 每次迭代均 承诺了 但是做不到， 这无疑是在凶狠的消磨团队士气。

因此，为了避免这种恐怖的情况发生，在过往的工作中，chris的潜意识里也倾向于 过度交付 。

读了此文， 才意识到 过度交付 对团队的不良影响 ，

过度交付，即意味着团队的产出总是能大大的超过之前的承诺，

咋一看，这是一个非常好的事情啊。

看了此文分析，再深入的想了一下，总是过度的交付，说明团队不能做出承诺。

一方面，团队缺乏挑战性的目标，长期的没挑战的环境也不利于维持团队的兴奋度、凝聚力。

另一方面，过分宽松的环境对团队成员的个人成长也是不利的。

总结之，适度挑战性的短期目标，对团队的影响是正面的，积极的。

chris回忆起KM team 过往IRM的情形，

印象中KM team的成员也意识到这个问题，提过过类似的担忧，团队渴望成长，庆幸！

因此，落实到实际行动，

我觉得往后的项目管理行为里，

一方面要保持思想上的警醒，不要过度承诺，也不要过度交付。

另一方面，要鼓励团队做出能完成的、积极大胆的承诺。放大团队完成挑战性目标的成就感。同时在挑战性的目标不能完成的时候，不要惩罚团队，而更多的鼓励这种挑战高峰的勇气。

使得整个团队能工作得更有目标，也能在高速的运转中得到成长。

第一次：

推广方式：RTX消息群发

发送范围：全公司

结果：

由于缺少全员推广经验及性能意识不够，在RTX消息送达之后的不久，

便引起了服务器雪崩效应，

随即进行服务器的操作，重启了服务，但是流量高峰已过，流失了部分潜在用户。

痛定思痛，平台组马上组织人员排查，优化。

当日一直奋战致深夜12点

最后综合了各种的技术优化手段，（静态化、变量cache、页面cache、暂时关闭写访问log的探针、服务器压力监控等等）

得出了一个优化方案并实施之。

第二次：

推广方式：邮件

范围：约等于全公司，(研发月报的发送范围)

结果：

经过第一次的教训及优化，大家也非常期待第二次推广来考察之前的优化是否能经受考验。

第二次推广选择在大家都去吃午饭的时间，希望能更进一步错开流量高峰。

根据chris目测，当时服务器压力的值，在0.5到2左右，连保护开关所设置的值20的十分之一也不到。

大喜过望！不费吹灰之力就应对了推广带来的流量。

但是不得不打个问号，到底是推广效果不好，还是服务器的处理的确强大了？

第三次：

推广方式：针对单人RTX消息推广

范围：3000多人（当时所有已经接收了福袋的人）

结果：

12:30开始分别对每个已经收到福袋的人发RTX消息通知，提示TA已经收到福袋，来平台回赠一下。

程序设置了每发一个人暂停半秒（为了错峰），预计会在1:00时发送完所有RTX推广消息。

实际上，发送程序一直到1:30才结束，相信是调用OA的RTX消息接口的耗时也相当严重。

而12:45往后，服务器的压力值就不断的挑战 压力保护开关的阀值20 。

随后chris不得不把压力保护开发的值上调到30 以容纳更多的请求 。

压力值一直持续在30 直到 2:00 左右排查了代码，去除了一句遗漏的代码后才开始回落。

本次推广的压力如此巨大，原因归结为：

1、在写福袋页面遗漏的代码会每半秒取一次福袋数量

2、RTX消息推广效果明显，针对人的推广，更凸显该用户对推广消息的关注程度。

3、扩大了可发送的福袋数量（20000个），能容纳更多的用户参与活动。

通过三次的推广手段及其结果， 虽然不一定百分之百是chris猜想的原因

但是，就chris来说， 在这次之前，

脑袋中还一直模糊的大概认为  Email的推广效果 = RTX消息的推广效果 = 平台广告的推广效果 = etc…

而经过这次福袋活动的推广，

很切身的体会到各个推广手段带来的效果其实可以差很远。

而另一方面，也很重要的就是，这次的活动加强了团队成员的性能意识，及拓宽了视野。

年前快速的在南极做了个小型的投票后台

这个下午都在弄 月报(km) 向 南极(home)的投票调用程序。

因为月报的这个活动是静态页面，所以只能通过javascript的方式来与投票后台交互。

这样困扰我们多次的问题又来了， 跨域调用问题！！

因为 km 与 home 不是同一个站， 获取 与 提交数据都是不允许的。
都会收到错误“ Access to restricted URI denied (NS_ERROR_DOM_BAD_URI)”

我们之前的解决方法是用本地的一个页面做代理，
即在km站写一个简单的 proxy.php?url=xxx ， 然后用php代码来获取 指定url 的内容

这个做法可以解决部分问题，

但是弊端有二：

1、只能获取数据，提交数据显得有点不够直接

2、丢失用户信息 ， 因为都是通过代理去访问最终的应用的，因此最终的应用服务器辨别不出用户的身份。

这两点都不太适合月报的投票应用。

于是chris开始查资料，用jQuery 1.2以上版本的 .getJSON 函数来处理跨站调用。

$.getJSON($url,function(data){
// do something
});

按这个函数的调用方式， 看似是跟原先 $.ajax 的调用类似

但是chris在过程中一直遇到“Access to restricted URI denied (NS_ERROR_DOM_BAD_URI)”

原来问题的关键在于 url  以及调用后台都必须要改造一下。

具体为：

[客户端]

如果 $.ajax 的时候 url 为  /user/get_something

用 $.getJSON 的跨站调用时， 就要写成  /user/get_something?callback=?

这里”callback=?” 是一个固定的写法，?的内容chris估计jQuery 会自动补充

[服务器端]

如果平时写的json数据返回是 {attribute1:xxx;attribute2:yyy;}

那么就要改成 CALLBACK_PARAM({attribute1:xxx;attribute2:yyy;})

其中 CALLBACK_PARAM 是通过 $_GET['callback'] 获得的url中传过来的 callback参数

举个例吧

测试服务端时， 例如 在地址栏敲 xxxx.com/users/get_something?callback=abc

那么返回应该是 abc({attribute1:xxx;attribute2:yyy;})

后来chris为了保证服务器端的兼容性， 所以在输出json数据包之前，如果有callback参数传入，则输出abc(JSON_OUTPUT) 的形式， 否则就直接输出JSON_OUTPUT

管中窥豹

虽然chris没有深入去了解这种jsonp的工作原理

但是chris猜测是，利用允许ajax获取跨站读取javascript这个空子，

把数据伪装成一段javascript脚本来返回。

所以要求服务器的输出是 abc(JSON_OUTPUT) 的形式

这种形式看着就像是一个叫“abc”的函数，其 参数是 JSON_OUTPUT

相信这点的实战，对平台组各位往后的js跨站数据获取的应用会带来帮助。

敬请关注

^_^

Welcome to Thinklet.net Blogs. This is your first post. Edit or delete it, then start blogging!