之前不断存着一个疑问：领取宝页面这么少，为什么大家都这么忙？
有这个疑问的时候，团队里的人，包括上海那边的三个，总共有十几人。那时候也偶尔会听到其他人在说流程怎样不好，流程怎样改，诸如此类，云云。作为一个新人也只是听听就过了。那是没办法，连流程也不知道，怎样去建议，怎样去改。另外，当时也正在做一个升级包，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。
流程也一样。小组去总结，团队去总结，再上升到小部门，到大部门。把可以用相反流程的项目归类出来，制定出一（多）个通用流程，甚至有特殊流程来应对重要的特殊情况。当然，这不是他妈在废话么，我置信人人都这么想。
其实事情并不是在这个点上卡住。而是：
- 谁去总结、收集这些材料了，到底有没有人在担任流程这种事
- 担任人是谁，他靠谱吗？是流程的深度用户吗？有没有总结？还是说只是看到功用升级，而不照顾技术升级的大瞎（侠）。
