我的工作日志4
从6号到17号,又将近两周过去了啊.
用近一周的时间去把系统物料部分的前期开发搞定。数据访问层和实体层直接用代码生成,然后经过简单修改移植到系统中,然后绘制界面,作简单的添加查询,因为牵扯到层层提交审核,还要画状态图,理清状态关系。然后便是具体的业务实现。其中牵扯到的难点先挂起来,争取先把整套审批流程跑一起来,再去有针对性的解决一些技术难点。因为这样子出活,随时可以拉出界面来看,基本的功能也可以点一点,项目组经理看着舒服,领导看着也舒服。只有懂业务的人才知道,其实工作仅仅完成了一小部分。没办法,之所以这么做,也是考虑到时间安排的问题,不能一味在难点上耽误时间,程序运行不起来,别人就会怀疑你消极怠工。遗留问题,只有在程序基本功能完成后,重点突破了。
这周由于测试组提出了一些我们开发中犯的低级错误,直接报到了上级领导,我的boss着急了,召集大家商量解决方案。其实之所以会产生这样那样的问题,也在于团队组建时间不长,每个人没个人的代码风格,而且对业务也不是很熟悉,本身需求也一直在变,基本没有设计文档,大家只能看着需求,根据需求加自己的理解去做,这样做出来的东西,不可能没有问题。由于大家还处于磨合期,对于一些规范和标准还有待讨论落实,对于一些公用的东西还有待发掘与封装。代码质量管理上,分工协作上,也都存在这样那样的问题。所以这次因为代码质量引起领导不满,也是情理之中。不能把责任全归结到一方面,有管理,有需求,有程序员素质等等因素。
由项目组boss牵头,大家制定了一些方案,简略如下:
1、提交测试前,进行详细自测,并请需求人员进行功能评定,得到需求人员认可,才可提交测试,如果与需求沟通中,出现偏差,如果是需求的问题,要把问题记录备案(因为组里需求人员少,又比较忙,根本来不及修改文档,而测试又是根据文档来测的,可想而知,问题很严重),供需求人员修改文档参考,和测试人员测试参考。
2、开发过程中,对于公用代码或控件的需求,要即时提出,并发布(项目组有自己的论坛)出来,由项目boss派人开发与维护,防止大家写重复代码,做无用功,损失开发效率,并能保持代码整齐度,提高质量。
3、开发过程中,出现的问题,及时与需求沟通,并把公共问题发布出来
4、对于需要统一标准的东西,也要及时发布出来,以便统一制定标准,保持程序的统一性。
5、建立良好的沟通机制……
等等……
对于已有模块,我们又进行了详细的自测和互测,在项目管理软件上互相提bug,并讨论,解决等等,风风火火干了一周。经过这一周,我感觉,对于项目的把握要比以前熟悉得多了。
中间还有一个小插曲,因为组里几个人来自同一家公司,由于代码问题我们也在zl开了一个会,主要提了一些问题,例如:数据校验统一管理,数据库专人维护,定期代码抽查等等。这些都很平常,让我感兴趣的是一个领导的讲话。他语气很平和,讲话非常有技巧,先简单说了说会议的主题,然后对大家这段的工作做了肯定,言语中也透露出对大家工作的理解,并承诺等项目一个阶段结束后带大家去放松一下,接着才说这次出现的一些问题,说问题的时候也一再说明,责任也不全在大家身上,有些客观因素也是不可避免的,表示了相当的理解与尊重,在这样一个背景下,才提了对大家今后工作的几点要求和希望。最后让大家踊跃地提这个项目中存在的问题,然后大家讨论解决方案。
在整个会议过程中,他一边说,一边听别人说,都在认真地在笔记本上记录。
我当时就感觉,领导果然不是盖的,这番话说下来,让人很容易接受,然后再提要求,这样大家也不会有抵触情绪,最后让大家提问题,尽早把项目中存在的问题都暴露出来。
这次会议算是一次相当有效的沟通,显然不是我三言两语能概括的,我在里面可能算是年纪最小的,也不怕笑话,有问题,我就说,很多时候,都被归结为“这是中国特色”,很难改变,我想遇到问题,我们要提出来,至于能不能解决,怎么解决,会不会问题太儿科被笑话,这些都不重要,重要的是把问题暴露出来,不至于问题严重到不可收拾的地步,影响到整个项目的质量和进度。
说了那么多,其实就是想强调,沟通在项目中重要性。如果一开始,我们便建立良好地沟通机制,我想很多问题,我们都是可以避免的。至于如何建立良好地沟通机制,要根据公司环境和项目背景来看,后续会慢慢和大家分享。