P2P理财项目四个月开发总结

本是古典何须时尚 2022-08-08 00:50 13阅读 0赞

# 目前项目情况 #

这个项目从元旦开始开发到现在已经有四个多月的时间了，上线期限也是一拖再拖，从整个项目开发情况来看造成项目延期的原因有很多，简单分析和总结一下这个项目的优缺点，以及在这个项目中的成长。

# 项目进展分析 #

##       需求方面 ##

需求变动在原因里面占用20%，通过个人感觉这个项目需求变动造成的时间浪费在20%左右，一般项目在代码写了一部分后基本上需求是不会再变了，可是这个项目再开发了两个月之后，需求又大变了一次，导致很多代码重新开发或者从新编译，开发重复劳动情绪也收到影响，当然项目慢也不能完全推给需求，需求变毕竟是正常情况和正常事件，如果需求大变一次可以走需求变更流程，各个负责人一起估算变更带来的影响，因此，需求就不过多的谈乱。

##         设计不当 ##

###                数据库表结构 ###

数据库结构正常情况确定好之后就不会再有大的改动，但是我们项目中数据库总是在变，数据库如果变化从底层mapping文件到界面都会跟着改变一次，改动还是比较大的，另外我觉得这种虽然是按着敏捷开发的方式开发，但没有达到那样的效果，尤其前端页面与后端分开来开发如此一来我们每个迭代每个月都看不到自己开发出来的成果，开发的比较盲目，这样时间一长没有开发出东西来会让大家感觉有一种疲惫感，不如换一种开发方式每个月都会有成型的东西出来，让大家对自己做的东西有种成就感。

除此之外，应该有一个人控制需求和数据库变更，一般不要改变数据库以及需求，就不会带来这个变动影响开发的情况，万一需求变了项目延期需要评估是否合理，不合理就不给于变更。

项目开发已经快结束，但是发现都没有数据字典，很多下拉列表直接返回给前端的都是数字或者英文字母，不知道代表什么后期集体添加数据字典这个功能，这个前期没有考虑进来；有些公共的技术点没有提出来并加以整理，比如控制事务、缓存失效时间、登陆、安全、代码格式等等，自己写自己的没有人控制；每个人都是负责自己的模块部愿意参与别人的模块设计，也不愿意帮助别人解决遇到的问题，想的都是把自己那一块问题解决完，保证自己的那块不出问题即可，但是这种系统耦合性太大基本上很难把几个人负责的任务分开，导致流程走的不顺畅。

###                 任务分配 ###

任务分配存在不合理的情况，并没有按照能力好一些的负责业务复杂一些的模块，水平差一些的负责相对简单一些的模块，这并不是说有的能力不高只是为了更好、更有效的完成项目中的任务，合理利用资源的问题，有时觉得某些人特别忙、某些人就比较闲的情况，P2P不管是前端还是后台管理走的是一个数据流程、其他大多数软件都是在走数据流程，有的节点稍微复杂一点有的节点就简单一点，我们不应该让前面的流程制约后面流程的开发，换句话说作为项目负责人或者经理应该就每个流程以及各个流程的衔接处的数据变更有较清晰的思路和认识，然后，对于每个人完成每个模块需要多长时间有一个整体认识，只有这样整个项目才不会延期。

在软件设计师考试中，曾经记得有项目有向图、无向图等图，清晰的记得整个项目的时间每个节点都受前面节点限制，而整个项目期限取决于时间最长的一段路线，因此项目工期应该考虑最可能出问题的那个组合；分配人员时应该把前面节点做完的人员分配到后面没有完成的节点上面，不造成资源的浪费，这样是最理想的情况。

在前天开技术讨论会的时候，我们总经理提到了我们那个项目，问我们那个项目五月一能不能上线，问某某人回答是：取决于谁做哪一块，明显显示出分配任务不合理的情况。

###                 开发氛围不和谐 ###

团队的开发氛围对于整个项目开发是有影响的，开发中有前期有十几个开发人员这几个人一组那几个人一组，形成了小的团体以自己小团体为准，我觉得我们开发组素质都比较高，开发任务也比较快很快完成了开发任务，在开发中公司招的的确啥水平的人员都有有的人，开发一个功能好几周还总问别人，问几次你会告诉他但是时间长了就没有人愿意告诉了，领导也不是看谁不行就说说谁，没有赏罚错误大家做多做少都一样，所以，你就没有必要总帮别人弄，时间长了大家都光顾自己那一块了，同别人交流的比较少，技术好一些的代码思路或者风格，以及好的实现也不愿意分享出来或者告诉其他人，水平相对薄弱的人也只能自己摸索着写，团队之间几乎没有知识共享不管好的技术还是不好的都没有人主动分享或者提出将要出现的问题，领导也不能及时发现可能存在的问题，如果你负责那一块那么这一块的所有内容都有自己来负责，完成任务的前提是每个人必须对自己租的那一块有清晰的认识和一定的经验才能有质有量的完成。

###                责任不明确 ###

在公司里面工作经常涉及到责任问题，有很多实现和涉及思路或者方案是需要领导或者经理来确定的，因为这里面会涉及到责任问题很多开发人员自己都不能确认是否应该这样，但是很多这样的涉及问题应该经理来拿主意的事情，常常让几个开发人员来自己确认这样一来谁都不会确认方案，因为确认方案如果出了问题都会推到某人身上，这样一来就造成了开发会感觉比较累，实现的同时还会考虑很多责任问题牵扯到开发钟来。

# 总结： #

总之，项目进展的好坏与项目设计每个方面息息相关，不要忽视每个方面对每个方面也不能够掉以轻心，作为经理以及管理人员不可只安排人员去处理问题，需要提前预算这个问题的产生，以及对每个人的每日进度以及每个人的整体进度有把控才行，对每个人的开发情况了如指掌才能对整个项目进展有明确规划，而不是出一个文档告诉开发人员按着这个写，然后自己就啥事情也没有了，如果达不到自己预想的标准就是不行，项目经理应该跟进每个人的情况。