LiuCHN®的博客：⌈思考、自由、启蒙、创业⌋，IT技术只是业余

曾经有个小国的人到中国来，进贡了三个一模一样的金人，把皇帝高兴坏了。可是这小国的人不厚道，同时出一道题目：这三个金人哪个最有价值？皇帝想了许多办法，请来珠宝匠检查，称重量，看做工，都是一模一样的。



怎么办？使者还等着回去汇报呢。泱泱大国，不会连这个小事都不懂吧？最后，有一位退位的老大臣说他有办法。皇帝将使者请到大殿，老臣胸有成足地拿着三根稻草，插入第一个金人的耳朵里，这稻草从另一边耳朵出来了。第二个金人的稻草从嘴巴里直接掉出来，而第三个金人，稻草进去后掉进了肚子，什么响动也没有。老臣说：第三个金人最有价值！使者默默无语，答案正确。



这个故事告诉我们，最有价值的人，不一定是最能说的人。老天给我们两只耳朵一个嘴巴，本来就是让我们多听少说的。善于倾听，才是成熟的人最基本的素质。



理解和感悟



一般人在交谈中，倾向于以自己的意见、观点、感情来影响别人，因而往往谈个不停，似乎非如此无法达到交谈的目的。实际上，与人交谈，光做一个好的演说者不一定成功，还须做一个好的听众。外国曾有谚语说“用十秒钟的时间讲，用十分钟的时间听”。而在人们面对面的交谈中，讲与听是对立统一的，认真地去听，可以收到良好的谈话效果。只有善于聆听的人，才懂得“三人行，必有我师”的道理，才能够利用一切机会博采众长，丰富自己，而且能够留给别人讲礼貌的良好印象。



因为听，同样可以满足对方的需要。认真聆听对方的谈话，是对讲话者的一种尊重，在一定程度上可以满足对方的需要，同时可以使人们的交往、交谈更有效，彼此之间的关系更融洽。能够耐心地倾听对方的谈话，等于告诉对方“你是一个值得我倾听你讲话的人”，这样在无形中就能提高对方的自尊心，加深彼此的感情。反之，对方还没有把将要说的话说完，你就听不下去了，这最容易使对方自尊心受挫。



与此同时，听还可以了解对方是否真正理解你刚才所说的话的含义。听，可以获得必要的信息。注意聆听别人的讲话，从他说话的内容、声调、神态，可以从中了解对方的需要、态度、期望和性格，他们会自然地向你靠近。注意倾听别人讲话，还可以同时思考自己所要说的话，整理自己的思想，寻找恰当的词句，以完善地表达自己的意见，给人鲜明的印象。



管理者需要倾听




在成功企业中,最重要的就是沟通,一个出色的管理者，必须让员工和自己之间畅通无阻的交流，而沟通从倾听开始


理解是人人都需要的，不只是被理解，还要去理解别人。沟通是相互理解的方式，而沟通又始于倾听，人际沟通的成败往往是由倾听是否有效决定的。



后退一步轻倾听他人说话的能力是每个成功认识的标志，管理工作的特点决定了倾听的特殊意义，正确的决策总是收到环境的影响，入竞争、多边、和整体环境，使个人无法确保自己做出的判断是否正确，不用雄辩的对话，也不用深刻的谈吐，朴质物化的倾听就足以让管理者受益，如果管理者擅长倾听，就可以从客户、同事和上下级处获得他们想要的信息，再对其进行分析、思考和评估。


1、倾听可以解除下属的戒心
2、使员工的自尊心得到满足 ，如遇知音，提高下属的自信心
3、可以及时发现员工的长处 ，并创造条件让其发挥
4、最精明的投资 是没有成本的，而倾听就完全符合，它几乎无须付出代价





倾听的技巧经验分享 ：


1、专注。 就是全神贯注，聆听的时候不要插嘴，尽量把你的语言减到最少，因为说话和聆听是不能同时进行的



2．建立协调关系 。了解对方，试着由他的角度看问题。这是提高聆听技巧的主要方法之一。


3、用心倾听。 面对他，轻松自如的和对方保持良好的目光接触，目光接触的另一个含义是 “我正在听你讲话”


4、停顿。 当对方讲完话后，你要静静的等待三五秒后再讲，这样一方面可以避免打断他人说话的风险（对方可能只是停下来整理思路），另一方面则是告诉对方，他说的话值得思考一番，因为你认为很重要



5、不要做出分心的举动和手势 。尽量避免做出让人感觉你的思想在游走的举动，这样说话者就知道你确实是在认真地倾听。在倾听时，不要进行下面举动：一直看表，心不在焉地乱翻档案，随手拿笔乱写乱画，这些举动会让说话者感到你很厌烦，对话题不感兴趣，更重要的是，这表明了你并没有集中注意力，因此很可能会漏掉说话者传达的一些有效的信息。



6、不要立即下判断 。人们常会在一件事情还没有搞清楚之前就下了结论，所以要保留对对手的很多判断，直到事实清楚、证据确凿。注意自己的偏见，即使是思想最无偏见的人也不免心存偏见。诚实地面对、承认自己的偏见，并且聆听对手的观点，容忍对方的偏见。


7、反馈。 用你自己的话重新复述对方刚刚说过的话，可以这样说：“你的意思是... ...” 这表名你刚在在心无旁骛的倾听他说的话，同时，也能确认自己是否已经正确理解了对方表达的意思。
 

一.Everybody can say no , someone can say yes !

很多创业团队，在创业的过程中，很多优秀的成员，他们个个都有自己的独立的观点。每当遇到事情，大家都是采用讨论的方式解决，可讨论了很久，就是没结果！这样很浪费时间，不仅浪费了团队的时间，也浪费了项目的时间。俗话说时间就是生命，效率就是金钱。一个优秀的团队，不但每个人要有超强的执行能力，每个优秀的队员的配合都要搭配得当。否则团队的失败就是创业的失败。个人觉得创业团队的，每个人都有发言的权利，绝不是虚民主，每个人都可以激烈而又准确的阐述自己的观点，就是每个人都可以 say no ，但是每个领域一定要有一个优秀的做最后的决定人。你们所有的观点都可以发表，但是最后的决定一定是一个统一的观点。比如：技术方面，得有一个服众的人即说话算数的Leader（如：技术总监），他决定所有的技术方向。产品方面，也一定得有一个Leader（如：产品经理）能做最后的决断，统一观点，避免思想分裂。而整个团队或者公司都必须有一控制整体大局的Leader（如：CEO），他来控制整个团队/公司的发展，前景的规划等宏观调控。

二.有能力人不一定能共事，能共事的人在某方面一定有相同的观点。

既然能组建团队，那么都是有志之士，或者牛逼的能人走到了一起，他们或许在某方面的观点产生了共鸣而走到了一起。如果他们个个都是牛人，个个都互不让步，坚持自我，没有一个统一的中心，一切都是白搭，做任何事根本没有效率，因为都是一直在争执某些本可以轻松解决的问题。所以有能力的人不一定你就能用好。关键是合不合适这个职位，不合适就不能共事了。但是能和你一起共事的人，他们懂得观点的取舍，互相的认可，互相的统一，这样的人一定能一起走的很远，很有可能成就大事。

三.中国未来10年，不缺投资人，缺的是愿意一起亲身投入到创业中的人。

中国的发展很快，未来富翁也越来越多。都有钱了，都想搞投资了。但是我们出来独到而明锐的眼光之外，我们还有能力参与到创业中去，这才是真正的创业，并享受创业过程的艰辛和快乐，享受创业充满神奇的旅程给你带来前所未有的快感！

http://www.yoyiorlee.com/archives/12.html
在上一篇（创业团队的那些事（一））从邮件中看到很多博友的评论，很行赏他们的观点，关于创业团队，我们都有说不完的理论，想不完的创意，干不完的事情，永远无法预知的结果，只知道我们这样做是目前最好的做法。每个互联网工作者都想在互联网这五线谱上弹出属于自己的的旋律。这年代，大街小巷都是两个字的声音：“创业”。我一直认为一个企业/公司想做好做大，那么团队是永远不能忽视的，因为团队就像是一个人的大脑，没有大脑的工作都是零散的，优秀的团队，才有优秀的产品，才有优秀的企业。

一.我们不是神，我们是人。

如果是一个0起步的团队创业，那么最基本的应该是保证团队自身都能够生存的基础上，才会去想创业。记得以前大一的时候一数学老师说：离散数学就是一群吃饱饭、穿暖了衣、也没得事干的人去研究的一门学科。当是听着觉得好笑，可后来仔细一想，这位老教授说得是那么的实在，那么的深刻。

创业的过程中我们也会犯错，或许在某个阶段我们都作出了错误的判断，导致不可想象的的结果，只要我们能吸取经验，及时改正，善莫大焉。创业肯定有失败，失败不只是结果的失败，更多的是细节的失败，才导致结果的失败。有句话：失败是成功的之母。

二.一定要脚踏实地。

不能老是变得飘飘然，理想主义。我想做这个，想做那个，想这么做，那么做，都只是嘴上一说，二天早上一起来，地球照样转，话照样没有说。做一个‘愚者’，笃信你一定会成功。在初期，我们只有默默不语，踏踏实实做好自己的产品，整好自己的团队。我相信，天道酬勤，付出了，你一定有收获，虽然你没有收获结果，但是你收获了过程，收获了教训，收获了经验。所以只有我们发现一脚踩下去是泥土才放心，如果是云朵，你心里肯定担心。

三.成功唯一可以复制的就是“吃苦和耐力”。

创业意味着：愿意吃苦、敢吃苦、喜欢吃苦、爱吃苦、嫁给吃苦…、享受创业带来的快乐、分享吃苦精神。记得曾经有一篇文章讲：去创业就等于你接受了1000份工作。的确有道理，因为开始的的时候你只有思想，也许你只对某一个角色熟悉或者精通，但是不一定每个角色都那么厉害，你要充当：管理者，激励者，销售员，设计者，开发者，网络管理员，公关经理等等。Mark Suster有个比喻很恰当：创业就像生产，9个女人一起使劲也无法生出一个孩子来。虽然荒唐，确实比喻恰当。创业是有一个“怀孕”的过程，这个过程的好坏就决定你创业是否成功，创业也需要一个酝酿的阶段，心急吃不了热豆腐嘛。互联网有很多牛逼的人士，也许他们的任一言谈都会引起共鸣，但是那只是属于他们的历史，我们听的只是他某个领域的一种意见，而真正我们做的时候还是要考虑到自身团队/企业的情况，有自身特色的创业才能有立足之地。

四.创业无论如何都离不开这三个要素：产品，管理，市场。

互联网创业看中是产品，没有产品，你再多的话都是白谈，谁都不会相信你的幌子。哪怕是理念，都有一个DEMO。有了好的团队，第一个就是产品，我们以一般都说让事实说话，其实就是让产品说话。产品的成败，就是团队的成败。因为产品的特点就是你团队的特点，如果你的产品失败了，那么说明你的团队也失败了，说明的团队还有问题，必须改进。不然怎么会失败？有了好产品，你自然会去管理好你的产品，那么产品面对的就是市场，他必须去拓宽他的市场，一切都顺气自然的处理。这样创业也许是比较合理的，但也不排除其他的偶然性。

五.创业团队也应该用到（俞永福提到的）管理层三要素：建班子，定战略，带队伍。

在今天这个互联网横行的时代，互联网创业，单打独斗肯定不行，一定是一群人斗一群人。想自己这一群人战胜其他的人，那么首先应该是自己的团队相对稳定，团结的力量无穷尽。

1.建班子。如果是一个人创业，很有可能成为一言堂。两个人创业容易引起两边摆，谁也不吃谁的，最后不欢而散。而最稳定的应该是3个人创业，三角形原理，三角形最稳定。如果两个人意见不合那么可以再听听第三个人的意见，如果第三个人的意见与其中一个相合，那么另一个就会考虑自己的理解是否有问题，发现问题自我检讨，这样很容易解决内部问题。

2.定战略。互联网更新速度快，所以互联网创业肯定不是找今天的机会，一定是找3年后的机会。也可以用一个简单的比喻:没有人再中午12点种树。树的生长需要合适的温度，合适的条件。今天每个人都在找机会，那人人都说的机会绝对不是创业这的机会。

3.带队伍。带队伍感觉就像带自己的影子，领头人是什么样的性格，那么团队就是什么样的性格。假如你是一个心胸大度的一个人，那么你带领的团队也会成为心胸大度的人。如果你是一个守时的，那所有人都会变得很守时，耳濡目染，你在什么样的环境下成长，就能成为什么样的人，如孟母三迁的故事。

在互联网，‘建班子’应该在‘定战略’前面，因为互联网产品比管理重要，团队比项目重要。

这是关于一个项目的故事，与其它项目相比，既不非常复杂，也不是很简单： 一个应用程序与数据库以及其它两个系统通信。这在技术和架构角度都是主流，而在管理角度则是标准情况： 所有工作都应该在昨天完成，但还有很多没有完成的。简而言之，“这很难！” （这是开发者经常表达的一种情绪，但是谁都不会太大声地把它喊出来。）
 
为此我们创建了团队。雇佣了四十位员工并指定了他们的角色。我们把团队分为小组，并在不同的小组之间设置了一种契约。每个小组负责应对特定类型的要求。这样就形成了要求的流程。指定的小组会承受很大压力，并成为瓶颈： 在上游小组中会创建要求，而下游的小组会等待这些要求。对于那些有压力的小组中的要求，重要的事情会变为紧急的事情。我们必须在紧急的事情之中做出选择，以解决最亟待解决的问题。我们经常需要在任务之间切换，最终，这导致流程变得很慢。 然后发布的最终日期临近了： 就在两个月之后。用户接受测试刚刚开始，但是不同组件之间冗长而痛苦的整合过程导致了测试的延迟。可能正是在团队之间创建的契约让整合变得如此复杂： 其中缺少一些必须的参数，日期格式不合适，只有部分错误代码能够得到解释……
在任何情况下，用户接受测试都会检测出很多的bug，而开发团队来不及解决，这样就无法对系统进行彻底的测试。
因此我们增加了更多人力。我们设置专门的团队来解决bug，在另一个地方的团队会完成开发，还有一个团队会整合不同的组件。但所有这些团队共享同样的代码，对某些代码做出的改变会影响其他团队所做出的修正。
接下来我们可以预测出这样的做法导致的结果： 开发者通宵加班，周末也要工作；最终日期被一再推迟，最初的工作任务范围发生了变更（减少了内容）；然而，多亏了计算机科学的奇迹，应用程序最终发布并运行了！

这是多年以前的事儿了。我认为这是“要走的路”，并且所有项目都以相同的方式管理。从那开始，我经历了各种不同的情况，读了很多资料，并与很多人做过相关的讨论。现在我能够从不同的思想角度来看待这个故事。
 创建IT系统是一种非常复杂的机制，其中不仅混合了技术、架构技能，还有管理以及与人相关的技能。在这两个领域有多种文化，但是关于构架系统的管理和人的部分，我认为Tom De Marco是我最喜欢的作者之一。我还记得他出版的两本书。在第一篇无标题的“软件工程： 关于谁的时代来临和消失的想法”中，De Marco讨论了对软件项目的控制（的幻想）。在第二篇“放松（Slack）”中，De Marco研究了管理学中的经典问题，并说明更多的放松能够如何帮助组织具有更强的适应性，最终获得更高的效率。
 但是，带着这两篇文章中的想法，让我们回到故事中，看看如何才能避免很多典型的问题。
 
没有优先级，或者是著名的“我们全都需要”
 Tom Demarco向我们展示了一种方法来避免整体上陷入困境，也就是“每项功能都非常重要”的项目：
 例如，你和团队的领导说，我时刻记着完成时间，但是我不会与你分享这个信息。当有一天我告诉你项目会在一周内完成时，你需要准备好打包，并把你所得到的东西作为最终产品发布。你的工作就是持续地为项目工作，按照相对值的顺序向其中添加内容，并在过程中持续地完成集成、编写文档以及验收测试工作。
 
简言之： 工作的目的是第二天就可以发布
 如果不考虑实际的组织和技术上的问题，你需要有意识地对软件进行持续构建。团队之间的合同责任很有限，从而无法在技术上或者任务上组织它们，而只能在业务特性上做到这一点。从技术的角度，每个团队都是这样，要负责让完整的功能可以很好地运行。从管理的角度，经理和业务人员需要作出选择： 什么是必须需要的特性。根据我自己的经验，你在需要符合交付日期的环境中工作的时间越长，这种特性团队和组织就会对你起到更大的帮助。
 
管理压力和恐惧文化
 我们在这里还要看看De Marco关于恐惧文化和它的特征是怎么说的：
 “……在具有恐惧文化的组织中，会具有如下特征：
 ■说特定的问题是不安全的（例如，我很怀疑是否能够达到这个限额）。
 ■目标设定得非常高，看起来没有完成的可能。
 ■允许权利超越一般的常识……”
 当我想到恐惧管理的时候，就会想象到一种专横的身体语言，他会在位置上对协作者大喊大叫，会用拳头敲桌子……这是非常具有讽刺意义的样子。这看起来像是在背后说人坏话，但是我们不得不承认，人们经常会处于这样的压力之下，难于提出警告，设定截止日期而不考虑团队是否能够承受，最终，团队会处于经理根据他们自己的地位所做出的提交压力之下。
 当然，了解问题只是第一步。我们怎么才能解决呢？ 当经理不了解风险所在，并且拒绝接受那些不可规避的风险，我们应该怎么办呢： 你需要选择，按优先级排序，并协商范围，以确保截止期限，或者把它延后。
 这个任务绝对不是个简单的任务，我现在所能够给出的最佳答案就是backlog和燃尽图的组合。依我所见，在以下各种情况下，这会有些好处：
 1.把所有任务集合在一起（技术上的、功能上的任务等等）。当然，我们可以通过用例或者特性来组织和统一这些任务。
 2.把任务与所有项目参与者共享。换句话说，让更多人知道哪些工作是必须要完成的。
 3.显示出信心，并制定切实可行的截止日期，从而让项目经理可以有效地排定任务的优先级。
 4.显示所有添加的任务，那可能会推迟最初制定的截止日期。
 
在上线前的几周，当前组织的压力比较大，因此我们决定要增加人手
 Brook在1975（我还没有出生）年声明了一条规则：
 “向已经延迟了的软件项目中添加人手，只会使其延迟更严重。”
 我们都已经对此深有体会。但是我们不得不承认，一般我们还是想要通过增加人力来保证在截止日期之前发布，而不是改变最初定义的范围，并保持最优化和合适的团队规模。Brooks对他的规则做出解释，其中有两个主要的观点。 第一点关注于新的团队成员，我们需要对他们进行培训，那会耗费现有人员的工作时间。第二点是一个“神话”，让我们相信开发任务可以任意分解，而不需要考虑工作中很多部分都需要智慧，并且还需要所有开发者之间必要的沟通。此外，我们还能发现更多与组织开发相关的困难，并且需要在所有开发人员之间共享同样的代码。这么多的细节会降低团队的生产力。
 Tom de Marco为我们做出了他对Brooks的规则的理解，他称之为“人浮于事（overstaffing）”。
 “按时完成并非是最重要的。重要的是看起来你已经做出最大的努力来按时完成。在这个“吃得少跑得快”的时候，对于你来说，使用少数（优化的）人员来运转项目是很不安全的。”
 请再次读一下，这次慢一些。你不认为这是一种很有趣的观点吗？ De Marco所建议的，或者说我的理解是，我们之所以不增加人力，是因为我们认为那会更快更好地完成工作。我们添加人力只是作为一旦失败时的借口。就像小孩子喜欢说的：“ 那不是我的错，我已经尽力了。”
 这是多么自然的反应啊！ 想要改变这种行为，首先需要改变我们的教育方式（并学着从失败和错误中吸取教训），并且组建一些组织，让失败成为其中的一种选择（当然不要太多）……
 
“一切都一直在失败”。你为什么不积极处理，而只是忽略它呢？
 和通常情况一样，批评很容易，而艺术地处理则很难。那样，我们会注意到相同的错误一次又一次发生，而很少试一下其他方法（当然，这些方法也会存在其他限制）。“风险管理是为失败做计划的方法”（Slack, Tom de Marco)，并且这可能正是我们擅长之处。Werner Vogels说过：“一切都一直在失败”。
 他们所要表述的是： 我们很难避免失败。就像往山上滚石头的人一样，如果想要爬得更高，走得更远，就必须接受石头会落下的事实，那是通往成功的必经之路。所以拥抱它、处理它，并从中学习吧。
 Tom De Marco告诉我们，想要管理风险，首先需要把它们识别出来，然后对其进行监控，设置指示器，当失败发生的时候会为我们提出警告。有时，我们需要找到其他方法。有些人需要培训。我们会开发软件的并行版本，这样，在做决定的最后时刻，我们就能够选择最适合的解决方案（精益管理把这叫做“基于设计设置（set based design）”原则）。
 但是风险管理不仅仅是计划。从架构的角度来看，风险管理当然还意味着可依赖性的管理： 从灾难中恢复……但这种风险管理的方法意味着要为我们的系统制定架构——与业务部门的人员紧密合作——从而管理并拥抱所有这些错误。换句话说，就是尽可能地预测我们架构中可能发生的错误情况：
 ■如何管理一种降级的模式，从而在整个系统的某个部分不可用，或者访问者的数量超出预期时让系统仍然可用？
 ■在发生错误的时候，需要执行哪些过程（如果需要手工过程的话）来终止业务处理？
 ■想要完成业务处理，需要哪些命令信息？
 ■警告机制是什么样的，从而可以根据最终用户的需要提前激活，通知他发生了错误，并帮助他恰当地终止正在处理的工作。
 ■…
 在现存的系统中，我们需要让它发展（而不是变革），从而确保这些已经检测出来的错误情况都被彻底修正。
 但让我们现实一些。如果你是成本驱动的，那么你会发现所有非业务的需求都没有用。但是，最终我们对于应用程序的信心不正是就它管理错误的能力（弹性和可靠性）吗？绝对不是其它标准吗。
 
结论： 那又怎么样呢？
 还有另外一个故事，属于另一个项目，既不非常复杂，也不是很简单。和其它所有项目的情况一样，其中有很多需要做的工作。开始时，IT和市场团队一起定义了清晰的路线图。
 ■“我们希望在四个月内发布新平台，其中会实现最简化的市场特性。对于访问量，我们期望每小时会有3000次，而80%的访问者会使用新特性。”这是市场团队所说的。
 ■“OK。”CTO说。“我们需要添加一些非功能性的特性来限制对平台的访问，以防我们的预测出现错误。在这些额外的特性中也会有一些技术风险，我们需要尽快确认。可能我们需要在下一次发布中看是否能够完成这些内容。”
 ■“没问题。尽快告诉我们关于这些风险的信息。在接下来的月份中，我们就会需要这些新特性……”
 ■- …
 随着特性团队负责实现完整的用户故事、修正bug并部署他们的代码，平台变得越来越大。
 当然，IT也遇到了技术问题。业务和IT部门需要一起来对路线图进行修正。最后期限已经到了，而有些特性被推迟实现了。那些都是优先级最低的特性。
 当然，市场预测也不怎么好。CTO向平台添加的非功能特性（例如，记录所有用户行为的日志，或者当达到已知平台限制的时候限制访问）在发布平台的过程中非常有用，帮助市场团队改进了预测。用户愿意使用这个新平台，并且信任它。
 在开放的空间中，墙上也充满了信息。燃尽图和累计流程图显示了团队的速度和问题，以及下次发布的目标……
 在这个项目中，还雇佣了一位技术专家： 那是CTO不想放过的机会。
 不管怎样，项目进行良好，并且还在运行中。技术人员们对自己所做的工作感到自豪……
 查看英文原文：The Story of a Project

本文来自:http://crazycoder.cn/ProjectManagement/Article173405.html