22
四
10

项目管理－问题分析及改进建议（5）

标签：,
Comments 0

5 配置管理方面
5.1 配置信息等发布相对不畅，且发布形式不利于查询。
项目的配置管理信息发布渠道目前多数是通过mail来发布，此方式信息零散，不利于查询。
改进建议：提议尽快建立和健全配置管理信息发布系统，结束信息的分散发布形式，并提供强大的查询方式。
 
5.2 项目环境管理方法不够自动化
对于项目环境的发布等，自动化程度不高，特别是对中途的编译失败等原因导致发布失败时，往往没有采取特别有效的应对方法。
改进建议：目前项目环境的建立一般是采用ant来编译，最终发布到tomcat, weblogic等应用服务器上，因此，可以总结归纳常见的发布方式，制作自动化发布工具，如自动取源代码，自动编译，自动发布编译结果，自动部署应用程序，自动发布部署结果，自动跟踪结果等，以提高项目环境的自动管理方法，高效且出错率低。
 
5.3 项目环境监控不够，问题出现频繁。
项目中对于项目各种环境的监控一般都无法到位，出现问题才开始找原因，没有采取提前预防措施，从而使得问题出现频繁。
改进建议：对于应用服务器，数据库服务器，应该采用监控机制，推荐制作一套简单的工具，去监控硬盘空间，数据库文件大小，网络状态等等信息，发现问题，能够自动通知。

22
四
10

项目管理－问题分析及改进建议（4）

标签：,
Comments 0

4 程序测试方面
4.1 测试case质量普遍不高，测试质量低。
目前大多数项目的测试case书，大多数都是根据详细设计书，采用复制，粘贴来完成，细化工作不够，遗漏case比较多。此外，在测试过程中，由于大多采用纯人工测试，测试结果的质量，也完全取决于测试人员本身的素质，而测试团队目前多数是临时组建，受测试专业训练较少，项目中的最终测试结果往往令人堪忧。
改进建议：测试质量很大程度上直接和测试case的质量挂钩，对于目前项目中的测试case来说，遗漏的case多数是详细设计不充分引起的，所以也可以先从加强详细设计这方面来进行。此外，对于共通case最好能够分成两部分来区别对待，第一部分是技术共通或者业务共通case，第二部分是非共通实现的相同测试case，其中第一部分由于是共通实现的，因此测试时可以有针对性，不需要在每个用到的地方都做详细测试。而第二部分由于是非共通实现，因此必须想对待非共通case一样，进行细致的测试。关于测试人员的测试质量问题，也应该是管理者们应该重视的，评价一个测试人员的好坏，就应该把他的测试质量作为一个很重要的点考虑进去，不能只考虑测试效率，并且需要采取一定的措施，来检查测试结果的质量。
 
4.2 高效的制作测试数据的手段缺乏。
目前测试过程中，测试数据的制作一般都是人工制作，测试数据较少，命中率较低，且测试数据制作过程耗时，且测试数据的人工导入也相对麻烦，容易引起冲突。
改进建议：可以通过制作或引进测试数据的制作工具，当然一般情况下，测试数据发生器，都需要一定的规则制定，这些规则，我认为融入在测试case中是比较合适的，这样可以直接用测试case作为输入，生成的测试数据作为测试case的一部分，此外，该测试数据也会给单体测试带来好处。
 
(全文 …)

22
四
10

项目管理－问题分析及改进建议（3）

标签：, ,
Comments 0

3 程序开发方面
3.1 项目技术积累太少，每次新项目的开发基本都是从头开始。
项目开发中，对技术的积累投入太少，导致目前项目结束后很少有真正整理好且严格审核的项目技术积累，每个新项目，往往都是从头开始，或者是直接从别的项目代码中copy部分代码，而这些代码往往没有经过严格的审核和挑选，往往这些代码没有充分共通化，其中鱼龙混杂，不利于再利用。此外，对于新开发的共通，学习成本大，且新的共通代码设计等方面往往不成熟，本身潜在问题可能比较多。
改进建议：针对以上问题，我认为不仅仅是要做好技术总结，以及平时的技术积累，技术收集工作，更关键是要建立一些最典型的开发场景，有点类似于appfuse的思想，然后针对于这些开发场景，收集整理好构建场景所需的各种共通并充分对其共通化，以便扩展，然后经过严格的评审，最后在实际项目开始时，采用合适的开发场景，在该场景之上去构架项目，即实现了跨项目之间的重用，也更便于学习的重用。此外，这些开发场景也应进行统一的维护，升级。
 
3.2 开发团队磨合期少，整体水平差，代码质量低。
由于当前人力资源的调配并不固定，分配给项目的开发者的水平也参差不齐，且开发水平普遍不高，新手较多，要在很多的时间内组合的团队，整体开发战斗力不强，且代码质量偏低，BUG率高，程序的潜在问题多。
改进建议：我觉得一个技术开发团队，成员的整体战斗力，决定了最终开发出来的项目的成败和质量，因此就必须采取手段已提高成员的战斗力水平，然而成员战斗力在短期之内是不可能有大的提升的。我认为，提高战斗力关键靠平时，且无时无刻的注意成员的培养，比如说可以在代码review的时候教导新手，拿我自己做个例子，我给很多人的代码进行过review，但我并不会只指出他们哪些地方是有问题的就完了，我更愿意告诉他们怎么做才更好，为什么好，遇到类似的问题处理原则是怎样的，然后要求把这些review的结果整理出来，在适当的时候对整个开发团队进行教育。这个只是个例子，我们更应该把这些可以提高整体战斗力的有效手段整理出来，在平时不断的实施，在适当的时候做总结。
 
(全文 …)

22
四
10

项目管理－问题分析及改进建议（2）

标签：, ,
Comments 0

2 式样设计方面
2.1 整体方式设计和业务设计有脱节现象，交流磋商要加强。
目前项目的应用程序的整体表现标准，处理方针等，都是由方式设计组完成，但经常出现业务设计组并不清楚方式的现象而使设计五花八门，或经常出现违背方式的设计而并未告知方式组，导致这些设计在实际的实现中遇到种种困难。
改进建议：每个项目都会有一个相同的要求，那就是要求风格统一。而对于风格统一这项要求的完成，不仅仅取决于方式组，也同时取决于业务设计组，首先在业务设计开始时，就必须先尽量把一些方式定下来，大家基于这个统一的方式来设计，如果遇到方式不明确，设计可能出现不统一的地方，应立刻向方式组提出，以求一个统一的方式，这个就是逐步统一的过程，因为没有一个项目能在设计之初，就把所有的方式给统一下来。此外，对于一些特别要求，有悖于统一方式或者统一方式不能满足需求的情况，也应该向方式组提出，方式组对特殊情况也应记录在案，以便于后续的实现考虑。可以看出这个过程中，方式组和业务设计组等的交流是非常的重要的事情。
 
2.2 式样设计中为下阶段考虑的内容太少，为统计，抽出有用数据考虑做的工作太少。
项目中式样设计为下阶段（如：编码，测试等）考虑的内容太少，以及为一些今后有用的统计（如：画面依赖，共通调用，DB操作统计等）所做的考虑也过少。
改进建议：式样设计在整个开发过程中是一个最不能被自动工具替代的过程，因此我们往往希望利用式样设计的成果物，为其他工程阶段，自动生成初期成果物来降低开发成本，提高效率。而对于要为下阶段要产生怎样的成果物，其实并不能立刻把握住，而且一旦设计书编写完成，如果再发现缺少可抽取信息为下阶段所需的话，一般也不会再去回头修改设计了。因此，必须在设计的前期，就需要把设计书充分规范化，不仅仅是要便于人们阅读，而且也要便于机器“阅读”。而且需要把最期望得到的统计信息的原始数据信息，完整的记录于设计书之上。
 
(全文 …)

22
四
10

项目管理－问题分析及改进建议（1）

标签：, ,
Comments 0

根据自身多年的项目经验，从项目开发的各个方面，总结了公司在整个项目开发过程中常出现的不足和问题，并分别对这些不足和问题提了一些改进建议，目的还是为了改进我们项目的整个开发过程，如有不妥之处，还望指出。此外，项目问题的分析其实还可以从人的方面来切入，这个就留在以后再来分析了。
 
1 项目管理方面
项目人力管理和计划管理：
1.1 日常人力资源管理成本大，人力资源浪费现象普遍。
需要不停从计划中或者人工的收集人力资源空闲状态来进行人力资源的管理，费时费力，且容易出错。目前项目管理中并未实时跟踪人力资源空闲状态，从而导致人力资源浪费。
改进建议：目前，公司的项目规模越来越上规模，对于百人以上同时作业的项目，如果还是停留在人工的从各个信息中抽取分析的话，那对于管理者来说，简直就是个恶梦。目前，公司里已经使用了一些管理工具，比如ms project等，但一般情况下，普遍用excel版本的各种一览管理文档为主，对于这些很多信息，可以说是分散的，对于各个管理工具来说，也是互相独立的。信息的分散，管理方法的分散和重复，给目前的管理带来了巨大的成本。因此，迫切需要一个整合的管理环境，能够把各种分散的信息，统一的进行汇集，进行分析和控制。要实现这个整合的管理环境，需要走比较长的路，但该走的路迟早是要走的，现在起就可以把需要整合的数据，以及需要整合的功能给整理出来，目标可以是通过技能，任务，人员三大视图，来进行有效的管理，使得整个管理操作是轻松的，实时的。把需要的数据通过便捷的方式进行导入，进行编辑，并且记录自动记录各种履历信息，使一切管理都是可回溯的，慢慢的有计划的把需要的功能整合进去，逐步淘汰现有的分散工具。
 
(全文 …)