Como lidar com essa situação infelizmente não hipotética com os usuários finais?

22

Eu trabalho em uma empresa de médio porte, mas com uma força de TI muito pequena.

No ano passado (2011), escrevi um aplicativo muito popular entre um grande grupo de usuários finais. Atingimos um prazo no final do ano passado e algumas funcionalidades (chamarei de funcA a partir de agora) não foram adicionadas ao aplicativo desejado no final. Portanto, esse aplicativo está em execução ao vivo / produção desde o final de 2011, devo acrescentar sem problemas.

Ontem, um grupo inteiro de usuários finais começou a reclamar que a função que nunca estava no aplicativo não está mais funcionando. Nossa prioridade nesta empresa é que, se um aplicativo for quebrado, ele deve ser corrigido primeiro antes dos projetos priorizados.

Comparei código e consultas e não há diferença desde 2011, o que é proofA. Consegui, então, convencer um dos usuários finais a admitir que nunca funcionou com o proofB, mas desde então o usuário final voltou e disse que estava trabalhando anteriormente ... Acredito que a horda de usuários finais tenha assimilado dela. Também revi minhas notas para este projeto, que possui requisitos e atualizações diárias sobre o projeto que afirma especificamente "a função não foi alcançada devido a restrições de tempo", proofC.

Conversei com muitos deles e posso ver onde eles podem ser confundidos, pois estão muito distantes do contexto da programação, mas também sei que eles são inteligentes o suficiente para atuar em um grupo, a fim de ignorar as ordens de priorização do projeto, a fim de obter funcionalidade que eles desejam para facilitar seu trabalho.

A pior parte é que agora o pensamento do grupo está se estabelecendo e meu chefe e o chefe de TI estão realmente começando a acreditar neles, mesmo que não haja alterações no código ou na consulta. No que diz respeito à revisão do estado da lógica, ela é muito cortada e seca ao ponto de se 1 = 1, funcA não funcionará.

Portanto, este é o fim da descrição do meu cenário, mas estou tentando não me atrapalhar com as métricas de desempenho devido a isso, que essencialmente me levou a corrigir um problema de produção que não existe que provavelmente assumirá o controle 1 mês.

project-management requirements maintenance

— Usuário Smith
fonte

1

Não somos um fórum no sentido tradicional da palavra, somos um site de perguntas e respostas que procura perguntas respondíveis. Discursos, pesquisas e discussões geralmente não se encaixam no nosso formato.

— maple_shaft

12

@ maple_shaft: eu discordo. Essa é uma pergunta séria, procurando uma maneira de lidar com um problema real que ocorre ao lidar com, digamos, usuários finais menos do que indiscutíveis. Todos nós já vimos e ficamos frustrados com isso, não é? Portanto, idéias sobre como lidar com esses cenários são muito boas para o formato deste site.

— Mason Wheeler

1

Não é possível que haja uma resposta para esta pergunta? Quem vigiará os vigilantes?

— Usuário Smith

2

Para beneficiar outras pessoas que estão lendo isso, este caso representa outra lição para aqueles que acreditam que a documentação é secundária e que os requisitos de canto não são importantes.

— precisa saber é o seguinte

1

"nada mudou" famosas últimas palavras.

— Jeffo

18

Disputas sobre fatos facilmente observáveis são realmente fáceis de resolver: basta observar os fatos. Se eu disser "há uma árvore com madeira púrpura do lado de fora da minha casa", qualquer pessoa que possa vir à minha casa poderá verificar a verdade ou a falsidade da minha afirmação por si mesma.

Se eles estão reclamando que o FuncA costumava estar no produto e costumava funcionar em uma versão anterior e agora não está funcionando, e você acha que nunca esteve no produto, peça a eles que o provem. (Ou, em palavras mais gentis, diga algo como "estamos tendo problemas para reproduzir o problema. Você poderia nos ajudar aqui?")

Dê a eles uma cópia da versão anterior, se ainda não tiverem, e obtenha-os no LiveMeeting, e mostre como eles costumavam usar o FuncA. Se eles não puderem fazer isso, então (esperançosamente) eles perceberão que não estava lá depois e sairão do seu caso a respeito, ou pelo menos tentarão uma tática diferente para implementá-lo. (E certifique-se de incluir alguém da gerência ou da PM no LiveMeeting.)

— Mason Wheeler
fonte

Eles mostraram uma captura de tela da prova que eu posso explicar, mas é apenas parcial, portanto os detalhes do cenário são o que eles dizem que não são realmente definidos por meio da captura de tela. Basicamente, o que se resume é que o MGMT não está muito ciente da lógica e, neste momento, é a palavra de um departamento inteiro contra um humilde programador. (Além disso, a versão anterior é igual à distribuição inicial que ocorreu em 2011)

— User Smith

3

@UserSmith: É por isso que eu disse para usar um LiveMeeting. É mais difícil confundir o que está acontecendo quando você realmente precisa executá-lo com as pessoas assistindo.

— Mason Wheeler

1

Essa resposta fornece uma definição de prova muito melhor do que "o usuário final diz isso" ou "Eu li o código". Pare e lembre-se das últimas 10 vezes que, como programador, você ficou completamente pasmo que poderia estar tão errado, apesar de olhar para 1 = 1 no código (quando deveria ter sido 1 == 1, por exemplo). Se você pensa na prova em termos de "leitura de código" como um ser humano propenso a erros, francamente suas métricas de desempenho devem ser afetadas. A @MasonWheeler propôs uma epistemologia mais precisa e atraente, convém que você a siga.

— precisa saber é o seguinte

Nas negociações, há um ditado "Se você tem que se defender, você já perdeu". A prova de fatos é a forma final de defesa - como regra, é melhor não, a menos que seja solicitado, mesmo assim, que seja mantido breve - menos é mais.

— mattnz

1

Marcado como resposta, provavelmente a resposta mais concreta. Embora eu já tivesse feito reuniões ao vivo antes de postar esta pergunta. Além disso, algumas outras respostas parcialmente boas. Honestamente, neste ponto, não me importo com minhas métricas, é mais o fato de que a estrutura fundamental de nossa organização de TI está em tal estado de confusão que isso está ocorrendo e me preocupa.

— usuário Smith

13

Esta não é uma questão que possa ser tratada com fatos - se você tentar, perderá credibilidade.

Primeiro, aceite que o software está "quebrado" - pois não faz o que os usuários desejam. Agora, aceite que os usuários têm o direito de fazer com que o software faça o que eles querem - é o que o software é, portanto. Então, o que temos é um software defeituoso e um engenheiro se recusando a corrigi-lo ...

Como resultado, se o sistema que você executa para definir prioridades, esses usuários não conseguem consertar seu software através dos canais normais, eles estão usando canais secundários e escalando meias verdades mais altas na cadeia alimentar para tentar manobrar o sistema. nesse meio tempo, fazendo com que seus KPIs pareçam ruins (sua principal preocupação deve ser os clientes, não os KPIs) - Seus KPIs são considerados "danos colaterais" se eles gostam de você, ou um efeito colateral benéfico se não o fizerem. No entanto, eles têm algum controle sobre o quanto acontece - melhor eles gostam de você.

Então, o que está acontecendo é que o sistema está quebrado e todo mundo está tentando manipular as coisas para conseguir o que deseja. Eles querem um recurso e você deseja manter seus KPIs impecáveis.

A menos que você possa consertar o sistema ou aprender a jogar com a política do escritório rapidamente, o jogo acaba: você perde.

Nota: Nenhuma dessas discussões envolve deadlines, discussões sobre bug versus recurso, quem está pagando etc. Esses são fatos - e fatos não importam (bem, eles meio que importam, mas podem ser manipulados de várias maneiras .... ) na política do escritório.

— mattnz
fonte

1

Como você pode perder credibilidade se pode provar ?

— Thomas Eding

3

@ThomasEding Credibilidade no mundo dos negócios é mais sobre como os outros o percebem do que sobre fatos. Se você se tornar um alvo, nenhuma quantidade de fatos o protegerá. Quantos desenvolvedores de estrelas do rock você conheceu que eram fraudes completas? Eu conheci mais do que gostaria de admitir.

— maple_shaft

2

Eu concordo com boa parte disso, é definitivamente uma forma de política de escritório. Quando encontrava qualquer situação, eu pensava que o primeiro curso de ação seria lidar com os fatos, então você meio que me perdeu por lá, mas eu concordaria que os clientes chegassem primeiro aos kpis em segundo até certo ponto, até que você fosse demitido. +1 para uma visão diferente da situação. +1

— Usuário Smith

2

Nunca reclame nunca explique. Discutir faz você parecer fraco. Ouvir pedidos educados é bom. É bom dizer que você discutirá o pedido deles com seu chefe para obter prioridade. Se você argumenta, então faça o que eles gritaram, isso reforça o comportamento desagradável deles. Se eles aumentarem, o poder de posição do seu chefe reforça a polidez. Seu chefe pode explicar diplomaticamente sua escolha para o seu tempo. Também mostra que eles não são seus chefes. Quando você aborda o problema em silêncio com seu chefe, pode ouvir palavras como "não se preocupe, eu te protejo". Mantenha-se focado, faça o produto, as reclamações vão parar.

— DeveloperDon

@thomas Pergunte a qualquer inocente acusado se um crime imoral particulay ....

— mattnz

9

Organizacionalmente, sinto um problema.

Existe uma hierarquia que inclui o chefe de TI e seu chefe. Se sua organização é tradicional (não parece Agile), você é um recurso e eles são gerenciadores de recursos. Você tem um emprego em período integral chamado desenvolvimento de software. Se os usuários finais estão solicitando recursos diretamente, definindo suas prioridades e tentando gerenciar seu tempo, seus gerentes são redundantes. Eles podem ser responsáveis perante os usuários finais, mas se eles estão fazendo o trabalho deles, você é responsável perante eles e eles precisam protegê-lo de sair do modo de desenvolvedor focado para o modo de desenvolvedor defensivo .

Alguns pontos para definir o contexto da minha resposta:

Os desenvolvedores de software não são viajantes do tempo; portanto, os resultados precisam ser julgados pelo que são, não pelo que poderiam ter sido.
Se um recurso estava em uma especificação de requisitos, um cronograma e foi priorizado acima do trabalho concluído, pode haver uma reclamação legítima. Caso contrário, qual é a justificativa para responsabilizá-lo?
Seu castigo, se merecido, precisa vir de sua cadeia de comando. Assim como o marketing e as vendas não gostariam se o desenvolvimento do produto censurasse os clientes, a maioria das organizações possui gerentes de produto para receber a ira (e elogios) do cliente e transmiti-la pelos canais.
Os gerentes de produto podem criar relacionamentos extremamente difíceis se aproveitarem o calor de partes bem-sucedidas dos projetos, mas apenas quebram o chicote quando encaram os desenvolvedores.
Se você entregou um produto funcional com um ano de trabalho e leva um mês (ou dois) para adicionar o recurso desejado, pelo que vi em nosso setor, sua estimativa foi acima da média.
Resolver o problema de maneira justa e produtiva exige que as pessoas voltem a colocar os dedos da culpa nos bolsos e façam um plano de avanço.

Você será capaz de fazer um trabalho de qualidade muito melhor e com mais motivação se for apreciado em vez de ser o bode em um processo que o chefe de TI deve possuir. É o caminho justo e o caminho produtivo. Espero que você seja gerenciado dessa maneira e, em algum momento no futuro, espero que você gerencie os outros dessa maneira.

— DesenvolvedorDon
fonte

DevDon, gostaria que isso acontecesse com a resposta nº 1, pois acho que isso é uma grande parte do nosso problema .... nossa estrutura de TI para esse cenário é extremamente aleatória. +1

— Usuário Smith

1

Em caso de falha da realidade como essa, a melhor coisa é seguir em frente. Em vez de discutir sobre o passado, fale sobre como fazê-lo funcionar e quão fácil ou difícil será. Realmente não importa se o problema está corrigindo ou implementando pela primeira vez. Se a gerência deseja que A seja feito antes de B, faça isso.

— ddyer
fonte

É claro que isso é verdade, mas quando o usuário final descobrir que pode manipular o sistema dessa maneira, minha empresa estará em uma séria inclinação descendente se isso continuar, pois os recursos serão usados dessa maneira, em vez de serem usados para estratégias estratégicas gerais da empresa. diretrizes que realmente direcionem os resultados da empresa.

— usuário Smith

0

Você é o único desenvolvedor a ter trabalhado neste projeto? Parece que você respondeu a alguém enquanto fazia o projeto. Onde está essa pessoa em tudo isso? Onde está a documentação do projeto dizendo o que foi entregue?

Deve haver uma trilha de papel de documento. Um documento de treinamento mostrando como usar o aplicativo. Uma especificação funcional descrevendo o que foi desenvolvido. Se um recurso não foi incluído, também deve haver documentação. Alguém deveria ter tido que assinar dizendo que aceita isso.

Não deve ser a sua palavra contra a deles, deve estar toda na documentação.

Se você não possui esta documentação ... então, temo que você precise morder esta. Considere isso uma lição de vida. No final do dia, seus usuários são seus clientes e, como diz o ditado: o cliente está sempre certo. Elabore como adicionar esse recurso e quanto tempo levará. Faça uma reunião e diga algo como 'Nossos registros mostram que esse recurso nunca foi implementado, mas podemos obter vida útil em x semanas. Devemos ir à cabeça?

E pelo amor de tudo o que é sagrado ... obtenha a documentação necessária para mostrar que foi aprovada.

— Tyanna
fonte

Sim, eu fui o único que trabalhou neste projeto. Há documentação com atualizações diárias que chamei de proofC na minha pergunta.

— usuário Smith

@UserSmith ~ Entendi que isso significava mais uma atualização de status diária. Essa não é realmente a documentação que eu estava falando. Alguém assinou o produto final? Existe treinamento ou alguma documentação de aplicação que você forneceu ao usuário final ou ao interessado?

— Tyanna 29/09/12

Infelizmente não. Houve treinamento, mas período muito curto de treinamento. Há documentação do aplicativo, mas não cobre a falta dessa funcionalidade. As atualizações diárias são basicamente uma ferramenta de diário que usamos para descrever descrições iniciais, diárias e finais do que aconteceu com um projeto.

— usuário Smith