网易云音乐 Linux 版 1.1.0 版本经验总结

2017-11-18 07:13 misc

如果问题出现过一次, 那它一定还会再出现

不要幻想着同样的问题不再发生, 除非已经明确定位到问题的出处并且修正了它.

没有不存在问题的软件

不管是功能上的错误, 还是设计交互上的不合理, 没有哪款软件是不存在问题的.

但是, 项目管理时, 要做的就是从全局评估一个问题会提高多少成本, 会损失什么. 当一个问题会导致软件无法启动, 或者运行时出现段错误退出了, 用户的数据也会 丢失, 那这个问题就是不可接受的, 这样的软件也明显是不可以被发布的.

越早修正问题, 成本越低

在开发阶段, 为了修正问题, 可能只需要把发布日期向后延几天. 但是, 如果为了 赶发布进度, 发布了有问题的软件, 等应用公开让用户使用时, 带来的负面影响绝 不只是几句批评, 而是整个形象和口碑的削弱.

尽早测试, 大批量测试

应用场景总是千差万别的, 用户的操作方式也可能会完全出乎项目之初的考虑.

这次, 竟然没有发布内测, 而只是几个人在使用, 这完全没道理的. 因为他们的 使用环境都非常单一, 不可能发现其它平台上存在的问题.

如果可能, 在项目开发之初, 就先做出来新版的原型, 然后只要能跑起来了, 就放出去, 让尽量多的用户来使用, 并且认真评估他们的反馈, 他们才是一线用户.

当然, 过早发布的测试版本, 功能上可能不全面, 而且会有一些问题, 但这并不影响.

经过大批量全面测试的软件, 可以有更大的信心, 确定它不再会出现什么大的纰漏. 想起来了之前新版的系统安装器, 在内测时发现了, 交互设计上的不足, 导致用户会 全盘格式化他的硬盘, 想想都怕, 这样是放到了正式版里, 完蛋了!

项目开发周期几乎一定会往后延

对问题和细节难以做到全面的预估, 导致在项目之初确定的开发周期不够全面.

另外, 中间还会有一些没有考虑到的问题, 会时不时地冒出来.

其次, 项目主管拍脑袋决定的开发周期, 嗯, 是的, 他们会随口就来一句, "等两三个之后 项目结束了".... 两三个月? 没有分解功能点, 也没有评估每个点的困难度, 只是随口来 几句, 就能主观地确定项目周期.就像 <生活大爆炸> 里面, Sheldon 他们接到了国防部 的一个研究项目一样, 刚开始被告认说开发周期是三周, 后来他们三个实在是搞不定, 然后 主动去找项目负责人, 人家也爽快地接受了新的项目周期, 嗯, 是三年.

还有, 还要维护其它项目, 或者临时有什么紧急的事情需要做支缓, 这些都是不能提前预估的. 但是, 它们带来一个共同的结果, 就是会占去为新项目分配的开发时间.

如果允许, 就快速迭代

对于网络软件, 这个都还好做, 因为只需要重新在服务器上面布署. 但是对于传统的桌面应用, 可以把快速迭代, 放到测试期间. 可以每天下午下班之前发一个当天的版本, 还要附带今天的 更新列表, 做了哪些新功能, 或者修正了什么问题.