Desenvolvendo para iPhone e iPad – Recursos para aprender

A nossa equipe vem desenvolvendo a versão do uMov.me para plataforma iPhone e iPad. E dentro deste processo, temos um trabalho de nos capacitar de forma constante, permitindo que mais pessoas da equipe possam trabalhar com objective-c, atuando na nossa característica de sermos multidisciplinares e poliglotas no desenvolvimento de software.

Um dos recursos que eu considero bem legais para aprender o “desenvolver objective-c“, fora todos recursos no site da apple, é o material liberado pela Stanford como Creative Commons.  Fora todo o material de slides e exemplos disponíveis, ainda existe uma grande quantidade de material de vídeo disponível no iTunes.

Fora este material todo claro, existem vários outros tutoriais na internet, desde trabalho com views e banco de dados SQLite, que podem ajudar a entender e evoluir aprendizado.

Dentro deste processo, também indico o estudo de ferramentas para apoiar o processo de testes. Uma das que estamos já trabalhando é o OCUnit. Uma outra ferramenta que vale olhar é o Frank, para testes de aceitação dentro do desenvolvimento iPhone. Neste sentido, de estudar testes automatizados, no próprio material da Stanford, existe uma lição sobre o assunto. Lição 19

Contratações em aberto no mês de março!

Estamos a procura de novas pessoas para nossa equipe. Desenvolvedores Web com foco em Java, VRaptor, JQuery e outras coisas legais. E desenvolvedores Mobile com foco em Windows Phone. E com a mentalidade que trabalhamos aqui. 🙂

Já falamos algumas vezes sobre nosso jeito de contratar. Então qualquer dúvida, faça contato conosco!

Uma coisa importante, é que contratamos apenas quando dói, fazendo referência ao livro rework. Então saiba que você está entrando no momento certo e que será valorizado e apoiado por todos da equipe desde o primeiro dia.

Quem escreveu este post? Daniel Wildt é CTO da Trevisan Tecnologia e curte ajudar o time a melhorar continuamente. Site no danielwildt.com e twitter @dwildt.

TTLabs Summit Q2/2011 – Daniel Wildt manda dicas para apresentações

Palestrei sobre o método @Lessig@PresentationZen e @GuyKawasaki, mostrando dicas para melhorarmos nossas apresentações.

Confesso que tive uma ajuda para passar e fixar a mensagem. Foi uma técnica usada pelo @Peleteiro no Agile Weekend 2009, sobre os bebês focas.

Acho que funcionou! 🙂 

Se você mudou sua técnica de apresentação, o que mudou? Mande seu comentário! 

Quem escreveu este post? Daniel Wildt é CTO da Trevisan Tecnologia e curte ajudar o time a melhorar continuamente. Site no danielwildt.com e twitter @dwildt.

A semana de trabalho

Olá, 

Trabalho com iterações semanais. Com isto sei quanto de tempo (horas) tenho disponível (nada de hora extra), sei quanto custa minha equipe, e tendo trabalhado com a equipe faz algum tempo, sabemos quantos pontos vamos conseguir entregar por semana em média. 

Planning game segunda-feira pela manhã, retrospectiva sexta-feira a tarde. Média de 1h30min, 2h para cada cerimônia destas. Standup meetings feitas diariamente. Na segunda-feira ela fica “embedded” na reunião de planejamento. 

Trabalho de análise é evolutivo e parte é feito dentro da iteração. 
Muitas vezes realizamos spikes[1] e paper prototyping[2] para entender melhor uma demanda e poder planejar com mais certeza. 

Conforme uma funcionalidade vai ganhando força e “interesse”, ela vai evoluindo em definição. Dentro do processo 3C [3]. 
Lembrete -> roadmap -> épico -> user story -> testes de aceitação
Tenho que fazer um post sobre isto. Anotei aqui.

Como vocês contratam?

Muitas vezes me perguntam como a gente faz a contratação aqui na empresa. Até fizemos no passado um podcast falando sobre contratações e eu mesmo fiz um post no meu blog sobre vagas de emprego e como elas devem ser legais.

São com certeza pontos importantes, mas não são apenas estes que existem.

No blog do udemy, achei legal um post sobre como atrair, contratar e manter as pessoas que vão trabalhar na sua empresa e nos seus produtos.

Os pontos que mais valorizo quando vou fazer uma contratação são os seguintes:

  1. Sem pressa. Não devemos correr para buscar currículos. Devemos buscar experiências e isto deve aparecer desde o início da conversa. Antes, existia no nosso site um local para a pessoa mandar currículo, links para email de RH, tudo muito “fácil” e direto. Agora o que temos é um espaço para contato. E ele é proposital. Quero saber como a pessoa se apresenta. Quero saber como ela fala sobre o que quer e o que busca. Que redes sociais ou site referencia. Ou ela se limita a querer um local para poder anexar um arquivo “.doc”?
  2. Busque referências. Ao receber um contato, queira saber quem é aquela pessoa. Redes sociais, e aqui é onde o LinkedIn pode ser útil. Você certamente conhece alguém que já trabalhou ou trabalha com a pessoa. Só tem que tomar cuidado para não expor quem está buscando novas oportunidades por aí. Além disto, a questão é buscar referências entre equipe, amigos e conhecidos para novas pessoas na empresa, assim elas já estão vindo com um “voto de confiança”. Hoje em dia só indico quem tenho certeza que pode fazer a diferença. Nem sempre foi assim. 🙂
  3. Seja realista. Você certamente possui um orçamento. Então não tente convencer a pessoa a reduzir os ganhos pela metade. Jogue com a realidade. Assim que surgir a oportunidade, tente entender o que a pessoa espera ganhar, o que ela está buscando. Seja tranquilo em falar sobre a grana que pode oferecer e benefícios que a empresa oferece. Você tem benefícios diretos (vales refeição, plano de saúde) e indiretos (treinamentos internos, dojos, ritmo saudável/sustentável e acesso a internet). Pode parecer loucura, mas deixar claro que não se gosta de horas extras, que se busca produtividade em equipe, e que a pessoa pode acessar a internet de vez em quando, ainda são exceções nas empresas de hoje.
  4. Transpareça sua cultura. Deixe claro quem é seu time e a identidade que se tem. No que acreditam. Já tivemos casos aqui onde a pessoa agradeceu o convite para participar do processo de seleção, mas ela sentiu que não era um lugar confortável para trabalhar. Ela buscava uma hierarquia mais estruturada (somos flat até onde é possível), ou questões de crescimento, nome do cargo, necessidade de ter alguém cobrando suas tarefas (aqui buscamos equipes que se auto-organizam e auto-gerenciam).
  5. Queira a atitude da sua equipe. Mesmo que o candidato em questão seja um técnico excelente, com todas certificações e participações em eventos que podem ser um sonho, será que esta pessoa compartilha da atitude da sua equipe? Você não quer um herói. Ou quer? Pelo menos eu busco sempre alguém que vai somar na equipe. Que vai entrar para ensinar e aprender. Que tem humildade para perguntar e para ensinar quantas vezes tiver que ensinar. Isto é importante para questões de pareamento e transferência de conhecimento.
  6. Compartilhe a decisão. Eu muitas vezes tomava a decisão de contratação sozinho. Até tinha equipe participando das entrevistas, mas no final eu decidia se entrava ou não. E quando a pessoa “falhava” dentro da equipe, a culpa era minha. Então acabei diluindo a decisão deste processo, me tornando inútil nele na verdade e sendo apenas um facilitador. Hoje nas entrevistas temos de 3 a 7 pessoas participando por sessão de entrevista. O objetivo é a pessoa sendo entrevistada conhecer quem serão seus pares. E da mesma forma a equipe poder questionar e assim entender se o candidato é o que se busca ou não.
  7. Teste tecnicamente e mentalmente. Você deve testar tecnicamente de alguma forma. A gente busca mandar algum problema que seria trabalhado em um Coding Dojo, para permitir que a pessoa teste e mostre skills com Unit Testing e possivelmente Test First (Test Driven Development) com alguma linguagem de nosso interesse. Normalmente as contratações tem base em Java, mas queremos pessoas com interesses em outras linguagens, exemplo Ruby, C# e Objective-c. Fora isto, buscamos testar como a pessoa escreve, e como ela estrutura seu pensamento. Como ela modela testes. Temos um questionário para isto, onde validamos conhecimento e comportamento em determinadas situações. Exemplo para relatar um defeito, relatar uma nova funcionalidade, e por aí vai.

E como funcionam nossas rodadas de entrevista?

  1. Entrevista inicial + expectativa de $$$. Aqui se a expectativa da pessoa está fora do que podemos pagar, já alinhamos e encerramos o processo.
  2. Questionário não técnico. Validar português e questões de escrita.
  3. Teste de código, usando problema de programação.
  4. Pareamento. O “pareamento” é normalmente usado quando a pessoa está desempregada, de férias ou possui alguma disponibilidade. O objetivo é que ela viva o nosso ambiente por algumas horas durante 1 ou 2 dias, para sentir a equipe mais de perto, participar de uma reunião diária ou de um coding dojo e assim poder conhecer melhor a equipe, ambiente, empresa, e por aí vai.
  5. Nova entrevista + papo sobre $$$. Se chegou até aqui o objetivo é fechar. 🙂

Era isto. Queria compartilhar um pouco como é o nosso processo e pontos que acreditamos. E vocês, como vocês contratam?

Quem escreveu este post? Daniel Wildt é CTO da Trevisan Tecnologia e curte ajudar o time a melhorar continuamente. Site no danielwildt.com e twitter @dwildt.

É para complicar ou simplificar?

Mais e mais o que se vê estar ocorrendo é que as pessoas querem soluções realmente simples e integradas para funcionar. O que quer dizer isto? O que o mercado está buscando ou dizendo?

  • serviços simples
  • melhor “user experience”
  • poucos clicks para gerar algum tipo de ação, objetividade, foco nas tarefas
  • mobilidade 

Na cio.com saiu um artigo sobre o fato dos cargos CxOs e gerentes de grandes empresas estarem “criando problemas” nas suas organizações querendo soluções mais simples que os grandes sistemas integrados com telas complexas e muitos processos. Eles buscam por mais mobilidade e soluções que sejam diretas, que atendam as suas necessidades.

Da mesma forma temos cada vez mais acessos a informações através de celulares e smartphones, aplicativos para os mais diversos fins, e pessoas buscando mobilidade e autonomia. 

Pequenos aplicativos, pequenas tarefas, poucos clicks, e portabilidade? O passo é poder mover 🙂 isto para o mercado corporativo e poder quebrar paradigmas

Startup Dojo? O que?

Um dojo de programação, Coding Dojo é um conceito usado para se praticar programação, através de problemas de lógica que ajudem a exercitar princípios como automação de testes, desenvolvimento orientado a objetos, padrões de projetos, enfim, tudo que possa nos ajudar a ter código limpo. 

Um StartupDojo tem o mesmo fim do caminho da prática, mas pensando em desenvolvimento de produtos e ideias que “alguém tem”. Uma diferença do Codign Dojo é que o “problema” normalmente vai continuar de uma edição para a outra. 

O que se busca no StartupDojo é aprender e entender o próximo experimento a ser feito, para poder validar um modelo de negócios. 

Aqui em Porto Alegre, eu (@dwildt) organizei um StartupDojo e começamos a fazer também dentro da Trevisan Tecnologia. Isto vai ajudar cada vez mais nossa equipe a “ter mais awareness” (seria algo como “ficar mais ligado”) sobre os produtos que desenvolvemos e que vamos ainda desenvolver. E saber que existem métodos diferentes para exercitar e evoluir modelos de negócios. 

Links relacionados da história: 

 

TTLabs lançado, e já faz a primeira edição do TTLabsSummit!

Inicia oficialmente no dia 29 de abril de 2011 o TTLabs (@ttecnologialabs)! Este será o canal da Trevisan Tecnologia para divulgar ações relacionadas a código livre, dicas, palestras, informações sobre nossos produtos que podem ser de utilidade para a comunidade, e por aí vai. 

Hoje mesmo realizamos a primeira edição #TTLabsSummit, uma reunião das pessoas da Trevisan Tecnologia para palestrar sobre algum assunto de seu interesse. Tivemos 5 palestras.  

Sobre as palestras que foram realizadas nesta edição?

@dwildt – Daniel Wildt falou do método @Lessig, @PresentationZen e @GuyKawasaki para apresentações. Aqui diversas técnicas que podem ser úteis para a galera que monta apresentações usando slides. E nesta apresentação Daniel teve ajuda para passar a mensagem. Foi uma técnica usada pelo @Peleteiro no Agile Weekend 2009, sobre os bebês focas. Acho que funcionou! 🙂 

@RafaelHelm – Rafael Helm tratou de “Carreira Profissional – Quão longa é esta estrada?” Apresentação estilo #AssimNoEsporteComoNaVida, Rafael referenciou Stephen Long, no livro Level Six Performance.

@Guilhermelias – Guilherme Elias puxou no assunto produtividade pessoal, e falou de Getting Things Done (gtd), referenciando David Allen

@lcborges80 – Luciano Borges falou sobre OAuth2 e a experiência dele fazendo este processo com a aplicação FourSquare

@eschena – Emerson Schenatto falou sobre Balanced Scorecard (bsc) com o tema: “Como o uso de indicadores e Balanced Scorecard (BSC) gera maior alinhamento nas ações da organização? Criando a cultura e mostrando a importância do uso dos indicadores”.  

Todas elas estarão disponíveis durante as próximas semanas, aguarde atualizações por aqui e pelo nosso canal do Twitter.