Archive for the ‘Management’ category

创业公司CEO每天应该做的13件事

April 7th, 2011

Mr. Jamie说,一般人大概很难想像创业公司 CEO 的工作有多难,你的公司在烧钱,说不定只剩下 6 个月的粮草,你怎么可能不担心?偏偏在团队面前你又必须装作若无其事,一切都在你的掌控之中。

Jason Goldberg 整理了一个列表,列出创业公司CEO每天应该做的13件事,以下是36氪编译版本:

  1. 记住你的“一件事”:你的创业公司在一段时间内只能把一件事做好,明确你的“一件事”,写在墙上,每天重复出现在自己眼中,将“一件事”作为公司例会最高级别的事情,不要让任何事情让你和你的团队分心。
  2. 记住,只有当你的团队优秀时,你才一起优秀:花时间培养你的团队,招聘那些在他们工作上比你曾经做得更棒的人,激励他们,让他们完成他们从来没想过他们能做到的事情,在引导他们去做“一件事”的同时给他们自由,像对待家人那样对待你的同事,创业不容易,让你的团队愿意成为公司一员是能够成功的重要因素,创业公司并不只是一个工作的地方,更是一种生活的方式,作为CEO,你的工作不是把每个人的工作都做了,你的工作是帮助他们把工作做得更好,确保定期给你的主管们反馈,告诉他们你的期望,需要他们改进哪些地方。
  3. 设定风格:每个人 – 你的同事,客户,合作伙伴,投资者,你的Twitter和Facebook关注者 – 都会从你身上得到暗示。从你公司的增值速度,数据,创新,客户服务直到公司文化都会反映出你作为一个CEO的职能,所以,不要做一个粗鲁的混蛋,付出行动,如果你希望人们想到你公司时是按照你想让他们想的那样,你需要付出行动并从个人做起。如果你自己无精打采,你的公司也会,如果你忘记微笑,你的公司也会,如果你缺乏耐心,你的公司也会,如果你不说请和谢谢,你的公司也会,公司高于每个人,但公司是由每个人和每个人的工作风格反映出来的,而你是领导者。
  4. 花至少75%的个人时间在你的产品上:只有当你的产品优秀的时候,你的公司才能优秀,亲自参与管理功能和用户利益,我的观点是CEO必须是首席产品官,作为CEO你必须为屏幕上每一个像素负责,我知道这听起来有点过了但是你的产品是你们所有努力工作对用户的输出,所以它的每个功能都应该反映出你们的目标和目的。
  5. 审视数字:我不是在谈论预算和现金流,而是一些关键指标,每周发一封邮件给你的团队,提炼出那些影响公司业务的关键数据,亲自写这封邮件,写邮件会强迫你自己去挖掘和分析你的数据,真正拥有那些数据,让你的工作能够确保公司的每个人都能专注在那些能给公司带来业务的数字上。
  6. 锻炼:我实在忍不住要强调这一点,让自己每周去至少4次健身房,最好是5-6次,锻炼能给你能力和耐心去解决复杂的问题,作为CEO对身体是很大的挑战,让健身房作为一个使自己头脑清醒和保持快活的一种方式,如果你还没有这么做,我保证去了之后你会震惊的,当你有规律的出去锻炼你会发现生活是多么的容易!离开你的键盘,去健身!
  7. 要求反馈:你猜怎样?你并不像你认为的那样聪明,你会犯错误,去问你的雇员,你的客户,你的合作伙伴等,确保你的管理团队中有一个人敢直言不讳,确保你有一个董事会之外的成员或朋友能够给在公司发展上给你提供建议(例如在融资上,董事会管理上)。
  8. 离开办公室:人们太容易生活躲在键盘后面,生活在收件箱里,离开办公室,去和你真正的客户,合作伙伴,供应商,博主们讨论
  9. 写博客,写微博,阅读,参与CEO论坛:写类似于这篇的文章,分享你学到的经验教训,和你工作的技巧等,不要担心没人看,从网络中获得反馈,阅读Hacker News,看其他创业者和科技极客们在分享什么,利用投资者的网络从其他CEO那里获得建议。
  10. 管理现金:现金是你的生命线,你必须一直清楚你还剩多少现金,能够你维持你多久,什么样的决定会影响你的现金状况,不要等到需要钱的时候才去融资。
  11. 像投资者一样去做:在每周结束的时候,问问你自己下面的问题:我们这周所做的提升了我们的价值么?过去的一周你对时间的投资回报率是多少?如果你连续2周或者一个月内有2周没有一个积极的投资回报率,你可能就在做错误的事情了。
  12. 享受乐趣:这很难,需要很大的精力,确保每一天都是愉快的一天,即使很糟糕的一天也需要一下乐趣,如果你觉得不快乐,你可能在作错误的事情,我最喜欢的一句格言:成熟,但不要长大。
  13. 爱:爱你的公司,爱你的同事,爱你的投资者,爱你的合作伙伴,爱你的供应商,但最重要的是,爱呆在家里等你的人 – 那些支持你让你能够日复一日战斗在最前线的人!

转载自@36氪

  • Share/Save/Bookmark

[转]项目经理思维和意识的转变-风险

August 7th, 2009

风险是什么?风险就是不确定性,而项目管理的过程就是不断的消除风险的过程,没有风险的项目一定应该是成功的,如果失败都说明前期没有充分的失败和应对风险。风险和风险管理都谈得比较多,但是其重点往往并不在于系统化的风险管理方法和流程,而在于风险意识的形成和转变。风险意识和危机意识是项目管理最核心的一个思维意识。对于风险管理可以再谈下其重点的核心如下:

* 风险管理是项目目标驱动的,这样的风险管理才有意义。
* 达成项目的目标究竟还存在管理,技术,支持等各个方面的哪些不确定性?这个不确定性如果不解决对目标影响是否可以接受。
* 做计划是对项目目标和结果进行预测,但是预测无法100%准确,风险管理目的就是应对计划本身的不确定性。
* 风险管理的难点在于通过历史经验积累,识别项目的关键风险,只有识别出来才谈得上应对。
* 项目应该预留合适的时间和资金的缓冲,但是缓冲太大确实灾难,它可能让我们忽视了风险本身,因为即使风险已经转化为了问题也没有影响到最后目标的达成。

风险意识重点就是在项目启动前或项目执行过程中都随时有意识的去识别项目的关键风险,只有先把风险识别出来,才谈得上如何去分析和量化,如何去应对。

首先我们应该看到的是从自己的失败中总结前车之鉴,历史的项目为什么失败了?为什么项目目标偏离了?要去分析这些问题的根源,要去考虑如果再接新的项目的时候如何去预防,如何避免问题再次发生。挂在嘴边的不仅仅是风险两个字,而是风险应对措施的真正落地,你需要去考虑哪些事情需要提前预防和提前介入,哪些事情需要制定备选方案,哪些围绕项目团队和环境的事情提前展开,这些工作都必须要做,都是为了降低和消除不确定性。有时候你做了这些事情后,风险没有转变为问题,大家可能看不到这些风险应对措施的价值,但是你仍然必须要去做。有时候可能往往成功救火的人反而得到了表扬,但是这些都不应该影响到你的思维和应对。

其次,从组织的失败中找寻经验。这也是我们说的组织级的风险库,别的团队和项目出现了问题,那么你自己的项目或团队就有可能出现问题,你可以去看他人的经验教训总结,看组织多年积累的风险库来审视自己的团队是否会发生类似的问题,这是一个组织成熟的重要体现。同时你也必须意识到你原来没有发生类似问题并不代表你将来不会发生类似问题。通过组织级的风险库和风险检查单,你就可以从团队,项目,环境,技术,支持过程,客户等多个方向去寻找可能存在的不确定性。

前面两点可以看到都是从自己和组织的历史中去找寻经验,比对现在项目可能存在的风险和不确定性。那么最后一点就是从当前的完整的项目计划中去找寻风险和不确定性。项目的进度是否能够达成?项目的质量和成本如何保证不出现偏差或偏差可控?项目的进度可以通过WBS分解到细化的活动和任务,项目的成本也可以通过预算逐层分解,而这个分解对应的往往正是一个项目的风险树,你需要考虑的就是风险树上的每一个节点在保证质量的前提下成本和进度都是可控的。(注:这里还要提到风险管理不仅仅是项目经理的事情,需要把风险意识下达到整个团队,每个团队成员都应该做这样的思考,如我这周的任务是否有100%把握完成,存在哪些不确定性?如果不能完成我应该这么办?)

原文http://blog.sina.com.cn/s/blog_493a84550100eqea.html

  • Share/Save/Bookmark

[转]黄鸣:为什么不提拔你?

February 26th, 2009

原文地址:http://home.51.com/gusingchen/diary/item/10045998.html

黄总你好:我感觉公司有些管理不是很完善。对于干部的提拔问题,为什么有经验的老职工不提拔,而偏偏提拔刚进公司不到一年的员工,就算她工作再好也还是不如老员工有经验吧?公司里多提拔一些有能力有经验的员工是不是对于公司的长远发展有利呢? 

    黄鸣回复:虽然我不清楚你是谁,一般像你这样谈经验谈能力的,并且认为新员工“就算她工作再好也还是不如老员工有经验吧?”的臆断,是会出大问题的。因为 这时你认为的“宝贝”(经验)已经是创新的障碍,你会沉浸在过去是怎么做的经验中不能自拔,你没有做过、没有成功的事情,就会认为它继续不能做、继续不会 成功,这样你不但阻碍了自己的创新,更阻碍其他人尤其是新员工的创新。

    最近我亲自提拔了两名新员工,并以此鼓励公司主管提拔新人、培养新人、重用新人。这两名员工虽说一位刚刚毕业不久,一位还是大四学生(在大三时已在公司勤 工俭学,是公司资助的大学生),但他们从到公司那天起都没有把自己作为局外人,对工作积极热情、主动承担工作任务,不是事找他们,而是他们找事做,并大胆 给公司提建议,对工作极其负责,这些就是公司提拔他们的理由,只有不拘一格降人才,才能促使更多新员工保持激情,同时也激发老员工的工作积极性,带动全公 司的活力与动力。

    很多公司在干部提拔上犯的问题之一,就是论资排辈,一些高层管理者眼中的干部提升标准也是把经验、能力放在第一位。经验和能力固然重要,但仅是参照项之 一,如果经验与激情撞车,能力与道德违背,经验和能力带给公司的反而是负面效益。尤其对一个以创新为主的公司,公司的健康发展,不仅要依靠一部分有能力、 有经验、有激情和活力的老员工,也要依靠有热情、有激情、积极向上的新员工。但在新员工干部提拔问题上,由于部分主管对新员工存有“没有管理经验、没有组 织能力”的偏见,所以不敢用不提拔,使部门陷在“经验堆”里不能突破,搞得部门四平八稳像封建官场的衙门,这样最终会落入死气沉沉的老好人组织中。

    其实,不仅仅皇明公司这样,世界上很多优秀的公司都是这样。在这一方面我想你应该关注的不是谁被提升的问题,而应该反思为什么有些老员工没被提升?为什么 提升那样的新人?你跟他们的差别是什么?这样更有利于你在公司继续发展。否则不是公司没前途,是你自己的前途堪忧了。

  • Share/Save/Bookmark

[转]项目经理和技术主管的分工

January 15th, 2009

版权声明:可以任意转载,但转载时必须标明原作者charlee、原始链接http://tech.idv2.com/2008/06/05/pm-and-tech-leader/以及本声明。

本文是日经BP上的一篇关于项目管理方法的实践的文章。对于短期的Web小型项目, 无论是开发周期、成本,还是技术上都有很大的风险。然而许多人对此认识不足, 导致项目失败,或是产品发布日期一拖再拖、成本大幅上升,或是匆忙发布后漏洞百出。 本文从项目管理的角度说明,即使在小型项目中,项目经理也不能将项目全权委托给技术主管, 而应当建立合适的体制,从几个方面对项目进行控制,这样才能保证项目的顺利进行。

原文在这里

通常的项目体制不适合短期开发

在大型机上花费几年的时间构建大型系统时,项目经理通常仅负责一个项目, 手下也聚集着许多软件工程师。在需求定义阶段,项目经理直接与客户进行交涉, 在需求定义中发挥着领导的作用。

这种体制本来十分理想,但对于开发期间只有几周到几个月的小型Web系统来说, 却不尽人意。团队的实际情况是,项目经理和技术主管通常会兼任数个项目, 设计、编码的工作全部交给年轻的工程师或合作方的工程师们。 这时,项目经理的一部分职责通常会交给技术主管分担。

职责、分工不明确

开发Web系统时,客户企业经常会要求使用EJB、XML、Web Service等较新的技术。 项目经理为了满足客户企业在技术上的要求,不得不依赖于技术主管。 另外,项目经理通常要照看多个项目,因此与之相比,技术主管接触客户的机会更多一些。

这样,在Web开发中技术主管的职责范围变得非常广泛。因此,项目经理和技术主管的 职责分工很容易变得模糊不清。绝大多数情况下,职责分工问题不仅没能形成书面文档, 甚至连简单的协议都做不到。极端的例子就是“除了钱的问题,其他全部委托给技术主管”。

这种现象并不鲜见,但是在大规模项目中,通常会有足够多的时间和人力来规避风险, 因此即使发生问题,也总有办法解决掉。但是小规模、短期的Web项目中,由于职责分工不明确 而导致项目内部的意见不一、决策效率低下等,是项目失败的直接原因。

项目经理无法掌握项目的状况

让我们具体地看一看,在项目最重要的任务之一——需求定义中,职责分工不明确会造成怎样的问题。

在Web系统开发中,客户企业经常会在开发途中增加、改变需求,因此完整的需求在项目初期很难确定。 再加上项目经理要兼任多个项目,无暇顾及每个项目的需求定义,只得将其全权委托给技术主管。

这种条件下,技术主管仅从技术的观点来接受客户的要求,导致项目超过预算、超过预定工期的可能性非常大。 另外,项目经理无法详细把握需求定义,因此无法把握项目的状况,导致项目的范围失控。 最终结果必然是,当问题的征兆出现时,根本无法采取任何对策,如与客户交涉“先实现优先的功能,其他无关紧要的功能下次再实现”等。

想象一下,技术主管完全根据自己的判断来回答客户企业的重要问题时会出现什么后果。 项目经理和技术主管的意见一致时尚可,意见不一致时,必然会招致客户的混乱。 此外,项目经理对技术主管过于依赖,会导致不好的结果。例如,带着“他会做好的”、 “这件事儿是他的责任”的想法,通过邮件给技术主管分配任务,其结果通常是该做的事情 没人负责。

建立职责分工的规则

为避免这样的问题,项目经理和技术主管必须事先决定职责分工。那么应当如何分工呢? 不同的项目千差万别,所以并不存在万能的灵药。应当综合各种方法,并结合项目的实际来决定。 以此为前提,首先应当制定职责分工的规则。具体来说,要制定以下的规则。

(1) 在需求定义结束之前,实现哪些功能、采用什么开发工具、安全实现到什么程度、 如何应对繁忙时的业务量等,这些关系到系统需求的重要事项必须由项目经理和技术主管协商决定。

(2) 在设计阶段之后,不影响进度、人员计划的功能追加、修改等项目范围内的事项, 首先由技术主管做出判断,交由项目经理确认之后再做决定。可能会导致合同变动的项目范围外的事项, 技术主管应当将判断权交给项目经理。用这种规则,就能回避职责不明确导致的混乱。

共同制作业务场景

同时,也应当建立项目经理和技术主管共享信息的方法。这里,我们以需求定义阶段 项目经理和技术主管合作制作“业务场景”的方法为例进行介绍。

新业务的场景,即根据客户询问、头脑风暴、JAD、原型、现有业务资料调查等方式获得的信息, 来描述新系统的样子的东西。

业务场景可以用讲故事的方式写成,附以图表就更完美了。也可以开发一套能实际运行的原型系统。 制作业务场景的过程中要不断与客户确认,以此为基础来确定详细的系统需求。

场景制作的材料可以完全委托给团队成员,但场景本身必须由项目经理和技术主管协同客户方负责人一起制作。 项目经理和技术主管经过不断的交涉,提炼材料,从开发的角度看哪些重要,现行系统的哪一部分在新系统中如何变化等, 这些问题项目经理和技术主管都要充分认识。这样,两者才能获得一致的意见。

技术主管通过制作业务场景来获得与项目经理一致的意见,在确定需求时才能更容易地获得客户的新人。 另一方面,项目经理也有充分的自信能够“完美地控制项目”。当然,场景的详细程度需按照项目来定。

项目经理也要有技术直觉

即使明确了职责分工,也不能说是十全十美。Web开发项目要想成功,项目经理也要拥有 “技术者的直觉”。认为“最近的技术全然不懂,干脆都交给技术主管吧”的话, 就无法进行风险管理了。

Web系统开发经常使用大量的新技术、新产品,技术方面的风险十分大。例如,不经深刻的讨论 就采用螺旋形方法进行开发,很容易陷入需求膨胀、不知何时才能最终完工的黑洞。 此外,面向最终用户的B2C的电子商务网站,若不在认真计划的基础上进行有效率的测试, 就会有测试量剧增的风险。

为防止这些风险,项目经理必须拥有“技术直觉”,努力管理项目,在技术问题上与技术主管充分交流, 而不能完全委托给技术主管。

所谓技术直觉,并不是要求精通技术本身。重要的是要了解技术的“意义”, 对于技术给项目带来的影响具有敏锐的洞察力。遗憾的是,有些项目经理抱有 “发生问题时,只要增加人手就能解决”这种简单的想法,但它正是没有技术直觉 造成的最为悲剧性的看法。

对于影响到项目进程的技术瓶颈,就算是增加人手也只是徒然浪费金钱而已。

项目经理要求有“技术直觉”,同样,技术主管也要有“项目管理直觉”。 特别是经常接触客户的技术主管,如果没有项目范围、进度、成本、质量管理这些 项目管理的基本知识,就容易仅凭技术来接受客户要求,不知不觉中就会使 成本和进度失控。项目经理和技术主管应当了解的知识如下所示。

  • 项目管理技能(参考PMBOK)
    • 综合管理
    • 范围管理
    • 时间管理
    • 费用管理
    • 质量管理
    • 人力资源管理
    • 沟通管理
    • 风险管理
    • 资源调配管理
    • 领导力
    • 交涉力
    • 问题解决能力
  • 软件技术技能
    • 需求定义
    • 系统设计
    • 编码、测试
    • 性能计划
    • 容量计划
    • 配置管理
    • 变更管理
    • 问题管理
    • 过程管理
    • 开发手段
    • 开发工具
    • 质量管理
  • 共通技能
    • 一般的IT知识、业务知识
  • Share/Save/Bookmark

项目经理的主要职责

December 18th, 2008

项目经理,主要职责是:

项目范围定义

项目计划制定、分解、分配、协调、汇报

项目质量控制

项目需求变更控制

结果自己一点都没达到么。。。。真是失败sigh

  • Share/Save/Bookmark