- É uma pergunta sobre quais ferramentas e técnicas são eficazes para transmitir a outras pessoas e desenvolver em conjunto modelos mentais para entender um sistema ou produto
- Como forma de desenvolver modelos mentais, é mencionada a experiência de construir e manter o próprio sistema
- A forma de transmissão se aproxima mais de explicações informais, como rabiscar em um guardanapo, explicar com gestos ao lado da pessoa ou colocar em palavras enquanto pensam juntos
- Documentos que organizam exaustivamente listas de funcionalidades ou áreas superficiais podem ser abrangentes, mas talvez não sejam suficientes para criar ou transmitir o modelo mental do tema
- A experiência de usar diretamente uma ferramenta ou produto bem projetado pode ajudar ao mesmo tempo no processo de desenvolver e transmitir modelos mentais
Foco da pergunta
- O ponto central é quais ferramentas ou técnicas são eficazes para transmitir e fazer crescer modelos mentais
- A pergunta trata de duas direções ao mesmo tempo
- Como desenvolver modelos mentais
- Como transmitir modelos mentais a outras pessoas
Exemplos e questão levantada
- Como exemplo de desenvolver modelos mentais, aparece a ideia de construir e manter sistemas
- A forma de transmitir modelos mentais aparece como um alinhamento de entendimento feito junto, no contexto prático, como por exemplo
- Rabiscar em um guardanapo
- Explicar com gestos ao lado da pessoa
- Explicar enquanto pensam juntos
- Documentos que listam funcionalidades ou catalogam escopos superficiais podem ser abrangentes
- Mas esses documentos talvez não cheguem a criar ou transmitir o modelo mental daquele tema
- A experiência de usar diretamente uma ferramenta ou produto bem projetado é tratada como uma forma de alcançar tanto o crescimento quanto a transmissão de modelos mentais
- A pergunta final pede quais ferramentas e técnicas cada pessoa considerou eficazes e por que elas funcionam
1 comentários
Comentários no Lobste.rs
Olog é um bom formalismo para transmitir ontologias.
Se for um processo de longa duração com muito estado interno, diagramas de estados e statecharts são úteis para documentar o sistema.
Usuários do sistema geralmente não percebem a estrutura real do sistema. Um motivo é que o Nakatomi space só fica visível para usuários que usam mal o sistema, e porque há uma região separada do espaço de estados para comportamentos não intencionais, como weird machines.
Outro motivo é que, como na visão de the purpose of a system is what it does, usuários podem criar uma razão de ser pessoal vendo apenas o que o sistema faz por eles, mas podem não perceber o propósito geral pretendido por projetistas e mantenedores.
Escreva um livro e contrate um editor.
Acho que isso chega perto do problema central da educação. Foram citadas duas categorias: aprender fazendo e orientação de especialistas; a terceira é ensinar.
A pergunta mais importante é se é possível criar modelos que sejam adquiridos com mais facilidade ao reutilizar princípios e designs parecidos, ou se dá para reduzir a necessidade de assimilá-los por completo por meio de abstrações. Mas é preciso que esteja bem definido onde a abstração vaza.
Relacionado a isso, The Programmer's Brain, de Felienne Hermans, é interessante. Achei marcante que a abordagem “vou resolver vários exemplos, então observe” usada ao ensinar matemática etc. a crianças pequenas também funciona bastante bem no ensino de programação.
Em um ambiente de trabalho, para onboarding, talvez isso assuma formas como “veja como eu investigo este bug” ou “veja como eu volto a entender este subsistema em que não mexo há algum tempo”.
Em engenharia de software, ajuda separar modelos mentais em histórias de usuário e implementação técnica.
Normalmente, histórias de usuário são requisitos primários, isto é, o valor que se quer alcançar; a implementação técnica é o elemento secundário necessário para atingir esse objetivo.
Histórias de usuário descrevem o valor entregue ao cliente, e a implementação técnica descreve como as restrições do sistema construído limitam as histórias de usuário.
Às vezes os dois se sobrepõem, de modo que uma história de usuário fica limitada pela implementação técnica, ou, ao contrário, uma implementação técnica é escolhida para realizar a história de usuário. Mas muitos comportamentos de sistemas podem ser enquadrados em um dos dois.
Depois disso, basta escolher a ferramenta que melhor se encaixa. UML é bom para desenhar mapas de entidades, e fluxogramas são bons para explicar fluxos. Diagramas de estados são bons para explicar estados permitidos e não permitidos e suas transições, e tabelas de variáveis e estados são boas para enumerar todos os valores possíveis.
A melhor forma de aprender a desenhar um sistema é pedir a três pessoas diferentes que cada uma desenhe a imagem que tem em mente. Mesmo a mesma ideia pode ser expressa de formas surpreendentemente variadas, e a maioria é igualmente válida, mas revela aspectos diferentes do tema. É parecido com arte.
Uso principalmente diagramas mais formais. Ainda assim, quando estou rabiscando em tempo real durante compartilhamento de tela, às vezes abro o jspaint, e, se for algo que outras pessoas talvez vejam depois, uso algo como Figjam.
Diagramas e apontar funcionam bem porque são nossas ferramentas mais antigas, e ainda úteis, de direcionamento da atenção. Antes de falar, nós apontamos e choramos; em localização e navegação, apontar é muito mais imediato do que a linguagem, por isso o mercado de ponteiras laser continua existindo.
The Geometry of Meaning: Semantics of Conceptual Spaces, de Peter Gårdenfors, trata desse tema em bastante detalhe. Barbara Tversky também tem muitos estudos sobre diagramas e estruturação de espaços cognitivos, e “What Constitutes an Effective Representation?”, de Peter Cheng, apresenta critérios bastante quantitativos para uma representação eficaz.
Shadowing, pairing e sessões de whiteboard são bons. Nesse caso, os dois lados precisam desenhar e fazer perguntas.
Também há métodos como escolher e executar juntos um projeto que expanda ou altere o modelo, quizzes, o aprendiz ensinar de volta, memorizar e escrever à mão.
Memorização simples deve sempre ser usada junto com outros métodos, e não deve se tornar o único método. Também ajudam fazer diagramas ou rabiscos fora do whiteboard, análise de lacunas comparando com outros modelos/soluções, e reflexões contemplativas e semiconscientes, como hammock time.
Acho que é preciso distinguir entre representações para comunicação e representações para executar a tarefa real. A segunda não foi mencionada aqui, mas está mais próxima de “execução”.
Modelos executáveis muitas vezes comunicam mal, em geral porque as fronteiras de abstração são ruins. Em computação, quase sempre são abstrações com vazamentos.
Entender o que algo faz pode ficar encoberto pela montanha de esforço acumulada para fazê-lo operar de modo eficiente. Por isso surge a necessidade de rabiscar num guardanapo e explicar: “neste nível de abstração, que corresponde ao seu modelo mental atual, este sistema funciona assim”.
Documentação é um artefato separado, então tende a ficar atrás do modelo executável; para evitar isso, é preciso mantê-la com muito cuidado. O modo mais difícil é acoplar a documentação diretamente ao código, ou colocar a documentação à frente do código, como em programação literária.
Por isso, ao transmitir modelos mentais, geralmente faz sentido usar a abordagem que exige o mínimo de esforço e manutenção: rabiscos no guardanapo e lidar juntos com o sistema real ao longo do tempo.
Há um motivo para recém-chegados começarem com correções fáceis de bugs, e não escrevendo documentos de design.
Recém-chegados precisam aprender fazendo, então um tutorial pode ser o mais adequado. Mas, depois de mexerem um pouco, é provável que tenham alguns mal-entendidos, e uma explicação em cima de rabiscos no guardanapo pode resolver isso.
Portanto, se você decidiu escrever um tutorial, não tente criar uma documentação de “tudo”; escreva um bom tutorial com foco claro.
Escrever é a resposta.
Software é uma mídia dinâmica pessoal, então é bastante interessante.
Acho que sistemas interativos ajudam. Por exemplo, algo como um depurador visual que ensina Python e variáveis encaixotadas.