Sobre espaçonaves e espaço. Como criar um recurso alterando todo o produto ao longo do caminho

Em 24 de abril, ocorreu uma mudança importante na plataforma Wrike: a equipe anunciou o lançamento público de um novo recurso - "Spaces", na versão russa - "Spaces".
O objetivo do Spaces é melhorar o trabalho das equipes no gerenciador de tarefas e simplificar a navegação no produto, tornando os processos mais orgânicos e transparentes. Fizemos isso? Continue lendo e aprendendo como lançar atualizações sérias em uma grande empresa e não estragar tudo, como garantir a interação de 30 equipes de scrum e as lições que aprendemos com o processo de desenvolvimento de produtos, cuja versão mais tarde nos custou muito sangue e um espírito de equipe inovador.

Por que os Spaces foram inventados?

Quando o Wrike foi criado, o foco era resolver os problemas de eficácia de equipes pequenas de 15 a 20 pessoas. É conveniente que essas equipes trabalhem em um local onde haja um "espaço" para todos.

Com o tempo, o tamanho das contas aumentou várias vezes. Agora, o produto é usado por equipes distribuídas em contas com milhares de pessoas e, no futuro, vemos o Wrike como uma ferramenta conveniente para o trabalho de muitos departamentos da empresa: por um lado, trabalhando em diferentes processos, por outro - ainda tendo que interagir entre si.

Como no mundo real as equipes existem em diferentes escritórios, escritórios, países, a equipe do Wrike pensou em criar um espaço especial para eles, para que pudessem trabalhar simultaneamente como parte do processo e não perder o contato com outros departamentos.

Os espaços permitem que grupos de trabalho individuais organizem eficientemente seu fluxo de trabalho: forneça as ferramentas e a estrutura de dados de que precisam, acesso a várias formas de consultas, para que eles possam organizar seu próprio espaço de trabalho e agir com mais foco. Os espaços também permitem controlar melhor a distribuição de informações em equipes multifuncionais e aumentar o nível de segurança dos dados.



A idéia de criar o Spaces pertence a Sasha Plotvinov e Van Saveliev, gerentes de produtos Wrike. Primeiro, eles realizaram pesquisas, desenharam um protótipo da solução para as equipes no quadro, montaram maquetes e validaram a ideia. Mais tarde, foi finalizado no Wrike Hackathon , onde deram um passo para o lado e montaram um protótipo do Personal Space que complementava o conceito.

"Espaços" é, antes de tudo, um recurso para equipes. No entanto, é baseado no conceito de espaço pessoal, que todos precisam excluir informações desnecessárias e ruídos estranhos.

Quais problemas o Spaces resolve?

Para simplificar, o Wrike consiste em projetos e ferramentas para trabalhar com eles. Por exemplo, ao trabalhar em um release abrangente, você cria vários projetos, monitora o progresso deles através do gráfico de Gantt, controla o carregamento de equipes usando a Carga de Trabalho e, com base nos resultados, cria um relatório para as partes interessadas.

Tudo parece simples, mas se houver milhares de pessoas trabalhando em uma conta em um grande número de equipes com processos sobrepostos e usando muitas ferramentas, dois problemas aparecerão: torna-se difícil gerenciar processos e a interface do usuário está sobrecarregada com elementos desnecessários .


<sub>era


tornou-se</sub>

Tais obstáculos ao trabalho em equipe efetivo surgem por várias razões: primeiro, na mesma árvore de pastas, existem muitas equipes; o usuário vê constantemente informações irrelevantes e viola inadvertidamente a estrutura da equipe "alienígena". Em segundo lugar, apenas os administradores têm acesso ao gerenciamento de processos e a estrutura da conta é geralmente formada pelos principais gerentes-administradores.

No processo de desenvolvimento de Espaços, chegamos a duas tarefas principais:

• O usuário deve ver apenas o que é relevante para ele
• Delegação e auto-organização devem chegar ao lugar da gestão vertical

Wrike é uma daquelas empresas que acreditam que o gerenciamento horizontal supera as organizações verticais e "turquesas" , mostrando-se da maneira mais eficiente. A abordagem implementada no Spaces ajudará a equipe a alcançar um novo nível de transparência e auto-organização, onde o gerenciamento horizontal prevalecerá.

"Se antes o administrador da conta tivesse um alto grau de responsabilidade pelos processos, agora ele poderá confiar a organização do fluxo de trabalho da equipe ao seu supervisor imediato, que muitas vezes conhece melhor os recursos de sua equipe".

- Ivan Savelyev, gerente de produtos Wrike

Que dificuldades encontramos?

Evidentemente, mudanças significativas no produto acarretam grandes riscos e várias dificuldades. Aqui estão alguns deles:

Dificuldade 1. Reduzir riscos

Adaptar uma conta a uma nova maneira de organizar o trabalho é uma tarefa bastante trabalhosa. Dentro do Wrike, o problema foi descoberto quase imediatamente: como uma empresa com muitas equipes e processos, entramos na categoria de clientes que consideramos nosso próprio público e usamos nosso produto diariamente. Dentro da conta da equipe (mais de 800 pessoas de todos os escritórios internacionais), lançamos lançamentos e imediatamente recebemos feedback de dentro - isso ajudou a preparar um lançamento público e a maximizar os riscos antecipadamente.
Para aqueles que nunca usaram o Wrike, nos estágios iniciais, realizamos uma série de entrevistas com soluções, lançamos testes usando o serviço UserTesting e também fizemos um programa de acesso antecipado à funcionalidade do Spaces para clientes interessados.

Antes de lançar para todo o público, também realizamos testes A / B em novas avaliações para garantir que o novo paradigma de navegação seja intuitivo para novos usuários. A partir dos testes, ficou claro que novos usuários estão começando a usar o produto com sucesso. Também entrevistamos os grupos de teste e controle e descobrimos que entre os entrevistados, os usuários tinham muito mais probabilidade de falar sobre a compreensibilidade da interface e a facilidade de uso do Wrike.

Dificuldade 2. Traga o valor da solução para o cliente

O Wrike tem muitos clientes que já usam o serviço e configuram seus processos de trabalho; portanto, havia o risco de que a nova funcionalidade fosse relutante.

Lançamos a versão beta privada para clientes-chave e conectamos nosso departamento de Serviços Profissionais ao processo.
Para transmitir o problema e, posteriormente, sua solução aos clientes, os gerentes de Sucesso do Cliente, juntamente com os administradores de contas, identificaram os problemas de organização de processos em um estágio inicial e disseram aos clientes como o Spaces poderia resolvê-los. Assim, transmitimos o valor máximo de Spaces, que superava o tamanho dos custos da reestruturação. De repente, não lançamos o recurso de repente, mas preparamos sistematicamente os clientes para sua aparência: os gerentes de sucesso do cliente realizaram seminários on-line, ensinaram os clientes a navegar em novos recursos, treinaram boletins por e-mail e conversaram sobre as melhores práticas.

Mais tarde, não fizemos nenhuma ligação: os clientes começaram a vir para o programa de testes iniciais e a usar um novo recurso.

Dificuldade 3. Uma melhoria requer muitas mudanças

A melhoria da plataforma afeta vários aspectos do produto e decidimos empreender a modernização para não ficar em um só lugar. Tivemos a sorte de ter uma equipe de desenvolvimento que desamarrou os nós técnicos mais incríveis e encontrou soluções ideais ao longo do trabalho no projeto. Além disso, todos entenderam a necessidade dessa iniciativa, por isso sempre tivemos um forte apoio do vice-presidente e do CEO.

Desde o início, a equipe de desenvolvimento decidiu criar uma arquitetura minimamente conectada, transformando toda a solução em um conjunto de componentes de negócios e miniaplicativos separados que integram e interagem apenas entre o Workspace (o produto final que o usuário do Wrike vê).

Um repositório separado foi criado para esses componentes, incluindo uma caixa de proteção. Era possível não apenas olhar para cada componente em ação e mostrá-lo, por exemplo, em uma revisão de sprint, mas também conduzir seu desenvolvimento e teste completos. A montagem, os testes de unidade e os autotestes levaram uma ordem de grandeza menor que a do desenvolvimento em um espaço de trabalho completo. Isso permitiu que os desenvolvedores iterassem rapidamente, mostrando os resultados no final de cada sprint e, se necessário, fizessem alterações rapidamente na funcionalidade e na API. Depois de algum tempo, o próximo passo foi dado - a criação de uma espécie de "playground", na qual uma interface muito simplificada do produto principal foi criada, incluindo a integração da maioria dos componentes. Isso nos permitiu projetar e depurar sua interação um com o outro.

Como as equipes interagem entre si?

O Wrike tem cerca de 30 equipes de scrum trabalhando em sua parte do produto, cada uma das quais atualmente é afetada por recursos ou serão incluídas no processo em um futuro próximo. A questão da interação entre equipes durante o desenvolvimento do Spaces às vezes surgiu muito acentuadamente - afinal, cada equipe tem seu próprio produto OKRs para o trimestre.

A questão da comunicação era uma prioridade: onde era possível discutir tudo com antecedência, concordar e formalizar os acordos, a interação era melhor do que com as equipes com as quais não havia discussões preliminares. No último caso, a equipe de desenvolvimento teve que fazer alterações ou modificar as funções de outras pessoas.

“Houve casos extraordinários: uma vez que era necessário integrar um componente bastante grande e complexo desenvolvido por uma equipe externa antes de ser finalizado por essa equipe (como resultado, ele apareceu em nossa parte da funcionalidade mais cedo do que basicamente). O que fazer - tentamos terminar o trabalho como parte dos prazos e tivemos que sair. E o tempo que gastamos colocando tudo em ordem após a conclusão do componente, tivemos que borrá-lo com uma camada fina ao trabalhar em outros recursos - a integração conforme o planejado havia muito tempo! ”

- Alexey Kartavenko, líder da equipe de front-end

O número de problemas que surgem quando 30 equipes interagem entre si em um ambiente ágil muito intenso não deve ser desencorajador. Para quase todas as empresas, a criação de um processo de scrum já é uma conquista, e o scrum de scrums é uma fantasia: aqui as empresas, os líderes e os desenvolvedores comuns precisam aprender a trabalhar uns com os outros.

Estas são as dicas fornecidas pela equipe do Spaces para aqueles que se preparam para fazer um grande projeto:

1. Sempre que possível, discuta as opções intermediárias do projeto com diferentes participantes no processo, colete feedback constantemente e procure alimento adicional para reflexão.
2. Se o que você fizer puder ser usado internamente (tivemos muita sorte com isso no Wrike), inicie um projeto piloto. Role sobre todos, informe todos, execute formulários de feedback!
3. Determine o nível de prontidão em que você pode ativar a funcionalidade para clientes fiéis: entre eles, sempre há quem gosta de acompanhar os tempos e ativar todos os tipos de recursos experimentais.O feedback deles será especialmente valioso porque é o seu público-alvo. todos os mecanismos de teste antecipado estão à sua disposição: experimentos A / B, lançamentos limitados e controlados das versões alfa e beta, acesso antecipado sob demanda, etc.
4. Equilíbrio entre a velocidade do desenvolvimento e sua qualidade, como em uma prancha de surf: não tenha medo de deixar dívidas técnicas no sprint atual, mas inicie imediatamente tarefas para eliminá-lo assim que a situação ficar clara. Lembre-se de dar a essas tarefas a maior prioridade. Não é míope fazer uma cobertura completa dos testes unitários e automáticos de funcionalidade que podem mudar após o feedback no próximo sprint. Além disso, não é apenas estúpido, mas criminoso para o engenheiro deixar o código indesejado no final e deixá-lo chegar ao lançamento.
5. Tente se preparar adequadamente para cada próximo sprint: realize PBRs (Refinamento do Backlog do Produto), certifique-se de executar tarefas para pesquisar o que planeja fazer no próximo sprint, converse com o Dono do Produto e o designer de UX o quanto achar melhor: prossiga na cozinha e na sala de fumantes, esclarecendo os detalhes. Tente sincronizar o back-end, o front-end e os testes de forma que a interação seja "interrompida", para que ninguém fique ocioso, aguardando a disponibilidade dos colegas de outra especialização, para que você não precise sentar no mok e jogá-los fora, etc.
6. Mais perto da data de lançamento, quando as paixões estiverem esquentando e a maior parte do trabalho estiver sendo transferida dos desenvolvedores para os engenheiros de controle de qualidade, substitua-os por eles: teste seu código, execute a regressão, ajude na análise e tente escrever autotestes.
7. Ao interagir com outras equipes, inicie discussões regulares com antecedência sobre como exatamente você fará isso. Anote todos os acordos e planos, gere documentação, você pode até elaborar contratos - não porque alguém tente enganá-lo e não faça muito, mas porque todo mundo tem sua própria espuma de dias e seus problemas são apenas cinco por cento estranhos. A sincronização do Sprint é ideal; mire nele.
8. Ao usar algo desenvolvido por outras equipes, tenha cuidado com as afirmações de que "quase tudo está pronto, pegue e integre". Primeiro, você precisa descobrir se não quer se meter em uma bagunça, pegando cegamente o que eles dão e construindo seus planos (especialmente os de calendário).
9. E o mais importante: nem uma coisa séria em um mundo complexo de TI é feita com o clique de um dedo; portanto, se o projeto estiver em desenvolvimento por um longo tempo e eles começarem a "olhar de lado", cuide de seus nervos e saiba: mesmo que não hoje, mas amanhã ou depois de amanhã, fios intermináveis ​​se entrelaçam, a neblina se espalha e o sucesso espera por você - porque você acredita no que está fazendo, certo?