【酸甜苦辣】记迭代二的酸甜苦辣(林聪篇)

        可怕的甲方。----题记

         第一次做一个校级项目，对我来说算是一个挺大的挑战，过程中确实成长很多收获很多。尤其是在一个项目的整个生命周期的各个部分感受到很多具体的不同。这里就说说自己的感想吧。

【项目开始】-------“我知道你很激动，但是请冷静点。”

         刚开始拿到大项目，大家都是充满干劲，想象里愿景也是美好的。感觉很多思路都在喷发，大家也很激动要给用户做出什么样的产品，又怎样有趣的功能。

但是整个项目完成后给我的感觉是，项目刚开始一定要慎重，冷静，【第一件事】是一定要根据用户需求想好项目开发平台：时间紧需求低就考虑熟悉易上手易开发的平台；时间长要求高就得慎重考虑，不能简单听别人的建议，哪怕有比较大的学习代价，也一定要保证运行的效率能令人满意，否则后期效率达不到根本没时间换平台，只能变成一个应付（失败）的作品。

         比如这次用MySQL和Django开发简直是个神坑，绝大多数组因为用这两个开发抢票系统，相当于从一开始就从性能方面退出了竞争，迭代二也没有时间临时改，后继推出的新功能也无法合并，只有前端幸免于难，我觉得这个问题真的是相当残念。

         【第二件事】：熟悉开发框架的使用。学写各种DEMO虽然花费时间比较多，但是简直救命。即使没时间写，也一定要把功能都浏览一遍，保证开发过程中不会出现有问题都不知道哪里查的现象。

         【第三件事】：设计界面。我想说：一定要设计到令人满意才开始做！不要想说边说边设计啊！！血泪！！设计的时间绝对要比做的时间多得多的多！！！！不然后期改简直要疯（界面设计对于整个项目来说就是背锅侠，因为用户看不到后台，小组内分工选择一定要谨慎，选前端一定要有一颗强大的心）….也要多问问用户的意见，虽然没有做出实体DEMO，具体的UI交互可能感受不到无法反馈，但是一定要让他至少觉得是美观舒服大方的，不然后期告诉你他觉得整体配色不好看简直想死的心都有了。（多问几个用户调查，以免调查的少数用户审美比较奇葩。。）

【项目中期】------“为了美好的明天，请给自己留条后路QAQ。”

         其实中期反而是比较轻松的过程，相较于刚开始的学习成本和设计，中期其实只是一个照图纸实践的环节。需要注意的是在项目开始的时候分工，如果分工有问题，开发过程交叉的地方过多，就会经常打断别人的开发过程和思路，这是很讨厌的事情。（不过我们这次分工挺好的，按功能/页面分，而开始就设计好了界面，因此不存在前端大家各自开发导致整体样式不一致的问题）。

         最重要的是：要注意代码的风格，模块化什么的，保证后期需要修改的时候不至于改个地方就导致雪崩式的BUG出现，否则单是打开各个文件挨个修改就能让你焦头烂额。

【项目后期】------“请再坚持一下，不要晚节不保。”

         后期个人感觉是最累的地方，一方面是精力和热情在开发过程中慢慢消磨掉了。二是你要面对最可怕的甲方！没错就是题记，甲方是最能让你崩溃的人。在你眼中那么理所当然显而易见浅显易懂的东西甲方就是不明白！（导致我在后期重新设计的时候都在脑补自己是个XX来设计）。另外因为这时候大概已经出了项目DEMO可以供大家试用，所以第三点，一定要记住，所有前期中期因为偷懒、粗心、技术不足而留下的坑会在后期一次性爆发。所以说前期中期一定要…….花时间把项目整理好了，否则贪时间急于转阶段，后期就会不断的重复从一个坑爬出然后跳进另一个坑的悲剧。

         这里单独具体说下第二点吧，后期是最需要沟通的地方，沟通的不好就容易导致情绪不稳定然后影响进度。事实上我已经做好被用户说不好的准备了，因为用户总会让你改进的更好，所以如果不是极其惊艳的设计，而且还有富余时间，是一定会让你再改的。

         总结一下沟通过程中出现的几个问题：第一个，用走心的方式觉得不好，也就是凭感觉觉得不好，但是又说不出哪里不好，给不出一个具体修改的方案。这个如果处置不好就是双方大眼瞪小眼了。因为甲方也不是专业设计的，而好的沟通，作为乙方我需要先解释我为什么这样设计，把自己的思路告诉他，然后他如果针对具体的设计有问题我再给出解释，并听取建议。起初跟老师沟通就有这种情况，老师觉得不太好，但是我也不知道应该改哪里，后来请了一个相关专业的说明总算比较清楚。

         第二个问题是，半吊子或者组内其他人提的建议，他们会对项目整体有一定的了解，但是对具体的设计细节却不清楚。

我觉得这种情况，一个是注重语气，如果直接说丑，直接说你不行，就容易上火，尤其是自己的产品就像自己的孩子，哪里能忍别人没理由指指点点，我觉得“…..如果…会不会更好”这样的建设性意见是容易接受的（我自己也是这样给别人提建议），你如果直接说不好就相当于把别人的努力全盘否定了，做到后期是个人都会上火。

         另一个方式是“丑/不好（先否定），（然后）我觉得就应该….”这种也算不好的沟通。首先你简化了了解我设计思路这个环节，就直接提出了自己的意见。打个比方，男女方吵架，男的说“你听我解释”，女的“我不听，我不听，我觉得就应该…..”。就容易让人觉得是在无理取闹。同时，你不先了解设计者的想法，你就不知道你的想法设计者是不是已经试过并且觉得不好。打个过程中的比方吧，小威威在集体开发的时候说选区丑，觉得蓝色的选区不好看，换成灰色好看，当时我其实就是有点火了，因为灰色在设计过程中我已经考虑过了，并且试过了，就是因为从多种颜色中看效果，最后才挑了蓝色，你直接让我改成灰色我是难以接受的，事实也证明我换成灰色给大家看的时候都反馈没蓝色好。

         还有一点就是因为后期就是不停的在小地方上挑挑拣拣，很容易让人厌倦，容易产生“算了不改了就这样吧”这种想法。虽然我们依旧诚恳的修改着（毕竟是学校的项目啊），但我觉得我们组成员或多或少都有某时刻冒出这种想法吧。我觉得一方面是沟通上强硬偏多，让大家疲于应付，一方面确实后期的精力没有保证，感觉就剩个尾巴了，就比较吊儿郎当。我最后总结就是前期的热情应该保留到后期，然后一鼓作气把测试做完。

         实际上感觉就是项目后期，暴露出很多成员间，和用户间我们交流沟通上经验不足的问题。可以说项目后期绝大多数时间都是花在沟通收集意见上。

【项目上线】-------“卧槽，求不崩。”

         上线是忐忑的，那个时候你就很不多后期多努力点把所有隐藏的坑都填上，因为不知道会不会出什么BUG。不过这时候也没有什么时间再繁复改了，所以说不要到最后来后悔。幸好我们在后期挣扎折腾以后上线没出什么问题。

 

 

         成就感就不必说了，显而易见的啦~另外这次宝贵的项目经历感觉会对以后的工作有很大的帮助。QAQ我会好好继续努力的。另外也感谢组内成员在开发过程中对我的包容，大家都棒棒哒！