IT项目 软件研发最佳实践
一，软件研发最佳实践
二， 战略
三， 需求篇
四， 设计篇
五， 编码篇
六， 测试篇
七， 实施篇
八， 计划篇
知道什么是挨踢项目吧？什么！不知道？那IT项目知道了吧？为了不让客户踢、不让老板踢、项目组成员之间不互相踢，俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功，也至少不会死得那么惨吧！我将分 团队建设 篇、战略篇、 需求 篇、设计篇、 编码 篇、测试篇、实施篇和计划篇为你分享。
一， 软件研发最佳实践
什么叫挨踢项目？
IT项目，特别是软件开发项目，都属于“挨踢”项目的范畴。挨踢项目的几大特点：
1.需求不确定。
2.技术不确定。
3.工期限死。
4.预算限死
两大不确定和两大限死，你想不“挨踢”都难！
由“踢皮球”事件想到的
事件回放：
某项目部署给客户后，重现了一些以前已经解决的问题，而这些问题测试时并没有出现。经检查，发现测试的版本不是部署的版本，不知道为什么老版本部署给客户了。领导要追究责任，于是大家各有说法：
开发人员说：我是按要求打标签的，没有问题。
测试人员说：我是在提交区中取版本来测试的，我没有出错。
实施人员说：我是按照开发给我的版本去部署的，我没有过失。
最后终于有人说：是之前已经离职的某某弄错版本号导致的。
该事件暴露了很多问题，但我想说的是团队建设的问题，没有任何一个人首先从自己身上找原因，第一反应就是推卸责任！
唐僧四师徒西天取经，如果每个人都是这样，不是自己内斗死，就是被妖怪吃掉！优秀的团队能“自动”解决很多问题，如何才能打造良好的团队文化呢？
良好团队文化的源泉是什么？
良好团队文化的根本其实就是老板的管理思想了，不同的管理思想，老板会设计不同的部门规划和考核办法。
有朋友提到他的Boss喜欢工厂化管理，硬生生将员工分成两类人，设成两个部门。一个部门叫设计部门，负责需求和设计；一个部门叫实施部门，负责编码、测试、实施。设计部门通过一个任务管理系统向实施部门下单，实施部门根据这些工单来工作。该老板还设计了自以为很牛的考核办法，如果实施部门不能按时按质完成工单，则会影响考核；如果设计部门的工单被实施部门退回，则会影响设计部门的考核。于是两个部门之间的扯皮时间天天发生，以前完成一个工作很简单的，现在要扯来扯去。设计部门自认为需求、设计等文档已经写得很清楚，实施部门认为已经按照这些文档完成工作，或者是认为这些文档说得不够具体，要退单。当文档主要用来任务交接的时候，文档就会变成茶几上的杯具！
还有一些老板喜欢用bug数量、文档缺陷率、工期延误率等所谓客观的量化的数据来考核，同样只不过是杯具的另一种形式而已。
软件研发活动是人类复杂的高级智力活动，是需要team work的活动。如果明白这个道理，如果懂软件开发，就不会设计出这些傻瓜的管理措施，将软件研发团队的每个人变成机械人、卸责人。研发团队中的每一个人都应该是值得尊重的、有血有肉的、充满激情和战斗力的专家！
作为Team Leader应该怎样做？
Boss的想法我们无法控制，虽然无法从根本上改变公司的部门设计和考核制度，但作为Team Leader来说，在能力范围内还是可以做很多事情的。Team Leader应尊重每一位Team Member，平等地对待他们，充分发挥他们的潜力，给予足够的支持和成长空间等。对大家好，大家是知道的，将来会给你带来更大的回报。
下面一些法则供你参考。
法则1：一荣俱荣，一损俱损
项目组由项目管理、需求分析、软件设计、编码、测试、实施等各方面的专业人士组成，每位成员在自己专业领域内发挥主导作用，并可以为项目的成功提出非自己领域内的建议。最终的项目成果是各位专业人士共同努力的结果，所有人对最终成功承担同等的责任。
如果系统部署后，系统出现了一个严重缺陷，请问谁应该负责？
项目经理？测试？开发？……
都不是，而是项目组全体都要负责！
软件中某个功能做得很炫很好用，请问谁应该受到表扬？
项目奖励发下来了，请问谁可以分到这份奖励？
以上问题相信你应该有答案了！
项目组全体是共同承担连带责任的，要死一起输死，要活一起活。如果项目组中有人受罚，有人会得到好处，这个Team是很难团结和有战斗力的。
法则2：让 Team Member 当家作主
项目组中难免有部分成员是新手，经验和水平不足，某些工作可能一时不能胜任。而我们往往迫于项目进度压力，某些任务就会直接安排给他做，不让他提出自己的想法和见解。而我们这些接受了中国式教育的人，不少人喜欢以“接受任务”的方式来工作，而不是主动迎接挑战。于是有时候你可能遇到一些成员会跟你说“今天工作已经完成！”“我按照任务要求来做的，我没有错！”之类的活活会气死你的说话。
不要剥夺项目成员当家做主的机会，应相信每位成员在他的专业领域内都是专家，在他的专业范围内，他可以说了算！只要满足项目的大框架，只要出发点是为了项目成功，那么这段代码应该怎样写、这个功能点应该如何测试等之类的决定，完全可以交给Team Member来做主！项目成员可能一时没有魄力独立做决定，可能担心犯错误，没关系，要多多鼓励他！犯错不可怕，因为还有“法则3：鼓励犯错！”
法则3：鼓励犯错！
少做少错，不做不错。如果犯错误会受到惩罚的话，那么前面八个字就会应验！
犯错几种情况：
1.经常挑战高难度工作，犯错是难免的。
2.做一些之前没有经验的工作，犯错也是难免的。
3.犯一些低级错误。
4.犯一些之前曾经犯过的完全可以避免的错误。
对于情况1、2，绝对是需要鼓励的！对于情况3、4，要帮助他避免这类的错误。
软件研发工作大部分是高难度和复杂的，加上进度压力大，犯错是不可避免的，如何在总结中前进。一个在工作中从来不犯错的人，他不是神，他应该是那种“少做少错，不做不错”的人，或者是专挑低难度工作的人，你喜欢这样的人？
法则4：言传身教
曾经见到这样的一些领导，当下属有问题求助时，他会板起脸孔，摆出领导的样子，然后说：你自己不会解决问题吗？你应该自己列出解决方案后才来找我！
我赞同领导不应该帮下属解决所有问题，有些问题应该由下属自己搞定，但下属是不可能搞定所有问题的，有些问题超出能力范围和职责范围，作为领导就应该出手。
作为Team Leader，应着重帮助Member养成良好的工作习惯和工作方法。中国式教育培养出来的学生，可能会喜欢直接得到答案，而不求工作方法。这个中国式教育的错，就只能由我们来补了。
法则5：挡住骚扰团队的外来干扰
Team Leader应当住来组团队外部的干扰，让团队可以专心工作。挡住麻烦是Leader的职责之一，而不要因为嫌麻烦，而让你的Member去处理这些麻烦。
法则6：全力维护团队利益
某部门的员工的薪金近年来很少得到提升，原因是该部门经理对外是好好先生，每年都不会主动积极为部门争取加薪的预算，总是被别的部门抢去预算。
某项目出了问题，老板找来项目经理，说要找人负责任，否则不好向客户交代。以下三个选择你会选哪个？
A.该问题确实主要是因为某Member导致的，所有他来负责是应该的。
B.这是团队的责任，要全体负责。
C.尽管是主要因为某人出错导致的，但作为PM的我应该负主要责任。
作为一个Team Leader，无论任何情况下都不应该“出卖”自己的Member，应该自己一力承担！回头你可以关起门来，批评这位犯错的Member。
法则7：我们是一个人
法则7是最重要的，其实只要能做到“我们是一个人”，其他法则自然就做到了。你不会和自己的左手作对的，右脚不会和左手打架，你的身体哪一部分受伤，你都会觉得疼，一个人的手脚动作是很容易协调的。如果我们团队能凝聚在一起，达到“我们是一个人”的效果，那么我们将战无不胜！
二， 战略
指挥战争可能是最复杂的项目管理？
做挨踢项目可能比较杯具，但最复杂、难度最高、代价最大的项目管理可能是 战争的管理了。战争靠什么取胜呢？如果你是这场战争其中一方的统帅，你会如何指挥这样战争呢？你可能会说：你不是在扯淡吗？说挨踢项目管理，怎么跑到战争去了？让我们先看看战争的战略管理，然后再回到项目的战略管理吧。白起的故事
白起你不会没有听说过吧？就是那个杀死几十万赵国俘虏的杀人狂魔。但我说的不是他杀俘虏的事情，而是白起被称为战神，一生没有打过败仗，他是如何做到的？因为他只选择打战略上能打赢的仗！
当时只有赵国有实力和秦国一战，双方几十万大军对峙在长平一带。秦军统帅是白起，赵军统帅是廉颇。白起对于此战的战略上的判断是这样的：两国实力、军力相当，如果全力出战，秦国能胜，但只能是惨胜，这样的后果只能是削弱了自己，反而让其他战国有机可乘。秦国的优势在于全国上下一心，特别是秦王和大臣们众志成城。而赵国虽然军力不错，但赵国内部权力斗争厉害，各派只为自己利益不顾国家利益。因此白起定下的战争策略是：对外称病不能担当统帅，隐藏自己做统帅的事实，以拖待变，寻找有利战机再出击。另一方面，秦国使出反间计，成功让赵国更换主帅，换了那个很出名的只会“纸上谈兵”的赵括。
赵括上任后，全军出击，结果中了白起埋伏，白起利用地形，用基本相等的数量的士兵困住了几十万赵军，不与之决战，消耗赵军的粮草，最后赵军被迫投降。后面就是白起杀死几十万降兵的事情了。白起成功地用比较少的代价，给赵国带来致命的打击。
白起杀死几十万降兵后，立马建议秦王马上挥军灭掉赵国。秦王认为此时出击必会促使六国合纵，这样秦国会招架不住；但白起认为，刚杀掉几十万降兵，其他五国还在震惊之中，没有这么快缓过气来，一时无法合纵，此时正是灭掉赵国的好时机！但秦王坚持自己的想法，白起只有退兵。后来秦王后悔了，想让白起率军灭掉赵国。这时白起认为：其他五国已经缓过气来了，此时攻击赵国，六国必会合纵。但秦王一意孤行，白起托病不统军，秦王另找人统帅，结果六国果然合纵，出现了“信陵君盗取帅印”促使魏国出兵的著名历史事件，秦军大败。秦王再次要求白起统帅，认为只要白起统帅必能获胜，但白起仍然推辞，最后秦王恼羞成怒，杀了白起。
白起在战略上的判断是相当准确的，可惜他的老板和他想法不一样，白起拒绝执行战略上注定失败的决策，虽然避免了自己打败仗，但得罪了老板，下场凄惨啊！咱们这些做项目的，如果遇到一个战略上有问题的项目，你是做还是不做呢？
庞涓的故事
说起庞涓，大家可能马上想到的是他如何害孙膑，然后孙膑又如何设计杀之报复。其实庞涓是一个战略上判断正确的人，只是被迫执行了战略上有问题的决策。
庞涓是魏国的大将，他对魏王建议的国策是：先西进灭掉秦国，解除后顾之忧后再图其他。秦国当时并不强大，多年与魏国争夺河西河东，“三十年河西三十年河东”的故事就是这样来的。但魏王认为：秦国很穷，但秦人很彪悍，灭掉秦国代价太大，没啥好处。魏王最想做的事情是灭掉赵国和韩国，所谓的“三晋合一”，魏、赵、韩原本同属晋国，后来他们将之瓜分掉。庞涓认为：灭掉赵国、韩国是不可行的，因为附近的战国，特别是齐国不会让魏国成功的，其他战国必会出兵。但魏王执意要先灭赵国，然后是韩国，让庞涓统帅。庞涓只能坚决执行老板的决策，率军猛攻赵国，就快攻克邯郸之时，齐国突然出兵突袭魏国的大梁，这就是“围魏救赵”的故事。庞涓只能回师救大梁，途中遇到和伏击，损失惨重，但还不至于战死。
魏王仍然不甘心，再次要庞涓统帅灭韩国，故事再次上演，这次是“围魏救韩”。庞涓再次回师，孙膑上演了“逐日减灶”的典故，让庞涓判断失误，率大军进入死地，被齐军伏击致死。
庞涓同样在战略上的判断是基本正确的，但他的老板想法不是这样，庞涓作为老板的手下，他选择了坚决执行老板的决策，但仍然得不到好下场！
遇到一个战略上有问题的项目，你不做会死，做也会死，怎么办呢？
认识软件项目的战略管理和战术管理
上面两个故事，希望我能大概说清楚什么是战略。项目的战略大概就是指：能决定项目成败的宏观因素，如：甲乙双方在这个项目上的商业利益、双方领导的特点、项目的预算、目标、工期等，还有就是你所带领的团队是否有能力有条件完成这个项目等。
战略上有赢的可能，加上好的战术，项目才有机会成功。
战略上没赢的可能，无论用什么好的战术，项目都逃不过失败。
战略上有赢的大好条件，但你的战术很差，项目也会失败，你浪费了一个大好的项目！
希望我们能尽量选择战略上有机会赢的项目，万一运气不好，挑上了一个战略上没机会赢的项目，那么就要想办法不要死得那么惨。
下面的法则供你参考。
法则1：从战略高度出发
客户为什么要做这个项目？我们公司为什么承接这个项目？
合同的金额是多少？我们公司对这个项目的预算是多少？项目工期有多长？
你的项目团队有什么人？每个人的水平和潜力怎样？
有没有其他影响项目成功的重大风险？
以上问题应该尽早搞清楚，通常来说可以在公司的高层领导那里得到很多重要信息，但如果你无法接触高层，或者高层不鸟你，你用尽所有办法都难以获取以上的重要信息，那么你基本上可以判断：这个项目死定！
最怕遇到一些让你自己解决所有问题的领导，这些只能是无水平、不负责任的领导！除了合同金额一些涉及公司机密的内容可能不方便漏录外，其他信息是必须让项目经理知道的，而且有些事情是需要高层出马帮助项目组去搞定的。
遇到高层不鸟你的情况，法则1-4都没啥作用，你可以直接看法则5。
法则2：尽量提高你在客户面前的地位
通常情况下，我们需要门当户对地和客户接触，高层VS高层，基层VS基层。如果你是一位小小程序员，想和客户高层说话，这是大忌！
很不幸的是，项目经理能经常接触的客户中的最高领导，只能是对方的业务骨干，最多是部门经理，而项目经理以下的项目成员，身份更加是低微了。
为了让项目组将来的工作更加主动，要做好项目组成员的“包装”，例如让项目经理挂上副总、总监之类的头衔，尽量让项目成员的身份放大和提高。第一次和客户接触时，就要包装好你的高大形象。例如项目启动会上，以比较高的形象来展示项目组各成员。
法则3：让客户的高层重视项目
越是高层的客户，越抓得住项目的目标，越是基层的客户，越容易陷入细节，甚至提出很多匪夷所思的要求。如果客户的高层能向下属明确本项目的目标和范围，那么客户的中层基层就比较容易搞定了。
法则2做得好，就很有机会让项目经理可以直接接触到客户的高层，项目经理在掌握了项目的战略的情况下，了解了客户大致想法的情况下，就比较容易驱动客户高层做事情了。如果项目经理不好接触客户的高层，那么就要动用法则4，让你的高层去找客户的高层。
法则4：驱动你的高层做事情
项目中很多重大问题，方向性的问题，其实是需要我们的高层去处理的。例如让我们的高层与客户高层明确项目的目标与范围，推动客户配合需求调研工作，推动上线试运行，推动验收等。项目中出现重大问题，会影响项目成功时，都应该第一时间将问题反馈给我们的高层，让高层去处理或给出建议。
我不觉得你能解决所有问题才叫厉害，在项目组的层面确实有些问题是无法解决的，这些问题如果不及时让高层知道并让高层支援你，问题将会变得更加严重。
如果你的高层是那种什么事情都让你自己搞定的“无能”领导的话，那么本法则不适用，请看“法则5：输少当赢！”
法则5：输少当赢！
如果是项目战略上判断觉得无赢的可能，但你的高层领导认为可以赢，执意要求你执行他的决策，那么本法则可能会让你不会死得那么惨。
做一个战略上不可能赢的项目是很痛苦的，最佳选择是不做这个项目，但通常你没得选，你只能硬头皮上。你应该庆幸，不是让你做战争的统帅，你不会象白起或者庞涓那样会死得很惨，你最多是辞职不干！
万一赢头皮要做这样的项目，只能是“输少当赢”了。向你的高层随时报告进展，遇到什么问题全部抛给他，美名其曰：向您请教应该如何处理！遇到与领导有某些分歧，你可以适当地争论一下，然后假装被你的领导说服，你还要装作很受教的样子。你只能在很有限的空间内，尽量降低这个项目的损失，尽量降低你将来需要承受后果的严重程度。将一些问题及时抛给高层，或许会有机会帮助高层重新思考自己的想法，逐步修正他对这个项目的战略判断，这样的话会慢慢变得对你有利。
采用法则5时，是不得已的选择。如果想不做这个项目，恐怕只能选择辞职；为生活，只能暂时忍一忍，接手这个烫手山芋吧。
关键是心态要好，尽自己力就OK了，对得起自己，也对得起这个项目。挨领导的批可能是不可避免的了，当他唱歌吧！
法则5是没有办法的选择
上策：不做这个项目，或说服领导放弃这个项目。
中策：在做这个项目的过程中，通过不断抛问题给领导，让领导重新思考修正想法。
下策：硬着头皮执行领导的决策，尽量少输。并且在一开始就将项目情况透明化，让领导随时知道项目进展和问题，这样至少有两个好处：1.领导有机会修正想法，从而向“中策”方向发展；2.将来发生问题时，领导就不会觉得“惊喜”了，项目组就不会死得那么惨。缺点就是：一开始就抛问题给领导，领导会不高兴的。你愿意选择一开始就让他不高兴？还是隐瞒问题，最后给一个“惊吓”给他呢？
不过话说回来，所谓我们认为领导对这个项目的战略分析是错的，这只是我们主观的看法。真是情况有可能是以下几种：
1.你是正确的，领导是错的。
2.你是错的，领导是正确。
3.你和领导都判断错了。
领导坚持他的判断，有些理由可能是不方便告诉你的，所以我们也不能断定自己的想法一定比领导的要好。
但这个项目最终是由你来完成的，如果你的想法与领导的想法从根本上是不一致的，做起这个项目来就会相当痛苦。
三， 需求篇
由“我要吃饭”的故事想到的
某天某客户跟你说：“我要吃饭！”
你非常关注客户这个需求：“请问您要吃中餐还是西餐呢？您想吃什么呢？”
客户非常开心，一下子说出了很多想吃的：
“西餐嘛，不错，听说那个菲力牛排很不错，配上红酒更加美味！”
“不过听说某某路的那个潮汕牛肉丸火锅，牛味很浓，牛气冲天……”
“哎呀，最近上火，还是不吃这些上火的东西了，吃日本寿司吧，听说那里有日本菜自助餐，有生蚝，正啊！”
“啊，不行哦，最近日本核辐射，海鲜还是不吃了”
……
最后客户说：
“你还是先弄一顿给我尝尝吧，见到菜才能提出具体需求啊！”
遇到这样的客户，你可能想找10个馒头塞到他嘴里面，让他撑饱，搞定！
当你搞了大半天 需求调研 ，仍然不知道客户想吃啥的时候，客户终于露馅了：“你快点吧，我饿得不行了！”
原来客户想解决肚子饿的问题啊，你马上说：“附近有一家XX大酒店，里面的粤菜很不错，人均消费300元可以搞定！”
客户很开心：“谢谢您请吃饭，让您破费了！”
你傻眼了，需求调研费还没有收呢，还要请吃饭！你说：“不好意思，吃饭的费用需要您自己搞定啊，而且我们还要收10%的需求调研费！”
客户急了：“我只有10块钱啊！”
你气死了，10块钱的预算想吃这么多东西！于是你提出一个解决方案：“咱们去那个XX快餐吧，那里的饭和白粥是随便吃的！咱们是老关系了，我们再赞助您10块，也不收您需求调研费了。”
没等你说话，客户就抓着你的手奔向那个XX快餐了：“快点吧，我快饿晕了！”
以上故事纯属虚构，如有雷同实属不幸！
这个故事是软件项目需求工作的缩影，客户的表面需求似乎很多，而且变来变去，很可能是因为我们没有抓住“我很饿”这个根本需求。客户可能提出很多匪夷所思的需求，提出一些超出自己预算范围的需求，如果我们能抓住客户的根本需求，让客户认识到自己的预算限制，再加上我们高水平的发挥，我们是有可能做出能满足客户根本需求，并且符合预算的软件系统。
我们可能经常听到一些关于需求方面的说词，如： 需求开发 、需求分析、需求调研、需求管理等等，下面将这些概念稍微梳理一下。
1）需求分析：
其他说法：需求调研、需求开发
关注点：如何获取和 确认需求？
2）需求管理：
“双赢”：客户能赢，我们也能赢！在“双赢”的基础上，处理以下问题：
a）如何签署需求？
b）如何处理需求变更？
需求驱动地工作。
a）用需求指导计划、设计、编码、测试、实施等工作。
b）不做或少做与需求无关的事情。
需求分析和需求管理的工作，我统称为需求工作。需求工作中的问题有些是需求分析的问题，有些是需求管理的问题，或者是两者兼而有之。
解决肚子饿的问题，是客户的根本需求，客户的根本需求或者说需求之源泉，我称之为需要！如果客户是公费吃喝的，嘴馋想吃东西，那么满足这个需要的做法又不太一样了。
客户一般不会直接说出需要，往往提出的是他自认为能解决这个需要的某种解决方案。“我要吃饭”只是表面需求，透过这个表面需求，找到需要是需求工作的根本！我们需要思考：客户为什么有这样的要求？客户希望解决什么问题？如果找到客户的真正需要了，那么我们需要进一步思考：有什么简单的方法可以满足客户的这个需要？
客户的需要其实很少会变的，变的是那些表面需求，多问问我们自己：我们抓住了客户的需要没有？有些客户对自己的需要很清楚，但有些客户可能只有朦胧的想法，我们需要总结出客户真正想要的东西并与客户确认。
10块钱解决肚子饿的问题，和100元解决肚子饿的问题，差异可以很大，所谓的看钱吃饭！
如果我们能搞清楚客户的需要，其实10块钱也可以有比较完美的解决方案的，可以去大排档吃个面、炒粉之类的，不是不可以的。某牛筋丸汤粉，才10块钱，但有8个牛筋丸，味道好极了，而且可以饱肚子！
除了预算，系统的技术条件限制，需要与第三方系统接口等其他限制条件，也需要事先搞清楚。需要、限制条件要和客户高层达成共识，一起努力找出在限制条件下可以满足需要的需求解决方案。
法则3：持续确认
曾经有人问我，几十页甚至上百页的需求规格说明书，如何让客户确认？我反问：这几十上百页的需求文档是闭门造车写了n天后，才给客户确认的吗？对于客户来说，该文档是从天而降，他之前没有见过其中任何的内容吗？
需求不是等全部写出来才去确认的，要持续地逐步地确认。我曾经做过一个项目，连续5天进行需求调研的工作，第5天几十页的需求文档写出来了，给客户签字确认，客户很快就签字了！这份文档的绝大部分内容，在之前的4天他都曾经确认过，第5天只是一个最终的确认而已。
持续确认好处：
1.能尽快发现问题，能帮助我们尽早确认需要，避免后期可能的需求变更。
2.客户能逐步消化需求。
曾经有一个某政府部门的项目，系统是各业务部门使用的，但需求只能从信息科那里获取。信息科的人自认为很牛，对项目组说：“需求向我们要就可以了！”而这个项目上线后，具体使用系统的部门就是不买帐，最后这个系统由信息科验收了。
信息科提供的是“二手需求”，向客户调研需求时，一定要避免“二手需求”！
上述案例你可能会觉得有点好笑，其实“二手需求”在项目组内也经常会发生。
某测试人员问为什么要做这个功能？开发说：这个你不用管，你这样这样测就可以了……
某实施人员觉得某功能看上去不太符合逻辑，提出疑问。开发说了一大通实施人员听不懂的技术用语，然后实施人员只能憋着不说话了。
项目组的测试人员、实施人员应该接触第一手的需求，最好能直接面对客户，而不是通过开发人员转述需求。
法则5：成为业务专家
你可能遇到过这样的情况，客户经常抱怨软件不好用，然后我们问：如何不好用？客户好容易说出了一些要求，我们按照这些要求修改了系统，但客户总是不满意，总是说不好用。诸如此类，不断重复。客户说啥，我们做啥，是比较落后的一种层次。我们应该处在客户的利益，提出超出客户想法的解决方案。要打造有竞争力的产品或项目，成为业务专家是必须的，不能偷这个懒，不要仅停留在需求调研这样的层次，而是要引领需求，给客户带来更先进的知识和管理办法。
法则6：需求是“设计”出来的
手机订餐系统的故事我经常拿出来举例子，大意是：某公司有一个订餐系统，但高层要求在这个基础上做一个手机订餐系统，让外出工作或请假的同事可以方便定午餐。手机订餐项目组花了九牛二虎之力，终于弄出这个系统，但问题多多。高层领导很不高兴：这点小事都折腾这么久！后来有人说：外出工作或请假的同事，打电话回公司，让前台帮忙订餐不就可以了？
“解决不方便订餐的问题”是需要，而“手机订餐系统”只是可以满足该需要的某种解决方案，我们完全可以通过其他更加简单的方法来满足需要。我个人观点：除了需要是来自客户的想法外，系统要具体做什么功能之类的需求，不是通过问客户问出来的，而是我们根据客户的需要，理解了客户的业务流程后，并根据限制条件，设计出来的！当然客户提出来的想法，会给我们带来很多启发，但我们不应该仅停留在需求调研的层次，而是提供一个高性价比的需求解决方案。
法则7：七分需求分析，三分需求管理
遇到客户变来变去的情况，我们可能第一反应是：有没有搞错！当初就应该让他签字！最好就是录音！如果我们连客户的需要都搞不清楚，就去抱怨客户需求变来变去，那我们的水平未免有点低了。其实真正很难缠的客户、不讲道理的客户很少的，只是我们水平未够，不能理解或找出客户真正想要什么，才让我们误以为客户变来变去。
需求工作可能有很多问题，应该以做好需求分析工作为主，而需求管理为辅，两者比例大概是七三开。需求分析工作做好了，需求的问题可以减少很多，而且客户也会非常认可你的专业水平，这样后续的工作就比较容易处理了。
当然也可能会遇到很难缠又不能绕过的客户，遇到这样的情况，建议你看看“挨踢项目管理求生法则（2）——战略篇”，如果从战略上判断该项目有很大问题，那么最好不要做这个项目，如果不幸要负责这样的项目，那么记住其中一个法则“输少当赢”。
四， 设计篇
什么是“漂亮”的设计？
一些关于软件设计的资料提到，咱们的设计需要高效、可靠、易用、安全、可扩展、兼容性强、移植性强……
每次看到这样的文字，我的第一反应就是头晕，这些基本就是废话嘛！
软件设计是为软件服务的，要服从项目的商业目标。一味追求所谓的优雅设计，项目可能会死的很惨。客户购买的是软件而不是你的设计。如果你在客户面前介绍你的设计如何精妙、如何OO、如何依赖注入？那客户只能当你是火星人看了，客户并不会因为你的设计如何精妙而原谅你的推迟交付和增加费用。如果为了节省时间，忽略设计或者粗略设计，项目同样很可能会死得很惨！没有想清楚就动手，就相当于冒着大雾往前走，可能走错方向，可能跌入悬崖……
我认为“漂亮”设计应该是这样的：
1.能命中需求。
2.符合项目的战略。
3.做适度的设计。
当然以上内容可能仍然不够清楚，请继续阅读下文。
为什么需要设计？
以前公司过ISO的时候，其中一个我觉得比较厌烦的问题是：软件的实际设计已经和设计文档不符了，ISO内审员要求我去更新设计文档。为了避免这些麻烦，我试图将设计文档写得比较粗和通用，这样就大大降低了需要更新文档的机会。如果将设计进一步抽象化，我完全可以写出一个N层架构的设计出来，这样的设计可以复用到n多项目上，每个项目的设计文档复制这个设计就可以了。但问题是：我们的软件设计就是为了得到一个不用怎样修改的文档吗？况且这样粗的设计对项目实际工作有什么实用价值呢？
在某项目管理培训中我展示了某项目的某模块的详细设计文档，但有学员提出了质疑，从他的经历看来，无法让程序员写出类似这样的文档。写不出文档，是因为没有能想清楚？还是因为不会中文呢？软件设计并不是写文档，而是通过探索和思考，想出解决问题的方案，文档写不出了没有关系，关键是你有没有解决方案？哪怕这个方案存在与你的脑袋当中，你能不能清晰的表达出来？表达的方式不一定是文档，可以是口头表达，可以是通过Demo来展示等等。
现在可以来回答“为什么需要设计？”这个问题了，我的观点如下：
1.需求解决做什么的问题，而设计是解决怎样做的问题。
2.如何更简单、更少工作量地解决怎样做的问题，是设计工作的重点。
3.需求工作决定了软件的价值，而设计决定了软件的成本。
4.写设计文档并不等同于软件设计，软件设计在于探索、思考、实践，摸索出有效的解决方案、具体做法等。
5.Word文档仅是软件设计的其中一种表现形式而已。
6.设计不是一次成型就不变的，而是需要持续优化和改进。
我们需要做什么设计？
设计包括概要设计和详细设计，这是我们惯常的认识，但我将设计分为以下几方面的内容：架构设计、模块设计、数据库设计、用户体验设计。
架构设计可以近似看作是概要设计，架构设计是通盘考虑了所有软件需求后的一个宏观设计，我通常会用UML的部署图、组件图和包图进行架构设计，设计的粒度会达到组件及模块级别。
模块设计是指在架构设计的基础上，在软件系统划分成n个模块，每个模块进行详细设计。我通常会用UML的类图、顺序图来进行模块设计，设计的粒度会达到类、类的方法和属性、类之间的调用关系等。
数据库设计这个不用多解释，粒度要达到最终实现的程度，而用户体验设计可能需要多加解释了。
用户体验是指用户使用软件时的整体感觉，用户体验设计需要考虑清楚软件的整体界面规划、界面先后关系、文字表达、软件与用户如何交互等等。说到用户体验设计，很多人直接反应就是美工的事情，这是不对的，美工仅是用户体验设计的一小部分内容而已。一个软件如果内部实现很烂，但用户体验设计做得很好，那么这个软件仍然会很受欢迎。相反，一个软件的用户体验设计很烂，哪怕软件的内部设计很精妙，客户也不会卖账。从这个角度上看，用户体验设计是相当重要的，但用户体验设计往往是被忽略的。很多软件公司没有专门的用户体验设计职位，往往由程序员自己设计软件与用户的交互，做出来的软件非常不人性化。
我在以前的公司做项目，一个项目一般会有1份架构设计文档，1份或者多份模块设计文档，1份数据库设计文档和1份用户体验设计文档。我想说明的是，以上提到的四种设计并不是非要对号入座，每种设计对应一份或多份文档，而是软件设计应该包含这四方面的内容，至于文档的数量和形式没有规定，你可以一个文档包含四个方面的内容。另外还要说明的是，并不是软件所有的模块都需要写详细的设计文档的，如果该模块的实现方法已经很成熟，成为项目组的“常识”，这些内容没有必要额外再写文档。
法则1：需求驱动设计
以前曾经参加某项目的某设计文档的评审，大家围着一个局部的技术问题进行讨论，但争论的内容仅仅是一些软件设计上的大道理，每个人对这些大道理诠释不同而已。于是我问：大家知道这个项目的需求吗？能不能列出设计中需要重点考虑的需求是哪些？居然没有人能答出来！
我去评审设计文档很简单，就是事先将需求搞清楚，列出设计中需要重点考虑的需求，然后看看设计文档是如何考虑这些需求的实现。设计就是用来满足需求的，用需求来检验设计文档，这是很基本的“常识”，但这个常识往往被我们忽略。编写设计文档的为“节省”时间，不去全面深入理解需求就去写设计文档，参加设计评审的为“节省”时间也不去了解需求，这样设计和设计评审就变成了走形式、浪费时间的事情。
前面提到设计决定了软件的工作量，在设计时间上“节省”时间，你的代价就是将会花数倍甚至数十倍以上的项目工作量。认真地需求驱动地做好设计工作，这是必须的。下面简单介绍一下什么需求驱动什么设计：
1.架构设计是通盘考虑全部需求后设计出来的，所以可以说：全部需求驱动架构设计。
2.模块设计是在架构设计的基础上，针对局部需求的具体实现设计出来的，也就是说：局部需求驱动某模块设计。
3.数据库设计是整理了全部需求当中的业务数据，思考这些业务数据如何在数据库中存取后设计出来的，也就是说：业务数据驱动数据库设计。
4.用户体验设计需要考虑业务流程、业务数据等，为满足客户的业务目标，我们设计出来的系统与用户之间的交互细节等，也就是说：业务流程、业务数据、业务目标等驱动用户体验设计。
“需求驱动设计”这句话还不够具体，还要进一步细化，什么需求驱动什么设计！上述几点是我以往工作的简单总结。
法则2：不要误解“简单设计”
极限编程中提到“简单设计”，有些朋友很兴奋，终于可以用“简单设计”作为不写设计文档的理由了！
什么是“简单设计”呢？以下情况是不是简单设计呢？
1.简单想一下，然后快速做一个设计。
2.没有设计文档的设计，就是简单设计。
3.不设计就是最简单的设计。
4.编码就是设计。
极限编程对“简单设计”的诠释可以总结为两点：
1.不要考虑太长远，仅考虑当前的需求。
2.用最简单的办法来实现。
我基本认同这个观点，但问题一些朋友的理解可能出现了偏差。第2点“用最简单的办法”这是很难做到的，将事情简单化这是难度很高、很考验智慧的事情。“简单想一下”是很难想出“最简单的办法”的，随便想一下想出来的办法，往往是工作量巨大的办法！简单设计的意思是指要让项目工作变得简单，而不是将设计的思考过程简单化。软件设计是一种智力投资，多花一小时想清楚如何让项目工作变得更加简单，会节省你更多的项目时间。
法则3：做高性价比的设计
在符合项目战略的情况下，用尽量少的工作量来实现需求，这基本上就是“高性价比”的意思。
实际上我们不太可能做出一个“最好”的或者说“完美无缺”的设计，因为有以下的条件限制：
1.有限的项目工期。
2.有限的项目预算。
3.项目成员的能力条件限制。
软件设计是高难度的技术活，需要你做出适当的取舍和平衡，做出一个合适的设计。
但高性价比的设计意味着：
1.公司项目的利润更加大，公司赚钱更多了，咱们能分到的钱也就更多了。
2.项目工作更加简单，项目组不需要加班或少加班就能完成工作。
3.高性价比设计是挑战智力的工作，会让你的工作更加有愉悦感和成就感。
所以为了公司好、你好、大家好，向“高性价比设计”的目标进发吧！
法则4：人人都是软件设计师
有这样一种观点：由软件设计师设计出详细的设计，程序员按“图纸施工”便可。
我不喜欢将软件研发工作变成流水线的工作，将研发过程分割为需求、设计、编码、测试等几个环节，每个环节有专职的人员，他们做好本职工作就可以了。这样的工作模式有以下几个问题：
1.人变成了机器，没有创造力可言。
2.每个人对工作职责负责，而不是对项目成功负责。
3.这样的模式不可能产生创意，也意味着不可能完成复杂的、需要创造力的项目。
我认为项目组中每个人都可以是软件设计师，不要剥夺程序员思考的机会，不要将他们变成按图纸施工的机械人。
在我的项目中，我是这样做的：
1.架构设计和数据库设计由富有经验的程序员负责，其他项目成员参与学习和评审该设计。
2.模块设计由将来负责该模块编码的程序员负责，架构设计师来评审该设计。
3.用户体验设计由测试工程师或实施工程师负责，程序员参与。
法则5：设计文档应该先己后人
一些QA通常用这样的理由来说服项目组编写设计文档：
1.为了让将来接手项目的同事搞清楚状况，设计文档是必须的。
2.将来你自己也很可能需要改程序的，现在写下文档对你将来的工作有用。
以上的做法，就好象你对一个正在挨饥荒的人说：现在多存点粮食吧，对你将来有用。听你劝说的人肯定气死了，恨不得吃掉你充饥！
所以以上的理由是不能驱动项目组写设计文档的，设计文档应该达到这样的效果：对项目当前的工作有用，能帮助我立刻解决问题！如果设计文档不能达到这样的效果，就不能驱动项目组写好设计文档。
设计文档必须先保证对自己、对项目组本身的当前工作有用，在这前提下有条件才去考虑对自己的将来有用、对别人有用。也只有立足于这个出发点下，才可能写出有实际价值的文档，文档不是摆设，是要立马在工作中用上的。
法则6：设计文档不一定是Word文档
以前曾经遇到一个挺郁闷的事情：
某项目用SQL Server数据库，我直接在SQL上进行设计，也就是说数据库的设计与实现一起做了。在数据库上做设计的好处有：
1.设计马上得到验证。
2.以利用数据库的特性做很多设计上的探索，让设计做得更好。
3.设计完成了，数据库也建成了，不需要再做一次，节省很多时间。
我很喜欢这样做，但QA认为我没有数据库设计文档，不符合ISO的要求。我觉得很郁闷，数据库这个文档就是数据库设计文档，干嘛非要写一个Word文档？后来迫于要ISO审核，我用复制粘贴大法写了这个数据库设计的Word文档。如果项目使用的数据库只有一种，我觉得直接在该数据库上做设计没有什么不妥，当然如果你的项目需要支持多种数据库时，该做法可能不妥。
通过这个例子我想说明的是：设计的表现形式可以很多，不一定是Word文档，怎样的方式对当前项目工作最有效，就应该采用怎样的方式。当然有人会说，写下Word文档对将来的人有好处，但前面的法则说了，要“先己后人”而不是“先人后己”，如果我现在就饿死了，你让我现在存粮有啥意义？况且Word文档并不一定是所有软件设计的最佳表现形式。
法则7：不是所有地方都需要有设计文档
有这样一种观点：代码没有设计文档是不符合CMMI要求的。
你认为是不是所有代码都应该对应有详细设计文档呢？
数据库四轮马车的操作如果你们公司已经驾轻就熟了，你们项目组闭着眼睛都能做了，你还会写一份详细的设计文档，然后对着该文档编码吗？
并不是所有的地方都需要设计文档，仅在需要的地方才写设计文档，我的做法通常是这样的：
1.架构设计文档一般不可缺。
2.数据库设计文档一般也不可缺。
3.并不是所有模块都要写设计文档的，一般在以下情况下才写该模块的详细设计文档：
1）算法比较复杂；
2）想法不太成熟；
3）负责该模块的程序员是新人等。
4.用户体验设计文档一般也不可缺，但文档的内容一般不会覆盖软件的全部内容，成为“常识”的内容不需要写。
法则8：“编码即设计”是合适的，但烂代码除外
“编码即设计”这个观点我支持，我要进一步修正，应该是“好的编码即设计”。架构设计文档、数据库设计文档或不可缺，但详细设计文档是可以直接通过编码来代替的，但前提条件是该程序员的编程素质足够好才行。
中国计算机教育培养出来的程序员，大多数是编程基本功不过关，在校没有写过多少代码。这是一大问题，而另外一大问题是这些编程基本功很水的人士，大多不会认识到自己的问题所在，还自认为自己水平不错，编程是小菜一碟的事情。遇到不愿意写或者写不出设计文档，又自认为自己编程水平很行但实际很差的项目组成员，就需要项目管理者多花心思来引导了。
有时候遇到一些编程新手，死活写不出设计文档，我会让他直接通过编码来思考。文档可能没有办法让他理清思路，那么直接编码来理清思路吧，你可以通过他的代码来了解他的想法并给出针对性的指导，帮助他提升水平。
五， 编码篇
“无节操”的加班
某公司有个加班龙虎榜，每周按照加班的总时长进行排名，加班时间最多的就是状元，然后是榜样、探花。其实没有谁这么变态要打进三强，但大部分人不想自己经常出现在榜尾，因为让领导看见了不是很好，有可能会导致饭碗不保，所以只能“自觉”加班！于是加班成了家常便饭……
某创业公司的老板搞了个“奖罚分明”的激励制度，任务分派下来如果能提前完成，提前时间越多，奖励越多；相反，如果任务推迟完成，推迟越多惩罚越多。结果大家都懂的，这些任务基本都是 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：关注程序员的需要”，程序员是一种你对我好、我对你更好的善良物种。
小结
有那么一句话：找老公就要找程序员！
这句话不太对，你当女程序员不存在啊，这句话应该是：找老公就要找男程序员！
那找老婆呢？女程序员！遇到单身女程序员，一定要尽早动手，因为她很抢手。
程序员们是可爱的群体，编码是高难度高技术含量的活，希望我们的编码工作能变成富有激情和战斗力的工作吧！
六， 测试篇
测试之囧
我曾经招聘了一名美女测试，面试的时候我问：为什么离开原来的公司？
美女测试答曰：原来公司测试流程不规范，给一页纸的需求就要我来测试，我希望到更规范的公司工作。
我听了后表示淡定，其实这位美女测试运气算比较好的了，很多公司的测试工作场景是这样的：
测试是没有书面化的需求的，对需求或者软件有不少不懂和困惑的地方，你可以找项目经理或某程序员寻求答案，但得到的回答是：这个你不用管，那个你也不用管，你这样测就可以了！
程序员 VS 测试工程师 谁更重要？
下面做个调查：
1）如果你是程序员，请回答这个问题：让你转职做测试，你愿意吗？（假设工资不变。）
估计100%会回答：不愿意！
2）如果你是测试，请回答这个问题：让你转职做程序员，你愿意吗？（也假设工资不变）
估计部分测试会回答：愿意！
如果你的回答是“愿意”，请继续回答这个问题：你觉得你能做程序员吗？
绝大部分测试是不会写程序的，所以这个问题的回答就会变成：不能:(
当然你会说有测试懂开发的！确实是有这样的情况，但这些懂开发的测试之所以懂开发，是因为他们最开始是做程序员的，后来发现自己不太喜欢技术，所以才转作测试滴。
俺从高中的时候就写代码了，非常喜欢做程序员。刚大学毕业想到北京某建筑结构软件公司做程序员，但发现人家要求是精通C++。很不好意思，我精通的是Basic，所以我退而求其次，那我应聘测试吧，希望通过测试这个跳板将来转做程序员！我心目中已经将程序员和测试工程师的重要性排了位置了，刚开始工作的几年我心里面是“鄙视”测试的，后来发现自己这个想法很有问题，特别是自己成为项目经理和公司管理者后。
如果你来做一个选择，你觉得程序员更重要，还是测试工程师呢？
我兼任测试主管的一个项目
我是项目经理，项目组中配有测试工程师，当时并不觉得自己兼任测试主管，后来总结一下才发现原来我干了很多测试应该干的活！
我做的几个测试的活有：
1）我每天检查程序们开发的东西有没有偏离需求方向。
2）我对测试工程师给出很多指导，让他能规划出符合项目需求及技术特点的测试方案。
3）我会让开发也参与测试，让开发之间交叉测试，这样增加了测试的人手，保证了测试的充分度。另外一个好处就是让程序员从测试的角度思考问题，提升程序员的编程素养。
4）测试并不是后期才做的，我们当时每周六都要加班，这天干的事情就是测试和修复缺陷。
这个项目工期是3个月，我们居然提前两周搞定！
测试的工作其实相当重要，帮助整个项目小组始终在正确的方向上工作，减少返工和犯错。我当时能做以上的工作，一方面是我具备了权力（我是项目经理），另外一方面是因为我具备了做好测试工作的几方面的技能。
作为项目经理的我，因为正好满足下面你将要看到的技能要求，所以我才能完成上述的4个测试工作。下面我们来看看测试工程师应该具备什么技能？
测试工程师应该具备怎样的技能？
废话不说，请看图：
图1：测试人员应该具备的技能
不少测试只懂“测试理论和方法”，对业务一知半解，对“IT基础架构知识”、“数据库知识”、“开发知识”、“软件设计知识”的认知几乎为零。如果作为测试的你掌握的知识这么少，你能有多大的能量呢？你能在项目中干多少活呢？这样你就不能怪程序员歧视你，也不能怪所谓的公司不重视测试。
当然这个图列的要求好像太多了，如果我满足这些要求，我干嘛还做测试这个岗位呢？你说的太好了！不要急，后续为你慢慢拆解……
软件公司真的不重视测试吗？
有些公司配置的测试人员很少，有些项目测试时间不够就直接给客户用，美名其曰：给客户测试！
某公司老板的想法更加牛逼，他认为公司根本就不应该配备测试这个岗位，因为如果存在测试的岗位，会降低程序员的工作质量！（程序员会因为有人在后面测试，工作质量会更低）
项目出现了严重缺陷，管理者第一反应是测试质量不过关！但我们可怜的测试往往是在被缩减的时间，去内完成不可能完成的测试任务，质量又如何保证呢？
测试阶段所爆发的问题，其实80%的原因并不在测试本身，而是前期的工作没有做好。要改善这些问题，需要包括测试人员在内的全体成员一起努力！
其实很多公司并不是不重视测试，所有老板都希望软件能赚钱、项目能验收，那么一定的质量要求是必须的，测试就是保证质量的一个重要手段。下面为你分享一些求生法则，希望对你能有一些帮助。
法则1：测试必须具备“基本技能要求”和“进阶技能要求”
先举两个测试人员因为不具备相应的技能而导致问题的例子。
1）例1：我无法开展测试
某测试人员的工作一直不能开展，我很郁闷，他解释：这个“增加”功能一直没有做出来，虽然“修改”和“删除”功能做出来了，但因为没有“增加”功能可用，所以……
听了后我有点恼火：为什么你不能到数据库中添加一条记录，然后你不就可以去测“修改”和“删除”功能罗！
他不好意思地说：我没玩过数据库……
2）例2：需要程序员帮忙的测试
我有事找某程序员，但他不在座位不知道干嘛去了，后来我了解到原来他去帮助美女测试了，他帮忙设置测试环境，包括：安装服务器的操作系统、安装数据库、安装程序、设好配置文件等等。
我觉得他做得挺好的，大家就应该互相帮忙嘛。但下一个版本，他又重复做类似的事情。
我问：上次你没有教会她吗？这次让她自己搞定就行了。
他说：她好像不太愿意学……
类似的事情我遇到的不少，由于测试人员掌握得知识太少了，以致很多工作都需要别人准备好安排好他才能做。而更让我气愤的是，有些测试学习的欲望很弱，而且对测试工作的认识很肤浅。一些测试认为：测试工作就是软件做好能见到界面后，我在界面上点鼠标和敲键盘就可以了，高级一点的测试工作就是能用LoadRunner之类的工具来做性能测试。
其实大部分测试都是追求进步的，“学习欲望弱”很可能是没有认识到自己需要学什么，没有打破自己固有的思维框框，没有能发挥自己的强大潜力。要改善测试工作，作为测试人员的你首先应该自我检讨，看看有什么可以改善的地方。
“图1：测试人员应该具备的技能” 中列出的要求，你必须至少要达到“基本技能要求”和“进阶技能要求”这两个层次。只要你有心去学，只需要3-6个月你就可以基本满足这两个层次的要求。而“高级技能要求”难度有点大，一般没有3年以上的相关工作经验是很难满足的，你可以考虑将这方面列为你的发展方向。只要你达到“基本技能要求”和“进阶技能要求”，你的能量将会成几倍爆发！
法则2：拒绝二手需求
“二手需求”就是项目经理获取需求后，将需求传达给测试，这样就变成二手需求了。
但这只是理想境界，通常是项目经理将需求传递给开发，然后开发告诉测试你怎样测就可以了。所以实际情况是，我们测试得到的是三手甚至三手以上的需求！
让测试获取一手需求的做法：
1）测试人员参与到需求调研中来，甚至让测试成为需求负责人；
2）需求文档不要等全部写好才给测试看，每写一部分就要与测试沟通。
法则3：测试至少要成为第二熟悉需求的人
项目中最熟悉需求的人通常就是项目经理，或者是需求分析师（产品经理）。
测试至少要成为第二个最熟悉需求的人，并且要争取成为第一位，将项目经理“干掉”！
法则4：拒绝半个人
不少项目后期才安排测试人员进入，而且测试人员还需要同时负责另外一个项目的测试，你最多只能得到“半个测试工程师”。
测试需要从项目的一开始就介入，并且每个项目至少要配备一名“完整”的测试。
法则5：是不是缺陷，测试说了算！
有一个缺陷，测试认为是缺陷，但开发认为不是，并且用一堆测试听不懂的话来解释这不是缺陷。
这种状况很常见，你们会用哪种方法裁决？
A）测试因为听不懂，所以最终被开发“说服”，这个不是缺陷。
B）交项目经理裁决，项目经理通常是开发出身的，所以最后就会变成这个不是缺陷。
C）交客户裁决。
D）少数服从多数。测试一定是少数，所以结果你懂的……
我以前的做法就是交项目经理裁决，后来觉得可以做得更好，我将做法改成：其他人可以提建议，但是不是缺陷的决定权在于测试！
我这样做是因为：
1）测试的角度更接近客户，他的判断更靠谱。
2）测试因为有这样的一个责任和权力，他工作会更投入，会更加努力提升水平。
3）“是不是缺陷”和“能不能按时发布”，两个问题要分开处理。不能因为要按时发布而掩盖质量问题，有质量问题也可以按时发布的嘛，但如果缺陷被掩盖掉了，就相当于埋下定时炸弹。
法则6：测试获取开发代码
请先看一个案例。
案例：需要界面规格说明的测试
某测试提出这样的要求，希望开发人员能提供界面的详细规格说明，以便可以开始准备测试用例，为正式测试做好准备。
开发人员反对这样的要求，因为这事情太浪费时间了，而且界面经常会变和调整的，这个文档我岂不是要天天改！
这是事情解决起来很简单，每一位测试的电脑上都装上开发工具，每天测试就好像开发一样去获取代码，测试每天干这些事情：
1）编译代码，检查是否编译通过。如果发现编译不通过，项目小组发达了，今天有人请吃饭，请客的人就是让代码编译不通过的代码提交者。
2）如果编译通过，那就进行“冒烟测试”。冒烟测试干的事情就是将主干业务流程走一遍，将所有能点的按钮和菜单走一遍，看看会不会出错。如果出错，那恭喜你，又有人请吃饭了！
3）对照需求检查程序是否在正确的轨道上，及时提出易用性方面的改进建议。
这样干其实就已经做到测试前置了，这样做就不会出现直到正式测试阶段才能见到软件庐山真面目的情况，问题不会在最后才爆发出来，前期已经发现并避免了。
要做这个事情，测试并不需要懂开发，会用开发工具，会编译软件就可以了。有条件的时候，测试还可以去学习代码，甚至逐步开始写一些测试代码呢！
法则7：人人都是测试
一般软件公司开发与测试的人数比例，大概是 4-8:1，当然也会有比较悲剧的公司是 20+:1 的。
我觉得比较合理和比较符合现实的比例也就是 4-6:1。我们就是按这样来配置的，但仍然会出现测试人数不够的情况，那是不是需要招聘更多测试呢？
如果已经做到法则6，测试的工作已经前置，那么到正式测试阶段，测试工作量峰值将会下降不少，但仍然是不够人数做测试的，这个时候本法则“人人都是测试”就适用了！
测试要实现做好测试方案，到正式测试阶段，将测试方案中的工作分派给开发，让开发也带上测试的帽子进行测试，记住基本原则就是不要让开发测自己负责的模块就行了。
法则8：测试设计的难度不亚于软件设计
我将测试方案及工作的规划，称之为“测试设计”。
如果测试只懂业务是很难胜任测试工作的，请看以下案例。
案例：某技术要求高的系统
该系统有几个技术难点和测试难点：
1）B/S架构，但界面的易操作性要求很高，写了很多JS脚本。系统需要在IE6、7、8上能正常运行。
2）系统需要部署在网络负载平衡的环境上。
3）系统有很多Windows Service服务，要定时生成很多数据。
4）系统需要满足一定的并发访问量要求。
如果不具备“图1 测试人员需要具备的技能”中的“进阶技能要求”和“高级技能要求”，你将会对这些测试难点素手无策。
当时我们的测试没有这么厉害，我相信很多项目的测试也不会这样厉害，而很多项目其实是有很多技术要求和测试难点的，那我们该怎样办？
记住“法则7 人人都是测试”，项目经理或项目的技术大牛就应该承担起测试设计的工作，但要注意要带上测试一起来做，训练测试逐步掌握这些技能。
法则9：不需要写面面俱到的测试用例
曾经见过某领导对测试的要求很“苛刻”，他要求测试无论事无大小必须写出面面俱到的测试用例。比方说一个登陆系统的功能，如果按照该领导的要求，要将所有测试数据都写清楚，那么写出来的测试用例至少需要10页以上的A4纸。
这是一个比较极端的真实案例，稍微没有那么极端的情况是，要求所有的需求都需要对应有文档化的测试用例。
在软件开发工作当中，其实有些工作是属于“常识性”的，你闭着眼睛也会做的，这些内容就没有必要文档化。
比方说我让你写一个吃饭说明，你会这样写吗？
1）用一只手拿起筷子；
2）用另外一只手捧起碗；
3）用筷子将碗中的饭扒到嘴中，记得要张大口噢；
……
你看了上面这段描述，不知道吐血了没有？
我们只需要对比较复杂的、容易出错的、有难度的地方，写出相应的测试用例，测试用例的描述在于描述清楚测试思路，不需要事无大小都写下来。
当条件成熟的时候，公司可以逐步建立测试用例库，对常见的情况建立测试指南，让所有的测试人员去学习和参考，项目中遇到类似的情况就可以直接参照用例库了，不需要再写一次测试用例。
法则10：测试也是开发，开发也是测试
当我是一个人写程序的时候，我就是按照“法则10”来干的；当我和另外一位程序员负责一个软件的时候，那三年时间我们基本上也是按照“法则10”来干的；
当我做的项目的人数是几个人以上后，这个“法则10”就很难实施了，不是我不想实施，而是因为各种客观条件并且我的领导不同意。
我的观点是：一名优秀的测试同时也应该是一名优秀的开发，一名优秀的开发同时也应该是一名优秀的测试！
但目前常见的现状是：
1）能做好测试的优秀开发有，但数量不多；更多的是没有测试意识、代码质量很差的程序员。
2）测试大部分是不懂开发的，我们认为优秀的测试往往也是不懂开发的。
我曾经想尝试这样的管理模式：
1）开发必须每年有一段时间换岗做测试工作。
2）测试也需要每年有一段时间换岗做开发工作。
3）干脆就不招聘测试，只招聘开发，但要求该岗位也要负责测试工作。
第1）点很难实现，因为开发基本不愿意去做测试。
第2）点基本无可能，因为测试编码基本功通常为零，而且很多测试是因为不喜欢编码才做测试的，悲剧！
对于第3）点，我承认，我是在“痴心妄想”！
现实可行的做法可能是这样的：
1）让有培养潜质的开发带上测试的帽子，负责某些项目的测试工作。该方法能提升开发的编程素养，也可以培养综合性人才。
2）让具备条件的测试在某项目中带上程序员的帽子，让他写代码。
我一直没有能在我管理的公司中尝试这样的管理模式，但我相信这样的管理方法一定会极大地提升公司的生产力和战斗力，你敢不敢和能不能去尝试呢？
小结：
要改善测试工作首先要从思想上重新定位：
1）测试并不是一个低技术含量的工作，相反，测试工作重要性和难度并不亚于软件设计。
2）测试并不是项目后期才开展的工作，而是从头到尾都需要的工作，是保证项目始终在正确轨道上的重要工作。
如果你是测试工程师，提升你的水平，发挥你更大的能量，这是你的当务之急。想别人和公司重视你，是靠你自己的实力去争取的！
如果你是项目管理者，你要注意的是：
1）项目管理者最优先要做的事情就是保证大家都在做正确的事情，你要从测试的角度从项目一开始就进行监控。
2）给测试工程师权力和成长机会，帮助他们成长，让测试工程师分担你更多的工作。
3）测试其实是一种帽子，其实谁都可以戴，要善于安排测试人力资源。
如果你是程序员，你需要多从测试的角度来检验自己的工作，你的工作目标就是不让测试工程师测出任何缺陷，将测试工程师“废掉”！
七， 实施篇
什么是实施工作？
实施工作内容主要有：
1）安装系统，包括整治网络环境、安装数据库、安装程序等一系列工作；
2）培训客户使用系统，解答用户使用中的问题，推动系统上线；
3）推动验收；
4）反馈客户对系统的意见给项目组。
看上去实施工作似乎是项目后期的工作，但实施工作其实是需要从项目一开始就要准备的，以下工作需要前期就做好：
1）熟悉客户业务，熟悉需求；
2）了解客户的IT环境，根据系统的要求提出整治要求，并帮助客户做好准备；
3）编写用户文档，通常至少包含两种文档：一种是给一般用户使用的，一种是给系统管理员使用的。
4）编写实施计划，准备实施环境进行演练；
5）熟悉客户各层次的关键人物，和他们搞好关系，为后续工作做好准备。
实施工作需要具备的技能
要完成上述工作，实施工程师需要具备以下的技能：
1）熟悉网络、操作系统和数据库；
2）熟悉客户业务，熟悉需求；
3）能和客户沟通和保持良好关系的技能；
4）需要有一定的商务触觉。
不要“歧视”实施工作
我曾经“歧视”过实施工程师，甚至认为不需要专职的岗位，开发人员或者是项目经理亲自去实施就可以了。
我“歧视”的原因有：
1）当时的实施工程师技能比较欠缺，经常还装不上系统，需要开发去支援；
2）当时的实施工程师对业务不熟悉，需求不了解，客户很多问题不会回答，不会“顶”回一些问题，只会做客户的“传声筒”；
3）当时的实施工程师学习的动力不大，没有意愿去改善业务水平。
法则1：实施的首要工作是推动验收
实施工作的首要目标是推动验收，安装程序、培训客户等等这些仅仅是手段，最终目的就是要验收！
通常合同中规定的付款方式是这样的：
1）合同签订后给一笔头款，通常占合同总金额的20-30%；
2）验收后付款合同总金额的60-70%；
3）维护期后给合同总金额的10-20%。
付款大头就是验收后的那笔付款，所以推动验收是实施工作的首要目标！你要这样看待这个工作：如果不能验收，你将没有60-70%的工资！这样你就会足够重视实施工作了。当然推动验收这个工作通常要和负责商务的同事一起来做的。
法则2：验收除了搞定甲方老板还需要搞定业务骨干
案例：验收失败
某项目甲乙双方老板很熟，验收之前乙方老板已经做了很多工作，甲方老板也表示验收没有问题。于是验收大会上，甲方老板一开始就定了基调：验收是可以通过的，有问题可以记录下来，验收后继续跟进。于是甲方老板问大家的意见，结果“惊喜”来了。由于事先的实施工作不到位，出现了以下状况：
1）设备没有采购都到位，大部分人还没有用过这个系统；
2）某业务骨干已经用了该系统，但他反馈的意见乙方没有重视，该业务骨干表示该系统无法验收。
乙方老板没想到是这样的一种情况，也觉得相当不好意思和丢面子，甲方老板也很不满，你不能这样忽悠老子验收啊！
所以结果你懂的，验收自然没有通过，乙方还需要再付出更多的工作才能搞定这个事情。
这个是真实个案，验收是需要大小Boss通吃的，固然要搞定大Boss，也需要搞定小Boss！
大Boss是需要下面的人工作的，他手下哪些人能干活、哪些人不能干活，他自然很清楚，所以如果他手下的业务骨干认为系统不可用、不能验收，他自然也不会同意验收。
法则3：一定要避免“一失足成千古恨”的错误
悲惨案例1：数据库数据被删除
某项目要安装一个小版本，对客户的原有版本进行了升级。本来以为是一个小事一桩，但升级后客户说见不到数据了，我们查看数据库，发现数据库中的一些表的记录全部没有了！检查后发现，我们的开发人员去做数据库升级的时候，犯下了超级低级的错误，居然直接用SQL Server自动生成的SQL去升级，而且居然还不去看一下这些SQL语句，哪怕是去看一眼。SQL Server自动生成的SQL是很坑爹的，它首先检查有没有这个表，有的话就Drop掉，然后重新建表，这样当然就删掉了很多记录了。本来这个悲剧的事情是有挽救的机会的，我们规定所有的升级工作之前要备份数据库，无奈我们一直无视这个规定，一直贪方便不备份数据库。
悲惨案例2：格式化客户服务器的硬盘
某客户服务器出问题，找我们去解决问题，实施工程师检查后决定用“绝招”——重装系统！实施工程师问客户：格掉C盘有没有问题？C盘有没有东西要备份？客户说：没有！实施工程师又再次确认：格调后数据都会丢失，不能恢复的，确认没有东西要备份？客户说：没有！于是C盘被格掉，系统重装了，问题解决了。但几天后，另外一个客户说：C盘的某些数据怎么没有了？后来客户的大Boss自然就来追究我们责任了，而之前一直说可以格掉C盘的客户就没有吭过声，而我们又不能“捅”他出来。
实施工作中会有升级数据库、格式化硬盘等“危险性”动作，做这些工作之前一定要做足备份。哪怕我们之前的工作做得很好，客户关系搞得很好，万一不小心干了无法挽救的错事，例如：删掉了客户几年来的数据又不能恢复、干掉了客户有重要数据的硬盘而没有备份等，这些都会直接导致灾难性的后果。
法则4：用户文档要同步交付
通常系统好不容易按期发布了，但用户文档是不会同步发布的，因为根本就没有时间去做这个事情。
但我们的要求是用户文档必须同步发布！这样的要求是因为：
1）用户文档是推动验收的有力工具；
2）用户文档可以降低服务工作量（参见下一条法则）。
法则5：用户文档是为了降低服务工作量
某电视机的说明书是这样写的：按什么菜单，弹出什么窗口，按“确定”按钮确定，按“取消”按钮取消……
看了等于没看，这样的说明书写了等于没写，不如不写！
应该写怎样的用户文档呢？
通常的写法是按照功能点一个一个的讲解，这些的写法是没有什么实质性用途的。要从客户的角度，业务的角度来写，通常要针对客户的不同用户群，模拟不同的角色的日常工作环境，告诉他要完成你的某项工作，你要怎样使用这个系统。不需要写“按确定按钮确定，按取消按钮取消”之类的废话，客户不是傻滴。
另外一个重要的用户文档就是管理员手册，要针对客户管理员的水平，写他能看懂能操作的文档，管理员手册通常写得内容是如何安装、调试、备份系统，通常需要写得比较傻瓜化，要有很多截图，要一步一步来写。
客户不喜欢看用户文档，就喜欢找我们，咋办？
我们首先保证用户文档的质量，然后就是要引导客户多看文档，让客户遇到问题第一反应是看文档，仍然不懂才找我们。
写用户文档不是为了要和软件配套，不是为门面好看，而是有“阴谋”的，就是降低我们的工作量！用户文档的方式可以是Word文档、打印出来的手册、在线帮助、视频等。
法则6：培训要有针对性
技术人员做培训，最容易犯的毛病就是从技术人员的角度来讲解，结果让大家听到一头雾水。我以前就经常这样干，而且还以为自己很牛B，你们听不懂是因为你们不懂技术！
给客户培训系统，目的就是让客户尽快上手，然后方便验收。通常这样的培训要分几次：
1）第一次培训：这次培训通常叫启动大会之类的名字，客户最高领导会参与，中层领导也会参与，然后是大量的基层员工。
我曾经也在类似的大会上做过这样的培训，效果不是很好；后面我总结出这样的大会，你的主要目标就是让客户的高层领导满意，你不需要面面俱到，你需要重点介绍：
a）系统的愿景和目标；
b）高层领导需要用到系统什么功能，能帮助他实现什么业务价值；
c）用户的其他关键角色需要用到系统什么功能，能帮助他实现什么业务价值。
2）后续的多次培训：这些培训通常是针对特定的受众的，例如：分别为不同的部门讲解如何使用这个系统，这个时候的培训就需要讲得比较细了。
培训可能是推动客户使用系统的最节省工作量的方法。要让客户几百人都用上这个系统，一对一手把手教肯定不行，我们需要有策略的培训，同时要注意培养客户的内部讲师，让他们可以内部进行分享。
法则7：降低差旅标准并不能降低实施成本
某公司为了节省实施成本，降低了实施工程师的差旅标准，原来可以坐飞机的改成坐火车，原来可以住3星酒店的改为2星……
实施工作通常要出差，出差工作诸多不方便，其实是挺辛苦的，如果再来一些”不人道“的差旅标准，对士气打击其实相当大，其实一点都不能节省成本！
降低实施成本的最有效办法是：
1）规划好实施工作，保证每次实施都有效果。
2）不要随传随到，每次实施之前都要和客户做好沟通，让客户做好准备。
3）用尽量少的实施次数和时间来达到验收这个目的。
对实施人员的差旅待遇要好一点，当然不是非要要求住5星级酒店，但至少要给多一些的人文关怀，让实施工程师安心和放心了，每次的工作效果自然更好，这样就会减少实施次数，节省更多成本。
法则8：“挨义气”做的事情一定要讲清楚
客户电话过来说：你们昨天安装系统，搞坏了我们的系统，快来看看！
我们吓一大跳，跑去一看，原来不关我们事，昨天动过这个服务器的还有其他人，但是我们还是帮助客户修复了问题。
上述仅仅是一个小个案，我们常常会帮客户做一些合同以外的事情，但客户并不一定知道这些是合同以外的事情，如果我们不加说明，久而久之，客户就会认为这是”理所当然“的事情。所以一定要说明，最好一开始就说明，并且每隔一段时间来一个汇总，说明我们干了哪些”挨义气“的事情。我们干的这些”挨义气“事情，要事先请示我们的老板，并且要报告我们的完成情况。从我们的角度看来，我们干这些”挨义气“的事情就是为了不得罪客户，维持客户关系，但从我们老板的角度看来，我们干这些事情是他和客户老板谈判的筹码。
法则9：最好设置专职的实施岗位
我曾经反对设置专职的实施岗位，我认为这个事情让开发人员“顺便”干了就行了。但后来体会到实施工作没有这么简单，对实施工程师的要求也很高，设立专职是必要的，而且效果更好。看看上文列出来的实施工程师需要掌握的几个技能，和客户沟通的能力、商务触觉这两点，一般开发人员是很难具备的。另外实施工作其实工作量挺大的，如果有专职的实施工程师，可以让开发人员更加专注开发工作。
但刚开始设立实施岗位的时候，很可能会出现“阵痛”，总体工作量更高。当时我们实施部刚刚成立不久，但部门项目组不喜欢找实施部来实施，他们说还不如开发人员直接实施了，这样更加节省时间，因为实施部的人不具备相应的技能。而实施部的头反驳说：1）实施部一直等待项目组的召唤，并且一开始就打招呼了；2）实施部的同事具备相应的技能。这样公司出现了开发部门忙死，实施部很闲的情况，而两个部门还在PK。
要尽快完成这个过渡，我们需要：
1）无论是开发部还是实施部，都需要理解实施工作的重要性和难度；
2）所有人都需要理解为什么要设立实施部，这个部门会降低开发部的工作量，并且更加有利于推动项目验收。
3）前期需要开发部的同事多帮助实施部提升水平，而实施部的同事需要严格要求自己，尽快进步。
法则10：实施工作需要贯穿项目整个过程
这个法则我放到最后再说，看了上述法则后，相信你对实施工作应该有新的认识了，所以实施不是最后才做的工作，一开始就需要准备，并且贯穿整个过程。
实施工程师的职业发展建议
我曾经招聘过实施工程师，我必须思考这个岗位的职业发展路线，帮每一位应聘者“画一个饼”。
这个岗位有三个比较好的发展路线，供你参考：
1）往销售和市场的方向发展。
实施工作帮助你沉淀了技术知识和业务知识，锻炼了你和客户相处的能力，为你成为超级销售打下了基础。从打工的角度看，可能销售这个职位是最赚钱的，当然这个职位是高风险高收入的，但你的实施工作积累会大大地降低你的风险。
2）往项目经理方向发展。
3）往产品经理的方向发展。
小结：
实施工作是高技术含量的工作，是需要和客户相处的工作，是需要商务触觉的工作。
作为项目管理者的你，希望本文能对你改善项目工作带来一些帮助；如果你是实施工程师，那么本文特别是职业发展建议部分希望能对你有一点点小帮助。
八， 计划篇
什么是项目计划？
计划其实就是为了实现项目的目标，对项目各项工作的统筹安排。
那什么是项目的“各项工作”呢？
各项工作包括团队建设、项目分析、需求分析与管理、软件设计、编码、测试、实施等，本系列前面的文章逐一分享了”各项工作“（当然项目的”各项工作“不止这些，后文会补充说明）。各项工作的最佳实践，将会直接决定计划的质量。
计划对加速工期有多大帮助？
有朋友问了一个计划应该如何写的问题。这位朋友已经有几年的软件研发一线工作经验，项目经理的工作也不是第一天干的，问出这样的问题我觉得有点怪。但我仍然说了一通项目计划的“大道理”供他参考。然后他说：项目成员技能不足，计划怎样写？
后来我才发现，他的真正问题是：如何写好计划以保证工期！
我给出的回答竟然是：计划本身对加速工期并没有帮助！
要加速项目工期，主要在于两方面：
1）提升需求分析与管理能力，能为客户带来价值的前提下，尽量将需求控制在一定范围内并尽量简单。
2）提升软件的设计能力，让项目的整体工作量下降。
如果项目小组能力不足，并且不重视上述两个方面，那么这个计划怎样写都是写不好的，写计划不是纸上谈兵啊。
而通常情况我们的工期是限死的，所以我们的计划是“倒推法”写出来的，计划中的关键节点基本上通过倒推法已经卡死，我们能做的事情就是想办法让事情变得更简单、工作量更少和提升我们的能力，以便在工期内完成项目！
所以计划及计划跟踪的问题，并不是仅仅本篇就能解决的，你还需要再认真看看前面的几篇文章，理解项目的”各项工作“是做好计划的根本。
法则1：项目管理首先是一门技术活
作为新上任的项目经理，如何写计划指导大家工作呢？
首先请做这两条自测题：
1）你熟悉这个项目需求吗？
2）你熟悉这个项目需要用到的开发语言、数据库和相关技术吗？
如果上述两条题目的回答都是NO，你是无法开展工作的。
软件项目管理首先是一门技术活，如果你不懂需求、不懂技术，你将会：
1）无法拆解工作；
2）无法和项目组成员沟通；
3）无法与客户沟通。
当然大部分项目经理是技术出身的，这方面的问题就不太严重；但有些项目经理是“外行”出身的，如果又不愿意去学习需求和技术，那么只能说祝你好运了……
法则2：项目经理需要周身刀并且每把刀都要锋利
中国的项目经理，通常要干以下事情：
1）项目管理（这个不用说了，废话）；
2）需求分析与管理；
3）软件设计，包括数据库设计；
4）写代码；
5）测试软件；
6）和客户沟通；
……
或者这样说会更合适一点，项目经理不干的事情有哪些？结果你发现：没有！
项目经理必须是全才，而且各方面能力都需要数一数二！
当然你会说：你当我是齐天大圣啊，可以三头六臂地干活！
以下一些实用建议供你参考：
1）有机会要尽量每方面都学习一下锻炼一下，项目经理确实是需要全才；
2）如果项目规模不大，那么你一个人兼任”管理+需求+设计”是可以的；
3）如果项目规模比较大，你可以兼任“管理+需求”或“管理+设计”；
4）哪怕项目规划超级大，不建议你干“纯管理”的事情，你至少要兼任“管理+需求”。“纯管理”其实是干不了事情的，还需要其他人“服侍”你，你才能“纯管理”。
法则3：积极提升项目成员水平
我做过这么多项目，没有试过项目小组从一开始具备了完成这个项目所需要的全部能力，这种情况估计以后也不会发生。提升项目成员的能力和水平，是按期交付的重要因素，甚至是决定性因素。
员工离职的两个重要因素，一个是薪金，另外一个就是学不到东西。项目经理可能还无法直接提升项目成员的薪金，但你可以创造学习机会和环境，甚至是亲自传授知识给项目成员，让他可以学到提升薪金的技能。如果你的下属离职了，原因是一直学不到东西，那么你们两个可以抱头痛哭了！
法则4：应对变化的最好办法就是计划
计划赶不上变化，所以计划写了也没有用！果然如此吗？
你可能觉得软件项目“两大限死两不确定”很恐怖，其实有更恐怖的项目呢，那就是战争指挥！
打仗要不要写作战计划？战争中信息千变万化，你会因为这样而不准备作战计划吗？情况越复杂，不确定因素越多，其实越需要计划！
法则5：估不准总比不估算要好！
估算很恐怖，很多人不愿意估算，主要原因有：
1）“两大限死“，估了等于没估；
2）“两不确定”直接导致无法估算；
3）估算就是一种承诺，我可不愿意自己限死自己啊。
其实在我们软件开发，估算偏差达到100%是很常见的事情，甚至是200-300%都很正常，但如果不估算，你的误差就是无穷大！
勇敢的跨出第一步，估不准总比不估算要好，估算和实际工作量之间总会有个谱，只要跨出第一步，我们就有改进基础了！
法则6：计划需要近期细，中长期粗，并持续细化和优化
曾经负责某项目，项目工期3个月，领导要求我写出3个月的详细计划。我很郁闷，死活写不出来，我不想纸上谈兵、不想浪费时间写这些没有用的计划，所以我还去和领导理论这样的做法是不合理的。软件项目存在这么多不确定因素，一般来说几周后的具体工作是很难计划出来的，所以法则6很重要。计划并不是僵化的东西，需要持续细化和优化。
其实比较怕遇到外行的领导，外行领导监督工作的办法就是让你写计划，然后根据你的计划来检查你，而这个计划的工期是卡死的。如果有人用这个你无奈而写的计划来卡死你，你肯定不愿意写这样的计划。
开明的领导是这样做的：
1）计划写出来了，我会全力支持你完成计划，包括：提供各种资源、协调各部门、协调客户等等；
2）计划可以变，可以推迟，但你要尽早告诉我；
3）我不会用计划作为你工作成绩的检查标准，也不会以此来绩效考核。
法则7：人人都是项目管理者
很多项目经理都有这样的感触：好像整个项目小组当中，就只有自己最紧张项目的成败，其他人的心态就是完成工作的打工心态。其他人似乎从来不会主动汇报工作，主动思考项目的风险与问题等。
项目管理是每一个人的事情，而不仅仅是项目经理的事情，每一个人至少需要做到：
1）全力完成工作，要保证工作质量；
2）要主动报告进度，遇到风险和问题要主动提出来；
3）要主动管理好自己的工作产品；（做好自己工作产品的配置管理）
4）要主动协助同事完成工作；
5）要主动沟通。
每一个人至少要做到能管理好自己的工作，如果自己的工作还需要别人来管理，这样的工作水平是不及格的！
法则8：计划的执行在于每一天！
我们都知道以下大道理：
1）项目的问题都是通过一天天积累的；
2）问题越早发现，解决成本越低。
但我们往往在计划跟踪上节省时间，结果得不偿失，在临近项目死期（发布日），进入正式测试阶段时问题大爆发：
1）某些需求没有实现；
2）某些缺陷无法改，需要改动数据库底层或软件架构才能搞定；
3）软件整体的用户体验很差，但这些问题已经遍地都是了，没有时间去改；
4）一大堆不符合编码规范的代码；
……
每天的计划跟踪能解决上述问题，并且能加速项目成员的能力提升。
跟踪计划的最有效方法是眼见为实，就是直接编译程序看看运行效果，同时检查代码与数据库实现。
法则9：通用项目管理知识的对项目的帮助不大
我在大学时曾经学过“施工进度管理”的课程（我大学学的专业是城镇建设），当时学了很多项目管理的知识，例如：前置任务后置任务、关键路径、单代号网络图、双代号网络图、甘特图、流水施工等等概念，开阔了很大的眼界，发现项目管理确实是一门高深的学问。后来我的课程设计就是要写一个施工进度计划，我纸上谈兵地完成了这个课程设计，结果我感觉良好，以为自己就是项目管理大牛了！
幸好我舅父给我泼了冷水，让我浮躁的心安静下来。当时舅父带我到某建筑工地见识一下，我见到工地的办公室中有一张很大的甘提图（进度计划），我问这个图有用吗？我舅父说：这个图只是摆出来应付检查的！
从事软件研发工作后，尽管我学过一些项目管理知识，但确实发现这些知识对项目管理基本上没有实质性的帮助。刚学习时，你确实会有“哇呀”这样的感觉，项目管理居然可以这样！实际上如果你没有丰厚的一线研发工作经验，软件项目管理是做不好的。
关于通用项目管理知识的学习建议：
1）公司报销或者你是土豪，并且你有很多空余时间，建议去考一考PMP，这个过程还是学到一些知识的；
2）没有银两，但你有很多时间，可以去自学一下，考证就不是必须的了；
3）这些通用的项目管理知识不要硬套到软件项目上。