DEV Community

Alexandre Paulino Sierra da Silva for Seasoned

Posted on • Edited on

O building se torna mais fácil em pequenas partes

Quando se tem algo complexo, mesmo que uma parte de um todo, uma maneira que ajuda a compreender, executar e validar é dividindo em partes (ainda) menores.

Se você trabalha com programação, provavelmente já ouviu sobre realizar pequenas entregas ao usuário, certo? Aquele clássico exemplo em que a ilustração mostra que o cliente quer se locomover mais rápido e então você entrega um patinete e em uma melhoria entrega uma bicicleta, depois uma moto e finalmente o carro.

Em "Shape Up" de Basecamp em seu capítulo "Get One Piece Done" (Tenha uma fatia pronta), Ryan Singer apresenta o conceito de que não adianta o time se esforçar e entregar muito trabalho se ao final não temos algo realmente funcional para apresentar.

É preciso entregar partes que sejam funcionais, em que o cliente possa interagir. Por exemplo, se temos partes A, B e C, entregar o front-end de A, B e C não é entregar valor para o cliente já que elas não são funcionais, assim como entregar A, B e C do back-end ou A do front-end e C do back-end. E daí o termo "fatia", essa “fatia do bolo” precisa ser entregue com todas suas camadas, de maneira que o cliente possa "degustar" o todo, realizar cortes verticais onde a entrega seja o front-end e o back-end do A, por exemplo.

Image description
Imagem extraída de Shape Up

Para começar e ter um bom resultado na entrega de valor e deixar o cliente satisfeito podemos listar:

  • Identificar no todo como é possível "fatiar" (como posso dividir em partes de maneira que entregue valor, mas não quebre por dependência?);
  • Identificar dentre as fatias qual gera mais valor para o cliente (muito importante a participação do cliente nesta decisão);
  • Identificar se a fatia escolhida não depende de outras fatias;
  • Identificar "rabbit holes"; e
  • Programar apenas o suficiente para atender a fatia, deixando os requisitos da próxima para quando for sua vez (não sofra por antecipação).

Ainda neste capítulo de Shape Up, podemos observar o incentivo a que o trabalho de building (programação) seja iniciado com base nas informações do pitch* que já foram trabalhadas no processo de shaping**, possuindo informação suficiente para modelagem, não sendo necessário um design pixel-perfect (reprodução fiel do design) para a fase inicial, inclusive assim podemos antecipar algumas questões como “Isto faz sentido?”, “Isto é compreensível?” e “Isto faz o que eu quero/preciso?”.

Essa estratégia que permite entregar "fatias do bolo" ao cliente em que ele pode ir validando e "degustando" pode aumentar a confiança dele na sua entrega, a satisfação dele com seu trabalho e antecipar correções ou ajustes no percurso. E você, concorda com essa estratégia? Como gosta de organizar sua linha de trabalho para deixar seu cliente satisfeito?

*Pitch em https://basecamp.com/shapeup/1.5-chapter-06
**Shaping em https://basecamp.com/shapeup/1.1-chapter-02

Veja mais sobre “Shape Up: Stop Running in Circles and Ship Work that Matters” de Ryan Singer em https://basecamp.com/shapeup

Top comments (0)