About spaceships and "space". How to make a feature by changing the whole product on the way
On April 24, an important change occurred in the Wrike platform: the team announced a public release of the new feature - “Spaces”, in the Russian version - “Space”.
The goal of Spaces is to improve the work of teams in the task manager and simplify navigation in the product, making the processes more organic and transparent. Did we succeed? Keep reading and learn how to roll out major updates in a large company and not screw it up, how to ensure the interaction of 30 scrum teams and what lessons we have learned from the product development process, the release of which cost ussweat and blood with a lot of effort and breakthrough team spirit.
Why were the Spaces invented?
When Wrike was created, it was focused on solving the problems of the effectiveness of small teams of 15-20 people. It is convenient for such teams to work in one place where there is “space” for all.
Over time, account sizes multiply increased. Now the product is used by distributed teams in accounts with thousands of people, and in the future we see Wrike as a convenient tool for the work of many departments of the company: on the one hand, working in different processes, on the other - still having the need to interact with each other.
')
Since in the real world teams exist in different offices, offices, countries, the Wrike team thought about creating a special space for them so that they could work simultaneously within their own process and not lose contact with other departments.
Spaces allow individual workgroups to effectively set up a workflow: give them the tools and data structure they need, access to various forms of requests so that they can organize their own workspace and act more intently. Also, Spaces allows you to better control the distribution of information in multi-functional teams and increase data security.
The idea of creating Spaces belongs to Sasha Plotvinov and Van Saveliev, product managers of Wrike. At first they conducted research, drew a prototype solution for teams on the blackboard, collected mockups, and outweighed the idea. Later it was finalized on the Wrike Hackathon , where they took a step to the side and assembled a prototype of Personal Space, which complemented the concept.
“Spaces” is, first of all, a feature for teams. However, it is based on the concept of personal life space, which everyone needs to eliminate unnecessary information and background noise.
What problems do Spaces solve?
If simplified, then Wrike consists of projects and tools for working with them. For example, working on a complex release, you create a number of projects, monitor their progress through the Gantt chart, control the loading of teams with Workload, and, based on the results, compile a report for stakeholders.
It seems to be simple, but if you have thousands of people working in one account in a large number of commands with overlapping processes and many tools are used, two problems appear: it becomes difficult to manage the processes and the user interface is overloaded with unnecessary elements .
It was
has become
Such obstacles to effective teamwork arise for a number of reasons: firstly, in the same folder tree there are many teams adjacent; the user constantly sees irrelevant information and may inadvertently disrupt the structure of the “alien” team. Secondly, only administrators have access to process management, and the structure of the account is often formed by the main managers-administrators.
During the development of Spaces, we came to two key tasks:
Wrike is one of those companies that believe that horizontal management benefits from vertical management, and “turquoise” organizations show themselves from the most efficient side. The approach implemented in Spaces will help the team reach a new level of transparency and self-organization, where horizontal management will prevail.
- Ivan Saveliev, Product Manager, Wrike
What difficulties have we encountered?
Of course, significant changes in the product carry great risks and a number of difficulties. Here are some of them:
Difficulty 1. Smooth risks.
Adapting an account for a new way of organizing work is quite a laborious task. Inside Wrike, the problem was discovered almost immediately: as a company with many teams and processes, we fall under the category of clients, which we consider to be our own audience and use our product every day. Inside the team account (more than 800 people from all international offices) we launched releases and immediately received feedback from the inside - this helped prepare for a public release and maximize risk mitigation in advance.
For those who have never used Wrike, in the initial stages we conducted a series of solution-interviews, started testing using the UserTesting service, and also made an early access program to the Spaces functionality for customers who want it.
Before launching to the entire audience, we also conducted A / B testing on new trials to make sure that the new navigation paradigm is intuitive to new users. From testing it became clear that new users successfully begin to use the product. We also interviewed the test and control group and found that among the respondents, users more often talked about the understandability of the interface and the ease of use of Wrike.
Difficulty 2. Deliver the value of the solution to the client
Wrike has a lot of customers who already use the service and set up their workflows, so there was a risk that the new functionality would be perceived reluctantly.
We launched a private beta for key customers and connected our Professional Services department to the process.
In order to bring the problem, and, subsequently, and its solution to customers, Customer Success managers together with account administrators identified problems of organizing processes at an early stage and told customers how Spaces could solve them. Thus, we broadcast the maximum value of Spaces, which outweighed the cost of redevelopment. We didn’t just suddenly “roll out a feature”, but systematically prepared clients for its appearance: Customer Success managers conducted webinars, taught clients to navigate in the new functionality, did training email-broadcasts, told about best practices.
Later, we did not make any calls at all: the clients themselves began to come to the early testing program and use the new features.
Difficulty 3. One improvement requires many changes.
Platform improvement affects different aspects of the product, and we decided to take on the modernization, so as not to stand in one place. We were lucky with the development team, which unleashed the most incredible technical units and found the best solutions throughout the project. In addition, everyone understood the need for this initiative, so we always had strong support from VP and the CEO.
From the very beginning, the development team decided to create a minimally coherent architecture, turning the entire solution into a set of separate business components and gadgets that integrate and interact with each other only in the Workspace (the final product that the user Wrike sees).
For these components a separate repository was created, including a sandbox. It was possible not only to see each component in action and show it, for example, on the sprint review, but also to conduct its full development and testing. Assembly, unit test and autotest runs took an order of magnitude less time than when developing in a full-fledged Workspace. This allowed developers to quickly iterate, showing the results at the end of each sprint, and, if necessary, promptly make changes to both the functionality and the API. After some time, the next step was taken - creating a kind of “playground”, on which a highly simplified interface of the main product was created, which includes the integration of most components. This allowed to design and debug their interaction with each other.
How did the teams interact?
Wrike has about 30 scram teams working on their own part of the product, each of which is either affected by features now or will be included in the process in the short term. The question of team interaction during the development of Spaces sometimes arose very sharply, because each team has its own food OKRs per quarter.
The question of communication was a priority: where it was possible to discuss everything in advance, to agree and formalize the arrangements, the interaction was better than with those teams with whom there were no preliminary discussions. In the latter case, the development team had to make edits or modify someone else's functionality.
- Alexey Kartavenko, Frontend Teamlead
The number of problems that arise when 30 teams interact with each other in a very intensive agile environment should not be discouraged. For almost any company, setting up a scrum process is already an achievement, and scrum of scrums is a fantasy: here both product managers, leads, and ordinary developers must learn to work with each other.
These are the tips that the Spaces team gives to those who are preparing to make a big project:
The goal of Spaces is to improve the work of teams in the task manager and simplify navigation in the product, making the processes more organic and transparent. Did we succeed? Keep reading and learn how to roll out major updates in a large company and not screw it up, how to ensure the interaction of 30 scrum teams and what lessons we have learned from the product development process, the release of which cost us
Why were the Spaces invented?
When Wrike was created, it was focused on solving the problems of the effectiveness of small teams of 15-20 people. It is convenient for such teams to work in one place where there is “space” for all.
Over time, account sizes multiply increased. Now the product is used by distributed teams in accounts with thousands of people, and in the future we see Wrike as a convenient tool for the work of many departments of the company: on the one hand, working in different processes, on the other - still having the need to interact with each other.
')
Since in the real world teams exist in different offices, offices, countries, the Wrike team thought about creating a special space for them so that they could work simultaneously within their own process and not lose contact with other departments.
Spaces allow individual workgroups to effectively set up a workflow: give them the tools and data structure they need, access to various forms of requests so that they can organize their own workspace and act more intently. Also, Spaces allows you to better control the distribution of information in multi-functional teams and increase data security.
The idea of creating Spaces belongs to Sasha Plotvinov and Van Saveliev, product managers of Wrike. At first they conducted research, drew a prototype solution for teams on the blackboard, collected mockups, and outweighed the idea. Later it was finalized on the Wrike Hackathon , where they took a step to the side and assembled a prototype of Personal Space, which complemented the concept.
“Spaces” is, first of all, a feature for teams. However, it is based on the concept of personal life space, which everyone needs to eliminate unnecessary information and background noise.
What problems do Spaces solve?
If simplified, then Wrike consists of projects and tools for working with them. For example, working on a complex release, you create a number of projects, monitor their progress through the Gantt chart, control the loading of teams with Workload, and, based on the results, compile a report for stakeholders.
It seems to be simple, but if you have thousands of people working in one account in a large number of commands with overlapping processes and many tools are used, two problems appear: it becomes difficult to manage the processes and the user interface is overloaded with unnecessary elements .
It was
has become
Such obstacles to effective teamwork arise for a number of reasons: firstly, in the same folder tree there are many teams adjacent; the user constantly sees irrelevant information and may inadvertently disrupt the structure of the “alien” team. Secondly, only administrators have access to process management, and the structure of the account is often formed by the main managers-administrators.
During the development of Spaces, we came to two key tasks:
- The user should only see what is relevant to him.
- Delegation and self-organization should come to the place of vertical management.
Wrike is one of those companies that believe that horizontal management benefits from vertical management, and “turquoise” organizations show themselves from the most efficient side. The approach implemented in Spaces will help the team reach a new level of transparency and self-organization, where horizontal management will prevail.
“If earlier the account administrator had a high degree of responsibility for the processes, now he will be able to entrust the organization of the team’s workflow to its immediate manager, who is often better aware of the peculiarities of his team’s work.”
- Ivan Saveliev, Product Manager, Wrike
What difficulties have we encountered?
Of course, significant changes in the product carry great risks and a number of difficulties. Here are some of them:
Difficulty 1. Smooth risks.
Adapting an account for a new way of organizing work is quite a laborious task. Inside Wrike, the problem was discovered almost immediately: as a company with many teams and processes, we fall under the category of clients, which we consider to be our own audience and use our product every day. Inside the team account (more than 800 people from all international offices) we launched releases and immediately received feedback from the inside - this helped prepare for a public release and maximize risk mitigation in advance.
For those who have never used Wrike, in the initial stages we conducted a series of solution-interviews, started testing using the UserTesting service, and also made an early access program to the Spaces functionality for customers who want it.
Before launching to the entire audience, we also conducted A / B testing on new trials to make sure that the new navigation paradigm is intuitive to new users. From testing it became clear that new users successfully begin to use the product. We also interviewed the test and control group and found that among the respondents, users more often talked about the understandability of the interface and the ease of use of Wrike.
Difficulty 2. Deliver the value of the solution to the client
Wrike has a lot of customers who already use the service and set up their workflows, so there was a risk that the new functionality would be perceived reluctantly.
We launched a private beta for key customers and connected our Professional Services department to the process.
In order to bring the problem, and, subsequently, and its solution to customers, Customer Success managers together with account administrators identified problems of organizing processes at an early stage and told customers how Spaces could solve them. Thus, we broadcast the maximum value of Spaces, which outweighed the cost of redevelopment. We didn’t just suddenly “roll out a feature”, but systematically prepared clients for its appearance: Customer Success managers conducted webinars, taught clients to navigate in the new functionality, did training email-broadcasts, told about best practices.
Later, we did not make any calls at all: the clients themselves began to come to the early testing program and use the new features.
Difficulty 3. One improvement requires many changes.
Platform improvement affects different aspects of the product, and we decided to take on the modernization, so as not to stand in one place. We were lucky with the development team, which unleashed the most incredible technical units and found the best solutions throughout the project. In addition, everyone understood the need for this initiative, so we always had strong support from VP and the CEO.
From the very beginning, the development team decided to create a minimally coherent architecture, turning the entire solution into a set of separate business components and gadgets that integrate and interact with each other only in the Workspace (the final product that the user Wrike sees).
For these components a separate repository was created, including a sandbox. It was possible not only to see each component in action and show it, for example, on the sprint review, but also to conduct its full development and testing. Assembly, unit test and autotest runs took an order of magnitude less time than when developing in a full-fledged Workspace. This allowed developers to quickly iterate, showing the results at the end of each sprint, and, if necessary, promptly make changes to both the functionality and the API. After some time, the next step was taken - creating a kind of “playground”, on which a highly simplified interface of the main product was created, which includes the integration of most components. This allowed to design and debug their interaction with each other.
How did the teams interact?
Wrike has about 30 scram teams working on their own part of the product, each of which is either affected by features now or will be included in the process in the short term. The question of team interaction during the development of Spaces sometimes arose very sharply, because each team has its own food OKRs per quarter.
The question of communication was a priority: where it was possible to discuss everything in advance, to agree and formalize the arrangements, the interaction was better than with those teams with whom there were no preliminary discussions. In the latter case, the development team had to make edits or modify someone else's functionality.
“There were extraordinary cases: once we had to integrate a rather large and complex component developed by a third-party team before it was completed by this team (as a result, it appeared in our piece of functionality earlier than mostly). What to do - we tried to finish the work in the framework of Delaynas and had to get out. And the time that we spent on putting everything in order after the component was completed, we had to smear it with a thin layer when working on other features - the integration was planned for a long time! ”
- Alexey Kartavenko, Frontend Teamlead
The number of problems that arise when 30 teams interact with each other in a very intensive agile environment should not be discouraged. For almost any company, setting up a scrum process is already an achievement, and scrum of scrums is a fantasy: here both product managers, leads, and ordinary developers must learn to work with each other.
These are the tips that the Spaces team gives to those who are preparing to make a big project:
- As often as possible, discuss intermediate project options with different process participants, constantly collect feedback and look for additional food for thought.
- If what you are doing can be used internally (we are very lucky with this at Wrike), start a pilot project. Roll at all, inform everyone, run feedback forms!
- Determine the level of readiness at which you can enable the functionality of loyal customers: among them there are always those who like to keep up with the times and activate all sorts of experimental features. Their feedback will be especially valuable because they are your target audience. All early testing mechanisms are at your disposal: A / B experiments, limited and controlled rollouts of alpha and beta versions, Early Access on-demand access, etc.
- Balance between the speed of development and its quality, as on a surfboard: do not be afraid to leave technical debt in the current sprint, but immediately start the task to eliminate it as soon as the situation clears up. Do not forget to assign the highest priority to these tasks. It is short-sighted to make full coverage of the unit and auto tests of the functional, which can be changed after the feedback in the next sprint. Moreover, it’s not just stupid, but it’s criminal for the engineer to leave the trash code and allow him to reach the release.
- Try to prepare for each next sprint: conduct PBRs (Product Backlog Refinement), be sure to take into the current sprint the tasks for research on what you plan to do next, talk to the Product Owner and UX-designer as much as you see fit: pursue them in the kitchen and in the smoking room, clarifying the details. Try to synchronize the backend, front-end and testing in such a way that the interaction goes “overlap”, so that no one is idle, waiting for the readiness from colleagues of another specialization, not to have to sit on mocks, and then throw them out, etc.
- Closer to the release date, when passions run high and the bulk of work is transferred from developers to QA engineers, substitute your leverage for them: test your code yourself, start the regression, help with parsing, try writing autotests.
- When interacting with other teams, start regular discussions in advance on how you will do it. Write down all agreements and plans, generate documentation, you can even draw up contracts - not because someone will try to deceive you and not do too much, but because everyone has his own foam of days and your problems - only five percent of others. Synchronization of sprints - perfect, aspire to it.
- When using something developed by other teams, be wary of claims that “almost everything is ready, take and integrate”. First you have to figure everything out, if you don’t want to be trapped, blindly taking what is given and building your plans on it (especially the calendar ones).
- And the most important thing: not a single serious thing in a complex IT world is done with a click of your fingers, so if the project is in development for a long time, and they start to “look askance”, take care of your nerves and know: let it not today, but tomorrow or the day after tomorrow the endlessly slipping threads will intertwine, the fog will shatter and success awaits you - after all, you believe in what you are doing, right?
Source: https://habr.com/ru/post/454808/
All Articles