当产品和技术部门没有统一的管理，即使使用有效的项目管理软件，所谓的deadline也不过是单纯的数字罢了。
“老大，开发他们要对数据库进行调整，近期不能送测‘改版需求’了。”我询问完开发主管后，随即就向我的老大汇报了这个情况。
“那这样的话，我们也没办法了”老大语重心长地告诉我，“这个功能可能会中断，你不觉得这个新版页面看上去很丑吗？”听完，我差点晕了我过去~
这是去年12月初，我和老大的一次对话。作为棱角还没磨平的我，眼看着自己的“孩子”面临夭折的风险，肯定不甘心，故产生了要为“孩子”讨回公道的想法——向老大再次“谏言”。
但是咱们反馈问题，还是要按事实说话。在平复情绪后，我决定对过往的项目工作进行梳理，万一这孩子真的夭折了也能抚慰其在天之灵。就在梳理项目工作的过程中，问题也慢慢浮现了……
项目梳理
这个“改版需求”的项目是8月14日开始的……
梳理启动
- 我将“改版需求”时间线内自己负责的所有需求都统计了一遍，并放在一个时间轴内（下图最左侧竖线），并对“改版需求”的重要节点进行了标注（包括时间+事件描述，下图最右侧竖线与文本）；
- 将“改版需求”及其时间线内进行的需求项目，以矩形的方式分别列出，头部标注开始时间，底部标注结束时间；
- 已经上线的需求项目用绿色边框标识，其余状态（包括：设计中、开发中、测试中等状态）用红色边框标识。
梳理分析
分析一：产品同步任务过载
如果拿出一条横线在时间轴上移动时，会明显的看到我在进行改版需求的过程中总共负责6个需求的工作。
分析二：周期停滞严重
有的需求上线了，有的需求停滞了，特别是在“改变需求”项目周期内插入的需求，还有不少已经上线了。
分析三：需求多次变更
除此之外，我们在上图左侧的节点描述中还能发现以下主要问题：
2017/09/04 因为新功能需要对页面进行修改，所以选择启动“改版需求”
2017/10/16 对新版页面进行修改（2017/09/06 UI已经完成新版页面）
2017/12/05 指出页面不好看
看到主要问题后，我脑海里首先冒出的就是“多次变动”，这也导致了后来的现象：开发改、UI改、产品也要改。
分析四：开发同步任务过载
看到自己单方面的任务混乱后，我查询了“改版需求”项目周期内开发哥哥的其他任务：
Web端需求任务共13个：
移动端需求任务共16个（除去改版需求）：
根据两张图的状态可以发现，开发哥哥中间穿插的很多需求项目也已经上线了。
发现原因
在项目梳理过程中发现很多问题后，我开始静下来回顾过往的工作流程，终于意识到出现这样的问题是“合情合理”的。
我的偷懒
每次开发主管分配任务后，想着自己的需求文档写得比较细致，就慢慢减少了与需求开发人员的沟通。后来，我发现开发哥哥拿到需求文档后，很少会从头到尾看一遍，更多的是看一点开发一点。恰恰是开发的这个习惯，造成每次开发过一段时间后才会发现需求设计存在一些问题。
后来我向我的一位同事描述了自己的问题，她告诉我在开发前她总会拉着开发过一遍需求，对比一下开发理解的与自己想的是否一致。是啊，如果当时自己能够拉开发哥哥一起过一下需求，或许就会减少像9月4日的那样的事故。
流程、管理混乱
（1）需求评审缺失
虽然主动找开发单独过一遍需求是必要的，但是如果在流程上定下规则是不是会更有效呢？平时的工作流程是这样的：产品们每次完成需求文档在系统上提交需求后，开发主管大致浏览一遍，就分配给开发哥哥进行研发了。正是缺少了需求评审使得开发者没有及时评估需求，如果仅仅依靠每个产品的自身意识去驱动，并不是什么长久之计。
（2）项目管理缺失
看到我和开发哥哥在工作穿插了多个任务，且有的已经上线后，我不禁想反问一下团队：“到底哪个是紧急的？”“需求项目的deadline是什么时候？”没人告诉我，因为现实中截至时间是开发主管随意定的，而紧急度的高低也没有具体的指标，有时候甚至和人有着很大的关系。没有需求评审、没有明确的优先级界定，所以需求总是变变变，任务也可以随意穿插。
寻求答案
从书中、论坛找了很多解决办法，要么过于高深不适应现在的部门，要么就是太概括，缺乏可以实施的细节。在这里要特别感谢一下粒粒橙老师，在咨询完相关问题后，她详细地介绍了自己部门的工作流程，主要部分整理如下：
项目立项：
一个月或者2周为一个开发周期，每个开发周期内，产品需要提出自己的需求。根据需求优先级（问题严重性、ROA值（资产回报率）高低、对用户的体验是否提升、对公司是否产生收益、是否增加内部人员的效率、技术成本是否会降低……）决定本期开发的需求；
方案评审：
需求是重要的，但是设计的方案不一定是最有效的，参与讨论实现功能过程的可行性；
交互评审：
（交互）设计师加入，参与细节的交互设计；
开发评审：
开发、测试人员等加入评审，评估需求实现可行性，以及实现的周期；
我非常赞同其中的两点：对需求优先级评估是有明确指标的，项目周期也是有固定的时间节点。同样，对于设计方案评估大家是用批判性眼光去看待的，一开始没有想着这个方案有哪些需要完善的地方，而是先去思考有没有其他更好的方案。
至此，终于意识到平日的需求（项目）工作流程都是结果导向，而非目标导向，所以团队通常情况下都没有好好重视中间的过程。
“谏言”
发现问题、找到可以尝试的解决方案后，我内心非常开心，毕竟自己的“孩子”可能不会夭折了。当我正想给老大发邮件描述这一系列问题时，我打住了，产生了一些顾虑：难道就我想到了这些？难道之前就没有人“上谏”过？
可能进入社会时间久了，自然就没了学生时代的无所无惧。但是，错了就是错了。于是心里突然冒出了“要么你变革，要么我走人”的想法，最终我还是把所有的问题、现象和整理的一些建议通过邮件发给了老大……
变迁
刚发完邮件没多久，老大就把我这个“低情商愤青”拉到会议室谈话了，万万没想到的是老大没有指责我，而是说了一句：“其实这些问题我也感受很久了，但是目前部门没有相关流程，愿意一起实施起来吗？”
听完后，我差点激动得跳了起来。但还是故作镇定地说了一句“I DO！”哦漏！是“OK！”
后来，我们部门开始把所有新的或者还未送测的需求全都拿了过来进行评审，大家也真正体会到人多力量大的益处。在需求评审中，我和我的小伙伴们也切实体会到了自己设计中不合理或者不完善的地方。因为公司内部的管理系统缺乏项目进程的管理，我们部门也开始尝试用一些管理软件比如“禅道”等作为优先级、周期等的管理。
时至今日，部门的工作流程已经发生了天翻地覆的变化，例如：标准化的需求评审从0实现到了100%。
结语
一次成功的突破之后，后面还会出现其他的阻力。当产品和技术部门没有统一的管理，即使使用有效的项目管理软件，所谓的deadline也不过是单纯的数字罢了。或许又要等待漫长的时间，才能够通过数据让一些人选择改变……
同时，彻底的变革无异于刮骨疗伤，当自己满心欢喜觉得在做着对的事情时，是否又给他人造成了一些烦恼呢？此时，与其想着方式的对错，倒不如想着如何把这件事更好的继续进行下去吧。最后，送给自己和所有小伙伴们一碗鸡汤，正如影片《熔炉》里所说：“我们一路奋战，不是为了改变世界，而是为了不让世界改变我们！”
欢迎小伙伴们在下方留言说出自己的想法，或者指出我的不足，并写下您的意见~
