金店管理系统的几个经验和教训

最近我带三个人的小组做金店管理系统&＃xff0c;有收获也有教训。简单的总结一下。

1、如果可以在做需求的时候先把UI做出来&＃xff0c;或许可以更好的理解需求&＃xff0c;架构和设计做起来更加顺手&＃xff0c;如果先从大的框架开始写&＃xff0c;然后去考虑UI设计&＃xff0c;效果会差很多。可不可以这样理解呢&＃xff1a;做UI本身也是在做需求&＃xff0c;更加容易的了解软件需要的功能和要求。能不能再以后的开发中把UI的要求做成需求分析的一部分呢&＃xff1f;

2、做开发最重要的是约束和量化&＃xff0c;所以基于接口的开发&＃xff0c;强制性的属性尽量以构造函数的参数进行传入&＃xff0c;而非写成成属性&＃xff0c;这样可以增强约束性。

3、每个模块开发之前&＃xff0c;最好有一个初步的讨论&＃xff0c;让队员明白大体的轮廓&＃xff0c;然后把讨论的内容书面化&＃xff0c;整理成一个沟通文档。

4、把每个可以量化和规范化的东西&＃xff0c;写成文档&＃xff0c;贴在每个队员的面前&＃xff0c;而非简单的沟通达成共识&＃xff0c;别太相信每个人的记忆力和自觉性。把可以量化的规范&＃xff0c;比如说代码命名规范&＃xff0c;比如说界面设计的每个部位的大小和风格约束&＃xff0c;数据库的字段设计要求等等&＃xff0c;一条一条的规定下来。每个队员开发好一个模块后&＃xff0c;交给另外一个队员进行检查。检查无误以后&＃xff0c;再签入递交&＃xff0c;确保递交的代码中没违背约束内容的出现。

5、对协作来说&＃xff0c;可信赖的协作胜过协作本身&＃xff0c;对编程来说尤其如此&＃xff0c;可以减少团队成员&＃xff0c;但是必须确保每个队员承诺的部分是已经实现的&＃xff0c;且没有问题的。如果承诺的东西没有实现&＃xff0c;就会影响到相应的环节&＃xff0c;最后起到连锁反应&＃xff0c;是一件十分可怕的事情。对于新手程序员来说&＃xff0c;必须要求他们减少工作量&＃xff0c;提高工作质量&＃xff0c;确保自己做的每个部分简单的错误没有出现&＃xff0c;或者错误不会重复出现&＃xff0c;可以牺牲时间来提高质量&＃xff0c;对于无法实现的功能&＃xff0c;应该在附件中说明自己什么功能无法实现&＃xff0c;以及自己的见解。

6、别期望每个团队成员都是积极进取&＃xff0c;会主动寻找工作点。大多数团队成员会呈现惰性。而对我来说&＃xff0c;我似乎更加喜欢自己埋头去做一些事情&＃xff0c;这样对团队管理不利。每个团队成员每天必须明确的知道今天要做什么&＃xff0c;要如何去做。每天结束之前必须要了解到他们完成了什么&＃xff0c;同时如果可以做一个简短的总结&＃xff0c;把他们的问题以合理的方式告知他们。

7、团队管理总重要的一点来自放权。任何一个管理项目的领导者&＃xff0c;无论在工作经验上&＃xff0c;还是对项目的认知上肯定要超越其他的组员。特别是有新手的组员&＃xff0c;管理者会感觉新手做东西还不如自己去做东西。与其去给他们修改&＃xff0c;还不如自己花费10分钟去做一下更加省事。而团队要想做大&＃xff0c;首先要放权&＃xff0c;要相信你的队员的成长能力&＃xff0c;给他们成长的机会&＃xff0c;眼睛里要容得沙子。让他们去做开发&＃xff0c;并且给他们适当的建议。本身可以减少管理者的压力&＃xff0c;还可以提高他们的水平。

8、尽可能的量化一些东西&＃xff0c;只有量化的东西&＃xff0c;才能适合大规模化和科学的管理。如果不能量化&＃xff0c;就会从在懒惰和黑暗。

9、磨刀不误砍柴工工&＃xff0c;尽可能的每天都有沟通&＃xff0c;每段时间都要有沟通会议&＃xff0c;了解每个队员的状态、情绪、心情、期许等等&＃xff0c;解决他们的包袱和问题&＃xff0c;统一认识。

10、分工要根据每个人的水平&＃xff0c;提供难易参数&＃xff0c;让他们从容易向难一步一步的开发&＃xff0c;第一容易上手&＃xff0c;第二容易提高。

11、如果可以&＃xff0c;花高价钱请好的员工。