Handerson Frota – WEB2.0

Introdução
Minha intenção com este post é tentar de alguma forma ajudar aqueles profissionais que estão iniciando em Java Web, profissionais que com tantas opções que a plataforma Java nos oferece, as vezes não sabem por onde iniciar, então quero tentar dar um norte inicial para começar bem.

Não vamos aqui discutir sobre qual IDE, ferramenta, infra em geral, pois já temos vários artigos na web que tratam deste assunto. Quero focar na parte conceitual da coisa.

Quero com este post responder algumas perguntas como:

1. Sou iniciante em Java para Web, o que devo aprender primeiro?
2. Devo começar pela especificação JEEx e seguir somente ela?
3. Qual framework devo começar?
4. Por que não devo começar com JSF/Seam e afins?

Não quero aqui entrar no mérito de quem é melhor, framework X ou Y, linguagem X ou Y. Como já falei em uma lista: Amadureci para não perder meu tempo discutindo sobre isso.

Vou escrever aqui a minha opinião, a minha visão, baseado nos anos de experiência que tenho com desenvolvimento Web e Java, baseado nas conversas que tenho com outros profissionais com a mesma e maior experiência do que eu, nas experiências de inúmeros projetos que já participei durante toda a minha carreira.

Então vamos iniciar as argumentações, lembrando que isso é voltado para aqueles que estão ainda iniciando no desenvolvimento Web na plataforma Java ou para aqueles que não tem uma base sólida em Web.

Iniciando no mundo Java Web

1. Sou iniciante em Java para Web, o que devo aprender primeiro?

Bem, se você está entrando agora no mundo Web, você precisa primeiro aprender WEB, aprender como funciona uma página WEB e aprender a linguagem da WEB, seus protocolos e comportamentos. Isso parece ser óbvio, mas muitos se perdem neste momento e simplesmente não ligam para isso, achando que já devem aprender frameworks X ou Z.

Vamos citar aqui os principais conceitos que um bom desenvolvedor web TEM que saber ou pelo menos conhecer:

Entenda como funciona e para que serve todos os verbos HTTP (HTTP verbs) que existem. Tenha um entendimento pelo menos de POST, GET, DELETE e PUT.

Você como desenvolvedor web é OBRIGADO a saber HTML, pelo menos as suas tags mais comuns, como utilizá-las e para que servem cada uma e como funcionam. Não saber isso é como querer tirar a carteira de motorista sem saber o que é um carro. Acesse: w3schoolsHTML

Entenda, como e o que é CSS, você não precisa ser um expert em CSS, mas saber o básico ajuda e muito, e você um dia irá precisar, acredite. A não ser que você não esteja desenvolvendo para WEB. Uma boa dica, é começar pelo site da w3schoolsCSS e o site do maujor.

Estude também o que é e como funciona um Web Container e sua estrutura básica de funcionamento.

APRENDA Servlet, JSP, por mais que você ache “antigo” eles são muito importantes para você complementar seu conhecimento em desenvolvimento web na plataforma java e acredite seu framework UTILIZA eles por baixo. Então é FUNDAMENTAL saber o que é e como funciona um Servlet e JSP.

“Brinque” um pouco com TAGsLib, EL (Expression Language), são ferramentas simples de se utilizar (principalmente EL), e deixam seu código bem mais legível. Você verá mais a frente.

JavaScript, ele é importante. Se você deseja ser um bom profissional web, você PRECISA saber javaScript. Por muitos anos o JavaScript foi considerado uma linguagem fraca, que só servia para enviar alerts para os usuários ou somente para validação de formulários. Grande engano.
O JS já provou por A + B que é uma poderosa linguagem em diversos segmentos de server-side desde Frameworks MVC (Express/Node.js | Helma/Rhino) a bancos de dados não relacionais (CouchDB, MongoDB), além do tradicional client-side com Frameworks populares (jQuery/ExtJS).

E o mito de que JS é ruim de manter, código desorganizado etc, é simplesmente somente um MITO, e é simplesmente falta de conhecimento de quem não sabe desenvolver com JS. JS hoje, está muito maduro e robusto, existem vários frameworks para facilitar a sua vida, é testável e é um código limpo, quando se usa da maneira certa. E isso claro, serve para qualquer linguagem.

Mas, assim como qualquer outra linguagem, não aconselho você já começar usando jQuery (ou qualquer outro), aliás, até pode sim, mas antes dê uma lida na documentação para entender o que é o DOM e BOM, apenas leia, você não precisa ser um expert, o que não seria ruim, pois iria te ajudar muito, mas apenas o conhecimento básico já é suficiente. Conhecer e saber usar uma ferramenta (framework) é uma coisa, ENTENDER o que ele faz é outra.

Depois disso, parta para um framework como o jQuery, MooTools, ExtJS etc.

[UPDATE-13/07/2011]

Alguns me perguntaram sobre quais livros ou fontes de estudos indico para iniciar com JavaScript, então resolvi atualizar aqui, essas dicas e para não replicá-las, vou pegar as mesmas que um amigo já fez .

Dicas do site do Christiano Milfont:

Existem alguns bons materias gratuitos que recomendo, como: Como criar um Framework javascript, Eloquent Javascript, JavaScript Garden, jQuery Fundamentals (que apesar de ser sobre jQuery, cobre muito sobre javascript em si), Essential Javascript & jQuery Design Patterns for Beginners e o Guia e a documentação de Referência da Mozilla.

Os melhores livros de Javascript:

Existem vários bons livros, inclusive já os indiquei em posts passados, veja indicações: recente e antiga.

2. Devo começar pela especificação JEEx e seguir somente ela ?

Bem, o certo seria sim, você deve começar pela especificação, mas infelizmente não é tão simples assim.

Se alguém falar isso para você, corra, corra dele e procure um profissional o quanto antes para te descontaminar, esse papinho de que é Deus no céu e especificação na terra é pura besteira. Quer exemplos ? Vamos lá.

Se você depender e seguir como um religioso fanático somente a especificação, você como profissional, estará no mínimo 5 anos ATRASADO.

Sim, para se ter uma ideia, o Ajax foi implementado no JSF, somente em 2010, ou seja, você que é bitolado, só foi poder utilizar-se de Ajax ano passado, enquanto eu e outros profissionais já o utilizavam desde 2004. Vergonha ? Também sentiria.

E não caia na conversa de que é o que o mercado pede, a não ser que você queira ser SÓ MAIS UM no mercado, depois não reclame do seu salário. Destaque-se, se sobressaia, não seguindo essa conversa fiada você já terá boas chances de ser um profissional bem qualificado e consequentemente, bem remunerado no mercado.

Mais um exemplo simples, é seguindo somente a especificação, você não vai usar o Hibernate ou Spring, pois eles não estão na especificação, a especificação “recomenda” usar o JDBC, CMP, JPA e outros Patterns. Para quem sabe o que é o Hibernate e Spring saberá o quanto será péssimo desenvolver um sistema web java sem eles, principalmente sem o Spring.

Na minha visão a especificação é somente para te dar uma ideia de como as coisas funcionam, e não como devem ser feitas, ela não é a lei, ela nem sempre é a melhor solução para o seu problema. Por isso não seja bitolado por ela.

3. Qual framework devo começar ?

Supondo que você já tem conhecimento em HTML, CSS, JavaScript, Servlets, JSP, TagLibs ou EL, Container WEB, qual framework você poderia iniciar?

Bem, qualquer frameworks Action-like. Por que?
Quanto menos abstração no lado web o framework possuir (componentes para tudo), mais você vai exercitar e aprender tudo aquilo que você estudou, sem falar na liberdade no desenvolvimento.

Atentem, que não estou aqui entrando no mérito de quem é mais produtivo, rápido, simples ou qualquer outra coisa do tipo. Meu foco é puramente e simplesmente que você aprenda desenvolvimento Web e só isso.

Framework como eu disse é apenas uma ferramenta para se desenvolver, como um martelo para um marceneiro, ou uma chave de fenda para o mecânico.

Seguindo esses passos, você pode evitar o erro (que infelizmente é comum) de querer usar a ferramenta para tudo.

Imagine que o marceneiro ame seu martelo e só queira utilizar ele, então para pregar pregos ele utiliza ele, para parafusar ele também utilize ele, para colar a maneira, ele também utilize o martelo, já imaginou ?

Pois bem, a analogia funciona da mesma forma para frameworks.

Quando você entende web, entende a necessidade do cliente, entende o problema, fica fácil escolher a ferramenta e mesmo assim você pode correr o risco de errar, imagine agora na situação de saber utilizar somente um martelo e pior, achar que ele pode fazer o trabalho de uma chave de fenda. Pense nisso.

Agora, suponha que você é realmente um iniciante, não tem noção de HTML e tudo aquilo que falei, qual framework você deve iniciar ?
NENHUM. Estude aqueles tópicos primeiro.

Aprenda a engatinhar antes de querer correr, para não cair e quebrar as pernas.

4. Porque NÃO devo começar com JSF/Seam?

Porque EU, Handerson Frota, NÃO concordo que um iniciante, que ainda NÃO tem nenhuma noção SÓLIDA de WEB já inicie com JSF?

Porque ? Vamos tentar colocar por tópicos:

a . Abstração do Servlet

Esse não é um problema, não é um defeito, pelo contrário, é até bom, deixa o teu controller desacoplado do objeto HTTPServlet. O VRaptor faz isso e claro o JSF faz isso. Mas ao contrário do VRaptor, que possui um design que facilita os testes, é muito ruim escrever testes de unidade para os managed beans.

Não estou dizendo que não é possível escrever testes de unidade, mas sim que não é tão simples assim quando o código foge do trivial. E ai pergunto, onde está a produtividade? Ah tá, vocês não usam testes?

Agora pergunto para quem nunca viu ou sabe o que é um Servlet, como você vai entender o que é um, saber como funciona se você não vê e ainda acha que não esta usando?

Você não sabe como funciona, o que é, e diz que desenvolve para Web? Acho que não.

Acreditem, existem MUITOS profissionais que começaram assim, que NÃO SABEM QUE JSF, VRAPTOR OU STRUTS, TEM SERVLETS não é legal? Você contrataria ele? Eu não.

b. Malditos componentes

Você está iniciando, não sabe o que é Servlet, mas também não vai aprender HTML, CSS, JS, ou qualquer LINGUAGEM DA WEB, pois você vai ter que aprender COMPONENTES. Componente para input (que muitas vezes o cara não sabe o que é, e acha que isso é do JSF), componentes para tudo.

Você já viu o código gerado do seu componente? Veja e se assuste.

Com o VRaptor ou Struts por exemplo, você usa o simples e eficaz HTML e EL. Simples assim. Resolve o problema e ainda deixa teu código mais limpo.

Veja um exemplo:
Formulario JSF com 2 campos.

<h:form id="UserEntryForm">
    <h:outputText value="Enter Your Name:"/>
    <h:inputText value="#{UserBean.userName}" />
    <h:outputText value="Enter Your age:"/>
    <h:inputText value="#{UserBean.age}" />
    <h:commandButton action="welcome" value="OK" />
</h:form>

Agora com o simples HTML e EL

<form id="form" action="" method="GET/POST" >
    Nome: <input type="text" id="nome" value="${objeto.nome}" />
    Idade: <input type="text" id="idade" value="${objeto.idade}" />
    <input type="submit" value="OK" />
</form>

Agora também compare o código gerado de cada um, e tire suas conclusões.

c. Conflitos de libs

Algo que eu via com muita recorrência em projetos com JSF, eram os famosos conflitos entre conjunto de componentes. Se você queria utilizar uma funcionalidade Ajax por exemplo, teria que utilizar o Richfaces/Ajax4jsf por exemplo, mas ele não se integra bem com o MyFaces Trinidad, por exemplo. Então você fica preso e obrigado a utilizar um componente do início ao fim de um projeto (praticamente).

Isso é prejudicial ao meu ver, pois aprendemos que durante o desenvolvimento de um software, ao contrário de construir um prédio, podemos mudar, podemos alterá-lo.

Você aprende mais sobre o negócio, você aprende mais sobre o próprio software, só que você não vai mais poder mudar, pois está preso naquele conjunto de componentes que você escolheu no inicio do projeto. A não ser que você queira alterar todas as páginas geradas e seus comportamentos. Isso inclui seus controles (ManegedBean e JSP), pois o JSF nos faz o favor de -colar- o JSP com o controller.

Você, ao invés de se preocupar em aprender como funciona a web, tem que se preocupar qual plugin/lib/componente utilizar e que não vá dar conflito com outro. Ok, alguns podem dizer que esses conflitos podem acontecer também com outros “componentes”, APIs/Plugins JavaScript etc. Mas posso afirmar com certeza, que é bem mais simples resolver esses conflitos.

d. Ciclo de Vida

Você ainda não sabe o que é um Servlet, como ele funciona e terá que primeiro entender o ciclo de vida do JSF? Que é completamente diferente do ciclo de vida de um Servlet, que o managed bean utiliza por baixo?
Preciso nem comentar sobre isso.

e. View é fortemente acoplada ao controller (managed bean)

Bem, na minha humilde opinião, não acho isso legal. O teu JSP, fica totalmente dependente do controller e claro dependente de libs do JSF. Diferentemente de uma página JSP com EL, cujo o Struts, VRaptor e outros usam.

Recentemente fizemos uma migração de um sistema em JSF para VRaptor, foi simplesmente APAGAR TUDO e refazer do zero, pois não tinha como reaproveitar nem as telas, pois eram todas feitas com componentes do JSF.

Não deu para aproveitar nada do layout, pois o CSS foi alterado por causado dos benditos componentes do RichFaces, nem as funcionalidades em JavaScript, pois quem fazia isso eram os componentes do JSF.

Ao contrário por exemplo, se fosse um Struts ou um sistema feito com outro tipo de controller que usa-se JSP e EL, e fossemos migrar para VRaptor, poderíamos aproveitar muita coisa, até 100% das telas e uma boa parte do controller.

Conclusão

Eu então, NÃO RECOMENDO que qualquer futuro aspirante a desenvolvedor web, INICIE seus estudos web em cima de um JSF e/ou SOMENTE com JEEx.

A pouco tempo, fizemos algumas entrevistas com alguns profissionais web, e foi um pouco decepcionante. Muitos estavam a anos estagnados em projetos JSF ou JEE “puro”. Ou seja, só sabiam JSF e JEE e não desenvolvimento WEB, não sabiam HTML, não sabiam CSS, não sabiam o que era um Servlet, e quando sabiam não sabiam dizer para que servia e como funcionava, não sabiam o que era um PUT ou um DELETE no verbo HTTP e muitas vezes nem o que era um verbo HTTP, não tinham ideia do que era Restfulie, não sabiam JS, logo não sabiam jQuery ou qualquer outro framework JS.

Sou pago para desenvolver soluções para vários tipos de problemas, e não posso ter somente um martelo como ferramenta.

Bem, finalizo aqui, com esses argumentos que vivenciei em vários projetos e por essa longa experiência que tive e tenho em desenvolvimento web, eu aconselho antes de tentar aprender qualquer framework, entenda o básico dele, ou seja, se é desenvolvimento web na plataforma Java:

NÃO COMECE com JSF!

Isso é uma pergunta acho que freqüente que vários desenvolvedores fazem.

Por que ? O que motiva um gerente de projetos a se meter a nível de código e soluções no projeto ?

Antes de continuar vamos entender para que “serve” um gerente de projetos, vejamos o seguinte trecho abaixo retirado do Wiki:

Um gerente de projetos é um profissional no campo de gerência de projetos que tem a responsabilidade de planejar e controlar a execução de projetos em diversas áreas de atuação, como a construção civil, arquitetura e desenvolvimento de software, entre outras áreas. É o profissional responsável pela condução do projeto e deve contar com o respaldo de patrocinadores (sponsors, segundo a nomenclatura PMI), normalmente indivíduos que estejam fora do projeto a ser executado.

E ainda temos:

O gerente e sua equipe de projetos planejam e coordenam o desenvolvimento do projeto colhendo métricas, suprindo necessidades, recrutando recursos adequados e mantendo o foco na meta de projeto, além de:

• estar sempre alerta, mas não avesso a mudanças;
• ser sensível a aspectos políticos: os interesses dos stakeholders nem sempre convergem;
• agendar reuniões, acompanhar o treinamento, avaliar o desempenho de sua equipe e mantê-la motivada, resolvendo conflitos.

O Milfont fez um post relacionado a esse assunto e o Akita tem um semelhante.

Entendendo o papel de um gerente.

Um gerente é um profissional responsável em lidar com pessoas, ele será a ponte entre a equipe e a diretoria.

Computador lento, cadeira quebrada, prazo do projeto, manter a motivação da equipe, ajudar individualmente cada membro da equipe com qualquer problema que atinja de uma certa forma o projeto, conflitos internos etc, essas são algumas de suas atividades e responsabilidades

Agora eu pergunto novamente.

Por que alguns gerentes teimam em se meter nos projetos a nível técnico ? Ou melhor, por que é “prejudicial” para a equipe o gerente fazer isso ?

Bem, nos já sabemos quais as responsabilidades de um gerente, mas sabemos também que existem gerentes que um dia já foram desenvolvedores e normalmente esses gerentes não sabem mais programar na maioria dos casos.

O gerente não precisa saber informações técnicas, a única preocupação dele é com o projeto como um todo, data de entrega, motivação da equipe etc. E não qual framework a equipe irá utilizar ou o código do desenvolvedor, isso diga-se de passagem, é responsabilidade do líder do projeto, normalmente conhecido por: Líder técnico.

O problema

Quando um gerente tenta se meter na solução proposta de um desenvolvedor eu só vejo um único motivo justo para isso: “O gerente tem a preocupação de que essa solução possa atrasar o projeto ou prejudicar o desenvolvimento do projeto por algum motivo.”

Mas infelizmente não é por isso. O gerente está fazendo porque ele não confia na equipe dele, simples. Isso pode causar um mal estar na equipe e principalmente desmotivação.

Outro problema é quando o gerente se mete a nível de código.

Eu acho que cada um tem um papel dentro da equipe em um projeto e com certeza codificar, escolher soluções, não é um atributo que o gerente deveria se meter. Quem deve decidir isso é a equipe, onde baseado nos conhecimentos dos integrantes eles trilharam o melhor caminho para o desenvolvimento.

Lembro de certa vez que quis utilizar um determinado framework em um projeto. O problema não foi tanto a escolha do framework e sim da maneira que ele estava implementado por mim, pois fiz de uma maneira não muito convencional ao “padrão” deste framework, mas que, comparado ao tradicional dava MUITO mais produtividade e funcionaria da mesma forma.

Foi quando o gerente não quis aceitar essa implementação, alegando que o cliente poderia achar ruim(O_o) e que não era o “padrão de mercado”.

Primeiro pronto: Quem é o desenvolvedor ? Quem vai trabalhar dia a dia no projeto ? Com certeza não será ele, normalmente um gerente não gerencia apenas um único projeto. Então porque ele tinha que se meter na implementação ou solução tecnológica do projeto ?

Segundo ponto: Todos os dias tentamos de várias formas sermos mais produtivos e criar soluções para cada tipo de projeto, onde cada um resolve um problema específico onde irá agregar mais valor ao projeto, então o que é esse “padrão de mercado” ? Por que sou obrigado a ficar preso nele ?

Pra mim isso é medo de mudanças e não confiar na equipe, lembram do:  “estar sempre alerta, mas não avesso a mudanças” ?

Pois é, quando o gerente se mete onde não é da sua alçada acaba acontecendo esse tipo de problema.

O projeto foi entregue em dia (4 dias antes para ser mais exato), mas COM CERTEZA não foi por mérito do gerente, e sim da EQUIPE. Equipe essa que as vezes ignorava muita coisa que o gerente falava, mas não o suficiente. Esse projeto poderia ter sido entregue até bem antes do prazo se o mesmo não tivesse se metido nas soluções e códigos da equipe.

Outro exemplo é quando temos em um projeto um determinado problema e como todo bom desenvolvedor iremos pesquisar a melhor solução para aquele problema. É ai onde o gerente metido a desenvolvedor se mete mais uma vez, não deixando que o desenvolvedor aplique aquela solução.

Isso é totalmente prejudicial, isso além de desmotivar o desenvolvedor acaba de uma certa forma “atrofiando” o mesmo, pois ele não se sente apto a aplicar alguma solução, pois o mesmo sempre é barrado pelo gerente.

Ele deve confiar na equipe dele e não desconfiar da capacidade dela, ele deve instigar a equipe a ser mais dinâmica e ser de uma certa forma auto gerenciável.

Motivos

Medo de mudanças, saudades do tempo de programador, falta de confiança na equipe ?

Bem, não sei ao certo, mas com certeza na maioria dos casos é a plena falta de confiança na equipe.

Se o gerente não confiar na equipe dele, ele se acha no direito de saber de TUDO que está acontecendo no projeto para se poupar de eventuais problemas futuros ou atrasos.

Outro ponto é a vontade de ter o poder, de sentir que está no controle e que todos dependem dele para executar alguma tarefa.

Gerente não é desenvolvedor

O gerente tem que ter em mente que ele não é mais desenvolvedor, ele está em outra área agora, isso não lhe pertence mais.

Nada de tentar decidir qual melhor framework para o projeto, nada de tentar saber com detalhes a nível de código porque aquela funcionalidade não está pronta ou fazer com que o desenvolvedor explique com detalhes os problemas técnicos na reunião diária.

Ai você pode falar: “Mas se deixarmos cada desenvolvedor colocar todas as possíveis soluções no projeto, ele pode ser sim prejudicado e o seu desenvolvimento e manutenção sofreram sérios problemas”.

Sim isso é uma verdade, mas o problema ainda não é do gerente, é da equipe.

Se a equipe não é uma equipe madura, nem o melhor gerente do planeta irá resolver esse problema e o projeto cairá em desastre com ou sem a sua intromissão.

A equipe deve se comunicar bastante e conversar sobre qualquer nova implementação ou solução, devem discutir e nesse ponto o gerente não precisa entrar ou muito menos se meter no sentido de decidir algo, ele pode sim dar alguns palpites baseado em sua experiência, mas NUNCA decidir alguma coisa, isso fica para a EQUIPE.

As pessoas custam a entender que os membros MAIS IMPORTANTES dentro de um projeto não são os Analistas e definitivamente não é o gerente, são os  DESENVOLVEDORES.

São eles que farão a funcionalidade que o cliente tanto quer, são eles que iram procurar e implementar a melhor solução para aquele problema, onde a solução irá prover qualidade e produtividade no desenvolvimento.

Não tem na prática como o gerente saber o que é ou não é mais produtivo pelo simples fato de que: ELE NÃO ESTÁ NO DIA A DIA DO DESENVOLVIMENTO.

Para ser um gerente não necessariamente ele precisa ser o técnico mais experiente ou conhecer a tecnologia que o projeto irá utilizar, basta que ele cumpra com suas responsabilidades de gestão e que não interfira no processo de desenvolvimento do software.

O profissional tem que decidir se ele quer entrar na área de gestão ou continuar na área técnica, fazer as duas juntas NUNCA vai funcionar.

Conseqüências

Nas metodologias ágeis o cliente tem como comunicador o desenvolvedor e não o gerente, o gerente não irá decidir ou ao menos saber qual tecnologia ou solução foi escolhida para aquele problema.

Quando o gerente começa a se meter nestes casos que citei é gerado um clima chato e desagradável na equipe com a presença deste gerente.

Ele acaba passando uma imagem negativa para a equipe, como uma pessoa autoritária, intrometida e que “pega no pé” mais do que deveria.

A equipe para de respeitá-lo, para de vê-lo como facilitador do seu trabalho e começa a ver ele como “peso” no projeto, a equipe fica totalmente desmotivada e no fim, quem será prejudicado é o projeto e depois os desenvolvedores que como sempre, levam a culpa.

Então você está me dizendo que não precisamos de um gerente no projeto ?

Não, definitivamente não. Estou dizendo que NÃO PRECISAMOS DE UM GERENTE QUE SE META NA ÁREA TÉCNICA EM GERAL.

Precisamos sim de um gerente, um gerente que se abstraia ao máximo da área técnica e que torne viável e possível um bom ambiente de desenvolvimento para a equipe.

Conclusão

O gerente tem um papel muito importante no início de projeto. Com as conversas iniciais com o cliente, prover treinamento para a equipe, resolver conflitos, entender porque o membro faltou e tentar gerenciar isso da melhor forma para não prejudicar o projeto e nem desmotivar o membro, manter a equipe motivada e focada no projeto, agendar reuniões, facilitar a vida do desenvolvedor para que o mesmo fique bem motivado e com isso faça um excelente trabalho no projeto.

Um bom gerente irá lhe dar um suporte necessário para que você tenha “liberdade” dentro do projeto e um bom ambiente e infra estrutura de trabalho.

No final temos um sucesso: projeto entregue, cliente feliz, desenvolvedor motivado  e um gerente respeitado.

Então se você é um gerente não tenha ódio por mim, acredite estou fazendo um bem para você, não se meta no desenvolvimento deixe isso para a sua equipe, já pensou se um técnico de futebol (odeio futebol ) não confiasse no seu time ?

Pense nisso e seja um GERENTE e não um PESO.

Abraços