It switched from operating public number " Ctrip Technology Center PMO " (ID: cso_pmo)
The following is my experience of a real project, any similarity is purely coincidental.
In late September 2018, due to the temporary departure colleagues took a project, is a line of business within the company to provide services outside the upgrading of IM tools, the goal is to develop their own line of business prior to each of the various IM tools Replace All new unified development tools, and knowledge base will migrate to the platform's latest AI platform.
Before the story, the background related items described under slightly so Tell me what you understand.
1, the project range: from a large access service lines are speaking more than 10 lines of business, as well as some internal service lines and different business forms small business service scenarios; each service will be divided substantially pre-sale, as well as to external supply of commercial platforms.
2, the existing tools: app about the outer end of the tool 2 to 3 from the line of business research tools, as well as micro-channel groups and the like; Online end of a separate tool, H5 also have separate tools, as well as their knowledge base.
3, the target user: user 1 is all the end user, the user is 2 seats each line of business services, user 3 is an external supplier. Within the company seating add up to about a thousand seats, and seat guests service tools to answer questions, there is the PC side, the phone side;
4, access workload: each line of business R & D team and our R & D team needs docking, docking complete new IM tools, and some lines of business due to the need to maintain complex business logic hierarchical allocation logic itself.
Background of the project
After taking over the project, the first step must be to understand the project background and objectives, understanding the second step after doing it? Familiar with the project team.
After several meetings, the basic organizational structure familiar with the project, involving six internal team, from outside to inside are:
1, app development end
2, app server development
3, the customer service end of the R & D
4, AI knowledge base development
5, BI research report
6, product manager team
Several team leaders have their own vertical reporting (functional structure)
After taking over what was found difficult is it?
1, there is a big line of business has access to the new IM tool, but has been producing gray verify there is no clear timetable for opening the flow;
2, while a large line of business he spent more than two years to develop a similar tool, users are very accustomed to, want to change more difficult;
3, the internal project team and more transparent information on the extent of the development progress of the teams is not high, especially in the slow pace of the FBI stage;
4, project milestones are not clear enough, and even some team members do not understand;
5, ready-made products can not cover the needs of all lines of business, many business lines have their own individual needs, it is difficult unified, so every access to a line of business workloads are not small.
6, leaders of the project completion time is too optimistic (the end of December to complete all lines of business access). I would like to take over the access to a large line of business. To be completed in three months time access, very difficult, internal project team dubbed "mission impossible."
For these projects background, organizational structure, known issues, has taken some of the following measures:
1, for the architecture, the introduction of large-scale agile mode, I was appointed project SM, responsible for overall project schedule and milestones external coordination, upgrading important issues;
2, the product development team as the team enters each PO and part-time SM, responsible for product demand strip lines and priority arrangements, is also responsible for the communication needs of BU, and each PO will be responsible for docking a large business lines;
LeSS framework
3, strengthen inter-team communication: do the "centralized office" "War room" "overtime dinner together" and so on. Fortunately, these development team basically in a floor, communication is more convenient, and then I moved to their side from the other floors, work together. War room mainly to account for a small meeting, our day will stand, interim meeting in the War room; overtime natural inevitable, different teams every day and eat dinner with the way students understand some of their work on the project overall progress has been very helpful.
4, daily stand will be. In addition to each organization's own development team will stop large project team will stand will be a day, team leader and PO to attend, will review the important events in addition to white, the main problem is the impact of various stations; of course, as the SM needs to control conference we use the whistle, a loud bell to cope with the chaos we discuss the problem. Details, usually after the station will leave the relevant students to communicate again, the station will only need to be clearly responsible for problem resolution time and requirements.
5, physical Kanban, I maintain. According to general release rhythm billboards 2-3 weeks, indicating the milestones, the current phase of the main tasks and milestones. Detailed requirements or tasks in each team's whiteboard. Before starting each iteration will, according to milestones, break down tasks to each team, especially the FBI need each point, a clear responsibility and point in time. After each team received the task of internal re-subdivision.
Team physical Kanban
6、会议：每个冲刺都有启动会和回顾会。启动会明确目标、团队进行扑克估算、分解任务，认领任务。回顾会：暴露问题，总结经验。
携程定制估算扑克
7、“虚拟专家组织”：因为涉及开发team比较多，在遇到一些技术问题，尤其是架构性问题时，需要有一些“专家判断”，所以组织了一个虚拟组织，每当有一些重大技术问题需要拍板时，有他们进来做分析判断。
虚拟专家组织
8、先打一个有把握的胜仗。对于一个周期较长的项目，能取得阶段性的成绩并让大家看到，这对项目推动有积极的作用。我在接手项目后，第一时间和前面提到的“已上线但迟迟无法开流量”的大业务线取得沟通，非常幸运的是这个大业务线的联系人非常负责也很细心（当然也因为太细心提了很多问题，哈哈）。和这位联络人沟通后，我拿到了开流量前置问题的list，然后立马在内部召集各team开会一一过问题（记得大概是50多个问题），然后看下来这些问题都可以解决的。Sure，作为最高优先级处理。很快，一个迭代，这些问题都得到了解决。然后这个业务线在10月下旬开放了流量，打了第一个胜仗，也吹响了全面进攻的号角。
携程自研项目管理工具iKanban
9、Checklist：综合之前项目的经验，我梳理了一个checklist（在confluence全团队可见可维护），标注了需要完成的业务线、对应联系人、计划上线时间、前置任务（比如知识库维护、分配逻辑联调、入口发布、AB分流配置、外部依赖项等）、流量开放任务，完成的事项就打上勾，没完成的会主动去push完成。这样一来，全团队对项目整体的状态、下一步方向都心里有数。
10、到一线用户中去。因为是一个偏业务产品的项目，实际用户的体验和反馈对我们尤其重要，所以我们要到一线去。除了去上海的服务部门职场外，我们还去了南通服务职场，和一线操作用户进行了面对面现场的沟通，了解他们的实操场景及诉求，对于我们了解需求、需求设计有了非常好的帮助。
和用户一起工作
11、借助外部或高层力量。这个项目可以算是公司级别，涉及全公司的服务部门，所以公司服务中心会有专人监督和支持我们项目，他们会定期召集BU和我们一起沟通问题、解决问题。有些我们搞不定或者认为不合理的问题，就会拉上他们一起和业务线协商，也感谢他们的支持。
12、抓大放小。我即是项目经理，也是大规模敏捷群的SM。因为这个项目过于庞大复杂，工期又紧。需要关注处理的事情非常多，如果作为大SM过于关注细节问题，自然你会漏掉一些重要事件。所以，你必须抓大放小（当然不是完全不管，而是授权给其他同学去负责）。作为敏捷群的大SM需要对项目有一个high level的总览思路，牢牢抓住为达成总目标服务的关键事件并去完成它。（实际上前面提到的checklist也有异曲同工）
最后，故事要讲完了，说下目前项目完成情况。截止18年12月底，目标范围的业务线全部完成接入，当然项目还没最终完成，因为新老工具的流量还在逐步切换，欲知后事如何，且听下回分解。