项目回顾

恰逢年中，项目任务稍显减少，遂有空记录去年的一个项目经验。以供后续参考。

项目背景：这个项目前期，是由商务和甲方接洽谈下来的合同，相当于闭口合同，对于需求这一块可以说是一个纲领性的，完全没有具体的需求说明书，这个项目是一个我们以前完全没有接触过的项目，是一个完全陌生的领域。也是公司战略上打开新的领域的牵头项目。由于甲方在前期规划项目的时候，花了很多时间，最后交给我们的时间，只剩下了不到6个月。同时我们了解到这个项目是一个帮助甲方对其老旧平台进行数字化的一个项目，甲方还要求信息的保密性以及操作的便捷性。由于是在甲方的目前平台上进行数字化，需要借助甲方目前正在使用的平台，但是由于甲方的资源有限，只给了我们一台装有他们平台的电脑来进行使用，所以这就意味着我们只能用有限的人员在他们有限的资源上进行开发。由于他们平台的限制，每天早晨7点到晚上11点半这一段时间系统可用，其他时间系统不可用。那么这一套总结下来，可以说是需求不明确，时间紧，任务重，风险大，战略位置重要。

项目初期：一个项目的开展，首先是需求。我们和甲方进行了多轮的会议，包括他们负责这个项目的领导，还有专门的资源管理者，以及使用他们目前平台的员工。详细的询问了他们对于这个平台目前使用的流程，以及他们对于数字化平台的需求，但是会议中发现，由于他们公司人员的变动，目前使用这个这个平台的员工对于他们的平台并不是很了解，只是会初步的使用，对于这一块，我们决定使用混合式开发，前期进行敏捷式开发，后期进行瀑布式开发，这样可以最大程度避免需求的不明确，等后期需求基本明确了，再进行瀑布式的开发。受制于甲方的平台所限制，开发人员只能在有限的时间进行开发，我们了解到他们上午对于平台的使用率比较高，所以我们决定调节我们上班时间，在下午和晚上进行开发，上午休息，这样就了很大程度避开了甲方和我们的平台使用冲突。同时，在安全上，我们在他们本地创建数据库，并且采用加密存储的方式，所有数据保存到他们公司的服务器，在项目上线后，我们不参与他们数据的操作。支持他们通过抓包等一切技术手段检测数据流向。 项目进行：项目开始后才知道我们的准备完全不够，首先就是沟通问题。当我们细化需求的时候，我们详细的询问甲方平台的使用者，他们有的人对于目前平台的看法是这样的，有的是那样的，非常杂乱无章。其次是他们对进度非常关注，经常询问进度，但是他们对于项目所用资源的配置却非常缓慢，然后是我们的测试机甲方经常使用，这就导致了我们的开发时间更加的紧迫。最后就是我们是在自己公司办公，而甲方的测试机是在甲方那边，只能远程连接。导致操作起来非常不顺畅。总结以上问题，首先我们建立了一个沟通流程，确认甲方的具体负责人，如果有问题我们可以及时找负责人协调。其次我们通过负责人来协调甲方领导来对接协调资源。然后我们开会研究决定驻场办公，我们驻场以后，甲方给我们安排了专门的办公室，测试机器只允许我们自己使用。上面我已经提到，这个项目是一个陌生的领域，使用的编程语言也是全新的一种语言，很多人还对这门语言不熟悉而且这个项目中我们采取的是中午到晚上上班的模式，这就导致很多人生物钟打乱了，刚开始的那一段时间非常难熬，由于是驻场开发，甲方也看到了我们的努力，给予了很大的支持。好在我们坚持了下来，并且总结出一套可行的方法。进度上我们采用了每日站会的方式，每天上班来，总结昨天的问题，规划当天的任务，并记录遇到的问题。在风险方面，我们在每日站会上回顾以前的风险，删除过时的风险，规划未来可能的风险，制定并记录风险的应对措施。同时把风险分层，分别给各层级风险制定合适的负责人。在各阶段关口，我们会进行阶段总结，并在公司公众号上发表总结文章。

项目交付： 交付阶段，我们总结了项目的文档，用过了严格的验收测试。但是我们把试用版发给客户，但是反馈很差，为了发现问题，我们深入一线，充当一线使用人员。发现很多的一线使用人员对于如何使用系统并不清楚。针对此问题，我们召集了所有相关方，详细讲解了使用方法和注意事项，通过我们的讲解，一线使用人员使用反馈还不错。至此第一版顺利上线运行。由于我们在文档总结方面非常完善，这个项目还在团队内被设为模范项目。

新版：在开发完第一版以后，大家已经很累了，我们也回到了自己公司，打算正好利用这些时间休息一下，当然中间也在不断收集以及回答客户使用过程中的一些问题。一开始使用的反馈还好，后来忽然有一天，客户反馈我们开发出来的产品不能运行了。这无异是给我们破了一盆冷水，从头凉到脚。我们马上开会，经过讨论，团队决定去甲方查看原因。现场查看日志发现，是甲方很少用的一种格式这次突然出现了，导致整个平台不兼容，而以前从来没有人说过这种格式，而之前的需求也没有识别到。为了防止这种问题的再次发生，我们召集了所有相关方开会，会上客户反应程序运行很慢，而且ui也不好，使用体验很差，我们把客户提的需求一一记录。在会后向不能到达现场的相关方发送问卷，收集所有需求，同时我们把客户之前的反馈也进行了梳理，这样详细的识别了需求。针对客户反应程序原型很慢的问题，我们通过开会审查发现，一方面是数据库设置不当，另一方面是由于系统是同步进行，如果有数据处理费时的情况，后面的操作就卡住了。对此我们给出的方案是，一方面进行数据库升级，读写分离。另一方面，进行异步操作。对ui重新进行操作界面的设计，在格式问题上，对所有收集到的格式进行兼容，并加入报错通知。我们拿着制定好的方案请客户确认，但是客户对我们的方案褒贬不一，有的人认为UI设计有问题，菜单层级太多，有的人担心运行速度还会慢，有的人自己也没想明白到底要啥，还有的对需求的看法前后不一致。这时候客户还在等着我们的改版，但是面对中说纷纭的需求，我们有一种无从下手的感觉。经过反反复复的开会研究，针对客户的反馈，我们制定了客户需求版本控制系统，在邀请客户确认需求的时候，提醒客户上一版的样子，防止客户需求的反悔，并对客户的需求分类整理，制成树状图，理清需求的脉络。这样一个新版的雏形就出来了。接下来，我们通过努力，新版系统完美的通过了客户的验收。