上周三领导找我谈话并发给了我一份PPT模板，里面的内容是IDP-Individual Develop Plan. 从需求分析工程师提升为高级需求工程师，我仍需提升的能力有哪些以及我该通过哪些途径来达成这些能力。在与领导初步沟通后，我需要在这周三也就是后天向领导提交PPT。沟通的时候我觉得问题不大，可在实际下笔的时候，我花了很久很久的时间去不知道该如何写起，甚至写着写着萌生出一股’怨气’：为什么其他人升职就不需要准备这个东西，难道他们就真的具备了高级的水平？为什么原本已经答应了的事情，现在却要弄个TAR(takearisk)？半年的考核期，这中间究竟该如何评估？这种心情就好像把自己放在别人的手心，什么时候把你放下来或者狠狠的摔下去，你完全不知道。即便同事们都说这只是个流程，但既然要提升和学习，就不能只是停留在口头上。我依然要感谢领导给这个机会，只是因为太在乎，所以患得患失的心情就会有些严重。
从积极的方面想，借助这个机会，如果可以逼自己多学点东西或者借此梳理下过往的工作经验，认真的总结一些有价值的东西，也未尝不是一件好事。通过过往的邮件记录以及本地保存的文档信息，对过去3年的工作做了梳理如下：2018/3至2018/10（6个月的试用期）参与EUIMS（Europe Inventory Management System）项目的测试，虽然自认为英文读写水平还不错，但是刚开始在对业务几乎一无所知甚至连药品品规是什么都要去查的情况下，再通过英文媒介（需求相关文档、技术文档以及一周2-3次的项目会议）去学习业务，就有点痛苦。一份30多页的需求文档，老同事直接丢给你让你先看，但是也没说下一步要干嘛。这份文档我要看多久，看完后要输出什么？总是担心自己的效率低，一份文档看两天会不会太久？但是时间太短，我确实又吸收不了。到了项目沟通会议上，听其他同事和欧洲的项目经理全程英文沟通需求，勉强听个差不多，但是领导直接来一句：Kathy，你有什么问题吗？只能尴尬的摇摇头。不是没问题，而是不太敢直接开口说，还有就是提了之后对方的回答担心听不懂。于是在刚开始的时候私下找到老板商量，有问题可不可以先内部沟通下，对于我这种业务还不太熟悉的，也许很多问题内部沟通时就可以解决了，这样可以减少和外部沟通时占用大家的时间。领导开始答应了，但由于他的会议比较多，另外一个高级需求分析师也不常常有空，所以偶尔在开会的时候就得硬着头皮去提问，提完问题心脏砰砰直跳……去年接手另一个欧洲项目IC（Inventory Connect）时，作为唯一的需求分析（另一位同事休了产假），领导忙于项目又很少参加会议，所有的需求都由我独立完成，同时手上还在同步做另一个国内的项目。这样的情况下，我还是顺利完成了两个项目的发布。现在想来，这中间的成长历程，也只有自己才最清楚。
产品为B/S架构，包含的主要模块有：Articles,StockLimitation,UserManagement,FMD,Confiruration。其他模块都还好，主要就是FMD这块内容。因为欧洲对药品有追溯到每一盒的强制要求，因此医院和药房急需一套软件系统来完成这个工作。软件的核心点也是难点就在于和欧洲药品防伪系统(Falsified Medicines Directive)的对接。由于国内没有相似的案例，最开始在理解这个概念上就花了不少时间。不同国家的中心系统也有所不同：英国使用的是NMVS(National Medicines VerificationSystem)，德国使用的是SecurPharm，爱尔兰使用的EMVS。半年多的时间，NMVS的接口更新了4个版本，每次他们更新，我们的系统就得重新测试一次。2018/10至2018/12，根据一线项目经理反馈，针对FMD从机器出药失败自动回收的需求，增加了ChangeRequest并在3个月内完成了一个hotfix(V1001)。2018/12至2019/01完成了软件安装程序的开发和测试（欧洲开发团队，国内测试团队）。项目通过LCR和GA后，根据产品经理反馈，正在运行的一家医院：1096条 Article master data, 44919 stored packages, 每天1200-1500 packages dispensed。这个数据和国内医院比，还是有比较大的差距，不过每个国家情况不同，这套软件在国外都是按功能模块收费的且价格不低，作为其中一员，还是蛮开心的。
2019年初，项目名称更改为FMD Verify并开始1.0.1.0的开发。在此次开发项目中，我协助另一位需求同事，完成了Product(VP,VPP,APP)和Storage Location两大模块的功能需求并向开发和测试人员进行需求讲解。为了帮助大家更好的理解需求，我使用了思维导图和原型工具帮助大家更好理解（另一位需求同事未采用过这些方式，主要以口述和笔画为主）。组内的成员基本上都是业务经验比我多很多的老同事，在需求讲解时，还是会有些紧张和忐忑的。虽然自己在私下里已经把思路理了很多遍，但在讲解的时候，同事还是会提出一些我之前没考虑到的问题。随着这样的会议越来越多，没考虑到的问题也是越来越少。对我而言，这也是成长点之一。2019/6至2019/10,团队临时接到一个新项目，做医院智能耗材柜的本地化以及仪表板系统。但是在对本地化做了1个多月的调研后，发现国外团队暂时无法提供及时的支持，便开始只专心做仪表板系统。4个月的时间，从需求调研开始到整理需求业务场景再到需求文档和原型输出，可以说是真正意义上独自负责并完成了一个项目，甚至这中间还有去联系软硬件合作商，协助项目经理对产品开发做成本估算。我认为这又是一次成长。
2020年初开始，配合部门战略，开始负责零售药房产品的需求工作。2020年3月到4月，创建了一个创新小组，由solution部门牵头，marketing, GCS,RD以及商务和销售多个部门配合进行前期调研。从RD负责的范围来说，软件层面可以参考现有的MDIS系统并根据需求做出调整，主要就是硬件供应商的选择以及硬件系统上客户端的开发工作。有了前面的经验铺垫，在这个项目中，作为独立的需求负责人，从5月份需求准备和前期多次讨论到6月份接洽实际客户：江苏润天，7月份便发布了V1010和V1011版本，适用于第一代硬件云屏。8月，二代硬件一体机制作完成并为了适用实际需求，增加线上支付功能，8月底在润天药房开业前顺利发布并获得多家媒体的报道。2020年9月至2021年1月，为了配合第3代硬件Pickup(支持自助取药，带有门开关)，软件更新了1030和1040两个版本。今年，最新一代的Pickup在广东佛山妇幼已开始使用。在完成RPDS(Retail Pharmacy Dispensing System) 产品过程中，同时还接手了Pyxis Inventory Connect项目的需求工作。除了前期需求对接工作外，8月到10月，共发布了IC V1001和V1002两个版本并在同事修完产假回来后顺利交还。
2021年初至现在则是一直在弄2代Dashboard需求和测试工作，这个在其他文章中都有提到，就不在这里继续赘述了。一路走来，这中间的辛苦和成长，真的只有自己最清楚。所以，我可以自信的对自己说：你值得这个Sr Requirement Enigneer的头衔