从4月中旬开始做选股宝产品，开发一个月，测试两周，最终App在6月底上线。作为一个新人，能够有机会负责做一个全新的产品，是机遇也是挑战，路上遇到的坑坑洼洼也是一笔宝贵的财富。
话不多说，开始吧。先说说产品线的情况：
移动网页：用来App没上线前的预热、充当各种webview以及分享页面；
ios版/Android版：移动App；
内容生产后台CMS：内容生产平台；
下面我将按照立项、产品设计、开发、测试、上线五个阶段来分别进行自我回测。
大抵创业公司的立项都是CEO敲出一个idea，然后就干的吧？
这个阶段，我没怎么参与，不过也没有打酱油：一边通过处理公司内部需求熟悉公司业务，一边实战炒股同时学习各种k线图、技术指标、基本面等等知识，把自己变成股民来体会股民的心态以及行为。
然后，就是机会来临吧，总负责人皮总让我一起跟进这个项目，Let's do it
从结果论上来说，炒股这个行为也让自己做这款产品相对来说更加得心应手，因为对需求对用户理解的更深。
这时候，大抵开始了作死模式，过程如下：
和总负责人皮总沟通、撕逼产品的方向、功能；
基于上面的前提，做出了App的动态原型1.0.0（基本功能、交互完善）；
1.0.0的产品方向被CEO枪毙；
和CEO&皮总沟通，做出App动态原型1.0.1；
再被局部枪毙；
产品总负责人变成了衣肿大人；
和衣肿&CEO沟通，做出了App动态原型1.0.2，以及后台CMS动态原型1.0.0；
这个阶段总结下来，有以下几点值得注意：
1、App动态原型1.0.0生产前，我默认了皮总和CEO是想法一致的，但事实上并不是，还相差略大，这给后面不断改稿埋下坑点；
可以做更好：尤其是一个新生的产品，它的方向会直接影响到是否有资源匹配、后续的功能如何以及呈现方式如何等，因此，在开始着手做原型之前，一定要确认大家在方向上想法是一致的。如果不一致，那就“撕”到大致一致；
2、在第1点的情况下，画了比较保真的原型。但是对产品方向的想法都不一致，再保真的动态原型也无用。虽然为了缩短时间，都是通宵赶稿出来的，然而这就跟“通宵念书很勤苦”一样，感动的是自己而已，如果多注意到一层，就不会这样了。
可以做更好：建议先画手稿和决策人进行沟通，得到大致一致之后，再去画比较保真的原型图，那么很多无用功夫就可以避免。
3、竞品分析做的远远不够，无论广度或是深度。当初觉得市面上没有内容，原来只不过是因为看的少。这个项目当初是比较赶着要做完上线，希望抓住牛市行情进行推广，因此在时间上非常的匆忙。
可以做更好：在时间匆忙的情况下，对于竞品分析这块我确实没有更好的方法来解决这个问题。不过想说一点：产品经理最好是自己产品的忠实用户。这样，对于产品的可改进点以及用户要什么，都会理解的更深。不仅对1.0的原型设计有帮助，同时对1.0之后的需求迭代也会有很大的助力。
4、虽然内心以及笔头都有规划过后面的功能，但是交付研发只给了1.0版本的东西，导致技术在架构上面容易没扩展性。以现在迭代几个版本的角度看，有些地方因为加了一些功能，确实导致了页面的重构。
可以做更好：建议把能够达到稳定版要求的原型都呈现出来，这样开发在代码设计的时候就更容易考虑到一些以后可能的情况吧应该。
这阶段，可以称之为“无人领头并行工作死翘翘”模式。这部分很大原因是，没有领头人的同时追求“快”，匆忙开发。
1、整个团队的成员都非常年轻，也没有做0-1项目的经验，在产品设计、UI设计、开发过程中，都存在经验问题。但是我觉得很可贵的是，整个团队都非常合作和团结。虽然大家做的很累，但最终，都把这个产品扛下来了。关于这点，并没有什么可更好的地方，毕竟，资源有限的情况下，团队和个人都需要时间成长。
2、在1的情况下，产品设计阶段的原型图只是一个大概的图，细节和逻辑并不完善。 细节不完善存在的问题是，当初画原型图就是个短时间的事情，有些地方的交互觉得并不那么符合习惯，那么就会存在修改了某个按钮的位置，然后设计师就得跟着改，前端开发也得跟着改，然后恶性循环，大家都很累；逻辑不完善存在的问题是，我一边补充更细的边界条件，开发人员一边进行开发，那么会造成开发和沟通上的压力。
可以做更好：即使并行工作的前提无法改变，那么可以让开发童鞋们先做功能实现，再统一修改UI，与此同时，产品和设计师确认好UI，避免开发在做功能的情况下还要一次又一次的修改UI；
3、因为要快，所以很多技术上的实现，能简单就简单，能套用公司原有的的东西就套用，这个在1.0项目上没有办法。但是从迭代几个版本的眼光来看，确实在一些技术的实现上，因为之前做的太耦合，导致后面又重构。
4、在开发过程中，由于上文第2点，存在开发过程中，需求小变更的情况，但是这个变更没有落在纸上。不是说落在纸面可以免责，而是口头沟通的问题在于，不能保证各自双方记忆力的完整。同时，某个需求如果同时涉及前后端人员，而大家没有全部知晓，也是隐患的存在；
可以做更好：如果需求有变更，不管是因为产品设计原因，还是因为技术暂时实现原因进行的折衷，都需要进行对应的记录标示清楚，以便于之后查询以及后续人员的产品了解。
5、也是由于上文第2、3点，产品的某部分内容是由公司原来的管理后台生产，要满足这种工作场景，必须对其进行部分的改造，而这个改造会影响到整个公司原有的产品线的内容（网站、ios & android的App）。在第一次在改造的过程中只考虑网站，却忘记了App端，好在第一次开发量不大，但是也是浪费了人力。
可以做更好：这个充分说明了PM在进行产品设计的过程中，大局观很重要。在改造原有东西的情况下，要了解清楚原有内容影响的部分、如何适应新改造、以及改造后对原有部分的测试等。这一点，在另一文章中进行更加详细的讨论（《产品小白科普：你做产品的优势是什么》）。
6、这个产品在1.0版本的时候是没有技术负责人/项目经理来管理需求的时间评估、进度的控制的。那个时候，由PM和需求相关的开发人员进行一个个需求分析的阐述、评估时间，最后测算开发时间。同时，在项目的过程中，也是PM进行进度的跟进、各种沟通协调。
这样会造成非常大的问题：
对项目时间的预估会存在很大的误差。
对项目进度的控制会存在很大的问题，或者说混乱。
在一些技术问题的解决上，需要PM来“牵头”问题的讨论、解决，也是有点坑。
总体来说更像是团队成员之间相互推动的结果。但是从管理上来说，这并不好。
可以做更好：一个团队必须要有综合的一个技术负责人对所有需求进行评估、开发上的设计以及和技术沟通。PM可以做这些事，但是从实际上来说，是真的做不好。同时，有比较科学合理的方法对项目进行管理也是比较好的。这个，在另一篇文章中提过Scrum敏捷开发管理（《产品经理如何用Scrum敏捷开发带领团队》）。
这个阶段，不但臭婆娘的裹脚布，又臭又长，而且还不得重点：
1、产品整个1.0版本的时候，是没有专门的测试人员的，也就是说完整测试、边界条件测试什么的都是PM跟进。在iOS 1.0第一次完整测试的时候，没有经验，没有写完整的测试用例，不利于测试结果的追踪也不利于其他人帮助测试。在第二次完整测试的时候，我结合了需求和第一次的测试结果，写了很完整的测试用例，同时又让其他人一起参与了测试，总算是提高了测试的效率。
可以做更好：
要有专门的测试大人！专门的事就让专业的人做，这样总体性价比才会比较高。
在没有测试大人的情况向下，PM要兼顾测试工作，那么一定要写很完整测试用例，包括行为、页面、期望值、测试结果、开发反馈、回测结果等等。
在完整测试过一次之后，就可以发起其他人帮助一起测试，测试用例云协作，提高测试效率。
2、测试也需要全局观，这个在第三阶段开发中也讲到过。
举个例子：利用原有管理后台的发送新闻功能，把某条新闻发送到一个选股宝平台中。临近上线前1天，研发人员把对原管理后台的改造给完成，但是当时我的注意力都选股宝的移动网页、后台CMS的测试中，并没有对改造的部分做非常严谨的验收测试。可是，原后台的改造才是最需要测试的部分，因为它涉及到了公司原来三个端的产品内容正常呈现。
3、很无奈的一点，精力有限。没有专门的测试的情况下，只能由PM来测，但这样，产品2.0的功能以及逻辑、竞品的了解等产品工作就往后推了，等上线完，所有的工作都停在了产品阶段，OMG；
上线前要考虑非常多的因素，包括：
上线的时间；
对用户的影响；
上线的东西是否测试完全；
上线需要准备的数据库迁移、服务器等等是否ok；
上线如果遇到问题，是否有有相关人员stand by；
App产品上线前就需要确定相关的素材是否准备充足；
上线是个需要非常谨慎对待的事情，谨慎！谨慎！谨慎！
好了，关于我们产品1.0的回测就到这里。希望以后有机会针对每一个坑能够进行一一分析^_^
本文由 @梁露瑶（微信公众号：killifer） 原创发布，未经许可，禁止转载。
|
