从交付到产品

这是一个七人的小团队产品组,正式加入刚好有一个月了。说长不长,不过可总结的倒是有一些。之所以会有些感慨,因为相对于前面所有的项目,这是比较特别的一个。

在公司将近三年的时间里,前前后后经历了四个项目,.Net, Java, Rails, Android,完全不同的技术栈。第一个.Net项目,跟着胡凯学习如何写程序,学习什么是敏捷工作。第二个Java项目,在米高的指导下学习如何代表一个团队与国外的客户沟通。第三个Rails项目,作为Tech Lead与澳洲的团队一起工作,与国内团队共享知识。最后一个短期的Android项目,以IM(Iteration Manager)的身份参与两个多月,与客户沟通需求,在短期内从零开始建立起Jira管理所有的需求。所有的这些我能看到自己一点一点的改变。而不变的是实实在在的客户,他们有需求,有计划,有鼓励,有疑问。

而这些,在产品组则有很大不同。

用户和客户

在交付团队,虽然没有接触过用户,不过客户时刻都在。从需求,设计,到最后BAT,这样一个循环的周期都是来自于客户而终于客户。在产品团队,客户与用户的角色是合二为一的,他们到无处不在是却又无法具体。这是个有意思的转变,首先是没有客户来帮你计划什么功能多久发布,并且间接的告诉你用户有了什么新的需求和为什么会改变。这里只能通过分析,以及用户试用的反馈,来推论需求。有趣的一件事是有位同事说,我们的单选和多选应该增加其他选项,而我告诉他这就是那天要上线的功能。

在交付团队,或者因为远离真正的用户,或者因为欠缺领域知识,很多时候只是从技术方面给予客户更多。而当用户可能就是身边的任何一个人时,关注反馈,了解市场成了工作中重要的环节。因为这是需求的来源,这决定着优先级的高低。

Story

同样以Story来进行功能的切分和管理。交付团队中,我们会习惯每个story都有详细的AC,因为这是团队之间沟通的契约,BA,DEV,QA,Producer,每个角色都会详细的分析每个AC,确保INVEST原则。而在产品团队,即便复杂的story可能描述也只是简明扼要的说明主要功能,配上不同页面的设计图片。详细的AC固然好,但是一方面这样的小型团队没有足够的精力,另一方面,开发人员有很大的主动性,他们了解这个功能的价值,就可能对详细的设计有足够的challenge,或许从实现的技术方案方面,或许从感觉用户的实际使用方面。可以称作灵活,因为可以BAT的人就在身边,任何可行的改动可以简单到只要一句话通知即可完成。

进度与压力

刚刚经历过的那个项目有一个IM和一个Producer,都是客户的人员,IM负责交付,Producer负责功能。这是一个天然的矛盾体,在固定的时间内,IM希望上线承诺的功能,而Producer希望更多功能上线。如果功能太少,那是Producer的责任,如果承诺多了而无法保证,那是IM的责任。于是,很多次看到这两个角色为了是否做某个功能挣得不可开交。 对交付团队来说,我们只能是给出我们的估计,并且所有人将这样的矛盾转化为大家无形的交付压力,希望同时满足他们两个人。而在进度方面,影响的因素会有很多,比如突然发现某个需求不很清晰,这样一来二去的讨论而耽误。又或者依赖的某个外部环境不工作了,必须要等待其他团队修复。

在产品团队,因为没有具体的服务对象,无论团队的成员是否有意无意的给予,压力都是来自于自己心里。记得我刚刚加入后仅仅和团队中唯一一个比较有经验的成员pair了两天,便开始需要独立工作。依稀记得那个story基本上属于一边看着已有代码,一边理解和猜测它的逻辑,一边尝试修改,一边还要讲给另一个刚毕业半年的应届生讲。我能感觉到压力,那种想要尽快贡献力量的迫切心态,与对代码逻辑陌生而缓步前进的矛盾带来的压力。

《黑客与画家》中提到

在越大的团队中,每个人的贡献就越接近平均水平 相反,在越小的团队中,每个人的价值和能力就越容易凸显。这种轻易可视化也是带来压力的重要方面,特别是当你想要表现的更好时。

开发-上线-探索

交付团队中,更多的工作是功能的开发,上线之后,便进入下一个开发的循环之中。产品组则不同,更像是开发-上线-探索。

每次IPM一个必要的环节是分析线上系统的运行统计情况,包括,客户端浏览器和设备,应用的入口点,访问的页面,停留时间等等,通过这样的监控,了解用户的使用情况,还有用户直接通过系统提供的反馈,往往是bug或者一些使用上的增强,进而探索更适合用户的功能。

持续部署

当所有一切都在可控的范围内时,事情会变得很有意思,或者说足够灵活。比如在部署和发布方面,如果上午验收测试完毕,下午就可以发布到产品环境。如果发现产品上出现什么比较严重的bug,会立刻将手中的工作切换到主干分支上,修复,提交,发布。当然这种灵活建立在对产品足够的信心之上,对质量提出了更高的要求。

参与过的交付项目中,测试是保证质量的重要方式,TDD,质量检查工具,这些都是必须的,而这里,没有硬性的覆盖率要求。但不意味着为了进度而没有测试,更何况没有测试只会让刚开始看起来快一些。TDD带来的好处已经无需论证,这里只是在测试的策略上更加灵活一些。这方面不知有没有规则可循,不过现在更多的是经验,或者建立在教训上的经验。

这些是一些零散的感受,总结为几个词的话,灵活,可控,但要自律。

新年的愿望,希望产品能顺利发展。

金数据 https://jinshuju.net

comments powered by Disqus