flyhigher1983的专栏

  项目管理者必须清楚产品的点点滴滴：产品当前状态、有没有风险点、bug数量及分布必须使用产品并对产品足够熟悉对产品的各方面至少要随机查看，比如需求描述、交互设计、测试情况，如果有相关背景甚至对后端设计也做相应查看。必要时甚至要补位，比如如果产品需求描述经常不全面...

  不能因为觉得某个产品简单而忽略测试。进一步总结，整个项目过程中，每个角色必须齐全，每个角色要做哪些事情由每个角色提出、项目管理者确认。...

  不管管理还是做事，找出问题在哪，时间主要花在哪，然后分析问题、解决问题即可。这样必然能一步一步前进。

  今天在跟一同事讨论文档时，另一同事脱口而出：文档写得好得人升职快。这句话看似笑谈，实则是很有其合理性的。文档要写得好，则必然思路很有条理。而一个人思路有条理，则往往做事有条理，自然容易把自己的事情安排得井井有条；如果是一个团队管理者，那么更容易把团队的事情管理得井井有条。可不就说明了“文档写得好的人往往升职快”。...

  好的产品应当是“先有概念，后有界面”。所谓”先有概念“，是指先确定产品中涉及的概念，随后理清概念之间的逻辑关系，概念及概念之间的关系这里我们称之为草图。”后有界面“是指在”概念及其关系“理清楚的前提下，再去做具体的原型。  与面向对象软件设计做下类比，概念类似软件设计里的一个个接口，草图则代表软件设计里的抽象的业务逻辑（接口之间的关联与交互），界面则是把每个接口替换成具体实现类。草图必须是...

  公司里出现了几次这样的现象：开发觉得这个地方不需要测，但是测了一下就出问题，更糟糕的情况是最终没测，到生产环境出了问题。  总体说来，很多开发是偏乐观的，没有太多的风险意识。所以不能由开发来决定功能点需不需要做测试，哪些地方需要测试，更多的要由测试或这项目管理者来决定的。当然，项目管理者必须要有风险意识。...

  由于产品资源紧张，所以将一块功能交给了外援去做，公司的A员工与外援对接，项目又是与B对接，辗转了好几层。B员工也给出了具体完成的时间点、状态。但是最后发现根本没有达到想要的。这里边的教训是：看似双方达成一致，实则未必，所以对于目标，一定要双方确认。这个很重要，哪怕是啰嗦了一点。对于依赖方，也要跟踪管理。有时甚至要跟踪最终的依赖方  总结起来，就是对依赖方（甚至最终依赖方）也要以项目管...

  多去发现组织内的问题，进行调查分析，去解决它，这就是你的工作亮点。职责范围内的，责无旁贷，是首要解决的。职责之外的，也可以无边界去推动或解决...

  管理这要有大局观，我觉得有几层意思：不要过于在意个人得失，多从组织得失角度考虑问题。看事情要具有全局视野，抓住主要矛盾。考虑问题要长远，提前布局。...

  测试完成之后还要做几轮验收，再加一层保证。验收会更多的以用户视角。第一轮：产品经理的验收。第二轮：售前人员的验收。产品经理参与了从产品设计开始的整个过程，所以对新版本的功能已经很熟悉，容易陷入思维定势。而售前人员对产品新功能并不熟悉，可以提出一些不一样的视角。...

  测试人员按照下面几点执行即可：参考需求描述文档和设计文档，设计全面的测试用例破坏性测试对测试之后的bug进行总结，不断循环

  清晰的需求描述文档和详细的设计文档是好的编码质量的基础。所以编码人员需要确保对需求文档和设计文档的理解。在此基础上，编码人员按照设计文档编码。有些编码人员提到不知道如何提高自测覆盖率，其实这跟编码一样，只要按照设计文档进行各种case的自测就能保证足够高的自测覆盖率了。...

  设计评审分两块：后端设计评审和前端交互评审。后端设计评审。把后端组长带起来，确保其设计文档质量；然后后端设计文档一律由组长带动进行内部评审，过关之后再组织外部评审；外部评审的参与对象包括架构师、测试人员。前端交互评审。前端交互评审采用轻量化的方式。由前端组长带动大家（主要是产品、测试人员）一起逐步形成完善的交互规范。凡是交互规范里提到的，一律遵循；其余个性化的写在交互设计文档里。  ...

  首先，需求评审的主要靠产品。但是，仅靠产品是不够的，还需要后续的架构、设计、测试人员进行补充完善。技术类的产品更是如此。所以，在很多公司，最终如果发现需求评审有问题，从责任的角度：产品一定主责架构/设计/测试人员次之。当然这个是有条件的，条件是“功能点存在，但是不够完备”。如果是一个独立的功能点在需求描述中缺失，那么架构/设计/测试人员是免责的。...

  管理者辐射的是整个团队，是大家的主心骨，必须具有公信力。如果要让大家信服，必须言而有信，切忌为了短期目标而轻诺寡信。一旦失去了团队的信任，做起事来势必大受影响。...

  《孙子兵法·始计篇》说到“主孰有道？将孰有能？天地孰得？法令孰行？兵众孰强？士卒孰练？赏罚孰明？吾以此知胜负矣。” 法令孰行，讲得是法治的重要性，赏罚孰明，讲得是一碗水端平的重要行。对于任何一个管理者而言，该法治的地方务必法治，该一碗水端平的务必端平，否则必定引起团队成员的不服与猜疑。...

  项目在推严格的质量管理体系，对需求说明书、设计文档、编码质量、测试质量，都提出了严格的要求。这时候，每个环节的责任人，必须具备把相应事情做全、做深、做细的能力。其实这个能力是专业人士应该具备的，而且一旦具备了这个能力，也应该是可以泛化到其他事情上的。所以，“做全、做深、做细的能力”应该成为人的基本素质。...

  首先，我们要给下属试错的机会。因为他们自己从错误中的成长才更扎实。但是，却不能一味的试错，务必及时的抓住其失败的案例，与其一起总结，促其成长。...

  对于想以后从事管理岗位的人来说，做深自己的专业领域固然重要，但是也一定记住抓住拓展自己广度的机会。因为对于管理岗来说，知识的广度会使得管理者更容易与人沟通。所以，抓住拓展自己广度的机会，相当于为未来的管理工作提前做了储备。...

  很多人常说要感恩遇到的贵人。反过来讲，在团队管理中，我们也应当力争做下属的贵人，我们也应当有这个责任。我们把自己走过的坑，自己积累的经验倾囊相授，下属自然更容易成长，自然积极性就高。...

  职场中经常看到有人处于这样的状态：一周过完了，却发现好几件该做的事情都没做，或者做了但是却又没有做好；但是回想一下，这一周却又是很忙碌。  出现这种现象最常见的原因往往是：没有好的目标，更没有可执行的任务清单。没有好的目标，都不知道要做成什么样，觉得做完了，才发现漏洞百出。没有列好任务清单，自然会出现事情遗漏。到头来却发现做了好些不重要的事情，重要的事情却没有做。   解决办法就是...

  只有你管好了自己的时间，你过得更加从容，你能够拿出更多的时间去做重要不紧急的事情，你才不会整天被那些重要紧急的事情追在屁股后面不断的要你去救火。...

  项目上问题很多，从需求、设计、编码、测试、验收，流程上的每一步都不尽完善。各个模块从组长到组员，也都有很多提升空间。  现状如此，急也急不来，只能是一个长期的过程。眉毛胡子一把抓，没法聚焦，反而没法解决问题。更需要的是一个个问题、一个个人进行单点突破，一步一个脚印，迭代式的进步，逐步的把问题都解决掉。  第一阶段：优先解决设计文档（含后端设计、前端交互）、需求描述、测试和验收的质量问题...

  工作当中，每人都可能有不同的处事方式。有的处事方式甚至与自己差异很多，甚至很不认同。但是这始终是正常的存在，不能因为不认同就不去协作或者采取过激的行为。这种情况下，我认为通过“沟通”达到“求同存异”是很好的协作方式。  于是当实际工作中需要与人协作（不管是上级、平级还是下级）时，特别是当对方的处事对自己的工作造成影响时，多沟通。我认为沟通有几种类型：一般的沟通。当需要对方协作时。开诚布...

  最近一周主要精力放在某个一个项目，对另外一个项目管得较少，昨天项目经理突然说要急着上线（测试人员还没有正儿八经测过），跟他说风险太高，才意识到问题的严重性。匆匆忙忙，只能叫相关人员加班。  像这类情况，原本是可以避免的。避免的方式是：事情做好规划，推演可行，留有buffer，按照节奏去执行。所以，管理者一定要有远见，事情想在前面，做好规划。...

  前面有几篇提到管理者要适时的Involve进去（管理：没有调查就没有发言权、如何指导下属把事做好之“案例管理法”），但是管理者也千万不要陷入Involve进去的误区而出不来。  调查也好、案例管理法抑或其他Involve的方式，是根据问题的实际情况而采取的措施。只有判断下属没法有效解决问题或者下属已经尝试去做仍无法解决问题时，管理者才需要Involve进去。管理三类人里我们也提到，对于“...

  公司某个项目质量一直不太好，也找了专人负责质量这个事情，但是却迟迟没有成效。根据情况做下分析，原因有如下几个：确定对质量有效的事情，没有得到很好的执行。比如设计，而设计没有很好得到执行的原因是负责人没有实际深入进去把设计带起来其他的措施也都是些common sense的。比如加testcase，但是实际做testcase的人却没法保证testcase的覆盖率和有效性。  无论第一种还...

  昨天的会议开的是一团雾水，毫无主题，开成头脑风暴了

  发现前段时间陷入了一个误区，项目中暴露的一些问题，都是自己在分析、想解决办法。这种方式带来了不少问题：自己的时间和精力被大大分散，几个项目相互挤占时间项目成员少了发挥的空间解决问题的速度也慢了不少  今天开始换种思路，多去了解项目成员的诉求，将问题的解决与项目成员的诉求结合起来。比如前端的某同学，有意愿走技术+管理的路线，那么正好可以请他带领前端组解决前端的质量问题。  了解每个...

  上周做过一轮全员测试，积累了不少bug，加上一些遗留问题，导致问题数激增。但是在这个版本的项目管理过程中，焦点都集中了在新功能上，忽略了这些老功能的bug，导致版本接近交互了，还有不少严重问题。  就这次事件进行总结，项目管理需要适时的关注细节，但是永远不能忽略全局：新增或改进功能点老功能的bug全局的时间点…...

  公司在做“通过sql解析获取血缘关系”的工作，原本相关人员预估的时间是一周，但是最后两周了还是没有完成。分析下来，主要是两个具体原因：相关人员认为自己开发完成就可以了，忽略与与相关模块联调的时间没有与业务结合起来，单纯从技术角度评估任务的完成度  总体来讲，根本原因是缺少了全局视角，任务分解不彻底，带来的直接后果是导致该任务的延迟，带来了项目的风险。所以在产品研发中，任务分解的能力很...

  初创公司的产品研发在摸索当中，问题很多。作为项目管理者，如果每次碰到问题，都involve进去具体解决，那么势必会陷入具体事物的泥潭出不来。需要做的是，每次发现问题之后，都总结为一类问题，形成该类问题的规范，下次碰到同类问题时，按规范执行就可以了。  现在我们已有的规范有：项目管理规范质量管理规范前端设计和交互规范继续加油，形成更多的规范...

  测试一直反馈“前端对设计和交互的考虑很少”，而前端又一直不认同。于是，测试整理了一些设计和交互的建议，大家一起开个会一起讨论下达成一致的，加入前端的todo list没有达成一致的，由前端去调研主流的网页设计和交互方式，整理几个方案，让后大家再讨论一次，最终达成一致，然后加入前端的todo list  所以，在团队协作中出现不一致时，大家充分讨论，各自提出自己的证据，最后达成一致，然...

  在项目管理中，最近发现一些很不好的现象：临近版本交付了，测试人员才说还有很多bug没有闭环产品也不去考虑最终版本的交付目标这里边根本的原因还是没有定义每个成员完整的职责。对各个成员的职责定义如下：|角色| 职责||–|--|| | |...

  在工作中经常看到，有不少人讨论起问题来，说的头头是道，但是实际解决起来却是一塌糊涂，甚至很多时候压根都不付诸行动。我们不妨称之为理论派，他们的根本问题在于不去实际行动，看问题都停留于表面。  在实际工作中，我们要想避免这种情况，最根本的还是去转化为实际行动。只有转化为实际行动之后，才可能解决问题。只有转化为实际行动之后，才能在实践中验证所想的方法是否可行，才能在实践中不断的碰壁、分析、行动、...

  初创公司百废待兴，人少钱少事多。怎么办？其中很重要的一点是要想办法提高团队成员的积极性。薪酬没有大公司高，平摊到每个人身上的事情又那么多，凭什么可以让大家积极性高呢？  初创公司其中一个很大的特点是问题太多，但是这些问题恰恰是每个人成长的机会。把难题尽可能地交给大家去独立解决，每个人在解决问题的过程中不断成长，当问题一个个解决掉之后，每个人自然就变得强大起来。当然在这个过程中，还是要积极的提...

  常常有管理者报怨，下属做事不到位，很多事情只能自己来，结果自己的时间完全不够用。当被管理的团队人数越来越多时，这个问题尤为突出。  管理很重要的一点是因人而异，所以我们可以将下属分成三类人，不同类的人采取不同处理方法：第一类人：顶尖人才，具有足够的能力完全独立把事情做到位。这类人中最顶尖的，即便是一个新东西，他也有足够的能力去学习、去分析，把问题解决，甚至最后形成处理这类问题的规范。在管...

  项目管理者需不需要具备多技能？  前面博文我们也提到，除了项目管理本身的职责外，项目管理者需要熟悉产品、懂技术，这些是必备的。除此之外，个人觉得也应当具备下面的技能：具备判断项目中的每个角色的产出是否到位，时间规划是否合理的能力。如果产品研发中的各个角色做事都很到位，那么这一点似乎必要性不强，但那也仅仅是如果。所以这一点还是要必备的。必要时，如果能做一些辅助某些角色，甚至补位的能力，那...

  项目管理到底需不需要懂产品？  项目管理对产品肯定是要有基本的了解的，知道有哪些功能点，熟悉产品的用法。这样才能对产品研发有个宏观把握，对计划有预估，执行过程中也能更好的控制风险，当出现变化时也可以很好的应对。...

  到底管理项目需不需要懂技术？  之前一直认为项目管理不需要懂技术，即便懂也可以不介入技术，现在越来越发现项目管理至少需要对技术略懂的，至少清楚技术模块、基本架构、流程，只有这样，才可以把控产品研发中的各个点。有的公司则干脆项目管理者即是技术领导。...