流程产品和人

　　之前一直存着一个疑问：支付宝页面这么少，为什么大家都这么忙？
　　有这个疑问的时候，团队里的人，包括上海那边的三个，总共有十几人。那时候也偶尔会听到其他人在说流程怎么不好，流程怎么改，诸如此类，云云。作为一个新人也只是听听就过了。那是没办法，连流程也不知道，怎么去建议，怎么去改。另外，当时也正在做一个升级包，163 个邮件模板j全部做成全新的。情况是一个升级包就改 163 个页面（回想起来这 TMD 难道不是个项目么，而且是给一个完全不熟悉这边的新人），当时也没怎么想，只是觉得连个升级包都这么麻烦，那么 10 来个前端这么忙也是理所当然的。
　　结果。现在团队已经有很多人。还是看起来特别忙。还是总有人告诉你他特别忙。什么情况?!
　　一、我的流程
　　先抛开公司流程，说说自己的流程。事实上，已经很久没有走完一个公司产品流程。离开业务组已快一年，在架构组一般都是前端内部的项目。项目开发流程都由自己或架构组项目小组规划，时间的制定也主要由自己制定报主管知悉。也就没有觉得流程有什么问题。因为一般我们都会分析项目，比如做样式库的时候大概的流程规范是这样的:
　　前期分析
　　要达成的目标
　　知识储备
　　投入人员
　　旧版与新版升级方案
　　项目分解
　　项目解构、细化工作
　　开发工作分配
　　开发/跟进
　　开始代码开发/文档编写
　　跟进进度，做相应调整
　　发布/宣讲
　　阶段性报告
　　阶段性发布/宣讲
　　另一个流程
　　开始下一个循环
　　对于这样的流程，都是按实现项目来做规划的。并不会有什么问题。不过，公司可不是这样。大家都有着一个共用的流程，这是某个人或某群人在历史上某个时间为你预先制定好的流程。
　　二、公司流程
　　至于具体的流程，这个我也不好细说，其实也没必要那么细。用三个事来描述吧。事情是这样的：一，某工友让我帮 fixed 一个 bug, 他说用的是新版的 Alice（我们的内部样式[CSS]库），结果 debug 发现引起 bug 的是上一版的 Alice 引起的；二，某工友突然有事走开，有一个新产品在做，做为项目支持的我，接手了他的工作，两天要完成 20+ 页面。三，有一个很有必要的点要改，但不是 bug，没人想起紧急发布。这样，这里有两个情况：
　　情况一：产品的＂升级＂包并没有升级计划。
　　情况二：新起产品项目没有为技术升级留时间。
　　情况三：流程分数和产品体验并不一定成正比。
　　当然，出现情况一、情况二这样的状况，也可以说是自己不够努力。怎么说呢，其实即便是使用旧的样式，不是在支付宝前端团队这样有维护样式库的团队，也会做得够呛。至于升级到最新版本，加班的话，也不是不可能完成，只是 QA 团队的测试又怎么能来得及？然后我们说 QA 也加班加点吧，事情也是可以完成的，但这对于公司和员工这总不是长久之计。
　　至于情况三。其实我们在一个大环境，在一个有着＂为了更好体验＂为口号的团队，在一个为了客户更安全稳定而特别看重可用性的公司，还有着很多层的老板关系。这样一来，这里可能（可能，是可能）流程算出的分数并不一定和体验成正比（因为这样写，我竟然差点都同意了）。
　　总结一下，这三个情况其实需要我们去解决的是两点：
　　时间只有 365 天，不长不短，不能省不能加。流程如何去保证时间的分配。
　　流程如何去保证产品的更好发展。
　　说到这里。就不得不说一下人了。
　　三、人
　　想想你平时是怎么做一件事的。特别是做你喜欢的事和不喜欢的事的情况会有什么区别。你想你自己的，这里我说两个关于我自己的事例。
　　事例一、在面试支付宝的时候，周爱民老师问，＂么么茶说你 CSS 不错，你能说出 5 个 IE 和 Firefox 在 CSS 上的不同吗？＂，当时我说了，这也没什么。只是有的 bug 能解决，但很难表述。他说，你这是缺少总结；
　　事例二、最近一个做产品的同学在知乎上邀请我回答＂为什么国外的如亚马逊的网页宽度是用户选择适应，而国内的大部分都是固定宽度居中的？＂，其实这个问题我也没思考过，但还是根据经验说出了观点，后来竟 TM 都自己要表扬自己了，竟然总结得有条有理（只是找来做个不是特别恰当的例子，具体为什么这人这么显摆请忽略）。
　　说这两个事例，只是为了引出两个点：
　　总结才能深入。如果一直流于表面，很难找到规律，就很难去深入。
　　其实人都是有惰性的，不逼一下自己很难知道自己的潜力是多少。
　　是的，我们就是这样。难道不是这样吗？如果你是前端，想想你是不是很多 BUG 能解，但就不能第一眼看出（经常有人问我为什么有人一眼就能看出来，你为什么知道，有没有什么秘诀）；想想你遇到马云，他抛给你一个观点，你是不是会更加努力去思考，而不是像你老妈突然抛出的一个观点（比如我妈总说我从忘事忘到大，到后来才想，原来真的有很多东西就是不爱去记住）那样去思考。
　　四、流程与人
　　刚刚说流程说到一半，就开始说＂人＂这个话题了。是的，像你常常听人说的，规则是死的，人是活的。人能创造这些东西，也能修改这样的东西。但我并没有想说这个。而是做这个需要一个深度用户，去总结，去结合实际深入思考。在架构组，我们大多数情况下只负责一个项目，流程是根据这个项目定制的，想出问题也难。但在一个有快 1000 人的部门，在一个多线开发多产品的，有无数项目的技术部。要如何去深入，去解决流程，不是深度用户，不根据平时实发情况来思考，也很难解决问题。举个不怎么恰当的鸽子，我们写程序时，都会特别注重重用：
　　列出所有点，分析程序逻辑
　　把可重用的写成模块
　　在各个页面运用。把特别单独 Hack。
　　流程也一样。小组去总结，团队去总结，再上升到小部门，到大部门。把可以用相同流程的项目归类出来，制定出一（多）个通用流程，甚至有特殊流程来应对重要的特殊情况。当然，这不是他妈在废话么，我相信人人都这么想。
　　其实事情并不是在这个点上卡住。而是：
　　谁去总结、收集这些资料了，到底有没有人在负责流程这种事
　　负责人是谁，他靠谱吗？是流程的深度用户吗？有没有总结？还是说只是看到功能升级，而不照顾技术升级的大瞎（侠）。
　　五、流程如何去保证时间分配
　　让我们想想前段时间讨论得非常多的，Facebook 让人羡慕的以工程师为主导的产品开发。他们为什么要以工程师为主导？产品经理就没用了吗？
　　问题就不直接回答了，但可以肯定的是，一种不升级技术的互联网产品很难长期保持生命力。就拿支付宝来说，他慢慢出来很多产品，越来越好用，用户越来越多。如果我们不在升级产品的同学，也升级我们后台的技术支撑，如何去顶住这么多人流的并发，如何保证机器出问题能顺利切流到另外的服务器。
　　其实说这么多，也就是为了引出：如果产品经理自己都不能很好理解自己负责产品的生命周期，能全面把握产品在各个点上的分配，比如不知道技术会影响这个生命周期。去告诉他。让他给你安排，让你的时间得到保证。
　　六、流程如何去保证产品的更好发展
　　一说到 BCD (Boss Centered Design)大家都会很兴奋，仿佛每个人都有一个很无理的老板，仿佛每个公司的层级关系都非常不乐观。其实事实上并没有那么严重，通常只是一两个事发生，甚至是不可避免地发生，然后就有人找个词来概括一下（当然，也有很恶心的，但我相信这些发展得很好的公司应该会很少）。
　　说个题外话，为什么有那么多人怕老板？因为他们对其有所求。无欲则刚，无求乃尊。如果你关注的是产品，那么你会去让你的产品更好，并让别人知道这样做会对产品和他更好。而不是单纯去怕老板，怕他不给你一碗饭揣。
　　好，是的，如何让老板认为这是对他更好的，同时对产品也好？
　　如果流程里面分数的算法更合理。假如提升产品的分数是加10 分，紧急发布分数是扣5分。那你的老板会不会让你紧急发布？可想而知。刚才也说了有时候是＂不可避免＂地发生所谓的老板为中心。当时我们以为老板不让发布，其实老板很想提升产品，但他觉得他的老板可能不想。但太多层级了，心思不好猜啊，人人都懂思想是直的，不然很难存活。只能说这种情况很无奈。而一旦有一个标准，那么人人心中也都有一个杆杠，根本就不用去猜别人的心思。
　　至于什么算法是合理的？单单这样说起来就是个哲学问题了。但当我们有一个现实中的产品，这时老板决策的作用就来了，决定什么应该加分，加多少分。
　　7、产品与人
　　另外，对于一个产品，也不会一整年都忙。毕竟我们现在有这么多人，几乎都是每个人负责一个产品，或者多个人负责一个产品。让人员分配好做（升级）产品的时间也是一个问题。
　　就像你经常会听说有人说自己很忙，或者表现得自己很忙。其实他们也会私底下说这个季度他们很闲，感觉好像不知道做什么。是啊，忙的时候觉得没必要去升级技术，不忙的时候觉得应该好好休息一下。产品压着人，也牵着人，而不是人去把握这个产品，去提升这个产品。我们又能怎么做去解救这些盲（忙，＂忙＂目，盲目）人呢？
　　有时候觉得团队有了业务组，有了架构组。架构组可以有测试组来测试前端框架；业务组里面也可以有专门负责项目技术升级，页面改善的的人。有很多人可能会问，改善产品本来就是每个工程师的职责所在，为什么还要去成立专门的团队来做这些事。很明显，如果职责不够明确，做不做都没问题的时候，再遇到惰性，还是有很多人会选择不做。而且，我们谁也不能保证公司的每个人负责的那一产品都当是做自己儿女来养。显然，期待每个人这样，也不可能。这时，把职责分得更细，加上传统的责任制，将令产品的提升有更好的保证。
　　产品需要架构，人也需要。而最终我们要做的是让人去惰性，把产品当做儿女去养，这对公司和人本身来说都是好事。
　　八、总结