Desenho funcional: onde a empresa encontra o software

ARTIGO

Escrito por Admin EngIndX


Uma introdução ao desenho funcional

O objetivo do desenho funcional é definir os requisitos a serem implementados por uma solução de software. Independentemente da forma que assumam, as especificações funcionais destinam-se a capturar o que o software precisa fazer para oferecer suporte a um usuário empresarial. Freqüentemente, os projetos funcionais são revisados e aprovados pelas partes interessadas de negócios e técnicas. Os usuários de negócios confirmam que, sim, é isso que eles realmente querem que o sistema faça. Os usuários técnicos confirmam que, sim, esses requisitos são viáveis, implementáveis e testáveis. A fim de aprender mais sobre as nuances do desenho funcional e nossa abordagem única na Engineering Industries eXcellence, nossa equipe de marketing se reuniu com um de nossos maiores gurus técnicos e especialistas em desenho funcional para uma boa e antiquada sessão de perguntas e respostas face a face.

Conheça nosso especialista: Guillermo Padron

ZB: OI GUILLERMO! OBRIGADO POR SENTAR-SE CONOSCO HOJE PARA NOS FALAR MAIS UM POUCO SOBRE VOCÊ MESMO E O QUE VOCÊ FAZ.

GP: O prazer é meu, vamos lá!

ZB: PRIMEIRO, CONTE-ME UM POUCO SOBRE VOCÊ E SUA HISTÓRIA. QUALQUER COISA QUE A MAIORIA DAS PESSOAS NÃO SABE SOBRE VOCÊ?

GP: Meus pais imigraram de Cuba para os EUA em 1979 durante o reinado de Fidel Castro. Cuba tinha um acordo com o governo dos EUA para permitir a emigração para os estados, e Castro usou isso como uma oportunidade para se livrar de indesejáveis - prisioneiros de estado, dissidentes políticos do regime comunista - você entendeu. Naquela época, meu pai era um prisioneiro político. Ele e minha mãe foram informados de que iriam de balsa para a Flórida, e eles o fizeram. Eles finalmente chegaram a Nova York e se estabeleceram em Nova Jersey. Eu nasci lá em 1991.

ZB: É UMA HISTÓRIA INCRÍVEL, G! NÃO TENHO A CERTEZA PARA ONDE IR A PARTIR DE LÁ, MAS DADO QUE VOCÊ É UM DOS ESPECIALISTAS TÉCNICOS MAIS TALENTOSOS DE NOSSA EQUIPE DOS EUA, QUERO QUERIA VOCÊ ERA COMO CRIANÇA. VOCÊ NASCEU PARA ESTAR NESTE CAMPO?

GP: Talvez não tenha nascido, mas definitivamente criado para isso. Na escola primária, eu era tudo sobre matemática e ciências. Eu gostava deles e era muito bom neles. Eles eram concretos e foi muito mais fácil para mim entender em uma instância o que era uma resposta para um problema. É assim que minha mente funcionava. Eu também estive em uma escola onde essas disciplinas eram enfatizadas, porque eu morava em uma área onde as oportunidades educacionais nem sempre eram as melhores, então os professores incentivavam os alunos a fazer aulas práticas e profissionais. Então, no colégio, busquei inspiração em Omar, meu irmão mais velho. Ele estava entrando na faculdade de ciência da computação e eu queria seguir seus passos.

ZB: QUAL É A SUA MAIS PRIMEIRA MEMÓRIA DE TECNOLOGIA?

GP: Quando eu era mais jovem, meu irmão e eu íamos visitar meu pai em seu escritório. No final das contas, se estivéssemos nos comportando e todos tivessem saído do escritório, ele nos deixava jogar alguns jogos no computador. Eu amei. Quando entrei no ensino médio, os computadores pessoais estavam começando a se tornar muito mais comuns em casa, e podíamos ter um em casa. Então, quando ficou muito mais disponível para mim, realmente me cativou. Eu entrei no mundo dos jogos de computador e não olhei para trás desde!

ZB: CERTO, DÊ AQUELAS CREDENCIAIS DE EDUCAÇÃO PARA O REGISTRO.

GP: Fui para a Rutgers University e me formei com dupla especialização em ciência da computação e matemática. Eu não tinha realmente tocado em uma linguagem de programação antes da faculdade, mas queria entrar nela. Então, eu me envolvi muito enquanto estava lá ... vários cursos de programação, sistemas operacionais, linguagens. Não foi fácil para mim. Ainda me lembro de momentos específicos de frustração ou clareza, tentando entender por que o código que eu estava escrevendo não estava funcionando ou por que meu desenho não estava produzindo os resultados que eu esperava. Mas você não pode aprender a ser um bom solucionador de problemas sem ter muitos problemas para resolver.

ZB: BEM DITO. VOCÊ TEM UM LADO CRIATIVO?

GP: Sim! Sempre adorei escrever, jogos, música - a criatividade está no centro de tudo isso. Inicialmente, entrei em programação porque queria criar um videogame. Embora eu não tivesse uma mente puramente criativa, o desenho de videogame requer uma combinação muito boa de conhecimentos técnicos matemáticos para garantir que o sistema funcione corretamente, bem como engenhosidade para ser capaz de criar um mundo único, envolvente no qual alguém iria quero jogar.

ZB: DESENHO DE VÍDEO-JOGO, VOCÊ DIZ? ENTÃO, COMO VOCÊ ACABOU NA ENGINEERING USA?

GP: Acontece que o mundo dos videogames é uma indústria incrivelmente competitiva e desafiadora para se entrar, e não uma que exige novos formados com experiência zero. Um dia, ainda espero viver meu sonho de videogame, mas sabia que não era para eu começar. Eu queria aprender, crescer como profissional e expandir meu conjunto de habilidades técnicas, e a Engineering Industries eXcellence me deu a oportunidade de fazer todos os 3.

ZB: SIM! O QUE VOCÊ FAZ NA ENGINEERING USA?

GP: Estou na Engineering Industries eXcellence há pouco mais de 5 anos. No início, tive contato com várias áreas de especialização diferentes em nossa empresa. Tecnologias PLM, MES, SPC. Projetos de treinamento de software de produção, validação de solução, integração de sistemas. Clientes em alimentos e bebidas, dispositivos médicos, petróleo e gás, energia, fabricação de produtos químicos. Sou muito grato por esta diversidade de experiências, porque me ajudou a desenvolver um entendimento profundo dos processos de fabricação e implementação de soluções. Isso tem sido fundamental para o meu sucesso como um desenhista funcional.

Desenho funcional na Engineering Industries eXcellence

ZB: AH SIM, BOM DESENHO FUNCIONAL OLE. O QUE É ISSO DE NOVO?

GP: O desenho funcional é pegar um requisito de negócios, que é o que o cliente quer que o software faça, e traduzi-lo em especificações técnicas que os desenvolvedores podem entender com base no sistema com o qual estão trabalhando. O desenho funcional é o momento do verdadeiro alinhamento entre negócios e TI e, como desenhista funcional, sou responsável por garantir que nada se perca na tradução.

ZB: EU ACHO QUE ENTENDI…

GP: Por exemplo, digamos que o cliente deseja um programa em que pode inserir 2 números e o computador fornecerá uma soma. O desenhista funcional pegará esse requisito de negócio e o transformará em uma série de casos de uso, ou especificações funcionais, que os desenvolvedores podem seguir para atingir o objetivo final. Então:

  1. Esta é a interface que você deve ter;
  2. Você deve ter dois campos;
  3. Você precisa deste botão para clicar em enviar;
  4. Quando o usuário final clica, isso deve acontecer.

Claro, ao fornecer uma solução de TI de produção avançada, essas especificações são muito mais extensas e complexas.

ZB: COMO FUNCIONA O PROCESSO DE DESENHO FUNCIONAL? TEMOS UMA ABORDAGEM ESPECÍFICA NA ENGINEERING USA?

GP: O cronograma e o escopo de cada projeto são diferentes, mas de modo geral, seguimos uma metodologia ágil nao Engineering Industries eXcellence. Esta é uma abordagem baseada em sprint e se aplica tanto ao desenho funcional quanto aos aspectos de desenvolvimento de software de nosso processo. Um sprint cobre uma grande parte dos requisitos de negócios de uma grande lista. Basicamente, dizemos: “Para este sprint, que vai durar x, vamos nos concentrar em x requisitos e fazer com que funcionem”. O benefício do método ágil é que ele permite a prototipagem rápida. Quanto mais curtos seus sprints, menos trabalho você entrega por sprint, mas com maior frequência o cliente pode ver seu progresso e dar feedback. Em contraste, a abordagem em cascata tornará as mudanças difíceis e demoradas. É muito mais fácil alterar um desenho após um sprint menor do que alterar algo após 8 meses de desenvolvimento, especialmente se o cliente teve a chance de observar ou usar o produto. Cada produto muda de uma forma ou de outra assim que o cliente obtém uma visão melhor do objetivo final.

ZB: MAS SE O DESENVOLVIMENTO ÁGIL NÃO TIVESSE DESVANTAGENS, SERIA A ÚNICA METODOLOGIA LÁ. QUAL É O LADO DE SEGURANÇA?

GP: Projetos complexos com um grande número de requisitos nem sempre são facilmente separados em sprints. A desvantagem do ágil é que geralmente requer que você separe certas fases de projetos que não devem ser dissociadas, tudo para manter um sprint em um tamanho razoável. Por exemplo, você pode ter um grupo de funcionalidades que estão todas relacionadas à programação de pedidos ou gerenciamento de estoque ou o que seja, mas esse grupo é muito grande para ser manipulado em um único sprint, então você precisa dividi-los. Como resultado, existe o risco de que o que acontece no segundo sprint possa afetar adversamente o que foi feito no primeiro sprint, exigindo mais tempo gasto corrigindo e testando novamente. Também há muita pressão nos primeiros sprints ágeis para fornecer algo que possa ser executado bem no início do desenvolvimento. Às vezes, isso significa gastar menos tempo com estruturas e ferramentas organizacionais, o que pode atrasar o desenvolvimento ao longo da linha. É aí que nossos relacionamentos com as ferramentas existentes e parcerias com outras empresas são inestimáveis. Eles fornecem muito da estrutura pré-existente, para que possamos ir direto ao ponto de atender diretamente aos requisitos do cliente. Porém, na maioria das vezes, os benefícios do agile e da obtenção de feedback do cliente sempre que possível durante um programa superam os negativos e levam à entrega de uma solução final melhor e mais eficaz. Então, nós continuamos com isso.

ZB: O QUE FAZ UM BOM DESENHISTA FUNCIONAL?

GP: Como desenhista funcional, você é um elo de ligação fundamental entre o cliente que está adquirindo a tecnologia e a equipe de desenvolvimento que está construindo o software. Como o principal mediador entre o negócio e o software, você tem muito controle sobre como a estrutura de uma solução acabará se desenvolvendo. Dado esse poder, você precisa considerar os dois lados em cada etapa do seu trabalho. Você precisa considerar não apenas como um desenho será visualmente para o usuário final, mas também como (e se) ele pode ser desenvolvido, testado e suportado. Às vezes, o que é bom para um lado não é bom para o outro. Além disso, você deve sempre tentar entender o que vai trazer os melhores resultados de longo prazo para o desenho. Você pode desenhar algo facilmente se não tiver restrições e simplesmente carregar uma infinidade de requisitos na equipe de desenvolvimento. Mas você quer ter certeza de que seus desenvolvedores tenham tempo suficiente em seu sprint para programar o que você desenhar. Ao mesmo tempo, é preciso considerar como esse desenho será testado. Se você sobre-desenhar todos os aspectos de um requisito, criará um cenário que é muito desafiador para suporte de validação. Você está tentando entender o quanto do desenho é explícito e obrigatório, quanto do desenho precisa ser adicionado para boas práticas de programação e quanta leniência você deseja dar ao desenho para garantir que todos os requisitos do negócio sejam atendidos. É um grande ato de equilíbrio.

ZB: O QUE O CONFIGURA COMO UM DESENHISTA FUNCIONAL, GUILLERMO?

GP: Em meus 5 anos na Engineering Industries eXcellence, fiz parte de todos os diferentes aspectos de um projeto de TI. Passei muito tempo no lado da consultoria de TI, muito tempo com o software e muito tempo com os operadores no chão de fábrica. Eu vi em primeira mão como meus desenhos repercutem no que está acontecendo no nível do solo. Isso me permitiu ter uma perspectiva única além da visão geral de um programa. Eu sei que os usuários usarão isso em seu trabalho diário e não quero dificultar seu trabalho. Eu entendo esse impacto e o considero uma responsabilidade séria.

ZB: UMA PERGUNTA FINAL PARA VOCÊ, ENTÃO, DEIXO QUE VOCÊ VOLTE A FAZER TODAS AS COISAS IMPORTANTES QUE VOCÊ FAZ. DO QUE VOCÊ GOSTA MAIS SOBRE O QUE FAZ?

GP: O desenho funcional me deu a oportunidade de aprender muito sobre as necessidades da indústria e a natureza dos projetos de desenvolvimento de software simultaneamente. Gosto da minha função porque me permite comunicar e obter feedback de todos os jogadores que são impactados por meus desenhos - os caras no topo, os usuários finais e minhas próprias equipes de desenvolvimento e validação. Meus desenhos afetam o que eles fazem e como seus trabalhos são fáceis ou difíceis. Essa interação me ajuda a entender onde meus desenhos são bons e onde estão falhando. Este tem sido um fator chave para o meu crescimento como especialista e a melhoria contínua do trabalho que produzo.

Para saber mais sobre os serviços que oferecemos para habilitar a Industry 4.0, clique aqui.

Interessado em falar com um dos nossos especialistas? Entre em contato com info@indx.com.


Contate-nos