查看完整版本: 理想的管理模式

理想的管理模式

[align=center][color=#000000][b][font=宋体][size=9pt]理想的管理模式[/size][/font][/b][b][size=9pt][/size][/b][/color][/align][color=#000000][font=宋体][size=9pt]    出于好心我们的管理者往往喜欢及时的调整工作的分配情况，抱着互相帮助的精神及其渴望做到平均分配的共产主义社会。希望闲的及时帮助忙的，及时分解繁忙状态，有空大家再一起学习。举例来说：[/size][/font][/color][color=#000000][font=宋体][size=9pt]比如某天某人发现自己有两个要测试项目，向管理者反应自己忙不过来了，因此管理者积极调动一组成员，谁有空谁帮忙，于是大家在忙完自己的项目的基础上，[/size][/font][size=9pt][font=Times New Roman]maybe[/font][/size][font=宋体][size=9pt]花了半小时乃至是一小时去帮这个忙，而更有甚者还积极咨询该项目的责任人来理解这个测试项目（变相消耗该责任人的时间），可能刚刚看明白这个项目是咋回事，就发现自己另有任务了，又去忙自己的任务。累计算一下，假设共有[/size][/font][size=9pt][font=Times New Roman]3[/font][/size][font=宋体][size=9pt]个人来帮忙该项目，每人累计一天花了[/size][/font][size=9pt][font=Times New Roman]1[/font][/size][font=宋体][size=9pt]小时，共花去[/size][/font][size=9pt][font=Times New Roman]3[/font][/size][font=宋体][size=9pt]小时，[/size][/font][size=9pt][font=Times New Roman]3[/font][/size][font=宋体][size=9pt]人咨询该项目的责任人共花去责任人累计[/size][/font][size=9pt][font=Times New Roman]1[/font][/size][font=宋体][size=9pt]小时。总共一天花在该项目上[/size][/font][size=9pt][font=Times New Roman]4[/font][/size][font=宋体][size=9pt]小时，可是这时的项目状态却依然是相当于未开始测试。而如果我们给项目排个优先级，当项目冲突时，组长先查看各成员的近期安排，假如存在某人能整体接下该项目则安排其开始接管此项目，否则则给项目排优先级不变更项目的责任人，通知项目的开发人员，今天不能测试这个项目，需推后一天，然后各成员各忙各的。可以看到这种安排项目可能依然是处于未开始测试的状态，表面上来看，项目组失去了互相帮助的精神，没有积极响应项目的测试，而实际上这样将对项目组成员的工作安排或计划的影响减小到了最小程度，我们的成员可以用这多余的一小时用来休息或用来[/size][/font][size=9pt][font=Times New Roman]find[/font][/size][font=宋体][size=9pt]自己工作时碰到的问题，亦或是用来思考自己的工作方式，这对我们的成员工作的提高又是多大的帮助呢？[/size][/font][size=9pt][/size][/color]
[color=#000000][font=宋体][size=9pt]    “谁有空谁帮忙”表面上看来这是一种极具团结思想的上进精神，但就我看来这是一种最危险的模式，这种模式往往导致整个团队在各项目之间疲于奔命，终究不存在所谓的有空的时候，而每个人都对每个项目都有那么一点感觉，而又不能对项目整体把握贯穿项目始终，因而对每个项目都没有归属感。最终漂浮于各项目至上，惶惶不可终日。同样，做为一个团队来说，不可能存在着十几二十个人同时闲着共同学习的情况。熟话说，学习如逆水行舟，不进则退。一个整天都处在所谓的互帮互忙的状态的团队，怎么可能有时间学习新知识呢？因此这种管理模式必然导致团队成员的知识最终落后。[/size][/font][size=9pt][/size][/color]
[color=#000000][font=宋体][size=9pt]    逆而想之，不可能存在着十几二十个人同时闲着共同学习的情况，但十几二十个人中每次有一个两个闲一天两天的情况却极可能存在。理想的管理模式应当是敢于打破这种平均主义的思想，而做到按劳分配，按需分配的情况。任何新项目先从组长处接口，由组长根据当前项目组成员的繁忙状态安排人员执行。如下图[/size][/font][size=9pt][font=Times New Roman]1[/font][/size][font=宋体][size=9pt]，新任务经由[/size][/font][size=9pt][font=Times New Roman]leader[/font][/size][font=宋体][size=9pt]之手，然后[/size][/font][size=9pt][font=Times New Roman]leader[/font][/size][font=宋体][size=9pt]查看成员的繁忙状态，忙的不与考虑，暂时闲着，但不能完全安排出时间接替该项目的不与考虑，剩下能完整给出时间来测试该项目的则分配该项目给他，如果没有满足这种条件的成员，则将项目排队等待。直到有满足条件的成员出现为止。这样，一保证了项目的入口是[/size][/font][size=9pt][font=Times New Roman]leader[/font][/size][font=宋体][size=9pt]处，避免了有些项目直到出现事故了在追究责任时[/size][/font][size=9pt][font=Times New Roman]leader[/font][/size][font=宋体][size=9pt]才知道有这个项目的情况出现，二最大程度的保证了项目组成员的工作计划的稳定性，不至于在项目间拆东墙补西墙的疲于奔命。三同时也给项目明确分配了测试责任人和测试安排，给项目的[/size][/font][size=9pt][font=Times New Roman]pm[/font][/size][font=宋体][size=9pt]或开发人员一个明确的交待，方便其他人做计划安排。[/size][/font][/color][size=10][color=#000000] [/color][/size]
[color=#000000][size=7]  [/size][font=宋体][size=9pt]但如项目非常紧急而此时又没有测试人员空闲时，这种模式就导致项目拖延时间过长，丢失市场抢占先机等风险，因此也存在着一定的弊处。那我们再来优化下上面这个流程――给各项目排个紧急度优先级，如果当前过来的项目紧急度高于在测试中的项目，则根据优先级调度项目优先级最低且能安排出接替完整测试该项目时间的人员暂停手头上的测试，完成当前紧急项目再开始测试原本进行中的测试。如下图[/size][/font][size=9pt][font=Times New Roman]2[/font][/size][font=宋体][size=9pt]： [/size][/font][/color]
[color=#000000][font=宋体]    [/font][font=宋体][size=9pt]新任务带着紧急度标志[/size][/font][size=9pt][font=Times New Roman]2[/font][/size][font=宋体][size=9pt]过来，首先到达我们的管理者处，然后管理者调出组内成员当前任务安排表，查寻对应紧急度，发现成员[/size][/font][size=9pt][font=Times New Roman]1[/font][/size][font=宋体][size=9pt]当前项目紧急度比新项目紧急度高，因此不考虑成员[/size][/font][size=9pt][font=Times New Roman]1[/font][/size][font=宋体][size=9pt]；继续查寻发现[/size][/font][size=9pt][font=Times New Roman]2[/font][/size][font=宋体][size=9pt]当前项目紧急度与新项目紧急度等同，因此也不考虑成员[/size][/font][size=9pt][font=Times New Roman]2[/font][/size][font=宋体][size=9pt]；接着查寻成员[/size][/font][size=9pt][font=Times New Roman]3[/font][/size][font=宋体][size=9pt]发现当前项目紧急度为[/size][/font][size=9pt][font=Times New Roman]3[/font][/size][font=宋体][size=9pt]，此成员可以列入待考虑范围；继续查寻发现成员[/size][/font][size=9pt][font=Times New Roman]4[/font][/size][font=宋体][size=9pt]，当前状态闲但却不能满足安排出一个完整的时间来接收新项目，因此也不考虑成员[/size][/font][size=9pt][font=Times New Roman]4[/font][/size][font=宋体][size=9pt]；最后看成员[/size][/font][size=9pt][font=Times New Roman]5[/font][/size][font=宋体][size=9pt]当前项目紧急度[/size][/font][size=9pt][font=Times New Roman]4[/font][/size][font=宋体][size=9pt]，比成员[/size][/font][size=9pt][font=Times New Roman]3[/font][/size][font=宋体][size=9pt]当前项目的紧急度还低因此排除成员[/size][/font][size=9pt][font=Times New Roman]3[/font][/size][font=宋体][size=9pt]，且若暂停当前项目接收新任务，能安排出完整的时间来接收新项目；最后，管理者将当前任务安排给成员[/size][/font][size=9pt][font=Times New Roman]5[/font][/size][font=宋体][size=9pt]，成员[/size][/font][size=9pt][font=Times New Roman]5[/font][/size][font=宋体][size=9pt]接收新任务并优先完成新项目的测试，返回完成后继续进行未完成的任务。由此，我们可以看到这样即保证了：一保证项目的入口是[/size][/font][size=9pt][font=Times New Roman]leader[/font][/size][font=宋体][size=9pt]处，避免了有些项目直到出现事故了在追究责任时[/size][/font][size=9pt][font=Times New Roman]leader[/font][/size][font=宋体][size=9pt]才知道有这个项目的情况出现，二最大程度的保证了项目组成员的工作计划的稳定性，不至于在项目间拆东墙补西墙的疲于奔命。三同时也给项目明确分配了测试责任人和测试安排，给项目的[/size][/font][size=9pt][font=Times New Roman]pm[/font][/size][font=宋体][size=9pt]或开发人员一个明确的交待，方便其他人做计划安排这些优点，同时又解决了万一项目紧急度高而无成员空闲而导致项目拖延时间过长，丢失市场抢占先机等的风险。[/size][/font][size=9pt][/size][/color]
[font=宋体][size=9pt][color=#000000]    最后，愚者自娱，写下所想，欢迎大家批评讨论，嘻嘻：）。。[/color][/size][/font][size=9pt][/size]

[[i] 本帖最后由 shelly 于 2006-11-6 16:51 编辑 [/i]]

管理者成为工作的瓶颈并不是很好的做法!

为什么会认为管理者会成为瓶颈？所谓瓶颈应该是说前后的工作量会频繁在某处形成堵塞前后等待吧。我不认为管理者分配任务是一个很大消耗工作量的事情啊。sdlkfj6

补充一句，而且，如果项目都不经过管理者，管理者又如何从宏观上把控整体工作呢？sdlkfj5
谢谢fxlizard 的回复。希望能看到更多的指点。

我觉得这个是各个人员自己的能力问题，及时调整自己的状态，如果公司的相关文档相当完善，而人员的职业水平比较高的话，这种问题出现的可能性很小，而且我觉得工作中随机应变是必备的能力，我觉得项目优先级影响不大...

[quote]原帖由 [i]conanin[/i] 于 2006-11-15 11:05 发表
我觉得这个是各个人员自己的能力问题，及时调整自己的状态，如果公司的相关文档相当完善，而人员的职业水平比较高的话，这种问题出现的可能性很小，而且我觉得工作中随机应变是必备的能力，我觉得项目优先级影响 ... [/quote]
这个观点我赞同，就现实情况出发，就是需要提高随机应变能力，前提是文档完善，流程清楚，体系成熟，否则就容易乱。

不知道现在有几个公司能做到：文档完善，流程清楚，体系成熟的。
理想主义者！

[quote]原帖由 [i]shelly[/i] 于 2006-11-22 13:34 发表
不知道现在有几个公司能做到：文档完善，流程清楚，体系成熟的。
理想主义者！ [/quote]
这个要求当然是相对的，楼主先别报怨大环境，总体来说，只要对于接受任务的人员来说，提供的信息足够那就可以了，其他的可以通过口头沟通和深入理解来弥补。
另外说一点，如果按照理想的管理模式的话，每个项目保证固定的测试人员跟踪，即使期间空闲，但无法完整承担新任务的话，就不用该人员，继续新招入，那么也要根据项目的可能产生的利润程度权衡，否则人员成本将会逐渐地成为发展瓶颈。你觉得呢？

好像原帖上面没有说新招入哦？sdlkfj8貌似楼上的自己引申出来的。sdlkfj6

[[i] 本帖最后由 shelly 于 2006-11-23 13:41 编辑 [/i]]