三个不同历史阶段的QA关于时间管理的对话

 

三个QA凑到一起讨论时间管理的问题：过去的QA\现在的QA\未来的QA

过去的QA说：

“老板总是感觉大家在偷懒效率不高，所以要求我用人时、绩效考核来监督员工的工作。”

 

现在的QA说：

“一般来说企业员工工作饱和度能达到80%，就算不错的了，如果偷懒的人有较大比例到了必须用人时来管理，

那基本可以认为是老板的问题，要么过时的管理方法、落后的思维模式，使得工程师学会偷懒了。”

 

未来的QA说：

这个牵涉到管理学里面的X理论和Y理论，大概管理层还把员工当做X理论中的“经济人”对待的缘故，从员工管理的角度来说，从落后到先进出现了下列几种管理模式：

************************************************************

1．“经济人”假设和管理－X理论

管理理论：

管理重点在提高生产率，完成生产任务

管理只是少数人的事，与一般员工无关，员工的任务就是听从指挥。

在奖惩制度上，主要依靠金钱来刺激员工的生产积极性，同时对消极怠工者给予严厉的制裁

 

2．“社会人”假设与管理

管理原则：

强调以人为中心的管理，注意关心人，满足人的需要

管理人员应重视人际关系，重视培养员工的归宿感和整体感

提倡集体奖励

让员工不同程度地参与企业决策的研究和讨论

 

3. “自我实现的人”假设和管理－Y理论

管理原则：

创造适宜的工作环境、工作条件，以便充分发挥人的潜力

管理者的职能是设计生产环境和条件

重视内部激励，重视通过满足员工的自我实现需要，来调动员工的积极性

主张下放管理权限，建立充分的决策参与制度，满足员工自我实现的需要。

 

4．“复杂人”假设与管理－超Y理论

管理原则：

采用不同的组织形式提高管理效率

根据不同的情况，采取弹性、应变得领导方式

善于发现员工的需要动机、能力、个性方面的差异，因时、因地、因人、因事采取灵活多变的管理方式

和奖励方式。

**********************************************************************

 

过去的QA说：

呵呵，企业管理有个基本的假设，一切问题都是管理的问题，管理的根源又是老板，这个就大了，老板理所当然是企业的最终负责人，所以，即使楼下食堂饭很难吃，也是可以归咎于老板的事情。有些命题太大就没有讨论的意义了。

 

现在的QA于是说：

所以拉回到原始命题，“人月神话”这本书里面说： 随着团队规模的增长，环节增加，人与人之间的沟通成本是按指数增长的。而沟通成本增长是导致团队效率降低的主要原因。但是当前的软件产品的规模和速度、质量要求必须追求一个高效的团队配合，这就形成了矛盾：

 

未来的QA接着说：

初始软件没有工程概念一说，游击队的形式，然后是逐步的规范/班排组织（职能单一），

规范进一步则有了更多的分工，类似营团组织，有些企业规模大了搞不好都军团组织了。

然后发现效率成了问题，于是一些公司采取了敏捷开发，又走回班排组织的规模了，但是人却完全不一样了， 与那种古老的骑士似的一个程序员、一台PC、做一个WPS完全不同了，如今软件行业的人素质算比较高的，自我意识、自我压力和管理上不会有问题，所以管理方面更应该把重点放在关注做事情的方法，或者说流程方面

 

在现有的条件下，再用“经济人”管理模式显然是不合时宜的，我们不妨把管理高度上升到管理学的Y理论，假设工程师主观上都不是偷懒的，都是敬业的。如果这个假设都困难的话，那就先想办法把这个做好。故而在确定大家都是积极的劳动者的基础上，我们要明确的就是任务。

 

现在的QA回答：

目前我们常用人时来对项目任务进行策划和管理，并统计投入成本，对于研发工程中的人时进行统计基础上，我们明确需求，然后分解任务，最好每天有个任务，然后进行任务跟踪，如果当天来不及完成的，工程师和Team都应该先确认下任务延误原因：

1）任务的难度超出了预先估算、

2）还是受所依赖的活动影响，

3）还是任务所属的需求出现了变化，

但一定要排除是否偷懒的答案，每天去确认任务，如果有延期，从答案里三选一，如果是需求范围变化了，去更新需求，如果是低估了难度，重新给出时限，如果是依赖任务没有完成，去追溯依赖任务的原因。这就是软件工程中时间管理的基础，很简单 一般敏捷开发里面很强调这一点，抛弃了所谓的人时，改用燃尽图进行时间管理。

 

 

 

未来的QA继续说：

所以敏捷模型中采用每天的standup meeting（站立会议，晨会）burndown chart（燃尽图）进行时间和任务管理...没有人偷懒

补充说明****************************************************

敏捷开发所说的每日例会，时间非常短，一般不超过15分钟

 所以是standup meeting，站立会议

 大家站着开会，目的就是不让会议变长

 站久了会累，所以你就会长话短说

*************************************************************

呵呵，我最喜欢敏捷开发里面的一个要点，就是对人的信任，而CMMI这些流程管理方法的出发点，就是基于对人的不信任这是敏捷开发与传统软件工程最大的差异 -----个人理解。

   

    现在的QA解释道：

说到不信任，恐怕大多数情况下是由于各个人的能力之间的差异，导致信任与不信任为将信将疑，否则就不用监督了。

    

     未来的QA接着总结：

说到这里我们要改变监督的思路，QA不要把自己定位在监督者，思维决定行动，把自己定位在监督者也许对你在特定公司是有用的，比如符合老板给SQA的定位，但我们还应该从行业的发展来给自己定位。

 工程师需要的是帮助，关于个人管理和Team管理（包含时间管理、知识管理）等等，而不是工期的监督。QA帮助大家找到时间的黑洞，提高效率。而不是一种干扰的声音。

 

过去的QA又提了另外一个问题：

另外一个老板和项目之间关于项目周期的纠结，我听到一些经理的抱怨：公司下达任务，时常会发现一些时间要求的打埋伏，本来45天以内完成就可以了，任务书上写30天，

接着下达到具体的任务负责人时变成了22天，而QA老是疑心项目组打埋伏，把22天的工作说成45天。

公司认为Team打埋伏，Team觉得不打埋伏会损害自己的利益，于是互相猜疑

然后公司想办法和Team讨价还价，争取削减时间，而Team为了保证质量，讨价还价，争取更多时间，而且除了保证质量，私下还有不可说的想法是为了避免混乱的需求带来的无休止的时间后延。

 

 

现在的QA分析道：

老板预留了buffer缓冲期，其实是为了预防某种风险的，也是必须的。

但是从管理层面来说，如果重在追究延期的责任，那就等于鼓励项目经理对项目周期打埋伏，这种情况归根结底的确是老板带来的，所谓恶性循环就是这个道理，

 

未来的QA总结症结：

观察多个产品情况，确实掌握信息之后，

把讨价还价/（讨价还价任何企业都有的，总比一言堂好，学名博奕）变成基于任务的讨论。

 比如买服装，我不愿意去市场，因为没有标准。厉害的人可以“对折拦腰半”，也就是说50％×50％×50%，100元的13块搞定。卖家不知道买家的出价意愿，买家不知道卖家的利润空间，靠察言观色来互相考验底线。

如果软件企业内Team和老板互相信息不透明，极端情况也会这样。

老板这个角色任期比别的角色更长，所以先不要管讨价还价的细节，把每天延期任务的分析做好，通过每个任务的确认接口把关，在此基础上把讨价还价的摇摆空间降低。

 

1、技术人员通常更愿意坦诚相待，如果依赖察言观色来沟通，技术人员多数是吃亏的一方

2、工程师多数会高估自己的能力，而不是低估自己的能力

3、开发工程师多数容易做乐观的估计，而不是悲观的估计，当然，测试工程师可能反之

 

最后了解工程师的思维，对QA是有帮助的