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

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

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

给谁看?

有些策划文档，我真的看不懂，有两方面原因：1.不是我自己写的，2.不是写给我看的。

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

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

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

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

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

开头写什么?

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

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

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

接下来做什么?

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

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

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

接下来，需求确认。

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

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

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

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

今天先写到这里……

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

更多信息请查看IT技术专栏