独立负责杂志的产品，也算是小有一段时间，算算也有一个多月了，在这段时间里，感受最深的，是自己从一个会议的被开会者，变成一个会议的组织者。同时又由于公司架构调整的原因，原来公司有一个协调的角色，负责组织会议与推动项目进程，结果现在淡化了，变成了我要去主动推进产品的进程。说实话，对于这个改变，我是挺开心的，因为项目推进，对于一个产品经理来说，是一项必备的技能，我还是很乐于去学习如何推动项目的进程的。这一部分，也是我大学多个项目中，较弱的一环，自己是希望能补上的。
但今天，要讲的，是最近让我突然倍感压力的技术评审。说是突然，是因为自己在从一个产品的协助者，变成一个负责者，没有及时调整自己在技术评审会议中的角色。在产品技术评审前，还是抱着一个可以临时解决问题的心态来面对，其实是稍微有点自负了。整个技术评审，后来总结了下，核心是自己心态太不重视了。也许是最近接收到的需求太多，忙于去评审各类的需求，而忽视了开发评审这块。但是这种心态确实需要调整过来。
当技术评审开始时，由于此次的需求为消息中心的设计，犯了一个较大的失误，就是没有根据参会的人，来调整讲解的内容。在讲解消息类型前，没有很好地先讲解消息类型的区别，而是太过于注重要做什么内容。为什么这样说呢？其实开发也需要大概分两种，一个是属于管理层开发，可能手下管着几个人的样子。这样的技术，因为是稍微属于管理层，而这次来的开发，就是属于这一种级别的。在这个时候，其实应该临时调整，在概念上需要稍微做下解释的。因为对于一般的开发来说，他最关注的，是做什么，而对于这种稍微属于管理层的开发，是有点偏向于帮你审核需求的。这属于稍微大概的分类。其实，有开发一起审核需求，很多时候会让需求变得更加严谨，这个是很有必要的，而且我也很开心听到另外一种声音。但是所谓ucd，就是要根据用户特性，来满足不同的需求。由于这个调整没有及时调整过来，导致了会议开始就出现了一些质疑。
其实在开发提出疑问较多的需求中，有一个需求是根据用户的行为筛选用户的。这个需求由于是涉及了多个平台，所以需求是稍微做得粗略，希望开发能在评审会上给出更多的建议。其实这个角度，从一开始就是错误的。其实技术评审会，并不是讨论会，而是确定会。在这个会议之前的需求，应该是基本确定的。你想想，这么多人，如果还需要从初步开始讨论，将是一个多大的时间成本。也就是，技术评审会，是一个确定会，而不是讨论会。这个是技术评审会议要点是需要牢牢记住的。也正是 这个会议的出发点没有把握好，导致被某开发直接说，其实我觉得你这个需求做得很烂。需求的价值是很值得肯定的，只是需求的可实现性，在会议之前，需要至少初步确定好的。
从这次技术评审会议中，学习到的，一个是面对技术评审的心态，要尽力去准备，考虑到评审会上可能出现的各种问题，一个是演讲内容，需要根据在场听众的特性，做一些相应的内容侧重调整，另外一个就是需要牢牢记住的，技术评审会，是一个需求确定会，而不是讨论会。
