安卓版
华师匣子产品经理 | 林文雅
华师匣子是一款专门为华师人打造的校园利器，主要解决在校难，如：
- 新学期上课，课室到底是9-11还是9-21呀？
- 饭卡到底剩下几块钱啊，中午想吃黄焖鸡哎(:зゝ∠)
- 听说新成绩已经出了，好想查啊，可是电脑不在身边哎
- 宿舍突然停电是什么鬼？！
- 运动会是哪三天来着？我想规划一下出游计划，嘿嘿嘿
- 教务处电话是多少啊？问了好多人都不知道啊！蓝瘦香菇TT.
- … …
在校难生动描述请戳→ 华师人测测你的伤害指数有多大
华师匣子
产品定位
整合校园多方面学生信息的轻量查询工具，通过该产品，便利华师学生在校的学习和生活
目标人群
华师本科在校生（不含交换生和留学生）
产品功能
- 图书馆：馆内书籍搜索并查看，已借图书查看
- 课程表：课程表查看，课程添加
- 学生卡：学生卡余额查看、近七天消费情况概览
- 电费查询：宿舍剩余电量、电费查询
- 成绩查询：某学年某学期成绩查询
- 常用网站：快速锁定常用网站
- 校历：查看校历
- 部门信息：查看相关部门咨询电话及部门位置
- 消息提醒：所添加课程中可选择课程提醒、图书即将到期提醒、学生卡余额消息提醒、有新成绩消息提醒
- 通知公告：教务处、学工部及校团委公告通知
- 产品分享：搭建我校校园产品（app/web）分享平台，向用户推送产品的相关信息，同时为用户提供产品使用的相关入口
- 设置关于：消息提醒功能设置、登出设置的功能；关于我们的信息介绍、检测新版本及意见反馈功能
开发人员
产品经理1名、设计师1名、安卓开发工程师2名、以及后端开发工程师1名。
产品成果
目前下载量有4000+，最高日活1000+，现已进入二版开发尾声阶段。
开发工作
在此次匣子开发过程中，主要负责的工作有：
- 需求挖掘和分析
- 用户调研
- 功能信息架构搭建
- 原型设计
- 可用性测试
- 把控及推进产品开发进度
由于前期工作准备充足，后期开发较少有需求变动；功能路径清晰大大降低了交互设计的难度；坚持每周大会和小会不间断的同时，强调产品在视觉设计、技术实现方面的交流，使得隐含问题能较早发现并处理，保证并推进开发进度。
前期工作准备充足
需求挖掘和分析是基础
打造匣子源于队长的一个想法，希望打造一款APP能够解决华师人在校学习和生活难题，于是我们就开始鼓动团内成员对产品功能进行头脑风暴。
当时我接触的开发模式是两类：精益开发和传统开发，而精益开发主要通过打造出MVP（最小可行产品）来满足用户的基本需求，注重的是能够快速开发出产品，并通过用户反馈等进一步完善产品。传统开发则更注重所打造产品需求的全面性、覆盖性。
当时匣子选择的是精益开发的方式（虽然当初我们并不知道这种叫精益开发（luck）），由于是初次接触产品开发，同时为了避免心太大影响产品质量，故选择功能精简开发的方式，拒绝功能冗杂或追求全面。
根据大家提供的风暴讯息，并结合匣子的产品定位和开发模式最终制定了匣子MVP初版。在这个过程中我们做了许多取舍，特别是我自己。
通知公告是否需要做历史信息记录？这个看似很平常的问题，我却在这里做了很久的纠结。其实加一个历史信息记录并不会使得通知公告这一大块功能变得冗杂，但是放在整个华师匣子一版开发考虑的话，通过公告增加一个历史信息记录是否过于精（细）了，如果要提供历史记录的话其实还应该要有一个搜索吧，帮助用户进行快速查找信息。同时历史信息记录到底是要提供几天的历史信息，是要三天、一周、一个月还是全部？最终这个需求被我砍掉了，并不是觉得它不被需要才砍掉的，只是觉得在当前的开发情况下，这个需求更可能会在二版或是三版中出现。
在需求取舍的过程中深刻感受到产品定位和产品规划的重要性，它们是做出判断的重要标准。确定好产品发展规划能够明确未来版本中产品功能拓展的方向，还能给产品原型设计做出有意义的指导。
在做取舍的过程中还有一个值得提到的地方就是，因为我是第一次接触产品开发，虽然是匣子的产品经理但是团队里面有已经开发过产品的老人，所以当自己的想法与他们想法相悖或是被他们否决时，就会不自觉地打压自己。
经过匣子一版及其余小型项目开发之后发现，做需求取舍时还应当适当去倾听自己内心的声音，去了解自己为什么想要提出这个需求，这样的需求是被需要的吗，为什么需要等，并向别人【表明自己的想法及考虑】。要相信自己是最熟悉自己产品，也是最想表达出产品理念的人。
即便到最后需求未被采纳，这思考的过程、倾听自己内心声音的过程也是必不可少，值得花时间去做的。
功能信息搭建是框架
确定需求（产品功能）只是第一步，需求的细化也就是功能信息架构的搭建是隐形的大boss。
确定基本功能后匣子开始搭建信息架构，比如课程查看功能要展示的课程信息是什么、需要怎么查看；课程添加功能要如何添加、添加课程的信息有什么、添加课程之后课程表会有什么改变等。
如果只是凭感觉直接进入原型设计而不确定产品功能信息架构，那么自身搭建起来的产品功能是不全面的，会出现细致功能遗漏的情况，导致理所当能能实现的功能并不能理想实现。
搭建信息架构紧密的思维逻辑能力十分重要，且要对功能的使用场景有一个全面的把握，需要的信息是什么，想要达到怎样的效果，会遇到怎样的问题并要如何解决都需要被考虑到。值得强调的是搭建信息架构并不是一次性就能够完成的或者说并不是一次就达到完美的状态，在匣子开发过程中我采取的方式是不同时间二次查看，同时与项目组成员展开激烈讨论，在开发过程中及时与开发工程师交流来减低由于信息架构搭建不全面引发问题的可能性。
搭建华师匣子功能信息架构时总是觉得恍惚间就一个下午过去了，毫不察觉的那种。沉浸在功能搭建的海洋里并且进行思维逻辑活动虽然十分累，但是却十分享受。在看到一个个基础功能在自己的努力后逐渐丰富和全面起来就感到无比开心和满足。
原型可用性测试是保障
初涉产品经理时观看的是《启示录》，里边很大篇幅讲到了“可用性测试”的内容。于是在匣子原型设计之后，也有意识地组织开展了原型测试的可用性测试。
匣子的可用性测试主要以场景测试为主，以纸质模型任务式的方式进行测试。测试前做的工作主要有：了解可用性测试涵盖的内容、此次可用性测试的目的以及主要测试场景的确定、测试人员安排等。
其实可用性测试中最难的并不是策划，而是如何将被测者带入测试场景，向被测者提出任务但是不引导他们做出选择。同时，在提出任务时也不被被测者影响，与被测者进行非必要的交流。这需要测试者有很强的自控力和场景把控能力。
测试时进行录制或是录音，以保证需要对场景进行回顾和确认。同时在测试过程中，测试者要及时记录好测试过程中被测者遇到的问题有哪些，即便只是简单的迟疑，也需要记录情况，待测试结束后再询问被测者为何感到迟疑，进一步确认问题产生的情况。测试结束后对测试情况进行汇总和分析，修改和完善原型。
最终我是将测试情况汇总在表格当中并根据表格信息对产品原型设计情况做进一步处理。需要解决还是不需要解决，解决的方案又是什么都在汇总表当中标明。
功能路径设计清晰
各大功能块切分明显
由于华师匣子本身是工具类产品，生动比喻的话匣子就像是一个解决校园在校难各种工具的收藏夹，所以匣子的功能切分会比较清楚，各功能间的相关性较低。这方便功能信息架构搭建的同时，也减轻了功能路径设计的难度。
穷尽功能搭建信息架构
基于华师匣子功能块切分明显的前提下进行功能信息架构搭建，对各大功能进行功能的穷尽，直到最后呈现给用户的每一种状态。
信息架构搭建时是采用了百度脑图作为思维拓宽的辅助工具，做到进行逻辑思考的同时能实时记录。需要注意的是在进行思维逻辑时需要保持在一个专注并轻松的状态。
专注是因为在做思维逻辑时，会根据某一点在脑海中进行全面的链式思考，这个思考很有可能是唯一的，不可再现的，一旦被打断或者是自己神游出去了，就很难回到原来的状态。那么很有可能这次思考就作废或是丢失了一个十分重要的点。
轻松是因为在做思维逻辑本身就是一个思维扩散的过程，很多时候不强调对错，就凭借第一感受去思考并记录。而轻松是为了让自己的思维能更加活跃、更加发散。
进行功能穷尽时主要是以产品需求情况以及用户的实用角度出发去完善华师匣子信息架构体系。
展示的信息架构体系并不是最开始搭建的信息架构，而是在多次的会议与讨论中完善起来的。毕竟即便是自己多次回顾也可能会有功能穷尽疏漏或是在技术层面实现考虑欠缺的方面。
强调产品开发交流
坚持每周大会小会不间断
在开会的过程中难免会遇到“觉得这个会议内容好像与我相关性不大”的情况，如在确立原型中安卓开发工程师可能觉得与自身的相关性不大。这个时候需要有意识地调动开发在会议中的参与感，往往会有意想不到的收获。
如在原型讨论中开发就提出了（这个控件不好实现）此时设计师就可以提前进入修改…
会议的主要内容有：
- 脑洞需求
- 确定需求
- 确定原型
- 评估技术可实施性
- 数据需求
- 任务分配
- 视觉评审
- API接口
- ……
强调及时发现并解决问题
每一次开会都会引导大家积极从自身领域思考提出对问题的见解，及时发现并解决隐含问题。
如在确定消息通知需求情况时，我原本打算是实时请求数据并若获取到有消息更新后就立即通知用户，而后端开发工程师提出这样会给服务器造成较大压力，经商量最终确定按情况进行请求次数及时间的设置，如课表信息更新请求是每日早上六点进行请求。
在开发过程中安卓开发工程师发现课表疑似少了一个删除功能的设置，并在开会中主动提出，而确实就是少设置了一个删除功能，虽然在此前已经进行了原型的可用性测试……
促进各开发组之间的交流
小会不间断是指除了较大的需要项目组全员参与商讨并确定的事件之外，各项目组组与组之间还要进行不间断地小会，主要是为了解决细致上的问题。
如在进行原型设计时，产品经理会与设计师详细交流需求情况以及功能路径情况，设计师不清楚的时候也会跟产品经理沟通。同时设计师拿不准是否可以实现的交互及其难度时可以积极主动去与开发工程师确认，而在匣子的开发过程中我就十分强调设计师与开发工程师的交流。
在确定数据的API时候，后端开发工程师虽然已经拿到了数据需求情况，但是需要与安卓开发工程师进行API接口的讨论及确认……
保证和推进开发进度
大概了解产品经理工作内容的都知道，产品经理的工作是贯穿整个产品开发及产品迭代过程的。主要的工作有竞品分析、用户调查、数据分析、需求分析、原型设计、可用性测试以及保证和推荐产品开发进度，但往往在进行了六项工作后，容易在保证和推进产品开发进度上松懈。
华师匣子开发过程中在经过高强度的需求分析、原型设计和可用性测试确定了匣子的原型之后，我仿佛舒了一口气，那感觉就像是我终于完成了我的工作了！但是随后坚持的例行会议以及开发期限却时刻提醒我：你要把控产品开发节奏！不能松懈！不许松懈！
那么在完成了前六项工作之后，可以从哪些方面保证和推进产品开发进度呢？
紧跟计划查收任务
项目展开时会确定项目的开发期限，而随着需求及原型的确定会更加细致确定项目中各任务的开发时间。同时根据制定的时间，不定期地对任务完成情况进行确认。
由于团队并未使用项目管理的软件，分配任务是借助Tower上的看板，而对任务完成的情况确认就需要我自己在私底下进行，所以我需要十分确定当前有什么事情，未来即将又要确定什么事情等。需要自身拿捏好任务情况的同时还要迅速在各任务中切换，这个时候做好记录十分重要。
在跟进项目情况时能够较快切换当前工作状态，并且做好记录及必要的修改工作。
协调进行并行开发
各组开发需要的“资源”是指：如安卓开发工程师开发需要的原型图或视觉稿，如后端开发工程师开发需要的数据需求等，而当明确各组开发需要的资源才能够更好地明确各组开发时间的同时还能调动并实现并行开发，而不是串行开发。
匣子原型设计完成之后，开发小哥就可以开始干活了，而后台小哥，在需求确定后还没进行原型设计之前也开始干活了，如爬取产品所需要的数据、开始编写API文档等……
未后语
华师匣子是我第一次作为产品经理角色打造的产品，也是木犀团队第一款系统打造的产品，可谓是一款从0到1的产品。
在华师匣子打造之前，木犀团队并没有产品经理，只有技术开发人员及设计师，由于缺乏这个角色造成了许多产品开发隐患。而当我来到木犀并担任产品经理角色组建项目组进行开发时基本是靠自己的学习和摸索。
在华师匣子开发前我先是自主学习了什么是产品经理，产品经理的工作主要有什么，产品开发的流程是什么等。当确定要做华师匣子产品时，我又开始了解竞品分析的内容、原型设计的内容以及可用性测试的内容。在推进华师匣子开发进度的同时，也提升了自我能力，并输出了产品小白学习概要、4步拿下可用性测试等学习成果。
也正是从华师匣子产品开始，木犀团队根据团队情况开始搭建了自己的产品开发体系，而我在期间起到了主要的作用。
在华师匣子的整个开发过程中我有想要懈怠过，有彷徨过，但是心中对打造出一款属于自己的产品的热情却从来没有递减，能够跟项目组成员在为着一个共同目标奋斗，一起感受打造一款产品的苦与乐是再值得不过的事情。我想在未来的开发过程中也是如此，尽管是有困难险阻，但是我来了，我足够热爱，我就不会放弃并会想办法去把它克服。：）
期待华师匣子越来越好，期待与下一个产品的相遇，期待自己成为更优秀的产品经理。
附：华师匣子开发时间轴
安卓版
2016年
02.28 诞生想法——想要打造一款便利华师人生活的手机应用
- 头脑风暴华师匣子需求 需求列表脑图
- 收集竞品进入竞品分析
03.02 竞品分析
- 了解竞品功能情况
- 了解竞品市场环境 实际上校园类产品市场分析并不是主要的，很少说会与业务挂钩
- 了解竞品优势劣势
- 了解竞品使用环境 武大的主要是在微信公众平台中进行使用，而移动端APP只是辅助
03.18 需求文档1.0
初拟定了华师匣子需求文档1.0 综合需求总情况及开发难度
03.20 项目组会议
组建项目组会议，根据每个大功能点：
- 删除需求（或留在下一版） 主要从后台和安卓技术实现出发
- 增加需求 会上项目组其它成员会对匣子需求有所补充，要判定好是否是刚需还是伪需求
03.21 原型1.0
原型1.0流程图 制作过程中主要是PM和设计师打交道，确立每个页面所要的内容和实现功能的路径，必要时还会制定出ABtest。同时在制作过程中，会发现原先制定的需求能容会有不适当的地方（对于第一版来说不需要做的太细致，会增加开发压力或者是漏了某一些需要的内容比如说当前周次的修改）
03.30 需求文档2.0
根据原型1.0中出现的问题进行需求进一步完善
- 删除需求 有些太细致的需求针对第一版来说有点操之过急，如通知公告的内容搜索（刚开始的时候想通知公告是放置所有的通知公告消息并且还提供了历史记录查看的功能，但是后面想想通知公告其实实时性较强所以没有必要放置过多的通知公告及历史记录，除此之外实现的处理会将“通知公告”这本来比较低级别的版块耗费较多的精力
- 增添需求 除了是之前对功能的想法不完善，如课表中遗漏了修改当前周次的功能，同时还会有项目经理等提出其他的需求，如我们加了一个产品分享，主要是为了能够有一个平台能够展示木犀团队的优质产品
04.17 原型2.0
- 根据需求文档2.0增删的情况进行原型1.0的改动设计
- 对产品ABtest的原型设计进行整理
04.20 可用性测试
- 根据原型2.0进行产品可用性测试，检测功能实现路径是否存在问题
- 测试ABtest的路径实现，选择相对较好的一个 能够让用户更加清楚这个是什么/怎么使用，即用户体验会更好的
- 可用性测试内容学习小结 点击查看脑图
- 4步拿下可用性测试 校园通可用性测试后，在简书上发表的文章
04.27 产品开发
- 后台数据开发
- 安卓设计开发
- 视觉设计开发
- 运营内容搭建
08.18 产品验证（上线前测试）
- 产品需求验证 主要是验证是否有在开发过程中遗漏的需求
- 功能实现验证 主要是测试：1.产品各功能路径实现是否有问题 2.在不同设备中使用是否有问题 3.多人同时请求时产品时服务器能承受的压力可以多高
- 上线前测试学习小结
- 根据发现的问题进行处理和解决
08.30 产品上线
- 各大应用商店进行上线
- 华师匣子下载官网
09.02 产品维护
- 及时发现产品使用问题并解决 如多人登录会导致产品闪退等问题，需要开发人员及时了解并解决。（由于华师匣子的登录需要请求信息门户，但是由于同一较短时间内登录的用户过多，导致信息门户上的服务器不提供访问，使得一批用户无法登录。我们后台人员及时发现问题并在项目组提出，同时评估解决时间。最后考虑到解决需要一定时间，并继续推广会造成匣子第一用户体验不佳故停止了推广活动）
- 持续对用户反馈的跟踪
- 收集用户在使用过程中提出的需求 收集的需求可能是成为一版新包的需求也可能是成为二版的需求
- 有意识留住粘结性较强的用户“信息”
10.15 产品新包及新版本开发准备
11.09 华师匣子二版开发正式开始