小项目可以单打独斗。大项目需要团队合作。每个人都是打磨成品环节中的零部件，配合起来才能正常运行。
最近承接了一个项目，按照组内scope与budget，算是大项目了。目标是为一线品牌leadership团队提供数据分析工具。
按照之前的项目经验，项目成功的关键是需求的把控。目前业务方有一位接口人，主要负责对业务需求的收集与汇总。我们主要与之对接。所以需求质量主要是接口人把控。从这方便来说，项目就变成了一个交付项目。
按照正常的项目流程，需求分析-》与接口人确定分析场景-》设计解决方案-》开发测试-》上线。
但是，这次的项目变得微妙了起来。
缘由和这家公司的工作环境有关系。
传统外企，非大众消费品。重视传统，传承与血统。工作中经常会有‘利益相关者’插一脚，尤其是有利益可寻的时候。
这次项目多了一个POC。但是这个POC还是非需求直接者提出来的。这位领导作为IT的最高领导者，他希望我们代表他的利益。一定需要组织个PoC. 而且还把业务方老大也邀请了。
PoC从方案角度很成功。同时竟然暴露出了一个严重的问题，就是需求！ 需求并不是最高业务领导者希望的scope。而这说明接口人和代表业务方需求出现了问题。虽然这不是IT应该承担的，但是这会影响交付的收益。
接口人一直跟IT push schedule，本以为我们没有商量的余地，但是经过这一次会，感觉一切都是大家商量与妥协的结果。结论不是唯某一方为大，否则不平等的地位必然造成后续合作的瓶颈。
1. 不管公司管理地位高低，在一个项目角色中，大家分工明确，职责平等，对不合理的要求说不，对职责范围内的事情要勇于发声，这样才能保证项目交付最佳。 Be professional.
2. 最终项目中关键role的反馈，不要情绪化。例如PoC架构师的交付很专业，表示认同，后续方向就按照既定的模板开展。同时也要控制schedule。
3.老大的观点需要重点参考，甲方项目成功不在于交付，在于相关者利益最大化。不可否认，领导的眼光和看问题的深度，要比你高。参考他们的意见，适时调整项目进展。
4.业务方不是神，作为有资深咨询经验的人，可以提供一些建议与合作。非role范围内的工作，可以给建议，但是让owner做决定。
5.关键项目，不要埋头苦干，也要抬头参考意见，及时反馈。要学会keep visibility,这样也可以让大佬有机会监督与把控方向。
2021.7补充
抓大放小，适当现在领导者或者被汇报对象角度考虑问题。
当前组最重要的是交付能力和质量，以技术驱动业务真的存在，多想想能给业务带来哪些好处。
网友评论