《党委会的工作方法》实践和总结

前言 去年国庆期间,看完了这本小册子,从中知道了很多管理团队上面的方法,当时自己的评价是:“完全值得每日一读”。但是看完也就看完了,并没有特别重视。这一段时间在团队管理上面,遇到了一些问题,想起这本小册子,温习了一下,顿觉发人深省,不由得感叹,之前毫不在意,如今逐字学习。行有不得,反求诸己,所以打算每一个工作方法都结合自身经历进行分析、总结和反思,希望自己在这方面能有所长进。 一、党委书记要善于当“班长”。 党的委员会有一二十个人,像军队的一个班,书记好比是“班长”。要把这个班带好,的确不容易。目前各中央局、分局都领导很大的地区,担负很繁重的任务。领导工作不仅要决定方针政策,还要制定正确的工作方法。有了正确的方针政策,如果在工作方法上疏忽了,还是要发生问题。党委要完成自己的领导任务,就必须依靠党委这“一班人”,充分发挥他们的作用。书记要当好“班长”,就应该很好地学习和研究 如果这“一班人”动作不整齐,就休想带领千百万人去作战,去建设。 一个人的能力不管有多厉害,他的时间和精力终究是有限的,单打独斗可以做成一些事情,但做不成大事,要做大事,就需要借助众人的力量,所以他需要一个团队,这是前提,而这之后,他想要把事情做好,这是结果,为了这个结果,他需要把团队带好,这是过程。我们常说,兵熊熊一个,将熊熊一窝,决定团队成败的最重要的人永远是团队负责人。文中提到的“正确的方针政策”和“正确的工作方法”,刚好对应上了团队负责人最重要的两个工作——目标和计划,目标是要做什么?计划是怎么做?然后重点来了,你知道做什么,也知道要怎么做,那么,你要怎么样才能让别人按照你的想法去执行呢?就因为你是领导么?就因为你官比较大?不是的,根本不会有人吃你这一套,换位思考,我也会这样想,如果这些事情对我没有好处,甚至还增加我的工作量,我干嘛要认可你说的,别跟我提什么为了团队的发展,为了团队的将来,跟我有什么关系,将来的事情谁说得准,多一事不如少一事,而且一将功成万骨枯,到时候出事情了我背锅,有成果了你摘桃子,我不见得落得什么好处。 做什么?怎么做?怎么让他做?通过职权施压,短期可能会有效果,但是长期来看,这是不健康的方式,迟早会有问题。要让别人心甘情愿去做某件事情,我觉得可以从两方面入手,一是领导力,领导力并不等于职权,它是被他人信任的体现,是需要日常去积累的;二是从人性是自私的这一点入手,只有摸清对方工作的诉求,才能对症下药,灵活调整应对方案。 二、要把问题摆到桌面上来。 不仅“班长”要这样做,委员也要这样做。不要在背后议论。有了问题就开会,摆到桌面上来讨论,规定它几条,问题就解决了。有问题而不摆到桌面上来,就会长期不得解决,甚至一拖几年。“班长”和委员还要能互相谅解。书记和委员,中央和各中央局,各中央局和区党委之间的谅解、支援和友谊,比什么都重要。 这就是项目管理制度执行过程中,之所以会出问题的原因,很多事情没说明白,似是而非,让同事有太多的选择余地,那大家肯定选择对自己有利的东西了,不会照你期望的流程执行。因此,必须假设人性本恶,先考虑最坏的情况,然后再采取行动,否则,永远无法解决问题。仅仅在群里发布是不够的,很多人不会重视,必须要在会议上,对所有规定的事情进行详细说明和解释,定好奖罚机制,达成共识。 三、“互通情报”。 就是说,党委各委员之间要把彼此知道的情况互相通知、互相交流。 信息的同步很重要,作为管理人员,也不要仗着掌握一些重要信息,然后拿捏其他同事。消除信息差很重要,传达是否及时,传达是否到位也很重要。 四、不懂得和不了解的东西要问下级,不要轻易表示赞成或反对。 有些文件起草出来压下暂时不发,就是因为其中还有些问题没有弄清楚,需要先征求下级的意见。我们切不可强不知以为知,要“不耻下问”,要善于倾听下面干部的意见。先做学生,然后再做先生;先向下面干部请教,然后再下命令。 我们做出的决定包括了下面干部提出的正确意见,他们当然拥护。下面干部的话,有正确的,也有不正确的,听了以后要加以分析。对正确的意见,必须听,并且照它做。中央领导之所以正确,主要是由于综合了各地供给的材料、报告和正确的意见。如果各地不来材料,不提意见,中央就很难正确地发号施令。对下面来的错误意见也要听,根本不听是不对的;不过听了而不照它做,并且要给以批评。 管理带人,以前还觉得不就是带人嘛,有什么难的,经历过一些事情之后,会有敬畏之心,而且要学的东西太多了,没办法面面俱到,很多技术细节没办法像之前那样深入,所以会觉得心里没底。很多时候,你只能听取在这个方向深入的同事提出的意见,这个时候就遇到考验了,你害不害怕手底下的人比你厉害?说实话,我恨不得团队里每个人都比我厉害,这样我工作更好达成,至于担心会被替代,其实也要明白,自己肯定是具备他人没有的优势,才会被安排做这样的工作,哪有那么容易就被替代的,即便如此,那只能说明自己就应该被淘汰,谁让你不持续成长呢,总之,我很乐意接受这种挑战,混吃等死有什么意思。 五、学会“弹钢琴”。 党委要抓紧中心工作,又要围绕中心工作而同时开展其他方面的工作。我们现在管的方面很多,各地、各军、各部门的工作,都要照顾到,不能只注意一部分问题而把别的丢掉。凡是有问题的地方都要点一下,这个方法我们一定要学会。 有时候会觉得,如果只是带一个项目的话,不会有什么难度,但是带五个项目的时候,就开始觉得有点力不从心,我一直在想问题出在哪里,为什么总觉得没有做好呢?其实,问题就在于把五个项目作为独立的个体来看了,其实,它们是相互关联的。看似多个项目,其实是一个项目,然后那五个项目只是五个模块罢了,各个模块又有相应的负责人,你只需要管理好五个人即可,而不是全部的十几个人。 六、要“抓紧”。 就是说,党委对主要工作不但一定要“抓”,而且一定要“抓紧”。什么东西只有抓得很紧,毫不放松,才能抓住。抓而不紧,等于不抓。伸着巴掌,当然什么也抓不住。就是把手握起来,但是不握紧,样子像抓,还是抓不住东西。我们有些同志,也抓主要工作,但是抓而不紧,所以工作还是不能做好。不抓不行,抓而不紧也不行。 这一点就是我要写这篇文章的原因。 在项目管理初期已经制定了管理制度,但执行过程中没有及时跟进,这就导致一些同事不遵守规定,比如今天不写项目进度会议记录,没有人提醒;明天不及时更新项目计划,也没有人提醒。这样一试探,便越发随意了。 那为什么不及时提醒呢?其实就是自己生气了,觉得说了那么多次,为什么总是这样?就开始不管不问了。这个是不对的,无论发生什么情况,都不应该赌气去做事情。无论问题大小,作为团队负责人,你都是第一责任人,应该对所有问题负起责任。不能被动地观望,任由问题扩大,到那时,已经为时已晚。 任何策略的制定都是为了实现特定目标,而不是为了制定而制定。重要的是做得好不好,而不是做得多不多。如果事情做得不好,再彰显自己怎么用心努力也是无济于事,不要掉进“没有功劳,也有苦劳”的陷阱,结果好就是好,不好就是不好,不要去争取这种施舍。 抓而不紧,等于不抓。如同朝鲜战争一样,打得一拳开,免得百拳来。当时不打这一仗,不是后代也要打的问题,是以后连跟人打仗的资格都未必有,只有挨打的份儿。 七、胸中有“数”。 这是说,对情况和问题一定要注意到它们的数量方面,要有基本的数量的分析。 在任何群众运动中,群众积极拥护的有多少,反对的有多少,处于中间状态的有多少,这些都必须有个基本的调查,基本的分析,不可无根据地、主观地决定问题。 有一次在向上反馈的时候,我说有些同事任务交叉得有点多,可能有点问题;还有一次,我说项目管理系统里待验收的任务,验收是否真的落实了?感觉很多人看都没看,就随便点了一下,算是验收通过了。然后上面问,有数据么,任务怎么交叉了?哪些任务是应付验收的?然后,我就懵圈了,因为我答不上来。 这两件事情,我现在想起来还是很生气,我不至于犯这种错的,还是平时太想当然,太掉以轻心了,一些细节不够重视,才在这种事情上栽了跟头。所以我回去写了检讨书,狠狠反思了一下。 没有调研就没有发言权,任何事情下结论之前,需要做下调研,依据事实和数据来判断,不能空口无凭。这部分在《毛选》中就有具体的处理方案,可以细读一下的。不应使用“想当然”、“凭感觉”来解决遇到的问题,没有数据作为佐证,就无法保证做出正确的判断,再者,你有的只是你的感觉,是很难让他人信服的。 在向上管理里面,任何需要反馈的问题,都应该先想清楚,而不是想当然、凭感觉,应实事求是,基于数据说话。 职责越大,就越需要谨言慎行,话不能乱说,事不可乱做,你不严谨的言行,容易留下后患。 八、“安民告示”。 开会要事先通知,像出安民告示一样,让大家知道要讨论什么问题,解决什么问题,并且早作准备。有些地方开干部会,事前不准备好报告和决议草案,等开会的人到了才临时凑合,好像“兵马已到,粮草未备”,这是不好的。如果没有准备,就不要急于开会。 开会之前,提前在群里发一下通知,这样其他同事可以安排好自己的时间,特别是跨部门协作更应如此,然后要讨论任何问题,不应该自己想都没想,就召集大伙召开会议,要准备几个方案,理清楚各方案利弊,然后自己的倾向方案是哪个?为什么?如果做到这些,可以说已经具备召开会议的条件了。 九、“精兵简政”。 讲话、演说、写文章和写决议案,都应当简明扼要。会议也不要开得太长。 会议前准备充分,那么开会时间就不会那么长,要明确重点,最近遇到的问题是,有同事经常开会就是3个小时,虽然适当拓展话题也是蛮好的,不怕你话多,就怕你没得讲。但是每次都这样也有点挺不住,因为还有其他项目要过进度,一天的时间很快就没了的。有些讨论的内容,其实是发散性的,可说可不说,也可以会后在座位上进一步讨论,所以,为了不打击对方的积极性,也就没在会议上去打断对方,只能自己先想办法,怎么解决这个问题,我就把会议安排在上午,然后还剩下一个多小时下班吃饭,就有了会议时长限制,不会总是开太久了。 十、注意团结那些和自己意见不同的同志一道工作。 不论在地方上或部队里,都应该注意这一条。对党外人士也是一样。我们都是从五湖四海汇集拢来的,我们不仅要善于团结和自己意见相同的同志,而且要善于团结和自己意见不同的同志一道工作。我们当中还有犯过很大错误的人,不要嫌这些人,要准备和他们一道工作。 “把朋友搞得多多的,把敌人搞得少少。”其实这一句话就说完了,但知行合一一向都很难,在工作中,如果某人给你留下了不好的印象,你心里就会给他贴上标签,这样就很难相对客观地去判断一些事情,到最后工作没做好,吃亏的还是自己。 我一直秉承着只要认真工作,哪怕笨一点也没关系,能帮的一定会帮,大家都是普通人,集思广益,总能找到解决问题的方法,但是你不用心,投机取巧,推诿甩锅,还耍小聪明就忍不了了,不要觉得自己做什么别人都不知道,怎么可能呢,没人是傻子,更不要说领导层的都是人精,谁不知道你心里那点小九九? 所以,我特别生气,无法理解这种人,啥好处都让你拿了,其他人汤都喝不上,还要替你背锅,加上一份工作,想做就把它做好,你觉得不爽不满意了,所以才消极怠工,那走就是了,找到你觉得更好的工作,然后会变得更加积极主动,认真努力不是更好?在这浪费时间有意思么?还是说你本来就是这样的人,这个只是借口而已? 没有人喜欢工作,但至少有点契约精神,加上资本是逐利的,任何人都可以被替代,不说显得自己多职业,至少为了自己,好好打磨自己的技艺,而不是浪费时间。 管理带人就是没办法可以随意爆发自己的情绪,有万分委屈该忍还是要忍,要不然成何体统,内心恨不得把对方头都拧断了,但还是要心平气和地去沟通,因为发脾气不能解决问题,只会让事情变得更糟糕,至于换人,之前我也觉得直接换人不就好了,但是现在又觉得,并不是什么事情换人就可以解决的,一定是自己哪个方面做得不够好,才会变成这样,没有人一开始就是这样的,要不然当初面试就不会招进来,就当是修炼自己的度量了,可以想象自己那些伟大的抱负,上升到更高的维度,就觉得当下这些都是小事情了。谁身上都有缺点,谁身上都有长处,容人之所短,用人之所长。 十一、力戒骄傲。 这对领导者是一个原则问题,也是保持团结的一个重要条件。就是没有犯过大错误,而且工作有了很大成绩的人,也不要骄傲。禁止给党的领导者祝寿,禁止用党的领导者的名字作地名、街名和企业的名字,保持艰苦奋斗作风,制止歌功颂德现象。 其实,说到底大家都是打工的,谁比谁高贵呢?出了公司谁认识你,所以根本没什么值得炫耀或者颐指气使的。 之前有一次安排加班,有个同事已经连续加了两天了,事情还没有做完,最好当然是能加班了。但本着人性化的原则,就安排先休息了,然后其他骨干同事就说,以前我们都有过熬夜通宵加班的,这个算什么,继续安排就是了,没必要和他解释那么多。然后我说,该说还是要说,你安排先休息了,对方不一定就真的去休息,你不安排休息,对方不一定就真的继续加班,人在工位,但是心里不情愿啊。我相信只要懂得换位思考,体谅他人的难处,事情一定会往好的方向发展,但是这个方式还是要看人,没有任何一种方法能够适用所有人,管理就是见人说人话,见鬼说鬼话,千变万化,无穷无尽。 后来,我还是和那个同事沟通,说连续加班挺累的吧,还是先休息下,然后再继续加班吧,然后他也没休息,继续先忙完要紧的事情了。 言归正传,其实这个点,也是我想说的,很多领导都会说,我每天那么用心工作,天天熬夜,为什么你们都不能用心一点?其实他不明白,屁股决定脑袋,位置都不一样,职责肯定不一样的,你拿这个来要求下属,下属只会笑话你,换我做领导,我比你还能卷,睡在公司都行。 我觉得以上就是一个骄傲的例子。 结语 管理之所以被称为一门艺术,是因为人性是自私的,人性是趋利避害的,人性是好逸恶劳的,人性是变化的,我们要知道在变化中求不变,又要在不变中求变化,一切都要见机行事,没办法像套公式一样,简单粗暴地解决遇到的所有问题,而是使用一种妥当的方式,让他人能够接受的方式去安排和落实工作,并拿到成果。管理不是目的,结果也不是目的,好的结果才是。 没办法生搬硬套书籍里的理论知识,只有不断地总结犯过的错误,才能从中吸取教训,并用于指导我们接下来的管理工作。

2024-04-29 · 1 分钟 · 58 字

项目管理问题探讨与解决方案

第1章 写在前面 你可能是项目中的开发能手,最佳情况也只是能保证自己,负责开发的功能没有问题,其他的你是无法保证的。哪怕你承担了项目中全部的开发工作,测试阶段、验收阶段和发布阶段也是需要其他人协助的,假设这些你都可以自己完成,而且也做得很到位,但要是需要该项目在很短的时间内交付,想必你就没有办法了。一个人的能力不管多高,人的精力终究是有限的,任何事情能够得到一个比较满意的结果,都离不开众人的努力,对于项目而言也是如此。 这本小册,打算将多项目管理推进过程中,反馈出来的问题进行分析和提供解决方案,不一定全都是对的,算是自己的一些反思总结和心得分享。本小册计划分为意识篇、能力篇、方法篇、提升篇和附录,意识篇主要是项目管理意识方面的探讨,意识是这一切的基础,意识没有到位,后面的其他方面做得再好,也是有局限性的,就像一棵大树,树根没有长好,枝干树叶的成长也是有限的。因为意识很重要,所以放在前面。能力篇主要是项目管理应该具备哪些能力的探讨。方法篇主要是项目管理方法上面的探讨。至于附录,是一些有助于提升项目管理能力的书籍摘要。 第2章 意识篇 2.1 项目管理的意义 我们探讨项目管理的意义,只会是关联密切的那部分,至于关系到公司成本投入等等问题,虽然是不争的事实,但是对于我们来讲,有点遥远,就不再过多拓展。对于项目负责人而言,他需要明白项目管理的意义,根据我个人一些经验,总结了以下三点,分别涉及到一个项目完整的周期,开始、过程和结束。 一致性 目标一致、步伐一致、项目中的全体成员都需要知道,我们的目标是什么?将全部精力投入到达成目标的要事上面。在这个过程中,间接实现了项目降本增效,还有提高团队的凝聚力。 及时性 项目进行过程中,无时无刻都在发生变化,不管是项目制定的计划,还是遇到了业务或技术难点,及时了解到当下的情况,尽快解决问题,可以避免项目进度受阻。 高质性 项目完成并不意味着没有问题,质量如何保证,就需要项目负责人进行项目的验收,不然怎么知道已经完善了呢? 以上这三点都是对于项目而言,那么对于项目负责人来说,意义又在哪里呢?那就是一个人的成功(做好事情)固然值得肯定,但如果他能将这种成功因地制宜地在团队其他人身上应验,那将意义深远。 一方面你团队里的成员能力有所提升,对项目上面的工作肯定是有帮助的,另一方面,我们都知道每个人都有自己对世界的一套认知,怎么做事情,都有自己的方式,我们只是一直在摸索那条规律,不断应验和调整,如果其他人也适用,那至少说明,你的一整套理论是有可取之处的,越来越靠近那条规律;如果不适用,那也可以借机进行反思和完善,对你而言是大有裨益的。这也是毛泽东《实践论》里提到的观点,”人类认识的历史告诉我们,许多理论的真理性是不完全的,经过实践的检验而纠正了它们的不完全性。“ 第3章 能力篇 3.1 项目负责人能力划分 我认真思考了一下,觉得项目负责人的能力可以分为五个阶段,分别对应的关键字是开发、方法、产品、整体、市场。虽然看起来好像呈递进关系,但是我发现实际上不是这样的,很多人可能没办法将其划分在哪个阶段,有些是好几个阶段都覆盖,各阶段要求的能力都有一点,但又不完全具备;有些是第二阶段了,可能第一阶段还没达到等等,所以这个划分只是参考。 3.1.1 第一阶段 项目里自己负责开发的功能高质量完成,基本可以认为是可以直接给客户演示的标准: 功能没什么特别重大的bug,比如不会突然用不了; 功能有完善边界,比如输入手机号有限制以及正确或异常提示等等; 界面交互体验顺畅,不会出现很混乱的场景; 界面美观,细节完善,哪怕一个像素都有注意到等; 3.1.2 第二阶段 项目里自己开发的模块,业务特别熟悉,其他分配出去的就不熟悉; 项目需求理解到位、项目方案设计、项目开发计划、项目内部验收、想提交测试和项目上线等环节都可完成; 3.1.3 第三阶段 项目里全部业务需求的脉络都一清二楚; 项目中涉及到硬件相关的产品都会使用; 产品需求、产品原型如果是你来做呢?对项目需求和原型有自己的见解,完全可以胜任; 3.1.4 第四阶段 项目里的技术栈全都熟悉,比如前端/后端出身的项目负责人去熟悉后端/前端相关技术栈知识。 3.1.5 第五阶段 项目的观念开始转变为产品,对其在市场上的定位以及价值有深刻的见解,明白这个产品的目的是什么? 关注产品在市场上的推广与营销; 3.2 项目负责人对业务不熟悉 3.2.1 问题描述 一直以来,存在这样的问题,项目负责人接到产品需求之后,可能就扫了一眼,就开始制定项目开发计划,制定好之后,只深入了解自己负责开发的模块,其他的就不会再深入了解了。对于那些其他人开发的功能,只要问三个问题,一般都回答不上来。 是什么,这个是什么功能? 为什么,客户为什么需要这个功能,这个功能对他们有什么用处,不开发这个功能不行么? 怎么做,这个功能前端是怎么实现的,后端是怎么实现的?一般能回答到第三个问题的前端/后端部分都很不错了,实际情况别说第二个问题了,有可能第一个问题都不一定知道。而负责开发该功能模块的同事,也可能是边了解边开发,需求了解的程度,刚好可以开发出功能就行了。这样就容易导致,这个项目在管理上面会有问题,表面上风平浪静,其实是失控的状态,主要表现在以下方面: 任务时间评估不到位的问题,经常变更任务计划; 风险意识问题,业务不熟悉,不能提前发现潜在的延期因素,不能有效判断是否需要加班; 任务验收问题,功能是否已实现,与需求是否一致,只根据开发同事的回答结果而定,因为对业务不熟悉,验收的时候有心无力,只能敷衍了事,整个验收工作开展很艰难,积极性也就不高; 3.2.2 解决方案 项目负责人需自己梳理一份项目需求与功能实现文档,将每个功能都按三个问题来梳理清楚,是什么,为什么,怎么做。然后项目推进过程中,有任何变更的需求,就实时更新文档,这样子至少心里是有底的。 3.3 对Bug系统的问题敏感度不高 3.3.1 问题描述 这个问题之所以出现,是因为对工作要求边界不清晰导致的。我们在项目中引入版本管理之后,基本明确在内部验收环节,保证当前Bug系统上面的问题是已经全部解决的。 3.3.2 解决方案 和项目负责人达成共识,内部验收环节,Bug系统上面的问题全部解决,视为任务达成。 3.4 项目任务验收工作没有真正落实 3.4.1 问题描述 之前我们计划项目负责人,每周周五进行任务验收,但在开展过程中,验收其他开发同事任务的时候,经常出现缺胳膊少腿的情况,比如某个任务完成了,但是文档没写,或者写了又没有提交更新;某个任务时间都过了,也没有调整变更,什么原因也没有说明等等,执行起来很困难。现在在项目进度会议上,当场把任务验收,就需要周一的时候,项目负责人牵头更新任务的时间、功能和文档情况,不然周二在项目进度会议上,还是会出现各种各样的问题。但是周一的时候,项目负责人已经验收过任务,周二在项目进度会议上又过一次,对于其他开发同事来说,就觉得被问了两次,显然这个方式可能没有从根本上解决问题。...

2022-08-21 · 3 分钟 · 506 字