Aqui estou demonstrando como um projeto nasce a partir de uma ideia, apesar de que mesmo que um produto/software preexistente já esteja estabelecido, ele pode sofrer atualizações, mudança ou disrupção. Portanto serve com certeza para o seu caso.

Quando o projeto é iniciado, especialmente os grandes, dois documentos são preparados por
analistas de negócios, o documento “as is” (ou “como é”) e o “to be” (como será). Aqui estou
demonstrando como um projeto nasce a partir de uma ideia, apesar de que mesmo que um
produto/software preexistente já esteja estabelecido, ele pode sofrer atualizações, mudança ou
disrupção. Portanto serve com certeza para o seu caso.

As is descreve o ambiente atual e o fluxo de trabalho no domínio do negócio (algumas coisas são
feitas manualmente, por exemplo, usando papéis ou, no caso da área de saúde, exames diagnósticos
dependem do especialista médico ou do citologista para saber se uma célula é ou não cancerosa). To
be descreve como o cliente deseja que as “coisas” sejam (como um software será usado em vez da
papelada, ou ainda como um algoritmo de visão computacional e machine learning diagnosticará
câncer a partir das imagens de exames que receberá).

O as is e o to be enriquecem em muito a visão do projeto e de seu produto/serviço, pois, a partir
deles, o analista começa a fazer os casos de uso e as especificações suplementares, que às vezes
não são captadas logo de início. O importante aqui é que você perceba que pode combinar ou
remover documentos conforme desejar ou precisar para que se adequem ao seu projeto, porém
devem fazer sentido e devem manter a completude da ideia.

Projetos menores não precisam de tantos documentos e não envolvem muitas funções. Grandes
projetos precisam dessa separação porque diferentes documentos falam para pessoas diferentes.
Principalmente se você deseja se comunicar com altos cargos gerenciais ou até mesmo o “C-level”,
não deve fornecer a eles documentos com conteúdo que eles não tenham interesse de ler (cada
documento deve ser construído com a linguagem adequada, não adianta colocar linguagem técnica
para um membro do conselho ou um vice-presidente de finanças, não porque eles não saibam, é
que não há tempo para isso, eles confiam em você e esperam que você esteja maduro tecnicamente
para fazer jus ao cargo que ocupará no futuro).

Mas, estamos nesse nosso PIT II descrevendo a fase de desenvolvimento e temos muito a fazer,
certo?! Vamos descrever um pouco sobre isso daqui por diante.

Creio que haja uma ansiedade grande por parte da maioria quando falamos em codificação, afinal,
quando falamos em escrever programas em uma linguagem de programação, como Java, PHP,
Python, ou front-end de aplicações utilizando HTML, CSS ou JavaScript, muitos mudam seus
semblantes, e essa jornada gratificante e enriquecedora acaba se tornando um verdadeiro tormento
ou pesadelo para tantos. Porém precisamos sair desse mito e mudar nossa perspectiva, nosso
mindset. É claro que estudantes de ciências da computação são apaixonados pelo que fazem e isso
envolve a codificação, porém, devemos levar em conta muitas vezes a falta de experiência natural
de quem está começando, por isso vamos quebrar esse paradigma iniciando com possibilidades de
realização por meio do emprego do no-code e do low-code.

Trata-se de um movimento importante no qual, mais que permitir que usuários tenham
empoderamento para aplicações baseadas em web, que desenvolvedores possam ter maior
produtividade e gamers criem seus modais e desenvolvam seus conceitos antes de partirem para a
programação pesada. Para soluções simples e elegantes, no-code pode ser a solução.

No-code para web trata de JavaScript, HTML5 e CSS, mas não exige conhecimento profundo inicial
num primeiro momento, o que se torna a solução ideal para você que está desenvolvendo um
projeto. Claro, não é uma panaceia para todos os projetos que serão desenvolvidos por vocês nesta
disciplina, mas trata-se de um facilitador pelo tempo que é limitado e exigirá foco e dedicação.
Vejamos agora alguns conceitos.