项目管理初(7)--变化

最近开发都很忙的,累得要死,一直没有时间更新,但最近几天也是变数最大的几天.也深刻感受了变给项目进度带来的影响.
首先[color=red]是需要发生变化[/color],或者说是当时的时候一些功能点并没有非常明确,导致在开发的过程,需要二次,甚至三次确认功能点,这无疑影响了开发的质量,不过也明显的感觉到淘宝在开发中的变化太频繁了,就算是定好的PRD,也会随着开发,UED的介入后,会改变.
其次是[color=red]技术方案变更[/color],最初计划存储消息文件,是通过远端分布式是持久化存储+本地文件存储的方式做(这个方案最主要是避免在服务器重启的时候,丢失聊天记录,所以先要缓存在本地).但开发三天后,发现这个方案有一个问题,就是在分布式环境下,存储的本地文件会乱掉,比如说,用户A先访问机器1,然后再访问机器2,那就会在本地存储两份文件,在用户退出的时候,甚至不知道需要把未存储的文件写到持久层.基于这个问题,和其它同学商量后,决定丢弃这部分聊天记录,当然这样的用户体验就更差了.刚决定这样做后,另一个开发人员提出来了,其实是可以让用户的聊天活动始终定位到一台机器上,这样可以避免之前遇到的问题.其实到这个时候发现,是因为现有的[color=red]开发人员对于系统不是了解[/color] ,导致在设计的时候一些错误的思考.其实整个请求是:
用户A--->APP1-->旺旺客户端I
虽然用户下一次可以请求到APP2,但是他的旺旺聊天应用始终会定位到旺旺客户端I那台机器.
所以项目成员一定要在熟悉系统的情况下,制定合理的技术方案.
[color=red]不确定的升级开发[/color],再项目开发过程中,我们升级了旺旺协议包和使用了新版本的Tair,其中这两个底层库都是最近升级的,Tair包还在测试过程.而对于这块的风险我是没有评估到的.这直接导致了增加了开发阶段的时间,好在开发人员的能力还有保证,项目只是顺延了两天发布.
但是并不是每次都能保证每次都有强力的开发人员,所以对于项目的评估需要增加以上三种考虑时间,特别是在技术方案阶段,要尽量细化.