Gerando scripts do banco de dados por PowerShell – Passo 1

Tento já explicado como utilizar o SMO para gerar o scripts do SQL Server por .NET, agora teremos a alternativa com PowerShell:

# Referências
[void][system.reflection.assembly]::loadfrom("C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SqlServer.Smo.dll")

# Objetos
$srv = new-object Microsoft.SqlServer.Management.Smo.Server(".\SQLEXPRESS")

$db = $srv.Databases["DemoAspNet"]

# 1. Gerando o Script do banco de dados
$db.Script() | Out-File "C:\Temp\DemoAspNet.sql"

# 2. Gerando o Script das tabelas do banco de dados
$db.Tables | % { $_.Script() } | Out-File "C:\Temp\DemoAspNet_Tables.sql"

# 3. Script com o GO entre as linhas (Forma 1)
$go = "`nGO`n"
$db.Tables | % { $_.Script() | % { $_ + $go} } | Out-File "C:\Temp\DemoAspNet_Tables.sql"

# 4. Script com o GO entre as linhas (Forma 2)
$go = "
GO
"
$db.Tables | % { $_.Script() | % { $_ + $go} } | Out-File "C:\Temp\DemoAspNet_Tables.sql"

# 5. Gerando o DROP das tabelas
$options = new-object Microsoft.SqlServer.Management.Smo.ScriptingOptions
$options.ScriptDrops = $TRUE

$go = "`nGO`n"
$db.Tables | % { $_.Script($options) | % { $_ + $go} } | Out-File "C:\Temp\DemoAspNet_TableDrop.sql"

# 6. Gerando o script das tabelas com as Primary Keys
$options = new-object Microsoft.SqlServer.Management.Smo.ScriptingOptions
$options.DriPrimaryKey = $TRUE

$go = "`nGO`n"
$db.Tables | % { $_.Script($options) | % { $_ + $go} } | Out-File "C:\Temp\DemoAspNet_TableKey.sql"

# 7. Gerando o script das tabelas com as Keys e Constraints, sem Collation
$options = new-object Microsoft.SqlServer.Management.Smo.ScriptingOptions
$options.DriAll = $TRUE
$options.NoCollation = $TRUE

$go = "`nGO`n"
$db.Tables | % { $_.Script($options) | % { $_ + $go} } | Out-File "C:\Temp\DemoAspNet_TableAll.sql"

Forma resumida para este script se executado dentro do próprio contexto do SQL Server (Jobs, PowerShell do SQL Server ou sqlps.exe):

# Sem referências

# Objetos
sl SQLSERVER:\SQL\LOCALHOST\SQLEXPRESS\Databases\DemoAspNet

$db = get-item .

# 1. Gerando o Script do banco de dados
$db.Script() | Out-File "C:\Temp\DemoAspNet.sql"

# 2. Gerando o Script das tabelas do banco de dados
dir Tables | % { $_.Script() } | Out-File "C:\Temp\DemoAspNet_Tables.sql"

# 3. Script com o GO entre as linhas (Forma 1)
$go = "`nGO`n"
dir Tables | % { $_.Script() | % { $_ + $go} } | Out-File "C:\Temp\DemoAspNet_Tables.sql"

# 4. Script com o GO entre as linhas (Forma 2)
$go = "
GO
"
$db.Tables | % { $_.Script() | % { $_ + $go} } | Out-File "C:\Temp\DemoAspNet_Tables.sql"

# 5. Gerando o DROP das tabelas
$options = new-object Microsoft.SqlServer.Management.Smo.ScriptingOptions
$options.ScriptDrops = $TRUE

$go = "`nGO`n"
dir Tables | % { $_.Script($options) | % { $_ + $go} } | Out-File "C:\Temp\DemoAspNet_TableDrop.sql"

# 6. Gerando o script das tabelas com as Primary Keys
$options = new-object Microsoft.SqlServer.Management.Smo.ScriptingOptions
$options.DriPrimaryKey = $TRUE

$go = "`nGO`n"
dir Tables | % { $_.Script($options) | % { $_ + $go} } | Out-File "C:\Temp\DemoAspNet_TableKey.sql"

# 7. Gerando o script das tabelas com as Keys e Constraints, sem Collation
$options = new-object Microsoft.SqlServer.Management.Smo.ScriptingOptions
$options.DriAll = $TRUE
$options.NoCollation = $TRUE

$go = "`nGO`n"
dir Tables | % { $_.Script($options) | % { $_ + $go} } | Out-File "C:\Temp\DemoAspNet_TableAll.sql"

Artigo relacionado:

PowerShell no SQL Server – Step 1

Gerando scripts do banco de dados por .NET – Passo 1

Criar scripts do banco de dados, ou de qualquer objeto do SQL Server por .NET não é algo muito complexo, pois os principais objetos do SMO possuem o método Script. Mas como gerar o script desejado é o que pode dar um pouco de dor de cabeça para quem esta começando com SMO, seja no .NET ou no PowerShell.

Para primeira demonstração, vamos ver como é simples gerar o script de criação do banco de dados:

using System;
using System.IO;
using Microsoft.SqlServer.Management.Smo;

namespace DemoSmo
{
    class DemoScript1
    {
        static void Main()
        {
            const string serverName = @".\SQLEXPRESS";

            const string databaseName = "DemoAspNet";

            const string scriptPath = @"C:\TEMP\DemoAspNet.sql";

            var server = new Server(serverName);

            var database = server.Databases[databaseName];

            // Gerando o script do banco de dados e salvando este em um arquivo
            using (var file = new StreamWriter(scriptPath))
            {
                Console.WriteLine("Script do banco de dados...");

                foreach (var str in database.Script())
                {
                    file.WriteLine(str);
                    file.WriteLine("GO");
                }
            }

            Console.WriteLine("Script concluído ...");

            Console.ReadKey();
        }
    }
}

Agora a geração do script das tabelas do banco de dados:

using System;
using System.IO;
using System.Linq;
using Microsoft.SqlServer.Management.Smo;

namespace DemoSmo
{
    class DemoScript2
    {
        static void Main()
        {
            const string serverName = @".\SQLEXPRESS";

            const string databaseName = "DemoAspNet";

            const string scriptPath = @"C:\TEMP\DemoAspNet.sql";

            var server = new Server(serverName);

            var database = server.Databases[databaseName];

            using (var file = new StreamWriter(scriptPath))
            {
                Console.WriteLine("Script das tabelas...");

                // Relacionando as tabelas do banco de dados
                foreach (var table in database.Tables.Cast<Table>().Where(table => !table.IsSystemObject))
                {
                    // Gerando o script de cada uma das tabelas
                    file.WriteLine("--");
                    file.WriteLine("-- Tabela: [{0}].[{1}]", table.Schema, table.Name);
                    file.WriteLine("--");
                    foreach (var str in table.Script())
                    {
                        file.WriteLine(str);
                        file.WriteLine("GO");
                    }
                }
            }

            Console.WriteLine("Script concluído ...");
            Console.ReadKey();
        }
    }
}

Na geração do script das tabelas, é bem provável que você vá se perguntar “onde estão as constraints das tabelas?”, ai entra o objeto ScriptOptions, o qual pode ser utilizado como argumento para o método Script, afim de definir como e do que será gerado o script.

Para entender isso, temos abaixo um ScriptOptions configurado para gerar o script das tabelas com as Primary Keys (DriPrimaryKey):

var scriptOptions = new ScriptingOptions { DriPrimaryKey = true };

O ScriptOptions para gerar o script de DROP das tabelas (ScriptDrops):

var scriptOptions = new ScriptingOptions { ScriptDrops = true };

E para um exemplo final, utilizando o ScriptOption afim de gerar o script das tabelas com as Keys e Constraints (DriAll) e sem informar Collation das colunas (NoCollation):

using System;
using System.IO;
using System.Linq;
using Microsoft.SqlServer.Management.Smo;

namespace DemoSmo
{
    class DemoScript3
    {
        static void Main()
        {
            const string serverName = @".\SQLEXPRESS";

            const string databaseName = "DemoAspNet";

            const string scriptPath = @"C:\TEMP\DemoAspNet.sql";

            var server = new Server(serverName);

            var database = server.Databases[databaseName];

            //Definindo o objeto ScriptingOptions
            var scriptOptions = new ScriptingOptions { DriAll = true, NoCollation = true };

            using (var file = new StreamWriter(scriptPath))
            {
                Console.WriteLine("Script das tabelas...");

                foreach (var table in database.Tables.Cast<Table>().Where(table => !table.IsSystemObject))
                {
                    //ScriptingOptions com argumento do método Script
                    file.WriteLine("\n\n--\n-- Tabela: [{0}].[{1}]\n--\n", table.Schema, table.Name);
                    foreach (var str in table.Script(scriptOptions))
                    {
                        file.WriteLine(str);
                        file.WriteLine("GO");
                    }
                }
            }

            Console.WriteLine("Script concluído ...");
            Console.ReadKey();
        }
    }
}

No artigo da próxima semana veremos como utilizar o objeto Scripter para gerar o script de vários objetos ao mesmo tempo, e ainda nesta semana a versão deste artigo para PowerShell.

Gerando backups do SQL Server por PowerShell

No primeiro artigo desta semana vimos como gerar backups do SQL Server por .NET, agora veremos alternativas mais simples para tal, com o PowerShell.

Para o nosso primeiro script de Backup com PowerShell, precisaremos referenciar os assemblies do SMO, e criar um código semelhante ao que vimos com .NET:

# Referências
[void][system.reflection.assembly]::loadfrom("C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SqlServer.Smo.dll")
[void][system.reflection.assembly]::loadfrom("C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SqlServer.SmoExtended.dll")

# Objetos
$srv = new-object Microsoft.SqlServer.Management.Smo.Server(".\SQLEXPRESS")

$bk = new-object Microsoft.SqlServer.Management.Smo.Backup

# Definindo de qual banco de dados será executado o backup
$bk.Database = "BASE1"

# Definindo onde será salvo o backup
$bk.Devices.AddDevice("C:\TEMP\BASE1_PowerShell.bak", [Microsoft.SqlServer.Management.Smo.DeviceType]::File)

# Executando o backup
$bk.SqlBackup($srv)

Mas quando no contexto do PowerShell do SQL Server (scripts executados em Jobs ou diretamente pelo PowerShell presente no SQL Server Management Studio ou SQLPS.exe), teremos algumas facilidades, como não precisar referenciar os assemblies do SMO e utilizar de “atalhos” para instanciar as variáveis do SQL Server (ex.: Smo.Server):

# Sem referências

# Objetos
$srv = get-item SQLSERVER:\SQL\LOCALHOST\SQLEXPRESS

$bk = new-object Microsoft.SqlServer.Management.Smo.Backup

# Definindo de qual banco de dados será executado o backup
$bk.Database = "BASE1"

# Definindo onde será salvo o backup
$bk.Devices.AddDevice("C:\TEMP\BASE1_PowerShell.bak", [Microsoft.SqlServer.Management.Smo.DeviceType]::File)

# Executando o backup
$bk.SqlBackup($srv)

Referências:

How To Load .NET Assemblies In A PowerShell Session

Gerando backups do SQL Server por .NET

No artigo da semana passada, tivemos uma breve introdução à biblioteca SMO, que pode ser tanto utilizada pelo .NET quanto pelo PowerShell para criar aplicações ou scripts para gerenciar o SQL Server.

Nesta semana, demonstrarei como utilizar as classes Smo.Backup e Smo.BackupDeviceItem, de um outro assembly do SMO, o SmoExtended, que poderá ser encontrado no caminho:

C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies\Microsoft.SqlServer.SmoExtended.dll

As classes Smo.Backup e Smo.BackupDeviceItem são responsáveis respectivamente por gerar backup e determinar onde este será salvo.

Para demonstrar a utilização destas classes, adequei o exemplo da semana passada, que relacionava os bancos de dados de uma determinada instancia do SQL Server, para também possibilitar identificar a data de ultimo backup de um determinado banco de dados e realizar o backup do mesmo:

Ajuste realizado:

// Gerando a classe Smo.Backup
var backup = new Backup { Database = database.Name };

// Definindo com o Smo.BackupDeviceItem onde será salvo o backup
var path = string.Format(@"C:\Temp\{0}_{1:yyyy-MM-dd HH_mm_ss}.bak", database.Name, DateTime.Now);

backup.Devices.AddDevice(path, DeviceType.File);

// Executando o backup
backup.SqlBackup(server);

Gerenciando o SQL Server por meio de aplicações .NET – Primeiros passos

Já tratamos no blog duas formas de interação da .NET Framework com o SQL Server, sendo a primeira e principal forma interação, por ADO.NET para execução de comandos T-SQL,  e a segunda forma, por SQL CLR para estender funcionalidades do SQL com .NET.

Além destas duas formas de interação, temos o SMO (SQL Server Management Objects) que nos permite gerenciar o SQL Server utilizando um coleção de assemblies .NET, que podem ser utilizados em scripts do PowerShell ou em aplicações .NET de forma bem transparente.

Há alguns anos escrevi um artigo para revista Mundo .NET sobre este assunto, mas não demonstrei muito do potencial que temos com SMO.

A partir deste artigo, pretendo iniciar uma nova série de artigos que tratarão várias formas de utilizar SMO com .NET e também com PowerShell (mais como um comparativo de como fazer com .NET e com PowerShell).

Hoje, vamos começar com uma aplicação .NET simples que ilustra bem a utilização do SMO.

Tento um projeto .NET, o primeiro passo será encontrar os assemblies que compõe a SMO, no caso do SQL Server 2008 (100). Eles podem ser encontrados nas pastas:

C:\Program Files\Microsoft SQL Server\100\SDK\Assemblies
C:\Program Files (x86)\Microsoft SQL Server\100\SDK\Assemblies

Caso não os encontre, você pode instalá-los:
http://www.microsoft.com/download/en/details.aspx?id=16177#SMO
(Microsoft SQL Server 2008 Management Objects)

Para a nossa primeira aplicação, precisaremos dos seguintes assemblies referenciados em nossa aplicação:

Microsoft.SqlServer.Smo.dll
Microsoft.SqlServer.ConnectionInfo.dll
Microsoft.SqlServer.Management.Sdk.Sfc.dll

Adicionadas as referencias ao projeto, será possível criar uma aplicação simples em .NET (em C# no meu caso) para relacionar os bancos de dados de uma determinada instancia do SQL Server:

using System;
using System.Linq;
using System.Security;
using Microsoft.SqlServer.Management.Smo;
using Microsoft.SqlServer.Management.Common;

namespace DemoSmo
{
    class Program
    {
        static void Main()
        {
            Console.WriteLine("Servidor:");
            var serverInstance = Console.ReadLine();
            Console.WriteLine();

            Console.WriteLine("Usuário:");
            var user = Console.ReadLine();
            Console.WriteLine();

            ServerConnection conn;

            if (!string.IsNullOrEmpty(user))
            {
                Console.WriteLine("Senha:");
                var pass = ReadPassword();
                Console.WriteLine();

                // Criando um objeto de conexão com SQL Authentication
                conn = new ServerConnection(serverInstance, user, pass);
            }
            else
            {
                // Criando um objeto de conexão com Windows Authentication
                conn = new ServerConnection(serverInstance);
            }

            // Criando um objeto que abstrai a instância do SQL Server
            var server = new Server(conn);

            Console.WriteLine("Carregando lista de bancos de dados ...");
            Console.WriteLine();

            try
            {
                // Recuperando a lista de banco de dados
                var lst = server.Databases;

                // Escrevendo a relação de banco de dados encontrados
                foreach (var db in lst.Cast<Database>().OrderBy(e => e.ID))
                {
                    Console.WriteLine("{0}. {1}", db.ID, db.Name);
                }
            }
            catch (Exception ex)
            {
                Console.WriteLine(ex.Message);
            }

            Console.WriteLine();
            Console.WriteLine("Concluído ...");
            Console.ReadKey();
        }

        // Método para evitar que a senha digitada apareça na tela da aplicação
        private static SecureString ReadPassword()
        {
            var pass = new SecureString();

            while (true)
            {
                var key = Console.ReadKey(true);

                if (key.Key == ConsoleKey.Enter) break;

                pass.AppendChar(key.KeyChar);

                Console.Write("*");
            }

            Console.WriteLine();

            return pass;
        }
    }
}

E por fim, executando a aplicação por SQL Authentication:

E por Windows Authetication:

Por enquanto não há muitos materiais no blog sobre SMO, então você pode esperar novos artigos serem publicados, encontrar outras fontes pela internet ou comprar a revista que tem o artigo que escrevi sobre SMO.

Até o próximo artigo!

A verdade sobre a instalação em Português do SQL Server

PowerShell – Especial de Natal

Boa noite pessoas,

Seguindo tradição do blog, pelo terceiro Natal consecutivo, estava planejando algo bem diferente dos anos anteriores, e em conversas com o @WilliamPietro, tivemos a ideia de criar um script de PowerShell especial para esta data.

Abaixo o script:

$a = (Get-Host).UI.RawUI
$a.WindowTitle = "PowerShell - Especial de Natal"
$b = $a.WindowSize
$b.Width = 18
$b.Height = 12
$a.WindowSize = $b

$c = "        .`n       .#.`n      .###.`n     .#%##%.`n    .%##%###.`n   .##%###%##.`n  .#%###%##%##.`n        #`n        #`n"

1..300 | % {
	$a.BackgroundColor = "darkgreen"
	$a.ForegroundColor = "white"
	cls
	Write-Host $c
	Write-Host "    HO HO HO"
	Wait-Event -timeout 1
	$a.BackgroundColor = "red"
	$a.ForegroundColor = "white"
	cls
	Write-Host $c
	Write-Host "   Feliz Natal"
	Wait-Event -timeout 1
}

Resultado, durante aproximadamente 10 minutos a tela do PowerShell exibirá de forma alternada as seguintes mensagens:

Boas festas, e que tenhamos um ótimo 2012!

Artigos relacionados:

Artigo de Natal de 2009

Artigo de Natal de 2010

Desenvolvendo componentes COM+ com .NET

Quando se trabalha com .NET em sistemas mistos com plataformas legadas, como ASP Classic, VB, VBScript, Delphi ou até mesmo Ole Automation do SQL Server, o .NET ainda permite interoperabilidade com estes sistemas por meio de componentes COM+, seja o .NET consumindo COM+ ou a plataforma legada consumindo um COM+ desenvolvido em .NET.

Como existem poucos artigos em português para explicar como desenvolver COM+ com .NET, procurei a demonstrar a criação de componente simples com C# no Visual Studio 2010.

Para a criação do componente, utilizei um projeto do tipo Class Library:

A este projeto adicionei referência à System.EnterpriseServices:

Nas propriedades do projeto, editei a “Assembly Information”,

especificando o Assembly como COM-Visible:

De acordo com a plataforma do sistema legado (x64, x86) que o COM+ irá trabalhar, defini esta em Plataform target:

Obs.: Esta opção é muito importante, pois é muito comum criar um componente em x64 e este não ser visível para uma aplicação VB x86, assim como tentar criar componentes x86 para tentar acessar por um VBScript que será executado em uma plataforma x64.

Por fim, criei uma chave “strong name” para o projeto:

Para uma classe .NET ser considerada componente, ela deverá ser herdada de System.EnterpriseServices.ServicedComponent, conforme abaixo, onde temos uma classe simples cujo o seu único método retorna um texto:

using System.EnterpriseServices;

namespace DemoCom
{
    public class Objeto : ServicedComponent
    {
        public string Teste()
        {
            return "Demo COM+ //By SQL From Hell";
        }
    }
}

Após realizar o build do projeto, utilizei o regsvcs de acordo com a plataforma x86/x64 e versão da .NET Framework do projeto, informando o caminho do seu assembly (DLL) onde esta “$(TargetPath)”.

C:\Windows\Microsoft.NET\Framework\v4.0.30319\regsvcs.exe $(TargetPath)

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regsvcs.exe $(TargetPath)

Após a instalação do componente, este será visível na relação de COM+ Applications no Component Services:

Para testar o COM+, utilizarei um VBScript simples:

Dim obj
Set obj = CreateObject("DemoCom.Objeto")
MsgBox obj.Teste

Também sendo possível por Ole Automation do SQL Server:

DECLARE @obj INT

DECLARE @return INT, @text NVARCHAR(4000)

-- Criando a 'instância' do componentes

EXEC @return = sp_OACreate 'DemoCom.Objeto', @obj OUT

-- Verificando se a chamada obteve sucesso.

IF @return = 0 PRINT 'COM: OK'

-- Chamando o método Teste

EXEC @return = sp_OAMethod @obj, 'Teste', @text OUT

IF @return = 0 PRINT 'Teste: OK'

PRINT 'Resultado: ' + @text

E por fim, para desinstalar o componente, bastará utilizar o mesmo regsvcs informando “/u”.

C:\Windows\Microsoft.NET\Framework\v4.0.30319\regsvcs.exe /u $(TargetPath)

C:\Windows\Microsoft.NET\Framework64\v4.0.30319\regsvcs.exe /u $(TargetPath)

Artigos relacionados:

Acessando dados de Web Service com Ole Automation Procedures

Gerando templates das System Views e Information Functions

Boa noite pessoas, para limpar minha pasta de scripts, segue outras duas queries que ainda não tinha colocado no blog.

Gerando templetes das System Views:

SELECT
[name] AS [View]
,'SELECT * FROM [sys].['+ [name] + ']' AS Query
FROM sys.all_views
WHERE [schema_id] = SCHEMA_ID('sys')
ORDER BY [name]

Gerando templates das Information Functions:

SELECT
[name] AS [Function]
,'SELECT * FROM [sys].['+ [name] + ']'
+ ISNULL('(' + LEFT([parameters], LEN([parameters]) - 1) + ')', '')
AS Query
FROM sys.all_objects o
CROSS APPLY
(
SELECT CAST((
SELECT [name] + ', '
FROM [sys].[all_parameters]
WHERE [object_id] = o.[object_id]
FOR XML PATH('')
) AS VARCHAR(8000)) AS [parameters]
) p
WHERE [schema_id] = SCHEMA_ID('sys')
AND [type] = 'IF'
ORDER BY [name]

Excessos e descasos na gestão na área de TI

Ao se falar em gestão na área de TI, a temos fundamentada em cinco atividades básicas da administração: Planejamento, Organização, Execução, Controle e Liderança. Mas tanto excessos, como a falta de dedicação em algumas destas atividades, são fatores a prejudicar os resultados que são esperados deste área.

Os principais problemas são visíveis já na atividade de Planejamento, onde são determinadas as ações pelas quais as estratégias da organização serão suportadas ou executadas pela área de TI. O excesso de planejamento neste momento pode estar relacionado ao uso demasiado de tempo para planejar como se dará toda a execução, numa tentativa utópica de planejar tudo o que será feito e prever todos os problemas que podem ocorrer durante a execução, tirando muito da autonomia de quem executará, além do planejamento ter que lidar com problemas tão complexos e dinâmicos que não poderão estar claros neste momento.

Da mesma forma, o descaso no planejamento pode tornar o objetivo da execução algo muito vago e exigir muito da autonomia de pessoas que talvez não estejam aptas para tomar iniciativas ou decisões. Assim, a busca de um equilíbrio no planejamento, permitindo uma visão clara do que é esperado da equipe e além de dar um pouco de autonomia à equipe (de acordo com a maturidade desta), para que esta equipe tenha o poder de planejar a execução das atividades mais específicas e tomar decisões a fim de resolver problemas de pouco impacto que venham a surgir durante a execução.

A atividade de Organização é vítima normalmente do descaso, por não orientar a equipe sobre as responsabilidades de cada elemento e também não definindo as regras que devem ser obedecidas (ex.: como se dará a comunicação com outras áreas da organização, clientes e fornecedores), o que poderá gerar conflitos internos na equipe durante o andamento dos trabalhos, ou conflitos entre a equipe e as outras áreas da organização.

A atividade de Organização permite a equipe entenda suas responsabilidades e as regras para execução das suas atividades. Sendo estas bem definidas, exigirá poucas mudanças durante a execução das atividades, além de suprimir conflitos desnecessários e evitar que determinadas pessoas fiquem sobrecarregadas de atividades.

Se as atividades de Organização e Planejamento não estiverem bem definidas, os problemas serão visíveis na atividade de Execução, resultando em retrabalhos, conflitos, atrasos e não alcançando os resultados esperados pelas suas atividades.

Durante a atividade de Execução, a atividade de Controle permite verificar problemas não esperados ou observar o comportamento e o impacto de problemas previstos, o que possibilita à equipe e ao gestor definir novos planos e se reorganizar a fim de resolver tais ocorrências. Esta atividade requer um pouco de prudência do gestor, pois a falta de controle do que esta acontecendo pode comprometer toda a execução das atividades, e o excesso de controle pode gerar insatisfação por conflitar com a maturidade e a cultura da equipe (hábitos, forma de fazer suas atividades e resolver problemas).

A atividade de Liderança pode sofrer pelo excesso, tornando a figura do gestor mais como um “pai” da equipe, tornando a equipe superdependente do seu gestor. Ou sofrer pelo descaso, onde o gestor não é visto como elemento que merece alguma consideração por parte da equipe ou que visto como uma figura que “só atrapalha, no lugar de ajudar”.

A figura do gestor deve vista de acordo com a maturidade da equipe, na qual deve ser visto como um elemento de auxilio (representante na comunicação com os outros setores da organização, parceiros, clientes e fornecedores) para equipes maduras e que já possuem autonomia, ou como elemento de orientação para que a equipe ainda não madura chegue a desenvolver seus relacionamentos e aos poucos conquistar sua autonomia.

Assim, evitando o excesso ou o descaso com as atividades de gestão na área de TI, será possível alcançar os resultados esperados pela organização, assim como fomentar a maturidade e autonomia da equipe, exigindo do gestor o papel de coordenar a equipe e melhorar os relacionamentos desta com elementos internos e externos da organização.

Rascunho escrito em Setembro de 2011.