在晨会上，开发说出tower上产品（也就是我）提出的bug不太实际，他们认为优先级并不高，一些他们认为很紧要的bug，产品并没有列举出来。
师傅在晨会后跟我传授了一些人生经验：
产品应如何控制进度 & 什么叫汇报进度
进度应该如何去盯？
首先，你心里要非常清楚项目每天的变化，这个变化不是存在于开发一句今天的事情做完了
我做的不好的地方就在于，大部分时候我只会问开发一句做的怎么样，以为这就是进度控制
开发告诉我今天tower上的bug做完了，你验收一下，我一个个测试过去，就完事了
根本没有去思考，今天的任务完成了，完成到什么样的地步了呢？
- 聊天页开发完了也叫做完成
- 聊天页开发完，但在聊天记录多起来后，滑动屏幕会有卡顿，滑动到很久之前的历史记录，这个时候点击输入框会自动回到最新一条消息也叫做完成
两者之间，缺的是什么？
作为产品经理，我真的知悉每天项目发生了什么变化吗？
我真的能够在开会时，跟老大和师傅拍着胸脯讲明白，这周任务完成了吗？
......
像这种组织开发了解进度，并且安排好每天的事情，每天悉知目前到了什么阶段，本周目标能否达成（才是好的进度控制）
所以，按这个节奏来，（就算中间因为意外因素，导致进度延迟）其实项目的时间（也）不会延迟太多，因为你每天都在确认，项目能否顺利进行
一旦觉得不对了，比如今天，明显发现跟之前的预期差了很多，及时作调整
这段话我理解是进度控制的精髓
之前的三个月，项目几乎是我一个人在进行产品设计、进度跟踪、版本控制
在产品设计这一块，遇到自己拿不准的地方，我也从来不会去找师傅和老大讨论
最后的结果就是，要么就自己决定砍掉功能，要么就草率的选择了一种方案
直到开发拿着文档开发完毕，集体测试了，师傅问我，为什么这么做的时候，却回答不上来
每天早上到公司第一件事情，先确定项目进展，不明白的地方找开发问清楚，存在的问题、难点、影响的因素都归类好
等老大来了，跟他说清楚，现在项目是什么情况，然后我觉得这周如果我们的目标是xxxx的话，我建议我们哪些地方要做调整
然后，人员安排上，我希望xxx可以参与进来做xxxx
这方面，我只记得有一次，跟老大汇报进度的时候，我清晰的说明了下周的工作安排，老大听完之后难得夸我一次：哟，这么牛逼啊= =
做产品设计，做进度跟进，都要带着自己的思考去做
产品设计没有带着自己的思考去做，接下来的第二个坑我会写到我是如何不带自己的脑子去做产品设计的...
就算项目一直进展的很顺利，隔三差五地选择节点跟上级汇报也很重要
比如，老陈，到今天为止，我们某圈测试服和正式服应该就能正式打通了，明天可以进行更新发布，能留存用户数据了
一个好的产品经理，不要让上级来盯着你问，怎么样怎么样
这么做还有一个好处就是避责，现在你在小团队，对这件事情会无感知，如果未来你去了一个大团队，学会避责很重要，项目出现重大事故的时候都有事故处理方案，第一责任人风险很大的，如果你已经做到事无巨细地汇报，承担责任的就是你的老大
最初，我是真的没有汇报的意识，这导致了师傅和老大在很长一段时间里，很多次的告诉我，纠正我，佳瑞你要去跟我们汇报！
庆幸自己是在一个值得信赖的小团队，如果是在大团队里，像我这样早就被拿去背锅了
「在自己没有背负责任能力的时候，事无巨细，向上汇报，真的是一个必要的专业素养」
最后，总结这篇文章的内容就是
如何控制进度
每天组织开发了解进度，悉知项目到了什么阶段，确定（前天）本周目标能否达成
具体的做法就是：
每天到公司第一件事情，先确定项目进展，不明白的地方找开发问清楚，存在的问题、难点、影响的因素都归类好
然后安排开发当天的开发任务和自己的产品工作
什么叫汇报进度
现在项目是什么情况，这周如果我们的目标是xxxx的话，我建议我们哪些地方要做调整
（然后，人员安排上，我希望xxx可以参与进来做xxxx）
ps：
希望在未来的工作中，自己能够谨记踩过的每一个坑，让它们成为自己的养分，而不是没有一丝痕迹
