Analyzing Yumemi’s organizational structure from object-oriented perspective

Transcript

1. Analyzing Yumemi’s organizational structure from object-oriented perspective kkeeth @kuwahara_jsri @clown0082 Feb 16, 2020 Object-Oriented Conference #ooc_2020 #ooc_c
2. organizations which design systems ... are constrained to produce designs which are copies of the communication structures of these organizations. - M. Conway
3. Good Systems, Apps ↓ Good Design ↓ Good Teams, Orgs
4. Let’s start talking about organizational design of Yumemi
5. const my_info = { Workplace: ‘Yumemi Inc’, Position1: ‘Servant Leader of FET’, Position2: ‘CEO(secondary)’, Community: ‘Riot.js, Ionic, DIST’, PokemonGO: ‘TL40’ } About me
6. npm/~kkeeth
7. github.com/riot
8. Sorry 1 … This slide is made in English. But I am unfamiliar using English. So, I may have a wrong expression. Plz feedback for me called “Masakari” about my English!!
9. Sorry 2 … The title says “Analyzing ... from object-oriented perspective“, but it doesn't matter much ...
10. What organization model is better? When we consider Conway's law and others
11. Yumemi’s organizational design seems good “Factory method” pattern or “Abstract” pattern
12. but, after the organization is actually changed...
13. There are funny system ‣ Decide our salary by ourself ‣ Unlimited paid leave ‣ All members are CEO
14. It’s just Chaos
15. not be chaos, not do chaos, but, into chaos
16. Keep order in Chaos !!
18. There are 3 Simple Rules of Flocking Behaviors https://gamedevelopment.tutsplus.com/tutorials/3-simple-rules-of-flocking-behaviors- alignment-cohesion-and-separation--gamedev-3444
19. 3 Simple Rules Cohesion Seperation Alignment
20. Alignment adjust vector with companion
21. Cohesion steer towards the center of mass
22. Seperation avoid clashes with companion
23. evolve from there…
24. Agile Organization If there is an algorithm that adapts without someone ordering it, it can respond to change naturally Organizations are self-designed and adapt as a result in unpredictable environments
25. What is a team in an agile organization?
26. Theme. 1 Separate rolls for each teams
27. Back-end Designer Front-end Infrastructure Planner Manager A project team Business Tester
28. Back-end Designer Front-end Infrastructure Planner Manager A project has closed Business Tester finished/ closed
29. Back-end Designer Front-end Infrastructure Planner Manager B project team Business Tester
30. Back-end Designer Front-end Infrastructure Planner Manager B project team Business Tester Creating a new team from scratch is costly...
31. Now in Yumemi, teams are created by each EXPERTISE
32. Designer teams Front-end teams Back-end teams Business teams PM teams
33. Designer teams Front-end teams Back-end teams Business teams PM teams Pickup and show details!
34. Front-end teams Boolean Elements memento-mori
35. Front-end teams Boolean Elements memento-mori And other non-engineering teams so too. e.g. general affairs and accounting
36. A team is defined from “3S”
37. The definition “3S” Story Stakeholder Scope
38. https://note.com/raykataoka/n/nb6b7e5434ce8?creator_urlname=raykataoka
39. Story
40. Think about 4 “what”
41. What is the background of the team? What is the significance of the team? What is the purpose of the team? What the results do the team want? Story
42. Scope
43. Refers to the scope of activities, tasks, responsibilities, available resources and budget that the team should fulfill. • reasonable distance about the activities • don’t overlap too much • don’t separate too much Scope
44. Stakeholder
45. Composed of “3C + R”
46. Stakeholder name detail Committer ɾHave responsibility and pro-req rights ɾCommit continuously of team’s scope Contributor ɾSupport committer ɾCannot have pro-req rights Coach ɾCoaching ɾDo not interfere more than necessary (Rep) ɾTeam contact ɾResource management
47. How is in project?
48. Boolean Elements memento-mori
49. In plain words, our teams are like GUILD
50. Designer teams Front-end teams Back-end teams Business teams PM teams
51. Designer teams Front-end teams Back-end teams Business teams PM teams
52. Designer teams Front-end teams Back-end teams Business teams PM teams
53. Designer teams Front-end teams Back-end teams Business teams PM teams
54. Designer teams Front-end teams Back-end teams Business teams PM teams It’s just a chaos
55. Is that really good?
56. There are 3 caveats
57. • Open/Closed principle • Single Responsibility Principle • Interface Segregation Principle - Principles Of Object-Oriented Design
58. Anti pattern I have 3 roles… Rep A Rep B Rep C PM/Business There are many consultation Reps... developer, HR, marketer...etc …
59. Anti pattern Team A ❌ Team A Team B We don’t accept you're join. ❌ We don’t accept creating new team.
60. Theme. 2 Yumemi Inc is like as OSS
61. What is “Pro-req” ?
62. Pro-req is… Proposal review Request One of Yumemi’s systems
63. The members in Yumemi are all CEO(*secondary)
64. Being allowed things(examples) Create new teams/rules/ committees Change teams/ roles/office Create/Change rewards
65. Pro-req flow Stakeholder Committer 1. Create Proposal 2. Review ※ Don’t deny 3. Check Review 4. Need to modify proposal? merge 5. Push Yes No Post channel
66. After Pro-req flow(example) Local Production Staging Pro-req flow Pro-req flow Release Close Pro-req
67. Of course, we cannot create Pro-req directly to Production environment
68. There is a hard-and-fast rule, I think
69. Theme. 3 Others(various designs)
70. The good design of corporate organization must need learning and recruitment
71. In Yumemi… Advising Process Teal organizational concept
72. Everyone has the rights to decide All parties involved in the decision and experts must be consulted There is no obligation to take every opinion, but it is not a compromise All advice must be accepted and seriously considered Advising Process
73. Advising Process We have the right to decide Please advise to me ✅ foo ❎ boo ✅ bar ̋̋ ˚˚ ✕✕
74. I won't talk about recruitment. The people in charge of HR are so amazing
75. https://speakerdeck.com/clown0082/the-results-and-learning-of-one-year-of- referrals-adoption
76. • Open/Closed principle • Single Responsibility Principle • Interface Segregation Principle - Principles Of Object-Oriented Design
77. Roles and responsibilities Manager Designer Engineer Programmer ɾRequirement definition ɾCreate document(Project) ɾResource management ɾDesign(UIUX) ɾDesign(System) ɾCreate document(System) ɾCoding ɾCreate document(Codes) ɾCommunication and adjustment about specification of system/app ɾre-design(UIUX/System)
78. Summary
79. Teams are more object-oriented than expected, but based Chaos Keep order in Chaos Yumemi is like an OSS Summary
80. Great development experience with good organization design!
81. Publicity
82. We’re hiring web developers!!
83. There are other funny system ‣ Support for re:Invent, WWDC ‣ Qualification bounty ‣ Unlimited exercise system