How to Fix Your Documentation Problems?

Fonte: http://www.payton-consulting.com/fix-documentation-problems/

O que esperar do futuro pós nuvem?

Aqui estão algumas tendências não muito distantes

Ainda hoje, Cloud Computing é vista como uma perturbação da ordem estabelecida. Mas um dia - que não está muito longe - ela vai representar status quo. Como será ele?

Aqui estão algumas tendências que podemos esperar:

1 - Escalas enormes

Todos os sistemas serão projetados para processar quantidades gigantescas de dados. Cada aplicativo será elástico, para responder às mudança de fluxo nas correntes de bytes. Quando sistemas forem desenhados, ninguém perguntará sobre capacidade, porque partirão do pressuposto de que a capacidade poderá ser infinita. Portanto, os esforços de design vão presumir isso, não importa quantos dados uma aplicação possa estar gerenciando ou quantas máquinas virtuais a topologia do programa possa conter, ele deverá ser capaz de expandir para suportar mais. Em essência, podemos presumir que sistemas serão projetados para um mundo da “ilusão da infinita capacidade”.

2 - A Internet das coisas será realidade

O CTO da Cisco previu que, em um futuro próximo, um trilhão de dispositivos estarão ligados à internet. Há muitas pessoas que preveem que estamos entrando na era pós-PC.Significa que além dos aparelhos com os quais os humanos vão interagir da forma tradicional, como os smartphones, tablets, etc, estaremos cercados por um número muito maior de dispositivos de propósito específico, dedicados a execução de determinadas funções, que se comunicarão com programas centralizados rodando na nuvem, e que por sua vez irão interagir com algo que nós,  ou alguém usando nosso proxy, vai achar valioso.

Por exemplo, não vamos precisar olhar para o nosso relógio para saber a nossa pressão sanguínea. O relógio vai medir a pressão e enviá-la para o sistema de monitoramento, que vai gerar um alerta para o profissional de saúde, baseando-se em uma experiência médica e nas especificidades da nossa saúde individual. Usaremos cada vez mais dispositivos como este relógio, equipados com sensores, e ubíquos, a ponto de sequer prestarmos atenção a eles, a menos que haja necessidade.

Não é fácil entender como isso vai acontecer. Mesmo os trabalhadores dessa indústria, que deveriam entender a dinâmica do processo, subestimam constantemente o que vai acontecer. Uma década atrás, em um debate com o CEO de uma empresa de chips análogos que equipava o protótipo de um refrigerador inteligente, ele chegou a afirmar que, no futuro, o refrigerador teria uma interface na qual você poderia fazer sua lista de compras baseado em diferentes níveis de observação dos alimentos armazenados. Duvidei de que que a caixa de leite poderia determinar que estaria com nível baixo e então contatar o refrigerador para adicionar leite à lista. Ele respondeu que essa funcionalidade sairia muito caro, na época, para uma caixa de leite. Uma resposta que levava em conta suas tradicionais suposições sobre custo/funcionalidade para a discussão, em vez de extrapolar a tendência que, efetivamente, hoje se impõe.

Em retrospecto, é claro que ele estava subestimando como as coisas aconteceram. Na verdade, é claro que eu estava subestimando as coisas. Hoje é claro que a caixa de leite vai conversar com o aplicativo da lista de compras in-cloud e essa app iria contatar o mercado selecionado para organizar seu pedido semanal de caixas de leite. É por isso que a internet das coisas vai resultar em “aplicativos” muito além do que podemos imaginar. 

3 - O custo dos componentes de TI cairá vertiginosamente

Não me refiro a chips ou drives de disco. Falo de cada elo da corrente de fornecedores de TI. Sistemas operacionais, middleware, softwares serão muito mais baratos. Se não, eles serão substituídos por programas open source gratuitos.

Por que posso prever tal coisa? É óbvio: se você vai prever a escala antes, os componentes individuais vão baixar de preço. Hoje, escuto muitas pessoas opinando que vendedores de software “não permitiriam” a mudança para a nuvem para reduzir seus preços ou lucratividade. Tenho novidade para os que compartilham essa opinião: Os fornecedores não têm escolha. Se os atuais fornecedores resistirem à tendência, novos participantes com preço amigável irão substituí-los.

Paradoxalmente, os gastos totais em TI aumentarão muito. Em certos setores de cloud computing há muita discussão sobre o Paradoxo de Jevon, que afirma que redução de custos de um bem ou serviço,em vez de reduzir gastos totais, na verdade, os aumenta. O crescimento terá como motor o fato de que as funcionalidades em TI insuflam as ofertas de negócio atuais. Toda nova oferta de negócios contém TI, portanto, o aumento de todas as iniciativas vai aumentar o investimento em TI. A diferença entre essa situação e as circunstâncias atuais é que o setor de TI não será uma função de apoio à função do escritório, mas pré-requisito para lidar com clientes. A Tecnologia da Informação vai atingir seu tão desejado papel de parceira de unidades de negócios.

4 - TI reestruturará a TI

O lado ruim de ser parceiro de negócios está no negócio. O surgimento de novos provedores de nuvem públicas gerou um benchmark de comparação para a oferta de serviços feita epla equipe interna de TI. Não ser capaz de oferecer transparência comparável aos serviços comerciais, facilmente contratados, será o beijo da morte.

Na decisão da estratégia de implementação o custo será um entre muitos fatores, incluindo privacidade, requerimentos como largura e latência de banda para os aplicativos, etc, que podem determinar se o aplicativo é implementado interna ou externamente. A suposição de que a decisão padrão de implementação seja a interna, se tornou uma fantasia. CIOs espertos vão reconhecer que seu papel é gerenciar a infraestrutura, não possuindo equipamentos. Já os menos informados vão ser ultrapassados pelos próprios  usuários. O que já começa a acontecer.

Junto com essa tendência de contratação na cloud direto pelas áreas de negócio, o maior desafio que as organizações de TI encontrarão no caminho para a era pós-cloud é o suporte aos sistemas legados. Eles representam uma enorme habilidade de TI para se alinhar com as demandas de usuários do negócio. No mundo pós-nuvem não será suficiente gerenciar aplicativos legados com o menor gasto possível. Mesmo com esse investimento, esses aplicativos carregam um alto custo de estrutura e manutenção. Custo esse muito mais alto que as ofertas de cloud disponíveis. Nesse cenário, a equipe de TI terá que ser muito mais agressiva e pró-ativa para fazer todas as coisas necessárias. Todo CIO precisa avaliar os sistemas atuais e montaram um plano para reduzir o custo, incluindo entre as opções a migração para um SaaS equivalente ou a terceirização de operações para um provedor mais barato.

5 - PaaS será o local onde estar

Muitas pessoas pensam da computação em nuvem como máquinas virtuais sob demanda. A indústria está se movendo rapidamente para além disso. Os desenvolvedores de aplicativos perdem seu tempo quando têm de contratar arquitetos para implementar escalabilidade e elasticidade. A infraestrutura deve lidar com isso, liberando os desenvolvedores de aplicativos para focar na funcionalidade do negócio, não no encanamento. O caminho para isso é a adoção do modelo de Plataforma-como-serviço (PaaS).

No pós-nuvem o departamento de TI dependerá muito de PaaS, usando uma organização interna ou externa para gerenciar a funcionalidade básica e a infraestrutura. Será talvez a única forma de gerenciá-los da maneira mais eficiente e de baixo custo sem abrir mão de proporcionar um ambiente aumente a produtividade dos desenvolvedores de aplicativos.

6 - Haverá escassez de bons desenvolvedores de aplicativos

O Paradoxo de Jevon significa uma explosão de demanda em TI. Em particular, uma demanda de criadores de aplicativos. Pessoas que saberão como construir ofertas de negócios integrando múltiplos aplicativos em um novo, implementando chamadas para APIs de serviços externos que terão uma demanda muito alta. Mesmo o surgimento do PaaS - paradoxalmente - aumentará a demanda por desenvolvedores de aplicativos.

cio.com.br

5 Common Problems with Scrum adoption

During the recent past, it has been a rat race that many organizations wanted to go the agile way of working, irrespective of their ability to change and work towards being agile. Often, organizations try to adapt to Scrum (since it is one the most popular framework in agile), but fail miserably due to several reasons. Some of the common problems are listed below.

No support from Senior Leadership

Often, senior leaders may be willing to support the transition, but turn negative after they fully understand the effort it takes for an organization to become truly agile. Leadership must be willing to “lead from the front” by providing necessary support and spearheading the organizational change and communication.

Existing Organizational Structures and Hierarchies

Existing structures can hinder successful adoption. The biggest pit fall is the organization leadership tries to tweak Scrum to force-fit into the existing organization structure and hierarchy. Some of the tweaks that are like to happen are;

Managers jumping to role of Scrum Master still using a command and control style of leadership,

Individuals working in silos without a team concept,

Product Owners being pushed into the job without knowing the roles, responsibilities, and time committments.

Scrum Master being unduly influenced by managers.

The existing process overhead in the organization may be too much for the team to carry on every sprint. No one really bothers to simplify the existing processes to the extent that the team starts self-organizing and delivers working software. The teams selectively apply scrum principles and eliminate the ones which are difficult to adapt given the circumstances. The Product owners often don’t have the seniority and decision making power they need to be successful.

Distributed teams

Scrum works well for co-located teams, distributed teams present a different set of challenges. Senior leadership face a stiff resistance in breaking the distributed team culture, since managers do not trust the remote teams completely. In addition, the distributed portion of the team is often under the control of a 3rd party vendor with a completely different management chain.

The biggest challenge with distributed team is that they don’t behave as ONE team. It is very much important that frequent contact among the team members, may be very effective, even though it is electronic. To make scrum adoption successful, it is a prerequisite that organizations must invest in high fidelity communication equipment infrastructure to enable smooth communication between the distributed teams. Added to that, organizations may also understand the necessity of tools for continuous integration, code reviews, unit testing and automation. Scrum may not work well if tools that improve the quality of the product are not in place. The desired results may be disappointing until the necessary tools in place to helps the teams to become distributed teams hyper productive.

Regional Organizational culture

Regional culture always plays a dominating role deciding the Scrum adoption. Asian cultures like India, Vietnam, Thailand, Philippines, China, Japan, Malaysia, and Singapore struggle to adapt Scrum as per Scrum guide. These cultures are particularly inclined towards hierarchy status and titles. When promoting agile methods, which warrant high transparency and honesty, it is very difficult to make the changes in culture necessary. In some Asian cultures the word “Servant Leader” has a negative meaning of lesser social status. Added to the chaos, imposing performance appraisal bell curves also make people to show case their individual heroism than the team work.

Unavailability of human skills

There is a dearth of agile skills in the open job market. Experienced and high functioning product owners, scrum masters, technical leads, and team members are in short supply.  Agile methods also embrace the need for specialized technical skills like test automation, build automation, devops and continuous delivery. These skills are very much in demand in the marketplace, and so every organization is competing to attract people with these skills.

Suggestions to overcome common problems:

Executive management need to understand that, being Agile is not a goal unto itself, Agile should be used as an enabler to accomplish business goals.

Engage enterprise Agile Coaches with significant experience in facilitating the right outcomes. Fully leveraging these coaches will make a huge difference to organizations rather than trying to solve these issues with internal staff.

Executive management need to understand that Agile transformation is a major organizational change and not merely project level coaching. So every support functions in an organization need to support agile transformation.

Lot of executive support and direction may be required for agile adoption, to push the change top down the layers and they have to continuously monitor the progress and remove organizations impediments that surface time-to-time.

The past transformation approaches show that, some organizations take a top-down approach while others take bottom-up, however, the results show that no single approach works perfectly, it largely depends on how organizations absorbs the change within its culture.

There needs to localized strategies made for every country culture, given the regional cultural differences, to make the agile transformation successful, while keeping the end goal same.

Not having the right human skills in an organization will impact the agile transformation significantly. It is important that organizations keep their skilled people on standby, before they start the transformation.

Do not force-fit agile into the existing organization structure and hierarchy, in fact there are many organizations out there, who tweak agile frameworks that fit into their existing structure and hierarchy, which is the biggest pit fall.

http://www.payton-consulting.com/

Agile Team Working Agreements

http://www.payton-consulting.com/

Dez passos para a implantação de projetos de Business Intelligence

É essencial aprender com os erros de outros para que um projeto não falhe.

No passado, as companhias gastavam muito dinheiro com BI, mas nem sempre conseguiam alcançar os resultados pretendidos. Prova disso, as reclamações dos usuários sobre a falta da qualidade dos dados e a dificuldade de utilização dos sistemas e ferramentas de BI, assim como relatórios incompletos ou dados imprecisos que impactam a tomada de decisões. Estas debilidades são causadas por fraquezas funcionais e organizacionais na implementação de projetos de Business Intelligence.

Particularmente para novos projetos de BI, é essencial aprender com os erros de outros para que o projeto não falhe. A Information Builders compilou 10 regras de ouro para a implementação.

1. Definir os requisitos funcionais.

Comparações por indicadores de desempenho (KPI – Key Performance Indicators) são o centro de qualquer aplicação de BI. A equipe do projeto, composta por colaboradores do departamento de TI e de outros departamentos especializados, deve determinar que informação deve ser disponibilizada pelas aplicações de BI, quando é necessário estar disponível e em que formato.

2. Definir os grupos de utilizadores.

A equipe do projeto deve definir quem são os utilizadores da solução de BI. Existem geralmente três grupos de utilizadores: utilizadores gerais de relatórios; os produtores e analistas que avaliam os dados; e finalmente os gestores que decidem os objetivos.

3. Envolver os utilizadores numa fase inicial.

Na fase inicial, o departamento de TI deve criar um protótipo simples da solução. Desta forma, pode ser feita uma revisão para assegurar que os requisitos essenciais serão incluídos desde o início. Na implementação de um projecto de BI, os colaboradores dos departamentos especializados devem sempre ser incluídos paralelamente, uma vez que são esses indivíduos que, no futuro, irão trabalhar com as aplicações. Quando se testar o protótipo, esses colaboradores podem determinar se o projeto segue o escopo.

4. Ter apoio da Gestão.

A equipe do projeto deve ter apoio da gestão. Esta é a única forma de garantir que os objetivos corporativos a curto e longo prazo sejam incorporados. A implementação é monitorizada pela comparação de indicadores de desempenho (KPI) permanentes dos rácios operacionais mais importantes.

5. Identificar os Indicadores de Desempenho (KPI) requeridos.

São necessários valores operativos para a gestão dos processos de uma companhia. A equipe de projecto deve defini-los em conjunto com o departamento especialista. No manuseamento e produção de materiais, por exemplo, indicadores de desempenho tais como “custo do material por cada componente” ou “volume de negócio por colaborador” são variáveis provadas. Isto torna mais fácil determinar se os objetivos foram alcançados ou não.

6. Garantir a integração e qualidade dos dados.

Integração dos dados é um fator decisivo para o sucesso de um projeto de BI. A equipe deve identificar os sistemas operacionais nos quais a informação requerida está disponível e como os dados devem ser acessados. Para informação atualizada, o acesso direto é a melhor opção. Se a qualidade dos dados brutos não for suficiente, isso deverá ser melhorado com as ferramentas de software apropriadas para acessar todas as fontes de dados.

7. Descubra que ferramentas de BI já estão disponíveis na empresa.

Quando um novo projeto é iniciado, é necessário determinar se as ferramentas existentes para os usuários finais devem continuar a ser utilizadas ou se devem ser substituídas completamente. Na maioria dos casos, a padronização num único sistema de BI é preferível para garantir consistência na disponibilização da informação dentro da empresa.

8. Escolher o Software de BI correto.

Com uma Proof-of-Concept (PoC), a equipe de projeto decide o software mais adequado, baseando-se geralmente  em um briefing específico. Este procedimento permite à equipe de projeto garantir com maior grau de certeza de que o software se adequa ao seu negócio.

9. Limitar o tempo de execução do projeto.

Aqui aplica-se a velha regra: “Tudo o que dure mais que seis meses deixa de ser um projeto e passa a ser um problema.” Quando se implementa um novo projeto de BI, os departamentos especializados devem estar centrados e proceder em claros passos definidos. Os subprojetos devem ser desenvolvidos para que os primeiros módulos executáveis e operacionais estejam disponíveis depois de dois ou três meses.

10. Um projeto de BI é um processo constante.

Os requisitos das companhias mudam constantemente e o mesmo se aplica a uma aplicação de BI. Todas as soluções de BI têm de ser continuamente desenvolvidas e otimizadas em uma base permanente. Esta é a única forma que têm de cumprir os requisitos.

“O BI é, antes de tudo, uma tarefa de controle, compras, marketing e vendas. Os departamentos de negócio estão familiarizados com os requisitos individuais em termos de gestão da performance funcional e sabem que parâmetros e dados necessitam para controlar os seus processos de negócio”, afirma Klaus Hofmann zur Linden, Technical Manager Germany da Information Builders em Eschborn. “O departamento de TI deve construir a infra-estrutura para as aplicações de BI e assegurar uma operação de confiança”.

Fonte: CIO