较大型项目的产品工作心得_项目管理_非技术区_程序员俱乐部

中国优秀的程序员网站程序员频道CXYCLUB技术地图
热搜:
更多>>
 
您所在的位置: 程序员俱乐部 > 非技术区 > 项目管理 > 较大型项目的产品工作心得

较大型项目的产品工作心得

 2022/9/15 14:41:24    程序员俱乐部  我要评论(0)
  • 摘要:最近做的一个项目从需求分析到上线绵延了四个月之久,这也是目前接手过功能点最繁复,产品线对接最多的一个项目。从中得到的一些关于设计较大型产品的心得,拿出来跟大家分享。立项前1、统一元素设计需考虑周全也许是初创团队的缘故,我不得不感叹团队对产品经理要求之严格之缜密,项目全程只有一个人负责,所以大到产品线对接,小到一句提示的位置和展示形式都需要一一推敲。哪些元素应该做到统一?A、提示方面:统一的操作成功/失败提示;统一的弹窗形式;提示语言采用较统一的句型;为空情况的友好提醒;溢出情况的友好提醒
  • 标签:

  最近做的一个项目从需求分析上线绵延了四个月之久,这也是目前接手过功能点最繁复,产品线对接最多的一个项目。从中得到的一些关于设计较大型产品的心得,拿出来跟大家分享

  立项前

  1、统一元素设计需考虑周全

  也许是初创团队的缘故,我不得不感叹团队对产品经理要求之严格之缜密,项目全程只有一个人负责,所以大到产品线对接,小到一句提示的位置和展示形式都需要一一推敲。

  哪些元素应该做到统一?

  A、提示方面:统一的操作成功/失败提示;统一的弹窗形式;提示语言采用较统一的句型;为空情况的友好提醒;溢出情况的友好提醒;表单实时验证的提醒形式等。

  B、文字方面:是否有统一的段落前“·”号;统一的链接状态;统一的字体、间距、行高等。

  C、图片方面:调取图片的统一尺寸;如果是上传图片类的操作,需要考虑周全全站的调取情况,以及考虑是否统一预览图的尺寸等。

  D、细节交互:未激活功能的按钮做“灰色”处理(例如用户没有勾选信息时批量删除按钮不可使用);按钮点击的状态统一(例如增加“提交中”的按钮状态,以防止网速慢用户狂点某一按钮的情况);特殊控件的统一等。

  也许会有朋友说,上面有些是交互设计师需要做的事,但我一直认为作为一个产品经理考虑周全一些,没坏处。这些“统一”同样可以用在验收阶段,要知道,即使一个像素也可以改变整个产品的感觉。

  2、原有功能的去留

  我一直觉得升级已有产品比开发新产品难一些。这就像栽培植物一样,新种下一棵果树无非需要选对了土地,然后刨个坑种下去,然而成长期的去病枝、打顶等各种修剪所消耗的精力往往更多。

  改进已有产品常常需要面对一个最棘手的问题:原有功能是去是留?

  原功能去掉的话是不是会影响部分用户使用?是否需要通过公告、站内信、界面引导等方式友好地告知用户?怎样把对用户的伤害降至最低?

  原功能留下的话是不是可以优化完善?听到了什么用户群怎样的声音?是否要在这次升级中做调整?

  这些问题当接到项目的时候,产品经理就应该考虑周全了。特别需要注意的是,如果这个产品之前不是自己设计的,那么最好找到PRD说明文档细细研究一遍,对把握不准的功能点找到原负责人确认,毕竟树苗是Ta摘的,别把将来最能结果的枝干给砍了。

  3、产品线上下游的对接

  昨天有跟朋友聊起淘宝强势之处,就是产品与产品紧密捏合,线上线下、跨平台跨行业形成了一个盘根错节、根深蒂固的根基,无可撼动。

  所以把握产品线上下游和产品周边很重要,即使一个看似简单的新闻展示页面修改也会牵扯到编辑后台、广告位管理、帮助中心,甚至是访问统计、数据需求的变更。

  这要求在产品设计开始前,需要把该产品“连根拔起”,仔细梳理相关脉络,如果产品线够长,一个清晰的产品线结构图很有必要。

  项目中

  1、项目期间来自相关产品线调整的影响

  项目期间相关产品线的调整是我最不愿意遇到的情况,这就像你在通往目的地的道路上高速行驶,就快要到达终点了,突然一个人告诉你:你走错路了。

  项目里有一个通用模块,产品设计到一半,这个通用模块改了;项目里有一个流程,产品做到一半,这个流程废弃了;最要命的是已经立项开发了,你不得不硬着头皮跟程序员说:“因为一些不可抗拒原因,这个需求咱不做了。”

  对于一个耗时较长的项目来说,这种情况难以避免,事出原因私自总结有三:

  A、严重体验性问题:例如某个流程遭到大量用户的不满,为防止用户流失,不得不做临时调整,而倒霉的是,你也在用这个流程。

  B、相关项目的影响:包括并行项目和新项目。例如你的同事在设计另一个产品,你们的产品相互牵扯较多,所以需求分析时做过很多沟通,但有一天,同事告诉你,Ta的一个需求做临时调整了会影响到你,怎么办?

  C、老板的突然决定:不举例。

  最终的解决方法不外乎三种:立即调整、延期调整、不调整。个人的处理原则一般是对A种情况进行立即调整,对B、C情况讨论并选择性延期。

  为什么这么做呢?A情况是必须要改的,时间早晚问题,长痛不如短痛,B、C两种情况必须坐下来细细讨论。需了解这个需求为什么要改?是长期对策还是临时决定?能否延期,记录需求等下一版本再开发?如果B、C情况提出来的需求没过两天又有改变,那与你配合的前端和程序员也太没有安全感了。

  这个时代能耐心阅读完2000枚汉字的人越来越少,较大型项目的产品工作心得[下]未完待续,欢迎交流……

  2、需求变更

  承上,需求变更是每个程序员、产品经理、设计师等都会遇到的情况。产品经理不是神,项目组也不可能是开了无敌状态抵挡任何外界的影响。

  当遇到不得不变更需求的时候,产品经理应该怎样处理呢?下面是个人的四条建议:

  a、积极处理。往往,当一个设计愈是趋于完成,人们愈是倾向于局部调整,而不是做重新设计。当一个需求因为众所周知的原因不得不调整的时候,作为产品经理需要做的第一件事便是积极面对问题,积极处理。

  项目开发往往是一个紧张的过程,每半天甚至每几个小时就有若干个功能点开发完成,当一个需求变更传达出现“延迟”,这个变更对项目的正常进程的“破坏力”就会更大一些。

  b、保持沟通。“说话容易,沟通很难。很多事除非对方自己想明白,劝是没有用的。所以,很多时候,沟通是个自己挣扎的过程”这话没错。需求变更直接会影响到下一道工序,产品经理需要将需求变更的细节和原因传达给相关人员,包括视觉、前端、程序、测试等。

  这是很多产品经理表示非常痛苦的过程,因为可能会遭到数落和冷眼,日本有一个礼仪原则是“不要给别人添麻烦”,但是在项目中,这不可避免。

  个人认为所有沟通的障碍都源于思想的不统一,如果让大家觉得这个需求修改是在浪费时间,那么沟通上的不畅快在所难免。项目不是这样算的,需求既然更改一定有所目的,产品经理需要将这个原因讲明白,不做修改或节约沟通时间导致的返工,后果往往更严重。

  c、更新文档。依然是为下一工序提供方便,产品经理往往不只负责一个项目,及时更新文档和修订文档版本号也可以为日后的查看提供便利。另外,文档不是万能的,更新文档是必要而非目的,任何时候都不要只丢下一些文字给别人,这好像在说“就这样改,其他别问”,是不负责任的态度。

  d、走好流程。每个公司的需求变更流程不尽相同,流程是为了项目更好的进行,不要看做累赘,流程不合理可以提出自己的建议,而私自绕过流程会为日后推卸责任埋下隐患。

  3、上线前准备

  在刚开始接触产品工作的时候,对于一个产品的上线一直停留在“需求-设计-开发-测试-上线”的简单流程模型里,实际操作起来才发现需要做的其实还有很多。

  这些工作主要包括:

  a、数据准备:产品中用到的数据(页面内容)需要提前准备。比如一个频道页上线,频道上的内容来自哪里?通过抓取?调用?还是后台推荐?编辑录入?如果是一个全新的模块,还需要重新填充数据。这个工作往往需要其他部门(比如编辑部)配合完成,产品经理需要做的是:1、提前告知,方便部门负责人合理安排工作;2、预留充足的时间,至少保证上线前填充完毕;3、细节说明和特殊说明沟通清楚,避免返工。

  b、统计需求:产品上线后需要跟踪监测的数据统计需求,需要形成文档告知开发人员。在产品设计期争议较大、把握不准的功能点,在效果图设计中存在顾虑的页面元素设计都可以记入统计需求,以便后期更好的分析用户行为,为下次产品的迭代和需求增减提供数据依据。

  c、广告位:页面的广告位变动,需要在产品设计期与销售、市场部门沟通,并在产品上线前再次确认。广告位的调整在产品设计中在所难免,为更好的保证客户利益,需要多听取销售与市场部门的建议。产品上线前需要将重新整理的广告资源交付平面设计,并替换在页面上。

  d、产品推广:属于产品运营的范畴了,产品与运营在工作中的碰撞更多一些,现在很多公司索性将两者合为一部,这是后话。这里想说的是,产品上线所必要的上线(改版)公告、商业软文、多渠道宣传这些基础的运营手段都是不能少的,产品经理前期可做简单跟进,主要是做沟通与配合。

  e、帮助内容:页面帮助相关内容的修改。主要是类似“帮助中心”频道的内容调整,如果是视频的话需要考虑重新录制。

  上线后

  产品上线往往意味着挑战才刚刚开始,这和拍电影不一样,经过紧罗密鼓精心筹划,一部商业大片终于上线了。观众看了笑了怒了骂了那是观众的事,反正可以赚的盆满钵溢。

  产品设计更像一个打靶的过程,用户需求就是靶心,每次产品改版都是在扣动扳机,我们需要做的就是——开枪,然后看看偏了多少,不断调整,力求下一次正中靶心。

  是的,产品上线意味着征战又重新开始,没有机会停歇。且回归用户需求,总结经验,继续投入到下一个项目中吧。[完]

  • 相关文章
发表评论
用户名: 匿名