以下内文节录自blog拙作 https://lnkd.in/gSB_g_X
背景
这个实际案例是公司的其他PM所领导的专案所面临的困境，并非我自己实际参与；但也因
为这样，比较容易从旁观者的角度来观察，在与该PM的讨论过程中，我也竭尽所能给了一
些建议，期待能有些突破，对专案能有所推展；当然也希望自己永远没有机会陷入这种窘
境。
这个产品事业部在公司内部相对是比较小的营收份额，但其实也存在已经有十多年了；也
许由于工业领域的关系、而产品技术相对门槛比较高些，新产品研发速度相对缓慢很多。
而近来又由于软件架构要改朝换代，新产品开发的时程估算出来，光baseline就拉了2-3
年之久。而更复杂的是，软件研发团队又人才尽失、近半年走了很多主力战将，更让整个
专案雪上加霜。
第一次冲突
由于专案复杂度高、软件主管在评估资源分派、时程的时候，相对保守，且必须顾及内部
组成、避免更多人才流失，一开始抓baseline就拉了2-3年之久，其中包含了，SQA test
plan在年久失修的情况下，也得趁这次产品软件架构要改朝换代，需用比较系统化的方式
建立test plan。PM在缺乏其他专案资讯可以参照的情况下，且有专职的SW PM，没办法
challenge 专案团队规划出来的project schedule/resource baseline，就先这样执行了
几个月。
但在几个月后，与最高主管的staff meeting中，第一个milestone就出现问题：SQA测试
不下去，原因是RD交付的项目有blocking issue导致无法按照原始规画的范畴完成验证。
在最高主管面前，RD、SQA团队当然是互相攻讦怪是对方的错。因为此研发专案的时程很
长，且critical path取决于软件开发的进程，所以PM, RD, SQA三方合议、在主管的同意
下采取"Agile"的开发方式：也就是当RD开发到一定程度后﹝所谓one sprint﹞，就提供
给SQA做部分验证跟测试，以避免又出现blocking issue导致SQA无法完成验证。
第二次冲突
如此又过了两个月，在第二次向最高主管报告的时候，最高主管当场才猛然惊觉，规划出
来居然最快要两年多才能上市，当场震怒！又开始RD、SQA互相指责，指称对方才是主要
罪魁祸首的原因；RD、SQA也都声称都是因为资源不足等等，无法满足公司期待的目标；
PM站在旁边只能傻眼，不知如何进行下去这还有2年要开发的日子，心也冷了…
稍微正面一点是，至少最高主管现在开始重视这个团队问题，要求要有月检讨会议，并针
对专案目前的issue、schedule update等作检视。
我的看法
专案管理手法
一开始建立project baseline的时候，软件相关这种架构性的大改造，的确非常难评估其
efforts；我建议一样要先以产品要上市的预期时间，往回倒推，PM先以商业利益优先先
列出大方向的milestones & date (也许是以"季"为单位)；之后交付软、硬件、SQA等协
同的团队，一起再将milestones breakdown列出可能要有的小里程碑。并好好管理团队内
部可能有的比较"次要"的任务；比如开发中的design documents、QA survey测试计画建
立的系统等时程。的确这些任务不是不重要，但其实不紧急。缺乏以商业角度出发的主要
目标，会导致专案团队以处理自己眼前任务的逻辑bottom-up规划时程，完全偏离组织、
或公司的要求。长远而言，就会造成产品没有竞争力、公司越来越不重视这条产品线，当
然就团队士气低迷、人才尽失。
“人”的管理
其实PM在整个讨论过程中非常重要，但很可惜的是，连主要stakeholders的要求都没有弄
清楚。schedule在第一次发生团队纷争的时候，就应该表明给最高主管，让他清楚知道其
实这个新产品上市时间，已经严重偏离市场期待。当下就可以要求团队一起想办法解决；
而且，PM就可以拿着“尚方宝剑”，有更高的权力要求RD、SQA主管想办法把不重要的任
务先摆到后头。RD主管、SW PM其实mindset也许在行之有年的氛围下，也变得不注重时程
；这更需要最高主管的当头棒喝，要不靠一个PM在后面抽鞭子，其实鞭长莫及，也没有效
益。
结论
不知道大家看完这个案例分享，是否也有其他可能的解法？在我PM职涯中，即使不是我领
导的专案，我还是会看看其他PM怎么处理专案的各种状况，也想想自己会怎么解，会有一
些不同的学习、启发、体悟。