很久以前,一个做游戏的朋友跟我聊天,他说,一个游戏项目能不能成,关键在策划。
他说:程序固然重要,美术固然重要,但都无法取代策划的核心玩法。
我记得以前项目组开会,策划总是炒成一锅粥,吵完了拉程序美术开会,预估每个功能大致需要多久能完成。
预估完了以后,开工。
这时候,每个程序员有不同的脾气,有的程序表明了「不开单子不做功能」,有的程序则比较好说话,策划跑过去聊个想法,程序就吭哧吭哧做了。
记得某次开会,策划在那边激动地描绘 xx 功能多么炫酷,玩家会多么喜欢。
然后程序问了句:赚钱吗?赚钱就做。
有趣的是,初级策划的工资往往不如初级程序,因为程序的职业门槛比较高。
想到这些往事的原因是,我作为一个技术,每天都有很多的时间花在跟客户经理的沟通上。
这个功能到底是什么样的,能不能按照客户的需求改成另一个样子,这个 bug 是不是 bug,客户经理都跑来问我。
但是整件事情的流程应该是什么样呢?
客户需求应该经由产品部门的评估,再分配给技术团队来做。
最了解产品的应该是产品部门,而不是技术团队。
当技术团队「帮忙」承担了产品部门应有的职责后,产品部门就把产品的决定权「转移」给了技术团队。
与此同时,产品部门也更加搞不懂产品到底能干嘛了,因为需求是技术定的,技术实现的,技术测试的,甚至连功能的名称也是技术想的。
客户经理跟产品部门的沟通也有越来越多的阻碍,客户经理迫于时间压力,必须快速找到问题的答案,而这个捷径就是——问程序。
产品缺位,技术越位,客户第一,这是一个恶性循环。
这种运作模式也许在公司发展初期是无法避免的,但是长期以往会影响公司的持续发展和扩张能力。
游戏产品的核心是策划,软件产品的核心显然也是产品部门,他们需要定义产品的目标、受众、路线、功能等一系列战略型问题。
为了搞懂产品应该做什么,我稍微去搜了点资料。
下图代表着产品开发周期的六个环节(six-stage life cycle),可以看到,在程序开始写代码之前,已经有了大量的讨论和设计层面的沟通,所以分给开发人员的任务应该是有清晰的 scope 和 acceptance criteria 的。
开发人员可以就功能的具体实现方式和产品进行沟通,但是产品功能想要达成的目标是由产品去主导和定义的;同样的,产品部门也要去定义产品的成功标准,如何去衡量这个标准的达成程度。
https://asana.com/resources/product-development-process
产品部门需要做大量的跨部门沟通,stakeholder alignment,去打磨、迭代功能设计,以达成产品想要实现的目标。
A product manager oversees all areas of the product life cycle and works to bridge communication gaps between various internal and external teams. The product manager works to initiate new product launches and initiates product ideation and market research.
虽然涉及的部门很多,但是产品部门依旧是沟通的核心主导者。
当产品功能无法按时交付,或者交付的效果不如预期时,产品部门应该是需要 take responsibility 的,因为这个部门的核心职责就是主导产品的迭代,创造商业价值。
至于 Product Owner 这个角色,是 Agile Methodology 催生的一个新职业,TA 会跟 scrum team 保持高频的沟通和同步,确保产品最终呈现的结果符合用户需求,能创造商业价值。
https://asana.com/resources/product-owner
有时候觉得自己挺操心的,有时候又觉得自己在瞎操心。
明明是个开发,为啥老是担心产品部门忘了客户部门那边提的一个重要功能。
可能是因为跟客户经理关系比较好,不太希望看到他们在客户那边为难吧。
但事实上,正因为我的瞎操心(总是好心去承担产品部门应该去做的事情),反而阻碍了合理的产品开发流程的构建。
我本可以选择像其他开发一样,只做自己的分内事,不去碰开发之外的职责(backlog 没排好顺序,找 PO 排啊)。
但……我这个团队,偏偏又没 PO。
当然,我可以选择指出团队没 PO 的事实,等待一个空降的 PO 来力挽狂澜。
可是我硬是把自己变成了 PO,填补了团队的空缺。
就这样,做了很多杂七杂八的事情,摸着石头过河,虽然碰了很多壁,也有过大大小小的成就感。
后悔吗?不后悔。
只是突然看到了自己的局限性,在「产品缺位,技术越位,客户第一」的恶性循环中,假如无法解决「产品缺位」的问题,就只能靠「技术越位」来满足「客户第一」的商业目标。
说到底,我不过是一个不按套路出牌的开发,而我这个特殊个体的存在,无法解决企业内部的结构性问题。