• 项目总结考虑的方面


    项目总结应该描述写些什么

    内容摘自网络

    1、项目初期要进行风险的管理探讨,项目远景定义和功能集合的详细定义。

    2.需求
    客户一般对计算机不是很了解,和他们交流是用软件行业的专业俗术语,他们根本就不懂,如果用文档也很难把需求写得那么明白,
    而且文档很多的话,客户都看烦了,很不直观。如果让客户一看就可以看出这个就是他们想要的,我认为最好的方式就是做系统原形(界面的功能模拟)。

    系统原形应该在需求分析师的指导下完成,当然开发只是界面的功能模拟,没有底层代码的实现。
    这样做的目的有三个好处,
    一是客户很直观的看到他们的系统是什么样子的以及怎么操作,
    二是这些开发的成果是可以二次利用的,
    三是可以更好的激发客户的需求。

    注重用户参与
    用户参与详细需求的制定,不能靠需求采集人员的猜想,造成系统功能不切合实际,与项目实际需求差距大,运行效果差。
    需求调研末期的《软件开发需求规格说明书》,要跟客户签字确认。
    这样既能保证我们所理解的需求就是客户所要的,也使得项目末期跟客户验收时有据可依。

    3、集团化以后,项目经理需意识到信息化核心问题是管理变革问题。
    在组织架构、权限、供应商等方面与力和集团理解不一致,需分别按组织进行区分。
    要根据企业业务需求制订策略,调整软件组织结构, 详细设计软件各组织架构之间的逻辑关系。


    4.良好素质能力的开发人员、设计人员、项目经理良好的管理能力
    开发人员要接触实际业务,和客户沟通,不要害怕客户提需求,对客户的需求做深度分析,要理解抓住真正的客户需求,改进系统功能。
    设计人员设计系统结构时不要过于定制,要考虑系统的可扩展性,考虑到后期的维护。
    当出现问题时,项目经理要根据现阶段的状况重新评价需求分析结果、开发人工数估算、设计结果等。


    实行双项目经理制度:为开发项目设定两个项目经理岗位,一个负责技术岗位,另一个负责管理岗位。
    管理经理做到对项目整体的管控,项目风险管理和控制。技术经理擅长的是技术研发。两者的配合提升软件开发项目的管理水平。

    技术岗位:负责技术框架的稳定性和可扩充性、质量的保证、风险的预测以及数据库的设计,模块测试、接口测试、白盒测试等;
    对于该项目具体需要多少人员、时间;到底需要什么层次技能的程序组组长和具体开发人员给出详细的计划;
    对程序组每周具体的开发目标的进行检测验收,保证开发进度。以及其它需要考虑的问题等,如网络速度,服务器访问量,数据库查询优化,都需要整体考虑。

    管理岗位:掌握行业知识、项目的前期调研、需求分析、功能模块架构设计、人员的管理、实施计划的安排执行和跟踪。
    提交《目标与范围》和需求调研末期的《软件开发需求规格说明书》。

    一个项目在前期的工作非常重要,就算是一个错误的开始话,后面有再强大的开发团队也是白搭。
    人员肯定是从项目实战中成长起来的

    5、合理做项目的进度安排,不要一味的追求快速开发

    项目中有个不变的金三角法则,即时间、功能和资源。
    我个人的意见是用我们的实际能力按照一个正常的进度去做,一个项目在功能、时间和资源一定的情况下,没有捷径可以走的,必须一步一个脚印。


    6、分清主次,不要胡子眉毛一把抓

    根据企业不同的发展阶段,按照规划逐步深入,这样一方面可以避免投资的盲目性,另外一方面在前期的投入收到效果后,
    再进行下一阶段投入的同时,员工和企业领导也容易接受,软件人员的压力也会相对减少。


    7、开发结果要做测试

    必须做好充分准备的开发计划,对于该项目具体需要多少人员、时间;到底需要什么层次技能的程序组组长和具体开发人员给出详细的计划。

    8、要做项目总结会议,重视项目质量。

    每日必须召开项目总结会议,随时捕获风险,当日事当日毕。
    软件开发初期的时候,就开始猛抓质量,而不是走“先上线、后优化”的项目常规实施方法。若发现质量不合格的地方,就让开发人员重新返工。


    9、软件版本发布周期尽量不要频繁。
    发布周期要合理,具体看产品要求,在版本更新前,必须做好充分的测试,方可交给客户使用。

    10、重视客户体验

    公司应该拿出一部分预算,有计划有规模地组织用户进行测试,对操作员给出的体验意见做好详细的记录,并给予充分的重视,对其中有用的软件改进意见给出相应的奖励。做好足够的风险应对计划,抵御这种影响所带来的对系统本身的顺利实施以及实施人员的信心和工作激情的冲击。

    11、要有数据风险意识。

    软件系统是一个高度集成的系统,一个环节的出错将可能导致一系列的错误,所以,对数据的准确性提出了很高的要求。


    12、注重细节。

    天下大事,必做于细。1%的错误往往会导致100%的失败。

    在此对之前开发过程中一些可以改进的细节列出,进行总结,在今后的开发中将进行改进。

    (1)软件每一个打开的窗体都应该写上标题,而不能是默认的标题。
    (2)操作按钮位置、操作顺序必须一目了然。
    (3)软件的功能都加上快捷键,使它适应不同操作习惯的用户。
    (4)每一个窗体都加上“关闭”快捷键,当用户需要关闭窗体时,只需要点“ESC” 键就可以退出,

    方便用户的操作。
    (5)所有输入文本框都必须按照用户的业务要求进行排列,使用户可以更快更好地输入数据。
    (6)进入系统以及退出系统时,如果程序执行比较耗时的代码,应该给出个提醒,而不能让用户傻等,最好放到线程中处理,不能让主线程出现假死状态。
    (7)用户登陆的窗口,应该自动帮用户记住用户名,用户可以自己确定是否要记住密码。
    (8)复杂的查询条件,错误提示之后,原来的输入是否都还保存?如果都没有了,用户要再输入一遍会很烦。
    (9)查询错误或无结果,必须有提示。
    (10)下拉框中的数据必须有排序。
    (11)系统中的各种提示必须要合理,不能有误导用户的情况。

    当然,还有许多需要注意的技术和非技术的细节问题,往往我们技术人员觉得不重要的东西偏偏是用户觉得最重要的。我相信,在软件开发的过程中,你只有琢磨你的用户是怎么想的,你才能使我们的软件更加完美,付出得越多,得到的越多。

    13、没有结果的结束。

    我们几乎听不到有人出来说项目失败了,我们听到的是延期、暂停、取消等等形容词,但是其实,我们其实应该承认,我们有做了一个失败的项目。
    项目的成败是变数多多,既有技术的,也有管理的,也有关系的,既有自身的,也有客户的,但是只要我们把我们可以控制的做好了,至少这个项目成功了一半。

  • 相关阅读:
    udp用户数据报协议
    java调用url
    mybatis中的#和$的区别
    sun.misc.BASE64Encoder图片编码,并在页面显示
    oracle查看列数据类型
    MyBatis传入多个参数的问题
    ajax详解
    Comparable和Comparator的区别
    谈谈hashcode和equals的用法
    从为什么String=String谈到StringBuilder和StringBuffer
  • 原文地址:https://www.cnblogs.com/Alanf/p/9930316.html
Copyright © 2020-2023  润新知