以转盘宝箱为例。

策划需求的是什么:点击开始按钮，转盘转动，转动速度越来越慢，转盘停止箭头指向奖品，玩家获得奖品。 抽奖内容、奖品几率等等。

程序的实现逻辑是什么:击开始按钮，请求服务端获取奖品，转盘转动，转动速度越来越慢，转盘停止箭头指向奖品，玩家获得奖品。
或者是：击开始按钮，转盘转动，请求服务端获取奖品，转动速度越来越慢，转盘停止箭头指向奖品，玩家获得奖品。

可见策划的思维方式和程序是不同的，这是一个不牵扯其他任何内容、很简单的功能，如果稍微复杂一点呢？复杂一点一个程序都很难懂另一个程序，更何况策划。

策划首先要做好自己的职责，写清楚需求，操作流程，体验效果等。在职责内策划是有决定权的，其他人对需求的修改需要和策划商量，决定权在策划手上。程序是有否决权，表示无法实现，同时提供原因和可行的替代方案给策划，策划重新确定需求。程序不能私自该需求。
同样程序怎么写代码是程序的职责，你可以帮助他(不建议，程序内部解决)，但决定权在程序。

而且替程序思考也很可能想当然的局限住自己，以为程序会这么做，所以这个需求被自己pass掉。当然最基础的逻辑感要有，不能天马行空。


总之不要替程序去思考。做好自己的职责，可以帮忙，但不要越权。

==================================

从软件工程角度考虑。大的方面分为需求、设计、实现、策划、维护几个阶段。

对于游戏来说，需求就是策划工作的重点内容。
而设计，注意是软件的设计而不是游戏的设计， 已经是程序的工作内容，设计阶段已经牵扯到软件的系统结构，数据结构，处理流程等。而且程序很少将这些内容落实到文档上，都是内部协商定下准则。那么在这个整体设计下，策划替程序思考是不够全面的。尤其是复杂的功能，程序之间都很难互相理解，更何况策划。策划做不到所有需求都替程序思考。 而且处理流程并不是有固定答案的，遍历算法不同程序员都有不同写法，程序不需要非要按策划的思路来写代码。如果你能做到，那么恭喜你可以胜任程序了，只差敲个代码。
这些都是程序的职责，策划不全能，也没有必要替程序思考。反而会因此限制住自己的思维。

在实际项目中，每个人的水平，项目经验不同，多沟通都是好的。但是搞清每个职位的职责范围，对项目进度、管理都是有益无害。在有争论时，应该尊重各职位的职责、权利，做好份内的事，这个产业链才能运转起来。

元素那么大，我想来看看！

立刻提起了精神。

给力！元素有你更精彩

立刻提起了精神。

{:1_145:}

正是本尊想要的！