公司的IT部门

IT不是超然於世的部门，而是运作於公司的一部分

甫加入公司的时候，已经有一个又一个的专案在进行着，有着现有的平台需要维护，有着现有专案要处理，因为我的号召，现在又多了一个新平台要开发，在初期，我犯了第一个错误，为了sprint而sprint，略知皮毛，就开始构筑起表面规则，所有工程师都得同时处理日常业务(Business as usual, BAU)和开发业务，而BAU又时常越线，需要更多时间处理，有更急的时限，想当然，讲求commitment的sprint永远都无法达标。这时候，我凭了我自己的想像，用google sheet兜了一个需求管理介面，其功能就只是简单规范与纪录需求，并没有直捣核心问题，同时，也让IT团队又只能沈浸在BAU中。这时候，因为要开发新平台一事，备受关注，被期待所发挥的杠杆效应，也就压上了时限，这个时限当然也蕴含了我天真的浪漫，而且以营运的脚步，本来也没办法让我们用slow motion缓步进行，部属们当然反弹了，这一次，我重新把团队切分成BAU的小组和开发的小组，这样的确也解决了部份问题，但也制造了下一个问题，BAU小组的人工作变得无趣也常收到需求单位的陨石要求，开发的人正式更远离需求单位，更不了解需求单位的需要，所以，这一次的重启，大家压力大、我的压力大、需求单位继续痛，所有问题都没有被解决，再一次宣告失败。在这过程中，并非毫无可取之处，但就是因为这样士气才会被打击的严重，工程师所做出来的东西，是花心思的，设计师对於功能想像，是有巧思的，但问题是，无法解决需求单位的问题，即便完成超mega平台，也是徒劳。IT是公司的一部分，每一个部门都有其运作方式与特性，如果单就一个部门来看，可以很简单想像其所具备的文化与管理方式，但是，当要多部门运作时，就不是倾向某部门设计，就能得到好结果。再加上公司运作是需要具备市场竞争力的，更不可能有机会让我们慢慢来，一切就变得更加艰难了。

从深入了解开始

好的部门合作，不是依存某个部门主角，而是用好的想法相互影响

产品经理一个必备技能，就是掌握所有利害关系人，也需要搭建好的沟通桥梁，让好的经验可以互相流动，这样也能让每一份工程师之力，妥妥地与需求单位的痛串接起来。因此，再来一次，我向主管与团队表示，我想从了解需求单位开始做起，也让IT团队不要急於新平台的开发。我做的第一件事是，让每一件BAU可以被记录下来，让我可以了解需求单位的痛与IT团队的需要，这里有两个很重要的思维，一个了解自己擅长之处，另一个则是确保让大家愿意配合。当下我知道，需求单位为求快，所以不愿意有个表单纪录细节，只要透过通讯软件或是口头叙述，就要让工程师开始动工。资工出身的我，我很清楚这样的行为已经踩了无数个工程师地雷，我心中已经盘算好，规格和时间掌握是我首要任务，以此为前提，我投身於需求单位，倾听他们的需求，将他们不愿意填写需求表的原因，一个个询问出来，同时传达工程团队需要的元素，让第一个基础桥梁被打造出来，这张需求沟通表，现在是我很重要的迭代基础，陆陆续续被改了好几次版，每一次都是将IT团队需要的、需求单位想要的做一次串接，力求将双方的沟通差距缩小，在这张表里面，我可以拉出许多数据观察，更重要的是让IT和需求单位好的思维：像是运营所需的节奏、对於开发所需预留的缓冲概念等相互影响。过程之中，产品经理扮演相当重要的权衡角色，就如同之前有提过的，没有所谓的best practice，只有最适合这个团队的方式，产品经理需要掌握三大元素：使用者、技术、利害关系人，能知晓如何配置三大元素，并让其可以流动，才有机会可以打造IT文化，因为IT团队不是独立运作的部门，而是公司的一部分！