摘要： 工作量的衡量标准 大部分TL会将产出与时间挂钩，将时长与产出挂钩是最原始的管理模式，且含金量越高的工作和时间相关性越低。 为什么这种方式那么普遍呢？笔者分析有以下两个原因： 一个纺织工在怎么突破也不会比别人双倍时间的产出高，经历过这种生产方式，潜意识里会认为产出等于时间。 加上这种方式实施起来不需要 阅读全文

摘要： B端项目即是需求明确的项目，又是需求最容易出现误差项目 需求明确指的是需求出自客户之口，入于吾耳相对于C端项目跟明确。容易出现误差是因为B业务复杂，不可能一次性完整描述。 缺少同理心 我记得有这样一个故事，有人问一个农民：“你认为当官的家里都有些什么”，农民答：“那肯定是堆满了粮食，挂满了腊肉”。 阅读全文

摘要： 守规矩的人我们喜欢，会变通的人我们也想要 作为一个TL期望下属按照自己制定的规则去执行，又期望下属在处理事情的时候能够灵活变通。到底是要不要变通呢？看上去矛盾了吧！ 其实二者并不会相互矛盾，本质上就是上级想要的就是在对的时候做对的事的人。 但在下级出错的时候往往会向下级强调其中一点，等于是向下级传递 阅读全文

摘要： 近期在学习产品经理的一些技能，有在抖音上看到@李三科的讲解，大部分讲的还可以，其中第二篇关于需求调研问题设计的案例，笔者觉得不是很恰当，下面说下笔者的看法。 首先介绍下背景，基于鼓励创作者而新增一个“打赏”功能，作为产品经理你回如何设计需求调研问题。李老师说了两个技巧，其一是多问用户过去发生的事不能 阅读全文

摘要： B端产品的一个特点是：需求会一直变化。相信每一位程序员都遇到过不断修改的需求，除了抱怨客户之外还有更好的办法吗？ 我们要把握一个核心：帮客户解决问题 需求变更的成本是巨大的，虽然不能做到100%的需求解读率，但却可以不断优化。 对于客户的需求整理成功能点进行确认，有条件的可以现场模拟一遍。有歧义的地 阅读全文

摘要： B端产品的一个特点：一个人有多个角色。即A角色的权限他有、B角色的权限他有。 这会带来两个问题： 一是需求访谈时角色边界模糊，对我们的设计造成一些困扰 二是对于有多角色用户，其流程可以更简洁 举一个例子 在上帝视角我们将系统中的角色分为ABCD。 如果是全新的领域我们需求访谈的对象所拥有的角色有A有 阅读全文

摘要： B端产品的一个特点：对接的都是客户的具体需求，也就是需求过来的时候已经是很明确的了，工作内容集中在如何实现。在这基础上就伴随着另一个特点，就是本文即将提到的“无法得知完整的需求” 这个无法得知的原因有很多，比如说能够完整描述需求这件事对于客户来说是非常困难的；如果是从0-1孵化一个新项目，想通过需求 阅读全文

摘要： WPF 反射 加载异常 阅读全文

摘要： 知识的诅咒 权利的诅咒 环境盲区 真实经历 前方实施同学，急需某功能。在我的认知这边进过评估后直接回复的是“这个功能下个版本才有”，结果被领导看到了给出的评价是“后方开发人员不能理解前方人员的难处不能积极配合”，领导随后说“前方需要的功能必要时可以通过补丁的形式给出去”。抱着赌气的心态将这项任务转给 阅读全文

摘要： 问题描述 表象 拾取元素时出现“穿透”，通过 WindowsAPI 拾取目标控件元素信息时，鼠标拾取元素的同时还执行了目标控件上的操作，这种情况是不允许的。（PS：通过单击进行拾取，常规情况下已做了屏蔽，不会执行目标控件的操作） 里象 经过分析和测试，得出结论。误操作的控件绑定的不是 Click事件 阅读全文