Arquivo Conteúdos - Página 396 de 476 - Colaborar Portfólios

Interessante e útil, não é mesmo? Não estou tentando criar um atalho aqui, mas lhe apresentar uma maneira moderna e atual de trabalhar com desenvolvimento!

Sem conhecer uma única linha de código, é possível construir chatbots com Voiceflow, conectar vários aplicativos e construir fluxos de trabalho automatizados com Zapier e utilizar Shopify para executar lojas de comércio eletrônico.” - WEBFLOW, 2021, p. 1-2

Existem muitos casos de uso para o não código. Não se limita apenas a construir sites. Ele pode ser usado para construir aplicativos móveis, aplicativos da web, aplicativos de voz, ferramentas internas, integrações e para automação de tarefas.

Em seguida, surgiram os construtores de sites mais dinâmicos que as plataformas originais sem código não podiam fazer, ou seja, construir sites cheios de interações, animações dinâmicas e outros elementos visuais sofisticados.

As plataformas de desenvolvimento web sem código percorreram um longo caminho desde os editores WYSIWYG – What you see is what you get (o que você vê é o que você pega) do passado. Onde esses designs geravam transitáveis para a época, esses sites eram simples, oferecendo uma experiência unilateral para o usuário.

Há dezenas de ferramentas ou IDEs que oferecem plataformas de desenvolvimento sem código, disponibilizando todas as funcionalidades do HTML5, CSS e Javascript, mas você não precisa conhecer nenhuma dessas linguagens de programação para começar a construir.

Quando dizemos no-code é simplesmente uma camada de abstração sobre o código. Ou seja, ele pega os fundamentos do código e os traduz em soluções simples de arrastar e soltar, permitindo que os criadores criem aplicativos e sites modernos visualmente.

O que antes era um espaço que apenas desenvolvedores e especialistas em programação podiam navegar, agora está aberto a todos. O movimento sem código removeu o obstáculo de ter que conhecer linguagens de programação, permitindo que qualquer pessoa traga suas ideias à luz.

Muito do que fazemos em nosso dia a dia é alimentado por código. Estejamos verificando nossas contas bancárias, curtindo fotos de amigos nas redes sociais ou procurando novas roupas em nossos sites de comércio eletrônico favoritos, a programação é o que torna todas essas ações possíveis.

O movimento sem código repousa sobre a crença fundamental de que a tecnologia deve permitir e facilitar a criação, não ser uma barreira à entrada. Muito do que fazemos em nosso dia a dia é alimentado por código.

“O desenvolvimento sem código é um tipo de desenvolvimento para a web que permite que não programadores e programadores criem softwares usando uma interface gráfica com o usuário, em vez de escrever código.

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.

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.

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.

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.

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.

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.

(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).

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

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.

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.

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.

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á).

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).

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á).

É mandatório e geralmente é preparado no estágio inicial do projeto, no qual apenas especificações de alto nível são definidas e têm como objetivo principal obter um “de acordo” com o cliente.

Por isso, quando falamos em ter uma ideia de desenvolvimento partindo das nossas orientações iniciais e dos limites no material didático do PIT I, levamos em consideração a visão do produto, que foi construída usando storytelling, canvas ou design thinking), pois são os melhores instrumentos hoje para lastrear uma ideia em estágios iniciais e verificar, além de sua validade, seus conceitos.

Esse tempo é bem-vindo, pois nos permite refletir, aprender coisas novas e dominar técnicas. Tudo isso nos traz novas ideias e com elas a necessidade de revisitar os documentos elaborados e atualizá-los, ajustar seu rumo, corrigir ou melhorar conceitos para uma construção acurada.

Às vezes, eles são separados em casos de uso para requisitos funcionais e especificações suplementares para requisitos não funcionais. Por que estou escrevendo isso? O motivo é simples, houve um interlúdio entre o PIT I e o PIT II.

« Anterior 1 … 394 395 396 397 398 … 476 Próximo »