🤔 - Release notes 📝 é só pra público aberto?

Pessoal queria tirar uma dúvida e já abrir uma possivel discussão.

Trabalho em uma empresa onde desenvolvo e dou manutenção em um sistema interno, desenvolvido internamente também, como se fosse uma intranet. Desenvolvido em React com backend PHP com framework Yii caso alguem tenha curiosidade.

É um sistema bem complexo, que tem desde controle de funcionários, contas da empresa, evendas comissão dos vendedores internos até sistema de questionario/pesquisa direcionado (somo uma empresa de jornalismo direcionado ao mercado de advocacia), CMS que alimenta um site também desenvolvido internamente.

Venho enfrentando um pequeno problema mas que tem crescido lentamente, que é controlar novas funcionalidades e lançamentos delas. Mais especificamente na divulgação para os funcionários interessados em tais atualizações.

Comecei a ver alguns exemplos de release notes, mas elas parecem ter um foco mais publico, pros clientes usuários, não entre colaboradores. Óbvio que eu poderia fazer da mesma forma, só mudar o foco e a linguagem escrita, mas isso é comum? Existem maneiras mais práticas e padronizadas?

Qualquer dica, qualquer tipo de comentário é bem vindo aqui, o meu objetivo é tentar entender essa área e saber se esse é um problema bobo ou é recorrente em alguma empresa.

rafael há 10 meses

Existem notas de lançamento privadas, onde você pode deixar junto ao repositório para acompanhar o que foi feito, quando foi feito, e caso tenha surgido algum bug, sabe exatamente em quais versões ele existiu, por exemplo. Esse controle pode ser feito num único arquivo, sem complicações.

E também existe uma versão pública, com menos detalhes técnicos, às vezes com GIFs e imagens etc. Essas notas podem estar num site, aparecer ao iniciar ou entrar no aplicativo/sistema, ter um menu específico para visualizar etc. Inclusive, pode existir algo interativo para o usuário já experimentar o que está vendo nas notas de lançamento. Como cada projeto divulga do jeito que deseja, o melhor é você entender como pode fazer e escolher a melhor opção para seu público, e não "seguir algo padrão" (até porquê não existe um padrão).

Dito isso, não entendi a sua dúvida. Os colaboradores da empresa são os usuários/clientes do sistema. Faça o que faz mais sentido para os seus usuários, informando apenas o que eles devem saber, sem detalhes ou complicações desnecessárias.

jonathanArgentao há 10 meses

Minha dúvida ta realmente em querer achar um padrão, que pela sua resposta me mostra que não devo me preocupar com isso. Só acho que preciso achar um ponto médio entre uma liguagem simplificada e uma linguagem técnica, pois não são programadores, mas também precisam saber dos detalhes pois afetam diretamente no trabalho deles.

RafaelMesquita há 10 meses

Existe uma diferença entre: 1 - Prestar contas do que foi desenvolvido 2 - Divulgar para a equipe as melhorias entregues

Eu entendo que tratamento de bugs devem ser reportados apenas para quem reclamou no mesmo tom que o chamado/ticket foi aberto. Agora, novidades, tem que ser num tom mais comercial, valorizando a entrega, mesmo que seja simples, pois além de garantir que usuários finais entendam, cria um marketing sobre o seu trabalho

jonathanArgentao há 10 meses

Sim! Fazer um marketing do nosso setor é um dos objetivos de eu querer implementar isso. Como trabalhamos em poucos devs, e por mais que estamos sempre atualizando as funcionalidades, poucas delas são visiveis, da impressão que estamos parados, temos que mostrar onde nosso tempo está sendo gasto.

franklin28 há 9 meses

Oi!

Eu uso práticas do SCRUM, Trello, Git Flow, Conventional Commits e Semantic Versioning. Vou explicar de forma resumida: quando uma sprint vai começar, fazemos uma reunião para revisar o backlog de novas funcionalidades e otimizações para o sistema. Criamos uma nova branch para cada novo recurso assim que ele está pronto, então fazemos um merge dessa branch na branch develop e, após os testes, fazemos o merge no master. Se durante esse processo aparecer algum bug, criamos uma branch para corrigi-lo o mais rápido possível e fazemos o merge na branch develop e, em seguida, no master. A branch do novo recurso também é atualizada com a correção do bug. Quando está tudo OK, geramos uma nova versão (Semantic Versioning). Quanto à geração da nota, faço manualmente. Eu reviso tudo o que aconteceu desde a última versão, identifico os bugs corrigidos, as novas funcionalidades, melhorias, etc. Meu documento de nova versão é um Word que vou atualizando com a data de lançamento, código da versão (tag) e um resumo de tudo o que ocorreu nessa sprint. É possível automatizar essa geração, mas, considerando que é pouca coisa e trabalho de 5 a 10 dias, gosto de fazer manualmente para revisar tudo o que aconteceu durante a sprint.

Espero ter ajudado! Se tiver mais alguma dúvida, pode entrar em contato comigo

https://www.linkedin.com/in/franklin-goncalves28/

O resultado final é mais ou menos assim https://github.com/HashLoad/horse/releases

https://github.com/otaviolemos/thewisepad-core/commits/master