产品需求文档作为我们工作的重要输出内容，一定要做好。我们工作做好了，开发如果没做好，这也就不是我们的责任了。
A.需求文档质量：
需求文档质量相当大程度上决定了开发质量。 你写什么他们就会做什么，有缺漏的他们也不会去改去补充。”，当然大部分开发还是很负责的。
1.字段、概念定义清楚：需求文档中涉及到的每一个字段或者名词定义，都要有解释，或者字段所有情况列举出来。 2.逻辑：所有涉及逻辑的部分，通过流程图+举例来说明，并通过文字再进行描述；这样能够保障我们自己不会缺漏逻辑， 开发中也不会漏逻辑； 3.交互细节：对于特定的交互样式也要描绘清楚，每一个按钮点击时会怎样，点击后会怎样，点击后的数据是怎么保存的。 都需要描述清楚。 记得之前听同事讲的笑话，需求文档中写着“点击保存后关闭弹框”，而开发实际开发出来后，确实是点击保存后弹框关闭。 但是表单中的字段居然没有做保存。开发说文档上写着点击保存关闭弹框。是不是很无语，当然，这里也有开发的问题。 4.标黄加粗可能出问题的点：对于一些明显可能出现问题的地方，一定要标黄加粗，并在PRD评审的时候重点讲述。 好的文档，开发在拿到后能够快速的书写ERD并开发；而不好的文档可能开发需要更多的时间去研究或者不断的询问产品经理，中间会浪费许多开发的时间，结果是实际开发时间进一步压缩。 产品需求文档作为我们工作的重要输出内容，一定要做好。我们工作做好了，开发如果没做好，这也就不是我们的责任了。
B开发进度跟进：
进入实际开发后，还需要我们不断跟进。
1.跟进开发问题：开发中，肯定还会有一定的问题或者开发无法实现的问题要解决。这时我们要第一优先级处理开发问题， 保障开发的问题能够第一时间得到解决； 2.开发进度跟进：每天或定期跟进当前开发进度，知道目前开发到哪个模块，哪些需求开发了，哪些需求没开发。了解开发进度， 一旦遇到风险点能够及时调整，保证如期完成。对于较大风险点及时上报自己老板，让老板来做重要决策。 3.开发内容跟进：开发中，我们每天可以找开发花五分钟看看做的效果，有没有和实际需求有严重不相符的， 没有的话就继续，有问题就及时和开发沟通，严重的话就要及时上报； 进度跟进不仅仅是保证项目能够按期上线，还是为了能够发现问题并尽快解决问题。 这样许多产品问题在上线前都能够被提早解决。
C跨团队协作信息同步：
对于产品开发中涉及到的跨团队协作，瑞叔这里就不提两个团队的进度问题。就谈一点：信息同步。 对于跨团队协作开发，最大的困难就是信息同步问题，往往产品上线出问题就是出在两个或多个团队间信息差上。 瑞叔此前带过一次需求，中间涉及到了3个团队开发。中间有一个需求变更，对于团队A来说，不需要任何改动， 只是需要确定要不要做就行，瑞叔当时决定后认为对团队B不会有影响，所以就没有通知B。 但是当上线前一天测试时，问题暴漏了，之前的需求变更对团队B造成了很大影响。以至于拉上两个团队leader来讲， 差点造成撕逼的严重后果。
D验收：
终于产品要验收了，验收是一个细致的活，需要我们做以下工作： 1.拉上业务方：让业务方来验收产品是否满足最初的需求，是否满足业务上的需求； 2.拉上UED：产品是否按照UED最初的设计来完成，交互细节是否都达到； 3.兼容性验收：这个也是测试的一部分吧，但也要在不同的测试机上进行一次验收，保证兼容性； 4.参照需求文档验收：我们这个时候拿出我们的PRD，对照最初我们设计的每一个逻辑、每一个字段进行验收， 尤其是我们最初标黄加粗的部分； 5.像素级验收：每一个线条每一张图片，都要认真验收是否对其、是否被遮盖等，细致到每一个像素级别， 错位一个像素都不可以； 验收工作中，一定要手拿小本和笔，有一个问题记录一个问题，全部记录下来，然后找开发一一调整， 直到全部调整好后才能够完成最后的验收，否则不予通过。
网友评论