信息动态

网站设计是技术与创意的完美融合!

建站常识

关于互联网产品策划设计文档的几个问题

2009-09-25 07:52:00

最近休息得比较早, 觉得晚上写日志,一写就几个小时,比较影响休息时间,故停写了几天,今天突然又想起一些事情要写写……

关于工作规范的自我评价,我一直都评了3.5,3.5是一个比较尴尬的分数,越形式主义,越主观,越人性,越会给出超出自己能力的不客观的分数,本来我应该给4分(最高是5)的,不过想想还是算了,一方面因为确实从来都是在摸索规范,如何规范;一方面因为没有给出明确的工作规范,我也不知道什么才是最规范的;另一方面,一些所谓的规范流程,由于还在实验阶段,基本上要使用严格去落实实验阶段的规范,沟通成本和学习成本也非常之大。

对于互联网产品策划来说,最终要拿给大家看的,就是一份策划文档,关于这份策划文档,我算是折腾了很久,总结了一些写文档时,要解决的一些问题:

给谁看?

有些策划文档,我真的看不懂,有两方面原因:1.不是我自己写的,2.不是写给我看的。
在思考给谁看这个问题时,其实就应该不断的思考自己在公司或策划项目时所充当的角色,给谁看?当然是给你和你以外的人员,与自己一样做其它项目策划的人员、技术开发人员、美术设计、测试人员、市场人员、市场调研、上司、老板,另外还可能留到其它人员手头上,正因为这样,这份写了你自己名字的文档,有可能给你带来很多影响,不同的人看了文档,只要你没有为对方考虑到,就会有很多问题找到你,后期会有很大的沟通成本。

作为文档作者,你必须不断的为这些人不断地做换位思考 ,不断地跟他们做可行性沟通,特别是技术、美术设计,这关系到项目是否能顺利进行的问题。


还没有写文档之前做什么?

其实写文档之前,基本上都是头脑风暴,讨论和思考,关键是,头脑风暴时,并没有确认谁来做策划和写文档,也没有确认任务落在谁的身上,如果你是主策划,也是项目的主导者,这倒还好,如果不是,又没有必要的会议记录,最终写文档时,可能之前讨论过的一些细节,都有可能忘记,所以在写文档之前,有必要做一些分散的记录,还有一些问题的收集。

当然,如果按最规范的做法和时间允许的情况下,应该有市场调研和数据分析,不过我一直认为,不需要所有操作都要经过形式上的市场调研和数据分析,一批合格的产品策划人员本身就应该长期跟进产品,并深度地在使用产品,成为用户的一份子,并有可能成为用户意见领袖,只要是这样,在写文档之前,其实已经掌握了大量的实现和用户反馈,只是没有书面的说明,但这些经验性调研结果和实现,必须后期整理和书面表达出来。

开头写什么?

项目名?实现方案?项目介绍?我认为是:给将要做的事情下一个明确的定义——项目定义。

最好还是解决项目名和项目名词定义的问题,并通过文字写下来,这是在解决要做什么的问题,只有明白了做什么,给将要做的事情下一个明确的定义,这个定义必须讨论一致通过,再具体到具体实现模型。

项目名和项目名词定义的标准是——可以单独复制传播放给别人看,当别人问这是个什么样的项目时,负责人员总能回答出来,所以,这要方便记忆,方便传播,并表达清晰简洁好理解。

接下来做什么?

解决了项目定义,接下来是确定项目需求和计划了,接下来应该严格根据定义列出所有与定义相关的需求点,并做出一些必要的分析,列出解决方案概要。

当然如果项目相对比较大,需求点会分步完成,相应的解决方案也会分步给出,不过我始终认为,初期的项目规划,从定义出法,需求点分得越细越好,再使用科学的方法找出最重要的,对复杂的项目来说,再给出分期的解决方案,要解决哪最重要、最核心、哪个是架构、哪个优先级更高的问题。

要是这些问题没有解决好,后期就很容易被人问:这个功能什么时候会做? 没有计划好,你答也答不上,要是别人总来咨询你的计划和解决方案,这不是什么好事情,这绝对是你的项目要做什么、准备什么时候做,这些问题没有考虑周全,并没有很好的跟别人沟通,特别是整天关注你产品的上司。

接下来,需求确认

所谓的需求确认,就是确认项目定义、项目需求、解决方案、产品上线计划等问题,确认无误,再进行下一步操作,这样能避免后期做实现方案的很多问题,如优先级、做什么、怎么做这些问题。做需求确认时,对产品负责人员有很多要求,如何让项目相当的人员、非项目组对项目相当的人员明白你的产品方面和思路?

口头表达固然重要,要用到简单明了的PPT,最简洁清楚的口头描述,所谓产品人员的说服力,在需求确认会上最容易表现了。另外,工作以外,你也可以有意没意地在向大家传达你的产品理念,让你的产品设计更有说服力,这样能减少很多咨询分子对你的骚扰。

当然通常有经验的设计人员,在前面两个步骤没有明文出现时,已经做出模型了,我不否认这种做法,因为能完成模型的人员,在完成模型之时,脑海里已经有了初步的产品需求模型,并了解了项目设计的出发点,有模型或产品构思图,可以帮助思考问题,口头经过讨论和确认后的需求,做出核心的产品模型,这样更具体的模型测试能得到更多的讨论和反馈,减少文档返工的可能性,减少写文档需要重复修改的时间和沟通成本。

但最终方案的文档,还是必要从“项目定义”“项目需求和计划”重新做起,并在模型上不断做调整,让模型更完善可行。


今天先写到这里……

其实上面过程还有很多细节没有提及,不过靠谱的产品策划,基本不用看我的这些文字,这些问题都是新手上路过程中慢慢摸索出来的,另外,这日志要表达的不是什么文档写作流程和规范,我连自己文档也在没有规范的环境下慢慢摸索和改进中……

PS:花了两个小时

原文:http://ucdchina.com/snap/4760

0532-85810878 473587358 service@leadto.com.cn