启示录
文章平均质量分 80
记身边人给的一些启示
禅思院
靡不有初,鲜克有终
展开
-
老大语录一 谈管理
但建立流程时往往会受到部分人员的特殊甚至是个人诉求,如此叠加形成了复杂冗余的流程,更可怕的是这会以所谓“本企业特色”掩盖了优化的动力。之所以会出现对组织人员的素质会有过高的要求,是因为往往事务进展不顺时会发生在某个个体身上,我们往往会开始纠结于某个人如果有更强的职业素质或者综合能力(这里不讨论专业能力不够的情况下),事故就不会发生。并且一般事物来讲,人才的贡献边际效应一定是递减的。管理逻辑是根据业务需要组建适合的组织,梳理出主要的业务流程(主业务和支撑业务),制定合适的管理制度约束组织和流程的行为。原创 2024-02-28 21:53:30 · 448 阅读 · 0 评论 -
我的这些年与前端
这篇文章起源于我在面试回来的路上,跟我目前在这家外包公司做兼职的一个前端工作者闲聊沟通说起前端这个行情怎么样?他是西安的,而我在郑州(之前在苏州工作),听他说 西安比至郑州强点,西安比北京、上海、深圳差点!这两年大环境不好,估计好的工作很难,郑州遍地外包,短期,项目制的,到项目结束,何去何从也不知道。原创 2024-07-10 14:37:27 · 485 阅读 · 0 评论 -
老大语录七 谈问责
在前面的假设下,在一些特殊的阶段,我们可以只处理一件事情,这样往往会处理的更好。这会给协同工作的多方一个信号,谁都不会愿意自己成为第一责任位置,这个效果会链式的传导,进而让各团队恪守住了自己的职责。但很多时候会陷入一种困局,那就是你会发现在讨论事故责任时,往往各方都会举出不同团队各种层面的问题,进而导致好像说的都没错,各方都有失职。这也往往是开头说的各方都能提出专业的观点,都是客观的可能会引起项目失败的风险,甚至可能是更核心的原因。虽然粗暴,但特定时间往往会的奇效,那这也不失为一个好的启示。原创 2024-04-16 08:16:54 · 184 阅读 · 0 评论 -
老大语录六 谈产品规划
除了稳定的需求来源,产品还可以有创新需求,对于这种需求规划的要求就是,创新不是一味的天马行空,它需要论述清楚线索,这里是线索,不是依据,并且创新型需求的比例要控制,比如不能超过20%。最后,就是根据能力和场景,总结出功能,这是结果,论述清楚这些功能逻辑上是否能支撑需求就可以了。最喜闻乐见的是,会有一个专家组织对某一产品的规划进行了形式上的评审动作,他们有的并不关心该产品的前途,亦或上升为不对公司的投入成本及前景负责,还有的是专业性不太够,甚至不了解产品是什么,最好的情况是只能从形而上的一些形式上进行挑战。原创 2024-03-26 19:25:11 · 894 阅读 · 0 评论 -
老大语录五 谈实地考察
以上的方式其实是一个比较标准切入项目的方式,我们通过很多资料,以及项目经理及其它干系人了解到这些信息后,基本项目状态就掌握了,再制定一些合适的项目管理手段就可以掌握起来,带领项目方向。很多人可能会有一种同感,那就是当一些项目出现问题,需要我们开始关注该项目时,我们会感觉始终不能够触摸到项目的核心中,无法成为项目的局中人,只能浅层次的了解下项目的基本情况,浮于表面,无法有掌控的感。项目的由来,(我们动作的还是客户主动建设,亦或是其它对手创建,我们入局的)。的切身体会,从而有效地了解上面的所有信息。原创 2024-03-26 17:05:51 · 275 阅读 · 0 评论 -
老大语录四 谈日常工作
只要有具体的工作目标,就可以使用这个方法来输出工作计划,又由于此方法具有滚动优化的特性,重复使用可以不断优化我们的工作效果,还可以不断从执行结果中修正抽象模型和分析结论,最后达成工作目标。当重要举措清单有了之后,拆解成工作项,根据依赖条件情况,结合现状,编排行动计划,行动计划可以是阶段的,也可以是全年的工作计划。分析因素,总结问题。它的特点是以目的导向,最后形成的举措都可以清楚地知道它在逻辑框架中的作用,每一步也承接了上一步,是分层思考的形式,对于复杂问题来讲简化了思考难度。原创 2024-03-20 12:50:33 · 871 阅读 · 0 评论 -
老大语录二 谈规划
在这之间就有了取和舍,并且也更专业的满足的客户的需求。Tob 类产品需要明确该功能的使用方是谁,一般在什么情况下会切入到该功能,用户看到该功能时下意识希望该功能输出哪些信息,该功能在交互中的期望反馈是什么。比如常见的审批流程,看是就是简单的审批流,往往底层的工作流引擎是需要沉淀的,很多团队也依靠这些沉淀开发出工单系统和OA系统。产品的定位,不同专业功能的敬畏,以及不明确场景下的减法。以上就是对产品功能规划判断的思考,也许有更好的评判公式,但实际经验中的总结也未免不是一种高效的方式来帮助我们来正确的做事。原创 2024-03-06 18:45:59 · 553 阅读 · 0 评论 -
老大语录三 谈需求变更
• 不要强制定义谁的权利,论述清楚底层逻辑更重要。团队成员有权利知道这些。• 团队只有在一个底层价值观下,才能达到士气上的一致,才不会疲于解释各种现象,安抚各种情绪。• 让感知利害关系的人做决策。且敬畏不同的专业。• 方案要基于人性但不是以此为中心,当人性与客观事实存在矛盾时,需要像现实妥协,但仍然充分考虑人性。需求变更,研发人员最讨厌出现的情形。这个是根本上的反感,即使抛开需求变更带来的计划打乱,可能带来的大家需要加班加点填补变更带来的成本。原创 2024-03-12 13:11:45 · 782 阅读 · 0 评论