Управление знаниями в привлечении Tinkoff: при росте команды от 10 до 150 и путь от Confluence до Neo4j

Александр Поломодов
Руководитель разработки в привлечении, Tinkoff
SECR 2019

Когда ваша техническая команда за 3 года растет с 10 до 150 человек, очень сложно обеспечить ее устойчивость, управляемость и эффективность на всем протяжении этого пути. Микроменеджмент в данной ситуации не работает. Зато работает принятие некоторых принципов и правил, которых надо придерживаться новым сотрудникам, чтобы приносить пользу. В своем докладе автор расскажет о том, какую информацию они заносили в свою базу знаний, как обеспечивали ее актуальность и как использовали ее для решения hr-вопросов. Расскажет про интеграцию Confluence и графовой базы (Neo4j) для анализа информации в разрезе команд, сотрудников, продуктов, проектов, открытых позиций, а также для помощи в принятии hr решений.

Transcript

1. “Knowledge sharing” In growing team From Confluence to neo4j
2. Hello I am Alexander Polomodov I am head of software development at acquisition dep of Tinkoff. Previously I was developer, teamlead, project manager ... You can find me at fb.com/alexander.polomodov 2
3. What is Acquisition Department ☐ Unauthorized web of tinkoff.ru, tinkoffinsurance.ru 3
5. What is Acquisition Department ☐ Unauthorized web of tinkoff.ru, tinkoffinsurance.ru ☐ Content management system for web and mobile 5
9. What is Acquisition Department ☐ Unauthorized web of tinkoff.ru, tinkoffinsurance.ru ☐ Content management system for web and mobile ☐ System for a/b tests and personalization 9
12. What is Acquisition Department ☐ Unauthorized web of tinkoff.ru, tinkoffinsurance.ru ☐ Content management system for web and mobile ☐ System for a/b tests and personalization ☐ System for acquisition channel automation (context,social,media ...) 12
13. Why we Need Knowledge sharing 13
14. 14 Head Count Relations Date
15. 10 15 Simple & Inside teams Head Count Relations Late 2016 First Steps Date
16. 10 30 16 Simple & Inside teams Simple & cross teams Head Count Relations Late 2016 Middle 2017 First Steps Date
17. 10 30 70 17 Simple & Inside teams Simple & cross teams Complex & cross teams Head Count Relations Late 2016 Middle 2017 Early 2018 First Steps Middle Level Date
18. 10 30 70 18 Simple & Inside teams Simple & cross teams Complex & cross teams Head Count Relations Late 2016 Middle 2017 Early 2018 Middle 2019 150 Complex & cross teams & deps First Steps Middle Level Advanced Level add graphs Date
19. Let’s go 19
20. 10 30 70 20 Simple & Inside teams Simple & cross teams Complex & cross teams Head Count Relations Late 2016 Middle 2017 Early 2018 Middle 2019 150 Complex & cross teams & deps First Steps Middle Level Advanced Level add graphs Date
21. What we Had (Late 2016) ☐ Jira as issue tracker 21
22. What we Had (Late 2016) ☐ Jira as issue tracker ☐ Confluence as wiki system for documentation 22
23. What we Had (Late 2016) ☐ Jira as issue tracker ☐ Confluence as wiki system for documentation ☐ Git as vcs and Bitbucket for hosting code 23
24. What we Had (Late 2016) ☐ Jira as issue tracker ☐ Confluence as wiki system for documentation ☐ Git as vcs and Bitbucket for hosting code ☐ Single jira project for all frontend teams, and jira projects 24
25. What we Had (Late 2016) ☐ Jira as issue tracker ☐ Confluence as wiki system for documentation ☐ Git as vcs and Bitbucket for hosting code ☐ Single jira project for all frontend teams, and jira projects ☐ Our confluence space mostly for business needs 25
26. What we Did (Late 2016) ☐ Create separate jira project for each product (front, back, highload) 26
27. What we Did (Late 2016) ☐ Create separate jira project for each product (front, back, highload) ◦ Change workflow as we want 27
28. What we Did (Late 2016) ☐ Create separate jira project for each product (front, back, highload) ◦ Change workflow as we want ☐ Create separate confluence section for each product (front, back, highload) with 28
29. What we Did (Late 2016) ☐ Create separate jira project for each product (front, back, highload) ◦ Change workflow as we want ☐ Create separate confluence section for each product (front, back, highload) with ◦ Teams structure 29
30. What we Did (Late 2016) ☐ Create separate jira project for each product (front, back, highload) ◦ Change workflow as we want ☐ Create separate confluence section for each product (front, back, highload) with ◦ Teams structure ◦ Tech documentation (faqs, instructions) 30
31. What we Did (Late 2016) ☐ Create separate jira project for each product (front, back, highload) ◦ Change workflow as we want ☐ Create separate confluence section for each product (front, back, highload) with ◦ Teams structure ◦ Tech documentation (faqs, instructions) ◦ Processes documentation 31
32. 10 30 70 32 Simple & Inside teams Simple & cross teams Complex & cross teams Head Count Relations Late 2016 Middle 2017 Early 2018 Middle 2019 150 Complex & cross teams & deps First Steps Middle Level Advanced Level add graphs Date
33. What we Had (Middle 2017) ☐ We hire people in all teams 33
34. What we Had (Middle 2017) ☐ We hire people in all teams ☐ We have opaque hiring process (strange mailing lists, unmanageable interview results for customers, ...) 34
35. What we Had (Middle 2017) ☐ We hire people in all teams ☐ We have opaque hiring process (strange mailing lists, unmanageable interview results for customers, ...) ☐ We get many newcomers 35
36. What we Had (Middle 2017) ☐ We hire people in all teams ☐ We have opaque hiring process (strange mailing lists, unmanageable interview results for customers, ...) ☐ We get many newcomers ☐ We need onboarding for them 36
37. What we Did (Middle 2017) ☐ Add structure in hiring (in our wiki) 37
38. What we Did (Middle 2017) ☐ Add structure in hiring (in our wiki) ◦ Add job descriptions 38
39. What we Did (Middle 2017) ☐ Add structure in hiring (in our wiki) ◦ Add job descriptions ◦ Add interview cards and process of its filling 39
40. What we Did (Middle 2017) ☐ Add structure in hiring (in our wiki) ◦ Add job descriptions ◦ Add interview cards and process of its filling ☐ Improve section for each product (front, back, highload) with 40
41. What we Did (Middle 2017) ☐ Add structure in hiring (in our wiki) ◦ Add job descriptions ◦ Add interview cards and process of its filling ☐ Improve section for each product (front, back, highload) with ◦ First day instruction 41
42. What we Did (Middle 2017) ☐ Add structure in hiring (in our wiki) ◦ Add job descriptions ◦ Add interview cards and process of its filling ☐ Improve section for each product (front, back, highload) with ◦ First day instruction ◦ Add tech roadmaps for products 42
43. What we Did (Middle 2017) ☐ Add structure in hiring (in our wiki) ◦ Add job descriptions ◦ Add interview cards and process of its filling ☐ Improve section for each product (front, back, highload) with ◦ First day instruction ◦ Add tech roadmaps for products ◦ Improve processes and its documentation 43
44. 10 30 70 44 Simple & Inside teams Simple & cross teams Complex & cross teams Head Count Relations Late 2016 Middle 2017 Early 2018 Middle 2019 150 Complex & cross teams & deps First Steps Middle Level Advanced Level add graphs Date
45. What we Had (Early 2018) ☐ We are large (70+ people) 45
46. What we Had (Early 2018) ☐ We are large (70+ people) ☐ We are hiring but smarter with head count quotas 46
47. What we Had (Early 2018) ☐ We are large (70+ people) ☐ We are hiring but smarter with head count quotas ☐ We need to improve onboarding 47
48. What we Had (Early 2018) ☐ We are large (70+ people) ☐ We are hiring but smarter with head count quotas ☐ We need to improve onboarding ☐ We split large teams into small 48
49. What we Had (Early 2018) ☐ We are large (70+ people) ☐ We are hiring but smarter with head count quotas ☐ We need to improve onboarding ☐ We split large teams into small ☐ We need to share our processes and tech products 49
50. What we Did (Early 2018) ☐ Create separate hr section (in our wiki) 50
62. What we Did (Early 2018) ☐ Create separate hr section (in our wiki) ☐ Create performance review process (see link in sources) 62
63. What we Did (Early 2018) ☐ Create separate hr section (in our wiki) ☐ Create performance review process (see link in sources) ☐ Create list of available trainings and process for requests 63
64. What we Did (Early 2018) ☐ Create separate hr section (in our wiki) ☐ Create performance review process (see link in sources) ☐ Create list of available trainings and process for requests ☐ Create postmortem process and postmortem templates (see link in sources) 64
65. What we Did (Early 2018) ☐ Create separate hr section (in our wiki) ☐ Create performance review process (see link in sources) ☐ Create list of available trainings and process for requests ☐ Create postmortem process and postmortem templates (see link in sources) ☐ ... 65
66. Add some confluence magic 66
67. How it works in Confluence Data And Reports ☐ Page Properties ☐ Page Properties Report ☐ Pivot Table ☐ Table Filter 67
70. How it works in Confluence Navigation ☐ Tabs Container ☐ Tabs ☐ Localtab Group ☐ Localtab ☐ Horizontal Navigation Bar ☐ Horizontal Navigation Bar Page ☐ Multiexcept 70
72. 10 30 70 72 Simple & Inside teams Simple & cross teams Complex & cross teams Head Count Relations Late 2016 Middle 2017 Early 2018 Middle 2019 150 Complex & cross teams & deps First Steps Middle Level Advanced Level add graphs Date
73. What we Had (Middle 2019) ☐ We are even larger (150 people) 73
74. What we Had (Middle 2019) ☐ We are even larger (150 people) ☐ We need tools for analyzing links between teams, employees, projects, vacancies, etc 74
75. What we Had (Middle 2019) ☐ We are even larger (150 people) ☐ We need tools for analyzing links between teams, employees, projects, vacancies, etc ☐ We need tools for visualization of team health and disorders 75
76. What we Did (Middle 2019) ☐ We decided to use graph database (i.e. Neo4j) 76
77. What we Did (Middle 2019) ☐ We decided to use graph database (i.e. Neo4j) ☐ Entities became Nodes 77
78. What we Did (Middle 2019) ☐ We decided to use graph database (i.e. Neo4j) ☐ Entities became Nodes ☐ Links became Edges 78
79. 79 The “whole” graph
80. 80 The “whole” graph
81. 81 “Leader - subordinate” graph
82. 82 “Teams - subteams” graph
83. 83 “Manager-TeamLeader-team” graph
84. 84 “Manager-TeamLeader-team” graph
85. 85 “Inner structure of one team” graph
86. 86 “Inner structure of one team” graph
87. 87 “Qa engineers distribution per teams” graph
88. 88 “Qa engineers distribution per teams” graph
89. Summary 89
90. Summary ☐ You need some regulated process for adding/updating facts 90
91. Summary ☐ You need some regulated process for adding/updating facts ☐ You need useful reports for participants 91
92. Summary ☐ You need some regulated process for adding/updating facts ☐ You need useful reports for participants ☐ You don’t need complicated system for knowledge sharing 92
93. Summary ☐ You need some regulated process for adding/updating facts ☐ You need useful reports for participants ☐ You don’t need complicated system for knowledge sharing ☐ You even can use confluence for simple cases 93
94. Summary ☐ You need some regulated process for adding/updating facts ☐ You need useful reports for participants ☐ You don’t need complicated system for knowledge sharing ☐ You even can use confluence for simple cases ☐ You can use graph databases for advanced cases with complex systems with many links 94
95. Sources ❏ Confluence Manual “Page Properties Macro” - bit.ly/2qanxF4 ❏ Confluence Manual “Page Properties Report Macro” - bit.ly/2N5lMSA ❏ Book “Graph Databases Specs” by Ian Robinson, Jim Webber and Emil Eifrem - bit.ly/32ZQRwK ❏ Try neo4j in cloud sandbox - neo4j.com/sandbox-v2/ ❏ “Tinkoff.ru. How we hire people and work with their motivation” by A. Polomodov - bit.ly/320YmSB ❏ “Tinkoff. Postmortem culture - how we learn on fuckups” by A. Polomodov - bit.ly/2q2pXWn 95 You can find me at fb.com/alexander.polomodov alexander.polomodov@gmail.com