入职半个月,痛并快乐着.
不可否认,上一家公司工作相对比较舒适,问题是上升的空间太少,而我又是那种有一点野心的人.直到现在,其实也不是十分确定离开是否正确,新的公司,实际上的单位小时工资却是降低的.但回想这三年的经历,却觉得自己是那种有些压力才能进步的人,不是那么自律的人.而且我的目标是做技术管理,需要一个合适的环境, 上一家公司好像很难有这个机会,新的公司提供了机遇和挑战吧..
忙,加班,为什么?
新到公司,观察两天,第一个想法是,公司怎么这么忙,而且加班频繁.为什么? 和老大谈过,老大是一个技术出身的人,对公司近期和远景都有规划.公司文档感觉上比较详细,使用业界比较知名的文档管理系统和任务跟踪工具.每个人都很认真地工作.但公司却一直很忙,还经常加班.前两天,听到另外一个组的PO也在电话里讨论这个问题,较有兴趣的听了一下,明显感觉到她有这种困惑,为什么大家这么努力,但结果并不是很好,也在试图寻找解决方法.我不是那个组的成员,不清楚他们的经历和遇到的实际问题,但就个人而言,我可不希望我所在的组将来会是同样的境况.
观察,小组处于什么样的环境中.
我加入的小组,比较幸运,是研发新的产品,已经有两名成员研究了大约两个星期,一名成员很热心,是一名有经验的程序员,简称A,一名当时第一感觉不是很愿意交流,比较年轻,简称B. A对于我的加入，非常热心，会给我这样或那样的帮助，不可否则，有些帮助很有意义，但有些关于技术的理解方面，感觉上总是和他有些出入,有时候表达了个人观点后，会遇到A的强烈反对，但毕竟觉得A研究的时间比我长，不是对自己的想法特别有自信.然而实际一段时间下来， A的想法确实是有问题的，而且发现他的一个习惯，如果他认为某个人是牛人，那么那个牛人的观点和做法就是对的，牛人的观点和做法就是论据，官方的文档都是入门级的，实战意义不大，其他人的观点都是不对的,最致命的是不屑去听别人的论点. 反观B,却比较踏实，有些观点，个人感觉还是挺靠谱，但往往也被强势的A否认. 同时发现目前小组的研究成果有些混乱和没有方向，不知道到哪个阶段了，更不要提什么计划，可控的开发了。这种状态给人的感觉可不妙，这样下去，估计整个小组可能试用期都过不了.
打牢技术基础 VS 盲目追风
刚进小组，A 强烈建议我不要看官方文档了，认为没什么作用，他从一个牛人哪搞到一个成型的项目，认为研究那个项目更有意义.没办法，个人感觉基础比较重要，还是坚持从基础做起，从官方文档看起。想法很简单，看牛人的项目，没有基础知识的话，只能是云里雾里，或者知其然，不知其所以然，又或无法从根本上证明所谓牛人的做法是不是最优的或最适合我们现在的项目。敏捷，也是从基础一步一步持续改进成高端的，而不是用一个看着很高端，然后不断修改.用来4天左右的时间,基础牢了，自信心就有了，尝试并比较了几种开发方式，发现有一种官方文档中的一个基础例子非常适合用于目前团队的开发，很遗憾，这种开发方式没能说服 A , 但最后得到了老大的认可和赞同，老大也认为这种方式是符合目前团队开发的，也能满足他目前对团队的期望. 分析A的想法 ，他可能比较迷信技术权威，如果他不认可，就很难说服他。算算到目前为止,两,三个星期过去，类似的争论又发生过几次，还是没能说服A, 但很多倒是得到了老大的认可，其实仔细想想,原因比较简单，很多方法，都是从基础概念出发分析的，很容易就能找到一个合理的方向。时间久了，估计A 会认可我的技术，到时候讨论解决方法就会比较容易了.(其实有时候,我也在想,我以前是不是也是A这样地人,人很善良,没有恶意,但有些固执,不是很喜欢听和分析别人说什么.想起上一家公司的领导,几乎都会问,我可以怎么帮助你.这也是我内心改变最大的事情.)
信息透明,目标明确 - 每日站立会议
进入团队第一天下来,真是不清楚大家做的怎么样,只是听到抱怨的声音,但却不知道到底研究到什么地步,问题在哪里,又很犹豫要不要加班,要加多久.感觉很累,没有目标,没有成就感.第二天还是如此.这时候开始问自己究竟为什么会这样,每天没有明确目标,也不知道怎么样算是可以下班.所以要解决的问题是: 需要明确每天的工作量,把大家遇到的问题暴露出来. OK , 每日的站立会议. 想到这里,第三天早上和老大谈了一下每日站立会议的想法,老大听后,完全支持. 开始每天站立会议后, 可以定每天的工作目标,集中听一下大家遇到的问题.由于之前的信息比较散乱,随后的几天还是有些辛苦,但至少每天需要加多久班,心理有了数,而且每天目标也比较明确.两天下了,大致知道团队目前遇到哪些技术问题,研究到什么程度.在此基础上,终于可以整理出团队的研究进度了.意外的发现,其实B也是一个很热心的人,只是有些腼腆.
技术列表 – 透明团队所处的阶段
每日站立会议,老大一般不参加,只有团队参加.团队想寻求高层的技术支持,或者合理的评估任务计划,通过面对面交流,有时总有种没有理顺思路的感觉,也没有很有说服力的东西.想到以前在公司做的技术负债列表,把当前我们遇到的问题,要解决的问题,已经解决的问题,列出清单,分析每个问题的影响,制定优先级别.团队当前的情况,就非常的清晰,而且大家可以在同一层面上看待团队所遇到的问题以及取得的成果,基于此,和老大讨论任务计划时更有底气和说服力.
回顾会议 – 暴露团队的问题,寻求上层帮助,寻找解决方法.
来公司一个星期,终于理顺的很多东西,但 PO那边的任务因为之前就已经定下来了,团队还是在痛苦中赶工.PO在不了解我们现在技术上遇到的问题时,认为要实现的东西很简单,团队基本没什么争论的余地.没办法,先做出来,然后在说明,否则没有说服力.怎么才能让PO和老大更好的了解团队遇到的问题? 我选择了回顾会议.在会议上,把老大和PO都请到了,其实当时比较担心老大和PO 不能参加会议. 比较幸运,老大和PO还是抽出时间,参加了会议.会上,列出团队那里做的好,那里做的不好,遇到什么问题,大家讨论如何解决.老大和PO 也积极参与其中. 老大和PO能积极参与其中,心里就有了底,证明老大和PO不是那种只关心结果,不处理问题的人,这也给团队很大的信心.整个会议下来,团队所遇到的问题都暴露给PO和老大,他们从会议中,也感觉到团队遇到的问题,以及任务进度缓慢的原因.老大是技术出身,会后,给团队一个很强的支撑,他决定周末回顾一下代码,确认一个开发方式.(周一的时候,老大兑现承诺,认可了我提出的开发方式,至少个人觉得老大是非常可信任的).但是很遗憾,PO还是没有办法改变原有的任务计划,后来了解到,他也没有办法,他的计划是他上面的老大安排的,他很难改动.团队只能更聪明的作事情了. 但至少,老大和PO 都很理解我们目前的处境.
简单实现,快速达到业务要求.
敏捷能够快速迭代,迅速产出,很大一部分依赖完善的UT.但这次我们是出原型,如果按照我们的开发方法还是很难达到PO的计划,怎么办? 没办法,找老大讨论.老大在前面技术列表和回顾会议后,重新制定了技术要求,在新的要求下,团队达成目标还是比较现实的.虽然个人能感觉到,实际上老大对团队有更高的期望,但是在现实情况下,综合考虑,降低了原型的技术要求.项目管理的三要素,资源和时间有限,只能修改范畴了.因为是原型,所以选择直接简单的实现,大家达成一致.
实现任务,消灭加班
公司的第三个星期的星期一,也是到公司后第一天没加班,并且心里没有什么压力的不加班.不知道以后怎么样,项目感觉进入了可控状态.想要做到项目的长期可控,估计以后还要和PO那边做更多的交流,隐约感觉到,在需求那边还有很长的路.但是感觉还是小有成果. Keep in walking….
突然决定已经话，要交付的不只是软件产品,更是一个好的团队.