这是一个七人的小团队产品组，正式加入刚好有一个月了。说长不长，不过可总结的倒是有一些。之所以会有些感慨，因为相对于前面所有的项目，这是比较特别的一个。
在公司将近三年的时间里，前前后后经历了四个项目,.Net, Java, Rails, Android，完全不同的技术栈。第一个.Net项目，跟着胡凯学习如何写程序，学习什么是敏捷工作。第二个Java项目，在米高的指导下学习如何代表一个团队与国外的客户沟通。第三个Rails项目，作为Tech Lead与澳洲的团队一起工作，与国内团队共享知识。最后一个短期的Android项目，以IM(Iteration Manager)的身份参与两个多月，与客户沟通需求，在短期内从零开始建立起Jira管理所有的需求。所有的这些我能看到自己一点一点的改变。而不变的是实实在在的客户，他们有需求，有计划，有鼓励，有疑问。
而这些，在产品组则有很大不同。
READMORE
用户和客户
在交付团队，虽然没有接触过用户，不过客户时刻都在。从需求，设计，到最后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带来的好处已经无需论证，这里只是在测试的策略上更加灵活一些。这方面不知有没有规则可循，不过现在更多的是经验，或者建立在教训上的经验。
这些是一些零散的感受，总结为几个词的话，灵活，可控，但要自律。
新年的愿望，希望产品能顺利发展。