Proposta de integração da engenharia de software nas estratégias empresariais

Proposition for software engineering integration into enterprise strategies

Proposta de integração da engenharia de software nas estratégias empresariais

Proposition for software engineering integration into enterprise strategies

Adalberto Faria dos Reis; Ivanir da Costa

Universidade Paulista

RESUMO

As empresas vivem os desafios constantes de produzir software de alta qualidade, de impacto no sucesso de seus negócios, com ótima relação custobenefício e, acima de tudo, em curto prazo. A engenharia de software estabelece a importância de considerar a estratégia da organização e a geração de valor no planejamento e na implantação dos seus projetos. Como parte dos desafios, é preciso escolher uma das opções de modelos de desenvolvimento e manutenção de sistemas, classificados como ágeis ou rigorosos.

É chegado o momento de propor o tratamento desses temas de forma integrada, através da prática do pensamento e da ação estratégica a serem aplicados pelos engenheiros de software no transcorrer de seus trabalhos. Um modelo de ação e comportamento estratégicos é proposto por este trabalho, capaz de auxiliar os engenheiros de software neste empreendimento, e são mencionados outros modelos e ferramentas que podem ser usados como apoio e complemento.

Palavras-chave: Engenharia de software, planejamento estratégico de software.

ABSTRACT

Enterprises face the challenges to produce high-quality software that support business success at an optimal cost-benefit ratio and in short term. Software Engineering reckons the importance of business strategy and value generation as basis for planning and implementation of its projects. As part of the challenges, it is necessary to choose one of the models for systems development and maintenance, classified as agile or rigorous.

It is time to propose the management of all these matters in an integrated way, through the practice of strategic thinking and action by software engineers during their work. An action and behavior model is proposed by this article, which is able to support software engineers in such endeavor, and other models and tools are mentioned that can be of additional help.

Key words: Software engineering, software strategic planning.

INTRODUÇÃO

Muitos profissionais de software trabalham em organizações que vivem a competição contra os concorrentes como parte inseparável de seu dia-a-dia. Neste contexto, a busca pela diferenciação estratégica e pela vantagem competitiva é esforço constante, que envolve toda a organização. Os autores sobre estratégia, administração e engenharia de produção defendem que este esforço também deve ser rápido, sob pena de não trazer todos os potenciais benefícios para quem o empreende. Recomenda-se a elaboração, ou redesenho, simultânea e integrada de processos, de tecnologias de produção e de informação, e ações de marketing como forma de reduzir os prazos de implantação e, desta forma, aumentar a vantagem sobre os concorrentes (SLACK, 2003; PORTER, 1986; HILL, 1993).

Os profissionais de software têm tido uma participação marginal neste cenário, e normalmente as decisões importantes são tomadas sem sua participação efetiva, e lhe resta o papel de participar da implantação de um plano formulado em outras áreas da organização. Como resultado, acontecem os conflitos, desgastes e a frustração entre as áreas que decidem e as que executam os planos (HILL, 1993).

É preciso reconhecer que há razões para esta exclusão do processo decisório em nível estratégico, pela tradicional dificuldade de diálogo entre os profissionais das áreas de negócio e os de software. Os dois grupos têm formação técnica diferente, sendo os temas de tecnologia da informação (TI) normalmente pouco familiares à maioria dos profissionais das diferentes áreas de negócio: finanças, marketing, vendas, produção, RH; enquanto os temas sobre estratégia e processos de negócios são pouco explorados e estudados pelos profissionais de TI, pois cada grupo de profissionais realiza um trabalho permanente de acompanhamento dos desenvolvimentos de produtos, das técnicas e processos de sua área de atuação. Assim, à medida que profissionais especializados aprofundam seus conhecimentos específicos, aumenta a dificuldade de diálogo com os representantes de outras áreas. Os altos executivos de TI vivem esta realidade com seus pares, e ouvem queixas de seus subordinados sobre este problema na forma de uma frase freqüentemente repetida: "Os usuários não sabem o que querem!". Este tipo de situação pode não estar claramente refletida em algumas pesquisas sobre este assunto, mas quem trabalha no ramo sabe o que isto significa. Os autores entendem que o exemplo retrata bem a dificuldade de diálogo entre profissionais de formação diferente.

Faltam processos e abordagens efetivas que considerem a TI nos processos de discussão, decisão e planejamento estratégico. A literatura especializada de TI foca as atividades relacionadas com a implementação das estratégias, ao considerar as etapas de especificação, desenvolvimento, construção e teste de sistemas. Como essas atividades são realizadas a partir de parâmetros definidos na etapa anterior de planejamento estratégico das organizações, podem ser malsucedidas por terem de cumprir parâmetros estabelecidos sem a participação de profissionais de TI e, por isso, tornam-se de difícil execução. Propõe-se, portanto, mudar este cenário.

A engenharia de software busca, permanentemente, estudar melhores formas de desempenhar sua missão de contribuir para o sucesso das organizações através do desenvolvimento de sistemas de informação, e muitas são as abordagens metodológicas desenvolvidas neste intuito, as quais podem ser enquadradas em dois tipos de modelos: rigorosos e ágeis. Ao analisarmos esses modelos, percebemos que todos têm em comum o mesmo conjunto de premissas em sua elaboração, colocadas de forma mais ou menos explícita, dependendo do autor escolhido (KRUCHTEN, 2001; SUTHERLAND, 2001; GLASS, 2001; PAULK, 2001; SOMMERVILLE. 2003):

• Os problemas a serem resolvidos e as necessidades a serem atendidas devem estar claramente estabelecidos, e as condições nas quais o atendimento é considerado satisfatório (o escopo).

• A descrição das funcionalidades do software, que implementa a solução dos problemas e o atendimento das necessidades, deve ser detalhada a ponto de permitir o desenho e construção do sistema e seu respectivo teste (a especificação).

• Os prazos e custos do desenho, construção e teste do sistema são resultado do tamanho e complexidade do escopo.

A partir dessas premissas, os modelos apresentam uma série de atividades aos participantes do trabalho de desenvolvimento do sistema, ou de manutenção, bem como o formato de sua execução e as ferramentas de apoio. Novamente, podemos perceber que as condições nas quais se desenrola a aplicação dos modelos, e que asseguram a qualidade e o sucesso dos produtos finais, são as mesmas [GLASS 2001, SOMMERVILLE 2003]:

• Os participantes dialogam e trocam informações sempre que necessário, embora a maneira de fazê-lo e registrá-lo varie, conforme o modelo.

• A cooperação entre os participantes do trabalho, tanto de negócio quanto de TI, é indispensável.

• O escopo e a solução dos problemas de negócio, implementados pelo sistema, devem ser acordados em conjunto pelos participantes, e no acordo prevalecem as necessidades do negócio.

Logo, a comunicação e a cooperação efetiva e tempestiva entre os profissionais de negócio e de software é o requisito básico, independentemente do modelo adotado. Mas isto nem sempre acontece, dado que as áreas de negócio decidem com base na discussão estratégica da qual os profissionais de software e de outras áreas de produção raramente participam, pois não são percebidos como capazes de contribuir nesta discussão, dado que seu conhecimento é considerado restrito aos temas de tecnologia. Essa prática é reconhecidamente prejudicial para as áreas envolvidas na posterior implantação das estratégias, seja a área de TI ou as relacionadas à produção de bens e serviços nas empresas de manufatura (HILL, 1993).

Os conflitos surgem quando as decisões tomadas pelas áreas de negócio estabelecem limitações de prazos e custos para um dado escopo de trabalho que são inatingíveis pelas áreas de produção, no geral, e de software, em particular. Por maior que seja a comunicação durante a aplicação dos modelos de desenvolvimento de sistemas, os parâmetros definidos na decisão estratégica podem não ser alcançados, apesar do esforço dos profissionais de software, por mais dedicados que sejam. Como prazos e custos costumam ser incompatíveis com o escopo desejado, e este é sempre uma necessidade de negócio, os modelos de trabalho adotados em engenharia de software são, na maioria das vezes, incapazes de atender aos limites estabelecidos pelo plano de negócios. Este é o ponto focal deste artigo: propor a mudança de uma prática de discussão, decisão e planejamento estratégico que aliena a área de TI e outras áreas operacionais de sua execução (HILL, 1993).

Independentemente do modelo de desenvolvimento ou manutenção de sistemas a ser adotado, a participação pró-ativa dos profissionais de software na discussão estratégica com as áreas de negócio, que acontece numa fase anterior ao trabalho de desenvolvimento e manutenção, poderia agregar valor ao possibilitar o estabelecimento de metas de objetivos, prazos e custos viáveis, indispensáveis para a aplicação bem-sucedida de qualquer modelo de trabalho a ser adotado na implementação da estratégia definida pela organização.

O propósito deste artigo é contribuir para a participação efetiva e construtiva dos engenheiros de software no processo de discussão, decisão e planejamento estratégicos com os demais profissionais da organização, e assim criar as condições que promovam o sucesso de seu trabalho nas atividades de implementação das estratégias. Chamamos engenheiro de software ao profissional de TI com formação em arquitetura, desenvolvimento, manutenção e operação de sistemas de informação, independentemente de seu nível hierárquico na organização.

Adicionalmente, será mostrado que a visão estratégica também dá subsídios para decidir sobre a escolha do tipo de modelo de desenvolvimento a ser adotado na implementação dos planos de negócio: se ágil ou rigoroso. Na segunda parte deste artigo, se estabelecerá o problema de estratégia a ser resolvido e a maneira de os profissionais de software atuarem em sua solução e, na terceira parte, serão exploradas as diversas formas de atuação a serem utilizadas de acordo com as condições nas quais se desenrolam a discussão, a decisão e o planejamento estratégico na organização. Para concluir, na quarta parte, apresenta-se a conclusão e, na quinta parte, a bibliografia.

O PROBLEMA ESTRATÉGICO DA ORGANIZAÇÃO E O ENGENHEIRO DE SOFTWARE

Estratégia, planejamento estratégico e decisão estratégica são assuntos tratados na literatura especializada, com contribuições de vários autores e modelos propostos (PORTER, 1986; HILL, 1993). Certamente, estas disciplinas não estão no foco do estudo e da pesquisa em engenharia de software, mas a prática profissional indica que não podem ser totalmente ignoradas, sob pena da exclusão do engenheiro de software do processo onde estes assuntos são tratados e as conseqüentes dificuldades que trará ao seu trabalho, conforme comentado na introdução. Sendo assim, deve o profissional de software buscar um entendimento básico sobre estratégia e os problemas correlatos, de modo a poder participar ativamente da discussão e decisão estratégica pela ótica de TI, sem precisar ser um especialista no assunto. Uma atitude comum em profissionais de TI é esperar que as outras áreas definam o que precisam, pois a partir daí acreditam ser capazes de superar qualquer dificuldade. Os próximos parágrafos tentam mostrar que este comportamento precisa passar por uma mudança.

A partir de referências clássicas em estratégia (PORTER, 1986; HILL, 1993), é proposto o seguinte esquema simplificado de representação do que está envolvido na discussão e decisão estratégica. A partir de seu entendimento, o engenheiro de software pode contribuir para que uma estratégia de negócios seja elaborada considerando a TI em sua formulação.

Qualquer que seja a organização e seu modelo de discussão e decisão estratégica, ela terá de chegar às seguintes definições, conforme representado na Figura 1:

• Quais os objetivos (resultados e prazos) a serem alcançados para ter vantagem competitiva.

• Quais os problemas a serem resolvidos (ou obstáculos a serem superados) para alcançar os objetivos, e os riscos associados. Estes elementos definem, em alto nível, o escopo da estratégia.

• Quais as ações a serem realizadas e os recursos a serem utilizados para resolver os problemas e gerenciar os riscos, de modo a atingir os resultados nos prazos estabelecidos. Estes elementos determinam os custos a serem incorridos na implementação da estratégia.

Os três pontos acima se inter-relacionam, de modo que não podem ser vistos e avaliados isoladamente. Cada conjunto coerente destes três pontos forma uma estratégia, e o problema da organização é decidir qual a melhor, em face da realidade enfrentada pela organização, seja com relação ao seu ambiente (atuação dos concorrentes, dos clientes e fornecedores, do governo, etc.), seja com relação à sua situação interna (capacidade financeira, capacidade gerencial, domínio e grau de avanço em tecnologia, etc.). A análise de cada opção de estratégia irá requerer avaliações sob as óticas das diversas especialidades necessárias ou já presentes na organização (finanças, RH, TI, marketing, etc.), e a melhor estratégia é aquela capaz de coordenar de forma mais coerente os elementos apresentados na Figura 1.

O interessante é notar que este modelo pode e deve ser aplicado em camadas, ou seja, primeiro na camada da organização como um todo, e depois na camada de cada área/departamento da organização, nas quais os objetivos das áreas/departamentos suportam os objetivos gerais e se identificam os respectivos problemas, riscos, ações e recursos. Assim, deve-se percorrer a estrutura da organização tanto na vertical quanto na horizontal, para que as estratégias sejam amplamente discutidas.

Se for considerado que o objetivo da área de TI é viabilizar, com eficácia e eficiência, a implementação das estratégias de negócio por meio de sistemas de informação, tem-se de responder à pergunta: Como fazer isso? A análise da Figura 1 indica a resposta: Os engenheiros de software devem ajudar os profissionais de negócio e pensar a estratégia considerando os recursos de TI e os problemas que precisarão solucionar para atingir os objetivos de cada estratégia. Esta consideração poderá oferecer diversas opções a serem seguidas, cada uma com seus riscos, custos e prazos. O importante é notar que a área de TI tem uma interação forte com cada uma das demais áreas, podendo contribuir com os esforços de cada uma para alcançar os objetivos gerais, dado que os produtos de TI não fazem sentido isoladamente, mas sempre atuam em conjunto com outros recursos de cada área da organização. O problema da eficiência e da eficácia da organização como um todo será afetado pelo modo, mais ou menos otimizado, como os recursos da área de TI forem utilizados em combinação com os demais recursos de cada área de negócio envolvida, seja no desenvolvimento ou na operação, e isto tem de ser considerado desde o início da discussão de qualquer estratégia (HILL, 1993; LAURINDO, 2001).

A área de TI, como qualquer outra, oferece recursos na forma de pessoas, competências e tecnologias. Estes recursos têm capacidades e limitações. Discutir e decidir estrategicamente sem considerar estes fatores poderá levar ao estabelecimento de resultados e prazos inexeqüíveis para a área, e por conseqüência para a organização como um todo. Logo, a atuação dos engenheiros de software deve ser voltada para evitar esta condição indesejada, e isso poderá ser feito pela participação pró-ativa na discussão e decisão estratégica no nível da organização como um todo.

Os profissionais de negócios não têm como avaliar corretamente o papel da área TI pelo seu limitado conhecimento sobre os seus temas correspondentes, da mesma forma que o profissional de software não deve decidir sobre temas específicos de negócios. Porém, os sistemas de informação a serem desenvolvidos, ou evoluídos, não poderão sê-lo de forma isolada por uma ou outra área da organização, e aí está o espaço a ser ocupado pelo profissional de software, desde que ele tenha entendimento sobre qual deve ser sua contribuição, suas atitudes e seus limites, além de utilizar seu conhecimento técnico específico. Uma atitude de buscar a atualização permanente dos conhecimentos profissionais será útil, desde que traduzida em instrumento de diálogo com os colegas de sua área e com os representantes das áreas com as quais interage no desempenho rotineiro de suas atribuições.

O engenheiro de software também pode contribuir na definição das prioridades da implantação da estratégia, um dos exercícios mais difíceis de serem realizados por uma organização, pelos conflitos de interesses entre as áreas envolvidas. Ao colaborar no mais realista dimensionamento de objetivos, prazos, riscos e custos de implantação de cada opção estratégica sob o aspecto de TI, o exercício de priorização se aperfeiçoa pelo melhor conhecimento do impacto de cada opção estratégica, pela organização, nos resultados e prazos almejados, bem como nos recursos necessários.

A ATUAÇÃO ESTRATÉGICA DO ENGENHEIRO DE SOFTWARE

A participação do engenheiro de software no processo de discussão, decisão e planejamento estratégico deve ser focada nos aspectos em que a TI afeta a operação dos processos de negócio (volumes, performance, disponibilidade, escalabilidade, etc.), tanto os processos atuais quanto outros processos requeridos para suportar uma dada opção estratégica sendo considerada. O foco em processos é crucial para permitir análises e trocas de idéias efetivas com outras áreas de negócio, pois será através dos processos que será implementada qualquer estratégia a ser formulada. Como a área de TI sempre produz seus resultados a partir de uma interação com as áreas de negócio, seus representantes devem ter dois objetivos em mente:

• As decisões finais serão sempre das áreas de negócio, mas após considerar os aspectos de TI (capacidades e limites) envolvidos no estabelecimento do escopo, prazos e custos do que será implementado (processos e sistemas) para cumprir uma dada estratégia.

• As áreas de negócio devem estar em acordo quanto ao escopo e às prioridades de construção dos elementos nele previstos.

Se os engenheiros de software cumprirem estes dois objetivos, evitarão os problemas mais críticos no desenvolvimento e manutenção de sistemas, que são: metas impossíveis de serem atingidas e mudanças relevantes no escopo dos sistemas (GLASS, 2001). Os objetivos acima podem ser alcançados pelas seguintes ações de relacionamento e de alinhamento estratégico dos engenheiros de software, descritas a seguir.

Ações estratégicas dos engenheiros de software: relacionamento

As ações de relacionamento com as áreas de negócio se concentram em garantir o diálogo amplo com todas as partes interessadas ou afetadas pela estratégia em discussão, a partir de uma perspectiva de processos (MOONEY, 1996). A meta é construir o consenso estratégico, via a discussão prévia das opções de contribuição dos sistemas aos processos que suportarão a implantação da estratégia.

• Promover o diálogo, preferencialmente pessoal, entre os representantes das áreas de negócio e os representantes de TI; dúvidas e diferenças de percepções devem ser esclarecidas e acordadas; informações compartilhadas e avaliadas quanto ao seu impacto; todas as áreas de negócio afetadas, direta ou indiretamente, pela estratégia em discussão devem participar do diálogo. Um modelo que pode facilitar a visualização da estratégia em desenvolvimento e seu efeito nos processos e estrutura da organização é proposto em Yu (1999). Outra opção de modelo é apresentada em Boehm (2003).

• Entender a estratégia e seus elementos (Figura 1); ter claro quais os ganhos (quantitativos) e benefícios (qualitativos) almejados, bem como as dificuldades previstas; eles serão os fatores a orientar as escolhas e a definição de prioridades. Uma metodologia e uma ferramenta para este fim estão descritas em Dietz (1996) e Ruhe (2002). Considerar o ciclo de vida da organização e seus produtos na estratégia também é essencial. Uma discussão desta questão sob a ótica de software é feita em Chhillarege (2002).

• Verificar que todos estão acordados sobre o que é essencial e o que é acessório na estratégia. Negociar mudanças de escopo é perigoso sem esta definição. Aliás, o escopo mudará muitas vezes enquanto não se chegar a um consenso entre o essencial e o acessório nos sistemas, e é o entendimento da estratégia que permite uma discussão racional sobre esta questão (BOEHM, 2005).

• Identificar os requisitos para a implantação bem-sucedida da estratégia; eles serão (no todo ou em parte) os componentes do escopo final (DIETZ, 1996; RUHE, 2002). Muito importante é incluir tanto os requisitos relacionados com a operação dos processos quanto os requisitos relacionados ao gerenciamento dos processos. Este cuidado prevenirá que, posteriormente, os sistemas sejam considerados insatisfatórios por não conterem funcionalidades suficientes, seja em suporte às operações, seja em apoio ao monitoramento e controle dos processos (MOONEY, 1996; MEHANDJIEV, 2000).

• Certificar-se que as áreas de negócio estão de acordo quanto à lista de requisitos; isto reduzirá a probabilidade de grandes mudanças no escopo durante a implementação da estratégia; alertar a todos que o trabalho não deve prosseguir sem este acordo (DIETZ, 1996; RUHE, 2002).

• Promover a discussão da interdependência dos requisitos entre as áreas de negócio, pois ela suportará o estabelecimento racional das prioridades entre os requisitos (DIETZ, 1996; RUHE, 2002; YU, 1999; MEHANDJIEV, 2000).

• Estabelecer a prioridade entre os requisitos; dificilmente todos os requisitos serão implantados ao mesmo tempo, seja por restrições de prazo ou de recursos, e deve-se saber qual a seqüência prioritária nas fases de implementação da estratégia: primeira fase, segunda fase, e assim por diante. A definição de prioridades é atribuição das áreas de negócio, mas cabe ao engenheiro verificar que ela foi feita e acordada entre as áreas interessadas, especialmente após considerar os aspectos de TI envolvidos. Um exemplo de como fazer isso em um sistema complexo e seus benefícios é mostrado em Moss (2001).

• Saber quais requisitos são novidade para a organização, e quais são recorrentes; a diferença será importante para avaliar os riscos dos respectivos projetos e o modelo de desenvolvimento (ágil ou rigoroso) que será adotado. Isto é discutido intensamente em Glass (2001) e Paulk (2001).

• Incentivar a tomada de decisões (sobre requisitos e prioridades) considerando, sempre, uma estimativa de prazos e custos, tanto do ponto de vista de TI quanto de outras áreas; decidir com base apenas na "experiência" e nos "aspectos qualitativos" pode resultar em erros da definição das expectativas de orçamento e prazos dos projetos que serão realizados na fase de implantação da estratégia escolhida (BOEHM, 2003; BOEHM, 2005; WALLIN, 2002).

Ações estratégicas dos engenheiros de software: alinhamento estratégico

Ações de alinhamento estratégico são suportadas por análises técnicas, baseadas nas disciplinas de engenharia de software, voltadas para suportar a discussão e decisão estratégica, e se concentrarão nos temas relacionados ao escopo e aos requisitos dos sistema. É relevante ter em mente que, em tempo de discussão estratégica, não se deve aprofundar os detalhes sobre o escopo e os requisitos. Eles devem ser tratados num nível geral e abrangente, o suficiente para estimar custos e prazos com rapidez, através dos impactos relevantes nos processos e nos sistemas de informação da organização.

• Organizar os requisitos de cada sistema em blocos independentes, numa perspectiva modular. Este cuidado facilita tanto a discussão sob a ótica de processos com as áreas de negócio, quanto internamente com a equipe de TI (SOMMERVILLE, 2003; LAURINDO, 2001; MEHANDJIEV, 2000).

• Avaliar quais blocos, ou grupos de blocos, podem ser implementados separadamente. Este é um tema auxiliar na correspondente discussão da interdependência entre os requisitos com o restante da organização (SOMMERVILLE, 2003; MEHANDJIEV, 2000).

• Estudar as alternativas de implementação via TI dos blocos de requisitos, conforme exemplos de soluções em outras empresas e nas propostas na literatura especializada (LAURINDO, 2001; COSTA, 2003). A atualização profissional constante é um quesito básico na participação pró-ativa da formulação estratégica.

• Identificar quais as seqüências de implementação de blocos de requisitos que viabilizam a implantação de uma estratégia, a partir da definição de prioridades dos requisitos. Esta ação também é indispensável para apoiar a discussão da interdependência e das prioridades entre os requisitos (SOMMERVILLE, 2003; MOSS, 2001).

• Discutir com as áreas de negócio qual a seqüência capaz de agregar maior valor à estratégia, pois planejar implementar todos os blocos de requisitos do sistema simultaneamente tende a atrasar a realização dos ganhos e benefícios, e gera pressão por redução de prazos dos projetos, com correspondente impacto negativo na qualidade final. Atenção para a possibilidade de certos blocos de requisitos serem redefinidos para acomodar as prioridades conforme a ótica das áreas de negócio. Flexibilidade, tanto quanto o rigor técnico, na aplicação dos procedimentos de engenharia de software é primordial para manter o diálogo com outras áreas (CHILLEREGE, 2002; BOEHM, 2003; MOSS, 2001).

• Discutir com as áreas de negócio a possibilidade de uma implantação do sistema em versões sucessivas dos blocos de requisitos, através de projetos cujos escopos sejam os sucessivos conjuntos de blocos discutidos na ação anterior, de modo a acelerar a obtenção dos objetivos estratégicos desejados, enquanto não se conclui a implementação de todos os requisitos (GLASS, 2001; MOSS, 2001).

• Estabelecer um projeto para cada versão; explorar a opção de projetos serem realizados em paralelo e por equipes independentes, caso a pressão por prazos seja muito grande (MOSS, 2001). Isto certamente terá impacto nos custos de execução dos projetos.

• Os modelos de desenvolvimento de sistemas a serem adotados em cada projeto podem ser diferentes, em razão da natureza dos requisitos: para os projetos com alto teor de requisitos inovadores, a prudência recomenda um modelo rigoroso, que permita o amadurecimento e a discussão das novas idéias e dos riscos pelas vias formais e detalhadas destes modelos; para os projetos onde a inovação é mínima ou nenhuma, pode-se explorar a rapidez dos modelos ágeis, pois os riscos são também menores em razão de o conhecimento estar consolidado nas áreas de negócio (CHILLEREGE, 2002; WALLIN, 2002; GLASS, 2001; PAULK, 2001). Os prazos e custos serão afetados significativamente por esta avaliação.

• Explorar as opções de compra de sistemas, bem como a contratação de serviços na análise, desenho, construção e também testes de aceitação, sempre que os recursos da área de TI se mostrem insuficientes para a implantação de uma estratégia. Um modelo de execução desta recomendação é proposto em Farbey (2001). Muitas áreas de TI tendem a limitar o uso de terceiros em apoio à implantação das estratégias. Certamente, isto requer capacidade de seleção e de gerenciamento de outras empresas e envolve riscos significativos. Dependendo do tamanho da organização, dos recursos disponíveis na área de TI e dos parâmetros de custos e prazos da estratégia em vista, pode ser um passo inevitável a ser dado; e quanto antes, melhor.

A geração de estimativas de prazos e custos, no que concerne às atividades sobre a responsabilidade de TI, é um dos pontos-chave da atuação do engenheiro de software na tomada de decisão estratégica. As futuras revisões destes elementos, quando se fizer o planejamento detalhado dos projetos, não devem ser significativamente diferentes das estimativas utilizadas na discussão, decisão e planejamento estratégicos. Se isto acontecer, questões de credibilidade da área de TI e sua participação futura na formulação de estratégia serão levantadas. A experiência indica que se não existirem métricas de TI na organização, dificilmente serão produzidas estimativas de custos e prazos razoavelmente confiáveis, conforme analisado em detalhe em Costa (2003) e Pessoa (2000).

CONCLUSÕES

As organizações têm muito a ganhar pela participação da área de TI na discussão e formulação de estratégias de negócios, desde seus estágios iniciais. O alinhamento estratégico entre a TI e as empresas precisa ser implementado em todas as etapas de planejamento, e não apenas no momento de iniciar as atividades de desenvolvimento e manutenção de sistemas. Os dois objetivos do artigo – criar meios para a participação construtiva no planejamento estratégico e decidir sobre o tipo de modelo de desenvolvimento de sistemas a ser adotado na implantação da estratégia – foram atingidos através das ações propostas na atuação estratégica do engenheiro de software, em sintonia com a caracterização do problema estratégico das organizações.

As idéias propostas neste artigo são o resultado da prática profissional dos autores e encontram apoio e desenvolvimento de seus elementos na bibliografia citada. Foi feito um trabalho de unificação e consolidação de idéias dispersas na literatura de engenharia de software, mas relacionadas ao tema proposto.

A aplicação destas idéias dependerá da vontade dos engenheiros de software de mudarem sua forma de atuação junto às demais áreas das organizações, adotando uma postura pró-ativa nos processos de discussão e decisão em nível estratégico. Em muitas organizações haverá uma resistência natural a esta mudança, dado que outras áreas com influência dominante em termos de formulação das estratégias podem não estar acostumadas a esta forma de trabalho em conjunto. Os autores acreditam que vale a pena buscar esta mudança, a qual trará benefícios tangíveis para todos as organizações que derem a oportunidade aos engenheiros de software e, quem sabe, a outras áreas de produção que são excluídas de forma semelhante. Os argumentos em defesa desta visão de mudança estão expostos na introdução do presente trabalho.

As idéias propostas neste artigo podem ser desenvolvidas em várias direções e pontos de vista. Mencionamos, a seguir, algumas delas, e convidamos os pesquisadores em engenharia de produção a participar desta jornada:

• Como os Chief Information Officers (CIOs) podem organizar suas equipes e processos de trabalho para conseguir realizar, na prática, as sugestões propostas? Quais competências precisam ser desenvolvidas, e como?

• Quais ferramentas e modelos, dentre os citados, melhor se adaptam à realidade brasileira, em sua busca pela inserção bem-sucedida na economia mundial? Podemos sugerir outros que sejam mais adequados ao nosso contexto socioeconômico?

• A partir da resposta às questões anteriores, poderíamos escrever mais um capítulo nos livros de Engenharia de Software: Planejamento Estratégico Empresarial Integrado com Tecnologia da Informação, no Brasil? Ou, talvez, um livro dedicado exclusivamente ao tema?

Artigo recebido em 15/06/2005

Aprovado para publicação em 12/12/2005

Sobre os autores

Adalberto Faria dos Reis

Universidade Paulista

Endereço: Rua Dr. Bacelar 1212 – Térreo – CEP 04026-002 – São Paulo – SP

Telefone: (11) 5586-4120 – Fax: [phone] – E-mail: [e-mail]

Dr. Ivanir da Costa

Universidade Paulista

Endereço: Rua Dr. Bacelar 1212 – Térreo – CEP 04026-002 – São Paulo – SP

Telefone: (11) 5586-4120 – Fax: [phone] – E-mail: [e-mail]

• BOEHM, B. Value-Based Software Engineering: Overview and Agenda www.sunset.usc.edu/publications, 2005.
• BOEHM, B.; BASILI, V. The CeBASE Framework for Strategic Software Development and Evolution EDSER-3 Position Paper, www.sunset.usc.edu/publications, 2003.
• CHILLAREGE, R. The marriage of Business Dynamics and Software Engineering. IEEE Software, November/December 2002.
• COSTA, I. Contribuição para o aumento da qualidade e produtividade em uma Fábrica de Software..., tese (doutorado) EPUSP Dep. Engenharia de Produção, 2003.
• DIETZ, J.L.G.; MULDER, H.B.F. Realising strategic management reengineering objectives with DEMO www.demo.nl/documents, 1996.
• FARBEY, B.; FINKELSTEIN, A. Software Engineering Management: strategic choices in a new decade www.cs.ucl.ac.uk/staff, 2001
• GLASS, R.L. Agile versus Traditional: Make Love not War. Cutter IT Journal, v. 14, n. 12, December 2001.
• HILL, T. Manufacturing Strategy: the strategic management of the manufacturing function Second Edition, London, Macmillan, 1993.
• KRUCHTEN, P. Agility with RUP. Cutter IT Journal, v. 14, n. 12, December 2001.
• LAURINDO, F.J.B. Tecnologia da Informação: eficácia nas organizações. Ed. Futura, 2001.
• MEHANDJIEV, N.; GASKELL, C. Requirements Engineering and Strategic Decision Exploration: An area for Interdisciplinary Research
• MOONEY, J.G.; GURBAXANI, V.; KRAEMER, K.L. A process oriented framework for assessing the business value of information technology. The DATA BASE for Advances in Information Systems Spring 1996 (vol. 27, n. 2)
• MOSS, L.T.Business Inteligence Methodologies: Agile with Rigor? Cutter IT Journal, vol.14, n. 12, December 2001 .
• PAULK, M.Extreme Programming from a CMM perspective. IEEE Software, November/December 2001.
• PESSOA, M.S.P.; SPINOLA, M. Gestão do desenvolvimento de software Biblioteca da Escola Politécnica, Engenharia de Produção, Produção Docente, 2000.
• PORTER, M. Estratégia Competitiva 5 ed. Rio de Janeiro: Campus, 1986.
• RUHE, G.; EBERLEIN, A.; PFAHL, D. Quantitative Winwin A New Method for Decision Support in Requirements Negotiation Proceedings of the SEKE 2002, Ischia, Italy.
• SLACK, N. et al Administração da Produção. 2. ed. São Paulo: Ed. Atlas, 2003.
• SOMMERVILLE, I. Software Engineering 6. ed. Addison Wesley, 2003.
• SUTHERLAND, J.Agile can scale: Inventing and Reinventing SCRUM in FiveCompanies. Cutter IT Journal, v. 14, n. 12, December 2001.
• WALLIN, C.; EKDAHL, F.; LARSSON, S. Integrating Business and SoftwareDevelopment Models. IEEE Software, November/December 2002.
• YU, E. Strategic Modelling for Enterprise Integration www.cs.toronto.edu/pub, 1999.

Datas de Publicação

• Publicação nesta coleção
  27 Mar 2006
• Data do Fascículo
  Dez 2005

Histórico

• Recebido
  15 Jun 2005
• Aceito
  12 Dez 2005