我的工作日志4

从6号到17号,又将近两周过去了啊.

 

用近一周的时间去把系统物料部分的前期开发搞定。数据访问层和实体层直接用代码生成，然后经过简单修改移植到系统中，然后绘制界面，作简单的添加查询，因为牵扯到层层提交审核，还要画状态图，理清状态关系。然后便是具体的业务实现。其中牵扯到的难点先挂起来，争取先把整套审批流程跑一起来，再去有针对性的解决一些技术难点。因为这样子出活，随时可以拉出界面来看，基本的功能也可以点一点，项目组经理看着舒服，领导看着也舒服。只有懂业务的人才知道，其实工作仅仅完成了一小部分。没办法，之所以这么做，也是考虑到时间安排的问题，不能一味在难点上耽误时间，程序运行不起来，别人就会怀疑你消极怠工。遗留问题，只有在程序基本功能完成后，重点突破了。

 

这周由于测试组提出了一些我们开发中犯的低级错误，直接报到了上级领导，我的boss着急了，召集大家商量解决方案。其实之所以会产生这样那样的问题，也在于团队组建时间不长，每个人没个人的代码风格，而且对业务也不是很熟悉，本身需求也一直在变，基本没有设计文档，大家只能看着需求，根据需求加自己的理解去做，这样做出来的东西，不可能没有问题。由于大家还处于磨合期，对于一些规范和标准还有待讨论落实，对于一些公用的东西还有待发掘与封装。代码质量管理上，分工协作上，也都存在这样那样的问题。所以这次因为代码质量引起领导不满，也是情理之中。不能把责任全归结到一方面，有管理，有需求，有程序员素质等等因素。

 

由项目组boss牵头，大家制定了一些方案，简略如下：

1、提交测试前，进行详细自测，并请需求人员进行功能评定，得到需求人员认可，才可提交测试，如果与需求沟通中，出现偏差，如果是需求的问题，要把问题记录备案（因为组里需求人员少，又比较忙，根本来不及修改文档，而测试又是根据文档来测的，可想而知，问题很严重），供需求人员修改文档参考，和测试人员测试参考。

2、开发过程中，对于公用代码或控件的需求，要即时提出，并发布（项目组有自己的论坛）出来，由项目boss派人开发与维护，防止大家写重复代码，做无用功，损失开发效率，并能保持代码整齐度，提高质量。

3、开发过程中，出现的问题，及时与需求沟通，并把公共问题发布出来

4、对于需要统一标准的东西，也要及时发布出来，以便统一制定标准，保持程序的统一性。

5、建立良好的沟通机制……

等等……

 

对于已有模块，我们又进行了详细的自测和互测，在项目管理软件上互相提bug，并讨论，解决等等，风风火火干了一周。经过这一周，我感觉，对于项目的把握要比以前熟悉得多了。

 

中间还有一个小插曲，因为组里几个人来自同一家公司，由于代码问题我们也在zl开了一个会，主要提了一些问题，例如：数据校验统一管理，数据库专人维护，定期代码抽查等等。这些都很平常，让我感兴趣的是一个领导的讲话。他语气很平和，讲话非常有技巧，先简单说了说会议的主题，然后对大家这段的工作做了肯定，言语中也透露出对大家工作的理解，并承诺等项目一个阶段结束后带大家去放松一下，接着才说这次出现的一些问题，说问题的时候也一再说明，责任也不全在大家身上，有些客观因素也是不可避免的，表示了相当的理解与尊重，在这样一个背景下，才提了对大家今后工作的几点要求和希望。最后让大家踊跃地提这个项目中存在的问题，然后大家讨论解决方案。

在整个会议过程中，他一边说，一边听别人说，都在认真地在笔记本上记录。

 

我当时就感觉，领导果然不是盖的，这番话说下来，让人很容易接受，然后再提要求，这样大家也不会有抵触情绪，最后让大家提问题，尽早把项目中存在的问题都暴露出来。

这次会议算是一次相当有效的沟通，显然不是我三言两语能概括的，我在里面可能算是年纪最小的，也不怕笑话，有问题，我就说，很多时候，都被归结为“这是中国特色”，很难改变，我想遇到问题，我们要提出来，至于能不能解决，怎么解决，会不会问题太儿科被笑话，这些都不重要，重要的是把问题暴露出来，不至于问题严重到不可收拾的地步，影响到整个项目的质量和进度。

 

说了那么多，其实就是想强调，沟通在项目中重要性。如果一开始，我们便建立良好地沟通机制，我想很多问题，我们都是可以避免的。至于如何建立良好地沟通机制，要根据公司环境和项目背景来看，后续会慢慢和大家分享。