产品实战记第期预估工期不能想当然每个里程碑都是经

　　在产品的规划阶段会遇到很多不确定性的问题，并不是每个问题都需要当即决定，马上给出反馈；其中一个就是工期的预估，也就是每个里程碑的设定。在产品研发中最常碰到的问题就是工期拖延，简直可以说是无解的。
　　不论什么样的项目，不论考虑得多周全，不论准备得多充分 ，项目总会延期，少则一两周，多则大半年。工期预估无法准确的原因有很多，多到有时甚至可媲美需求的庞乱纷杂。
　　必要的里程碑
　　我们先捋顺一下作为产品工期中必要节点的里程碑有哪些。
　　1. 产品需求文档初稿
　　也就是PRD的初稿，根据产品的规模大小，有写一两天的，也有写十来天的。初稿可以简略，说明白大概的情况，以便后续开工，等其他工作开始后再陆续补充完善也是来得及的。但PRD初稿必须跟UED组长、技术组长都商议过过才算确定，如果大家不能得到大体认同，工作也是无法正常开展的。
　　2. UED组
　　这里包括美工、界面、交互，美工做的是图片及重点页面效果图，界面主要负责所有页面、弹出框等等所需图片的标注、切图等，交互确定动作、页面之间的跳转、刷新、删除等模式，UED组长确定整个产品的用户体验各方面的定义和效果。在这个阶段会出现反复比稿，细节调整等大量消磨时间且并无具体输出的工作。
　　3. 开发是一个难以具象化描述的工作
　　我们经常看到的页面后面其实是庞大的开发工作，并不是只有前端的页面开发和功能开发。有些软件在搭建平台、平台开发、后台开发上需要的时间和工作量远远超过前端开发。使用软件的一点点开发工作量只是冰山露出水面的那部分。这里若只是自己公司的工作还算容易把控，如果需要对接其他公司的平台，调用第三方也就是他人平台的数据或用户账号（如付款、交友等），那也是一个漫长的对接和调试的过程。
　　4. 联调与测试是耗尽心力耗费时间的必经之路
　　如果联调不通，测试不过，产品上线后用户可能遇到千奇百怪的各种无法使用的问题，偷懒这一步往往会造成商用后技术不停地修改，甚至无法开展下一个升级的工期。具有前后端的产品必须联调，上线前必须得测试。一方面是产品验收的标准，合格与不合格并不是一两句话就概括的，需要多次且完整的测试报告；另一方面也是保证用户使用体验的根本，很多原因会造成用户流失，新版本不好用BUG过多是一个占比较大的因素。
　　不稳定因素
　　每道工序中造成时间不确定的因素有哪些。
　　1. 产品需求文档
　　产品经理没想好功能，功能无法形成闭环用起来逻辑不通。产品经理脱离技术、UED现有实力设计产品。想好的功能不被认可，技术团队认为产品经理的想法太过异想天开，现阶段网络技术无法达到。
　　2. UED小组
　　效果图页面比稿阶段所有候选方案都不合格，必须重来一遍。页面风格确认时间过长，每个修改都要等待高层领导同意才能落实。一个软件的所有页面规则不统一，切图不全、标注不全。UED小组内部意见不统一时，产品经理不敢担责任不肯下决定。这种UED的噩梦会造成时间无限延期。
　　3. 开发前强迫缩短时间，开发中随意更改需求，开发结束时要求返工
　　经常听到的话往往是：
　　＂领导要求在XXX前必须完成。＂
　　＂这些功能大不了不要了。＂
　　＂能多快就多快，不行就加班。＂
　　＂大家加个班把这个问题解决掉。＂
　　＂不论发生什么情况这个月一定要完成。＂
　　要知道开发是一个合作性工作，且每个人的每个工作并不是加班就能搞定的，不要把开发真的想成搬砖工人或小说家，并不是只要不停码代码就能完成任务，其中很多方案、逻辑、实验都是需要开发不断探索的。牵一发而动全身的事情时常发生，比如添加或删除一个功能，开发要把所有相关的功能代码都审核一遍，还得跑通，确保不产生连带影响。这些工作量不像写一篇文章时删掉一句话那么简单。
　　4.联调和测试要不停地重复使用，不停滴挑错找毛病，不停地叫技术去改。
　　不合格就是不能过，这是一个不能讲情理的工作。简单的测试就是所有按钮都点一遍，这是最基本的，复杂一点是所有按键在不同终端上都点一遍，之后是所有不同网络状态下，所有按钮点一遍，接下来是所有按钮不停连续点，直到点出异常状态。不停切换账号在极端情况下进行测试。每个测试通过或不通过，所用状态、终端型号等都需要有记载。每个功能都有响应的级别，一般情况下A级BUG是不允许出现的，B、C级BUG允许少量出现，D级BUG要看具体情况。如果开发偷工减料，所有的省掉的工时会在这个阶段全部找回来，并让所有人纠结得一塌糊涂。
　　工期不能靠蒙，但为什么光凭经验也不好使呢？
　　1. 每个项目的成员都不同，每个成员的水平也都不一样。在相同功能需求时，碰到高手工期自然缩短，碰到初级的必然会加时，这点不单单指开发，包括其中任何一个环节的参与者。退一步讲，就算把每个人的水平都看成一致的，参与项目的人数也不同。
　　2. 合作是需要长时间磨合的，所有不和谐因素都是时间杀手。一个团队的效率不仅在于成员水平，还在于每个人的合作融洽度，虽说产品可以比作是流水线工作，但与流水线不同的是每个人的工作与他人都必须有接触，工序的衔接是靠人而非机器。矛盾冲突是必然会发生的，就事论事是求同存异将工序推进下去的关键。
　　3. 领导每次的需求不一样，反馈时的角度也不一样。虽说产品经理决定产品形态，用户使用决定产品使用，但不可避免决定产品方方面面的还是领导，各级领导的需求从大到小，从功能到设计无所不包，这些需求都在随时影响着全流程的工期进度。
　　产品经理对工期的预估一定要跟UED、开发、测试都一一核对过，才能判定各个里程碑的大概时间，根据进度的发展再不断即时调整，万不能只是当个甩手掌柜，切不可按照自己想法估算时间后就等验收时候再怨天尤人。