Um bom ponto de partida para falar sobre o que acreditamos e fazemos, é a Pirâmide Lean. Nela estão resumidos os valores e princípios que buscamos aplicar diariamente em nossas atividades na OnCast.

Olhando para a pirâmide podemos constatar que não é uma tarefa fácil tornar realidade tantos conceitos e ainda mais de forma global partindo do setor estratégico do topo da pirâmide, passando pelo domínio de processos e finalizando pela base de sustentação que é a engenharia.

Apesar de não ser trivial, é fundamental que os valores e princípios sejam sim entendidos, e aplicados por todos, sem exceção na organização. Não há possibilidade de colaboração se não houver engajamento entre as equipes e setores da empresa.

Eu diria que esse é o diferencial que enxerguei logo que comecei meu trabalho na OnCast, pois apesar das pessoas terem conhecimentos e estilos de vida diversificados todas compartilhavam muitos dos princípios e valores presentes no manifesto ágil e nos conceitos do Lean.

É desta forma que vejo que conseguimos ter um ambiente de aprendizado e melhoria contínua, onde todos colaboram de verdade para o crescimento e aprimoramento dos demais. Exemplos práticos disso não faltam.

Na área de engenharia, por exemplo, automatização de testes é uma prática difundida no dia-a-dia, porque todos acreditam que desta forma a entrega terá mais qualidade e segurança. Testes automatizados praticamente requerem um ambiente de integração contínua, o que torna muito facilitada a tarefa de automatização de deploy, e uma cultura de continuous delivery. Estas boas práticas não fazem muito sentido se aplicadas de maneira superficial, o verdadeiro valor delas se percebe quando em conjunto.

De nada adianta ter uma base de engenharia com ótima cobertura de testes e ambientes automatizados se o produto entregue não atende as necessidades dos usuários que irão utilizá-lo. É neste ponto que a constante análise do valor de negócio do que está sendo desenvolvido deve ser avaliada. Tarefa essa que está representada no centro da pirâmide Lean.

Requisitos que não agregam valor ou que podem ser adiados, são alguns dos principais pontos que vejo as equipes avaliando a todo momento na OnCast.

Discussões como estas ocorrem nas mesas de trabalho entre a equipe, na cozinha da empresa onde pessoas de outras equipes acabam se envolvendo, ou até mesmo sentados nos puffs do OnCastLabs.

Esse ambiente de aprendizagem contínua só é possível pois a cultura está espalhada por todos os pontos da organização, o que permite o crescimento de todos como profissionais e como pessoas. Não tenho receio de confirmar que, conseguimos sim, aplicar muitos dos conceitos das metodologias ágeis que descrevemos, e se ainda falhamos em muitos deles, a própria cultura intrínseca dos princípios e valores comentados aqui nos ajudarão a sanar esse déficit.

Gostava bastante de ser sysadmin, e achava que continuaria para sempre(!), entretanto quando terminei a faculdade de ciência da computação, decidi mudar. De área de atuação e de cidade.

Era hora de aplicar os conhecimentos de programação em C, C++, Java e Python adquiridos durante a faculdade. Mal sabia eu que tinha muito o que aprender.

Comecei então a procurar por empresas de desenvolvimento de software em Florianópolis, lugar que me interessava desde os tempos que vinha passar as férias. Trabalhar e ainda poder ir a praia, por que não? Só iria descobrir o trânsito alguns meses depois!

Encontrei várias empresas, descobri inclusive que o setor de TI em Florianópolis era maior que o de turismo e construção civil juntos.

Dentre as empresas que encontrei, estava a OnCast que me chamou a atenção pois mostrava ter uma abordagem diferente, moderna e com uma cultura que eu gostaria de absorver e poder contribuir.

Parti então para o envio do curriculum, e algumas semanas depois o RH retornou com um assessment para fazer e entregar. Naquele momento confirmei minha impressão inicial, de que era realmente uma empresa com abordagem diferente, pois foram logo para o show me the code! E os requisitos citavam a todo momento o fator qualidade. Dava cada vez mais vontade de trabalhar lá.

Assessment enviado, e a resposta do RH alguns dias depois dizia que eu não havia sido aprovado naquele momento, e um feedback logo abaixo que mais uma vez confirmava minhas expectativas positivas.

No feedback continha tanto pontos positivos quanto negativos. Foi incrível como naquele momento aquela avaliação me motivou a melhorar meu código e as tecnologias que eu poderia aprender.

O feedback dizia, entre outras coisas, que eu poderia ter utilizado um framework de testes(?) que poderia ser integrado ao build por uma ferramenta de integração contínua(?).

Eram tantas as keywords desconhecidas que levei um susto! Passado o susto, percebi que tinha muito o que estudar e praticar para ser um Engenheiro de Software como descrevia a vaga.

Logo em seguida participei de mais alguns processos seletivos em outras empresas e em uma delas fui aprovado. Lá tive minha primeira oportunidade de trabalhar como desenvolvedor de software.

Entretanto muitas das keywords do assessment não apareceram, e percebi que precisava aprendê-las por conta própria. Confesso que não foi um grande sacrifício pois foram assuntos que me interessaram desde o início, ai ficou fácil!

Um assunto levou à outro, e durante cerca de um ano me aprimorei bastante. Era hora de voltar a fazer o processo de seleção da OnCast novamente.

Enviei o curriculum novamente e algumas semanas depois recebi a resposta, realizei o assessment e desta vez passei para o próximo passo! Ir até a OnCast.

Cheguei lá esperando por uma entrevista, mas para mim foi mais uma conversa, ou discussão técnica. Na sala de reuniões estavam eu e mais três pessoas, cada um falou um pouco, e em seguida um deles disse: vamos fazer um review do seu código? Preciso relatar o momento de tensão?

Tive que defender cada linha de código com argumentação das decisões que tomei em cada caso. Muitas delas não consegui sustentar, realmente minha abordagem não era a melhor.

Terminado o review me convidaram para conhecer o OnCastLabs, quase não acreditei que pudesse ser verdade, no post de inauguração do OnCastLabs tem mais detalhes, tirem suas próprias conclusões!

Saí dali naquele dia com a certeza que aquela primeira impressão de 1 ano atrás era verdade e que eu queria fazer parte daquele time. Hoje estou na OnCast a um ano e meio e tenho certeza que evolui muito como profissional. Em outro post conto como tem sido o dia a dia por aqui!

As variáveis não tinham que ser bem nomeadas, os métodos não tinham que ser pequenos e descritivos. O código de teste não tinha que ter um bom design. Contanto que o código de teste funcionasse e cobrisse o código de produção, estava tudo bem.

Quanto mais o tempo passava, mais difícil era alterar os testes e adicionar novos. Vez ou outra alguns testes falhavam quando a equipe mudava o código de produção, e corrigi-los também se tornou uma tarefa árdua e demorada. As estimativas ficaram cada vez mais altas, porque mexer nos testes era muito custoso. Depois de um tempo, eles jogaram fora toda a suite de testes. Mas sem os testes, muitos bugs começaram a aparecer, a equipe perdeu a confiança em alterar o código, e no final, clientes e desenvolvedores ficaram frustados.

Moral da história, se o código será mantido – seja de produção ou de testes – então ele tem que ser bem escrito.

Então, vamos botar em prática essa regra. A seguir, temos um exemplo de como podemos melhorar a qualidade de um teste. No último projeto que participei, uma classe de testes estava nos incomodando. Cada vez que tínhamos que alterá-la, era uma demora. Toda vez que abríamos essa classe, demorávamos entendendo novamente a sua difícil lógica. Vou mostrar a evolução do seguinte método de teste:

@Test
public void actionOriginatedInClientShouldNotBeExecutedIfReceivedFromServer()

O código original:

actionSyncServiceTestUtils.getActionExecutionServiceMock()
.addActionExecutionListener(new ActionExecutionListener( {
    public void onActionExecution(Action action,
        ProjectContext context,
        Set inferenceInfluencedSet, boolean isUserAction) {}
});

loadProjectContext(new ProjectContextLoadCallback() {
    public void onProjectContextLoaded(ProjectContext context) {
        actionSyncServiceTestUtils.getActionExecutionServiceMock()
            .onUserActionExecutionRequest(
                new Action(context.getProject().getId(), "filho"));
    }
    public void onProjectContextFailed(Throwable caught) {
         assertEquals(SAME_CLIENT_EXCEPTION_MESSAGE, caught.getMessage());
    }
});

final ArgumentCaptor eventHandlerCaptor = getEventHandlerCaptor();

createInstance();

final ActionSyncEvent eventHandler = eventHandlerCaptor.getValue();

final UUID clientId = new UUID("123");
clientHasId(clientId);
try {
     eventHandler.onEvent(new ActionSyncEvent(createRequest(clientId)));
} catch (final RuntimeException e) {
     final String sameClientExceptionMessage = "This client received the same action it sent to server.";
     assertEquals(sameClientExceptionMessage, e.getMessage());
}

assertNoActionWasExecutedInClient();

String clientId = "123";
given().aClientWithId(clientId);
when().aRequestArriveFrom(clientId);
verifyThat().noActionWasExecutedInClient();

@Test
public void actionOriginatedInClientShouldBeExecutedOnce() throws Exception {
    int nTimes = 1;
    when().anActionWasExecutedInClient();
    verifyThat().userActionsWereExecutedInClient(nTimes);
}

public class ActionSyncServiceTest {
private ActionSyncService ASS;
private ActionSyncRequest request;

@Test
void actionOriginatedInClientShouldNotBeExecutedIfReceivedFromServer() {
    String clientId = "123";
    given().aClientWithId(clientId);
    when().aRequestArriveFrom(clientId);
    verifyThat().noActionWasExecutedInClient();
}

@Test
void actionOriginatedInClientShouldBeExecutedOnce() {
    int nTimes = 1;
    when().anActionWasExecutedInClient();
    verifyThat().userActionsWereExecutedInClient(nTimes);
}

@Test
void actionsNotOriginatedInClientShouldBeExecutedAfterBeingReceivedFromServer() {
    short projectId = 1;
    given().aClientWithId("one client").ignoringProjectCheck(projectId);
    when().aRequestArriveFrom("other client");
    verifyThat().nonUserActionsWereExecutedInClient();
}

@Test
void actionNotOriginatedInClientShouldNotBeExecutedAsClientAction() {
    short projectId = 1;
    given().aClientWithId("one client").ignoringProjectCheck(projectId);
    when().aRequestArriveFrom("other client");
    verifyThat().nonUserActionsWereExecutedInClient();
}

@Test
void actionReceivedFromServerThatBelongsToAProjectDifferentFrom
ClientCurrentProjectShouldNotBeExecuted() {
    int currentProject = 1;
    int otherProject = 2;
    given().aClientWithId("client").aClientWithCurrentProject(currentProject);
    when().aRequestArrivedFrom("other client", otherProject);
    verifyThat().noActionWasExecutedInClient();
}

@Test
void actionReceivedFromServerThatBelongsToTheSameProjectOf
ClientCurrentProjectShouldBeExecuted() {
    short project = 1;
    given().aClientWithId("client").aClientWithCurrentProject(project);
    when().aRequestArrivedFrom("other client", project);
    verifyThat().nonUserActionsWereExecutedInClient();
}

private Given given() {
    return new Given();
}

private When when() {
    return new When();
}

private VerifyThat verifyThat() {
    return new VerifyThat();
}

private class Given {
  private Given aClientWithId(String clientId) {
    Mockito.when(clientIdentificationProvider.getClientId())
        .thenReturn(new UUID(clientId));
    return this;
  }

  private Given aClientWithCurrentProject(int projectId) {
    Mockito.when(projectRepresentationProvider.getCurrentProjectRepresentation())
        .thenReturn(ProjectTestUtils.createRepresentation(projectId));
    return this;
  }

  private Given ignoringProjectCheck(int projectId) {
    Mockito.when(projectRepresentationProvider.getCurrentProjectRepresentation())
        .thenReturn(ProjectTestUtils.createRepresentation(projectId));
    return this;
  }
}

private class When {
  private void aRequestArriveFrom(String clientId) {
    request = RequestTestUtils.createActionSyncRequest(clientId);
    fireEvent();
  }

  private void aRequestArrivedFrom(String clientId, int projectId) {
    request = RequestTestUtils.createActionSyncRequest(clientId, projectId);
    fireEvent();
  }

  private void anActionWasExecutedInClient() {
    createInstance();
    Action action = mock(Action.class);
    actionExecution.onUserActionExecutionRequest(action);
  }

  private void fireEvent() {
    ArgumentCaptor eventHandlerCaptor = getEventHandlerCaptor();
    createInstance();

    try {
      fireActionSynEvent(request,  eventHandlerCaptor);
    }
    catch (RuntimeException e) {}
    }

  private void createInstance() {
     // Create instance of the class being tested.
  }

  private ArgumentCaptor getEventHandlerCaptor() {
    ArgumentCaptor eventHandlerCaptor = ArgumentCaptor.forClass(ServerActionSyncEventHandler.class);
    doNothing().when(serverPush).registerServerEventHandler(eq(ServerActionSyncEvent.class), eventHandlerCaptor.capture());
    return eventHandlerCaptor;
  }

  private void fireActionSynEvent(ActionSyncRequest request, ArgumentCaptor eventHandlerCaptor) {
    ServerActionSyncEventHandler eventHandler = eventHandlerCaptor.getValue();
    eventHandler.onEvent(new ServerActionSyncEvent(request));
  }
}

private class VerifyThat {
  private void nonUserActionsWereExecutedInClient() throws Exception {
    int nTimes = request.getActionList().size();
    verify(actionExecution, never())
        .onUserActionExecutionRequest(any(Action.class));
    verify(actionExecution, times(nTimes))
        .onNonUserActionRequest(any(Action.class));
    verify(actionExecution, never()).onUserActionRedoRequest();
    verify(actionExecution, never()).onUserActionUndoRequest();
  }

  private void noActionWasExecutedInClient() throws Exception {
    verify(actionExecution, never())
        .onUserActionExecutionRequest(any(Action.class));
    verify(actionExecution, never())
        .onNonUserActionRequest(any(Action.class));
    verify(actionExecution, never()).onUserActionRedoRequest();
    verify(actionExecution, never()).onUserActionUndoRequest();
  }

  private void userActionsWereExecutedInClient(int nTimes) throws Exception {
    verify(actionExecution, never())
        .onNonUserActionRequest(any(Action.class));
    verify(actionExecution, times(nTimes))
        .onUserActionExecutionRequest(any(Action.class));
    verify(actionExecution, never()).onUserActionRedoRequest();
    verify(actionExecution, never()).onUserActionUndoRequest();
  }
}
}

Scrum without the “R” of Rigor becomes SCUM, which acronym stands for Slow, Confusing, Unreliable and Missing. But missing what? Missing confidence, assertiveness, productivity and other important aspects which make Scrum the preferred choice of agile project management framework for most agile companies.

The rigor and discipline when using any agile methodology is more than essential, it’s vital to the sake of the /company/product/project/team/. The right rigor in understanding the values and applying the principles and practices accordingly is just the difference between failure and success. Without rigor teams tend to shift the focus from valuable deliverables to wasteful rituals, which in turn aggregate nothing to them.

Mature agile leadership in the other hand foments discipline in taking responsibility and demonstrating ownership. Modern agile management delegates the decision making to the people who are actually performing ground work with dirty hands on the code. This is the way to foster a flexible governance and create innovation in the company.

However, when ground workers have no discipline in applying the technical and methodological agile standards, they are prone to generate an immeasurable loss to the business, usually overengineering the solution and making wrong decisions.

Great developers make a move when, and only when they understand the value behind that move. If you understand the value, then rigorously do the minimum movement necessary to achieve that value, never more and never ever less than that.

If you consider becoming yourself a good agile developer/leader/whatever, think and act with discipline and rigor, providing responsibility and restlessly pursuing the goals you and your team have agreed with.

Remember: work hard, fail sometimes, fail fast, make your failures visible, try again, fail again, fail better.

How could delivering value be sustainable without writing good code? Is that possible? In this sense, good code means to me clean code, well documented, easy to read, to understand and to extend. Moreover, good code is well tested, is simple, is cheap to change and is part of a robust architecture, capable of delivering an unfair competitive advantage to the business. Nevertheless, good code is essential to sustainably and reliably deliver value over time. But what if I have all that and have not delivered value? Is that sustainable? Can you keep doing that forever? Probably not.

And in the other hand, is it possible to deliver value with poor code? The answer is: It depends! Usually it is, but in a very short term, since it wouldn’t be sustainable in a long term. It usually depends on what kind of business you’re working on. If people may die if something goes wrong in your software, I would recommend not to rely on poor code to deliver value. But if your business can live with a poor code base for a while, just during the barely enough period you need to generate value, I would say: go for it. Seek the simplest way that could possibly generate value. Sometimes this way is so stupid that we can’t even think about it.

What happens though if you can deliver value in a short term with poor code? Remember that value is the only thing that can keep a business existing. If you have value, you survive. However, if you have no value, even with the best possible architecture, you do not survive – your legacy becomes waste. So, if you’re capable of delivering value with poor code, and you’re intelligent enough to apply the agile engineering practices such as refactoring to improve the existing poor code base, you can transform it into a good code base that will sustain your business in the long run.

Some developers may also argue that the complexity of businesses and the complexity of the human beings with ever changing minds running their business make it even worse to deliver value. These developers are right! Therefore, whether you have good or bad code, you’ll have to deal with numerous aspects other than technology in order to deliver good value. In my humble opinion, there is nothing more important in software development than delivering value. You just have to carefully think what kind of value you’re looking for and to whom it will serve.

So, what kind of developer you are? The one that writes good code or the one that delivers value?

Tudo começou com um vídeo do Dan Pink que o Vinicius Nunes mandou para o pessoal sobre motivação:

Então, lembrei de uma discussão que tive em uma disciplina no MBA a alguns dias, chamada arquitetura organizacional. Em princípio achei que iria ser um sacrifício ir para a aula, ouvir o professor falando sobre organogramas, etc… Maaaasss, foi sensacional!

Apesar de não ser exatamente sobre motivação, o assunto da discussão trata de tendências mundiais, que podem ser percebidas claramente através do conceito de motivação apresentado no vídeo. A pouco tempo, esse tipo de motivação – pelo propósito, pelo conhecimento – era praticamente inexistente. As empresas e as pessoas (pense em nossos pais ou avós) trabalhavam para ganhar dinheiro, adquirir coisas. A motivação era o dinheiro.

Porém, estamos em transição! A anos atrás (200 ou 300 talvez) vivíamos em uma sociedade seguindo uma tendência artesã onde a padronização e a produção era muito pequena. Os trabalhos eram bastante manuais. Depois entramos na era do industrialismo, onde a padronização foi muito forte, tínhamos produção em massa e trabalhos bem mecânicos. E o que está acontecendo hoje? Pare para pensar quem são as empresas mais admiradas ou valorizadas no mundo: Apple, Google, Microsoft… indústrias onde o conhecimento é a base. Estamos entrando na era do conhecimento!

Essa mudança de onda ajuda a explica a crise nos países “desenvolvidos” (EUA, Grécia, Espanha…). Não há mudança sem crise. E isto está só no começo. Mas onde estão as indústrias? Na China, que, “atrasada” com a evolução, entrou na era industrial a pouco. O que acontece lá hoje já, e que muitos consideram um absurdo com os direitos humanos, aconteceu em outros países que já passaram por esse processo, porém hoje é mais aparente com o avanço da comunicação e a globalização. Outros países nem na era industrial estão.

A China é o país que mais cresce por ano, e portanto é considerado o “novo gigante”. Porém, o que define quem é o maior? O PIB? A qualidade de vida? Há um balanço entre IDH, PIB e poluição? E qual o papel dos países que investem fortemente na mão de obra chinesa?

Para quem se interessar mais sobre o assunto, existem dois livros, ambos do Alvin Toffler, que estou prestes a ler:

• A Terceira Onda

• O Choque do Futuro

Abraço e boas discussões!

Porém, apesar da importância dos testes automatizados, raros são os projetos de software que se utilizam deles, ou se utilizam com uma quantidade/qualidade satisfatória.

No último projeto em que estive envolvido aqui na Oncast chegamos na marca de quase 79% de cobertura de testes no nosso código, com testes unitários, de interface (quando relevante) e integração.

Não irei justificar a importância dos testes automatizados. Se você ainda não os julga importante, ou não investe o suficiente, meus pesâmes para você.

Ao invés disso, baseado na minha experiência nesse projeto, vou tentar descrever resumidamente como chegamos nesse número de cobertura de testes, tentando responder a uma simples pergunta que eu mesmo me fiz:

“O que esse projeto teve de diferente de outros para que isso fosse possível?”

O projeto teve duração de 7 meses, onde estávamos em parceria com o nosso cliente, reformulando um dos maiores portais de entretenimento do Brasil atualmente.

Além de um novo visual para o usuário final, também íriamos migrar os dados do portal legado e prover uma nova aplicação administrativa para a geração de conteúdo. A nossa responsabilidade foi da implementação dessa nova solução administrativa e da migração dos dados. Para o desenvolvimento dessa nova ferramenta administrativa foi utilizado Ruby on Rails.

Lembrando que tivemos uma série de desafios nesse projeto, como: distância com o cliente/PO, data definida para o lançamento do novo portal, mudanças na equipe, arquitetura complexa, integração tardia e por aí vai. Enfim, um cenário real que faz parte do cotidiano não só da área de TI como de outras indústrias.

Logo já sabemos que isso não foi o diferencial desse projeto para outros os quais já trabalhei.

Então, como chegamos nesse número de quase 80% de cobertura de testes?

Algumas das diferenças que encontrei, comparando com outros projetos que trabalhei, foram:

• Sabíamos da importância ainda maior de testes automatizados utilizando linguagens dinâmicas, nesse caso Ruby;
• Apoio do nosso cliente e “product owner” Claudio Br (@oclaudiobr – http://blog.claudiobr.com/), na verdade um dos poucos PO de verdade com quem já trabalhei. Além de priorizar de maneira eficiente, sabe da importância dos testes e sempre nos incentivou;
• Os frameworks utilizados (Rails, rspec, e várias outras gems) na maioria das vezes facilitaram a nossa vida para se implementar os testes. Ao contrário de outras linguagens e frameworks (Exemplo: java/javaee/ejb);
• A disciplina e o profissionalismo da equipe foi fundamental. Pois mesmo com pressão de prazos, entregas, todos da equipe não abriam mão dos testes;
• Equipe madura com uma mentalidade voltada para o TDD/BDD;
• Integração contínua (Hudson) funcionando desde do início do projeto;
• Atenção com a integração contínua, sempre que uma build quebrava alguém verificava o problema;

Não existe regra ou receita mágica, acredito que nossas experiências (positivas ou negativas) são as melhores ferramentas para que possamos evoluir.

Portanto esse post, nada mais é do que um lembrete para mim, para me ajudar a não esquecer dessa experiência.

E meus sinceros agradecimentos a todos os meus companheiros de equipe da Oncast, que provaram que é possível sim, mesmo com as dificuldades e os obstáculos, ter um projeto com uma excelente cobertura de testes.

Entretanto me espanta constatar que uma parte significativa das empresas que desenvolvem software, especialmente aquelas que não tem o desenvolvimento de software como fim, ainda sofrem em ambientes caóticos e desumanos. Muitas ainda usam métodos que há pelo menos mais de uma década foram caracterizados como ineficazes para o desenvolvimento de software.

Em desenvolvimento de software há apenas uma grande certeza, a de que existe muita incerteza. Não existe previsibilidade em desenvolvimento de software e também não existe fórmula mágica para isto. Existe sim um conjunto de técnicas, princípios e valores que permitem um processo de desenvolvimento adaptativo e evolucionário, onde o aprendizado precisa ser reconhecido como uma base essencial para que se possa entregar valor de forma contínua e iterativa.

Existe também a necessidade pela colaboração irrestrita entre clientes e desenvolvedores, pela criação de ambientes maduros, onde a visibilidade é total e a confiança mútua é possível. Também não estamos livres dos desafios de conciliar as necessidades de mercado em definir orçamentos claros (e muitas vezes fixos) para escopos que geralmente são mutantes e imprevisíveis.

Porém, tudo isto é possível, e as respostas você encontra na pura essência do Manifesto Ágil, nos princípios do Lean, nas práticas imprescindíveis do XP e nas ferramentas do Scrum. Ainda assim, um equilíbrio vital é necessário. A aplicação inadequada todavia pode também levar projetos à morte. Portanto, se você quer sobreviver num mundo onde não temos chance de errar, mova-se agora. O mundo mudou!

Com o crescimento da OnCast e fortalecimento de nossa marca, precisávamos de um espaço que pudesse materializar a nossa cultura e fomentar a disseminação dos nossos valores. Com a ajuda da designer Fernanada Dill, estávamos muito bem amparados para um novo e ambicioso projeto, a criação da nossa nova casa, o #OnCastLab. Confira abaixo algumas fotos e relatos:

Fernanda Dill – a Oncast é uma empresa cuja filosofia, apaixona todas as pessoas que tem a oportunidade de conhecê-la. E comigo, mesmo não trabalhando diretamente, não foi diferente. Assim, foi um grande desafio criar um espaço de trabalho que representasse os valores dessa equipe, mas também, um prazer enorme desenvolver um ambiente comercial tão inovador.
A recepção teve como objetivo principal expôr a identidade visual da empresa, explorando as cores escolhidas para levarem a marca Oncast. Simultaneamente os nichos com formas orgânicas e assimétricas, transparecem a leveza e a irreverência da equipe.

Rodrigo Branas – A nova sede da OnCast Technologies reflete a essência dos valores fundamentais da empresa. É um ambiente onde o incentivo a comunicação e colaboração são levados ao extremo! Esse novo espaço consegue unir valores como profissionalismo e liberdade, proporcionando a todos o melhor ambiente possível para se trabalhar e desenvolver suas carreiras.

Fernanda Dill – Na sala de reuniões buscamos um ambiente um pouco mais tradicional e sofisticado afim de receber clientes e abrigar reuniões de planejamento da empresa. Nas salas da presidência, marketing comercial e diretoria de operações, o conceito foi  a personalização. As salas são temáticas, estampando nas paredes literalmente a identidade dos seus colaboradores.

Fernanda Dill – A área de desenvolvimento comporta até 35 pessoas. As equipes ficam integradas, porém inúmeros quadros brancos entre elas, garantem a privacidade para que cada uma possa discutir seu projeto. Os Open Spaces, posicionados na área de desenvolvimento, trazem um conceito lúdico, representado na utilização de grama sintética, puffs coloridos e adesivagens nas paredes. Esses materiais e cores, estimulam a criatividade, a interação entre os colaboradores e proporcionam momentos de descontração que potencializam os resultados das equipes.

Fernanda Dill – Por fim, o Living, sem dúvida o espaço preferido da equipe nas horas de descanso, é um lugar de entretenimento e de convivência. Conta com uma pequena cozinha, espaço para tomar uma café, “Bater um papo” com os amigos e distrair a mente e o corpo descansando em um puff ou jogando video game.
É importante destacar que aspectos ergonômicos foram a base de todo o projeto, proporcionando maior conforto aos usuários e gerando um espaço propício para que cada um desenvolva suas atividades com a máxima qualidade e performance.

Fernanda Dill – Um espaço nada convencional, nada tradicional, mas pronto para receber a melhor equipe de desenvolvedores e demais profissionais que a Oncast possa ter. Um ambiente pronto para fazer com que cada pessoa tenha prazer de fazer parte da Família Oncast.

Este espaço é um pouco do que estamos fazendo para mudar a indústria de software. Faça parte desta mudança você também, venha nos fazer uma visita e descobrir como. Grande abraço…