Como convencer a gerência a jogar fora um protótipo?

Adoro a prototipagem como uma maneira rápida e eficaz de colocar uma interface do usuário na frente de um usuário.

Muitas vezes, porém, a gerência atrapalha o processo, e o protótipo é arrastado para o desenvolvimento do fluxo principal.

Como você gerencia o gerenciamento para não fazer isso?

Use uma ferramenta como o Microsoft SketchFlow ou faça seu protótipo em outro idioma ou plataforma, tornando quase impossível a integração no desenvolvimento principal.

Há também um ensaio sobre software de joelons sobre mostrar capturas de tela e protótipos, onde ele faz com que aspectos não implementados e não executados pareçam obviamente quebrados / não implementados, deixando claro onde o trabalho ainda precisa ser feito.

Corolário importante dois. Se você mostrar a um não programador uma tela com uma interface de usuário 100% bonita, eles acharão que o programa está quase pronto.

...

O que você pode fazer em relação à isso? Depois de entender o segredo do iceberg, é fácil trabalhar com ele. Entenda que qualquer demonstração que você faça em uma sala escura com um projetor será sobre pixels. Se possível, crie sua interface do usuário de forma que as partes inacabadas pareçam inacabadas. Por exemplo, use rabiscos para os ícones na barra de ferramentas até que a funcionalidade esteja lá. Ao criar seu serviço da web, considere realmente deixar de fora os recursos da página inicial até que esses recursos sejam criados. Dessa forma, as pessoas podem assistir a página inicial passar de 3 para 20 comandos à medida que mais coisas são construídas.

Portanto, tente criar seus protótipos no Photoshop em vez do Visual Studio, ou algo assim.

Não protótipo com código de trabalho. Protótipo com lápis e papel, ou um equivalente de software .

Usar Mockups é como desenhar, mas como é digital, você pode ajustar e reorganizar facilmente. As equipes podem criar um design e iterá-lo em tempo real no decorrer de uma reunião.

Usar papel tem o benefício que os membros da equipe podem facilmente acessar, e todos entendem que é apenas uma folha de papel em branco. Isso faz com que pareça menos precioso.

Nunca comprometa a qualidade do seu código.

Escrever código não solicitado é uma economia falsa.

Como outros pôsteres sugeriram, você pode conseguir isso usando ferramentas específicas para maquetes.

No entanto, existem diferentes razões para criar protótipos. Às vezes, você pode mostrar o que precisa sem escrever código, mas geralmente esse não é o caso. Uma parte interessada pode querer que você demonstre a viabilidade técnica de um recurso.

Crie a coisa mais enxuta possível para demonstrar o recurso / provar o conceito. Deixe de fora qualquer outra coisa.

Para um recurso de interface do usuário, certifique-se de não desenvolver nada no servidor - não toque nele. Desenvolva novamente zombarias / falsificações incorporadas.

Se você precisar se esforçar para tornar a interface do usuário compatível com o estilo do restante do aplicativo, não se preocupe. Se parecer bom o suficiente sem nenhum esforço, altere as cores para destacá-lo, ou talvez até uma marca d'água para mostrar que é um protótipo.

Descobri que os criminosos mais prováveis ​​de fazer com que os protótipos se transformem em código de produção são os vendedores. Eles venderão seu produto para um novo cliente - sem esse novo recurso, o cliente não teria assinado. Você não pode culpá-los, eles têm alvos. Tenha cuidado com eles; certifique-se de que eles não façam você tirar as coisas que indicam que é um protótipo. Você tem que defender sua posição - eles provavelmente não deveriam ser clientes enganadores de qualquer maneira.

Seu gerenciamento pode começar a forçá-lo a transformar um protótipo em código de produção, peça por peça. Se você seguiu meu primeiro conselho para nunca escrever códigos ruins, não deve haver problema. Gradualmente, você constrói o software, sem compromisso.

Então, se a gerência começar a forçá-lo a reduzir a qualidade, você deverá se perguntar por quê. Eles são passivos? fraco? desesperado? Nenhuma dessas coisas são boas razões para permanecer na empresa.

Muito simples mesmo. Diga a eles que eles acabariam perdendo seu cliente favorito se acabassem colocando essa bagunça de buggy à mostra.

E sim, peça a eles que se arrisquem se souberem melhor.

Finalmente: por favor, não diga que o protótipo possui bugs específicos A, B e C. Em seguida, você deve corrigi-lo, e a gerência alegará que eles canalizaram energia para preparar a produção de software.

As chances são de que esses bônus de desempenho e as concessões de ações futuras nos dias de hoje eles vão ouvir.

Evite o problema em primeiro lugar. Não termine. Com isso, quero dizer, não faça com que pareça bonito ou que se encaixe nos estilos existentes no site. O objetivo é simplesmente obter a versão de trabalho mais bruta possível para que você possa ver que o fluxo da interface do usuário muito básico funciona. Se você lançar o estilo de site existente ou polir excessivamente, eles assumirão que você pode simplesmente "conectá-lo". Gerenciamento é como Pakleds de Star Trek. Eles só querem que você "faça acontecer". Quanto mais pronto você parecer, mais pronto eles vão pensar que é.

Se isso não resolver o seu problema, arrume um emprego em pelo menos uma empresa com uma marca conhecida por um ano. Coloque seu e-mail e número em um currículo on-line e você estará combatendo os recrutadores de volta com um bastão, o que permitirá dizer a eles "absolutamente não" com a confiança de um desenvolvedor que sabe o que está fazendo e pode conseguir um novo emprego amanhã, onde esperamos que sua experiência no assunto seja levada mais a sério.

Atualmente, estou trabalhando em uma base de código que não tem dois, mas um golpe de pilha tripla do Rails, .NET e Java. A razão pela qual colocamos o Rails no ar foi porque um protótipo foi feito no Rails e o principal executivo da empresa disse "faça isso". Às vezes precisamos dizer não. Contanto que não façamos isso o tempo todo, eles devem nos levar a sério.

Mas sim, o que você faz com um protótipo, verifique se ele começa realmente feio.

Não se preocupe com isso.

Se você se senta e joga controles de interface do usuário para um "protótipo", há exatamente zero motivo para você sempre jogar fora esse design automaticamente. Se foi bom o suficiente para mostrar o gerenciamento, é um bom lugar para começar quando codificar o programa "real".

Mover de um protótipo para uma interface mais "polida" não deve ser mais do que uma série de etapas inteiramente justificáveis. Você teve que adicionar um segundo botão. Você recebeu comentários dos usuários de que eles acharam o pedido confuso. O grupo de padrões da sua organização determinou uma pequena alteração. Você teve que alterar o tamanho de uma caixa de texto para internacionalização.

Nenhuma dessas razões é "bem, era apenas um protótipo". No design da interface do usuário ou no código ou por escrito, QUALQUER COISA pode acabar vivendo para sempre. E aqueles que nem todos devem ter boas razões para matá-los.

E a gerência provavelmente não se importa.

Realisticamente, se o motivo pelo qual você não soltou sua interface do usuário no código existente foi "Eu tive que reescrevê-lo em nossa estrutura correta", isso deve ser o suficiente. E se não fosse, você provavelmente deveria ter uma discussão sobre a própria estrutura da interface do usuário, mas essa é outra questão.

Eu costumava ter esse problema, até que percebi que não era um problema, mas uma maneira de me libertar dos padrões de desenvolvimento bastante desatualizados impostos na maioria das lojas.

Então, você diz à gerência que está escrevendo um protótipo, escolhe as tecnologias que funcionam melhor para você nesta área problemática e depois escreve o software com o conhecimento total de que ele entrará em produção.

Você evita o tédio de "os aplicativos devem estar em java 1.6 usando a Web (insira o mecanismo J2EE caro de escolha de gerenciamento)" e os padrões de nomeação inúteis etc.

Minhas linguagens de protótipo atuais são "php" (que é totalmente escalável para ambientes de produção pesados ​​- basta perguntar ao Facebook) e a combinação muito elegante de Groovy / Java com Tomcat ou Jetty.

A combinação groovy / java é ótima para o desenvolvimento rápido. É fácil usar o Groovy de desenvolvimento rápido, mas funciona como um caracol geriátrico, no entanto, é trivialmente fácil re-fatorar seções críticas de desempenho no Java puro. Casamento do aplicativo com Tomcat ou Jetty significa nunca ter que lidar com EJBs e outros horrores J2EE novamente.

A principal vantagem de ter um protótipo funcional em oposição a um esboço proposto por vários pôsteres é o feedback do usuário. Os protótipos são uma ótima maneira de envolver verdadeiramente os negócios no design. Quando eles percebem que podem dizer coisas como "esse campo não deveria estar na tela principal" e pronto! lá está, na tela principal, na próxima demonstração, eles se abrem e se envolvem no design, trazendo anos de valiosa experiência comercial para o projeto.