策划程序沟通

sjinny

如果策划也是程序兼任的，那么沟通的困难不会太大，至少双方有着共同的术语、理论工具和实施细节的知识。但是策划必然要专业化，当策划成为一个领域而不是一个职位的时候，策划与程序的沟通就不会自然而然地顺利了。
从程序的角度说，程序与程序之间有这样一些沟通工具：UML、伪代码、软件原型、设计模式。从程序的角度观察策划，策划与策划之间有这样一些共同工具：文案，公式，数值表，流程描述，已有游戏的案例，交互推演。
对程序来说，策划的这些共同工具描述的都是结果、目标或者说需求，但是一旦这些需求缺乏规律性，程序就会一头雾水，对策划来说，程序的沟通工具涉及很多技术细节，或者沟通工具本身就需要花费时间精力去学习（如UML），如果程序用这些与策划沟通，结果也不会太好。
大家有什么看法呢？

wxhwhmanshan

nan???????????

ArmStd

其???统绦虍?UML?D是有?替程序找麻???膊槐叵氲媚屈N??，事前的?贤ê苤匾??梢砸来私?⒁惶妆容^合?的文案格式，所有策??也根??@??格式?作文?n，那就比??]有看不懂的???，除非???策??真的文案表?能力有???。

另外，通常基?核心??出??r，???都??冗M行系?分析，?些多?刀际窃谇爸?r???瓿傻模?灰?绦虻?EADER能看懂、能?可的，其他程序?T就?能看懂，???窃?公司程序的一??基本??I能力。其他有疑?]的???可??h或言??贤ǎ?饕?遣??必?多少懂一?程序的概念，才不??u同??。

sjinny

UML图可以用来表达程序结构，也可以用来表达需求概念。比如说，策划画的类图不一定就是让程序照着做的，而是用来表达需求领域的概念关系，还有状态图之类的也可以用来表达需求。
文案有一个问题，往往是文字有余而图标不足，描述有余而规律不足，结果就是产生一份几十页的冗长文档，满眼的文字，对程序来说，如果不看完那么就不能全面地理解需求，但要看完的话，这么长的文档不仅花费时间，而且由于内容的规律性不足所以往往看到后面忘了前面。这样的鸡肋文档是不利于沟通的，结果就是在有了完整的文档之后仍然需要大量的口头沟通，之后再根据口头沟通的结果来更新文档。文档成为了一种历史记录，沦为了附庸，不再是沟通的工具，更谈不上设计工具。

核心的东西当然会预先确认，但是具体细节还是会很多的，特别是与交互有关的，细节会很多。

互相了解对方领域的概念是产生共同语言的基础，但是这还不足以构成良好的沟通工具……

blocks

UML不错，只是要清楚策划的UML和程序自己的UML是两马子事情，实际上一个合理的流程图就可以了
伪代码不错，言简意赅，省时省力

ArmStd

??人所配合?的程序，都是希望看到流程?D，然後自己做UML，?是??映绦蛩悸繁容^不??艿礁?_。而做文?n本?砭褪悄墚??D的不做表格，能做表格的不??字。

有?r如果有疑?的?|西，也有?成的??虍a品可以做?φ眨?屈N通常??人??袢≈苯哟蜷_?????碚f明。

abc606

1、最需要的工具不是你所掌握的技术,而是你能清晰给出逻辑
2、沟通的技巧在于说服
至于工具或其他的掌握我觉得足够虚心和理解力可以解决

santaclaus_lion

    项目经理

ykx_yeer

能??D的不做表格，能做表格的不??字！！

santaclaus_lion

ykx_yeer: Re:讨论一下策划与程序的沟通工具

能??D的不做表格，能做表格的不??字！！

   片面强调了图形和表格的表达方式。 事实上图形和表格生动有余灵活不足。 每种表达方式都有自己的特色。 善用者因地制宜，不拘泥于形式。

   也就是所谓的沟通高手。

   让每个程序、策划都是沟通高手！ 这个目标显然不切实际。 所以就要在程序和策划之间建一个沟通的桥梁， 请表达和接受能力好的人来担任。 通常“项目经理”担任此职比较合适。