大家什么时候觉得被程序忽悠了？

sjinny

分情况讨论：
一种情况是，程序真的不会做或者觉得掌控不住，会老出bug或者很卡，这种情况再沟通也没用，要么找到更好的方案，要么找到其他人来做，但是在项目以外找人做一般是很困难的事，所以这种情况下只能量入为出，有多大的能力办多大的事；
另一种情况是，程序觉得最终可以搞定，但是费力费时，或者对其他东西有很大的影响或者限制，这时如果程序认为这种东西完全不划算，就需要策划去沟通证明这样做是值得的；
但是上述情况都需要有个大前提就是互相信任，否则就什么都谈不起来，可能会变成“我说值得就值得，没有什么为什么”和“我说做不了就是做不了，没有什么为什么”……

两女一杯又一杯

觉得大部分的程序很靠谱。
尽量给程序流程图，减少设计中的歧义，保证他们不用猜你究竟是什么想法。
交付文档时，例行沟通一次
调用配置清晰明确，精确到路径
事先对设计可行性严格评估，（没有执行经验的人很难做到，这是理论派失败的根本原因,执行做得太少，不能对自己的设计负责）

sjinny

好吧我建议把理论派和空话派区分开来，一个领域要走向成熟早晚得要有自己的理论，而说空话其实是另一回事，脱离实际的空话不应阻挡正常的理论总结。

蚂蚱先生

sjinny: Re:大家什么时候觉得被程序忽悠了？

好吧我建议把理论派和空话派区分开来，一个领域要走向成熟早晚得要有自己的理论，而说空话其实是另一回事，脱离实际的空话不应阻挡正常的理论总结。

好吧，你是在说我吗
我就是这样的策划——“我说值得就值得，没有什么为什么”和“我说做不了就是做不了，没有什么为什么”……

sjinny

其实我是对12楼说的……
“我说做不了就是做不了，没有什么为什么”这种一般不是策划说出来的吧……

gantleman

无论如何都让我想起九品芝麻官里，
把管子说直的那位，
能辩论的策划伤不起啊

sjinny: Re:大家什么时候觉得被程序忽悠了？

其实我是对12楼说的……
“我说做不了就是做不了，没有什么为什么”这种一般不是策划说出来的吧……

Miller

。。。死在程序性能上的游戏又不是一个两个。。
有些时候死在功能重叠，矛盾的。并不是策划一个人的错，程序做的时候干什么去了。
及时沟通改了不就完了么，用得着弄死项目么？
人无完人，再牛逼的策划，也不可能做到提的需求毫无漏洞、歧义，百分百顺利开发。
再说那个游戏不是改出来了？那个游戏犀利到一发做出来就没问题了。

绝大部分所谓的因为程序不行夭折，或者策划不行夭折，本质上都是团队沟通协调不行，和能力无关。
真二八经上线了，运营、维护都毫无问题，那死了才是策划的错。

土匪猫

浅层看，是策划，或者程序的问题。实际上都是管理上的问题。。。
死在管理上的多。。。。

1.请个策划，拿策划的工资，顶制作人+产品经理的缸。
2.功能做起来费力，说策划写的案子有毛病，不会写简单点。

协调不好需求-->实现-->制作-->测试-->迭代关系的团队。

浅层看都是策划是垃圾。
深层看，看出来啥了吗？

puredirt

我就是被LZ引用的“某个策划”，其实我并非策划，而是测试：）
所述的只是我的经历，或许是我在的公司管理上不太正规，不过现在的很多小公司现状也就这样，项目经理通常不能真正起到项目经理的作用。公司规模不大，人员素质也参差不齐。
也许各位的团队比较和谐正规，没遇上被忽悠的情况吧。
公司里的新策划是会遇上这样的情况的，尤其是项目赶得比较紧的时候，程序实现的结果与策划的不一致（其实很多只是程序没怎么看文档就开工，实现了个大概，并非技术上不能实现或者真要花大代价，比如昵称限制同名、字数、符号之类的），通常不够强势的新策划都会妥协，甚至把功能去头去尾。程序给出的理由一般就是赶时间XXX，实现起来要XXXX。而老策划通常都会比较强势或坚持，觉得要做到的就会催程序改，不至于被程序三言两语就打发了。
如果大家的素质都很高，各司其职，好好干活，当然不会遇上以上问题。

puredirt

呃，说辩论是好听点，其实就是扯皮。最终决定谁让步而已。
站在测试的角度上来说，策划让步了我们也没必要坚持了，毕竟测试的依据是需求文档，只是最终产品总感觉做得很粗糙没什么诚意。