Bookish产品经济学今日看点

我的产品元年:经验与迷茫

2017-03-13  本文已影响70人  Bookish_陈键

职位:产品助理

入职时间:2016年3月01日

就这样,工作一年了。曾经对产品经理有着极大的好奇和各种yy。真正做起来,才明白到底产品是个什么样的工作。

如果你想知道我这一年在做什么,就看吧,流水账,不想看就算了。

先说一下我们项目组的背景,我们做的是一款企业内使用的IM,我们没有测试工程师和项目经理。所以产品经理其实是身兼多职。而偏偏,我又是一个不太懂技术的产品狗...

工作到现在,我的任务分为几大类:测试、任务推进、功能策划、需求管理

一、测试工作

如上所述,没有测试工程师,产品只能由策划手动测试。测试包括:每次更新前的常规测试,需求完成后的回归测试,其实就是验收一下。

常规测试,有常用的测试用例,这些测试用例包含了大部分常用功能以及以往修复好的大bug。同时还要过一遍这个版本修复的bug和新开发的功能,保证这些功能达到发布的程度。

验收测试,是在每个需求实现之后进行测试,包括bug的修复和新功能。

关于测试的一些经验:

1、如果是新功能,首先要了解功能解决的需求、看懂策划文档。

2、编写“测试用例”、常规操作。在看懂了策划文档之后,需要编写测试用例。测试用例需要打双引号,因为这并不是真正意义上的软件测试,我们所做的用例仅仅是操作层面的,而不是在代码逻辑。所以,有很多东西未必能测出来,但是也要做啊,这就是真实的工作!写用例可以缕清思路,测试的时候会更加全面。

3、想象异常情况,暴力测试、网络异常、功能冲突等。由于不懂代码层面的东西,因此我们要做更多的是模拟真实场景,找出一些使用中可能会出现的bug。

二、任务进度追踪

所谓跟进,其实就催研发干活。话说回来我们的程序资源还算不错,一个内部项目小组有专门的程序员,不需要跟别的项目共用。而程序做的每一项需求都要有专门的策划负责跟进。

每个程序在每个版本不止一个需求。如果你不说,他就有可能忘记做。也有可能认为优先级不高,所以一直拖工期。

所以策划需要每天了解程序有没有在做那些需求。产品是个不要脸的工作,有些程序和设计师的资历比我还深,可是为了工作必须厚着脸皮不停的去催,因为他们不做,最后拖工期的锅就是我的。前辈说,程序干得慢就是因为策划不够强势。虽然不想认同,但现实好像就是这样。。。

这也是我的缺点,我确实不是一个多么强势的人。然而,我需要一遍遍的去问他们做的怎么样,做到什么程度。甚至一些技术上的逻辑我也需要了解,要不然,领导突然问起来,答不出,又要怼的还是你!就这么苦逼。

跟进的方式:

1、企业内部IM骚扰。每天问,相关的人员可以拉个讨论组,有什么事情在讨论组交流,这样效率会更高。

2、让他们定个deadline,其实程序很讨厌这样,因为现实情况是经常会有新需求插入,程序不能保证只做一个需求。因此,策划还需要了解程序手头上有那些需求,以及这些需求的优先级。

3、盯着他们做。这招对设计师比较有用,因为你不知道他做出来的东西能否满足你的要求,而你其实是可以看着他们做的各种效果的,这就免得他们出N多份效果图了。

4、找头儿。有些程序是共用的或者是其他组的,例如服务器的或者一些插件的。这些找程序,他们可能不怎么搭理你,这时候就要找他们组的策划,最好是比较资深的那位,让他们帮忙安排工期。

三、策划工作

这一年来可能做了可能有十来个小功能的策划案吧,实现了的可能就一半半吧。

因为是新人,经验也不足,所以只能做一些简单的、次要的功能。其实很多时候你做过的东西还要老同事帮忙检查,实际是加重了别人的工作量。

关于策划这一块,理论上也应该是一个产品策划真正的价值体现。

我做的是内部使用的产品,没什么机会接触市场,用户也不是很多,再加上原本已经比较完善的了,所以做新功能的需求自然也不多。有进一步的优化也不是我们能handle的。

我个人对于策划这方面的想法自然也不够成熟,但还是总结一下吧。

1、明确需求。明确一个功能需要满足的各个需求是策划一个功能的第一步。有人说产品是为人们的某个问题提供解决方案的,因此清楚要解决的问题是关键的一步。

2、竞品分析。无论新人还是老油条,研究竞品都是不可忽略的一步,有种说法是“不要重新设计轮子”。所以竞品分析是一定要做的,还要多做,分辨出那种解决方案是最有效的,甚至是将这些方案混合创造出有效的解决方法。

3、保证业务逻辑和细节。为了装逼,新人最喜欢搞一些动画等高保真策划案。当然,公司有要求的,这样做无可厚非。但是不能把过多时间放在视觉效果上,逻辑才是最为重要的,要是逻辑不够严谨,程序根本没办法工作,他会不断跑来问你这种情况应该怎么处理?大大降低了工作效率。多考虑一些情况,不断推敲逻辑上是否有bug,其他交互效果能一句话带过的,加句描述就行。

4、交互、界面设计考虑清楚。UI应该是设计师做的事情,不过很多设计师是照着策划的方案画UI的,这样他能完美的躲过策划的责难。所以策划要想清楚各种效果,同时要会say No,对不好的设计方案尽量不要容忍,让设计多出几份效果图。他们出图其实很快的,但是要有理有据,有时候只说一个“丑”字,又真的让设计师挺难做的。

5、考虑特殊情况。策划案毕竟还是策划案,实际效果未必有那么顺利,多考虑真机中存在的问题,例如网络异常、设备权限等相关影响因素,一并写在策划案,让程序处理,这能减少一些bug。

6、策划案要简洁明了。我发现很多程序看策划案十分粗心,某些文案明明写出来了,他却没看到。所以还是要用图说话,尽量简洁易看,注意字体、排版之类的问题。

四、需求管理

十二月份,小组的执行策划调去其他任务,我也开始要管理整个项目了。这方面的经验也是不足,还有很多可以提高的空间。我个人只有一点点经验:

1、每周编写任务清单。很多公司其实会开早会,以前在创业公司也是每周例会,但是张小龙也说了,移动网络这么发达,也没什么必要天天开会了。所以我一般在群里发布这一周的工作任务,之前试过每天写,感觉太浪费时间了,每周一份,这周内不断更新,到更新日期检查下所有任务,感觉让大家明白要做那些事情就可以了。

2、明确优先级和负责人。优先级肯定要写清楚的,很多人都知道四象限法,把任务按紧急性和重要性划分,不过我觉得三个等级就够了,优先完成的,重要的(尽量完成),一般的(可以拖)。优先级其实是在帮程序减轻负担,但PM要考虑清楚什么需求更重要。

3、需求细分。所谓WBS,把一个任务分作若干任务,逐个完成。这很头痛的,因为我不懂技术啊,什么应用服、web端、什么接口、插件,这些东西我自己都懵懵懂懂的,完全搞不懂程序要干些什么。那也只能去问程序了,“稳食艰难”啊!

做了一年,我自己也是有点动摇了,我一直在问自己到底适不适合这个行业?

不自信首先来自于技术的缺乏,太多相关的技术不熟悉了,也没有什么人指路,纯粹是野蛮生长。其次是我看不到自己的价值,这很难受。我做公众号可以看阅读量、粉丝数,评估自己的工作做得如何。但是做一个内部产品,几乎没有任何成就感可言。没有任何数据可以体现你的价值。

我相信一个人的价值是可以用金钱来衡量的,而我呢?没有为公司挣到钱,也没有为自己挣到钱。继续这样下去,我很怕我会贬值。我只能通过不断加班,做一些可有可无的工作,体现自己的辛勤,我知道这是自欺欺人,人人都可以做到的事情,你做到了,并不能显示你的价值。而你又有什么是别人取代不了的呢?唉,这是问题。

上一篇下一篇

猜你喜欢

热点阅读