一篇可能影响你职场发展的博文

      写在前面：做者工做三年多，一直从过后端开发，去年开始接手负责公司一个跨国物流解决方案中调度平台的小型开发团队，当前正与一位负责仓库管理系统的实施妹子在美国洛杉矶出差、到仓库一线了解业务及实际业务场景、解决现场问题及用户、客户需求收集，如下将对今天从排查一个业务问题的不一样态度开始阐述，自勉同时与你共享。

      事情描述：今天下午收到一封美国仓业务负责人关于出库单建立的一个问题邮件，收到邮件后，因为本人对调度系统的熟练度很高，很快便大概肯定了问题的范围与最大缘由发生的可能性（猜想缘由与我负责的调度系统无关，而是仓库操做人员在仓库系统中某项操做所致），此时我想再进一步排查一下下流系统，验证猜想是否正确，因而请教了美国分公司对该下游仓库系统相对熟悉的同事，然而她也并无找到我想要的一个移库记录跟踪，因而我便再也不继续往下排查了，直接回了仓库业务负责人的邮件，详详细细说明该问题与我负责的系统无关，并附上了两张截图及相应逻辑辅助，同时建议他去check仓库是否对某一商品进行了移库。相信不少与我同样作开发工做的同窗会认为这就能够了呀，问题排查了呀，若是你真的这样想了请继续往下看。

      我在发出邮件后的30秒内，和我一同出差的同事（很好的朋友）微信我：“为了让个人职场生涯更近一些，给我一个不成熟的建议”，因而咱们进了一个会议室开始交谈，她先是给我举了个例子，而后问：你认为你的回答解决问题了吗？你的问题抛出后Eric有时间有精力去仓库check吗？固然站在开发的角度，不少开发都是这么想也这么作的。最后她给我讲了她本身的例子，的确在正常工做中她是一个必定会把问题尽本身全部可能去解决的人。我这时才明白过来，我这样虽然是排查了问题，但结果并非业务方或者问题提出人真正想要的，虽然也无伤大雅但并不能让人放心把一个困难的事彻底放心交付给你，更况且我是调度系统的负责人。交谈时间大概3分钟，结束后我和她说：“谢谢你和我说这些，我承认你的见解”。真的很谢谢她。

      回到座位后我便询问了另一位和该下游系统接触比较多的美国同事，她和我大概讲了后，而后依然没有在该仓库系统中找到能够查看相应日志的地方，同时她手头事情比较多，因而便和我说要不你本身再找找，晚些帮我看，因而我便本身一个页面一个按钮的找。 10分钟后个人那位同时把邮件回复了，她找到仓库系统移库的记录并截图附在邮件中，同时加以说明的确是由于仓库内的移库致使订单出不了库，与调度中心无关，最后还建议仓库是否须要联系客户取消该订单。业务负责人后来给她回了邮件，Noted thanks！嗯，用的是感叹号！

      这件事让我认识到了自身一直存在的问题，把本身的份内工做、相应责任作好、尽到，其实咱们真的不该仅止步于此，我将下定决心改变，解决问题时，可以真正解决客户、业务的问题。

      本篇是一篇自勉篇，但但愿你也能有所收获，若是你看完还以为这是小问题，它便也正发生在你身上。