读书生

项目管理其实是一个合理控制和分配时间及资源的管理流程。想到几点，随手写在这里：

1. 需要一个长期的规划。

-规划的目标要在可能实现的范围内，越远大越好。记住，要可能实现。做个网址导航站，说要到纳指上市，那肯定是不行的。
-这个规划中，应该包括你想做什么，你的目标是什么，最后这个项目会变成什么样子。
-这个规划应该在每一个中期，甚至是短期目标实现之后，做出调整和补充。
-所谓战略管理，就是这个部分。

2. 需要一个基于长期规划的现实计划。现实计划分为两个：中期的，和短期的。

-中期的计划要包含一部分长期规划中的目标：到什么时间，完成什么任务。
-短期的计划要切实可行，确保每一个短期计划都可以在经过努力后实现。
-短期计划应由中期计划分解而来。比如中期计划是公司3年内收支平衡，则短期计划应至少分解到每年实现怎样的收入水平。

3. 需要一个切实可行的短期时间表，及一个可控的资源分配表。

-时间表必须可执行。可执行的意思是，时间表重要细化到日常工作，时间表的作用是：完全按照时间表执行，到deadline的时候，短期目标即已经实现。所以时间表的制定需要花费很多时间和精力，经过仔细考虑。
-资源分配表包括人力资源、物质资源等各类可以调动的资源。其重点是“可控”，即，列入该表的资源必须是完全under control的，从而确保任务可以完成。在公司管理中，资源分配表应包括所有下属的KPI及其中/短期计划

4. 执行！根据时间表和资源分配表，切实贯彻所有计划，并且，坚持到底。

-执行力就体现在这个部分。既然时间表和资源分配表都已经完成，那么下一步就是不遗余力地执行并完成任务。
-员工的作用就是具体执行并完成任务；管理者的作用，除了完成属于自己的任务之外，还要在员工遇到问题，可能无法按时完成任务的时候，协助解决问题，保证进度。
-坚持到底。坚持到任务完成目标实现。

5. 有效跟进时间表的进度和资源分配表的消耗。每一个项目的进度都要在两张表中有效地反映出来。

-时间表和资源分配表的真正作用在于督促执行，如果任务执行过程中没有充分的跟进，那这两张表也就毫无意义了。
-充分的跟进，意味着每个工作日必须对两张表进行更新，标识已经完成的进度、遇到的问题，管理者必须做到心中有数，并且据此对之后的工作合力安排优先级。

6. 执行中，要关注细节，力争做到每个细节的完美。

-“细节决定成败”说的就是在执行中注意每一个细节。能否得到promotion，往往取决于其对细节的关注和把握程度。
-有时候，整个项目的成败，或是成功的程度，也取决于一些细节的把握。
-管理者要对重要的细节心中有数，在分配资源的时候，做出相应安排并且要亲身参与。

7. 执行中，要提高沟通效率，明确各方需求，抓住重点。

-这是“执行力沟通”的问题。沟通的效率分两个层面：1，能否明确需求；2，能否提高效率。
-明确需求，管理者要协调各方在沟通中充分表达意见并且达成互相的理解，从而明确项目目标和各方需求。
-提高效率，管理者要通过运用有效的管理手段和工具，尽可能提高沟通的效率，减少沟通中的成本浪费（人力、时间）。

以上是经过一段时间的项目管理、时间管理后的简单小结。
其实这个过程，也是一个结构化（参见前文）的过程。

网站和用户的关系有时候就好像男人和老婆的关系。

1. 你不能都听她的，因为第一，她不一定都是对的，第二，总要有拿主意的人，你是户主；
2. 你不能完全不听她的，否则你将面临一哭二闹三上吊的窘境；
3. 你要引导她，告诉她你的理由，让她相信你，支持你；
4. 你要哄着她，尤其生气的时候，不能把事态扩大，要大事化小小事化了，保持和谐；
5. 你同时要及时改进自己的错误，犯错不要紧，能改就是好同志。

站务论坛，就得这么弄。

【阅世书生原创·转载请注明出处】

这两天总是右眼跳，果然是凶兆。

忙得像个陀螺不去说它，今天中午一个会后突然就发现，之前一篇信手拈来的部门事务说明文档，居然引发了一场不小的地震：不仅抄送到CEO那里，还发出好几封to everyone的。虽然老大出手把事情挡了下来，但还是让我相当郁闷。

1，首先要认清问题所在：的确是我的疏漏造成的误会，但事实上，这本不应成为一个误会；这样的疏漏并非错误，类似于发感谢信时少抄送了一份，而且还是因为存在时间差导致的；
2，接着就是要说抱歉：对发件人，对相关人，表明态度。同时记得抄送；
3，最后是吸取教训：有些地方一定要注意措辞，要为别人考虑，要重视“用户”体验。还有，要低调。

谢谢PIER和小七及时的安慰。不管你们是否曾经有过和我这次一样的疏漏，谢谢。
其实，就是一些很简单的世故人情，算起来也是我放纵惯了，从不注意。很多时候做人做事，还是非要注意不可的。
和人打交道么，尤其是要合作的伙伴或者是不断熟悉起来的朋友，这些都是基本的生存技能。
相比之下，倒是做推广打电话要容易一些，都是官样文章，客气相当。

【阅世书生原创·转载请注明出处】

在小公司的好处就是能学到各种东西。比如除了产品策划之外，必须学会测试。一个人打两份工，虽然只拿了一份的钱。
一个上午都在测试。在可以预见的将近一周时间里，都将进行这样的测试。每个页面，每个细节，每个功能点，甚至每个数据，每个对齐，每个颜色，每个字体样式，每个浏览器兼容，每个CSS效果……
我知道百度有专门的HTML代码实现员，有专门的测试部门，我们都没有。于是我们的UI设计师要负责代码开发，我们要顺便负责测试。周四上线的东西，只有4天时间测试+修订。其中测试还包括白盒黑盒，甚至还有公司范围的内测，怎么来得及？我们4个人一个上午就列出来100来个问题……

中午吃饭的时候，琢磨一下，发现还是流程的问题。这是第一次在产品和技术直接加上HTML实现这个环节，磨合上肯定存在问题。比如，究竟代码是对产品部负责还是对技术部负责？究竟我们提交技术的应该是代码还是PS？技术的工作量究竟如何界定？实现员的工作又如何界定？而实现员在写代码的风格上，CSS的运用上，浏览器的兼容上，本身就与技术需要一定时间的熟悉和磨合，所有这些不熟悉，自然造成了这次测试环节的混乱。

是不是应该这样：

1. 产品策划完成后，提交技术评审，此时产品方面暂时Close;
2. 评审完成后，产品和技术各自准备文档，技术评估工作量，产品提交进度，同时实现员开始写代码;
3. 写代码的过程，技术有限地参与，协助调整CSS等;
4. 代码完成后，交付产品部进行初步UI测试，通过之后将产品文档和代码一起交给技术开发;
5. 此时产品和技术协调确定交付测试的时间;
6. 最后的上线时间则由产品部在功能测试的过程中再最后确定。

上线之后要好好写一份report。

【阅世书生原创·转载请注明出处】

学会总结是一个很好的习惯。工作至今的几个月里我虽然没能每天坚持，但是每凡有事总是做一些记录，美其名曰产品部工作日志。本意是写成航海日志的意思来，现在看起来更像是工作的流水帐，仅有自己整理思路，“结构化管理”的作用了。

总结是很有必要的。两周之前，部门讨论会的时候作了一次简单的项目总结。发现确然是能学到一些东西。这次的项目眼看又要结束了（下周上线），眼下临到最后的测试阶段，这个项目如何总结，总结一些什么东西，又要提上日程了。

总结应该分几个方面：
1，项目总体优劣的评判；
2，优点是什么？原因是什么？（是吸取了教训？还是采用了新的办法？）
3，不足是什么？原因是什么？（缺乏经验？还需磨合？）
4，项目流程中遇到的问题；（技术的问题？产品的问题？沟通的问题？安排的问题？）
5，问题出在哪个环节上？产品设计？技术评审？沟通？
6，如何改进？——针对每个问题，如何改进？

“管理学”的学习分为两个部分：理论+案例。
不论是复旦的光华学院还是百度的PM部门，都很强调一点：Case Study。我相信大部分涉及管理的地方，都是如此。
学习案例的作用是要举一反三，往往从一个案例中就可以走通一整个流程，或者为以后避免一整串错误。通过案例，尤其是真实的案例学习，可以迅速积累经验，有效提高判断的准确性。

有必要整理一下手头工作中的案例。
这将是下周除了大规模测试之外，最重要的工作。

【阅世书生原创·转载请注明出处】

最近一段时间关于管理执行，在工作中听到最多的词语是“流程”。很高兴自己加入到这样一个成长中的团队里，成为参与理顺流程的一部分。
“结构化管理”是我自己生造出来的词。结构化（structurize）的意思是将一样东西变得有结构，有层次。结构化管理，我的意思是，将管理（management）变成的有结构有层次，简单说，就是理顺管理流程。

大的流程我不敢说，知道的一些也不方便说。虽然自己身在其中感受很深，这些东西还是私下交流比较好。小的流程我用篮球队来说事吧。这是我目前真正“管理”着的实体性事务。
篮球队有十几二十来号人。上到公司高层，下到普通员工。高到1米94，壮到200来斤，都有。篮球队每周活动，已经成为惯例，十几号人虽然不可能每次都全到，但是大致总能到个10来个，分3组对抗，每次都打得有声有色。
作为组织人，我需要负责的事情其实很简单：一定周期从行政部预支一笔储备金，每周四左右，给队员发邮件确认是否参加本周活动，然后订场地，记录参与人数，周六带上篮球，买够所有人喝的水，付钱进场，然后收集队员的交通发票，队员在我这里报销，预支费用基本用完的时候，凭发票到财务处报销，然后预支下一轮的储备金。另外，如要联系公司间的比赛，则包括与对方联系，确定场地，清算支出等。(这是战略性的，按下不表)

那么现在，我来结构化一下：
数一数，一共8件事。其中每周例行的是6件事。剩下的2件事平均3-4周一次。
先分析每周例行的6件事：
1，邮件确认是否参加：不是很花时间，甚至邮件都可以制作统一格式，只需按照outlook的时间提示及时发送就可以了。作为组织人，这件事必须自己做。这件事情引发了后一件后续任务：记录参与人数。这件事无法优化也没有必要优化，相反，这件事是确立组织人地位的有效方式之一。
2，记录参与人数：这件事同样必须自己做。也不是很花时间，因为只需要根据大家的回复情况，就可以大致知道人数，不需要非常精确。记录这个人数是为了方便确定买多少水。这件事无法优化。同样，也是确立组织人地位的一种方式。
3，订场地。这件事必须我自己做。这样方便发票的汇总，也方便场地那边联系人与我们的配合。人头熟了好办事，如果不是自己做就会很混乱。这件事情的问题是比较麻烦。因为引发的后续事件比较烦：每次要跑到三楼付钱，由于不是整数，还要在凑满一定次数之后才能拿到发票，引发我这里现金流的混乱。从结构化的角度，这件事可以设法优化。
4，买水。这件事可以不必总是自己做。从管理的角度，对篮球队活动而言，这件事可以称之为琐事（附属性工作），组织人亲历亲为，只会让整个管理过程变得繁琐而难以忍受，还会影响去三楼付钱这件事情的进度。这件事可以优化。
5，付钱进场。没啥好说的，当然要自己来。省不掉。但是如果订场地的流程可以优化，那么这个流程也可以随之一起优化。
6，收集发票报销。没啥好说的，必须我来做。否则谁给队员报销？

再来结构化剩下的2件事：
1，预支储备金。必须自己做。流程已经预设且无法改变。虽然这个流程不是很顺，因为每3-4周去预支一次钱是很麻烦的，但是由于这件事并非完全由我控制，关涉到我与上级（行政经费），所以如果不能批下来一笔固定经费的话，这个步骤相当于与上级共同协调、讨论工作，难以优化。
2，凭发票报销。必须自己做。这没啥好说的，实报实销。可以优化的只是财务流程的熟悉程度。准备好足够多的报销单，定时签单报销。相当于定时向上级report。无法优化。

可以优化的事情如下：（列出我的优化办法）
1，订场地：比较好的优化方法是与对方协商，作为长期客户，办理会员卡，从而简化每次的付费流程。这样就免去了每周电话里报名字、报时间、还要提心吊胆，可能还会没有场地（会员卡可以确定获得场地）。
2，如果上述流程可以优化，则付费进场的流程可以直接免去。一次性付费之后，每次只需确认到场（这个不用我来确认），记录次数就好了。
3，买水：这件事我的优化办法是，每次进场之后，电话联系来得最晚的几名队员，请他们帮忙买水，进场后找我报销。这样优化对全队更合理：保证组织人始终在场内，方便组织活动，让最后几名队员买水可以确认需要买多少水，甚至可以免去记录参与人数这个步骤。

以上优化是对下的，是我的管理范畴。另外一件事的优化是对上的：
预支储备金：我希望的优化流程是，篮球队有一笔固定经费（小金库），每次发票实报实销，不填充预支储备金，报销来的钱直接进入小金库，从而确保小金库的额度。优化的难度在于，预支储备金的流程，在财务方面更简单，固定经费目前通不过行政审批。所以这个优化暂时搁浅。当然，为了简化流程，我还在与上级沟通，如果能办会员卡，那么就可以预支到一笔较大的储备金，这个问题其实也基本解决了。

结构化之后，原本呈“碎片状”的8件事，被整合起来了，变成了以下这个流程：
1，预支一笔较大额度的储备金，前往办理会员卡。
2，每周邮件联系，确定参加人数。
3，周六直接入场，人差不多到齐之后，联系最后几名队员买水，同时开打。
4，活动后收齐发票，到一定额度后报销。
会员卡额度用完之后，重复第一步。这样整个流程就比较顺了。

结构化之后，每周例行的工作缩减成了3件事。而且都相当简单，几乎不花时间。而剩下的事情也变成了较长周期的一次性工作，很容易操作。
篮球队是个很小的松散型组织，日常工作的结构化管理可以优化流程简化操作提高效率。更大范围的管理是同样的道理。
我写得很累了……

写博客可以结构化么？

【阅世书生原创·FeedSky博客挑战赛·转载请注明出处】
再写那些抒情式的书评乐评影评，就离我这个博客建站的初衷越来越远了，虽然我知道，作为本博的长期固定读者，小D同学更愿意看我写那些柔软的文字。请小D同学谅解，这个博客除了供我时常抒发泛滥情感之外，还担负着整理思路记录思想的任务。

这本《Don’t Make Me Think》（以下简称DMMT）是网站UI设计方面的必读书，是网站设计师和产品设计人员的经典读本。现在市面上看到的是这本书的第二版。和日新月异的互联网同步，这本讲述网站UI设计的书，由于采用了很多优秀/糟糕网站的页面设计案例，所以其版本的更新必定要跟上时代的步伐。

我是在开始这个职位的工作之后才读到这本书的。感谢张总和星汉，在我刚刚接触这个行业的时候，给了我入门的指导：看哪些书，学什么东西，读什么博客等。这本DMMT我们在部门讨论会的时候也认真讨论过，对自己在工作中涉及到的UI设计和产品细节，的确有很大的帮助。
这里向所有对网站界面和产品设计有兴趣的朋友推荐这本书。

DMMT的中心思想其实用一句话就可以概括：以用户为中心。不要让我思考，本质上就是减轻用户的负担，将设计围绕着用户进行。
我们看、或使用一个网站，通常在使用的过程中会对一个网站有我们自己的判断：好，或者不好，方便或者不方便。这个判断的标准，通常就出自我们对这个网站的使用体验。如果我们能够很顺利地在网站上完成我们的既定目标，如果网站在设计上能站在用户的立场上考虑问题，最大限度地方便用户，那么这个网站通常就能留住用户。
换句话说，“不让用户思考”，才能留住用户。这是一个读图时代（轻量化阅读）的必然。

这本《DMMT》通过作者从事互联网咨询的工作经验，从UI设计、界面细节、网站结构、导航设计、测试等整个流程，通过实际案例的讲解，为我们介绍了如何让一个网站更可用，更易用，更“以用户为中心”。
其中的不少建议，现在已经成为互联网的通行做法，被很多优秀的、重要的网站采纳，比如导航的设计，看似简单，但是其中需要设计人员很深的功力，这本书提出的一些基本思路，对网站整体结构和设计原则的把握，相当重要。在讲到导航的时候，作者将网站的导航比作大卖场的标识。如何用最简单的方法，最快地引导用户找到自己需要的东西，是导航（标识）需要完成的工作。而搜索，就相当于去询问大卖场的工作人员。这个比喻非常贴切，我在实际设计茶品的过程中就一直问自己这个问题：用户能找到么？用户的流程顺利么？所谓以用户为中心，指的就是这样的思考方式。

（书评不能再这样写了。可是我实在没有时间再配图、分析案例或者抄书了……书里有很多精彩的案例和细节的考量，有兴趣的朋友自己去看吧。当然，也可以参考本博客的“UCD报告”分类文章，这个分类里记录了一些我对各类网站设计的简单分析，有好的，也有不好的。或许可供大家讨论。）

博客挑战赛系列索引：
给我投票
前一篇：电影《无间道》 前一篇同类主题：《公关第一广告第二》
后一篇：音乐《无间道》 后一篇同类主题：《引爆流行》

http://www.feedsky.com/challenge/art/137056/feedsky/puyuping/~/gtsp/zt2/d1828/lnk.html

【阅世书生原创·转载请注明出处】

昨天说了“活下来”的意义，大意是在目标既定的长期竞争中，胜利者不一定是取得最多胜利的人，而是输得最少、活到最后的那个人。那么如何活下来，就成了一个很重要的问题。就这一点，美国人一档叫做《幸存者游戏》（Survivors）的真人秀，或许有值得研究的地方。这个游戏的规则是，16人分成两组，与世隔绝的生活39天，每三天进行一场对抗赛，获胜的一组获得工具和物品，失败的一组每次失败淘汰一名选手，直到还剩8人，取消分组，继续淘汰，直到还剩最后一人，即可获得百万美金的奖励。
我们来看，在这样一个生存游戏中，团队如何自发淘汰成员？相信这不论对于职场生存还是行业竞争，都有可以借鉴的地方。

1，能力不够的（严重妨碍团队取得胜利）
第一轮比赛被淘汰的是一位磕伤了腿的63岁老人，不仅行动不便还需要别人照顾，导致小组首轮失利。
2，触犯众怒的
第二轮淘汰了一个自私自利的家伙，这人贪小便宜，说谎，让大家都不喜欢他。
3，诽谤他人的
第三轮的结果，是轰走了一个整日喋喋不休说别人坏话，觉得大家都应该被淘汰的人。
4，不合群的
第四轮，一个公开声称自己“不喜欢白人学校”，并且找借口不愿与小组其他成员沟通的黑人药剂师回家了。

综合前四轮，淘汰的人分别是：无法适应艰苦竞争的人，说谎的人，难以合作的人，及不愿充分沟通交流的人。这较好理解，在游戏初期，团队取得胜利，是确保没有人遭到淘汰的前提。所以无法协助团队取胜的人，自然会被淘汰。这就是团队的逻辑。这里值得注意的是，那些能力不强，但是愿意主动沟通交流的人，活下来了。团队的强势领袖，活下来了。他们代表了两种人：能力超强的领导者和团队合作的润滑剂。
简单总结：
在竞争人员较多，情况较复杂的情况下，团队的淘汰遵循团队的“集体逻辑”——团队需要什么样的人来取得胜利。所以领袖和润滑剂是最重要的人物。此时，团队合作能力是首要的。另外，一些基本的人品和素质也决定了你的去留。这个环境好比竞争激烈的职场，公司核心的地位一般比较稳固，团队中善于协调多方关系的人通常也不会在竞争中处于劣势。这就是为什么很多能力并不强的人能在职场中游刃有余——他们会在团队合作中进行沟通，也会在适当的时候“混版子”，他们能够帮助团队获得胜利从而保全自己，即便团队失败，他们也能用自己的形象和关系，凸显出团队中某些人的不合群。

接着两轮，淘汰了两个有能力的人。应该说，是他们的短板造成了他们被淘汰。他们中的一位有些坐享其成的意思，被团队成员投票淘汰，另一位虽然曾经是团队胜利的功臣，但是由于表现出对女性的不尊重，也被投票出局。
这两个人其实是有能力的，所以在初期，他们对团队是有用的，能帮助团队获胜，所以不可能被团队淘汰。但是当团队谋求进一步发展时，这些人性格上的不足就让他们成为了团队发展的绊脚石。所以一直到这个时候，淘汰，还在按照团队的逻辑进行着。
正是因为比赛到这时始终遵循团队的逻辑，所以一个31岁的黑人篮球教练虽然对团队毫无帮助，却一直留到现在。因为他总是对团队成员有求必应，甜言蜜语，让大家都挺喜欢他。出乎意料么，这样的人能在团队中稳固生存？其实并不奇怪，这些低调而懂得保护自己的人通常能比一些有着明显缺陷的人，活得更久一些。

所以，有三种人可以在团队逻辑的环境下活下来：
1，领袖——团队需要他来取得胜利。
2，润滑剂——团队需要他们来更好地协作，发挥集体的力量。
3，老好人——低调，善于与人相处。

团队的“集体逻辑”在团队一起“打江山”的时候有用，但是一旦团队瓦解，环境迫使参与者单兵作战，此时的竞争淘汰就开始遵循另一套逻辑了。
如果说团队的逻辑是打江山的逻辑，那么这另一套逻辑就是守江山的逻辑，其中包括了很多猜忌、防备、策略，甚至阴谋。
如果说团队的逻辑是个人在团队中如何生存，是职场生存的法则，那么这另一套逻辑，就是公司如何在竞争中活下来，是行业竞争的无情法则。

【阅世书生原创·转载请注明出处】
简单整理一下思路。项目管理分两种，一种是对单一项目的管理，一种是对多个项目的协调管理。
1，对单一项目的管理。
其实这是最基层的执行，就是所谓的“做事情”。执行的过程中需要做很多看似琐碎的决定，包括UI的设计，功能的实现，与技术人员和设计师的协调，从策划到设计再到测试的整个流程，以及对该项目时间的控制和管理等。
对单一项目的管理其实是把一个项目分拆成不同的阶段、步骤，做每一步的决定，完成每一步都要求。这个管理的过程是单线程的，顺着项目的策划思路走就可以了。这个过程中，利用文档或其他日程安排工具进行管理是很不错的。

2，对多个项目的管理。
通常我们所说的“项目管理”是这个层面的，即，同时有多个项目需要安排、协调，如何管理人力、资源和时间。所谓“管理”，通常是从这个层面开始的。这个过程中最主要的其实是对各个不同项目的时间和进度的掌握，做到心中有数，同时能够齐头并进。管理的级别越高，对单一项目管理的深度相对就会越浅，而对多个项目管理的广度就会越大。

看起来，对多个项目的管理似乎更有挑战，也更“高层”，其实并不尽然。
管理本身其实是一种“控制”，out of control就是管理失效的表现。所以如果管理者无法对单一项目进行有效管理，那就很难做到对多个项目有充分的掌握能力。管理者在很多时候是一个决策者（decision-maker），而决策的判断是需要知识和经验的，否则，即便能协调好各方关系，也无法真正掌握自己管理的项目。

由此想到两点：
1，挂职锻炼这种模式是必要的，从基层开始不断熟悉，的确对一个管理者很重要。所以一个真正的管理者视野要开阔，知识面要广。产品，营销，市场，资本，财务，甚至包括法务、技术、人事，都应该有所了解。

2，如果只会协调各方关系却没有踏踏实实、从细节上做过项目，那么下场很可能跟李鹏总理当年决定炸掉三峡一样。

【阅世书生原创·转载请注明出处】
挺早的时候（两个月前），千鸟发了一篇《用文档来推动产品》，正好是我们也在摸索产品流程的时候。过程中想来一些问题：究竟怎样的管理方式更有效？对于互联网产品这种较为特殊的项目而言，如何管理更有效？

先想到传统行业的大公司做法：Report制度。
项目部署之后，下级对上级的负责以及上级对下级工作进度的监督，都体现在每日的report制度上。下级的几乎所有工作都需要进行文档化的记录，然后用report的形式汇报给自己的直线经理（line manager）。比如，拿到项目之后，下级通过report汇报自己的思路，上级决定项目走向；碰到需要出差的情况，下级继续通过report阐述工作细节，如需要考察的内容等；出差之后，下级还是通过report汇报计划实施情况；平时的工作中，report更是不可缺少，内容包括制定计划、安排进度、汇报成果……所有report最终都被保存，备案，以求责任到人。整个项目在结束的时候，看到的就是厚厚一摞report。
其实，report制度就是一种依靠文档推动项目进程的机制。

这么做的优点是：
每个环节都很清晰，上级对下级工作进度的掌握很到位，分工明确责任到人，便于管理。
这么做的缺点是：
增加下级无谓的工作量，在方便管理的同时，影响下级员工的工作效率。可能导致机构臃肿，效率低下。

大公司采用这种规范化、程式化的管理方式，显然是从方便管理的角度考虑到，因为公司越大，效率就越体现在战略决策上，而非现实执行上。应该说，这是正确的体制选择。但是对于小公司而言，是否有必要照办report制度，完全依靠文档来推动产品？
个人认为这是一个权衡。对于规模有限的小公司，在牺牲下级员工的效率和增加上级管理成本之间，选择哪个？如果文档机制最后留下的那一摞report只是放在那里供人观瞻，那么在项目进行的过程中，消耗员工的效率去写这样的report是否有意义？而如果完全不依赖report制度，上级的管理是不是又显得力度不够，从而无法做到有效执行？

我的想法是这样的：
1，文档对推动项目（产品）和协助管理都是有用的，关键是怎么使用文档。
2，对小公司而言，文档在推动项目上的作用应该更侧重一些。项目的每个里程碑都应该有相应的文档作为对照，因为小公司的特点是，每个项目的影响都可能很重大，高层管理者对项目的影响很重大，导致项目的变数很多，需要依靠文档记录并推动。
3，上级有必要充分了解下级的工作进度以进行全面的项目管理，但是此种了解不一定要借助文档，可以采用其他方式进行。比如，通过项目管理来协调员工的时间和工作量，用项目来管人。
4，对下级而言，有必要充分了解项目整体进度，也有必要记录自己的工作进度，通过文档记录不失为一个不错的办法，这个文档不一定都要汇报给上级，但至少自己心里要有底。一个类似于“航海日志”的工作日志文档，或许是有价值的。

文档来管人，当然是一种有效的管理手段，但是小公司的优势就在于管理层次浅，系统灵活，所以在用文档推动项目和产品的时候，不能让文档影响了自己的灵活性。

文档机制应该是整个项目管理过程中的一环，或者说是一种手段。
采用哪种手段进行项目管理，就像谈恋爱一样，没有是最“好”的，只有最“合适”的。

回到上海的路上我差不多一直都在睡觉。两天两夜的行程太累了。
很难得如此放松地入睡，很难得如此忘记一切地疯玩。杀人，联欢，游山玩水。印象中，即便是我们最后的毕业游，也很难找到这样的恣意。
看着和我们一起肆无忌惮，笑得张牙舞爪的老总们，几乎感觉时空错乱。

谢谢朋友们，两天两夜的欢声笑语，让我彻底忘记了之前的压力或者紧张。
谢谢点评网，人数不多的团队里，竟能找到这么多和我有这么多共同点的朋友。
谢谢张总叶总和星汉，三轮面试之后，你们给了我加入这个团队的机会。
之后几天，会很忙。虽然这两天没碰一点工作，但我觉得思路很清晰。
之后几周，会很忙。等待上线的日子有太多事情需要计划、执行，我充满自信。
之后几个月，或许还会很忙。高速发展的未来需要我们不断的进取和努力。我满怀激情。

嗯。加油！明天会更好。

【阅世书生原创·转载请注明出处】
写一个很简单的UCD报告。参考对象是三家不错的2.0网站：土豆，豆瓣和饭否。主题是：某个条目没有内容，怎么处理？
所谓条目没有内容，是指注册之后，没有添加任何人为好友、没有添加任何主体内容（如视频、书评），或者没有加入任何小组，这些条目（好友、豆单、小组）该如何显示？

有必要先明确，条目没有内容一般发生在什么情况下，此时用户希望获得怎样的体验？

最常出现无内容的情况就是新注册的用户。这段时间很重要。如果使用过程顺利，那至少在第一步上留住了用户；如果过程遭遇挫折，很可能你就永远失去了这个用户。
那么此时用户的体验是什么呢？应该是：我注册成功之后能获得什么？（信息），能做什么？（分享），能体现什么？（获得认可）。这时候，用户还希望知道：哪些地方是我可以进去的，哪些东西可能是一个“开关”，以后我一直要用到，哪些地方能展现我的分享内容，等等。
综上，对条目没有内容的设计，应该重在引导。引导用户顺利地了解和使用网站，成功地看到自己分享的内容，从而在网站上获得认可。而引导应该分为两步：1，告知没有内容，2，提示如何操作。

饭否做到了第一步：

明确地显示，好友=0，关注者=0，“我目前没有好友”，但是新用户到这一步就手足无措了：我没有好友，但是我想添加好友，怎么办？没有进一步的链接，只能返回我的空间，而此时“我的空间”页面也是一片空空如也，半个人影都找不到：

不过，这也比豆瓣的好友系统（友邻）要好一些：

真是白茫茫一片大地好干净。左边主体居然是一片惊人的空白，而右边的东西又是标准的懒婆娘的裹脚布！
1，2，3，都不能点击。虽然都在告诉我，豆瓣能做什么，但是对一个新用户而言，这有什么用？至于4，就更可笑了，我还是个新来的，谁会加我为好友？右侧的东西这么多，拖得这么长，左边的空白是要留着干嘛？告诉用户我这里一穷二白？我问了三个人，他们都以为这个页面没有刷出来。我最早注册使用的时候，就不明白一点：人呢？怎么没人用豆瓣？
豆瓣的“我的主页”在没有内容的时候，也相当搞笑：

还是没有地方可以点击引导我做下一步。还是在不停地告诉我能做什么，结果我在这个页面上还是什么都做不了，我想出去找事做，结果你还不给我链接。我就在刚才截图的时候还足足点了5下那个红色的“发表评论”，结果什么都没有发生。我真的觉得自己被豆瓣耍了。

相比之下，土豆就算是很好的了：

没有搞错。我没有添加过任何好友。这个“celia在土豆”，是系统在我好友数为零的时候，自动默认给我的。这种做法的确流氓了一些，但是至少给了我一点安慰，也让我知道，原来我可以添加好友，而且通过点击这个人，我可以比较流畅地开始使用土豆了：看她的节目，看她的好友……土豆把我留住了。

而土豆的主体内容部分也相对人性化一些：

没有博客，他提示我去写博客，点一下就到了写日记的页面，多好，很可能我随手几个字，至少试用一下，看看出来是什么效果。而且，这个“我的日记”模块不是打开页面就出现的，设计了几秒钟的延迟，更容易引起用户注意。多好的细节设计！

今天我还说自己喜欢豆瓣——我声明，我只是喜欢豆瓣的气质和内容，和这个网站的设计无关。 我不喜欢土豆的内容，但是不得不说，土豆的很多东西做得是不错的。而饭否，看起来是过于简单了一些。

【阅世书生转载并笔记·《铸造团队的执行力》片段·2007-10-10·横戈】
真正的执行者应该是管理者

“美国ABB公司董事长巴尼维克曾说过：“一位管理者的成功，5％在战略，95％在执行。”管理者的执行力如果不到位，管理思想与指导方法没有运用于实际的管理要求中，就会使下属工作人员不能认真的对待和落实执行目标与工作方案。下级完成上级制定的目标和计划是执行；而上级明了下级如何去具体实施才能实现目标更是执行。因此，真正的执行者应该是高中层管理者。
“在企业管理中，就是很多人想当然地认为企业执行力不强是下属没有按照上级的意志去落实，像大多数管理者认为的那样，是“别人没有按照自己的想法去做事”， 其实这是一个误区。执行是一个管理过程，在整个过程中，员工主要是实施，而管理者却要关注全过程。因此，在执行的过程中，管理者的作用更大，管理者不仅要 告诉员工完成某项任务的标准和时间，还要在执行过程中进行检查和协助，同时还必须保证有最合适的员工去完成该项任务。”

上次一篇《公司决策模型》讲到了战略和决策。今天引用这段很有趣的文章，是想讲讲执行力。
执行力这个词，长久以来一直被我们误会着。大部分时候，我们中的大部分人会认为，执行力是底层员工的事，就如那本书的名字：《执行——如何完成任务的学问》。但是，任务也分成两种。一种是别人交给你的，一种是自己要求自己的。
前一种，就是老板交给员工任务，员工执行老板的部署。毫无疑问，这是传统意义上的“执行力”——员工能否执行（完成）老板交予的任务。
后一种，其实也不复杂，只是把老板换成自己。自己交给自己一个任务，然后完成它。企业的中高层管理者就处于这样的地位。他们自己制定决策，部署给下属，并且通过下属完成实现决策。这，也是“执行力”。第一种执行是字面意义上很直观的执行，后一种执行则包含更多内容：协调、管理其他人一起完成任务。

所以对执行力，要做广义上的理解。做事是执行，管理时间和人手，带领Team来做事，更是执行。（这个执行的概念类似于“项目管理”）所以对一个管理者而言，制定战略只是很小的一环，重要的是，如何团结下属，如何带领团队，“从一个胜利走向另一个胜利”。这一切，都是“执行力”。

所以很多时候，能不能做成一件事，往往取决于管理者，有没有能力带领团队共同完成目标，换句话说——有没有执行力。

【阅世书生原创·转载请注明出处】

小公司的一个好处就是可以学习到公司管理的流程，比如可以看到决策的产生与相应的责任。而在大公司等级森严的每日Report体制中，处于最底层的员工及Band One Manager很难有全局性的管理视角。

前段时间公司做了一次简短的BI（Business Intellegence）培训，BI的问题这里不谈。这里从架构师提到的公司决策模型说起。
公司结构通常为金字塔形，处于顶端的是公司高层管理者，通常他们做出的决策是战略层面的，对公司发展影响重大，而这样的决策一般数量较少，重要度较高，做出决策的成本、风险和收益都是最高的。一旦决策失误可能满盘皆输，所以每个决策都很慎重，需要更全面的行业资料和经验。
中层管理者一般做出的决策是战术层面的，他们通常管理具体的项目，分配人员、时间和其他资源，完成战术性的部署，他们的决策通常数量适中，重要度一般，决策的成本、风险和收益都处于中游水平，更高层次的管理者将在一定程度上为中层管理者的决策成本、风险和收益买单。中层管理者需要更多的是项目管理方面的经验。
公司底层的员工是在公司里需要做出决策数量最多，但是对公司影响最小的人。他们处于执行层面，每天有很多小决策需要他们进行判断，这些决策是战役性的。决策的重要度较低，决策的成本、风险和收益都较低，中层管理人员将通过项目管理的安排承担成本和风险。

简单说，在公司体制中，通常越往高层，需要做出决策的数量越少，重要性越高，风险越大，责任越重。

本来培训过了也就忘了。几天前在方军商业日志里看到一篇文章《别让猴子跳回背上》，就勾起了关于上述决策与责任的记忆。
猴子，就是指工作中各类低层决策，每天都有很多。别让猴子跳回背上，说的就是管理者要学会让自己摆脱那些长期以来困扰自己的低层决策，对中层管理者而言，要摆脱战役性决策，对高层管理者而言，要摆脱战术性决策，从而让自己站得更高，看得更远，担负更重大的责任。所谓的“管理者不要万事亲历亲为”就是这个意思。

其实打工者和老板之间的差别，不在于你是否真正拥有一家公司，而在于你用什么样的心态去工作。
如果你永远只听命于自己的上司，没有主动参与公司决策，永远在用战术性甚至战役性的眼光对待自己的工作，那么你和一个熟练工就没有什么区别，永远只能为别人打工。
如果你能够让自己站到一定高度上看到公司运作和发展，在完成本份工作的同时尝试着锻炼战略眼光，那你就拥有了老板的心态。
当然，战略和执行的关系是相辅相成的。所谓战略，其实在很多时候也是一种执行力，只是战略的执行力不通过自己实现。这是另外的问题了。我们下次再说。

【阅世书生原创·转载请注明出处】

这本是一篇可有可无的文章。缘起是今天早上惊闻莱库宁今年F1封王，汉密尔顿继“推车”之后失蹄，阿隆索也只能黯然离开。 之所以想写两句是因为按决战之前的形势，莱库宁要封王，几乎是Mission Impossible，但最终却乱中取胜，很值得学习。

1. 背景1：迈凯轮内部失和。
   小汉和阿隆索的队内竞争已经导致了车队失和，两人的争宠给迈凯轮带来的不是有序的竞争而是一片混战。之前已经出现过阿隆索和小汉置车队利益于不顾，两辆银箭在场上你死我活的情景。没想到，巴西决战，内斗的场面重现。这次又是阿隆索挤住小汉，小汉错过刹车点。
2. 背景2：法拉利蓄势待发。
   莱库宁和马萨的地位很清楚，日子也都过得不错。决战当晚马萨抛却个人利益，一心辅佐芬兰冰人，先压住小汉，再档掉阿隆索，最后通过进站策略巧妙放行，自己在后掩护，收官战自己拿个亚军，确保队友封王。这就是，团结的力量。
3. 引申1：统一的目标很重要。
   法拉利最后一站的目标很明确：协助莱库宁封王，任务安排也很清晰：莱库宁只顾自己夺冠，马萨负责左扑右挡，确保阿隆索在第三名之后，同时确保小汉不进前五。换句话说，就是要废掉小汉，再挡住阿隆索。马萨此战的责任比莱库宁更重，并且，马萨做这些，只是在“为他人做嫁衣裳”。
4. 引申2：执行力！
   本站小汉只需确保自己进入前五，就可夺冠，阿隆索要自己夺冠并且指望小汉拿不到前五才能夺冠。按说今年迈凯轮损失惨重，阿隆索理应顾全大局，此等局面下配合小汉先拿下，至少先抵御了外敌，内部的问题可以慢慢解决。可是阿隆索的选择却非常“中国人”，他挤掉了小汉，试图自己夺冠，却在这个过程中被莱库宁赚了便宜。
5. 引申3：团队合作。
   如果最后一站小汉和阿隆索能够稍稍发挥一些团队精神，阿隆索没有挤掉小汉，那至少小汉保住了前五，车手冠军还是留在了迈凯轮，兴许大家一高兴，皇帝轮流做，明年小汉也配合一把阿隆索，弄个冠军玩玩。可是显然阿隆索是不服气的，咬死了“我拿不到也不让你拿到”，结果两败俱伤。试想，如果两人昨天配合默契，阿隆索多和马萨纠缠，或者两人合力搞定马萨，那即便莱库宁夺冠，也不至于拿走总冠军，即便明年散伙，也至少是好聚好散，买卖不成，仁义在。
6. 引申4：除了1对1的单挑，这个世界已经离不开团队合作了。
   优秀的配合加上取长补短的合作，才能让团队的1+1>2，才能创造出卓越的战斗力。
7. 引申5：团队合作可能造成某个团队成员在短期的获利减少，责任增加，比如马萨，但是只要合作成功，团队整体的获利大幅上升，则该成员的总体获利水平相对于其他失败团队，还是增加的。我相信现在大部分车队都不敢要阿隆索。
   至于在团队内部，如果本身就有优劣，那主次非常分明，如果主次不分明，则需要相互之间能够妥协和谅解，能够在必要的时候为对方做出牺牲。
8. 显然，迈凯轮只是买了两个牛人，却没有协调好两个人之间的关系。光让两个年轻人放手竞争，肯定是要付学费的。就像练武功，迈凯轮今年算是练了两套相生相克的功夫，到头来，还是打不过法拉利。
9. 所以功夫不再有多强，而在于有多适合自己，能融合到何种程度。团队成员也不在于单个有多牛，而在于合在一起，能不能迸发出强劲的战斗力。当一个团队一起在执行某个任务时，团队里的个人，要忘记自己——你不是一个人在战斗。

组建团队者，当2007赛季的迈凯轮以此为鉴。