Gerenciamento do projeto #49
Comments
|
Oi @AlvaroAguiar ! Você tem alguma ideia de datas ou milestones que podemos colocar? Qualquer sugestão é bem vinda! Podemos incluir isso em algum arquivo do repositório. |
|
Breno, bom dia. Antes de tudo, alguém que esteja incluído no desenvolvimento desde o início deve "assumir" o gerenciamento (é o cara que agregará informações sobre quem está fazendo o quê, onde encontrar e para quem distribuirá incumbências). Seria você? Ou o Otto? Importante que seja alguém da Poli, que tenha acesso à direção, respaldo e autorizações necessárias (eu não sou). Imagino haver três gargalos nesse desenvolvimento (aceito sugestões), que seriam; software, hardware e ANVISA, correto? Assim sendo, você (ou o Otto...), deveriam nomear três caras que são os (na prática) cabeças, que já estão basicamente fazendo isso agora. Esses chefes seriam focados em levar adiante suas atribuições e são eles quem sabem QUANDO poderão entregar suas partes. Disso depende a integração das três áreas que virá depois (então teremos os milestones finais). A partir do ponto em que sabemos os milestones finais de cada área (tendo em conta que precisamos desses respiradores para daqui um mês (ou vinte dias, ou quinze!), podemos estipular o prazo de entrega do projeto todo (a integração das três áreas que formam a bagaça) e portanto, teremos o respirador pronto para fabricação. Essa data pode ser 2 dias depois (uma certa tolerância de um dia ou dois não é um problema aqui). Imaginando que uma área esqueceu de alguma coisa importante para outra, e que isso só vai aparecer na integração, vamos colocar mais uns 3 dias para resolução de pendências. Mas é a partir da entrega de cada uma das áreas que teríamos que estipular fases intermediárias. Aí, ninguém melhor que os responsáveis pelas três áreas do programa para nos dizer: o chefe de hardware, o chefe de software e o chefe de AVISA. Eles saberão que partes importantes, dentro destas três áreas, deverão ser alcançadas. Ex. na área de hardware, poderíamos citar o chassis, o pistão, a válvula peep e a lista final de peças (pode haver mais, é só um exemplo mesmo). Algumas dessas partes podem ser desenvolvidas concomitantemente, como a válvula e o pistão, outras só podem ser entregues depois que outras tiverem sido concluídas, como a lista de peças (que obviamente depende do que for estabelecido para as outras partes). Por isso um especialista (o tal chefe de área) é que deve estabelecer essas datas (os milestones!). É ele quem está inteirado do desenvolvimento de todos os seus itens e por isso é quem vai passar pro gerente de projeto quando pode entregar seus objetivos. Cabe ao gerente de programa aceitar (usando o bom senso) essas datas, tendo em mente não extrapolar demais o cronograma final e dando prazos realistas, já que a vontade de ajudar, muitas vezes, leva ao estabelecimento de um milestone inexequível (imagine o chefe de ANVISA dizer que pode entregar amanhã um milestone, sendo que sabemos que leva uma semana, por "N" motivos burocráticos... Não pode). Milestones devem ser exequíveis! Mas não podem ser eternos também: "Olha daqui um mês eu entrego... Aí não. lembra que estipulamos um mês para FINALIZAR o programa? Como um milestone será entregue depois do encerramento? Não. Finalmente, os chefes de cada área, usando a mesma lógica, estabelecerão os próprios milestones para seus colegas (os outros colaboradores, que o estão ajudando na área). Eles deverão distribuir trabalhos e cobrar que sejam entregues até tal dia (eles saberão, já que entendem seus recursos disponíveis e a disponibilidade de mão de obra capacitada). Esses colaboradores se comprometerão com seus chefes de área e os chefes entregarão seus milestones ao gerente de projeto, que montará um Exel, com data de início, duração e data de término de cada atividade. Nisso eu posso ajudar. Estabelecidos os milestones, não tem choro, cada um deve cumprir seus prazos pois, é de se imaginar, as áreas serão interligadas globalmente em vários pontos e um trabalho dependo de outro. Atrasar aqui implicará um atraso de mais pessoas adiante. Daí é que se vê, nas empresas, um engenheiro arrancando os cabelos porque sua data final de entrega continua a mesma sendo que a de início foi atrasada por não ter recebido o milestone anterior. O gerente tem de cobrar de seus chefes de áreas. Os chefes de área tem de cobrar de seus colaboradores. E aí, mais ou menos, a data final é mantida. Portanto, primeira coisa, Breno: quem é o chefe de projeto? :-) |
|
Oi @AlvaroAguiar ! Primeiramente, muito obrigado pela sugestão. Sobre quem seria o responsável do projeto, não sou eu (No caso estou ajudando na organização do projeto no Github, em sua parte Open-Source). Os coordenadores podem ser encontrados em https://www.poli.usp.br/inspire, onde podemos ver que são dois professores Titulares da USP. Acredito que uma boa parte da organização do projeto não está Open-Source (Tirando, obviamente, a parte que está open-source aqui, no que diz respeito ao ambu e aos designs do projeto). Acredito que a sua sugestão seria aplicar uma metodologia ágil (Como XP, Scrum ou Kanban) ao projeto, uma vez que eu tenho certeza que os professores coordenadores estão supervisionando o trabalho e assegurando que tudo está sendo feito da forma mais segura e rápida possível. Não sei ao certo o quanto poderia ser open-source no que diz respeito a milestones, visto que partes do projeto como o firmware não estão mais abertas. Aqui no github temos uma parte de projetos (https://github.com/Inspire-Poli-USP/Inspire-OpenLung/projects) onde temos um board estilo Kanban, acredito que podemos aplicar sua sugestão lá (Podemos ir colocando cards com os trabalhos necessários). Podemos tentar organizar, se você tiver alguma sugestão para card, pode colocar lá, ou passar para mim que eu coloco. Abraços! |
|
Breno, não sei como gerenciar apenas parte do projeto. Minha sugestão é devido ao fato de que é necessário agilizar o processo. Cada dia a mais no desenvolvimento significa vidas não salvas. Não temos retorno do que está acontecendo. Não é o que tinha em mente quando vi que a Poli-USP estava trabalhando para desenvolver um respirador para ser utilizado (ainda) nesta pandemia. Vai dar tempo? De qualquer forma, podemos ver issues abertos a mais de duas semanas no GitHub sem que haja novas manifestações. Deveria haver alguém para dar um follow up no pessoal, ver o que está faltando, ver se é possível acelerar, ver se mais alguém pode ajudar... Esses issues são importantes, afinal? Meu objetivo era poder montar respiradores para quem precisar na minha cidade (e talvez na região) isso será possível ou estou sonhando? |
|
Oi @AlvaroAguiar, as suas críticas são muito certeiras e importantes. Obrigado por se dar ao trabalho de fazê-las. Como o Breno disse, boa parte do projeto não está open devido a entendimentos sobre incertezas jurídicas envolvendo a responsabilidade civil por esse projeto. Eu vou organizar aqui como entrar em contato formalmente com a USP para que você e outras pessoas consigam ser ouvidas e exerçam o seus direitos de cobrar de a liberação de informações de uma instituição que é pública. |
|
Um adendo: fizemos testes em humanos com sucesso! O que torna mais imperativo compartilhar as informações do projeto com grupos/ instituições que possam especificamente assumir a responsabilidade civil daqui pra frente. |
A que parte do projeto esse Issue se refere?
Sugiro que haja um gerente de projeto e que Milestones sejam estabelecidas. Precisamos ter uma data de término e liberação. Por melhor que sejam as perspectivas de desenvolvimento não temos tempo! Há de se implementar o que for possível no menor tempo.
The text was updated successfully, but these errors were encountered: