我以前只做过几个小企业的网站,现在突然要负责一个管理系统,有另一个人做完需求分析后就完全推给我了,我要带领另外3个人在几个月里完成。因为以前都是别人告诉我完成什么功能,我只负责写代码就完了,现在我要负责模块的划分,具体每个页面要实现什么功能,控制项目的进度和质量等。
我没有做过这方面的事情,很担心系统设计的不好会导致客户不愿意使用,甚至项目的失败。
各位给我出出主意、谈谈经验。我想很多人的大的项目经验都很丰富,大家每个人花几分钟时间回复一下,你们的建议会对我很有帮助,谢谢!

解决方案 »

  1.   

    多看资料和已有的成功案例:The architecture of Web applications
    http://www-128.ibm.com/developerworks/ibm/library/it-booch_web/index.html软件的架构与设计模式
    http://soft.yesky.com/lesson/495/2012495.shtml使用 Rational Unified Process 和 UML 开发联邦企业体系结构框架
    http://www-128.ibm.com/developerworks/cn/rational/r-feaf/index.htmlArchitectural Sample Applications
    http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnbda/html/bdasamppet4.aspDotNet(.Net)下构建高适应性的三层架构 
    http://www.cnblogs.com/rexsp/articles/43815.aspxMSA 企业设计
    http://www.microsoft.com/china/technet/itsolutions/techguide/msa/vmhtm25.mspx#XSLTsection123121120120
      

  2.   

    我觉得楼主目前的情况的话也不可能在架构上考虑太多了,重点做好以下一些工作吧:模块的划分、层次的划分、文件命名、目录结构、编码的简单规范在模块开发之前一定要先考虑好整个系统的权限管理和异常处理情况,尤其是权限问题确立一个交付制度,控制代码质量,每个开发人员一周内该完成什么、如何交付、谁来把关...同时也要做好源代码管理,一定不能乱确立bug和变更的处理流程:发现bug尽可能及时处理;变更是肯定会有的,一边开发需求可能会不断地变,要有计划地进行,或者让客户也尽可能地参与到开发过程中来......
      

  3.   

    To:The123(Shall We Dance? :)) 
    客户一般只会通过电脑屏幕或者投影机来判断你的东西,他才不懂“幕后”的玄机
    --------------------------------------------我的意思是设计的不好,不能满足客户的需求或使用起来不方便,还不如手工的操作
      

  4.   

    jiezhi推荐的资料不错.好好看看,负责一个项目下来你就觉得自己能提高很多.
      

  5.   

    我的意思是设计的不好
    --------------------
    呵呵,告诉我你理解的“设计”是什么?不能满足客户的需求或使用起来不方便,还不如手工的操作
    ——————————
    所以要你“仔细”分析需求啊?你不“仔细“去分析需求,何来的设计?如果时间宽裕或者你熟悉面象对象和设计模式的思想,那么请参照jiezhi(风满袖)同志的建议,但切忌不要陷入"过渡设计"的泥沼里,那就像个无穷的递归,你会变成欧阳峰的,哈哈
    如果项目时间紧,那么先别太多考虑面向对象的问题,以完成任务为目的,但一定要注意程序的performance,呵呵,请参照Eddie005(♂) 暴赱同志的建议,当时间允许的时候,带着你的手下review你们的"垃圾代码",重构你们的代码。开发都是个迭代循环的过程,需求永无止尽,闷啊
      

  6.   

    控制项目的进度可以用Project____________________我又回来了!
      

  7.   

    同意 : The123(Shall We Dance? :)) 总结的. Just do it! 
    祝楼主好运!
      

  8.   

    多与客户沟通,多听多讲,要注意发掘客户的需求,你可以不断地给客户举例,这个东西这样实现怎么样,那个东西为什么要那样。客户经常会不自觉地隐藏自己的需求,要分清楚哪些需求是重要的,哪些需求是次要的。
    因为一般来说,这样不负责任的小公司,都不会在指定时间内完成所有的功能的,一定会有后期维护的时间安排,所以你先实现主要功能,让客户能够投入使用,交钱,上面自然就不会催得那样紧。对于程序员来说,做不好不如不做,你手下的程序员多半也抱这个想法。然后就是建模,会有一些什么样的数据,整个系统是什么类型的,是MIS还是什么别的,再搜索这个类型的系统的资料。数据的细节不重要,但是关系非常重要,这些关系客户不会条理很清楚地告诉你,这就需要你自己分析和挖掘。作为Web项目,用户界面是另一个非常麻烦的问题,如果牵涉到页面的转换,数据如何传输?用户授权的实现。另外,也许你要做一些基础的建设,例如数据库访问帮助器,数据库的建立。输入验证和授权模块,对于手下的员工,一定要要求责任到人,各个模块互相分开,独立测试,公共组件宁愿自己亲自动手。要有感染力,号召力,多与他们沟通,重点告诉他们两点:一、你该做什么。二、你做的这个东西很重要。
    告诉他他做的东西重要,可以让他有责任心和成就感。另外,作为一个团队,绝对不允许先做完的先休息,大家要齐心协力,互相帮助,让每个人明白,如果别人没做出来,那你的工作也是白费。分模块做的话,接口定好后,就不要随意改动,即使要改动也必须与使用这个接口的程序员沟通和妥协。
    差不多就是这样了
      

  9.   

    楼主既然以前没做过,没什么经验可谈,现去学系统架构,项目管理也不现实
    不如做好实际的东西:
    1、不要所有的都自己来做,把其他几个人拉进来跟你一起分析;
    2、一定要明白需求,花一些时间大家一起熟悉需求并探讨是必须的
       最好每个人都完全明白需求 最起码你自己要完全明白
       以大家都明白的方式重新整理给你的需求(以后有需求变更要做好记录)
    3、大家一起做好功能划分,明确大家的分工,做好时间进度
       时间规划不要太紧,要符合每个人的能力,不要每天赶任务还完不成规定好的 
       这样时间一长容易产生逆反心理 反而更不好
       另外时间规划要留有足够的测试期 和风险时间
       风险时间不好把握的话暂可根据你对需求的理解 理解的越透彻风险时间可略短 反之略长
       但是一定要有,以应变 难免的需求变更以及突发事件
    4、(内部沟通)经常性的 短时间的 工作会议是很好的方式
       建议每周不少于两次 周末最好有一次
       内容一般是 了解大家工作中遇到的问题 互相探讨解决 
       强调各人分工 明确每个人的目标
       了解项目进度 做好督促工作
       周末的一次 总结本周工作 做好下周安排(下周一早上最好在明确一下安排)
    5、(外部沟通)与客户的沟通必不可少
       客户有专人参与进来最好
       最好项目分出几个里程碑,做到一个里程碑就到客户那汇报一下工作
       发现跟客户需求差距很大的时候要及时做好变更调整
        这个时候做好需求功能调整的时候不要忽略时间进度调整 
        如果是客户的问题 则可以争取这部分调整时间
        如果是自己这边的问题而客户又不答应延长工期 则要用好前期 预留的风险时间
    6、时刻关注好自己团队的稳定性 尽量不发生项目中途有人员退出的情况 具体情况具体处理
       可平时开展一些有利于团队间相互了解 促进稳定的活动 
       例如 隔段时间大家一起出去happy  项目进展的比较顺利可适当的奖励等
    7、你作为项目负责人 最好学一些项目管理的知识,了解一些工具
        并应用到项目中 往往事半功倍 
        但是不要为了一些什么标准的管理流程,标准的文档 而丢了你的项目
        一切只要内部统一 便于沟通 就是标准  大家都明白最重要
    8、关于项目质量 测试很重要做好局部测试 单元测试 最后的总测试必不可少 
        一定要保证数据的稳定性 
        另外代码最好要有一定的容错能力 扩展能力想不起来了 就这吧