千万级这类大型集团定制开发的项目，一般投资大、需求多、周期长、且用户关系复杂，本文作者以自己亲身经验，为大家总结出五种适用于这类项目的思维方式。

我要复盘的千万级项目，主要指大型集团型企业的定制开发项目，这类企业一般都有多层级的组织机构，总部-分公司的管理模式，用户的需求很难用相对成熟的产品套件来满足。

这类项目一般呈现的特点是投资大、需求多、周期长、用户关系复杂，稍有不慎可能就掉进了大坑。

本人有幸参与并负责过几个这样的项目，深有感触，我总结了5个思维方式来指导这类项目的售前以及售后支撑。

一、占点思维

占点就是要占领制高点，获取资源优势，这类千万级的大项目听起来投资不小，可实际算一下，售前、需求、产品、项目、研发、测试、集成实施投上几十个人，干个3年左右验收，基本上不赚钱，而且即使干完一期项目还有二期，还是一样很难赚到钱。

赚不到钱为什么还要做？因为抢下这个点有优势，这个点一般指的是集团总部的大项目，抢下了总部的项目，会打响你的知名度，让你掌握更多的资源，比如更加及时的了解总部管理上的变化、最新的管理变革、人员变动等，这些都是隐形的优势。

我们当年拿到了总部的大项目，虽然没有赚钱，后来省里很多分公司有相关的投资项目，都会优先找我们，这样一下拿到了省里十几个点的类似项目，同时因为打入了分公司，公司很多其他的产品也得以推广、落地，这样总体来看市场更大了。

我主导过一个供应链的IT咨询项目，当时和我们一起竞标的有IBM、埃森哲这些业内很有名头的咨询厂商，但是最后我们中标了，我们中标的价格并不低，用户最看重是我们的市场优势，因为我们在集团总部有供应链的项目，同时又在各个分公司占了十几个点，自然就成了这个大型集团企业内部来看最牛逼的厂商，选择我们就是能够及时获取总部最新的创新方案，快速复制兄弟公司的信息化实施经验，这个才是我们的核心竞争力。

后来这个IT咨询项目汇报的时候，也印证了这一点，人家并不看重你所谓高大上的咨询方法论，再美的PPT也没太大的作用，真正打动用户领导的就是上面说的核心竞争力。

通过占点，也能在能在一定程度上提升公司在某个领域的影响力，通过这种影响力可以有助于向其他行业市场进军，从而达到从点、线、面、体的逐步扩张，利益最大化。

二、规划思维

一般这种千万级的大项目，大多都业务复杂、技术要求高，需要跨部门协调，用户最希望的就是厂商可以引导他们，而不是用户说什么就做什么，要充当引领者，某种程度上厂商既要充当一个咨询的角色又要充当集成商的实施角色。

作为咨询者就要帮助用户做IT规划，从业务层明把错综复杂的业务梳理清楚，借鉴一些最佳实践或者把用户方竞争对手的案例拿过来参考，建立完整的业务视图，通过我们的IT能力，进行功能规划、系统规划和技术规划，最终输出项目演进的实施路径。

通过做规划从业务和IT层明引导用户建立顶层设计架构，一步步实现由业务到IT系统的落地，这样你在用户心目中才叫专家，才是真正引导用户IT建设的专业厂商。

曾经有个集团级项目，我们已做了三期，感觉用户越来越不满意，为了能把四期建设起来，通过编写业务和技术规范的方式来引导用户，最后这个规范上升到公司级，并且下发到所有分公司遵照执行，一下子把盘子变大了，原来觉得都没什么可做了，现在一下还能做几期项目，而且每期项目都是千万级的。

做IT规划的最大好处就是通过顶层设计，建立专家范，取得用户信任，并且可以把小单变大单，寻找明天的奶酪。

三、边界思维

通过前期的规划引导，项目基本确定要做了，这个时候最重要的就是要确定项目边界，把项目的需求范围控制在一个可行的范围之内。

这个时候很关键，一定要通过建立本期项目目标和价值来引导用户确定项目范围，如果涉及到高层汇报，就一定要协调本公司的高层参加，通过高层对话最终确定项目范围。

当时我做的一个项目就遇到了类似问题，甲方项目经理和主管领导层面一定要把某个大功能模块包含在本期范围之内。

我们评估此模块不但业务复杂度高、开发工作量大，最重要的是按照现在的管理程度，即使建设了这个功能也用不起来，所以双方坚持不下，最后只能开高层会议，双方总裁级领导参加，当时我做的汇报，最后的决策是不做了，这样研发成本省了至少100万，也为后来项目成功实施打下了基础。

这么大的项目不要想着一下全都开发完上线，这种模式风险太大，一方面无法快速的见成效减轻项目压力，另一方便也无法快速得到用户反馈，导致可能后续改动的内容过多，所以一定要分步实施，借鉴产品管理的MVP思维，要先建立一个最小可用版本作为第一个版本上线，先用起来，一边验证、一边迭代后续的版本，这样进度压力会减轻不少，用户满意度也能大幅提升。

四、用户思维

做过这么多管理类产品项目，我自己的经验是，一个项目能否成功50%取决于用户，所以建立用户思维很重要，建立用户思维的核心就是站在用户的立场上为自己着想，也就是要双赢。

这类大项目一般都涉及到大量重要的干系人，最典型几类干系人就是甲方项目经理、难缠的需求部门用户、管理层、决策层，不同层级的干系人都要维护好，才能保证整个项目的顺畅进行。

一般作为乙方的产品/项目负责人要有能力搞定甲方项目经理、难缠需求部门用户，并且得到中层管理者的支持，决策层就要由销售牵头高层领导建立互访通道。

我曾经遇到过很多难缠的需求部门用户，其中一个就是文姐，我在以前的文章写过，其实就是是几件事让她对我有了全新的认识：

（1）大周末的给她打电话，她虽然很烦，但是感觉这态度怎么和前任不一样了，这努力的尽头系统一定可以做好啊，后来他还专门给我的领导打电话说这个事，说他来了你们真得开始转变了。这也许是她对我初步达成信任吧。

（2）她要我回复的每个邮件，我都会非常认真的写，而且写得非常仔细，专业，她回我一句话，我要用十句话给她解释，而且我还会扩展讲出其它可能她都没有想到的问题。慢慢的就算是我也会有些错别的字她也不会太计较，因为她觉得我态度非常好，而且回复的邮件逻辑清晰，非常专业。以至于后来她专门找我的领导说，你这是从哪找的人，怎么这么仔细，比我还要仔细。

（3）有些错误我帮她扛着，有时候她也会犯一些小错误，特别是在她的领导面前我会主动把一些错误扛到我身上，这些小错误我扛着对我来说只是客户策略，没什么，我得领导也不会对我怎么样，这样她会对我特别感激总觉得欠我的。

（4）帮她写了一个技术规范，让她很好的完成了年度任务。这个任务是她的直接领导给她的，以她的水平很难写出来，这个时候体现我专业能力的机会来了，我把各种信息化规划的方法论，给她大讲一遍，一个月的时间洋洋洒洒写了100多页的技术规范，她高兴得直说，真是专业，这才像我们的合作伙伴。

最核心的就是态度和专业，态度好，专业能力强是征服难缠用户最重要的武器。

五、过程控制思维

除了把人管理好，最重要就是要控制需求，防止需求蔓延，引发大规模的需求变更，控不好需求已成为项目失败的关键因素。

要控制需求变更，对外要建立协同机制，对内要严格控制需求流程，通过对内对外的流程管控，达到整个项目团队对需求的理解一致。

（1）从外部看，需要重点控制四个环节，其中两个环节需要签字确认，也叫“四定两签“，四定指的是定方案、定需求、定UAT结果、定上线计划，需求和UAT结果需要白纸黑字，签字确认。

定方案：在细化软件需求说明书之前，先根据自己对用户需求的理解，出一个方案，方案与需求说明书相比重在描述解决问题的思路和措施，给用户汇报方便，不像软件需求说明书那样晦涩难懂，通过方案达成了我们与用户对需求理解共识的第一步，而且出方案成本低，就算是方案不合格重新写也没关系，如果到了详细的软件说明书和原型都出来了再返工，成本会相对较高，所以方案就成了连接用户需求与软件需求的桥梁。

定需求:输出物就是软件需求说明书，一般会配上系统原型，通过给用户汇报原型达到大家对需求理解的共识，需求说明书一定要签字确认，作为后续设计、开发的依据，不能随便变动。因为要签字，用户确认需求时也会更加谨慎。

定UAT结果：UAT是在功能上线之前由用户进行测试，测试通过后具备功能上线条件，一般UAT会采用会议方式，由厂商负责系统演示，用户提出问题，针对UAT发现的系统问题或者小优化一般会承诺解决，变更或新增的需求只做记录，后面单独谈，UAT之后会出UAT报告，由甲乙双方签字确认。

定上线计划：上线计划最重要的就是割接方案，上线能否成功很大程度上取决于割接方案能否成功执行，割接方案有时在业务层面需要和用户达成共识，如果割接的业务规则没搞对，很可能会造成不可逆的错误，记得割接时一定要备份数据，这算是给自己留个后手。

（2）从内部看重点控制两个需求环节，分别是需求评审和测试演示。

需求评审大家应该比较熟悉，由产品发起，组织研发、测试等相关人员对原型、需求进行内评审，评审完成后输出需求评审会议纪要，通过这一步由产品人员对需求进行详细讲解，达到内部项目团队对需求理解尽量保持一致，减少需求传播造成的失真。

测试演示这个环节是测试和研发的衔接环节，这个环节由研发发起，组织需求和测试人员对开发出的功能进行初步验证，尽早的让产品看到开发的功能，更早的发现理解上的差异，通过这个环节让测试人员更加深刻的理解需求，只有需求演示环节通过的功能才能进入测试环节。

六、资源整合思维

通常这类大项目团队人数大，很可能涉及到不同产品线的协作，系统开发可能涉及到很多横向、纵向接口，需要协调大量第三方厂商共同完成接口的开发。

这个时候我们就不是单纯的软件开发商，而是总集成商，需要协调内部各部门、用户、用户平行单位、第三方软、硬件厂商共同协作完成项目的最终交付。

对内要学会向上管理，培养自己的横向领导力，对外学会通过与关键用户建立信任关系，积累社交货币，从而帮助你撬动其他资源。

#专栏作家#

奋斗De奶爸，微信公众号：奶爸的小客栈（ID：naiba2000），人人都是产品经理专栏作家。10年以上产品、项目管理实战经验，关注企业供应链、数据中心、IT监控等产品，喜欢琢磨，希望把有价值的产品理念和实战经验传递给需要的人。

本文原创发布于人人都是产品经理。未经许可，禁止转载。

题图来自 Unsplash，基于CC0协议。