当然是在项目开始前整理。

产品经理在项目开始前就应该有一个初步的迭代计划，在不同时期为了满足哪些需求，需要上线哪些功能。要先有一个方向和规划，不然后面工作中可能会跑偏。

你说“没有深入到工作中，做用户故事的意义比理清单大，理解老大是想用这个表格预估技术工时”，其实有两个误区。

1.功能清单表不仅仅是预估工时，更多的是看产品后面的规划是否正确，是否可以解决不同时期业务面临的问题，考察产品的规划能力。

2.并没有说让你一次性把功能清单列的特别详细准确，功能清单是在项目的进行过程中不断补充完善的，只要项目现阶段的功能清单是全面准确的就可以，规划中的功能清单可以再更新。

原则上在开始进行整理，是可以很好的规划产品范围以及做预算。

后期再补的话，会更准确，更多是为了验收使用。

我这里因为要做预算，所以大部分都是前置，先把清单做出来。

但是谁也不能 一下子就搞那么全，除非真的是把原型画完了。

因此你需要考虑的是，既然领导是要估算工时，

我这里的经验就先从粗的开始进行规划

第一步：系统系名称，系统描述

第二步：系统名称，子系统名称，子系统描述

……以此类推，在逐渐完善原型的同时逐渐增加后面的功能清单

这样子，既划定了范围， 又通过描述，告知领导和开发人员，这个模块是要干什么，评估有什么技术难点，评估工时。

你后面给的越详细，评估的就会越准确。

综上，我这里因为要给甲方报价，做预算、立项、招投标，因此清单必须在前期提供出来。但是根据提交的用户不同，粗细的颗粒度也是不一样的。

下面截图，是我这里用的报价明细。

另外，如果做产品规划，使用产品路线图会更合适。

功能清单最主要的作用，应该还仅是 计算工时 和 报价。

产品功能清单是在项目开始前整理较好。

原因如下：

        当做项目时，顺序是首先我们需要从需求、场景、用户角度做足充分思考和分析；然后便是从产品方案、功能、页面逻辑这块用逻辑将这两块连接起来。

         那么需求场景都准备充分后，在做方案时，就输出业务流程图，从业务流程图推页面流程图，根据页面架构功能架构，版本迭代计划可以先输出一版较详细的功能清单了。

       此时输出功能清单后，有以下几方面作用：

       【1】、反复跟业务方沟通整体方案，看看方案有哪些功能点，有哪些业务场景没覆盖到，需要做出产品方案及功能清单上相应调整。

        【2】、跟研发大佬们沟通一下产品整体方案和大致功能清单，看看技术上对于某些功能是否有盲点及目前自身技术能力达不到实现不了的功能点，需要合理分析利弊及探讨出出最优的产品技术方案。

         【3】、跟老板过一版目前写出的产品方案及功能清单，评审下产品的方向和规划目标是否是想要的，这点至关重要！比如我先前设计了一版预约功排队的系统，但只是定制个性化的产品方案，跟老板评审后老板指出需要做出一个产品话的通用型产品解决方案，及时更正。

          【4】、列出较明细的功能清单后，预估出相应的工时和报价，可已发邮件或者书面合同形式发给业务方作为交付边界，业务方确认是否接受，这点也比较重要，可以省去后续很多来回扯皮的麻烦！

          【5】、列出功能清单后，后续产品设计时可作为大方向参考，跟原型图、用户故事结合起来，相辅相成，将产品功能清单和产品整体解决方案更完善起来！

         以上只是本人的观点，欢迎大家提出宝贵建议，一起交流！谢谢大家～

#产品经理挑战赛第2期#    

Day 1

正常情况来说，产品功能清单肯定要在项目初期给到，确实涉及到工作量评估和资源分配。

但现实中在项目初期肯定是给不到很详细的，顶多到二三级菜单就不得了了，除非在需求调研的时候，做的很充分（实际上，项目前期的需求调研很难做到充分）。

那这样的话，我们能给到的大概就是基础的功能列表，细分到大的功能，类似于这样的：

随着项目发展（或随着甲方心情变化）需求是不断变化的，这个表肯定会越来越详细的，最终肯定会细化到具体的功能按钮，类似于这样的：

从工作经验上来说，我个人觉得细化后的表反而更容易评估工作量，因为知道具体涉及的页面数量、业务复杂度等等。尤其是一些运用软件造价相关知识的公司，更需要这些。

按照产品经理的标准工作方式：

第一步是通过需求调研，用思维导图界定产品边界，确定业务场景与解决方案；

第二步是整理功能清单与主要业务流程图；

第三步才是画原型、写需求文档，然后做需求评审，最后是技术实现的评审，然后就开发测试验收。

“虽然我能理解老大是想用这个表格预估技术工时，但由于项目真的很大，我感觉自己真的不能做到最好。。。”

俗话说得好，talk is cheap，show your code。

产品经理工作的时候也是如此，如果你觉得自己不能一次性达成领导的要求，其实是可以先给个初始版本（MVP），然后再根据领导的要求慢慢完善。

比如清楚知道领导要的这个list需要细致到什么程度，我估计项目初期评估的话其实是不太会很细致的，可能只是需要模块-子模块。比如要做一个电商平台，需要商品、订单、店铺、售后、物流、促销等等模块，以商品模块为例，又涉及到品牌管理、类目管理、商品管理、商品评论等，每个子模块由包括增删改、数据同步、定制型功能等等。

如果产品经理刚开始工作不久，不太具备直接整理list的能力，先去调研竞品截图（其实也是原型工作的一部分），先把原型做出来再去做功能list我觉得也没啥毛病，但是这个时期不要在原型的细节上过多纠结。

原型只是解决方案、想法的具象表达。

我会在画原型前把业务流程、功能结构、信息架构、页面结构等梳理清楚，这时其实已经可以输出比较完整的功能清单了，最多是在原型画完后查缺补漏。

看题主的描述，我得到一个荒（ren）谬（xing）的回答。

这题看似在问功能清单是项目开始前弄好还是项目结束时弄好

其实是在说，我怕我做不好，我想找个理由说服我自己，恩，最好是业界大佬们说的

这上级领导都下任务了，还是赶紧干吧~

理论项目前，调研好需要开发的功能，列全找leader等各方相关者确认，给出大概时间节点（30%波动）。

先做原型，不列全功能，做原型的时候也多少有点遗漏。

毕竟是leader，他肯定想看下这个项目会消耗多少工时，方便他协调资源，心里有数（视野不同）

不管多大，都要提前写出来，既然你说这么大，那就更要写出来的。

小不点的（比如就2个功能），不用写，都还过得去。
大的项目不仅要罗列全部详细功能清单，还要有业务流程图、以及产品架构图等等。

这是互联网产品经理的基础的工作。

思维脑图啥时候产出这个就啥时候整

先规划，再迭代更新。

项目开始前

功能清单比原型重要，都不知道要哪些功能，等画完原型再去列功能清单，会存在多次大修改原型，或者说是重新来一遍的结果。

我怀疑你是我同事（狗头）

如果是原型出完后再补，那原型出的依据是什么呢？