项目实战笔记之四:团队建设(尊重)
作者:网络转载 发布时间:[ 2013/5/31 11:21:39 ] 推荐标签:
4)在一些公共场合,尤其有上级领导在时,公开表扬那些为团队做出很多额外贡献的人
5)绩效考核肯定以结果为导向,不能以加班多少论英雄,但要有其他措施安慰辛苦的人
推荐策略:加班是一种奉献精神,我们要小心使用,认真对待。不能简单的当做管理者的权力,轻言肆用,否则久之必招其离心。
4、开放沟通的团队氛围
人都希望自己能够有发言权,能够对关心的事情产生影响。上至的选举,下至日常的工作生活。如果发言权被长期压制,会产生压抑和叛逆的心理。因此构建一个具有开放沟通的团队氛围则显得很重要。而往往言路开明后,项目经理总是能在一些讨论中,得到很多比预期更好的解决问题的方案。一个强权的管理者,容易获得一定程度上的执行力,但是容易被自己的盲点击败。而一个开明的管理者,往往能使用集体智慧,获得跟随者,更容易产生威望。
推荐策略:
1)项目沙盘等关键策略制定时,要全体项目参与讨论
2)项目经理鼓励大家发现问题,提问问题,对于好的措施,能够采纳执行
5、责任到户 VS 大锅饭
从头到尾的责任到户制应该是理想的工作分配方式了,在这种分配方式下,团队成员有一块自己土地,通常愿意花更多的时间与精力去耕耘(例如:某个全新的模块),如果这个模块又是他一直想尝试的方面,那将会更加完美,我们有理由相信他将会在这里充满了激情。
然而世界上总没有十全十美的事情及百分百通用的方案,尽管责任到户制如此之好,但是在某些项目上我们达成不了这样的期望。
我所亲身经历过的两个版本遇到了这样的状况。两个版本的共性是:在一个很大的系统上做覆盖面很大的,很多小点的修改(例如:更换所有UI系统),但是基于老系统的复杂性及历史问题,项目在中会遇到很多bug,各种各样,在bug没有查到原因之前并不好确定这个问题谁改动引发或是谁的责任,这种情况下责任到户制会出现失效。在面对系统这么多的bug时,项目经理很容易想到一种方法:“那是给大家分配bug数,下指标,每天每人要解决3-4bug等”。两次项目经历中,项目经理确实都想到了这种方法,区别是前者实施了,后者被我阻止了。原因如下:
1)团队组员容易产生不被尊重感,被当成解决问题的机器
2)团队之间的协作会发生困难,而且过度强调这项指标,例如谁每天不修改完这个bug数,要加班到10:00之类的,会导致部分组员开始取巧,每天争抢容易处理的bug
3)没法发挥人的主动性,将团队目标和个人目标相背离
这种情况下大锅饭的机制似乎更合适一些,如果团队没有达成目标则需要一起想办法或加班解决,而不是将这人归咎个某个人。
推荐策略:在正常项目中尽量使用责任到户制,而对于一些特殊项目,则选用大锅饭制,没有一成不变的方案,具体情况具体变通。
相关推荐
更新发布
功能测试和接口测试的区别
2023/3/23 14:23:39如何写好测试用例文档
2023/3/22 16:17:39常用的选择回归测试的方式有哪些?
2022/6/14 16:14:27测试流程中需要重点把关几个过程?
2021/10/18 15:37:44性能测试的七种方法
2021/9/17 15:19:29全链路压测优化思路
2021/9/14 15:42:25性能测试流程浅谈
2021/5/28 17:25:47常见的APP性能测试指标
2021/5/8 17:01:11