iSpiik快记102:过度管理 、过度需求、过度关心、过度保护…

问:过度的本质是什么,是范围问题吗?
答:如果是范围,那或许叫——管的太宽!比较合适。

过度是粒度的问题,管理上讲究粒度、需求实现也讲究粒度、连关心人都要讲究粒度问题。

A:【职场过度】相信有过职场经历的人都有感触,在非当前关键事项上,过度的细化规则制度,由此造成的人力、管理成本上升严重超过这种管理能带来的价值。
B:【行事过度】可以放在工作中、产品实现中,比如过度需求,你希望在一个迭代前把一些现在还不透彻的需求分析完全搞完,你希望在时间和资源有限的情况下还无限的扩展细节范围,这都是过度,希望是better其实是worse

对应的过度,其实还有适度和轻度(不禁又关联起来超筋、适筋和少筋梁的情形)

#ispiik小站#

iSpiik快记101:再谈手段与目的

任正非曾说:哪一天一把火将华为烧没了,你们“带着嫁妆,带着你的妹妹”都走了,但只要制度和流程在,我们就还可以再造一个华为……

“先僵化,再优化,后固化”的观点,是上世纪90年代华为请IBM做公司咨询的时候提出来的,现在已经成为华为系企业奉行的一项天条。

华为的2个方面也可以印证这个思路:
1、手段与目的的相对性,一定的时期手段是目的,之后目的又成为手段;但是手段肯定是为了实现目的的
2、重要的不是它是手段还是目的,而是我们时刻知道那个点它以什么定位存在能够产生符合使命愿景价值观的最大杠杆
3、手段也是团队资产

工作中、生活中我们都会面临类似问题,参加一个聚会的着装、进行一次商业谈判时愿景描绘、产品文档及代码管理工具……

iSpiik快记100:高手把目的当手段,低手把手段当目的

这样的案例在生活中听到、看到的实属不少。所有的BP大概就是拿着自己的目的作为撬动资本的手段吧,呵呵。高考时目的吗,显然不是,它只是进行人才分流筛选的手段,但是高考前学生的目的就是它,但是对于家长和学校又在用这个目的当作手段去激励和引导学生。做产品也不是目的,是实现商业价值的手段而已,商业价值又是为了完成使命愿景。

切忌把本该是手段的东西当作目的:有个人吃饭用勺子,勺子本来是工具而已,他非要找到一个完美的勺子去吃饭,结果饿死了(杜撰情节,现实中可能是你公司里面的KPI、某项极其形式的制度;最近纯银v分享个例子,他在taptap群给成员说不用回复收到,结果下面一排整齐的收到…… 先僵化后固化再优化,任正非的这个理念也要看应用背景)

目的,作为结果的同时,也是达成结果过程的一个条件。同一件事情手段还是目的是相对存在的,有了这个思维,做人做事中就会尽量避免短视行为,保持对远方的关注。#ispiik小站#

iSpiik快记099:雁过留声,职场人也总想留下点什么

拟定各种流程、制作各种模板、设置各种规则,这是一个人或者组织处事风格的抽象,或者说是价值观的部分具体体现…

每一个职场人或许都想留下点什么,我们拼命的向前跑,但是最终的终点始终是一个人无法到达的,我们需要一群人、更多的人加入一场逐梦的旅行。

自己也曾在团队中做过这样的事情,为了在线旅游小组和产品部门的交互更加清晰,自定改良版的确认件模板;为了策划小组的组建初期工作开展,拟定作业流程和工作管理表(事后看其实就是需求list);团队ERP产品的落地拟定了各种操作规范,还去往当时集团其他的子公司推广……

各种流程也好、模板也好,都是一种工具和手段,究竟目的?
①确定性——让多边协作的人保持在同一个语言和模式预期上,提高沟通协作效率
②指引性——在既定的框架内填充内容、事件、行为,更容易进入轨道
③标定性——就像大海上点亮的灯塔,你会看到需要到达的地方,不至于遗漏和忽略#ispiik小站#

iSpiik快记096:里程碑与确定性

【里程碑与确定性】职场中经常会遇到这种情形,面临某个艰难的任务,boss说:达到****数据/完成***工作,我们发xxx奖金+聚餐happy

这就是一种典型里程碑设置,当然更多时间你可能没这么好命。里程碑是在达到目标前的中间存在的,可以看作是对达标路上抽象的表达:

①人的内心渴望确定性,不管是参与者还是项目管理者,所以我们希望有明确的抽象出来的标点标定在预期(时间 资源)下达到的位置;这样才能更加专注和聚焦
②不断的对标,进行纠偏
③资源的阶段分配

iSpiik快记095:工作中的晨会

#晨会# 是很有意思的一件事情,一般会在打某个战役或进行某种项目时候发起的一种临时会议形式,可以将战斗意识注入到以天为单位的时间里面,每天的对标,重新建锚,可以让参与人员身心投入到进度、目标的关注上。

晨会X:去哪儿酒店BU当年做市场覆盖,考核代理、直销、夜销酒店签约数量。每天晨会会有几分钟的破冰互动(可能是个拉手转圈圈)、个人分享、数据概览、每个BD报今天自己的签约目标,然后撒网放BD,每天晚上收网拿回来签约协议然后电脑上线酒店产品。

产品实现过程中,一般也都会有晨会形式,保持小组成员信息的触达确保大家都是同步的,对X问题可以即时的投入关注和调整,算作是项目管理中动态管理的范畴。

所以说,瀑布模型和敏捷模型谁对谁错?简直是泥中有我我中有你啊#ispiik小站#

iSpiik快记094:产品工作量评估与工期

产品实现过程中,工作量评估出现不止一次:
①需求要想活,你得描绘它的性价比,在需求list入包的时候要初步评估一边工作量
②立项之后,需求确认冻结,这个节点有一个纳入工期的工作量评估,这个是需要尽可能贴近事实的

这个地方通用的三点估算法:(最乐观+最悲观+最可能)/3作为项目时间计划里的工作量。

为什么要估算?我们结构化拆解一下,工作时间包含:
准备和收尾时间
不可避免的中断时间
低负荷工作时间
正常负荷工作时间
其他交纵事项占用时间(比如某个攻城狮的紧急bug修复)

工期的得出怎么来?
①项目是有一个个功能list的点来的,称之为工序,工序之间存在逻辑关系,比如不张嘴怎么吃饭
②各个point的工期是条件
③其他的技术间歇、组织间歇等
④一个工期计划中,必然有一条隐形的关键路径,大佬尽量安排到关键路径,因为这个路径的延缓和提前是直接与工期相关的
#ispiik小站#

iSpiik快记093:做产品vs做项目|方向盘vs车轮

如同之前分享的:做产品充满了解构与建构的过程,解构用户的真实世界然后建构起来虚拟世界;项目管理重执行,更像是数学中一道有了完备相关条件(时间资源范围)的解答题。

换个比喻可以把做产品看作是把握方向盘手握挡杆脚踩油门刹车,你得看产品的发展、走向,驾校时候教练经常说:眼不要老看着引擎盖,看远些!项目则是在方向盘指明了方向之后,沿着道路前进。

杠杆也不同,方向盘在科三路考时候走直线那可是动都不敢动,生怕稍微动一下走到另外个车道了;项目就如车轮,你们给了方向油门,车轮就如是前进。

项目像正确的做事,产品像做正确的事,一个是事一个是风格,一个是画一个是画风

iSpiik快记090:迭代周期内的工作粒度怎么安排?

需求包的颗粒度要合适控制,一要具有关联性确保是流程线上的有关需求点,不至于一个批次的需求南辕北辙;

二是具有相互依存性质的特例需求,可能需求间互相依赖、需求和队友互相依赖,同样的这个问题在需求评估中也要考虑(类似于之前说的杠杆套,为了更重要的功能提前放出来的功能杠杆),每个批次需求包也好迭代周期也好,都有瓶颈所在,识别瓶颈才能迁就瓶颈;

三是粒度的划分要合适,这个问题我比作拿一个巨无霸面包吃和拿一个个一口可以吃完的面包的感觉,合适的粒度可以作为资源灵活调用,符合小步快跑的敏捷理念;#ispiik小站#

iSpiik快记089:价值需求、价值工程

每个人都面临过这种情况,A美食想吃、B美食也想吃、C美食也想吃,但是又不可能一次吃完,只能拍出来顺序,在一段时间内陆续吃完。

吃饭我们是怎么做选择的呢?
也许你会考虑,ABC三种的价格,到达ABC三个点的时间花费,以及三者目前的是否有活动又会、目前自己意愿里最想吃的是哪个,然后排除顺序。

在做产品的过程中会出现同样的问题,面临一堆产品需求,但是不可能在一个迭代内全部搞定,那在一个迭代周期内如何选择要做的内容也是个不得不面临的问题。通常上,可能是由boss直接基于经验判断拍脑袋,或者大家讨论都觉得应该做什么,不过总觉得虚了些。之前读到苏杰老师人人系列中设想过用群体打分获得商业价值(但是实操起来比现实),然后性价比=商业价值/实现难度决定需求list的优先级。

如果同类别需求,具有可比性,还可以尝试F/C的方式得到价值高的需求,F代表功能系数(比如有10个需求,每个对应功能值然后求和,F为当个需求功能值占比),C代表成本(简化为瓶颈资源,多数为开发资源,然后同样的求占比)。
———————————-
上面的过程也正应了:不能因为简单就先做,不能因为价值大就先做

得到价值需求或者性价比需求之后,还需要考虑:
杠杆套——连环杠杆的情况,比如#微信#  上线打飞机的那个版本,后来听说是个连环套功能,因为升级版本才能玩打飞机,然后客户端升级版本是微信支付场景的一个前置条件