产品研发过程中经历的一切工具或事项，都是为了确保产品高质量按时上线。那么在产品研发过程中，有哪些环节是必须经历的，下面我以我最近负责的一个产品为例展开说说。
这是一款关于智慧幼儿园的B2B2C产品，软硬件结合，作为幼儿园和家庭的桥梁，这款产品主要功能包括园务管理、家校沟通、亲子作业、学生考勤、宝宝课堂等，分设园丁版和家长版。刚开始接触到产品需求，心里没底，毕竟之前没有类似产品的实践经验。可以说这是我第一次正式接触原生App开发（IOS&Android），心里充满期待，但也没太大把握。好在这次只是在旧版上重构，并非从0到1的项目，部分关键功能的雏形已经有了，只需要在优化交互设计及用户体验即可。但也有新增的功能模块。
从信息架构到原型设计
从老板处拿到一份简单的功能需求文档，虽然我在拿到文档的第一时间向老板确认了产品需求，但是没有花时间投入去梳理信息架构。由于对产品的不熟悉，在原型设计上耗费了不少时间。
初次接触产品，唯恐对产品设计的时间把控不到位，同时又不明确原型的验收标准。在原型设计上，所以采用了取巧的方式，即截图，并在截图上修改。这种做法比较吃亏的地方在于，对产品没有形成很系统的认知，很容易造成东补补西补补的零散经验。
事后反省，是因为没有主动给自己梳理高标准高质量的要求，才会导致原型呈现零散拼接的后遗症。所以在复盘的时候，也初步给自己在原型设计定了要求，比如说：1.好用的交互设计，2.有必要的交互说明，3.有简洁的文字说明，3.高保真或低保真
从原型评审会议到制订项目进度表
原型评审会议一般都是安排在原型设计完成之后。我认为，原型评审会议所起的作用至少有两个：一是初步告知产品项目相关人员，要做一款什么样的产品，需要什么样的资源；二是初步讨论研发这样一款产品可能会遇到哪些问题，需要如何去解决。
这次产品的原型评审会议上，几乎召集了开发部所有人员参加，包括产品、前端、后台、客户端、测试、UI等。第一次面对这么多人评审，多少有点紧张。在阐述原型设计思路时，由于对产品需求理解不够深入，竟然有一两次回答不上开发提出的问题，导致尴尬的局面发生。事后反省，大多是因为会议前准备功课没有做好，对相关人员可能会问的问题没有考虑周到。这点值得再三磨练。关于相关人员可能会遇到的疑问，大致可以罗列如下：
1.对所有相关人员：新版本和旧版本在功能上有什么不同？新增了哪些模块？有哪些模块是不用重新开发的？
2.对于UI，新版本页面基本上都要重新设计，所以他们关心更多的是设计稿本身的质量；
3.对于后台，最关心的是接口问题，旧接口是否可以重复利用？
4.对于IOS&安卓，UI页面什么时候设计好？接口什么时候写好？交互说明是否明了？产品需求是否明确？
5.对于前端，有多少页面需要重写的？需要利用到哪些框架？
......
原型评审会议结束，作为产品经理，需要承担一部分项目管理的工作，我着手制定一份详细的项目进度表，包括模块负责人、开始时间、完成时间以及预计用时。实践证明，这个表对跟进和把控开发人员研发时间的作用并不大，因为每个开发人员的习惯不一样，比如说：有些开发人员习惯评估好时间再投入开发，预计时间和实际开发时间有出入；也有些是开发完之后再给确定时间，这样时间需要准确，但是容易导致项目失控。所以事后反省，项目进度表还是要做的，具体时间需要和开发人员沟通好，至少要评估出一个大概的完成时间。
关于项目进度表，意外发现一个重大的作用，就在于帮助测试人员再测试过程中发现bug后能在第一时间找到问题负责人。
从UI设计管理到项目进度会议
这款产品的UI设计有专门的团队来做，这样有个好处就是，产品经理可以花更多时间在协调沟通上。其实在UI设计的过程中，设计师也会遇到一些产品上的问题，比如是页面展示、交互设计，一环紧扣一环，所以跟进沟通也显得必不可少。有时候，在与UI沟通的过程中，也有可能萌生出更好的创意。
在UI页面设计方面，首先要做的是确定首页的风格，从而确定整套app页面的基调。由于UI设计涉及到创意，相对来说，完成时间难以评估。所以需要充分考虑现实情况，其包括设计师的能力以及习惯。
至于UI设计的审核，从大的方面来看，无非离不开逻辑、风格以及表达的含义。小的方面来说，就是对齐、重复、对比、亲密性。在这款智慧幼儿园产品来说，采用的是绿色为基调
关于UI页面管理，我们统一使用蓝湖。
产品投入研发，每周的项目进度会议显得非常有必要。很多潜在的问题，或者有疑问的地方，都可以在会议中抛出来，经过群策群力，找到最佳的解决方法。比如说，这次项目最突出的问题，后台写接口的速度远远赶不上客户端开发的进度，而且有些接口还存在问题；这些问题一一在会议上得以反应，也为产品负责人知悉情况并且进一步安排工作提供了便利。
在这里，作为会议主持人，我总结了几点心得及技巧：1.会议只找相关人员，2.预估所用时间，3.开会地点，4.提前告知会议内容概要。除此之外，作为主持人，在开会之前的准备工作一定要充分，至少要提前揣摩可能会出现的问题，避免会议出现尴尬的场面。
会议结束之后，建议梳理一份会议记录，分享到群里面。主要是为了告知与会人员，会议讨论了哪些内容；作为记录，避免重要事项的遗漏。
从代码研发到验收测试
在这次app 研发中，投入了3个ios，3个android，3个测试，8个后台，但是后台提供接口的速度还远远没跟上节奏，而且写出来的部分接口存在问题。
对于代码研发的理解，我的经验是基于数据的储存、分布以及流转的基础上。再深一点的话，稍微涉及到代码的业务逻辑。在智慧幼儿园项目中，我们采取的是前后端分离。后台只需要提供接口，并确保接口高质量即可。客户端开发人员在接到UI设计师提供的页面，并结合原型的交互设计，以及后台提供的API接口，制作App页面，拉取或推送相关数据。里面涉及到UI页面的切图、以及原型的交互说明，甚至于产品需求的确认，以及API接口的质量。
在核心功能研发出来后，并同步投入测试：IOS园丁版和家长版，Android园丁版和家长版。关于bug的管理，我们统一使用禅道。我觉得，测试是一门技术活。既要求对产品功能、设计流程熟悉，也要求有一定的代码查看能力。比如说前端操作后，后台需要返回什么数据，返回的数据是否存在不妥；以及后台写的接口是否存在问题，存在哪些问题。
在这次产品研发测试中，包含IOS和安卓端在内，测试人员总共发现将近600个bug。但令人欣慰的是，开发人员在规定时间内把这些bug全部消化掉。
从发包到用户运营
测试，修改bug，确定没问题，发包。等待各应用商店审核，以及收集用户反馈的问题。一般来说，IOS的审核机制相对严格，所以等待的时间也会长些。由于产品是软硬件结合使用，所以有些问题要等到幼儿园实际使用过程中才能发现的。最先反馈问题的是来自肇庆的一位业务员，问题是刷卡考勤，产品上没有显示记录。除此之外，河南也有业务员反馈，相册发布不了照片，但是在其他区域却能。等等诸如此类的问题，对于产品的迭代来说，无疑是一份珍贵的一手资料。
只有经受起市场和时间的洗礼的产品，才能算得上好的产品。产品上线，意味着说产品的生命周期才正式开始。
网友评论