项目（6）——医疗设备的维护单开发教训反思

项目需求说明: 
医院方有7栋医技大楼，2000多号员工，他们的设备和各种设施肯定在使用的时候容易出问题。而他们将自己的设施出现的问题委托给了一个维修公司，进行专门的维修，而维修和保养的时候，需要进行记录和保养。保养的时候需要记录。后端框架是fastadmin + 前端需要小程序能遥控。该项目难点是没有需求文档，只有一个外行的描述需要，需要将其转化成脑图，再根据脑图核对需求，然后搞简单的原型图，将项目做出来。

需求比较模糊，注定开发的时候是比较麻烦的。这是一个很典型的开发场景，项目本身不复杂，关键点事需求方只能大致罗列出自己想要的功能，然后需要开发者自己整理，缺少一个产品过度，不过其实就算有产品也不一定能梳理，需求者不一定能描述清楚自己需要的东西。

项目的难点:（所有外行开发通用性的难点，就是产品需求的不明确）
需求描述的模糊性，需要转换成项目系统。最终沟通简化勉强符合的流程:, 以不同科室为单位 作为前端登录账号（开始想的是给每个医生都分配一个账号，但是存在一个巨大的问题，A医生报修该设备的一个问题，B医生又报修该设备的另外一个问题，我们到底判断其是一个问题还是俩个问题，收单的人分派任务的时候是分派几个人任务，这导致分任务的人的，非常难以将单子派发给维修人员），而以科室为单位报修，同时限定一个科室在未解决单子前，不允许再发第二个单子，但是其实也有很多问题，比如想要同时报修俩个东西，没法报，而如果允许报修俩个东西，科室内公用的账号直接导致可能一个问题反复报，后台管理员接到请求，将同一个问题分配给俩个师傅。

后台管理权限，后台要录入各种维修的器材，但是器材本身在仓库的，而仓库的器材管理并不仅仅是派单师傅在使用。这直接导致我们本来只是做个简单医院的设备管理报修，方便医院和维修厂的结算，现在变成要开发一套维修厂的内部库存管理系统。显然出资方，医院肯定是不干的，库存与医院本身没什么关系，医院只是想记录自己的使用器材，直接使用的时候，做数据统计就行。最后我们商量的结果是只统计维修部分的器件损耗。

第三对接的仓库管理员，极度反感操作复杂的电脑后台，她本身是仓库的管理员，然后也是平台派单人员，也是公司的行政之类的，导致她非常不愿意操作电脑，觉得实在太复杂了。最头痛的事情就是如此，她就是嘴巴说下要的东西，但是本身又非常外行，然后没办法，给她开个手机端管理员，也就是前端登录了维修师傅端还有医院科室端，她作为管理员也必须登录到前端系统，而且要尽量的简单化操作。

第四，需要将各种纸质的维修说明和维修合同一份一份的录入到平台，定期维修的和检查。但是又觉得平台合同不方便看。

其他各种问题也跟预料中一样，基本商量半天，到最后给的回答就是，这块我不懂，你们是技术，比我懂，实现了就行，反正大体是这样。而对付这种客户，你要先实现一个最简单的样板，然后她用着用着再来改。非常熟悉的客户属性，也就是普通的客户根本没有完整的描述自己的需求，需要实现出来，使用的时候，反复给你提方案，而这种订单，往往是很容易导致开发严重超期的。

技术层面:
选用了fastadmin ，之前使用的是公司内部自研的框架，但是功能确实差fastadmin一截，所以决定使用自动生成来完成这个简单的技术。
我之前没使用过fastadmin开发项目，在这个项目里面正式使用。

所以需要理解这套框架带来的优势:
1.按照指定方式设计数据表后，可以一键CURD，也可以通关关联，将其他表的数据关联到前端显示。后台有插件支持可视化CURD，大幅度减轻传统方式里面简单开发，需要反复重复开发的事情。对于这种频繁变更，但是项目预算有限，而且还需要一个还可以的后台的，fastadmin在这方面控制的挺到位。
2.小程序和服务器端的交互，存在不同科室的人使用同一个账号问题，所以其实小程序不能锁定微信，只需要账号密码可以登录，所以后台需要生成这些科室的相关管理数据表。
3.需要掌握小程序的相关开发语法，也就是在没有UI的情况下，自己构建简单的前端请求页面。由于对UI要求不高，基本都忽略设计。

项目后来的总结，果然不出意料的意料，交付第一个版本很快，但是需求方药进行大改，没办法，拿回来重修进行修改。总结就是没有产品定义或者需求文档的项目，是不值得做的，特别是全部靠嘴巴聊简单的需求，最后反复让你修改。

最后工期实在没办法，硬生生的将估计半个月搞完的项目，三个月后才勉强交付他们的开始需求。最后回头看，显然这个单亏本了。还好只是中途反复改，并不是一一直在开发，开始报价周就是半个月，后面其实算下前后端花费时间，计算招工成本，先按就是亏损的。

所有项目之前，需要有完整的项目相关需求，使用产品画图工具很重要。