- 发帖可能变空内容，邪门暂不知所以然
- 『稷下学宫』新认证方式，24年网站打算和努力目标
主题：【原创】浅谈软件项目管理 -- 河蚌
家园 关于需求分析、设计 我们现在的大多数软件实施，面临的主要问题，就是没有人能够把握住业务需求，而能够将业务需求变成系统设计的人，则更是十分稀缺。和这个问题比起来，项目的管理反而是次要的。而在实际的工作中，大多数项目也许表象是管理混乱造成失败，而实质却是由于项目中缺乏合格的分析设计人员，造成业务需求没有整理清楚，以及模块没有设计清楚。用一句话来总结很多项目，就是”一群乱七八糟的人，做着一些乌七八糟的事“。这个现象在所有行业软件里，都是一个首要考虑的因素。这其实是个项目管理的经典问题。我举一个刚经历的例子。这个项目是严重依赖于行业的，但恰好一个懂行的PD刚跳走，所以开局有点难看。顶上来美国MM,c刚毕业没多久，对行业更是一无所知。刚开始俺也挺犯嘀咕的，不过一两周后就比较安心了。C在这两周里只做一件事--用户访谈，然后转化为用户的痛点阿，用例阿什么的。随后就好办了，一两个月为周期，不停地出原型给用户，收集反馈，几个迭代后，大事就定了。当然，如果团队里面有个行业专家就完美了，大大提高效率。
家园 需求分析确实很重要 对于我们这些已经在一个行业里面做了很多年的人来说，由于经验的积累，甚至大部分客户都已经无法和我们比深度和广度。但这反而让我们对于需求分析的理论认识是最少的，因为对于我们来说，要做一个系统，需求就在那儿，就是那个样子，大多数的客户访谈和需求交流，目的只是为了验证客户是不是也是按照我们设计的这种模式去做，是不是还有什么特殊的要求。
但是，上面这种模式实际上就是专家模式，项目需求的好坏，依赖于谈需求者的专家业务水平。这种需求交流是无法复制的，随便换一个人就可能连这样一半的效果都达不到。
而对于公司而言，最好的需求交流方式，是假定公司的谈需求者是不懂业务的，而只是通晓一套需求交流的规范（当然，此人依然要有比较高深的IT技术水平），然后根据这套规范，与客户进行访谈，并最终总结出一套完整的需求文档出来。这样的方法才是可以大规模推广的，才是可以重复的（可重复是CMM几级的标准？忘了）
我曾经在2001年短暂地做过一个邮政系统的项目，是邮区中心局的生产系统。这个项目使得我能够跳出银行业，以只懂得IT不懂业务的全新身份来进行系统设计。这个项目，让我认识到，实际上各个行业的企业，其运作流程都有很大的相似之处，而IT系统，不外是企业的实物流、数据流和凭证流进行来回的处理和输入输出。我试着将银行网络的某些运作规律，套到邮区中心局上，最终在业务深入的过程中，发现竟然也相差不大。
通过这个项目，我觉得，应该有一套方法，让只学过企业管理学而没有行业知识的人，可以很方便的了解特定企业的运作机制，并将其运作机制转换为IT系统的实现。毕竟，麦肯锡的成就还是摆在那儿，虽然他的后任者为大家贡献了无数的笑话，但是，既然跨行业的咨询可以做，跨行业的IT需求肯定也可以做。
不过，如何总结出这个方法，确实是一件很让人期待，但在目前也很令人费心思的事情。
家园 学习了 原来是只缘身在此山中。这倒是个挺好的话题。
如果换个角度，变成不是做项目，而是推销产品呢？
家园 这就是Agile吧 我的结论也是，这么搞用户最喜欢。
家园 花好文 有个小建议：分割成不同的部分也许可以更有利于讨论
家园 需求这个环节确实太关键了 在项目初始阶段，就需要双方确定需求的功能边界，并且通过组织架构明确需求变更的流程，其中用途之一就是限制无谓需求的追加。
我过去经历的一个失败经验是，系统委托方领导不断增加想法，而系统架构面临推倒重来的问题，问题是按照项目时间表，下一步将是系统上线试运行。这就是开始阶段需求不扎实的后果，结果是这个系统悲剧了。
家园 对业务的理解很重要却很难得到 其成败中的关键因素，在于对业务的理解以及系统设计等技术因素这句话总结的好，而且适用于其他行业软件。行业软件的特点是最终用户往往无权决定是否使用它，而是管理层拍板买不买用不用它。
开发者很难得到真正的最终用户反馈的从而获得对业务的理解。真正用户的反馈需求也很难传递到开发。
家园 这个矛盾挺深的 行业软件的特点是最终用户往往无权决定是否使用它，而是管理层拍板买不买用不用它这个点很有意思，老法师了：）
行业软件越来越往辅助决策这个方向走--这个是管理层关注的。
而对具体的工程师而言，出设计/结果的效率才是第一考虑。这个矛盾在整体流程变更之前，基本无解。
有个正在进行的项目就是这样。经过一段时间与工程师的交流，最后发现他们所反对的，恰是产品的优势所必然带来的代价，而这个优势，是说服大boss最关键的东西。。。
家园 写的不错 有些话，说的跟实际情况很相符。我们是做电信网管软件，文中说的很多问题都遇到过，整个项目做下来，往往可用性不大，但是网管软件毕竟不是给用户做创收的。其他的行业软件不是很了解，很奇怪，如果情况都类似的话，用户为什么还要做那么多软件，难道还抱有希望，或者用户参与度不够。
- 复 写的不错
家园 银行的大多数软件都是有用的 这个是谈项目管理中的混乱情况，并不代表这些项目都是不成功的。大多数项目是延迟、延迟再延迟，最终还是会上线的，而且随着运维阶段不断地改BUG，还会错误越来越少，稳定度越来越高。
与此同时，公司一个产品线也会随着项目实施案例的增多，而日渐稳定，项目实施也越来越成熟。一个部门，一个产品，只要在做，总是会进步的。
但是这种机制，其实就是久病成医。
问题是，一个公司不能只做一个产品，总要开发新的产品。而一旦上新产品，马上又会重复老路，甚至对一个产品做出重大的升级，也同样是一个痛苦的过程。
我们做项目，总是希望，对于新的项目，也能借鉴过去的经验，让它能够做的足够稳定，这个体会主要也是写这些方面。
家园 工具不是最重要的，但为何还使用如此古老的版本管理工具？ 家园 因为它是不收钱的。 还因为他是微软的，和OFFICER产生的文档配套。
WEB/JAVA上的源代码版本控制以前用CVS，现在开始用SVN。