小项目可以单打独斗。大项目需要团队合作。每个人都是打磨成品环节中的零部件,配合起来才能正常运行。
最近承接了一个项目,按照组内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补充
抓大放小,适当现在领导者或者被汇报对象角度考虑问题。
当前组最重要的是交付能力和质量,以技术驱动业务真的存在,多想想能给业务带来哪些好处。
网友评论