日期:2013-09-17  浏览次数:20744 次

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

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

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

给谁看?

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

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


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

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

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

开头写什么?

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

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

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

接下来做什么?

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

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

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

接下来,需求确认

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

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

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

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


今天先写到这里……


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