Em cada uma de nossas seis equipes de desenvolvimento, a lista de pendências está agendada para cerca de dois anos, levando em conta a quase inevitável refatoração, correções, recursos e productologistas da Wishlist. No interior, tudo pode ir de acordo com as prioridades, e alguns blocos grandes se tornam mais importantes, depois são removidos e, em seguida, algo novo é adicionado lá. Mas sempre há um entendimento de onde cavar nos próximos meses.
Além de várias vantagens, esse sistema tem duas desvantagens óbvias:
- Isso é muito chato, e o tédio não é o que nos motiva a escrever código.
- Muitas hipóteses estão acumulando que, de acordo com o processo usual, caem em algum lugar no final da lista de pendências, mas cada uma delas pode dar um resultado rápido. Ou talvez não. Alguns deles são interessantes.
No modo normal, é difícil analisar essas hipóteses, porque você precisa da interação de um cientista de produto, de uma pessoa de negócios (geralmente um gerente de linha) e de mais algumas pessoas de outras equipes de desenvolvimento. Ou seja, quando você tem duas horas livres, ainda não consegue. E como muitas vezes ganhamos dinheiro pisando o caminho nos negócios para novas interfaces e novos recursos, o teste de hipóteses é a vida.
Primeiro, reservamos um tempo dentro do escritório e fizemos o fluxo de trabalho geral. Verificou-se que, se você verificar o mais rápido possível, obterá soluções médias. Para melhorar a qualidade, você precisa sair da rotina geral.
Portanto, já viajamos para uma cidade estrangeira três vezes e trabalhamos lá.
Por que isso é necessário?
Se você já leu posts sobre como acumulamos
dívida técnica e o que fazemos com ela, e sobre o que o
desenvolvedor precisa saber
sobre negócios , então você sabe que, de tempos em tempos, temos dezenas de hipóteses sobre o que fazer. Cerca da metade é de desenvolvedores, em parte de histórias de outros departamentos e da transferência de experiências para si mesmo, em parte de um cientista de produtos, fundador ou simplesmente por causa da fase da lua.
Em seguida, determinamos a lista de pessoas necessárias para resolver a maioria dessas tarefas. Como regra, é uma equipe de desenvolvimento específica (direções do ar, ferrovias, passeios, trens, aventuras ou análises), um engenheiro de infraestrutura, algumas pessoas de uma empresa (para uma visão geral e avaliação da consistência financeira), um analista de transferência para lá e para cá, pessoas de outras equipes .
O processo básico ficou assim: pegue um profissional de marketing, desenvolvedores, designer, analistas e líder. Bem no escritório, uma vez por semana, organizamos uma discussão sobre o sprint sobre hipóteses. Um dia é alocado quando o trabalho é realizado apenas em hipóteses. Se a solução de um problema sair em seis horas, é interrompida e sai desse processo. A tarefa é iniciar o beta oblíquo em seis horas. Dez hipóteses por semana são testadas para todas as equipes.
Isso funciona bem, mas as limitações que você viu acima.
Em um desenvolvimento completo, considera-se que, de acordo com os resultados da versão beta, o gerente de projeto está satisfeito.
Consultamos o guru do gerenciamento de projetos e várias pessoas disseram ao mesmo tempo que forças especiais deveriam ser criadas dentro da empresa, ou seja, aquelas que estão especificamente envolvidas no desaparafusamento de hipóteses rápidas. Em algum lugar, isso é chamado de grupo de desenvolvimento, em outro lugar. O ponto é um hackathon permanente para uma equipe.
Parece lógico, mas não rapidamente implementado: é necessário reunir especialistas em seis áreas diferentes do negócio e privar as principais equipes dos mais interessantes, porque todas as passas do pão são escolhidas por essas "forças especiais".
"Forças especiais" são necessárias porque, se não 100% do tempo do desenvolvedor é alocado para resolver o problema, o resultado é pior. A julgar pela experiência. Mas não conseguimos fazer isso.
Pegamos o TRIZ e sugerimos que precisamos focar parte do tempo em hipóteses, em parte no trabalho principal "a longo prazo". O que nos impede de fazer isso, como fizemos no escritório? Contexto, distrações e regulamentos constantes, emprego constante dos membros da equipe e feedback longo.
Foi assim que as pessoas criaram hackathons. Eles removem todas as restrições do escritório e dão tempo para se concentrar. Apenas um hackathon é uma história voluntária gratuita, e geralmente é sobre treinamento. Os desenvolvedores passam o sábado, porque podem aprender algo novo e não melhor para fazer seu trabalho.
Por isso, decidimos realizar um experimento e ir a Istambul com uma equipe de 14 pessoas.
Experiência de Istambul
Por que Istambul? Precisávamos de uma cidade que atendesse aos requisitos alimentares:
- Faça um voo rapidamente sem atrasos frequentes (o outro lado do planeta não se encaixa, ilhas com clima imprevisível não se ajustam).
- O acesso é relativamente barato (a Islândia geralmente não é adequada).
- A cidade é mais atraente que Moscou nesta época do ano (nem todo mundo gosta de sair do escritório apenas para viajar, Omsk não é adequado, mas os habitantes desta cidade vão me perdoar).
- Há muitas coisas interessantes para as quais você não precisa viajar muito (a Noruega não é adequada).
- A equipe, por unanimidade, quer ir a esta cidade.
Fizemos uma lista de cidades adequadas e discutimos com todos. Era importante que tudo fosse verificado de uma só vez, e esse não era um dever terrível.
Decidimos que teríamos uma grande reunião em Istambul em troca de dois dias de folga (pagos), mas compramos os ingressos. Essa lógica se adequou a todos, porque é uma chance de atracar esses dois dias de folga nos fins de semana e tirar umas mini-férias no meio do ano.
Bem, no final, ainda somos pessoas apaixonadas por viagens.
No local, eles alugaram uma casa grande perto do centro.
Quem fez Um dos desenvolvedores passou seu tempo pessoal organizando tudo isso. Não tenho certeza se isso foi porque ele queria estudar o processo de viagens de negócios (acabamos de promovê-lo) ou simplesmente porque ele queria ajudar todos.
Durante uma semana, eles avisaram a
cozinha que precisávamos de lanches na estrada, mas a carga de comida diminuiria nos próximos dias.
Trabalhamos na sexta-feira de manhã, como sempre, às 12:30 fomos para o aeroporto, por volta das 15 horas - partida, às 18 horas estávamos lá.
Chegamos em casa, já havia wi-fi implantado lá, eu tinha materiais impressos comigo. Tudo com laptops corporativos. Comemos, sentamos e discutimos as principais coisas. De fato, foi um debate sobre o que e como fazer no produto. Ou seja, decidimos o que deve entrar no backlog. Eu queria discutir hipóteses "rápidas", destino e prioridades de tarefas de longo prazo.
No dia seguinte, chegamos a esse formato: na quinta-feira, apareceu uma lista de questões problemáticas (além daquelas que já eram conhecidas), então conversamos sobre elas quase toda sexta-feira. Dois lados foram encontrados: um era a favor da hipótese e o outro era contra. Então eles organizaram um duelo, que todo mundo julgou. Ou seja, quase como um julgamento de hipóteses: o promotor puxa o que você não precisa fazer e o advogado puxa para obter sucesso e alegria. É verdade que eles não pensaram em mudar o promotor e o advogado, e esse é um procedimento padrão em tais debates.
O horário de trabalho era o seguinte: escolhemos o pior horário para caminhadas (em Istambul, este é o meio do dia), colocamos a reunião lá. Manhã e noite são livres, mas almoçamos juntos, esta é uma oportunidade para se comunicar. Nessa viagem, algumas pessoas ainda realizavam pequenas tarefas, ou seja, não podiam desligar completamente o processo usual. Por outro lado, não diria que demorou um tempo considerável.
Um exemplo de uma hipótese de amaciamento
Os ônibus não possuem uma passagem eletrônica legalmente aprovada. Isso nos entristece incrivelmente, porque os passageiros precisam imprimir o formulário em casa ou em uma impressora na estação de ônibus (o que às vezes se torna um problema e às vezes é banal por uma taxa). A Russian Railways aceita inscrições eletrônicas em quase todos os lugares há muito tempo, as companhias aéreas imprimem para você no aeroporto sem perguntas nos terminais ou na recepção (e em alguns lugares você não precisa imprimi-las). E em ônibus em alguns lugares ainda os anos 70 da URSS.
Na prática, existem estações progressivas que apenas mostram o bilhete pelo telefone. Eles ainda têm esses dados na declaração da parte deles, e você só precisa olhar lá e no documento da pessoa. Mas existem estações conservadoras e aquelas que são apenas "Baba Yaga contra". E todas as estações têm suas próprias formas de tais formas.
Do ponto de vista da estação, um ingresso eletrônico é um desenvolvimento. A segurança da estação aumenta, é mais conveniente para o controlador e o motorista, as operações são aceleradas, o papel é economizado, os jovens não fazem perguntas.
De qualquer forma, em um ônibus, um ou dois passageiros esquecem os bilhetes e, em qualquer caso, eles são restaurados a partir dos dados da estação. Mas em alguns lugares eles encontram muita falha. A prática mostrou que, se um passageiro começa a escandalosamente, ele o deixa entrar. Se ele sair em silêncio (na maioria das vezes aposentados) - já temos que entender a situação.
A primeira coisa que fizemos foi alocar estações conservadoras e, ao comprar passagens, fazemos uma notificação separada com elas para o passageiro de que é necessário imprimir uma passagem: elas não serão permitidas sem ela.
Então decidimos fazer uma "lista branca" dessas estações de ônibus onde o registro eletrônico funciona. Cheque triplo: retirada de passageiros, ligação de nosso cliente secreto, pergunta direta à gerência da estação.
Se a legislação está atrasada na realidade em termos de permissão de tickets eletrônicos, mas existe uma solução alternativa através da recuperação de tickets de acordo com a estação, por que não automatizar e fazer sua própria muleta rápida e conveniente?
Em geral, encontramos essas estações e marcações marcadas no site.
A verificação é repetida de tempos em tempos.
No processo, descobriu-se que existem estações que chegaram a esse esquema, mas não disseram aos passageiros sobre isso. Integradores para isso também vão com alegria.
Em seguida, concedemos pequenos bônus no sistema às estações que possuem essa marca, para que haja um incentivo econômico para isso.
Como resultado, verificamos que rapidamente combinamos (bem, na verdade não nós, mas eles mesmos combinaram, em particular, com nossa ferramenta) algumas estações e operadoras que já fazem o registro eletrônico.
Ou seja, você não pode apenas sentar e esperar até que tudo apareça legislativamente, mas descobrir como fazê-lo programaticamente. E é isso. Precisávamos de um desenvolvedor, gerente, uma pessoa em comunicação com parceiros e um designer.
Qual é o resultado?
Perdas da primeira experiência:
- Menos bilhetes e acomodação.
Benefícios:
- Quase como umas férias no meio do ano.
- Nos seis meses seguintes, eles decidiram todas as perguntas de uma só vez.
- Eles foram capazes de se comunicar especificamente com a equipe. Por alguma razão, o escritório não funciona dessa maneira.
- Coisas dificilmente mensuráveis no nível das sensações: as relações na equipe mudaram.
- Analisamos o nosso próprio produto de fora: afinal, usamos nossas ferramentas (e outras equipes) o tempo todo, apresentamos vários recursos "on the fly".
- Eles simplesmente dirigiram em uma viagem, o que é lógico para uma empresa que é sobre viagens.
- Os camaradas "seniores" ensinaram os "juncos" a pensar racionalmente, não apenas no desenvolvimento, mas também no planejamento do dia. Isso é muito insignificante, mas a transferência de experiência é sentida.
- Eles foram capazes de atrair desenvolvedores remotos para a comunicação, o que geralmente não era suficiente.
Nezhdanchiki:- Aprendemos que as duas meninas tiveram problemas catastróficos com a orientação para a área: elas estavam perdidas, nós as encontramos, nunca as deixamos ir. Isso quase interrompeu a sessão de trabalho.
- O desenvolvedor que assumiu a organização mostrou uma manifestação de liderança situacional. Não é de se esperar, eychar e líder ficaram surpresos.
- Descobrimos que nossa colega Misha tira fotos legais. Ele pegou a câmera, tirou tudo e depois apresentou as impressões em papel. Para memória.
É muito difícil sincronizar nas viagens, e isso ainda não se tornou um processo. Mas acho que sim, porque os benefícios são óbvios. Agora usamos as duas abordagens: alocamos o tempo das equipes no escritório para analisar hipóteses e ocasionalmente sair. Partidas são necessárias mais para determinar a visão e tarefas diferentes, e "não perturbe" no escritório para quebrar hipóteses no modo hackathon pessoal.
Sete hipóteses foram selecionadas e testadas na primeira iteração, das quais três apresentaram resultados. Por exemplo, na direção dos ônibus.
Na etapa de entrada de dados, os passageiros começaram a mostrar uma placa com a inscrição "Última compra de passagem para este voo, N minutos atrás". Na versão móvel A / B mostrou + N% nas vendas, no desktop não há resultados significativos. Expandimos o formulário de pesquisa na versão móvel das páginas com o cronograma - como resultado, obtivemos + NN% em vendas. Recebemos dados de clientes para poder devolvê-los. Em questões vazias, eles começaram a coletar e-mails dos usuários para enviar ônibus, se aparecerem na direção, haverá centenas deles por semana. Com base nas preferências do usuário, coletamos ofertas no boletim informativo. Os resultados. Sucesso: 91-93%. Vendas de quem abriu a carta: + NN, 3% (significativo). Mas! As pessoas andam de ônibus nas mesmas direções, o que significa que as previsões são as mesmas. Até agora, as correspondências serão sempre as mesmas. Vamos pensar em como diversificar.
Naquela época, havia tarefas típicas na lista de pendências, por exemplo, uma rotina:
- Execute duas integrações com estações de ônibus.
- Atualize três integrações atuais.
- Integre as transportadoras de ônibus da Lituânia.
- Faça conectores para sua conta 16 operadoras.
Em geral, funciona, mas gostaríamos de ouvir sua experiência de trabalhar "isoladamente" no escritório e viajar para algum lugar, se você os tiver.