2015年参与Web项目开发的总结

1,165 views

从年初到现在,在新项目中已有9个月左右了;国庆假期一过,马上就要年底,趁现在有空,整理一下思路,回顾参与新项目的这九个月,总结过程中的经验和教训,心得和体会。
作为亲历者和旁观者参与新项目,从无到有的建立起一个开发团队,其中感触很多,伴随着项目的成熟和团队的成长,积累很多经验和教训。

项目初期的困境

项目从成立到现在,团队从无到有的建立起来,其中遇到了很多问题。

  • 新人比例过高。团队中有经验的自有人力比较少,而且事后发现来项目组的自有人力大多有离职倾向,参与新项目只是为了发挥余热。合作公司加入这个项目的员工基本以工作一至两年的人员为主,因此表现不尽如人意,比如:
    • 规范意识欠缺,既然是新人,对于开发过程中的规范几乎是一无所知。比如在代码评审时就发现,新人开发的代码虽然功能上勉强通过,但缺少日志、缺少注释,编码习惯如命名、代码格式等方面完全没有章法,有多少人就有多少风格。
    • 协作经验不足,软件开发项目是多人协作活动,结果我们的新人同学们完全是各扫门前雪,开发时完全不关心他人。比如代码提交后冲突、覆盖现象不断,直接导致几次发布测试延迟严重,版本上线推迟到凌晨才完成。
    • 沟通能力不足,比如在Story评审时表现不佳,测试人员对方案提出挑战时,直接放弃反抗,导致多个Story评审不过;又比如开发人员与测试人员意见不合时,情绪激动,气氛很尴尬,合作很不愉快。
  • 基础技术储备不足,比如:
    • 项目使用了bootstrap作为Web界面的UI框架,但项目组中只有先期加入的自有人员有使用经验,合作员工对bootstrap完全没有概念。
    • 缺少必要的控件,比如时间选择控件、表格控件、图表类控件、富文本控件、树控件等。
    • 项目决策使用MySQL来存储数据,但项目组居然没有人有使用MySQL的经验。
    • Web开发技能不足,准确的说,初期参与项目的几位新人,居然只有一位具有基本的开发经历,其他几位同事则是从零开始,边做边学。
  • 项目管理的问题,比如:
    • 进度压力偏大,由于前期方案调研、分析、汇报等活动占用了过多的时间,导致项目开发的时间被急剧压缩;
    • 工作量评估偏低,各级领导对于本项目非常重视,希望可以毕其功于一役,快速输出成果,解决各自的诉求,导致实际开发所需的工作量被忽视;
    • 方案返工,为保证项目一次成功,开发项目PM决定采取及早演示的策略,定期准备环境演示,及时根据领导及周边人员的反馈来修正实现,导致赶工和返工并存,方案的反复也就不足为奇了。
  • 项目组规范缺失或者执行不严格,比如:
    • 数据库脚本维护规范执行不严格,引入很多问题:
      • 表结构发生变动之后,开发人员以口头方式通知其他开发人员和测试人员表结构发生了变动,而具体的变动点则需要自行分析和处理;
      • 数据库的脚本中,乱码和语法问题层出不穷,并且缺少必要的注释;
      • 表结构的全量安装脚本和升级脚本分开维护,全量脚本用于新环境安装,而升级脚本用于已有环境的升级。本意是希望由开发人员来自行维护升级脚本,提升维护效率,但事与愿违,全量脚本与维护脚本中经常存在不一致,比如同一字段的注释不同,数据类型不同,最头痛的莫过于字段缺失,有字段在全量脚本里存在、而升级脚本中没有,或者升级脚本中为表增加了字段、全量脚本里存在多份,等等现象。
    • 代码提交配置库时,提交注释格式不统一,内容混乱,没有参考价值;事后回溯问题代码时,虽然可以找到代码的提交记录,但无法从提交日志中获取有价值的提交原因。
    • 问题单填写不规范,比如定位信息、处理建议、代码修改说明、测试建议等等字段,随意填写,不知所云;而测试人员在回归问题单时,经常需要与开发人员做大量的沟通,以确认修改范围和影响点。
    • 。。。
  • 我自己的问题:
    • 凡事亲力亲为;
    • 一头扎进技术细节;
    • 对业务的学习不够上心;
    • 对SE的抱怨过多;

技术的问题很好解决,只是要花点时间,但其它方面的问题就有点复杂。这些问题一度让我感觉很辛苦,压力很大,但某天和合作PM就这个问题交流过后,想起之前看过的一部电视剧里的台词,云在青天水在瓶,突然茅塞顿开,终于开窍了,想通了很多。
之前一直在从心底里埋怨这些新进员工如何如何,把很多问题都堆在他们身上,认为他们不重视云云,其实是我的心态出了问题。作为刚毕业的新人或者有一年工作经验的新人,和工作过九年的我相比,各方面肯定是不足的,拿领导对我的要求作为标准来衡量他们,他们必然无法达标。因此想清楚这一点,前面罗列的问题都有了应对策略。

应对策略和心得

  • 划分人群,量才器使。事先声明,这里的划分人群并没有偏见,不涉及种群隔离,仅仅是从工作年限、经验、能力等维度做考虑,划分为新手、高级新手、胜任者。
    • 新手,定义是刚毕业或者工作一年以内的员工,特点是技能和经验不足,无法对自己的工作及工作量做准确的评估,对合作项目运作规范全无概念。项目组里三分之二的合作员工都在这个区间,因此在工作安排时,挑选进度压力小、技术难度一般、相对独立的任务。同时安排项目组骨干作为导师,及时传递技能和规范。另平时要抓住机会和他们做交流,了解他们的困难和进展,及时引导,给予信心。
    • 高级新手,定义是工作三年以内或者是有两年参与合作项目经历的员工,特点是技能满足项目日常开发工作,对自己的技能有清醒的认识,但在解决技术难题时,容易逃避或者采取不合理的解决手段,另外偶尔会不遵守项目组规范,需要及时敲打。项目组里其余的合作员工在这个区间,工作安排时可遵从本人的意愿,由其自主认领。对于进度压力要求很紧或者技术难度较大的工作任务,平时不需要过多的过问进展,仅需要设置必要的检查点,在检查点上评估即可。
    • 胜任者,定义是工作三年及以上的员工,这样的员工走到哪里都是老员工,自然需要有更高的要求。在当前项目组里,符合条件的只有自有人员,自然要有更高的要求。
  • 完善制度,温言在口,大棒在手。
    • 制度的设计。设计项目组的规范制度,目的只有一个,提高交付效率,降低内耗。但出发点美好的事情,结果可能未必如先前之所想。因此在制度在设计时要广泛征求大家的意见,AAR工具这时可以大展身手,从团队成员口中提出的措施最能博得成员的认同。
    • 制度的宣传。制度颁布之后,还要随时、随地,配合恰到好处的样例来宣传,加深团队成员的印象和理解。
    • 制度的执行。规范的顺利执行离不开合理的处罚制度,对于不遵守规范的成员如果不及时进行处罚,会降低规范的严肃性和重要性,团队成员会无视规范的存在,导致更大的损失。
  • 不要让自己成为项目团队的瓶颈。项目新成立,技术上的困难很多,新人很多,我自己身上压了很多事情,效率很低,且效果不好,团队里其他成员想帮却帮不上忙。怎么办呢?把项目组当前遇到的技术问题和公共问题罗列出来,按照优先级整理出实施计划,把事情分配给不同的成员。由此,我来提供思路,参与事务的成员则负责细节思考和动手实施,这样一来,效率和效果均有明显改观。我身上的压力瞬间小了很多,而参与其中的成员自身能力也有了提升。对我自己来说,从自己做到指导他人做,角色发生了变化,要求也随之不同;一方面克制住自己出手解决问题的冲动,另一方面要计划、工作量、选人方面做细致的思考,让参与人可以顺利的完成任务,获得相应的提升,避免任务没完成、参与人又很疲惫,这种两败俱伤的结局。
  • 控制情绪。控制自己及成员的情绪,遇到问题时对事不对人,避免起争执,处理任何事情都要把项目目标放在首位。
  • 有效的培训。培训的效果只有20%到30%,效果虽低,但却是技能传递的最佳途径。从我自己的经验看,可以从如下方面改进:
    • 传授范围。依据培训主题,控制参与人的范围。
      • 一对一培训,效果最好,投入比较大,产出相对较小,因为一次只有一个人受益,但对于听讲人来说,印象会非常深刻。
      • 三到五个人参与的培训,适合于某荐具体技术的研讨。
      • 全员培训,适合介绍比如项目组规范或者一些公共的技术。
    • 培训注意的要点。切记不要讲太多的理论,以解决项目当前实际问题为目标。
      • 技能传递,介绍技巧和学习方法,避免在知识细节上做过多的纠缠。
      • 实践,辅助以必要的实践活动,注意要与项目相关,同时注意及时收集培训参与人的反馈,必要时要求参与人在实践完成后输出总结。

面试人员的技巧

团队从无到有建立,自有人力不足,团队的成员只能依赖合作公司来补充人力;但合作公司输送的人员良莠不齐,如何从中寻觅适合项目组的员工,这道难题摆在了眼前,亟待解决。
按照公司规定,我作为技术面试官做为第一道关,前来应聘的员工都需要经过我的甄别,合格的才能进入下一环节。
技术面试过程中,一般会针对应聘者的经历、开发知识做一些提问,目的是了解应聘者是否具有所需的技能,同时顺便了解应聘者的沟通能力和工作态度。

经历相关的提问

针对应聘人员的经历提的问题,基本上都属于开放类问题,如下:

  • 做过哪些项目?一般应聘人员的简历上其实都有写,这里只不过是随口问问,观察下应聘者的反应。
  • 做哪个项目时印象比较深刻?部分应聘者需要沉思一会,部分应聘者会脱口而出,部分应聘者无法回答。
  • 那个项目为什么会让你印象如此深刻?在上一个问题后紧跟着提问。考察下应聘者的准备程度,和前面问题相同,部分应聘者会沉思一会然后回答,部分应聘者会脱口而出,还有的应聘者想不出理由。
  • 那个项目多大的规模?可以从人员数量、代码规模等方面提示应聘者来回答。
  • 那个项目的业务是什么?了解下应聘者本人对项目的理解。
  • 那个项目的团队结构如何?从应聘者的回答中,顺便了解下项目的难度,公司对项目的认可程度,项目的离职率,骨干员工的数量等信息。
  • 你在团队是什么职位或者承担了哪些工作?了解应聘者的实际能力,以及离职前的工作情况。
  • 之前的工作中,遇到过哪些问题?
  • 这些问题都是如何解决的?答案无外乎自己搞定、求助他人、自动消失或者没解决等。从应聘者的回答中,分析他的主动性和技能在什么水平,解决问题的思路怎么样。
  • 业务流程的介绍。如果时间充裕,还可能就面试人的某项经历做细致的调查,要求面试人介绍下他开发维护过的模块的一些详细信息。

技术相关的提问

针对开发知识提的问题,基本上都有正确答案,另外限于时间关系,也不会问太深,毕竟合作公司提供的应聘资源经验和资历一般,技术方面可问的不多。

心得

及时总结,才能有所收获。

  • 结构化面试,这个方法很重要,但应用效果是否能够达到预期,还需要不断的总结和练习。
  • 面试过程其实是双向的活动。面试官按照预定的流程向面试人提问题,面试人回答问题,在这其中,面试官除了关注回答本身的内容,还要关注面试人的表情、动作、语速等等,捕捉这一系列的信号,以便于后续对面试人做最终评价做准备。而面试人通过面试官的提问的问题和表现,也可以借机了解一些信息,得出一些有趣的结论。
  • 面试别人,也是面试自己。与面试人交谈过程中,观察他人的表现,同时观察自己的表现,设身处地的假想当自己有一天做为面试人被他人面试,怎样表现才可以赢得面试官的信任。比如面试人的简历上经常会写比如精通SSH框架等,作为面试官,要考虑设计怎样的问题可以了解到面试人的真实水平和经历;假如我自己有一天被人面试时,如何回答问题,可以圆满的应付他人的挑战。这真是一个难题,尤其对于我这样的、工作有相当年限的老家伙。
  • 面试失败的表现,比如情绪容易激动、回答问题时小动作太多、答非所问、与面试官发生争执等。

绩效评价

这是一个大问题,尤其当前新人比例较高,老员工较少局面下。这部分主要针对自有人力而言,合作公司的团队成员不在讨论范围之内。
作为团队成员,可以从如下方面做评价。

  • 从业务交付角度看,评价维度包括进度、范围、质量。
  • 从团队贡献角度看,评价维度包括改进建议、技术培训、经验分享、技术文档等。

我自己也是团队成员的一份子,但领导调整了我的工作内容,现在已经不参与具体的Story交付活动,那么我自己的绩效如何评价呢?这个问题很让我头疼,暂时还无解。



若非注明,均为原创,欢迎转载,转载请注明来源:2015年参与Web项目开发的总结

关于 JackieAtHome

基层程序员,八年之后重新启航

此条目发表在 工作总结 分类目录。将固定链接加入收藏夹。