强人PM与敏捷相遇 -2

虽然想把这些敏捷有关的精神导入团队中，但自己仍不愿意对外说在执行敏捷的流程。其中一个最大的差异，是在工作分配/指派的方式。

我理解中的敏捷流程，在评估一个任务时，会有个估计的流程，让团队成员讨论为什麽自己是这样估计任务的时数。这个流程在我的认知中，这是一个无法理解的流程。而我也相信这流程就是我夥伴所谓的需要非常对等的工作能力才能执行的一个流程。如果缺法对等的能力，那麽这个流程很容易变成形式，就跟每天15分钟站立会议一样，在内部被画上最多黑人问号的一个流程。

因此，我一直认为任务的分配上应该用"战略思考"的角度去做分派，而不是用点数竞标价高/低去拿案子，甚至变成燃尽图消耗工作时数的伎俩。

传统上主管都会把专案分配给自己最信任的同仁，或者谁都信不过，只能自己来。以这个模式进行，我想这就是众所周知操死人最好的方法了。但我的分派原则却一直都是，同仁中谁有最相近的专案经验可以衔接，或者谁最缺这个专案核心价值的认识，就派该同仁去执行这个专案。但如果这个专案过於庞大，我就会与技术主管讨论怎麽拆解成两三个适当大小的专案，依照上面的逻辑去分配。

分配当下会明确告知同仁为什麽把这个任务交付给他，并且约定时间请他提出对应的架构规划与做法，请他在大会议上说明细节，让资深的同仁一起帮忙审核与确认是否有细节上的疏漏。开工後续也是定期的回报工作进度，我们也在这过程中拟定上线前的测试方式，压测预估数值等，而验证的方式也可能会变成另外一位同仁的专属任务，用这样的方式可以加速普及相关的商业逻辑给多一点人知道，提高未来维护时的效率。

有人会问我：这样做，只要有时间都没问题，如果专案时程赶，那该怎麽办? 其实我对於"时程很赶"的专案，都一直有很多的疑问。除了线上BUG问题有限时修复的需求外，每一个需求的形成应该都有迹可循，指是敏感度是否足够发现而已。通常一个需求的发起，势必在某些业务群体中会有许多可行性的评估讨论，或者试探性的询问过。在这个情况下，我也都会很直白地告诉我的技术团队，目前正在进行某某事项的讨论，发展方向可能是什麽，是不是能在内部能先做某层面的评估，好让我届时可以在主管面前第一时间作出好的建议或者决策。

一开始团队对於这样的评估觉得很厌烦，但是在这边传达一个概念：「技术需要服务商业，我们才有存在的价值。今天我们被出这些考题，那不就是一个让同仁熟悉系统架构的机会吗?透过模拟需求的实作，有一个最低成本的方式考考同仁是否有正确理解系统架构，找到适合的切入点。」

我大概是用这样的方法，当工作派下来的时候，我已经领先完成了时程评估的工作，直接进入开工；而开工过程中可以得到比较高的开发品质，也在於不断的让同仁在既有架构中模拟开发，透过思辨累积多种专案形式样貌，获取不同经验。