初识管理

目录

技术人员看管理

团队背景

对管理的认识

结束语

---

技术人员看管理

作为一个标准的软件工程毕业的人，课本上从未学过管理方面的课程，也没看过管理相关的书。在没开始管理工作之前，对管理的理解只是停留在自己上级领导每天的工作日常，很彻底的诠释了"不在其位，不谋其职"，如果把IT管理者比作是带兵打仗的将军或者元帅，那技术人员就是士兵或者先锋官，而我当时就是不折不扣的士兵，偶尔充当先锋官。曾经根本没体会到管理工作的难度和玄妙，对管理者的印象：排计划、排座位图、约人聊天、组织开会、采集进度、汇报进度、整理或做成文档、说官话画饼子，自己没有具体任务，但是整天在电脑面前忙叨，也不知道在忙叨什么。更大一级别的管理者就更闲了，连电脑都用的少，一般能看见的时候就是在溜达，画更大的饼，或者见客户，或者是出去不知道干什么。总结一句话：拿着比较高的薪资，做着些组织协调、"耍嘴皮子"的活。这对于一个自认为武艺超群的士兵来说，遇到这样没有"实料"的将军，往往都是嗤之以鼻的，认为这样没有"硬核"的工作没什么意思。当初只想着或成为团队的"武术"NO.1，受人敬仰，或成为孤傲的侠客，笑傲江湖。在此我对我曾经的无知和武断的结论，郑重的道歉。

团队背景

时过境迁，经历过6年职业生涯的洗礼，一次偶然的机会有幸开始管理岗位生涯---初创公司的项目负责人，与公司老大直接对接。当初公司老大第一次找我谈话赋予职责的时候，虽然本着对工作尽心尽责的态度，但是当被赋予管理权限的时候，内心深处还是有些不屑的，毕竟我的目标一直是要在技术上做最"横"的那个人。老大看出我的些许不屑，也没多做解释，只是笑着说了一句：其实管理好一个团队真的很有“技术”含量。当时没多想，只是考虑以最厉害的技术来服众，不过现在想想当时的想法也挺可笑的。由于是初创公司，当时职责包括搭建团队架构和技术架构、招人组队、技术选型、样例开发、编程规范、框架模式、未来技术演变、确立团队目标、对接客户、计划、把关、编写各种文档样例、协调各种资源。算是管理、业务、技术一手抓，老大把项目接下来后，基本上一切事物由我来安排。这样经过两年时间，经过几次进出的人员变动后，团队算是初具基础。啰嗦了这么多，并不是夸耀自己多有本事，一个初创团队，做了几个项目，也没什么好骄傲的，只是把前提描述详细一些，以便下面写管理上的一些感悟的时候，有良好的背景呈现。

对管理的认识

以下均为个人粗浅理解，不代表任何组织，无意发起任何争端。

到底什么是管理呢？引用百度的概念：管理是指一定组织中的管理者，通过实施计划、组织、领导、协调、控制等职能来协调他人的活动，使别人同自己一起实现既定目标的活动过程。总结一句话：用最合理的方式实现目标。

百度上的概念从文字表达上看起来简单易懂，但实际对于"管理"来说还是比较抽象的，因为管理的概念太宽泛了。不过，从中可以抽取到管理的一个点：管理是一种"过程"，实现目标的过程。如果目标实现不了就不是管理了吗？当然不是，所以简言之，管理是对如何"做人"与"做事"的规律、方法。了解完概念之后，就很容易的引申到管理的对象：人和事， 也可以扩充成资源。人指得就是团队中的人员，对人员的管理主要是对其思想和行为的管理，思想是基础。事的概念就比较宽泛了，时间、金钱、地点、行为等都是"事"的范畴，且事与人如果协调好是相辅相成，相互促进，协调不好就会进入恶性循环，最终"内存溢出，系统崩溃"。管理过程个人拙见可分三个阶段：自我管理->人员管理->事件管理。无论是管理什么，都是以人为基础的，是人的行为，而产生管理行为的这个人，我们可称作为管理者。管理者想管理好团队的人和事，首先应该做的就是管理好自己，管理并不只是靠语言的叮嘱和立下的条约，最根本的是需要管理者以身作则，一个合格的管理者可以宽松要求团队其他人员，但一定要严格要求自己，特别是细节上，比如：上班从不迟到不早退，不主动扰乱秩序，不背后议论人和事等等。毛泽东主席在1945年与蒋介石重庆谈判时，会议上连续几个小时不抽烟，对于一个平时烟不离手，嗜烟如命的人来说是何等的定力。领袖是国家的管理者，也为我等做好表率，一个合格的管理者要有严格的自我管理能力，想要自然的散发出这种表率，不仅需要在工作中的自律，更需要把自律根植于生活和习惯中，这样从根基的自律也会让一个人从根基上得到提升。自律性差的人能成为好的管理者应该是很难的。先管己，后管人，因为人是事的执行者，所以第二阶段是对团队人员的管理。对人的管理前文提到过主要是对其思想和行为的管理，核心是思想。有了正确的思想才会产生正确的行为，管理者能让团队人员按照正确思想去执行，首先要做的是自己认识到什么是"正确的思想"，也就是明确团队目标。其次，就是管理中的重中之重：沟通。一个团队的发展，一个项目的成功都离不开有效的沟通。把正确的思想灌输给团队人员需要有效的沟通，一个称职的管理者需要强大的沟通能力，对人管理的阶段，沟通是核心。实际上不仅仅需要管理者需要沟通能力沟通技巧，团队每个成员都应该锻炼沟通能力，有了良好的沟通能力就使成功变的事半功倍。没有沟通等于瞎子点灯，没有沟通就会产生"信息孤岛"，导致做成与实际不一致而偏离正轨。初创团队这两年期间，项目做成中有大约60%的问题的根本原因都是因为沟通不足导致，大约20%原因是因为目标不明确。沟通是一切的基础，做好沟通才能使团队像一个庞大的机器一样各部件充分关联，共同前进。有了良好的沟通和明确的目标后，第二阶段还需要形成团队的凝聚力。凝聚力是个比较抽象的概念，且与人密切相关，凝聚力就是团队对人员的吸引力，而通过人员对吸引力的认可，来达到团队潜能的发挥。由于初创团队人员不太多，作为管理者，本着带兵带人心的理念，对团队人员在纪律上几乎不做要求，企业是创造价值的地方，而发自内心的，没有压力的工作是能让团队价值最大化的一个重要因素。所以平时跟大家完全打成一片，并没有明确谁是领导谁是下属的感觉，只希望大家能精诚合作，共同把“事”做好。纪律上靠自觉，请假人性化，积极协调安排计划，尽量不制造高压；以技术为本，持续丰富新技术融入到项目架构体系，绝不满足现状，干到老学到老为客户提供最优质的产品。这一切的团队模式和目标需要团队人员的首先就是不甘平庸的上进心，时刻保持积极态度，哪个抱着“混”的心态就不用来了，并且做到对团队人员工作要求的尽量满足；其次需要团队人员有一定自觉性，也就是培养团队人员的自律性，管理者从不强调纪律，需要自觉，不过如果纪律过分会在薪资奖金上予以惩罚体现；最后就是需要团队人员“担事儿”的能力，“担事儿”不是担责任，责任自然由责任人来承担。需要团队人员在平时有个轻松愉快的工作环境的同时，在遇事儿的时候勇于承担任务，不逃避，不放弃，在关键的时刻起到作用。真的特别感谢公司BOSS对我的信任和对我管理理念的认可，对团队前期没有盈利情况下豪放的薪资的付出(加班按法定加班费给，对于初创团队来说很难)，经过将近两年时间，筛选出满足要求的优秀人才，打造出一个工作氛围轻松，遇事能顶事儿，凝聚力强大的团队。所以，来到团队的人员能留下没被清退的人都没有离职，原因跟马云总结的一样：因为有法定加班费和较丰厚的奖金，金钱上颇具竞争力的；对团队人员工作要求尽量满足，想尝试做设计，或者做前端或做后端，部署服务器等随时欢迎(心没受委屈)，当然能做到这些需要强大的技术支持，项目容错能力，充分的风险管理能力。这在特别是团队初期的时候，走了太多的弯路，挖了很多大坑，作为管理者，我有不可推卸的责任，不过现在也算苦尽甘来，沉淀已久且前期疲软的团队，到现在终于初现不俗的战斗力，毕竟团队的构建一直本着"从长远做打算"的理念。接下来就是对管理“事”的分解，宽了不讲，就以软件项目为例子，做个粗浅的总结：

对“事”的管理基本上是管理者的作业内容，以管理者为核心统一协调沟通各种人力、物力、时间等资源。用B TO B项目举例，角色暂且定义为：乙方老板、乙方项目经理、乙方员工，甲方老板，甲方项目经理，甲方员工。如果甲方公司想完成本公司两个部门信息化建设作为整个信息化建设的第二期，期望六个月时间完成。得到比较笼统的消息后，从乙方项目经理的角度，其实在继续与甲方公司聊细节之前，应该搞清楚一件很重要的事：本次项目的成功标准是什么？这里所说的成功标准当然不是指"验收"成功，如果"验收"过不了，那干脆就别继续做项目了。。。这里说的成功的标准其实是老板的意图，这里是从乙方项目经理的角度来说的话，那这个"成功标准"就是乙方老板的意图，因为乙方老板才是你的老大。所以，老大的真正意图是左右项目怎么做的关键，老大可能是想扩展新客户，或可能是想为以后做推广产品打基础，或本次就是想赚钱，甚至本次就是想试水等等；当然各个意图不同情况下，也需要掌握老大的底线，因为凡事都有一个"度"。掌握了自己老大的真实意图也就有了最根本的目的，之后项目一切的开展都将围绕这个目的。接下来就进入了ERP类软件项目的周期，项目立项阶段->需求调研阶段->项目计划阶段->项目设计阶段->项目开发阶段->项目测试阶段->验收，再根据各阶段进行细化，每个阶段之间可能有穿插的细节，这里硬性流程没有什么好说的，做过软件项目的都应该了解。不过，越靠前的阶段需要越明确，因为前阶段的基调会严重影响后续阶段的结果，如果等到测试阶段发现立项阶段方向上不正确，那很可能是无法挽救的。所以这就需要项目经理决策的重要性，而这决策的基础就是沟通和理解，充分的沟通、理解后反复的确认、及时的记录及确认，是把握正确性的基础。作为项目经理，一个项目实际工作流程的核心人员，首先要有优秀的沟通能力，沟通上做的不好就会使项目的具体做成"跑偏"，"跑偏"就会产生时间等成本，影响项目规划。其次要有优秀的心里素质，项目经理作为核心人员，会和所有人员打交道，会遇到各种各样不可预见的问题，而这些问题都需要由你去解决，这就需要有优秀的心里素质作为基础，如果项目核心"崩溃"，项目的推进可想而知。最后必须有风险意识和担责精神，因为一个项目涉及因素很多，基本不可能按照预想的顺顺利利的实现，提前想好各种风险，做好风险管理，并准备好一旦发生问题，敢于承担责任，努力挽救，使损失降到最低；这里有个小建议，为了给风险做好基础，可以把计划做成三份儿，一份给团队人员看，这份计划在合理范围内时间最短，让完成进度与项目真正周期有尽量大的缓冲时间。一份给甲方看，和甲方谈好的时间节点，这份儿计划是时间最长的计划。一份给乙方老板看，这份儿是最真实的项目计划，时间介于前两个计划之间，可谓是留下的二级缓冲。而项目的成功的一个最最基础的就是前文提到的团队人员凝聚力，如果连你本队人员都不能众志成城，就相当于一棵大树从根的位置坏掉了，那将是灾难性的。而项目过程中，甚至每个项目的做成中基本都会遇到需求变更的问题，互联网和软件服务类项目流传一句话“唯一不变的是需求一直变”，这并不是空穴来风，需求变更是必须经历的。而面对需求变更项目经理需要从多个角度考虑，这个多个角度包括乙方老大的容忍度，甲乙双方员工的心态，立项阶段的规定，已做好的记录(必须留好证据)，对项目整体的影响，花费的各方面成本(时间、人力、物力)，甚至甲乙双方老大的处事方式等等。以上众多因素考虑清楚后，如何与客户沟通，最终决定如何面对变更。需求变更时候，大多数处理的是软性的“事”，大多情况都会"商量"着来，挑选最合理的解决方式，这也符合我们所说的"中庸"之道。其实管理页可以按照PMI所写内容“深度效仿”，但在国内更应该以实际场景为主，像本次例子所说，需要做成甲方的两个部门的系统，在项目立项阶段就需要考虑这两个部门的背景、关系、关联，及这两个部门和其它部门的关联(特别是人力部门)。如果乙方完成本次项目的部门也是大于等于2个部门，就需要提前协调好各部门完成范围，做好规范，尽量避免产生"部门墙"，大家应该都不想看到在还未开始与甲方对接之前，自己内部先乱成一团。关于项目管理该讲的，该注意的有太多太多，以下做个简单的使项目"死掉"的总结（包含真实经历的血泪）：

1.不可达到的目标

目标制定的好高骛远，不切实际，只求高大上。让领导看着开心，能不能实现再说，做到这一点需要甲方拍脑袋，乙方配合忽悠。

2.目标不清晰

乙方自己目标不清晰，对这次项目的没有目的性。甲方目标不清晰，让乙方先"看着做"。做成范围不清晰，导致做了很多无用功或必要项未做。

3.无法执行的计划

这个不用多说，本来一个页面的后端功能员工甲需要4天完成，计划里只写1天。。。

4.缺乏项目资源

口袋里只有路边摊的钱，妄想吃满汉全席。。

5.失控的变更管理

今天说要做A，明天说做B，后天做C，大后台又说A好，项目需求变化频繁，自己脑补开发人员与产品经理的互殴画面。

6.缺乏态度及立场

过分迁就客户或从不迁就客户，如果项目利益相关方较多的话，就会死的更快。

7.无能的团队建设

团队人员经验不足，人手不足，职责张冠李戴，人员流动频繁，经常分散团队人员注意力都会严重影响项目。

8.赏罚不清

评自己喜好奖罚，不能公正、公平、公开的赏罚。难以服众的赏罚----致命。

9.缺乏风险管理

没有风险管理意识，永远在问题爆发时，客户投诉时才救火，习惯"擦屁股"，执行力过于被动。甚至感觉客户意见是故意找茬。

10.经验不足的乙方PM

误解客户需求，理解错误意图，花钱快，进度慢，质量差，人心涣散。

11.经验不足的甲方PM

一个不合适的甲方PM，对项目破坏力是摧毁性的，可以毁掉乙方所有向成功的努力，而你又无权换人。

12.业务背景的特殊性

如果选择的用户人群是对项目接收慢，或干脆不愿意接受新规则的人群，那将使项目做成再完美，也变的毫无意义。

结束语

个人理解，各种成本里，时间成本真的弥足珍贵，因为"时间"是真的不可再生资源，而团队人员更是“根骨”。开始管理生涯后，学到了很多，锻炼了很多，被冤枉的很多，无奈的也有很多；不过这都是成长，都是人生不可或缺的一部分。管理管过程，带兵带人心，干到老，学到老，不忘初心，方得始终。