关于组织管理和项目管理的一些见解 - ryda_ncu

时间:2024-01-24 10:37:19

关于组织管理和项目管理的一些见解

1.团队的意义

没有具体负责的领域和事情,就不存在团队。反过来说,团队存在的意义就是为了负责处理某一个领域或一些具体的事情。

长久的团队一定有负责的领域,当这一块领域的事情出现后,自动就落在了这个团队上,负责的团队TL会主动把事情揽过来做。

短期的团队是为了解决某些临时特定的项目,当项目完成后,团队自动解散。例如一些矩阵式架构的临时项目组。

 

组建一个团队或者重组团队,最重要的就是职责的划分和明确。团队管理者需要知道哪些事情是自己的责任。

 

如果一个长期的团队一直都在接受各种各样,各个领域的临时任务,那么这个团队的状况一定会比较糟糕。

团队管理者在没有具体任务的时候就会无所事事,因为他没有负责的领域,也就不会做这个领域的准备工作,做训练,提高效率提高技能。当没有战事的时候也就不会像有阵地的队伍会去不断的做战前准备,挖壕沟。

 

2.对团队给出目标并信任团队的管理者

你若信我,我便不辜负。所谓用人不疑,疑人不用。如果信任存在问题,团队也就没有一往直前的勇气了。这个道理大家都懂,但是多数都做不好。

而给出明确的目标,是需要领导和团队达成一致的必要条件,并且这是前提。对团队管理者来说,要坚持没目标,不行动。

一只乱串瞎行动的团队,会让团队成员觉得很没劲。

 

领导给团队细节目标,不是一个好做法。我们对团队管理的时候,应该先和团队达成一致的项目目标,大家的目标一致了,再说后面的事情。

而直接给细节目标,可能会误导项目目标。大家对细节的理解不一样,倒推出的项目目标就不一致了。

 

3.领导对团队在任务过程中的监管

如果有精力,领导可以对团队在任务执行过程中进行监管。目标一致了,那么团队在做事情的过程当中,领导的视野更广,角度更多,更可以发现一些问题。

和团队管理者去沟通这些问题,不管是执行前,还是执行中,或者执行后。和团队管理者探讨自己觉得有问题的做法,讨论是不是偏离了项目目标。

如果领导自己没有精力或自己不能确定这样做是不是对的,那么参考2.a,信任自己的团队管理者。

 

领导自己不可能什么都懂,不可能有那么多精力,所以要减少瞎指挥,让自己的团队管理者能够成长。

 

4.目标管理

前面也一直在提目标,公司有战略目标,落实到团队是项目目标,然后拆解到个人是具体的任务目标或者行动目标。

有了目标,就需要有结果。目标很重要,结果也很重要,结果是不是符合目标的评价也就很重要。

领导给出项目目标后,需要去核对项目目标是不是完成(这里不是说做了就好,而是要看是不是达到了目标描述的效果)。

只有不断的去核对目标的完成情况,才能发现不足,才能改进。

 

如果一个目标给出后,不对结果做评价。那么长此以往,执行力会不断下降。

 

4.项目管理的方式

团队OK,有明确的职责。

团队管理者也OK,互相信任很努力,能力也过得去。

目标管理也OK,大家都知道目标在哪里,一起在努力。

这个时候基本的管理已经没问题了,再要提高效率,就看项目内部的管理方式了。

 

我们知道做事情,有一种PDCA的方法。

P:做计划

当一个项目或一个任务来了,第一步就是做计划,计划是在把目标分解成具体的事项,并且有前后顺序,依赖关系。

比较顺的做事情,当然效率就高。事情有一搭没一搭的做,一会发现少了这个少了那个的,就容易忙中出乱,返工,效率低。

计划也不是越细越好,因为有很多行动计划的内容,是在做的过程当中变化产生和修改的。

这里也体现的是项目管理者的能力,能把事情想得清楚,计划就会比较靠谱,想不清楚可能就没计划了,或者计划只是做做样子,写完之后就不再看。

 

D:执行

任务的性质不同,执行过程中的方式也不同。

事务性的:去买包烟,准备一台服务器。这些事情一眼就能看到结果的会比较好处理。

创造性的:比如做一个产品,做一个系统。这里就涉及到软件工程的方法,要做很多的任务分解和分派。

涉及到需求调研,要做需求分析设计,要做系统的规划设计,数据库设计,概要设计,详细设计,编码,测试,联调,部署,维护。

 

互联网产品、软件产品、定制软件项目的做法都不一样。

需求明确和需求不明确的做法也不一样。

团队成员能力不同(例如有没有好的测试;有没有好的的设计能力的人),做法也不一样。

 

越是复杂的过程,越是要有一些规范流程,即使牺牲少量的灵活性。

越是复杂的过程,越是考验设计能力。

 

C:检查

事情做了,就要检查结果是不是符合预期目标。项目管理者要不断检查,不断检查,不断检查。

 

A:改进

如果发现了问题,就要改进。

改进会涉及到计划的改进,做事方式的改进,任务安排的改进。

并不是完全执行了最早的计划就是好的。