Gestor de Tráfego Piauí

Gestor de Tráfego Piauí ? ?

Estratégias para o sucesso do SharePoint com um orçamento apertado

Por que os projetos do SharePoint custam tanto? Por que as organizações ficam chocadas quando veem o custo de, digamos, uma nova intranet legal ou uma migração do SharePoint para a nuvem? Às vezes, o projeto começa bem, mas o choque vem mais tarde – quando o orçamento já está quase acabando – e a equipe descobre uma tonelada de trabalho que ainda precisa ser feito. Se você precisar gerenciar o custo de seu projeto do SharePoint ou espremer seu projeto em um orçamento mais apertado, continue lendo. Descreverei cinco estratégias para manter o orçamento do seu projeto do SharePoint sob controle.

É verdade que alguns projetos sofrem de expectativas irreais. Outros projetos são simplesmente mal administrados. Como consultor sênior, vi todas as combinações e permutações desses desafios. Em vez de insistir no óbvio, este post aborda equipes com expectativas razoáveis, habilidades de raciocínio e experiência razoável. Mesmo com expectativas, habilidades e experiência razoáveis, ainda há riscos de que os custos possam sair do controle. As estratégias descritas aqui reduzirão o risco, melhorarão os resultados e ajudarão você a manter as despesas baixas.

Nomeie um Product Owner

Nomeie um Product Owner do seu projeto do SharePoint e dê a ele autoridade para definir as prioridades.

O  framework Agile Scrum define o Product Owner como “um membro da equipe que não codifica, que tem uma compreensão completa dos requisitos e do valor comercial do produto e é responsável por priorizar o trabalho da equipe”. No contexto de um projeto do SharePoint, a intranet, extranet ou aplicativo que você está criando (ou migrando) é o Produto. Embora a maioria dos projetos do SharePoint sejam gerenciados usando técnicas de cascata em vez de Agile, você ainda pode adotar o conceito de Product Owner e deve.

O SharePoint e o ambiente do Microsoft 365 estão repletos de recursos e estão mudando rapidamente. Da mesma forma, os requisitos de negócios para sua intranet provavelmente são numerosos e também estão mudando rapidamente. Encontre um Product Owner que entenda o que a plataforma pode fazer e o que o negócio precisa. Dê a essa pessoa a responsabilidade e a autoridade para manter a linha.

Dezenas de decisões precisarão ser tomadas antes que seu projeto seja concluído. Até mesmo projetos de migração em que você está “simplesmente” movendo uma intranet do, digamos, SharePoint Server 2010 para o SharePoint Online podem ganhar vida própria. As partes interessadas e os usuários avançados começam a ver todas as coisas interessantes que podem obter no Microsoft 365 e começam a inserir (“clarificar”) requisitos para seus sites. Um Product Owner forte pode ser o único anel para governar todos eles. Mesmo com uma especificação muito boa, você ainda enfrentará inúmeras compensações antes de terminar. Seu Product Owner entende que cada decisão representa um risco de aumento de custo.

Promova recursos prontos para uso e minimize as personalizações

O SharePoint Server, o SharePoint Online e o Microsoft 365 vêm com uma ampla e profunda variedade de recursos prontos para uso (OOTB). Eles também têm muitas APIs e pontos de extensão poderosos para criar soluções e integrações personalizadas. Se você estiver com um orçamento apertado, promova os recursos prontos para uso e desencoraje as personalizações.

Entre OOTB, de um lado, e soluções customizadas, do outro, está a  configuração. A configuração é uma área cinzenta. Eu geralmente encorajo aprimoramentos por meio de configuração como alto valor por baixo custo.

A tabela a seguir lista o que considero ser a funcionalidade OOTB na coluna mais à esquerda, personalizações na coluna mais à direita e recursos de configuração na coluna do meio (entre esses dois extremos):

Geralmente, quanto mais você ficar à esquerda nesta tabela, mais simples será sua solução e menos dispendiosa.

E quanto ao PowerApps e PowerAutomate (anteriormente conhecido como Flow)?

Da perspectiva de um orçamento apertado, considero PowerApps e PowerAutomate personalizações. Estas são ferramentas fantásticas e você absolutamente deve usá-las – se o seu projeto precisar desse tipo de funcionalidade. Mas o PowerApps e o PowerAutomate custarão mais do que uma lista básica do SharePoint. Não subestime o custo e o escopo da criação de um PowerApp personalizado. Sua equipe precisa das habilidades de um usuário avançado na fronteira com um desenvolvedor de software para construir algo mais do que um PowerApp trivial. Além disso, construir a solução é apenas o começo: considere o custo de vida útil da solução. A manutenção e o suporte desses recursos custarão muito mais do que OOTB e configurações especiais.

Desenvolvimento rápido de aplicativos (RAD)

Cada vez que seus usuários solicitarem um recurso especial, tente atender às necessidades deles por meio da configuração da funcionalidade pronta para uso. Você pode fazer bastante através da configuração dos recursos prontos para uso e, no entanto, os usuários sempre parecem querer algo um pouco diferente (ou muito diferente) do que você mostra a eles. Tente convencê-los a começar com os recursos OOTB e os recursos que eles podem obter através da configuração. Se, após esgotar todas as opções de configuração, o SharePoint ainda não puder fazer o que seus usuários precisam, considere o Desenvolvimento Rápido de Aplicativos (RAD).

Tendo em mente os limites do seu orçamento, coloque um especialista no assunto (SME) junto com seu desenvolvedor ou consultor do SharePoint/MS365. Faça com que eles façam protótipos rápidos e iterativos. Desafie-os a ver até onde podem chegar com o mínimo de complexidade. A complexidade aumenta à medida que sua solução chega ao lado direito da tabela de OOTB-vs-Customizations mostrada acima.

O objetivo da abordagem RAD é descobrir a abordagem menos complexa e mais econômica que atenda às necessidades do usuário. Outro conceito Agile é altamente aplicável aqui: o conceito de  produto mínimo viável . Qual solução minimamente complexa atenderá às necessidades de seus usuários nos próximos seis meses a um ano? Se eles podem se contentar com isso, não vai estourar seu orçamento, e você vive para lutar novamente outro dia. Em outras palavras, você pode terminar seu projeto do SharePoint “dentro do orçamento” e aproveitar sua credibilidade recém-adquirida para ganhar um novo orçamento para uma versão 2.0 que retrocede e melhora algumas das coisas que você comprometeu na versão 1.0.

Reduzir o tempo do calendário

Tempo é dinheiro, especialmente quando você está pagando uma equipe de desenvolvimento. Ao mesmo tempo, mover-se rapidamente aumenta o risco; pressa faz desperdício . Entre um extremo do ritmo de caracol e o extremo oposto do relâmpago, há um ponto ideal. A cadência precisa deve ser descoberta novamente a cada projeto executado. Como consultor, sei que, às vezes, preciso diminuir o ritmo para que meu cliente possa receber e absorver meu trabalho. O teste leva tempo e a comunicação leva mais tempo ainda.

Um bom gerente de projeto aprende rapidamente onde está o ponto ideal para o projeto em questão, a equipe e o cliente. Quando há uma variedade de velocidades que podem funcionar, aquelas que concluem a solução mais cedo economizarão dinheiro, tudo o mais sendo igual.

Quando o ritmo é tão lento que seus desenvolvedores estão trabalhando apenas uma fração do dia em seu projeto, há o custo oculto da alternância de contexto. Cada vez que seu especialista em SharePoint se volta para seu projeto, ele deve lembrar de onde parou, localizar suas anotações e encontrar as senhas corretas.

A cada dia ou semana que passa, certamente haverá outra reunião de status. Menos semanas equivale a menos reuniões de status. Apenas não adicione muitos funcionários adicionais em um esforço para diminuir o tempo decorrido do projeto. Conforme mostrado no livro clássico,  The Mythical Man-Month , (Fredrick P. Brooks, Jr., Addison-Wesley, 1975) adicionar pessoal incorre em custos de coordenação e rapidamente se torna um retorno negativo sobre seu investimento. Por outro lado, projetos grandes e complexos, onde há vários threads que devem avançar em paralelo, são adequados para ter uma equipe com vários desenvolvedores. Uma migração básica do SharePoint para a nuvem, no entanto, geralmente é melhor com uma pequena equipe de, digamos, um especialista técnico sênior, um controle de qualidade fracionário e um gerente de projeto fracionário.

Vá para o exterior – mas seja bastante claro com as equipes de desenvolvimento offshore

Aproveite o custo mais baixo de especialistas técnicos localizados na Índia, China e outras partes do mundo com experiência em tecnologia, mas seja bastante claro sobre os requisitos, restrições, expectativas e detalhes técnicos do que você está pedindo que eles façam.

Aproveitar uma equipe internacional eficaz pode ajudar bastante a entregar seu projeto do SharePoint com um orçamento apertado. Quase todos os projetos em que trabalho envolvem uma mistura de recursos on-shore e off-shore. Os perigos contra os quais tomar precauções decorrem do fato de que sua equipe offshore está a meio mundo de distância. Perceba que o que parece óbvio para você quando você envia um e-mail pode ser confuso, vago ou ambíguo para eles.

Ao se comunicar com especialistas técnicos offshore, um protótipo funcional é uma ótima maneira de expressar a direção que eles precisam seguir. As especificações escritas também são importantes, mas você deve incluir capturas de tela, wireframes e cenários de usuário específicos.

Além das formas de comunicação escrita e no computador, recomendo fortemente a reunião em tempo real. A diferença de fuso horário significa que alguém ou todos se encontrarão em um horário inconveniente, então compartilhe a dor igualmente. Eu trabalho em Seattle (fuso horário do Pacífico) e acho que funciona bem ter uma reunião de design mais longa e técnica que começa por volta das 21h, horário do Pacífico (cerca de 9h30 na Índia) e um tipo de atualização de status mais curto e mais curto da reunião por volta das 8h30, horário do Pacífico (cerca de 21h na Índia). Dessa forma, o material técnico mais profundo pode ser coberto quando os membros da minha equipe offshore estão novos e começando o dia, e a atualização rápida do status ocorre quando eles terminam o dia e eu posso descobrir o que eles fizeram.

Conclusão

O SharePoint/O365 é complexo, mas os projetos não precisam custar muito caro. Com uma equipe forte, um bom Gerente de Projeto e as estratégias descritas aqui, você pode entregar uma ótima solução sem gastar muito.