Contratação de desenvolvimento de software; entregar histórias de usuários ou requisitos de negócios?

5

Somos uma pequena empresa na qual eu sou desenvolvedor líder, e temos tido reuniões ativas com possíveis interessados para uma boa oportunidade. Esta parte interessada está nos ajudando diretamente na obtenção de uma proposta junto a um grupo de outras partes interessadas para o software para o qual elas têm uma grande necessidade. Espero que, se os vendermos em nossa proposta (consistindo de recursos de alto nível e resultados gerais), eles patrocinarão o projeto e crescerão organicamente de lá para os usuários de todo o país, que verão como isso é útil.

O problema é que nós, como um desenvolvimento, estamos terrivelmente atolados, como ocorre em projetos anteriores, na manutenção de sistemas de produção existentes e em recursos desnecessários no backlog. Tal como está, porque este projeto pode ser altamente lucrativo e não existem concorrentes sérios, a gerência quer agir rápido e obter as funcionalidades mais básicas o mais rápido possível, independentemente do custo .

Isso não é realista para nós sem aumentar nossa equipe, mas isso leva muito tempo. Eles estão pensando em contratar o trabalho de desenvolvimento, mas querem que eu seja um analista de negócios e também tenha uma palavra arquitetônica no projeto. Quando terminam o desenvolvimento de grandes recursos, eles antecipam que a minha equipe assume a responsabilidade pela manutenção, portanto, claramente, o controle arquitetônico é importante, pois queremos que as entregas sejam passíveis de manutenção.

Estou bem com este papel, mas não estou acostumado a isso. Internamente, normalmente não usamos documentos de requisitos formalizados e, em vez disso, coletamos requisitos de histórias de usuários, casos de uso, fluxos de trabalho e contratos com clientes. Estamos acostumados a formular histórias de usuários, mas temo que não faça sentido entregar histórias de usuários a uma empresa terceirizada, pois elas provavelmente terão sua própria gestão de projeto, que pode querer fazer as coisas do seu jeito. Eu não gostaria de impor nosso processo de gerenciamento de projetos não familiar a eles se eles acharem que é estranho e isso os atrasa.

Estou pensando que os requisitos de negócios formalizados extremamente detalhados estão em ordem porque queremos ter certeza de que eles têm as diretrizes necessárias para criar um software de qualidade, mas não tenho ideia de que tipo de esforço isso levará sozinho. Eu também não tenho certeza de quando começar. Nada é oficial ainda, mas tenho 90% das informações que eu sinto que preciso das partes interessadas. Eu só não quero acabar com a gerência me informando que o acordo foi assinado, temos que entregar em 6 meses e obter todos os documentos de requisitos até o final da semana.

Sentindo-se um pouco acima da minha cabeça aqui, eu formulo histórias de usuários ou requisitos de negócios? Alguma outra sugestão útil?

    
por maple_shaft 20.12.2011 / 13:46
fonte

3 respostas

1

I am afraid that doesn't make sense to deliver user stories to an outside contract company as they will likely have their own project managment who might want to do things their way

Você é o cliente, e você estará pagando a eles ... diga a eles o que eles receberão. Além disso, eu não acho que é particularmente importante que formato os requisitos sejam entregues, qualquer desenvolvedor decente deve ser capaz de trabalhar com qualquer um deles.

Pessoalmente, eu pensaria em contratar alguns contratados / freelancers individuais em vez de uma grande consultoria. Você pode acabar contratando as pessoas que a consultoria teria contratado, será mais barato e você terá um relacionamento mais próximo com os desenvolvedores.

    
por 20.12.2011 / 14:29
fonte
1

Em vez de determinar como você apresentará seus requisitos, primeiro concentre-se em encontrar alguém para construir o sistema, de preferência dentro do custo e do cronograma aceitáveis para sua organização. O processo deve começar com a criação de uma visão geral de alto nível que delineie os objetivos do projeto, antecedentes e motivações, requisitos de alto nível, especifique exatamente o que está no escopo e fora do escopo e as entregas necessárias. Ao mesmo tempo em que isso está acontecendo, o departamento jurídico também estaria envolvido para determinar a propriedade intelectual, os NDAs, qualquer tipo de conformidade regulatória necessária ao subcontratado e assim por diante. Ambos os documentos seriam disponibilizados aos contratantes em potencial para fornecer as informações necessárias para construir uma proposta que abordasse o cronograma, o orçamento, os recursos e até mesmo alguns riscos.

Neste ponto, torna-se uma negociação. Você pode obter uma série de custos ou cronogramas que estão fora de sintonia com suas expectativas, e nesse ponto você pode precisar revisitar o que está disposto a investir ou reduzir o tamanho e o escopo do projeto. Pode haver outras perguntas de contratantes em potencial que precisam ser respondidas para fornecer informações. Há um período de ida e volta aqui para resolver mais alguns detalhes necessários para realizar o projeto. Se você nunca esteve envolvido em uma negociação, recomendo os livros Como chegar a sim: negociação do contrato sem dar entrada e Passando Não: Negociando em Situações Difíceis .

Com base em seus critérios, depois de selecionar um contratado, o nível de envolvimento depende do que é negociado. Eu pessoalmente vi tudo a partir do contratante sendo uma caixa preta que recebe os requisitos e, em uma base regular, envia os artefatos solicitados e entregas para o contratante, sendo uma caixa de vidro com um cliente que está sempre ou rotineiramente no local, ativamente envolvido no processo de desenvolvimento. E há muitos tons de cinza no meio, com diferentes níveis de envolvimento entre o cliente e o contratado. Em última análise, isso depende do contrato e do acordo entre o cliente (sua organização) e o construtor.

Desde que você mencionou que sua organização receberá o produto e continuará a manutenção e desenvolvimento nele, eu gastaria tempo extra investigando potenciais contratados em seu processo de desenvolvimento e práticas de garantia de qualidade. Eu também tentaria maximizar a visibilidade de seus processos e produtos durante a vigência do contrato, para que você pudesse identificar problemas em potencial antecipadamente e tomar medidas corretivas. Portanto, você deve trabalhar com a empresa contratante para descrever suas funções e responsabilidades para o projeto, bem como suas responsabilidades para com sua organização. No entanto, como eu disse, é uma negociação, então você pode não ter 100% de tudo que você quer.

Outra opção seria contratar empreiteiros temporários internos, supondo que você tenha os recursos para que eles trabalhem. Eles precisariam de algum tipo de lead (que eu diria que seria você), computadores, servidores de compilação, um ambiente de reunião ou colaboração, espaço na mesa e assim por diante. Sua organização também teria que gastar tempo entrevistando candidatos e encontrando pessoas que trabalhassem bem juntas e talvez dentro de sua organização. No entanto, também pode levar a funcionários em tempo integral no futuro.

Nesta situação, você pode ditar o processo de desenvolvimento e ter um grande controle sobre como as coisas são feitas. Mas você também tem os custos, como adicionar pessoas e infraestrutura para lidar. Pode ou não ser mais eficaz em termos de custos, mas pode ser algo a considerar, especialmente se sua empresa pode estar procurando expandir-se ao longo do projeto ou em sua conclusão - você tem alguns possíveis futuros funcionários trabalhando com você.

    
por 20.12.2011 / 14:26
fonte
1

Como empreiteiro, eis o que penso:

Primeiro, conheça seu contratante . Fale com ele um pouco, fale com os desenvolvedores principais. Eles precisam avaliar seu nível de habilidade e nível de intuição. Você não pode simplesmente assumir que todos os contratados podem receber requisitos, histórias ou o que você tiver. Você precisa descobrir o que eles podem fazer sozinhos e o que eles não podem fazer.

Não dê muito trabalho de uma só vez . O empreiteiro não está familiarizado com a sua empresa e o trabalho deve ser verificado quinzenal ou semanalmente, se possível, para garantir que está indo na direção correta.

Se este for um projeto do zero, então:

Após a primeira reunião, peça ao empreiteiro para desenvolver um protótipo mínimo do que você espera. Dê a ele requisitos de negócios e não o amarre demais. Você quer ver o quão bom o contratante pode fazer por conta própria. Dessa forma, quando você lhe der mais instruções, você não estará dizendo a ele coisas que ele já conhece e perdendo tempo. Adapte suas instruções ao indivíduo que deve executá-las.

Se o projeto for um projeto existente que precisa de alterações:

Explique o projeto de uma perspectiva de negócios. Envie-lhe o projeto, deixe que ele configure as coisas. Dê-lhe um dia ou dois com ele e marque uma reunião. Peça, explique, comunique, sinta-se à vontade, crie rapport .

O

Rapport será muito mais importante do que qualquer conjunto de requisitos do projeto. No final do dia, o seu relacionamento é o que vai levar o empreiteiro a consertar o projeto em curto prazo, ou ir a milha extra para se certificar de que é incrível. Um conjunto frio de requisitos não lhe dará isso.

Uma vez que você tenha passado pelos estágios iniciais, conecte seu contratado com um contato de desenvolvedor líder, que será seu contato com a empresa. Se ele tem uma pergunta, ele pode disparar para ele. Eles devem se encontrar semanalmente. Acho Citrix Go-To Meeting é a melhor solução para isso, o compartilhamento de tela é uma obrigação.

Agora que você estabeleceu comunicações, se quiser implementar algumas listas ágeis ou apenas distribuir listas de recursos desejados, isso realmente não importa. Nenhuma metodologia ou sistema substituirá as coisas fundamentais que os humanos precisam e esperam.

Somos humanos primeiro, desenvolvedores em segundo.

Cuidado, porém, isso não significa não enviar documentação. É melhor você enviar os melhores documentos e requisitos de projeto que você pode reunir. Esse cara é novo, e ele tem que nadar agora. Certifique-se de jogar um colete salva-vidas.

Se você decidir usar o Agile, recomendamos o roteador principal .

    
por 21.12.2011 / 01:03
fonte