扫描二维码，输入您要打赏的金额产品上线前产品经理或者专员应该干什么？
产品上线前产品经理或者专员应该干什么？
产品上线前产品经理或者专员应该干什么？
最近公司的网站在筹备上线，这个时候作为产品感觉有些迷茫，不用做新功能，只是成天在帮忙测试。公司为了让一期版本如期上线，规定这段时间只能修bug不能对功能进行大的修改。这时间产品更多的应该关注什么呢?感觉没什么事做有些迷茫。勤劳远比黄金可贵。网，提供更真实的招聘信息，pincai.com
发表于 15:14:58.000000
我目前正好也处在这个阶段，现在我做的事情有：1 给销售做培训。2 给客户做讲解。3 关注产品的市场反应，搜集客户反应。 4 对产品深入挖掘，并且考虑改版方案。
另外，我觉得产品的项目开发阶段盯人的主要是项目经理，产品经理前期确定了产品方案，开发过程中应该不太介入才对。我以前的公司和我现在的公司都是这么做的。
另外，版本上线不能修改功能，只能修改bug，这也是对的。功能要在项目开发初期就完全确定，如果有新想法完全可以放在二期，在项目开发过程中不断更改功能会影响开发进度，可能会产生大量冗余代码，并且容易出错。
网站的项目规模比较小，开发相对来说比较简单，所以开发过程中经常会出现东改西改的情况，这其实非常影响产品的运营进度，并不可取。
发表于 14:35:53.000000
这个阶段，QA 确保工程质量；项目经理（如果有的话，没有就是产品人员）主要跟进项目进度，确保是能在计划的时间上线。
产品人员主要是参与测试功能完整性、功能可用性方面的问题，不断地体验新功能，从各种角度和流程。还包括 UX 方面的微调。
发表于 13:56:48.000000
你们有测试组吗？有项目经理吗？这段时间就是盯着改bug呗，然后就是看哪些bug必须这个周期修，哪些推后到下个周期嘛。再个就是准备下个周期的功能计划吧
发表于 13:17:43.000000
我一般会这么分配精力
1.产品进入coding阶段，我首先是盯项目，和开发人员保持每天沟通，一方面确保进度，另一方面听取技术的意见和发现更好的解决方案。----65%精力
2. 考虑下一版的一些点。这个过程有点类似一个人的头脑风暴，但不是刻意的。一般是在看其他方面的文章、产品时会突然有灵感，然后把这些灵感都一一记录下来，用于下一版的更新中。---25%
3. 和运营及其他人员聊聊。前期产品规划阶段忙的不亦乐乎，现在有空了可以把之前的一些问题聊透，并问问他们接下来的计划安排。这样有助于对产品的整个脉络和公司其他方面进行全面了解。---10%
发表于 12:38:38.000000
作为待上线产品，我会关注如下几点：
1、产品的需求匹配情况，对当前做出的功能是够完全或接近完全的满足之前的需求情况，对不满足的需求情况进行分析是否影响上线。排除各需求的盲区，做好上线前的各方沟通。
2、对产品的性能，尤其是网络产品更需要加大对性能的提升，对关键的性能屏障点尤其要注意，需确保产品性能可以满足当前的需要。
3、对细节调整的关注：有些开发人员认为的细节的调整往往是造成使用不够方便或不能够让使用者满意的地方，紧盯细节的调整，确保细节动技术不懂操作方式。
发表于 11:59:33.000000
1. 测试再测试，商业商品，出现重大bug是不能容忍的；同时还需要检查产品与公司其他产品线的耦合。2. 新产品的推广方案，应该也是要到快速落地的时候了。3. 每个产品都有Deadline，所以每一版本都不是产品经理心中最完美的样子，整理下一版本需求，有利于快速迭代。
发表于 11:20:28.000000
这个我感觉每个公司可能会有差别吧。感觉产品经理前期策划做好“定”了，后期就是“盯”。我们在上线前会“盯”很多，结合各种文档盯流程、配合测试盯BUG、盯设计（界面和体验），还要盯小白用户（客户）的阶段可用性测试反馈等等，总之很多很多哦。
发表于 10:41:23.000000
每一个小细节都可以做得更好，不要说没有事做，只能说你关注的细节还不够。
发表于 10:02:18.000000
好久不在聘才职业圈冒泡，正式在国内互联网创业公司工作三个月，趁着这个问题整理下最近略为凌乱的思路。略微拓展下问题的范围，不局限于产品上线前，而将其放在产品需求文档交付之后，即产品正式进入全面开发阶段，产品经理每天的工作是什么。参与制定详细的项目开发时间表项目开发时间表应该在与开发人员一起评审完需求文档之后的一至两天内制定出来，根据需求文档中的用例细化每一部分的开发时间。此项任务需与程序员哥哥们通力配合，首先要全面地收集他们在听完需求文档评审后对于产品本身的意见与建议，然后逐项予以合理的解释，以保证程序员哥哥们打心底里认同这个产品，认同形成这个产品的每一个需求。另外作为一个PM，也应该要对基本的开发流程有所了解，在制定每个需求的开发周期时提出正确的建议，保证最终的项目开发时间表既不会拖慢整个项目的进度，也没有超出程序员哥哥们每天正常的工作量，保证他们不会感到过大的开发压力。补充程序开发过程中所缺失的资源如果是一个客户端产品，则最重要的两部分开发资源，一是后台测试接口，二是前端UI切图。这些资源在与技术人员一起评审完需求文档之后都应立刻提上日程，接口方面PM应尽可能地给出一份所需要的接口列表以及每个接口的基本字段，完成后将接口文档邮件给后台及客户端开发工程师，以方便他们在这份文档的基础上更为快速地完成正式测试接口需求的对接，并在双方对接的过程中，提供相应的产品方面的支持。UI切图方面，前期可以先让客户端开发工程师参考原型图搭基本的界面框架，并在这段时间内尽快与UI方面保持沟通，快速迭代出满意的设计图。设计图通过后，一到两天的时间内让UI设计师将设计图切图后打包，发送给客户端工程师以方便他们完善界面。客户端后台的需求文档撰写思考产品正式上线后各部分的内容该如何维护、如何更新、以什么样的频率更新，即如何以最有效率的方式在客户端后台更新客户端显示数据。对于后台需求文档，UI不重要，逻辑很重要。要求PM对整个产品的架构烂熟于心，哪个模块需要以什么样的方式进行更新，如何在网站版的后台组织这些所需要的数据。一个优秀的PM顶半个架构师，这一点不仅仅体现在产品本身某些重要的大逻辑上，在撰写后台需求文档时一样可以体现得淋漓尽致。项目整体进度跟进对于整体项目的进度，要做到心里有数，每天更新项目进度表，了解最新的项目进展与动态，解决开发过程中已经出现的问题，并将自己看到的潜在问题尽量扼杀在萌芽之中。当然，最重要的是，所谓跟进，不是每天盯着工程师问进度，更多地是要以描绘产品未来愿景的方式鼓舞士气，让团队中的每一个人都感受到自己肩上的重任并愿意主动地去承担。下一阶段的产品规划此处的下一阶段应分为两个部分，一是目前的开发周期完成后就需要添加的新需求或老需求的优化，二是目前产品上线后下一个版本可能要做的需求更新或整体产品的改版。优先级为先做第一部分的事情，再做第二部分的事情。第一部分的事情应形成正式的需求文档，第二部分的事情更多的是以bullet-point的形式出现在PM的记事本中，以方便在产品正式上线后结合用户反馈，快速形成一份新的产品2.0版需求文档。与运营同事合作制定产品的营销推广计划PM生孩子，运营养孩子。产品这个小娃娃已经接近出生，后续的养育工作自然应该列入工作计划之中。在这一方面，PM重点需要去做的并不是制定出一份完整的营销推广计划，而是尽可能多地让同你合作的运营同事了解你做出来的这个产品。这个产品是什么？以怎样聪明的方式解决了用户的哪些痛点？这个产品身上所带的情怀与气质是怎样的？这个产品的目标用户群在哪？商业模式又是怎样的？相信如果PM可以帮助一起合作的运营同事搞清楚以上的这些问题，专业的PO同事一定会拿出一份让你拍案叫好的推广计划的。当然，如果PM有一些抖机灵的点子，自然也可以多于PO同事分享，这世界上哪有什么软文，被叫做软文的文章不过是写得烂到家的推广文案。利用专业的测试工具进行有效的QA千呼万唤始出来，犹抱琵琶半遮面。产品终于开发完毕，正式进入QA阶段，没有大公司必备的专业测试框架，我们至少还有这双手。撰写测试用例，然后逐条测试，以保证产品的稳定性、流畅度、易用性。
值得加入的圈子产品经理如何提升需求分析的能力--百度百家
产品经理如何提升需求分析的能力
分享到微信朋友圈
产品经理如何提升需求分析的能力
【准备阶段】
凡事都要打好基础再行动，做需求分析至少熟悉以下三方面:
1、熟悉业务，能够把业务流程所涉及的场景，角色，活动，上下游搞清楚。
2、熟悉产品，至少要掌握产品核心功能与系统边界，了解需求在产品中的位置。
3、熟悉团队，了解合作团队的角色分工和人员能力情况，了解目前的资源状态(忙还是闲，全职还是兼职)。这一点很重要但常被无视。
如果因种种原因刚好没有相关积累，用到时最好请教了解的“行家”，万万不能略过直接上马就做分析，会出大问题的。
好在做产品的一般都会对业务和所负责的产品比较熟悉。至少我们公司里，我认识的大部分产品经理都是其他岗位上“做而优”，然后转产品的，笔者亦然。
当然这些储备工作在于日常积累，从一个模块到一个产品到再整个系统，从了解到熟悉再到精通是漫长的一个过程，我想这恐怕也是月薪5千到月薪5万的过程吧。
判断需求所处的是产品生命周期的哪个阶段。不同阶段有不同的分析策略。比较典型的MVP阶段，要求功能极简。这个阶段需求是一道选择题，需求要尽可能的体现产品核心价值才被执行，其他辅助性的增值的花瓶的统统砍砍砍。
在线运营阶段，需求分析要多考虑对现在业务和用户的影响，尤其是涉及核心业务或模块大改的需求。这个时候需求是个变换题，要想办法通过各种变通的方式实现或合理引导需求方从而减小影响。
产品转型阶段，这个时候需求是个判断题，有些需求是给产品整容，但也有些是完全是毁容，我是见过太多被改的他马麻都不认识的产品。
了解了产品当下的阶段之后，就可以有针对性的开始需求分析了。大致为两个阶段，第一个阶段主要回来要做什么，为什么要做?
【第一阶段】
为了回答这两个问题，一般可以如下四步走：
1、看需求来源，谁提的?客户的需求、老板的需求、产品的需求还是研发自优化需求，或者干脆是个BUG(广泛意义上也是需求)。所谓人人都是产品经理，人人都可以提需求，但不同来源的需求处理起来的节奏感是不一样的。以下省略500字。
2、看需求是个体性的还是群体性的，是否有代表性。表面描述背后的本质需求是什么，这点更重要。有个笑话说客户提出A，产品经理理解成B，开发设计成C，最后交付了D。简单的挖掘方法是多问几次为什么，为什么提这个需求?这个需求要解决什么问题?为什么现在提?打算什么条件下使用?提出者有解决方案吗?转着圈的多问几次，不要怕麻烦，需求会越来越深入，越来越接近于本质。
3、看需求的类型，是单纯的界面优化还是涉及流程调整?是完全独立的新增功能还是涉及老模块的改造?是单一模块的内部需求还是跨模块甚至跨产品的复合需求?从需求的性质判断出需求的范围、影响面、重要程度(研发视角)、实现难度等。
4、分析需求的紧要程度，可以参照时间管理的四象限方法，把需求划分成紧急且重要，重要但不紧急，紧急但不重要，不紧急也不重要。以下省略一本书。于是这个需求要不要做，以及什么时候做，优先级就都有了。
上面四步走，全程都是结合着业务流程和产品来的，比如需求的紧重程度不是客户或老板说了算，而要依照当下市场分析并结合产品战略做出理性分析的。
以上说的复杂，实际操作上有时可能分分钟就搞定了，看经验、能力和悟性了。
分析完之后要做什么就基本清楚了。此时应该有产出了，流程图或泳道图之类的，有时候需要简单的原型。同时要做一份需求确认文档，去跟需求提出方交流。理解不同的要PK，范围要PK，优先级也要PK。如果说需求调研时倾听最重要，这时就要体现引导客户的能力了。2B的，尤其是2大B的。沟通之后是改改改，直到完成需求确认。这个过程有长有短，是体现产品经理能力的加分点。
确认之后，需求就最终定下来了，存档入库，不再接受变更。(PS：不再变更?99%是不可能的啦)
【第二阶段】
二阶段回答怎么做?
在回答怎么做之前先要问能不能做?即可行性。
评估可行性，往往需要多方面配合，比如产品、技术、研发、测试、项目经理、交付、运营、运维等。
可行性评估会影响之前的所有分析结果，甚至要时返回第一阶段从新分析。再好的想法如果太超前技术上实现不了或实现成本太高那都是不靠谱。实际工作中我发现可行性评估这一步常常被忽略掉，结果给下游的同事挖各种坑。
如果对产品经理认证有兴趣的话，建议还是多参加线下的NPDP认证讲座，听一听讲师在日常工作中是如何利用NPDP中所学的知识进行调控产品的。这样也能够更直观的理解NPDP认证。
北京9月24日线下大型讲座“从敏捷教练到产品管理——敏捷产品管理的‘幻想’、现实与实践”报名地址：
分享到微信朋友圈
在手机阅读、分享本文
还可以输入250个字
推荐文章RECOMMEND
阅读：1087
阅读：1642
热门文章HOT NEWS
万妮达PK对手是吉克皓，两人风格也是不在一起跑线，万妮达演唱的...
百度新闻实验室
百度新闻客户端
百度新闻客户端
百度新闻客户端
扫描二维码下载
订阅 "百家" 频道
观看更多百家精彩新闻现在Bug管理工具太重，这个简洁的工具可以帮你减负--百度百家
现在Bug管理工具太重，这个简洁的工具可以帮你减负
分享到微信朋友圈
这是款努力解决程序员开发过程中痛苦事的工具。
有一个段子，程序员最讨厌康熙的哪个儿子？答：胤禩，因为他是八阿哥（音似Bug）。实际上在段子之外，却有款真的叫“八阿哥”的Bug管理工具，在努力做着解决程序员开发过程中的痛苦事，它就是——Bugclose。
Bug工具太“大”，“我们要做减法”
Bugclose是一款免费的Bug管理工具，他们的Slogan则显示了他们的追求：简单、易用、稳定、安全。之所以有这样的追求，主要是缘于他们一次“失败”的创业经历。在这个追求完美的项目中，向涛和他的团队发现了一个的痛点：“Bug太多，但是我们找不到一个好用的Bug管理工具。”
可能有很多朋友会说，Bug管理工具不是很多吗：QC、redmine、jira、bugzilla，国产的禅道、easybug和techexcel等。不过，在向涛和他的团队眼中，这些产品表面强大，但他们觉得这些产品却有以下四个缺点：
1.功能臃肿复杂，上手难度高。
2.界面反人类，还巨丑，不想用。
3.需要线下部署，安装复杂。
4.专业版本收费高昂，随随便便要上万，小创业公司——钱给不起。
他接着指出，目前主流的Bug管理工具，尤其是外国的专业软件，功能的确十分强大，然而使用起来却十分麻烦。功能太多、属性太多、角色太多、优化差、操作繁琐…用这种产品，小团队得去学习半天，而且80％的功能都用不到；另外这些Bug管理软件，设计体验基本上都是10年前软件开发时代，和当下比较有违和感。因此，向涛和他们的团队在功能和设计上做减法。
“难题”用几顿饭就解决了
有了初步打算之后，他们规划了下方向，他们眼中的缺陷管理工具是这样的：
简单：提一个Bug不要填太多的空；不要搞太多的流程；不要限定太多；
易用：最好一个工作台就搞定，不要打开关闭页面；在任何地方都能跟踪Bug；图片支持手机上传；
稳定：有专人来维护，不要动不动就要看源码或者请外部支持人员；
基于云：最好是基于云的，这样才能促进工具改善，越来越好用；
安全：Bug还是比较敏感的，通讯最好采用https。
说干就干，三位创始人，一个是产品经理出身，负责产品原型和运营；一个是清华大学毕业，典型的程序员，负责后台；另外一个是特别文艺的前端男，负责前端开发。技术上的人员配置合理、分工明确，再加上如今的云服务也比较方便，所以开发过程相对来说也比较“顺利”的，仅仅是业余时间就把这个工具给做出来了。不过，这种“顺利”仅仅是技术上的，在设计上他们还是有点束手无策的，“好在后来仅仅用几顿饭就把这个问题给解决了。”向涛非常感激地说起这位义气的好哥们。
“我们知道抓对了需求”
产品随后也很快上线。对于产品目前的发展情况，这位年轻的创业者和笔者透露，“目前我们的用户大概有200个、项目140个、Bug数量300多条。”他显得很兴奋，兴奋地原因不是因为用户增长数超过了他们预期，而是这些种子用户给了他们不错的反馈，“我们知道抓对了需求。”向涛乐呵呵地说。
至于盈利模式，他们目前还没考虑好。向涛称，他们目前就考虑两个事情，一个是把产品做的更好一点，“好到我们的用户没有必要去找第二款类似产品。”他这么定义“好”的标准；第二，他想用最快的时间内让更多的开发团队知道他们的产品。
“要做让用户感动的产品”
对于产品的未来，他用“互联网大会央视白岩松对雷军的一段采访：小米要回归本心，要做让用户感动的产品”作为引子，他称，“有很多优秀的精雕细琢的产品，当你使用的时候，会感觉到作者的灵魂存在于产品中，能感受到作者是付出巨大的努力和辛苦，非常不容易才做出这个东西，你会为作者的那种精神所感动。” 回到Bugclose这款产品，如果让他用一个比喻来形容自己的感受，向涛觉得这种感觉就像看了一部感动自己的电影。
“我们小团队也有小理想，让开发者、测试人员等研发团队中的每一个角色，使用Bugclose这款产品的时候，都能感觉到我们对产品的用心是特别真诚的，让他们感觉这是一个顺手、好用的小工具。”向涛称，尽管他们离这个目标还有很多路要走，但他很看好自己的产品，“第一免费；第二在云端，很多测试员和程序员随时可以看Bug；第三只需要一个账号就可以使用，而现在很多产品都是要本地部署，安装复杂，配置环境费劲。”他相信，再加上他们对产品的真诚和用心，用户一定会满意。
结束语：“自来水哲学”
对于这样一款的产品，有些人或许觉得没什么，但这位连续创业者有着自己的思考：
这么容易的东西，为什么没人去做？也许不够酷，也许不够有市场前景，所以很多人不屑于去做。但我们可以看见，市面上的无用东西真的太多了，有的花了很大的资源和精力，最后做出来却无人问津。所以我们这样的“程序猿攻城狮”，希望用小成本做点有价值的产品。
在一篇博文中，他引用松下幸之助的“自来水哲学”来继续解释他们的价值、企业的前途：
企业的责任是把大众需要的东西，变得像自来水一样便宜。经营就是以优良的品质，用消费者能购买的价格，把商品像自来水一样源源不断地为顾客提供出来。使顾客常受益，是企业获益的最大源泉。
在邮件采访最后，“我们不是B2B，只是一个小工具，不需要老板拍板就能用上，也不需要花大价钱。”他真诚而渴望地希望用户能使用他们的工具。
微信公众号：Lookdute。
分享到微信朋友圈
在手机阅读、分享本文
还可以输入250个字
推荐文章RECOMMEND
阅读：6922
热门文章HOT NEWS
万妮达PK对手是吉克皓，两人风格也是不在一起跑线，万妮达演唱的...
百度新闻实验室
百度新闻客户端
百度新闻客户端
百度新闻客户端
扫描二维码下载
订阅 "百家" 频道
观看更多百家精彩新闻