paint-brush
A vantagem de uma página: um modelo para projetos de engenharia de softwarepor@vlshahane
2,750 leituras
2,750 leituras

A vantagem de uma página: um modelo para projetos de engenharia de software

por Vishal Shahane
Vishal Shahane HackerNoon profile picture

Vishal Shahane

@vlshahane

Vishal is a Senior Software at AWS for over a...

3 min read2024/05/22
Read on Terminal Reader
Read this story in a terminal
Print this story
Read this story w/o Javascript
Read this story w/o Javascript

Muito longo; Para ler

A complexidade dos sistemas de software muitas vezes exige que engenheiros ou gerentes de software escrevam propostas para alinhar a equipe, a organização ou as partes interessadas. Estas propostas ajudam a comunicar motivações, recomendações ou marcos de forma concisa, ao mesmo tempo que obtêm feedback e alinham todas as partes interessadas. Este artigo fornece um modelo genérico para escrever one pagers, embora não se limite a sistemas de software, ele tem se mostrado útil ao liderar organizações de engenharia de software.

Companies Mentioned

Mention Thumbnail
Make
Mention Thumbnail
reflect
featured image - A vantagem de uma página: um modelo para projetos de engenharia de software
Vishal Shahane HackerNoon profile picture
Vishal Shahane

Vishal Shahane

@vlshahane

Vishal is a Senior Software at AWS for over a decade with over 16 years of industry experience.

Isenção de responsabilidade : As opiniões e opiniões expressas neste artigo são exclusivamente minhas e não refletem necessariamente as opiniões de qualquer instituição ou organização.

Introdução

A complexidade dos sistemas de software muitas vezes exige que engenheiros ou gerentes de software escrevam propostas para alinhar equipes, organizações ou partes interessadas (equipes parceiras, serviços dependentes, etc.) às mudanças. Essas propostas ajudam a comunicar motivações, recomendações ou marcos de forma concisa, ao mesmo tempo que obtêm feedback e alinham todas as partes interessadas.


Esses documentos também servem como pontos de referência anteriores para novos funcionários assumirem a propriedade de sistemas de software e compreenderem o processo de pensamento de como as decisões foram tomadas no passado. Este artigo fornece um modelo genérico para escrever one pagers; embora não se limite a sistemas de software, tem se mostrado útil na liderança de organizações de engenharia de software.

Modelo

Visão geral

Este será o resumo executivo do documento, bom para captar a motivação e o que você está propondo para que os leitores se interessem pelo seu documento.

Introdução

Forneça detalhes sobre o histórico/motivação para a mudança. Métricas/dados podem ser incluídos para explicar o problema e fornecer insights adicionais.

Metas

Requisitos no escopo para este projeto.

Não-metas

Identifique quaisquer tarefas que não sejam metas ou fora do escopo deste projeto. Essas podem ser distrações para resolver o problema no qual você deseja focar.

Opções

Resuma uma lista de opções/alternativas que você considerou para resolver o problema, de preferência com prós e contras de cada uma.

Recomendação

Com base nas alternativas discutidas na secção anterior, forneça recomendações para soluções estratégicas com explicações ou argumentos de apoio.


Abordagem tática como opção - Com base nos desafios/cronogramas associados à consecução da abordagem recomendada, considerar fornecer uma solução tática; potencialmente, isto pode ser um passo incremental em direção a uma solução estratégica ou uma mudança mínima para resolver o problema no curto prazo.

Teste

Descreva como você validará se o recurso está funcionando conforme esperado; para que você testará? Como você vai testá-lo? Haverá um período para validação gama ou de pré-produção? O que isso implicará? Certifique-se de incluir casos de teste que verifiquem se o recurso se aplica apenas aos eventos onde deveria ser aplicado

Conquistas

Liste tarefas/marcos de alto nível para soluções recomendadas com estimativas em dias de desenvolvimento. Para fornecer esta lista além das mudanças funcionais, pense em:

  • Estratégia de teste antes do lançamento (testes unitários, de integração, etc.)
  • Necessidade/estratégia para preenchimento
  • Quaisquer alterações nas métricas/scripts/ferramentas de relatórios
  • Novas métricas/etapas de validação após o lançamento (canários, fluxos de trabalho de aprovação de pipeline)
  • Revisão de segurança
  • Mini revisão de prontidão operacional

Referências

Referências que você acha que podem ajudar os leitores a mergulhar profundamente no espaço do problema ou nas alternativas apresentadas.

Perguntas frequentes

Responda proativamente a quaisquer perguntas ou dúvidas antecipadas que possam ter surgido em discussões consecutivas relacionadas a esta proposta.

Apêndice

Adicione qualquer informação suplementar à proposta, que os leitores possam consultar conforme necessário.

Notas da reunião

Mantenha o resumo abaixo para as reuniões em que você fará a revisão da proposta.

Participantes

Lista de pessoas que participaram da reunião.

MoM (Ata da Reunião)

Resuma a ata da reunião para referência futura.

L O A D I N G
. . . comments & more!

About Author

Vishal Shahane HackerNoon profile picture
Vishal Shahane@vlshahane
Vishal is a Senior Software at AWS for over a decade with over 16 years of industry experience.

Rótulos

ESTE ARTIGO FOI APRESENTADO EM...

Permanent on Arweave
Read on Terminal Reader
Read this story in a terminal
 Terminal
Read this story w/o Javascript
Read this story w/o Javascript
 Lite

Mentioned in this story

companies
X REMOVE AD