编码问题引发的思考
有一个编码实现问题，团队小伙伴有点搞不定了。测试了好几轮，核心的问题始终没有得到有效解决。眼看产品发货日期临近，我不得不向上反馈，技术负责人很快定位了问题，但是由于之前的程序架构他没有参与，改动起来也是比较费时的一件事。最后，在技术负责人的指导下，还是由团队小伙伴一起在原有架构基础上加班加点，完成了程序的定版工作，但定版的程序在可知的范围内仍存在一些缺陷。
周末适合总结，今天就来说说这件事，记录一下我的思考。
一、向上管理
领导的时间有限，有很多其他的事情在争夺他们的注意力。本质上，他们需要了解的是你是否令人满意地处理了一切问题，还是需要他们出面干预。
遇到什么样的问题，需要向领导寻求帮助呢？
也许需要考虑你的产品与其他一切正在发生的事情比起来有多重要。如果你的产品是公司的核心产品之一，且关系到公司未来潜在的收益，而它出现了一个问题，可能就会对收入产生不利影响，那就值得把这个问题（和解决问题的一些想法）报告给上级。
在什么时间节点向他们汇报呢？
因为实际工作仍然是团队在执行，在团队小伙伴的工作没有触碰到深水区和足够折腾之前，太早不合适；但如果是在截止之前一两天，把一个较难的问题扔给领导，估计也只能是挨骂的结局，这不是寻求帮助而是扔雷了。
想要把握好这个时间节点，可能是一个综合要求。需要产品经理或项目经理能够比较好地把控产品的整体进行状况，一是团队小伙伴的技术能力及执行情况评估，我们并不擅长发现自己的问题或者经常高估自己的能力，导致总是到无法解决的关口才开始想备选方案，这就涉及到下面第二部分所说的“向下管理”；
二是前期的技术风险评估有没有做以及做到什么程度，在开发过程中需要及时回顾并做出适当的评价，当确定是技术难点时则当机立断进行技术方案沟通和复审，这涉及到下面第三部分所说的“技术复审”工作。
二、向下管理
有一个典型的错误式向下管理方式叫做“狗吠式下命令”：像狗吠一样军事化地下命令，这种方式没有想到过要给下属充分的时间来融入工作，并理解他们在做的事情，甚至提出很不合理的要求。
而和“狗吠式下命令”相反的是，我称之为“理想式撒手不管型”。主要表现为：提出最终要做的事情，盲目地信任下属的能力，不评估下属的能力现状，以为每个人都可以自主、自动、自觉地完成每件事情，关键过程和节点不把控，总是到最后才发现，结果和要求的相差太大。
这两种错误，我都犯过，尤以第二种错误影响大。以前刚做管理时常犯第一种错误，后来意识到问题，但又走入另外一个极端，常犯第二种错误。
前段时间看《产品经理方法论》，书中提到向下管理的“情境领导理念”，这套理论由行为学家保罗·赫塞博士（Paul.Hersey）和肯尼思·布兰查德（Kenneth Blanchard）提出。作为一名经理，你需要搞清楚你团队中每个成员都身处哪个学习阶段，然后相应地调整你的管理方式。记住一点，人们可能在不同的任务上处于不同的阶段——有人也许对开展可用性测试轻车熟路，但或许在做展示方面需要一些指导。
“情境领导理论”需要有效地去评估团队中每个角色当前所处的状态，根据不同的要求去管理不同的人。用一个同事的话说：我们当前还处于社会主义初始阶段，你不能要求每个人都具有小康社会时的觉悟，也是有一定道理的。
你可以采取直接下命令的方式来管理新手，因为他们通常热情很高，但并不知道他们正在做什么（不知道自己不知道）。你可以仅仅告诉他们你想要什么，想要它怎么样，这么做并不会花你太多时间。
而在他们的能力有所增长之后，就会遇到现实的低谷，他们对工作的承诺可能大打折扣，所以你需要花更多时间来指导他们。这不仅应该包括告诉他们你想要什么，还要帮助他们弄清楚如何做这项工作。
然后，随着他们的自信与能力不断增长，他们的热情将会被重新唤起，但偶尔仍会受点儿打击。因此，你应当转换模式，更加信赖他们做事的判断，但仍在他们遇到困难的时候提供帮助。确保不要忽视这些更有能力的团队成员。他们可能仍需要你合理地花上一部分时间来提供支持与安慰。
当他们终于完全掌握了工作，他们的工作能力和承诺都会很高，你只需要把工作委托给他们，相信他们能做好就可以，这样你直接管理他们的时间就会减少。
三、技术复审
说回本文开头的问题，除了向上管理的时间节点以及向下管理的方式有问题外，产品的技术路线也是一个严重的问题。
在这个环节，有可能有多种技术实现方式，但最后应该殊途同归。所以，我们需要问的一个问题是：该产品会按照预先设计的那样正常工作吗？
正常工作有两个指标，其一是产品的进度完成情况，其二是已经完成的代码行数和文档页数。我所犯的错误是过度追求了第一个进度指标，而忽视了第二个质量指标。因为缺少了代码的评估，就无法保证上千行代码是有用的代码。这也是产品开发过程中常见的问题之一，也许“进度”完成了99%，但实际上完成的也许不到10%，因为代码可能错得一无是处，也可能只错了一点点，但修改起来需要花费大量的人力。
技术复审也许是解决办法之一，需要程序开发人员自己根据设计需求整理出来设计方案，设计方案需要涵盖产品应用场景、实现方式、异常处理、关键代码架构等，技术复审小组再根据文档和代码进行有针对性讨论和审核。
这个环节，产品能做什么呢？这涉及到第四部分，产品经理的核心职能。
四、产品经理的核心职能
作为产品经理，首先且最重要的职责是指导和塑造产品的成功与发展。
最近一段时间我反复总结，作为产品负责人，仅仅提出产品的需求书是远远不够的。还有几件事，也必须考虑得足够清晰才行，否则团队执行肯定出问题。
其一，是产品的实现逻辑。ABCDE，分别是怎么工作的，他们之间是怎么协调匹配的，谁在前谁在后，出现了异常会怎么样。这个环节一般需要画出详细业务流程图，然后按照分析正常与不正常的流转。
其二，是功能列表。清晰明白地将所有功能整理齐全，可以分模块整理，然后交代各模块之间的内外部联系；也可以按职能进行区分，每个职能完成的内容不一样，列出来并提出需要其他职能配合的地方，跨职能的边界是重点需要关注的环节。
第三，产品负责人需要提炼场景，也就是告诉开发人员现场是什么样的一种情况，产品会在什么样的条件下执行，客户一般会怎么操作仪器等。如果缺少了这一步，就容易出现本文开始提到的问题。
五、不要完全依赖于经验
即使团队内有一些高手，也不要完全依赖经验做设计定型，这方面的坑太多了。这不是说团队成员不值得信任，而是每个人都有盲点，不要想当然地进行设计，一定要可行、可靠、可验证。
另外，对于软硬件结合的产品，谁也离不开谁。硬件是骨骼，软件是血液。如果硬件设计不考虑软件，或者软件不参与硬件的设计指标评审，最后的结局往往要么硬件性能不达标，要么软件受限于硬件的设计而只能将就。
一周的产品问题总结，希望对你有所启发。