闲着没事，写点自己项目中的一些心得，经验有限，且没有参加过正规的项目管理培训，有些想法可能并不合理或者成熟。
 
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