Sinopses de 3 linhas perfeitas

“Fardos de palha” © Wernher Krutein, photovalet.com/64360

Há umas semanas atrás, tive que recolher e organizar informações sobre trabalhos de alunos de anos passados (uma frase descritiva, umas palavras-chave e um vídeo/imagem). Não era uma tarefa complicada — bastou abrir um disco de backups antigo —, mas rapidamente se transformou numa tarefa demorada.

Isto porque descobri rapidamente que, muitas das descrições que os alunos registaram foram… bom… menos interessantes (estou a ser simpático).

Afinal, o que custa escrever uma descrição curta de um projeto? Resumir a ideia numa frase, ou num parágrafo de… três linhas, ou de 30 palavras? Tipicamente, isto faz-se para livros, filmes, aplicações… para tudo? Então porque é que muito poucos conseguem?

Claro, estou a ser mauzinho, eu sei. Também passei pelo mesmo (quem é que escreveu o texto perfeito aos 20 anos?). Mas a verdade é que me tenho lembrado muito de um grande professor que tive — o professor de cinevídeo e realizador da RTP, o Prof. Rui Ramos. Ele repetia religiosamente o mantra “S”+”TS”+”… que era o método de nós afinarmos ideias progressivamente de uma frase (sinopse), para um tratamento (da sinopse), até redigirmos um par de guiões literários e técnicos completos.

Atualmente trabalho de forma semelhante. Começo com uma ideia difusa. E, após brainstorms, definições de requisitos e funcionalidades vários, defino uma ideia forte, funcionalidade-chave, foco, ou (como gosto de chamar) o USP. E é esta última que deve ser capturada na sinopse. Se pudéssemos estabelecer o paralelo para o mundo do desenvolvimento de software, é a ideia que vai ser concretizada num MVP.

Mas tenho sempre bastantes problemas em passar esta mensagem aos alunos. Tal como um produto em MVP não é um produto completo, uma sinopse não é um resumo nem uma descrição completa de funcionalidades, ou da narrativa. É uma sinopse. É o sumo do sumo…

Tal como Sylvain Gauchet da Apptamin, a sinopse deve ser uma:

… description in a concise paragraph. Say who your audience is, what your app does, what sets it apart from the crowd.

Este ano não foi diferente. Apesar de muitos grupos terem feito um trabalho excelente, acho que muitos continuam a não perceber como isto pode ser feito. Por isso, para os alunos, colegas, amigos ou interessados em desenvolver ideias e produtos digitais, aqui fica o modelo para escrever uma sinopse perfeita de três linhas:

O projeto NOME, uma DESCRIÇÃO DA APLICAÇÃO e/ou TECNOLOGIA SUPORTE, que tem por objetivo USP, FOCO ou FEATURE DISTINTIVA DA APLICAÇÃO, para responder ao OBJETIVO, NECESSIDADE ou PROBLEMA A RESOLVER do PÚBLICO ALVO PRIMÁRIO, num contexto ENQUADRAMENTO TEÓRICO, SOCIAL, etc. [opcional: , com as ENTIDADES PARCEIRAS, e/ou as CONTRIBUIÇÕES ou RESULTADOS ESPERADOS]

The NAME project, is a SUCCINT APLICATION DESCRIPTION supported by SUPPORT TECHNOLOGY, that aims to USP, FOCUS, or DISTINCTIVE PROJECT FEATURE, developed in order to address a SPECIFIC NEED or GOAL for the TARGET AUDIENCE, in a context of THEORETICAL, SOCIAL, etc. [optional: , with PARTNER ENTITIES and/or that will produce SPECIFIC OUTCOMES OR CONTRIBUTIONS.]

Claro, que assim até parece fácil. Parece óbvio. Não é. Mas também não foi fácil chegar a esta sinopse. Aliás, basta substituírem o texto acima pelas vossas palavras e dificilmente terão uma sinopse de 3 linhas. A arte e a ciência de conseguir este resultado vai ser na redação sintética e objetiva do que pretendem.

Por isso, experimentem este desafio. Experimentem trocar as poucas palavras neste modelo para descrever a vossa aplicação, software ou instalação multimédia favorita.

Experimentem por exemplo fazer isto para a Aplicação Móvel do Facebook. Qual é a feature principal/distintiva? Provavelmente as respostas vão ser variadas, dependendo do uso de cada uma. Por isso, tentem um processo de eliminação até chegar à feature sem a qual a aplicação não poderia funcionar, ou que descreva outra aplicação existente (melhor?) no mercado. Por exemplo, dá para tirar e partilhar fotos com a APP do FB… mas tirar fotos não é a funcionalidade chave (certo, Instagram?). Dá para ver, seguir e gerir os grupos (mas também existe outra para isso…). E que tal conversar? (Alguém conhece o Messenger, Whatsapp, ou Snapchat…? ).

Sendo assim, para mim, em 3 linhas, a APP do FB para dispositivos móveis seria descrita da seguinte forma:

A aplicação Facebook Mobile uma aplicação móvel nativa (iOS, Android e Windows*) que tem por objetivo principal seguir as atualizações (posts, comentários, fotos, etc.) da nossa rede de contactos (pessoas, empresas, sites, etc.) de forma interativa e personalizada, para o todos os públicos, para promover uma maior interligação social.

Bom. Esta tentativa de descrição quase que cumpre o objetivo. Acabou por ficar longa demais… O objetivo das 3 linhas (aprox. 30 palavras) foi um pouco ultrapassado (para quase um dobro de 49 palavras). E encerra (o que considero ser) um problema grave—a identificação/estratificação do público-alvo primário. Por isso, tentaria uma segunda definição orientada a casos de uso, por exemplo no contexto de estudo, ou grupos na escola.

A aplicação Facebook Mobile uma aplicação móvel nativa (iOS, Android) que tem por objetivo principal sincronizar os alunos de um grupo (informação, ficheiros, ou links) de forma rápida, pessoal e privada para promover uma maior interligação social, dinamismo e apoio ao estudo.

Esta definição — ligeiramente mais curta com 42 palavras — continua a ser uma descrição válida. E ainda podia ser mais sintetizada.

Mas reparem como personalizei a coisa para particularizar um uso / caso. É claro que se esta fosse a descrição da APP, podia perder pontos em relação ao #Slack… mas é uma sinopse. De seguida, acrescentaríamos detalhes de forma progressiva (contexto de uso, etc…) até chegar a um resumo mais completo, visando a integração nas redes sociais a que pertencem (IRL & Online), a facilidade, a ubiquidade, etc… mas aqui é que reside a diferença entre uma sinopse e um resumo.

[update 2017-02-13: No livro da Leah Buley, que me foi recomendado há uns dias pelo prof. Ivo Daniel, é mencionado um aspeto que foi negligenciado nesta sinopse — os constrangimentos. No respetivo tratamento, ou no documento de especificação de requisitos de software, estes constrangimentos ou restrições — constraints — devem ser bem identificadas. Ou pelo menos, devem ser equacionadas na definição do que é o produto ou aplicação. Para também ser mais fácil dizer o que não é. Do que depende (requisitos de conteúdo, sistema, dados, software, …). E do que não depende. É fundamental!]

Mais tarde este tratamento pode ser ampliado para um press release, um resumo, um “paper” (como temos feito nos últimos anos), um Mobile Request for Proposal (APP RFP) ou mesmo a documentação técnica.

Deem uma vista olhos no link acima: http://www.apptamin.com/blog/get-app-reviewed/ , no link original: http://www.appdesignvault.com/erica-sadun-pitch-perfect-interview/ onde as autoras também disponibilizam exemplos e promovem um livro interessante que nos deixa a pensar no assunto… descrições de um parágrafo e vídeos de 30”…  ;)

[update 2017-03-01] Sobre a questão da sinopse poder ser um bom guia inicial (ideia difusa), ou uma síntese final (ideia concisa), acho que ambas abordagens são válidas e pertinentes. No modelo de desenvolvimento MethodKit, é sugerido como proposta de [ideia para desenvolver] soluções inicial. A semelhança com esta sinopse é assustadora:

A product that… uses [technology] with [trend] on [location] fulfilling [human need] made of [material] made with [person] in mind, that offers [value/business model] and makes money from [revenue stream/business model].

You could also complete the sentences with an [idea] … that solves the housing crisis or a [solution] … that makes people more healthy.

O que é engraçado é que eles usam sem preconceito a palavra trend [moda] e location [local], o que, para produtos digitais, é capaz de ser mais complicado. Complicado, mas não menos relevante—trata-se do contexto? Ainda assim, não deixa de ser interessante o uso ligeiro e assumido destas palavras. Mais informações sobre o método deles aqui: https://methodkit.com/hackathons/?utm_source=adroll&utm_medium=adroll&utm_content=static&utm_campaign=adroll

De qualquer forma, uma sinopse, ideia ou solução tem sempre que ser expandida num formato compreensivo e detalhado (pontos chave da ideia, públicos, features, concorrência, tecnologias, custo, tempo,…)

Para um documento mais completo, vejam o template da ClearBridge: http://info.clearbridgemobile.com/mobile-app-rfp-template

[update 2017-02-13 Este exemplo de um SRS também é impressionante e muito completo]

Têm uma opinião diferente, ou gostaram do desafio? Deixem em comentários ou enviem-me exemplos das vossas sinopses de três linhas. Fico curioso por ver/saber como descrevem as vossas aplicações [favoritas].

* No próprio site a lista de suporte para dispositivos é vasta e a ordem é, no mínimo, interessante: “iPhone, Blackberry, Android, Windows Phone, Nokia, and other mobile devices…” A sério? Symbian ainda percebo, mas Blackberry?! ;)

Advertisements

Author: Pedro Amado

Professor Auxiliar na Faculdade de Belas Artes Universidade do Porto lecionar Ferramentas Digitais, Web Design, Design de Interação e Creative Coding

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s