一个架构师兼PM、咨询、开发人员同客户谈需求的二三事

以前偶尔听业务咨询人员抱怨 “开发的脑回路也太奇怪了，沟通，谈需求谈到最后吵了一架…"

也曾经听开发人员抱怨 “不懂技术，还瞎指挥，刚拼死拼活搞定的功能，他跑过来一句话要改，还今天就改好，我全都得重写，提前都不问问，就和客户吹牛简单，问都没问，那是几行代码的问题吗？是今天能搞定的吗…”

我曾经同咨询一起做过需求，也曾经同开发一起去和客户谈过需求，下面就分别讲讲几种不同情况。

第一个，是个好案例，曾经一个项目，人员有咨询，开发，项目经理，外聘专家，客户。这个项目很多时候任务分下来时，我们不知道具体需求，需求和开发同步进行，咨询人员那时与我们坐在一起，他们会与开发人员讨论可行方案，然后写出具体需求，与客户进行确认，在那个项目上，我没有体会到咨询与开发的矛盾，大家共事很是顺利。

第二个，是我带的一个项目，我是PM，项目还有架构师，开发。我们与客户方PM坐一起工作，直接画了原型确认，流程、接口等需求由我带着架构师和senior的开发，及客户PM，客户业务人员一起讨论，由于前端要使用wcms进行维护，所以有段时间我们每天与客户开会确定哪些内容由wcms维护，哪些由后台维护，哪些静态内容，一次谈到产品详情页，客户问详情描述信息能不能由wcms维护，那样能直观看到维护出来什么样子，架构师说：“技术上来说应该是可以的”，我问，“每个产品的详情都不同吧，你们有多少种产品？”，客户说，“现在不多，几千种，第一批上线应该只有几百种，以后可能会开新的产品线，具体多少现在不确定…”，我回：“就技术来说确实可以实现，但是，我们的产品页在wcms里也是只有一个页面，那就意味着详情区域会维护几百，甚至几千个组件，那样你们维护时就要在一个area里从上千个组件中找到要改的那一个，费时费力不说，还很可能改错，把别的组件改了…”，之后又和客户讨论了半天，如客户问能不能每个产品在wcms里做一个页面等等，很多都是技术上可以实现，但是业务上并不推荐的方式，那时候发现一个问题，和技术人员讨论时，他们最先想到的是能不能实现，容不容易实现，有的也会考虑有没有挑战性…但是易用性等是放最后考虑的，甚至有人忘记考虑。话说我也是开发出身，难道以前我也是这样考虑问题的吗？不过我负责的东西一直比较杂，设计开发时也总是有很多需要沟通的东西，可能也就练出来了。

第三个项目，我是架构师，项目组成人员：PM，我，业务的leader（一个很高级别顾问），几个业务顾问，客户业务人员，客户领导，客户开发团队。项目特点：PM在公司的职位比我及业务leader低，我与业务leader同级。在外企，PM级别在项目中不一定是级别最高的，这种通常是PM负责管理项目的正常运行，其他人专于自己领域共同配合完成项目。但是。这个项目的咨询人员是跨行业的，他们是CMS的经验，但我们做的是用电商套件做网络pos机。我原本只是出差过去几天，看看他们原本的东西，对于我们未来的架构给出建议，并且带去一个懂电商套件的开发人员，在那里，也和PM及咨询聊了聊，咨询很是能说，我也喜欢听别人说，但是那时需求已经开始很久，没有任何文档提供给客户或者项目组，我提出需求确认、开发都需要有文档，就算是敏捷开发，没有任何资料，也没法做，何况网络应用，需要有原型，PM看起来比较焦虑，每天有空都是与我在沟通需求、开发等等要怎么弄，呆了一周我返回上海，第二周又去了两天，原本的计划就是去那几天，之后就在上海远程支持一下，但是PM向领导反应，希望我能直接过去，而且那时的情况也是需要有懂得产品的人带客户团队及我们的团队一起做开发，于是我就去出差了。客户急着要求立即开发，于是我开始列backlog，同时同PM及咨询lead反复强调，我们首先必须有原型、要确定接口文档等基本内容，然后与PM、客户负责人等确认backlog，因为当时上线时间已经确定，我们需要明确需求，所以我列出了在线pos的所有需求任务列表backlog，与PM商量最好能让客户签字确认backlog，之后如果有需求变更就要按照流程走，不能随意变了，最后客户CEO同意了baclog。我们开始开发，同时，我也开始与我们的咨询团队确认电商及其他平台需求，然后发现，我们签的是200万的合同，但是需求给出的是2千万能做的内容，我提出疑问，咨询和PM说，做完整的再和客户谈PCR，当时我有疑虑，客户并不是容易增加预算的客户，中台甚至都不愿意付出50万以上的费用，于是我再三说谈的时候最好先不要承诺什么东西会做，最好写好文档，让客户确认最终我们这期的需求，PM也同意我的说法，但是咨询似乎不那样认为，后来内部矛盾重重，PM开始向领导要求撤出咨询lead，但是未果，最后PM辞职了，他走时对我说“与其项目失败被开，不如自己走人”。
线上pos机上线后，我退出了项目，在pos实施时，我也与咨询有过矛盾，一次早会，我们那时一期上线内容已经确定，咨询lead突然提出把下一期我们正讨论方案的内容也一起上线，我直接拒绝了，因为时间来不及，而且因为太忙，我未曾与他多说，就与其他人讨论技术去了，现在想来可能让他有点没面子，但是我们是一个团队的，有变化也应该私底下讨论好，会上直接压别人去加入不可能完成的任务，也未免太过，所以即使后来我也觉得自己讲话可能有点太直，但并不觉得愧疚。退出项目后不久，听说项目失败，打官司去了，因为客户认为我们实施的比需求少很多，所以不肯付费，而且客户的ceo那时已经换了人，他们的实施选型据说也要换。

其实一个项目的成功与失败靠的从来不是哪个人，而是整个团队。团队有良好氛围、互助合做，同时，每个项目都需要有规章，一盘散沙最终只有消亡一途。

下面总结一下一个项目成功的关键因素：

。。。。