客户识别 Client Categorization

问题: 如何减少跟某个客户了解和确认并实现了的需求却被他的同事推翻需重新设计和实现



具体的原因有很多，其中一点是一开始没找对人.



一个项目，客户那边的stakeholder通常不止一个人，这些人有自己负责的领域. 他们也通常是某一领域的专家. 这里专家的意见要参考，但要找负责的人确认. 所以首要的就是识别谁负责啥.



以CWP项目为例, 初始客户那边有4个人. 他们轮流到现场和开发团队一起工作. 随着客户的轮换, 经常出现需求反复的情况. 一段时间之后, 项目组了解了他们各自的职责.



L需要对业务流程负责. 如果产品上线后发现关键的业务流程走不通或变通成本很高, 他的前途就危险了. 其它的问题则基本不会影响他.

R需要对非功能性需求负责，比如性能，数据安全等. 如果上线后性能很差，数据丢失或泄漏，他的日子就不好过了. 其它的哪怕业务流程有问题也基本影响不到他.

S是Program Manager,需要对项目总体负责，但主要是预算, 进度, 工期等，只要钱没花超，要的功能都在那里先不管质量如何, 他基本上就安全了.

B是大老板，他对项目的成败负责. 除此之外， 他还负责把握实现核心价值的那些功能的需求. 然而由于某种原因，B却参与的很少，项目组也没认识到他的重要性，认识到了也没努力去改变，努力了也出于其他方面的考虑放弃了，采取了等待他自己认识到错误的策略. 至于他负责的这部分需求，就都去找L确认，L毕竟也是这个领域的专家. 终于在上线前一个月，B出于某个意料之外的变动，不得不亲自参与项目，结果发现设计和实现并不是他要的那种，也没法责备开发团队，毕竟是他信任的L确认的需求，也回忆起项目组为involve他曾经作出的努力，只好开始想尽一切办法弥补. 这里其实项目组承担了很大的风险. 相当于把项目最核心的功能推到了上线前一个月才去做， 之前做的都是原型...如果可能，需要尽力避免这种路子...



前面说的这些信息客户通常都是不会直接告诉开发团队的, 需要不断的去观察. 一个有用的手段就是非工作场合的非正式交流，比如一起吃饭聊天等. 通常都会讲一些各自公司的八卦，真相通常在八卦中.