项目中的一些心得

闲着没事,写点自己项目中的一些心得,经验有限,且没有参加过正规的项目管理培训,有些想法可能并不合理或者成熟。
 
1.  Requirement的优先级: Required/Must > Need > Want/Nice to Have

  • Required/Must是必须要实现的。如果出于技术或者资源的约束而无法实现,我们要做的不是马上告诉用户,“对不起这实现不了”,而是先要搞清客户提出这种需求的原因,在什么应用场景下他们会有这样的需求,因为在很多情况下,客户自己也不是非常清楚他们为什么要这样要那样,或者只是想当然得认为自己要这样要那样。因此,我们需要和客户坐在一起,分析需求的运用场景,很多时候,我们可以让他们认识到,这些场景在新的系统中,是不会出现的。如果客户坚持,我们可以进而propose自己可行的解决方案,让他们知道,新的解决方案同样能满足他们的需求,而且效果接近或者等同于他们提出的方案。
  • Need顾名思义,就是某项功能是需要在系统中实现的,但是并不是说要一字不差得实现的。这个优先级会比Required低一点,而且一旦出现技术或者资源约束,客户也比较容易愿意接受替代的解决方案。
  • Want/Nice to Have是最低优先级的,通常来说,都是用户体验方面的enhancement。一般来说,在资源允许的情况下,可以尽可能地满足这些需求,前提是必须优先保证高优先级的Requirements。如果在高优先级的requirements里有过无法满足需求而迫使客户接受替代方案的情况,那么在want/nice to have中做一些妥协,往往会减少客户的不满和抱怨。(因为这些需求往往是很显而易见改善)

 
2.  Issue/Bug的类型:

  •    Requirement not fulfilled:

这里的requirement,一般都属于Required/Must和Need的requirement,一旦出现这个问题,必须马上修正,因为在我看来,出现这种问题,是非常不professional的表现,甚至会比出现bug更伤害客户的信心。

  •    Programming error

世界上没有bug free的系统,Programming error我一般分为三类:
Crash/Fatal Error, Business Logic Error, UI Error. 优先级从高到低依次排列。特别是前两项,没有还价余地,必须修正。

  •    Platform default behavior

这个类别的issue,一般都属于user interface的问题,而且绝大多数情况下,不会影响系统的正常运行,在保证高优先级issue已修正的前提下,可以试着解决,但是,必须让客户知道,this involves additional development,这一点非常重要,否则的话客户很容易take for granted这类问题三五分钟就能搞定,将来吃苦的还是我们自己。
 
// 待续。。。看球去先。。。下次有新的想法了,再来update

1 thought on “项目中的一些心得

Leave a Reply

Your email address will not be published. Required fields are marked *