Desenvolvimento de Software Educativo: A Coordenação como Fator Crítico de
Sucesso
1. Introdução
Associado aos processos de desenvolvimento, têm sido aplicadas diferentes
técnicas de gestão de projetos reconhecendo que, a necessidade de estimar
cronogramas e orçamentos é muito importante, e que a coordenação destes
recursos se torna tanto mais crítica quanto maior for o projeto e a
complexidade do mesmo. As abordagens teóricas para avaliação e a melhoria dos
processos de desenvolvimento de software, tais como, o Capability Maturity
Modeling e a ISO 15504 (2004), identificam práticas de referência para a gestão
da engenharia de software e quando as mesmas devem ser aplicadas, levando as
organizações a compreender, a controlar e a melhorar os processos de
desenvolvimento (Costa, Loureiro, & Reis, 2014).
Em projetos em que o desenvolvimento de software é feito envolvendo equipas
multidisciplinares, o seu sucesso depende do desempenho dos elementos da
equipa, como sucede em qualquer projeto que envolva interação entre pessoas
(Moe, Dingsøyr, & Dybå, 2010). As equipas que trabalham colaborativamente,
aumentam a possibilidade de obterem melhores resultados do que se os seus
elementos atuassem de forma individual, uma vez que: i) é possível rentabilizar
o mesmo trabalho com base no esforço e competências de cada elemento (Fuks et
al., 2008) e ii) os elementos podem identificar antecipadamente inconsistências
e falhas que decorrem durante o processo de desenvolvimento. É nesta dinâmica
que as atividades de coordenação se tornam essenciais ao sucesso de
desenvolvimento de um software educativo.
Numa equipa multidisciplinar recentemente constituída, numa fase inicial,
existe a preocupação de distribuir corretamente as tarefas pelos elementos e
se perceber se cada um é capaz de assumir a responsabilidade ou papel nas
tarefas que lhe são conferidas ou designadas (Miguel, 2003). O mesmo autor
afirma que quanto maior for a integração dos elementos da equipa, melhor será a
partilha de informação, serão facilitadas as tomadas de decisão, levando os
elementos a sentirem-se mais comprometidos com o projeto. O nível de confiança
entre os elementos da equipa permite que os processos de comunicação sejam mais
fáceis e eficazes e reduza as atividades de coordenação apresentadas na
terceira secção.
A Metodologia Híbrida de Desenvolvimento Centrado no Utilizador foi o primeiro
processo analisado pelo modelo 4C. A MHDCU foi utilizada no desenvolvimento do
recurso educativo Courseware Sere ' O Ser Humano e os Recursos Naturais.
Trata-se de um processo de desenvolvimento simples, iterativo e incremental que
tem como alicerces princípios do Design Centrado no Utilizador (DCU),
especificados na International Organization for Standardization 9241-210
(ISO9241-210, 2010) ' Ergonomics of Human-System Interaction (210: Human-
centred design for interactive systems). Na sua base encontra-se a estrutura
disciplinada de processos de desenvolvimento, bem como práticas e valores dos
métodos ágeis de desenvolvimento de software. O processo é constituído por 4
fases principais: planeamento, design, implementação e manutenção/operação. A
prototipagem e a avaliação são realizadas de modo transversal a todo o processo
(Costa, 2012a).
Seguidamente será descrito o modelo 4C dando enfâse à dimensão coordenação
(segunda secção). Posteriormente, apresentamos o processo metodológico
(terceira secção) e respetivo modelo de categorias da dimensão coordenação.
Finalmente a análise interacções da dimensão coordenação (quarta secção) e as
conclusões (quinta secção).
2. A Coordenação no Modelo 4C
Malone e Crowston (1994) definem coordenação como managing dependencies
between activities sendo gerida por mecanismos de coordenação. Os mecanismos
podem ser ubíquos (encontrados em muitos processos) ou variáveis (podem gerir
muitos tipos de dependências). O trabalho cooperativo, de acordo com (Acuna,
Gómez, & Juristo, 2009), exige um esforço suplementar de coordenação da
equipa multidisciplinar, de forma a evitar que os fatores do comportamento, que
surgem através da interação, tais como, conflitos, a coesão, a cooperação e a
comunicação, levem a falhas.
A coordenação (ver Figura_1) organiza a equipa atribuindo tarefas para serem
realizadas por determinada ordem, dentro de um determinado intervalo de tempo e
cumprindo os objetivos inicialmente propostos (Raposo, Magalhães, Ricarte,
& Fuks, 2001). A coordenação envolve ainda a articulação das diferentes
tarefas, levando às ações necessárias para o trabalho cooperativo. As tarefas
devem ser assumidas como um compromisso individual ou da equipa.
Os elementos de perceção são fundamentais para a coordenação da equipa. Com
estes, é possível conhecer em que fase está o projeto e o que cada elemento
está executar em determinada fase. Os elementos de perceção permitem transmitir
ou provocar mudanças de forma a gerar um novo compromisso, controlando a
qualidade do projeto com respeito aos objetivos previamente estabelecidos,
evitando a duplicação de esforços. Como sugere a teoria da mente coletiva
(Weick & Roberts, 1993), quando os membros da equipa mantêm a perceção do
papel de cada um através da interação empenhada, maior será a garantia do bom
desempenho da equipa (McChesney & Gallagher, 2004).
As informações são essenciais para o coordenador verificar se existem conflitos
de interesse que prejudiquem a equipa e para identificar a capacidade e
experiência de cada elemento da equipa multidisciplinar.
A Coordenação é uma das dimensões do modelo 4C. O modelo 4C (Figura_3) foi uma
adaptação do modelo 3C de colaboração (Figura_2) que, por sua vez, surgiu na
década de 90 e tem sido disseminado por diversos autores, tais como, Denise
(1999), Borghoff & Schlichter (2000), Blois & Becker (2002) e
essencialmente por Fuks e colaboradores (Fuks et al., 2005; Fuks et al., 2008;
Pimentel et al., 2008). O modelo 3C tem sido usado para diferentes finalidades,
tais como, classificar ferramentas colaborativas (Borghoff & Schlichter,
2000), para análise de interfaces com utilizadores e para avaliação de
aplicações colaborativas (Neale, Carroll, & Rosson, 2004).
A comunicação no modelo 3C de colaboração compreende a troca de mensagens, bem
como a negociação de compromissos. A cooperação envolve o trabalho em conjunto
dos elementos da equipa, através de um espaço partilhado. Na coordenação, as
pessoas, as tarefas e os recursos são geridos para lidar com conflitos de
interesse e tornar a comunicação e a cooperação o mais eficiente possível. De
uma forma sintetizada, a necessidade de executar tarefas origina a negociação
de compromissos através da comunicação, sendo geridos pela coordenação e
realizados de forma cooperativa.
O modelo 4C difere do modelo 3C de colaboração pelo facto de se considerar que
os conceitos de colaboração e cooperação são distintos. A fig._3 bem como a
descrição de cada componente do modelo 4C é a versão já com as alterações
propostas incluídas.
O modelo 4C está assente em três pilares, que se descrevem sucintamente:
- Comunicação: partilha de informação e partilha de pontos de vista sobre o
processo de desenvolvimento, essencialmente sobre as soluções de projeto
(protótipos programados, documentos e protótipos em imagem). Nos compromissos,
os elementos da equipa combinam as tarefas a executar, dependendo o sucesso na
realização das tarefas definidas da sua autodisciplina. Os compromissos podem
ser definidos a uma escala temporal, em que o elemento define uma data ou
período para realização de determinada tarefa, ou não. A comunicação funciona
como o contributo espontâneo emitido por um ou vários elementos da equipa
multidisciplinar (emissores), sendo o seu impacto refletido pelos restantes
elementos (recetores) através das interpretações/perceções e (re)ações.
- Colaboração e Cooperação: tarefas que a equipa multidisciplinar desenvolve em
conjunto (colaborativamente) ou individualmente (cooperativamente) mas com um
objetivo comum, através de um espaço partilhado. Na colaboração e cooperação é
normal que se contribua ou solicite feedback sobre as soluções de projeto
apresentadas (protótipos ou documentos), estando este na maioria das vezes
associado à discussão (através de sugestões, da concordância/discordância e da
formulação de perguntas) de soluções de projeto. A concordância pode ser total
ou parcial com ressalvas. A discordância pode ser complementada com um
argumento ou apresentada uma proposta alternativa. A clarificação é um fator
essencial da colaboração e cooperação, permitindo o esclarecimento ou
explicação de situações pouco claras ou problemas. A persistência dos elementos
da equipa multidisciplinar é demonstrada na realização das tarefas, nas
sugestões e nas novas soluções de projeto.
- Coordenação: a coordenação organiza a equipa, negociando/atribuindo tarefas
para serem realizadas por determinada ordem, de forma a cumprir os objetivos
propostos. A coordenação tem ainda a responsabilidade de gerir conflitos
associados a atitudes de competição, à desorientação, a problemas de hierarquia
e à difusão de responsabilidade. Compete-lhe preparar a equipa multidisciplinar
para o trabalho colaborativo e cooperativo, através da preparação de ações
(pré-articulação), na execução de tarefas (insistência) e gerindo as
interdependências, tendo em conta que a execução de uma tarefa afeta outras
tarefas e todo o processo de desenvolvimento. Uma caraterística de
interdependência é a reciprocidade, que significa que os elementos da equipa
são mutuamente interdependentes (Molleman, Nauta, & Jehn, 2004).
3. Processo Metodológico
Inúmeras vezes e por diferentes motivos (geográficos, de agenda, entre outros)
as tarefas que constituem o desenvolvimento de software educativo poderão
necessitar de ocorrer à distância. Surgem assim novos desafios aos processos de
desenvolvimento de software, que necessitam de ferramentas que permitam a
interação entre os elementos da equipa multidisciplinar. A utilização de
software colaborativo, normalmente designado como groupware, tem sido explorado
dado integrar diferentes ferramentas de comunicação, de coordenação e de
colaboração e cooperação.
De suporte a estas atividades foi utilizado como software colaborativo
(groupware) a plataforma Learning Management System (LMS) moodle (moodle é um
software livre, de apoio à aprendizagem, que funciona num ambiente virtual).
Apesar de esta plataforma não ter sido desenvolvida especificamente para a
gestão de projetos de desenvolvimento de software educativo, a mesma foi
essencial para a interação entre os elementos da equipa multidisciplinar,
disponibilização de versões de software, debate de ideias, entre outros (Costa
et al., 2010c). A seleção desta plataforma em detrimento de outra deveu-se à
familiaridade e conhecimentos que o Gestor de Projeto detinha sobre a mesma.
Com a finalidade de propor melhorias à Metodologia Híbrida de Desenvolvimento
Centrado no Utilizador (Costa, Loureiro, & Reis, 2009; 2010a; 2010b; Costa,
2012b; Costa; & Costa, 2013), propôs-se identificar os pontos fortes e as
fragilidades da mesma, através de análise das interações que decorreram entre
os elementos da equipa multidisciplinar durante a conceção do Courseware Sere '
O Ser Humano e os Recursos Naturais (Costa, 2012b; Sá et al., 2010; Sá, Guerra,
& Costa, 2012) Apesar de terem sido utilizadas diferentes ferramentas de
comunicação (e-mails, chats, entre outras), a nossa análise e interpretação
recaiu sobre os 292 posts inseridos nos fóruns.
Os fóruns permitiram que as interações ficassem organizadas e disponíveis para
serem revisitadas, podendo ter levado os elementos da equipa a usar esta
ferramenta em detrimento de outras. Além disso, a utilização dos fóruns
permitiu a disponibilização e discussão das soluções de projeto e perceber o
fluxo de posts submetidos pelos diferentes elementos da equipa
multidisciplinar, evidenciando-se uma excelente ferramenta para as atividades
de Coordenação.
Seguidamente apresenta-se parte da análise estatística descritiva bem como
análise de conteúdo da dimensão coordenação (Costa et al., 2014).
4. Análise da Dimensão Coordenação
Análise Estatística Descritiva
Por forma ajudar a compreensão da análise efetuada à dimensão coordenação,
considera-se ser importante perceber o grau de envolvimento dos elementos da
equipa multidisciplinar, de forma a poder analisar e discutir os resultados em
torno de evidências, quantificando assim os posts submetidos e, fundamentá-las,
embora com algumas ressalvas decorrentes do referido envolvimento. Duim,
Anderssin & Sinnema (2007) designam como Free Riders os elementos de uma
equipa multidisciplinar desmotivados/pouco participativos no processo de
desenvolvimento. Os mesmos autores afirmam que a falta de interesse ou a falta
de competências sociais são dois dos fatores que caracterizam estes elementos.
Por outro lado, a falta de interesse, a que se referem não se coaduna com um
dos valores dos métodos ágeis: a responsabilização e a autodisciplina,
caraterísticas que os elementos de uma equipa multidisciplinar devem ter
(Sommerville, 2007).
A figura_4 apresenta a autoria dos 292 posts submetidos pelos elementos da
equipa multidisciplinar, ao longo do processo de desenvolvimento do Courseware
Sere.
Dos 292 posts submetidos, 53,1% (150 posts) são da autoria do Gestor de
Projeto. Os Designers-Ilustradores (A e B) bem como os Programadores (A e B)
envolveram-se minimamente ou não se envolveram (no caso do Designer-Ilustrador
B), na discussão das soluções de projeto através dos fóruns disponibilizados no
moodle(3,4% o que equivale a 10 posts). A falta de interesse foi um dos fatores
que, no decorrer do desenvolvimento do Courseware Sere, levaram à pouca
interação por parte do Programador A e do Designer-Ilustrador B, elementos que
acabaram por ser substituídos no projeto. A pouca participação na discussão das
soluções de projeto, por parte dos designers e dos programadores, pode prender-
se também com o facto de terem uma disponibilidade restrita para o projeto,
como acima indicado.
Associado à coordenação surge o papel do Gestor de Projeto. Das soluções de
projeto submetidas, 77,5% dos posts (100 posts) foram da autoria do Gestor de
Projeto (figura_5a)). Esta percentagem, evidencia uma vez mais, uma maior
envolvência por parte do Gestor de Projeto, apesar da existência de dois
Designers-Ilustradores, elementos da equipa multidisciplinar responsáveis pelo
desenvolvimento técnico dos protótipos em imagem. Uma vez que estes elementos
pouco interagiram nos fóruns, essa responsabilidade recaiu no Gestor do Projeto
(figura_5b)).
No que respeita à submissão de documentos (guiões e outros textos), existiu uma
maior envolvência por parte dos dois investigadores e dos dois peritos da
equipa multidisciplinar. Da figura_5a) conclui-se que estes quatro elementos
submeteram 22,5% dos documentos (29 posts) e que o Gestor do Projeto
disponibilizou 31,8% (41 posts) dos documentos (figura_5b)).
O papel ou responsabilidade do Gestor de Projeto não passou apenas por garantir
a execução das tarefas, alocando recursos por um determinado período de tempo.
Como acima referido, o Gestor de Projeto foi o elemento mais interventivo e
dinâmico. Atendendo à caraterização dos elementos da equipa relativamente à
disponibilidade para o desenvolvimento do Courseware Sere, o facto do Gestor de
Projeto ser o único elemento a tempo inteiro no projeto, pode justificar a sua
maior envolvência.
Análise de Conteúdo
A dimensão Coordenação no modelo proposto abrange a execução de tarefas
(única categoria desta dimensão) e está orientada para o trabalho realizado
pelo Gestor de Projeto ou elementos que assumam este papel (tabela_1). Segundo
Ribeiro (2007), as tarefas numa fase inicial envolvem, normalmente, a definição
de requisitos e a caraterização do software, ou seja, definem o âmbito do
trabalho a desenvolver em termos de dimensão e da complexidade.
A dimensão Coordenação compreende a pré-articulação (18 referências) de ações
de forma a orientar a colaboração e cooperação. A pré-articulação, à
semelhança do que é descrito no método ágil Extreme Programming, como
planeamento incremental (Beck, 2000), facilita a apresentação de forma célere
de um plano global, que evolui durante o ciclo de vida do projeto, sendo
flexível, e alterando com a implementação de funcionalidades, respondendo a
mudanças.
Ao longo do processo de desenvolvimento do courseware, a pré-
articulaçãopermitiu, como sugerem (McChesney & Gallagher, 2004), que a
equipa tivesse conhecimento do que cada elemento estava/ia executar,
potenciando o seu bom desempenho, tal como é evidenciado nas seguintes
referências.
Assunto: Re: Ecrãs
Enviado: Gestor de Projeto, segunda-feira, 9 de junho de 2008, 11:47
Programador-A, Designer-Ilustrador A e Designer-Ilustrador B, coloquei na pasta
de Material em Formato Vetorial, a versão 6.2.
( ) Designer-Ilustrador B está a fazer o MovieClip. ( ) Designer-Ilustrador A
está a fazer as ilustrações para as animações da FASE 2. ( ) Designer-
Ilustrador A as melhorias/alterações que ainda faltam nos ecrãs devem ser
enviadas o quanto antes, para o Programador A efetuar as alterações. ( )
A pré-articulação também teve como propósito identificar objetivos e distribuir
tarefas para serem realizadas pelos elementos da equipa multidisciplinar, como
evidenciam as seguintes referências:
Assunto: Re: Ecrãs
Enviado: Gestor de Projeto, segunda-feira, 9 de junho de 2008, 11:47
( )Programador-A, é necessário começar a animar, por exemplo o ecrã da escolha
das personagens, o ecrã da escolhas das fases, o ecrã da entrada... ( )
Investigador em Didática das Ciências, era importante que os textos desta
legenda ficassem mais pequenos.
( ) Investigadora em Didática das Ciências e Tecnologia Educativa e
Investigadora em Didática das Ciências não se esqueçam dos textos. ( )
Assunto: Re: Ilustrações para animações da Fase II - Cenário 1
Enviado: Gestor de Projeto, quinta-feira, 10 de julho de 2008, 12:30
( ) Ilustrador-Designer A convém ler os textos que a Investigadora em Didática
das Ciências e Tecnologia Educativa fez para a descrição das animações (ver o
wiki que se encontra no espaço da FASE 2). ( ) Perito em Didática das Ciências,
seria importante que verificasse a alteração dos textos da Fase 2 (ver textos).
( )
Assunto: Re: Pegada Ecológica
Enviado: Gestor de Projeto, terça-feira, 13 de janeiro de 2009, 16:02
( ) Investigador em Didática das Ciências e Tecnologia Educativa e o
Investigador em Didática das Ciências: Adaptar a tabela seguinte de forma que
se possa representar por Planetas:
( ) Fazer os textos de introdução e conclusão da Pegada Ecológica;
( ) O Guião de Exploração Didática - Professor deverá ser alterado pela
Investigadora em Didática das Ciências e Tecnologia Educativa e a Investigadora
em Didática das Ciências e ser enviado para a Perita em Tecnologia Educativa e
Perito em Didática das Ciências.
( ) Perita em Tecnologia Educativa e Perito em Didática das Ciências: Verificar
novamente as questões da Pegada Ecológica, mencionando neste espaço quais as
questões em que o utilizador poderá escolher como resposta, mais do que uma
opção.( )
Algumas tarefas não foram atribuídas diretamente a um ou mais elementos da
equipa multidisciplinar. Nestas, era importante o envolvimento da maioria ou de
todos elementos da equipa, numa articulação concertada e criativa, promovendo
assim o trabalho colaborativo. As seguintes referências são exemplos deste tipo
de situações:
Assunto: Ecrãs Fase II
Enviado: Gestor de Projeto, quarta-feira, 21 de maio de 2008, 11:11
( ) É necessário preparar os textos de apoio/ajuda para o Ecrã 1 desta FASE, em
que o aluno/professor irá perceber o que se pretende nesta FASE.( )
Relativamente à descrição dos 6 (seis) cenários, será necessário também,
preparar os textos de apoio o quanto antes.( )
Assunto: Re: Ilustrações para animações da Fase II - Cenário 1
Enviado: Gestor de Projeto, quinta-feira, 10 de julho de 2008, 12:30
( ) Está em anexo a versão 2 do Ecrã 1 (América Norte) para que seja aprovada
pela equipa de projeto.( )
Assunto: Re: Dossiers de Exploração Didática - FASE 1
Enviado: Gestor de Projeto, quarta-feira, 28 de janeiro de 2009, 17:32
( ) Pedia que tentassem ler este guião antes da próxima reunião de forma que a
mesma seja mais produtiva possível. ( )
No desenvolvimento do courseware, não foi dada muita relevância ao fator tempo.
Partiu-se do pressuposto que os elementos da equipa multidisciplinar eram
autodisciplinados e executariam as tarefas da forma mais célere possível.
Contudo, quando tal não sucedida, essencialmente o Gestor de Projeto, submetia
posts de insistência (28 referências), que foram também codificados na
categoria coordenação, apelando à realização das tarefas.
A subcategoria interdependência (48 referências) na realização das tarefas foi
uma atividade essencialmente gerida pelo Gestor de Projeto, realçando assim,
uma vez mais, a reduzida alternância de coordenação no decorrer do processo de
desenvolvimento (ver tabela_2).
Uma caraterística da interdependência é a reciprocidade, o que significa que os
elementos da equipa são mutuamente interdependentes (Molleman et al., 2004). A
subcategoria interdependência foi dividida em dois indicadores:
interdependência direcionada e interdependência geral. Na interdependência
direcionada, os posts eram submetidos ao conhecimento de todos os elementos
mas, no seu conteúdo, continha palavras/frases que os direcionavam apenas para
determinado(s) elemento(s) da equipa multidisciplinar, como exemplificado a
seguir.
Assunto: Re: Manchas Florestais
Enviado: Perito em Didática das Ciências, domingo, 18 de janeiro de 2009, 22:06
( ) Peço à Investigadora em Didática das Ciências e Tecnologia Educativa para
consultar um docente do Depart. de Biologia da UA ou UP para confirmar as
designações das várias florestas.( )
Tendo em conta o acima ilustrado, pode associar-se a interdependência
direcionada à divisão ou atribuição de tarefas e, por conseguinte à pré-
articulação e ao trabalho cooperativo, ou seja, a execução de tarefas de modo
individual em que o seu resultado será a base de trabalho de outro elemento
(podendo ser o elemento anterior), ocorrendo iterações até ao incremento na
solução global.
Na interdependência geral, um ou vários elementos aguardam por feedback dos
outros elementos da equipa multidisciplinar para avançar com a execução de
determinada tarefa. Esta interdependência geral também pode ter lugar quando um
dos elementos necessita de feedback de parte ou de todos os elementos da equipa
multidisciplinar.
Assunto: Re: Ecrãs Fase II
Enviado: Gestor de Projeto, domingo, 25 de maio de 2008, 18:15
Interfaces_Fase2_vers2.pdf
Boa tarde, é necessário que deixem ficar as Vossas opiniões relativamente aos
Ecrãs da Fase 2.( )
As mensagens de insistência (28 referências) podem ser uma repetição de uma
mensagem de pré-articulação ou interdependência que é submetida/enviada por
ausência de feedbackdos destinatários. Na referência seguinte, o Gestor de
Projeto insistiu no feedbackdos elementos da equipa multidisciplinar, de forma
a que Designer-Ilustrador B pudesse continuar a ilustração dos cenários
(exemplo de interdependência). O primeiro post,enviado a 2 de junho de 2008, é
exatamente igual ao que se apresenta nesta referência (segundo post), enviado a
23 de junho de 2008.
Assunto:Re: Ecrãs Fase II
Enviado: Gestor de Projeto, segunda-feira, 23 de junho de 2008, 02:20
Boa noite, deixo ficar esta mensagem tendo em vista recolher a Vossa opinião
sobre a forma como irão surgir as animações da Fase II. Passo a descrever as
imagens abaixo apresentadas.
Quando o utilizador escolhe no Planisfério África, surge o 1º ecrã, que passará
em 3 segundos para o 2º ecrã. Sendo assim:
O tipo de ilustração adequa-se ao que é pretendido?
Era necessário saber isto o quanto antes, para o Designer-Ilustrador B poder
ilustrar os 5 cenários que faltam. ( )
A maioria das mensagens de insistência foi enviada quando um ou vários
elementos não contribuíram para resolução da situação ou problema. As
referências seguintes evidenciam mensagens de insistênciacujo enfoque se rendia
com a validação de soluções de projeto, mais especificamente no que respeita ao
manual de utilização do courseware:
Assunto: Re: Introdução e Manual de Utilizador
Enviado: Gestor de Projeto, sexta-feira, 16 de janeiro de 2009, 16:22
Introd_MUtilizador_vers2.5_.doc
( ) Pedia que voltassem a rever o documento que segue em anexo.( )
Assunto: Re: Introdução e Manual de Utilizador
Enviado: Gestor de Projeto, domingo, 25 de janeiro de 2009, 23:57
ManualUtilizador_vers3_.doc
Pedia que verificassem o Manual do Utilizador de forma a poder terminar
paginação do mesmo.( )
Assunto: Re: Introdução e Manual de Utilizador
Enviado: Gestor de Projeto, quinta-feira, 29 de janeiro de 2009, 10:54
ManualUtilizador_vers3.2_.doc
Bom dia, pedia a todos que verificassem o Manual do Utilizador. ( )
Pode ocorrer ausência de feedback, por partes dos elementos da equipa, por
diferentes motivos: não se identificam como responsáveis pela realização da
tarefa; falta de disponibilidade por estarem a realizar outras tarefas; ou
considerarem que o seu contributo não é necessário.
O excesso de posts com atribuição de tarefas, a alteração de soluções de
projeto, entre outros, pode levar ao surgimento de conflitos. Esta subcategoria
definida dentro da categoria tarefas, está dividida em quatro indicadores:
competição, desorientação, problemas de hierarquia e a difusão da
responsabilidade (Acuna et al., 2009). Nos 292 posts analisados, apenas
extraímos dois estratos que evidenciam situações de conflito: desorientação (1ª
referência) e difusão da responsabilidade (2ª referência) respetivamente.
Assunto: Re: Ecrãs Fase II
Enviado: Designer-Ilustrador A, terça-feira, 3 de junho de 2008, 03:05
( ) vou desenhar pandas, ursos, floresta, tipos a cortar árvores?( ) isso não
ficou esclarecido...está muito em fase embrionária. ( ) as animações não podem
ser feitas assim. eu não consigo...( ) Mas não sei mais concretamente o que
hei-de desenhar para compor uma animação para cada um dos cenários...( )
Assunto: Re: Pegada Ecológica
Enviado: Perito em Didática das Ciências, sexta-feira, 23 de janeiro de 2009,
16:28
( ) Quanto à validação de peritos (das áreas "científicas" mais focadas no
courseware) face à falta de tempo, proponho já o compromisso de, depois, com
uma versão completa, pedir (e pagar, o que penso que será a LudoMedia) a 2
peritos (um deles eu tenho já uma ideia face à qualidade do que faz a este
nível) a revisão e na 2ªedição incluir na ficha técnica (ver como se fez nos
guiões didáticos do PFEEC do 1º CEB) o nome destes dois revisores científicos.
( ) Bem, isto não é discutível, nem calendarizável. ( )
Considera-se que a ausência de conflitos do tipo problemas de hierarquia e
competição pode ser positiva. Contudo, pode também ser um indicador de pouco
envolvimento na discussão de soluções de projeto, não contribuindo ou marcando
posições que levem ao surgimento de conflitos. Um conflito provocado e
controlado pode ser um fator impulsionador para que elementos com reduzida
participação se envolvam mais no projeto. Por outro lado, os conflitos quando
descontrolados e mal geridos podem levar ao término de um projeto (Acuna et
al., 2009).
Conclusões
A coordenação do projeto tem que estar sensibilizada para diferentes situações.
Por exemplo, os autores Duim, Anderssin & Sinnema (Duim, Andersson, &
Sinnema, 2007) designam como Free Riders os elementos de uma equipa
multidisciplinar desmotivados/pouco participativos no processo de
desenvolvimento. Os mesmos autores afirmam que a falta de interesse ou a falta
de competências sociais são dois dos fatores que caraterizam estes elementos.
Por outro lado, a falta de interesse, a que se referem não se coaduna com um
dos valores dos métodos ágeis: a responsabilização e a autodisciplina,
caraterísticas que os elementos de uma equipa multidisciplinar devem ter
(Sommerville, 2007).
A falha de compromissos e o pouco envolvimento, conduziu a que durante o
processo de desenvolvimento o Designer-Ilustrador A e o Programador A fossem
dispensados/substituídos do projeto. O Designer-Ilustrador B deu continuidade
ao projeto, acumulando os papéis e responsabilidades do Designer-Ilustrador A.
Este processo foi facilitado pelo facto deste colaborador já ser um elemento da
equipa multidisciplinar. O Programador B foi contratado para substituir o
Programador A, tendo sido necessário algum tempo para que se integrasse na
equipa multidisciplinar.
