初为产品经理的心理障碍

一

这篇博客记录了一个月来做项目的一些心情感想和作为leader的反省与领悟。
这中间我一度想起项目作业就心情郁闷、寝食难安。

为什么说是初为产品经理呢？其实大一就发觉自己对开发技术没什么热情，想走产品的路子，但一直都没能完整地带过一个项目。在易助这个神奇的团队也呆过，那时候只是学习学习开开眼，后来自己带头的软件项目也都因为种种原因流产了——说出来好羞耻……菜是原罪啊！所以这次系分的课程项目，一个没有理由失败的项目，是我第一次作为产品经理——能比较完整地跟进一个软件产品的各个生命周期的机会。好了，这也交代了我遇到各种心理障碍的根本原因。

---

二

在开完第一次迭代会议（三周以前）之后，我陷入了深深的焦虑。这种焦虑大体可以归结为：事情很多，不知道接下来该做什么。

那次会议基于简单的backlog讨论确定了第一次迭代做登陆注册功能和其他开发准备工作，同时也暴露出我们需求还不尚明确的短板——没有精确到用例的需求会给设计和开发带来困扰——而当时我连应该精确到什么程度都不清楚。我们决定，四个负责需求的同学再开一次需求讨论小会议。
可是会议在我当时看来非常的不理想。我当时认为首要的任务是找到“做事的方法”，用例图？泳道图？详细的需求文档？我们到底应该做什么，来为开发服务？我在网上拼命搜索，可是没有找到资料能告诉我如何从需求落实到编码。我在会上表达了我的疑惑，希望大家跟我一起寻找这个答案，可是大家一时半会儿也回答不了，并表示不应该纠结于这种问题。然后会议的后半程就在大家的催促下明确了几个主成功场景（讨论的时候大家还没这个概念），把需求模块分派开来去“明确”。开这次会的前后好多天，我们几个对需要产出的制品都很模糊，这是我焦虑的主要来源，两次糟糕的讨论加重了我的负面情绪。

那阵子连做梦都在烦恼项目的事，那是非常难以消化的焦灼感，失去对事物控制的迷茫和无力感。一边是，团队里的大佬以迅雷不及掩耳之势完成了初期的开发准备，然后坐等需求；一边是，“怎么感觉每天都在做系分作业”却“还是没有进度”，让我十分心累。于是我开始试着一点点抽剥这堆糟糕的情绪，从困境中跳出来解决问题。

---

三

首先是直面这个问题——“需求分析应该产出什么制品”，我认为这无可回避，否则你怀揣着一个要明确需求的目标，却不知道如何下手。我默默地翻书查资料，啃完了书本的4-9章，也去请教了别人，始终觉得目前进度到编码之间还是有个断层。后来随着学习的深入，发现从业务文档可以生成用例，从用例中可以提取数据的约定和规范。这才终于慢慢意识到，这个断层叫设计，ER图是设计、领域模型是设计、功能架构是设计、原型交互也是设计，并不是从需求一步就到编码的。想明白这一点终于可以安心做需求了，因为接下来要进行的步骤终于看得见摸得着了。
目前先给出用例文档就好，接下来再做讨论进一步明确需求并作出基本的原型设计，而架构师也可以从大家一致认可的用例文档中提取需要的数据，设计类和API。设计师拿到带有数据的页面流就可以做原型设计了，而开发拿到原型图、逻辑图（功能流程图）和用例文档（特殊情况说明）也能开始编码了。

实在是太菜了啊有木有！设计是软件生命周期中基本的一环啊，居然让我困扰这么久。

事实上，开完小会第二天上课就在讲用例文档，书本第6章也给出了一个详细版本的范例，大家看了都说好，就照那个写。我当时仍然在“还是先干活儿吧”和“想清楚怎么干”之间痛苦地徘徊，虽然比大家都提前了解到这个做法，但啥也没说，大家只会觉得我很磨叽吧——无奈，还不是怪我自己菜。其实做需求的方法和步骤有很多种，产品的起点（产品的创新度和团队资源）不一样选择上就会有不同，工作量和工作分配也因此不同。

---

四

当时觉得小会开得糟糕、影响心情，下面一一反省：

一是被建议不要纠结会觉得不爽。我讨厌还没有想好一件事怎么做之前就嚷嚷着要动手，我认为大家只是急于求成而催促我，却回避了我认为重要的问题。
当然这个问题本就不该抛给大家，在当时那种开短会的环境下，出现无法通过讨论解决的问题就是应当搁置到会后（当然搁置和不要管还是有本质区别）。其次，建议是建议，听了别人建议觉得不爽就是我的不对了。开会时一定要保持头脑冷静，撇开情绪，就事论事——因此也要避免把开会时间定得太晚，那时候人会疲倦。

二是上面那个问题让我堵得慌，无心参与到大家的讨论中。于是大家开始发散到其他各种事情，东说一锤子要跟外援UI设计师对接，西说一棒子要看看综合实验那边的课程要求。这些东西我不仅心里都有数，还有记录一份团队的待做事项，我也知道着急啊，一件件摆出来徒增我的压力。所以就更不想说话了，整个人有点飘忽排斥在他们的话题之外。
想了想还是主要还是自己心态不好，不怨队友催我。我有心收集好所有散碎的信息，做好所有的安排和计划，让大家可以安心地各司其职，可是再怎样也不敢说现在的自己有这样的能力。我的队友能一起监督我是好事，大家都对这个团队负责。其次，自己要注意掌控会议的节奏，要学会适宜的打断：“嘿！现在已经很晚了而我们关键的问题还没有解决，大家快回到主题上来”。

三是跟队友之间高效地讨论和沟通。在形成默契之前，磨合沟通方式是很有必要的。出现问题一定要及时表达自己的意见，具体是什么问题我就按下不表了。

总得来说，自己真的需要摆好心态。外界向我输入了很多信息，我得过滤并以正确的方式消化。首先不要有所有事一把抓的想法，其次警惕情绪，leader的情绪和开会时的状态真的很能影响其他人，我需要拿出百分百的干劲。
很多事情回过头来看才又有了不一样的感受，虽然路途曲折，但事情总是在往好的方向发展。比如那次会议我们似乎在稀里糊涂的情况下完成了几乎所有用例主成功场景的讨论，这是为我们分工写文档做好铺垫的。事实上几乎每次上课讲过的东西，我们已经做了或者正在做，我觉得这个节奏很好，上课变成了一个自查和巩固的过程。比如第一周就画了总的用例图出版，第二周我就看了五分之一“硝烟”那本书做了产品backlog。而我的队友，都是非常可靠又有趣的大佬呀！

---

五

大概会有这么多心里障碍主要还是因为自己菜吧，对做产品的流程仍然缺乏经验。往后还是要大胆地去做，去探索解决方案，老在一边做计划、自己一个人想想想确实有点磨叽。“新手容易陷入瀑布模型的陷阱”，开头的确是这样，什么事情都想要兼顾到，害怕出错和返工。
从不知所措到坚定我们一定可以完成好这个项目的信念，这番摸索和实践必将使我受益良多。