新的工作做到今天有两个月有余了。如果要给之前的工作做一个总的自我评价，我觉至少是及格的，至少最终能够在预定的时间拿出一个像样的东西来，能够有一个关于产品如何去做的比较清晰地思路了。个人能在原型设计，前端开发，数据库设计等方面也得到了体现，最重要的一点在于能够通过不断思考产品如何去做，让原本模糊的东西变得清晰起来。
但是来到第二个阶段，突然觉得自己遇到了瓶颈。主要的问题有两个方面，
第一个问题是关于事情本身。之前产品的工作更多停留在宏观层面，包括概念的明确，大体逻辑地梳理，UI风格的设计，试图搞明白做什么？这个阶段成果是有，但是存在很多隐患，一方面太抽象不具体，很多东西没有想细也没有办法想细，另外跟其他产品线以及技术部门沟通不足，这带来的问题是设计的合理性，是否能够最大限度复用已有成果？是否在存在现阶段技术能力无法实现的功能？如果所有的设计对原有系统进行了颠覆或者技术难度太大，带来的不光是工作量的问题，还有人的思想态度问题，大家会问这个事情是否靠谱？这些问题被隐藏在产品光鲜的外壳下，而我心理很清楚，不能够在设计层面解决复用难题，产品化永远只是只是一个漂亮的口号。
第二个问题是关于人的问题。人的问题牵扯的最大问题是产品与原有产品的整合。领导建议我直接授责于原有的产品相关人负责灾害风险部分核心功能的开发，个人认为这是没有问题的，灾害风险洞察一定是要站外原有气象预报和灾害风险成果基础上，再增加没有的遥感应用、GIS应用等技术进行整合创新。
与原有系统衔接一方面是数据的衔接，比对原有系统数据中哪些能够满足当前设计的要求，不能满足需要评估是否能够补充，因此现有系统对数据结构的定义不能脱离原有数据结构，因此这个环节最重要的一项工作是明确原有系统地数据库设计和文档存储设计，然后通过对此，增加需要补充的字段和文档目录。原有模型运行后成果入库，现有系统增加接口工程提取数据返回前端，这是核心的思路。数据衔接解决产品可用问题。
与原有系统地第二个衔接是技术衔接。技术衔接应该是对数据衔接的补充，解决一些具体场景的要求，比如预警的实时推送，需要后端模型增加异步消息机制，绕开数据库直接与前端对接，当然除非特别有必要，尽量避免这类技术的衔接。技术衔接更多解决产品体验问题。
与原有系统对接的第三个衔接是人员衔接。人员衔接其实是最不可控的因素，原有团队人员有自身项目任务，而且很多是多年老员工，给他下达具体任务，需要非常明确具体做什么？做成什么样？什么时间完工？当然也需要考虑他们实际工作安排，所以需要他们有明确投入计划。最重要想清楚需要他们做什么？通过沟通搞清楚他们能做什么？结合我们要做的事情明确他们具体参与的工作。
还有一个很重要的问题是个人精力投入选择。前面做了不少前端开发，一方面是因为人手问题迫不得已，另外也是想要通过参与开发熟悉一些技术特性，以便后续人员和技术选择更加合理。但是第二个阶段，我的重点应该是思考如何串联整合系统，如何适应多个项目。因此，前端开发需要专人来优化。这个人员招聘需要尽快落实了。
