研发管理
笑看风云之变换
这个作者很懒,什么都没留下…
展开
-
项目管理者必须清楚产品的点点滴滴,可以做随机查看、甚至补位
项目管理者必须清楚产品的点点滴滴:产品当前状态、有没有风险点、bug数量及分布必须使用产品并对产品足够熟悉对产品的各方面至少要随机查看,比如需求描述、交互设计、测试情况,如果有相关背景甚至对后端设计也做相应查看。必要时甚至要补位,比如如果产品需求描述经常不全面...原创 2019-05-11 18:18:41 · 246 阅读 · 0 评论 -
管理三类人
常常有管理者报怨,下属做事不到位,很多事情只能自己来,结果自己的时间完全不够用。当被管理的团队人数越来越多时,这个问题尤为突出。 管理很重要的一点是因人而异,所以我们可以将下属分成三类人,不同类的人采取不同处理方法:第一类人:顶尖人才,具有足够的能力完全独立把事情做到位。这类人中最顶尖的,即便是一个新东西,他也有足够的能力去学习、去分析,把问题解决,甚至最后形成处理这类问题的规范。在管...原创 2019-04-20 08:40:19 · 455 阅读 · 0 评论 -
产品研发:项目管理者是否需要必备多种技能
项目管理者需不需要具备多技能? 前面博文我们也提到,除了项目管理本身的职责外,项目管理者需要熟悉产品、懂技术,这些是必备的。除此之外,个人觉得也应当具备下面的技能:具备判断项目中的每个角色的产出是否到位,时间规划是否合理的能力。如果产品研发中的各个角色做事都很到位,那么这一点似乎必要性不强,但那也仅仅是如果。所以这一点还是要必备的。必要时,如果能做一些辅助某些角色,甚至补位的能力,那...原创 2019-04-20 07:59:14 · 327 阅读 · 0 评论 -
产品研发:项目管理需不需懂产品
项目管理到底需不需要懂产品? 项目管理对产品肯定是要有基本的了解的,知道有哪些功能点,熟悉产品的用法。这样才能对产品研发有个宏观把握,对计划有预估,执行过程中也能更好的控制风险,当出现变化时也可以很好的应对。...原创 2019-04-20 07:31:04 · 152 阅读 · 0 评论 -
质量管理体系之需求评审
首先,需求评审的主要靠产品。但是,仅靠产品是不够的,还需要后续的架构、设计、测试人员进行补充完善。技术类的产品更是如此。所以,在很多公司,最终如果发现需求评审有问题,从责任的角度:产品一定主责架构/设计/测试人员次之。当然这个是有条件的,条件是“功能点存在,但是不够完备”。如果是一个独立的功能点在需求描述中缺失,那么架构/设计/测试人员是免责的。...原创 2019-04-29 11:22:48 · 362 阅读 · 0 评论 -
产品研发:管理项目需不需要懂技术
到底管理项目需不需要懂技术? 之前一直认为项目管理不需要懂技术,即便懂也可以不介入技术,现在越来越发现项目管理至少需要对技术略懂的,至少清楚技术模块、基本架构、流程,只有这样,才可以把控产品研发中的各个点。有的公司则干脆项目管理者即是技术领导。...原创 2019-04-19 16:46:56 · 431 阅读 · 0 评论 -
管理者务必言而有信,切忌轻诺寡信
管理者辐射的是整个团队,是大家的主心骨,必须具有公信力。如果要让大家信服,必须言而有信,切忌为了短期目标而轻诺寡信。一旦失去了团队的信任,做起事来势必大受影响。...原创 2019-04-28 22:52:03 · 217 阅读 · 0 评论 -
管理者务必一碗水端
《孙子兵法·始计篇》说到“主孰有道?将孰有能?天地孰得?法令孰行?兵众孰强?士卒孰练?赏罚孰明?吾以此知胜负矣。” 法令孰行,讲得是法治的重要性,赏罚孰明,讲得是一碗水端平的重要行。对于任何一个管理者而言,该法治的地方务必法治,该一碗水端平的务必端平,否则必定引起团队成员的不服与猜疑。...原创 2019-04-28 22:47:01 · 133 阅读 · 0 评论 -
要具有做全、做深、做细的能力
项目在推严格的质量管理体系,对需求说明书、设计文档、编码质量、测试质量,都提出了严格的要求。这时候,每个环节的责任人,必须具备把相应事情做全、做深、做细的能力。其实这个能力是专业人士应该具备的,而且一旦具备了这个能力,也应该是可以泛化到其他事情上的。所以,“做全、做深、做细的能力”应该成为人的基本素质。...原创 2019-04-28 22:39:27 · 269 阅读 · 0 评论 -
要给下属试错的机会,但是也一定要失败的案例促使其成长
首先,我们要给下属试错的机会。因为他们自己从错误中的成长才更扎实。但是,却不能一味的试错,务必及时的抓住其失败的案例,与其一起总结,促其成长。...原创 2019-04-28 22:34:45 · 699 阅读 · 0 评论 -
在做深自己领域的同时,也要抓住拓展自己广度的机会
对于想以后从事管理岗位的人来说,做深自己的专业领域固然重要,但是也一定记住抓住拓展自己广度的机会。因为对于管理岗来说,知识的广度会使得管理者更容易与人沟通。所以,抓住拓展自己广度的机会,相当于为未来的管理工作提前做了储备。...原创 2019-04-28 22:30:33 · 231 阅读 · 0 评论 -
质量管理体系之设计评审
设计评审分两块:后端设计评审和前端交互评审。后端设计评审。把后端组长带起来,确保其设计文档质量;然后后端设计文档一律由组长带动进行内部评审,过关之后再组织外部评审;外部评审的参与对象包括架构师、测试人员。前端交互评审。前端交互评审采用轻量化的方式。由前端组长带动大家(主要是产品、测试人员)一起逐步形成完善的交互规范。凡是交互规范里提到的,一律遵循;其余个性化的写在交互设计文档里。 ...原创 2019-04-29 17:04:21 · 740 阅读 · 0 评论 -
质量管理体系之编码质量
清晰的需求描述文档和详细的设计文档是好的编码质量的基础。所以编码人员需要确保对需求文档和设计文档的理解。在此基础上,编码人员按照设计文档编码。有些编码人员提到不知道如何提高自测覆盖率,其实这跟编码一样,只要按照设计文档进行各种case的自测就能保证足够高的自测覆盖率了。...原创 2019-04-29 17:10:42 · 643 阅读 · 0 评论 -
质量管理体系之测试质量
测试人员按照下面几点执行即可:参考需求描述文档和设计文档,设计全面的测试用例破坏性测试对测试之后的bug进行总结,不断循环原创 2019-04-29 17:14:06 · 1893 阅读 · 0 评论 -
项目管理:角色必须齐全
不能因为觉得某个产品简单而忽略测试。进一步总结,整个项目过程中,每个角色必须齐全,每个角色要做哪些事情由每个角色提出、项目管理者确认。...原创 2019-05-11 18:11:52 · 1006 阅读 · 0 评论 -
问题驱动的管理
不管管理还是做事,找出问题在哪,时间主要花在哪,然后分析问题、解决问题即可。这样必然能一步一步前进。原创 2019-05-10 16:20:47 · 375 阅读 · 0 评论 -
文档写得好得人升职快
今天在跟一同事讨论文档时,另一同事脱口而出:文档写得好得人升职快。这句话看似笑谈,实则是很有其合理性的。文档要写得好,则必然思路很有条理。而一个人思路有条理,则往往做事有条理,自然容易把自己的事情安排得井井有条;如果是一个团队管理者,那么更容易把团队的事情管理得井井有条。可不就说明了“文档写得好的人往往升职快”。...原创 2019-05-09 15:27:33 · 282 阅读 · 0 评论 -
发现组织的问题,解决它,这就是亮点
多去发现组织内的问题,进行调查分析,去解决它,这就是你的工作亮点。职责范围内的,责无旁贷,是首要解决的。职责之外的,也可以无边界去推动或解决...原创 2019-04-30 15:33:32 · 173 阅读 · 0 评论 -
产品设计:先有概念,后有界面
好的产品应当是“先有概念,后有界面”。所谓”先有概念“,是指先确定产品中涉及的概念,随后理清概念之间的逻辑关系,概念及概念之间的关系这里我们称之为草图。”后有界面“是指在”概念及其关系“理清楚的前提下,再去做具体的原型。 与面向对象软件设计做下类比,概念类似软件设计里的一个个接口,草图则代表软件设计里的抽象的业务逻辑(接口之间的关联与交互),界面则是把每个接口替换成具体实现类。草图必须是...原创 2019-05-08 16:27:33 · 330 阅读 · 0 评论 -
研发管理:不能由开发来决定功能点需不需要做测试
公司里出现了几次这样的现象:开发觉得这个地方不需要测,但是测了一下就出问题,更糟糕的情况是最终没测,到生产环境出了问题。 总体说来,很多开发是偏乐观的,没有太多的风险意识。所以不能由开发来决定功能点需不需要做测试,哪些地方需要测试,更多的要由测试或这项目管理者来决定的。当然,项目管理者必须要有风险意识。...原创 2019-05-08 15:08:26 · 189 阅读 · 0 评论 -
要有大局观
管理这要有大局观,我觉得有几层意思:不要过于在意个人得失,多从组织得失角度考虑问题。看事情要具有全局视野,抓住主要矛盾。考虑问题要长远,提前布局。...原创 2019-04-30 12:35:10 · 369 阅读 · 0 评论 -
产品研发:了解每个项目成员的诉求,激发他们的斗志
发现前段时间陷入了一个误区,项目中暴露的一些问题,都是自己在分析、想解决办法。这种方式带来了不少问题:自己的时间和精力被大大分散,几个项目相互挤占时间项目成员少了发挥的空间解决问题的速度也慢了不少 今天开始换种思路,多去了解项目成员的诉求,将问题的解决与项目成员的诉求结合起来。比如前端的某同学,有意愿走技术+管理的路线,那么正好可以请他带领前端组解决前端的质量问题。 了解每个...原创 2019-04-25 12:36:30 · 396 阅读 · 0 评论 -
项目管理:不仅要管理项目成员,还要管理所有依赖方
由于产品资源紧张,所以将一块功能交给了外援去做,公司的A员工与外援对接,项目又是与B对接,辗转了好几层。B员工也给出了具体完成的时间点、状态。但是最后发现根本没有达到想要的。这里边的教训是:看似双方达成一致,实则未必,所以对于目标,一定要双方确认。这个很重要,哪怕是啰嗦了一点。对于依赖方,也要跟踪管理。有时甚至要跟踪最终的依赖方 总结起来,就是对依赖方(甚至最终依赖方)也要以项目管...原创 2019-05-08 11:39:24 · 315 阅读 · 0 评论 -
质量管理体系之验收质量
测试完成之后还要做几轮验收,再加一层保证。验收会更多的以用户视角。第一轮:产品经理的验收。第二轮:售前人员的验收。产品经理参与了从产品设计开始的整个过程,所以对新版本的功能已经很熟悉,容易陷入思维定势。而售前人员对产品新功能并不熟悉,可以提出一些不一样的视角。...原创 2019-04-29 17:20:29 · 252 阅读 · 0 评论 -
做下属的贵人
很多人常说要感恩遇到的贵人。反过来讲,在团队管理中,我们也应当力争做下属的贵人,我们也应当有这个责任。我们把自己走过的坑,自己积累的经验倾囊相授,下属自然更容易成长,自然积极性就高。...原创 2019-04-28 22:19:06 · 120 阅读 · 0 评论 -
产品研发:必须理好功能清单,并严格跟踪
这个版本的功能比较琐碎,有些是客户反馈的bug或优化。在项目执行过程中,并没有把功能清单放到公共文档上,也没有很细的跟踪,导致项目出现了风险。 基于此,后续的产品研发中:必须理好功能清单,并严格跟踪每一项,不管有多琐碎。...原创 2019-04-19 16:36:34 · 1101 阅读 · 0 评论 -
管理:没有调查就没有发言权
公司某个项目质量一直不太好,也找了专人负责质量这个事情,但是却迟迟没有成效。根据情况做下分析,原因有如下几个:确定对质量有效的事情,没有得到很好的执行。比如设计,而设计没有很好得到执行的原因是负责人没有实际深入进去把设计带起来其他的措施也都是些common sense的。比如加testcase,但是实际做testcase的人却没法保证testcase的覆盖率和有效性。 无论第一种还...原创 2019-04-27 09:14:52 · 1039 阅读 · 0 评论 -
有效的会议
&esmp;很多时候我们都把时间浪费在了低效乃至无效的会议上。特别是当参会人数较多时,每低效增加1小时就是浪费好几个小时的时间。如下是个人的一些心得一定要有主持人,负责:组织会议、设置议题控制会议不要偏离主题控制时间有的选,尽量选会议把控比较好的人当主持人大家请尊重主持人,级别越高越应自觉尊重主持人,否则主持人很难做。请提前发会议邀请,明确主题、参会人、预计时间,并...原创 2019-04-14 15:13:24 · 207 阅读 · 0 评论 -
项目管理规范
PMPM的职责PM负责项目的整体规划(Milestone制定、收集汇总任务细化)、站会、风险的处理、组织项目总结PM是项目的最后一个关口,保证所有的风险可以处理掉。PM处理不了的风险,找能处理的人协助(比如架构师)PM的要求必须以身作则,要有最强的时间观念和责任意识PM是联系各方的纽带,在跟各方沟通时,务必真正理解了对方的需求,也向对方传递了自己的需求每件事情都要给出明确的状态...原创 2019-04-14 14:53:17 · 2150 阅读 · 0 评论 -
高效会议:明确会议主题,紧紧围绕不偏题
昨天的会议开的是一团雾水,毫无主题,开成头脑风暴了原创 2019-04-26 09:13:15 · 2176 阅读 · 0 评论 -
产品研发:在项目管理中,明确每个成员的职责
在项目管理中,最近发现一些很不好的现象:临近版本交付了,测试人员才说还有很多bug没有闭环产品也不去考虑最终版本的交付目标这里边根本的原因还是没有定义每个成员完整的职责。对各个成员的职责定义如下:|角色| 职责||–|--|| | |...原创 2019-04-21 14:41:45 · 671 阅读 · 0 评论 -
产品研发:务必转化为有效的行动
在工作中经常看到,有不少人讨论起问题来,说的头头是道,但是实际解决起来却是一塌糊涂,甚至很多时候压根都不付诸行动。我们不妨称之为理论派,他们的根本问题在于不去实际行动,看问题都停留于表面。 在实际工作中,我们要想避免这种情况,最根本的还是去转化为实际行动。只有转化为实际行动之后,才可能解决问题。只有转化为实际行动之后,才能在实践中验证所想的方法是否可行,才能在实践中不断的碰壁、分析、行动、...原创 2019-04-21 10:57:02 · 151 阅读 · 0 评论 -
初创公司如何提高团队成员的积极性
初创公司百废待兴,人少钱少事多。怎么办?其中很重要的一点是要想办法提高团队成员的积极性。薪酬没有大公司高,平摊到每个人身上的事情又那么多,凭什么可以让大家积极性高呢? 初创公司其中一个很大的特点是问题太多,但是这些问题恰恰是每个人成长的机会。把难题尽可能地交给大家去独立解决,每个人在解决问题的过程中不断成长,当问题一个个解决掉之后,每个人自然就变得强大起来。当然在这个过程中,还是要积极的提...原创 2019-04-21 10:43:08 · 526 阅读 · 0 评论 -
管理之“其身正,不令则行;其身不正,虽令不从”
管理问题:很多管理者抱怨,三令五申的跟下属说要怎样做事,但是效果却总是不尽如人意。怎么办? 孔圣人其实很早就交给我们一个方法。 子曰:“其身正,不令而行;其身不正,虽令不从。”------语出《论语·子路篇》 释义: 孔子说:“当管理者自身端正(作出表率时),不用下命令,被管理者也就会跟着行动起来;相反,如果管理者自身不端正(而要求被管理者端正),那么,纵然三令五申,被管理者也...原创 2019-04-13 07:58:15 · 1707 阅读 · 0 评论 -
如何指导下属把事做好之“案例管理法”
场景举例:项目组做了几个月的软件设计,一直不到位。又没有现成的好样例,怎么办 解决方案:案例教学 第一步,自己心中弄清楚什么样的软件设计是好的。根据项目组的情况,好的软件设计需要满足以下几点:满足了产品需求说明书里的功能需求,并写清楚了软件系统是如何满足的满足了非功能性需求并说明了如何满足的。非功能性需求既包括产品需求里提到的,也包括好的软件设计所要求的。具体包括:可复用性(...原创 2019-04-12 19:56:19 · 317 阅读 · 0 评论 -
软件部署规范
部署流程正常代码一律分支开发;某个版本的bug在主干上开发当某个分支代码测试通过之后,合并到主干并打上版本号部署到预发布环境,并做验证预发布环境验证通过之后,部署到生产环境部署包准备+标记配置文件做了哪些更新+标记数据库schema要做哪些变更特别说明:不同的场景会有微调,但是总体思想差不多...原创 2019-04-12 12:37:37 · 3703 阅读 · 0 评论 -
管理:该授权时务必授权
前面有几篇提到管理者要适时的Involve进去(管理:没有调查就没有发言权、如何指导下属把事做好之“案例管理法”),但是管理者也千万不要陷入Involve进去的误区而出不来。 调查也好、案例管理法抑或其他Involve的方式,是根据问题的实际情况而采取的措施。只有判断下属没法有效解决问题或者下属已经尝试去做仍无法解决问题时,管理者才需要Involve进去。管理三类人里我们也提到,对于“...原创 2019-04-27 09:38:10 · 122 阅读 · 0 评论 -
管理:做好规划
最近一周主要精力放在某个一个项目,对另外一个项目管得较少,昨天项目经理突然说要急着上线(测试人员还没有正儿八经测过),跟他说风险太高,才意识到问题的严重性。匆匆忙忙,只能叫相关人员加班。 像这类情况,原本是可以避免的。避免的方式是:事情做好规划,推演可行,留有buffer,按照节奏去执行。所以,管理者一定要有远见,事情想在前面,做好规划。...原创 2019-04-27 10:10:02 · 171 阅读 · 0 评论 -
重视沟通的力量
工作当中,每人都可能有不同的处事方式。有的处事方式甚至与自己差异很多,甚至很不认同。但是这始终是正常的存在,不能因为不认同就不去协作或者采取过激的行为。这种情况下,我认为通过“沟通”达到“求同存异”是很好的协作方式。 于是当实际工作中需要与人协作(不管是上级、平级还是下级)时,特别是当对方的处事对自己的工作造成影响时,多沟通。我认为沟通有几种类型:一般的沟通。当需要对方协作时。开诚布...原创 2019-04-27 17:52:49 · 177 阅读 · 0 评论 -
产品研发:必须严格走需求评审和设计评审
这个版本又由于需求和设计问题导致项目出现了风险,具体如下:对搜索进行了重构,没有在意需求评审,但是做的过程中发现界面也需要调整。从而导致需求变更为了早点排出时间,没有做好设计评审的情况下就定了计划,导致设计评审之后发现工作量预估不足 所以后续的改进措施是(也强烈建议各研发团队遵循,尤其是数据逻辑较多的产品或项目):必须严格走需求评审和设计评审,不管新功能还是老功能修改等需求评...原创 2019-04-19 16:28:47 · 2761 阅读 · 0 评论