软件行业最现实的问题—软件过程管理 软件开发项目管理文档管理技术人企划运营

        谈到软件过程，有的人脑子里立马浮现出CMMI那一套巨大的理论所描述的各种模型方法和理论。如果完全按照这套理论进行实施，可能大部分中小型项目都会面临严重的时间和精力的问题。So，大部分的需求分析充其量就是一篇简单的文字或者一个截图加上一句话，甚至很多项目根本就没有所谓的需求分析，直接由技术和客户进行对接。

 

        但是一个项目的规模是否真的就如开始所预料的那样，一定是“so easy”或者“so hard”的项目呢？不一定，一个小项目可以逐渐累加需求成一个大项目，一个大项目在经过需求的挖掘精炼以后可能会变成只有若干核心功能的小项目。决定一个项目的有市场技术人才等多方面的的因素，但是最根本的因素就是项目的需求，其他的因素都是根据需求而改变的。甚至可以说，一个项目就是不断将用户需求具象化的过程。如果这样说，你是否仍然认为需求分析是一个可以省略的过程呢？

 

        “我们的项目时间很紧迫，所以就省掉那些分析设计阶段吧”，“没时间写文档，直接开始开发吧”这是领导们在开会时“体谅”项目组经常说的话。然而事实上是否真的可以把这个阶段消灭掉呢，NO，准确地说这只是把需求分析的工作“转移”了。转移到了哪里呢，转移到了设计，转移到了开发，转移到了测试，转移到了运营，甚至可以反过来转移到用户那边去了。大家都从自己的角度理解需求，实现需求甚至扩展需求。而从设计开发到运营，参与的人数往往都远大于需求分析的人数。这样一来，大家百花齐放，项目经理说：这个东西这样做比较节省时间。技术经理说：这里咱们加个菜单把。开发说：这里不好实现其实可以换种方式。测试说：从用户体验的角度这里不该这样做。运营说：这里（此处省略N个“这里”）加个判断不就行了吗？最后客户说：我昨天看到一个更好的网站，我明白自己想要的了，咱们直接改版把。也许你觉得投入一个人去做专业的需求分析可有可无，但是后期这么多人消耗的成本之和真的会小于投入一个需求分析的成本吗，精打细算的老板们确实要好好算一算。

 

 

        软件行业大多数项目的进度都是要求很紧的，这当然与时下流行的浮躁与功利主义分不开关系。另一个重要的原因是，在社会大众的眼里，计算机属于高科技行业，高科技行业的生产效率必然远胜于传统行业。如果高科技行业的效率比在路边捡破烂讨饭的效率还要低，那为什么还要搞软件开发？软件开发是很潮的，但绝不限于它的技术很潮，事实上大部分的应用软件开发用的都是上个世纪就有了的技术。软件开发的潮应该体现在它先进的项目管理和人员管理上，项目管理系统，内部支撑系统，标准化文档管理，敏捷开发，质量审查，绩效激励，甚至通俗一点的怎么拉拢人心怎么让别人服你的气，都是属于项目和人员管理的范畴。

 

        计算机的软硬件大多数已经标准化，软件开发使用的技术已经到了多如牛毛的地步，用编译原理去写一个编译器的人已是绝少数。我们需要的事情是要让人的活动接近标准化。而一个成功的项目，其花在代码上的功夫往往都不是最多的，甚至用的是些一点都不“潮”的技术和一点都不“牛B”开发人员。软件是人做出来的，一堆思路混乱浮想联翩的人就是用超级计算机也开发不出来什么东西，而想把一群天南地北的人管好，则只能用过程、规则加上一点个人魅力去约束、引导，否则还需要管理做什么呢？

 

        对于一个只有几个人，租着民房搞开发兼自己做午饭的的软件作坊，需求开发实施运营可能都是一个人，如果让他把这几个职位分开招人来做，他一定会认为你想搞垮他的公司。但是对于一个经营领域走向多元的现代化企业来说，分工细化，规范化，流程化则是不可避免的必经之途。这意味着投入和风险，但是更多的是考验做为领导者的远见、魄力和修为，以及贯彻领导意志的制度和有执行力的下属。否则，凝聚在你周围的团队将会是一群看起来毫无作为只会年底要求涨工资的“人才”,或者把本来不是这样的人变成这样的“人才”。部门（企业）变成一群“山寨土匪”纠结而成的伪军，历经数载而毫无积累，像盘散沙那样一吹就散。所谓的做大做强也就永远是句口号。