临时项目经理
公司的PM（项目经理）采用了轮流制，这次轮到我来做了。
与上一任PM沟通后，发现风险并不在于技术方面，主要还是在于需求和跨组协作方面出现了问题。
具体包括需求评审不够细，有遗漏，导致实际所需时间比预期长；操作变更未通知其他组人员；缺少UI评审环节等。
让我印象最深刻的是一个发送站内信的功能，因为客户端与产品对于兼容程度的理解不同，而导致项目延期了多天。
一、需求和技术评审
1）需求评审
鉴于之前的经验教训，此次需求评审做的比较细致，开了一个小时左右。
但是从各方的表现来看，在开这个会议之前，大家都未细看需求。在会议上，也只是单方面的听产品说明需求。
如果读过的话，那么肯定会有更多思考，在会议上与产品的互动也会更多。在会上有一个重要信息，那就是当前的需求是不完整的。
还有两个重要的需求，正在策划中，随时会添加进来。当前的话还是按计划执行，我会用飞书制作一张开发进度表。
表格中包含需求名称，版本，优先级，平台，开发人员，进度，工时等列，每个组对应的需求都会有单独的一行。
将原始需求拆解成任务，这个工作还是客户端做比较适合，因为版本迭代时，其他组都是为他们服务的。
而且我还需要与客户端沟通制订一些迭代中的时间结点，这样我就能更精确的把握开发进度，保持信息同步，也能预判是否有延期风险。
在初评之后，还有个详评，但鉴于需求比较明确，我将详评和技术评审合并在一起了。
2）技术评审
在第二轮的技术评审之前，我们组详细的阅读了需求的每个字，其实如果细看的话，可以发现很多没注意到的盲点和细节。
我在阅读第一遍后，就找到产品核对了好几个细节和歧义，让她也补充了图示，还特地让她完善了兼容性说明。
在会议之前，还让客户端按照他们的节奏制订了需求开发的顺序，这样我们其他组可以配合他们，提前准备好接口或数据源。
在会议中，会针对每一个需求，每一个组，从头过到尾，从接口数据结构到一张表的字段，尽量做到不遗漏，会议也进行了半个多小时。
总体来说，将看的到的，都核对了一遍，另外的细节，各个组在会后再讨论。
在会议中又提到了一次前后端分离的问题，因为这次有个广告需求，这些业务的表都存在我们维护的数据库中。
服务端既不想连接这个数据库，也不想做解析，他们希望我们提供接口给客户端，服务端只做一层转发，那我肯定不会答应的嘛。
如果直接与客户端交互的话，那么我们这边就要做进一步的优化，防止在用户量上来之后，出现性能瓶颈。
并且一旦有问题，调试链路也变长了，与营收相关的业务，公司肯定会重视，下班时间有问题还得配合排查，很多现实问题让我不得不仔细斟酌一下。
后面经过讨论后，他们希望再招一个人，来应付这些需求，那和领导申请即可，上半年完全没有名额，现在现金流好点了，名额也开放了。
不过在人到岗前，还是得先把任务职责划分好，最后还是由他们和客户端对接。
在进一步与客户端沟通开发节点时，iOS表示目前还无法给出明确的时间点，他们还有一些特殊的事情需要完成，而安卓表示最快这几天就可以开始了。
二、项目过程
在需求评审召开一周多的时间之后，各个小组才陆陆续续的正式开发。之前在处理上个版本的问题，或其他杂七杂八的需求。
直到现在服务端还没有评估好开发时间，更没有给出初步的提测时间，于是我又做了张表格，用于记录各端的提测时间。
目前给我的感觉就是服务端对项目管理并不是很配合，其他组的话，催促一下会有点反映，但他们组的响应总是会慢几拍。
1）时间结点
各端将提测时间制订好后，粗略算了下，都要十多天的开发时间。
为了能及时的了解进度情况，需求评审时我是想让客户端制订一个各个功能的时间结点，然后我就在这个时间点确认是否完成，以此了解开发进度。
在正式与客户端表明意图后，他们表示这个操作可行性很低，无法执行。就比如最近服务端有个人休假了，那么与他配合的功能就不能按计划开发了。
如此一来，之前订的时间结点就无效了，客户端表示，他们目前可以给出功能优先级，同时他们建议各端及时的更新进度表中的状态。
这样也就能了解当前版本的整体进度了，并且每天固定时间在群里和各个组同步进度，询问是否有需要沟通的问题。
服务端未能在规定的时间提测，这其实也在我的预料之中，因为这些天的开发过程中，有一个组员的进度慢了一天多。
2）测试用例评审
QA会准备一份详尽的测试用例，涉及到这次版本功能的方方面面，以表格或思维导图的形式展现。
他们会将版本迭代的相关人员组织在一起，开一个评审会议，一般在一个小时左右。
在讨论用例的同时，也会再一次与各端确认技术细节，同步对功能的认知。
大家面对面的谈，也能让QA及时的更正那些他们对需求的误解，尽早发现问题，也能避免更多的损失。
3）UI和业务验收
QA经过测试和预发两个环境的验收并通过后，接下来需要产品和UI的验收。
业务方包括产品和运营等人，她们会查看功能是否有遗漏，版本的实现能否达到她的预期，由于时间的关系，对于用户体验的要求不会很高。
UI会查看页面与设计稿之间的匹配度，他会将需要修改的部分配上像素值和截图，并且也会提一些体验修正。
开发会对体验方面的问题做些适当的调整。
4）复盘
首次需求评审时的版本比较简单，两周左右就能完成。后面加了一个比较重要的营收功能，一下子就拉长了整个开发周期。客户端比预期的提审时间玩了几天。
iOS希望这次版本能将之前用户提的问题一并修复，提升用户满意度。iOS工程师认为期待了那么久的新版本，却没有修复预期的问题，非常影响用户心情，于是就延迟了提审时间。
整个版本迭代周期差不多是一个月多几天，其实我个人感觉周期有点长，期间会发生变数的概率比较高。如果每次提审时间都延迟个几天，那么积少成多，可以加起来都有一个月的。
服务端的人员变动也间接影响着版本迭代，期间有个人是经常请假或来半天，导致客户端虽然布好了页面，但无法联调。另一个在版本迭代快结束时离职了，由于在后期，所以并没有影响提审时间，不过上线后的维护多多少少会有点影响，毕竟换了个工程师。
客户端和服务端积累着不少陈年Bug，这些Bug一旦爆发，那么就会非常影响迭代进度。一般的话，偶现的问题都会先放放或加埋点，必现且严重的就会腾出手来修复。虽然这个双月提出了清零计划，但看目前的进程来看，很难按计划行事。
任务进度表只是在前期刚开始的时候大家会维护，后面就形同虚设了，除了我们组自己会更新状态，客户端也会更新一点，服务端基本不更新。测试组的进度也不会在此反映。这个表的用途就变成功能分割后的展示了。
