@iamfox
2015-08-15T13:51:08.000000Z
字数 7501
阅读 1618
IT界有个很著名的段子叫只差一个程序员。大概是说创业者们在向技术人员介绍自己的项目时往往会这么说：我们有个很好的主意，市场前景广阔，我们有靠谱的营销团队，有人脉，有多年的行业积累，只差一个程序员把我们的想法实现了就能成功了。
只差一个程序员，是非技术人员对程序员最深的误解，也是最低级的认知错误，这句话在IT界就是个笑话，原因下面再说。
当然，一般人对程序员的误解远远不止这一点，所以才有了这篇文章。
经历过互联网创业的人，慢慢会意识到程序员是个生活在不同次元的神奇物种，永远都有隔阂，不知道他们忙碌的表象下隐藏着什么。
而程序员这个群体，大多不擅表达，即使有极少数人想要写些关于程序员是怎么工作的这样的科普文，也往往因为太以自我为中心，写成了给想要加入程序员群体的小白看的学前科普，而不能换位思考，站在业务人员的角度去阐述程序员的工作实况。
这次我也斗胆尝试下，能否写出一篇真正为非技术人员所理解的，关于程序员工作的方方面面的介绍，以减少互联网开发中因为代沟形成的团队内耗。
曾几何时，软件还是一个比较简单的东西，比如一个日历，一个播放器，于是就有技术大牛开始涌现，用很短的时间，一个人就做出了流行的软件。
但是到了互联网时间，各种各样的网站系统越来越复杂，如淘宝，软件开发从作坊式工作，变成了一个系统性的协作工程。
仅从一般性的技术团队的职位上划分，现在一个综合型网站至少需要下面这些人：
产品经理、架构师、UI设计、前端开发程序员、服务端开发程序员、移动端开发程序员、DBA（数据库管理员）、服务器运维、项目经理。
如上，一共有将近十个不同的专业方向，就从事技术行业的人来说，大多数人只熟悉其中一个领域，已经是不愁吃不愁穿，能养活全家人。而对架构师这样的引领技术团队的人来说，则需要熟悉若干项，至少要有对每项都有所了解，同时又得避免因为一知半解做出错误的决策。因此架构师是一个大型项目中最重要的技术角色了。
那这些人到底是怎么分工的？我们得做个类比。最接近于软件开发的工作，大概是建筑行业，我们可以用盖大楼来比喻。
小软件是小房子，几个工匠可以搞定。
大平台是摩天大楼，盖摩天大楼会有什么人参与呢？
建筑总设计师 – 产品经理
建筑工程师 – 架构师
设计外观的建筑设计师 – UI设计
装修施工人员 – 前端开发
盖房子的施工人员 – 服务端开发程序员
另一种技术的装修的施工人员 – 移动端开发程序员
负责地基、下水道等基础设施的维护人员 – DBA
负责大楼质量保养的维护人员 – 服务器运维
项目经理 协调资源和工作
以上，了解了这样的分工，当你想要做一个互联网项目的时候，你还会再说只差一个程序员吗？
当你千辛万苦，花费了不菲的价钱，终于凑起一支技术团队时，你最关心的当然是什么时候能把你想要的东西做出来。
你会花上很长时间，涛涛不绝地向技术人员描述你的设想，完了最后补上一句：你们什么时间能做出来？
如果负责任地回答，任何项目经理，架构师都不应该立即答复。或者只能说，大概X个月到X个月这样的模糊答案。
评估软件开发的工期取决于什么因素？太多了。
举个小例子：我需要用户注册登录功能，听起来很简单。那要多久能开发出来？
如果输入用户名密码就OK，可能一个程序员开发一天。
如果想要通过手机号、邮箱也能登录，可能开发两天。
然后还想要用QQ、支付宝帐号也能登，可能要三五天。
如果这个帐号要在登录服务器时把手机端挤下来，又要加一两天。
如果想要记录用户的每次登录，还想分析下他的登录位置，可能又加两三天。
如果最后还想我们的帐号能不能像QQ登录一样也开放给别人用，让别人也能用我们的帐号在其他网站注册登录，可能要半个月。
结果，注册登录这么一个简单功能，可能一天，可能数周。你能想象到那些复杂的交易功能，工作量会有多大的变数吗？
我还没给你算一算如果要做成支持10万人在线和100万人在线有多大的工作量差别，如果要做成以后想加功能就能加和一次性做好就再也不好改了有多大的工作量区别，要做成一年内有10%的机率出现宕机和1%的机率出现宕机有多大的工作量区别。
另外，这个功能需要产品经理、UI、前端、服务端多个角色协同开发，谁在忙更重要的事，谁会遇到了技术难题，都会导致开发周期不能按计划走。
结论，能直接回答多久能做出来的技术人员，都是在敷衍。到时间做不出来了怎么办？如果领导能听得进去，就把责任推到需求一直在变，外部配合不到位头上。如果领导听不进去，就直接偷工减料，只求表面效果完成。
在由非技术型领导说了算的开发项目中，优秀的项目经理和架构师，都是在避谈细节、取舍短期内影响不大的功能，对人力资源最大效率的调度中寻求到最佳平衡点，既要满足大体需求，又不至于出现严重的问题。
在领导问他什么时候能做出来的时候，他一般没机会长篇大论去解释为什么他估不出时间，否则会被领导视为不敢担当，不堪重用。少解释不一定是没有想法，只是想把精力留给干活。
慢工出细活，最终作品是苹果手机还是山寨机，时间和人力投入是大致成正比的，这是铁律，不是加班或者死命令所能改变的。
在讨论对技术人员的工作考核之前，我们要先从头来审视下软件的模式。
软件开发大致经历了这么几个过程:
1、 想到哪做到哪，没有计划
2、 计划到极致，考虑周全，再动手
3、 只做总体计划，考虑出现变化的应对，快速实现短期目标。
第一种是瞎搞，不值一提，后两种，都是在用心工作的方式表现。
第二种叫瀑布式开发，第三种叫敏捷开发。
瀑布式开发是传统方式，基本就是从建筑行业学来的。先设计好图、流程、细节，每个功能，每个操作，事无巨细，然后定案，大家照着文档开发代码。
瀑布开发努力想在开发前考虑到一切问题，设计到每一个细节，把大量的精力投入到前期设计。然后排出了精确的量化计划，这个功能多少天，那个功能多少天，完了就做成了。
但是事与愿违，没有任何一个大型项目能够在长达数月的开发中没有任何需求变化，没有超人架构师能够考虑到一切细节问题，如果你的计划满满当当，今天做这个明天做那个，任何意外的出现，都会让你陷入混乱。
再看看敏捷开发怎么搞的。
不做精确的按天排期，只设定一个阶段目标。阶段周期之内，我们会讨论一批需求，设计和开发一批功能，改进一些问题，发布一个新版本。
这个周期看不同产品而定，比如小米的MIUI是一周，手机QQ大概是三个月。通常应该在3周左右为中值。
快速实现，快速沟通，不追求极致的细节设计，而是遇到问题及时反馈，立即讨论解决。强调了工作过程中的交互和反馈，而不是自上而下的命令式的事无巨细的按设计来工作。
更重要的一点，敏捷开发要拥抱变化。开发过程中发现问题，设计要调整，需求要补充，大家要及时讨论并统一意见放弃哪些功能，优化保障哪些功能调整。
经过如上对比，可能大多数人都会认为，敏捷开发才是王道，事实上软件行业的主流思想也是这么认为的。虽然在执行敏捷的过程中，不同团队有不同的执行方式，但是都强调了要灵活应对不能死板。
当今世界上还在坚持瀑布开发模式的典型，就是对日软件外包，日本人至今仍很奉行命着非常详细的设计书让码农们照搬，精确到一个按钮的作用的方方面面。因此，做过多年对日外包的程序员技术能力和价值往往会落后于同辈，而日本在整个互联网行业，开发领域也无甚建树。
讨论完了大局（开发模式），接下来该介绍程序员的类型了。
会成为程序员的人，大至就是以上这几类，当然人是一个复杂的综合体，多数程序员都是以上几类特质的综合体，有的方面突出些，有的方面弱一些。
在我个人所接触到的程序员群体来看，以上几类人几乎平分，并没有哪一类人群占主流的感觉。
首先要说下程序员偷工减料的目的。除了懒惰型的是为了偷懒而偷工减料，其他几类程序员也有不得不偷工减料的时候。
最常见的莫过于对他们期望过高，在没有量级的技术差距的情况下，5个人鼓鼓劲，在泄气以前能顶8个10个人，但是要顶10个20个人，小马拉大车，除了偷工减料别无他法。
淘宝这种大团队，有时候投入了三五个年薪数十万的高级开发人员，对底层算法、技术框架做了数月的技术改进，成果可能就是让网站的某些部分响应速度提升了个10%到20%而已。
毫无疑问，一般的公司会毫不犹豫把这种工作给省掉，因为追求这点提升的投入产出比对中小公司完全划不来。
上面这种偷工减料没什么大问题，但更多的就会开始埋下隐患。
比如一个功能，做得灵活点，可能需要三天，但做得死一点只要一天，逼急了肯定选后一种。等到要改的时候可能就要多花三五天，甚至改不了了只能重做。
再比如一个功能，做得稳定点，一年里只有1%的机率会崩，需要三天，做得粗糙点，一年里10%的机率会出问题，只需要一天，逼急了一定是后一种。
再如一个功能，代码写得漂亮整洁点，层次清晰，要三天，写得乱点，管你以后谁看，只求实现，只要一天，逼急了肯定是后一种。
这些状况的共同点就是，一时半会不会有问题，出问题了也不一定还能再怪到你头上，因为出问题的原因往往是综合性的。还有，做好做坏，除了时间不同，非技术领导根本无从评价，不会给你什么奖励，能评价你的人往往没有权力因为你代码写得漂亮给你奖金，而且有用没用结果是个概率性事件，见效太慢。
所以为什么10个人的电商网站开发团队，如果要做同类应用，和京东、淘宝绝对是全面的技术差距，人力和技术水平都是全面差距，成果自然也是全面差距。他们都有4、5位数的技术人员，仅一个余额宝，就是阿里、天弘投入了100多研发人员，历时三个月加班加点做出来的，手机QQ背后有1600人的产品和研发团队在支撑，一个美团网就有过千人的技术团队。
的确也有小公司人很少做得体验很好，比如天天果园，但是他们的应用简单啊，业务模式、运营层次、供应链相较传统电商都极其简单，开发难度也就不在一个层面上。
如果10个人做出来的一个电商应用，功能差不多，体验差不多，性能差不多，那京东淘宝的CTO早该被拉出去烧死了。
话说回来，所有大团队都是从小团队成长过来的，淘宝成立之处也曾经只有几个开发人员，但是当年的淘宝只是个很简单的网站。
真正的矛盾在于在技术团队还弱小的时候，却匆匆启动了巨大的综合性平台级项目，结果不一定只是进展慢，地基处理不好将导致项目全面崩塌只能推翻重来。当我们回过头来，想要集中精力解决一些突出问题时，常常难以纠正，因为当初地基就没有打好，本来应该很容易改善的问题，在这样的背景下变得难以优化。
先转载一篇很有代表性的文章：
蔡学镛：KPI心理学
阿里巴巴集团大部分的员工，每季或每半年都要接受一次的KPI考核，看看他绩效如何。关于用KPI来打考核，许多员工其实都有一些负面的看法，而管理层也知道采用KPI有时候会有负面效果，但是没有更好的方法之前，我们还是仰赖KPI。我已经到阿里巴巴的支付宝上班一年多了，对于KPI，我有四阶段的心理变化，值得描述一下。
刚进公司时，我对KPI的重视程度是70%。大多数的时间，我做的事都是KPI设定的任务，有些事情，虽然不是KPI关注的任务，但只要对公司有利，我依然会去做。这是第一阶段。
后来，我对KPI的重视程度降低到30%。大多数的时间，我做的事都是对公司有益处的事，至于是不是KPI的重点我就比较不在乎了。这是第二阶段。这是对公司最好的阶段。
接著，我发现做正确的事会导致自己的KPI不好，无法升迁，于是我开始变成100% KPI导向。只要不是KPI的内容，我就不愿意做。这是第三阶段。公司把一个员工逼到这个阶段，是很可悲的，对公司也是一个伤害。
第三个阶段不会持续太久，会立刻变成第四个阶段：对KPI重视程度为0%。这表示对于自己在这家公司的前途已经不在乎，准备开始找工作了。我现在正在第四阶段，至于会不会有第五阶段，我就不知道了。
70% -> 30% -> 100% -> 0%，你在哪一个阶段呢？或者，你有不一样的折线图呢？
===================================================
描述非常地贴切，不只是技术人员，可能很多岗位都是如此。
领导层可能会有疑问：为什么阿里的KPI制定被描述得如此不堪，但项目开发还这么成功？
钱，阿里系上万人以上的技术团队，平均薪资一两万，一个月发工资就发掉过亿。
流动性市场，阿里拥有足够号召力让新的技术人员源源不断地进入补充，很多公司没有这个号召力，只会出现人才断档。
我对KPI的看法是：如果一个团队在多数人都在混日子，庸才多于人才的时候，KPI给予了方向的指导，鞭策了大家的前进，是有益的。如果一个团队人才济济，大家都在用心工作时，KPI束缚了大家的手脚，歪曲了大家的价值取向。
所有的团队都有能人，有拖后腿的，如果用同一个标准，同一个制度去对待，在约束了懒人的同时，也挫伤了能人的积极性，与其用鞭子抽着大家前进，不如换血。
说完了大道理，还是回到程序员身上。
首先程序员是群比较单细胞的人，从面试入职起就懒得去弯弯绕绕，所以他们提了薪资8千，1万，1万5，潜意识里就认为，只要我做好本职工作，我就该拿到全额薪资，企业想要分什么固定工资岗位工资绩效工资，一概懒得深究。
程序员是个上帝模式的职业，每天的工作都是在创造，不知不觉中也就产生了一种自负心理，如果有一个不是技术人员的人来给他们制定考核标准，会产生强烈的逆反心理。因为他们不认可非本行业的人有权威来评价他们的工作。
再次，程序员不爱与人较劲，如果他遇到一个技术难题，他可以不吃不喝死磕进去，非要把它解决不可，但是遇到人的因素阻碍，比如没人给他准备张银行卡做测试，合作单位没有回复邮件，他们往往会搁置工作，问都懒得去问。
这种性格对KPI的影响就是，你哪怕放权给他自己去制定奖惩措施，他也懒得去争取，因为即使定出来，还要花很多精力去和领导解释，证明他做到了，这些都是他们不爱做的事。因此不求有奖，也不要拿些我不认可的标准来扣我工资。
一个事实是：千儿八百的浮动，对习惯了高薪的多数程序员来说并不放在心上，多给了也就带来三分钟热度，少给了，忍忍就过了仍然我行我素。他们内心深刻地认为，只有坚持自己的工作方式，专注于技术，才能提升自身价值，有美好未来。公司不认可并不重要，只要做好了大家看得见的项目，提高了技术水平，别的公司自会开高薪。如果程序员落到老是和公司计较这点钱，他也就成了不思进取，只想安稳度日的那一类人了。
我带过不少技术团队，也经历过不少高潮低潮，以我所总结的经验来说，有几种情况能让程序员们情绪高昂，大幅提升工作效率。
1、 公司制定了一笔不菲的奖金，说你们只要在某某时间做出这样那样，这钱就全是你们的。这种方式往往有效，但有某些情况除外。比如这项任务需要程序员处理的非技术状况太多，什么需要合作单位，非技术部门深度协助之类的，一旦让程序员觉得超出了自己掌控，就作罢。
2、 公司决定推翻程序员早已抱怨不已的老系统，说要做个更NB，更受人喜欢的新系统。这种事能让好的程序员打上一针兴奋剂，精神状况大好。前面说了，程序员是个上帝模式的职业，出自自己手中的新系统才叫创造，能有机会尽收别人的赞赏，改老系统就像收拾残局。
3、 工资普涨。经历了一年的工作，大家对公司业务，协作流程，技能水平都有了或多或少的提升。普涨体现了企业对大家这一年有进步的认同，不涨，则相当于评价他这一年白干了，请个新人也和你差不多。
4、 公司找到了程序员们都认可的技术权威来带领团队或做为顾问团向管理层进言，合理评价他们的工作，理解他们的难处，给了他们更大的发挥空间。
最终，程序员还是要量化的，没有量化就无法评价。
量化要考虑的问题：
度：过严伤积极性，过松形同虚设。度定得不准一定弊大于利。
代价：投入的检查、监督、追踪的人力管理成本和对员工精力的内耗，是否抵得上量化KPI带来的价值提升。管理成本代价过高就是投入产出不符，不如放任。
无论是工作时长、代码行数、交付速度、BUG数量，都不能做为衡量单位。
因为工作时间长的可能是笨和拖延，工作时间短的可能是偷懒。
代码行数多的可能是实现方案不好，代码行数少的可能是偷工减料。
交付速度快的也可能在偷工减料，交付速度慢的可能是水平和态度不行。
完成任务多和少，与交付速度一个道理。
BUG数量多可能是因为功能复杂时间紧，BUG数量少不代表将来不会出现重大问题。
这些东西，事实上都不能做为衡量程序员的主要指标。
能衡量程序员成果的，只有他的技术实现方案和代码质量，这两方面都好的，如果完不成工作，一定是外部原因。这两方面都差的，工作时长，代码行数，交付速度都是浮云，无论怎么样结果一定不能给公司带来好处。
那评价程序员的技术实现方案是否合理，代码质量高不高的难点在哪？
一是前面说了，时间有限，要取舍，不可能人人追求极致，那样没效率。
二是评价方的权威性和权力制衡，一个人负责考核的指标制定、检查工作，无论公正性，还是透明性，都是不合格的。
三是管理成本，要投入多少人力才能够充分判断每个人的方案和代码质量？也许投入的人所损耗的生产力还要高于考核所带来的生产力提升，又回到了度的问题。
正如艺术家的工作和价值不可能去量化，而生产线流水工人的成果很容易量化。好的程序员，好的项目，又正是一种处于两者之间，又更偏向艺术家的，以创造为职业的工作，注定了不能用条例去量化工作。
领导层不妨尝试和员工代表、技术管理层、外部专家顾问团等多方定期进行访谈，以表现打分制，交叉比对得出综合评价。