本文首先是真实记录下我新工作环境，并以我第一次参与的项目为例，总结成功和失败的经验，既记录下自己的成长。
按理说作为初来咋到的“新人”，应该是多干活少说话，毕竟你并不熟悉这个环境，而职场又是一个比较复杂的环境，虽说IT界的人都比较单纯，但是有人的地方就有江湖，有江湖就有恩怨，不得不小心行事。
但是现实情况确实让我不得不担负起研发管理的责任。怎么说呢？项目开发只能用一个“乱”字形容。当前开发流程完全是“作坊开发”模式，没有规范，效率极低。那么如何从作坊转变为正规军呢？
转变是一个水磨功夫，需要一个熟悉的过程，但是有一些小改变，既可以立竿见影，也不需要太大的改变。好，那么我们就从这些小地方开始改起来。
-
避免口头讨论需求。 建立需求文档的版本管理，所有讨论确认的需求必须更新到版本管理上面，统一维护。有效避免需求不明确，理解不统一，经常遗忘需求的问题。
-
建立CI系统，使用脚本自动编译及版本号自增。这样首先将研发从低效无聊的手动打包中解放出来，使研发能专注开发，效率更高；也让测试对测试的版本更明确，每个版本有哪些修改一目了然，出现问题也能对应到具体的版本，极大方便bug的定位和解决。
-
提出对UI设计，bug提交格式，编码等的规范。当然，这些东西并不是能立竿见影的，需要一个过程来实现。
-
架构重构。之前的架构是采用MVC模式，问题是Controller随着项目规模越发笨重，切UI逻辑和Business逻辑混在一起，维护困难还无法测试。所以我建议采用MVVM模式将UI逻辑和Business逻辑分离，让逻辑更清晰，同时Business逻辑还可以测试。
以上的改进获得了总监、主管及同事们的认可，因为这些改变实实在在的让他们都获得了好处。也只有感受到好处才能被接受吧。
还有一些问题，比如代码审查，开发周期估算，风险管理等，不是我说就能改的，但是我想这些肯定在慢慢推进中都会实现。
最后我想说的是工作的价值就是为公司创造价值，同时也让自己获得好处。在这个项目中，我既帮公司提高产品的质量，也帮开发这边提高效率(老板当然高兴，效率高意味同样8小时产出更多)，老大也高兴，可以将这些作为成绩了。同事也高兴，以后不用面对一团乱码了。而最高兴的应该是我，既能实践自己所学，也得到领导的认可！当然不可少会得罪旧势力，但那又怎样？工作不是交朋友！我就是这样将一个项目从混乱中慢慢改善的。
网友评论