Onde colocar as palavras-chave

Continuando com as diferentes técnicas para o melhor registro, comentamos os distintos lugares onde devemos introduzir palavras e frases chave em nossa página.

Agora vamos ver onde situar as palavras e frases chave, assim como a descrição dentro da página web.

O título da página

O primeiro que devemos fazer é escolher um título apropriado, ou seja, um título que descreva bem a página onde se encontra, e que contemple outras pequenas considerações:

• Tem que ser muito descritivo. Algo como Oficina mecânica não é suficiente. Deveria indicar também a localização da oficina ou qualquer informação adicional que possa enriquecer a descrição, como o nome da oficina ou sua especialidade.
• Há de incluir as palavras-chaves que definem nosso site. Ademais, deveria conter as palavras mais importantes a princípio, pois muitos buscadores só observam as primeiras palavras do título.
• A extensão do título também é outro parâmetro que deve ser ajustado. Um título curto é pouco adequado, mas os buscadores podem pensar que estão fazendo spam se encontram um muito longo. Existem muitas considerações a respeito, mas podemos indicar que o mais adequado é que seja de 15 a 20 palavras de extensão ou da ordem dos 50 a 100 caracteres.

Um título apropriado para o mecânico de Copacabana seria:

Oficina mecanica de carros em Copacabana, Rio de Janeiro, Tudo Auto. Conserto de para-brisa eletricidade troca de óleo.

Primeiros parágrafos

É outra coisa que muitos motores de busca observam ao indexar uma página web. Se nossa web permite, devemos colocar um primeiro parágrafo que sirva de introdução a tudo o que podemos encontrar na página. Este primeiro parágrafo:

• Deverá estar colocado dentro do , o mais perto possível deste. Se for possível, evitaremos que entre a etiqueta e o primeiro parágrafo existam outras etiquetas, como imagens.
• Deverá ser legível. Este texto será visto na página, como qualquer parágrafo, por isso, deve ler-se bem.

Poderíamos colocar na página do mecânico este texto depois da etiqueta

Tudo Auto

Em Copacabana, situado na rua Siqueira Campos, no Rio de Janeiro, encontra-se nossa oficina de conserto de automóveis e troca de peças. Será um prazer lhe atender e oferecer nossos serviços de todo tipo para seu carro, como troca de óleo, conserto de para-brisa, entre outros.

De maneira adicional, e sobretudo durante os primeiros parágrafos podemos utilizar outras regras, de utilidade mais duvidosa.

• Utilizar os cabeçalhos (etiquetas

  e similares) para destacar os títulos das páginas sempre que se possa.

• Definir os atributos ALT das imagens com palavras-chave.

Estas técnicas devem ser usadas sempre com moderação, evitando qualquer uso excessivo que acabe prejudicando a posição do site.

Papel: Analista de Teste

O papel Analista de Teste é responsável por inicialmente identificar e posteriormente definir os testes necessários, monitorar a abrangência dos testes e avaliar a qualidade geral obtida ao testar os Itens de Teste-alvo. Este papel também envolve a especificação dos Dados de Teste necessários e a avaliação do resultado dos testes conduzidos em cada ciclo de teste. Às vezes, este papel também é denominado Designer de Teste ou considerado parte do papel Testador. Este papel é responsável por:
Identificar os Itens de Teste-alvo a serem avaliados pelo esforço de teste
Definir os testes apropriados necessários e quaisquer Dados de Teste associados
Coletar e gerenciar os Dados de Teste
Avaliar o resultado de cada ciclo de teste

Pessoal
Os papéis organizam a responsabilidade de executar atividades e desenvolver artefatos em grupos lógicos. Cada papel pode ser designado a uma ou mais pessoas, e cada pessoa pode desempenhar um ou mais papéis. Ao definir o perfil do papel Analista de Teste, você deve considerar as habilidades exigidas para o papel e as diferentes abordagens que podem ser feitas para designar o papel ao pessoal.
Habilidades
As habilidades e o conhecimento exigidos para o papel Analista de Teste incluem:
boa habilidade analítica
uma mente desafiadora e curiosa
atenção aos detalhes e tenacidade
entendimento de falhas de software comuns
conhecimento do domínio (muito desejável)
conhecimento do sistema ou aplicativo em teste (muito desejável)
experiência em vários esforços de teste (desejável)
Abordagens de designação de papéis
O papel Analista de Teste pode ser designado das seguintes formas:
Designe um ou mais membros da equipe de teste para desempenhar os papéis Analista de Teste e Testador. Esta é uma abordagem adotada com freqüência, sendo especificamente adequada para equipes pequenas e equipes de teste de qualquer tamanho, formadas por um grupo experiente de Testadores com nível de experiência relativamente igual.
Designe um ou mais membros da equipe de teste para desempenhar somente o papel Analista de Teste. Esta abordagem funciona bem em equipes grandes, particularmente em situações nas quais existem especialistas do domínio com experiência mínima em implementação de testes, mas que possuem um nível de conhecimento significativo do domínio para especificar os testes adequados e determinar os resultados apropriados para esses testes. Esta estratégia de designação de papéis também pode ser usada para separar responsabilidades se algum membro da equipe de teste tiver experiência mínima em automatização de testes e, em virtude disso, apresentar dificuldade para desempenhar os papéis Testador e Designer de Teste.
Designe um membro da equipe para desempenhar os papéis Analista de Teste e Gerente de Testes. Esta estratégia é uma outra opção para equipes de teste de pequeno a médio porte. Atente para que as minúcias do papel Analista de Teste não afetem de modo adverso as responsabilidades do papel Gerente de Testes. Para minimizar esse risco, atribua tarefas de Analista de Teste menos críticas a uma pessoa que desempenhe esses dois papéis, deixando as tarefas mais importantes para os membros da equipe que não possuem nenhuma responsabilidade direta de gerenciamento.
Designe um ou mais membros da equipe para desempenhar os papéis Analista de Teste e Especificador de Requisitos. Esta estratégia é uma outra opção para equipes de teste de pequeno a médio porte e geralmente é utilizada quando existem especialistas do domínio disponíveis para desempenhar ambos os papéis. Tenha cuidado para destinar o esforço apropriado ao atendimento dos dois papéis. [[[Also need to provide some guidance on how to staff based on the specialized
testing skills required - "Load" Testing, Functional Testing, Web-Site Structural
Testing, Installation, Unit Testing (use of PQC type tools) etc.]]]--->
Observe também que os requisitos de habilidades específicas variam de acordo com o tipo de teste a ser realizado. Por exemplo, as habilidades necessárias para analisar corretamente os requisitos de teste de carga do sistema são diferentes daquelas necessárias para analisar os requisitos de teste funcional do sistema.
Informações Adicionais
Recomendamos a leitura da obra Lessons Learned in Software Testing [KAN01], de Kaner, Bach e Pettichord, que contém uma excelente compilação de aspectos importantes para as equipes de teste. Os capítulos Role of the test group, Thinking like a tester, Test planning and strategy e Bug advocacy são de interesse específico do papel Analista de Teste.

TERMO DE COMPROMISSO DE ESTÁGIO

Ai galera conversando com amigos meus que não conseguem trabalho área recomendei que f$izessem estágios,pois é uma maneira de concilhar o trabalho a parte pratica com o que se

aprende nas nos cursos, alem do mais te da uma ajuda, para engressar no mercado de trabalho, pois bem achei interessante postar um modelo de contrato de estagio, nada mais justo de que levar o proprio contrato de estagio, mas muito cuidado com os exageros EHEHEHEEHE!

esse modelo peguei do site do imasters como sempre um bom site coisas interessantes, entrem la para ver.
http://www.imasters.com.br

Abraço a todos espero qeu seja util.

TERMO DE COMPROMISSO DE ESTÁGIO

IDENTIFICAÇÃO DAS PARTES CONTRATANTES

CONCEDENTE: (Nome da Concedente), com sede em (xxx), na Rua (xxx), nº (xxx), bairro (xxx), Cep (xxx), no Estado (xxx), inscrita no C.N.P.J. sob o nº (xxx), e no Cadastro Estadual sob o nº (xxx), neste ato representada pelo seu diretor (xxx), (Nacionalidade), (Estado Civil), (Profissão), Carteira de Identidade nº (xxx), C.P.F. nº (xxx), residente e domiciliado na Rua (xxx), nº (xxx), bairro (xxx), Cep (xxx), Cidade (xxx), no Estado (xxx);

ESTAGIÁRIO: (Nome do Estagiário), (Nacionalidade), (Estado Civil), (Profissão), Carteira de Identidade nº (xxx), C.P.F. nº (xxx), residente e domiciliado na Rua (xxx), nº (xxx), bairro (xxx), Cep (xxx), Cidade (xxx), no Estado (xxx). As partes acima identificadas têm, entre si, justo e acertado o presente Termo de Compromisso de Estágio, que se regerá pelas cláusulas seguintes e pelas condições descritas no presente.

DO OBJETO DO CONTRATO

Cláusula 1ª. O presente tem como OBJETO a prestação de serviços a ser feita pelo ESTAGIÁRIO que se encontra no (xxx) período do curso de (xxx) da Universidade/Faculdade (xxx).

Cláusula 2ª. O objetivo primordial do presente instrumento é a experiência prática do aprendizado teórico, aperfeiçoamento técnico, científico e de relacionamento humano, de forma a complementar o ensino e a aprendizagem em consonância com o calendário escolar.

Cláusula 3ª. Quaisquer dúvidas concernentes às atividades realizadas pelo ESTAGIÁRIO d$everão ser comunicadas expressamente à CONCEDENTE.
DA JORNADA

Cláusula 4ª. O ESTAGIÁRIO terá uma jornada total de (xxx) horas semanais, sendo cumpridas de (xxx) à (xxx) horas diárias, no período (diurno ou vespertino), ficando deste modo completamente compatível com o horário escolar. Cláusula 5ª. No período das férias escolares os contratantes estabelecerão os critérios específicos para o cumprimento do mesmo.
DO COMPROMISSO

Cláusula 6ª. No decorrer da vigência do presente instrumento o ESTAGIÁRIO se compromete a realizar todas as atividades requeridas pela CONCEDENTE, ressalvando-se aquelas que são completamente incompatíveis com o aprendizado técnico-escolar. Cláusula 7ª. O ESTAGIÁRIO se compromete a prestar informações ou esclarecimentos sobre qualquer óbice que porventura venha a adquirir junto à Instituição de Ensino a qual estuda ou, no cumprimento de suas funções.
DA REMUNERAÇÃO

Cláusula 8ª. As atividades exercidas regularmente serão remuneradas por meio de bolsa-estágio, no valor de R$ (xxx) (Valor Expresso), pago mensalmente em dinheiro, até o quinto dia útil subseqüente ao trabalhado. Cláusula 9ª. A bolsa referida acima, não configura remuneração trabalhista, portanto pode ser modificada mediante ajuste das partes. }

Cláusula 10ª. O ESTAGIÁRIO está incluso(a) na cobertura do seguro contra acidentes pessoais de trabalho, mediante a apólice nº (xxx) da Instituição (xxx).
DA RESCISÃO

Cláusula 11ª. As partes poderão interromper, rescindir ou renovar por tempo indeterminado o presente instrumento, desde que haja comunicado expresso por escrito.

Cláusula 12ª. A rescisão se fará por ato unilateral desde que comunicada expressamente pela parte interessada com antecedência mínima de uma semana, bem como, e o ESTAGIÁRIO agir de forma prejudicial em relação ao CONCEDENTE.
DO PRAZO

Cláusula 13ª. O presente compromisso terá o lapso temporal de validade de (xxx) meses, a iniciar-se no dia (xxx), do mês (xxx) no ano de (xxx) e findar-se no dia (xxx), do mês (xxx) no ano de (xxx).
CONDIÇÕES GERAIS

Cláusula 14ª. O presente contrato passa a vigorar entre as partes a partir da assinatura.

Cláusula 15ª. O presente instrumento não se configura sob nenhuma forma vínculo empregatício. Cláusula 16ª. O estágio tem fundamento e base na formação curricular do ESTAGIÁRIO, caracterizando sua pré-formação e profissionalização, complementando a tarefa escolar.

Cláusula 17ª. Faz parte do presente a apólice de seguros prevista na Cláusula 10ª.

Cláusula 18ª. Ao final do presente termo o ESTAGIÁRIO elaborará relatório completo das atividades exercidas o qual será assinado pela CONCEDENTE e pela Instituição de Ensino.

Cláusula 19ª. A Instituição de Ensino a qual o ESTAGIÁRIO está diretamente vinculado se compromete também por meio deste instrumento a remeter semestralmente comprovante de matrícula do mesmo.
DO FORO
Cláusula 20ª. Para dirimir quaisquer controvérsias oriundas do CONTRATO, as partes elegem o foro da comarca de (xxx); Por estarem assim justos e contratados, firmam o presente instrumento, em duas vias de igual teor, juntamente com 2 (duas) testemunhas.

(Local, data e ano).
(Nome e assinatura do Estagiário)
(Nome e assinatura do Representante legal da Concedente)
(Nome, RG e assinatura da Testemunha 1)
(Nome, RG e assinatura da Testemunha 2)

O profissional do século XXI

Ser um profissional competente e bem informado no mercado de trabalho atualmente tornou-se necessário devido alto "turn over" de pessoal nas empresa. Estar bem informado sobre o que acontece no mercado e em suas áreas de atuação é sempre bom, e nada que jornais, revistas e mesmo a internet não possam lhe oferecer gratuitamente no tempo e horários que você estiver disponível.

O profissional deve estar bem informado sobre sua área de atuação e mais, a formação técnica e/ou superior aliado às certificações são extremamente necessários para o reconhecimento do profissional. A experiência é um ponto forte que pode fazer a diferença, mas que se tornar quase invisível quando não se tem formação. As empresas trabalham com documentos, certificados, diplomas, currículos e com experiência na última hipótese de não se encontrar um profissional com todos os pré-requisitos anteriormente citados.

Vale lembrar que a afirmação "quanto mais estudo, mais aprendo" não é linear crescente, e o mesmo vale para "quanto mais experiência ganho com trabalho, mais aprendo", em certo ponto os dois podem estabilizar ou mesmo cair se o conhecimento não for constantemente renovado. Conhecimento teórico aliado à experiência prática é o melhor caminho para se tornar um profissional ideal.

A postura profissional no ambiente de trabalho deve ser pensada e calculada:

• Ouvir e estar atento a opiniões a favor e contra, principalmente quando não dominar o assunto em questão;
• Evitar erros e contar com a ajuda dos mais experientes, seja na empresa ou fora dela, para precaver e mesmo solucionar possíveis situações de risco;
• Ser amigável e descontraído nos momentos certos e oportunos, evitando gafes em situações mais sérias;
• Cumprir metas, prazos e horários, evitando atrasos em qualquer situação;
• Ter responsabilidade de cumprir com os compromissos firmados, nunca firmar com alguém o que não se tem certeza.

O profissional não precisa ser um ser politicamente correto e seguir a risca todas as regras de conduta e leis vigentes no estado, o ideal é que tenha bom senso e saiba se portar em cada situação, evitando conseqüências desagradáveis e que possam denegrir a imagem do profissional no mercado como arrogante, sem compromisso, irresponsável ou qual outra dessas "qualidades".

Fonte: Artigo retirado do site Imasters
André Rodrigues (e-mail) trabalha com programação para web desde 1999. É graduando em Sistemas de Informação pela UNIPAC - Universidade Presidente Antônio Carlos de Ipatinga MG, trabalha como analista desenvolvedor de sites e sistemas web com o Grupo Host-Up.com.

XML em 10 pontos

XML, XLink, Namespace, DTD, Schema, CSS, XHTML... Se XML é novidade para você, pode ser difícil saber por onde começar. Este resumo em 10 pontos tenta cobrir o suficiente dos conceitos básicos de forma que um iniciante possa vislumbrar a floresta em meio às árvores. E se você está dando uma palestra sobre XML, por que não começar com estes 10 pontos?

1. XML é para estruturar dados
São exemplos de dados estruturados planilhas, cadernos de endereços, parâmetros de configuração, transações financeiras e desenhos técnicos. XML é um conjunto de regras (você também pode encará-las como convenções ou diretrizes) para projetar formatos de texto que o permitam estruturar seus dados. XML não é uma linguagem de programação e você não precisa ser um programador para usá-la ou aprendê-la. XML torna simples para o computador gerar e ler dados, e garantir que sua estrutura não seja ambígua. XML evita os problemas mais comuns em projetos de linguagens; ela é extensível, independente de plataforma e suporta internacionalização e localização. XML é 100% conforme ao padrão Unicode.

2. XML parece um pouco com HTML
Como HTML, XML usa marcadores (palavras envoltas pelos sinais '<' e '>') e atributos (na forma nome="valor"). Mas enquanto HTML especifica o que cada marcador e atributo significa, e às vezes como seu conteúdo aparecerá num navegador, XML usa os marcadores apenas para delimitar os trechos de dados, deixando sua interpretação completamente à cargo da aplicação que os lê. Em outras palavras, ao ver "

" num arquivo XML, não assuma que é um parágrafo. Dependendo do contexto, pode ser um preço, um parâmetro, uma pessoa, um p... — ora, quem disse que a palavra tem que começar por pê?

3. XML é texto, mas não é para se ler
Programas que produzem planilhas, listas de endereços e outros dados estruturados freqüentemente os gravam em disco, usando um formato binário ou textual. Uma vantagem do formato textual é que ele permite às pessoas, se necessário, ver os dados sem usar o programa que os produziu; ou seja, você pode ler um formato textual com o seu editor de textos favorito. Formatos textuais também ajudam os desenvolvedores a depurar mais facilmente as aplicações. Como em HTML, os arquivos XML são arquivos-texto que as pessoas não deveriam precisar ler, mas podem fazê-lo em caso de necessidade. A semelhança diminui quando vemos que as regras para arquivos XML são rígidas. Um marcador esquecido ou um atributo sem aspas inutilizam um arquivo XML, enquanto em HTML tal prática é tolerada e com freqüência explicitamente permitida. A especificação oficial da XML proíbe as aplicações de tentar inferir a intenção do autor de um arquivo defeituoso; se um defeito é encontrado, a aplicação é obrigada a parar ali mesmo e sinalizar um erro.

4. XML é prolixo de propósito
Como XML é um formato textual e usa marcadores para delimitar os dados, os arquivos XML são quase sempre maiores que num formato binário equivalente. Isso é fruto de uma decisão consciente dos projetistas da XML. As vantagens de um formato textual são evidentes (vide item 3), e as desvantagens podem ser geralmente compensadas num outro nível. Espaço em disco já não é tão caro como costumava ser, e programas de compressão como zip e gzip podem comprimir arquivos rápida e eficientemente. Além disso, protocolos de comunicação modernos e o HTTP/1.1, o protocolo central da Web, podem comprimir os dados em trânsito, poupando banda tão eficientemente quanto um formato binário.

5. XML é uma família de tecnologias
XML 1.0 é a especificação que define o que são "marcadores" e "atributos". Além de XML 1.0, a "família XML" é um conjunto crescente de módulos que oferecem serviços úteis para levar a cabo tarefas importantes e muito requisitadas. Xlink descreve uma forma padronizada de inserir hiperlinques num arquivo XML. XPointer e XFragments são sintaxes em desenvolvimento para endereçar partes de um documento XML. Um XPointer parece com um URL, mas ao invés de apontar para documentos na Web, ele aponta para trechos de dados dentro de um arquivo XML. CSS , a linguagem de folhas de estilo, aplica-se tanto a XML como a HTML. XSL é uma linguagem avançada para expressar folhas de estilo. Ela é baseada em XSLT, uma linguagem de transformação usada para rearranjar, adicionar ou apagar marcadores e atributos. O DOM é um conjunto padrão de funções para manipular arquivos XML (e HTML) com uma linguagem de programação. As recomendações Esquema XML 1 e 2 ajudam os desenvolvedores a definir precisamente as estruturas de seus próprios formatos baseados em XML. Há vários outros módulos e ferramentas disponíveis ou em desenvolvimento. Mantenha-se informado na página de relatórios técnicos do W3C.

6. XML é novidade, mas nem tanto assim
O desenvolvimento de XML começou em 1996 e é uma Recomendação W3CSGML, desenvolvida no início da década de 80 e padrão ISO desde 1986, largamente utilizada em grandes projetos de documentação. O desenvolvimento de HTML começou em 1990. Os projetistas da XML simplesmente pegaram as melhores partes da SGML, guiados pela experiência acumulada com HTML, e produziram algo que não é em nada menos poderoso que SGML, e amplamente mais regular e simples de usar. Contudo, às vezes é difícil distinguir algumas evoluções de revoluções... E deve ser dito que, enquanto SGML é usada principalmente para documentação técnica e muito menos para outros tipos de dados, com XML ocorre exatamente o oposto. desde fevereiro de 1998, o que pode levá-lo a crer que XML é uma tecnologia imatura. Na verdade, esta tecnologia não é muito recente. Antes de XML já existia

7. XML leva a HTML à XHTML
Há uma importante aplicação XML que é um formato de documento: é a XHTML, a sucessora da HTML. XHTML tem muitos dos mesmos elementos que HTML, mas a sintaxe foi ligeiramente modificada para se conformar às regras da XML. Uma aplicação que é "baseada em XML" herda a sintaxe de XML e a restringe de certas formas (e.g., XHTML aceita "

", mas não ""); ela também acrescenta significado à sintaxe (XHTML reza que "

" significa "parágrafo", e não "preço", "pessoa" ou qualquer outra coisa).

8. XML é modular
XML permite que você defina um novo formato de documento combinando ou reutilizando outros formatos. Como dois formatos desenvolvidos independentemente podem ter elementos ou atributos homônimos, deve-se ter cuidado ao combinar tais formatos ("

" significa "parágrafo" deste formato ou "pessoa" daquele outro?). Para eliminar a confusão de nomes ao combinar formatos, XML provê um mecanismo de espaços nominais (namespaces). XSL e RDF são bons exemplos de formatos que usam espaços nominais. O Esquema XML foi projetado para reproduzir este suporte à modularidade no nível da definição da estrutura dos documentos XML, tornando fácil combinar dois esquemas para produzir um terceiro que represente uma estrutura de documento híbrida.

9. XML é a base de RDF e da Web Semântica
A Framework para Descrição de Recursos (RDF) é um formato textual XML para descrever recursos e aplicações de metadados, como listas de reprodução de músicas, álbuns de fotos e bibliografias. Por exemplo, RDF permite que você identifique pessoas num álbum de fotos na Web usando informação de uma lista de contatos pessoais; assim, o seu programa de correio poderia automaticamente disparar uma mensagem para essas pessoas dizendo que suas fotos estão disponíveis na Web. Assim como HTML integrou documentos, sistemas de menu e formulários para deslanchar a Web original, RDF integra aplicações e agentes numa Rede (Web) Semântica. Assim como as pessoas precisam concordar acerca do significado das palavras que utilizam para se comunicar, os computadores também necessitam pactuar o significado dos termos para poderem se comunicarem efetivamente. A descrição formal dos termos de uma certa área (comércio ou manufatura, por exemplo) são denominadas ontologias e são uma parte vital da Web Semântica. RDF, ontologias e a representação formal do significado, de modo que os computadores possam ajudar as pessoas em seus trabalhos, são todos tópicos em discussão no grupo Semantic Web Activity.

10. XML é livre de licenças, independente de plataforma e bem suportada
Ao asear um projeto em XML, você herda um vasto e crescente conjunto de ferramentas (uma das quais pode fazer exatamente o que você precisa!) e uma comunidade de engenheiros com experiência na tecnologia. Optar por XML é semelhante a escolher SQL para bancos de dados: você ainda tem que montar sua própria base de dados e os programas e rotinas para manipulá-la, mas há muitas ferramentas disponíveis e muita gente que pode ajudá-lo. E como XML é livre de licenças, você pode criar seu próprio software com ela sem ter que pagar nada a ninguém por isso. O vasto e crescente suporte significa que você não está preso a um simples fornecedor. XML não é sempre a melhor solução, mas vale sempre a pena considerá-la.

W3C Communications Team, w3t-comm@w3.org
Traduzido em 19 Mar 2003 por Marcelo Jaccoud Amaral. (Versão anterior)

Os 7 passos do gerenciamento de projetos

O enxugamento dos quadros de pessoal e o aumento da necessidade de especialização técnica têm levado muitas empresas a recrutar no mercado profissionais por período determinado apenas para a execução de projetos específicos. Neste contexto, entender o processo de gerenciamento de projeto tem se tornado vital para organizações a medida em que mais e mais novos negócios vão se revestindo da aura de projeto e passam a exigir um cabedal de técnicas gerenciais que nem sempre estão disponíveis nas empresas.
Um projeto é um empreendimento temporário, com data de início e fim, cujo objetivo é criar ou aperfeiçoar um produto ou serviço. Gerenciar um projeto é atuar de forma a atingir os objetivos propostos dentro de parâmetros de qualidade determinados, obedecendo a um planejamento prévio de prazos (cronograma) e custos (orçamento). Ou seja, dadas as metas e as restrições de recursos e tempo, cabe ao gerente de projetos garantir que ele atinja os objetivos propostos.
Muitas empresas estão adotando a estrutura de projetos no seu dia-a-dia. Desde a concepção de um novo software até a implantação dos procedimentos de atendimento a clientes, desde a construção de uma ponte até a revisão dos processos de venda com vistas a aumentar a taxa de fechamento de negócios, muitos empreendimentos no seio das organizações se enquadram na classe de projetos. Nos mais diversos setores, a abordagem de gerenciamento de projetos está ganhando terreno por permitir um melhor uso dos recursos para se atingir objetivos bem definidos pela organização. Sabendo da importância de se gerenciar bem um projeto, vamos ver os passos que nos levam a melhorar nossas habilidades de gerenciamento de projeto.
Tudo começa com a contratação de uma empresa para tocar o projeto ou a definição dos colaboradores internos que integrarão a equipe de projeto. Num dia determinado, inicia-se o projeto. Este momento deve ser formalizado com um documento que se chama de “termo de início do projeto”. Em projetos maiores, deve ser um documento assinado pelos patrocinadores e pelo gerente do projeto. Para projetos menores, pode ser um e-mail que o gerente envia aos patrocinadores, copiando os demais envolvidos, para notificar que naquele momento se inicia o projeto e todos estão envolvidos com a sua execução.
1. Escolha e adote uma metodologia
Uma metodologia é um processo a seguir que dá maior controle sobre os recursos que serão utilizados no projeto. Controlando melhor o processo a equipe será mais eficiente pois entregará o projeto com maior grau de acerto em termos de prazos e custos. O bom uso de uma metodologia é importante porque permite evitar práticas que levam ao insucesso e com isso reproduzir o sucesso.
A Microsoft usa o MSF (Microsoft Solutions Framework) no desenvolvimento de seus produtos. Muitas empresas na área de software optam pelo CMM (Capability Maturity Model). A opção pela metodologia deve ser tomada a partir de alguns fatores: as exigências de cada mercado em que a empresa atua, a disponibilidade de mão-de-obra e a cultura organizacional necessária para adotá-la. Para exportar software, muitas empresas nacionais têm se alinhado com o padrão CMM para dar credibilidade a sua iniciativa em mercados dominados por indianos e chineses, que já possuem capacitação neste padrão.
Em última instância, uma metodologia é um conjunto de regras de como conduzir um projeto com sucesso. Pode até não ter siglas bonitas, mas é importante que já tenha se mostrado eficiente dentro da sua empresa, de preferência em situação similar à que você está vivendo no seu projeto atual. Para quem gosta de siglas, há uma que está bem na moda: a UML (Unified Modeling Language) que, como já diz o nome, não é uma metodologia mas uma linguagem, uma forma de se documentar um projeto. Uma linguagem de modelagem é uma notação, em geral feita com símbolos gráficos, que se usa para traduzir processos abstratos. A empresa que criou a UML desenvolveu uma metodologia conhecida como RUP, “Rational Unified Process”.
2. Comunique-se: não é só o peixe que morre pela boca!
Quando falta comunicação, os boatos e outras formas de ruídos tomam seu lugar. Na falta de versão oficial, ficam circulando informações que podem minar a moral da equipe e levantar suspeitas sem fundamento. O gerente de projeto deve evitar esse tipo de prática, conhecida por "rádio-peão", dando informações claras e confiáveis sobre o status do projeto. Certamente esta é uma área em que a diplomacia é essencial. Se há um problema, o gerente de projetos pode e deve não só falar sobre ele, mas também informar que está trabalhando na solução, e não apenas comunicar que o problema existe. Problemas sem uma perspectiva de solução são angustiantes e causam um desconforto na equipe que muitas vezes é desnecessário.
A criação de relatórios de progresso do projeto ajuda no processo de comunicação, sobretudo por que torna o processo impessoal e mais objetivo. Imagine o efeito de um email onde se critica um membro da equipe pelo atraso do projeto. Imagine a mesma informação vinda de um relatório em que a data de término real de uma tarefa está em branco: objetivamente a situação é a mesma, o indivíduo não fez a sua parte, mas no caso do email a pessoa envolvida pode se melindrar. No relatório, temos um dado objetivo, que salta aos olhos, mas que não gera ressentimentos.
3. Defina o escopo do projeto e detalhe as atividades
O “escopo do projeto” é o trabalho que deve ser realizado para se obter um produto ou serviço com determinadas características e recursos. Comece por definir o que deve ser feito e o que não deve. Esse processo nos permite entender os contornos do projeto e traçar uma linha divisória entre o que deve ser feito e o que não deve ser, pelo menos neste momento. Muitos novatos se perdem em discussões intermináveis sobre recursos do produto final que o tornariam “perfeito”. Sempre me lembro de um amigo muito experiente que, ante a minha ânsia em acertar todos os detalhes logo de cara, me dizia que “o ótimo é inimigo do bom”, ou seja: enquanto perseguimos o “ótimo” nos distanciamos de algo que está bem mais próximo, o “bom”, é que temos mais chance de conseguir atingir. Com o tempo achei uma forma elegante de contornar as exigências de projeto sem decepcionar os clientes: não é que não faremos o que está sendo pedido, mas devemos ver que este recurso cabe na versão 2, 3, etc... mas não cabe na versão 1, que é o que estamos tentando desenvolver neste momento ! Afaste o fantasma da perfeição.
Para você não se perder numa lista interminável de características da versão 1, uma boa idéia é pedir ao cliente que liste só que o que é “absolutamente essencial”. Claro que se você der a ele 30 minutos para responder, tudo será “absolutamente essencial”. Não adianta, temos de ser realistas, o tempo é curto é temos de escolher só o que realmente é importante. Se “escrever é cortar” como dizem os grandes escritores, a arte de se definir o escopo do projeto passa por saber o que abandonar e o que reter do universo de necessidades do cliente.
Bom, definido o escopo do projeto, podemos passar para a fase de detalhamento das tarefas. O objetivo é chegar ao WBS (Work Breakdown Structure), onde temos as “unidades de trabalho” com tempo medido em dias ou horas de trabalho. Como regra, uma atividade deve ocupar entre 4 e 80 horas, nem mais, nem menos.
Em paralelo, deve ser elaborado um orçamento levando em conta quantas horas de cada profissional serão necessárias. Veja um modelo simples:
Profissional Tarefa 1 Tarefa 2 Tarefa 3 T.Total (h) Custo/h Custo
Gerente de projeto 20 0 3 23 150,00 3.450,00
Líder de projeto 10 3 2 15 80,00 1.200,00
Analista Sênior 20 0 0 20 50,00 1.000,00
Programador 0 40 20 60 30,00 1.800,00
Testador/Documentador 0 20 30 50 15,00 750,00
Total - - - 168 - 8.200,00
Para montar este modelo, você precisa saber o custo-hora de cada profissional e estimar o tempo que cada um gastará no projeto. Os profissionais podem estar envolvidos em outros projetos e quando o programador está cuidando de uma fase do projeto A, o gerente de projeto já pode estar planejando o projeto B, só voltando ao projeto A quando for para entregar ao cliente e obter a sua aprovação, sobre o que falaremos mais adiante.
Estas estimativas são mais precisas à medida em que se avança no detalhamento do projeto. Para estimativas iniciais, admite-se uma variação de -25% a +75%. Na fase de planejamento, o orçamento deve ter uma variação de -10% a +25%. Lembre-se que nesta fase, o gerente de projeto já envolveu quem realizará a tarefa. Na estimativa final, a margem de erro é menor: de -5% a +10%. Aqui, o conhecimento do gerente de projeto de situações anteriores fará diferença. Eu, por exemplo, sei que quando lido com determinados clientes, haverá tanto “overhead” administrativo, como dezenas de reports para cima e para baixo antes que cada passo importante seja dado, que eu já estimo 50% a mais do tempo nas tarefas em que o cliente está diretamente envolvido. Vai da experiência do gerente, mas nessa hora, se a empresa têm um histórico de projetos semelhantes, vale a pena se basear neste background, mesmo que tenha sido com outras equipes e outros gerentes de projeto.
Um dos grandes segredos do gerenciamento de projetos é proteger o seu escopo. Projetos que ficam mudando o escopo durante sua execução têm sérias dificuldades em cumprir o cronograma e estouram o orçamento. O risco mais comum é o que se chama de “scope creep”, quando o escopo vai crescendo a medida que o cliente vai entendendo suas necessidades e reformulando seus objetivos. Há quem chame este problema de “Jacques”. Seria uma homenagem a um francês ilustre ? Não, trata-se apenas da forma como o cliente costuma abordar o assunto: “já que o sistema faz isso, ele pode então fazer aquilo. Agora eu quero aquilo também incorporado ao projeto.” O gerente do projeto deve ter calma e analisar com cuidado cada demanda: ao rejeitar um pedido, ele pode se indispor com o cliente, mas se aceitar ele pode estar dando um tiro no próprio pé, já que o prazo e orçamento não serão tão “elásticos” quanto as exigências. Devemos sempre contar com uma certa “margem de manobra”, mas nos tempos atuais, em que eficiência é a palavra que está na ordem do dia, não há muita “gordura para queimar” e os compromissos assumidos pelo gerente podem se transformar num sacrifício, muitas vezes desnecessário, para toda a equipe.
Em projetos de software, o “scope creep” é uma situação tão comum que não dá para começá-los sem tomar algumas precauções. O primeiro cuidado é negociar a forma de remuneração: fixa ou variável. Se for fixa, o risco das mudanças está toda com o gerente do projeto, se for variável, o cliente assume os custos extras. Mesmo neste caso, o gerente do projeto deve cuidar para que o cliente seja informado a priori dos novos custos. Por precaução, eu sempre redijo um adendo ao escopo colocando o que será feito, em quanto tempo e a que custo. Colho a assinatura do cliente e só depois autorizo a execução da tarefa. Gerentes financeiros não participam destas reuniões e podem alegar que não há previsão de recursos para os extras, então mantenha-os informados das novas condições para evitar dissabores na hora do recebimento.
O segundo cuidado é documentar meticulosamente o escopo do projeto. Este documento resume o que será feito, com que características e com que recursos. Ele é um “quase-contrato” mas não traz as cláusulas de rescisão e as penalidades. Neste momento, tudo está bem e todos concordam. Só que, na cabeça de cada um, há uma imagem diferente do que será o produto final. Á medida que este produto vai tomando forma e sendo entregue, o cliente vai vendo que o que ele imaginou “não é bem aquilo” e podem começar as decepções.
A satisfação do cliente depende em muito do que será dito e prometido no que se chama de “pré-venda”. É neste momento que o gerente de projetos deve entrar em cena para meticulosa, cuidadosa e disciplinadamente escrever tudo o que o sistema deve ter e fazer. Este processo é o “planejamento de escopo” e num software dele abrange das telas até os relatórios. Esta tarefa pode ser delegada para um analista, mas a responsabilidade não sai nunca das mãos do gerente. Eu costumo especificar toda a interface dos usuários com o sistema: telas e relatórios. Depois de “colocar tudo no papel”, o gerente deve obter do cliente um “de acordo”, de preferência assinado no final do documento em que todas as páginas serão rubricadas com um “visto” para que ele tome ciência do que será feito. Não há palavras para expressar a importância deste planejamento em que as expectativas serão levantadas e moldadas, de forma que, diante do produto final, o cliente não possa se dizer decepcionado.
O terceiro cuidado é definir prioridades. O gerente deve ter a sensibilidade para identificar quais são os requisitos obrigatórios e quais os desejáveis, marcando cada um segundo com a sua prioridade. Isso evita que alguém arbitre o que é importante no lugar do cliente. Há gerentes de projeto que vão mais longe e pedem ao cliente para definir o que ele considera “sucesso” do projeto. Por exemplo, num sistema em que havia desperdício de 30% da matéria-prima, foi considerado sucesso reduzir esta taxa para 15%. Mas este número ainda é alto, diria você. Sim, mas o cliente considerou que uma redução de 50% dos desperdícios já representaria benefícios suficientes que compensariam os investimentos no projeto. Além do mais, lembre-se de que: “o ótimo é inimigo do bom”.
Em suma: definir o escopo, no fundo, é saber o que deve ser feito para atender a necessidade do cliente.
4. Conheça os envolvidos e monte seu time
Todos os envolvidos no projeto são os "stakeholders". Nesse grupo estão não apenas os membros da equipe, mas também os clientes e fornecedores envolvidos. Dentro da empresa do cliente, há uma pessoa que se destaca por ser a patrocinadora ("sponsor") do projeto. Ela é que cria as condições para a contratação do projeto, mesmo que não seja ela que vá usar o produto final.
É importante que o gerente do projeto conheça os interesses de todos os envolvidos. Imagine como é arriscado contar com um membro da equipe que não está disposto a colaborar. Ele pode ser um problema mais do que uma solução dentro do grupo: sabendo disso, melhor pensar em chamar outra pessoa. Eu passei por uma situação destas quando fui destacado para gerenciar um projeto onde havia um colaborador mais antigo e que entendia que ele é quem deveria estar gerenciando. Eu não percebi seu ressentimento a princípio e à medida que o projeto avançava esta pessoa se tornava um problema cada vez maior, na medida em que, não só ele não fazia a sua parte, como minava os demais membros da equipe contra minhas decisões. Um dia, eu o chamei e abri o jogo. Ele então me explicou o que estava sentindo e fizemos um acordo: ele se enquadraria para completar o projeto, que graças a ele já estava atrasado, e eu o apoiaria junto à direção para que recebesse seu próprio projeto para gerenciar. É claro que manter um “profissional” com este tipo de atitude não é bom negócio para a empresa no longo prazo, porque cedo ou tarde ele vai acabar atirando contra a própria equipe novamente, só para mostrar que as “coisas têm de ser feitas do jeito dele”.
No processo de definição do escopo, as habilidades necessárias vão ficando mais claras. Nesse momento, é importante formar uma equipe com competência diversificada e com experiência nas áreas de atuação do projeto. Em projetos em que há muito conhecimento técnico envolvido, surge a figura do "líder de projeto", um profissional com grande conhecimento técnico e com capacidade de liderança entre os técnicos. Em geral é um profissional sênior, com credibilidade junto aos demais técnicos e com muita bagagem. A experiência desse especialista pode economizar muito tempo e dinheiro no projeto. Dê-lhe voz ativa, cobre dele insights que você não tem e respeite a sua opinião. Só assim ele estará sempre do seu lado, mesmo quando você errar.
5. Desenvolva o cronograma junto com quem põe a mão na massa
Uma vez que temos as tarefas definidas a partir do escopo, temos de estimar a duração de cada uma. Procure fazer esta estimativa de tempo de execução com a ajuda de quem está escalado para executar o trabalho. Ao mesmo tempo em que essa pessoa é quem melhor sabe quanto tempo precisará, ela estará se comprometendo com um prazo para a sua execução. Por outro lado, quando se trabalha com consultores externos, o custo será função direta do tempo estimado para a execução do projeto. Ao fixar o cronograma, o profissional está dando por tabela um orçamento da sua parte.
Note que além de saber o que deve ser feito, as tarefas têm três propriedades importantes: duração, inter-dependência e responsável. A duração é importante mas se as tarefas podem ser realizadas em paralelo, como é ilustrado neste caso onde há duas figuras: o analista e o programador, a duração total do projeto encurta. Dessa possibilidade de trade-off entre tempo e recursos alocados, alguns gerentes acreditam que se o projeto está atrasado, então “basta colocar mais gente” que o problema se resolve. Isso raramente ajuda uma vez que com mais gente, os problemas de comunicação aumentam e o projeto que já está atrasado atrasa mais ainda. Trazer mais gente pode ser útil quando se precisa de especialistas em temas que os membros não dominem. A rigor, se o planejamento foi bem-feito, já se sabe que esta mão-de-obra será recrutada em algum momento do projeto. A atitude de simplesmente aumentar a equipe para acelerar a produção é que está errada e deve ser combatida. Só que alguns gerentes de projeto medem seu poder pelo tamanho da equipe que gerenciam. Você pode imaginar como isso acaba: contratamos mais pessoas, eu fico mais “poderoso” e temos todas as explicações para os atrasos, afinal o projeto era mesmo “muito grande”.
O gerente de projetos deve trazer sua experiência para corrigir as expectativas muito otimistas de algum colaborador mais afoito. Sim, há quem estime 50 horas e depois, com a maior tranqüilidade, cobre pelas 120 horas que foram necessárias para realizar a tarefa. Ele só errou em 140% ! Se o preço é fechado, o risco fica todo com o consultor, mas a sua boa-vontade e a qualidade do produto final podem sofrer em decorrência da pressa. Se a remuneração ficar vinculada ao tempo de prestação de serviço, o contratante precisa de um mecanismo de controle minimamente confiável. Eu não uso uma fórmula geral, prefiro trabalhar segundo as características do profissional mas de todos exijo um relatório de horas que contém o dia, data de hora e início, tempo de trabalho e a(s) tarefa(s) realizadas no dia.
Se no planejamento da semana há tarefas que não foram realizadas, na reunião de avaliação, eu pergunto porque a coisa não seguiu o ritmo programado e quanto isso impacta na data final de entrega. Procure estabelecer pontos de controle, "check-points", que são datas onde se medirá o andamento do projeto em face do cronograma que havia sido programado. Nestas datas, pode-se estar apenas executando-se uma verificação do progresso das atividades ("milestones") ou pode haver entrega de produtos ou sub-produtos (“deliverables”) tais como desenhos, especificações, protótipos, modelos, etc...
Quem já reformou ou construiu uma casa sabe que esta tão trivial experiência de gerenciamento de projeto pode acabar mal. Quantas histórias existem de gente que foi pagando o pedreiro sem atrelar os pagamentos a entregas de tarefas determinadas. Nestas histórias tristes, o dinheiro acaba antes da obra, e o pedreiro some, deixando o cliente sem dinheiro e sem a sua casa. Tudo porque ele não cuidou de atrelar entregas de tarefas a pagamentos, não criou pontos de controle que lhe dariam visibilidade do atraso. Sabendo antes que a “vaca está indo para o brejo” o cliente pode optar por “apertar” o pedreiro ou suspender os trabalhos enquanto ainda tem dinheiro, que poderá ser usado para pagar uma equipe mais eficiente.
É verdade que em projetos de TI nem sempre dá para “trocar o pedreiro” porque há muito conhecimento e estudo envolvidos. Mas por isso mesmo, temos de ser muito mais cuidadosos na monitoração para saber em que momento o projeto começa a atrasar e como fazer para recuperar o ritmo no futuro próximo.
6. Monitore os riscos e seja pró-ativo
Agora que todos sabem o que devem fazer, é importante mitigar os riscos que podem impedir o bom desenvolvimento do projeto. Desenvolva uma lista de fatores de risco e um plano para lidar com eles. Mas lembre-se de que são duas coisas diferentes: a monitoração do risco e controle do risco.
A monitoração dos riscos envolve acompanhar o status de cada risco e as opções de ações definidas para enfrentá-los, caso eles venham a se tornar problemas reais. A monitoração também se preocupa em avaliar a probabilidade de ocorrência de um risco, qual o seu impacto no andamento do projeto e como contorná-lo. Por exemplo, numa determinada tarefa crítica a contratação de dois profissionais pode parecer um exagero mas o gerente do projeto sabe que se algo acontecer nesta área do projeto o impacto será grande no restante. Os profissionais passam a ser um backup do outro dentro da linha de que “quem tem um, não tem nenhum”.
Voltando ao nosso projeto de exemplo, chamo a atenção para um recurso que o MS Project tem e que deve ser usado para se identificar riscos. Veja a tela do diagrama de Gantt que obtivemos a partir da lista de tarefas que elaboramos acima:

Note que há uma seqüência de tarefas que quando alinhadas compõem o prazo de duração do projeto todo. Destaquei o início e o final só para que você perceba que se trata de uma série de processos que devem ser gerenciados mais de perto uma vez que o atraso em algum deles acarretará o atraso do projeto todo. Por isso é que se chama este de “caminho crítico”. Os riscos que estão embutidos nestas tarefas são os que se deve gerenciar mais de perto, de forma mais pró-ativa.
O controle dos riscos é o processo de executar o plano de ações e divulgar seus relatórios de status. Inclui também possíveis mudanças no plano de riscos, e eventualmente até nos planos do projeto. Essas mudanças são referentes a recursos, funcionalidades ou cronograma.
7. Formalize o início e o encerramento do projeto
O início do projeto é um momento solene. O patrocinador deve formalizar a todos os envolvidos que o projeto está iniciado e o cronômetro está correndo. Muita gente não gosta de se preocupar com isso, mas imagine que haja resistência de setores da empresa que se opõem ao projeto. Sem um documento que atesta que o projeto começou, o gerente pode não conseguir apoio algum. Além disso, este documento funciona como um “cumpra-se” de uma autoridade da empresa: não cabe discutir a ordem, o projeto começou e todos os “arrolados” devem participar.
Outro momento importante é o do encerramento do projeto. É preciso formalizar o final para que fique claro para todos os envolvidos, especialmente para o cliente, que o projeto está concluído e que novas necessidades serão atendidas em um novo projeto. Qualquer extensão ou alteração deverá ser orçada e todo o ciclo se inicia novamente. Com relação à manutenção do sistema entregue, não se pode considerá-lo um projeto na medida em que, a princípio, trata-se de um processo contínuo. O que pode ocorrer é definir-se projetos ao longo da vida útil do sistema com o objetivo de melhorá-lo. Por exemplo, a atualização dos equipamentos eletrônicos (“aviônicos”) de um avião para auxílio ao vôo é um projeto que se distingue da sua manutenção rotineira.
Ao final faz-se também uma reunião de avaliação dos erros e acertos da equipe. Chamadas de reuniões "post-mortem", elas servem para se gerar uma lista de "melhores práticas" contribuindo para a formação de uma base de conhecimento que poderá ser muito útil em projetos futuros. Da minha experiência pessoal, posso dizer que tirei grandes lições quanto às "piores práticas", atitudes e decisões que se mostraram ruins e que devem ser evitadas em projetos futuros.
Conclusão
Acima de tudo, gerenciar projetos é planejar e acompanhar a execução com "um olho no peixe e outro gato". O gerente do projeto deve se manter alerta e flexível com os acontecimentos do dia-a-dia mas deve estar sempre se reportando ao plano inicial para não perder o controle. A principal qualidade do gerente de projeto é saber se comunicar bem com todos. Ele é o ponto focal das informações, nele convergem as informações que ele depois deverá processar e divulgar para todo o restante da equipe.
O segredo é envolver a equipe, cliente e fornecedores de tal forma que todos se sintam diretamente responsáveis pelo sucesso do projeto. Como diz aquele velho ditado caipira, "quando todos empurram na mesma direção, ná há carroça que não saia do atoleiro".

Fonte: Fernando C. Barbi Gerente de Projetos especializado em TI com 18 anos de experiência na área e colaborador da ADVANCE Marketing – empresa de treinamento consultoria em gestão, marketing e vendas (www.advancemarketing.com.br)

Dez testes rápidos para checar a acessibilidade ao seu web site

Dez testes rápidos para checar a acessibilidade ao seu web site

A DDA (Disability Discrimination Act) preconiza que os web sites devem ser acessíveis para pessoas portadoras de necessidades especiais. Como checar seu web site para acessibilidade?
Existem alguns testes básicos que você poderá fazer com a finalidade de verificar os itens relevantes da acessibilidade no seu web site. A listagem a seguir mostra procedimentos que se constituem em um bom começo para incrementar a acessibilidade do site para pessoas portadoras de necessidades especiais:

1. Check os textos alternativos para imagens que transmitam informação
Coloque o cursor sobre a imagem, por exemplo, o logotipo da empresa. Aparece na tela uma caixinha amarela [ou de uma outra cor, dependendo do set-up do computador] com um texto descritivo da imagem? Para usuários navegando com browsers sem suporte para imagens, será aquele texto descrito, visto (e/ou ouvido) no lugar da imagem.

2. Check os textos alternativos para imagens decorativas
Coloque o cursor sobre a imagem que não tem outra função senão decorativa. Aparece na tela uma caixinha com um texto descritivo da imagem? Não deverá aparecer. Não há qualquer razão para que usuários com browsers sem suporte para imagens tomem conhecimento de uma imagem decorativa.

Atenção ao realizar este teste. Se a caixinha não aparecer, isto pode ser interpretado e analisado de duas maneiras:

1. O texto alternativo para a imagem foi definido como inexistente - alt="" - significando que será ignorado pelo browser sem suporte para imagem. Esta situação é a ideal.

2. O texto alternativo para a imagem não foi definido, significando que usuários com browser sem suporte para imagem tomarão conhecimento da existência de uma imagem, mas não saberão qual o propósito dela - o que será uma situação frustrante para o usuário! Esta certamente é uma situação a ser evitada.

3. 'Ouça' conteúdos de vídeo e áudio, sem volume
Se você desligar suas caixas de som, estará garantindo o corte total do volume para qualquer conteúdo de áudio e em consequência impossibilitado de ouvir qualquer som. Esta situação simula um usuário portador de surdez. Assegure-se de que seu web site disponibiliza um conteúdo escrito para o conteúdo de áudio, de modo que usuários portadores de surdez tenham acesso ao conteúdo áudio.

4. Check a acessibilidade de seus formulários
Usualmente cada campo de formulário possui seu texto descritivo. Por exemplo, um formulário de contato possui os textos 'nome', 'e-mail' e 'comentários' cada um deles próximo ao seu respectivo campo onde os usuários entrarão com os seus dados. Clique sobre o texto descritivo do campo e deverá aparecer o cursor 'piscando' no campo respectivo. Se o cursor não aparecer é porque não foi usado o elemento no formulário e isto poderá tornar o formulário inacessível para alguns usuários (mais detalhes sobre acessibilidade em formulários, consulte:
WaSP tutorial com mais informações sobre acessibilidade em formulários).

5. Check a possibilidade de aumentar o tamanho dos textos
No Internet Explorer (usado por 90% dos internautas) vá em View > Font size > Largest. O texto do seu web site aumentou de tamanho? Se não aumentou o seu site estará inacessível para usuários portadores de baixa visão.

6. Check seu web site no browser Lynx
O browser Lynx é um browser de texto e não oferece suporte para
muitas das facilidades oferecidas pelos outros browsers tal como o Internet Explorer. Você poderá checar como seu site se comporta em browsers de texto com o Simulador Lynx. Se o seu web site apresenta-se estruturado (se ele 'faz sentido') e você pode navegar por ele no Lynx então poderá estar certo de que muitos dos itens de acessibilidade estão em conformidade. O Lynx pode ser considerado como o 'menor denominador comum' dos browsers.

7. Check a navegabilidade sem uso de um mouseVocê pode navegar seu site usando somente tab, shift-tab e return?
Se isto não for possível, seu site será inacessível para usuários impossibilitados do uso de mouse bem como a usuários com leitores de tela. Deixe seu mouse de lado e navegue com o teclado para testar.

8. Check a existência de um mapa do site
Existe um mapa do site, facilmente localizável? Se não, os usuários poderão ficar perdidos no seu site.

9. Assegure-se que os textos dos links sejam descritivos para o destino remetido
Usuários portadores de deficiência visual total, navegam por sites na Internet valendo-se da 'tabulação' pelos links. Os textos descritivos dos links tem sentido? 'Clique aqui' e 'mais' são dois exemplos bem comuns de textos não descritivos para links. Se você estiver restrito a frases curtas para descrever seus links, considere o uso do atributo title no elemento a para suprir uma informação adicional sobre o destino do link, p.ex.: Descontos adicionais

10. Check sua página web em programas automatizados
Dois programas automatizados de checagem estão disponíveis na Internet Bobby e Wave. Estes programas, embora não não sejam capazes de todas as checagens possíveis para acessibilidade, já que alguns pontos só poderão ser checados por humanos lhe dará uma indicação em quais áreas os itens de acessibilidade precisam ser revistos.

Este artigo foi escrito por Trenton Moss. Eu e meu netinho.

Mauricio Samy Silva [maujorcss[arroba]maujor.com]

Copacabana - Rio de Janeiro, RJ - Brasil

Web Marketing

Web Marketing, é qualquer esforço promocional realizado por meio da Web. Mesmo que você possua o melhor e mais interessante site do mundo, você vai precisar fazer algum esforço para dizer aos internautas que você existe e está aguardando visitas. É ai que entra a promoção através do Web Marketing. . É claro que existem outros canais como a TV, Rádio, Revistas, Outdoors... Mas como nosso canal de atuação é a Web, e portanto é lá que o nosso público está, é natural que os meios mais eficazes de geração de tráfego sejam aqueles realizados por meio do web marketing.

Estratégia # 1 de Web Marketing: SITES DE BUSCA
Os Sites de busca são de longe a forma mais popular de localização de informações e produtos na Web. Justamente por isso ocupa um lugar de grande destaque entre as estratégias de web marketing. Pesquisa realizada pelo Forrester Institute entre 8.600 residências com acesso a Web, mostra que quase 60% dos internautas se utiliza dos Sites de busca. Em segundo lugar vem o e-mail com cerca de 38%. Sem dúvida, o ponto forte dessa estratégia é o fato que a maior parte dos sites de busca são gratuitos, embora haja uma tendência muito forte de cobrança por parte dos grandes sites que prestam esse serviço. O Gerenciamento dessa estratégia é bem trabalhoso no início, na fase de montagem e registro do site. Após esse período, o trabalho consiste de acompanhamento da classificação e eventuais atualizações.

Estratégia # 2 de Web Marketing: eMAIL MARKETING
As pesquisas de comportamento do usuário, indicam que receber e enviar e-mails é disparado a atividade mais realizada pelos internautas, seguida de longe pela leitura de notícias e diversão. Isso indica que não dá para imaginar um site bem sucedido que não tenha sistemas e canais de comunicação muito bem arejados com seus visitantes. Quando se fala em eMail Marketing, as pessoas pensam imediatamente em mala-direta eletrônica, não autorizada (spam). Prática que não deve ser seguida por empresas sérias. Na verdade, a grande força do eMail Marketing é sua agilidade como canal de comunicação com o cliente que autorizou a abertura desse canal (opt-in). A comunicação autorizada possibilita o conhecimento e o melhor atendimento das necessidades do cliente.

Estratégia # 3 de Web Marketing: PROGRAMA DE AFILIADOS
Um programa de afiliados, é a montagem de rede de sites que divulgam o negócio e enviam potenciais clientes para o site do comerciante em troca de comissões sobre as vendas. Para implantar e gerenciar um programa de afiliados o comerciante precisa adquirir uma solução (software) que faça o rastreamento dos afiliados e possibilite o controle das vendas pelo comerciante e também pelo afiliado. Programas de afiliados ainda são novidade no Brasil, com poucas empresas utilizando essa estratégia de web marketing. No entanto, é certo que, da mesma forma que ocorreu nos Estados Unidos, os programas de afiliados se tornarão uma das formas mais eficientes de geração de tráfego.

Estratégia # 4 de Web Marketing: ANÚNCIOS
Na economia tradicional, os anúncios são peça fundamental na disputa pelo cliente e as empresas reservam parte expressiva de seus orçamentos em anúncios na TV, Rádio e mídia impressa. A WEB é um novo canal com características peculiares e um público mais qualificado, o que demanda uma comunicação de mais alto nível. É o que muita gente chama de Soft-Marketing. A grande novidade são os links patrocinados - anúncios pagos em sites de busca -- que estão ganhando fatias expressivas dos recursos destinados à publicidade on-line. É importante, quando se trata de anunciar, não se perder de vista que o objetivo não é apenas a geração de tráfego mas o “Mind-share”, ou seja, a presença da marca na mente do consumidor. Se 100 pessoas clicaram em determinado anúncio, muito provavelmente milhares de pessoas a marca.

Conclusão:
Todas as estratégias de Web Marketing citadas aqui, com certeza vão gerar retorno para o seu site. O ideal seria utilizar todas e avaliar aquelas que melhor se enquadram nas características de sua empresa e, principalmente, nos objetivos estabelecidos. Para isso, é fundamental a observação de duas regras:

· Acompanhar e quantificar o resultado do investimento realizado, ou seja, quantas ações desejadas (AD) foram realizadas, ex: visitas, compras, downloads, etc..

· Comparar o retorno atingido com o investimento realizado. Isto poderia significar, por exemplo, responder a seguinte questão: quanto me custa a venda de meu produto “X” , se eu utilizar a estratégia “A” ? ou a “B” ou a “C” ?, e assim por diante.

Isso pode ser feito sem grandes dificuldades com a tecnologia disponível e representa uma das grandes vantagens do Web Marketing; a possibilidade de mensurar com precisão o desempenho e os resultados obtidos nos esforços promocionais.

Fonte: http://www.e-commerce.org.br/webmarketing.htm

Uma abordagem prática para projetos em crise

Aprendemos as maiores lições nos momentos de crise: quem nunca esteve num projeto prestes a naufragar? Por que isso acontece? Alguns procedimentos simples e um pouco de experiência podem nos livrar de grandes enrascadas.

Dizem que você aprende as maiores lições em momentos de crise. Comigo não foi diferente. Trabalhando em agências de internet, passei por várias crises e aí estão algumas valiosas lições que aprendi. Estas idéias se aplicam principalmente neste ambiente, onde tenho maior vivência.

Vamos supor o seguinte cenário básico: a agência precisa entregar um projeto grande num tempo relativamente curto e as coisas não estão indo muito bem com relação às entregas. É o cenário mais comum.

Segue um descritivo dos papéis:

Recurso (diretor de arte, programador, webdesigner e etc..). Trabalha até tarde da noite e nos finais de semana, fica irritado com qualquer coisa que pedem para ele fazer. Começa a se desmotivar e permanece sob pressão constante.

Responsável por gerir o projeto. Esconde a crise do diretor, começa e entrar em processo defensivo e a se dedicar a outras coisas, a dizer que não sabia de nada e culpar os outros. Tem na ponta da língua o nome do culpado, que pode ser o cliente, um recurso ou o atendimento (se ele não for o atendimento).

Diretor ou gerente de contas. É o último a saber e quando descobre, normalmente acaba tendo uma visão errada, pois é informado muitas vezes pela pessoa responsável pela crise, que tende a jogar a culpa em outro. Ele tenta atacar a causa do problema, mas nem sempre dá certo, pois não sabe muito bem qual é a causa.

As causas mais comuns

Podemos identificar cinco causas muito comuns no cenário descrito:

1. A venda do projeto foi feita sem avaliar os devidos riscos e a condição da empresa entregá-lo.

A empresa oferece e vende projetos e não está muito preocupada em como fazê-lo. Pode ser que tenha complicadores tecnológicos e a pessoa que vendeu não soube avaliar muito bem isso. A empresa pode ter vendido um projeto com escopo mal definido e o cliente se aproveitou disso e pediu muitas coisas a mais.

2. Uma pessoa da equipe é desorganizada, está desmotivada, aceita tudo o que o cliente quer ou simplesmente é incompetente e tem um papel importante no projeto.

Às vezes uma pessoa da equipe põe tudo a perder. Pode ser o atendimento, coordenador ou recurso. Ela pode se desorganizar, deixar o cliente se aproveitar, segurar informações importantes, gerar falsa expectativa no cliente, prometer datas impossíveis ou simplesmente não entregar as coisas na data combinada.

3. O cliente muda constantemente o escopo do projeto.

Quando o cliente resolver ficar mudando as coisas no decorrer do projeto, pode ser um problema sério se a equipe não estiver preparada para travar ou absorver bem isso.

4. A empresa não tem um planejamento muito claro do que fazer para entregar o projeto.

Este é o mais comum de todos. A empresa vende o projeto, não planeja e simplesmente sai fazendo. Não define escopo, não faz um cronograma realista, não define os riscos, não avalia os recursos, não prevê mudanças, testes e etc… Depois quando as coisas dão erradas fica muito difícil de consertar.

5. Excesso de trabalho da equipe (e prioridade a outros projetos).

É muito comum: um projeto passa na frente do outro e o que ficou para trás acaba entrando em crise. Isso reflete desorganização na agência.

Pule a parte da negação

A parte da negação é a primeira fase. Pessoas inexperientes têm dificuldade em enxergar a crise por achar que um milagre vai ocorrer na próxima semana e tudo ficará bem. São muito otimistas. É a fase em que todo mundo garante que vai resolver tudo porque se não o disser será taxado de incompetente.

Saiba reconhecer esta fase e tire as pessoas dela. Dica: quando falarem para você que um problema está sob controle ou que será resolvido em breve, diga: “Convença-me disso. Mostre-me como você vai fazer para resolver.” Se a pessoa não tiver uma idéia muito clara na cabeça, é sinal que está tentando enrolar e o problema vai continuar.

Ataque o sintoma e também a causa

Em caso de crise, ataque também a causa, não só o sintoma, pois a causa pode ser uma pessoa sem conhecimento, desmotivada, difícil de lidar ou desorganizada na equipe. Resolver só o problema prova a esta pessoa que ela pode continuar fazendo as coisas daquele jeito e que sempre fica tudo bem. Se não houver organização, organize. Se o cliente muda muito as coisas, trave as mudanças.

Tenha as pessoas mais experientes possíveis junto de você

Neste momento é o melhor conselho: reúna as melhores pessoas de suas áreas e as mais experientes para ter uma opinião consolidada e tomar a melhor decisão. Lembre-se: as pessoas envolvidas na crise tentem a estar reativas e a culpar uns aos outros. Na cabeça delas, o outro é sempre o culpado (é natureza humana). Siga o próximo conselho…

Tenha sempre uma segunda opinião

Na crise, as pessoas envolvidas podem estar contaminadas pelo estresse ou pela possibilidade de serem demitidas. Tenha uma segunda opinião de alguém de fora do processo ou até mesmo da agência.

Livre-se dos amadores

Os amadores são a última coisa que você pode querer na sua frente em momentos de crises. Chame os caras bons e experientes. Os amadores só vão servir para piorar ainda mais as coisas.

Comprometa as pessoas

Se a pessoa não está comprometida com a solução, mas só envolvida, ela vai te ajudar muito pouco. Comprometa todos. Normalmente dá pra ver claramente quem está comprometido e quem não está. Muito cuidado com as pessoas que trabalham muito, mas contribuem pouco para o resultado final. É posição defensiva, pois não querem ser acusadas de terem feito “corpo mole” no momento de crise e no final vão dizer: “Estou saindo tarde todos os dias, estou me estressando, me dedicando ao máximo…”. Em resumo: não basta somente ser esforçado; o esforço tem que ser útil ao projeto.

Trave as mudanças

Não tem coisa que piore ainda mais a sua situação do que as mudanças de escopo do projeto. Controle as mudanças, principalmente em momentos de crise.

Confira tudo, teste tudo e só acredite vendo

Neste momento é importante conferir tudo, testar e ter certeza de que tudo funcione. Só acredite vendo. Tenha um profissional responsável por isso.

É comum se achar que a situação é melhor do que realmente é. Todos querem realmente acreditar nisso e as pessoas gostam de acreditar naquilo que precisam. Não há coisa pior do que chegar ao final do projeto e descobrir que há mais coisas para fazer porque simplesmente fizeram mal feito. Esta foi uma das maiores lições que aprendi.

Se você pressionar, ele vai fazer mal feito

Se você pressionar uma pessoa a fazer uma atividade muito rapidamente e em momento de estresse, ela vai fazer mal feito, não tenha dúvida. E o pior é que você nem poderá culpá-la disso pois ela vai dizer: “Tive que fazer correndo, num deu tempo, trabalhei no fim de semana, num tenho culpa…”. Portanto, cobre sempre o razoável e obtenha o compromisso de entrega.

Se você pressionar, ele vai falar sim para tudo

Se você pressionar uma pessoa a te dar uma resposta sobre “se ela vai te entregar alguma coisa a tempo”, ela vai dar a resposta que você quer ouvir, não necessariamente a verdade. Esteja preparado para reconhecer as mentiras.

Cuidado com a Síndrome do Estudante

A Síndrome do Estudante é a mania de adiar tudo para a última hora. Ocorre naturalmente nos projetos, mas se reflete na crise quando algumas decisões demoram em ser tomadas ou quando a agência ganha um prazo maior para entregar um projeto e este prazo é perdido pelo “relaxamento” das pessoas, que acham que tudo dará certo depois disso.

Pode piorar muito mais

Sim, tudo pode piorar. O cliente pode mudar, o recurso pode estressar, você pode ter avaliado mal o problema, tudo é possível. Acredite, as coisas podem piorar muito ainda. Esteja preparado, tenha um plano B e lembre-se dos conselhos acima.

Afinal, quem é o culpado?

Eu acredito que o culpado seja a pessoa responsável pela gestão do projeto, até que se prove o contrário.

O gestor tem que ter a capacidade de organizar, orientar as pessoas, alocar corretamente os recursos, garantir o que o cronograma esteja sendo seguido, avaliar os riscos, cobrar as pessoas, segurar o cliente e principalmente “conseguir prever o futuro” (para isso deve ser experiente).

Lógico que muitas vezes o projeto entra em crise e nem sempre o gestor pode controlá-la ou evitá-la, existem fatores extra-campo que realmente são imprevisíveis, mas um pecado mortal é a negligência.

É a pessoa saber que as coisas não estão indo bem e não fazer nada para corrigir, saber que o projeto está naufragando e se preocupar mais em culpar os outros do que tomar uma atitude, é avisar só em cima da hora que as coisas não vão sair, é alocar as pessoas erradas para as tarefas, é mostrar desconhecimento de coisas importantes do projeto e principalmente: não ter humildade e reconhecer que também erra.

Acreditar que sempre está certo e que as coisas sempre estão sob controle. A arrogância do gestor pode arruinar definitivamente o projeto, pois atua como fator desagregador e desmotivador para as pessoas envolvidas no processo produtivo.

Concluindo, focando apenas na parte de construção do site, boa parte das crises de projetos pode ser evitada com processo, organização e bom senso. É preciso enfatizar a importância da sinergia na equipe para que tudo isso funcione bem.

Em projetos pequenos (uma ou duas semanas), a sinergia compensa qualquer tipo de organização ou processo formal. No entanto, com um projeto maior, é inevitável possuir um processo formal de desenvolvimento e uma boa dose de metodologia de gestão de projetos para que as coisas permaneçam sob controle. No meu artigo vamos ver uma proposta de processos de desenvolvimento em agências

Marcelo Okano é Gerente de Tecnologia da Interativa | CDN.

Documentação do DBA

Estes documentos são úteis não apenas para ajudar a documentar aspectos técnicos, mas também para organizar e gerenciar o trabalho do DBA (Database Administrator).

Ao contrário do que alguns podem pensar, a documentação não é apenas um trabalho desnecessário que toma tempo e torna tudo mais lento. Ela é um item necessário e obrigatório em qualquer projeto, servindo a vários propósitos.

Em geral, é difícil encontrar profissionais, em particular DBAs, que trabalhem com muita documentação. Isso se deve tanto à questão cultural como a questão que envolve a disponibilidade de tempo para criar e manter a documentação atualizada. De qualquer maneira, neste artigo apresento os 10 principais documentos utilizados por quem trabalha tanto como DBA como desenvolvedor.

1) MER (Modelo Entidade Relacionamento)

O MER (Modelo Entidade Relacionamento), também conhecido apenas como modelo de dados ou diagrama de entidade-relacionamento, é a principal documentação de um banco de dados. Neste diagrama são relacionadas as principais entidades (tabelas) e seus relacionamentos, além de alguns detalhes a respeito das entidades, como nome das colunas nas tabelas, tipos de dados e constraints. Geralmente utiliza-se uma ferramenta CASE para modelagem deste diagrama, sendo o ER-Win um dos softwares mais utilizados para elaborar este diagrama. Independente do software utilizado é imprescindível que o DBA conte com ao menos um MER para cada uma das bases que ele administra.

2) Padrões de Variáveis (Tabelas, colunas etc) e Documentação

Uma das boas práticas de desenvolvimento é contar com padrões. Saber colocar nomes significativos e explicativos em funções, variáveis, classes etc está se tornando cada vez mais um pré-requisito para quem trabalha com desenvolvimento. No que tange à banco de dados, a idéia não é diferente: possuir um padrão de nomes para tabelas, colunas, constraints e objetos de bancos de dados é muito importante. Aqui a idéia não é apenas possuir um padrão e utilizá-lo largamente, mas possuir um padrão eficaz que seja fácil de ser utilizado, além de fazer sentido no contexto de banco de dados. Para formalizar a adoção de um padrão, recomenda-se montar um documento explicando todos os detalhes deste padrão como, por exemplo, se o padrão é baseado na notação húngara, se os nomes devem ser em português ou se há um limite no tamanho da coluna.

3) Capacity Plan

A necessidade de prever recursos de hardware é uma das grandes responsabilidades de um DBA. Além de economizar recursos, a previsão mostra que há um controle não apenas para os recursos que estão sendo utilizados, mas também para os recursos que podem ser necessários no futuro. Para ajudar nesta previsão, o DBA deve ser responsável pela elaboração de um documento chamado Capacity Plan, ou Plano de Capacidade. Este documento deve listar as necessidades de espaço de armazenamento, utilização de CPU, largura de banda e outros requisitos técnicos que possam impactar o banco de dados. Com certeza, este é um documento que envolve muitos aspectos e deve ser elaborado com cuidado. Por questões práticas, muitas vezes é necessário fazer uso de estimativas e tendências ao invés de contar com informações precisas. Deste modo, o documento não precisa estar 100% correto, mas deve conter uma boa base e previsão dos principais recursos computacionais relacionados ao banco de dados.

4) Dicionário de dados

O Dicionário de dados é um documento que complementa o MER. Este documento deve conter mais detalhes a respeito das tabelas e seus relacionamentos. Por exemplo, além de listar todas as colunas de uma tabela, o documento deve fornecer também uma pequena descrição do significado desta coluna, quais são os valores possíveis, a quantidade típica de valores armazenados e quais constraints agem sobre esta coluna. Além das informações sobre colunas, este documento apresenta o nome dos objetos que dependem da tabela, como stored procedure, triggers, views, funções etc, e suas respectivas funções, além dos parâmetros necessários e o que é retornado. É importante notar que este documento deve sempre estar alinhado e atualizado com a base de dados atual, para evitar desencontros e desentendimentos.

5) Política de segurança

O documento contento a política de segurança é um documento não-técnico que envolve os procedimentos, responsabilidades e atribuições relacionadas tanto à segurança das informações como do acesso à elas. Geralmente este documento contém uma política de usuários e senhas, que especificam várias regras, como as definidas abaixo:

• Troca de senha a cada três meses;
• Desabilitar as contas padrão;
• Forçar senhas com letras, números e caracteres especiais que tenham um tamanho mínimo de 10 posições;

Outras políticas gerais de senha, como o cancelamento após um algumas tentativas e horários definidos para certos usuários, também deve constar neste documento, sempre tendo em mente a utilização de sistemas e bancos de dados.

6) N.D.A (non-disclosure agreement) - Compromisso de sigilo

Imaginem a seguinte situação:

Somos responsáveis por uma base de dados que deve ser integrada com um sistema externo à empresa. Para discutir os detalhes desta integração, uma reunião é marcada com a equipe externa à empresa que desenvolve o sistema. Durante esta reunião são apresentadas informações sigilosas da empresa que trabalhamos, com o objetivo de discutir os aspectos da integração.

Vamos supor que na situação apresentada acima os profissionais da equipe externa hajam da má fé e utilizem as informações fornecidas para seu próprio benefício, seja comercialmente ou não. Este tipo de situação pode gerar diversos problemas, podendo chegar ao ponto onde a equipe que agiu de má fé ser acusada de roubo.

Para e proteger de situações como estas, é comum fazer uso de um documento chamado NDA (non-disclousure agreement), também conhecido como compromisso de sigilo. Este é o tipo de documento que protege todo mundo: tanto quem assina como quem solicita a assinatura. Em termos práticos, que assina compromete-se a não revelar nenhum detalhe da informação que lhe vai ser comunicada sob pena de ser alvo de procedimento legal.

7) S.L.A. (Service Level Agreement) - Acordo de nível de service (ANS)

O SLA, também conhecido como Acordo de nível de serviço - ANS, é um acordo entre a área prestadora de serviços e seus clientes. Este acordo deve deixar claro quais serviços estão sendo oferecidos (serviços específicos) e o nível de cada serviço (horas de funcionamento, downtime, horário do suporte etc). Geralmente este acordo é colocado na forma de um contrato que deve ser assinado na contratação do serviço. Para banco de dados, em particular, pode-se utilizar um SLA interno, onde o DBA se compromete a dar algum tipo de retorno (feedback) ao solicitante. Notem que este retorno não quer dizer, necessariamente, a resolução do problema ou o conserto, mas sim que o DBA está ciente da solicitação.

8) Diagrama de arquitetura

Atualmente é comum encontrar nas empresas diversos ambientes de bancos de dados. Estes ambientes são separados de acordo com a sua finalidade, isto é, seu principal objetivo. Por exemplo, é comum encontrar ambientes de desenvolvimento, onde os programadores/analistas executam diversos testes durante o processo de desenvolvimento, e ambientes de programação, onde os usuários finais trabalham com os dados reais dos sistemas.

Para documentar e organizar o gerenciamento destes ambientes, o DBA deve elaborar um diagrama de arquitetura, que indica, de forma gráfica, quais servidores pertencem ao ambiente de desenvolvimento e ao ambiente de produção, como eles estão localizados em relação aos usuários com informações sobre link, rede, zonas desmilitarizadas (DMZ), firewalls, roteadores, etc. Este tipo de diagrama contém informações relacionadas à estrutura arquitetural dos ambientes e é extremamente útil para quem não conhece a organização física e lógica dos componentes da rede e dos servidores. É importante lembrar que este documento pode ser flexível, ou seja, pode incluir detalhes específicos, como endereços I.P. e senhas, ou apresentar uma visão de alto nível, onde apenas os principais servidores são apresentados.

9) Estratégia de Backup

Todo DBA profissional deve possuir uma estratégia de backup adequada. Esta estratégia deve ser montada de acordo com as necessidades de recuperação e disponibilidade do sistema, ou seja, toda a estratégia de backup vai depender do quanto de downtime e tempo de recuperação é aceitável.

É importante documentar a estratégia de backup utilizada, tanto para oficializar este tipo de tarefa como para conscientizar os usuários a respeito do que pode ser recuperado, quando, sob quais condições e a qualidade do que foi recuperado. Geralmente este documento contém todos os bancos de dados envolvidos na estratégia, como o backup será realizado, qual a periodicidade, qual é o procedimento para recuperação, quem são os responsáveis e os recursos envolvidos. Por fim, é importante atualizar este documento conforme as necessidades de disponibilidade e recuperação mudam de acordo com o volume de informações manipuladas pelos sistemas.

10) Procedimento para controle de chamados ou O.S. (ordem de serviço)

Este último item não é exatamente um documento, mas sim um procedimento que deve ser adotado para o controle de solicitações de serviço (ou chamados) ao DBA. Este tipo de controle evita problemas de comunicação entre quem solicitou e que realiza uma tarefa. Deixar este controle apenas a cargo do envio de e-mails é um primeiro passo, mas investir em um sistema para controlar o acesso às pessoas é algo fundamental, uma vez que este procedimento está diretamente relacionado com as regras definidas no SLA. Obviamente, este tipo de controle deve ser utilizado de forma sensata, pois existem diversos tipos de solicitações que podem exigir tratamentos diferentes, como apenas uma olhada no estado de um servidor. Mais uma vez, a idéia aqui é estabelecer um mecanismo de controle tanto para quem solicita a tarefa como para quem a executa.

Outros tipos de documentos são necessários para quem trabalha com desenvolvimento de sistemas. Atas de reunião, manuais de implementação de sistemas e help-online são apenas alguns exemplos disto. Em geral, o DBA é o profissional que menos tem que lidar com este tipo de documentação. Apesar disso, é importante que o profissional que trabalha com banco de dados, e também com desenvolvimento de sistemas, tenha consciência que esta documentação não necessariamente é burocracia, mas sim que ela é um artefato extremamente importante para todos os profissionais envolvidos

Mauro Pichiliani é mestre em computação, possui as certificações MCP, MCDBA, MCT e MCTS e atua como consultor de banco de dados com enfoque na área de tunning.