Desenvolvimento ágil baseado com contrato que tenha sido aceito por advogados parece impossível. A natureza de processos tradicionais de compra e contratação não coincide com os princípios ágeis. Quando um projeto é pequeno você até consegue dar um jeitinho, mas para um projeto grande com altos riscos a situação é diferente. O cliente quer saber o que ele vai ter pelo dinheiro que vai pagar, embora ele, de fato, não consiga detalhar suficientemente suas necessidades. Tendo anos atrás adotado princípios de trabalho ágeis, em algum momento temos que encarar esse desafio. E parece que como certa vez disse Nelson Mandela: “sempre parece impossível até que seja feito”. Permita-nos compartilhar nossas experiências em uma empresa de seguros.
Era uma situação incomum. Uma empresa de seguros queria introduzir no mercado um novo serviço de seguro saúde no prazo de seis meses. As aplicações de suporte de workflow e de comunicações deveriam ser desenvolvidas do zero enquanto a integração com a aplicação de registro de apólices existente era mandatório. Faltavam especificações claras. Ao todo era um projeto muito ambicioso e arriscado. Vários fornecedores apresentaram propostas, as quais o cliente não confiou por causa da altíssima faixa de preço. Eles, felizmente, compreenderam que uma abordagem ágil tinha que ser seguida para ter uma solução funcionando dentro de seis meses. Essa foi nossa sorte, porque em muitos outros casos precisamos de muito esforço para convencer o cliente que uma abordagem ágil seria a melhor.
As RFPs trazem um monte de informação, mas a maioria delas não é realmente necessária.
A RFP consistia em várias páginas de requisitos técnicos e funcionais. Imediatamente ficou claro porque os outros fornecedores prepararam propostas tão diferentes. Apesar de todo o trabalho feito pelos analistas de negócio do cliente sobravam incertezas e faltavam funcionalidades essenciais e descrições de integrações.
Por ser claro que faltava informação propusemos introduzir três semanas de brainstorms para conhecer os analista e os especialistas no domínio (incluindo vários usuários finais).
Juntos discutimos as diferentes funções e tarefas, definimos papéis de usuários, que no final resultaram no “escopo do projeto”. Sumarizamos a discussão através de épicos e, quando possível estórias de usuários para mostrar que havíamos entendido suas necessidades.
Depois desses workshops até mesmo o cliente entendeu a complexidade de seus próprios processos.
Estimando para preparar a proposta
Seria razoável concordar em um orçamento e data limite se não entende muito bem o que deve ser entregue? A resposta é sim – mas apenas se usa métodos de projetos apropriados para esses tipos de desafios. Ágil é um deles. Embora tenhamos dado um jeito de concordar com o escopo, ainda tínhamos pela frente um dos maiores desafios: definir e formalizar todos os compromissos. Hoje em dia existe um framework para contratos ágeis, mas não enquanto estávamos preparando nossa oferta.
Decidimos estimar de duas formas diferentes. Primeiramente, estimamos de uma forma mais tradicional discutindo quanto tempo uma determinada estória de usuário levaria. Checamos essas premissas “chutando” quanta capacidade de design, desenvolvimento, testes e implementação seriam necessários para fazer o projeto dentro do prazo acordado. A segunda forma foi baseada em “Planning Poker”. A equipe basicamente define a complexidade dos épicos e estórias de usuários por comparação. Baseado em nossa experiência com projetos similares, mais ou menos sabíamos qual velocidade (quantidade de horas de desenvolvimento por pontos de história) poderíamos presumir.
É claro que esses métodos geram estimativas diferentes, mas tendo estimativas feitas com métodos diferentes nos tornamos mais capazes de definir o total de projeto que assumimos ser necessário para entregar a solução requisitada. Também incluímos um fator de risco, porque consideramos que um grande gerenciamento adicional seria necessário para tocar o projeto.
Então, as negociações de preço começaram.
Para o cliente, nosso orçamento era muito alto (como sempre, devo dizer). Graças à nossa estimativa de projeto totalmente transparente, o cliente estava plenamente ciente da forma como havíamos estimado o projeto. Graças a essa transparência, sabíamos que tudo que foi incluso era o que realmente era necessário.
Convencemos o cliente a aumentar o orçamento para se aproximar da nossa estimativa. Concordamos que o orçamento do cliente seria chamado de orçamento “alvo” para o projeto. Além disso, adicionamos 40% que gerou um orçamento máximo. Assim que o orçamento cruzasse o orçamento alvo, o cliente seria cobrado pela metade da tarifa de hora de um desenvolvedor. Também concordamos que, no caso de conseguirmos realizar o escopo acordado dentro do orçamento máximo, compartilharíamos as sobras.
Nesse caso, um processo padrão de controle de mudanças deveria ser estabelecido. A abordagem Custo-Alvo-Com-Limite-Máximo foi inspirado pelo artigo de John Rask “Contratos de Custo-Alvo“.
Havendo chegado a um acordo verbal, a execução do projeto começou. As formalidades ainda tomariam dois meses, mas não podíamos esperar mais. Baseado num acordo de cavalheiros, o projeto teve seu kick-off.
Advogados são necessários …
Rascunhar um acordo de negócio é uma coisa, mas colocá-lo no papel de uma forma que os processos administrativos de negócio ficassem satisfeitos, sem emperrar a execução de um projeto ágil é um grande desafio. A nosso pedido, o cliente nos enviou as condições da compra. E eles estavam longe de serem ágeis.
Nosso advogado, que já havia aprendido a ser mais ágil, preparou um acordo, que continha várias das condições do cliente, e lhes enviamos de volta. Seus advogados revisaram o documento e basicamente todas nossas propostas foram removidas.
Concluímos que essas interações legais não levariam a nada e, portanto, organizamos uma reunião entre diretores representantes do “lado do negócio” e advogados dos dois lados para explicar ao advogado do cliente qual era o objetivo do projeto, porque ele precisava ser ágil e o que agilidade significava.
Isso ajudou.
A construção do contrato
Uma estrutura contratual estava sendo esboçada. Além de condições gerais de compra, essa estrutura contratual incluía regras como:
O escopo do acordo ser de desenvolvimento de sistema. Manutenção e administração, documentação do usuário, treinamentos, etc, eram, por exemplo, excluídas;
Divisão do projeto em releases;
O planejamento de alto nível dos releases;
A explicação do processo ágil, incluindo divisão por interações, uso de estórias de usuários para definir o escopo dos releases;
O processo de aceite por release baseado em critérios de aceite e no aceite final do sistema após o release final e da satisfação do cliente. O documento de aceite estava sendo incluído como um anexo;
Procedimentos de tratamento de falhas;
Comunicação entre cliente e fornecedor e do poder de tomada de decisão das pessoas chave envolvidas;
Templates e documentos a serem usados durante o processo de desenvolvimento;
Termos de pagamento baseados na divisão do projeto.
Por questões administrativas do lado do cliente foi preciso de uma razoável papelada e acordamos que os seguintes documentos fluiriam pelo projeto.
Dividindo o projeto em pedaços menores
O sistema completo foi dividido em dez releases para melhor definir e gerenciar o escopo. Cada release tinha seu próprio orçamento, baseado nas estimativas de alto nível dos épicos e das estórias de usuários. Graças à abordagem “story points” e “planning poker” fomos capazes de determinar o tempo necessário para realizar alguns releases.
Conseguimos rascunhar um arcabouço contratual com as “regras” da nossa cooperação. Além de que cada release tem seu próprio acordo e protocolos de aceitação.
Por release, uma equipe de analistas e consultores definia o escopo, resultando em um “Backlog de Release de Produto”. O Backlog de Release de Produto continha todos os casos de uso que deveriam ser implementados juntos com critérios de aceitação apropriados e a definição de pronto, com o que cada caso de uso deveria ter. Graças a isso, conhecíamos exatamente o que precisava ser feito, bem como quando estava pronto. Juntos, isso formava a “definição de release”.
Então a equipe de desenvolvimento quebrariam o release em várias e estórias de usuários detalhadas. Prioridades são estipuladas juntamente com o product owner resultando em um planejamento por iteração. Isso foi tudo formalizado através de um “acordo de iteração”. Além disso, a equipe definia a velocidade esperada por iteração, o que era usado como um indicador para medir o sucesso da iteração.
Durante o desenvolvimento o product owner era frequentemente informado sobre o status do desenvolvimento, bem como os especialistas do domínio, entre outros, para prover informações mais detalhadas, para rever designs de interface de usuário e para testar funcionalidades novas ou que sofreram alteração.
Cada release era testado pelo cliente, com base nos testes de homologação definidos previamente. No caso do cliente confirmar que o release estava mais de 85% “pronto”, o projeto continuaria, o release tinha de ser pago e o planejamento do próximo release começaria. Trabalho restante seria incluído no próximo release. Isso levaria a uma assinatura do protocolo de homologação de release, um documento necessário para a administração financeira do cliente. Caso contrário, a fatura não poderia ser paga.
Graças à grande cooperação, o nível de aceitação ultrapassava de longe os 85% em todos os releases.
Dentro do arcabouço contratual a data de início e de entrega de cada release foram definidas e isso obrigou todos os participantes do projeto a cumpri-las. O deslocamento de um prazo não seria permitido. O orçamento para cada release também tinha sido definido (tanto o orçamento alvo, quanto o máximo). A única parte variável era o alcance do release, ou seja, quais funcionalidades exatamente seriam materializadas.
Como o contrato suportava o projeto na realidade
Quando o cliente nos chamou para a RFP, não nos sentimos nem um pouco confortáveis com o projeto. Era de muito alto risco. Graças a esse processo de contratação o projeto se tornou gerenciável. Na verdade, o grande projeto foi dividido em dez projetos menores, que foram (re)contratados toda vez. A vantagem desse processo foi que cada stakeholder se encontraram entre si frequentemente para discutir o status do projeto e, se necessário, para ajustar a abordagem. A satisfação do cliente foi medida continuamente. Isso tornou o processo um pouco mais burocrático, mas muito mais previsível. O risco do projeto foi dramaticamente reduzido para os dois lados.
Todas essas vantagens também foram notadas pelo cliente. Eles perceberam que necessitavam de uma forma ágil de trabalho para alcançar o objetivo e prevenir burocracia quando quisessem introduzir mudanças durante o processo de desenvolvimento. Esse contrato fornecia os documentos essenciais para gerenciar seus processos administrativos, enquanto resguardava o desenvolvimento ágil do projeto.
O arcabouço jurídico permaneceu inalterado durante o projeto. Pequenos ajustes foram feitos em diferentes documentos usados durante o processo para torná-los melhor tanto para o cliente como para as equipes de desenvolvimento.
O contrato dava direções claras ao projeto e definia muito bem o campo de jogo. Baseado no contrato pudemos forçar o product owner a fornecer material ao projeto em tempo hábil, os estimulamos a aparecer com os critérios de aceite em tempo hábil, etc. Frequentemente tivemos que mutuamente relembrar as obrigações do contrato, mas apenas para deixar toda a equipe focada em entregar o escopo do projeto no prazo e dentro do custo aprovado.
O contrato nos protegia para sermos pagos também pelo trabalho realizado. O contrato claramente definia quando as partes do projeto deveriam ser pagas e na maioria dos casos o cliente cumpriu com essas obrigações de acordo com o planejado.
Internamente decidimos incluir o nível de satisfação do cliente nas recompensas individuais de algumas pessoas chave da equipe de desenvolvimento. Aparentemente isso foi bastante estimulante.
Flexibilidade com custos permanentemente sob controle – é possível?
A interação frequente entre ambos os lados e o teste regular de novos elementos do sistema genuinamente apóiam em caso de introdução de mudanças no escopo inicial de requisitos. Isso geralmente não é possível quando o projeto é gerenciado usando métodos tradicionais – cada mudança leva a um aumento do custo global ou a longas discussões entre os dois lados sobre se um determinado requisito foi já bem definido e nasce a partir da documentação inicial.
Saber que durante o desenvolvimento as idéias sobre o sistema ideal mudariam (e elas sempre mudam!), permitiu ao cliente ajustar tanto o âmbito e as prioridades dos releases/iterações. Enquanto ela fosse “orçamentalmente neutra” não haveria problema. Devido as novas perspectivas durante o desenvolvimento do projeto, inúmeros novos pedidos levaram a um aumento do escopo e do orçamento. Felizmente, os prazos ainda não precisaram ser ajustados. As equipes de desenvolvimento lidaram com isso adicionando mais recursos quando necessário. Isso possibilitou que o cliente explorasse de forma empírica qual funcionalidade acrescentaria mais valor ao negócio. Foi possível que eles afinassem a plataforma às suas reais necessidades.
Uma solução bem-ajustada no prazo
Graças à abordagem escolhida pudemos mostrar os resultados iniciais de nosso trabalho – um painel de usuário totalmente funcional – já depois da primeira iteração (duas semanas). Depois de dois meses, começamos a implantar a primeira parte do sistema e os usuários começaram a inserir dados de produção nele. Nesse período o acordo formal ainda não havia sido assinado.
Para o cliente essa forma de trabalho permitiu que eles utilizassem partes do sistema em um estágio muito inicial, ao invés de esperar pelo primeiro prazo planejado. Para seu planejamento de negócio isso trouxe um grande alívio. Eles imediatamente puderam começar a afinar o sistema baseado em experiências reais. Para eles, todo o processo de negócio era muito novo e eles não sabiam muito bem o que esperar.
A cada release novos participantes (do lado do cliente) foram introduzidos ao projeto. Representantes dos usuários finais estavam validando o sistema e forneciam feedback útil, o que permitiu à equipe de desenvolvimento aperfeiçoar o sistema e re-priorizar a implementação de algumas funcionalidades.
Essa abordagem resultou não só em um sistema funcional e estável, mas no bem otimizado, entregando o maior valor de negócio possível.
Graças à entrega iterativa, o sistema foi testado com frequência. A quantidade de problemas e de bugs potenciais foi consideravelmente reduzida por meio de testes automatizados e permitiu que a equipe teste a compatibilidade com versões anteriores.
Cada iteração terminava com a execução de testes automatizados que cobrem as versões anteriores do sistema – para se certificar de que toda nova versão não quebraria o conjunto existente de funcionalidades. Além disso foram criados novos testes automatizados para cobrir novos recursos e funcionalidades nos testes também. Adicionalmente os usuários finais estavam testando cada iteração.
Isso fez com que o aceite do sistema completo se torne uma formalidade.
Dicas para contratação ágil
Dependendo do tipo de cooperação, um contrato “burocrático” pode ser solicitado pelo cliente. Acreditamos que este não precisa bloquear uma cooperação ágil. Aproveite o tempo para chegar a um entendimento mútuo sobre as necessidades e demandas, alcance exato do projeto, abordagem de trabalho, etc. Defina as necessidades, sob a forma de estórias de usuários, porque isso estimula a todos para descrevê-las de uma forma mais compreensível do que as descrições funcionais normais.
Pode dar algum trabalho para convencer representantes dos clientes que estão apenas um pouco envolvidos no projeto. Não os “ataque”, é necessário perceber que eles podem não compreender totalmente o que significa uma abordagem ágil. Em geral, eles querem sentir que estão no controle e será necessário explicar como eles podem controlar um projeto ágil também.
Passo a passo, ao trabalhar juntos a confiança mútua crescerá e ambas as partes lucrarão com ela.
Em conjunto com o cliente, permitimos que um pouco de burocracia fizesse parte de nosso projeto ágil. Conseguimos limitá-la à papelada que o gerente de projetos conseguisse manipular. Ela suportava a governança do projeto de uma forma mais tradicional, uma forma que a parte interna da empresa do nosso cliente precisava. As equipes de desenvolvimento nunca foram incomodadas, eles desenvolveram a solução segundo o método Scrum. No final quase todo o orçamento teve que ser consumido, o que, para ser honesto, não nos surpreendeu. Já esperávamos por isso. Um significativo orçamento adicional para novos desenvolvimentos e para um acordo de manutenção de longo prazo, fez esse investimento do nosso lado mais que valer à pena. Nosso cliente ficou realmente feliz por ter uma solução funcionando muito bem ajustada no prazo e no custo aprovado.
Com base no projeto descrito, concluímos que é possível desenvolver um grande projeto de uma maneira ágil ao quebra-lo em pedaços menores. Levou algum tempo para definir esses pedaços e preparar um contrato equivalente, mas valeu à pena. Ao passar uma significativa quantidade de tempo juntos no início do projeto, compreendemos muito bem os desejos e as necessidades do outro. Esta compreensão mútua cresceu e se tornou confiança mútua quando percebemos o quão bem a cooperação acontecia, graças ao tempo inicial investido.
Agora podemos concluir que Mandela estava certo.
Fonte: InfoQ
Categorias Gestão, Informática, Processos e Práticas, Projetos	Tags Adoção de Agile, Agile, Agile nas empresas, Análise de Negócios, Clientes e Requisitos, Colaboração, Contratos e Negociação, Cultura e Métodos, Estudos de Caso, Feedback, Gerenciamento de projetos, Histórias de Usuários, Iterações, Melhoria Contínua, Orçamentos, Outsourcing, Técnicas Ágeis, Trabalho em Equipe	
ter nov
14th
2017
0	
IntSoft Consultoria
Os 10 Mandamentos do Programador de Computadores
No início, tudo era o Caos, depois, veio o Big Bang, as galáxias, a sopa cósmica, a Pangea, o ornitorrinco e toda aquela história que se resume nos “Alienígenas do Passado”. Vamos entender o que isso tem a ver com o Profissional de TI.
Para organizar toda essa ‘bagunça’, Deus entregou a Moisés a “Tábua dos 10 Mandamentos”. Viu que tinha que alterar certas coisas e que o Homem não estava mais disposto a caminhar 40 anos no deserto para uma nova reunião de atualização.
Então, para facilitar a comunicação, liberou o conhecimento da Informática para um seleto grupo de seres humanos, mas esses criaram o wi-fi, o chat e o Facebook – e tudo voltou novamente ao Caos.
Como lição, Deus lançou àquele grupo, e à todos os que ousaram escolher ser um Profissional de TI, os 10 mandamentos (ou 10 grandes pragas):
1. Sobre teu físico e aparência
Tua barriguinha crescerá e poderás usar como apoio para o mouse, além de ser o espaço ideal para a caneca de café e a latinha de Coca-Cola. Tuas 2 únicas camisetas serão a do Homer Simpson e a do Sheldon Cooper e terão formato côncavo. Ostentarás cabelos grisalhos, ou uma “careca cabeluda” – se tiveres sorte e a genética te ajudar.
2. Sobre a tua alimentação
Refeições decentes farão parte de tuas doces lembranças e os aplicativos mais utilizados serão os de pedido de fast food e o da farmácia – para o sal de fruta.
3. Sobre teus relacionamentos
Não os terás. Se tiveres sorte, terás uma família. Se tiveres tempo para fazer filhos, ficarás na dúvida sobre qual nome escolher: Mainframe, Control C, Control V, Wi-Fi, Hashtag, Google, Amazon, Adobe Font Folio ou Cloud – e ainda chamarás todos de ‘download’ – para facilitar.
4. Sobre teu julgamento
Primeiro, subestimarás o conhecimento de cada usuário, depois, os classificará como: o Usuário Mainframe – ocupa muito espaço; o Usuário Google – diz
que sabe tudo; Usuário Torrent – só compartilha arquivos proibidos com outros usuários; Usuário Servidor – está sempre ocupado.
5. Sobre tua identidade
Perderás o teu nome e o teu título de formação para ser conhecido somente como o “menino (a) do suporte”, menino (a) do computador ou “tio (a) da TI”.
6. Sobre tua empatia
Nunca conseguirás explicar para um
BIOS (Bicho Ignorante Operando o Sistema) que 1 bit não é a mesma coisa que 1 byte; que a pressa será a inimiga da conexão, e que, “quando o programa não está respondendo” não serão os 325.485.284 cliques que resolverão o problema.
7. Sobre tua saúde
Criarás alertas automáticos de medicamentos para controlar os triglicerídeos, colesterol, diminuir os riscos de AVC e de Infarto. As “ites”: bursites, tendinites e gastrites serão apenas alguns itens colecionáveis. A vitamina D será proveniente da luminária sobre sua cabeça ou do aplicativo da farmácia.
8. Sobre tua diversão e descanso
Não terás. Somente passeios em lojas de equipamentos de informática. O leito na clínica de endoscopia será um dos poucos lugares aconchegantes que você lembrará de deitar e dormir “bem” – sem ser atormentado por sonhos com códigos fonte e com pedidos para trocar o cartucho da impressora.
9. Sobre teus desejos
Cobiçarás o processador e a memória damáquina do colega, além de sua cadeira giratória e do porta retrato com o Bill Gates (brincadeira :-)).
10. Sobre tuas paixões
Desenvolverás um amor platônico pela cafeteira e pela máquina de refrigerante (a cafeína não fará mais efeito em teu organismo); irás incorporar o personagem ‘Smeagol’, do Senhor dos Anéis, quando falarem do datacenter ou da Nuvem (Google Gloud, Amazon…) – “my precious”.
Não satisfeito com todas essas “pragas”, ainda terás a crença de que o computador tem vida própria, pois, nem tudo o que fizeres, saberás refazer ou explicar como foi feito. Além do que, deverás estudar e aprender eternamente, já que a melhor solução de hoje, poderá não ser amanhã.
Mas não se apavore! Pois a conclusão de tudo isso, é que ainda assim, amarás o fato de teres escolhido ser um Profissional de TI!
🙂
Categorias 4Geeks, Insólitos	Tags Programador, Trolagem	
qui out
19th
2017
0	
IntSoft Consultoria
Empreendedorismo – Como tudo começou?
Fui convidado pelo Sr. Paulo Henrique, aluno de graduação do curso de Desenvolvimento de Sistemas do Instituto Federal do Amazonas – IFAM para uma entrevista sobre como nasceu a IntSof Consultoria, em que circunstâncias ela foi criada, quais as motivações no momento de sua concepção, espero que leiam e curtam um pouquinho da nossa história de empreendedorismo.
Esta entrevista faz parte de uma avaliação normal da disciplina de Empreendedorismo da grade curricular do curso de graduação IFAM.
Vamos a entrevista:
1) Que fatores o influenciaram a se tornar empreendedor?
Ele trabalhava em uma empresa pública especificamente com tecnologia na área fiscal.
2) Que pessoas, empreendedores o inspiraram?
Ninguém o inspirou, mas a necessidade de uma solução de software que ajudassem as empresas na área fiscal deu os devidos motivos para ele empreender.
3) Alguém de sua família era empreendedor?
Seu pai é proprietário de uma padaria.
4) Houve algum evento de “disparo” para iniciar o negócio? (Demissão? Aposentadoria? Outro?)
De fato a oportunidade de criar um programa que atendesse as empresas no sentido ajudá-las nas questões fiscais.
5) Ele criou seu próprio negócio durante a faculdade ou colégio?
Não, começou enquanto trabalhava.
6) Que educação formal ele teve? Foi relevante para o negócio?
Conhecimento técnico na área de desenvolvimento de software e do próprio negócio proposto. Isso foi importantíssimo para o estabelecimento do negócio.
7) Como o empreendedor encontrou a oportunidade?
Muitas empresas estava procurando por um programa que repassasse a informação, embora não existindo e não ficando pronto a curto prazo, mesmo assim ele acreditou, desenvolveu e passou a vender o produto.
8) Como ele avaliou a oportunidade?
Como uma ótima oportunidade para empreender e ganhar dinheiro.
9) Ele tinha um plano de negócios? Se não, ele fez algum tipo de planejamento? Peça que explique.
Não. Ele meio que começou apenas sabendo onde tinha que chegar, mas com o tempo foi se planejando. Hoje tem plano de negócio bem definido.
10) Que experiência de trabalho anterior o empreendedor teve antes de abrir o negócio?
Ele trabalha em uma empresa de tecnologia e tratava de questões específicas do fisco para empresas.
11) Quais são suas forças e fraquezas?
Tem muita vontade de aprender e gosta muito de trabalhar. É otimista.
12) Ele teve sócios?
Ele até tentou chamar alguns colegas para fazerem parte da equipe, porém não conseguiu enganjar a todos. Empreendeu praticamente sozinho.
13) Pergunte sobre os sócios; eles complementam suas habilidades para levar o negócio adiante?
Não.
14) De que recursos (econômicos/financeiros) ele precisou para implementar o negócio?
Ele não precisou de recursos econômicos, mas precisou usar do seu vasto conhecimento em desenvolvimento de software bem como no negócio em que se propunha a solução.
15) Onde e como ele obteve esses recursos?
Estudando e pesquisando durante a sua caminhada acadêmica e profissional.
16) Quando ele obteve o primeiro cliente?
O primeiro cliente foi após seis meses de ter concluído o sistema. Até hoje, após 4 anos continuou conseguindo novos clientes e desenvolvendo novas soluções.
17) Qual foi o momento mais crítico no início ou mesmo depois de sua criação? Como foi superado?
No início, pois mesmo tendo grande conhecimento, a vontade de desistir foi grande, seja por motivos de não ter nenhum cliente como também por apenas ele fazia tudo na empresa: era desenvolvedor, analista, teste, designe etc.
18) Qual foi o momento de maior satisfação?
Quando conseguiu fechar seu primeiro contrato com uma empresa de grande porte e ver o seu sistema funcionando, gerando os resultados esperado para o negócio do cliente e o retorno financeiro.
19) Qual é o lado positivo de ser empreendedor? E o negativo?
O lado positivo é que é bastante prazeroso você começar algo e que sabe que outras pessoas, até mesmo empresas, irão utilizar e em consequência disto ajudá-los de alguma forma. O lado negativo disso tudo é que é uma missão muito cansativa e trabalhosa.
20) Como a carreira de empreendedor afetou sua família?
Afetou de todas as formas, pois elevou seu poder financeiro, pode dar uma melhor moradia e uma melhor qualidade de vida para sua família; Pôde levar a todos a lugares no qual não podia antes por falta dos devidos recursos. Isso é bom demais.
21) Pergunte se ele faria tudo de novo. Em caso positivo, o que faria diferente?
Sim. Nessa nova fase teria um melhor planejamento.
22) Que conselhos ele daria a uma pessoa que deseja se tornar um empreendedor?
Se você tem vontade de montar alguma coisa, vá em frente, lute. O começo será problemático, pois você estará fazendo algo inovador para você e para os outros também. É trabalhoso, mas também é uma grande satisfação pessoal e intelectual.
Por: Paulo Henrique
Categorias 4Geeks, Fazenda, Internet, Intsoft, SEFAZ Amazonas, Tecnologia	Tags Empreendedorismo, Entrevista	
ter out
17th
2017
0	
IntSoft Consultoria
RubyConf 2017 – O maior evento de Ruby da América Latina
O RubyConf chega à sua 11ª edição e acontece nos dias 17 e 18 de novembro, na sede da Fecomercio SP, reunindo cerca de 1.000 participantes, entre desenvolvedores e demais interessados no assunto. Os debates serão acerca do Ruby, Ruby on Rails, Técnicas Ágeis, Devops e outras tecnologias como Elixir, Clojure, Go, Rust e Crystal.
Realizado pela Locaweb, o RubyConf deste ano conta com a parceria inédita da iMasters e da comunidade oficial Guru-SP. “Nosso objetivo é fomentar a troca de conhecimento, debater tendências e desafios do setor, além de estimular o networking entre toda comunidade”, explicou o gerente de marketing institucional da Locaweb e responsável pelo evento, Luis Carlos dos Anjos.
Entre os palestrantes estão importantes nomes do mercado de TI, como Coraline Ada Ehmke, desenvolvedora de código aberto com mais de 20 anos de experiência; José Valim, criador da linguagem de programação Elixir; e Rafael França, líder de engenharia de produção da Shopify. “O RubyConf é um dos mais tradicionais e respeitados eventos para desenvolvedores do mundo. Já trouxe ao Brasil os maiores gurus da linguagem e criou uma comunidade imensa em torno de Ruby, além de manter a excelência na curadoria e conteúdo”, ressalta o sócio-fundador do Grupo iMasters, Tiago Baeta.
As inscrições podem ser feitas pelo site. O valor é divido por lotes, sendo até 1º de novembro, R$300,00; e entre 2 e 16 de novembro R$ 500,00.
Serviço
Quando: 17 e 18 de novembro
Onde: Fecomercio SP – Rua Dr. Plínio Barreto, 285 – Bela Vista, São Paulo – SP
Programação e inscrições pelo site: http://eventos.locaweb.com.br/proximoseventos/rubyconf-2017
Fonte: Imasters
Categorias 4Geeks, Desenvolvimento, Informática, Tecnologia	Tags Devops, Linguagem de Programação, Ruby, Ruby on Rails, RubyConf, Software, Técnicas Ágeis, Tecnologia, Tecnologia da Informação	
sex out
13th
2017
0	
IntSoft Consultoria
Nossa Política de Privacidade
Todas as suas informações pessoais recolhidas, serão usadas para o ajudar a tornar a sua visita no nosso site o mais produtiva e agradável possível.
A garantia da confidencialidade dos dados pessoais dos utilizadores do nosso site é importante para o Intsoft Consultoria.
Todas as informações pessoais relativas a membros, assinantes, clientes ou visitantes que usem o Intsoft Consultoria serão tratadas em concordância com a Lei da Proteção de Dados Pessoais de 26 de outubro de 1998 (Lei n.º 67/98).
A informação pessoal recolhida pode incluir o seu nome, e-mail, número de telefone e/ou telemóvel, morada, data de nascimento e/ou outros.
O uso do Intsoft Consultoria pressupõe a aceitação deste Acordo de privacidade. A equipa do Intsoft Consultoria reserva-se ao direito de alterar este acordo sem aviso prévio. Deste modo, recomendamos que consulte a nossa política de privacidade com regularidade de forma a estar sempre atualizado.
Os anúncios
Tal como outros websites, coletamos e utilizamos informação contida nos anúncios. A informação contida nos anúncios, inclui o seu endereço IP (Internet Protocol), o seu ISP (Internet Service Provider, como o Sapo, Clix, ou outro), o browser que utilizou ao visitar o nosso website (como o Internet Explorer ou o Firefox), o tempo da sua visita e que páginas visitou dentro do nosso website.
Cookie DoubleClick Dart
O Google, como fornecedor de terceiros, utiliza cookies para exibir anúncios no nosso website;
Com o cookie DART, o Google pode exibir anúncios com base nas visitas que o leitor fez a outros websites na Internet;
Os utilizadores podem desativar o cookie DART visitando a Política de privacidade da rede de conteúdo e dos anúncios do Google.
Os Cookies e Web Beacons
Utilizamos cookies para armazenar informação, tais como as suas preferências pessoas quando visita o nosso website. Isto poderá incluir um simples popup, ou uma ligação em vários serviços que providenciamos, tais como fóruns.
Em adição também utilizamos publicidade de terceiros no nosso website para suportar os custos de manutenção. Alguns destes publicitários, poderão utilizar tecnologias como os cookies e/ou web beacons quando publicitam no nosso website, o que fará com que esses publicitários (como o Google através do Google AdSense) também recebam a sua informação pessoal, como o endereço IP, o seu ISP, o seu browser, etc. Esta função é geralmente utilizada para geotargeting (mostrar publicidade de Lisboa apenas aos leitores oriundos de Lisboa por ex.) ou apresentar publicidade direcionada a um tipo de utilizador (como mostrar publicidade de restaurante a um utilizador que visita sites de culinária regularmente, por ex.).
Você detém o poder de desligar os seus cookies, nas opções do seu browser, ou efetuando alterações nas ferramentas de programas Anti-Virus, como o Norton Internet Security. No entanto, isso poderá alterar a forma como interage com o nosso website, ou outros websites. Isso poderá afetar ou não permitir que faça logins em programas, sites ou fóruns da nossa e de outras redes.
Ligações a Sites de terceiros
O Intsoft Consultoria possui ligações para outros sites, os quais, a nosso ver, podem conter informações / ferramentas úteis para os nossos visitantes. A nossa política de privacidade não é aplicada a sites de terceiros, pelo que, caso visite outro site a partir do nosso deverá ler a politica de privacidade do mesmo.