zoukankan      html  css  js  c++  java
  • 对项目和产品中坎坎坷坷的一些感悟

        近期非常流行一张图

        这张图想表达一个什么样的想法呢?用户想要一个李若彤版的小龙女形象,在我们的原型实现中,变成了刘亦菲版的小龙女,尽管跟用户的要求有差距,但整体而言还是一个用户能够接受的范围。可是最后上线效果却是一个馒头版的小龙女,这个就跟用户的期望相差非常大了。

        看到了这个图,大家都会认为这个肯定是员工在开发的过程中出现了非常多的问题,导致了产品和预先的期望有了非常大的差距。由于管理者也有一种推卸责任的心里存在。我认为就这个图达到的效果,我们作为整个项目,甚至是整个部门的管理者而言都存在比較大的管理失误。

        在项目开发过程中,项目领导作为一个项目的总体把控后,会讲任务分解,然后安排给不同的员工开发。假设小龙女脸上出现一个眼睛大,一个眼睛小,或者脸上有疤痕,鼻子太高或者太矮那就是员工在开发中存在有误的地方。而就这个图而言,脸部的每一个部位都是合理的,正确的,仅仅是总体实现的效果没达到用户的要求。这个总体的效果是项目领导者最须要去关心的内容,员工往往考虑问题都在自己的模块中,项目领导是站在项目总体的方向去看待问题的。这个时候项目领导应该及时的站出来提出总体框架不合理的地方,然后带领大家完好产品,达到用户的期望。

        通过这个图,这个事情,我想表达的是,作为项目管理者,不是简单粗鲁的管理项目的进度,能不能完毕,什么时候完毕,完不成就加班。作为管理者,须要从一个大局的眼光去管理整个项目、分析用户的需求调动员工的积极性、培养和挖掘人才对失败和成功进行制度化、管理化的总结和优化

       就管理整个项目而言,项目经理的意见、对于用户需求的理解和项目方向的把控起到一个至关关键的数据。所谓蛇无头不行,国不可一日无君就是这个道理。国若一日无君,大家都站在自己的调度看问题,专注于自己的工作,资源是有限的,这样就会导致什么都做不好,什么能不伦不类的。作为员工而言,在工作中假设积极性足够的话,更加的注重点在于对于自己模块的开发,优化,总结,须要提高模块的功能和性能,这样就不easy站在总体的角度来看待问题。就比方,我们一个项目,一个产品中,事实上能够覆盖整个用户的需求,并且用户的每一个需求都能做的比較好,可是整合起来后,可能用户就不惬意了。可能是功能组合的不合理性或者操作过于复杂用户全然不会使用等等。这些在局部功能的开发中是非常难意识到这个问题的。这个时候就须要项目领导站在整个项目、产品的角度来审视能否满足用户的需求,用户能否接受和买单。假如项目领导自己都不看不下去或者不会使用的话,用户的想法就不言而喻了。

        对于员工的积极性也是管理者须要重中之重须要考虑的问题。我们的管理说究竟管的不是项目,管的是人。对于员工的积极性,我建议大家多说“假设”,少说“可是”。在一个项目和产品的开发中,假设最后的产品做的不太好,在开会的时候,项目领导常常会说:

    某某人,这个功能这样这样做的,“可是”什么什么情况满足不了。

    一般项目领导这样说的时候,员工心理都会非常难受,即使知道自己做错了,也会非常抵触项目领导这种说法。

    假设项目领导这样来表达:

    这个功能这样这样做不能满足什么需求,假设那样那样做,就能满足了,并且会更好。

    员工听到这种话的下意识感觉是:真的是这种,假设那样做就更好了,我怎么没想到呢,我开完会了要好好的完好一下。

    通过这个演示样例我们发现,事实上表达的意思是一样的,可是达到的效果是全然不一样的。

    “可是”是作为一个转折的角度,让人感觉到是在批评,“假设”是作为一个递进的角度,让人感觉到是在建议和鼓舞。这个将不伤害员工自尊心的同一时候,达到了改进的效果。

    所以说项目领导在平时,特别是在开会的时候说话一定要注意措辞。人为什么有两仅仅手,两仅仅脚,走路的时候都是一前一后的,所以有一句话叫留一手。人为什么仅仅有一张嘴,由于说出去的话就收不回来了。所以大家作为朋友跟大家讲话能够无所谓。可是在重要的场合,公共的场合说话须要注意自己的身份和措辞。

        在我们的项目管理中,要注重对于员工积极性的培养,我们管理的不是项目,我们须要管理的是人。所以我们在项目管理或者开会的过程中就不能这种来表达:

        “我无论你怎么做,我仅仅要什么时候做好,至于你要加班不加班,我无所谓

         这种说法是外包公司的说话,这种领导管理的不是人,管理的是项目。为了项目不在乎员工的心里感受。我称之为外包公司的管理方法,不在乎管理人,仅仅在乎管理项目,仅仅要项目做好了,其它的无所谓。由于在外包公司,非常多领导都认为事情谁都能够干,你不干,我再招其它人来干。反正项目的技术和架构都已经定好了,仅仅须要人来写代码就好了。

         作为创业型的公司或者科技型的公司而言,这种管理方法是不可取的。在须要创造性的公司中,我们的管理须要环绕着员工,由于对于产品和项目的技术存在着非常大的上下空间,有能力的人能做的非常好,没有能力的人做的非常一般。外包公司仅仅是有能力的人做的更快,没能力的人做的慢一点而已。作为创业型的公司,我们要的是能做的又快又好的人才。这样就须要调动大家的积极性,让大家能主动的思考学习。就像相同是项目进度紧张,假设我们跟员工说出我们产品或者项目的意义,得带来用户什么样的体验,能达到什么样的市场地位,能为整个公司或者整个市场带来什么样的作用。这样作为员工来说,能增强使命感和责任感。就算领导们不说要加班,仅仅有核心员工能带头加班,其它员工也会跟着一起加班,并且这种加班效率是非常高的,大家都会非常珍惜时间,把项目做的更好。

        在《亮剑》中,李云龙常常说“兵熊熊一个,将熊熊一窝”。假设一两个人积极性不高可能是个人的原因,可是假设大部分员工积极性都不高或者原来本来积极性非常高,结果积极性慢慢的减少了,这个时候作为管理者就应该開始反思了,这个真的是员工自己的问题吗,感觉不尽然吧。

         通过这样我们能把员工的积极性调动起来,不只能把这个项目做好,其它项目也能做好。

         假设採用外包的方式去管理的话,人就是创造性就大大折扣,不过为了完毕目标,并且从员工的心里而言存在比較大的挫败感和抵触心里。项目可能能完毕,可是真不一定能达到多好的效果。这样恶性循环,其它项目也非常难做的完美了。说究竟,管理是管理的人,大家都会说人才战略,中国人、中国梦,引进人才,事实上都是为了能调动人的积极性,能发挥人的创造性。这样我们不只能吸引住人才,并且还能培养大批的人才。

         我们平时的招聘都是招人才,而不是找人才,找到的人才不一定符合公司的须要,不一定跟公司的理念是一样的,不一定能留的这。所以我们要招人才,要把我们的企业文化,企业使命感,企业的理想和目标描写叙述出来,通过这样我们招到的人才有认同感,归属感,责任感,使命感,才是真正能为公司效力,能一起共患难的忠心的员工。

         Google和微软这种大公司为什么这么多人想进去呢,不不过待遇好,是让人有一种归属感,一种自豪感,同一时候也会有一种责任感,公司给我提供了这么好的环境,我做不出好的东西,心里会备受愧疚的。

        对于失败和成功的总结,这个也是项目领导须要去做的事,我们作为项目领导不能总是跟员工说,你们要常常总结,对失败进行总结经验教训。对于员工来说,总结的经验教训大部分都是细化的,是技术层面上的。是让以后的产品在技术层面上做出更好的东西。我们项目领导也须要常常总结,我们须要站在产品和项目的角度去总结经验。一两个功能的问题不会影响到整个产品和项目的成败。整个产品和项目的成败原因很有,可能是用户需求的不理解,可能是资源的不合理配置等等。

        没有无缘无故的失败,也没有无缘无故的成功。对于失败大家都会想到总结,可是对于成功大家也一定要去总结。成功不是无缘无故的,是存在和合理性的。可能是无意中什么地方做的特别好,特别有效果。这种无意可能就是成功的关键。成功可能是由于某一点做的特别好,或者是某些举措特别有效。所以我们对于成功的项目和产品一定要能找出当中做的特别好,特别合理的地方,而且一定要形成规章制度,形成经验总结。这样我们在下次的产品和项目的规划管理中就不会漏掉一些很有帮助的地方,也会引导大家走正确的路。

        所谓读史而知兴替,就是这种道理,我们不只要知道“替”的教训,也要知道“兴”的道理,形成制度。

        这些都是我在我的一些经验和教训通总结出来的我自己的一些想法,可能有些大家不允许的地方,能够大家一起讨论讨论。

  • 相关阅读:
    WF4.0 Beta1 自定义跟踪
    WF4.0 Beta1 流程设计器与Activity Designer
    新版本工作流平台的 (二) 权限算法(组织结构部分)
    WF4.0 Beta1 WorkflowInvoker
    WF4.0 基础篇 (十) Collection 集合操作
    WF4.0 基础篇 (十五) TransactionScope 事物容器
    WF4.0 基础篇 (六) 数据的传递 Arguments 参数
    WF4B1 的Procedural Activity 之InvokeMethod , InvokeMethod<T> 使用
    WF4.0 Beta1 异常处理
    WF4.0 Beta1 变量 Variables
  • 原文地址:https://www.cnblogs.com/mfrbuaa/p/4296846.html
Copyright © 2011-2022 走看看