O “Modelo de Responsabilidade” tenta descrever como nós, humanos,  geralmente nos comportamos face aos problemas que encontramos diariamente. Acho que este modelo descreve algo que nasce conosco, as atitudes e sentimentos que foram cultivados durante milhões de anos de evolução.

Ora vamos lá ao modelo…

Quando encontramos um problema, começamos com a “Negação“:
Negação: O código compila no meu computador, não há problema nenhum.

Depois da negação, passamos para a fase de “Atirar com as culpas“:
“Atirar com as culpas“: O problema é da especificação Java que deveria permitir fazer isso…

E continuamos para a fase seguinte, a “justificação“:
“Justificação“: Ah, pensava que era possível fazer isto, uma vez vi isso no código do António…

A “Vergonha” é a fase que se segue, onde muitos vêm a oportunidade de desistir:
“Vergonha“: Aii, sou mesmo mau programador, não nasci para isto…. (Boa oportunidade para “Desistir“: Vou mudar para manager )

Depois destas fases, se não desistirmos, temos dois caminhos que podemos seguir: A “Obrigação” ou a “Responsabilização“:

“Obrigação” : Ok, já percebi que tenho de corrigir o erro… Diz-me o que posso fazer para o corrigir.

“Responsabilização“: Não vou ficar aqui à espera que alguém corrija este erro, vou ler a especificação Java para ver como posso resolver o problema e vou corrigir este erro ainda hoje.

Ficam alguns links com mais sobre o assunto;

http://www.selfishprogramming.com/2008/09/26/challenge-your-personal-agility/

http://www.christopheravery.com/responsibility-process

The reason for the fall of empires and civilizations throughout history is … because their societies got too complex and gridlocked to be managed.

Isn’t the same with Software?

“Survival of the Simplest“

“An effective team has to be able to respond quickly[...] And for that, we need a forum for robust dialogue.

A formally constituted team comes from the desire to work collaboratively [...] There is a shared commitment to goals that has the support of individual team members, and in turn supports them.

An effective team [...] contrasts with a more common hierarchical approach to business goals, “the command-and-control approach.”

The effective team are [...] The Magnificent Seven rather than The Good, The Bad and The Ugly.

To have and effective teams [...]Businesses need to shift from individual bonuses to team-based bonuses, to flatten out their reporting structure.

What may not be a Team? [...] A committee is a weak variant of a team [...] A team [...] is the opposite of a committee in that it has a unifying purpose and values to which all members ascribe, despite their position within the organization.

How to build a team? [...] Peer mentoring is a team learning system that lets people teach each other [...] Workshops have their place in leadership development, but most corporations don’t have a significant way to transfer that knowledge into skills.”

Peer Mentorig [...] challenges people to take ownership of their careers. As long as no direct reporting is involved, it works magically.

How a effective team looks like?[...] include enough people, and a good cross-section of skills. We call it collective intelligence. The worst thing to do is try to figure out things by yourself.

Ainda no mesmo artigo são sugeridas oito características de uma boa equipa:

EIGHT TEAM MUST-HAVES

1. Must have a meaningful purpose that all members care about.
2. Can’t be too large. Some experts suggest capping at 20. Field cautions against there being too little work for all members.
3. Needs a diverse set of skills appropriate to the goals.
4. Needs to be physically together. Even having some team members on different floors can hurt the team.
5. Succeeds or fails together. No stars or scapegoats.
6. Shares leadership. Of course there is one leader, but he or she should be willing to step aside when another team member’s skills are required.
7. Has strong shared norms and expectations of behaviour. These are soft skills that often need to be taught.
8. Needs time. “You lose advantages if you hurry,” Prof. Field says. “Slow it down for the process to work.”

Artigo original:

http://www.financialpost.com/story.html?id=2258320

joaomrpereira: estou a criar conflitos http://bit.ly/2AvQOU

joaomrpereira:como é que vêem o conflito na colaboração? de que maneira o conflito contribui, positivamente ou negativamente, para a colaboração?

E um artigo sobre Aikido : http://www.urbansim.org/pub/Research/ResearchPapers/Aikido%20and%20Software%20Engineering%20final%20accepted.pdf

Acho que o conflito é um elemento essencial à colaboração, por isso não vale a pena tentar resolver conflitos através de pequenas cedências, poderes, ataques pessoais, ignorando-os ou suavizando-os.

Apenas introduzi uma ou duas alterações ao meu artigo de 21 de Dezembro de 2007 onde já falava no “novo papel” dos CIOs ou directores de informática ou como lhe preferirem chamar.

Mudança, TI e negócio

A mudança está hoje indiscutivelmente associada ao mercado global onde nos encontramos e também estará mais no futuro. Estar na liderança significa estar atento às ameaças e oportunidades que essas mudanças trazem. Aproveitar as oportunidades, combater as ameaças e manter a visão é a fórmula para o sucesso. No entanto, estas mudanças significam alterações na forma como as empresas fazem negócio e inevitavelmente alterações estruturais dentro da empresa.

Inegavelmente, as TI (Tecnologias de Informação hoje são um elemento indissociável ás operações da empresa, por isso as TI terão de acompanhar essas alterações e evoluir de modo a criar ou melhorar as capacidades operacionais necessárias para os objectivos da empresa, cada vez mais mutáveis.

Infelizmente muitas empresas ignoram esta associação e tendem a esquecer as TI por completo, resultando num erro que as levam a não conseguir agarrar as oportunidades e falhar os seus objectivos.

Para lutar neste mercado agressivo é imperativo investir em estratégias de TI iterativas que são ajustadas com frequência suficiente para manterem as capacidades operacionais da empresa de acordo com os objectivos de negócio. Apenas assim será conquistada e perpetuada a liderança.

Infelizmente em Portugal, muitas PME, e mesmo grandes empresas, não tem a mesma visão relativamente ás TI. Conheço casos em que são contratados “responsáveis pela informática” que o único papel é fazer manutenção de sistemas. Um computador avaria, uma impressora que não imprime, um sistema operativo que está lento, etc etc. São estas as tarefas rotineiras e quase desprezáveis dos “responsáveis pela informática“. O problema é que a empresa não consegue perceber que esses “responsáveis pela informática” são, muitas vezes, ignorantes no que diz respeito ao negócio da empresa e que essas pessoas apenas estão a trazer prejuízo à  empresa.

Pergunte ainda hoje ao seu “responsável pela informática” o que deve se feito para atingir o objectivo de negócio X. Pergunte-lhe de que forma ele está a contribuir para a visão da empresa. Peça-lhe para quantificar o retorno do seu ultimo investimento em sistemas de informação.

Pergunte-lhe quais são as estratégias dele para os próximo três meses e de que forma essas estratégias estão alinhadas com os objectivos de negócio. Pergunte-lhe, ainda, que capacidades operacionais são necessárias para a empresa atingir os objectivos, e quais os sistemas de informação estão projectados para conseguir essas capacidades operacionais. Existem tantas perguntas que poucos “responsáveis pela informática” conseguem responder simplesmente porque eles não entendem o negócio e, mais grave, não entendem o papel deles.

Não contrate “responsáveis pela informática“. Devem ser criadas estruturas de gestão dentro da empresa e criar o papel de CIO. Um CIO deve entender o negócio da empresa tão bem como o responsável máximo da empresa. Deve conhecer o panorama do mercado, incluindo concorrência, oportunidades, ameaças, factores geográficos, sociais, económicos e políticos que influenciam o negócio, fornecedores e clientes, etc. etc. Peça-lhe para criar estratégias e executar planos para melhorar as capacidade operacionais e consequentemente ajudar a atingir os objectivos da empresa. Dê-lhe autonomia e condições para colocar a empresa na liderança.

As TI transformam industrias e mercados. Tenha as TI do seu lado e não contra si.

Artigo originalmente publicado em 2 de Dezembro de 2007. Será que o diz o estudo “A Nova Voz do CIO” é novidade para alguém?

Link do meu artigo original: http://old.jpereira.eu/mudanca-ti-e-negocio.html

Intranets today reflect one view point – that of management – and are not platforms for dissent or debate.  After Blogs, wikis and other voice-giving technologies appear, this will change. However, the question remains: will the change be welcomed?”

[...]

These tools reduce management’s ability to exert unilateral control and will be used to express some level of negativity.

Por exemplo, será que o Management está disposto a reportar a toda a organização que o projecto XPTO está atrasado e estão a “cortar” na qualidade para o entregar a tempo?

Antes de utilizar tecnologias “Enterprise 2.0″, como wikis ou blogs, acho que existe um um princípio fundamental que deveria ser seguido pelas pessoas na organização: “Transparência”. Quando existem múltiplos canais, múltiplas plataformas e múltiplos níveis de “reporting” é fácil comunicar progresso “falso” nos projectos. Não acho que este falso reporting seja motivado pela falta de desejo nas pessoas em fazerem um bom trabalho, mas sim por outros factores.

E também, o que me diriam se eu fosse o vosso Management e vos “recomendasse” a utilização de um wiki e depois nunca o utilizasse ou ignorasse o que por lá está escrito?

Para não confundir a inovação do século XX com a inovação do sec XXI, Umair Haque decidiu chamar  “Awesomeness” a esta inovação do século XXI, o que em português se poderia traduzir por qualquer coisa com o velho “fixe”, do século XX .

Umair Haque dá o exemplo de como Steve Jobs revolucionou o mercado com o iPod e o iPhone, p.exemplo.

O “Awesomeness Manifesto“, como se chama, termina com o sumário do que é afinal a inovação do século XXI, de acordo com a visão de Umair Haque :

Let’s summarize. What is awesomeness? Awesomeness happens when thick — real, meaningful — value is created by people who love what they do, added to insanely great stuff, and multiplied by communities who are delighted and inspired because they are authentically better off. That’s a better kind of innovation, built for 21st century economics

Para ver todo o manifesto: http://blogs.harvardbusiness.org/haque/2009/09/is_your_business_innovative_or.html

Você está a pensar em iniciar um novo projecto e necessita de um estudo de viabilidade económica. Depois de uma pesquisa na Internet encontrará os meus posts sobre o assunto:

• Como Seleccionar um project
• Cálculo do indicador VAL
• Cálculo do indicador TIR
• Cálculo Rácio Beneficio/Custo
• Cáculo do Payback Period (Período de Recuperação de Investimento)

Estes posts contêm informação sobre alguns assuntos a considerar durante o estudo e, além dos links úteis, disponibilizo também um modelo em Excel que pode ser adaptado às suas necessidades.

Download da Versão 4 do Modelo Económico

Mas é claro que toda esta informação se pode tornar confusa logo no primeiro post. É por isso que acho que o assunto dos modelos de negócio é pertinente para os estudos de viabilidade.

Entender o modelo de negócio não é só primeiro passo para um estudo de viabilidade, mas é também a base para o sucesso do negócio. Por isso tenha um modelo de negócio simples para nunca se esquecer dele.

Oscar Osterwalder utiliza uma ferramenta visual para este processo que chama “business model canvas”.

O “business model canvas” é composto por quatro pontos relacionados com o financiamento e operação do negócio:

• Actividades Chave – Quais são as principais actividades do negócio?
• Rede de parceiros - Apoia-se numa rede de parceiros? Quem são?
• Recursos – Vai sempre necessitara de recursos. Dinheiro, pessoas, matérias primas, etc. Quais são? Quantos?
• Estrutura de custos – Os recursos não são grátis por isso neles encontra a estrutura de custos do seu negócio. Onde vai gastar o seu dinheiro?

Os quatro pontos anteriores são ligados a mais quatro através da Oferta – O que vai oferecer ao seu mercado? O que propõe aos consumidores?

• Relação com o cliente – Como estabelece contacto e se relaciona com os seus clientes?
• Segmento de mercado – O seu negócio destina-se a um nicho de mercado? Qual?
• Canais de distribuição – Como irá levar os  produtos/serviços até aos seus clientes?
• Fluxos de entrada em caixa – Quanto dinheiro vai gerar com venda dos seus produtos/serviços?

Estes últimos quatro pontos estão relacionados com o mercado dos seus produtos/serviços.

Fica uma apresentação do “business modelo canvas:

@joaomrpereira and @innomgmt are now following each other at Twitter.  @innomgmt has a LinkedIn group that is a community

Working together to dramatically improve Innovation Management effectiveness, to share experiences, and to explore new models and methods.

I’ve found this very interesting and joined. I had the chance to take the survey recommended by Andrew Loveless on the discussion “Discover the Political Temperature in your Organisation.” and I’m now waiting for the detailed results at my email. From the results I have immediately, they seems pretty much accurate.

Of course I will not discuss my results here, as you may understand, but from the first results I have, there’s a lot of good insights to keep.

Take your time to take the survey at http://www.relayconsultants.com/politicalbenchmarksurvey/ and think at least for five minutes per screen. If you find yourself stuck in some of the screens it’s good sign. Take the time to make an retrospective on your last projects and discuss with your colleagues if possible. At the end discuss the results with your organization.

I’ve introduced this book here in Portuguese.

I haven’t read it, but I will, I promise and I hope you, as an agile wannabe, read it too so you will not make anything stupid when planning your releases .

This chapter deals with release management.  What is covered:

• Planning the release and creating the release plan
• Estimating product backlog items
• Determining velocity
• Managing cost
• Dealing with risk
• Tracking and reporting the progress
• Practices for large projects including lookahead planning and pipelining

Have a nive reading.