关于工作任务安排的讨论

   起因是前几天给下面的人安排工作任务。我在项目总体时间计划下，安排了一些任务给我的成员。如其中一个任务，我安排了3天。该任务只要认真做，2天就ok.正好该成员上班时，网上看了一下小说，被我的上级路过发现。上级私下和我说：你安排的工作，饱和度不够。比较郁闷就是了。当然，任务在规定时限内最后也是完成了的。撇开上班看小说不谈，是不是我的方式不对呢？
    我的意见是，只要在规定期限内完成安排的任务就ok,所以任务都是适当宽松一些。如一天至多安排5个小时的工作量。我觉得，一个人应该愉快的开发，可以适当的有个人的空间。现在想来是不是我的思考方式不对，或者说更多从开发者角度思考问题了。是不是上面只考虑进度，我是不是以后也应该转换角度进行任务安排。欢迎大家一起探讨。
  

评论

78 楼 wandou 2011-06-05  

再说得直白一些，以理服人，就是反扯淡能力。会跟你扯淡的，主要是管理者，以及部分政治意识比较强的员工。技术强的员工，反而不一定扯淡。
周星驰的电影里有句话，想做清官，得比贪官更奸。
以理服人这关过不了，休想做到以德服人。
lz的坚持是对的。但是战斗力不足，不能保护自己的坚持。
多学法律知识，管理理论，并且熟悉常见的扯淡手法，找出他们的漏洞，提高辩论能力，才能把你的路走下去。
适当的时候，应当注意到，舆论，其实是最强大的力量。坚持以理服人，就能获得舆论的支持。
人性就是如此，你想坚持人性之善，必须了解人性之恶，才能坚持下去。

77 楼 wandou 2011-06-04  

补充一下，以力服人，有两种形式。
第一种，用暴力压迫，把不合理的事情强加于被管理者，不与被管理者交流。
第二种，用言论暴力。这种比较多，直白一点说，就是扯淡。用一些员工无法验证的信息去欺骗员工，用较强的辩论能力去压倒员工，让员工口服心不服。利用员工拉不下脸的心理去控制员工。这些都是无法长久的手段。

说到底，公司想做得久，无非诚信二字。
诚，心诚。承诺，就是真的想做到，而不是误导对方的思路，让对方与自己的理解不同，事后以此理由反悔。
信，就是承诺必须做到，言出必行。
有的人，是信而不诚。与员工交流时，用可能，或者，大概之类的说法去误导员工。比如，“这件事情做得好，我给你争取加薪。”这句话的实质，就是没有保证。如果管理者知道加薪比较困难，那么这种做法，就是信而不诚。虽然从员工的角度看，没有理由指责管理者违背承诺，但是，以后肯定会觉得自己受到欺骗，不会再主动配合。

76 楼 wandou 2011-06-04  

peterwei 写道

   起因是前几天给下面的人安排工作任务。我在项目总体时间计划下，安排了一些任务给我的成员。如其中一个任务，我安排了3天。该任务只要认真做，2天就ok.正好该成员上班时，网上看了一下小说，被我的上级路过发现。上级私下和我说：你安排的工作，饱和度不够。比较郁闷就是了。当然，任务在规定时限内最后也是完成了的。撇开上班看小说不谈，是不是我的方式不对呢？
    我的意见是，只要在规定期限内完成安排的任务就ok,所以任务都是适当宽松一些。如一天至多安排5个小时的工作量。我觉得，一个人应该愉快的开发，可以适当的有个人的空间。现在想来是不是我的思考方式不对，或者说更多从开发者角度思考问题了。是不是上面只考虑进度，我是不是以后也应该转换角度进行任务安排。欢迎大家一起探讨。
  

你不应该转换角度进行任务安排。你做得对，应该继续坚持。
管理，流派多得很。其实也就三种形式：以德服人，以理服人，以力服人。
以德服人，上乘境界。调动员工的积极性，让员工不计较利益。发挥最高的战斗力。
以理服人，中乘境界。在员工的利益发生矛盾的情况下，有让大家信服的规则，解决矛盾。
以力服人，没有境界。初学者都这么干，团队效率极低，而不知反省，死路一条，不能长久。

以德服人很难达到，需要结合以理服人。你现在是试图以德服人，但是在以理服人的环节，觉得有所不足。、
现在的问题，就是上级与下级的关系发生矛盾。

这个员工看小说的事情，上级的看法是，要求你用很多的工作量去压他们，让他们没有时间去看小说。这是否是好的方式？肯定不是。以力服人，最终结果，是公司和员工互不信任，最后员工消极怠工。加班又能怎么地？还能把人看住不成？看住又怎么地？把代码翻来翻去，就是不把bug找出来，难道公司还能证明一个bug需要多长时间才能解决？

员工上班是否可以看小说？这个要看公司的规定。如果员工确实完成了自己的工作任务，而公司又没有上班时间不允许看小说的规定，那么我认为，他看小说也没有错。不能以此责备他。但是，我会建议他以后不要在上班时间看小说，以免影响其他人的工作情绪。我尊重他完成工作任务之后看小说的权利。我对上级，也会如此交代。因为他积极做事，已经完成了工作任务，所以在看小说，没有违反公司规定。如果公司不希望员工上班看小说，应该增加这样的规定，并且经职工代表大会讨论通过（劳动法的要求），以后再出现看小说的现象，按规定进行处罚。

至于上级要求增加他的工作任务的做法，不能认同。因为这样做，是对能力较强者的打击。如果这么做，就会失信于全公司。能者多劳，又没有奖励，结果就是以后大家都装熊。反而使工作进行不下去。

让员工快乐，的确不是项目经理的职责范围，但是，作为一个人，让身边的人快乐是一种美德。
既然是美德，坚持并没有错。我相信你，顺着这条路走下去，最后会取得成功，得到所有人的认可。

至于你需要提高的，是以理服人的能力。很明显，你在论辩方面有所不足。对上级，有畏惧感。任何事情，只要占住一个理字，再加上一个“礼”字，都可以立于不败之地。领导也得讲道理。你尊重他，但是，请他以理服人。

记住，你是在为公司的利益考虑。至于工作，你有你的工作方式。如果，他需要决定你的工作方式，那么请他说出理由，说服你。如果不能说服你，又坚持他的理由，那么，他应该为自己的决定负责。

75 楼 lyy3323 2011-05-31  

终于看完帖子了。
感觉几位管理者都有自己的思路，也都有自己的道理。

作为开发人员，其实跟你们谁干就感觉比较HIGH。因为你们肯分享，肯改变。

74 楼 pushboy 2011-05-21  

很赞成一蓑烟雨的话
我以前的做法跟LZ差不多，后来发现不是这么回事
慢慢的就变了，然后发现效果相当好，无论是对个人对公司对下属对项目
看着这个帖子，就好像看到自己的成长经历一样
呵呵

73 楼 qljcly 2011-05-21  

mark一下

72 楼 doltter 2011-05-20  

我也明白了，明白了我该怎么做了。
下面做的不对，该喷的时候，就得喷！

71 楼 kill_all 2011-04-13  

todo158 写道

对于工作安排我一般在时间允许下，会将工作按优先级分割成几个小版本（也可以理解成里程碑）。在每个小版本内做
1、版本规划
2、需求分析（需求分析人员忙，设计人员小忙，程序员只参与讨论或评审或休息）
3、设计（需求分析人员小忙，设计人员忙，程序员只参与讨论或评审或休息）
4、编码，按设计分解任务，在里程碑内程序员自由安排，项目经理做代码走查（需求分析人员休息，设计人员休息，程序员忙）
5、集成测试，修改BUG（设计人员忙、测试人员忙，程序员小忙）
6、确认测试，修改BUG（需求人员忙、测试人员忙，程序员小忙）
7、结束，开始下个版本迭代
这种每个迭代期间大家都有机会很忙，也有机会休息，每个里程碑结束也会有成就感，不会感到项目没完没了，做不到头

这是项目各个角色状态，关键的项目经理定位没有说明

70 楼 ouyangshixiong 2011-04-13  

项目紧的时候大家都紧张起来，项目松的时候大家都闲点。人性化的管理。看看小说怎么了。关键问题是不是大家都在忙，就他在看小说，项目经理把水端平了就没问题。扯到薪水，个人素质，发展前途都是扯蛋。

69 楼 huangfoxAgain 2011-04-08  

我们年初还在制定各种文档模板、管理流程呢~现在还没有具体可实施的 任务分配、反馈、审核 方式，目前感觉就是开发松松垮垮，开发人员、小组、部门没有很好的衔接起来，高速运转！
我想很多公司都有这种问题吧~！？

68 楼 changtiger 2011-04-05  

工作按计划完成，那是工作安排的松了，没按计划完成，那是你没好好工作。老板都这德行。

67 楼 robot2008 2011-04-02  

回帖全看完了,感谢大家分享.

66 楼 yanaicheng 2011-03-25  

yangguo 写道

楼主什么公司什么部门啊，招人不？理想中的开发环境啊。

一蓑烟雨任平生什么公司也提一下吧，深怕一不小心行差踏错进了你的部门真是几生修道啊。

也不是那么绝对的，如果像那么说的话，很多人都会不太高兴跟你继续合作下

65 楼 yangguo 2011-03-10  

楼主什么公司什么部门啊，招人不？理想中的开发环境啊。

一蓑烟雨任平生什么公司也提一下吧，深怕一不小心行差踏错进了你的部门真是几生修道啊。

64 楼 xiaoyuwei 2010-10-09  

我们项目组也有不少成员看网页，我也经常看网页。。。。

我觉得每个人每天都有自己高潮期，低潮期。

程序员开发应该是个艺术工作，给他们时间在低潮的时候调整下自己，也是没啥问题的。程序员也会觉得很人性化。

项目经理看的应该是结果，每天早上花上10几分钟定下任务，晚上再用上10几分钟来跟踪，结果导向很重要。

63 楼 todo158 2010-10-08  

对于工作安排我一般在时间允许下，会将工作按优先级分割成几个小版本（也可以理解成里程碑）。在每个小版本内做
1、版本规划
2、需求分析（需求分析人员忙，设计人员小忙，程序员只参与讨论或评审或休息）
3、设计（需求分析人员小忙，设计人员忙，程序员只参与讨论或评审或休息）
4、编码，按设计分解任务，在里程碑内程序员自由安排，项目经理做代码走查（需求分析人员休息，设计人员休息，程序员忙）
5、集成测试，修改BUG（设计人员忙、测试人员忙，程序员小忙）
6、确认测试，修改BUG（需求人员忙、测试人员忙，程序员小忙）
7、结束，开始下个版本迭代
这种每个迭代期间大家都有机会很忙，也有机会休息，每个里程碑结束也会有成就感，不会感到项目没完没了，做不到头

62 楼 ouchxp 2010-10-08  

zoukang_83 写道

keating 写道

恩,明天加班.
项目经理的责任还是在项目,并不在培养人才鸟,培养人才是部门主管的事情.

如果一个公司分的不细，项目经理有事部门主管团队发展怎么办？

董事长一人全兼怎么办??
层次很清晰 董事长 -> coder

61 楼 ouchxp 2010-10-08  

peterwei 写道

以一个20人的项目为例。假设分为三个开发小组。那么垮小组调bug,谁有空谁改，这恐怕不大现实。一方面你改bug虽然改得很hign,但有没有想过让别人很难堪。另一方面越权，工作任务安排上每个组都对应有相关责任人,你去改别人的，从权力上来说就不充许。即使是比较大点的领导推行起来，还是有一定问题的，现在的人一个比一个NB轰轰。
那么只能小范围的来互调bug,这倒是可以试行的办法。比如熟悉的两人组。

用五笔的 拼音党膜拜下.

60 楼 zoukang_83 2010-09-30  

keating 写道

恩,明天加班.
项目经理的责任还是在项目,并不在培养人才鸟,培养人才是部门主管的事情.

如果一个公司分的不细，项目经理有事部门主管团队发展怎么办？

59 楼 抛出异常的爱 2010-09-30  

为了这个率已经与QA吵了无数架了.....