以下内文节录自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怎麽处理专案的各种状况，也想想自己会怎麽解，会有一 些不同的学习、启发、体悟。 --

※ 发信站: 批踢踢实业坊(ptt.cc), 来自: 220.136.37.242 (台湾) ※ 文章网址: https://webptt.com/cn.aspx?n=bbs/P_Management/M.1615473647.A.BC3.html