1 开篇-开发模式
上线系统需要操作说明、培训机制、稳定性。
要想提高稳定性,必须专门从队伍中找一个人,他作为公共代码开发员(技术架构师)。
产品经理要熟悉客户需求,而且是深刻理解客户需求。
客户为什么要提这样的需求?客户要根本解决什么问题?这些问题谁来想,谁来想解决办法?
开发经理(业务架构师)来承担起客户行业研究。
有了夯实的业务+技术,功能实用、功能符合客户操作、功能稳定。这是软件最基本的要求。
测试人员上场夯实质量并兼技术支持。
好的产品,还需要有好的文档和培训。
招一个文案人员,写帮助说明,制作操作视频,制作学习版数据库,参与辅助测试(这个很重要,否则文案人员不熟知产品,无法写出有质量的文案)。
文案兼起培训工作,在培训中会有各种提问,会更加增进他对文案和产品的理解,能站在使用者的角度上来写来讲,而且他属于开发部门,他会给产品开发带来更多更好的产品易用性建议。
开发模式:业务架构、技术架构、测试兼技术支持、文案兼培训,四套马车。
有了这么好的团队,就能比过去产出更好的软件,软件的质量,软件的进度,软件的竞争力就都上来了,再上各种管理软件:如项目管理软件、版本管理软件、BUG管理软件、自动测试软件,就水到渠成了。
开发部门也终于专职专业起来。
2 实施-方法
一个实施项目只派一个人去,而这个人需要培训、辅助导入旧系统数据、清洗合并数据、规范化数据、报表制作、需求协调、推动切换上线、现场运行监控、个性化定制修改代码。
一个项目这个人,身兼项目经理、开发员、需求调研、软件设计、功能测试、实施培训、定制化开发,还有时候写培训文档。
很多软件公司的成立,就是由于老板有一个关系,接到了某个项目,于是拉住了某个客户,小活不断,于是成立了公司。
有三个方面特别费时间:客户需求,数据准备,报表制作。
人常说,上下同欲者胜,庙算者胜。你一开始必须界定好项目的边界和目标和执行标准和责任人,否则大家谁都想管或者谁都不管,大家没有目标,或者大家各有各的目标,肯定无法项目很好的推进[ww1] 。
校验现有基础数据很有必要。没有的数据,先让他们做准备[ww2] ,但你要书面把要准备的规范写好交给要参与的各个用户,而且要做好培训工作,不能讲讲就认为他们理解了。
必须要有专人(培训方法、培训文档、培训素质)来做培训。这块是项目实施非常重要而且工作量大的一块。这才是真正的项目实施。
你在现场,你的任务就是当好一个项目经理,专门协调,控制,理顺,制定流程、规范、目标、时间,保证执行到位。
公司里还有专门coding的程序员分担你的开发测试工作,而且人家写的代码更加多家客户兼容使用,而且质量稳定性比你高。
只有专业分工合作,才能转成正规军。
我们只能是能改进什么就改进什么,天天进步一点,我们就会大变样。
你是项目经理。你是这个项目的领头人。你决定这个项目的成败。
3 项目经理的工具箱
项目经理,主要职责[ww3] 是:
1) 项目范围定义 ;
2) 项目计划制定、分解、分配、协调、汇报;
3) 项目质量控制;
4) 项目需求变更控制;
自己的责任就是帮助公司最大限度的利润最大化。而利润最大化的实现手段就是最小的成本、最少的人、最少的时间、最简单的方法达到老板的目的,拿出合适[ww4] 质量和功能的产品,包装好,卖上尽可能高的价格。
我划出开发部专人支持后,规定流程[ww5] 。所有的需求,不管是哪个部门或哪个客户,都归口到他这个人手上。即使还有人直接打给开发员,包括老板打给开发员的,开发员必须把需求或问题再并口到这个技术支持手里,我来统一安排调度开发 。
上BUG管理系统 。不管是BUG还是需求还是建议还是疑问,谁想提,都提到这里来,随时记录。
支持兼测试。
一个BUG管理工具,能把计划、进度、质量、需求、BUG都能管理起来,而且能追溯,能考核,能统计工作量和工作质量。真是必备。
PPT+WORD+脑图+EXCEL的描述需求。一页PPT相当于一个界面窗口。关于PPT的详细描述,字段,流程,特殊注意,特殊控制,都用WORD说明好。遇到有报表功能的时候,用EXCEL把报表画出来。
软件包装,第一步就需要帮助文件、视频操作、解决方案、产品介绍、演示系统。文案和美工上场。
迈出你的第一步吧。不迈出第一步,你都会觉得这是不可能完成的任务。
4 人、是人、真的是人-团队建设
职业经理人和老板的关系:
1老板都是疑人也用用人也疑。用人不疑,疑人不用,我不奢望。
2职业经理人的职责范围的,老板权力范围的,不要超越,也不要动歪脑筋。
3计划不计划一件事情,执行不执行一件事情。一定要以老板利益为目的。
4方法都是为了解决实际问题,为了老板赚钱更快更省成本更容易,员工更省力,客户更满意,而且每个方法都是在本企业能力和成本范围内能执行落地的解决方案。
其实技术就是个手段,合法赚钱是目的。
环境支持:
1好的氛围[ww6] ,才会引入、留住好的人
2好的人,才会有好的制度,并且保持好这个制度
3好的人和好的制度,才会遇到好的客户
如何制造好的氛围:
1师傅制。
2朝九晚五,禁止加班。
3良好的办公环境和良好的个人形象。
4以更快更省成本更容易完成任务为目标,以赚更多钱为目标,以提高产品质量产品价值产品售价为目标,鼓励员工进行自我岗位上的改进创新,经常给与交流和指导,一旦有效,进行精神或物质的奖励或职位提拔或工资晋级。
引入好的人才的几个心得:
1人的年龄和工作经验拉开距离。年年招,时时招。不断看人,试人,滤人,培养人,形成层次感有阶梯有接力的员工组织,绵绵不断前赴后继,不会出现人才地震、集体疲劳、小团伙争斗。
2人的技术能力高低先放一边。首先要过EQ关[ww7] 。讲经历。
3专业发展,流程协作。
4下一阶段目标交流制定。
团队精神建设得天天讲,时时讲,到处讲,就形成了文化精神,就形成了习惯。
习惯决定性格,性格决定命运,细节决定成败。
5 实施经理的工具箱
做实施,最怕的不是人家使用中出现各种麻烦。而是业务部门抵制[ww8] 用,不想用,出各种各样理由,项目进展很慢。
从软件附着的管理理念中抽取出了管理模型KPI、管理模型计算公式、管理模型流程宣贯。[ww9]
做实施的第一步,做好数据初始化。
系统要求:
1测试数据字典准备(基础数据录入)功能。
2封锁数据库。把数据库访问权限严格控制,数据库约束完整。
3错误日志。
组织编写数据准备手册。详细的数据准备操作流程,输入输入规范约束默认值不可为空不可重复等等都说明的很清楚。而且还给了一份清单,每通过一步,就打一个勾。如果这个清单上的列表,每项勾都打好了,说明数据准备阶段就完成了。
按照数据准备手册按照流程给他们信息科培训几次,模拟操作几遍,就回到公司[ww10] 。
第二步,培训。
培训方案、培训计划、培训考核。
培训专员制作了培训课程、培训教材、培训考试卷、培训版系统、视频教学软件。
第三步,上线后的监控运行。
一定要明确限定项目边界,项目时间目标。实施目标、计划、责任人。
每天邮件报告给我的老板、他的老板、项目涉及到的每个人,通报今天的工作内容和明天的工作计划。
你如果觉得无法突破,那么你真的就无法突破了。
6 客服顾问的工具箱
QQ、QQ群。
BBS搭建起来。BBS有理念讨论区、常见问题FAQ区、功能操作问答区、技术问答区、补丁下载区、实施方法区。
客服工单系统。
7 你这该死的销售-售前配合
一般小公司,老板就是最大的销售,所有的大单子都是老板在跟。
单子签好后,程序员根本不知道合同都签了些什么。
不管是谁的问题,只要是阻碍我的问题,我都要解决,千方百计去解决它。
要先学会做PPT,想、做、写、说,对于一个成功的人来说都是必不可少的。
我的手下逐步在我的带领下发展出来专职的测试、文案、公共代码开发人员。
售前:
1他首先必须懂得客户业务,否则和客户交流一看就是个外行。
2他最好能干过开发。否则他也会和销售一样,不知道能不能技术实现,一律放炮答应下来。
3他制作PPT或写个什么文字,也不要太惨不忍睹。这个是可以训练的。
4他需要有个项目经理的气质,别一坐那里就像个程序员。
5有那么点灵气劲。别不识眼色。
于是,一篇篇越来越有质量的PPT、文案、报价、工作量报价,都从这位项目经理之手而出(文案人员可真是他的好帮手,很多细节细致的收集资料、反复校对修改都是文案在做)。
售前经理,就是咱们部门的宣传官,和老板(销售)一起去打单演讲。
8 水清则无鱼-开发费报价
在研发过程管理上引入了一些方法,引入专职的项目经理、公共代码开发、测试员,来收集需求、控制需求、安排进度、把控质量。在产品制造上我引入了美工来美化界面,引入了文案编写了精美的帮助文档、产品白皮书、演示版和视频教学。让销售拿出去给客户打单,一看PPT一看产品演示就感觉这是个专业的产品。另外,我在实施和咨询和技术支持也下了大功夫,让这种专业性一直连贯的保持下来,否则就会让客户感觉签单前很专业,一签了单子就糊弄人,这样生意就没得做了。
人数可以缩减,但要做的事情不能缩减,这样效果衰减的就不会很厉害。
9 实施费用也能DIY
实施项目经理的职责为:
1项目范围界定
2制定项目计划
3组织项目成员
4协调相关人沟通
5保证项目质量
6推进项目进度
实施费用=(所选级别的项目经理每天费用+N套子系统x所选级别的培训专员每天费用)x实施天数。
培训讲师费用=(某一级别的培训专员某门课程的培训费用)x培训次数。
给客户一套实施费用计算表,客户根据自己的财力和想达到的效果来调节参数,就可以选择适合自己的项目经理、培训专员、实施阶段、培训课程、培训课本。
10 将服务费用DIY到底
人有层次,服务也有层次。
论坛和QQ群,就是免费的支持。
收费的服务支持,就有远程支持和现场支持两种。
11 物以类聚、人以类分-培养员工
企业文化就是老板的性格。
往往大部分事务的成败,也就有那么两三个关键点。你抓住了关键点,事务就不可能偏的太远。
企业员工间的矛盾,不外乎就是一口气、一个位子、一个面子或者是一点小利。其实最大的控制者还是老板,所有人都是棋子而已。解决了气、位、面、利,就很好搞定团队和谐了。
商业+产品+管理+技术=IT管理者
从现实来看来做,从手头的资源从手头的问题做起,行进中开火,解决问题中长大。
看人,引导人,锻炼人,提拔人。首先就是责任心。在责任心之后,才能说到才能。
对于下属,我主要是给机会给项目锻炼人。聊天交流,什么都聊。指派一位合适性格的师傅。
用高于他能力一倍的项目锻炼人。不会把项目成败的关键点任务给他。鼓励他,指导他,我会问他遇到什么问题了,我会问他进度提醒他任务时限。
12 为什么DIY报价-报价
开发部一定要把老板能看懂的东西主动的完整的呈现给老板,让老板减轻疑心。
编写了设计文档、测试案例、测试报告、帮助文档、演示版、需求管理库、BUG管理库、每一次版本的归档源代码和文档,并且也用了专门的开发部服务器,表明里面装的都是公司最重要的财富:软件源代码。
根源就在企业不知道软件成本构成,乱设底价。而软件公司,为了得到单子,报价更低于客户的底价。就这样,一轮轮的循环,价格越来越低,软件公司为了生存,不断糊弄事保本。最后直到糊弄的客户都知道这家软件公司是个骗子了事。
要有售前人员和销售人员一起配合打单,售前人员调研收集分析客户现状和问题,并且提出解决方案,然后再和销售一起完成销售报价。
13 敢问路在何方-职业规划
商业软件公司,赚钱为主。如果你的技术无法给公司赚钱带来帮助,就根本没有用。
职位发展:
实施人员、实施经理、咨询经理、售前、市场、销售
服务人员、服务经理
开发人员、高级开发、客户化定制开发、技术专家、开发经理、技术总监、CTO
项目经理、PMO
踏实努力干活的员工在每个IT公司都是宝。
是工作强奸你还是你享受工作,就看你怎么看。
14 懈寄生-书单
我的奶酪是什么?我的奶酪什么时候会变质?我的下一块奶酪如何得到?我究竟想要什么样的奶酪?
《TCP/IP原理》
《微软的秘密》
《竞争战略》
《计算机世界》
《COM本质论》
《设计模式》
《流程管理》
《谁动了我的奶酪》
《CORBA企业解决方案》
《软件开发的科学与艺术》
《程序员》杂志
心有多大,舞台就有多大。
你关注什么,你就会得到什么。
15 那根胡萝卜-激励
大部分老板开公司的出发点和目的点都是钱和权。
在管理技巧上,项目奖金不是唯一的激励手法。而且未必是最有效的方法。每个人每个阶段的诉求是不一样的。
1每次的和老板的交流更改,都先写文字性的东西,给老板看理解的对不对。
2每次和老板的交流更改,都把他过去的几种思路都在文档中列出来,并且说明每一种的优点,每一种的缺点。并且你要综合出一个综合所有优点避免缺点的方案也写在文档中。让他感觉,这就对了,没有缺憾了。
不要让老板想问题答案。而应该把老板能想到的答案你先想到,然后给老板一个选择题,这样你就不会出意外了。
16 七里香-新人
新人培训采取行动中开火,实战中成长,师傅带领指导监督管理。
而一位新人,不管你是应届毕业生还是老油子,你既然来到了一个新的公司新的环境,就必须要很快融入这个独特的部门文化中。
直到真正遇到任务,带着问题去找相关的答案,他们才会去真正用心了解这些。
这次我是娴熟的老员工。
1公司所有人的联系方式要到
2每个部门的头都短期内认识了。认识方法就是吃饭
3现有产品深刻使用操作了一遍,发现了问题,也知道了现状,也知道了未来如何改进
4现有客户,现有正在跟单的项目情况
5离老板最亲近的几个人,和他们玩,聊天,吃饭,深刻观察了解他们的做事方法,观察他们为什么能离老板这么近。近朱者赤近墨者黑。这样也能看出老板是个什么样的人
6每个部门的事实领导人,有些人不是头,但是很有影响,是事实上的内部头目,和他们玩,请他们吃饭,把部门的利益团伙和公司历史,公司的真正收入来源和真实收入数额和盈利模式都了解清楚
7瞅机会,创造一切机会,和每个老板聊,了解每个老板的想法
8改进现有产品最大的几个难点问题,寻求短期内出彩的活让公司所有人立刻刮目相看。
17 走钢索的人-架构师
架构师应该具备的特性:
1核心软件技术。深入了解数据库的工作原理。
2产品特性。如果不以解决自己工作中的问题为圆心,很容易陷于到大量学习却越来越茫然找不到出路的境地。
3软件趋势。大环境变,咱们就跟着变。大环境不变,咱也照旧。
4创新技巧。你想把你手中的技术能用活,你必然是理解这项技术的来龙去脉和这项技术的适用领域,还要深入理解这项技术的工作原理,还要清楚的认识到你要解决的问题领域,否则,你无法把你的技术和你要解决的问题结合在一起。
架构师总是游走在技术和业务之间,既要兼容软件历史不能割裂又要面向未来发展。
客户并不是那个非要和你作对的人,他只想解决他的问题。可能你不理解他的真正根源问题而且你又提不出更好的方案,所以他要跟你急,要让你必须实现某个功能。
只有你不断游走在业务过去现状未来与技术过去现状未来,你做的架构才是真正的实用、弹性、易用,而且最小成本,不走弯路,不多花开发精力。
18 焦油坑-需求调研
收集报表和单据,通过他们给我的表格,我就大致知道了他们的工作岗位内容。
把最常用的,次常用的,偶尔用的报表都分了类,了解影响考核和奖金工资福利的表格。
最关注哪几个指标,这些指标的关联关系,这些指标是怎么的,数据是怎么得来的。
了解报表和单据的使用频率,明白每个人主要真正做哪些事,怎么做,最后怎么考核,哪些事最重要,哪些事每天做,哪些事频率最高。
常用的功能,重要的功能,性能压力大的功能,稳定性要求高的功能、数据精确要求高功能,易操作性要求高的的功能,就是从这些提问回答中自然浮现出来的。
列出来部门的组织结构、人员岗位角色说明、业务流程图、考核报表。
针对这次项目,把这次项目相关的详细描述出来,并且把核心业务流程和非核心业务流程分开。
针对每个报表间的钩稽关系,每张单据录入的每一项录入要求、默认值、必填项、唯一约束、录入校验、单据状态、可选值都做了详细调研。
单个人访谈,把每个人工作中认为最想解决的问题都提出来,但只能说5个,能想到哪些就说哪些,我们一一记录。
优化流程:整理调研内容,针对疏漏和矛盾的地方,提出改进建议。把他们每个人认为最想解决的问题都考虑进流程和业务单据报表中,建议增加什么流程、建议增加什么单据、建议增加什么报表,谁来做,怎么做,谁来监督,怎么考核。
组织了部门座谈会。讲解了我们梳理过的流程现状,给他们说明漏洞和矛盾,给他们说明我们提出的方案。
把这份调查报告又给了他们大老板演示了一次。有了大老板的肯定。
做一个部门的调研,就给他们的大老板发一个报告邮件。邮件抄送给调研的业务部门负责人。
我并没有想过这件事该管理咨询公司做,那件事情该软件公司做。我只想解决我的问题,我的方法也是由此而来的。
系统的调研方法,从调研描述现状、然后分析优化的组织结构、工作流程、考核报表、岗位职责四大块来描述需求。
把这些转变为软件中的功能、权限、报表也一气呵成。组织结构和岗位职责决定了功能点和功能权限、工作流程决定了软件流程、工作流程中使用的纸张信息、EXCEL信息、软件信息就是数据输入,报表就是数据输出。这就是一个企业管理软件的四大块:组织权限、输入、处理流程、输出。
我们在需求调研的阶段会调研客户的信息化现状,如IT维护人员能力,信息化应用能力,客户老板对信息化认知理解,最终用户信息化操作能力。
解决问题,这是你自己面临的问题,你不去自己想办法,没有人会给你解决这个问题。能救你自己的只能是你自己。
19 一个人的战斗-维护
维护老系统,也要象经营企业一样,不断继承包袱,不断细心剖析问题,剥茧抽丝理清思路,不断改进,才能渐渐从恶性循环走向良性循环,才能把一套烂代码扭转成可持续维护的代码。
维护写代码的八个建议:
一、重点把控输入数据的校验。
二、以后的需求再往上加,都写成函数。
三、以后再加功能,尽量不要做成联动触发的。
四、把特殊处理业务和正常处理业务的功能代码分离。
五、现有的功能,把不常用的功能做一些隐藏处理。
六、你越和旧有代码生气,你的工作越乱。真正危害大的是全局变量和大流水代码。所以写代码,要严格避免这两个坏因素。
七、修改需求或BUG的时候,要按照模块来集中修改。
八、更新帮助说明。在写帮助说明的时候,我要求实施人员把每个按钮都要点到,每个Grid中的每一个字段的数据来源和数据含义都要说明到,每一张报表中的字段的数据来源和数据含义,每一个明细录入中的字段的数据来源、数据录入要求和数据含义。
不盼望软件工程,不抱怨一穷二白,不幻想增加人手,从现实入手解决自己的问题,发现很多解决方法既简单又有效,根本无须动辄就是团队就是UML就是OO。
需求控制的建议:
需求,是很多方面的。有关于功能的(尤其是每家客户特殊的业务需求),有关于异常错误的、有关于性能的、有关于兼容性的、有关于易用性的、有关于特殊权限的、有关于美观性的。
需求的来源也是很多方面的。
需求的优先级也不一样。
第一、 把需求分类,做个EXCEL表格,量化解决。记录客户名称、需求提出人、提出日期、需求关闭时间、功能模块名、客户现在版本号、需求描述、需求分类(需求、BUG)。
第二、 需求描述不清晰是反复修改的罪魁祸首。
开始版本管理。
代码备份到其他的机器上。备份目录要跟上日期。
如果每次发布新版本,就把从上一版本发布之日之后的关闭的需求列表都单独摘成一个文件,附带到这次新发布的版本之后。
有方法,你就不是一个人在战斗。
20 累斗累-引领行业
我是把产品放在一个产业中看。看竞争对手,看业界标杆,看业内管理专家,所以我对产品的升级完善,是基于产品战略的,是基于盈利模式和竞争力构建的。如何引出更多的盈利增值产品,如何保证产品更有竞争力,是我思考的重点。
程序员一直在修改,但另一方面,我们已经修改了多次,满足需求300多条,但是我们的产品竞争力增强了么?我们的特点在哪里?我们的亮点在哪里?我们的竞争力在哪里?
客户需要在ERP中加入游戏,如果理由充分也是可以的。重要的是客户不能得罪。客户关系是老板的生存之本,而非产品。
客户和实施人员不分析问题根源,只看表面问题现象,还自以为是提最佳解决方法,还让开发部实现。
走访客户的目的:了解客户现状,想方法如何去引导与影响客户。客户面临最急需的问题是什么?客户对软件的认知程度如何?客户把软件价值认为成什么样?客户认为这套软件应该是干什么的?
将量化的评价模型内嵌到软件中。
引领客户,引领老板和实施人员对产品,对业界,对未来,对竞争的认知提高。
你的价值在哪里?
21 我要飞的更高-新产品规划
只有盈利模式+先进技术+先进管理,才可能成就新一代的产品。
摸清了我们自己的优势、困境、竞争地位、未来目标、未来业界位置,摸清了行业业界现状、未来影响,摸清了竞争对手,摸清了现在流行的盈利模式,摸清了未来更加敏捷的技术,我们才能给我们的产品定一个位置。有新的高度、新的视角,对行业企业组织、业务流程进行审视、形成有组织、有流程、有层次的管理信息化体系。
新产品必须与公司的实力和战略相结合,符合老板的观点。
标杆法。跟踪分析SAP、用友、金蝶这些标杆企业的产品,学习他们的架构、产品气质、实施模式、咨询模式、服务模式、销售模式、市场模式。
只比客户前进半步。这是做产品的很重要的指导原则。
客户是给老板钱的人,老板是给我们钱的人,而营销部门在乎的是好不好卖,能不能大卖,能不能赚更多的提成,而且卖完后没有后遗症(小心自己多年维护的客户关系被毁了)。而实施部门在乎的是东西好不好让客户接受,能不能很快培训完上线走人。而支持服务部门只在乎以后别出问题就行,工作越少越好,但也不能没有BUG,否则他们就没有多大用处了。
得到者多助,失道者寡助。上下左右逢源,你才能成功。
22 波、波、波-新产品研发
产品规划,我们尽量促使产品成为消费类软件或基础类软件。大家研发产品的时候一定要记得这两个关键点:整合产品竞争力、基础类软件与合作伙伴。
关于新产品的研发,一定要有这个产品生命周期的视野。要从产业、竞争环境、国家环境、客户行业、技术发展多个角度去思考产品规划。
大局规划,细处入手,客户最关键的需求实现。
23 八部众-质量属性
我们做新产品,也不能抱着科学家研究的思路,而更应该是在资金、时间、人的素质、人的数量、竞争压力、客户现状的框架下的量化可控的研发,有阶段,有目的,有重点的研发。
一个软件,对于不同的人来说有不同的要求:
对于销售来说,演示的时候稳定、易用、好看、速度快就是关键;
对于实施来说,最重要的就是软件稳定。为了能让实施人员现场满足客户需求,开发人员必须要给实施人员提供实施人员能用的起来的实施工具;
对于培训来说,软件易用最关键。培训文档:演示版,操作视频录像,最新版本帮助文件,新版本更新说明;
对于支持来说,软件稳定是第一位的。软件必须可跟踪,记录日志。对于数据量大性能要求高的应用,性能是很关键的持续改进方面。对于安全性要求强的应用,设计安全的方案,编写安全的代码,安全的测试覆盖是很重要的工作;
对于测试人员来讲,软件必须具有可测试性。这就要求有设计文档,详细写明什么样的操作和结果是正确的,报表数据之间的关联关系。这样就有了可测试可验证的标准。
对于文案人员来说,软件必须能让文案人员编写文档。
对于企业管理软件来说,必须在基础设计的时候就强烈关注数据库设计。
实用性、稳定性、容错性、性能、可测试、可理解、可修改、可实施、可支持、灵活性、移植性、兼容性、安全性、易用性....
但这么多要求,我们都要有目的分阶段的一步步达到。而且,往往我们不断补齐上一阶段留下的遗憾,我们此阶段的努力又会形成下一阶段的遗憾,总是无法达到一个赏心悦目可以笑看江湖的软件。可能,世事轮回皆此规律。
一个好软件,也是如此多的标准特性,也是如此共生又如此矛盾。
24 葵花点穴手-产品定位
微软的一个产品定位方法:
对于什么目标市场的客户(一定要精确描述好你的目标市场,千万别用什么中小型企业之类的词语)而言,你的什么产品或服务(针对这类目标客户,你提供了相应的什么产品或服务,这个产品或服务一定要与你的目标客户匹配),提供了什么主要价值(要精确,千万不要说提高了管理水平。管理这个东西很模糊,就类似这个企业管理水平低,到底指的是什么),因为你的这个产品或服务提供了什么独到之处(一定要独到,否则人家为什么买你们,而不是买别人的)。
标杆法:
1我们就拼凑,把各个功能使用优秀的客户分别挑出来,然后都按照组织结构、企业文化、老板性格...等等这些方面来描述,然后把他们综合在一起,一个“完美”的最佳客户就出来了。
2我们以后去做销售、实施的时候,就把当前这个客户和我们设计的这个最佳客户进行对比,很快就能分析出这个客户最适合使用哪部分,它的优点在哪里,它的缺点在哪里,它的差距多大,从什么方面去提升。
25 文档知多少-研发流程
一、系统调研
系统的调研方法,从调研描述现状、然后分析优化的组织结构、工作流程、考核报表、岗位职责四大块来描述需求。客户优化后的流程、工具中包含手工纸张信息、EXCEL信息、软件信息。
需求调研的结果,落实到纸面,就有需求分析说明书,另外还有一份需求调研报告,是偏向于项目过程叙述的。
二、概要设计
需求调研人、业务组组长、测试组组长来学习、讨论,根据大家讨论补充后的需求分析说明书,出功能点文档。
我们会把需求分析说明书中的业务功能都列出来清单,属于组织结构建立、组织角色、权限分配、登陆验证、基础数据维护之类的都归类到系统功能中。系统管理,各个企业管理软件差不多,我们又有公共的系统管理模块,就不需要重新发明轮子了。所以,我们主要重点是分析业务功能。
根据需求分析说明书中的每个流程,都先提出来成为一个功能点。然后针对现在整理出来的功能点,再一个个对照流程,如果这个流程复杂,就拆分,把这个功能点拆成几个复杂性和预估工作量差不多的功能点。经过这样的拆分,就形成了最终的功能点文档。
而功能点之间,根据上述方法的拆分,就形成了功能群。
功能点就成为功能权限控制的最小单位。功能群就成了软件菜单中的一项。几个相关联的功能群就成为了一个业务子系统。
就这样的方法,使子系统-功能菜单-功能点(可能是某个功能窗口上的功能按钮)三级分开,与组织结构-员工-角色-用户-权限结合。一个软件,未来会成为什么样子,大框架就出来了。
然后,我们会根据功能点清单,为每一个功能进行优先级的标示。我们通常会把优先级分为三级。这就意味着一个项目,大致分为三个阶段。一级是必须要做的,即使延期也要做,必须调度多加人手多加班也要完成。一级做完后,如果有时间,就把二级完成。如果时间超期,有适度的尽量去完成二级,可以延期,但也要根据预算和时间。如果适当延期也无法完成,我们会给客户去上线实施,边实施边并行开发,使实施团队和开发团队进行并行工作。所以,二级也是重要的功能。三级就是如果时间用完,三级的功能就要舍弃掉不开发。
一般是,按功能的重要性来划分优先级,我们调研需求的时候,就把常用业务和异常业务分开,把每天做的业务,和每周、每月、每季、每年做的业务分开。几个结合特别紧密的,互相关联的,我们也会把他们划分在同一个优先级,需要单独开发的基础数据维护界面,我们也会放在同一个优先级。这样,只要我们项目到期,或者我们迫于竞争突变,我们会随时推出一个可以完整使用的系统。虽然这个系统可能功能简陋,但可以完整处理整个常用业务流程,而不会造成中断,无法处理下去。
三、详细设计
我们开始针对功能点清单编写我们的功能设计说明书。
我们是按照优先级来编写功能设计说明书的。我们并不会把功能设计说明书都编写完毕后才开始编码。而是,我们先把优先级为一的详细功能设计编写出来,就开始开发。二级的功能编写会在开发人员进行一级功能编码的时候并行。
功能详细设计说明书由业务开发组的组长来编写,属于系统类功能或公共类的功能,都归给公共代码人员来编写,需要复杂的算法,高性能,高安全,高数据量,需求一直未确定最终解决方案的未来未知变化的接口,也都由公共代码人员来编写。所以,一个开发团队,有高技术的公共代码人员,有深刻理解业务的业务开发组组长,有普通的coding人员。业务开发组的组长一般由熟悉客户业务,编码经验较多但技术能力一般、踏实细心负责适合团队管理的人担任。
功能设计说明书,根据每个功能点详细展开描述。一般一个功能点由一个EXCEL文档来详细描述。
EXCEL文档第一个sheet中是版本信息,每次修改都有变更记录。第二个sheet是页面布局。我们通常会用PPT或开发工具建立个界面草图,然后贴上去。第三个sheet是页面上面的每个字段的说明,如默认值、不可为空、输入约束、主键唯一、输入长度、参照录入等等。第四个sheet,如果有必要,可以用VISIO画出业务流程图。第五个sheet是关于运行要求,如易用性、安全性、性能、数据量、并发性,这几个特性都分为高中低三个等级。
一个功能,必须考虑它的用户的计算机水平,否则功能很实用,但就操作不习惯,客户非要改成客户习惯的方法,我们经常会面临这样的要求。我们的软件需要在什么硬件上什么基础软件上运行,数据量多大仍然可以运行流畅,我们的软件要达到的易用操作程度,要达到的易用维护程度等等,我们必须在设计期考虑到。
我们会先交给测试组的人员来校验这个功能点的详细设计,是否和需求流程和需求要求吻合,不符合的地方就整改。
整改后的功能设计文档,算是和需求说明文档一致,设计正确。这时候才涉及到具体的实现说明。
五、数据库设计
我们会让公共代码人员(数据库设计人员)从界面输入输出和业务流程图中整理出数据结构。我们为什么不让业务开发组的组长来整理表结构,就是由于业务开发组的组长熟知业务却对技术并不精通。数据结构很影响未来的性能、扩展,所以应该由公共代码人员来设计表结构,并且建立视图和存储过程。
公共代码人员为了考虑性能和扩展,表结构的设计可能就被打散成多个表,而不是业务开发组长自然理解的存储结构。所以公共代码人员建立了视图,保证在视图的层面上让业务代码开发组的人看到的是一个自然的业务实体数据结构,根本无须理解内部的表结构之间的关联关系。而且有存储过程来保证如何无须知道表之间的关联关系就可以增删改数据。
公共代码人员把设计完毕的数据结构交给业务开发组组长,组长来编写每个功能的数据增删改查操作文档。增加这部分文档到EXCEL中,成为第六个sheet。
六、代码开发
我们采取的是从后到前的开发方法。先有数据层,有基础表结构、视图、存储过程,然后基于视图和存储过程进行业务流程代码开发,最终由普通的业务开发人员进行界面拖控件绘制界面。
七、测试
我一直提倡的是全程测试,从需求到设计到代码到文档到打包,都要经过测试。只有每个环节都能保证正确,结果才会正确。如果到了代码编写完后才发现了不对,甚至是需求一开始就理解的不对或有矛盾流程,这就糟糕了。
八、并行
文档编写完毕一个整块(相对独立模块,不是全部的一级功能编写完毕后),我们就会交付给业务开发组去开发。具体开发人员任务安排,由业务开发组组长来决定。需要由公共开发人员来开发的,业务开发组组长都会根据自己的开发计划和公共开发人员的任务列表(我们用需求管理系统来安排每个人的开发任务),告知公共开发人员预期的实现完毕时间。
这样,公共开发和业务开发在并行,设计编写和功能开发在并行,设计和设计测试在并行,代码和代码测试在并行(我们采取的是版本管理和每日构建)。
一旦发现某个环节出现问题,理解集中人力来解决,而不会让这个问题的这个人延期钻牛角尖,否则,所有的项目进度管理都成了一句空话。没有了实质的进度,也就没有了实质的项目预算管理。那到底能不能赚钱,真成了一个鬼才知道的问题。
九、文档
我们并不是为了正规才编写文档,我们写的每一个文档都有作用。我们也在力求能少写就少写,根据团队的、客户的磨合理解共识程度,哪个文档或哪个环节不需要写,我们就砍掉。
我们只是商业开发,我们要的是可控,在有限的人力资源、合同额、合同周期内交付出客户认可的质量产品(不是高质量,是客户能接受的质量,我们从来不为没有利益回报的东西多付出)。
26 狮面人-岗位
销售打单的时候,关于产品的、技术的、开发周期、工作量估算、项目团队组成的PPT和方案由研发部的项目经理来做,关于价格和商务条件上的由销售来做。
一般,都是一个产品或一个项目,由一名业务开发组长、一名主程、一名辅程加项目经理、公共代码开发、测试员、文案等。
然后就是公共代码开发人员,一般就一个人。对于企业管理软件的开发,框架的开发和维护,公共代码的开发,高难度的问题跟踪,需要高性能的设计,需要高扩展性的设计,需要高稳定的代码,需要高安全的代码,需要高并发的操作,需要复杂代码重构。需要性能优化,不知道的技术API,都可以寻求这位公共代码开发人员的帮助。他还负责新技术跟踪、新技术介绍、新技术试验。但这个新技术必须是为了改进公司现有产品和现有客户。新技术的跟踪必须上报给技术总监,以防不符合公司目标乱跟踪或跟踪方法和思路不对。对于有利于现有开发的新技术,可以筹备好培训课,由研发部经理安排时间,让公共代码人员给研发部全体人员讲解。如果大家认可这种方法,就需要选择适当的时机在产品中引入。
测试人员,包括编写测试案例,编写测试结果,参与项目的需求测试、设计测试。一般也兼任服务部门技术支持人员。而且测试人员还兼任配置人员,在产品打包、产品安装测试、产品发布、版本分支管理、源代码备份、历史版本归档方面都由他来管理。由测试人员控制产品版本发布,能不能发布,就是测试员说了算。测试员感觉质量没有达到,就有权不发布。
为了不让项目质量和特定人密切相关,使公司研发保持连贯性水准,必须做到分工专业,互相配合互相牵制。
对于研发部的文档方面,如文档的正规化,都由文案来负责。文档的正规化、美化、文字校对、空格段落措辞标点符号,都由文案制作。帮助文档,也由文案负责。帮助方面,有版本更新说明帮助、安全配置帮助、系统维护管理帮助、基础数据配置与维护帮助、业务功能操作帮助、软件操作演示视频、产品简介PPT、产品演示版,都由文案来做。
为了防止文案不懂产品而写产品帮助,在需求说明书、设计说明书这些文档性的工作上,如果有什么文档体力活之类的工作,也由文案人员来做。文案人员还兼任产品辅助测试,主要是作为一个普通的操作者来测试
有时候团队小了,每个人都身兼数职,而且都对自身的提高非常有好处,而不是给他身上堆砌毫不关联的工作内容。每一项职责都是能互相互补的,整体提高他的岗位专业性。
作为业务开发组组长,他很大的一个职责就是开发项目的进度和质量管理。业务开发组长必须每天都在监控进度异常,监控每个开发人员目前身上背着的开发任务和开发进展。每天下午5点的时候都要询问一下自己手下这两个人的开发进展。
来自需求管理系统中的需求,来自BUG管理系统的BUG,都会被业务开发组长来评估,根据自己团队当前每个人的工作量来适机添加、定优先级、分配任务、调度任务。也根据这个任务分配,哪些任务超期了,哪些任务完工了,哪些任务还没有开工,哪些任务正在进行当中,来判别开发人员的开发进度和工作量。
每个任务的时间,都会是业务开发组长在开发人员自己预估的时间基础之上进行调整,获得一个开发人员和业务开发组长都能接受的任务时间段。然后根据每天的进度报告来随时调整这个时间,让开发进度尽量能现实,而不是计划前就定好实际工作中就不能改。
开发,是个团队配合的事情。一个软件,并不是开发人员就能全部完成的(许多老板都这认为有开发人员就行)。缺少了测试,质量就无法保证;缺少了文档,产品就是光秃秃的软件。而许多老板还认为测试和文档可以在代码编写完后可以做,真是对软件质量如何保证一无所知。
我们做企业管理软件,要想上升赚钱,必须大规模一般员工团队低成本开发,这是我和老板都认同的一种思路。所以,我们必须使用最常用最普通的技术。
不允许团队使用最新技术。我们只使用最合适的技术。
采取了每日构建每日测试,来保证软件的进度和质量。不每日测试,哪到什么时候才测试。到那个时候测试,会不会出现其他什么不可控的问题,我们都说不清。
软件是由代码组成的,确实不容易让客户理解其中的艰辛和付出,所以客户并不认可我们的付出。能拿客户可以理解的方式去讲明白就是解决方法。我一贯遵守的原则就是:要么解决问题,要么闭嘴。
27 沙场秋点兵-重构
这次没讲明的,这次提问没有确切答案的,下次继续讲,而不仅仅是讲一回。我发现,很多团队缺乏这种不断追根到底的魄力。总是虎头蛇尾。
不会让新产品、新团队、新技术这三个新都同时出现,风险太大了。而且坚决不使用新技术作为基础技术。
我既不赞同你们尽量使用过去代码,也不赞同全部重新编码。先重新写,需要用的时候自己就COPY出来。
28 代码那些事儿
我确实没有阅读过OO的书籍,我不是一个死钻牛角尖的人。我只是有什么问题,就去找解决问题的方法,能解决我的问题就OK,而不在乎我用的正不正宗,也不在乎我用的是不是OO。可能它是OO的外壳,但是它实质上可能是伪OO,我也不想去深究和区分什么是正宗OO,什么是伪OO。反正能解决我的问题就行。
我们就把这个全局变量封装成属性,给它赋予读和写的函数。不管有多少个地方调用了它,有谁给它乱赋值,这里掐源头,都做好日志和异常保护校验。
把所有函数,能变成私有的就变成私有的,需要公共供其他人调用的谨慎的放出来。放出来的函数,一定要做好参数的校验,什么空指针,什么没有初始值,什么非法参数值的,尤其是临界值上下边界,都在门口就挡住,根本不往下执行进行业务处理,否则走的越远引起的问题越大。
而且要求每个函数都要做好自己的内存保护工作,自己函数内创建的就要在函数内释放。每个函数要做好异常处理和日志记录。
于是,我们在版本测试的时候、第一个版本小规模放给典型客户的时候,都加了断言。一旦软件出现问题,就立即记录日志,并进行软件中断,而不让错误继续错乱的不按我们预想的代码流程走下去。
我要求开发人员经常性使用断言,很多过去悄然发生的错误,测试员只运行可执行程序无法捕捉到,现在都能明确的捕捉到,在测试阶段就尽可能的消灭了那些过去无法明示的BUG。
确实需要分离的时候就分离,即照顾了设计扩展,又照顾了实用。真正的纯OO,纯设计模式,可能只存在于教学和科学,而不在于我们的商业软件开发。我们作为商业开发,强调的是叫座的基础上叫好,所以折中方案是必须的,客户和我们自己两相宜就OK,是否符合正宗,就不在我们的商业开发管理范畴了。
做事不能走极端。要么全写注释,要么不写注释,都是不对的。我只在我认为要小心的地方,或者我自己都觉得很难理解懂的地方我才写注释。
我的心中只有业务,业务和代码,我认为只是英语和汉语的区别,表达的是同一个思路。而在你心中,业务是DOC上的文字,代码是你的技术表现,你老需要把业务和代码映射拧在一起,我则不需要。业务流程如何,我的代码流程就是如何。
没有详细设计说明书,所以你看不到一个形象的东西,而咱们现在至少有PPT画的业务界面,也有输入要求说明,也有数据增删改查说明,也有业务描述说明。而且数据库,一个中大型应用,性能、稳定性、可扩展性,都在于数据库的设计和中间件的设计,如果每一个程序员都要从数据库设计到中间件组件开发到前端客户端开发,那么要想保证这个软件的统一整体质量,那有多难。每个程序员需要懂得多少的技术知识才能达到统一的质量要求。所以,让不同技术高度的人做不同难度的事情,把重要的事情掌握在高素质的人的手中,这样质量就不会跑偏到哪里去。企业管理软件,不外乎是数据的增删改查。数据库的视图和存储过程,已经屏蔽了复杂的表之间的关系,提供了统一的业务实体视图和业务实体的增删改操作。这样中间件组件就容易处理业务实体间的流程,到了客户端,就只剩下数据的输入和输出了,真正成了终端。
我还经常进行代码复查工作。发现有人的代码出现坏迹象,我就让他整改重构自己的代码。否则,定了规范,光喊口号让大家遵守规范又不检查又不惩罚,谁爱遵守规范?
企业的运作,恰恰在于每一步的成功,最终汇合成最终目标的实现,没有脚下的每一步前进,再好的设想也是空想。
管理,就在细节当中。
代码高手,也在于细节当中。
质量、进度、成本、目标、折中,这就是核心。写代码,做管理,道理一样。
29 风语者-测试
测试每个问题,要标好功能模块,有测试人,有测试版本号,有测试时间,有测试操作过程,有测试输入数据,有报错截图 。
先测试正常的数据输入,正常的操作流程,是否能全部流程走通,是否数据保存正常,是否保存后的数据还能正确的取出来。那些临界条件测试先不要做。
对于功能不易操作、界面不好看、起的窗口标题是否得当,字体是否加粗这些需求不要提。咱们目前阶段的重点是测试问题,不要把需求和找问题混在一起。
这个大项目快做完了,以后有什么活能养活现在这么多人呢。所以,最好的做法就是把现在这个项目产生的软件改改,变成一个产品,卖给其他的客户,卖的越多越好。但是,其他客户我们有关系的并不多,所以要想销售给其他客户,必须拿产品说话。于是,研发部陆续加入了专职的测试人员、文案人员、美工人员,旨在提高产品的质量和包装,希望能卖个好价格。
所以说,专职的测试人员是这么来的。
很多软件公司没有测试人员,其原因就是老板搞定关系,程序员老实干活,项目质量虽然不行,但也能将就把钱结了。既然能赚钱,干嘛要测试人员呢。除非由于质量问题,签不到单子。除非由于质量问题,客户不验收不给尾款。除非公司所有人都测试还是无法达到客户满意的质量。只有这样,才会招聘专职的专业的测试人员。
我又下了几招: 1开发人员绝对不能接触客户,不能接听客户电话,也不能解决客户问题,更不能给客户更新 2开发人员不能没有任务分配和设计文档就擅自修改软件,否则记过处分 3大家一致使用版本管理工具、BUG管理工具、需求管理工具、任务管理工具。用工具把项目经理、开发人员、测试人员、文案人员绑定在一起,按固化流程推进流转。 4打包发布统一交给测试人员来做,测试人员来控制是否可以发布,发布的版本号的命名。质量达不到,有权不能发布。
现在,我们的测试已经能做边界测试、版本兼容性测试、系统兼容性测试、压力测试、安全测试、集成测试、破坏性测试 。也已经在项目中应用全程测试,测试人员主要参与需求验证、设计验证、代码验证、文档验证、打包验证。
老板越从软件上赚钱,他才会越舍得投入软件。成本永远嫌多,利润永远嫌少。
如果你是一名开发主管,你的老板还没有从你负责的软件中赚钱,而且是很快乐的很大规模的赚钱,而不是他靠他的人际关系和送礼吃饭支撑着,我想,他不会给你一毛钱的。你抱怨也没有用,因为你没有价值,所以投入也是没有意义。
先去证明你的价值吧。
30 蛋白质女孩-文案
写帮助:
有一步步的操作截图,有一步步的操作说明,有特殊业务的特殊说明,有FAQ,有重点注意地方的重点标注,有业务流程,有数据流程,有输入要求,有输出要求。界面上的每个字段都做了解释,形成一张表格,每个字段一行说明。有这个字段的含义,有什么样的作用,是否为必填,是否有默认值,输入的约束是什么,什么时候是只读的,可能会有几种状态值,如果是下拉选择的参照录入,参照字典是哪个基础数据维护功能可以维护。
对于输出报表,报表每个字段的含义,报表每个字段的数据来源,字段与字段之间的钩稽关系是什么,此报表字段还与其他什么报表的什么字段关联。
我有文案人员充当客户方案编写,让过去销售部夸大空洞的解决方案有了实质产品感觉。
为了打单方便,文案还制作了演示版,里面有模拟真实客户业务的数据,可以达到完整的演示全部流程和报表表现。
虽然每次发布新版本,都有更新变动说明,都有最新的操作说明,也有操作视频,但没有人看。
每当新版本发布,你对照你写的更新变动说明,你的操作说明书,你的操作视频,你的演示版,你搞个实施人员集中培训。并且你出题,给他们考试,给他们打分。但你给他们做培训的时候,必须有正规的签到表,正规的培训教材,正规的培训PPT,掌握好一节课的时间,掌握好一节课的重点,掌握好一节课的快慢与难易程度的节奏。下了课还必须让他们填写本课的培训反馈。
机会是需要你去铺垫创造,你去抢机会(你自己铺垫的机会也有可能被别人抢走),你去有能力抓住机会,机会并不是我送给你的,机会是转瞬即逝的。
31 像咨询师一样思考
提升管理软件的销售价:
在软件产品方面,分了高级版、标准版、简化版。并且引入了测试,提高产品质量。引入了文案,制作了产品白皮书、操作帮助说明、安装说明、配置说明、维护说明、新版本更新说明、操作视频、演示版。在软件UI方面,引入了美工。在实施方面,引入了金牌实施顾问、银牌实施顾问、铜牌实施顾问。在服务支持方面也亦然。一切的一切,都旨在一个产品,面对不同层次的客户进行裁减组合,销售不同的价格,提供不同的服务项目与质量,与客户所期望的目标和所付出的金额成正比。
企业管理软件,软件是一种形式,而管理方法才是最重要的。
管理软件公司没有管理,这是业界很久的一个自嘲笑话。
管理软件,要有竞争力,必然是在管理方法上竞争。这是目前能提高软件售价的唯一出路。
咨询方法:
一、把你现在怎么做的写下来,然后照着做。如果写的和做的不相符,就改进写的内容,直到相符了。执行一段周期,重新审视你写的内容,需要整改或详细的部分,就让它完善起来。然后继续按照你写的去严格执行去做。这个思路就是ISO的思路。也是CMM可重复级的思路。现状好与坏,先放在一边不要争论。反正现在已经形成这样的现状,必然是符合现在的情况和历史的发展情况。每件事情的形成都不是无理由的。存在就必定合理。所以,先能让你写的和你做的吻合了,是最紧要的事情。先固化,后优化。
二、计划、执行、检查、修正、再计划、再执行、再检查。
三、组织、岗位、流程、考核。这个方法也是企业一般管理方法,对于软件公司也通用。软件公司也是公司,也要生产销售,和自己面对的企业客户是一样的,都脱离不了这个方法论。公司的组织结构、每个人的岗位职责描述、每个岗位的每个职责的工作流程、每个职责的工作流程之后的考核。按照这种方法梳理下来,管理流程、方法都跃然纸上了。
四、问卷评分法。我们需要问卷评分法,来量化实施后的效果。而且要周期性的量化,以辨别这个提升是由于行业整体上升因素影响,还是上了软件的影响,还是产品创新销售红火影响,还是涨了工资员工积极性提升的影响。
五、标杆法。拿自己和行业领头羊比,看看差距多大,看看差距在哪里。
六、KPI法。管理方法,你不能是按照企业现状照猫画虎来个流程梳理,然后按照流程做套软件就OK了的。那这种软件就是模拟一下现实,有什么管理提升的价值呢。所以,我们在梳理企业管理流程之后,我们会提出KPI指标模型,如何全面而概要的评价它的销售、如何评价它的生产、如何评价它的财务能力。都制定了KPI。而且会提出目标,提升10%,或提升20%,或提升30%。每个提升的目标,我们都有不同的策略。而不同的策略,它需要投入的变革时间、变革幅度、变革资金、变革阻力都有所不同。每个企业都希望提升最多,但我们现实的来看你自己,你是否能适应相匹配的变革。如果不匹配,很有可能变革失败引起企业流血甚至中层造反。所以,我们首先会根据企业现状的管理流程,建议企业KPI提升的幅度,然后建议进行优化组织、流程、考核方法。我们会根据KPI,把改良落实到几个点上。这样我们的工作有量化、有目标,有质量和进度控制。
咨询行业,核心是咨询方法,是寻找问题寻找答案的一种快速方法。这是具有很强的适应性和普遍性的,所以咨询行业才能扩大才能成长。
需要的咨询人才,一般具备以下能力:1能够根据企业现状,绘制出企业现在的组织结构、岗位职责、流程、考核 2能够找到空白的、多重管理的、压力大的、不优化的业务流程节点 3能够找到关键流程节点,制定KPI考核指标 4能够根据KPI指标设计问卷回访评分模型。
管理软件也不再是企业现有流程的素描照片,而是有清晰的体系和重点和功能目标,也能明确的给客户企业评价投入产出效果。
32 一分钟先生-经验
有很多网友特奇怪我为什么能有时间来写博客,甚至还能接受网友的IM交流,问我是怎么做到的。他们都觉得自己每天忙死了,相信我作为部门的头公司的高层,估计更忙的不见人影,怎么回事呢?
我总结了总结,在此给大家分享一下。
首先,我每天的工作主要干什么?
1每日接受开发组长报告给我的进度报告、功能需求设计报告,我来提出调整建议和指导。对于报告的问题,我会给出建议的处理方法。如果需要我出面动手解决,那我就出面。这是每日的例行事务,占了主要的时间。
2处理手下员工间的流程配合问题,处理部门间的流程配合问题。一般都是根据现在出现的问题重申和强调过去的流程、职责。如果需要调整流程和职责,就把新的流程和职责重新定义清楚,并且观察几天的执行情况,直到每个人都按照新的流程走。
3定期重新回顾这段时间公司业务的开展情况和面临的困难和未来的动态发展,以重新审视自己过去定义的产品战略,不断调整,以适合公司发展变化。根据产品发展战略的调整,然后调整内部每个人的职责和分工。
4定期和每个员工在MSN中沟通或面对面沟通,了解他们现在的心理变化、薪水、公司发展看法、职业发展看法,以自己掌握的信息和自己的经验,对每个员工提出指导建议和方向建议。对于没有个人目标的员工,和他一起交流制定一个可见时间内他可以达到的目标。如程序员,我会提出,在6个月内,让你的代码变的比现在稳定,至少要达到你自己心中的满意的稳定程度。然后,我会针对这个目标,时常提醒他,不要让他忘记这个目标,鼓励他一定能达到这个目标。不提醒,人就会渐渐忘记了自己上个月才确定好的目标,甚至由于当前的诱惑和问题,对自己定的目标发生了怀疑或不感兴趣,就失去了目标。
5对于每个员工所干的工作,我也会根据他最近出现的问题,及时进行能力方法、技巧的指导。如你应该这样做会更好。对于如何写稳定的代码、高性能的代码等等,对于如何测试找到更深层次的问题等等,都有技巧的指导,而且都是结合他现在所遇到的问题和手头的工作。我不会专门拿出一段时间来专门培训。我都是在日常工作中不断指导,把培训都化在了每日的工作中,尽量做到润物细无声。对于一些新手程序员,我拒绝回答他们的技术问题,我通常会说:把你们报错的那个信息原模原样输入到百度中,你就会找到答案。你也可以查询微软、SUN的联机手册,或者你到优快云上问、搜索。
6我还会平时看IT技术网站、行业网站,思考客户行业发展、IT技术发展。我来研究软件中的管理思想、管理模型、管理业务流程优化、考核评价模型。管理软件、数据分析咨询业务、市场推广,很需要这些模型和文章。每当我研究出一个管理模型,我就会写文章在内部发邮件,给公司老板、高层、员工推广。
7偶尔我会跟着实施、咨询团队到客户现场,体会真实的客户应用,和客户面对面交流,交流现在的问题,交流目前的困境和焦虑,交流未来的发展看法,体会客户真实的想法、思考思路,体会客户的真实应用水平。
这就是我大概的每日工作内容。
我能把时间省出来,最重要是以下几点方法:
1由于我经常性思考产品发展战略、盈利模式、管理模型、工作职责、流程制度,所以公司的发展一般都是按照计划和既定流程走的。很多公司也不知道自己做什么才能赚钱,就东一头西一头拉项目,所以也不会有产品发展战略,而一般老板也是销售出身,想不透软件产品如何发展,而技术总监呢,又不懂这些,可能就是个技术牛人而已,甚至连技术牛人都算不上,只能算个一帮人的头儿。我们过去也是没有产品发展战略,但我是职业经理人,我不能让公司东一头西一头的随波逐流,所以我常常思考公司现状,从公司的现在的资源和优势和困境来找一条产品发展路线。就这样不断思考不断尝试不断执行,渐渐的,在我空降公司3年后才找到了现在的清晰的切实可行的产品发展战略。有了切实可行的产品发展战略,随之就有稳定的工作流程与职责,每个人就有了稳定的计划和工作任务。变化少了,自然也就不会老救火了。很多人说忙,就是老出异常,老救火,公司没有稳定清晰的盈利模式,一直处于抓项目的状态,每个项目都没有连贯性,当然也就不需要流程,也不需要职责,有了项目大家一窝蜂加班,没有项目大家闲的要死,这样的状态,即使有流程和职责也是被废掉,根本没有用,执行不了,项目一来就废掉了。
2我不会去处理事情。我总是授人以渔。我一直强调方法和流程。如果一发现新异常,没有流程和职责和明确的人负责,我就会立即把这些都补齐,让明确的人去处理,而且有明确的处理流程。如果明确的人没有方法和头绪,我会指导他。但我从不会亲自做。
3就是因为有稳定的模式和流程和员工岗位,我就从细节中抽了出来。需求调研、功能设计,有项目经理。开发有开发组长和程序员,测试有测试员、文档有文案人员,实施有实施人员,支持有支持人员,每个事都有专门的处理人员,而且有明确的流程协作。由于我的平时不断的指导,还有他们每日都处理自己专门的事情,所以他们对自己负责的事情越来越经验多,处理起来很快,质量也高。我看到很多公司业务不固定不稳定,人经常被抽调来抽调去,当然经验积累就不深入不专业,工作就不胜任,干活质量和效率都不高。
4我这个人很专。我清楚的知道自己的优点和缺点,自己想要走的路。所以我十年,一直在开发岗位,而不是去做项目经理,去做实施,去做售前,去做市场,去做销售等等。很多人尝试了不少工作,但我没有。我知道自己,所以我总是把自己很优秀的方面练的更加优秀,这样我的缺点就非常明显,因为我没有去想着补齐我的缺点,我根本就没有为我的缺点投入任何精力。所以我这个人看起来很简单,同事们都能很容易看出我的优点和缺点,而且我的优点和突出。所以对于老板、对于其它同级同事,某件事需要不需要我的参与,需要不需要我做,大家都很明白。所以,我不擅长的事情从来不找我。这样,我也省去了很多乱七八糟的事情,就有了很多的时间。不少人这个也能干那个也能干,但都干不精,这样的人最容易被别人抽调来抽调去,当然就没有时间了。我只能干很窄的一个领域,所以我在这个领域精进的很快很高很专业,所以我总是能当这个领域的管理者。
5我是个公司赚钱导向的人。我研发产品,率领研发团队,我一直贯彻这样的思路,所以整个研发团队全是这个想法。所以,很多事,一拿这个准则来衡量,这个事到底值不值得做就很清楚了。所以,省掉了不少事。许多人不知道自己要做一个什么产品,只要别人说的有道理没有办法回绝就做,到头来这个软件就成了一个四不像,看着什么功能都有,但这个软件的竞争力在哪里,它的核心模型是什么,很多人回答不出来了。我对产品目标,每个阶段的目标,产品的核心竞争力,我因为有清晰的产品发展战略,所以我都能把这些要素控制的很好。到底做不做,看是否符合利益和当前阶段的目标。
6我这个人不是一个追求完美的人。只要不影响我的任务目标,即使出点小问题小异常,我也不爱管不爱问,就这样过去了。世界上很多事情,其实要成功,只有那么关键的几个点,我深刻的理解是哪几个点。于是我就把控这几个点。只要不是这几个点出现的问题,我都大事化小,小事化了。所以在我手下做事,干的比较轻松,还能达到目标。虽然在有些追求完美的人的眼里看来,每件事情都做的不好。但钱也赚到了,事也按客户要求的进度和质量完成了,而且后续的客户单子也来了,又没有影响未来的客户合同延续。一切关键因素都不影响,我何必花成本和代价去追求完美,让我的人累的半死呢?
7我有个我自己的每日任务列表。我每天要做什么事情,我都随时记录下来,然后一条条的做,一条条的消。我看着不断有任务变灰,就很开心。我清楚的知道我每天要做什么事。
8我要求手下在每天下班前一个小时把今天的工作进展发过来。然后我一一审阅,给些建议。这样,他们明天该怎么做,该做什么,今天遇到的问题该怎么解决,在他们下班前就知道了。这样,他们明天一来了就立即动手,根本不耽误时间,所以工作效率很好。
9有的员工跟我絮絮叨叨讲了很多,反映他所遇到的问题。我听完后往往第一个校验的就是,你到底要达到什么目的。很多员工被反问后,是啊,我到底要达到什么目的。最后一重新审视自己的问题,很快就把问题简化了,问题的症结就找到了,当然解决也就很快了。甚至,弄清楚了目的,发现问题根本不是问题,根本无须解决。省了不少功夫。
10我不喜欢员工像讲故事一样来龙去脉的报告。我总是强调,要1、2、3,这样来。而且你一次报告,不要报告太多的问题,人不应该关注那么多问题。关注多了,就根本理不清,所以也就解决不了问题。先要把自己的头脑清醒了,就焦点关注在前三个问题。等前三个问题解决了,再思考以后的。有些员工向我报告问题,总是拔起萝卜带出泥,一个问题的描述往往会引入另外的问题,然后问题串问题,跟糖葫芦一样。我总是让他打住,就说那是另外一个问题,咱们现在先别管它,咱们先把你现在说的这个问题说清楚解决完,再处理另外一个问题。
11咨询有个方法,就是四象限。在时间管理中也有这个方法,重要且紧急,重要不紧急,紧急不重要,紧急重要。很多人其实是分不清楚这个事情是重要不重要的。我就拿我的目标和赚钱为导向来校验,不赚钱,也不影响未来赚钱,也不影响我当前核心目标,这个事情就不重要。既然事情不重要,那它怎么会紧急呢。不重要,就认为它是紧急的。就让大事化小、小事化了。很多事情,随着时间的消磨,也就那样了。你不去处理它,也就过去了,根本对未来没啥影响。
12有时我指导训练手下员工,但员工听不懂,当然也不会按照我的方法来做。不少管理者见到这种情况,非常生气,还不如自己亲自动手做,本来简单的事情被员工搞了两天搞不定,如果是自己,两个小时就能搞定。但作为管理者,千万不要自己这么做。越这样,越是欲速则不达。每次都是自己亲为亲力,员工闲死,自己累死。我不怕员工做事做不好,关键点出了异常我可能会亲自处理,其他我都能过则过,而一件事情的关键点往往就是两三个。所以,一次做不好,咱们其他的事情我继续指导、重复指导。一次听不懂,我继续在下一件事情方法上指导,直到员工自己也能做的很好。时间,真是一个很奇妙的东西。它能自然改变很多东西。有时候你讲了许多员工也听不懂,时间长了,他也就明白了。不是不到,是时候未到。就是这个道理。
13我希望记笔记,不管看书,还是做事,想到一个很好的点就立即记下来。而且我还经常回顾自己的这些记录,把它们尽量整理成体系和方法,让彼此关联起来。所以我解决问题思考问题的时候,总是有很多参考。而不是从头想起,也不是一遇到什么事情还得重复寻找资料。我这个人由于太专,所以关注的东西也不多。就看自己关注的东西,所以范围窄。许多人没有重点,什么热就看什么,而且积累了一大堆资料,反而后来自己都不看。而我,由于关注的少,所以看的东西自然比别人范围小,看的少也就看的精,而且还定期整理自己的笔记和资料,发现过时了就删除掉,保留下自己持续关注的资料。我发现,不少人有移动硬盘,里面放了很多资料,但真要做事反而一点资料都找不到,跟没有资料一样。
14我喜欢看书和思考问题。过去坐地铁上下班,我都拿本书拿支笔,随时读书和记笔记。一天不读书不总结就觉得空空的,即使上个厕所也要带本书。很多工作中的管理方法很问题解决思路都是这样想出来的,在工作时间就赶快去,节省了不少工作时间。有的人记忆力还不好,还没有做笔记的习惯,还想问我有什么阅读理解的好方法?我的父亲常说:好记忆不如有个烂笔头。其实做笔记不仅仅是个做笔记这么简单的过程,而是在你写字的时候你就会思考揣摩思考,本来你认为很不错的一段文字准备记录下来,在记的过程中你就会想到自己的问题是否能有所借鉴,在记的过程中你就会联想其他同类的信息对比,总结出共性和差异点,在记的过程中你就会发现这段话说的比较片面不像你刚看的那么激动。很多人做不好自己时间管理,就是想做,但只是一个想法,真正做,就觉得这样做太累了,就放弃了。
15我常笑说我是个生活不能自理的人。许多平时工作中的例行事情,我都交给我的团队中的文案女孩处理了。她就相当于我的一个兼职文秘助理一样,帮我处理了许多行政事务。我要去给客户讲某个产品,我给她讲好思路和客户爱听的重点,她就能把方案处理的符合我明天的讲解。比如我要出差,订票订宾馆只要和她讲一下,她就处理了。而且她还会告诉我怎么去那家宾馆,地址、路线图、联系电话都有。我很多事情,都是能不用我处理就不要我处理,我都分配给下属了。
16我从小爱看书,但是家里也没有多少钱买书。我的一个亲戚家里有许多书,但我不能经常去。但只要去了,我就赶快看书。为了看的多,就渐渐养成了能很快把握书中的重点和思路的方法,也养成了如何快速鉴别手中的这本书对自己到底有没有用的方法。所以,现在工作也是,能很快读书,也能很快总结理出思路。对于员工报告的问题,也能很快找到重点和关键。这个性格也是我能留出时间的原因之一。但这个性格很少人有,这个是从小的影响,无法复制,所以我也就放到了最后。
33 灯塔客户-标杆
过去一直做项目,也就是说,没有东西,先有方案,方案客户同意签单,才开始调研、设计、开发、测试、安装、培训、支持。
推产品,做灯塔客户。他们客户之间都互相走动,消息特灵通。先让他们中的有影响的客户先用起来,咱们给其他客户宣传推广的时候就容易的多。而且灯塔客户用的好,咱们的影响力就大的多。
我说去一个星期,但说好了,必须只能是一个星期,不管完成没完成,就一个星期。而且这次去了,还需要跟一位实施经理。你(销售)做项目经理,但你不能越位做产品设计。你负责好客户沟通、协调,上线推动,实施经理和开发人员调度就行。而开发人员不能直接面对客户,所有的客户需求必须由实施人员收集整理,按照咱们正规的实施流程走。
我还不断让他们各自坚守各自角色。那一个星期,我花了大量的精力在不断区分他们的角色,在客户要求和他们三人之间达到平衡,不要让他们三个人都变成需求人员和实施人员。
一个星期到了,销售说他已经签了单子,能不能让开发人员再留一个星期,让开发人员开发利索了再回去。
我说我要看看还剩下多少活儿。于是我让开发人员报了一下工作列表和工作量估计。我也听取了实施经理的实施效果和进度的报告。我也拿开发人员的工作列表找销售去确认了一下看看是否是这样子。三个人都确定好后,我又把期限宽了三天。三天内,开发人员要完成什么工作我都安排好,做完后离开。实施人员按照正规实施流程走,不能无限期在现场实施,否则客户永远会说自己不会。要在三天后安排培训、考试,不能实行目前的一对一培训。
那三天,真是很累的三天。销售要说服客户三天后离开,实施要编写培训课程和考试内容,开发要保证按时完成任务,谁都不轻松,每个人的压力都很大。
终于开发人员和销售回来了。实施经理留在现场,我又派了一位实施培训人员跟进。
当然,实施经理几次着急上火直接给开发人员打电话,但我都让开发人员自己记录下来,排进需求管理工具中。这个过程当然痛苦,稍不加管理,开发人员就成了实施人员和支持人员,说不定为了救火还需要冲到现场。
好不容易,第一家灯塔客户上线验收了。第二家灯塔客户,就是这位实施经理带领培训专员去了,没有跟销售,也没有跟开发。培训专员管培训课程课件制作、培训、考试。实施经理管理好项目进度、需求协调。
开发人员在办公室,有我做管理指导,有专业测试在每日测试,软件质量也得到保证。
走出第一步,千万要把型塑好,千万不要特殊事情特殊处理,否则特殊处理很容易变成习惯处理,最后再也无法回到正常的流程上来了。
想让开发部不变成实施部,第一步很重要。
34 黑衣人-实施人员
每个人实施前的准备,一律统一穿深色西服,里面是蓝色或素色的衬衣,打上深色领带。
用什么样的签字笔,准备什么U盘、用什么样的录音笔、用什么样的指示笔、用什么样的数码相机都统一好。
U盘是为了COPY文档方案的,录音笔是为了录下和客户访谈开会的录音,指示笔是为了培训指示用,数码相机是为了拍下现场实施的照片。
我们还给实施顾问准备了塑料夹子,所有需要现场实施时候填写的现场IT硬件调查表、各个角色调查访谈表、培训签到表、培训反馈表、培训考试卷、验收合同,每家客户一套这样的文档装在这个夹子里,另外,每家客户的产品说明手册也是每家一套。
接下来就是培训每个人的产品演讲能力。首先,大家有统一的产品演讲PPT,PPT有专业的模板,带有公司的LOGO和版权说明,有标题,有目录,有管理思想,有产品截图,有收尾总结。
到一家客户处,就首先把客户的照片拍下,和总经理的合照也要拍下,他们的生产流程也要拍下,客户公司的logo也要拍下,到演讲的时候,要把PPT放上客户的logo,并且修改为专为XX客户制作,并且把PPT日期改为今天。
PPT有规定的演讲时间,每张PPT的演讲时间限制,把整个培训控制在2个小时之内,并且每隔50分钟就休息10分钟,还给演讲培训留下了5分钟的答疑时间。
我们在实施的过程中非常重视实施启动会和实施总结会,让一个实施项目像那么回事,有头有尾。
我们在实施启动会的时候,会让全体到会人合影。会从项目意义、项目常见失败现象、项目组成员建议构成、项目组分工职责与工作流程与汇报流程、项目实施阶段、项目如何验收、项目总结这些方面来阐述。主要是为了让客户老板知道一个管理软件项目是怎么个来龙去脉,不是像安装个电脑安装个WINDOWS操作系统那么简单的,尤其对项目常见失败现象要提前告知客户,让客户从正确的方向上支持项目实施。
我们在实施总结会的时候,会把在整个项目实施过程中发生的培训、访谈、调研、流程梳理、需求收集、开会纪要、验收报告、运行维护建议,都汇集成厚厚的一本,打印出来,装订好夹子,然后郑重的交给客户,并且对比实施前后的效果差异,指出实施过程中的问题。
对于实施过程中的交流,也不要随便乱说话乱侃,即使是和客户一起吃饭喝酒也不能。和客户在一起,永远是工作,不管你是和客户的一个IT人员吃饭,还是和客户的老板吃饭,都不能乱说。人家客户看你,不是单单看你一个人,是看整个公司。
实施回来后,每个实施顾问都还要做总结。
35 矛与盾-利益
我只是一名职业经理人,有始有终做好职业份内的事,让老板的归老板,让职业经理人的归职业经理人,让员工的归员工。员工讨论企业文化和发展战略,老板强调细节和执行力,职业经理人强调股权和控制权,这都不是份内之事。
每天几乎一半的有效时间是在公司渡过的,却过的老不愉快,那生活是多么糟糕。要么你上升,要么你离开,你不走不动到底在耗什么?混日子?
我发现任务不断变更的原因有以下几点:
1需求没调研清楚,需求变更了。
2需求没描述清楚,程序员理解有误了,还得代码变更。
3有突想新的需求认为是很好的功能就生插了进来,但还要按照原有计划进度为目标。
我还进行代码复查工作,来评价程序员对于稳定性、易用性、高性能、可扩展、可阅读、可维护的代码特性质量。
我个人认为:代码复查质量、BUG数量、BUG下降趋势、任务的进度超期或缩短,比较能客观评价程序员的工作态度。如果一个程序员的工作态度不好,这些指标也会有影响。
我们仍然在努力提高自己的商品意识,希望自己交付的产品能够带来更多的销售。我们不希望客户购买产品是因为客户关系、送礼到位才促成的销售,我们希望客户是看重产品占80%的决策意见,这样,我们的研发价值才能体现出来。
不要去抱怨,抱怨丝毫解决不了任何问题。我们要去解决问题,面对什么样的人我们就采取相应的策略去解决,否则问题仍然是问题,而且是困扰我们自己的问题,除了我们自己,没有人会帮助我们。
作为开发主管,是老板的下属,应该有义务去向老板证明自己开发团队的工作。你不亲自报告,你还想等老板细致观察,那老板是请你来做大爷的,还是请你来帮他分忧的?
每做完一个项目,需求收集了多少,BUG测试出了多少,写了多少测试计划,写了多少测试报告,安排了多少任务,每个人的项目总结,厚厚的项目文档,有条理有根据,主动给老板报告,让老板不由得心服口服。
放权,一定是建立在放心的基础上。
尤其到半年会或年终会总结上,这些会都需要每个人发言。这是向公司所有人展示自己的重要机会。写总结PPT,写什么内容,怎么表现的更好看,怎么用数据说话,怎么开场白,怎么说清重点,怎么做个完美的总结,如何注意演讲的手势、仪表、口头语、眼光等等。
开发人员工作有报告有统计有分析有总结,不加班不弹性工作,会开发会写总结会演讲。
绩效评价指标。
管理就是如此,你可以无限去接近,但你永远到不了。
36 地主家也没有余粮了-企业发展
作为我所在的公司,为了扩大营收,不仅在定制项目开发和产品开发上继续发展,还要围绕这两大核心扩展其他的业务,如IT流程梳理、IT数据分析、IT整合、IT数据清洗、数据调研收集外包、IT培训外包、IT实施外包、IT服务支持外包等等。不仅仅在业务上横阔,就是在软件产品上也是纵向扩展,由过去的一个点扩展成一条线,然后不断把线做扎实做宽做深做长,因此也和过去本来是合作伙伴的形成了如今的产品重合竞争。
我们能做到的只能是大量购买了关于该成功模式的所有书籍去研究阅读,摘要细节,分析,推敲。并且在网上尽量搜索到这个企业中的人的文章,搜索到他们的这些其中人的真实感受。
我们会多方论证,大处着眼小处着手,一边踏实谨慎的落实,一边思考如何做才更可行。
都是我们不断的尝试才找到合适的发展之路,大部分的尝试都是错误的失败的,但不尝试,也就不知道走什么路才能找到突破口,在原地等、看,只能每个月消耗工资,消耗上三五个月心里有发毛了,就赶快自己主动想办法该怎么办。所以,有人有这样的疑问,一般都是没有做过企业的一般基层员工这样想。
家家有本难念的经。这山望着那山高。
37 兵临城下-创新模式
企业管理软件领域,出现了新的特点:
一、IT需求由IT部门领导转变成为由业务部门领导。
二、大量的专业IT咨询公司,如IBM咨询、德勤、埃森哲,具有专业的项目管理方法与经验、专业的咨询方法、深厚的行业解决方案业务模型,他们以IT咨询、系统整合、IT流程梳理为名再造IT业务流程,在此过程中会产生许多新的开发、扩展、整合项目。
三、现在大家都在往全球化、互联网化、服务化的方向转型。
现在的趋势就是咨询公司在找软件公司做合作伙伴,而软件公司,也在同样找咨询公司做绑定。
大家都知道长江后浪推前浪,前浪死在沙滩上。早走一步就是先烈,迟走一步就成了落伍者。
38 我就是一个香港导演-关联思维
这就和我们写软件一样,必须要以客户为中心,按照客户的需求来设计软件,要有一种途径和方法与客户做第一手的互动。你越是自己闭门造车,越就远离客户,客户最终就会抛弃你,你只能自己自言自语。
我设计开发软件的时候也是这样,先把第一优先级的,互相关联的功能先设计出来,然后边开发边进行第二优先级的功能设计,这样就保证了设计、开发、测试、文案在同时工作,将串行变成了并行。
所以对于我们开发软件,平时就要注意客户需求,关注客户行业的变化趋势,经常性阅读、讨论、思考。需要有需求管理系统来明确的记录需求,等下一版本开发的时候,很自然就能决定开发的周期、开发的重点、开发的工作量。
习惯决定性格,性格决定命运。
39 方法为什么-责任
责任,你把你的工作岗位有了这种责任,你会发现什么压力、什么艰难,都没有了,你要做的,就是把心踏实下来,不急躁不茫然不失措不逃跑不灰心,然后把身子踏实下来,打好长久战的准备,打好艰苦战的准备,一步步,一丝丝的解决问题。
所以,我能做的就是尽量展现自己的工作效果,让老板看到我的全面价值。
但是我不同意一种做法,就是那句老话:“没有功劳我还有苦劳呢”。
没有功劳,你耽误了客户,你耽误了公司时间,你占用了公司资源,你还要公司发工资,你还想让老板给你加薪水。没有价值,还有成本,还要继续提高成本。我对这类喊苦不出价值的人不予以关怀。
那什么是价值?我个人是这么看的:“为客户带来好处和收入,为公司带来好处和收入”。不管是名声和形象的提高,还是收入的提高,还是成本的降低,还是工作效率的加快,都是价值。
你有什么价值?你的价值值多少钱?你的价值在市场上有竞争力吗?我时常问我自己这三个问题。
责任感,就能产生领导力,就不畏挑战。态度、胸怀就能决定是否有团队能让你领导,是否有人追随你自然形成团队。
但是,每个公司都有机会。机会需要你去创造铺垫,需要你去敏锐的观察是否出现,需要你去快速果断的抓住,甚至有时机会需要你去抢才能抢到。机会,不是给你掉下来落到你的手上砸到你的头的。
我跟他说,其实作为中层管理,有五个点你一定要把握好:“需求、进度、质量、报告、平衡”。
方法为什么?
方法为什么会产生?方法为什么会落实?
借用周星驰的一句话:皆在一个“心”字。