Ciência de dados? Ágil? Ciclos Meu método para gerenciar projetos de ciência de dados na indústria de alta tecnologia.

Desmistificando o gerenciamento de projetos de pesquisa em ciência de dados

Ori Cohen Blocked Unblock Seguir Seguindo 3 de janeiro

O desenvolvimento de software ágil assumiu a indústria de alta tecnologia. Se implementados como Scrum, Kanban ou Scrumban, esses métodos foram criados para serem flexíveis e permitir mudanças rápidas, trabalhando em ciclos curtos. Embora essas implementações sejam adequadas para o desenvolvimento, elas colidem em certos aspectos com pesquisa, portanto, para serem ágeis na pesquisa, precisamos adaptar os valores centrais do Agile e reconciliá-los com metodologias de pesquisa, ou seja, criar uma implementação funcional que use Valores e ideias ágeis, mas orientados para a pesquisa. A seguir, um método que desenvolvi, baseado em minha experiência pessoal no gerenciamento de uma equipe de pesquisa em ciência de dados e que foi testado em vários projetos. Nas próximas seções, revisarei os diferentes tipos de pesquisa de um ponto de vista temporal, compararei as abordagens de desenvolvimento e pesquisa de fluxo de trabalho e, finalmente, sugiro minha metodologia de trabalho.

Tipos de pesquisa

Geralmente encontramos três tipos de pesquisa:

  1. A longo prazo, na academia e em empresas como a IBM ou o FACEBOOK, ou seja, pesquisas que avancem a ciência ou a tecnologia.
  2. Projetos de médio prazo, ou seja, estratégicos, que contribuirão para a sua empresa no futuro próximo.
  3. Projetos de curto prazo, ou seja, recursos para o produto de sua empresa, projetos de clientes, projetos internos, como APIs ou POCs reutilizáveis.

Projetos de curto ou médio prazo, na minha opinião, aplicam-se a qualquer projeto com alguma afinidade com o meio acadêmico ou um projeto relacionado à empresa que visa criar um novo algoritmo ou implementar um novo recurso, mas com restrições do setor, como tempo, recursos ou dinheiro. Em contraste, a pesquisa de longo prazo na indústria é geralmente a mais temida (embora haja exceções). Por exemplo, em muitas entrevistas, como formada em PhD, me perguntaram se eu poderia trabalhar em uma empresa de mentalidade de inicialização acelerada e entregar resultados em curto prazo.

Principais diferenças entre desenvolvimento e pesquisa

Vamos comparar o fluxo de trabalho de desenvolvimento para ambos os campos.

Programação : No desenvolvimento de software, você organiza o código em funções, classes (isto é, programação orientada a objetos) e pode usar padrões de projeto etc. Você tenta projetar uma arquitetura genérica que seja clara, reutilizável e que possa ser facilmente mantida em o futuro. Na pesquisa, o processo pode ser comparado a um estágio de prototipagem em que precisamos de muita flexibilidade, o que nos permite experimentar muitas ideias o mais rápido possível. Para mim e para os outros, isso se resume a usar "Notebooks" – um ambiente python interativo que permite prototipar mais rapidamente do que os IDEs tradicionais, compartimentando certos blocos de código e mantendo a memória persistente. Não temos que recarregar variáveis enormes ou recalcular algoritmos se não houver necessidade, podemos continuar trabalhando em um estágio anterior. A programação em notebooks pode ser comparada a um grande 'main' dividido em várias células, cada célula atuando como uma função. Os IDEs de programação tradicional também são incompatíveis com a memória persistente, imagine tentar ler um conjunto de dados enorme ao tentar depurar um determinado algoritmo.

Depuração : O processo de depuração possui ferramentas bem estabelecidas e você pode facilmente passar de linha para linha, em funções e classes. Nos IDEs tradicionais, você é forçado a recarregar seu conjunto de dados e desperdiçar tempo valioso quantas vezes reiniciar seu processo de depuração, nos cadernos o conjunto de dados é persistente e é mantido na memória durante toda a duração (contanto que o kernel não seja redefinido) . Em um bloco de notas, o processo de depuração consiste em usar print (), portanto, o estágio de depuração é realmente bastante simplista. Eventualmente, quando o algoritmo é concluído, nós o reestruturamos usando ferramentas tradicionais de desenvolvimento de software, como PyCharm usando OOP, padrões de projeto e, finalmente, escrevemos testes de entrada-saída.

Gerenciamento de tempo e cronograma : Em implementações comuns do Agile, cada projeto é dividido em várias tarefas de pequeno porte que recebem uma estimativa de curto prazo. as entregas são agrupadas em ciclos. Essas pequenas tarefas são executadas pelos membros da equipe até a conclusão, tentando concluir todas as tarefas até que o ciclo termine. O ciclo é redefinido a cada X semanas. Em geral, as tarefas de pesquisa são mais longas e nem sempre correspondem bem à metodologia de ciclo curto. Por exemplo, quando iniciamos um modelo, pode levar algumas semanas para obter a métrica de precisão cobiçada. No entanto, isso não significa que não vemos resultados mensuráveis durante essas semanas de outras maneiras, ou seja, uma correlação entre os recursos para uma variável de destino, etc.

Agora que falamos sobre algumas das principais diferenças entre desenvolvimento de software e pesquisa, vamos falar sobre o meu método de gerenciamento de pesquisa ágil e ver como eu tento resolver esses problemas.

Minha metodologia de gerenciamento de pesquisa

Na pesquisa, analisamos as demandas de produtos, atribuímos recursos, pensamos em possíveis soluções algorítmicas, definimos metas e KPIs. A verdade é que não temos um caminho cristalino em direção a esse objetivo, em outras palavras, não sabemos qual é o caminho exato para a conclusão em termos de tarefas. O desenvolvimento algorítmico não é meramente produção, é muito mais sobre a compreensão do problema, avaliação de opções, validação, etc. Na prática, testamos muitas hipóteses e ideias diferentes, baseadas na intuição e experiência, algumas podem ajudar, outras não.

Primeiro, decidimos sobre um prazo razoável para um projeto, seja duas semanas, um mês ou mais, basicamente o tempo que você acha que deve ser baseado em sua experiência ou na estimativa. Os prazos entre projetos diferentes não estão alinhados, portanto, difíceis de colocar em ciclos rígidos. É importante ter em mente que esses prazos podem mudar, os projetos podem ser estendidos ou terminar antes do que prevíamos.

Eu divido cada projeto em seis estágios básicos (Figura 1.), o que me permite agrupar sub-tarefas com base no contexto. Os seis estágios básicos, listados abaixo, podem ser vistos na Figura 1 como uma placa Jira.

Figura 1: os seis estágios de um projeto de pesquisa aplicada ou de ciência de dados

Estágios do Projeto:

1. Revisão de literatura

2. Exploração de dados

3. Desenvolvimento de Algoritmo

4. Análise de resultados

5. Revisão

6. Implantação

Usando o método de estágios, um projeto pode ir e voltar entre estágios até a conclusão (setas azuis e verdes na Figura 2). Por exemplo, terminamos de escrever nosso algoritmo e, no estágio de 'análise de resultados', descobrimos que precisamos voltar e mudar uma idéia central de engenharia de recursos, o projeto voltará para 'exploração de dados' e passará pelo algoritmo e etapas de análise de resultados mais uma vez.

Figura 2: os seis estágios de um projeto de pesquisa aplicada ou de ciência de dados sobrepostos em uma placa Jira. Exibindo a ideia principal de que um projeto pode se mover para um estágio diferente, seja para frente ou para trás.

Em cada estágio, eu crio tantas idéias, hipóteses ou tarefas, ou seja, entregas. Por exemplo, no estágio "revisão de literatura", você pode ter várias tarefas, como pesquisar artigos no Google Acadêmico, pesquisar no Github.com ou tentar encontrar postagens relacionadas no Medium.com. No estágio de exploração de dados, você pode explorar engenharia de recursos, seleção ou todos os métodos de incorporação disponíveis atualmente, de word2vec, phrase2vec, sent2vec a Elmo, Bert, etc. No estágio de 'algoritmo' podemos testar vários métodos clássicos de aprendizado de máquina. algoritmos, tente algumas idéias de redes neurais (CNN, LSTM, BI-GRU, redes de múltiplas entradas), algoritmos de empilhamento, conjuntos, etc. No estágio de 'análise de resultados', podemos explorar muitas métricas como precisão, F1, explorar o correção do modelo olhando para o conteúdo, etc. Na etapa de 'revisão', um membro da equipe revê nosso algoritmo. Finalmente, no 'estágio de implantação', convertemos nossos notebooks em uma API clara baseada em classes, expondo init (), train (), predict (), upload_model () e download_model () à equipe DevOps, criamos testes unitários e finalizamos com um pacote Pip (estamos usando circleCI e Gemfury).

Eu não atribuo estimativas em cada entrega, pois isso adiciona uma sobrecarga de planejamento, instala um plano de trabalho rígido que eu quero evitar e interrompe a criatividade no processo de pesquisa, ou seja, não queremos que o plano de trabalho nos gerencie, queremos para gerir o plano de trabalho. Eu quero que minha equipe explore diferentes soluções que aparecem e são pensadas durante o processo criativo e não fure um plano predeterminado que é basicamente apenas uma lista de desejos. Em outras palavras, dados, resultados e insights do processo geram muitas ideias brilhantes que permitirão à minha equipe resolver novos problemas de negócios.

Por fim, exploramos muitas ideias que podem nos levar ao nosso objetivo, no entanto, não é obrigatório finalizar todas as tarefas em cada estágio, ou seja, se estamos satisfeitos com o estágio atual, podemos avançar para a próxima etapa sem concluir todas as outras tarefas. Por outro lado, se você não estiver satisfeito com o plano atual, poderá alterá-lo, pular para frente ou voltar.

Como gerente de pequena equipe, não quero a sobrecarga que vem com o gerenciamento de sub-tarefas. Para gerenciar essas subtarefas eu uso o plugin ' smart-checklist' para o Jira, como visto na Figura 3. A lista de tarefas está contida em cada caixa do projeto, a tarefa apropriada pode ser marcada para 'completion' ou 'in progress' no UI, obviamente, você só trabalha na lista de subtarefas no estágio em que a caixa do projeto reside. À medida que sua equipe cresce, você pode ter uma pessoa dedicada cujo trabalho é manter cada sub-tarefa em detalhes extremos e você pode sentir a necessidade para usar o gerenciamento interno de sub-tarefas do Jira, que adiciona alguma sobrecarga ao gerenciamento de subtarefas. Pessoalmente, sinto que a maioria das nossas sub-tarefas não precisa ser rastreada na íntegra e a visão da diretoria deve ser a mais limpa e agrupada possível.

Figura 3: um exemplo de projeto com tarefas em cada um dos estágios primários.

Pesquisa Diária

O gerenciamento de projetos não termina com um conselho de administração, uma reunião diária também é um aspecto muito importante do gerenciamento de projetos. Minha equipe tem uma reunião diária de uma hora, geralmente de manhã e, assim como no desenvolvimento, tentamos fazer um brainstorming, sincronizar, falar sobre o que fizemos ontem, discutir as questões em que estamos presos e falar sobre os próximos passos. Devido à natureza relativamente mais longa de nossas palestras, descobri que um diário sentado é mais apropriado, em contraste com um diário em pé, ou seja, é muito mais benéfico ficar confortável em um sofá e falar sobre detalhes algorítmicos precisos. Isso nos permite compartilhar ideias, ser criativos e melhorar constantemente sem esperar por feedback no final de um ciclo.

Fluxo de trabalho de pesquisa:

A seguir, uma visão geral da minha metodologia de fluxo de trabalho de pesquisa

  1. Metodologia de ciclo de troca com prazos de projeto por projeto que se ajustam às expectativas, metas e KPIs do seu projeto.
  2. Reconheça que um projeto existe em vários estágios durante toda a sua vida útil.
  3. Reconheça que um projeto pode retornar temporariamente a um estágio anterior para tentar ideias adicionais.
  4. Divida cada projeto em entregáveis baseados no palco.
  5. Atribuir um prazo-limite para cada etapa.
  6. Reconheça que sua lista de entregas não precisa ser concluída como um todo, as entregas podem ser adicionadas ao longo do projeto, o que influencia os prazos.
  7. Em cada etapa, escolha as melhores entregas a serem completadas primeiro, quando satisfeitas, passe para a próxima etapa da pesquisa.
  8. Lave a repetição da lavagem.

Desenvolvimento de Versões

Vamos fazer uma breve discussão sobre as versões de desenvolvimento de algoritmos. Eu costumo tentar alcançar os objetivos do projeto e os KPIs, mas um algoritmo bom o suficiente é sempre melhor que nada. Portanto, é aconselhável criar um produto viável mínimo (MVP), finalizar o processo, obtê-lo em produção e, em seguida, decidir quais são as metas futuras para a próxima versão, elas podem vir de seu departamento de produto, análise de resultados estágio ou a partir de seu plano de trabalho inacabado, como visto na Figura 4.

Figura 4: um fluxograma representando o desenvolvimento da versão enquanto se utiliza o fluxo de trabalho da metodologia do estágio de pesquisa.

Espero que você possa adaptar ou usar algumas das idéias mencionadas aqui para gerenciar projetos de pesquisa de ciência de dados. Tenha em mente que, para que esta metodologia funcione, sua empresa deve entender que a pesquisa é um processo incerto, alguns resultados não podem ser garantidos, mas com a metodologia de gerenciamento de projetos correta, o processo pode ser controlado com sucesso para atingir nossas metas. Finalmente, se você estiver interessado em fluxos de trabalho de projeto desde o design do produto até a conclusão e manutenção do modelo, Shay Palachy escreveu um excelente post .