在写150版本总结之前我先回顾一下120版本的问题：

一、依然有方案不清晰，造成后续改动

二、方案改动没有书面的通知；

三、UCD设计体验变更较晚才下来，代码变动大；

四、SDK相关代码功能的开发，没有很好的传达到到位；

五、跟SDK开发的沟通成本还是较大。

简述

   此次150版本，方案设计这部分没有问题，方案设计比较清晰，没有大的方案变更；

SDK这部分有时候会存在一些交付解决问题延迟的情况，SDK交付版本延迟，晚导致APP出版本延迟，或者深夜才出来版本。这部分我们自己以及测试方面颇有怨言。

说下主要问题：

1. UCD体验改动

A．鸡毛当令箭

   这里不是说谁的问题，要追究谁的责任。UCD前期给的低保真图，严格意义上来说只能作为参考和预热，根本是不能作为启动开发依据的。因为交付时间紧的问题，要求立即照此启动开发，实际上也是有风险的。

   后来版本经理说，“UCD没给高保真可以不开发，你们可以提达不到开发标准，无法启动开发”，然而现实是没有高保真图，也不得不启动开发。

   事实证明，开发过程卓很多没落实的细节，不少交互没有想明白，连相关页面草图都没有，导致不断的来回讨论拉会议、评审，产生了很多沟通上的耗损。不仅是时间上，还有精力上的耗损，开发者的倦怠和疲乏在增长，是一种熵的增长。潜在地导致了安卓、iOS开发人员细节理解不一致，理解不一致又导致反复核对、遗漏、再核对、仍有遗漏、问题单，这一套不好的循环。

B．一心二用

   后来了解到，UCD方面并没有全力投入到我们的项目中，据说是同时负责两个项目。一个项目前期最重要任务就是方案设计和UCD体验，UCD同时负责两个项目的这种安排，不管是对项目来说还是开发人员来说，我觉得都是不合理的。最上的决策层，对这部分有管理缺失。

C. 当面沟通

   UCD人员和我们不在一处办公，我觉得也是不方便的因素之一。有很多简单的体验，本来内部聊天客户上简单问一下就可以解决的。如果一两分钟答复了，就完事儿了。结果往往是一两分钟没反馈于是打电话沟通，复杂的地方有时候打电话描述都说不清楚，还得附带截图说明（手机截图-mac机取图-传到pc-pc取图发送）。怎么说都不如面对面拿着手机直接看效果来顺畅和省事。

D．优秀体验的参照标杆

   按照UCD的说法，开发者不能“我说一你就做一，我说二你就做二，要有点自己的想法”，要能够参考别的APP的优秀体验自己做一些决定。按照这个说法，到底是参照谁，微信还是微博，标杆是谁？为什么一会儿参照微信，一会儿参照微博，之后又怪开发者不找自己方案，半夜赶版本的时候找谁去对方案呢。按照这个做法，安卓、iOS自己还得频发拉小会议来对齐体验，说起来这部分的根源还是设计上的缺失不是吗？

2. 体验会改动频繁和大众体验时机不妥当

   我们内部体验和大众体验的安排时机不得不说一下。

   所谓内部体验，即内部知晓方案实现的前提下，项目内部人员体验一下基于目前设计方案的完成效果。这个体验会的意义在于发现开发的bug、体验上的设计缺陷等等。

   所谓众测体验，即以普通用户的角度，去看看我们整个用户的体验上，有没有什么是用户觉得不懂不理解的，不会用的。

   可以看到，这两者的功效是不一样的。而众测体验阶段，如果有改动要涉及重大设计改动的，宜早不宜迟。

   我们做完每次做完一轮迭代，即进行内部体验，提出修改方案和修改意见，这个流程符合情理。

   时间上，11月20日左右进行了转测试提出了部分问题，应该属于bug修正的功效，之前有些小范围的内测或转测也是一样。

   11月29日，进行了一次正式的内部体验，这时候大部分开发工作都已经完成了。按道理来说，应该尽早进行众测体验，发现体验上的设计变更。因为设计变更涉及到的代码改动大、风险大，特别是涉及到数据源处理，牵扯广泛，原有已达成也功能可能就出问题，必须全面测试才行。

   开发方面所知道的，迭代三完成日期大约是12月9日左右（可能处于迭代安排有所提前），实际上直到12月20日才进行众测体验。

   参与进行众测体验并有设计改动意见的还有设计体验的老大，提出某些设计的问题。不少问题都已经走了评审流程，或者已经达成共识的地方，不可以直接用评审约定。如果真的必要改动，是不是还要拉起原先评审的一批人，问问他们同不同意这么改？

   而且这个改动这么必要的话，初期制定方案的时候为什么没提到，当然，我不确切知道有些领导是不是在我们项目组担当有职责。如果有，是我的话，这个时候不提，即使是特别差的设计，也应该接受自己缺位导致的苦果。而不是在非常后期的时候来给出“指导意见”。要知道这已经到了“众测体验”阶段了，菜都要端上桌了，才想起来没放料呢。再者既然是众测体验，我觉得不应该有身份带入，任何人都是小白用户。

    再进一步地，测试方面或者版本经理给《体验修改问题汇总》到开发人员的时候，也应该现先筛选哪些是不合理的、甚至很扯的，应先去掉。而不是给过来，开发人员再去拉会议找SE找SDK去沟通，这是非常低效率的，能避免的要避免。毕竟开发人员只有决策的建议，并没有决策权力。

3. SE前期缺席导致决策拖沓

   前期iOS视频录制攻关不顺利，天天在家做demo测试，压力较大；而实际的困难并不是技术能力达不到，是受限于复杂的特性要求（720P+横竖屏+码流限制+视频大小10M以内）业内没有可参考的资料，可以说是iOS系统封闭性的原因无法达成。

   何况以我们的技术力量和时间成本来说，如果发现成本太大或者达不到商用标准，应该立即砍掉，转将人力投入到关键部分。

   这一点， SE出差不能关照到项目推进的细节，没有最早决断，耗费了不少精力。毕竟开发者不可能说，这个我做不了，不要做这个了吧。

4. 细节，我们要更加注重细节

   iOS团队内部，代码检视部分还需要做的更加好。不管时时间紧任务重，这一环节不可缺失。

   解决问题单的过程中发现，不少处理的比较草率的地方、注释不清同事看不懂的情况，也做了不少擦屁股的工作。有时候非自己开发的功能测试过来询问业务细节，自己因为不了解相关代码，也不能解释的很清楚，转而要求测试去直接询问开发的人。这一点我们做的不好。

   我们要考虑到一个问题，如果这个开发人员请假了呢？离职了呢？

   我们需要一个正式的内部代码讲解会议和代码审核会议，全面梳理一下本次项目的所有代码，已经改动细节的原因讲解。为什么要这么改动，是什么评审意见得出的，或者其他原因。

优点简单说：

   内部团结，大家都全力投入项目工作，非常非常负责任；

   响应快，测试方面提出的问题及时响应、问题单及时处理；

   沟通顺畅，安卓和iOS随时核对细节，保证了体验一致，涉及到多方改动的基本能及时传达。