在软件开发中，有一个非常无奈的现实，客户往往无法正确清晰的表述出自己的需求。
作为研发团队团队的管理者，你负责的产品，在拿到产品需求之后，如果只是一味埋头开发，在开发期间不做任何沟通，到最后在为客户呈现产品的时候，得到的反馈往往不是你所期待的，即使你完美的复现了需求要求的一切。
如果你负责的是内部产品，还有产品经理和对应的业务部门“背锅”，有公司内部的流程和各种确认单据来做背书。如果是市场产品，用户的反馈足以将你淹没。
因为在提出需求的时候，客户自己的脑中也没有明确的概念（对业务精通且有软件使用经验的客户除外），他们的很多需求，只是在当时需求调研的deadline要求下，提出的应付的想法。或者他们也有想法，但是还局限在当下的工作条件和流程中，想要通过上线新的系统改善工作效率和质量，结果是重新陷入新系统的使用泥沼当中。
有一个很经典的案例。客户想要提高仓库和商店之间运输效率，他们的认知中，货物的运输是依靠马车来完成。他们提出的需求就是要更快的马。但如果你不做进一步的需求分析，直接去培育更好品种的马，等你漫长产品研发周期过去，牵着一匹提高了50%时速的马匹和客户交货，得到的仍然是客户不满意的咆哮：我要更快，更快！
持续的沟通，能够尽快发现用户以为的需求和实际他们想要的需求之间的偏差。
敏捷，就是解决这个矛盾一种有力的工具。
敏捷的实施，有很多要求，最好团队不要太大，可以参考开发团队的两个披萨的原则。船小好调头，才能让敏捷的实施更顺利。如果团队过大，可以根据业务领域或者需求特性，去拆分团队。
敏捷原则中提到的，可用的软件胜过一切文档。如何保证这一点，不在让用户吐槽你的软件垃圾，就是把他们尽早的拉进软件开发的战场当中。
研发管理者可能会诉苦，客户根本不配合，拿过去软件demo去寻求反馈，如果知道不是最终的产品，根本就不看！这就要研发管理者还有其他同事，比如售前、市场参与协调，强调这个流程的重要性，找到关心这个产品的用户。
根据系统的功能用户角色，找对应的对接人。一开始最好找系统最终用户，他们其实是最关心系统的受众，新系统是否好用，能否对他们的工作提供更大的帮助，是他们极为关心的。
但最终签单付款的人不是他们，导致他们在初期备受冷落，往往到系统验收阶段，矛盾会像火山喷发一样暴露出来。
一个系统好不好用，整体业务流程的基础，往往这些终端用户能够提出非常宝贵的意见，最起码不会再最后的验收阶段，大量的吐槽导致系统难以在实际工作中推行。
如果产品是内部产品，就更方便配合在敏捷研发流程中频繁的参与产品的阶段评审了。
从一个最小的可行性产品开始，根据用户的反馈逐步的扩充完善，可以根据业务链的顺序，也可以根据组织机构的划分来完善，最终搭建出用户认可的产品。
网友评论