项目执行过程中，为了准确的了解项目进度，识别项目风险，项目经理需要清楚地知道团队每天的具体任务是什么，以及每天完成情况如何。而这件听起来简单，实际执行时仍然会遇到诸多问题。
项目经理在向项目成员了解进度时，经常会收到这样的回应：
PM：FE（前端），今天详情页开发完成了吗？FE：弄完了PM：Good，兄弟辛苦了第二天上午前端FE和后端BE在群里发生这样的对话：FE：BE，你给我的“金额”是没计算过的，你计算好了再给我吧。BE：啊，这个计算量不大，你在前端计算一下就行………………讨论了10分钟，决定后端计算好后再返回………………BE：PM再讲一下计算逻辑PM：WTF，金额不是详情页需要展现的一个数据吗，难道昨天还没做完！（接下来用10分钟介绍计算逻辑）BE：估计实现这部分计算逻辑还需要半天时间！PM：WTF，意味着详情页昨天没做完，今天至少需要半天时间，中间要再出点问题，得再花一整天时间。
从上面的对话来看，
前端程序员在汇报进度状态时，存在报喜不报忧的情况，“问题”理应在前一天的开发过程中暴露出来；PM没有验证进度状态的准确性。后置任务的时间计划受到影响，进而导致里程碑有delay的风险。
问题
项目经理如何了解准确的项目进度状态？
解决办法
项目经理应提高与程序员的沟通频次，至少每人每天2次，并更新在干系人沟通计划中。
如每天结束时才问当天的任务的进度状态，要么会遇到“报喜不报忧”的待遇，要么会“喜获”一枚炸弹。存在小问题，程序员有可能报喜不报忧，因为会被要求加班弥补，谁也不想平添加班的风险，在程序员看来，第二天花点时间补上影响也不大；为什么有时候会有炸弹报出来，就是存在大问题，程序员不得不提出来，由PM来协调解决。
项目经理在向程序员询问进度时，问题需要分解得更细。
比如，前面对话的场景里，PM问的第一个问题就比较粗。可以把详情页的前端开发任务至少可以分解成详情页UI的实现，页面逻辑的实现，接口联调3项任务。如果页面比较复杂，被明确分成了4个部分，如summary，费用，基础信息，操作日志。理论上，每个部分都有UI实现，页面逻辑实现，接口联调3项任务，合计可以分解为4*3=12项任务。PM需要就12项任务one-by-one地确认完成状态。
如条件允许，应要求团队每天下班前在测试环境发布一版，确保完成情况可以看得见。
毕竟，正常发布也就5分钟的事。项目经理可以每天晚上花时间验证完成情况，发现问题及时更新在任务清单中，排期解决；识别出风险，更新在风险登记册，并制定应对措施。
项目经理在项目执行过程中，最重要的任务就是识别风险。而不能了解准确的项目进度本身就是1个风险，需要及时制定风险应对措施。
