公司重构项目带来的一些思考

我们公司的重构项目从2016年五一后启动，到目前(2017.02.16)仍然没有结束的希望。这次重构涉及到近十个模板(平台、IM、待客云、用户轨迹、存储服务、用户中心、web端、pc客户端、手机客户端等等)

1、如果项目涉及的模块比较多,涉及的技术比较复杂,最好采用螺旋模型的开发模式或迭代增量式开发;

瀑布式开发(我们公司就如此)就想是泥牛入海,久久不能自拔,而且带来的人员需求逐渐膨胀,项目周期无限延长,最重要的是项目后期(不知道是中期还是后期,因为不知道是什么时候结束),参与人员疲惫不堪,斗志萎靡,又加上人员流动,需求修改变动,其他部门的挤兑(自己部门也会挤兑,我们研发部门没参与重构的人员经常挤兑和揶揄我们),这个项目很可能无力走下去。

2、项目涉及的技术比较复杂,那么就必须考虑到技术风险,以及由此带来的人力成本和后期维护成本;

如果让开发人员边学边做(我们公司就如此),那么时间成本自不比说,更不必说开发人员由于技术能力带来的开发质量风险,其实更大的风险在项目交互至生产环境的那刻才刚刚开始。

3、一个项目要求强有力的研发领导,甚至独裁者(有能力的),当然最好是德高望重者;

我们有些技术方案一直在讨论,从项目刚刚启动开始,一直到到项目快结束了还在讨论,我觉得本就没有完美的方案,领导者应该果断拿定一个方案走下去,虽然有风险,但也比始终没有方案,致使项目延迟甚至搁浅好的多。至于带来的风险,风险是不可能没有的,我们只能尽量减少,我们总不能因噎废食。

选择一个有威望的领导还有一个更大的好处是可以为这个项目争取到更多的资源(比如从协调人力和物力)

当然我们选择的领导必须是研发者,否则无法沟通(其实远不止沟通,涉及到的方方面面大家都懂),项目管理(监工)？销售？人事？  Oh,No！！！

4、规范要在项目开始前就定好;

有朋友说这条应该放在第一位,其实我觉得这个是细节问题,不是不重要,而是如果前面都没做好,就不会也不要走到这步了。

我说的这个规范包括文档规范和代码规范(数据库的库名、表名、字段名,程序中的类名、方法名、变量名及注释,http接口、各个模块数据交互的格式、git的分支名等等)。

5、必须要立项,而且得到最高管理者的重视;

一个项目必须要得到管理者的重视,得到很高的地位,否则很难得到足够的资源(人力和物力)支持。

6、项目各个模块细分,二三人小团队作战,明确各个部分责任;

项目细分(这本身是一件很难的事情),有利于明确责任,这个太重要了,防止各个部分扯皮。

两三个人一个团队,有利于管理和沟通(研发人员本身不善于管理,跨部门沟通也是很麻烦的),更有利于责权分明。

7、明确目标或者说项目研发前就确定好目标;

由于我们项目启动前,没有明确的目标(实话说,有,就是比现在的好*>.<*),或者说可以量化的目标,形成文档的目标。项目进行中,由于人员的变动,产品本身设计的问题,中途给开发带来了很多新的需求和变动,到最后发现和我们最初想要的产品相差很远。

8、注意人员变动的风险;

我们有个员工因为和别的部门感情的问题,导致他的离职,然后我们没有接手的人员,很被动。