工程师型创业者必须要看,因为你们都毫无例外会在预算问题上犯错

http://news.cnblogs.com/n/535150/

  英文原文:How to Ruin Your Company with One Bad Process

风险投资人兼 Loudcloud 创始人 bhorowitz 是一名工程师,他通过自己的经验和教训,讲述了工程师创业者会因为工程师思维,在管理和执行过程中忽视了 “预算” 这种约束行为。

  我一直强烈支持技术型的创业人,应该亲自去管理公司。但是,我也察觉到工程师出身的创业人,在经营企业过程会犯一个相同的错误。这个错误就是,他们根本不会做预算。

  你可能觉得我说的很荒唐。什么?预算?经济学名词?这是什么意思?为什么工程师创始人不会做预算?

  我可以告诉你,我是怎么犯下这个错误而差点把自己的公司搞砸。

  Loudcloud 主要提供互联网基础架构服务。并非吹嘘,我们当时发展前景甚佳,面临最大问题就是供不应求,有太多的顾客想要注册我们的网站。团队和我本人每日都在勤恳地工作,不仅为了满足顾客强劲的需要,也为了抢在竞争对手来临前开拓更大的市场。

  为了让公司完成这些目标,我仔细设定了工作目标、也设定了完成目标所必须要做的细节工作。而在和公司核心团队讨论后,我很确定自己的这些计划符合实际,也确定了如果计划遭受措施后的补救和后援团队。

  接着,我亲自向执行团队去阐述这些计划。并在得到他们的反馈后(比如需扩张团队人数和预算后),又对计划进行了更进一步的调整。

  现在,一切看上起来完美无缺对不对?

  来再细分下我的步骤:

1、设定企业成长的所必须要达到的目标 
2、细分目标,然后指派给具体的团队。让团队了解分派到自己具体的目标。
3、目标的评估,把目标转变为各种可衡量的指标,因为数字可以用来作为评估团队执行结果的指标。
4、做一个团队内的效率评估:确定扩招多少人可以达成目标 
5、估计执行过程中的所有必要花费 
6、再重新对收到的反馈,以及行业里的基准水平做个了解 
7、针对了解,优化全局 
8、执行

  除非你是一个经验老道的管理者,否则你都看不出来我这里的步骤哪里做错了。但是,就是这些精准的做法差点让我公司直接倒闭。我在不知情的情况下,颠倒了不少主次做法。

  我再提醒一次,如果你希望自己的公司破产,内部人员混乱,才应该按照刚才的那八步去做!

  实际上,当我在最初问团队经理:你们要达成这个目标,都需要什么资源。就这一句话,已经把整个公司拉到一场噩梦里。因为每个经理都会以自己团队的利益出发,去要求整个公司的其他部门为他的利益作出最大让步。而每个部门经理,在潜意识里都想在公司内部扩大自己的职权范围,都想让自己部门在公司拥有更高的影响力。

  你可能会说:「这不可能发生在我们公司!我的员工绝对没这么恶劣。」

  这不是人性恶劣不恶劣的问题,每个人都有眼界和高度上的局限性。仅此而已。而因为这个存在,管理才是难中之难。

  继续按照刚才的说法,我问了每个部门经理他们需要什么,部门经理没有提出非分要求。他们随后反馈了如何完成目标,那些战略和战术显得非常可靠。但是,另一个噩梦又出现了,那就是部门经理会盲目扩张。

  公司为部门制定的目标,本质上都是在现有业务基础上实现增长。但是,部门经理会无序的开发新市场。比如说,当我说希望部门「增加市场占有率达到增长」,部门经理就会自然地认为,是要「在全国范围内增长市场占有率」,而不是说「在某个重点城市范围内增长市场占有率」。

  部门经理会对新市场野心勃勃。为了让 CEO 对他们的扩张计划动心,他们还会诉说目前严峻的形式:「如果我们销售增长没有达到 500% 的增长,我们的主要竞争对手却做到了——那公司就会落后于人。如果我们落后,我们将不再是第一位。如果我们不是第一位,那么我们将再也无法招到最优秀的人才,提供最合适的价格,或打造最好的新产品。我们将旋入死亡的深渊……」

  所有这些可怕的事实,都建立在他们假设竞争对手今年内销售量增长了 500%。

  除了团队经理,当我主动去问团队:你们要达成这个目标,都需要什么资源,也会产生微妙的问题。当 CEO 向员工主动提出是否需要帮助,他们就会默认自己肯定能从我这里得到所有援助。当部门经理从我这里成功拿到资金和人手,士气当然会受到鼓舞。但我一旦作出削减预算和人力的决定,部门内部也会立刻人心惶惶。

  而比起自力更生,团队会逐渐发现「内部花费两周讨论一个成本更低的计划」,远远不如去求 CEO 多要点资金,来得更有效率。而我如果想鼓舞这个部门的士气,不得不必须掏出更多的钱。但如此一来,现金流和士气流失都会相同得快。

  以上麻烦出现的原因,是整个管理过程中我们没有设置一个特定的盈利目标,也没有在全过程里设置壁垒和限制,每个人都以个体的身份运作。其中的花费非常武断和轻率,可以说每个人都能无限量的燃烧现金。

  这就是我开头提出的问题,预算! 你在管理中,做足够的预算和限制了吗?

  与人们普遍的认知相反,严格的预算(对资金和人力约束)反而能凝聚公司士气并形成公司文化。公司文化的首要杀手,其实是过快的雇员人数增长。即使你的新员工无比优秀,或者入职后经过严格的培训——没有用,公司的文化依旧会显得疲软。

  有的时候,某些部门在短期内进行大量的人员扩张是必要的。比如销售部门。但在一些需要内部紧密沟通的部门,比如技术部和市场部,你需要格外谨慎。

  举个例子。如果把技术部在一年内扩大 4 倍,肯定比一年内扩大 2 倍工作效率更好。但与此同时,你不仅需要耗费更多的现金,更重要的是公司文化的凝聚性非常不坚固。新人在最初进入团队,都会以自己的方式做事,而适应公司和团队的文化需要时间和老员工的指导。如果团队里一半人数,甚至是三分之二都是新雇员,整个团队可以说是没有任何文化。

  请注意,这一点大公司要注意,而人数很少的初创公司也要注意。你可以从一个工程师慢慢变到四个工程师,从两个工程师慢慢变为八个人。这很好。但是你原本 50 个工程师,突然变为 200 个——请小心!这是危险的信号!

  反言之,如果你想建立一个公司文化,也不妨从预算开始入手。 这里有几个有用的建议,帮助你更好地在设定企业目标,并在随后的管理和执行中理解「预算」这个概念。

  1、设置上涨率

  我这里所说的「上涨率」,并不是「上涨速率」。

  如果你想达成某目标,其中涉及到必要花费。那你应该在上个月或者去年的此花费基础上,设置一个增长速率。比如:我希望今年的宣传幅度更加猛烈,我愿意在去年的广告费上多花 10% 的预算,去达到这个效果。这个 10% 就是上涨率。

  所有的扩张的调整,最好都设定一个限额。

  2、设置收益 / 损失区间

  一般收益不需要设置上限,但必须要设置下限。而损失更要设置,最好有个目标年收益和目标可承受年损失。

  3、部门工程师增长速度

  除非你正在进行项目收购,或者单独运营一个项目,再或者你正在尝试让工程师团队独立于公司之外工作——除了这三种情况,否则你就不应该在十二个月内把现有工程师的人数翻倍。

  4、工程师部门以外的部门增长速度

  首先你要确认好工程师部门和其他部门人数的比例。这样,你就可以根据工程师部门的人数,设置其他部门的人数。

  以上是针对公司全局的「预算设置」,以下是更多细节建议。

  1、设置了数字指标,就要严格执行。必要情况下,再缩减 10%-25%。

  2、在以上的人数基础上,去设置每个团队预算。

  3、就预算和团队进行谨慎的沟通。

  4、向你最初设定的目标进攻!并鼓励你的部门经理们在预算范围内完成任务。

  5、设置备用金。当你确认为某件事投入更多的钱,确实会受到更多的成效时。可以在最终拨给项目经理的金额里,增加 10-25% 的预算。

  看到这里,相信很多读者认为我根本不是一个淳朴的工程师,而是一个老奸巨猾的商人。但没有人比我懂得,假如一个工程师在项目最初就要开始考虑资金,简直就是噩梦。这会扼杀我的创造力,甚至还会阻碍我创造出一个真正的好东西。

  因此,我几乎是耗费了全部的精力才写下了此篇文章,把我了解到的东西一览无余分享你。简而言之就是: 一个人的行为处事,是被他的思想和个人因素而影响。而放眼到公司,局部效应会刺激整体,如果对人的管理不妥善,会危害到整个公司。而对人管理的迟钝,也会把你从一个小而敏捷的公司变成一个臃肿而迟钝的公司。

《C++编程实例100篇》是一本深入实践、极具价值的编程教程,它针对C++编程语言提供了丰富的实例,旨在帮助读者更好地理解和掌握C++的各项特性与编程技巧。这本书的经典之处在于它将理论与实践相结合,通过100个精心设计的编程实例,覆盖了C++的各个核心领域,包括基础语法、面向对象编程、模板、异常处理、STL(标准模板库)等。 我们来探讨C++的基础语法。C++是C语言的增强版,它保留了C语言的高效性和灵活性,并引入了类、对象和继承等面向对象编程概念。基础语法包括变量声明、数据类、运算符、控制结构(如if语句、for循环、while循环)、函数的定义和调用等。在实例中,你可能会遇到如何编写简单的程序,如计算两个数的和,或者实现一个简单的猜数字游戏。 C++的面向对象编程是其一大特色。通过类和对象,你可以构建复杂的软件系统。类是对象的蓝图,它定义了对象的属性和行为。实例化一个类,就是创建一个具体的对象。继承允许你创建新的类,这些类从现有的类派生,共享其属性和方法,同时可以添加新的功能。多态性是面向对象的另一个关键特性,它使得不同类的对象可以对同一消息作出不同的响应。这些概念在实例中会以各种形式展现,例如设计一个图形界面的类层次,或实现一个简单的模拟游戏。 接下来是模板,C++的模板功能让代码更加通用,可以处理不同类的数据。模板分为函数模板和类模板,前者可以创建泛函数,后者可以创建泛类。通过模板,你可以编写出高效且灵活的代码,比如实现一个通用的排序算法。 异常处理是C++中用于处理程序运行时错误的机制。当程序出现异常情况时,可以抛出一个异常,然后在适当的点捕获并处理这个异常。这使得代码能够优雅地处理错误,而不是让程序崩溃。实例中可能会有涉及文件操作或网络通信时可能出现的异常处理示例。
### Spring Boot 自动配置面试常见问题及答案 #### 什么是Spring Boot自动配置? Spring Boot自动配置是指框架能够根据项目中的依赖关系以及一些默认规则来推断并完成应用程序所需的基础配置,从而减少开发者手动编写大量XML或Java Config的工作量[^1]。 #### 如何实现自动配置? 自动配置的核心在于`@EnableAutoConfiguration`注解,默认情况下该注解会被`spring-boot-starter-parent`所引入的其他starter模块间接激活。其工作流程主要是通过扫描类路径下的`META-INF/spring.factories`文件,从中读取出指定类的配置类名称列表,并依据这些信息注册相应的Bean实例到IoC容器内[^4]。 #### 解析`spring.factories` 此文件位于JAR包内部,用于声明哪些组件应该被纳入考虑范围之内参与自动装配过程。对于每一个可能影响应用行为的关键点——比如数据源、事务管理器等——都会有一个对应的工厂方法负责创建特定的对象实例。 #### 日志级别的动态调整机制 考虑到生产环境中经常需要根据不同场景灵活改变日志输出等级的需求,在开发阶段可以通过设置环境变量的方式预先定义好一套策略;而在部署之后则借助于某些中间件服务(例如Kubernetes Secrets)或者云平台特性来进行实时修改操作[^3]。 #### 关键字:条件化 Bean 定义 在整个过程中,“条件化”是一个非常重要的概念。这意味着并非所有的候选者都会毫无例外地加入到最后的应用上下文中去,而是要经过一系列判断逻辑筛选出最合适的那部分才予以采纳。这背后涉及到诸如`@ConditionalOnClass`, `@ConditionalOnMissingBean`等多个专门为此设计的元注解[^2]。 ```java // 条件化加载示例代码 @Configuration @ConditionalOnProperty(name="example.enabled", havingValue="true") public class ExampleConfig { @Bean public ExampleService exampleService() { return new ExampleServiceImpl(); } } ``` #### MyBatis集成注意事项 当把MyBatis同Spring Boot结合起来使用的时候,有几个地方值得特别留意: - **mybatis.config-location**: 明确指明映射文件的位置有助于提高查询效率; - 正确处理多数据源情况下的命名空间冲突问题; - 利用AOP技术增强SQL执行期间的日志记录功能[^5]。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值