APP发版情况还原
此APP本身是一个2G2C性质的产品。即产品的业主方（或者说需求方、管理方）是G端客户，服务对象为个人用户。近期有一个重要的版本，涉及到客户内部两个部门的协助推进，两个部门各自也拥有独立的研发团队。
在经历了反复多次的组织沟通、需求确认、产品设计之后，最终进入到研发阶段。过程虽然也有波折但整体还算顺利。最终到deadline要上线了，结果还是出现了意料之外的情况。
- 上线前给到产品测试的时候，发现有1/4的数据有异常
- 版本发布需运营人员协助配置各广告位，但并未提前安排，导致上线当场部分推荐位抓瞎
- 后续iOS版本上线后，与android的视觉风格差别过大
最终的结果是周末加班处理这些问题，app的整体上线时间延后两天。
表面上的问题
这一波加班结束后，整理这次事件出现的问题，大致有以下几点：
- 上线前的准备不充分，相关干系人不到位（运营位配置）
- 技术前期准备工作不完整（提供的数据未经过准确测试，导致未发现数据有误）
- 技术团队的开发测试质量不达标（ios和android有明显的视觉偏差但开发与测试环节并未警示、也无所谓修复）
- 双方对进度时间不明确（虽然有大致的一个实施计划表，但并没有涵盖所有的人员角色，工作也没有完全纳入，对进度表的更新也不及时）
问题产生的原因
其实各位老板如果经历多了，一眼就能看出来核心问题。那就是项目管理的混乱
由于这个项目涉及到两个部门、两个项目开发团队，这也导致各自开发团队的负责人都认为自己并不是主要负责人，进而在进度排期和关键节点跟踪上出现纰漏。
没有统一的负责人 -> 没有人统筹整体计划 -> 只出大致计划表但还有很多细致工作没有落实到具体人。
没有统一的负责人 -> 相关干系人权责不明确 -> 没有人去检查关键节点进展情况 -> 团队中各自只负责自己这块儿，按照上面传达的要求搞完就好了，有人说不对的时候我再改。
没有统一的负责人 -> 相关干系人权责不明确 -> 任务只有分配没有对结果的检查 -> 风险被滞后到上线时接受客户与用户的检查才会爆出
当然在具体的工作中还有很多比如工作流程不清晰（、在工作中存在惯性思维（或者叫惰性思维，不够积极主动）等，也是为这次的问题埋下了种子。
优化建议
既然认为有这些问题，下面就是要考虑怎么办了。
首先 明确负责人
所有的问题最终归口都可以归到具体的项目管理负责人身上。这次项目明明有两名高阶的项目管理人员，却还是出现无人牵头的问题呢？无非就是因为双方都不认为自己应该负责跟踪呗。
- 我方团队认为：这个整体开发都是对方团队做的，我方技术团队只是做配合工作，自然应该不是我方牵头
- 对方团队认为：这次整个开发都是为了满足你方客户的需求，自然你方要牵头，我这边还有其他的部门客户要服务。
对于这种双方边界“可能”不太明确的情况，个人建议看最后项目出问题的结果对谁影响更大来确定主要负责人。比如这次如果APP更新不上线，我方客户可能面临后续工作无法开展，而对方客服只是整体业务的某一部分推进出现阻碍而已。那么这种情况，整个“联合项目团队”的责任人就应该由我方项目负责人来承担。
其次 确定关键干系人 产出进度表
由负责人牵头，端到端的去梳理当前整个项目中所涉及到的业务部门、团队、人员和功能模块，并列出干系人清单，保证后续出现问题可迅速定位到具体人。
同时也借助端到端的思路，去排列工作计划表，将所有涉及到的工作均在表中进行规整排期（project或者其他甘特图工作，项目管理中很常用），这个排期表应该遵循这些基本原则：
- 如果是不同人负责的模块，应该要分开来列（确保每项任务到单独的某一个人）
- 任务要有明确的结束时间
- 所有的任务应该要完全覆盖整个项目所涉及到到的各个方面（不应该出现进度表中没有但需要单独安排人做的事儿【如果出现了就在进度表中加上去】）
具体怎么来做这个排期表 后续有机会我再来跟大家分享。
第三 对任务进度表负责
任务进度表并不是产出之后就完事儿的，它也是很多团队每天早上站立会议、或者每周进度会议的核心。有任何涉及到任务deadline的变化都要及时反馈到进度表中，项目中有新的变化、新的任务也要及时更新。这样去针对整个进度表做固定频次的检查（check），才能真发挥进度表的作用。
而这次我们遇到的这种双方团队跨地域协作的情况，更需要关键人员约定一个频率（每天或每周固定日期），通过语音会议等方式去核对进度，更新任务表，确保双方团队的关键干系人都能了解整体进度，做好项目风险的控制。
最后 针对这次事件的具体执行优化
上面三条是放之四海皆准的项目进度管理和风险管理的基本手段，那么针对这次我们遇到的具体案例，也是有一些执行层面可以优化的内容。在复盘中我们也做了相关整理。
需求发起时
两个部门客户的需求相互之前是有矛盾点的，在双方的需求碰撞阶段，经历了多轮正式协商，才确定了大体需求方向，但到需求分解和产品设计阶段，还有很多执行细节需要明确。这时就需要经历反反复复的协商沟通了。
在这类沟通中有个比较常用的，如果双方无法达成一致，则建议的沟通路径如下：
第一阶段 我 - 你
第二阶段 我 - 你领导
第三阶段 我 - 我领导
第四阶段 我领导 - 你领导
这是一种螺旋上升的问题解决通道，毕竟在组织中，问题总能升级到一个能拍板的人手里。当然还有一点比较重要，就是如果在过程中形成了比较重要的共识，最好能最终通过邮件或其他比较正式的形式进行阶段性确认，方便后续在工作开展过程中出现反复。
研发过程中的跟踪
在研发过程中，因为团队分布在不同的地域，因此更要约定要中间版本（或里程碑）的分布，约定好研发的进度确认点。
上文提到的每天的站立会议（或者语音会议、电话会议等等），工作组内需要共享（至少关键干系人需要做到进度的周知），当然团队中如果有devops思想指导下的相关工具也需要大力用起来，毕竟只有统计了才会有管理。
而在团队开发工作中，获取的三方数据，也要做一个基本的判断与验证，确保对方提供的数据不存在“肉眼可见”的问题。（深入的问题咱也保证不了，只能上线跑了）
另外，过程中的进展也需要反馈给关键客户知晓（最次也应该是日报形式或周报形式，有条件应该当面汇报，毕竟很多时候你的日报根本没人看），而关键版本的确认工作也要经过客户确认，否则长达一两个月的开发，很容易让客户有一种你们到底在干没干活，现在干成啥样了？我都不知道的两眼一抹黑情况。
在产品测试阶段，因ios不方便测试（不像android一个apk包就能装），因此我们仅提供给客户android的测试版本，在沟通过程中也围绕android版本进行，这也在一方面导致ios上线后我方才发现双版本视觉差别巨大。
虽然它核心问题是开发团队的质量控制出现纰漏，但如果有提供生产环境的内部测试版本，让开发人员以外的角色来参与使用测试，至少要覆盖主要干系人，再加上一些普通用户，这步很有可能导致在上线前发现一些从最初设计就没有考虑的问题，或者技术实现的偏差（当然如果原型就拉了一圈人做了可用性评审，这块儿发现设计之初的问题 的可能性就比较小）
另外，客户侧的重要干系人不一定在设计启动之初就参与进来（或者开会喊了但其实心思并没有过来），所以最终产品的确认流程还是有必要的。
上线时
在产品侧已经完成工作时，并不代表就可以直接上线，这次的案例中，我们的版本就涉及到服务布局的重大调整，因此需要运营的同学针对新版布局重新上传宣传图。相关版本宣传文案、各渠道广告、宣传物料等都需要做推进，因此在上线时也需要考虑周全，涉及到的重点部门、团队，也是需要纳入干系人清单中，做到信息及时通报的。
核心关注
血和泪的教训说了那么多，其实落到核心还是：
- 明确负责人
- 明确核心干系人
- 建立计划跟踪表
- 以跟踪表为核心按约定频率跟踪/更新服务进展
以上，希望对各位老板有所帮助，欢迎留言，一起讨论产品与项目的管理。
网友评论