IT项目 软件研发最佳实践

一，软件研发最佳实践

二， 战略

三， 需求篇

四， 设计篇

五， 编码篇

六， 测试篇

七， 实施篇

八， 计划篇

知道什么是挨踢项目吧么！不知道IT项目知道了吧了不让客户踢、不让老板踢、项目组成员之间不互相踢，俺为大家分享一些减少被踢机会的心得体会。就算不能让项目成功，也至少不会死得那么惨吧！我将分团队建设篇、战略篇、需求篇、设计篇、编码篇、测试篇、实施篇和计划篇为你分享。

一， 软件研发最佳实践

什么叫挨踢项目/strong>
IT项目，特别是软件开发项目，都属于“挨踢”项目的范畴。挨踢项目的几大特点：
1.需求不确定。
2.技术不确定。
3.工期限死。
4.预算限死
两大不确定和两大限死，你想不“挨踢”都难！

由“踢皮球”事件想到的
事件回放：
某项目部署给客户后，重现了一些以前已经解决的问题，而这些问题测试时并没有出现。经检查，发现测试的版本不是部署的版本，不知道为什么老版本部署给客户了。领导要追究责任，于是大家各有说法：
开发人员说：我是按要求打标签的，没有问题。
测试人员说：我是在提交区中取版本来测试的，我没有出错。
实施人员说：我是按照开发给我的版本去部署的，我没有过失。
最后终于有人说：是之前已经离职的某某弄错版本号导致的。

该事件暴露了很多问题，但我想说的是团队建设的问题，没有任何一个人首先从自己身上找原因，第一反应就是推卸责任！
唐僧四师徒西天取经，如果每个人都是这样，不是自己内斗死，就是被妖怪吃掉！优秀的团队能“自动”解决很多问题，如何才能打造良好的团队文化呢/p>

良好团队文化的源泉是什么/strong>
良好团队文化的根本其实就是老板的管理思想了，不同的管理思想，老板会设计不同的部门规划和考核办法。
有朋友提到他的Boss喜欢工厂化管理，硬生生将员工分成两类人，设成两个部门。一个部门叫设计部门，负责需求和设计；一个部门叫实施部门，负责编码、测试、实施。设计部门通过一个任务管理系统向实施部门下单，实施部门根据这些工单来工作。该老板还设计了自以为很牛的考核办法，如果实施部门不能按时按质完成工单，则会影响考核；如果设计部门的工单被实施部门退回，则会影响设计部门的考核。于是两个部门之间的扯皮时间天天发生，以前完成一个工作很简单的，现在要扯来扯去。设计部门自认为需求、设计等文档已经写得很清楚，实施部门认为已经按照这些文档完成工作，或者是认为这些文档说得不够具体，要退单。当文档主要用来任务交接的时候，文档就会变成茶几上的杯具！
还有一些老板喜欢用bug数量、文档缺陷率、工期延误率等所谓客观的量化的数据来考核，同样只不过是杯具的另一种形式而已。
软件研发活动是人类复杂的高级智力活动，是需要team work的活动。如果明白这个道理，如果懂软件开发，就不会设计出这些傻瓜的管理措施，将软件研发团队的每个人变成机械人、卸责人。研发团队中的每一个人都应该是值得尊重的、有血有肉的、充满激情和战斗力的专家！

作为Team Leader应该怎样做/strong>
Boss的想法我们无法控制，虽然无法从根本上改变公司的部门设计和考核制度，但作为Team Leader来说，在能力范围内还是可以做很多事情的。Team Leader应尊重每一位Team Member，平等地对待他们，充分发挥他们的潜力，给予足够的支持和成长空间等。对大家好，大家是知道的，将来会给你带来更大的回报。

下面一些法则供你参考。

法则1：一荣俱荣，一损俱损
项目组由项目管理、需求分析、软件设计、编码、测试、实施等各方面的专业人士组成，每位成员在自己专业领域内发挥主导作用，并可以为项目的成功提出非自己领域内的建议。最终的项目成果是各位专业人士共同努力的结果，所有人对最终成功承担同等的责任。
如果系统部署后，系统出现了一个严重缺陷，请问谁应该负责br> 项目经理试发…
都不是，而是项目组全体都要负责！
软件中某个功能做得很炫很好用，请问谁应该受到表扬br> 项目奖励发下来了，请问谁可以分到这份奖励br> 以上问题相信你应该有答案了！
项目组全体是共同承担连带责任的，要死一起输死，要活一起活。如果项目组中有人受罚，有人会得到好处，这个Team是很难团结和有战斗力的。

法则2：让 Team Member 当家作主
项目组中难免有部分成员是新手，经验和水平不足，某些工作可能一时不能胜任。而我们往往迫于项目进度压力，某些任务就会直接安排给他做，不让他提出自己的想法和见解。而我们这些接受了中国式教育的人，不少人喜欢以“接受任务”的方式来工作，而不是主动迎接挑战。于是有时候你可能遇到一些成员会跟你说“今天工作已经完成！”“我按照任务要求来做的，我没有错！”之类的活活会气死你的说话。
不要剥夺项目成员当家做主的机会，应相信每位成员在他的专业领域内都是专家，在他的专业范围内，他可以说了算！只要满足项目的大框架，只要出发点是为了项目成功，那么这段代码应该怎样写、这个功能点应该如何测试等之类的决定，完全可以交给Team Member来做主！项目成员可能一时没有魄力独立做决定，可能担心犯错误，没关系，要多多鼓励他！犯错不可怕，因为还有“法则3：鼓励犯错！”

法则3：鼓励犯错！
少做少错，不做不错。如果犯错误会受到惩罚的话，那么前面八个字就会应验！
犯错几种情况：
1.经常挑战高难度工作，犯错是难免的。
2.做一些之前没有经验的工作，犯错也是难免的。
3.犯一些低级错误。
4.犯一些之前曾经犯过的完全可以避免的错误。 
对于情况1、2，绝对是需要鼓励的！对于情况3、4，要帮助他避免这类的错误。
软件研发工作大部分是高难度和复杂的，加上进度压力大，犯错是不可避免的，如何在总结中前进。一个在工作中从来不犯错的人，他不是神，他应该是那种“少做少错，不做不错”的人，或者是专挑低难度工作的人，你喜欢这样的人/p>

法则4：言传身教
曾经见到这样的一些领导，当下属有问题求助时，他会板起脸孔，摆出领导的样子，然后说：你自己不会解决问题吗应该自己列出解决方案后才来找我！
我赞同领导不应该帮下属解决所有问题，有些问题应该由下属自己搞定，但下属是不可能搞定所有问题的，有些问题超出能力范围和职责范围，作为领导就应该出手。
作为Team Leader，应着重帮助Member养成良好的工作习惯和工作方法。中国式教育培养出来的学生，可能会喜欢直接得到答案，而不求工作方法。这个中国式教育的错，就只能由我们来补了。

法则5：挡住骚扰团队的外来干扰
Team Leader应当住来组团队外部的干扰，让团队可以专心工作。挡住麻烦是Leader的职责之一，而不要因为嫌麻烦，而让你的Member去处理这些麻烦。

法则6：全力维护团队利益
某部门的员工的薪金近年来很少得到提升，原因是该部门经理对外是好好先生，每年都不会主动积极为部门争取加薪的预算，总是被别的部门抢去预算。
某项目出了问题，老板找来项目经理，说要找人负责任，否则不好向客户交代。以下三个选择你会选哪个br> A.该问题确实主要是因为某Member导致的，所有他来负责是应该的。
B.这是团队的责任，要全体负责。
C.尽管是主要因为某人出错导致的，但作为PM的我应该负主要责任。
作为一个Team Leader，无论任何情况下都不应该“出卖”自己的Member，应该自己一力承担！回头你可以关起门来，批评这位犯错的Member。

法则7：我们是一个人
法则7是最重要的，其实只要能做到“我们是一个人”，其他法则自然就做到了。你不会和自己的左手作对的，右脚不会和左手打架，你的身体哪一部分受伤，你都会觉得疼，一个人的手脚动作是很容易协调的。如果我们团队能凝聚在一起，达到“我们是一个人”的效果，那么我们将战无不胜！

二， 战略

指挥战争可能是最复杂的项目管理/strong>

做挨踢项目可能比较杯具，但最复杂、难度最高、代价最大的项目管理可能是战争的管理了。战争靠什么取胜呢果你是这场战争其中一方的统帅，你会如何指挥这样战争呢可能会说：你不是在扯淡吗挨踢项目管理，怎么跑到战争去了我们先看看战争的战略管理，然后再回到项目的战略管理吧。

白起的故事
白起你不会没有听说过吧是那个杀死几十万赵国俘虏的杀人狂魔。但我说的不是他杀俘虏的事情，而是白起被称为战神，一生没有打过败仗，他是如何做到的为他只选择打战略上能打赢的仗！
当时只有赵国有实力和秦国一战，双方几十万大军对峙在长平一带。秦军统帅是白起，赵军统帅是廉颇。白起对于此战的战略上的判断是这样的：两国实力、军力相当，如果全力出战，秦国能胜，但只能是惨胜，这样的后果只能是削弱了自己，反而让其他战国有机可乘。秦国的优势在于全国上下一心，特别是秦王和大臣们众志成城。而赵国虽然军力不错，但赵国内部权力斗争厉害，各派只为自己利益不顾国家利益。因此白起定下的战争策略是：对外称病不能担当统帅，隐藏自己做统帅的事实，以拖待变，寻找有利战机再出击。另一方面，秦国使出反间计，成功让赵国更换主帅，换了那个很出名的只会“纸上谈兵”的赵括。
赵括上任后，全军出击，结果中了白起埋伏，白起利用地形，用基本相等的数量的士兵困住了几十万赵军，不与之决战，消耗赵军的粮草，最后赵军被迫投降。后面就是白起杀死几十万降兵的事情了。白起成功地用比较少的代价，给赵国带来致命的打击。
白起杀死几十万降兵后，立马建议秦王马上挥军灭掉赵国。秦王认为此时出击必会促使六国合纵，这样秦国会招架不住；但白起认为，刚杀掉几十万降兵，其他五国还在震惊之中，没有这么快缓过气来，一时无法合纵，此时正是灭掉赵国的好时机！但秦王坚持自己的想法，白起只有退兵。后来秦王后悔了，想让白起率军灭掉赵国。这时白起认为：其他五国已经缓过气来了，此时攻击赵国，六国必会合纵。但秦王一意孤行，白起托病不统军，秦王另找人统帅，结果六国果然合纵，出现了“信陵君盗取帅印”促使魏国出兵的著名历史事件，秦军大败。秦王再次要求白起统帅，认为只要白起统帅必能获胜，但白起仍然推辞，最后秦王恼羞成怒，杀了白起。
白起在战略上的判断是相当准确的，可惜他的老板和他想法不一样，白起拒绝执行战略上注定失败的决策，虽然避免了自己打败仗，但得罪了老板，下场凄惨啊！咱们这些做项目的，如果遇到一个战略上有问题的项目，你是做还是不做呢/span>

庞涓的故事
说起庞涓，大家可能马上想到的是他如何害孙膑，然后孙膑又如何设计杀之报复。其实庞涓是一个战略上判断正确的人，只是被迫执行了战略上有问题的决策。
庞涓是魏国的大将，他对魏王建议的国策是：先西进灭掉秦国，解除后顾之忧后再图其他。秦国当时并不强大，多年与魏国争夺河西河东，“三十年河西三十年河东”的故事就是这样来的。但魏王认为：秦国很穷，但秦人很彪悍，灭掉秦国代价太大，没啥好处。魏王最想做的事情是灭掉赵国和韩国，所谓的“三晋合一”，魏、赵、韩原本同属晋国，后来他们将之瓜分掉。庞涓认为：灭掉赵国、韩国是不可行的，因为附近的战国，特别是齐国不会让魏国成功的，其他战国必会出兵。但魏王执意要先灭赵国，然后是韩国，让庞涓统帅。庞涓只能坚决执行老板的决策，率军猛攻赵国，就快攻克邯郸之时，齐国突然出兵突袭魏国的大梁，这就是“围魏救赵”的故事。庞涓只能回师救大梁，途中遇到和伏击，损失惨重，但还不至于战死。
魏王仍然不甘心，再次要庞涓统帅灭韩国，故事再次上演，这次是“围魏救韩”。庞涓再次回师，孙膑上演了“逐日减灶”的典故，让庞涓判断失误，率大军进入死地，被齐军伏击致死。
庞涓同样在战略上的判断是基本正确的，但他的老板想法不是这样，庞涓作为老板的手下，他选择了坚决执行老板的决策，但仍然得不到好下场！

遇到一个战略上有问题的项目，你不做会死，做也会死，怎么办呢/span>

认识软件项目的战略管理和战术管理
上面两个故事，希望我能大概说清楚什么是战略。项目的战略大概就是指：能决定项目成败的宏观因素，如：甲乙双方在这个项目上的商业利益、双方领导的特点、项目的预算、目标、工期等，还有就是你所带领的团队是否有能力有条件完成这个项目等。
战略上有赢的可能，加上好的战术，项目才有机会成功。
战略上没赢的可能，无论用什么好的战术，项目都逃不过失败。
战略上有赢的大好条件，但你的战术很差，项目也会失败，你浪费了一个大好的项目！

希望我们能尽量选择战略上有机会赢的项目，万一运气不好，挑上了一个战略上没机会赢的项目，那么就要想办法不要死得那么惨。
下面的法则供你参考。

法则1：从战略高度出发
客户为什么要做这个项目们公司为什么承接这个项目/span>
合同的金额是多少们公司对这个项目的预算是多少目工期有多长/span>
你的项目团队有什么人个人的水平和潜力怎样/span>
有没有其他影响项目成功的重大风险/span>
以上问题应该尽早搞清楚，通常来说可以在公司的高层领导那里得到很多重要信息，但如果你无法接触高层，或者高层不鸟你，你用尽所有办法都难以获取以上的重要信息，那么你基本上可以判断：这个项目死定！
最怕遇到一些让你自己解决所有问题的领导，这些只能是无水平、不负责任的领导！除了合同金额一些涉及公司机密的内容可能不方便漏录外，其他信息是必须让项目经理知道的，而且有些事情是需要高层出马帮助项目组去搞定的。
遇到高层不鸟你的情况，法则1-4都没啥作用，你可以直接看法则5。

法则2：尽量提高你在客户面前的地位
通常情况下，我们需要门当户对地和客户接触，高层VS高层，基层VS基层。如果你是一位小小程序员，想和客户高层说话，这是大忌！
很不幸的是，项目经理能经常接触的客户中的最高领导，只能是对方的业务骨干，最多是部门经理，而项目经理以下的项目成员，身份更加是低微了。
为了让项目组将来的工作更加主动，要做好项目组成员的“包装”，例如让项目经理挂上副总、总监之类的头衔，尽量让项目成员的身份放大和提高。第一次和客户接触时，就要包装好你的高大形象。例如项目启动会上，以比较高的形象来展示项目组各成员。

法则3：让客户的高层重视项目
越是高层的客户，越抓得住项目的目标，越是基层的客户，越容易陷入细节，甚至提出很多匪夷所思的要求。如果客户的高层能向下属明确本项目的目标和范围，那么客户的中层基层就比较容易搞定了。
法则2做得好，就很有机会让项目经理可以直接接触到客户的高层，项目经理在掌握了项目的战略的情况下，了解了客户大致想法的情况下，就比较容易驱动客户高层做事情了。如果项目经理不好接触客户的高层，那么就要动用法则4，让你的高层去找客户的高层。

法则4：驱动你的高层做事情
项目中很多重大问题，方向性的问题，其实是需要我们的高层去处理的。例如让我们的高层与客户高层明确项目的目标与范围，推动客户配合需求调研工作，推动上线试运行，推动验收等。项目中出现重大问题，会影响项目成功时，都应该第一时间将问题反馈给我们的高层，让高层去处理或给出建议。
我不觉得你能解决所有问题才叫厉害，在项目组的层面确实有些问题是无法解决的，这些问题如果不及时让高层知道并让高层支援你，问题将会变得更加严重。
如果你的高层是那种什么事情都让你自己搞定的“无能”领导的话，那么本法则不适用，请看“法则5：输少当赢！”

法则5：输少当赢！
如果是项目战略上判断觉得无赢的可能，但你的高层领导认为可以赢，执意要求你执行他的决策，那么本法则可能会让你不会死得那么惨。
做一个战略上不可能赢的项目是很痛苦的，最佳选择是不做这个项目，但通常你没得选，你只能硬头皮上。你应该庆幸，不是让你做战争的统帅，你不会象白起或者庞涓那样会死得很惨，你最多是辞职不干！
万一赢头皮要做这样的项目，只能是“输少当赢”了。向你的高层随时报告进展，遇到什么问题全部抛给他，美名其曰：向您请教应该如何处理！遇到与领导有某些分歧，你可以适当地争论一下，然后假装被你的领导说服，你还要装作很受教的样子。你只能在很有限的空间内，尽量降低这个项目的损失，尽量降低你将来需要承受后果的严重程度。将一些问题及时抛给高层，或许会有机会帮助高层重新思考自己的想法，逐步修正他对这个项目的战略判断，这样的话会慢慢变得对你有利。
采用法则5时，是不得已的选择。如果想不做这个项目，恐怕只能选择辞职；为生活，只能暂时忍一忍，接手这个烫手山芋吧。
关键是心态要好，尽自己力就OK了，对得起自己，也对得起这个项目。挨领导的批可能是不可避免的了，当他唱歌吧！

法则5是没有办法的选择

上策：不做这个项目，或说服领导放弃这个项目。
中策：在做这个项目的过程中，通过不断抛问题给领导，让领导重新思考修正想法。
下策：硬着头皮执行领导的决策，尽量少输。并且在一开始就将项目情况透明化，让领导随时知道项目进展和问题，这样至少有两个好处：1.领导有机会修正想法，从而向“中策”方向发展；2.将来发生问题时，领导就不会觉得“惊喜”了，项目组就不会死得那么惨。缺点就是：一开始就抛问题给领导，领导会不高兴的。你愿意选择一开始就让他不高兴是隐瞒问题，最后给一个“惊吓”给他呢/span>

不过话说回来，所谓我们认为领导对这个项目的战略分析是错的，这只是我们主观的看法。真是情况有可能是以下几种：
1.你是正确的，领导是错的。
2.你是错的，领导是正确。
3.你和领导都判断错了。

领导坚持他的判断，有些理由可能是不方便告诉你的，所以我们也不能断定自己的想法一定比领导的要好。

但这个项目最终是由你来完成的，如果你的想法与领导的想法从根本上是不一致的，做起这个项目来就会相当痛苦。

三， 需求篇

由“我要吃饭”的故事想到的

某天某客户跟你说：“我要吃饭！”
你非常关注客户这个需求：“请问您要吃中餐还是西餐呢想吃什么呢
客户非常开心，一下子说出了很多想吃的：
“西餐嘛，不错，听说那个菲力牛排很不错，配上红酒更加美味！”
“不过听说某某路的那个潮汕牛肉丸火锅，牛味很浓，牛气冲天……”
“哎呀，最近上火，还是不吃这些上火的东西了，吃日本寿司吧，听说那里有日本菜自助餐，有生蚝，正啊！”
“啊，不行哦，最近日本核辐射，海鲜还是不吃了”
……
最后客户说：
“你还是先弄一顿给我尝尝吧，见到菜才能提出具体需求啊！”
遇到这样的客户，你可能想找10个馒头塞到他嘴里面，让他撑饱，搞定！

当你搞了大半天需求调研，仍然不知道客户想吃啥的时候，客户终于露馅了：“你快点吧，我饿得不行了！”
原来客户想解决肚子饿的问题啊，你马上说：“附近有一家XX大酒店，里面的粤菜很不错，人均消费300元可以搞定！”
客户很开心：“谢谢您请吃饭，让您破费了！”
你傻眼了，需求调研费还没有收呢，还要请吃饭！你说：“不好意思，吃饭的费用需要您自己搞定啊，而且我们还要收10%的需求调研费！”
客户急了：“我只有10块钱啊！”
你气死了，10块钱的预算想吃这么多东西！于是你提出一个解决方案：“咱们去那个XX快餐吧，那里的饭和白粥是随便吃的！咱们是老关系了，我们再赞助您10块，也不收您需求调研费了。”
没等你说话，客户就抓着你的手奔向那个XX快餐了：“快点吧，我快饿晕了！”

以上故事纯属虚构，如有雷同实属不幸！

这个故事是软件项目需求工作的缩影，客户的表面需求似乎很多，而且变来变去，很可能是因为我们没有抓住“我很饿”这个根本需求。客户可能提出很多匪夷所思的需求，提出一些超出自己预算范围的需求，如果我们能抓住客户的根本需求，让客户认识到自己的预算限制，再加上我们高水平的发挥，我们是有可能做出能满足客户根本需求，并且符合预算的软件系统。

需求分析与需求管理

我们可能经常听到一些关于需求方面的说词，如：需求开发、需求分析、需求调研、需求管理等等，下面将这些概念稍微梳理一下。
1）需求分析：
其他说法：需求调研、需求开发
关注点：如何获取和确认需求/span>
来源：bamboolsu