一.进度问题：
1.由于沟通和理解的问题，我这边传递了错误的信息给产品经理。将自测时间（周五）传递给了他，他认为是“提测”时间。
于是在接下来按我的进度走，慢了产品进度三天左右。
2.开发这个功能在保存逻辑那里是最大的问题。我对公司业务的掌握不够深入，对“保存”的代码不够熟悉，导致严重拖慢了工作进度。
3.开发时间安排不合理。面对这样一个涉及业务（业务还不熟悉），还有大量验证逻辑的功能，正常开发时间加自测应该在7天左右，而“提测时间”
需要2-3天。
二.个人问题：
1.开发流程的问题。应该将功能拆分后，做完一块和前端测试一块，保证问题的出现不会累计到最后集中爆发，从而导致排查问题，从头调到尾，浪费了
大量的时间。
2.排查问题的方式。下载功能出了问题，报500，我首先想到的是后台代码的问题，通过log,定位到类强制转换异常（实际不是），是前端拼接请求方式的问题。
排查问题不够仔细，没有按正常的流程来。应该先从“源头”排查，即“接口”开始，而不是盲目的找后台问题，事实上，不看前端访问路径，只看后台是永远找不出问题的。
3.避免重复造轮子。对于不熟悉的业务，“代码”要及时请教，避免走弯路。还有系统中“旧的”方法实际上是经过之前测试的，相对可靠，应该避免重复造轮子。
这样可以节约很多时间，对于这种问题，我们每个人应该有这个习惯:首先想“有没有现成的？”。如果有现成的直接拿来用，这样不但可以复用代码，还能避免bug的引入。
如果一就开始阅读“创建手工单”的代码，可能就可以避免自己创建代码，然后引入各种bug.
三.沟通问题。
1.需求评审。在开发前期应该整理好各自的问题和开发所需的资料，避免在后期开发的过程中来回跑。虽然交流避免，因为问题可能会在开发进行中暴露出来，还有需求也有可能会变。
但是还是要尽量在评审的时候问深入一点。
2.交流的方式。交流要有重点，要观点鲜明，要有耐心，尽量使用平和的口吻，避免导致双方情绪化，不利于问题的解决。
3.人人都是owner。每个人都是“参与者”，而不是“旁观者”。问题要“到我为止”，发现问题及时汇报，及时交流，及时解决。对于两种观点的碰撞，
要做到“观点鲜明”，“不妥协”，“PK淘汰”，在说服对方的基础上淘汰对方观点最终达成一致意见。
1.由于沟通和理解的问题，我这边传递了错误的信息给产品经理。将自测时间（周五）传递给了他，他认为是“提测”时间。
于是在接下来按我的进度走，慢了产品进度三天左右。
2.开发这个功能在保存逻辑那里是最大的问题。我对公司业务的掌握不够深入，对“保存”的代码不够熟悉，导致严重拖慢了工作进度。
3.开发时间安排不合理。面对这样一个涉及业务（业务还不熟悉），还有大量验证逻辑的功能，正常开发时间加自测应该在7天左右，而“提测时间”
需要2-3天。
二.个人问题：
1.开发流程的问题。应该将功能拆分后，做完一块和前端测试一块，保证问题的出现不会累计到最后集中爆发，从而导致排查问题，从头调到尾，浪费了
大量的时间。
2.排查问题的方式。下载功能出了问题，报500，我首先想到的是后台代码的问题，通过log,定位到类强制转换异常（实际不是），是前端拼接请求方式的问题。
排查问题不够仔细，没有按正常的流程来。应该先从“源头”排查，即“接口”开始，而不是盲目的找后台问题，事实上，不看前端访问路径，只看后台是永远找不出问题的。
3.避免重复造轮子。对于不熟悉的业务，“代码”要及时请教，避免走弯路。还有系统中“旧的”方法实际上是经过之前测试的，相对可靠，应该避免重复造轮子。
这样可以节约很多时间，对于这种问题，我们每个人应该有这个习惯:首先想“有没有现成的？”。如果有现成的直接拿来用，这样不但可以复用代码，还能避免bug的引入。
如果一就开始阅读“创建手工单”的代码，可能就可以避免自己创建代码，然后引入各种bug.
三.沟通问题。
1.需求评审。在开发前期应该整理好各自的问题和开发所需的资料，避免在后期开发的过程中来回跑。虽然交流避免，因为问题可能会在开发进行中暴露出来，还有需求也有可能会变。
但是还是要尽量在评审的时候问深入一点。
2.交流的方式。交流要有重点，要观点鲜明，要有耐心，尽量使用平和的口吻，避免导致双方情绪化，不利于问题的解决。
3.人人都是owner。每个人都是“参与者”，而不是“旁观者”。问题要“到我为止”，发现问题及时汇报，及时交流，及时解决。对于两种观点的碰撞，
要做到“观点鲜明”，“不妥协”，“PK淘汰”，在说服对方的基础上淘汰对方观点最终达成一致意见。