一个开发者到项目管理的角色转变 | 掘金年度征文

2,272 阅读31分钟

写在前面

本文是我个人关于工作的2019年度总结,同时也是一个初领团队的项目管理者的心路发展历程。

本文内容主要以项目驱动,通过梳理这一年来我们团队做的事情,讲述了一个新产品如何从0到1的过程,也包含了从个人开发者和项目管理者角色的转变,带来的二者思考方式上的区别,以及具体工作内容发生了什么样的变化。

希望想要转型TL或者PM的技术者们,通过我的真实案例,可以有所收获。

同时我也希望,自己通过这一篇长长的自我剖析与总结,可以在新的一年有更积极的转变。

首先交代一下,我们是一个十几人的创业团队。众所周知创业公司有其缺陷,比如流程不规范,招人难,团队人员水平参差不齐等等诸多问题。但我们也有大公司没有的优势,我感受最深的就是,因为没有繁琐流程限制,所以做事自由,想法产生到落地,这个过程非常迅速。

而我们公司更是非常民主自由,老板本身就是个很能服众的管理者,加上他奉行无为而治,平时基本上不过问工作细节,所以我们得以像一群脱缰的野马,有啥新奇的想法冒出来,干就完了,几乎不受任何约束。除非方向跑的太偏,老板会过来拉一拉,在具体执行的问题上,我们每个部门都有绝对的自主权。

而我在去年年底,接下了网站组的管理职责,我们部门负责公司所有互联网产品的开发和维护工作。

以上是背景,接下去,就开始正文模块。

1w字长文预警

自从在去年年底接下了管理整个部门的责任之后,感觉承担在肩上的东西重量呈非线性增长。一年下来,至今为止最大感受就是,疲惫,整个人的精力被四分五裂

刚接手的时候,因为一些复杂的人员变动,部门有段时间就我一个全职员工加上一个后端实习生。我的主要任务是盯好一个烂摊子,维持产品的稳定。当时的主要产品线上问题频出,在不开发任何新功能的情况下,几乎都无法自运转,前端我顺手就给重构了,而后端代码一堆坑,在人员储备不足的情况下,我们根本不敢大改。

那个实习生是一个非常让人省心的孩子,他当时才大三,来公司已经实习一年,完全可以独立负责业务,而且虽然不是全勤工作,但出了问题的时候,不管是在上课时间还是半夜凌晨,都能迅速作出反应,几乎能独立完成公司这边提出的所有需求,就算不会,也能快速学习并很快上手。

不过他当时已经确定毕业后不留在公司,而是选择出国的,虽然我们都很希望他能留下来,觉得他靠谱,能干,学习能力又强,不过我还是双手支持他的决定,毕竟他还很年轻,而且正当人生的岔路口,前方道路条条通罗马。而他在做了决定之后,还在公司呆了很长一段时间,我能感受到他真的是出于想帮我一把的想法才一直拖着没走,毕竟新招的人上手没那么快,我们还有那么多条业务线,加上一堆前人留下来的代码shi山,其实如果他不在的话,我肯定早就坚持不住崩溃了。

那是一段很艰难的阶段,憋屈,恼火,可是又无能为力。不过还好,我们俩一起熬了过来。

过年前后,公司先后入职了两位全职的得力干将,主要都是负责后端业务,我也得以从后端业务中抽身,可以专心做前端的事情。那位实习小朋友也在两位新同事对公司业务基本熟悉了之后,在五一后安心回到了学校,准备出国的相关事宜。在这里祝福他前程似锦,他一定会变得非常厉害!

之后事情就逐渐走向正轨了。我们还在年中,入职了一位全职的算法。

现在,算上我自己,我们整个部门有了4个人,前端后端算法,麻雀虽小,五脏俱全。

不过,随着人数的增多,我逐渐发现所需的管理成本也在逐渐升高,我需要在团队管理上花的时间也越来越多。

首先是任务分配问题

依照去年的工作惯性,我只需要偶尔询问进度,把控一下整体开发节奏即可。在当时,因为各自负责的任务相对独立,所以不管进度把控还是进行一些细微的迭代,我们基本上能对自己的工作完全负责。

我对团队成员的要求是前后端都需要一个人独立完成,每个人对自己的模块,不论是在功能还是进度上都需要负全责,比如我负责网站A的开发,他负责项目B的开发。这样的好处是某个业务线进度慢了或者出了问题,责任人一目了然。同时各责任人可以自由安排开发任务,极大减少了沟通成本,也减少了因为任务串行导致的阻塞。

而现在,这种方式逐渐变得不可行。

让团队成员的每一个都有前后端开发的能力,本身这个想法就太过理想化,合适的全能人才可遇不可求。招人的时候如果钻牛角尖非全栈不招,那么对于本来招人就困难的创业公司,找到合适的人就更是难上加难了。

所以最符合实际的情况是,每个人都会有自己擅长的领域,让成员做擅长领域的任务,才是最符合实际的方式。所以,在任务分配上,由过去的按业务线负责,改为了按技术模块负责。

进而,我就需要投入更多的时间,对项目做全局性的规划,逼迫自己从更宏观的角度思考问题。

一个人的时候拍脑子想需求,实现需求,最后放入市场检验,这个流程可以非常迅速,检验不对就重新想重新写。

但是当面对一个团队的时候,需求可就不能拍脑袋想了,决策要尽可能对团队成员负责,否则一旦发生推倒重来的情况,就是对整个团队资源的极大浪费,而且容易滋生抱怨情绪,打击团队的士气。

所以在规划需求的同时也要给出充分的设计理由,这样才能降低不合理需求出现的概率,而就算时运不济需要推倒重来,大家相对也能更好的接受。

这个时候就要求我花更多的时间,投入更多的经历,对项目的大方向做梳理,提出的需求和迭代方向要足够明确,保证让其朝着正确的方向发展。

另外,团队在不断壮大,那么在管理上,不可避免的,就需要引入一套绩效考核机制。

我们无法保证所有的团队成员都抱着公司创始人的心态为你卖命工作,而对于开发部门来说,因为开发项目的回报周期通常都比较长,和公司利益相关的指标,比如说收益率,用户增长率,在短期内很难有质的变化。

我们日常做的大部分都是很细碎的功能,比如在首页增加一个点赞功能,增加一个评论功能,这些琐碎的功能优化在短期内对用户增长的影响实在有限。

对于程序员群体,他们更关注需求如何实现,如果直接用用户增长,收益指标去试图激励,可能并不能起到很好的效果。

对于程序员的激励制度一直都是业界一个比较难以判断的事情,而这又非常必要。至少,我们需要对成员到底是在“调研技术,认真工作”,还是“浑水摸鱼,得过且过”,进行精准的判断。先不论惩罚与否,至少,对于努力工作的高效员工,不使用激励手段进行工作态度和能力的区分,绝对是不公平的。

我在这部分也经过了几次摸索,现在依然处于尝试阶段。我认为激励制度之所以有效,核心就在于及时性和公平性,围绕这两点,我也思考过很多指标,比如bug数量,代码数量,任务完成数量,任务重要程度等等,但终归是各有各的局限性,可以说没有一个单一指标,可以衡量一个开发者在当前团队是否表现最优。

当前正在实施的措施,是某次参加的技术管理者分享会的收获。主要内容是管理者需要瞻前性地列举任务清单,每个任务都有相应的属性,如优先级,难度,重要性等,然后让成员定期认领任务,同时规划好开发时间,根据任务的属性,和实际开发时间,来对任务的负责人进行奖惩。

这种方式主要是对管理者的精力投入,和评价指标的合理性取了一个均衡。因为人少,虽然制度目前并不完美,但是目前执行起来还算取得了不错的效果。

不过呢,我也不可避免地,在对任务做重要性,难易程度,开发量的评估上,投入了更多精力。

以上是管理团队上,相比于去年的调整优化。在实际业务上,我们也做了很多的尝试和创新。

因为团队扩大,公司对我们部门的期望变得更高,对我们也提出了更多的业务需求。

大概在3,4月份左右,老板提出想开辟一条新的产品线的想法。不过在当时那个阶段,老板只是一个初步而宏观的构想,我们也只是接受到了“我们要做新产品”的这个信息,具体做什么,怎么做,如果类比新生儿的诞生,那新产品就还处于一个“备孕期”,谁也不清楚。

接下去的这段时间,因为涉及到更多协作的环节,对各成员之间代码协作就有了更高的要求。我们对整个开发流程做了不少优化,同时也开始引入了一些协作工具。

对旧业务上,我们对系统主要做了以下事情:

  1. 对之前旧系统在使用上进行了一定程度的优化,增加一些锦上添花的功能,并对性能做了大幅提升.
  2. 推出了主要产品(集智学园)的小程序版本。
  3. 追加了一些数据记录,做了一段时间的数据分析
  4. 对去年推出的产品进行了一个大版本迭代(星空图v2.0),同时也跟进了用户数据的变化。尝试培养用户使用新版本的习惯,不过应该算是是失败了,用户普遍反馈使用不习惯,产品数据上也不太乐观。

以上不过是小打小闹,所有业务都没有脱离原来的基础,后端代码该Shi还是shi,加上旧数据混乱,表结构复杂,表字段冗余,虽然整体功能在我们修修补补的进程下趋于稳定,但还是偶尔会出现陈年老坑,把我们雷的外焦里嫩。这里如果不拦着我,我还能再吐槽8000字。

关于旧系统,我们也不是没想过重构,不过公司大方向上的态度是,不要在上面花费太多精力,只要用户使用上没有bug就可以,不需要增加新的功能,更不需要花时间去重构。因为用户是否认可产品,关键还是内容。我们平台的内容太过分散,不成体系,导致用户留存率低。

而现实情况也是,我们通过一系列的优化手段,改善体验,改善性能,对数据的影响却小的可怜。

在旧产品上挣扎了一段时间,我们全组人就逐渐把重心投入到了新的任务中。

就这样,我们开始了全新的产品线

翻了汇报记录,发现新产品是从今年7月份正式开始规划,进入日常工作流程的。

新产品架构上,计划和原有系统完全独立,使用到的后端框架,数据库,搜索引擎全都是新的,光是技术调研就花了很长的时间。我们接受到的信息关键词是:海量知识(论文)资源爬取,论文关系是重点,知识网络/体系等,最终调研后确定了一系列技术,后端框架由Yii改为laraval,引入electic search做为存储论文和搜索的工具,引入图数据库neo4j用于关系存储,还有爬虫框架scapy用于爬取外部资源。

一开始的时候,没有任何产品形态,就全公司人听老大拿了张思维导图,咔咔咔讲了一堆很宏观很牛逼的东西。听的时候觉得对对对就是这样我们一定能成功!听完后回到工位打开电脑一脸懵逼:所以我要做啥?

我一向对我们部门的定位是研发,可是当面对一个全新产品概念的时候,如果只有开发人员的话,所有人都会是一筹莫展的,所以非常需要有个人来思考产品功能的设计,并且对整个产品流程负责。当然,招一个产品经理对我们来说肯定是奢望。

我想既然我们是作为产品的主导者,而我又是部门的负责人,那产品设计工作就由我撸起袖子承担起来好了。在这个时候,我才真正接受了对我们的“网站组”这个称呼。

就这样,我从一个项目负责人 + 前端开发,变成了产品经理 + 项目负责人 + 前端开发。除了其他项目对小组成员的开发进度跟进,以及前端任务之外,我还需要思考这个新产品要如何开始。

于是,我就开始了基本上每天一睁眼脑子就开始围绕新产品思考各种各样的问题,从一开始的宏观层面:

产品面向用户群体是谁?

他们的需求是什么?我们要如何利用我们的优势为他们服务?

产品长远目标是什么?短期目标又是什么?

什么功能是核心的重要的,什么是不重要的?

用什么样的产品形态可以达到我们想要的效果?
....

到后阶段的微观层面:


这块的操作这样是否合理?别扭的交互如何优化?

当前模块使用什么样的组织形式会更好?我们要展示哪些详细信息?

什么功能是没有围绕长远目标,需要舍弃?后续如何展开推广?

第一批用户怎么样才能正确认识到我们产品想要表达的概念

....

有太多需要明确但是却很难明确的事情。

说实话,这件事情真实做起来的时候,难度的确出乎了我的意料。最大的阻碍在于,很多事情在真的做出来之前,无法判断其是否正确。老板能判断什么是不想要的,但也无法明确说出什么才是想要的。把老板脑子里宏观的概念恰当的落地到产品功能,这一步确实很难。

期间还遇到了很多很多的问题,技术问题,架构问题,功能问题。技术不会的就学,遇到了坑就解决,解决不掉就讨论是否有替代方案,功能效果不好就改。。我也知道整个团队都经历了一段非常不容易的阶段。不了解这个过程的人只会觉得,我们把一个产品从无到有做了出来而已,不会理解期间我们走的路有多曲折。

接下来就让我来重点讲一讲我们新产品的孕育过程

从0开始

要从0开始考虑一个产品的进程,首先要考虑产品整体方向与公司整体不出现宏观上的偏差,宏观方向当然是老板给出的。那从宏观方向落地到具体产品形态这个过程,需要经过大量的方向和需求讨论。

我记得光是确定产品名称我们就开了好几次会

最终在一个阳光明媚的下午,我们确定了“集智斑图”这个名字。斑图为英文单词pattern的音译,pattern在复杂系统中特指大量相互作用单元涌现出的时间空间模式,集智斑图取自其衍生意义,指学习者在探索互动中形成的知识空间和集体智慧

如果你对我们集智俱乐部有所了解,你就会发现这个名字起的恰到好处。

随后我们逐渐确定了产品的一系列属性:

  1. 长远目标:知识爆炸时代最便捷的跨学科学习探索平台
  2. 阶段性目标:复杂性科学领域自组织学习平台
  3. slogan:用知识连接探索者

知识,意味着我们要建立一门学科的知识体系,而初期,是要在在复杂性科学领域落脚

连接,意味着我们希望用户之间可以形成关系网

探索者,意味着我们的用户群体特征,是一群渴求知识,并且有自驱力的学习者们

用户调研,设计原型图,确定功能模块

由于我们有先天优势,通过长期的集智俱乐部这个品牌运营,得以聚集了数量庞大的目标用户群体,甚至老板本身就是一位长期学术圈的大佬。所以用户调研的对象资源非常丰富,获取用户当前的痛点相对比较容易。

用户痛点:

  1. 一个研究者对于自己领域论文的检索通常驾轻就熟,知道该去什么地方可以找到需要的论文。然而,当他要进入一个陌生的领域时,他就无法像在自己领域中一样如鱼得水,迅速定位到想要寻找的目标。比如说一个计算机领域的研究者,他的算法研究涉及到了基因网络,他想查找一下生物领域相关的背景知识,如果这个时候没有人指点,那在庞大的互联网信息中就非常容易迷失,不知道该去哪里找,就算找到了,他也无法凭借一己之力判断,这篇文章是否权威。

  2. 一个研究者,想要转变课题,或者单纯对某个领域感兴趣,想要了解这个领域的基本框架组成。同样的,如果没有相关的导师指点,他就很难在互联网上正确地获取比较系统的知识体系。就算通过自己探索和自学,最终获取到了这个知识体系,那也一定费劲千辛万苦。

用户需要的,是一个知识体系完整的平台,在这个平台上,他可以获取陌生领域的最新进展,用以补充自己的研究,或者获取有利于自己研究的信息;也可以获取这个领域的经典论文,得以快速,且正确地入门这个领域。

而接下去的工作,如何将痛点转化为产品需求。就是一件相对比较棘手的事情了。

首先是内容展示形式

通过对痛点的分析,可以得出,我们要打造的是一个知识平台,我们需要把当前互联网中,某个领域零散的知识整合在一起,用这种方式去形成知识体系。

那么什么样的知识体系对学习者来说是最优的?

备选列表:

1. 一篇对知识进行整合说明的文章:

优点:技术上可操作性强;对某一个知识点展开说明的空间很大,不受格式显示;对于内容生产者来说,符合传统生产内容方式,更易被他们接受;

缺点:只能表示知识的线性结构(从上而下的说明),知识体系结构性不够强;对于知识的接受者来说,展示形式不够精准,可能会导致理解上的困难

2. 思维导图:

优点:结构性强,直观明了;在宏观分类下表现优异

缺点:思维导图本身“强分类”的局限性,随着知识库复杂度的增加,交叉知识点越来越多,思维导图就越发难以表示两个从属不同的大类下,细分领域知识点之间的相关性,而实际情况是,就算是相去甚远的两个类别,他们包含的内容之间也会有可能出现高度相关。

3. 双曲空间:

优点:足够创新,可以作为一个产品的强大优势;足以表现知识网络的复杂,;算法 + 人工,可能会让知识结构涌现出无法预见的奇妙特性

缺点:实现成本高,目前的双曲空间嵌入技术几乎没有在工业中的成熟应用,我们需要做第一个吃螃蟹的人;对于用户来说,也是一个需要学习这种空间的含义,需要有一个相互适应的过程。

一开始我们选择了双曲空间,觉得这种形式最符合我们的要求;我做了一个非常简陋的双曲空间原型图,然后经过了一圈用户访谈后发现,收集到最多的反馈,要么就是不知道这种表现形式代表了什么,从而质疑产品本身的意义,要么就是表示非常认可,但对于最终的实现效果存疑。

推进了一段时间后,技术瓶颈的确不小。而且除了知识底层体系的展示问题,还有其他许许多多的问题都亟待解决,比如针对某个知识资源需要扩展什么额外的功能,用户和产品的接触点是什么,如何让用户来到我们平台后产生粘性等等。

最后,在双曲空间上花了1个月左右探索之后,最终我们还是决定先选择最保守的策略:使用文章来表示知识结构,一篇文章即代表一条知识路径。等我们把所有的逻辑都明确,并且走出一个最小产品原型后,再去考虑使用双曲空间,单独对内容模块进行迭代。毕竟不能一口吃成个胖子,还是应该小步快走。

在确定了内容展示形式后,次重要的,就是需要确定内容来源的获取方式

通常一个做内容的平台失败,80%的原因要归咎于内容生产环节出了问题。

首先知识资源的获取。对于研究者而言,学术论文可以说是最重要的资源了,另外还有书籍,视频课程等。既然要做到丰富,完整,那依赖人工去收集肯定是不现实的,尤其是论文,光是arxiv每天更新的论文就上千篇了,所以论文是一定需要自动化去获取的。书籍和视频课程,可以考虑做成手动添加入库的形式。 在有了知识资源之后,接下去的的问题就是对资源进行整合了。在上一个环节我们已经明确了使用知识路径来对知识进行整合,既然我们立志做知识体系最完整的知台,那如何产出这些知识路径呢?

如果自己生产内容,虽然质量易把控,但制作成本高,且来源少,而且从内容生产到平台服务,整条产业链太长,对于一个小团队来说精力太过耗散;之前的视频学习平台就是一个很好的例子。

如果使用UGC(用户生产内容):把内容生产权完全交到用户手中,试图从用户中涌现优质内容,问题就更多了。首先就是直观的冷启动问题,前期很难积累优质内容,而且在内容不够充足和优质的情况下,如何吸引第一批优质用户?稍有不慎就会陷入没内容——>无法吸引新用户——>内容产出更少的恶性循环中。其次是我们对内容的要求比较高,不是所有人想产出就能产出的,我们甚至希望来平台产出内容的人在业内都具有一定的权威,否则对于学习者来说,这份知识整理甚至会产生误导性。

另外还考虑到,我们也不希望出现两条相似的学习路径,这样对于学习者来说,依然会面临没有指导情况下,选择困难的问题。

最终决定,我们将路径的创作是一个半UGC的形式,我们还是要依赖已有资源,邀请业界专业人士为我们的平台贡献内容,尤其是前期,一来能奠定我们高水平内容的基调,二来可以利用这些影响力大的用户,吸引更多的用户入驻。

而我们允许任何用户自生产内容,但这些内容除了除非经过筛选,否则不会被暴露给其他用户。这样我们对内容就有一个绝对的把控权,我们还是期待能从用户生产的内容中涌现出足够优质的内容。

我们还在当前框架基础上,利用我们举办读书会出身的优势,增加了对知识资源的解读模块

用户可以对任意知识点(论文,书籍,课程等)发起一场解读活动,有完整的申请,报名等活动流程。

确定基础模块后,就进入了开发流程

说是开发流程,其实基本上还是在频繁地提出需求修改需求需求。因为原型图和真实实现的产品效果还是差的比较远,而且很多操作都需要深度使用了才能判断其优劣。

而且还有大量的细节功能,都是在开发过程中才确定下来的。如评论,评论回复,点赞,收藏,与之相对应的站内通知,还有用户间的关注等互动等等。

为什么不等原型图确定了再进入开发流程呢?

的确对于一个正常的产品来说,应该要经历:用户调研——>设计原型——>设计稿——>开发——>测试——>上线,这样一个完整的过程,如果原型确定不好就往下走,那么后续的设计和开发步骤,都会有因为需求变化而导致工作重构的风险。一开始我也计划先确定好原型图,敲定所有需求细节,然后再进行开发工作(我们没有设计)。

而在一开始的时候我也的确把主要精力放在了用户调研,分析需求,画原型图上,每次组织讨论也都是对照原型图来讲的,期间还对产品形态做了一次重构,我还很庆幸自己没有着急进入开发流程,导致开发重构等不必要的资源浪费。

不过随着产品形态的逐渐明朗,当确定了产品的基本架构,但是还有很多细节需求还没有确定的时候,我发现我如果还在原型图上扣细节,比如我现在想加个点赞和评论功能,看似是个小功能,但是往深一研究,就会发现涉及到的改动范围还是比较大的:

未登录的人能点赞吗?

个人中心如何显示点赞和评论列表?

需不需要在首页列表显示点赞数和评论数?

可以直接在首页操作点赞或者评论吗?

可以修改评论吗?可以删除评论吗?

评论需要回复功能吗?评论回复可以修改吗?
...

许多细碎的问题都需要有一个明确的选择。与其费劲地在各个页面画框,调整按钮,画列表,写交互说明来确定细节,身为一个开发者我觉得直接在一个界面上调整功能要快得多。。

所以,可以说在确定了产品大框架后,我们就直接进入了开发流程,讨论需求与开发并存也就不难理解了。这一点我觉得还是小团队的优势,没有那么多流程上的问题,而且的确由于人员短缺,没有全职产品经理,虽然在没有明确需求的情况下就开发,难免会有最终实现出来的效果有哪里不对的情况,但是沟通后修改效率也非常高,基本上花个把小时的时间就能拉到正轨上了。

当然,这么做的适用范围是细节需求,且有强烈的实际社会与环境因素,经验借鉴需谨慎,如有雷同,纯属巧合。

测试流程

一开始计划分三个测试环节,自测 + 公司内测 + 邀请用户制度进行公测。总耗时规划1-2个月的时间。 后来发现,还是我太天真了。公司内测这个环节就足足卡了近2个月。

说是测试,更确切地不如说是接受来自他人的diss。测试过程中,测试人员会源源不断地提出对功能的质疑,以及提出自己的需求或者修改意见。去年的产品发布前我已经接受了一波这种“测试”的洗礼,知道并不是改bug那么简单。新来的开发人员一开始觉得非常难以接受,认为测试不应该提feature,只能提bug。但是的确拦不住大家提出诸如“评论字数最好限制一下”,“电脑端跳转在新窗口打开更舒服”,“为啥没有笔记模块”之类的问题。

怎么说呢,之所以会出现这个现象,我也进行了深度的自我剖析。

首先,也是最重要的原因,还是我这个半吊子产品经理做的不够好,在设计功能的时候考虑的不够全面,没有讲细枝末节都考虑进去。而当设计完功能后,我就立刻转变成了开发者思维,考虑功能如何实现,难免被禁锢在了已有的功能里,很难跳出来宏观地看这个功能的缺陷在哪里。

在自测的时候,我虽然已经在尽量地把自己当作一个普通用户,也从普通用户的角度做了不少优化。但因为是自己开发的产品,还是无法对它作出很苛刻的评价。最终导致大家使用的时候依然能挑出很多功能设计上的缺陷。

其次呢,其实对产品核心功能我也没有绝对的话语权,基本上还是围绕着老大的思路做填充产品肉体的工作,整个产品流程也是不断在和老板沟通,把老板的思路落实到产品需求的过程,期间双方的理解会不可避免出现偏差,发现了就要及时纠正。那也就意味着,跟老板沟通的越多,这个偏差就会越小。

所以另一个问题就在于,我跟老板沟通的还不够多。到了产品功能开发出来的时候,老板才明白我原来是要做成这样,然后他会提出自己的修改意见,这时候我才明白原来老板要的是什么样。如果我能在开发产品的期间,也能保持频繁的沟通,那么很多问题在开发过程中就能解决掉,而不是等到测试环节才暴露出来。

当然,我对于所有的建议也会有自己的判断,而不会全盘接收所有人的意见。在有些情况下,尤其是测试后期,功能已经趋于完善,大家的建议都属于锦上添花,而不属于产品的硬伤了。这个时候,我就会强硬地拒绝一些功能建议。毕竟我们现在还是第一个版本,在刚使用一个新产品的时候,很容易就会产生“如果有xx功能就好了”的想法。如果功能不核心,不高频,它看上去再有用我也会选择不接受。

我还是更倾向于让用户数据(而不是用户的‘我觉得’)来告诉我,他们真正需要的到底是什么。

毕竟,微信的哪一次更新不是50%的用户在吐槽,我刚用mac的时候还嫌弃macos系统非常不好用呢。到最后还不是真香。

产品心理VS开发心理

整个产品流程做起来还是非常心累。

对外,我是一个懂技术的产品经理,需要对所有天马行空的需求作评估,衡量技术上的可行性和需求的本身的重要性,然后需要不断地进行梳理,尤其是要在产品会议上说清楚,为什么我选择做这个功能而不是另一个。

而对内,我是一个产品经理的身份,给大家提供要做的需求,同时,我还要自己接受这个需求带来的开发量,进行一些开发工作。

工业界产品经理和项目开发的矛盾众所皆知,一个想要设计出完美的产品,另一个需要对产品如期上线、技术可行性负责,所以当两个角色都出现在自己身上的时候:


加这个功能好像不错,可以让用户有更好的体验。

可是开发量太大有可能延误产品进度。

当然产品第一了,这个功能很重要

真的有这么重要吗,第一个版本用户对这个功能需求量不大,我们可以在下个版本迭代。

只要有一个用户会使用,我们就要做到最好,否则这个用户就流失了

...

所以我每天都在陷入强烈的自我纠结。角色往项目那边偏一偏,就决定下个版本迭代;往产品那边偏一偏,就决定把这个功能加上。。

新产品在现阶段依然处于测试环节,在写这篇文章的时候,我们已经确定了最后要优化的几个点,完成后就上线,并且不再接受所有的非核心功能优化建议。希望不要打脸。

2020集智斑图,这是我们孕育了半年的儿子,现在马上就要生了,大家敬请期待。