一个项目需求讲到多少遍才能被大家理解。

我原以为这个次数应该是三次，第一遍是让对方有个轮廓印象，知道要做什么。

第二遍在讲是为了让彼此知道需求背后的流程和细节，这个过程也是在审视需求的合理与不合理的地方。

第三遍是技术准备动工之前，双方对功能实现路径组织讨论，为的是确保可实施可执行。

不过最近有一个项目需求讨论了很多遍，跟技术团队很多人都讲了三遍以上，最后发现不止一次还要跟具体开发人员再讲一次。

于是，我发现自己这是在浪费时间在重复做一件事，不断的介绍一个项目需求，讲给同一个人，讲给不同的人。

而当每次有人问新的问题时，却又发现一些之前没有考虑到的地方，等于衍生出新的需求，一个需求背后又多了一些隐藏的需求。有种看到了一座冰山，而实际来到近前，才发现冰山下面的部分更加庞大。

需求管理是一门艺术，也是一个反复沟通的过程。

于是，这几天在技术的要求下，我开始踏上了画图之旅，画了三张流程图，然后又为它们配上逻辑判断文档。

后来又整理了一份又一份需求文档。按理说，这些文档材料都是开发所必须的。

不过，我却也发现一个问题，就是我和开发团队之间的边界在哪里呢？

我应该负责的是需求管理，可是逐步已经渗透到了开发功能逻辑，从表面的业务需求已经深入到数据表和字段，以及它们之间的关系。

我察觉到自己可能越界了，跨界指挥，工作内容超出了职业范围。

那么为什么会分不清自己的边界呢？

以前我也很少干涉具体技术开发细节的，把需求讲清楚，给一个负责技术的产品经理讲明白，他有问题我们再进一步沟通。等于是我只要抓住一个人，他去给技术出文档出规则。而如今，这个角色的人短期内空缺了，于是就出现了一个需求跟团队几乎每个人反复介绍，工作看似扁平化了，技术随时有问题随时来找我，而我也从技术外围被卷进了技术的中心。

每天有一半时间是在回答技术的问题，问题有需求逻辑的，有功能怎么做的，有字段存哪里的，也有跟我讨论实现技术判断流程的。

我一个技术外行与技术专家讨论着大大小小的功能细节，我内心没有多少激动，相反是如履薄冰，我一个人对接一个团队，我讲的需求他们不容易理解，而他们能理解的我又搞不懂。因为技术人员的语言要么是逻辑流程，要么是算法，要么是表和字段的关联。很遗憾，这三个方便都不是我擅长的，我努力把逻辑流程讲清楚，讲不清楚就画流程图，为此再次安装VISO，画完再补充文档。有图有字，互为补充。

这个过程我也发现，从最初接到业务需求开始，这个需求就是比较模糊的，无论他提的多么具体，其实都不是清晰的需求。提出人能把自己想要什么说清楚就是很优秀的，多数人是没有想明白自己要什么，就直接提了一个自认为很合理的需求。需求梳理后，距离把需求转为技术可理解的需求还有好几步路。

第一步，需求对应功能是什么，是现有的还是新增的？

第二步，需求文档有没有，里面的取数规则是什么，完整流程是什么，展现规则是什么，存储规则呢？

第三步，什么功能可以满足需求，这个功能要做什么开发呢？开发的字段有什么，存在哪个表？是否有限制和检验，如何保证唯一性，如何保证录入规范性。

第四步，需求的预计排期和优先级，什么时间要交付，优先级是什么？哪个最重要？

第五步，给相关开发讲解需求和功能设计。

有了这五步，一个需求才算是可以落地开发了，这就好比是我们一直说想买辆车，也去看了很多车，但是如果不加入具体诉求，使用场景，性能要求，资金限制，是否有替代方案，时间期限，优先级等，那么可能一直在到处看车，不知道买什么，销售人员也不知道如何向你推荐。

只是买一辆车，这不是可落地的需求。

买一辆什么车，一手还是二手，代步还是跑车，越野还是货车，这个车用来做什么，是否要考虑油耗和动力，能源是电动还是油动还是油电混，品牌预期，价位预期，买给谁，什么场景开车。这些都想明白了才能在有限范围内选择，找到自己想要的汽车。

而有的人提需求可能是我要买一辆二手车，上下班代步用，最好的是大牌子。这样的需求看似具体，但是没有明确价位、性能、油耗、二手车公里数、是否汽车大修过等等。所以需求不明确还是不能支持做出准确选择。

做需求一方面要挖掘需求和场景，考虑整体流程和细节，另一方面也玩考虑限制条件，比如时间、金钱、性价比、指向性等。

明确需求后，应该继续参与方案设计，目的也是推动需求转为可执行的具体行动计划，沟通团队对接人或者负责人，确保大家在需求开发上达成共识，方向和理解在一个水平线上。