Buscando Motivação

“I’ve been an analyst for a long time now and have finally come to the decision that I don’t want to be just an analyst. I want to be a really good analyst. I’m no longer satisfied with taking the word of someone else as to why things are done a certain way. I not only want to know why, I want to be part of creating a better solution. I want to be respected for my opinion. I want people to know that my opinions are rooted in facts and not just some wild hair that someone got reacting to a situation. I want to be recognized for the things I have done, the countless hours I’ve spent making processes better or providing solutions to problems. Now, what?”

Doug Goldberg, daqui.

Faltam pouco mais de 30 páginas para terminar o livro do Cockburn. Em breve vou começar a estudar para o CCBA. Ou CBAP, se conseguir comprovar as horas de análise.

 

 

 

Publicidade

Comentando a palestra “Análise de Negócios em Projetos Ágeis”

Ontem fui assistir à palestra do Claudio Kerber sobre análise de negócios ágil. Confesso que a idéia de entregar software rodando (software rodando, software rodando) mais rápido seduz, em um primeiro contato.

Porém houveram alguns pontos da palestra em que discordei do inteligentíssimo palestrante, que vou discorrer a seguir.

A melhor maneira de testar um conceito de um requisito é fazendo um protótipo funcionando do software que será entregue, numa versão “rascunho”.

Nessa ocasião, foi dado o exemplo da criação do sistema sob discussão numa página em Php, descobrir eventuais problemas do software e com a engenharia reversa, desenhar o caso de uso para que o time trabalhe.

Questionei a iniciativa pois a maioria dos analistas de negócio que conheço, conhecem código, e assim como eu, não possuem habilidade técnica para tal. Foi-me sugerido então, aplicação num Excel, Access, o que seria perfeitamente possível.

Porém, ainda discordo da prática, pois acredito que me utilizando de software para provar um requisito, apesar de parecer boa prática, corro o risco de me distanciar das necessidades do usuário e “puxar a sardinha” para o desenvolvimento. Mesmo que software rodando seja um bom argumento, há o outro lado da moeda: O stakeholder aceitar o software entregue, mesmo não atendendo 100% suas necessidades, só porque “veio rápido” e é possível “se adaptar ao software”.

Se o mundo acabasse hoje, e houvessem apenas baratas e desenvolvedores, sairia software.  Mas, se o mundo acabasse hoje e houvessem apenas baratas e analistas de negócios, não haveria software.

Hora de “puxar a sardinha” pro meu lado, não é? (rs) Se o mundo acabasse hoje e houvessem apenas baratas e desenvolvedores: Bem, não acredito que sairia software. Desenvolvedores, em sua maioria, possuem perfil detalhista e grande dificuldade de comunicação com áreas usuárias. Numa estrutura onde já houvessem stakeholders responsáveis pelo levantamento de requisitos  e priorização dos mesmos, pode até ser que isso aconteça. Num mundo onde desenvolvedores possuam grande capacidade de visualizar soluções e não componentes, também.  Desenvolvedores tendem a fazer o que é desafiador a eles, não o que agrega valor ao cliente. Bem, num mundo onde só há baratas, desenvolvedores fariam um software qualquer.

Num mundo onde só existem baratas e analistas de negócios, também não haverá software, a menos que o analista de negócios seja aquele que desenvolve algo para testar o conceito. Aí sim, teríamos software. Mas,  como eu não concordo com essa prática, minha conclusão é:

Analistas de Negócios e Desenvolvedores são habilidades complementares e não sobrevivem sozinhas, salvo raras exceções.

Como eu saí do caos completo e fui agregando valor ao meu trabalho utilizando UML e RUP, para mim parece estranho ignorar todo o resto porque simplesmente “não funciona”. Os processos do RUP, PMBOK, funcionam tão bem quanto Scrum, Kanban e Agile se aplicados corretamente. Todos os processos permitem flexibilização e aplicação de acordo com o dia-a-dia. A flexibilização também é uma faca de dois gumes:  Abre precedente para falácias sobre os processos, e aplicação dos mesmos de forma incorreta. O que mais se ouve no mercado é “trabalhamos com as melhores práticas do mercado: RUP e PMBOK”, “Usamos metodologia ágil”, ou “Temos um Scrum adaptado”. Não preciso dizer que em nenhum dos casos as empresas sequer arranham as metodologias citadas. A metodologia usada nesses casos, geralmente, é a TVN (Te vira negão).

O que é legal no Agile

Divisão do escopo

A divisão do escopo do software em pequenas partes é uma boa idéia. A iteração já era prevista no RUP, mas utilizada de forma incorreta.  Dividindo o escopo em pequenas partes, podemos validar com antecedência se o requisito levantado está sendo atendido adequadamente, eliminar riscos, etc.  Neste caso, o cliente precisa “comprar” a idéia e topar homologar a versão quinzenalmente. Entretanto, não vejo como dividir escopo em projetos de migração de dados e projetos “Big Bang”.

Indivíduos e interação entre eles mais que processos e ferramentas

É certo que ruídos de comunicação podem ser responsáveis por arruinar todo um projeto. Aquilo que é uma seção no PMBOK, é premissa no Agile. Deveria ser premissa em todos os projetos. A alta interatividade entre o próprio time possibilita entrega de valor mais rápido.

Software rodando

Sem dúvida esta é a mais legal das vantagens do Agile. Surpreender o cliente e obter feedbacks do que está bom ou não, é o que mais motiva a comunidade ágil a continuar. Poder melhorar a cada iteração é uma grande vantagem.

Feedbacks constantes

No Agile é possível verificar erros imediatamente, obter feedbacks da liderança rapidamente e o crescimento profissional e aprendizado é exponencial. Também deveria ser uma prática a ser adotada em qualquer projeto.

Colaboração com o cliente mais que negociação de contratos

Colaboração com o cliente, e colaboração do cliente, seriam as melhores ferramentas para trabalhar num projeto de software. Quebrar barreiras e diminuir distâncias é um desafio na análise de sistemas desde que ela existe.

Conclusão

Acredito que Agile, mais do que uma metodologia, é uma cultura que poderia, em grande parte, ser implantada nas fábricas de software e em clientes. Comunicação, agilidade, vontade de trabalhar, entregar valor e colaborar com o cliente, embora óbvias, são coisas que muitas vezes são esquecidas num projeto de software, tanto na cultura ágil quanto na cultura tradicional de gestão de projetos. Gerentes falastrões, analistas pouco preocupados com o resultado ou inexperientes, desenvolvedores cansados e clientes não envolvidos não darão resultado em nenhuma metodologia.

RUP com XP: Como tornar isso possível?

Baseado no material do RUP.

O RUP (Rational Unified Process) é uma estrutura de processo que o Rational Software aperfeiçoa com o passar dos anos e tem sido amplamente utilizado para todos os tipos de projetos de software, do pequeno ao grande. Recentemente um número crescente de processos “agile” – como XP (eXtreme Programming), SCRUM, FDD (Feature-Driven Development) e a Metodologia Crystal Clear têm obtido reconhecimento como métodos eficazes para a criação de sistemas menores. (Consulte www.agilealliance.org para obter informações adicionais sobre a Agile Alliance.)

A comunidade agile sintetizou um número de “boas práticas” que são especialmente aplicáveis às equipes de projeto pequenos no mesmo local. Embora o RUP seja destinado às equipes de projeto de qualquer tamanho, ele pode ser aplicado com êxito aos projetos pequenos. Em geral, o RUP e os processos da comunidade Agile têm uma visualização semelhante às boas práticas principais requeridas para desenvolver software de qualidade, por exemplo, aplicando o desenvolvimento iterativo e enfatizando os usuários.

As seguintes seções explicam como aplicar algumas das “boas práticas” identificadas na comunidade Agile para projetos com base em RUP que gostariam de se beneficiar de algumas dessas práticas. Nesse caso, o foco estará especificamente nas práticas apresentadas pela metodologia eXtreme Programming (XP). (Para obter informações adicionais sobre o XP, consulte o Web site: http://www.extremeprogramming.org.)

Práticas XP

O XP inclui quatro “atividades” básicas (codificação, teste, escuta e design), que na verdade são alinhadas mais intensamente às disciplinas do RUP. Essas atividades de XP são executadas usando um conjunto de práticas que requerem a execução de atividades adicionais, que estão mapeadas em outras disciplinas do RUP. As práticas do XPs, de acordo com o Extreme Programming Explained são:

  • O jogo do planejamento: Determine rapidamente o escopo da próxima liberação, combinando as prioridades de negócios e as estimativas técnicas. Quando a realidade superar o plano, atualize-o.
  • Pequenas Liberações: Coloca um sistema simples em produção rapidamente, em seguida, libera novas versões em um ciclo muito curto.
  • Metáfora: Guia todo o desenvolvimento com uma história simples compartilhada de como todo o sistema funciona.
  • Design Simples: O sistema deve ser projetado o mais simplesmente possível a qualquer momento. Qualquer complexidade extra deve ser removida assim que for descoberta.
  • Teste: Os programadores escrevem testes de unidade continuamente, que devem ser executados sem problemas para que o desenvolvimento prossiga. Os clientes escrevem testes demonstrando que as características foram alcançadas.
  • Recriação: Os programadores reestruturam o sistema sem alterar seu comportamento para remover a duplicação, aprimorar a comunicação, simplificar ou incluir flexibilidade.
  • Programação aos Pares: Todo o código de produção é gravado com dois programadores em uma máquina.
  • Propriedade Coletiva: Qualquer pessoa pode alterar qualquer código em qualquer lugar do sistema a qualquer momento.
  • Integração Contínua: Integra e constrói o sistema muitàs vezes por dia, sempre que uma tarefa é concluída.
  • 40 horas por semana: A regra é não trabalhar mais de 40 horas por semana. Nunca faça hora extra duas semanas seguidas.
  • Cliente On-site: Inclui um usuário real, ativo na equipe, disponível em tempo integral para responder perguntas.
  • Padrões de Codificação: Os programadores escrevem todo o código de acordo com as regras, enfatizando a comunicação por meio do código.

As atividades realizadas como resultado da prática de “jogo de planejamento”, por exemplo, mapearão principalmente para a disciplina de gerenciamento de projeto do RUP. Mas alguns tópicos RUP, como a implantação do software liberado, estão fora do escopo do XP. A obtenção de requisitos está ainda mais fora do escopo de XP, já que é o cliente quem define e fornece os requisitos. Além disso, devido aos projetos de desenvolvimento mais simples com os quais lida, a XP pode tratar de forma mais superficial as questões que o RUP aborda em detalhes na disciplina de Gerenciamento de Configuração e Mudança e na disciplina de Ambiente.

Práticas XP Compatíveis com RUP

Nas disciplinas em que o XP e o RUP se sobrepõem, as seguintes práticas descritas no XP podem ser e, em alguns casos já são, empregadas no RUP:

  • O Jogo de Planejamento: A orientação de XP sobre planejamento poderia ser utilizada para alcançar muitos dos objetivos mostrados na disciplina do Gerenciamento de Projeto do RUP para um projeto muito pequeno. Isso é especialmente útil para projetos sem muita formalidade e que não precisam produzir artefatos de gerenciamento de projeto intermediários de modo formal.
  • Design Teste Primeiro e Recriação: Essas são boas técnicas que podem ser aplicadas na disciplina de implementação do RUP. A prática de XP para testes, que requer teste anterior ao design, é uma forma excelente de esclarecer requisitos em um nível mais detalhado. Como veremos na próxima seção, a refatoração pode não ser compatível com sistemas maiores.
  • Integração Contínua: O RUP suporta essa prática por meio de construções nos níveis de subsistema e de sistema (dentro de uma iteração). Os componentes testados em unidades são integrados e testados no contexto do sistema emergente.
  • Cliente On-site: Muitas das atividades do RUP se beneficiariam muito por terem um cliente on-site como um membro da equipe, que pode reduzir o número de produtos liberados intermediários necessários, especialmente os documentos. Como meio preferido de comunicação cliente-desenvolvedor, a XP destaca a conversação, que tem como base a continuidade e a familiaridade para ser bem-sucedida; no entanto, quando um sistema, mesmo pequeno, tiver que ser transferido, mais de uma conversação será necessária. A XP permite fazer isso como uma reflexão posterior (por exemplo, projetar documentos no final de um projeto). Como não impede a produção de documentos ou outros artefatos, a XP defende que devem ser produzidos apenas aqueles que são realmente necessários. O RUP concorda, mas continua a descrever o que é necessário quando a continuidade e a familiaridade não são ideais.
  • Padrões de Codificação: O RUP tem um artefato-diretrizes de programação-que quase sempre seria considerado obrigatório. (Os perfis de risco são os principais fatores de adaptação.)
  • Quarenta Horas por Semana: Como na XP, o RUP sugere que trabalhar horas extras não deve ser uma condição crônica. A XP não sugere um limite rígido de 40 horas, admitindo diferentes margens de tolerância para o período de trabalho. Os engenheiros de software costumam trabalhar muitas horas sem gratificação extra, trabalham apenas pela satisfação de verem algo concluído, e os gerentes não necessariamente precisam colocar arbitrariamente um ponto final nisso. O que eles nunca devem fazer é impor essa prática ou se utilizar dela. Eles devem reunir métricas sobre as horas realmente trabalhadas, ainda que não compensadas. Se o registro de horas trabalhadas de um funcionário for alto durante um período prolongado, isso certamente deve ser investigado. Entretanto, essa questão deve ser resolvida entre o gerente e o indivíduo, dentro do contexto das circunstâncias em que ocorrem, admitindo preocupações que o restante da equipe poderia ter. Quarenta horas é apenas uma diretiva, mas convincente.
  • Programação aos Pares: O XP afirma que a programação aos pares é benéfica para a qualidade do código e que uma vez que essa habilidade é adquirida, ela torna-se mais agradável. O RUP não descreve o mecanismo de produção de código em um nível tão refinado, embora seja possível usar a programação em pares em um processo baseado no RUP. Algumas informações sobre a programação aos pares, assim como teste anterior ao design e refatoração, são fornecidas com o RUP, na forma de white papers. Obviamente, não é obrigatório usar essas práticas no RUP. No entanto, em um ambiente de equipe, com uma cultura de comunicação aberta, podemos arriscar um palpite de que seria muito difícil discernir os benefícios da programação em pares (em termos de efeito sobre o custo total do ciclo de vida). É normal que as pessoas se reúnam para discutir e resolver problemas em uma equipe bem integrada, sem que sejam obrigadas a fazer isso.

A idéia de que um bom processo deve ser imposto no nível “micro” não costuma ser bem recebida e pode não ser adequada a algumas culturas empresariais. Por isso, qualquer imposição rígida não é defendida pelo RUP. Entretanto, em algumas circunstâncias, o trabalho em pares, e algumas das outras práticas de equipe defendidas pela XP, é obviamente vantajoso, como cada membro de equipe pode ajudar o outro; por exemplo:

  • no início da formação da equipe, quando as pessoas ainda estão se conhecendo
  • em equipes que não tenham experiência em uma determinada tecnologia nova
  • em equipes mistas formadas tanto por pessoal experiente como por novatos

Mapeamento dos Artefatos para um Pequeno Projeto

Quando adaptamos o RUP para um projeto pequeno e reduzimos os requisitos do Produto de Trabalho de acordo, como isso se compara ao equivalente dos artefatos em um projeto XP? A Tabela abaixo mostra um conjunto típico de artefatos RUP em um pequeno projeto RUP.

Artefatos de XP Artefatos RUP
(Exemplo para Pequenos Projetos)
Histórias
Documentação adicional a partir de conversações		 Visão
Glossário
Modelo de Casos de Uso
Restrições Especificações Suplementares
Testes de aceitação e testes de unidade
Dados de teste e resultados de teste		 Plano de Teste Caso de Teste Conjunto de Testes (incluindo Script de Teste , Dados de Teste )
Log de Teste
Sumário de Avaliação de Testes
Software (código) Modelo de Implementação
Releases Produto (Unidade de Implantação)
Notas Sobre o Release
Metáfora Documento de Arquitetura de Software
Design (CRC, esboço UML)
Tarefas técnicas e outras tarefas
Documentos de design produzidos no final
Documentação de suporte		 Modelo de Design
Padrões de codificação Diretrizes Específicas para Projetos
Espaço de Trabalho
Estrutura de teste e ferramentas		 Caso de Desenvolvimento
Configuração do Ambiente de Teste
Plano de liberação
Plano de iteração
Estimativas de história e de tarefa		 Plano de Desenvolvimento de Software
Plano de Iteração
Orçamento e plano geral Caso de Negócio
Lista de Riscos
Relatórios em andamento
Registros de tempo para o funcionamento da tarefa
Dados de métricas (incluindo recursos, escopo, qualidade, tempo)
Rastreamento de resultados
Relatórios e notas sobre reuniões		 Avaliação de Status
Avaliação de Iteração
Registro de Revisão
Defeitos (e dados associados) Controles de Mudança
Ferramentas para gerenciamento de código Repositório do Projeto
Espaço de Trabalho
Pico (solução) Protótipos
Protótipo da Interface com o Usuário
Prova de Conceito Arquitetural
A própria XP (suas recomendações e diretrizes) Lista de Idéias de Teste
Diretrizes Específicas para Projetos
[Não incluído no XP] Modelo de Dados
Material de Suporte do Usuário.

Embora a granularidade dos artefatos varie nos dois lados, em geral os artefatos no RUP para projetos pequenos (do tipo com o qual a XP lidaria tranqüilamente) são mapeados sem problemas para os de um projeto de XP.

Observe que a tabela também inclui alguns artefatos que não são cobertos pelo XP, mas são necessários em muitos projetos. Isso inclui o Modelo de Dados e os artefatos relacionados à implantação, como o Material de Suporte ao Usuário.

Atividades

O RUP define uma Tarefa como trabalho executado por uma Função – seja utilizando e transformando os artefatos de entrada ou produzindo artefatos de saída novos e alterados. O RUP continua enumerando essas atividades e as categoriza de acordo com as disciplinas RUP. Essas disciplinas incluem: requisitos, análise e design, implantação e gerenciamento de projeto (entre outras).

As atividades estão relacionadas ao tempo por meio dos artefatos que produzem e consomem: uma atividade pode logicamente ser iniciada quando suas entradas estiverem disponíveis (e em um estado de maturação apropriado). Isso significa que os pares de atividades produtor-cliente podem se sobrepor no tempo, se o estado do artefato permitir. Eles não precisam obedecer a uma seqüência rígida. As atividades se destinam a fornecer diretrizes claras sobre como um artefato deve ser produzido ou alterado e podem ser usadas para ajudar o gerente de projeto no planejamento.

Combinadas por meio do RUP, já que são descritas em termos de ciclo de vida, artefatos e atividades são “boas práticas”: princípios de engenharia de software que comprovadamente produzem softwares de qualidade criados para orçamento de programação previsíveis. Através de suas atividades (e artefatos associados), o RUP suporta e realiza essas melhores práticas. Elas são temas executados através do RUP – que sustentam os principais princípios que fundamentam o RUP. Observe que a XP utiliza a noção de “práticas” também, mas, como veremos, não corresponde exatamente ao conceito de boas práticas do RUP.

A XP apresenta uma visão de desenvolvimento de software que é atraentemente simples, composta por quatro atividades básicas (codificação, teste, monitoramento e design) que devem ser ativadas e estruturadas de acordo com algumas práticas de suporte (conforme abordado no capítulo 9 do livro Extreme Programming Explained). Na verdade, como observado anteriormente, as atividades de XP estão mais relacionadas em escopo às disciplinas do RUP do que às atividades do RUP. Muito do que acontece em um projeto de XP (além de suas quatro atividades básicas) é resultado da elaboração e da aplicação de suas práticas.

Portanto, há equivalência entre as atividades de XP e RUP, mas as “atividades” de XP não estão formalmente identificadas ou descritas como tal. Por exemplo, analisando o Capítulo 4, “Histórias de Usuários”, no Programação Extrema Instalada, você encontrará o título, “Definir Requisitos com Histórias, Escritas em Cartões” e em todo o capítulo há uma mistura da descrição do processo e da orientação sobre o que são histórias de usuários e como (e por quem) elas devem ser produzidas. E continua assim; nas várias seções dos manuais de XP (com títulos que são uma mistura de ênfase em artefato e ênfase em atividade), os “itens produzidos” e os “itens feitos” são descritos em graus variáveis de prescrição e de detalhes.

O grau de prescrição aparentemente alto do RUP é resultado da abrangência e maior formalidade no tratamento de atividades e de suas entradas e saídas. Não falta prescrição à XP, porém, na sua tentativa de permanecer leve, a formalidade e os detalhes são simplesmente omitidos. A falta de especificidade não é vantagem nem desvantagem, mas a falta de informações detalhadas no XP não deve ser confundida com simplicidade. A falta de detalhes pode ser ótima para desenvolvedores mais experientes, mas, em muitos casos, a fartura de detalhes é uma grande ajuda para membros da equipe que sejam novos ou que ainda estejam tentando acompanhar o ritmo da abordagem da equipe quanto a desenvolvimento de software.

Com Atividades, assim como com Artefatos, é importante manter o foco no que estamos tentando alcançar. Executar uma atividade às cegas nunca é uma boa prática. As atividades e as diretrizes associadas estão à disposição para quando você precisar delas para atingir seus objetivos, mas não devem ser usadas como desculpa para não ter de descobrir qual é o seu objetivo. Esse pensamento é bem articulado em XP e acreditamos que deva ser aplicado a todos os usuários de RUP.

Funções

No RUP, as atividades devem ser executadas por funções (ou, mais precisamente, por indivíduos ou grupos exercendo funções). As funções também têm responsabilidade por artefatos específicos; a função responsável normalmente criará o artefato e garantirá que as mudanças feitas por outras funções (se permitidas) não danifiquem o artefato. Um indivíduo ou um grupo de pessoas pode assumir apenas de um a vários papéis. Uma função não tem que ser mapeada para uma única posição ou “slot” em uma organização.

A Programação Extrema Explicada identifica sete funções aplicáveis ao Programador XP, Cliente, Testador, Rastreador, Técnico, Consultor e Diretor e descreve suas responsabilidades e as competências requeridas das pessoas que as executarão. As referências também são feitas a essas funções em alguns dos outros manuais de XP . A diferença no número de papéis no XP e no RUP é fácil de explicar.

  • A XP não aborda todas as disciplinas do RUP.
  • Os papéis de XP equivalem mais a posições dentro de uma organização (possivelmente com várias responsabilidades) do que a papéis do RUP. Por exemplo, o Programador do XP, na verdade, executa várias funções do RUP: Implementador, Revisor de Código e Integrador, que requerem competências ligeiramente diferentes.

Funções XP e RUP em um Pequeno Projeto

Quando as funções RUP são mapeadas para um projeto pequeno, o número de funções parecidas com XP as quais elas correspondem é reduzido consideravelmente em que o número de posições ou títulos de tarefas é 5. A Tabela abaixo (retirada do RUP) mostra este mapeamento com a Função XP correspondente.

Função XP Exemplo do Membro da Equipe do Pequeno Projeto RUP Função RUP
Técnico
Consultor
Diretor		 Sally Slalom, Gerente Sênior Coordenador de Projeto
Gerenciador de Implantação
Revisor Técnico
Gerenciador de Configuração
Gerenciador de Controle de Mudanças
Cliente Envolvido (conforme documentado na Visão ) Revisor de Gerenciamento
Revisor Técnico (requisitos)
Cliente
Diretor
Rastreador		 Tom Telemark, Engenheiro de Software Sênior Analista de Sistemas
Especificador de Requisitos
Designer da Interface com o Usuário
Arquiteto de Software
Revisor Técnico
Gerenciador de Teste
Analista de Teste

Funções do Desenvolvedor (com menos ênfase)
Programador
Testador		 Susan Snow, Engenheira de Software

Henry Halfpipe, Engenheiro de Software Júnior

 Designer
Implementador
Revisor Técnico
Integrador
Designer de Teste
Testador
Redator Técnico
Rastreador Patrick Powder, Assistente Administrativo Responsável por manter o site do projeto na Web, auxiliar a pessoa que exerce o papel de Gerente do Projeto no planejamento/programação de atividades e ajudar a pessoa que exerce o papel de Gerente de Controle de Mudança a controlar mudanças nos artefatos.   Também pode auxiliar outras funções conforme necessário.

Tabela 3: Mapeando Funções XP para Funções RUP em um Projeto Pequeno

Utilizando Práticas XP com o RUP

O RUP é um framework de processo a partir do qual determinados processos podem ser configurados e, em seguida, instanciados. O RUP deve ser configurado, esta é uma etapa obrigatória, definida no próprio RUP. Especificamente falando, devemos comparar uma versão adaptada do RUP com XP, ou seja, com o RUP adaptado às características do projeto que a XP explicitamente estabelece (e as que podem ser inferidas). Um processo de RUP adaptado dessa forma poderia acomodar muitas das práticas de XP (como programação em pares, refatoração e teste anterior ao design), mas ainda não seria idêntico à XP, por causa da ênfase do RUP em arquitetura, abstração (em modelagem) e risco e de sua estrutura diferente no tempo (fases e iterações).

A XP é dirigida intencionalmente para a implementação de um processo leve para projetos pequenos. Ao fazer isso, ela também inclui descrições (pelo menos nos livros) que não são totalmente elaboradas. Em uma implementação de XP, sempre haverá itens que precisam ser descobertos, inventados ou definidos rapidamente. O RUP acomodará projetos que estejam adequados ou além do escopo da XP em escala e tipo. Como mostra este roteiro, na verdade, o RUP é perfeitamente compatível com a maioria das práticas descritas na literatura sobre XP.

Lembre-se de que a essência da XP é o foco na organização, nas pessoas e na cultura. Isso é importante em todos os projetos e, certamente, é aplicável aos projetos que usam o RUP. O uso conjunto dessas práticas seria muito vantajoso para projetos pequenos.

Chefes Tóxicos

Este artigo da Você S/A é um dos melhores que já li. Compartilho agora com vocês.

Especialistas, em recursos humanos, executivos e leitores da VOCÊ S/A dizem por que empresas toleram profissionais destrutivos e como não se deixar contaminar por eles.

Revista Você S/A – por Fernanda Bottoni

Um chefe tóxico contamina todo o ambiente com seu comportamento. Ele é aquele que nega, com atitudes, os valores da empresa em que trabalha. Ele não conhece o limite que separa a pressão por resultados da falta de respeito pela equipe. Ele desrespeita as pessoas no tom de voz, no discurso, no excesso de centralização e na incapacidade de fazer com que elas cresçam. A especialidade do chefe tóxico é dar ordens, sem se preocupar com o coletivo. A ele falta a capacidade de liderar e inspirar pessoas. Um chefe assim não é modelo para ninguém. Ele não atrai nem retém os melhores talentos na própria equipe porque simplesmente sufoca e anula o que seus funcionários têm de melhor.

Quem tem um chefe tóxico conhece os estragos que essa relação pode trazer para a saúde, para a carreira e até para a empresa que aceita esse tipo de comportamento. Contudo, tanto quem responde para um profissional com esse perfil quanto quem só ouviu dizer que ele existe não entende muito bem por que, afinal, as empresas ainda toleram essas pessoas. Para responder a essa pergunta – e também para apontar o melhor caminho para quem não quer ser envenenado por um chefe assim VOCÊ S/A reuniu, no mês passado, especialistas em gestão de pessoas, executivos e leitores da revista para discutir o assunto. O resultado da discussão você confere ao longo desta reportagem.

• Dilemas nocivos

Para começar, a resposta dos convidados à nossa questão inicial é que chefes nocivos são mantidos nas empresas por dois fatores principais: o resultado que entregam e a invisibilidade que suas toxinas podem ter para quem não está sob o mesmo guarda-chuva.

“As empresas toleram pessoas com comportamento inadequado porque elas entregam resultados no curto prazo”, diz Felipe Westin, diretor da área de desempenho organizacional da Right Management. “O que ocorre muitas vezes é que, com a desculpa de buscar resultados a qualquer custo, os chefes ultrapassam a linha tênue que separa a presssão por resultados do desrespeito à dignidade humana”, diz Marco Tulio Zanini, professor da Fundação Dom Cabral, de Minas Gerais. “Avançar essa linha é inadmissível em qualquer circunstância.”

O problema é que os limites de conduta se tornam ainda mais frágeis em um ano de crise econômica. Segundo um estudo da consultoria McKinsey, mais de 80% dos executivos reportam que as empresas onde trabalham estão mais focadas em resultados de curto prazos, mais rigorosas na aprovação de custos e ainda passaram a controlar as atividades com maior frequência. É o cenário ideal para a ocorrência de abusos, conscientes ou não. Há uma boa notícia, no entanto. Apesar de toda competitividade e guerra para crescer, as companhias começaram a perceber que acolher pessoas tóxicas nem sempre é bom negócio. “Antigamente, os funcionários eram avaliados apenas pelo resultado que alcançavam. Hoje, o comportamento também compõe a avaliação de desempenho”, diz Felipe, da Right. “A promoção de um profissional depende também de sua atitude e da forma como lida com as pessoas”.

Basicamente, as empresas começam a perceber que, no longo prazo, os chefes tóxicos geram destruição. “As companhias aprendem que os resultados apresentados por esses profissionais não são sustentáveis”, diz Maria Lúcia Ginde, diretora de recursos humanos da Kimberly-Clark. A falta de sustentabilidade a que ela se refere está relacionada à continuidade do negócio e também das equipes.

Um dos maiores sintomas da contaminação do ambiente, aliás, é a perda dos melhores profissionais de uma equipe. Um chefe tóxico não é capaz de reter talentos – um recurso caro para as empresas. “Mesmo que tenha funcionários capacitados, um chefe desses tem o dom de desmotivar um a um, utilizando as ideias do grupo para se autopromover”, diz Thiago Grossi, de 29 anos, coordenador de suprimentos corporativo da International Paper. “Felizmente, hoje em dia, a sociedade está mandando para dentro das organizações pessoas que não deixam que façam com elas o que outras gerações deixaram”, diz Rolando Pelliccia, diretor do Hay Group.

• Chefe ou líder

“Quem tem um cargo de chefia e não sabe liderar não vai alcançar resultados no longo prazo”, diz Rodrigo Drysdale, diretor de marketing da Warner Bros. Para ele, o que difere o chefe do líder é que o primeiro dá as ordens e o segundo sabe motivar e serve de exemplo para toda a equipe. “O chefe tóxico traz resultados a qualquer custo, pensando no curto prazo e muitas vezes comprometendo o longo prazo”, diz Claudia Elisa Soares, diretora de RH do Grupo Pão de Açúcar. Por outro lado, o líder é aquele que inspira, que obtém resultado fazendo com que todos deem o melhor de si numa relação de ganha-ganha com a empresa. Para Rolando, do Hay Group, o ideal para qualquer companhia é ter o chefe e o líder na mesma pessoa. “Para o RH, é uma decisão difícil abrir mão de um funcionário que entrega. Mas chega um momento em que é inevitável”, diz Maria Lúcia, da Kimberly. “Já vivi isso muitas vezes. A opção por demitir esse tipo de pessoa ocorre quando a empresa enxerga a destruição que ela causa”, diz.

• Veneno invisível

O que ocorre muitas vezes é que as organizações demoram demais para perceber a destruição causada por maus gestores. Nem sempre o veneno é visível a ponto de incomodar quem não está sob o mesmo guarda-chuva. É a tal da invisibilidade o segundo fator que leva muitas companhias a tolerar pessoas com esse perfil de comportamento. Em casos assim, quem se sente prejudicado precisa dar sinais claros da sua intoxicação. Uma atitude difícil – e arriscada – em grande parte dos casos.

Luciara Batista Lubrand, de 25 anos, que o diga. Formada em pedagogia, ela trabalhava havia três anos numa grande instituição financeira quando decidiu dar um feedback ao seu gestor antes de sair de férias. “O clima na agência estava insuportável e eu achei melhor dizer isso ao chefe. Quando voltei ao trabalho, fui demitida”, diz Luciara, que trabalhava como assistente da gerência. Embora não tenha surtido o resultado esperado, a atitude que Luciara tomou, de tentar uma comunicação direta e franca com o gestor, é a mais recomendada pelos profissionais e especialistas que participaram da mesada e ouviram o seu relato.

Os nove participantes foram unânimes ao dizer que os profissionais que querem aprender a lidar com um chefe tóxico devem tentar estabelecer um diálogo sincero – e cheio de tato – com ele. “Eu já dei um feedback a um gestor e o resultado foi positivo para todos. Foi o contrário do que ocorreu com a Luciara”, conta Thiago da International Paper.

“Muitas vezes o chefe não sabe que está fazendo mal para usa equipe,” diz Rodrigo, da Warner Bros, que também já sofreu nas mãos de um chefe tóxico que chefiava pelo terror, e não pela motivação. Claudia Elisa, do Grupo Pão de Açúcar concorda: “Conheco muito gestor que não tinha noção do impacto que causava nas pessoas até que alguém tomou coragem e falou para ele”.

• Gestão de Risco

Claro que, antes de tomar a decisão de falar com o chefe tóxico sobre a destruição que ele causa, você deve considerar os riscos que corre. Quando se trata de uma pessoa com esse perfil, é grande a possibilidade de você sofrer uma retaliação, como a que Luciara recebeu.

Avalie seus propósitos e seus objetivos. Vale a pena investir num diálogo que possivelmennte será desgastante para tentar reverter a destruição que seu chefe causa? Você realmente quer continuar na equipe, na área e na empresa? Se estiver numa companhia pequena, com poucas chances de crescer e tiver performance acima do padrão dela, é melhor nem pagar para ver. Para esse caso a recomendação é, de cara, buscar uma recolocação.

Se, ao contrário, você achar que vale o esforço, a recomendação é dizer cuidadosamente como o comportamento do chefe tem impacto sobre você – pessoal e profissionalmente. A conversa deve ser cautelosa e baseada em fatos. Não vá apenas com impressões. Reúna exemplos do comportamento do chefe e do desgaste que ele gerou.

• Falta de confiança

Embora seja a recomendação número 1 dos especialistas, nem sempre é viável falar diretamente com um chefe tóxico sobre os problemas que seu comportamento causa. Além disso, nem sempre uma conversa dificil como essa surte algum resultado. “Se o gestor não estabelecer confiança com a equipe, dificilmente alguém vai ter abertura para uma conversa dessas”, diz Marcelo de Lucca, diretor da Michael Page, empresa especializada em recrutamento de executivos.

Para casos assim, a recomendação é recorrer aos canais de denúncia anônima, que muitas empresas mantêm para apurar casos de mau comportamento. “As denúncias são encaminhadas à área de RH, que tem o papel de guardiã da cultura e dos valores da companhia”, diz Claudia Elisa, do Grupo Pão de Açúcar. Depois de averiguar a denúncia, o RH deve buscar o gestor do chefe denunciado para obter informações. “Perguntamos se ele já notou alguma coisa. Normalmente, ele já tem conhecimento da ‘toxicidade’ do funcionário”, diz ela.

Se a denúncia anônima também não surtir resultados, ou se a empresa não tiver um canal desse tipo, talvez seja o caso de levar o problema à área de recursos humanos. Essa possibilidade existe desde que o RH da sua empresa seja de fato uma área preocupada com o bem-estar das pessoas. Se ainda for um setor burocrático, nem adianta considerar a ideia. “Em muitas empresas, o RH ainda cuida da folha de pagamento e não tem poder para encarar um problema assim, que prejudica a empresa como um todo”, diz Felipe Westin, da Right. Se não houver opção, há a possibilidade de levar o problema diretamente ao chefe do seu chefe.

Essa decisão pode ser ainda mais arriscada do que a primeira – a de falar diretamennte com o tóxico. Não basta ter tato para conduzir a conversa. É essencial avaliar a cultura da organização, saber se ela aceita que um funcionário tome esse tipo de atitude. “Fazer um bypass no Brasil é muito complicado, porque quebra a lealdade, prejudica a imagem”, diz Felipe, da Right Management. “No Brasil, as relações são baseadas em lealdade pessoal, não em confiança. Quando você toma uma atitude dessas, quebra a lealdade e passa a ser visto com desconfiança”, diz Marco Tulio, da Fundação Dom Cabral. Quanto mais hierarquizada for sua corporação, maiores são as chances de essa atitude ser mal interpretada. Em ambientes informais ela tem mais chances de ser bem aceita.

• Promoções tortas

De qualquer forma, antes de fazer esse movimento, vale lembrar que, muitas vezes, seu chefe chegou à posição que ocupa pelas mãos do gestor dele. Ou seja, ao demiti-lo, o gestor do tóxico deve assumir que errou. “Se for esse o caso, o gestor pode tentar proteger o tóxico para não demonstrar sua incompetência na escolha e na promoção desse profissional”, lembra Felipe, da Right Management.

O erro de promover excelentes técnicos a cargos de chefia é mais comum do que imaginamos, mesmo em grandes empresas. Muitas vezes, as companhias promovem as pessoas antes da hora, pelo potencial que têm. Depois, precisam correr atrás de treinamento para que elas desenvolvam competências de liderança e gerenciamento de pessoas. “Eu mesma já recrutei pessoas erradas para cargos de liderannça e tive de demitir depois. Errei também porque demorei para demiti-Ias”, diz Maria Lúcia, da Kimberly-Clark. “Muitas vezes uma promoção errada faz com que a empresa perca um excelente técnico para ganhar um péssimo gestor”, diz Marcelo, da Michael Page.

• Ninguém nasce gerente

Qualquer que seja o meio de denúncia utilizado, o primeiro objetivo do profissional é fazer com que esse chefe receba um feedback e mude seu comportamento. Mas será que um tóxico tem recuperação?

Segundo Rolando, do Hay Group, depende do tipo de veneno. “Se o mau comportamento for baseado em atitudes antiéticas, esse indivíduo não tem recuperação e não deve ter outra oportunidade.” Comportamento que cria assédio sexual é outro que não tem salvação. “Minha experiência mostra que, no máximo, 10% ou 20% das pessoas que têm problemas sérios de comportamento conseguem mudar”, diz Felipe, da Right Management.

Quando se trata apenas de um gap de competência do chefe, a situação pode ser reversível. Por exemplo, quando ele é uma pessoa de confiança e até é bem intencionada, mas não deixa os subordinados crescerem – o que é um comportamento tóxico -, essa característica pode ser revertida com treinamento e coaching. Segundo Maria Lúcia, da Kimberly-Clark, cabe ao RH oferecer apoio.

• Fim de caso

Se você já tentou de tudo, se já demonstrou sua insatisfação e os impactos do mau comporrtamento de seu chefe e não obteve retorrno – ou até conseguiu retorno, mas não viu a situação mudar-, é mesmo hora de buscar uma recolocação.

Uma boa estratégia pode ser a de definir – e comunicar – um prazo limite. “Diga a seu gestor, ou ao RH, que você está disposto a esperar mais três meses por alguma mudança. Deixe claro que, se nenhuma mudança ocorrer, sua saída será inevitável”, diz Claudia Elisa, do Grupo Pão de Açúcar.

“Quem entrega resultados e se sente intoxicado pelo chefe deve sair debaixo dele o mais rápido possível”, diz Marco Tulio, da Fundação Dom Cabral. O alerta é para o bem da sua carreira e também da sua saúde. Se demorar demais, você poderá acabar viciado.

Análise de Negócios em Projetos Ágeis, por @oclaudiobr

Quem se interessa pelo assunto, pode correr pra palestra que vai rolar dia 27/01. Seguem as informações:

Mais valor. Mais rápido.

Objetivo

“Análise de negócios é análise de negócios”, contudo, em um contexto ágil, parece que estamos fazendo análise de negócios em uma montanha russa. A boa notícia é que é realmente divertido (para quem tem estômago).

Público Alvo: Profissionais interessados em entregar mais valor mais rápido para as organizações através de
soluções de software.

Palestrante: Claudio Brancher Kerber

Data e Horário: 27 de Janeiro (quinta-feira), às 19:10h (credenciamento a partir das 18:30h)

Investimento:
R$ 70,00.
Desconto de 50% (R$ 35,00) para pagamentos efetuados até 26/01/2011
R$ 30,00 para Associados do IIBA Internacional (somente para pagamentos efetuados até 9/12/2010)

Forma de Pagamento: Depósito Bancário ou Transferência

Local: Fundação Carlos Alberto Vanzolini – Av. Paulista, 967, 5° Andar, Bela Vista, São Paulo (próximo ao metrô Trianon-MASP)

Inscrições1) Enviar e-mail para eventos@saopaulo.theiiba.org
Assunto “Inscrição – Análise de Negócios em projetos ágeis”
Informar:
1)      Nome
2)      E-mail
3)      Telefone com DDD
4)      Número de Membership Emitido (Associados IIBA Internacional)
5)     Aguardar email do Comitê de Eventos IIBA-SP com instruções para pagamento.

REGRAS: Não será realizada reserva de vaga.
Não será realizada inscrição por telefone e/ou no local do evento.
Não haverá devolução da taxa de inscrição e/ou o crédito da mesma em caso de desistência.
A efetivação da inscrição dependerá do envio dos dados do comprovante de pagamento.
Depósitos ou transferências deverão ser feitos até 4ª feira – dia 26/01/2010, dentro do horário do expediente bancário.
As inscrições feitas dia 27 de janeiro deverão ser pagas pessoalmente, conforme regra de valor integral, durante o horário do credenciamento – das 18:30h às 19:10h, do dia 27 de janeiro.
O pagamento feito pessoalmente deverá ser somente em espécie, no valor integral de R$ 70,00 para Associado e Não-Associado do IIBA e estará sujeito a disponibilidade de vaga caso não tenha feito inscrição por e-mail.
Patrocinadores:
Interdual Análise de Negócios
Rezende Fontes e Braga – Sociedade de advogados
Fundação Vanzolini
DoMore! soluções em produtividade

E o RUP?

O que é RUP? A sigla RUP quer dizer “Rational Unified Process”, ou, em português, “Processo Unificado Rational”. Mas isso não significa que o RUP seja realmente um processo, mas sim, um framework de boas práticas. Digo isso porque o RUP apenas sugere algumas boas práticas para o desenvolvimento de software, e não implica que nenhum software será entregue caso as práticas do RUP não sejam seguidas.

Cheguei a ler o RUP 5.0 inteiro, no que compete a papéis do analista, e pude observar que o RUP possui todas as orientações para o desenvolvimento de um software.

O que as pessoas querem saber quando te perguntam: Você sabe RUP?

O RUP, além de ser um framework de boas práticas, possui uma série de templates de artefatos a serem entregues nas diversas fases do desenvolvimento de software. Quando alguém te pergunta se você conhece RUP, está se referindo ao seu conhecimento quanto ao uso destes artefatos em cada fase do projeto.

Mas não são artefatos demais?

Sim, são. Porém, existem alguns artefatos que são “padrão” de uso e exigidos na maioria dos processos de desenvolvimento de software, e outros que são apenas complementos, ficando o usuário do RUP livre para decidir quais artefatos serão necessários.

Como o RUP, que é um “manual”, consegue saber da necessidade diária do meu projeto?

Aí é que está a mágica: ele não sabe. Mas possui uma série de técnicas que são comuns à maior parte dos projetos, e pode ser adaptado conforme a necessidade.

RUP é o Waterfall, ou Processo Sequencial Clássico?

Essa é uma das maiores confusões em relação ao RUP. O rup possui as quatro fases de desenvolvimento do software, a seguir:

  • Iniciação
    • A meta dominante da fase de iniciação é atingir o consenso entre todos os envolvidos sobre os objetivos do ciclo de vida do projeto. A fase de iniciação tem muita importância principalmente para os esforços dos desenvolvimentos novos, nos quais há muitos riscos de negócios e de requisitos que precisam ser tratados para que o projeto possa prosseguir. Para projetos que visam melhorias em um sistema existente, a fase de iniciação é mais rápida, mas ainda se concentra em assegurar que o projeto seja compensatório e que seja possível fazê-lo.
  • Elaboração
    • A meta da fase de elaboração é criar a baseline para a arquitetura do sistema a fim de fornecer uma base estável para o esforço da fase de construção. A arquitetura se desenvolve a partir de um exame dos requisitos mais significativos (aqueles que têm grande impacto na arquitetura do sistema) e de uma avaliação de risco. A estabilidade da arquitetura é avaliada através de um ou mais protótipos de arquitetura.
  • Construção
    • A meta da fase de construção é esclarecer os requisitos restantes e concluir o desenvolvimento do sistema com base na arquitetura da baseline. A fase de construção é de certa forma um processo de manufatura, em que a ênfase está no gerenciamento de recursos e controle de operações para otimizar custos, programações e qualidade. Nesse sentido, a mentalidade do gerenciamento passa por uma transição do desenvolvimento da propriedade intelectual durante a iniciação e elaboração, para o desenvolvimento dos produtos que podem ser implantados durante a construção e transição.
  • Transição
    • O foco da Fase de Transição é assegurar que o software esteja disponível para seus usuários finais. A Fase de Transição pode atravessar várias iterações e inclui testar o produto em preparação para release e ajustes pequenos com base no feedback do usuário. Nesse momento do ciclo de vida, o feedback do usuário deve priorizar o ajuste fino do produto, a configuração, a instalação e os problemas de usabilidade; todos os problemas estruturais mais graves devem ter sido trabalhado muito antes no ciclo de vida do projeto. No fim do ciclo de vida da Fase de Transição, os objetivos devem ter sido atendidos e o projeto deve estar em uma posição para fechamento. Em alguns casos, o fim do ciclo de vida atual pode coincidir com o início de outro ciclo de vida no mesmo produto, conduzindo à nova geração ou versão do produto. Para outros projetos, o fim da Transição pode coincidir com uma liberação total dos artefatos a terceiros que poderão ser responsáveis pela operação, manutenção e melhorias no sistema liberado.

Mas isso não significa que cada fase só executará uma vez, ou que elas tenham dependência para início. O gráfico das baleias mostra exatamente como deve ser o ciclo de vida do projeto:

Como é possível verificar, a modelagem de negócios acontece durante todo o projeto, por exemplo. A parte de requisitos é forte durante as fases de Iniciação e Elaboração, mas continua durante todo o projeto, assim como as demais disciplinas. Isso diferencia o RUP do Waterfall, que possui uma única iteração ao longo do projeto, com interdependências entre fases.

Habilitar uso seguro de redes sociais no trabalho desafia a TI

Gestores são pressionados a afrouxar as regras de acesso às comunidades virtuais como o LinkedIn, o Facebook e o YouTube.
Por Network World/EUA

A tentação de bloquear o acesso às redes sociais no ambiente de trabalho é grande, mas não tem futuro. Os departamentos de TI são pressionados a afrouxar as regras de acesso às comunidades virtuais como o LinkedIn, o Facebook e o YouTube.

Essa pressão vem de várias frentes diferentes e tem motivações igualmente variáveis. As equipes de marketing e comerciais, por exemplo, vão contatar seu público usando essas mídias. Na perspectiva do RH das organizações, funcionários com vivência nessas redes serão melhor avaliados, mas de nada valerá contratar esses colaboradores se não puderem exercer seus conhecimentos no trabalho.

Mudança de paradigma

O vice-presidente e analista-chefe da Forrester, Chenxi Wang, afirma que há um movimento grande de mudança de paradigma nas organizações, à medida que elas adotam modelos mais liberais de interação digital de seus funcionários. Falta apenas encontrar a mistura balanceada entre liberdade e segurança.

Especialistas no assunto sugerem que a abertura seja efetuada de maneira gradativa e com base em um planejamento. Se, por um lado, empresas afrouxaram sensivelmente o uso do email, muito pouco foi feito com o objetivo de transferir essa liberdade aos sites de relacionamento.

A primeira tarefa das empresas é estender as políticas de uso do email pessoal a todas as vias de comunicação digital, diz Bradley Anstis, que ocupa a cadeira de vice-presidente de estratégia digital da empresa M86 Security.

Cada caso um caso

No planejamento da abertura social devem ser considerados os níveis de acesso com foco em segurança. O YouTube, por exemplo, não precisa ser acessado por todos. O mesmo pode ser dito sobre os aplicativos para Facebook. Quem sabe, seja questão de configurar acesso em modo leitura apenas, o que impede que programas alheios aos interesses da empresa gravem qualquer bit no sistema corporativo. Como em tudo, educação é a pedra fundamental nessa questão e deve abordar o perigo de vazamento de informações confidenciais.

Nosso papel não é nem será o de policiar a diversão e a alegria das pessoas, diz Anstis. Basta às empresas compreender isso e habilitar o uso seguro das redes sociais no trabalho, completa.

Pesquisa

Um levantamento realizado pela empresa FaceTime Communications com 1.654 gerentes de TI e usuários de redes sociais em 2010 revelou que a presença de redes sociais no ambiente de trabalho é certa para 62% dos respondentes. Recursos digitais, como a partilha de arquivos acontecem em 74% das empresas, respondem os usuários. Aos olhos de gestores, porém, essa realidade não é percebida. Apenas 32% destes responderam que existe a disponibilidade desse tipo recurso em suas estruturas. Outra discrepância é percebida quando o assunto são programas de chat. 95% dos usuários responderam que sim, usam esses programas ou sites em seu trabalho. Apenas 31% dos administradores de TI confirmam esse fato.

Outras ameças

Mas o vazamento de dados é apenas um dos pontos críticos. Há várias ameaças digitais que comprometem as organizações por violar determinadas regulamentações de segurança. É o caso dos botnets, de malwares e de tentativas de phishing. Para John Vecchi, líder de marketing de produtos da empresa Check Point, a web 2.0 traz consigo muitos desafios aos departamentos de TI. Especialmente no que tange à proteção dos dados, em que o surgimento de vários canais aumenta de forma quase exponencial o perigo de informações confidenciais ganharem a rede.

A regulamentação de mídias sociais pode, e deve, acontecer junto com a configuração das políticas de grupo e de usuário. Normalmente isso acontece via integração ao diretório corporativo. Ferramentas que não tenham opções de filtragem nesse nível não bastam para garantir a segurança dos dados. Outra questão de fundamental importância é gerir o acesso (leia-se o bloqueio) de malwares baseados em scripts e verificar a natureza de dados baixados e carregados na internet tudo com vistas a preservar as políticas internas.

Logo

Se, por um lado, é importante resguardar os bens da empresa dos riscos impostos pelo uso de redes sociais, é igualmente importante aceitar que o uso do Facebook, Twitter e do LinkedIn não têm como ser erradicados à base de cliques e de configurações em servidores. Os funcionários irão encontrar um jeito de entrar na rede, nem que seja para comemorar que venceram os esforços da organização e comentar quando perceberem na tentativa de separá-los de seus amigos.

O negócio é manter uma mente aberta sobre seus colaboradores e como percebem as mídias sociais, recomenda Wang. Acredito que seja fundamental informar os usuários sobre os riscos associados às redes de relacionamento, dar-lhes as ferramentas para que se protejam e deixar que tomem as medidas que acharem necessárias.

Como atender os usuários utilizando Pacotes de Software

Quais tipos de requisitos são necessários para escolha de um pacote de software de prateleira (COTS package)?

Desenvolver requisitos para escolher um software de prateleira é diferente de desenvolver requisitos para um sistema feito "em casa", mesmo que uma RFP (request for proposal) não seja nada mais que um pacote de requisitos. Estas dicas ajudarão com requisitos para escolha de um pacote.

Ajude seus usuários a encontrar seus objetivos e necessidades primárias antes de agendar demonstrações.

Vendedores de software dão demonstrações excelentes de seus produtos. Eles mostram funcionalidades surpreendentes, coisas que os usuários de negócio nem sabiam que existiam. Isso pode ocasionalmente distrai-los das necessidades principais que motivaram a procura por um produto no mercado. Trabalhe com os stakeholders para definir objetivos prioritários e utilize uma abordagem ágil de priorização. Por exemplo, os stakeholders definiram a lista de funcionalidades que eles precisam e então priorize as top 5 ou 10. Faça com que eles concordem que você não escolherá um pacote até que as 5 ou 10 necessidades sejam satisfeitas, não importa o quão impressionante seja a demonstração! Dê as necessidades aos vendedores para que eles possam guiar a apresentação pelas necessidades.

Converse com a área técnica para verificar suas necessidades e limitações. Você pode economizar tempo eliminando fornecedores que não se encaixam no plano de arquitetura antes das demonstrações começarem.

Requisitos não-funcionais são a chave.

Juntamente com os requisitos não-funcionais fornecidos pelo negócio, as limitações e requisitos não-funcionais fornecidos pela área técnica são alguns dos requisitos mais importantes para incluir na RFP. Todo pacote contábil fornece planilhas de contas, então sua escolha será baseada em outras necessidades. Por exemplo:

– Qual a velocidade de acesso a uma conta?

– As contas podem ser alteradas?

– Qual o nível de precisão garantido para os cálculos?

– Qual a dificuldade para fazer um relatório personalizado?

– Os dados podem ser exportados para outros pacotes?

Interfaces são caras.

Em alguns ambientes, interfaces entre o pacote de software e o legado serão custosos, consumindo tempo de parte do projeto. Identificar todas as interfaces antes da escolha e ter uma estratégia manual ou técnica para cada migração de dados. Descobrir que um pacote não consegue se comunicar com outro depois de implantado é um erro muito caro.

Reconheça lacunas.

Nenhum pacote pronto de software satisfará todas as necessidades dos usuários. Discuta as escolhas com todos os stakeholders e certifique-se que as expectativas são realistas.

Este material foi traduzido da newsletter do IIBA®, pela autora deste blog.