%\part[\ \ \ \ \ \ \ \ \ \ \ PARTE II -- DIRETRIZES E GESTÃO]{Diretrizes e Gestão}
% \part*{Parte II  \\ \ \\ DIRETRIZES DE GESTÃO}
\addcontentsline{toc}{part}{PARTE II -- DIRETRIZES DE GESTÃO}


\chapter{Visão Geral da Migração}

\section{A sensibilização é o melhor começo}
\label{sensibilizacao}

Como descrito no Capítulo \ref{pq_sl}, o \emph{software} pode ser livre ou proprietário. Esta escolha é uma decisão do desenvolvedor ou da instituição desenvolvedora e muitas vezes não se trata de escolha puramente técnica. Refere-se também a uma decisão econômica, comercial,  que no mínimo esteja contextualizada em uma política tecnológica (por exemplo, quando uma empresa define seu Plano Diretor de Tecnologia da Informação -- PDTI). A decisão sobre o desenvolvimento e o uso de \emph{Software} Livre sofre também influências de caráter cultural, e estas podem ser mais limitadoras do que o próprio emprego da tecnologia.

Mudar sistemas, alterar soluções e plataformas, em geral, são tarefas complexas. Ao considerarmos que toda mudança capaz de modificar o comportamento e as rotinas das pessoas aumenta o grau de dificuldade das tarefas, podemos  afirmar que, ao se falar em migração, a atenção dos Administradores não pode se concentrar exclusivamente na parte técnica. A migração exige também esforço de mudança cultural, o que nas organizações se retrata diretamente no que se concebe como Cultura Organizacional.

A experiência demonstra que toda alteração de plataforma, ou de paradigma, para ser bem sucedida, exige profundo trabalho de convencimento. Conforme descrito no Capítulo 4, é importante que se desenvolvam ações de convencimento dos corpos técnico, gerencial, funcional e, conseqüentemente, dos ``cidadãos usuários'', objetivando estabelecer ambiente favorável à realização da migração e ainda desenvolver mecanismos motivacionais. 


Em geral, toda migração que desconhece a importância de sensibilizar as pessoas envolvidas leva muito mais tempo ou simplesmente não é bem sucedida. Explicar os motivos da migração, afirmar suas vantagens, demonstrar sua importância é indispensável, principalmente para transformar os grupos diretamente atingidos  em principais aliados no processo, conforme discutiremos no Capítulo \ref{questoes_humanas}.

Antes de capacitar os usuários em soluções livres, é preciso reuni-los e explicar os motivos da migração. Os Administradores podem realizar reuniões gerais, por setor, por grupos de gerentes, que devem ser em número suficiente para convencer e angariar a simpatia do maior número de pessoas. A força da mensagem do \emph{Software} Livre é tão contundente que pode motivar as pessoas para uma migração exemplar e exitosa. Mas antes de tudo é preciso explicar bem o que está acontecendo. Esta é uma atividade essencial chamada Sensibilização.

A Sensibilização e as suas técnicas são tão relevantes que merecem especial atenção dos Administradores; sempre pode-se recorrer a diversos estudos referentes ao assunto que orientem o debate, como, por exemplo, Michael Porter\footnote{
Michael Porter, em \emph{Estratégia Competitiva} (Rio de Janeiro. Campus, 15a. ed. 1986) introduz reconhecidas técnicas
para análise da indústria e concorrentes; em
\emph{Vantagem Competitiva} (Rio de Janeiro. Campus, 4a. ed. 1992), descreve como as empresas podem criar e
sustentar vantagem competitiva.},
ao reforçar que  ``[...] um produto substituiu outro se ele oferece ao cliente/usuário um incentivo para mudar, no qual ele cobre os custos de migração (fator econômico) ou sobreponha as resistências para mudança (fator humano e cultural)''.

\emph{\textbf{A Sensibilização é uma fase tão importante que muitas vezes pode-se abrir mão do tempo de execução de outras atividades de migração para executar adequadamente esta Fase.}}


\section{Gerenciando a Migração}

Muito do que precisa ser feito para migrar de um ambiente proprietário para um de \emph{Software} Livre é semelhante a qualquer migração. Até mesmo na migração de um ambiente tecnologicamente idêntico e/ou de um mesmo fornecedor, não podemos pressupor que os formatos dos arquivos serão compatíveis -- sempre haverá necessidade de testes apropriados antes de se proceder a qualquer mudança mais difundida. Todas as migrações precisam ser baseadas em cuidadoso planejamento, conforme programa de fases discriminado no Capítulo \ref{metodologia_migracao}.

As orientações apresentadas não pretendem ser um manual sobre gestão de projeto; supomos que a Administração tenha habilidade para gerenciar a migração de forma apropriada e os Administradores, capacidade técnica para realizá-la. No apêndice \ref{plano_de_migracao_mp} existe um exemplo de projeto. A descrição adiante pretende realçar os pontos importantes de uma migração para \emph{Software} Livre.

O diagnóstico do ambiente definido na identificação do cenário poderá indicar necessidade de modificações no ambiente atual, antes de ser concebida a migração para o \emph{Software} Livre. Essa é a razão pela qual até mesmo Administrações que não têm planos imediatos para migração, mas que desejam manter essa opção disponível, são instruídas a solicitar somente padrões multiplataforma e abertos, como mencionados na e-PING, e a avaliar sua infra-estrutura em comparação a esses padrões (veja também Seção \ref{pense_alem}).

%vindo da parte1 "4.2"%%%%%%%%%%%%%%%%%%%
A mudança para o \emph{Software} Livre deve ser vista como qualquer outro tipo de migração de sistemas de TI. Portanto, são aplicáveis, a essas migrações, desafios e possibilidades já experimentados por todo Administrador/gerente de informática. Em especial, a migração de sistemas de TI proporciona a oportunidade de realizar também a reengenharia destes, para satisfazer às novas demandas a eles propostas. Destacam-se 
as seguintes questões: 
\begin{itemize}  
   \item promover a interoperabilidade dos sistemas;
   \item dar suporte aos usuários;
   \item identificar usuários remotos de forma segura;
   \item construir sistemas administráveis.
\end{itemize} 

Acima de tudo, como se certificar de que a segurança seja planejada desde o início e não acrescentada como questão posterior.

No caso específico de migrações para o \emph{Software} Livre, é importante destacarmos que as decisões referentes a servidores têm diferenças significativas em relação às referentes a estações de trabalho. Afinal, para utilização em servidor, o \emph{Software} Livre é bem estável e já empregado em larga escala. A migração de servidores para o \emph{Software} Livre pode ser feita, em termos gerais, sem qualquer efeito adverso para os usuários; por isso, é normalmente, por onde se deve começar um projeto de migração.

Já o uso de distribuições baseadas em \emph{Software} Livre nas estações de trabalho envolve maiores desafios, embora potencialize, para grande parte das organizações, maior economia de custos de propriedade de \emph{software}. Os principais desafios em migrar estações de trabalho se referem à necessidade de que os aplicativos livres mantenham interação com os existentes. Deve ser objeto de atenção, particularmente, a forma como ferramentas de trabalho em grupo (\emph{groupware}) e emuladores de \emph{mainframe} interagem com os ambientes baseados em \emph{Software} Livre e proprietário. 

Adicionalmente, na substituição das ferramentas de automação do escritório proprietário, os documentos-modelo devem ser verificados para garantir que gerem o produto correto. As macros devem ser reescritas, preferivelmente, como \emph{scripts}. Aplicativos para os quais não haja equivalentes em \emph{Software} Livre podem funcionar como Cliente Leve (\emph{thin clients} -- mais informações no Capítulo \ref{arq_ref}). Com o decorrer do tempo, aplicativos de estação de trabalho poderão ser crescentemente substituídos por equivalentes livres.

Embora as diretrizes objetivem mudança completa para o \emph{Software} Livre, a tendência é que um ambiente heterogêneo seja construído, especialmente porque a migração de centenas de estações de trabalho levará tempo. É possível ainda a possibilidade de utilização simultânea de aplicativos livres e proprietários, na eventualidade de não existirem versões estáveis de aplicativos livres.

Em qualquer das decisões assumidas pelos Administradores, é importante assegurar-se de que as escolhas, mesmo que não estejam diretamente relacionadas à migração, não amarrem a Administração, no futuro, a formatos proprietários, seja de arquivos ou de protocolos.

Recomendamos refletir quanto ao caráter diferenciado do desenvolvimento do \emph{Software} Livre, o qual possibilita mudança fundamental na forma como as organizações realizam serviços de TI. É a mudança de uma indústria baseada no produto, para uma indústria baseada no serviço. O \emph{Software} Livre possui nitidamente custo menor de instalação. A questão é como formar profissionais em larga escala para o suporte, pois esses geralmente estão mais familiarizados com os produtos proprietários. Existe certo número de companhias de prestação de serviços, bem como representantes de distribuições. No entanto, se a postura da Administração diante da TI é ``Quem será processado se as coisas derem erradas?'', então será necessária mais reflexão sobre as reais condições de responsabilização por problemas na utilização de \emph{software} proprietário. Os mitos de que ambientes de TI baseados neste modelo de licenciamento sejam ``gerenciáveis'' estão profundamente construídos em nossa sociedade.

No entanto, são mitos. Conforme assinala Hexsel\footnote{
HEXSEL, Roberto André. \emph{Propostas de Ações de Governo para Incentivar o Uso de \emph{Software} Livre}. Curitiba, UFPR 2002. Relatório Técnico RT-DINF 004/2002. Disponível em \wwn{http://www.inf.ufpr.br/~roberto}.},

\begin{quote}
\small
O simples fato de existir um proprietário do \emph{software}, e portanto legalmente imputável, não provê necessariamente garantia quanto a 
prejuízos decorrentes de erros ou falhas nos sistemas. 
Pelo contrário, freqüentemente o proprietário se exime de qualquer  responsabilidade por danos 
ou prejuízos decorrentes da \emph{utilização correta\footnote{
Grifo original do autor.}} de seus produtos.\end{quote}
\normalsize

É necessário igualmente entendimento da dinâmica do movimento \emph{Software} Livre e do seu funcionamento. Aconselhamos definir a melhor forma de se relacionar com a comunidade \emph{Software} Livre e usufruir os benefícios do novo modelo de negócios. Os dois modelos adotados apresentam riscos inerentes, mas as condições efetivas para gerenciá-los -- mesmo que não atendidas pelos modelos de comercialização instituídos e praticados -- estão mais acessíveis em ambientes livres.


%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
O processo de migração deveria, em tese, consistir das partes que se seguem. Algumas delas podem ser feitas em paralelo, tais como a 2, a 3 e a 4, ou de acordo com o planejamento de cada instituição.


\subsubsection{1 -- Criação de equipe habilitada com apoio gerencial}

A criação de equipe habilitada é o primeiro passo para a realização de qualquer processo de migração. Além disso, é importante que haja apoio gerencial, caso contrário haverá resistência para sair do modelo dos sistemas proprietários. Essa equipe de suporte técnico deverá possibilitar que se construam, no mínimo, pilotos representativos, o registro oficial desta ação é fundamental; portanto, terá que ser produzido um relatório de implementação/plano de trabalho e talvez algum documento mais detalhado, quando houver mais dados disponíveis.
O Apêndice \ref{portaria_funasa} apresenta um exemplo 
de institucionalização de Comitê ou Grupo de Trabalho.


\subsubsection{2 -- Entendimento do ambiente alvo}

É necessário que se entenda o ambiente-alvo, tanto o \emph{Software} Livre quanto a arquitetura básica (veja Capítulo \ref{arq_ref}), junto com as várias opções e escolhas disponíveis. Nesta fase é importante treinar a equipe existente, recrutar ou utilizar consultores, o que vai demandar custo inicial; portanto, requer suporte gerencial suficiente. Há, por vezes, a idéia de que o \emph{Software} Livre possa ser compreendido e utilizado sem ônus. Essa expectativa pode provocar inconsistências nos custos planejados ou subdimensionar os planos de investimento.


\subsubsection{3 -- Revisão da arquitetura base e aplicativos utilizados}

A migração é uma oportunidade para revermos a arquitetura-base, bem como os aplicativos. A arquitetura que recomendamos  no Capítulo  \ref{arq_ref} é baseada no controle centralizado e possui algumas vantagens ali discutidas. Essa mudança pode implicar custos, a serem considerados. Devemos atentar que os custos não se referem à mudança para o \emph{Software} Livre, mas sim para a nova arquitetura.


\subsubsection{4 -- Entendimento da ``filosofia'' do 
\emph{Software} Livre} 

É muito importante que se entenda a ``filosofia'' do \emph{Software} Livre. Algumas questões precisam ser bem consideradas antes de tomar-se qualquer decisão:

	\begin{itemize}	
	
		\item[A. ] Onde houver várias opções para cada uma das funções, é necessário que os Administradores conheçam os prós e os contras de cada produto, para que se possa optar pela solução que melhor atenda às suas necessidades. Neste Guia serão sugeridos os parâmetros que devem ser avaliados para cada uma das opções disponíveis, seguidos pelas opções de produtos que já foram conhecidas na prática em experiências da Administração e, finalmente, um ou mais casos de sucesso relacionados com essas ferramentas.

	
		\item[B. ] As diferenças entre as várias distribuições dos sistemas operacionais livres devem ser consideradas. Algumas são desenvolvidas por empresas que oferecem suporte, reparos e manutenção. Outras têm características distintas para essas mesmas questões; as diferenças devem ser avaliadas antes de se escolher uma distribuição. 

		\item[C. ] Os Administradores devem determinar o nível de suporte necessário. Pode-se obter suporte comercial com os responsáveis pelas soluções ou com os mantenedores das distribuições, no caso de oferecerem tal suporte. Caso não ofereçam, pode-se consegui-lo com serviços de terceiros, pois o código-fonte é disponibilizado e há muitas companhias oferecendo prestação de serviços para tais soluções e distribuições. 


		\item[D. ] A questão do suporte é uma diferença bem clara em relação ao mercado de software proprietário, no qual somente as empresas que dispõem do privilégio de acesso à fonte podem fornecer o suporte com maior nível de profundidade -- isso se torna crítico caso o revendedor proprietário deixe o negócio sem liberar o código-fonte. Com a adoção do \emph{Software} Livre, as organizações têm acesso e controle ao código-fonte; dessa forma, adquirem autonomia para negociar com qualquer empresa que preste este mesmo serviço.

Além disso, a maior parte desses aplicativos possui listas de discussão ativas, em que um pedido de ajuda será respondido por alguém interessado na ferramenta. A presença de uma lista de discussão ativa e de uma comunidade de usuários é, freqüentemente, um dos primeiros critérios na seleção de componentes do software.  

	\end{itemize}


\subsubsection{5 -- Realização de auditorias nos sistemas existentes}

As informações coletadas pelas auditorias serão necessárias, não somente para fazer a migração, mas, em grande parte, para construir um modelo de custo de propriedade para um plano / relatório de migração detalhado.

Façamos o inventário\footnote{O Governo Federal disponibiliza para o inventário de Hardware e Software o sistema CACIC (mais informações: \www{http://guialivre.governoeletronico.gov.br/cacic}), disponibilizado sob a licença GPL.}:


	\begin{itemize} 
		\item[A. ] Para cada aplicativo usado:

		\begin{itemize}
			\item[a. ] o nome do aplicativo, o número da versão e o contato para responder a questões relacionadas ao aplicativo;

			\item[b. ] a quantidade de usuários que requerem acesso ao aplicativo, incluindo a hipótese de acesso simultâneo;

			\item[c. ] com quais sistemas operacionais o aplicativo pode ser usado -- considerar todos os ambientes;


			\item[d. ] quais outros aplicativos são necessários, tanto no cliente como no servidor, para o aplicativo funcionar -- pré-requisitos e/ou dependências;

			\item[e. ] o \emph{hardware} exigido, considerando se é necessário algum equipamento fora dos padrões ou de última geração -- alta performance, etc.;

			\item[f. ] os protocolos e as portas usados para comunicar-se com outros aplicativos;

			\item[g. ] os formatos de arquivos requeridos e gerados.

		\end{itemize}


		\item[B. ] Requisição de Dados:

			O conceito de \textbf{dado} deve ser interpretado no sentido amplo, o que inclui, por exemplo, documentos de processador de textos e planilhas, dados som/voz e de imagem, além dos bancos de dados habituais: em geral, qualquer coisa que se pretenda processar em um computador.

		\begin{itemize}
			\item[a. ] Quais são as dificuldades na interface com sistemas externos ou usuários fora dos quadros de funcionários da Administração? 

			\item[b. ] Quais os requisitos para guardar os dados e poder processá-los no futuro? Há um repositório de dados legados ao qual se tenha que dar suporte? Em caso positivo, há necessidade de aplicativos específicos para acessá-los (caso estejam armazenados em mídias cuja acessibilidade é restrita a determinado sistema ou aplicativo) e processá-los?

			Dividamos os dados nas seguintes categorias:

			\begin{itemize}
				\item[i. ] Dados que não precisam ser mantidos e podem ser eliminados. Descarte-os. Tenha cuidado de fazer o \emph{backup} para o descarte no período adequado, de acordo com a política de armazenamento de dados da instituição;

				\item[ii. ] Dados que precisam ser mantidos e se encontram normalmente em formato aberto, ou podem que ser facilmente convertidos para o formato aberto. Neste último caso, o custo e o prazo  da conversão devem ser avaliados;

				\item[iii. ] Dados que precisam ser mantidos, mas que estejam em formato proprietário fechado, que não permite fácil conversão para formato aberto. Esses dados podem necessitar de cópias do aplicativo proprietário específico para serem mantidos. O custo desse aplicativo deve ser avaliado. O número de cópias desse aplicativo pode ser determinado pelo grau de acesso necessário aos dados. Por exemplo, se os dados forem raramente acessados, uma única cópia em uma máquina central será suficiente.

Também pode ser necessário manter um \emph{hardware} específico para usar esses aplicativos. Finalmente, para tanto, pode-se considerar a utilização de características do modelo Cliente Leve -- \emph{Thin Client} (veja na Seção \ref{cliente_leve}) ou a utilização de emuladores (veja Seção \ref{emulacao}). 

			\end{itemize}
		\end{itemize}

		\item[C. ] Requisitos de Segurança
		\begin{itemize}
			\item[a. ] Qual é o sistema atual para criação de usuários e senhas? Há uma estrutura para os nomes dos usuários? Em caso positivo, qual é ela? Está de acordo com a norma apontada na e-PING? Qual é a política para alteração de senhas?
 
			\item[b. ] Há sistemas que requerem alguma outra autenticação além de um simples nome de usuário e de uma senha?

			\item[c. ] Quais as políticas Administrativas e de Governo existentes com relação ao uso de computadores? Existem normas internas específicas? Por exemplo, há restrições ao uso da Internet e do correio eletrônico?
 
			\item[d. ] Há planos de segurança que requerem o uso de \emph{hardware} e/ou \emph{software} específico?

			\item[e. ] Existe alguma sistemática de uso de Certificação Digital?

		\end{itemize}
	\end{itemize}

\subsubsection{6 -- Definição de um cenário detalhado para migração}

A definição do cenário deverá basear-se nos dados compilados nas etapas sugeridas nos itens anteriores e consistirá de algumas seções, inclusive,

	\begin{itemize}
		\item[A. ] do  custo do ambiente existente durante um período razoável de tempo, tal como 3 anos, com os pressupostos apropriados à Administração;

		\item[B. ] do custo de ambientes alternativos, bem como do custo da migração para cada um, ao longo do mesmo período;

		\item[C. ] da comparação dos custos dos ambientes atual e futuro;

		\item[D. ] dos pontos fortes e fracos do ambiente atual e das várias alternativas.
	\end{itemize}


\subsubsection{7 -- Atenção com os usuários}

A consulta aos usuários pode ser elemento favorável. Explique as razões da migração e os seus efeitos. Considere as preocupações informadas com seriedade e permita que eles utilizem a tecnologia o mais breve possível. Quanto mais rápido se envolverem, melhor. Isso pode ser exigência em alguns órgãos, porém deve ser realizado em qualquer caso, para facilitar a introdução do que pode vir a ser uma mudança significativa nas práticas de trabalho. A questão da sensibilização abordada na Seção \ref{sensibilizacao}, é uma prática importante que não deve ser desprezada.

Crie uma Central de Atendimento que responda às dúvidas dos usuários. Mais tarde, quando a migração estiver estabelecida, a Central poderá responder a problemas e tornar-se centro de excelência e boas práticas. Crie um sítio na rede interna com uma Seção de Dicas e um ``Como Fazer'', que pode ser atualizado pelos próprios usuários (existem aplicações livres próprias para permitir tal interação). Isso é importante porque os usuários se sentirão incluídos e também porque o sítio dará ao pessoal do suporte técnico uma idéia dos tipos de problemas mais enfrentados por seus clientes. 


\subsubsection{8 -- Realização de projetos piloto}

Quando assumir que o cenário foi definido e a justificativa elaborada, comece com projetos-piloto de acordo com sua capacidade de atender às demandas geradas pelos projetos(Vide Apêndice \ref{plano_de_migracao_mp}). Isso vai proporcionar, dentre outras coisas:

	\begin{itemize}
		\item[A. ] dados para modelos mais refinados de Custo de Propriedade e Serviços;

		\item[B. ] opinião do usuário, que pode ser usada para facilitar a introdução de outros sistemas; 

		\item[C. ] validação ou modificação da arquitetura-alvo e do modelo de negócios;

		\item[D. ] aquisição de experiência ao longo do tempo.

	\end{itemize}


	
\subsubsection{9 -- Definição do modelo de migração}	

É necessária a definição do modelo do processo de migração a partir do momento em que ele começar. As principais opções são:

	\begin{description}
		\item[A. Big bang: ] Todos os usuários mudam do sistema antigo para o novo ao mesmo tempo. Na prática, a mudança provavelmente deverá ser marcada para um final de semana ou um feriado nacional. A vantagem é que não são necessárias disposições para acesso a mais de uma plataforma e que o pessoal não precisará ficar trocando de um sistema para o outro, mantendo o ambiente homogêneo. As desvantagens incluem o alto risco e a necessidade de recursos durante a mudança. Este esquema de migração provavelmente só será atrativo para pequenas Administrações.

De qualquer forma, se for possível, evite a migração \emph{Big Bang}. As migrações \emph{Big Bang} possuem tantas variáveis para se controlar que quase sempre falham, provavelmente por problema de gestão, e não do \emph{Software} Livre, o que pode não ficar transparente.

Evitar a migração \emph{Big Bang} não significa que o Administrador vai protelar indefinidamente a migração. Ela deve ser feita de maneira progressiva nos estritos limites em que esta progressividade for indispensável à continuidade das atividades de seu órgão ou sua instituição. 

		\item[B. Transição em fases por grupos: ] Os usuários mudam do sistema antigo para o novo em grupos. É provável que grupos funcionais completos sejam movidos juntos, para minimizar compartilhamento (perda de segurança) de dados e problemas do trabalho em grupo. Os riscos podem ser contidos, e os recursos administrados pela escolha do tamanho apropriado dos grupos. É possível aproveitar este momento para fazer alterações necessárias no \emph{hardware}, com substituição gradual da estação de trabalho, ao mesmo tempo fazendo a atualização das máquinas removidas de um grupo e instalando-as depois no lugar das máquinas antigas do outro grupo. Existe a desvantagem para ambientes heterogêneos: às vezes pode ser necessário tratar de cada ambiente separadamente.

		\item[C. Transição usuário por usuário: ] Essencialmente igual à opção de transição por grupo, porém com tratamento diferenciado para cada pessoa. Este método de alimentação ``gota a gota'' requer poucos recursos, permite dimensionar o problema; entretanto, cria ilhas no ambiente e é ineficiente e de interesse pouco provável para grandes Administrações. Pode, no entanto, ser forma apropriada de conduzir projetos-piloto.

É provável que os sistemas antigos e os novos tenham que funcionar lado a lado por algum tempo. É importante possuir estratégia de transição que possibilite aos sistemas antigos e aos novos trabalharem juntos, de forma que as atividades de produção possam seguir adequadamente durante o período de transição. Pode-se levar longo tempo até a substituição da última máquina; portanto, é provável que a coexistência venha a ser fator relevante no processo. 


		\item[D. Transição para as pessoas ou tecnologias novas na organização: ] O ambiente organizacional tem seu próprio dinamismo e sempre convive com momentos de mudança, que acontecem, por exemplo, com a entrada de novas pessoas ou tecnologias. É interessante aproveitar esse momento para capacitar as pessoas no ambiente existente no \emph{Software} Livre ou instalar soluções livres nos equipamentos adquiridos. Exemplo comum é a utilização de ferramentas de automação de escritório, em especial editores de texto, planilha eletrônica e correio eletrônico para as pessoas recém-chegadas à instituição.

	\end{description}	

\subsubsection{10 -- Possibilitar que a migração atinja toda a Administração} 

Para permitir a migração para toda a Administração, será necessário treinamento adicional dos usuários e do pessoal técnico. Considere o treinamento do pessoal técnico primeiro, com repasse posterior do aprendizado aos demais, visando diminuir os gastos e as dificuldades. A realização de campanhas internas com a montagem de Planos de Comunicação pode atingir de maneira equânime toda Administração.


\subsubsection{11 -- Acompanhamento do \emph{feedback} do usuário}

É fundamental que a equipe de migração atente ao \emph{feedback} dos usuários e procure resolver quaisquer problemas que aparecerem. Algumas necessidades dos usuários podem ser tão específicas, que não será possível prevê-las com antecedência ou descobri-las durante projetos-piloto. Esteja certo de que haverá recursos suficientes para lidar com tais necessidades após a transição, pois a agilidade no atendimento a essas demandas deixará os usuários mais seguros.

Podem existir nichos de aplicativos proprietários que eventualmente não possuam soluções com performances equivalentes no \emph{Software} Livre. Nessas circunstâncias, dependendo da criticidade de tais sistemas, o processo de migração pode ser inexeqüível em um primeiro momento, aguardando que as soluções livres equivalentes adquiram relativo grau de estabilidade.


\chapter{Questões Humanas}
\label{questoes_humanas}

Essas diretrizes não objetivam tornar-se um guia para gestão de Recursos Humanos. A intenção é destacarmos os tipos de questões surgidas em instituições que realizaram a migração para o \emph{Software} Livre. As Administrações já terão enfrentado muitas dessas questões em outras áreas e, por isso, possuem considerável habilidade interna para superá-las de forma solidária. O setor de Recursos Humanos deverá estar envolvido desde o início do processo.

É muito importante que todo o pessoal seja consultado e informado sobre o desenvolvimento do processo. Uma forma de fazê-lo é criar uma Intranet que possibilite ser atualizada facilmente e possa ter seção para \emph{feedback} do usuário. Existem soluções em \emph{Software} Livre que possibilitam este tipo de interação, com sistemas de votação, livro de visitas, dentre outras.

A oportunidade de treinamento é fundamental. Algumas instituições permitem que os usuários decidam por si se desejam participar de treinamentos, enquanto outras determinam quem será treinado. A escolha vai depender da cultura da Administração e do assunto do treinamento. Manuais e documentação estão disponíveis muitas vezes apenas em língua estrangeira, e isso pode causar problemas para algumas pessoas da equipe. A tradução para a Língua Portuguesa pode ser considerada como custo de migração e acarretará a necessidade da tradução continuada das atualizações.

Algumas interfaces de usuário do \emph{Software} Livre oferecem opção de idiomas, porém a tradução pode não ser completa, com alguns itens ainda em língua estrangeira. Além disso, nem todos os aplicativos terão suporte às \emph{configurações regionais} (localização plena). No entanto, existe um quadro de mudança acelerado, e a estrutura que permite o uso de outro idioma estará disponível, se a Administração quiser usá-la. Já há, inclusive, interfaces com característica de acesso para deficientes visuais disponíveis. Buscando promover a inclusão digital e reiterando que a informação é para todos, o Departamento de Governo Eletrônico teve o compromisso de elaborar um Modelo de Acessibilidade de Governo Eletrônico\footnote{Mais informações sobre o Modelo de Acessibilidade de Governo Eletrônico - e-MAG, pode ser obitido em \www{http://www.governoeletronico.gov.br}}, para o desenvolvimento e a adaptação de sítios e portais governamentais, gerando um conjunto de recomendações a serem consideradas. Tais recomendações proporcionarão que o processo de acessibilização dos sítios do Governo Brasileiro seja conduzido de forma padronizada, de fácil implementação, coerente com as necessidades brasileiras, e em conformidade com os padrões internacionais. %no país.

Há algumas reações clássicas a qualquer mudança nas práticas de trabalho, para as quais deverá haver planejamento, como, por exemplo:


\subsubsection{i)  Medo do Desconhecido}

O uso do \emph{Software} Livre poderá ser completamente novo para a maioria dos usuários e a equipe técnica. O medo natural do desconhecido e a tendência em manter os sistemas existentes poderão fazer que as pessoas resistam à migração.

Em toda instituição sempre haverá usuários mais curiosos, que poderão interessar-se em experimentar o novo ambiente. Esses são os que deverão ser apresentados, em primeira instância, ao novo Sistema e se tornarão voluntários do projeto de migração. A experiência indica que, após as pessoas perderem suas reservas, elas verificam que a utilização do novo Modelo não difere profundamente do modelo proprietário a que estavam acostumadas e acabam por utilizar o \emph{Software} Livre com satisfação. Assim, existe a possibilidade que esse grupo inicial de usuários mude para a nova plataforma de forma entusiástica e que essas pessoas sejam aquelas que melhor irão avaliar o desempenho das novas ferramentas, tornando-se fonte de retorno importante para o processo de migração.

Outro fator que devemos  considerar é a possibilidade de algum funcionário já possuir conhecimento sobre o \emph{Software} Livre e estar, inclusive, utilizando ferramentas livres em seu trabalho. Por isso, é interessante que a Administração esteja atenta à identificação dessas pessoas, as quais poderão auxiliar positivamente o processo de migração em função da experiência pessoal.

O primeiro grupo de usuários (os voluntários) poderá ser usado em projetos-piloto; após passarem pela experiência, poderão incentivar e orientar seus colegas. Podemos pensar na criação até mesmo de um grupo para estes usuários, com destaque dentro da Administração, para servirem como exemplo e quebrarem a barreira das pessoas mais relutantes.

De qualquer forma, na segunda Fase, os usuários mais reservados terão que receber mais recursos de apoio, por meio de central de atendimento, Intranet, usuários locais experientes e treinamento presencial.

O mesmo processo pode ser usado para a equipe técnica, porém é provável que o nível do treinamento seja significativo se o ambiente proprietário existente não for compatível com Unix/Linux. A equipe técnica, particularmente, precisa ter suas dúvidas logo dirimidas. Essas pessoas serão ponto focal para todos os problemas que acontecerão e, se não acreditarem no Projeto, não poderão encorajar os usuários e nem auxiliar positivamente no primeiro atendimento e suporte. 


\subsubsection{ii)  O efeito diluição de Currículo}

Tanto a equipe técnica quanto os usuários poderão sentir que, por não usarem o software proprietário ``padrão'' da indústria, terão prejuízo em sua habilidade de desenvolver-se na carreira. Este é um problema que demanda cuidadoso gerenciamento. A Administração não deve parecer distante dessa realidade em sua abordagem com o corpo técnico. Mas até que o \emph{Software} Livre seja largamente utilizado, as Administrações deverão enfrentar este obstáculo com freqüência e informar que a qualificação profissional de quem atua com o \emph{Software} Livre é valorizada no mercado.

Torna-se necessário sólido investimento em capacitação técnica e aperfeiçoamento profissional na intenção de valorizar, motivar e especializar a equipe para a nova realidade. 



\subsubsection{iii) Conhecimento é poder}

As pessoas que conhecem os sistemas e as configurações já em utilização dispõem de certo poder e podem demonstrar relutância em abrir mão dele, se o ambiente do \emph{Software} Livre for muito diferente do existente. Novamente, o problema requer gerenciamento cuidadoso, já que essas pessoas cumprem papel crítico no funcionamento desses Sistemas.

É possível priorizarmos o treinamento delas no novo Modelo com a intenção de garantir-lhes o \emph{status} já adquirido na organização, agilizando o processo de migração e tornando-as aliadas. 


\chapter{Facilitando a vida}
\label{facilitando}

Há algumas considerações que podem facilitar a introdução do \emph{Software} Livre. Neste Capítulo, destacamos algumas medidas que poderão atenuar o impacto da migração no ambiente.

\section{Introduza aplicativos livres em ambiente proprietário}

Muitos dos aplicativos \emph{Software} Livre trabalham em sistemas operacionais proprietários; isso proporciona a oportunidade de introduzirmos esses aplicativos sem ter que trocar totalmente o ambiente. Por exemplo, o pacote de automação de escritório OpenOffice.org, o navegador Mozilla e o servidor web Apache trabalham no Windows\reg; portanto, podemos utilizá-los  como substitutos do Microsoft Office\reg, do Internet Explorer\reg e do IIS\reg, respectivamente.

Além de ser menos radical, essa abordagem permite que a reação do usuário seja avaliada em pequena escala e os planos para seu treinamento podem ser baseados na experiência real. Além disso, problemas como conversão de formatos de arquivos, macros e modelos podem ser facilitados, se o aplicativo proprietário permanecer instalado por algum período.

Essa abordagem nos permite dizer que a escolha do aplicativo no ambiente-alvo final (livre) estará limitada aos que trabalham com base em sistema operacional proprietário. Por exemplo, o alvo para navegador \emph{web} pode ser o Galeon, porém o Mozilla é o único que funciona tanto no Windows\reg como no GNU/Linux, portanto pode ser adotado primeiro, por já funcionar em ambiente proprietário. 

\section{Faça primeiro as coisas fáceis}
\label{faca_primeiro_facil}

Em primeira instância, efetue mudanças que não causem ``divisões'' no corpo funcional. Isso significa proceder às mudanças primeiro no servidor, o que vai fornecer uma plataforma para a introdução das mudanças das estações, futuramente. Muitas das mudanças serão compatíveis com ambiente proprietário;  portanto, o efeito da alteração será minimizado.

Por exemplo, servidores de nomes DNS, servidores DHCP e servidores de base de dados com software proprietário são todos candidatos à substituição por um \emph{Software} Livre equivalente e ainda estabelecem interface com o resto dos sistemas correntes (livres ou proprietários) como antes.

Também existem soluções que funcionam no \emph{Software} Livre e permitem a coexistência de diversos sistemas operacionais, a exemplo do Samba. A adoção imediata desse tipo de solução flexibiliza o processo de migração por permitir melhor gerenciamento na migração dos ambientes existentes.

\section{Contrate um Profissional da Comunidade}

A Administração pode aproveitar o momento de ingresso de novos profissionais para sua estrutura interna, sejam eles concursados ou contratados, para dar uma nova dinâmica a sua área de TIC no que tange aos processos de migração, podendo assim gerar facilitadores para a incorporação de novas tecnologias e a mudança de paradigmas.% Os primeiros profissionais podem chegar através de concursos futuros para aumentar o peso do conhecimento e domínio de tecnologias abertas e softwares livres.
Para os profissionais concursados pode ser exigido o domínio em ferramentas livres diretamente na ementa do concurso e o conhecimento com relação ao \emph{software} livre valorizados no processo seletivo. Para os profissionais terceirizados podem ser aproveitados os contratos em vigência para ampliar o quadro funcional ou realizar uma troca dos atuais profissionais já contratados. A chegada de um profissional que já possui convivência com o \emph{software} livre e contato com a comunidade, poderá criar uma cadeia motivacional forte dentro da equipe e acelerar a migração.

\section{Elabore um Plano de Migração}

A dificuldade de conhecer o ambiente a ser gerenciado pelo Administrador é algo tradicional para a área de TICs. O nível de incertezas na gestão do parque tecnológico na maioria da vezes é alto. Pode-se aproveitar o momento de migração para criar um ``Plano de Migração" que valorize o diagnóstico do ambiente computacional e venha inclusive a resolver muitas outras questões relacionadas à Tecnologia da Informação. Portanto, este momento é uma oportunidade ímpar para se repensar e reestruturar toda a rede de TIC, agregando novos valores, corrigindo falhas antigas, padronizando o ambiente e adotando tecnologias inovadoras.

\section{Pense Além}
\label{pense_alem}

Empregue de imediato diversas práticas para minimizar o que certamente poderá dificultar a migração futura.

\begin{enumerate} 
   \item Insista para que todo desenvolvimento feito para \emph{web}, construído na instituição ou contratado, produza conteúdo que possa ser visto pelos navegadores definidos pela e-PING, ou seja, sem aplicação  de padrões proprietários. As Administrações não precisarão, em qualquer caso, de um \emph{software} específico para ver seu conteúdo. Existem ferramentas disponíveis para ajudar a verificar a compatibilidade das páginas da \emph{web}.

   \item Desencoraje o uso indiscriminado de macros e \emph{scripts} em documentos e planilhas; encontre outros meios de prover funcionalidade. O uso indiscriminado desses recursos é, comumente, um meio pelo qual os vírus infectam os sistemas. As macros também podem ser facilmente usadas para roubar dados e subverter documentos, pois podem fazer o documento  ``dizer''  coisas diferentes, dependendo de quem o está lendo, ou  ``dizer''  outra coisa quando impresso. Finalmente, muitas das ações feitas por meio de macros e \emph{scripts} devem receber sistematização mais robusta.

   \item Insista no uso de formatos de arquivos-padrão abertos, por exemplo, Postscript e PDF. Sabe-se que há discussão sobre serem, o Postscript e o PDF, modelos abertos ou não. Isso é mais um debate sobre definições estritas e, em particular, de quem controla o modelo. Na realidade, esses são os formatos de arquivos amplamente utilizados no momento, que possuem definições disponíveis publicamente e podem ser usados sem restrições significativas. Diversas soluções em \emph{Software} Livre produzem com facilidade esses formatos de arquivos.

Particularmente, não use formatos proprietários para arquivos cujo objetivo é somente serem lidos e não editados pelo destinatário, pois tais arquivos são um meio comum de disseminar vírus. Ao usar formatos proprietários, a Administração estará amarrada ao fornecedor por tempo considerável. Além disso, esses formatos proprietários podem incluir quantidades consideráveis de metadados, em particular textos apagados previamente, os quais, caso vistos, podem tornar-se problemáticos para a Administração. 

   \item Na elaboração de documentos em colaboração de usuários, utilize um formato de maior interoperabilidade possível (ou melhor acessibilidade). Isso aumentará a possibilidade de uso de aplicativos do \emph{Software} Livre no futuro.

   \item Use protocolos de padrão aberto. Definem-se protocolos de padrão aberto como aqueles livres de patentes e implementados com requisitos e especificações abertas, como aqueles atribuídos pelo padrão W3C.
Os padrões adotados pelo Governo Federal estão no documento de referência da e-PING, conforme destacado na seção \ref{subsecao_eping}.

   \item Desenvolva sistemas baseados preferencialmente em modelo de três camadas (veja Seção \ref{arq_generica}), em que o código do aplicativo é independente da interface humana e dos métodos de acesso aos dados. Por exemplo, se possível, tenha uma interface que possa ser acessada em um navegador \emph{web} de \emph{Software} Livre. A construção de aplicativos dessa forma, modular, tornará mais fácil a migração aos poucos. Reduzirá não somente a escala de qualquer fase de migração, como também o risco de fracasso. Os aplicativos de clientes monolíticos tradicionais são, notoriamente, difíceis de manipular.

   \item Insista que todos os novos aplicativos sejam feitos para ser portáveis. Evite linguagens de arquitetura específica e APIs ou construir aplicativos que exijam a presença de outros aplicativos proprietários.

   \item Substitua os leitores de correios que usem formatos de armazenagem proprietários e/ou que se comuniquem com servidores usando protocolos não-padronizados pela e-PING. Se possível, utilize uma solução para armazenar listas de endereços e calendários em formato aberto. 

\end{enumerate}


