就软件开发项目而言，传统的生命周期基本重点是从需求分析开始，这当中会有个不大不小的问题，即“知识断层”。大部分软件项目中，项目经理接触项目通常是在合同签署后，这个时候就有一个很明显的断档，我相信有些项目经理没有过项目售前的经验（我不是指和销售人员跑跑客户讲讲方案演示下demo什么的），真正的项目售前其实是一个咨询的过程，这个过程要抓住客户，唯有四个字“提供价值”，这里的价值，表现为通过方案的描述，通俗易懂的描述能帮助客户解决什么问题，达到什么样的成果等等。这个阶段收集到的需求和目标才是客户最原始的项目需求。
全生命周期
和传统软件生命周期不同，一般软件工程理论只重视项目实施这一环。在真实项目场景中，我经常会听到项目经理抱怨“销售当初怎么和客户说的，画这么大个饼，也不提前支会我一声”。其实，这种情况不能完全怪销售或售前，项目经理在进入项目实施前，应主动找销售和售前人员了解当初拿下这个项目中所有的过程细节，了解从哪些地方打动了客户，哪些是客户真正关心的，即时在售前环节不是从技术上征服了客户的，你也有个心理预期，知道这项目客户想要的到底是什么。
举个不那么恰当的例子：谈恋爱中最具影响力的过程不是恋爱环节，而是你和对方确认恋爱关系前所做的一切努力，没前面的铺垫，一下子进入恋爱实施环节，肯定不是一个完整的过程，对吧，各位。
下面总结一下项目全生命周期的各个环节
因为篇幅所限，所以重点介绍一下项目售前和项目运维。关于项目实施，各类理论和学说在网络上汗牛充栋，就简单带过了。
项目售前
这个阶段的重要性如前文所述，经常被项目经理所忽视。导致的后果就是：项目视野狭窄、项目目标误判、项目理解周期长、项目磨合期长、客户意图理解周期长而导致的信任感低等问题。这些问题基本没人会提醒你，在哪个风险库中你也找不到，但是在实际项目中确实存在。下面就售前阶段的各个步骤简要说明。
可行性分析
通常这个阶段的目标是协助客户对项目的经济性、合规性、实施可行性、安全性等做个分析。简单说就是从业务角度帮客户做一个量化的投入产出分析，让IT部门能依据这份报告来说服老板答应立项（就是投钱）。
基本上这个阶段，销售接触的是客户的IT部门，即使是业务部门有熟人透露项目信息，最终也会转到IT部门过一道。相对于业务部门来说，IT部门更难搞定一些，毕竟对方既是IT专业出身，又对自身运营业务和特点熟悉。因此，可行性分析首先要打动他们。而打动他们其实就是他们认为能打动老板。因此不要小看这份报告，通常分管IT的CIO并没有什么决算权力，碰到审批权限之上的（软件项目我看大部分CIO都不是最终拍板的），基本上还是得由总经理（国企）或CEO（合资/外企）来拍板，但他们熟悉自己的文化和老板的风格，通常能到CIO位置的，揣摩上级心思还是很有一套的。因此在拿这份报告时，首先是得获取客户方上至IT老板下至分管项目的主管的认同，当然还有业务部门的认同。
通常这个阶段客户的优势是有一些IT应用的专业知识，熟悉内部业务和行业知识。但他们的缺点也刚好是我们的优势，就是在IT领域上，基本上乙方的专业知识会强出不少，更具有优势的是，部分乙方在行业经验上比甲方更具深度。因此，运用自己的专业知识和行业背景知识，理解客户业务部门的痛点，适当放大，再美化产出效果，是打动最终老板的唯一正途（歪途就不说了）。
这个阶段中，如果需求是由业务部门发起的，那么与业务部门的沟通尤其重要。有些企业IT部门与业务部门互相看不顺眼，这个时候你也没办法，必须硬着头皮去找业务部门沟通需求，聆听（注意这个词）他们的想法，理解他们的无奈，方案上与他们达成一致，
这个阶段的产出物，很多是PPT，重形式的国企或政府机构会要求出具文档形式的报告。PPT和文档都是一个累积的过程，等有空的时候我再来专门讲解如何制作PPT和文档。
有意思的是，这个阶段对项目型公司最难的是不具备行业背景知识。因此我给出一个文章《跟专业人学习一周摸清一个行业》的链接供大家参考，实际应用中，我也确实认同这种方式，可以在短期内写出一份比较精彩的报告来打动客户。
项目立项
这个阶段基本上就要看甲方老板的反应了，一般的销售就会傻等，稍微厉害的会怂恿IT部门的老板找老板一起开会汇报（当然事先要多次排练，一旦演砸基本上就没戏了），更厉害的除了汇报之外还会动用自身的人脉，适时的约上甲方老板时间汇报了。不过我看一般也就第二层了，第三层没点皇亲国戚的关系没人会鸟你。
这个阶段呢，销售还有一些辅助手段。譬如找业务部门的人，让他们适时的吹吹风。提供一些案例参观和考察的机会给甲方等等。
一旦老板点头同意立项了，基本上就成功有望了。这个阶段多少有点只能侧面迂回的感觉，除非是老板亲自抓的IT项目，那就另当别论了。
项目方案建议
这个阶段有些公司直接省略了，其实是不太合适的。最直接的后果是，销售感觉能做的，在没有专业技术人员支撑的前提下（售前很多是二把刀），无限画饼，承诺客户。导致期望和项目范围无限放大。最终结果就是项目经理接了个隐患重重的项目。
方案建议其实是一个项目中关键技术论证的报告，阅读对象是客户的IT和业务部门，其目的是告诉对方：1、你放心，从项目目标、实施范围、典型场景、关键技术、实施计划的方方面面我都考虑到了，让客户的IT部门对你的信任感无限上升；2、告诉客户，这个项目的边界在哪儿，项目中的实施范围的优先级、顺序、技术实现方式是什么；3、给客户吃一颗定心丸，知道项目接下来的实施模式是什么样的；
因此，这个报告的形式以文档为优，而且这个报告最好是由公司内专业的技术骨干、项目经理、销售、售前来一起写。花这点力气是值得的，一、此时项目经理和技术骨干的介入，会直接给技术实现以最可行的方式；二、此时项目经理的介入，会了解项目的背景、风险和由来，因此在这个阶段由项目经理和销售一起引导客户的技术思路是最有效的；三、最重要的，防止销售画大饼；
那么这个方案如何写呢。写一个好的方案建议书，要知道是给IT和业务部门看。因此开篇的时候要从业务角度去写，即“凤头”，通常的章节如“前言、项目目标、项目范围、实施内容、技术原则”这些。开篇就是要让人有眼前一亮的感觉，觉得你是懂我的，你是懂我这个行业的，你说的是我听得懂的话，你说的把我想的都总结了。
接下来的中间章节，一般称之为“猪肚”，通常有“系统开发平台、系统逻辑架构、系统物理架构、系统运行环境、关键技术实现”等内容，通常这部分业务部门会一眼带过，但IT部门会认真看，特别是架构部分的图，千万别马虎画，要经得起推敲。另外就是关键技术实现，实际上就是解答IT部门内心关于技术难点如何解决的疑问，同时给后来的项目组成员一个指导和参考。
最后的章节，就是怎么落地了，因此叫“豹尾”，意思是有力干脆。一般有“项目进度规划、项目管理保障、项目费用概算”这些，当然概算你事先要和客户达成一致。这个阶段可以稍稍高点。
招标与投标
这个阶段么，只要你方案建议做的好，基本上招标书的内容，客户都会照抄你方案建议书的内容，或是让你帮忙代劳。甚至评分规则上也会咨询你意见，向你倾斜。其实到这个份上，如果你还拿不下项目，基本上我只能说你们公司肯定有问题了。我就碰过这么一次，不过那是因为人员更替造成的，客户前期很信任那个写方案的项目经理，打了三次电话邀请他们公司来投标（因为乙方不想投，嫌金额小不够成本），后来甲方说可以缩减部分需求，甚至底价都说了，结果那个项目经理离职了，没人可以写投标方案，也没人可以讲标，这项目就黄了。所以软件公司么，最重要的真的是人。
至于标书的制作，没有什么窍门，就是两个字“仔细”，当然还需要深厚的方案写作功力。不过此时有前期的方案建议书可用，写起来也应该得心应手。总之，前面几个阶段做好了，只要不是天灾人祸，拿下项目是十拿九稳的事。
项目实施
这个过程没啥还多说的，敏捷、RUP、MSF各种东东，我想说的是，无论哪种方法，要重点注意的是，一定要在合同签署中或后有一个项目工作范围的确认，这个工作范围说白了，就是要完成哪些模块、功能，功能的具体描述，哪些是甲方要提供的条件，哪些不归乙方负责的，一定要仔仔细细想清楚了写，千万在里面不要在功能描述的时候来个“等等”之类的字眼，这个东东最好和作为合同附件，在和客户谈需求的时候将是你的最后一道防线。
项目运维
其实很多人忽视了这个阶段。我的实践经验中，我手上大部分项目都是在运维过程中冒出的新需求而产生的。而且，实际过程中，运维因为周期长，人员要求素质高（别以为放两个毕业生就可以），实际成本并不低。特别是现场运维，要有熟悉客户现场环境和项目开发过程的（别以为靠文档就可以两三天整明白的）人，最不济也要有人带上个把月，告诉你代码结构、功能特点、项目隐患、注意事项、客户脾气这些细节。才能放心把人放在现场运维。
运维制度/流程
项目运维之前，首先要和客户确认的运维制度和流程。而且必须把业务部门培训好，让他们可以进行一些简单的运维工作（前提是你们完成的系统不能太烂）。有了这个双方认可的运维制度/流程，基本上大家都知道如何处理日常问题，不会再出现扯皮拉筋的事了。
运维/持续改进
项目运维也是个很细致的活，日常检查、月/季巡检、灾备演练、运维记录、客户回访、bug修订、新需求收集。基本上项目经理把活做好了的，运维的时候还是得时不时让他们回访一下客户，很多新项目机会就是从这些回访中冒出来的。
小结
综合上面所说，我所认为的软件生命周期，并非只包含了项目实施这一个环节，而是应当包括项目售前和项目运维两个阶段的，这才是一个完整的软件生命周期，好比一个生命，最初的起点是怀胎，最终的结点是你死后再没有人缅怀你。而作为项目经理，特别重要的是要能参与到售前中来，特别是方案建议的环节，对后期的项目实施有着清晰项目范围、理解项目背景、了解客户期望、缩短项目磨合期的巨大好处。当然现实是残酷的，公司的高层是否有这样的觉悟，有了这样的觉悟是否能组织好技术型人才和销售型人才的工作配合问题，那就得看各位的造化和努力了。