flyzl

      最近在做的一个项目，从一开始到目前这个里程碑都遇到了很多的问题，可以说，项目进入到很危险的境地，现在来谈谈期间的一些情况：
      是先前销售谈好的，只包含价格，不包含具体需求。因此在谈完价格之后，公司的项目管理组开始和对方谈需求，由于价格已经定好，因此对方很随意的开出了一系列复杂的需求。按理，公司这里完全应该提出对需求的异议，但限于管理组的出身（管理组的前身是公司的实施部门）和公司的运营情况，很想拿下这个项目，因此基本上的需求都接受了。接下来搞设计的人开始上马，由于需求比较复杂，设计一开始也很困惑，该如何设计好这个项目，但总的来说还是开始设计的了，项目工期很短，于是边设计边开发。现在遇到的问题是：

1. 需求太过复杂，由于是上面的意思，认为谈需求不需要技术，知道一点业务就行了，因此谈需求的时候很多不容易实现的需求都被接受下来，导致最后设计和开发的困难。这是典型的外行领导内行的结果。
2. 开发人员不足。这个在任何公司都会碰到的问题是个很头疼的问题，由于项目的价格是谈好的，因此公司定好的开发人员肯定也是有限的，造成目前项目组人员有6人，但真正产生代码或设计的人员才3人，其他的人都是兼职其他项目的，而同时开发人员也是兼职其他项目的。造成目前开发进度滞后，项目拖延比较大。
3. 设计人员的设计规范性不够，确切的说目前的设计只是设计了数据库表结构和一些业务逻辑的说明，开发人员的随意性和不确定性很大。
   

    以上这些问题的解决是公司的管理思路的变化，我谈一下我的想法：

• 关于售前价格，这一点取决于公司的行业地位，没法定量，但有点要做到的是销售和对方谈了多少需求，这应该直接影响到项目的价格，否则公司会因为一个项目的消化不良最终全盘皆输。如果公司对销售的压力仅仅反映在销售总额上而不是销售质量上，那最终传递到公司内部，将会是很多部门的日子很难过。所以好的销售思路决定了一个公司的成败。
•  需求的谈判上，应该至少让技术人员（项目经理）参与，否则最终的实现没法把握，开发时间和进度的谈判更是空谈，必要的时候应该向客户让步，但如果被客户牵着鼻子走，最终倒霉的只能是公司本身。
•  设计人员一定要是有多年开发经验的人员，要能够从实现业务、开发快捷、系统架构多方面思考问题，好的设计人员完成一份设计的同时心里面已经大概知道这个模块的具体实现该如何做了。目前看来比较好的设计不仅仅应该设计表结构，至少程序中的通用变量，通用模块都应该规范，这样有利于代码重用和移植，而且关键的算法应该用伪代码实现，否则设计和需求没什么太大的区别。
•  最后谈谈项目管理上面的问题，项目经理制已经是被实践证明最佳的软件企业内部管理制度。在项目经理的人选上面，首先他一定要有过相当的开发经验，同时他又要熟悉所做软件的业务。事实上，项目经理是沟通技术开发人员和客户或者需求人员的桥梁，他既能把控需求的开发进度，难度。又能沟通客户，引导对方的合理需求。因此项目经理的职责是很重大的。而事实上，目前一些让实施和需求人员担任项目经理的架构完全是本末倒置的。



•  项目经理平时的工作除了沟通协调制定目标，完成设计之外，很重要一点要养成一个习惯就是不断的了解开发人员在做的技术，也就是要时刻保持对技术的敏感性。因为软件开发相对还是很专业性的活动，且变动很大。流程和框架的变化很容易导致开发时间的变化。如果不时刻了解项目所用的的技术和开发人员的开发情况那就没法预估和控制开发时间了

       唠叨了那么多，其实都是些很常识性的问题，但在实践中很多常识的问题往往就被抛在脑后了。