vlambda博客
学习文章列表

2020年5月19日

进展：

• 针对费用优化专门安排了时间进行推进，同时推进的节奏也特意进行了思考和安排。从任务整体来看，是一个复杂长时间的过程；但是通过思考，将任务拆解成每天都能推进的最小化单元，执行难度直线下降。对于此目标的信心指数回调到0.5。

阻碍：

• 以现在的人力储备，重新考虑设置两个目标是否合适？目前的情况是集中攻克一个目标，带来的收益最大。但是费用优化和稳定性提升这两个目标，在现阶段又都是P0级别，没有长时间停止一个的选项。破局之法是什么？既然症结是人力，那么可以尝试从人力的借调上入手。明天安排个时间跟其他部门的人协调下，看看有没有一周借调2天的可能性。

主题学习方向：

        马斯洛需求层级的深入分析：从现在的知道变为详细了解，并能在之后的管理中灵活运用。

小感悟：

人肉编译器

        今天又造了一个词：人肉编译器。灵感的来源是业务研发，在昨天思考如何破OKR推进之难的困局后，有了新的启发。那就是：我司现在一线的业务研发到底算不算是脑力工作者？到底有没有创造性可言？还是说只是“人肉编译器”，把需求方的自然语言转化为计算机语言。

        绩效使能在发挥内驱，提升创造力上有巨大的正向促进作用。但是一线研发的工作中如果没有，或者只有少的可怜的创造性，那么KPI这种注重结果达成，追求执行效率的绩效考核方式更合适。所以我们需要优先搞清楚的一件事情是：我们的团队是否真的具备实施OKR的条件？还是说只有一部分货真价实的脑力工作者具备这个条件？

        OKR能否顺畅实施，团队的准备度很重要。摘要出三个评估要素：业务不确定性程度；管理成熟度；员工成熟度。

• 业务不确定性程度：OKR天然适用不确定性程度高的业务，对强调敏捷，强调快速适配需求不断调整目标的场景，特别适合采用OKR。但对于确定的部分，比如一线研发的职责：转化确定的需求描述为代码逻辑。如果不能给工作注入意义，那么编码工作将沦为无趣的、被动的工作，研发也会成为人肉编译器。而工作的意义需要管理者来注入，这就涉及到了第二个要素，管理成熟度。

• 管理成熟度：管理者敢于放权，敢于让员工自由发挥，过程中起到教练的角色，给与帮助和支持。如若不能，管理者事无巨细的都要管一管，这种管理理念和OKR是冲突的，也就不适合引入OKR来进行管理。信任是开展OKR的前提。

• 员工成熟度：OKR希望激发员工的内在动机，员工的内在动机受其所处的马斯洛需求层级所制约。如果员工主要诉求是物质和金钱，那很难和他们去探讨诗和远方。在开展OKR之前，评估一下员工是否足够成熟？是否有主动做事的激情？如果没有，需要先促成这一点，否则引入OKR只会带来更多混乱。