为什么拓扑图项目的进度管理做得这么烂

内部需求的需求文档至关重要。

拓扑可视化平台这个项目的进度让我很不满意，比预期的时间整整多了三天。究其原因，在于我的项目管理做得太烂了，基本上没有什么规划可言。

没有需求文档

由于这个项目是别人提的需求，只是简单描述了下，我自己这边也没有去对需求做文档上的细化，只是用 xmind 大致拆分了下功能，导致的结果就是很多细节没考虑到，功能点越做越多，进度评估失控。

这让我在跟其他同事(特别是新同事)沟通的时候，效率非常低，很多交互上的细节，我以为对方懂了，其实对方是没有明白的，结果到了后面发现有很多功能我以为他们会做，其实并没有做。

就像昨天，本来以为可以发布了，结果到了晚上和 CW 聊的时候，发现他还有很多概念和细节没理清楚，沟通起来很费劲。然后我花了大半个小时画了一个粗糙的交互图，给他们讲了一下，马上就非常清楚该做什么、还有哪些功能没做了。

一图胜千言，下次一定要先画好图，粗糙点也没关系。

这导致沟通起来成本很高。

比如这次的数据，就分为了作图数据和应用管理数据，这些都需要提前定义好名词，方便交流。

昨天画了交互图之后，今天还是进度失控了，原因在于没有详细列出需要哪些接口、每个接口需要什么权限控制。导致 CW 这边并未真正明确需求，到后面完全来不及做了。

我不进行具体的项目编码，那么我可以写单元测试，这是了解项目、把控进度的好办法。

这个词语是最近听 LXD 提到架构感知后，想出来的。需求分析也要像画架构图一样，画一个功能拆解的图，这样完成了多少、还剩多少，才能一眼看清楚。

需求文档->交互文档->方案设计->外部资源确认->编写测试用例文档（用于验收，很重要）->server 编写 router.ts->front 编写 devServer 配置->开发编码

#项目管理