摘要：
有一句古语“少壮不努力，老大做IT”，做IT确实挺悲剧的，但最悲剧的是做码农（程序员）！烂代码直接产出来软件，而烂代码是怎样产生的呢？是烂程序员吗？大部分程序员是追求进步和高质量代码的，往往是烂的管理方式、无节操的项目工期而导致程序员不知所措、疲于奔命、为赶工而写代码。当加班成常态，你还跟我谈什么代码质量呢！
什么叫挨踢项目？
IT项目，特别是软件开发项目，都属于“挨踢”项目的范畴。挨踢项目的几大特点：
1.需求不确定。
2.技术不确定。
3.工期限死。
4.预算限死
两大不确定和两大限死，你想不“挨踢”都难！
“无节操”的加班
某公司有个加班龙虎榜，每周按照加班的总时长进行排名，加班时间最多的就是状元，然后是榜样、探花。其实没有谁这么变态要打进三强，但大部分人不想自己经常出现在榜尾，因为让领导看见了不是很好，有可能会导致饭碗不保，所以只能“自觉”加班！于是加班成了家常便饭……
某创业公司的老板搞了个“奖罚分明”的激励制度，任务分派下来如果能提前完成，提前时间越多，奖励越多；相反，如果任务推迟完成，推迟越多惩罚越多。结果大家都懂的，这些任务基本都是 mission impossible，“提前完成”需要人品大爆发，“推迟完成”是正常现象，程序员们的薪金都被扣得差不多了，再推迟的话就要倒贴公司了！
一个人一天当中，能高度集中精神的工作时间有多长呢？你可以自测一下，我的答案是6小时，偶尔可以爆发到7-8小时。
如果不用加班，按一天工作8小时算，如果其中有6小时能高度集中精神工作，其实已经很不错了！
如果加班呢？我告诉你，原本还有6小时的高效工作时间，马上就会减少！加班越长这6小时减少得越多，如果加班时间家常便饭，那么这6小时就会变成零！
软件研发不是体力活，是高强度的智力运动，希望管理者要清楚明白这个软件研发的客观规律，我们不能违背这个自然规律。低效率的加班只能是一种心理安慰（这个心理安慰只对领导有效），只能带来更多的问题。
“奔放”的项目管理者
领导要K人，一般会把要K的对象叫进会议室，然后关上门来K，开门后就好像没有发生过任何事情一样，门外的人一律不知道发生了什么事情。（PS：这里说的K不是指打人噢，而是批评，俗称骂人。）
但是有些领导很“奔放”，直接当众K人，有些邮件K，但这个邮件会抄送项目组全体甚至全体员工！我运气比较好，还没有遇到过“奔放”老板，但万一你运气好，遇到了被领导“奔放”地K了一顿，你会怎样呢？当然你要这样想：这个领导其实算不错的了，在“阳光”下K你，如果他来“阴”的，岂不是更恐怖！
闷骚、腼腆、脸皮薄、心灵弱小，是程序员的特点，一般的程序员是接受不了“奔放”的管理模式的……
保命四招
如果你遇到“极端情况”，后面介绍的法则都不会适用，你要用的是这保命四招。
什么是“极端情况”呢？
那就是类似前文提到的“无节操的加班”和“奔放的项目管理者”这些情况，当然不限于这些情况，因为没有最惨只有更惨！
以下是保命四招：
1）抱怨有益健康。
有人说抱怨没有用，但如果不抱怨你会憋死，所以你需要宣泄，你可以约朋友吃饭喝酒齐齐诉苦，这样才能有益身心。但要注意抱怨并不能解决问题，不要沉迷抱怨噢！
2）忍一时风平浪静，退一步死无全尸。
工作中遇到不公想发作，你一定要用第二招：忍一时风平浪静，退一步死无全尸！要忍但不要退，要用耍太极的方式来推挡一些事情，不要累死自己便宜了别人。
3）自我增值才是硬道理。
增加你的价值就是增加你的谈判筹码，这就是第三招。我曾经和领导直接电话对骂，我居然没事，因为当时公司需要我完成这个项目，我有恃无恐！你可以尝试在公司爆发一下，测一下你的价值，如果爆发完你没事，说明你对公司的重要性不错。但如果出事你不要找我噢！我当年敢干这些出格的事情，是因为我年少无知、血气方刚，并且自以为自己很牛B！自我增值让你有更多选择，能帮助你选择更好的工作。
4）我只想将工作做好！——这不可取，因为这是你辛苦的根源。
在“极端环境”下，好的工作态度是不受欢迎的，只能变成折磨你自己！做好工作不是你一个人的事情，我们没有这么强大，我们只能顺势而为。很多事情我们改变不了，但我们能改变自己。我不是鼓励消极的工作态度噢，这是在你因为各种原因还不能选择更好的工作机会时的过渡方法，有好的工作环境时，你就需要重新树立“我要将工作做好”的态度！
面对“极端情况”我也没有什么好招，前面的内容实在是太多负能量了，实在有点“儿童不宜”！
下面将会介绍“正常情况”，“正常情况”当然也会存在很多问题，但这些问题都是有机会解决的，后面的内容都是正能量滴，是“老少咸宜”滴噢！
牺牲质量能提升进度吗？
项目管理基础知识中提到，项目管理主要管成本、进度和质量，我们不可能用很低的成本、很快的进度和很高的质量来完成项目，也就算俗称的“多快好省”地完成项目是不可能的。我们的软件项目成本是卡死的，进度也是很紧的，所以我们只能稍微降低质量来保证进度，这样的逻辑合理吗？
实际工作中我们其实就是进度优先，但仍然有很多加班。忽视质量其实并不能带来更快的进度，而是更多的加班！
我们为什么会加班？我们的加班大部分原因是要返工，或者是前面没有发现问题后期问题才爆发，简言之就是前面工作质量不过关，导致后续更大的工作量。工作质量包括需求的质量、设计的质量、代码的质量等等。重视质量反而会加速项目进度！我们需要定下项目的基本质量要求，想清楚才动手，一步一个脚印地做好项目。
代码的重要性
我认为项目中是两类文档是必须的，那就是需求和代码！有人可能会更绝，必须的文档只有一种，就是代码！没有代码就编译不出软件，其他文档可以不要，但代码必须有。而程序员是写代码的，非程序员是写其他文档的，所以除了程序员，其他角色也可以一律不要。其实上述说法是成立的，我曾经试过只有我和另外一位程序员的情况下，不需要其他人就我们两个程序员，我们就能做好一个软件并且这个软件的销量还可以。
代码及代码的质量其实是相当重要的，但很多项目可能是这样的一种现状：不抓代码质量，软件问题多多，但一抓代码质量，项目马上就会死翘翘！
如何解决上述困境呢，下面的求生法则可能有用！
法则1：问题根源80%在于需求
程序员的工作职责是什么？这个是单选题，你选择哪个？
A）写代码；
B）完成领导分派的任务；
C）实现自我价值；
D）实现客户价值；
标准答案是：D
客户价值就是通过需求来体现的，不要扎头就写代码，要弄清楚需求。需求文档其实是必须的，不过文档的载体和格式是不限的。
法则2：拒绝需求变更
某项目原定一个月发布某版本，但这个版本延迟大半个月还是发不出来。原来客户喜欢提需求变更，并且越接近发布日期，变更的要求就越多，客户希望这个版本包含的内容越多越好，而项目组为了不得罪客户答应了这些要求。不要怕得罪客户，要拒绝这样的需求变更，我会跟客户这样说：欢迎需求变更，但这个版本不考虑，下个版本再考虑。
这个法则并不是要你拒绝所有需求变更，而是某个一迭代中要实现的需求是稳定的，不适合再改的。盲目顺从客户最终并不会让客户满意，而程序员们因为要应对这些需求变更，需要反复改代码，这样是很打击士气的。
需求变更是不可能没有的，我们需要：
1）检讨需求分析的工作质量，请留意法则1；
2）原则上要拒绝当前版本的需求变更，下个版本再考虑；
3）万一遇到重大的需求变更确实需要马上实施，那可以停掉当前版本重新规划，一定不能用“逐步添油”的方式工作。（出现这种情况，通常是因为需求分析工作质量不过关导致的，所以法则1很重要啊！）
法则3：程序员的工作需要有灵魂
我们先看看什么叫程序员工作“没有灵魂”：
1）不知道自己为什么客户服务；
2）不知道项目的远景；
3）只有项目经理操心项目，而程序员以“打工”的心态工作；
4）程序员任何改进意见都听不进，能写完代码就阿弥陀佛了！
那怎样才能让程序员“有灵魂”呢？
1）让程序员理解需求，至少自己做的部分要理解；
2）让程序员先行自己估算自己的工作，项目经理给出指导；
3）尊重程序员的实际水平，想办法让他引爆小宇宙，而不是靠强压。
法则4：写代码也是在做软件设计
程序员们会用“码农”来自嘲自己，其实写代码是高技术含量的活，写代码其实同时也在做软件设计工作，包括软件的架构设计、详细设计甚至是数据库设计！
当你用开发工具规划solution、project的时候，当你在project中划分文件夹的时候，你其实就是在做架构设计；当你新建一些类文件，思考类的职责并且在注释中写下来，当你写下方法的定义（暂时没有实现的代码）的时候，你其实就在做详细设计；当你分析各种业务对象后，在数据库中去建立表、字段、表关系的时候，当你在代码中设计实体类的时候，你其实在做数据库设计及实体类设计。
所以我们不是码农，优秀的程序员其实也是优秀的软件架构师、软件设计师以及数据库设计师！作为程序员来说，不要将自己定位为码农，你可以站得高做得更好；作为程序员的领导来说，不要将程序员定位为低技术含量的工种，程序员其实是最重要最有技术含量的工种。
法则5：关注程序员的需要
问：工作了这么久，领导找过你谈心没有？
答：有啊，经常“谈心”呢！谈工作，谈进度，谈缺陷，谈做完了没有！！
我说的“谈心”是指领导和员工谈员工的职业发展，让员工说出他的想法，领导在公司层面给予支持和帮助。
程序员有什么需要？无非是以下需要：
1）薪金的需要；
2）个人职业发展的需要；
3）生活上的需要。
薪金的需要通常是不能满足的，作为程序员领导的你可能也对自己的薪金不满，更谈不上让你去涨程序员的薪金了。但领导是不是可以问问程序员的职业需要呢，他想学什么技术，做什么类型的项目等等，在工作安排上给予一定的照顾呢？在生活上是不是可以允许程序员稍微弹性上班呢？有些家庭生活上的事情可以让程序员先去处理一下，不用他请假更加不会扣他的工资，程序员没有后顾之忧才能做好工作啊。程序员可能是地球上最善良的一类人，他们会滴水之恩涌泉相报！
法则6：男女搭配效率加倍
有些公司比较“变态”：不招聘女生，如果要招聘就一定要找已婚已育的！还冠上冠冕堂皇的理由：女生出差不方便啊！女生加班不方便啊！
有些领导比较“歧视”女生：女孩子嘛，不适合干什么技术活，做一下测试或QA就好了。
女程序员本来就少，加上以上的原因，更加是少上加少！
女生的威力特别是女程序员的威力是很强大的，不仅仅是这位女程序员自身的作用，更重要的是女程序员对男程序员发生的化学作用！如果男程序员原来的战斗力是10，如果有女程序员一同工作，那么男程序员们的战斗力至少可以上升到15。所以那些老板们太不会打算盘了，不要只看着女生生孩子的那段时间，请一位优秀的女程序员，绝对是一个超值的投资！
法则7：编码规范不是摆设
问：你们有编码规范吗？
答：有！
问：谁能说出编码规范中最有用的几条要求？
答：……
不少公司的编码规范是“空降”的，或者是你来到公司后就一直知道有编码规范这回事，但一直没有见过这份文档，更加没有在工作中执行过。
“空降”的意思是所谓的参考业界标准“抄”过来的一份文档，或者从某CMMI多少级的公司中“抄”过来的文档，“空降”文档注定就是要被摆上神台供奉，不能落地的。
有效有用的编码规范可以很简单，最开始的时候可以一页纸就搞定！我们只需要总结出当前编码中出现的问题，针对性地定出规范，只制定当前能执行的规范，不能执行的不要写进去，这样很快一页纸的规范就可以定出来，并且大家都愿意执行。规范不在于长短，不在于参考了什么“伟大”的标准，关键是能不能执行！
所有的改进都应该遵循循序渐进、持续改进的原则，这样一页纸的规范将会逐渐添加更多的内容，这样也表明了我们的编程水平正在持续提升。
法则8：提升编程基本功
有些程序员是写不出排序算法的，更悲剧的情况是在一堆数中找出最大的算法也写不出来。
两个途径解决编程基本功的问题：
1）把好入职关，增加编程基本功的笔试题。
2）增强代码评审。
代码评审应该在早期就做，高手评初手，评审主要目的不仅仅为了发现和解决问题，更重要的是提升程序员的水平。程序员水平提升后，评审就可以减少次数甚至不需要。
法则9：零缺陷意识
MSF（微软解决方案框架）提到的“零缺陷意识”非常有价值！零缺陷代码可能真的很难写得出来，但零缺陷意识必须有。
作为项目管理者来说，你要知道零缺陷的代码才能准确预测项目的进度；作为程序员来说，你要把这个当成基本的素养，对自己提出严格的要求，不要盲目求快，不要说反正后面有测试，如果程序有问题，那就是测试没有做好。
作为程序员来说必须做到以下两点的最基本质量要求：
1）你的程序能编译通过；
2）你的程序能通过“冒烟测试”。
通过冒烟测试是指：
1）模拟用户的最常见的正常操作，程序不会出错。
2）点击所有能点击的按钮、菜单等，程序不会出错。
这个冒烟测试是程序员自己做的，程序员们要自己擦干净自己的屁股噢！
法则10：避免“外包人头”
某些大公司大国企为了所谓的降低研发成本，会使用一些“临时工”，这些临时工和正式工一同工作，通常正式工干主要的岗位，而临时工干码农的工作。这些临时工是一些合作方公司以“外包人头”的方式租给雇主公司，临时工是合作方的正式员工，但在雇主公司那里他们就是“临时工”。
将软件研发工作特别是编码工作看成是低技术含量的事情，将程序员看成“工人”，这本身就是违背软件研发特点和客观规律的不合理做法！对于一些公司这样的做法，我是强烈喷之的。这样的做法其实不会降低成本，反而是增加不少成本。如果你是公司的管理层，强烈建议你不要采用这样的做法，说得难听一点，这是“反人类”的做法，而且这其实并不是“同工同酬”，其实是违法的做法。
试想一下，“临时工”会有怎样的战斗力？不是他能力不行，而是*上的问题，他愿意全力以赴吗？软件研发是高技术含量的团队工作，不是靠人多就搞定的。假设企业原本打算使用100名临时工，你不如招聘20名正式员工，20人的正式员工比100人的临时工的工作效率会更高，但总成本节省不少。企业还可以将节省的成本拿一部分出来，用来提升大家的薪金，这样整体效率会提升不少。
如果你的团队中已经有“临时工”了，你也无法改变领导层雇佣临时工的用工策略，你该怎样办呢？
相信你在工作中已经能体会到，你是很难调动“临时工”的工作积极性的，当然会有少数“临时工”是不错的。你可以参考“法则5：关注程序员的需要”，程序员是一种你对我好、我对你更好的善良物种。
小结
有那么一句话：找老公就要找程序员！
这句话不太对，你当女程序员不存在啊，这句话应该是：找老公就要找男程序员！
那找老婆呢？女程序员！遇到单身女程序员，一定要尽早动手，因为她很抢手。
程序员们是可爱的群体，编码是高难度高技术含量的活，希望我们的编码工作能变成富有激情和战斗力的工作吧！
如果本文对你有帮助，麻烦点一下“推荐”啦，谢谢！
作者：张传波
创新工场创业课堂（敏捷课程）讲师
软件研发管理资深顾问
CMMI首席专家
《火球——UML大战需求分析》作者
软件知识原创基地创办人
本文出自 “张传波” 博客，请务必保留此出处http://fireball1975.blog.51cto.com/8231356/1375633