一思二想

Think with a wild mind!

发表于 分类于 ，

在产品研发项目管理中，我们通常会接触到两类项目，一类是在现有现有产品基础上增加新功能；另一类则是需要从底层和架构层面做出变革的新产品引入。
对于第一种项目，也可以说是在现有产品技术架构和研发运作模式下的“迭代”开发。相对来说，不管是从项目本身的需求澄清、工作拆分，到具体开发实施，还是研发团队的运作模式，都是在已有框架下进行的。因此，我们的关注点更多是对现有流程的优化和持续改进，从而不断提高新功能的研发效率。
另外一种情况，我们需要根据新产品、新技术的特点，从整体架构设计开始，重新引入一个新的产品。但是，项目团队团仍然是同一个研发团队。甚至大部分情况下，为了保持整个公司运作模式的统一，新产品仍然要去遵循现有的工作方式和流程。这时候，就会出现项目团队的组织形式和工作模式，与新技术、新产品不能匹配的情况。这也是很多公司在推出新产品方面都动作迟缓的原因，甚至说，越是成熟的研发团队，推出新产品的速度反而更慢。

那么，如何在一个相对成熟的组织中引入“新”产品呢？

在具体实施之前，我们首先要明白，我们所谓的“成熟”的组织，到底是指什么？我们可以从几个方面来看。
首先就是整个产品的技术方案和架构已经相当成熟和稳定，与此对应的，我们的研发团队的设置也必然与整个产品的架构高度匹配，比如研发团队的技术领域的划分与产品的模块划分一致。并且，这种高度匹配会随着产品新功能的不断开发而不断增强。这是通过技术分工来最大化研发效率的必然结果。
与此类似，整个团队的运作模式也与产品架构高度一致。也就是说，整个研发的工作流程，从开发到集成测试，再到最后的发布模式，都与产品特性严格捆绑。
所以，从团队设置（技术背景、领域划分）到研发工作模式（WoW）都相当成熟，甚至说已经根深蒂固在所有团队成员的潜意识里。

在如此“成熟”的组织中，如果我们想引入一个全新的产品，就必须从团队设置和工作模式入手，针对新产品进行全新的组织划分和流程设置。否则，我们需要花费大量的时间去研究如何使新产品去适配这些“成熟”模式中。

  1. 像组建“创业团队”一样组建新产品研发团队
    新产品研发团队的组建，要基于新产品的技术特点和产品架构来设置。如果是一些技术难度比较大、模式新的产品，我们也要像运作创业项目一样，先组建特别小组进行产品原型验证，然后根据原型验证的结果组建正式开发团队，以确保团队的搭建满足新产品的要求。
  2. 重新设计针对新产品的开发流程和工作方式
    关于工作流程和团队之间工作方式的设计，我们可以在参考原型开发流程的同时，重点关注模块和团队之间的接口定义和责任划分，以及团队配合模式。具体关于流程的制定，可以参考流程。
    具体流程可以包括：开发流程、模块之间的联合集成流程、问题处理流程、交付流程等。

最后，如果没有条件成立单独的项目团队给“新”产品，那就要格外注意与现有“成熟”产品和研发流程的关系，从项目间的沟通机制上入手，最大限度避免来自“成熟”的产品和流程的干扰。

原文：https://mp.weixin.qq.com/s/2FvEcsS2WN9zJJrfYmCE2A

发表于 分类于 ，

在开始之前，先来看一下几个项目中常见的场景。

场景1：项目还在计划阶段，评估结果显示某个功能不能在设定的交付日期之前完成。作为项目经理，你要怎么做？
场景2：执行阶段发现了需求遗漏，你会要求团队增加资源投入，将新需求加入到项目内容？还是将新识别的需求计划到以后的项目中？
场景3：执行过程中，你发现某个模块的进度严重落后，你要怎么处理？
场景4：临近项目交付，测试团队报告说发现了棘手的技术问题，你会延期项目交付来解决这个问题吗？

快还是慢？
生活在一个快节奏的社会，面对工作和时间压力，每个人都在寻找能快速解决问题的方法。在软件项目管理中，我们也经常面对这样的情况。开发进度落后，马上增加开发资源，加班加点赶进度；测试发现了问题，增派更多专家加快解决问题的速度。这些措施表面看起来都没问题，但是往往执行到一半，就再次发现其它问题，于是需要推翻之前的方案，或者选择一个新方案。如此反复，浪费大量人力物力不说，项目也陷入问题的泥潭越拖越久。这些看似快速的方案，实则在拖慢我们项目的进度。
在《思考的快与慢》中说我们的大脑有“快思考”和“慢思考”两种模式，大脑的惰性会让我们更偏好“快思考”。而很多项目中的问题，也恰恰是“快思考”带给我们的陷阱。 要想避免被“直觉”绑架，就需要我们在面对问题，寻求解决方案时，强迫自己进入“慢思考”的理性模式。问题建构的过程，正是将我们从“快思考”模式拉入到“慢思考”模式的过程。

从“快”到“慢”：问题建构
对于我们熟悉领域的问题，我们会自然地在脑海里产生可能的选项，并且对某个选项产生特殊的偏爱，不管是出于项目利益，还是执行难易程度。这时候，我们就可以采取假设金字塔来对我们的偏好进行验证，所有的子假设都有数据可以证实，或者某个子假设被证伪，那就可以很容易知道执行起来可能遇到的问题，根据问题来调整我们的假设方案。
另一方面，对于一时无法给出假设方案的问题，我们可以借助“问题树”框架对问题进行拆解，一直到我们能够直接给出解决方案的子问题，然后对子问题的解决方案进行汇总和整理，就可以形成对核心问题的可行性方案。

“慢”下来看看
再次回到文章开头提到的几个问题，是不是可以得到不一样的处理方案？我们以场景1和场景4为例。

  1. 假设金字塔
    场景1：项目还在计划阶段，评估结果显示某个功能不能在设定的交付日期之前完成。作为项目经理，你要怎么做？
    图片
    图1：问题建构：假设金字塔
    一旦某个子假设不成立，那么我们的核心假设就不成立。我们要么是子假设成立，要么修改我们的核心假设。

  2. 问题树
    场景4：临近项目交付，测试团队报告说发现了棘手的技术问题，你会延期项目交付来解决这个问题吗？
    图片
    图2：问题建构：问题树
    基于这些问题的答案，我们可以提出假设性解决方案。之后，我们可以再次通过假设金字塔来验证我们的方案是否可行，并根据验证结果对方案做出调整。

拙速：“慢”即是“快”
从以上两个问题构建的例子可以看出，对任何一个问题，我们可能凭直觉就会产生一个假设性方案，但是真正是否可行，还需要我们静下心来，通过问题的建构过程，老老实实分析一遍，最后形成真正可行的应对方案。看似笨拙，实际中却大大降低方案的风险，加速问题的真正解决。这时，慢，即是快！拙，即是速！
道理千万条，实践第一条，真正的高手，是那些能够在实际中坚持践行并不断探索的人。处理项目中的各种问题没有什么捷径，让我们脚踏实地，拙速前行！

原文：https://mp.weixin.qq.com/s/ebM9miFZmv_3b6BZueNt9w

发表于 分类于 ，

在实际软件项目中，我们会遇到各种问题，开发延期、测试被问题阻塞、软件实现与客户需求不匹配，等等。特别是一些棘手的技术问题，问题本身在技术或者复杂性上很难解决，再加上软硬件资源的限制、紧迫的时间压力等等，我们一下子会觉得无从下手。这时候就需要我们“回到初心”，跳出问题本身，来想想我们解决这个问题的目的是什么？有没有其他途径可以同样达到同样的目的？带点儿“功利心”去看问题。

对于技术问题，问题本身的目的可能很明确，可能是提高某个软件模块的性能指标、降低某个硬件模块的能耗等等。这些首先需要技术专家去从技术方案上来解决，另一方面，从项目管理的角度来说，作为项目经理，我们可以多问几个为什么，进而发掘问题背后更大的“动机”。比如我们解决这个问题的目的是什么？是为了给客户提供更好的使用体验？是减少整个系统的能耗？那么，从项目上来说，我们有什么手段可以达到相同的目的？这种“功利心”可以有效帮助我们回到初心、明确方向，而不是为了解决问题而解决问题。

一方面，我们可以将目光看长远一点，如果问题针对的是一周，那我们就放眼一个月，如果是一个月，就放眼看一下三个月后的目标。这可以使我们在一个更长的时间维度来重新审视问题，问题的解决就会有更多的可能性。

另一方面，就是站在更高的维度去重新审视问题。在一张白纸上画两个点，我们都知道，两点之间的最短距离就是连接两点的直线的长度。但是，这只是从二维的角度来看。如果我们从更高维度去来看项目中的问题，就好比从三维的角度去看待二维空间里的问题，问题本身就会遭受“降维打击”。更高的维度，我们有时候会说成是“上帝视角”，在项目中，就需要我们经常跳出问题本身，以局外人的角度重新观察当前的问题，让自己做一次“上帝”，有了清晰的思路以后，再跳入进去，如此往复。这就好比从三维世界来看待二维白纸上的那两个点，解决问题的思路也会豁然开朗。

所以，对问题的认识和理解，不仅要“功利”地去挖掘问题背后的目标和利益，而且还要从更大的时空维度来看待我们解决问题和目标。

发表于 分类于 ，

项目需求是指在软件开发过程中，为满足业务需要而提出的对系统性能、功能及其他特性的需求说明。项目需求的充分准确地表述对软件的开发和后期维护有着至关重要的作用。不仅如此，项目需求还对用户体验、软件质量以及对外竞争力等方面都有着重要影响。

然而，在软件开发过程中，存在一种情况，就是项目需求的遗漏。项目需求的遗漏会给软件开发带来什么影响？如何避免项目需求的遗漏？下面我将从这两个角度分别进行阐述。

首先，项目需求遗漏所带来的影响是非常明显的。一方面，项目需求的遗漏容易导致软件的缺陷出现在软件测试的后期，从而导致软件项目的进度延迟。另一方面，在软件的发布后，如果用户对软件原有功能的表达需求没有被考虑到，那么软件的使用体验便会受到影响，进而影响到软件的市场反响。除此之外，项目需求的遗漏还可能使得软件在后期维护过程中变得更加困难和复杂，从而增加维护成本以及减缓软件的更新速度。

那么如何避免项目需求的遗漏呢？与其说是避免项目需求的遗漏，不如说是在项目需求管理中充分考虑各个环节的配合和把控。

  1. 需求收集时尽可能全面：在项目启动初期的需求收集阶段，应该尽可能全面地收集用户需求，甚至可以多找几个用户来进行面谈，以确保所有的需求都被考虑到。

  2. 需求审查：需求审查是严格把控要求的一种方式，审查过的需求更容易被发现。组织需求审查小组，让多个人来评审项目需求的完备性和准确性，以确保需求被充分审查，它的质量更高。

  3. 反复确认需求：在整个开发过程中，需求不断变化，因此要及时反馈和确认需求变更，确保最新的需求一直被跟踪和纳入设计中。

  4. 开发过程中及时发现遗漏：开发人员在进行软件开发时，应该定期检查需求文档和设计文档，尽早发现需求遗漏并及时确认。

  5. 客户反馈：软件发布后，客户反馈也可以督促开发人员及时发现需求遗漏，并尽快纠正。

总之，项目需求的遗漏会对软件的开发和维护造成非常严重的影响。因此，在软件设计的初期，应该全面、准确地收集、分析、充分考虑用户需求，保证设计出的软件全部能够满足用户的需求。同时，需要各角色之间的配合和协作，确保需求信息的有效传递和反馈，避免因为信息遗漏而影响项目的实施。

原文： https://mp.weixin.qq.com/s/eYkXt28QMSw0Bi1BDUHU6A

0%