用第一次成功建立信心

给予空间、给予适应、不限方式，让团队创造第一次成功

制定了目标、习惯以团队思考、有了些管理工具、也有一群在乎使用者痛点的IT夥伴，那就要创造一次成功经验了！为了要让IT团队成功创造使用者有感的效益，身为产品经理的我，可是下足了不少功夫，在今年初组织调整之後，我手边的IT资源是一名全端工程师、两名实习生，直到正职的两位全端工程师加入，我约莫有半年的时间，在持续作战的状态下，边掌握边收敛、边照镜子边影响窗口，让IT团队可以具备足够的资源与条件下，建立第一次的成功。我做了以下几件事情：

1. 给予空间
2. 给予适应
3. 不限方式

给予空间

空间包含时间上的空间和技术上的空间，我相信一位优秀的工程师一定会致力於在单位时间内创造最大价值，在蹲点使用者等待IT新血加入时，我把时间先拉出了缓冲时间(理论上，缓冲时间应该是由工程师依据自身能力与工作状态，衡量并估时)，让所有需求对接窗口感受到并且接受其必要性，一位资深工程师告诉我：「IT在做的事，是创意发想型的工作，所以都会有风险」，缓冲时间便是为了风险而预留。而後，我依据时间的用途，先为工程师留下会议的时间，让他们在忙於BAU之际，有机会停下脚步，彼此分享工程做法或是检视自我的程序。时间上的空间，我的重点放在，将这样的mental model传达出去，同时掌握着IT时间的主导权，让我可以为IT严守时间资源，使其可以同时进行BAU、开发、会议。参与公司部门运作的人都知道，只要讨论到资源议题，就会引起反弹，获得主管支持、促使工程师能协助正向呈现效益、不厌其烦的沟通，在这个过程都没有少过。相较之下，技术上的空间就简单许多，过去我会习惯性，很快跳到解方设计，让问题的表述让淡化，这样造成工程师的input受限，也会让自己很容易成为扞卫解方的人，现在，我着重於问题表述，为了加速讨论流程，我会以抛出提案但不限提案的方式，让工程师可以参与解方发想，比起怎麽解决，我现在花很多时间在为何要解决，而这样和工程师间，我们是共同的关系，而不是彼此挑战、检核的关系，可以增加更多信任感。

给予适应

当IT新血加入时，彼此尚不熟悉、对公司不熟悉、对业务不熟悉，所以我们没有急於启动打造IT的软件开发文化，设定以1个月为期，让新来的工程师可以探索遍BAU，仰赖於过去半年的累积与收敛，我开始可以为BAU分类，并在配给或安排任务的时候，确保每一位都可以经手不同类型的工作，使新工程师可以将触角放到最大，因为是人力资源的扩充，所以我请原本的工程师夥伴，退居幕後，协助新夥伴的第一线处理业务，当然，我会记下这类型业务是否为新夥伴的第一次接触，第一次会为其保留更多时间，之後缩短。同时，我也会藉由新夥伴的视角，来看现行做法有无可以更好的地方。

不限方式

没有任何一套方法是可以直接套用的，我们或许很想要导入Scrum，但是要达到scrum，需要打通很多环节，比起了解新方法，我们花更多心思想要了解现在的自己和现在的团队，所以在这次开发时，虽然我们有用到一些Scrum常用的工具，我们并非高举着Scrum大旗说，要用Scrum的方式进行。除此之外，包含要使用什麽管理工具等，我们都不急於当下决定，一个Notion、googlesheet、白板就支撑起了第一次开发。这让我们更能感知我们的现况，知道团队缺少的、找到初步和使用者沟通的切口。

在有SMART的目标基础下，和这些条件基础下，我们成功地打下第一次成功，中间当然不乏产品经理和工程师之间的拉扯，在接下来的两天，我们会持续探究如何促成彼此信任感的建立，当然，这是我到目前的经验，信任感这件事，是每天每天没有终点的团队课题。