Portanto, em que consistiu o curso, em suas 24 lições e por que é útil para o desenvolvedor, e não apenas para o produto futuro.
Lição 1. Produto
Era: A essência do produto. Ciclo da vida. Tarefas do gerente de produto. Produto vs projeto.
Útil:É extremamente importante para um desenvolvedor conhecer o produto que está produzindo. Por isso, eles pagam mais estupidamente. Claro, você pode fingir ser um bule de chá. Siga rigorosamente o TK e não faça nada além do que está escrito nas especificações. Agrupe todos os desejos adicionais do cliente e não comece a trabalhar até que o líder técnico grave todos os detalhes no ticket, até a largura dos recuos na interface do usuário. Mas, surpresa-surpresa, com essa abordagem, você nunca ficará acima do nível do desenvolvedor intermediário. Existem programadores que se orgulham de sua incapacidade de se comunicar com a equipe e o cliente. Existem, é lógico, exceções. Mas se você não é Sheldon Cooper em TI, é melhor ativar a empatia e descobrir como o produto funciona, quem participa, o que faz, o que é importante para eles e por quê. Em um dos projetos, um cliente começou a escrever com água fervente de felicidade, quando, na lista de recursos que precisavam ser feitos, perguntei sobre prioridades.E então ele se ofereceu para mudá-los, tk. algumas tarefas foram bloqueadas por outras. E alguns foram redigidos incorretamente, o que levaria a erros no processo de negócios. E a maior falha que cometi foi quando fiz uma grande refatoração sem a aprovação do cliente, porque nosso cliente PM e PM estavam de férias. O cliente se recusou a pagar por isso, porque não trazia valor comercial para o produto.
Lição 2. Hipóteses
Foi: Definição de uma hipótese. Definir metas para o SMART. Ciclos HADI.
Útil: "Quem não sabe para qual porto navegar, pois não há vento de cauda" - disse Lucius Annei Seneca, o mentor de Nero, mas não o amamos por isso. Hipóteses são sobre prioridades. O que fazer primeiro, o que depois e o que nunca. As prioridades afetam a velocidade do projeto. Velocidade - para cumprir o prazo. Salários, bônus e outras vantagens dependem do prazo para o projeto. É como Tetris. Existem 20 figuras que precisam ser colocadas em um copo em um minuto. As figuras são todas diferentes. Sua área (o número de quadrados em cada) é conhecida. Resumimos a área - eles devem caber facilmente próximos um do outro, até o local permanece. Mas ... eles não se encaixam. Porque, surpresa, eles se encaixam se você os colocar na ordem certa. Portanto, um desenvolvedor experiente executa tarefas de forma a não retardar o trabalho dos colegas o máximo possível. Se você precisar criar uma API da Web, primeiro concorde com a interface e faça stubs de método para que os desenvolvedores front-end possam chamar a API,e depois modifica o corpo dos métodos. Se ele estiver envolvido em um banco de dados, ele iniciará as tabelas o mais rápido possível, para que possam ser usadas no back-end, e exibirá exibições, índices e outras ligações posteriormente. Se ele escreve um documento, ele envia um rascunho para revisão o mais rápido possível e não o publica 5 minutos antes da linha didática, como parece a ele, um documento 100% perfeito.
Lição 3. Gerenciamento de equipe
Era: Team building. Ágil. Kanban.
Útil: Estes devem ter habilidades para programadores e não apenas. Os modernos produtos de TI são fabricados por equipes. Se você não sabe trabalhar em equipe, seja bem-vindo
Lição 4. Revise as tarefas e a seleção do projeto
Foi: Revisão de problemas reais do produto. Apresentações de casos dos participantes.
Útil: Parece. Por que um programador saberia como eles resolveram o problema de baixa conversão de anúncios, aumento na verificação média ou viralidade da aquisição de clientes? Resposta simples. Habilidades de resolução de problemas - habilidades de resolução de problemas. É por isso que os recrutadores oram há 10 anos e o que é encontrado em cada segunda vaga nos EUA / UE. A experiência de outra pessoa nunca é supérflua. Depois de expressar o problema, o professor sugeriu discutir como os participantes do curso o resolveriam. Nunca é supérfluo usar o cérebro e aprender com a experiência de outras pessoas.
Lição 5. Avaliação do Produto
Foi: Avaliação de mercado e análise da concorrência.
Útil:Conhecimento não óbvio para o programador. Tabelas de listas de recursos, análise SWOT, tamanhos de mercado TAM / PAM - por que isso? Sim, parece não haver necessidade até você decidir sobre a escolha de uma pilha de tecnologia no projeto. Ou você acha que precisa mudar imediatamente para as versões mais recentes das bibliotecas assim que elas saírem (não). Ou decida a qual universidade frequentar. Ou em que idioma escrever seus primeiros projetos. Em resumo, você toma uma decisão estratégica que determinará seu destino nos próximos anos. C # ou Java? Angular ou reagir? MSSQL ou Oracle? App Store ou Google Play? Mobapps nativos ou QT / Xamarin? Código do Visual Studio, WebStorm ou Visual Studio? Ainda tenho vergonha do caso com um cliente. Ele estava procurando contratados para desenvolver um grande sistema ERP do zero. Nossa empresa ofereceu a ele uma equipe e uma pilha - Silverlight. Por 1.Por cinco anos, fabricamos um produto e, em seguida, a Microsoft anunciou que não era mais compatível com o Silverlight. Fatalidade! O sistema finalizado e depurado pode ser jogado no lixo. O cliente passou 10 pessoas * 18 meses * apenas no desenvolvimento * pagamento mensal médio incluindo impostos, digamos US $ 3.000 = $ 540.000. Metade de um cachorro no rabo! E se somarmos o lucro perdido, levando em consideração o desenvolvimento de um novo sistema (a empresa ganha cerca de 10 bilhões de euros por ano), imagine o dano da decisão. A questão não é apenas sobre TI. Loiras ou morenas? Comprar um apartamento ou alugar? Vive na cidade ou nos subúrbios? Devo votar ou ir à casa de campo? Para qual empresa trabalhar? Mover-se para a capital ou permanecer em sua cidade natal?O cliente passou 10 pessoas * 18 meses * apenas no desenvolvimento * pagamento mensal médio incluindo impostos, digamos US $ 3.000 = $ 540.000. Metade de um cachorro no rabo! E se somarmos o lucro perdido, levando em consideração o desenvolvimento de um novo sistema (a empresa ganha cerca de 10 bilhões de euros por ano), imagine os danos da decisão. A questão não é apenas sobre TI. Loiras ou morenas? Comprar um apartamento ou alugar? Vive na cidade ou nos subúrbios? Devo votar ou ir à casa de campo? Para qual empresa trabalhar? Mover-se para a capital ou permanecer em sua cidade natal?O cliente passou 10 pessoas * 18 meses * apenas no desenvolvimento * pagamento mensal médio incluindo impostos, digamos US $ 3.000 = $ 540.000. Metade de um cachorro no rabo! E se somarmos o lucro perdido, levando em consideração o desenvolvimento de um novo sistema (a empresa ganha cerca de 10 bilhões de euros por ano), imagine o dano da decisão. A questão não é apenas sobre TI. Loiras ou morenas? Comprar um apartamento ou alugar? Vive na cidade ou nos subúrbios? Devo votar ou ir à casa de campo? Para qual empresa trabalhar? Mover-se para a capital ou permanecer em sua cidade natal?Loiras ou morenas? Comprar um apartamento ou alugar? Vive na cidade ou nos subúrbios? Devo votar ou ir à casa de campo? Para qual empresa trabalhar? Mover-se para a capital ou permanecer em sua cidade natal?Loiras ou morenas? Comprar um apartamento ou alugar? Vive na cidade ou nos subúrbios? Devo votar ou ir à casa de campo? Para qual empresa trabalhar? Mover-se para a capital ou permanecer em sua cidade natal?
Lição 6. Público-alvo
Foi: Métodos para descrever o público-alvo. Segmentação.
Útil: vou revelar um segredo terrível. Nem um único cliente no mundo paga a um programador apenas para vê-lo bater no teclado, pesquisar no google sobre o stackoverflow, tomar café, discutir os princípios do polimorfismo com os colegas e dar dicas inteligentes em teleconferências. O cliente paga para resolver seus problemas. Portanto, vale a pena conhecer e respeitar o seu cliente, pelo menos pelo fato de ele pagar-lhe dinheiro. Sem um cliente, basta escrever aplicativos divertidos gratuitamente. Um passatempo tão fofo em casa, como colecionar selos ou queima de madeira.
Sessão 7. Pesquisa de Clientes
Foi: Desenvolvimento de clientes (pesquisa de clientes através de entrevistas com problemas).
Útil: Como a lição anterior foi sobre o cliente. Por que outro? Você deve Fedya, você deve! Aqui estamos falando de uma entrevista. Você precisa falar com o cliente. E poucas pessoas sabem como fazer isso. Não pressione suas opiniões, não sugira respostas, pergunte sobre o passado, não sobre o futuro, descubra números específicos, não deseje, esclareça incertezas, tenha um plano de conversação e estabeleça acordos, ouça mais, ouça menos. Nada melhor do que o livro de Rob Fitzpatrick "Ask Mom" já foi escrito. E eu até tenho uma revisão disso. De repente, falar em um formato de castev não é apenas possível com o cliente, mas também com colegas.
Sessão 8. Entrevista prática
Foi: procure por respondentes. Formulação de perguntas. Desenvolvimento de Clientes na Prática.
Útil:Para se tornar um bom entrevistador, infelizmente, você também precisa realizar entrevistas. Falo inglês perfeitamente, com todos os gerúndios, consigo reconhecer gírias e imitar qualquer sotaque, brinco incendiário e entendo as nuances mais sutis da língua. Mas está na minha cabeça. Na prática, soa assim: “Ixcuzmi. Veriz eeee niarest shop? Comprar produtos para vistos? Notas de chip, caramba, quão caro, mas, com certeza, expansivo! ". A teoria não funciona sem prática. Uma experiência muito traumática para a psique de qualquer programador de hickey é encontrar entrevistados. Saia do prédio e outras coisas. É fisicamente difícil forçar-se a ligar para uma empresa desconhecida e pedir uma entrevista ou oferecer um serviço. Ou pergunte sobre algo na rua. Mas o que não mata nos fortalece. Um telefonema não vai te matar. O principal é não chamar a chuva e não se esconder debaixo das árvores.
Sessão 9. Pesquisa qualitativa e quantitativa
Houve: entrevistas, pesquisas, grupos focais, especialistas, webvisor, comprador misterioso, testes A / B.
Útil: Você precisa de argumentos para tomar uma decisão. Argumentos precisam de fatos. Os fatos são baseados em números. Os números são derivados de pesquisas. Diferentes tipos de pesquisa sobre a mesma coisa dão uma imagem mais realista. Por que um desenvolvedor precisa? Vivemos em um mundo muito cruel. Não é mais possível, como em alguns anos 70, procurar o chefe e pedir US $ 152 bilhõespara pousar na lua, olhe bem, embora tudo esteja perfeitamente visível através de um telescópio. Se você propõe refatoração, é melhor mostrar o lucro disso em números. Por exemplo, acelerando as consultas ao banco de dados em X-times, reduzindo a duplicação de código e acelerando as alterações ou correções em Y-times. A compra de um recarregador é justificada pela aceleração da codificação por um fator de Z. Pizza grátis às sextas-feiras - mais de 100.500 vezes o espírito de equipe.
Lição 10. Gerando idéias
Foi: Método 6 chapéus, Walt Disney, vaca estúpida, geração reversa, objetos focais, TRIZ.
Útil: Meu passatempo favorito. Como disse um homem inteligente, "a programação é uma invenção sob demanda". Não há nenhum lugar na TI sem ele. Quantas vezes eu enfrentei um problema aparentemente insolúvel e, depois da descoberta, encontrei uma solução elegante. Como se viu, as pessoas criaram várias maneiras de estimular a criatividade. Uma maneira de trabalhar é explicar o problema a um colega, pedir conselhos e encontrar algumas alternativas durante a discussão. Você precisa se comunicar mais. É bom "dormir" com o pensamento e, de manhã, a mente subconsciente encontra uma solução ou se envolve em atividade física (natação) e, no processo, pensa na idéia.
Lição 11. Proposta de Valor
Foi: Compilação da CPU. Lean Lean, Lona de Proposição de Valor.
Útil: Mais uma vez, aqueles que são puramente técnicos ficarão desapontados. Quaisquer nomes de funções, bibliotecas e sintaxe da linguagem de programação. Claro que nada disso aconteceu. E houve análises, formulando perguntas e obtendo respostas, buscando informações, elaborando tabelas e estruturando dados. Tudo sem o qual é impossível imaginar um bom especialista em TI.
Lição 12. Modelos de Negócios
Foi: Tipos e construção de modelos de negócios. Business Model Canvas. Monetização de produtos.
Útil: Semelhante à lição anterior sobre CPU. Mexendo cérebros a toda velocidade. Um tópico útil sobre os tipos de monetização, porque é sempre melhor imaginar exatamente como seu produto gera dinheiro.
Lição 13. Roteiro do Produto
Era: Roteiro. Gráfico de Gantt. Estratégia. Plano de Liberação. Lista de pendências do produto. Lista de pendências de desenvolvimento.
Útil: Este é mais para um líder técnico e gerente de projetos. Libere a funcionalidade, linhas e marcos, riscos, contabilize os recursos disponíveis, carregue pessoas e planeje conquistar o mundo.
Lição 14. Projetando um MVP
Foi: Tipos de MVP (Produto Mínimo Viável). AIDA e 4U ao criar uma página de destino.
Útil: Para o gerenciamento de produtos, o MVP trata da criação de um protótipo de produto para testar a demanda de maneira rápida e barata. Como isso se relaciona com o desenvolvimento? O fato é que os programadores recebem tarefas atribuídas, mas geralmente não é especificado exatamente como essas tarefas devem ser resolvidas. Portanto, um bom desenvolvedor tenta economizar recursos e executar a tarefa com o mínimo esforço, porque as prioridades podem mudar e ninguém cancelou a linha didática. Se for dito que você cria uma tabela de dados editável, não deve fazer um controle capaz de exibir qualquer tipo de dados, incluindo modo dinâmico, funcionalidade do Excel e exportação de dados em qualquer formato. Os princípios de YAGNI , KISS eo pecado da otimização prematura é sobre isso. E nunca, você ouve, nunca faça uma tarefa e uma grande refatoração em um bilhete! (chorando).
Lição 15. TOC
Foi: Teoria das Restrições. Lugares estreitos.
Útil: Este é o TOP direto ao otimizar a velocidade do programa. Para os produtos, tratava-se de otimizar a parte mais estreita do funil. Para um especialista em TI, geralmente é necessário aumentar a velocidade de resposta - carregamento da página, geração de relatórios, upload de arquivos. O SQL possui plano de consulta, armazenamento em cache e outras técnicas de otimização. Sempre vale a pena melhorar o gargalo no sistema. E, para isso, é necessário medir as etapas do processo, registrar o tempo e tomar decisões com base em números, e não sentimentos como "Vou reescrever do LINQ para armazenamento, parece ajudar".
Lição 16: Histórias de usuário e cenários
Era: Construindo e usando o Mapa de jornada do cliente.
Útil: confesso. Programar é divertido, escrever documentação é chato. No meio está o design das interfaces (UX, para não confundir com a interface do usuário). É mais divertido do que chato. Esboce interfaces no Visio, pense em cenários de uso, escreva regras de negócios. Se você deseja passar de desenvolvedor a líder, gerente de vendas, analista, produto ou arquiteto, é melhor dominar essa técnica. Nem estou dizendo que muitas vezes os requisitos de software são definidos de maneira vaga, ou mesmo sem layouts de interface do usuário. Portanto, projetar uma interface decente imediatamente, resolver inconsistências lógicas na lógica de negócios em tempo hábil economizará muito tempo e afetará sua satisfação com o seu trabalho.
Lição 17. UX
Foi: Scripts. Noções básicas de UX. Página de destino. CJM.
Útil: Havia prática de UX aqui. Acontece que estou atrasado. As pessoas fazem páginas da web há muito tempo em Tilda , Figma e, Deus me perdoe, Tinkoff . E diagramas e protótipos de UX não são criados no Visio, mas nos Desenhos do Google , Draw.io e LucidChart . Para o básico do design adequado (preenchimento, blocos visuais, fontes, acentos), gostei do livro de Vlad V. Golovach "Design de interface do usuário: a arte de lavar um elefante" . O link é a segunda versão, eu li a primeira, é melhor.
Lição 18. Métricas
Foi: principais métricas, personalização, cobrança.
Útil: Tomar decisões com base em dados é útil. Os dados são a nova tomada de decisões orientada a dados e tudo o mais. Em empresas legais de TI, os desenvolvedores se acostumam a medir e operar com um monte de dados - os resultados da execução de testes, implantação no servidor, verificações de qualidade de código, o andamento do fechamento de tarefas no Jira e assim por diante.
Sessão 19. Economia da Unidade
Era: Na verdade, economia unitária.
Útil: Tema super útil para produtos. Você precisa ganhar mais (mais de 3 vezes) na venda de uma unidade de mercadorias do que gasta na produção da mesma unidade. Qual é o análogo para desenvolvedores? Eu não sei. Afinal, o programador é encarregado de tornar a funcionalidade dentro do escopo tempo-dinheiro-qualidade. Quanto dinheiro esse ou aquele recurso trará em comparação com os custos de sua produção é determinado pelo produto e pelas prioridades definidas por ele.
Lição 20. Análise de um caso real de lançamento de produto
Foi: metodologia de lançamento do produto. Geração de melhorias no produto.
Útil: A experiência é sempre útil, e a experiência em uma empresa sangrenta é duplamente útil. Há uma opinião de que os freelancers não gostam muito de empregar corporações, especialmente para sistemas legados altamente carregados. Não se trata nem da NDA, da incapacidade de trabalhar em equipe, da inconveniência da comunicação remota e de outros problemas típicos da terceirização. É que existem nuances em um sistema vivo em que um freelancer pode nem pensar. Da burocracia à interoperabilidade de integrações e uma janela de tempo conveniente para implantação. Sem mencionar o problema de atualizar o banco de dados em tempo real, versão da API, etc.
Lição 21. Prática na avaliação de soluções de produtos
Foi: Mecânica para avaliar soluções de produtos.
Útil:Esta foi uma continuação da lição anterior. Somente com foco em prática intensiva, geração de hipóteses, atribuição de tarefas e acompanhamento de resultados. Em suma, o sistema operacional. Seria útil para um bom desenvolvedor aqui entender que o trabalho não será executado. As tarefas que precisam ser realizadas ontem vêm em duas partes por dia. Um deles aparecerá no momento em que você sai do trabalho e finalmente verifica seu e-mail. Esse equilíbrio entre vida profissional e pessoal é importante. Há momentos em que você só precisa pegá-lo e fazê-lo, independentemente da hora do dia. Mas é igualmente importante não ficar atolado em uma rotina e não queimar em alguns meses. Você pode permanecer no trabalho por 4-6 horas acima da norma, mas isso significa que no dia seguinte a produtividade do trabalho será de 50 a 70%, pelo que as horas extras constantes são inúteis.
Lição 22. Priorizando Tarefas do Produto
Foram: Métodos MVP - priorização, ICE / RICE, Binário - priorização, período de retorno.
Útil:Bom tópico porque os desenvolvedores precisam constantemente fornecer estimativas da complexidade das tarefas. Não é tão fácil quanto parece. Gradualmente, você pode se animar para fazer estimativas mais ou menos adequadas para não estragar mais de 20%. Mas geralmente a PMU não gosta de tais números. É difícil porque existem tarefas interdependentes, o fator de familiaridade com uma seção específica do código e / ou tecnologia, pressionando o PM para reduzir o tempo, pois “Ele era desenvolvedor e lembra que é simples”, vaga especulação (adoro quando o analista acrescenta novos pontos durante o processo de desenvolvimento), a opinião subjetiva de “interface do usuário parece boa ou precisa ser aprimorada”, o desejo de não parecer estúpido em comparação com os outros e, portanto, duro reduza sua avaliação, pressão dos colegas, uma recomendação emitida acima "já assinamos um contrato com o cliente pelo valor e termos exatos", etc.
Lição 23. Preparação para a defesa do trabalho
Foi: Tipos de apresentações. Dicas para falar. Testes de execução de relatórios.
Útil: Mais uma vez. Se você não planeja crescer acima do Middle Developer, pule este ponto. De resto, e para seu próprio desenvolvimento, não será supérfluo aprender a preparar um relatório, inflamar o público, não cair em perguntas complicadas, discutir construtivamente o tópico e defender seu ponto de vista ou alterá-lo sem ir a extremos do Código Penal da Federação Russa na forma de infligir danos corporais graves a oponentes ideológicos. ...
Lição 24. Defesa de documentos de mandato
Era: Combatendo o desempenho na frente de uma platéia.
Útil: Bem, na verdade, uma performance ao vivo. Você pode se preparar por um longo tempo, lamber o preza, ter aulas de falar em público e atuar. Mas depois do primeiro golpe no queixo (subindo no palco), tudo isso sai da minha cabeça. Não sei por que, nas grandes empresas de TI, eles falam em conferências ou pelo menos escrevem artigos para publicações especializadas pelo menos duas pessoas. Embora isso melhore bastante a capacidade de formular pensamentos, a marca pessoal do palestrante, desenvolve a comunidade de TI e economiza as empresas em custos de RP e RH.
De que outra forma um desenvolvedor pode deixar de ser apenas um codificador de formulários de interface do usuário para acessar um banco de dados e ficar imbuído do pensamento do produto?
Primeiro, há uma nova tendência para as organizações turquesas . Existe um excelente ensaio sobre o tópico habr . Claro, muitas coisas parecem um pouco utópicas. Dar responsabilidade sem poder real e compromisso financeiro pode ser muito arriscado. E quem é fácil agora?
Segundo, ou talvez este seja o manifesto do primeiro ponto - " negócios descolados ". As citações selecionadas do livro podem ser lidas aqui. O que eu amo nessas letras é que elas são escritas como uma revelação religiosa. O mais embaçado possível, acessível, para todo o bem, contra todo o mal. Isso não é uma desvantagem, mas, pelo contrário, uma dignidade. Todo mundo que lê vai pensar e tirar suas próprias conclusões.
Finalmente, há a recente tendência de inovação corporativa . Hackathons, pilotos de startups, desenvolvimento interno de empreendedorismo, estratégia de transformação digital, Lean, desenvolvimento de clientes e Design Thinking. Há um ótimo esquema sobre o tópico no Disruptive.vc :
Conclusão
Tenho certeza de que não revelei nenhum segredo. Quanto mais você souber, melhor. Mesmo se houver muito conhecimento, há muitas tristezas. Em uma equipe de restaurante com um cliente do Reino Unido, nosso líder técnico mostrou um truque de caixa de fósforos. Colocou-o na beira da mesa, bateu por baixo e jogou-o no ar e com a mesma mão acendeu um fósforo contra ele. O cliente ficou tão impressionado que pagou a conta de toda a equipe, da cerveja aos arrepios do mar. E um dos PMs brincou tão bem que stand-ups e retrô se transformaram em clubes de comédia nos melhores anos. Você pode até dizer que as habilidades de um gerente de produto não serão apenas supérfluas para o desenvolvedor, mas quaisquer habilidades em geral desempenham um papel positivo no trabalho, o ponto é apenas na aplicação correta . Portanto, vamos aprender, continuar desenvolvendo e desfrutar do nosso trabalho!