在外包公司工作，会不会毁掉一个程序员的三观（代码观、职业观、生活观）？
10:09:13 +08:00 · 8367 次点击
最近有些周围的朋友、同学去了外包公司，感觉各种观念已和我已有很大不同。比如，前端工程师的工作应不应该包括切图，程序员大学里的知识储备（如数据结构、操作系统、计算机网络）重不重要，关系型数据库的知识是不是一个 SQL 就能概括，多人协作时的代码规范、ORM重不重要，工作了之后还应不应该坚持每天学习 等等 ……
你们周围有没有被外包公司“洗脑”的朋友？
27 回复 &| &直到
10:17:18 +08:00
& & 10:23:33 +08:00
是洗脑了，是你被学校洗脑了~~
& & 10:27:51 +08:00
除了最后一条 其他的你怎么被洗的
& & 10:29:28 +08:00
在这个五毒俱全的社会，会不会毁掉你的各种观？
人，还是要简单快乐的活着
& & 10:34:50 +08:00
我在外包公司
做的是某运营商的一项目
做的东西能用就行
太闲了,自己看了好多东西
有时候感觉安逸了，最近已联系好一份新工作了
& & 10:35:13 +08:00
@ @ 在学校里一直没怎么上过课，挂科 26 个学分。哈哈，是不是我被书洗脑了？切图不是设计师做的事情么，感觉很多基础知识能帮助我深入的解决问题，关系型数据库我深入研究过一本书，叫《深度探索关系数据库》，代码规范极其重要（我主用 Python），ORM 在多人协作时重要但查询聚合很复杂时应该使用原生 SQL，工作之后应该保持对新技术的学习。以上，我的三观。
& & 10:46:28 +08:00
切图不是美工做的么
@
& & 10:49:15 +08:00
智商不够到哪儿都被毁，真被毁也是先被父母毁，然后被老师毁。
& & 12:07:23 +08:00
& & 12:23:01 +08:00
感觉楼主有点为了捧 xx 而故意贬低 xx 了。
前端工程师的工作应不应该包括切图，
//
这个因公司因团队因人而异，并不是只有外包公司和非外包公司而异
程序员大学里的知识储备（ 如数据结构、操作系统、计算机网络 ）重不重要，
//
但凡不傻的人也知道重要，就像说小学语文到底重不重要一样
关系型数据库的知识是不是一个 SQL 就能概括，
//
同上，编程的知识是不是一句 Hello World 就能概括？计算机的知识是不是一个 0101 就能概括？爱情是不是一句 “ 我爱你 “ 就能概括？
多人协作时的代码规范、ORM重不重要，
//
同上，只讨论第一句，这个东西到哪都重要。
工作了之后还应不应该坚持每天学习 等等 ……
//
还是同上，哎。
世界如此美妙，你却如此搞笑，哈哈
& & 12:25:27 +08:00
如果做这行的都能被洗脑，那就在那混混吧，出去也没前途
& & 12:49:48 +08:00
@ 问题是，他（们）现在觉得：做前端好辛苦，又要懂切图、PS，又要懂设计；觉得大学里的这些基础知识工作了完全用不到，没什么用；觉得会写 SQL 就算会了关系型数据库；公司用 PHP 却没有编码规范，公司内部框架有 ORM 但大多数人都是直接写 SQL。每天下班之后跟室友们打 LOL ，对于 PHP 7 基本不了解。
不止听过一个在外包公司工作实习的同学这么说过。
& & 13:06:34 +08:00
我们是不是可以理解为外包公司在培养“全端工程师” 啊哈哈哈
说点正经的，这些问题哪个研究好了都够研究一辈子的。
& & 15:36:00 +08:00
我的简历上有&四不做&. 不做外包是第一条
& & 15:56:14 +08:00
自己或和一两个人做外包还好，有事好商量。在外包公司就算了，都已经是制度森严了。
& & 16:01:27 +08:00
& & 16:04:19 +08:00
我呆过的公司前端都不切图，ui切
& & 16:14:01 +08:00
不同的团队有不同的分工方式啊，即便是让 CEO 来切图，我也不觉着有什么奇怪的。
& & 16:18:13 +08:00
不会，只要三观足够牢固。因为外包公司而被毁掉的，即使不在外包公司也很可能被毁掉。
& & 16:29:06 +08:00
我也是在外包公司。
这里技术人员多，说说我吧，我是做UI的，我在这边的工作，基本等于半个产品/交互+UI，作图之前，先去和产品（说的恰当点应该算销售吧，哈哈）完善原型，把他的坑填满后，开宣介会议，然后开始作图。图做好了之后，图片标记（字体大小、颜色、间距、点击效果等等）、切图（安卓一套，ios@2&@3）、市场审核图、后期资料整理。
这些基本是我的工作内容。
说道工作强度，我不是很排斥加班，比较排斥的是，让我去降低质量赶工期，一个30个页面左右的app项目，给我这边的时间也就7个工作日内，从零要作图完成，而原型画的质量很差，中途还会变来变去。我觉得，我做的东西既是给现在的老板用的，同时又是给下一个老板看的，做的烂对公司和个人都没有什么好处，特别是做设计的，你的作品就是你的招牌。所以，给我的时间充足我也不会早早做完闲在那边，会尽量去完善自己做的东西，做完一个不错的作品后还是有成就感的。
也想过跳槽，去环境更好的公司，但是无奈在三线城市，都差不多，没有互联网氛围，而一些原因让我又不得不呆在这里，有时候好羡慕你们能在外面飘，辛苦并成长着……
& & 16:36:10 +08:00
另外，很多外包公司，不谈对员工体贴，连设备都会很抠，就说我现在的公司，做设计的，申请到8g内存也是去年申请了四个月才申请下来，显示器颜色不对，上半部分和下半部分都有色差……去年说可以申请升级设备，还很开心，申请了个1000多的戴尔显示器和一块120g的ssd，后来发现只是说说而已……勉强用吧，好在有psplay，可以实时在touch上看到效果。公司的测试机，去年采购了一批二手货和廉价机器后，就没有再采购……恩，也勉强算能用吧……
& & 16:40:07 +08:00
我是做设计的，我觉得切图完全应该由设计师来做，最好设计师懂点前端，这样作图/切图的时候会协作地更好，我在公司里切图、安卓上的点九图都是我做的
& & 17:00:47 +08:00
嗯。工作8-9年的人，不知道什么什么是gfw，不知道v2ex。
我让他了解业务，可他只愿意做代码工人
我引导他用mac，可是硬是活生生被用成windows， 装了一大堆盗版软件，不会用命令行
我引导他上v2ex，第一个帖子就是在这里跟我撕逼
我介绍他python的好，他回应python是门很烂的语言
我介绍他学学前端知识，他告诉我easyui足够了，于是我就让他在项目里用用easyui，答复我他不熟悉不会
外包时间长了真的会出问题的，他表现得对技术很有兴趣，但是仅仅限于他的舒适区。在公司和我吵得很厉害，原因是我让其学新东西；技术只是糊口的工具，不应该自己去学的，我们这些懂的人直接告诉他就行了。于是5分钟一个问题，甚至让一个同事不堪其扰的躲回了家。
能力可以培养，技术可以学，三观。。。。我实践下来，真心别去想着去改变一个人
& & 17:30:35 +08:00
关键还是看个人。但是外包公司的环境确实不好。
我面试过一些外包公司的人，的确是有通病的：
1、遇到问题选择回避的情况比较多，因为只要按时交付任务就可以了，怎么简单怎么来。这样导致思考和解决问题的能力不好。
2、技术视野比较窄，积极性也不是很高，即工作中不会用到的技术一般不太会去接触学习，更别说深入研究了，导致技术水平上不去。
& & 17:45:49 +08:00
软件开发和别的职业并没有什么不同，踏踏实实的把手头的事情做好，多琢磨多动手，总能做的不错，不论你在什么公司。
& & 21:15:04 +08:00
不会啊，我的项目下有十几个不同公司的外派人员，刚来的时候确实有点愣头愣脑，熟悉项目几个月后现在都挺聪明能干的。而且其中一个公司因为待遇不是很高，离职率略高，但是经过这么一次倒手，身价都提升了很多。在外包工作干活，如果要想有前途，重点就是：学好业务。技术谁都会，业务就没几个码农吃得透了。
& & 21:45:51 +08:00
外包也分很多种,做与不做,严谨和不严谨,思考与不思考都是自己的选择
大浪淘沙,市场下外包形式的存在是必然的,也不见得外包的技术门槛有多低
& & 10:17:18 +08:00
还是年轻 见的少
& · & 1723 人在线 & 最高记录 3541 & · &
创意工作者们的社区
World is powered by solitude
VERSION: 3.9.8.0 · 19ms · UTC 15:17 · PVG 23:17 · LAX 08:17 · JFK 11:17? Do have faith in what you're doing.小站会根据您的关注，为您发现更多，
看到喜欢的小站就马上关注吧！
下一站，你会遇见谁的梦想？
关注web领域技术的发展和学习&【js&/&html5&/&css3&/&jquery&/&jqm】【php&/&nodejs】【apache&/&nginx&】【redhat&/&CentOs】
[转]加班赶工，得不偿失
文/Evan Robinson 译/乔梁
早在75年之前，大多数行业就已经放弃了加班赶进度。数不清的行业经验和研究事实证明：要想完成工作，加班赶工是成本最高的做法。
缘起2004年，某国际电子游戏公司员工的家人以Ea_spouse为名，在某网站上发布文章，讲述了其配偶由于高强度、长时间的加班，对自己的身体健康以及家庭生活造成了很不好的影响。一石激起千层浪，关于电子游戏开发行业人士生活质量的话题再次引起了大家的热烈讨论。Ea_spouse收到了上千个回复，此事也很快被主要媒体跟踪报导。通过网络，上千人参与了这个自发的大规模讨论，内容涉及强制加班、工作效率、怠惰、工会、诉讼以及对很多公司的控诉等议题。我已经做了二十多年软件项目的开发与管理工作。过去的每一年，做过的每一个项目，都让我更坚信：加班赶进度&&&赶工&&&是一种高成本、低产出且极具破坏性的工作方式。&工作持续时间越长，工作效率越低&已是常识了。然而随着时间的推移，我已注意到：由于过多额外加班导致工作效率下降的速度，要超过大多数软件行业管理者的认知。随着调查深入，我惊讶地发现我并不是第一个认识到这一点的人：近一个世纪以来，传统工业的工程师们对于我所观察到的问题早已达成共识。
历史1908年，工业效率研究先驱&Ernst&Abbe公布了他的研究结论，即每天的工作时间从九小时减少到八小时，其日产出量会增加。而他也不是第一个注意到这件事的人。早在1893年，William&Mather在Salford钢铁公司（Salford&Iron&Works）就已经采纳了每天八小时的工作制。在1909年，Sidney&J.&Chapman发表了《工作实践》（Hours&of&Labour）。他在文中描述了每天的工作小时数与工人的生产力之间的变化。下文会对其结论进行详细阐述。亨利&福特在1926年大张旗鼓地采纳每周40小时工作制，至少已经进行了十二年的试验让他确信：将每日工作10小时调整为8小时，并把每周工作六天改为五天，实际上会增加总产出并降低生产成本。福特大肆宣扬缩短工作时间的社会效益，并强调增加消费时间对每个人都有好处。但其核心观点仍是：减少当班时间可以带来更多产出。我发现很多组织（如商业、大学、工业协会和军事单位等）进行的研究结果都持有同样的基本观点，即对于大多数人来说，&每天工作八小时、每周工作五天&是保证高产出和低身心消耗之间的最佳平衡点。在十九世纪的三十年代至五十年代，类似研究进行过上百次；到了六十年代，40小时工作制所带来的好处在美国企业界已被无可争辩地接受了。1962年，商业协会（Chamber&of&Commerce）甚至专门发行了一个小宣传手册，来称赞减少工作时间所带来的生产率提高。然而，不知何故，硅谷却把其抛在了脑后。Ea_spouse写到：&现在的强制工作时间是从早上九点到晚上十点，且每周工作七天，基于员工的良好表现，星期六的下班时间偶尔会提前到晚上六点半。平均算下来，这相当于每周工作85小时。&实际上，一周有六天是从早上九点工作到晚上十点，还有一天是从早上九点到晚上六点半，算下来是每周工作87.5小时（6&13＋9.5=87.5）。可是在工作这么长时间以后，谁还会算得那么详细呢？在这一方面，电子艺界与其它高科技公司没什么不同。请希望提高员工生产力且同时让他们保持头脑清醒的人一起来看一下：管理者在工作时间、产出、效率以及生产成本这几个方面做出的假设，以及一个世纪的产业研究如何证明这些假设是完全错误的。
管理者想要什么？当管理层将员工送上&死亡之旅&时，他们究竟想要得到什么呢？我们真的相信EA的CEO想看到员工撅着屁股在办公室里连续工作7&24小时吗？管理者想从雇员那里得到最大的产出，是用最少的成本投入生产出最好的产品。不到万不得已，他们不希望为了完成产品出钱雇佣额外的人力资源，从而增加成本。表面看来，要想达到这两个目的，&赶工&好象是最显而易见且合理的方法了。假设产出是利用计件方式来衡量的话，没读过上述研究报告的管理者可能会推断：假如一个人在八小时内生产16件产品，那么，他在九个小时内应该能生产出18件产品，在十个小时内可能生产20件。我们可以用下面这个简单的公式来表示这种观点：O&=&X/Y&*&t其中，O是总产出，X是基准时间Y（以小时为计量单位）内的产出，而t是实际的工作小时数。在这种假设前提下，增加时间t是提高产出O的最简方法。在个别情况下，这种假设是有效的，例如只在很短的一段时间里延长工作小时数以便能在最后期限时交付。但是，其它行业的长期试验和研究表明：加班冲刺的极限持续时间比大家想象的要短；而且当达到极限以后，这种冲剌也会陷入困境。
小时生产率很重要对于如何看待&工人的产出&，更现实的方法是考虑小时生产率会随着工作时间的长短发生变化。这种变化有两种主要来源：在一天中最后几个小时里，产生在脑力和体力上的明显疲劳状况；随着已经延长了工作时间的工作日不断增加，脑力和体力的疲劳也不断积聚。下面的等式表达了这种更复杂一点儿的情况：O&=&P(t1&,&t2&,&t3&,&&&,&tn&)其中，O代表总产出，P(&)表示小时生产率随时间(t1-tn)的变化。在这个等式中，P(&)是一个函数，不是一个常量。P(&)根据工人的不同而变化，因为某些人生产力要高于其他人。P(&)也随时间变化，因为人不是机器，在第14个小时完成的工作并不完全等于在第1个小时完成的工作。另外，P(&)也会随工人最近的状态而变化，例如，开夜车后的早上与睡了一个好觉后的早上，其工作效率也不可能是完全一样的。在1909年Sidney&J.&Chapman发表的《工作时间》一文中展示了下面这张示意图：
其中，曲线P表示&固定数量的劳动力（根据每个工作日的小时数）产出边际价值的长期变化值&。OX轴表示一天内的工作时间，OY轴表示产出的价值。在OX轴的n点上，也就是说如果每天工作n个小时，其总产值是图形Onda的面积（详情请参见&）。可以发现：曲线P的高度就代表了工人的工作效率（每天在给定的工作小时数下，每个单位时间的产出）。聪明的读者已经注意到在点b，工作更多小时不会创造更多的价值。而且在b点以后，每多工作一个小时，产出反而是负值。怎么会这样呢？Chapman的工作曲线图假设给定工作小时数的工作日会持续一定的时间。因此，它将每天的疲劳状况和长期的疲劳累计统一在一个模型之内体现。首先，小时产出率的下降反映了在接近一天工作结束时，疲劳效应对工作质量和数量上的影响。但是到后来，每天的疲劳是由累积疲劳复合组成的。也就是说，在头一天加班时间导致疲劳产生的生产力下降，会对此后工作日的小时生产率下降产生叠加效应。即便是在一天之内，当精疲力竭的雇员再也无法投入工作时，产出就会停滞不前。如果某个已经变得麻木的雇员犯了灾难性的错误，破坏了前面已经完成的工作和投入资本，那产出就会变成负数。就工厂而言，一个工人的生产率会随时间下降。某工人在一个班次开始，可能每小时生产10个工件，而在接近下班时，可能每小时只能生产6个，在这其间，有几个小时可能会达到峰值12个。再往后，其工作会变得更慢，而且会犯更多错误。这种减速和错误最终会使生产力成为零，即花了很长时间才生产一个工件，而到了最后一个总会有点毛病。流水线的管理者很久之前就发现：当达到这种疲劳程度时，会带来较大的失误，并导致更大的成本损失，如昂贵的机器受损，存货被毁，或者工人严重受伤等。作为脑力工作者，得到充分休息后，程序员会生产更多高质量的代码，而且bug也会比较少。在开始工作的第一个小时，程序员会逐渐进入状态，接下来的&几个小时是最佳状态。在此之后，我们会感到疲劳，小时生产率也就下降；我们会花很长时间才能修复一个简单的bug，或增加一个简单的特性。而这样的事情如果拿到前几个小时做，可能也就是几分钟的活儿。再恶劣一些的状况&似乎很多电子娱乐行业的公司大部分时间都在这种极端状况下工作&一个过度疲倦的IT技术人员可能会删除很有价值的文件，从而要花费额外的工作去恢复备份；他也可能在回家的路上遇到交通事故，结果在几个月内都无法上班。
这就是第一课：在一个工作日中，生产率随时间h变化。在前四至六个小时里，生产效率最高。随着时间的流逝，生产率会降为0，甚至会变成负数。
平衡点在哪里？如果在一个工作日内，生产率本来就会随时间下降，而且长时间工作会导致低生产率，那么我们如何找到一种方法来达到最大产出呢，平衡点又在哪里？不幸的是，希望量化脑力劳动者的产出是相当困难的。我也希望能给出一个简单的公式，只要代入几个数字，就可以计算得出每个人达到最大产出所需工作小时数。但是我不能，因为即使存在这样的公式，也不能就找到并代入哪些基本数据达成一致。常见软件度量方式，如代码行法或功能点法，要么只是简单收集数字，无法让人信服其价值，要么就是数据很难定义和收集。有用的度量数据，如造成bug数目和修复bug数目等，其可信度也不高，并有可能会被不公平地用于年度考评上，也可能被聪明的程序员利用来算计年终考评或绩效奖金。架构师的产出可以很容易地用某些数据（如模型或架构图的数量）来衡量，但同样很难用另外一些数据（如主观质量、观感，及模型复杂度）衡量。如果用发现的独特bug数来衡量测试人员的产出很容易，但用代码覆盖率来衡量就有点儿难了，假如用发现缺陷的总百分比来衡量就难上加难。总而言之，对于团队的产出，大多数公司好象陷入了一种&最小公分母式&的度量。要么用游戏出厂数量和销售量，要么就不用。虽然这些的确是大多数股东所在意的度量数据，但对于生产率的度量完全没用，尤其是每日或每小时的生产效率。
◆&第二课：对于脑力劳动者，生产效率很难量化。所以，我们只好同其它行业中进行类比：以下内容来自Work&Less&Institute&of&Technology名为《IT行业中的精神物理学》的一篇文章，是对Ea_spouse的回复：&这是一个多世纪前，Dr.&Ernst&Abbe&对德国耶拿的蔡司光学工厂（Zeiss&Optical&Works）工作时间与产出的调察。Dr.&Abbe是工厂的董事，他将工作时间从每日9小时减少到8小时，并详细记录了调整前后每个工人的每日产出，其结果与十九世纪的其他研究一致，即适当减少工作时间确实提高了总产出。&Tom&Walker指出：&产出的增减与工作时间的长短不成正比&好象是每一代人的必修课。1848年英国议会通过10小时工作法案，结果每个人每天的总产出增加了。到十九世纪九十年代，雇主又广泛尝试8小时工作制，不断发现每个工人的总产出仍在提升。&科学管理理论&创始人泰勒&（Frederick&W.&Taylor）指出减少工作时间会显著增加个人产出。在上个世纪二十年代，亨利&福特对工作时间安排进行了多年试验，最终在1926年引入每周工作五天共计40小时，却付六天薪水的工作制度。福特为什么要这么做呢？因为他的试验表明，其工厂在五天内的产出要比六天的产出还多。而在工作制变迁的每一步上（1840s，1890s和1920s），总有些行业人士坚持认为：缩短工作时间会降低产出，使经济受损。
◆&第三课：经过上一个世纪的研究表明，每周五天且每天8小时的工作时间，从长远看其产出将会最大。有什么理由让我们认为：我们这个行业可以不遵守这个规则呢？
短期的产出又当如何？如果每周40小时工作制是收到最多产出的最佳工作时间安排方式，我们能否期待&短期内的延长工作时间&能够有短期的成效？简而言之，从几天到几个月，你通过延长工作时间能够得到多少额外的产出，取决于一个工作日工作多长时间。显然，如果在八小时工作制下一个工人每小时生产一个工件，他在十六小时工作制下生产的工件数会在八到十六个之间。这是隐藏在&赶工&背后不那么明显的本质。另外，工人生产率还依赖于其所处状态。与每周工作40小时相比，每周工作60小时会导致生产效率下降。刚开始时，这额外的20个小时会弥补生产效率的下降，使总产出增加。但研究表明，当改为每周工作60小时以后，建筑工人的生产率很快就会开始下降。这种下降很快可以感觉到，一周之内就会很明显，而且还将不断下滑。在两个月内，累积生产力的损失会下降到与每周工作40小时的产出同样的水平。同一篇报告引证的研究显示出：每天工作八小时的总产出会高于每天工作九小时总产出16%或者20%。所以，没错，&赶工&可在短期内提高产出。但在每周工作60小时的情况下，这个&短期&绝不能超过八个星期。因为从这一点开始，成本耗费会严重超过带来的收益。不仅会失去赶工带来的成果，还会使员工感到疲倦、易怒、情绪难于控制。当恢复为每周工作40小时后，还需要一段时间，他们的产出才能恢复到原来的水平。一周如果工作87.5小时会怎么样呢？虽然缺乏确凿的数据，但我估计效率在一个月内将跌至原来的50%，即使每周额外的47.5小时工作（两倍于&正常&工作时间）在最初阶段可能有相当高的产出。
◆&第四课：每星期工作60小时的情况下，由于长时间工作所导致的生产率下降，会抵消几个月超时工作所带来的产出。
睡眠因素在评估&赶工&是否有用时，还要考虑另一个因素：如果工人没有足够的睡眠，他们能保持高产多长时间？Gregory&Belenky上校是Walter&Reed&军队研究所神经精神科的主任。他曾为五角大楼研究如何使士兵在战斗条件下最大化其效率和警惕性。在其1997年的论文《持续作战中睡眠、剥夺睡眠与人体的表现》中，他指出：&实验室内研究表明，每连续保持清醒24小时，神智功能下降25%。被剥夺睡眠的个体虽然能够保持认知活动的准确性，但是反应速度明显下降。&在我们的研究中，来自第82空降兵团炮火指示中心的团队接受了模拟持续战斗状态的测试，共持续了36小时。在测试开始阶段，当我们要求向一所医院进行模拟开火时，团队还能查看方位图，评估目标状况，拒绝开火请求。到模拟测试后期，他们就无视目标性质毫不犹豫地开火了。在进行模拟演习的第15天，每晚睡四小时的炮兵连的成绩仅是每晚睡七小时的炮兵连的三分之一。
◆&第五课：每连续工作24小时，认知能力会下降25%。连续开夜车的人会产生严重的累积影响。
认知迟钝与错误率&赶工&引起生产率下降的重要因素之一就是产生错误数量的增加。尽管大多数错误很容易修复，但还是有一些错误会把从&赶工&中得到的收益消耗殆尽。&赶工&时间越长，相关人员遇到大麻烦的机会就越大。程序员、架构师和测试人员能够拿到薪水，不是由于他们拥有发达的肌肉或者什么超能力能把重物从一点移到另一点，而是因为他们的大脑。工作时间越长，或者缺乏充足的睡眠（好比每晚只睡1～2小时）会大大降低他们使用大脑的效率。Belenky上校指出：士兵即使每天仅少睡一个小时，后果是&减少了&&保持清醒地进行高条理性脑力工作的能力。降低了个体和团队的效率&。知识工作者应该感到幸运他们不必担心发生&友军误伤&的问题。在《持续减少睡眠会产生严重恶劣后果》一文中提到：&宾夕法尼亚大学的研究人员发现：连续十四天内每天只睡4至6小时的研究对象在认知表现方面显示出明显不足，其水平相当于连续三天不睡觉的人。然而，这些研究对象却说自己只感觉有点儿困，并没有意识到他们的状况有多糟。&在2005年1月的《洛杉矶时报》上，Karen&Kaplan有一篇名为《瞌睡的医学院实习生成为马路杀手》的文章：&研究表明，在21个小时内没有睡眠的司机，其状态相当于血液内酒精含量检测达到0.08的人，而0.08是美国对非营利性驾驶司机进行血液内酒精含量检测是否超标的法定界限。&令人感到讽刺的是，大多数软件公司会解雇一个工作时间喝酒的人，却能毫不犹豫地将今年最重要的项目交到由于缺少睡眠（相当于达到法定司机酒精含量超标标准）的人手里。事实上，是他们要求这些人在&违法醉酒状态&进行工作的，并以此作为雇员被继续雇佣的条件。带来的风险很现实&引发的错误真能导致灾难发生。在Dr.&William&Dement写的《睡眠的承诺》一书写道：&日的夜晚清冷宁静，空气如水晶般透明。埃克森石油公司的油轮离开了阿拉斯加的瓦尔迪兹市，驶向威廉王子海湾。在如此清澈的气候条件下，油轮按原计划放下了输油管道，却没有及时收回。巨大的油轮搁浅，数百万加仑的原油泄漏到海湾之中。&&在最后的报告中，国家运输安全委员会&(NTSB)发现，缺少睡眠是事件的直接原因。&&导致美国历史上最严重的漏油事件的直接责任人是船上的三副，他在事发前48小时内仅睡6个小时，睡眠严重不足。&
Exxon Valdez 威廉王子海湾漏油事件&罗杰斯调查委员会（Rogers&Commission）在关于美国挑战者号航天飞机失事分析最终报告中说：在关键时刻的电话会议上，做出发射决策是有问题的。在&人为因素分析&章节提到睡眠缺乏&对此有重大影响&。如果由于缺乏睡眠可以导致战斗失利，危害病人，搁浅油轮，引爆太空飞船；仔细想想这会为价值一千五百万美金的游戏项目带来什么？
◆&第六课：错误率会随连续工作时间而攀升，尤其是睡眠时间不足的情况下。最终，失败会找上门来，导致灾难发生。当时间紧且预算投入大时，你真能承担得起这个风险吗？
这意味着什么？意味着生产率下降。在保持每周五天共约40小时工作时间的情况下，工人可以维持生产率。工作更长时间，生产率开始下降。在四天和两个月之间某个时间点上，从加班工作中得到的收益会被小时生产率下降所抵消。在某些极端情况下（当工人无法保证每晚至少7到8小时睡眠的状况下，一到两天之内），效率会直线下降。上面的研究内容很多都是来自于工业产业环境，可能有人会认为这些结论不适用那些更多地使用脑力的程序员、架构师和测试人员身上，因为他们与普通的体力劳动者不同。事实上，的确不同，Belenky上校明确表示：&与复杂的脑力活动相比，可以说，简单的心理活动、体力劳动和耐力基本不受缺乏睡眠的影响。&需要完成复杂任务的脑力劳动者受睡眠缺乏影响比体力劳动者更明显，生产率下降得更快。在知识工作者中，由于过度工作而导致的生产率损失会比普通士兵更早更快，因为我们的工作更受脑力疲乏的影响。Ea_spouse想告诉我们，她老公所在团队的工作效率远远低于最佳效率。在老板让他们进行每周87.5小时的超级&赶工&之前，每周工作60小时以上的状态就已持续几个月了。二十世纪，在大部分的时间、地点和行业中，让手下雇员这样工作的管理者就被认为是不能胜任其工作。这不只是因为他们威胁到了良好的雇佣关系，还由于他们的错误管理方式将公司的生产力和资产至于危险境地。一百多年的业界研究已经毋庸置疑地证明：员工因精疲力尽所产生的错误会推迟计划，损坏设备，增加成本，降低产品质量，最终威胁组织的生存。这是对项目的威胁，也是对其管理者、雇主、每个人，以及其自身的威胁。无论如何，&将&赶工&用作长期策略，在经济上是不可行的。延时工作不能增加产出，除非是短期行为。另外，&赶工&也不能使产品更快推出，只会导致产品延迟发布。&赶工&不能提高产品质量，只能使其更糟糕。&赶工&增加了引发重大错误的机会，比如交付会擦除客户硬盘数据的软件，或者删除代码树，或者把可乐洒到最近没有做过备份的服务器中，甚至引起火灾。的确是这样，在&赶工&最后那些睡眼惺忪的日子里，我曾亲眼目睹过前三个后果。第四个后果迟早会发生，大概只是时间上的问题。管理者决定赶工，是因为他们想告诉他们的老板&我已尽我所能&。他们赶工，是因为他们评估的是放在椅子上的&草人&而不是那些能开发游戏的&大脑&。他们赶工，是因为他们没有认真考虑要做的工作，或没有考虑做工作的是人。他们赶工，是因为只知道要表现出自己在尽力做好工作的重要性，而不是真正去把工作做好。他们赶工，是因为他们回想到当他们还是程序员、测试人员、&助理制片人&或&副制片人&时，他们也是被要求这样做的。但这不是唯一的方法。事实上，很多文献一次又一次地表明：加班赶工是最差的方式。这也是很多行业七十五年前就已放弃这种工作方式的根本原因。管理者、股东和员工都坚信：使用经过时间检验的&&每天工作8小时、每周5天&&管理实践，大家会因更快、更省地交付更好的产品而获益，而且不会损耗组织的人力资源和在公众中的声望。
Evan Robinson19 岁进入游戏行业， 在TSR 做程序员。22岁，他已经作为独立程序员给EA 做电脑游戏。之后的二十几年里，他先后在该行业数家知名企业做过程序员、高级工程师、技术主管、工程主管、过程咨询顾问，以及技术专员。Evan 的出版物以及其早期的GDC 演讲确立了他的地位，被认为是业内最佳软件工程实践及最有价值软件开发管理人员之一。目前他住在温哥华。
响应式Web设计：最佳指南
本文是对博文《》的翻译，内容如下：2012年被称为智能手机年。根据最近一份调查显示，美国的智能手机覆盖率已达50%。现在确实是提升移动终端用户体验的大好时机。如果你正运营一个网站，那就必须有一个响应式的Web设计，以便可以从移动终端上很好地访问你的网站。如果你还没意识到响应式设计的盛行，你应该多去了解一下它。
响应式Web设计
首先了解什么是响应式Web设计，这一点很重要。精确的说，响应式Web设计是一种技术，可以使网站适应于任何设备。任何设备，可以是智能手机、平板电脑、TV、PC显示器、iPhone和Android手机，包括横向、纵向的屏幕。你需要做得只是正确地实现响应式Web设计，到时你的网站就可以很好地适合各种设备。
响应式设计的替代方案
自从移动设备成为除桌面浏览器外的另一选择时，响应式Web设计便开始广泛流行起来。有些人认为响应式Web设计是让更多人访问该网站的最佳方法。但有些网站由于太复杂而无法实现响应式Web设计。针对这样的网站，有如下两个解决方案：
开发针对网站的、完全独立的移动版本如果你认为你现在的网站无法实现响应式Web设计，你可以为你的网站再开发一个全新的移动版本。如果用户通过移动终端访问你的网站，他们将被引导至网站的移动版本；系统将检测他们的智能手机，相应地显示网站内容。
开发移动应用如果不想陷入设计响应式网站的麻烦之中，开发一个移动应用是最好的办法。但单独开发移动应用可能会很昂贵，同时它也不是&开放Web&的一部分，搜索引擎无法找到他们。
响应式Web设计的优点和缺点不要认为响应式Web设计是针对移动终端的万能解决方案。它并不能真正替代移动网站。但它非常受欢迎，且有很多优点。世间万物，有优点，必有缺点。响应式Web设计同样也有缺点。让我们来看一下响应式Web设计的正反两个方面。
1.对用户友好很显然，响应式Web设计可以向用户提供友好的Web界面，因为它可以适应几乎所有设备的屏幕。现在技术发展日新月异，每天都会有新款智能手机推出。如果你拥有响应式Web设计，用户可以与网站一直保持联系，而这正是开发响应式网站的目的所在。2.移动频段（Mobile Segment）在响应式网站的帮助下，你可以获得网站流量的全景图。你需要做的只是创建一个移动频段（的流量统计），以获得与网站流量相关的所有必要信息。流量的状态在分析网站性能及采取必要措施提升性能方面十分有用。3.积累分享响应式Web设计可以让你（作为网站的拥有者）通过单一的URL地址收集所有的社交分享链接。你可以为创建更好、更友好的网站而做出积极贡献。4.最佳化搜索引擎搜索引擎也在变得越来越聪明，它们足够智能可以完成移动网站和桌面网站的连接。5.无重定向响应式Web设计最大的优点之一是，你不必在乎任何重定向，它包含无用户代理定向。所以当你很少负责解决重定向及定向用户时，这是一件很棒的事情。6.更少维护开发一个独立的移动网站，会增加你的工作负担。实际上你就拥有了两个独立网站。如果你有一个响应式网站，维护的成本将会很小，因为它只有一个布局，且可工作在所有类型的设备上，而这可以明显地减少你的工作量。
1.加载需要一定的时间虽然，它不是一个大问题，在响应式设计中，需要下载一些看起来并不必要的HTML/CSS。除此之外，图片并没有根据设备调整到合适大小，而这正是导致加载时间加倍的原因。2.优化搜索引擎对于响应式Web设计，为搜索引擎确定关键字不是一件容易的事。因为相比一般桌面用户，移动用户多采用不同的关键字，修改标题及其他事项都比较困难。3.Google排名如果响应式网站仅基于移动内容，它可能会影响到网站的Google排名。因为Google不支持这样的网站，它不会对你的网站进行索引。4.时间花费开发响应式网站是一项耗时的工作。如果你计划把一个现有网站转化成响应式网站，可能耗时更多。如果你想要一个响应式网站，最好从草图开始重新设计。5.布局响应式Web设计的布局主要是液态的，这也正是设计者对设计样式不好控制的原因。而且眼下正是设计者提前展示各种&复制品&的时候。设计者试图针对移动和桌面布局分别显示线框和设计原型。只有等到这两种布局均得到提高后，响应式Web设计策略才能真正实现。
响应式Web设计并非适合所有类型的网站。尽管，由于技术上的最新进步，从移动设备上访问网站的数量已经增长，但在顶端、最著名的网站中，只有9%拥有他们的移动网站。最新好消息，Google已经推荐使用响应式Web设计，这将使其更加流行。原文链接：
配置SVN强制填写注释
最近有人说： SVN是可以不写任何注释就签入代码的，团队中总会有人偷懒的，还是git比较好，规定必须输入注释 &
&其实我们可以这样配置，就可以要求SVN提交时强制要求输入注释
利用svn的pre-commit钩子可简单实现此要求。
进入仓库project1/hooks目录，找到pre-commit.tmpl文件，重命名，去掉后缀.tmpl。
编辑pre-commit文件，将：
$SVNLOOK log -t "$TXN" "$REPOS" |
grep "[a-zA-Z0-9]" & /dev/null || exit 1 commit-access-control.pl "$REPOS" "$TXN" commit-access-control.cfg || exit 1
这三行注释掉（前面加#符号），在此位置添加如下几行：
LOGMSG=`$SVNLOOK log -t "$TXN" "$REPOS" | grep "[a-zA-Z0-9]" | wc -c`
if [ "$LOGMSG" -lt 5 ];#要求注释不能少于5个字符，您可自定义 then & & &echo -e "nLog message cann't be empty! " 1&&2&
& & &exit 1&fi
保存，退出。&
给pre-commit添加可执行权限： chmod +x pre-commit
配置结束，可以使用了
http://blog.csdn.net/dojotoolkit/article/details/7682978
苹果面试8大难题及答案
导读：苹果这样的公司通常会在面试过程中向求职者抛出一些逻辑的问题来考研面试者，所以，如果你对进入苹果感兴趣，或者向往类似的公司，又或者只是对逻辑问题感兴趣，这些面试难题值得你仔细研究。
&你面前有两扇门，其中一扇门内藏着宝藏，但如果你不小心闯入另一扇门，只能痛苦地慢慢死掉&&&这一听就是那种经典的最令人头痛的一类问题，但其实与其他问题相比，这只是个热身。在这两扇门后面，有两个人，这两个人都知道哪扇门后有宝藏，哪扇门擅闯者死，而这两个人呢，一个人只说真话，一个人只说假话。谁说真话谁说假话？那就要看你有没有智慧自己找出来了，游戏规则是，你只能问这两个人每人一个问题。那么，你问什么问题？问哪个人？根据他们的回答，你又该怎么做？求职者的最佳答案：
随便问其中一个人：&如果我问另一个人，他会跟我说哪扇门后是宝藏？如果你问的恰好是讲真话的那个人，那他指给你的答案就是那扇通向死亡的门，因为他会诚实地告诉你那个说谎的人会怎么说。如果你问的是那个只说谎话的，你得到的也是错误的答案，因为另一个人是讲真话的，说谎话的人会告诉你与讲真话的人相反的答案。所以你只要随便问一个人上述问题，然后选择与他们说的相反的门就行了。
&你前面站了5个人，他们中间只有一个人讲真话&&&&这个问题比上个问题难就难在，你只知道他们五个中有一个只讲真话，但其余四个，他们有时候讲真话，有时候讲假话，只有一点可以确定，这四个人将真话和假话有个规律：如果这次讲了真话，下次就会讲假话，如果这次讲假话，下次就讲真话。你的任务是，把五个人中那个只讲真话的人找出来。你可以问两个问题，两个问题可以向同一个人发问，也可以分别问两个人。你该问什么问题？小提示：你可以这样安排两个问题承担的任务：首先你可以先问一个问题，不管得到的答案是什么，你都能从中知道下一个问题你将得到的答案是真是假。求职者的最佳答案：
随便找一个人，首先问：&你是那个只讲真话的吗？&如果答案是肯定的，你再问这个人：&谁是只讲真话的？&；如果第一个问题你得到的答案是否定的，你就再问对方&谁不是只讲真话的？&正如这个问题给出的提示，第一个问题的价值在于，如果你得到的答案是&我是&，那么你问的人要么是那个只讲真话的，要么是那个这一轮讲假话的&半真话半假话&者，不管是谁，他下一轮一定会说真话。所以你可以继续问这个人：&谁是只讲真话的？&对方的答案就是正确答案。如果对第一个问题你得到的答案是&我不是&，那么回答者不可能是只讲真话的那个人，只能是一个此轮讲真话的&半真话半假话&者。此人下一轮将会说假话，所以你应该问他：&谁不是只讲真话的？&同样他告诉你的，只能是那个只讲真话的。
&外星人打算将地球用来种蘑菇，并且已经抓了十个人类&&&&外星人用这十个人代表地球60亿人口，将通过外星人的方式来测试这十个人，决定地球是不是有资格加入跨星际委员会，如果没有，就把地球变成一个蘑菇农场。明天，这十个人将被关在一间漆黑的屋子里前后排成一队，外星人将给每个人戴一顶帽子，帽子为紫色或者绿色，然后外星人会将灯打开，这十个人每个人都无法看见自己头上的帽子是什么颜色，但可以看见排在你前面的每个人头上帽子的颜色。帽子的颜色是随机的，可能全是紫的，也可能全是绿的，或者是任意的组合。外星人会从后往前问每一个人:&你头上的帽子是什么颜色？&如果这个人答对了，这个人就安然无事，他所代表的地球上6亿人口也将获救。否则，这个人将被爆头，外星人将把他所代表的6亿人口变成蘑菇的肥料。每个人的答案屋子里所有人都可以听到。现在，人类的命运在你手上，你可以设计一个方案，使这十个人提前制定一个计划，这个计划必须拯救尽可能多的人。提示：有个方案可以让你拯救其中至少九个人。求职者的最佳答案：
第十个人计算排在前面的所有人的绿帽子是奇数还是偶数并向前面的人发出一个信号，这样排在前面人就可以再通过排在更前面的所有人的绿帽子的奇偶数是否变化来判断自己帽子的颜色，因为如果绿帽子奇偶发生变化，那自己就是那个导致变化的&绿帽子&，如果没变化，自己就是&紫帽子&。因为所有的人除了回答外星人的问题不能说话，所以第十个人的&信号&只能包含在自己的答案里，比如如果排在前面的九个人有奇数顶绿帽子，这个人类就告诉外星人自己的帽子是&绿色&，如果是偶数，就猜自己的帽子是&紫色&。这样等于给他前面的人一个暗号，排在他前面的这个人，可以通过计算自己前面的所有人的绿帽子的奇偶变化来判断自己的帽子是绿还是紫。排在最后的那个人为了大众利益没有选择，根据前面的人的帽子情况告诉外星人自己是&绿帽子&还是&紫帽子&，他的答案有1/2的几率正确，但他前面的人一定都能答对。还没懂？比如第十个人看到前面有奇数个绿帽子，他就告诉外星人自己的是绿色，这是他前面的人就知道他的意思是前面九个人中有奇数个绿帽子，这是第九个人再数前面八个人的，如果前面八个人中也有奇数个，那自己就是紫色帽子。第九个人告诉外星人自己是紫色帽子，第八个人就知道绿帽子没有减少还是奇数个，再数数前面七个人绿帽子数的奇偶，就可以判断自己帽子的颜色；反之，如果第九个人告诉外星人自己是绿色帽子，那第八个人就应该知道绿色帽子减少了一个由奇数变成了偶数，再看看前面所有的绿帽子情况作出判断。这样一个接一个，只要每个人都认真听后面的人的答案并在心里计算所剩绿帽子的奇偶变化，前面九个人都能获救。当然，你也可以计算紫色帽子的奇偶。
&100个完美的逻辑学家坐在一个房间里&&&&这是一个电视真人秀节目，节目里100个拥有完美无瑕逻辑思维能力的人围成一圈坐在一个房间里。在进入房间前，这100个人被告知，100个人中至少有一个人的额头是蓝色的。你可以看见别人额头的颜色，但无法看到自己的，你需要对自己额头是不是蓝色进行猜测，在房间的灯被关掉时，如果你推测出你的额头是蓝色的，你需要站起来离开房间。然后房间的灯被再次打开，那些认为自己额头是蓝色的人已经不在屋内。接下来灯会再次被关掉，剩下的人中推测自己额头是蓝色的离开房间，如此重复。问题来了，假设这100个人的额头都是蓝色的，将会发生什么情况？注意，这100个人都有完美无瑕的逻辑推理能力，他们会根据其他人的额头颜色对自己进行合理的推理和猜测。提示：想想看，如果100个人不全是蓝色额头，又会发生什么情况？求职者的最佳答案：
将会出现的情况是：灯关了又开，开了又关，重复到第一百次时，所有人都同时离开。这是为什么呢？想想看，每个人都看见其他99个人额头是蓝色的，灯关掉后再打开，发现这99个蓝色额头的同伴都没有离开，然后灯再次关掉后打开，如此重复100遍后，所有人同时离开了房间。这么理解吧，假设只有一个人的额头是蓝色的，由于这100个人事先被告知至少有一个人额头是蓝色，所以这个人如果看到其他99个人额头都不是蓝色，立马就知道自己是蓝色，所以灯一关掉，这个人就会离开房间。如果有两个人额头是蓝色呢？其中一个蓝色额头的人会想：我的额头可能是蓝色也可能不是蓝色，现在其他99个人中有一个蓝色额头的人，如果我不是蓝色，那么就只有这一个人是，那么他看到我们都不是蓝色额头就能推断出他是，那么灯一关他就会离开，我先等一下，灯再打开如果他已经走了，那就证明我的额头不是蓝色的。反之，如果我的额头是蓝色的，那个蓝色额头的人的想法会和我刚才的想法一样先等一等，第一次关灯他不会离开，这样如果灯开了那个蓝色额头的人还在，就证明我的额头也是蓝色的。这样第二次关灯我们俩会一起离开。以此类推，如果有三个人额头是蓝色，你看到另外两个人额头是蓝色，应该推算出如果自己的额头不是蓝色的话，那么灯第二次关的时候他们俩会同时离开，如果他们俩没有同时离开，那就证明我的额头是蓝色的，我应该在第三次关灯的时候离开。结果是，三个蓝色额头的人在第三次关灯的时候同时离开。把上述逻辑重复一百遍，你就得到了最上面的正确答案。
&你有一个横6竖6的方格&&&你现在在左上第一个格子里，你的任务是移动到最右下脚的格子里，你每次只能向右或者向下移动，不能斜向移动，也不能后退。你能找出几种方法移动到最右下脚的格子？求职者的最佳答案：&
252种。从对称的角度思考这个问题。随便挑选一个格子，假设你从出发点有n种方法从到达与所选格子上边相邻的格子，m种方法到达与它左边相邻的格子。想想看，从出发点到达一个格子的方法与到达它左边和上边的格子的方法有什么关系？说对了，由于你只能向右和向下移动，到达一个格子，不是从它左边来，就是从它上边来。所以你从出发点到达一个格子的方法等于到达它上边格子的方法好到达它左边格子的方法的和相同，也就是n+m.这样，参照上图，你就可以算出从出发点到达每一个格子的方法了。
&逻辑学家们围成一圈坐着，他们的额头上面画有数字&&&又来一个逻辑学家围成一圈的问题，这次是这样的，三个拥有完美逻辑推理能力的人围成一圈坐在一个房间里，每个人的额头上都画着一个大于0的数字，三个人的数字各不相同，每个人都看得见其他两个人的数字，看不见自己的。这三个数字的情况是，其中一个数字是其他两个数字的和，已知的情况还有，其中一个逻辑学家的数字是20，一个是30。游戏组织者从这三个逻辑学家后面走过，并问三个人各自额头上的数字是什么。但第一轮每个逻辑学家都回答他们无法推测自己的数字是什么。游戏组织者只好进行第二轮的发问，这是为什么？你能据此猜出三个逻辑学家的数字吗？求职者的最佳答案：
结果由第三个逻辑学家的答案而定。他们三个的数字分别是20，30和50。假设第二个和第三个逻辑学家额头上的数字是20和30，这时候如果第一个逻辑学家的数字是10，那么第二个逻辑学家看到其他两个人一个是10，一个是30，会想：&我要么是20，要么是40.&第三个逻辑学家看到其他两个人一个是10，一个是20，会想：&我要么是30，要么是10，但我不会是10，因为每个数字都不一样，所以我应该是30.&这样第三个逻辑学家就会猜出自己的数字是30了，但他没有，第一轮谁也没有准确推测出自己的数字，这说明我们的前提不正确，第一个逻辑学家的数字不是10，那么他只能是50。
&你面前有一百个灯泡，排成一排&&&一百个灯泡排成一排，第一轮你把他们全都打开亮着，然后第二轮，你每隔一个灯泡关掉一个，这样所有排在偶数的灯泡都被关掉了。然后第三轮，你每隔两个灯泡，将开着的灯泡关掉，关掉的灯泡打开（也就是说将所有排在3的倍数的灯泡的开关状态改变）。以此类推，你将所有排在4的倍数的灯泡的开关状态改变，然后将排在5的倍数的灯泡开关状态改变&&第100轮的时候，还有几盏灯泡亮着？提示：如果你是第n轮（n大于1小于100），排在n的倍数位置的灯泡的开关状态就发生转变。反过来，比如第8个灯泡，当你在8的因子轮（即第1，2，4和8轮）的时候，它就会改变开关状态。所以对于第m个灯泡，如果m有奇数个因子，你的开关状态就发生奇数次变化。求职者的最佳答案：
10盏灯泡亮着，这10盏灯泡排位数都是平方数。根据提示已经可以看出，这个问题的实质就是找出有多少个灯泡的排位数拥有奇数个因子。每拥有一个因子，到这个因子数的那一轮时，这个灯泡就会被转换开关状态。比如第1轮，因为所有100个数字都有因数1，所以全部被打开；第2轮，只有那些拥有2这个因子、能被2整除的数字的灯泡转换状态被关掉；第3轮，只有那些拥有3这个因子、能被3整除的数字的灯泡被转换状态。以此类推，如果灯泡排位数拥有奇数个因子，意味着它被打开和关上奇数次，那它就最终还是被打开的状态，如果灯泡排位数拥有偶数个因子，那它最终就是被关上的状态。比如第1个灯泡有奇数个因子，第2个有偶数个（1，2），第3个有偶数个（1，3）第4个有奇数个（1，2，4），所以 第4个灯泡最后还是亮着的。最终计算得出，所有排位数为平方数的灯泡最终还是亮着的，因为这些数都拥有奇数个因子，1，4，9，16&&在100以内，共有10个平方数，分别是1，4，9，16，25，36，49，64，81，100。这10个排位数的灯泡，最终都还是亮着。
&你有一个立方体，立方体的边长是3&&&这个问题比前面那个从左上格子走到右下格子的问题难，因为那毕竟是个平面问题。如图所示，这次的任务是从立方体的背面左上的小立方体走到完全相对的正面右下小立方体。你可以往上移，也可以往下移，还可以往前移。问题还是，你共有几种走法？求职者的最佳答案：
90种，思路是将这个立方体分成&三层&。上面平面图的那道题的思路就是个最好的提示。你可以将这个立方体分成&三层&，粉红色代表最上面那层，紫色代表中间那层，橘红色代表下面那层。现在，我们把问题变成了：从左边、右边和上边到达目标小立方体的走法共有多少（如图所示，即到达紫色中间层最右下脚方块以及橘红色最右下脚左边以及上边相邻方块的方法）？假设从起点小立方体到达终点小立方体左边相邻小立方体共有m种方法，到达右边相邻小立方体共有n种方法，到达上边相邻小立方体有r种方法，那我们需要求出来的，就是n+m+r.按照前面那道平面题的思路和方法，你就可以一点一点计算出来我们的正确答案。
为什么C语言屹立不倒？
有些语言诞生几十年了依然是世界上最流行的语言，比如C语言。有些语言虽然号称新兴的语言却很少有人使用。在编程语言这个领域里似乎不符合长江后浪推前浪这个规律。这恐怕不止语言本身的因素，里面的缘由值得研究者好好去探索一番。近年来，谷歌一直致力于开发出自己的编程语言以取代当今世上最常用的C、C++和JavaScript。在系统语言方向，谷歌的Go语言能够为用户在数据中心内建立大型软件提供更多的便捷，有望取代C语言和C++的地位；而在网络开发方面，谷歌希望凭借Dart取代JavaScript。编程语言的世界里可谓是江山代有人才出，可有那么一位引领风骚达数十年之久，它就是C语言。编程语言之间的竞争一天也没能停歇，长江后浪推前浪，一代更比一代强。它们之中只有屈指可数的少数能够被市场接纳，成为程序员们日日夜夜的伴侣。究竟怎样的编程语言才能够成为大浪淘沙中的幸运儿？普林斯顿大学（Princeton）和加州大学伯克利分校（University of California at Berkeley）的研究者雷欧&马耶若维奇（Leo Meyerovich）和阿里&拉布金（Ari Rabkin）希望通过自己的研究，来解开编程语言世界的丛林法则。他们在探寻一个问题&&为何C语言虽垂垂老矣却能屹而不倒？雷欧和阿里采访了数以万计的程序员，又在全球最大的软件仓库SourceForge梳理了超过30万份的程序。&为什么C语言没有被淘汰？&拉布金提出了这个问题。的确，C语言距问世之初已经有了35年的历史。在这期间里，计算机迈出了不可测量的发展步伐，软件和操作系统也早就今非昔比，编程语言中不乏叱咤风云的新生代，而C语言也有了升级版。即便如此，C语言依旧风采不减当年。拉布金刚刚取得了加州大学伯克利分校的计算机博士学位，如今在普林斯顿大学攻读博士后学位。&在学术领域，现今的趋势是解决那些尚未出现的难题，&拉布金说，&学者们希望能够标新立异地建立起一个全新的语言系统，就没有考虑这么一套编程语言是否有实践的价值。编程语言的开发者们缺少一个明确的目标。&他指出，有些编程语言甚至缺失了最基础的东西，比如文档（Documentation）；还有些开发者不停地在语言系统上画蛇添足，弄到最后搞的程序员们只能因为它太&丰富&了不得不放弃。马耶若维奇认为：&我们发现这个问题事实上不是一个技术领域的问题，它是因为整个学术界不够注重实践需求所造成的&。新兴编程语言Scala是一个很好的例子。数据分析机构Slice-Data的创始人之一张洋（音译）是Scala众多使用者中的一员，他从2006年起开始接触Scala。Scala在问世之初文件编制就存在很大的缺陷，这给用户的学习使用造成了很大的不便和痛苦。&我当时肯定是个受虐狂。&他回忆道。除却新兴语言本身的问题，这里面还有一个要素是程序员的学习能力。试验中收集的信息表明，因为学习新语言太辛苦困难了，程序员们在使用一款新型的编程语言前并不会认认真真地去学习一番。马耶若维奇拿Adobe公司开发的ActionScript作为例子。ActionScript是一款以用户为导向的编程语言，程序员们普遍认为ActionScript的使用比较简单。可是当要用ActionScript做新的事时，比如从媒体开发转向游戏开发，因为没有系统的学习过，他们就束手无策了。我们普遍认为，程序员年龄越大，经验就越老道，掌握的语言就越多。事实又是怎样的呢？雷欧和阿里在试验中发现，多数程序员都掌握了3至4种程序语言，但当他们到了35-40岁时，很多人就会步入管理岗位。脱离了编程一线，学习新语言的动机和机会就大打折扣了。马耶若维奇认为，他们正在研究的这个课题十分重要，关乎整个行业是否能够高速和健康地发展。他和拉布金把实验数据都发布在网络上，希望他人能够给出新的视角，同时为如何解决这一问题提供建议与帮助。英文出自：
【转】做产品
首先想向各位关注我的互联网/移动互联网创业系列博文的人们表示感谢，同时也跟大家稍微道歉一下，最近很忙，第四期的互联网/移动小团队创业隔了这么久。正好我和我们的项目和助跑计划的团队有个交流,有热心的同学把我说的记了下来，我就整理了一下，去掉一些内部内容和数字贴在这里。
&今天的主题是信仰，愿景，极致，有爱。
最近大家创业都有了一定成绩，都发布了产品，大部分都获得了不错的用户增长，甚至有4，5个团队用户数增长的连服务器都跟不上。这是好事，但反而不少团队在这种状况下陷入了迷茫，不知道如何保持自己的成绩，如何继续完善自己的产品，面对五花八门的用户回馈，新出的机会，新出现的竞争对手，方向也不如一开始坚定了，开始战线拉长，不必要的功能和bug增多，有了成绩后，有的团队的冲劲和果断也降低了，变的保守。
在前一段时间我和大家更多的是强调快速原型，快速发布，快速验证，快速修改，那是在创业初期，也就是相当于我们创新工场助跑计划针对的那些项目所处阶段，更多的是探路，验证想法和探索用户。创业公司应该在有限的资源和机会时间窗口内，用很短的时间先把产品做出来，快速获得用户反馈，快速让产品去见市场，把路摸出来。这一点上，很多创业的小团队做的比较好。
可是一旦过了这个阶段，有了一定的用户群体，用户反馈也还不错，路摸清了，第二阶段就要专注的重点投入，做到极致。我们这里的项目大部分的产品基本上就已经成型了，有大量用户涌入，产品的大方向已经不可能变了。这个阶段其实我们更重要的是要把产品真正做好做细，所以这时的策略就不是再是快速探明方向了。
既然已经到了第二个阶段，这个阶段最重要的三个关键字在我看来，首先是信仰，愿景和极致。
之所以说信仰和愿景，是因为这是所有的根本，无论是战略设定，还是产品取舍。我发现很多的团队到了这个阶段会出现一个问题，用户多了，团队强了，似乎开始忘记了自己是什么，自己不是什么。开发出来的产品功能线开始逐渐变长，拉出了非常多的新功能，但是这些所谓的改进功能，新功能，反而让我看不到这个产品本来的用户和功能主线是什么。大家有时候会说，因为收到了用户反馈，有几个用户想在里面交友聊天，所以我们就要把这个产品加个聊天室，也有人反馈想做一些其他的什么事情，于是我就给产品加上个其他的什么功能。美国又出了一个新东西，我们要学一学。还有很多人向我说最头疼的是砍功能，问我如何取舍。
但是如果你的愿景和信仰明确的话，这个其实是最容易的，无论是轻易的把产品转方向，还是产品增加大量的新功能，很大的一个原因都是因为创业者没有信仰，不知道自己是什么，不知道自己不是什么，而这点是很必须的。做产品有道和术两个方面，愿景和信仰是道，方法论是术。无论是用户反馈，市场调查，运营数据之类，所有的这些东西，可以是一个真命题，因为你是要依据这个改进或者做你的产品，但是从另外一个方向讲，它是一个伪命题。比如说天下有七八十亿的人口，十几亿的互联网用户，随便做什么样的产品，后面其实都可能有几千万上亿的用户想用你的产品，无论是什么feature都能找到数据支持。所以说，最后决定你取什么舍什么，其实还是这个团队自身的信仰，自己团队的愿景，而不是用户调查。一定是先有愿景，之后才有用户调查。也就是你先要知道自己的产品应该是什么样子，或者说是想要变成什么样子，然后根据自己产品的特点才去做用户调查。因为首先，你的创新团队没有足够的能力去做一个面面俱到的巨无霸，其次，很多用户需求根本就是互相冲突的。比如图片领域，photo shop,flickr,美图秀秀都是成功的软件，但你不可能把它们混起来。 如果你的愿景是做一款手机图像分享软件，它可以让你拍照之后放到分享给朋友，最近热卖的Instagram，就是一款很棒的软件，它非常简洁，快速登陆，能在几秒钟之内选好效果做完分享。它的核心的理念是第一时间让用户在几十秒钟之内完成一个很流畅的漂亮照片分享过程。这种快速分享就是它的愿景。它知道自己不是光影魔术手，不是Photoshop，我打赌在它的用户回馈里面肯定有诸如&你们的软件支持的特效太少了！我想给我的照片加上更华丽的效果&这样的内容，但是它依然只保持了十几种特效，因为如果真的加了500个特效，photoshop级别的编辑，想要快速分享自己照片的用户第一遍登陆进去就开始玩特效，玩了15分钟之后觉得太麻烦了，就给Instagram关掉了，甚至忘了分享。反过来也一样，photo shop是给真正编辑照片的人用的，如果里面有向美图一样有一大堆卡哇伊的、绮丽的头像或者是乱七八糟的东西，用户也会马上关掉。
&甚至还有团队只是因为团队加了人，暂时有人工作量不满，或者一个功能开发很简单，成本不高而加一个功能，这更是没有愿景的体现。想一想，用户的注意力，界面空间的每一个像素尤其是手机，流畅的使用流多么宝贵，为了一个有的没的功能去增加所有用户的负担代价是相当高的。即使纯从开发上来说，如果一个功能开发只用了一个人日成本，以后维护升级可能就是10个，运营推广100个，任何功能的全程代价都是很高的。&
&当知道自己是什么，知道自己不是什么之后，所有的一切取舍实际上就是非常简单和直接了。
第二点有爱，有爱是非常非常重要的，有爱才能把产品做到极致。
对自己的产品有没有爱体现在好多方面，热爱自己的愿景，热爱自己的用户，自己的产品想自己的孩子一样，不能容忍缺陷。有的创业团队很客观的像一个科学家一样从外部去做产品，比如说因为数据是这样，那个是这样，所有的这些是这样，所以我要做这个产品；竞争对手出了什么，我觉得我们为了应对所以我要做这个功能等等。但是这样是做不出一个好的产品的，一个特别好的产品，产品的团队跟这个产品本身是二合一的，和他的用户也是二合一的。举个例子，比如说Nokia的人去做iPhone，做出来的还是Nokia，不可能是iPhone，所以你必须把自己化身成自己的用户，你对自己的产品有深切的爱，所有的数据和用户调查都只是一个外面的东西，只能让你知道这件事是这样的，但为什么？用户是这么做的，但用户这么做的心理原动力是什么？你必须首先把自己化成这个用户你才能知道为什么有这个数据的呈现，用户的追问是什么，为什么要这样做，甚至领先一步发现用户还没意识到的需求。做航班管家的同学经常去机场，甚至总结出了和陌生人搭讪和往陌生人手机上装软件的几大诀窍。马化腾作为腾讯CEO，还天天不停的在各种场合用自己的产品
这里有个同学提了hao123，问hao123产品是不是好产品。
我的答案是，李兴平是我见过的最好和最执着的产品经理。Hao123是一个产品愿景和用户定位非常清晰的产品-让互联网的初阶用户非常快和方便的去到目的网站。我们每个人都知道Hao123的网页做的相当不符合近年来人们的审美标准。我们可以很轻易的把Hao123做的更漂亮，更人性化。比如纯粹静态的页面不好看，我们可以做成动态的；纯粹文字的连接不好看，我们要做成图片的；网站排序可以是动态的，让系统自动将点击高的连接放在前面，这些都是很摩登很美的事情，而比较起来Hao123就好像20世纪80年代的美国印刷品广告。但是Hao123并没有这么做，这是因为他们很清楚这个产品是什么，用户是谁，如果你不是他的目标用户，他不会试图讨好你，他也没有接受诱惑去加这些&高级功能&。他们将自己化身成用户，问自己：我需要从这个产品得到什么？这个产品要有什么特点？如果答案是需要快，那么好，要用纯文字页面不要图片，要静态页面，页面大小限制在多少K以下，当用把一个页面设为首页的话，用户只会给你1秒，加载速度每快0.05秒，用户体验就会非常不同。如果答案是让用户很容易习惯，那么就要保持现有链接位置不要轻易改变，每个月只重新编辑或增加几个网站链接，否则用户找不到。这位同学说Hao123是个很懒的网站，从出现开始就基本没有任何变化，怎么能说对自己产品有爱？但是如果你天天看他的产品的话你会发现非常多的改进，看别人的产品要看得懂。我是很喜欢看别人产品。最早的Hao123没有分色条，后来加上了；原来上面的字体跟下面的字体是一样大的，后来才把上面的字体做成大字版，让上面的字体大了一号，后来又把上面的字体放大了一号；最早的侧边条的间距也扩大了，原来的间距要小很多；包括它的工具条的位置，原来最上面是没东西的，后来放上了功能入口。类似的这些细节的改进是非常多的，而且跟他的产品联系的非常好。Hao123是在他的愿景下做到极致的产品。
回到主题，把产品做到极致。我们有团队的确发布版本很快。有一些产品随便一用就有BUG，或者是交互缺陷，这是很不可思议的事情。只要做这个产品的团队自己用了三分钟，就可以发现这个BUG，根本不应该把这个产品发布出去。我不知道这些团队是不是拿自己的产品开玩笑，拿自己的口碑开玩笑。产品的第一批用户很多都是业内人士，他们不仅仅是用户，而且也可能是你将来的合作伙伴，是将来口碑的传播者，是会写文章批评你产品或者推荐你产品的人，所以这里面每一个BUG造成的后果都是非常严重的。我们已经过了这个阶段，要相对的做精品，用户应该是来测试产品方向和功能的，而不是帮你DEBUG的。发布有bug的产品是对产品和自己的用户没有爱的体现
当年个人开发者，如flashget，foxmail等等, 他们之前也不是产品经理，如何一个人做出好的产品的？如果你还记得，这些软件有时候一天能出好几个版本。问起来的时候，说如果接到反馈有Bug,会睡不着觉，一定要改了才能安心。这就是对自己产品的爱。
做产品要有爱，有不能容忍的心态，不能容忍用户体验不好，不能容忍我的产品有BUG，要跟0.01秒的较真，跟0.1K来较真，把自己化身用户，做到极致。这些都是非常重要的。当你对自己的产品有热爱的时候，知道自己是什么的时候，这些都自然而然地会发生。而现在大家有个特点，大家做的产品做到一定程度的时候，做疲了，之后就会单纯把自己的产品当工作去做，而不是当作自己的孩子来看待。这些问题你自己甚至都没有意识到。如果我在做手机网页的话，我会在任何情况下都掏出手机来反复查看这个网页，在家里用，出租车上，电梯里，所有不好的用户体验，我都会立即解决掉。这是我做产品的原则。
我们要把自己化身成我们的愿景，把这个愿景做到极致。不过这里有一个小问题，大家还是不能矫枉过正。在中国有一些很糟糕的现象。第一，我们很容易把将产品做到极致跟磨洋工或者半年出一个版本这些事等同起来；第二，完美主义很容易形成孤芳自赏的那种状态。大家必须明白，快速发布产品是公司的生命力和活力所在，这跟把产品做好并没有冲突，把产品做到极致不是像VISTA一样，一年才憋出一个版本，这个是很糟糕的一件事情。你不能做的很慢，小步快跑，快速迭代，才是把产品做到极致的正确方法。但是快速的发布绝不等于快速的出BUG，再说一遍，用户应该是来测试产品方向和功能的，而不是帮你DEBUG的。
另外，不理智的完美主义是很危险的事情，完美主义是有取舍的，不可能各方面做的完美，完美主义不是平均主义。比如说你可能要为了效率牺牲掉漂亮，你有可能为了漂亮牺牲掉效率，这都是没有问题的，没有对和错。出发点是你搞清楚你是什么，在此之后就可以做取舍。当你试图做到各方面平衡的完美，或者从自我满足的角度做到完美，而不是从用户角度出发，很容易陷入一种僵局，产品出不来，拼命的磨，最后出来的是折衷主义的东西，各方面都追求完美或者自我满足反而导致了各方面都不能做的很好，完全不能做出好产品。
今天我和大家说的这些，其实很简单，很多人都知道的，只是创业过程中被各种各样的琐碎事物遮住了。我的本意是跟大家提个醒，因为这些问题可能导致非常严重的后果，希望大家能够稍微重视一下。最后感谢大家能够耐心看完这篇文章。另外借机预告下，我们下一轮的助跑计划会在下个月开始再次开放在线申请，有兴趣创业的各位可以提前准备，届时提交&原文链接：http://blog.sina.com.cn/s/blog_67ens07.html&&
大公司（如腾讯）抄你怎么办？
编者按：本文作者郭子威，前网易网站产品部总监，想要联系的读者可以在微博上@纯银V。其实，这篇文章是打算写&大公司抄你肿么办？&很明显腾讯最 典型嘛，以至于我还在网易的时候，Boss也问我，腾讯抄你怎么办？此时屡屡有一股邪火在胸口燃烧着，想大吼一声：腾讯抄我怎么办？老子跳槽去腾讯！最后 我还是选择了创业。
我在网易5年，一直带业务部门，从内容总监转职产品总监，算得上资深中层吧。网易做产品的环境，放在业内大约是中等偏上，它的好处别家未必有，弊端 则是寰球同此凉热。年初跟VC谈天使融资的时候，对方大统领换了一个问法：如果网易抄你怎么办？我很吃惊地回答，如果留在网易就能把这个项目做出来，我还 创什么业？难道你以为我创业是为了发财、专权，或者给自己戴上SB风格的CEO头衔？
那么大公司到底是真老虎还是纸老虎？我得从大公司业务运作的常识说起。
▎部门背景
大公司是一个笼统的概念，由若干个事业部&大部门&中小部门&项目组构成。其中战斗力过硬的项目组是少数，王牌军不足十分之一，而水货项目组的占比至少超过一半。 我们品头论足说XX公司的产品做得很好，其实是某几个项目组实力非凡。如果不与他们正面对抗，其他组做产品也就是60出头的平均分。难道你连产品70分都没有自信？没这自信你还做个屁啊。
所以在忌惮大公司之前，先摸摸底，和你竞争的大公司项目组归属在哪个部门下面，它又是什么背景。正如我以前对某大公司很是好奇，为什么一部分业务很烂，另一部分很赞？内部人士答：因为它们分属于两个不同的事业部，一队落魄边沿化，另一队则是常胜王牌军。
▎业务关联
有些时候，你发现某大公司和你进入了同一个竞争领域。别着急，先看看做这个项目的部门，主营业务是否和该项目在同一条中轴线上。
由于野心的驱动，部门主管常常会批准一些和主营业务关系不大的，想象空间又很大的项目，妄想别错过金矿。然而这只是投石问路，买张彩票，主要的资源 仍然在主营业务线集中，更不可能忍受平缓的增长曲线（掘金心态嘛，哪怕掘到铜矿也会断然放弃）。外界看见&XX公司悍然进入XX领域&&&屁嘞，只有做这 个项目的团队甘苦自知，时间紧/期待高/投入少，不挂基本上不可能。 紧接着上一条，对大公司对手的部门背景作详细调查，或许能解除你对那个庞然大物的恐惧心。如我以前在网易门户做摄影分享社区，第一年里，有8个月分到了1 位工程师的工时；接下来一年总算有3位工程师了，其中2位又是实习生。我熬了整整3年，3年呐，才熬到基本够用的技术人员配置，那时市场机遇早已消失不 见。
▎公共资源
大公司的公共资源往往包括如下部分：UED、QA、推广位，集中调度以提高利用率。有时候运营人员也是公共资源，有时候更惨一点，连程序员都是公共资源。 虽然家底殷实，公共资源摊薄到每个项目上便很寒碜，所谓僧多粥少。项目经理可能把自己有招聘权的人给凑齐了，但他还得腆着脸找各个公共部门老大要资源，有 时是恳求，有时是苦苦哀求。
跪下来舔鞋都提不上工单的时候，我以前还使过一茅招，搞点部门经费，请前端组的同事私底下帮忙切图&&当作付费外包来对待。那时视觉稿已经堆了个把月，没法推进一步。类似的木桶效应多如牛毛，几乎每个大公司项目都会遇到，偏偏使不上力，被短板卡得上气不接下气。
即便抢到了(勉强够用的)公共资源，你还得面对分配资源的随机性问题。比如说小清新风格的产品，能分到擅长此风格的设计师吗？不能，谁空下来分派 谁。擅长小清新的设计师当然也有，人家正在别的项目组，即便那个项目恶俗，设计师也很不开心，做到一半怎可能中途离场。所以我以前跟PM说：有人帮你做就 快去烧香还愿，有推广位到手就感恩热泪盈眶，你还挑啥子挑喃？十几个部门几十个项目都闹着要最好的最合适的，你让UED情何以堪喃？
由于公共部门采用派单制，大部分人员缺乏项目归属感，荣誉感，他既无法全程参与，也很难真正融入项目组里边。座位经常隔了几百米，一周只能碰头两三 面，甚至因为参与时间短暂，就连对产品的理解也比较浅，应付完这个应付那个，&应付了事&的心态极为常见。往往只有项目经理把产品当儿子看，别人都当成牵 到自己家里来串门的邻居小孩儿。
更能理解的是，公共部门这个月做A项目的单，下个月做B的单，这个月A项目组请饭请求加班，下个月B请饭请求加班。项目上线你们倒是领功/打赏/休 假，下一个项目组又声泪俱下说这单子特别重要，非得拉兄弟一把不可。这岂不是&无穷无尽的加班&&无穷无尽的拼这一仗&？你们少来诳老子&& 曾见以前合作的设计师，私底下为自己做了款玩票的APP，比当初花两三个月为我们部门设计的APP，起码高出两个等级。当真刮目相看。
KPI是万恶的，没有KPI又是万万不能的。
所谓KPI，属于体制的一部分，也是大企业病的一部分。这个世界上不靠谱的人和项目占多数，衡量创业团队是否靠谱的标准很简单&&剩者为王。这是一款生存游戏。
随着公司活下来并且膨胀起来，自然淘汰的筛选法很快失了效。创业意味着高风险和高收益，当创业团队成长为中型公司，大公司，则个人的风险降低(收入 增加，薪资职位稳定)，收益也降低(期权减少甚至没有)，容易滋生更多轻浮的冒险，拿公司的钱去玩自己的票，修筑各种烂尾楼。如果不用KPI来制衡，十八 般瞎折腾便掏空公司资源。人家旱涝保收底薪很高的，人家从折腾中赚到了经验值，就算引咎辞职，下一份工作还能拿到更高薪水的，而你老板呢，资产耗光只能去 摆地摊了。
鉴定和约束各种瞎折腾的管理手段之一，我们称之为项目KPI，即阶段性的项目考核。在这个过程中证明自己靠谱，项目有戏，公司才会继续支持你。以我 所见，虽有不少被KPI整死的好项目，但95%以上被涮掉的，确为次品，事后一齐流泪控诉KPI之恶贯满盈，觉得失败原因是&公司不给支持&。问题是怎么 证明你和这个项目值得更多的支持？怎么证明你是有可能成功那5%，而不是注定失败的95%？
老板毕竟不是天网，他不可能什么都懂，尤其对新拓展的业务，一旦超出了高层的成功经验领域，只能靠KPI来判断项目前景。这同时意味着[要命的]公 司对项目缺乏耐心和远见。若不能看到短期数据利好，则支持度快速下降，资源供给减少，方向盘立刻打到一条名为&黄泉&的路上。预见到灭顶之灾又会干扰项目 经理的判断，往往使些目光短浅，饮鸩止渴的茅招出来，苟且保得眼前性命。
▎高层干预
刚才提到大公司对新业务缺乏耐心和远见，这根子还在公司高层身上。所谓高层，最低也是管辖几百人的方面大员，通常从VP起计。能做到大公司高层必有 过人之能，不幸人过30岁后对新领域的学习能力直线下降，再加上行政事务缠身，无法专注于业务。故而对于市场拓展，大部分高层混合了视野狭窄与刚愎自用这 两种特质，必然大量依赖KPI管理。
反过来看，如果高层瞄准了某个项目，下决心赌上一把呢，它就会得到更多的资源和宽容，初期KPI有可能压根不设，所有公共部门都围着你打转。高层力 挺可以解决掉60%的大企业病，作为创业团队，遇到这样的对手是件挺可怕的事情，还好它们只是极少数，占比不足5%。而你会因为大晴天也有可能下雨沾湿 鞋，就畏畏缩缩不敢出门吗？
何况高层的支持是一把双刃剑，他会给你喂足粮草，钉好蹄铁，同时也给你戴上嚼子，圈定方向甚至策略。那么高层指定的方向策略出错呢？恭喜，贵项目挂了。长官意志令如山，最怕长官是外行。
另一些情况下，大公司项目因为资源不足，资源错位而做砸，其实还是高层的决策影响。他认为给这些支持已经足够看清前景，若是败局，又何必豪赌下去。毕竟主营业务还赚钱嘛，还有得选择，反倒是&没得选择&转化为创业团队背水一战的韧性所在。
▎齐心协力
说句听上去挺刺耳的话，大公司里很难谈真正的齐心协力。按我的理解，齐心协力的基石不是个人素质，而是成员都适合这个项目，喜欢这个项目，自然努力 团结。可你加入某一家大公司，往往受其光环/福利/资历的吸引，有个坑就猛往里跳，其后转岗不易。做什么项目亦受到部门限制，自主权有限得很。 换句话说，参与大公司项目组的，并不是最适合，最喜欢这个项目的人，而是项目经理目前能搞到的人(调动、招聘以及公共部门派单)。甚至项目经理本人也是奉 命而为，或无奈抓阄。驱动工作的动力是职业道德，季度考核，奖金与功名，却非你对这款产品的爱。老实承认，我自己即是一例。哪怕在网易加班极多，直到辞职 出来做有爱的产品，方才觉得过去皆是行尸走肉。
而我目前的创业团队只有6个人，来自5家大公司(上市或即将上市)。你说大家放弃了高薪福利，稳定工作，来上海做一款前途未卜的产品是为什么？当然不是服了我的三尸脑神丸&&
于是我现在的项目速度比之前在网易快3倍，工作进展有规划，无管理，队员的主动性之强，内部合作的愉快与默契是过去从未经历过的。两个字：&开心&。换回大公司，那得打多少鸡血开多少动员大会啊，最后有人还在会上睡着了。
▎人多嘴杂
小团队凭什么跟大公司竞争呢？有人说是&专注&，有人说是&耐心&，有人说是&远见&。这些都对，我还要补充一点，小团队一定要比大公司犯更少的错。
这句话听上去挺莫名其妙的，大公司人才济济，小团队凭什么跟人家比正确率？回答很简单：人才济济，同时也人多嘴杂。给项目提意见的人越多，执行效率 越低，这是铁一般的定律。尤其当建议者中包括各级领导的时候，决断就更加飘忽不定。你非得考虑上司的立场，部门的立场，微妙的公司政治环境，固然不乏真知 灼见，合拢在一起便成噪音干扰。大量时间花费在报审/修改/开会/争吵/写文档/走流程上面，行动迟缓举棋难定，更增加误入歧途的概率。
相比之下，小团队的快速决策，快速行动，正好击中了大公司的软肋。一款新产品出来，大公司实权派发现它起码得2个月，看懂它2个月，立项组好队还得 花2个月。再加上市场前景不明朗，在创新者大红大紫之前，大公司愿意投入(冒险)的资源是极少的，试水而已，复制抄袭多于革新改良，保守跟随多于锐意开 拓。结果一两年过去了，创新者勇猛精进已成气候，大公司才回过神来，欲与之全力一搏。人家的前期积累已领跑市场，后来者未必追赶得上。
类似案例，多不胜数。创业者眼里唯一的好机会，大公司看来却只是1000个模糊不清的机会之一，拿捏不定。由此逆向思维的话，创业团队最好不要插入 大公司的主营业务去虎口夺食。人家苦心经营多年，凭借对这块市场的理解力和戒备心，会更快发现你，重视你，然后高层吹响号角击溃你。但你去开辟新战场呢， 大公司跟还是不跟，用多大力跟，往哪个方向走，它就很难统一内部意见。
▎基因转移
人都艳羡大公司&资源多&，所谓资源，一半是人才资源，一半是海量用户，即推广资源。然而不常被提及的是，大平台的团队基因/用户构成/用户习惯，与新项目是否吻合。或者笼统点说，大平台的资源优势是否能向新项目平滑过渡。
我一直是&基因论&的支持者，公司实权派的个人偏好，决定了团队构成与文化，进而决定了主场优势与劣势。正如APPLE在社交网络几战皆败，伟大如 Google也被Facebook压得抬不起头来。只是受到野心蛊惑，即便八字不合，大公司也会悍然进入新领域(凭什么我不行)，随后又惨然退出(原来我 真不行)。
比团队基因更令人恼火的，是用户基因，即当前用户群的构成与使用习惯。做产品经常遇到&跨域&这个问题，借势推广也一样。新项目的产品诉求，用户构 成，如果和母体在同一个域内，则资源优势平滑过渡，对竞争者是致命的杀伤力。但其实&&平滑过渡又是一件特别不多见的事情。有时新项目整个的跨域，比如腾 讯做拍拍，做朋友，导入损耗率惊人；有时大平台向垂直市场细分，无法精准过滤推广目标，导入用户良莠不齐得厉害，对于重视&气质、氛围&的垂直市场则是拔 苗助长。
以我之前做网易摄影为例，不推吧，在大公司做产品跟创业有多大区别，生怕浪费了资源。推吧，不搭边的人路过都来踩一脚，各种低端用户、自拍用户、审 美低下热情万丈的中老年用户蜂拥而入，氛围混乱，运营成本指数级上升，最终受困多过受益。反倒是独立摄影产品如图虫，用户气味相投而来，自然增长营造的社 区气质远胜从大平台引流，气质恰恰又是社区的核心竞争力。
做产品，鲜有一夜暴富，尤其UGC，口碑带动增长才是最稳健的方法。道理固然大路货，KPI压力下却容易急于求成。母体供血一旦大量掺水，相当于修 炼邪道武功，起步快而后力不济，很快会触碰到天花板。这时大平台所谓海量用户，反倒成为盛满鲜花的陷阱，涂抹蜜糖的慢性毒药。好似小时候四环素治病，长大 后灿然一笑露出满口黄牙。
总之，在大公司里做产品的雷区多多。与内部环境作战所使的力气，往往占到血槽的2/3强，只留下不足1/3去对付市场。它抄你，不见得就打得过你。 它是个大家伙，但也喜欢把两个脚拇指绑起来走路。在多数情况下，大公司的新项目只是全身挂满钻石镣铐的，虚弱的巨人，被它抄死多半说明你太逊色，而不是大 家伙太凶恶。 不过，这个行业的主流论调并不这么看。
最近几个月，各式各样的人纷纷来问我，既然立志创新，大公司抄你怎么办？
对这个问题，我有各种具体的回答，但都不是真心话。只是面对某些人，比如投资人的时候，你跟他讲虚的，会被当成喷子，得表示我有明确的对策&&其实对策易变，反倒是&产品哲学&这类虚的东西更加恒定。
我真心的态度可以用三次自问自答来概括。
1、我的产品质量能不能打败跟随者，至少是与跟随者各擅其长？
如果做不到，这不是我被抄的问题，是我太挫，我认栽。竞争会刺激我提高产品质量，未必是一件坏事。
2、假定产品通过创新，打开一个新的细分市场，这个市场是否足够大，大到可以容纳下多个竞争者同时生存？
如此则对手亦是队友，我们一边互相作战，一边共同开垦荒地，联手培育市场。即便最后我只拿到第三、第四的份额，也不错啊，谁规定创新者就非得独吞整个市场不可&&初夜权不等于占有权，市场又不是从一而终的贞洁牌坊。
3、除了用户口碑之外，产品是否有具象化的的价值沉淀？
比如黏性强的用户关系，比如用户留存的他看重的内容，比如有忠诚度的优质内容发布者，比如含金量与时效性较长的信息。这些沉淀即防御壁垒，从产品架构阶段就应该提前考虑，决定了防守反击的难度。
所以别人来不来抄这种事情，我从来都是不大关心的，偶尔想想，从不忧虑。周鸿祎有句话说得很好，少盯着对手，多研究用户。一天到晚担心&腾讯抄我怎 么办&？担心有屁用啊，万一产品做得不好，腾讯抄都不屑于抄，那得白白浪费多少脑能量。我只管埋头做自己的产品，洪兴罩我去战斗~
换个角度看，哪怕比较倒霉，很快被大公司看得起并临幸了，对手在高层力挺下全力以赴地复制并改良，它的基因刚好又平滑过渡&&那么，我挂了。但产品 创新若是如我所愿地打开某个细分市场，改善某类用户体验，作为始作俑者，老子倾家荡产，虽败犹荣。&小小改变世界&比&赚到一千万&更值得追求。
正如我在微博里所说：阻挡你创新的是&无能&而不是&抄袭&，鼓舞你创新的是内心骄傲而不是永远独占鳌头。
程序员都是乐观主义者
程序员是我遇到过最乐观的一群人。当问到他们一些事情将会有怎样的走向的时候，他们总会告诉你还有一段路要走。这不是因为他们讨厌你，或者是他们根本不知道，而是他们对任何事情都抱着乐观的态度。项目，技术，以及许多未知的未知。特别是这未知的未知，这是不可能预测到一切的问题的。总是有太多的变数。当时我们觉得可以1，2个小时解决的问题，但忽然要要花费一整天。作为程序员，我们总是假定最理想的情况，即使是乘以Pi。还有另外一种职业，也要面对很多不确定性，要做很多预测，那就是医生。医生做出了错误的判断，人们却常常感到很开心（吐槽）让我来跟你说一个程序员的故事。我的任务是网页上的分割算法。要将一个网站，决定哪些部分是标题，侧边烂等等。这是一个有趣的事情，因为每个人只想获取内容丰富的部分。该算法终于在这个星期的早些时候，可以将返回的结果与HTML结合显示。星期五早上的时候可以完成，我说。我没觉得这很难，只是我讨厌JAVA，从来没使用过，还有2个星期时间去钻图书馆。当然我可以在周五完成这个对于我来说不怎么熟悉的任务，这是出于我对此的评估，我已经做程序员好些年了。结果，它没有完成。我花了很多时间在扩展某些对象的功能函数上。后来我发现我使用的HTML解析器是线性的，所以没有方法来判断子节点从属于哪个父节点。在最后，我用了所有的时间，用最原始的方法将算法的结果加入到HTML中&在DOM里面，每个节点前加一个数字编号。悲剧！！
程序员是乐观主义者每当你跟一个程序员谈话的时候，要记得，他们是最乐观的一群人。是的，即使是最心灰意冷，衣衫褴褛的老程序员也是出奇的乐观。我们要面对：深入到项目里面，规范都要改变用未知的工具，应用于未知的领域每个不同的项目，都是不同的世界每隔几年工具就要更新作为程序员，如果不乐观，就会被淘汰。其他行业的人，又有谁可以这么说？
【转】“牛逼”项目经理
&&&&&&& 如果一个技术出身的项目经理，基本上不懂什么项目管理理论，也没有多少项目管理经验，却可以将一个中途接手并且项目成员流动性很高的，近人的项目，管理的井井有条，并且最终成功拿到回款，这样的项目经理是不是很牛？不管你是什么感觉，反正我是觉得这是我见过的最牛的项目经理。
&&&&&&& 下面就详细说说这个项目经理和这个项目的故事。
&&&&&&& 按照惯例，先介绍一下这个项目经理。
&&&&&&& 他从工作开始，一直做得是技术工作，后来对日外包项目的的工作，主要的工作内容包括部分需求，但主要是概要设计和国内开发和设计人员遇到问题的解答及上线之后的测试。在接手该项目之前，有人说他做过一个项目的项目经理，有人说没做过，也有人说做过两个项目的项目经理，总之，最高不会超过两个。至于项目管理理论知识，我不太清楚一个连&基线&是什么都不知道的项目经理，能有多高的理论水平，但想来不会太高，而且在实际中也没听他说起过什么理论。
&&&&&&& 接着介绍一下在他接手之前项目的情况。
&&&&&&& 项目是对日外包项目，人员个左右，国内开发团队人数最少的时候不太到，人数最多的时候大约。他接手的时候，大约有人，分了两个组，一部分以设计和集成测试为主，另一部分以开发和单元测试为主，每个组一个项目经理，他主要负责开发和单元测试组。在他接手之前，该组曾经有过两任项目经理，第一任项目经理在项目组第一次返工，用掉个星期的，并被逼着做了很多次总结之后辞职，第二任项目经理在接手不到一个月之后提出辞职。之后，他进入了项目组，并逐渐接手项目组的工作。
&&&&&&& 开始的时候，公司的高层对他很是不放心，公司副总每天跟项目组成员一起工作，一直坚持了两个周左后；之后改成参加项目组的所有会议，坚持了也有差不多两个周；再之后，改成选择性参加会议，频率较高；再再之后，频率逐渐降低，最终几乎不再参加项目组的任何会议。这个过程，也从一个侧面展现了他的实力。
&&&&&&& 他的故事还很多，以后会一个个地讲给大家。
&&&&&&& 他所管理的项目团队中，有个人的工龄超过年，其他团队成员工作时间最长的工龄也不超过年，差不多的团队成员都是刚从学校毕业的大专学生，当然都是软件开发相关专业的，在上岗之前进行过一个月的日语培训。
&&&&&&& 他所处的公司，是刚刚成立两年的小公司，公司员工不到，公司的规章制度、质量体系文件等都是装订成册锁在柜子里的，根本就没有人知道是什么内容，当然，质量管理部写这些东西的哥哥除外。
&&&&&&& 好了，背景交代完毕，下面正式开始讲他的故事。
&&&&&&& 故事一：公司领导直接干涉项目组成员工作
&&&&&&& 这个问题}