Entonces, en qué consistió el curso, en qué consistió en sus 24 lecciones y por qué es útil para el desarrollador, y no solo para el producto futuro.
Lección 1. Producto
Fue: La esencia del producto. Ciclo vital. Tareas de gerente de producto. Producto vs proyecto.
Útil:Es extremadamente importante para un desarrollador conocer el producto que está haciendo. Por esto pagan más estúpidamente. Por supuesto, puedes pretender ser una tetera. Siga estrictamente los conocimientos tradicionales y no haga nada más allá de lo que está escrito en la especificación. Envuelva todos los deseos adicionales del cliente y no comience a trabajar hasta que el líder técnico escriba todos los detalles en el ticket, hasta el ancho de las sangrías en la interfaz de usuario. Pero, sorpresa-sorpresa, con este enfoque nunca superarás el nivel de desarrollador medio. Hay programadores que se enorgullecen de su incapacidad para comunicarse con el equipo y el cliente. Hay, por supuesto, excepciones. Pero si no eres Sheldon Cooper en TI, es mejor activar la empatía y descubrir cómo funciona el producto, quién participa en él, qué hacen, qué es importante para ellos y por qué. En uno de los proyectos, un cliente comenzó a escribir con agua hirviendo con felicidad, cuando, en la lista de características que había que hacer, le pregunté acerca de las prioridades.Y luego se ofreció a cambiarlos, tk. Algunas tareas fueron bloqueadas por otras. Y algunos estaban redactados incorrectamente, lo que conduciría a errores en el proceso comercial. Y el mayor fracaso que cometí fue cuando realicé una gran refactorización sin la aprobación del cliente, porque nuestro cliente PM y PM estaban de vacaciones. El cliente se negó a pagarlo porque no tenía valor comercial para el producto.
Lección 2. Hipótesis
Fue: Definición de una hipótesis. Establecer objetivos para SMART. Ciclos HADI.
Útil: "Quién no sabe a qué puerto navegar, para eso no hay viento de cola" - dijo Lucius Annei Seneca, el mentor de Nerón, pero no lo amamos en absoluto por esto. Las hipótesis son sobre prioridades. Qué hacer primero, qué después y qué nunca. Las prioridades afectan la velocidad del proyecto. Velocidad: para alcanzar la fecha límite. Los salarios, bonificaciones y otros beneficios dependen de la fecha límite para el proyecto. Es como el tetris. Hay 20 figuras que deben colocarse en un vaso en un minuto. Las figuras son todas diferentes. Se conoce su área (el número de cuadrados en cada uno). Resumimos el área: deben encajar fácilmente entre sí, incluso el lugar permanece. Pero ... no encajan. Porque, sorpresa, encajarán si los pones en el orden correcto. Por lo tanto, un desarrollador experimentado realiza tareas en ese orden para no retrasar el trabajo de los colegas tanto como sea posible. Si necesita crear una API web, primero acuerde la interfaz y cree apéndices de método para que los desarrolladores front-end puedan llamar a la API,y luego modifica el cuerpo de los métodos. Si está involucrado en una base de datos, entonces inicia las tablas lo antes posible para que puedan usarse en el back-end, y luego realiza vistas, índices y otros enlaces. Si escribe un documento, carga un borrador para su revisión lo antes posible, y no lo publica 5 minutos antes de la línea didáctica, como le parece, un documento 100% perfecto.
Lección 3. Gestión del equipo.
Fue: trabajo en equipo. Ágil. Kanban
Útil: Estas deben tener habilidades para programadores y no solo. Los productos de TI modernos están hechos por equipos. Si no sabe cómo trabajar en equipo, bienvenido
Lección 4. Revisar tareas y selección de proyectos
Fue: Revisión de problemas reales del producto. Presentaciones de casos de participantes.
Útil: parece. ¿Por qué un programador sabría cómo resolvió el problema de la baja conversión de anuncios, el aumento de la verificación promedio o la viralidad de la adquisición de clientes? Respuesta simple Habilidades para resolver problemas - habilidades para resolver problemas. Esto es lo que los reclutadores han estado orando durante los últimos 10 años y lo que se encuentra en cada segunda vacante en los EE. UU. / UE. La experiencia de otra persona nunca es superflua. Después de expresar el problema, el profesor sugirió discutir cómo los participantes del curso lo resolverían. Nunca es superfluo usar tu cerebro y aprender de la experiencia de otras personas.
Lección 5. Evaluación del producto
Fue: Evaluación de mercado y análisis de la competencia.
Útil:Conocimiento no obvio para el programador. Tablas de listas de características, análisis FODA, tamaños de mercado TAM / PAM: ¿por qué es esto? Sí, parece que no hay necesidad hasta que decida la elección de una pila de tecnología en el proyecto. O cree que necesita cambiar inmediatamente a las últimas versiones de las bibliotecas tan pronto como salgan (no). O decidir a qué universidad ir. O en qué idioma escribir tus primeros proyectos. En resumen, usted toma una decisión estratégica que determinará su destino en los próximos años. C # o Java? ¿Angular o reaccionar? MSSQL u Oracle? ¿Tienda de aplicaciones o Google Play? Mobapps nativos o QT / Xamarin? Visual Studio, WebStorm o Visual Studio Code? Todavía estoy avergonzado del caso con un cliente. Estaba buscando contratistas para desarrollar un gran sistema ERP desde cero. Nuestra compañía le ofreció un equipo y una pila: Silverlight. Para 1.Durante 5 años hicimos un producto y luego Microsoft anunció que ya no era compatible con Silverlight. ¡Fatalidad! El sistema depurado y terminado puede tirarse a la basura. El cliente pasó 10 personas * 18 meses * solo en el desarrollo * pago mensual promedio incluyendo impuestos, digamos $ 3,000 = $ 540,000. ¡Medio perro por la cola! Y si sumamos la ganancia perdida, teniendo en cuenta el desarrollo de un nuevo sistema (la empresa gana ~ 10 mil millones de euros por año), imagine el daño de la decisión. El problema no es solo sobre TI. ¿Rubias o morenas? ¿Comprar un departamento o alquilar? ¿Vives en la ciudad o en los suburbios? ¿Debo votar o ir a la casa de campo? ¿Para qué empresa trabajar? ¿Te mudaste a la capital o te quedaste en tu ciudad?El cliente pasó 10 personas * 18 meses * solo en el desarrollo * pago mensual promedio incluyendo impuestos, digamos $ 3,000 = $ 540,000. ¡Medio perro por la cola! Y si sumamos la ganancia perdida, teniendo en cuenta el desarrollo de un nuevo sistema (la empresa gana ~ 10 mil millones de euros por año), imagine el daño de la decisión. El problema no es solo sobre TI. ¿Rubias o morenas? ¿Comprar un departamento o alquilar? ¿Vives en la ciudad o en los suburbios? ¿Debo votar o ir a la casa de campo? ¿Para qué empresa trabajar? ¿Te mudaste a la capital o te quedaste en tu ciudad?El cliente pasó 10 personas * 18 meses * solo en el desarrollo * pago mensual promedio incluyendo impuestos, digamos $ 3,000 = $ 540,000. ¡Medio perro por la cola! Y si sumamos la ganancia perdida, teniendo en cuenta el desarrollo de un nuevo sistema (la empresa gana ~ 10 mil millones de euros por año), imagine el daño de la decisión. El problema no es solo sobre TI. ¿Rubias o morenas? ¿Comprar un departamento o alquilar? ¿Vives en la ciudad o en los suburbios? ¿Debo votar o ir a la casa de campo? ¿Para qué empresa trabajar? ¿Te mudaste a la capital o te quedaste en tu ciudad?¿Rubias o morenas? ¿Comprar un departamento o alquilar? ¿Vives en la ciudad o en los suburbios? ¿Debo votar o ir a la casa de campo? ¿Para qué empresa trabajar? ¿Te mudaste a la capital o te quedaste en tu ciudad?¿Rubias o morenas? ¿Comprar un departamento o alquilar? ¿Vives en la ciudad o en los suburbios? ¿Debo votar o ir a la casa de campo? ¿Para qué empresa trabajar? ¿Te mudaste a la capital o te quedaste en tu ciudad?
Lección 6. Público objetivo
Fue: Métodos para describir el público objetivo. Segmentación.
Útil: revelaré un terrible secreto. Ni un solo cliente en el mundo paga a un programador solo para disfrutar de verlo golpear el teclado, google stackoverflows, tomar café, discutir los principios del polimorfismo con colegas y dar pistas inteligentes en llamadas de conferencia. El cliente paga para resolver sus problemas. Por lo tanto, vale la pena conocer y respetar a su cliente al menos por el hecho de que le paga dinero. Sin un cliente, solo escribes aplicaciones divertidas gratis. Un pasatiempo tan lindo en casa como coleccionar sellos o quemar madera.
Sesión 7. Investigación del cliente
Fue: Desarrollo del cliente (investigación del cliente a través de entrevistas de problemas).
Útil: Al igual que la lección anterior fue sobre el cliente. ¿Por qué otro? ¡Debes Fedya, debes! Aquí estamos hablando de una entrevista. Necesitas hablar con el cliente. Y pocas personas saben cómo hacer esto. No presione con su opinión, no sugiera respuestas, pregunte sobre el pasado y no sobre el futuro, encuentre números específicos, no deseos, aclare incertidumbres, tenga un plan de conversación y arregle acuerdos, escuche más, hable menos. Todavía no se ha escrito nada mejor que el libro de Rob Fitzpatrick "Ask Mom". E incluso tengo una crítica al respecto. De repente, hablar en formato castedev no solo es posible con el cliente, sino también con sus colegas.
Sesión 8. Entrevistas prácticas.
Fue: Búsqueda de encuestados. Formulación de preguntas. Desarrollo de clientes en la práctica.
Útil:Para convertirse en un buen entrevistador, desafortunadamente, también necesita realizar entrevistas. Hablo inglés perfectamente, con todos los gerundios, puedo reconocer la jerga e imitar cualquier acento, bromeo incendiariamente y entiendo los más sutiles matices del idioma. Pero está en mi cabeza. En la práctica, suena así: “Ixcuzmi. Veriz eeee niarest shop? Comprar productos de visa? ¡Notas de chip, maldita sea lo caro, pero, por supuesto, expansivo! ". La teoría no funciona sin práctica. Una experiencia muy traumática para la psique de cualquier programador de chupetones es encontrar entrevistados. Sal del edificio y otras cosas. Es físicamente difícil obligarse a llamar a una compañía desconocida y solicitar una entrevista u ofrecer un servicio. O pregunta por algo en la calle. Pero lo que no mata nos hace más fuertes. Una llamada telefónica no te matará. Lo principal es no llamar bajo la lluvia y no esconderse debajo de los árboles.
Sesión 9. Investigación cualitativa y cuantitativa.
Hubo: entrevistas, encuestas, grupos focales, expertos, asesores web, compradores misteriosos, pruebas A / B.
Útil: necesita argumentos para tomar una decisión. Los argumentos necesitan hechos. Los hechos se basan en números. Los números se derivan de la investigación. Los diferentes tipos de investigación sobre la misma cosa dan una imagen más realista. ¿Por qué lo necesita un desarrollador? Vivimos en un mundo muy cruel. Ya no es posible, como en algunos años setenta, ir al jefe y pedir $ 152 mil millonespara aterrizar en la luna, mira limpiamente, aunque todo es perfectamente visible a través de un telescopio. Si propone una refactorización, es mejor mostrar el beneficio en números. Por ejemplo, acelerar las consultas de la base de datos por X-times, reducir la duplicación de código y acelerar los cambios o arreglos por Y-times. La compra de un resharper se justifica acelerando la codificación por un factor de Z Pizza gratis los viernes: más de 100,500 veces mejor espíritu de equipo.
Lección 10. Generando ideas
Fue: Método 6 sombreros, Walt Disney, estúpida vaca, generación inversa, objetos focales, TRIZ.
Útil: mi pasatiempo favorito. Como dijo un hombre inteligente: "La programación es una invención a pedido". No hay ningún lugar en TI sin él. ¿Cuántas veces me he enfrentado a un problema aparentemente insoluble, y después de la idea encontré una solución elegante? Al final resultó que, a la gente se le ocurrieron muchas maneras de estimular la creatividad. Una manera de trabajar es explicar el problema a un colega, pedir consejo y encontrar un par de alternativas durante la discusión. Necesitas comunicarte más. Es bueno "dormir" con el pensamiento y en la mañana la mente subconsciente encuentra una solución o realizar actividad física (natación) y en el proceso pensar en la idea.
Lección 11. Propuesta de valor
Fue: Compilación de la CPU. Lean Canvas, Value Proposition Canvas.
Útil: Una vez más, aquellos que son puramente técnicos se sentirán decepcionados. Cualquier nombre de funciones, bibliotecas y sintaxis del lenguaje de programación. Nada de esto, por supuesto, sucedió. Y hubo análisis, formulando preguntas y obteniendo respuestas, buscando información, elaborando tablas y estructurando datos. Todo sin lo cual es imposible imaginar un buen especialista en TI.
Lección 12. Modelos de negocios
Fue: Tipos y construcción de modelos de negocio. Esquema de modelo de negocios. Monetización de productos.
Útil: similar a la lección anterior sobre CPU. Meneando cerebros a toda velocidad. Un tema útil sobre los tipos de monetización, porque Siempre es mejor imaginar exactamente cómo su producto genera dinero.
Lección 13. Hoja de ruta del producto
Era: Hoja de ruta. Gráfico de gantt. Estrategia. Plan de lanzamiento. Pila de Producto. Backlog de desarrollo.
Útil: Este es más para un líder tecnológico y gerente de proyecto. Funcionalidad de lanzamiento, líneas didácticas e hitos, riesgos, contabilidad de los recursos disponibles, carga de personas y planes para conquistar el mundo.
Lección 14. Diseñando un MVP
Era: Tipos de MVP (producto mínimo viable). AIDA y 4U al crear una página de destino.
Útil: para la gestión de productos, MVP se trata de construir un prototipo de producto para probar la demanda de forma rápida y económica. ¿Cómo se relaciona esto con el desarrollo? El hecho es que a los programadores se les asignan tareas, pero a menudo no se especifica exactamente cómo se deben resolver estas tareas. Por lo tanto, un buen desarrollador intenta ahorrar recursos y realizar la tarea con el mínimo esfuerzo, porque las prioridades pueden cambiar, y nadie canceló el didline. Si se dice que crea una tabla de datos editable, entonces no debe hacer un control que pueda mostrar ningún tipo de datos, incluido el modo pivote, la funcionalidad de Excel y la exportación de datos en cualquier formato. Los principios de YAGNI , KISS yEl pecado de la optimización prematura se trata de eso. ¡Y nunca escuches, nunca hagas una tarea y una gran refactorización en un boleto! (llorando).
Lección 15. TOC
Fue: Teoría de las restricciones. Lugares estrechos
Útil: Este es el TOP directo cuando se optimiza la velocidad del programa. Para los productos, se trataba de optimizar la parte más estrecha del embudo. Para un especialista en TI, a menudo es necesario aumentar la velocidad de respuesta: carga de página, generación de informes, carga de archivos. SQL tiene un plan de consulta, almacenamiento en caché y otras técnicas de optimización. Siempre vale la pena mejorar el cuello de botella en el sistema. Y para esto, debe medir las etapas del proceso, registrar el tiempo y tomar decisiones basadas en números, y no en sentimientos como "Reescribiré de LINQ al almacenamiento, parece ayudar".
Lección 16: Historias de usuarios y escenarios
Fue: Construcción y uso del Mapa de viaje del cliente.
Útil: lo confieso. La programación es divertida, escribir documentación es aburrida. En el medio se encuentra el diseño de interfaces (UX, que no debe confundirse con UI). Es más divertido que aburrido. Dibuje interfaces en Visio, piense en escenarios de uso, escriba reglas comerciales. Si desea pasar de un desarrollador a un líder, PM, analista, producto o arquitecto, es mejor dominar esta técnica. Ni siquiera digo que a menudo los requisitos para el software se establecen de forma bastante vaga, o incluso sin diseños de interfaz de usuario. Por lo tanto, diseñar una interfaz decente usted mismo de inmediato, resolver las inconsistencias lógicas en la lógica de negocios de manera oportuna le ahorrará mucho tiempo y afectará su satisfacción con su trabajo.
Lección 17. UX
Fue: Scripts. Conceptos básicos de UX. Página de destino. CJM.
Útil: Hubo práctica UX aquí. Resulta que estoy atrasado en los tiempos. La gente ha estado haciendo páginas web durante mucho tiempo en Tilda , Figma y, Dios me perdone, Tinkoff . Y los diagramas y prototipos UX no están hechos en Visio, sino en Google Drawings , Draw.io y LucidChart . Para los conceptos básicos del diseño adecuado (relleno, bloques visuales, fuentes, acentos), me gustó el libro de Vlad V. Golovach "Diseño de interfaz de usuario: El arte de lavar un elefante" . El enlace es la segunda versión, leí la primera, es mejor.
Lección 18. Métricas
Fue: métricas clave, personalización, colección.
Útil: es útil tomar decisiones basadas en datos. Los datos son la nueva toma de decisiones basada en datos negra y todo eso. En compañías de TI geniales, los desarrolladores se acostumbran a medir y operar con un montón de datos: los resultados de ejecutar pruebas, implementar en el servidor, verificar la calidad del código, el progreso del cierre de Tareas en Jira, etc.
Sesión 19. Unidad de Economía
Fue: En realidad, Unidad de economía.
Útil: tema súper útil para productos. Tiene que ganar más (más de 3 veces) en la venta de una unidad de bienes de lo que gasta en la producción de la misma unidad. ¿Cuál es el análogo para los desarrolladores? Yo no sé. Después de todo, el programador tiene la tarea de hacer que la funcionalidad esté dentro del ámbito de alcance-tiempo-dinero-calidad. El producto y las prioridades establecidas por él determinan cuánto dinero traerá esta o aquella característica en comparación con los costos de su producción.
Lección 20. Análisis de un caso de lanzamiento de producto real
Fue: Metodología de lanzamiento del producto. Generación de mejoras de producto.
Útil: la experiencia siempre es útil, y la experiencia en una empresa sangrienta es doblemente útil. Existe la opinión de que los freelancers no son muy aficionados a emplear corporaciones, especialmente para sistemas heredados altamente cargados. Ni siquiera se trata de la NDA, la incapacidad para trabajar en equipo, los inconvenientes de la comunicación remota y qué otros problemas típicos de la contratación externa existen. Es solo que hay matices en un sistema vivo en los que un profesional independiente ni siquiera puede pensar. Desde la burocracia hasta la interoperabilidad de integraciones y una ventana de tiempo conveniente para la implementación. Sin mencionar el problema de actualizar la base de datos en tiempo real, versiones de API, etc.
Lección 21. Práctica en la evaluación de soluciones de productos.
Fue: Mecánica para evaluar soluciones de productos.
Útil:Esta fue una continuación de la lección anterior. Solo con un enfoque en práctica intensiva, generación de hipótesis, asignación de tareas y seguimiento de resultados. En resumen, el sistema operativo. Sería útil para un buen desarrollador aquí comprender que el trabajo no se escapará. Las tareas que deben hacerse ayer vienen en un par de piezas al día. Uno de ellos aparecerá en el momento en que salga del trabajo y finalmente revise su correo. Ese equilibrio entre el trabajo y la vida es importante. Que hay momentos en los que solo necesita tomarlo y hacerlo independientemente de la hora del día. Pero es igualmente importante no empantanarse en una rutina y no quemarse en un par de meses. Que puede permanecer en el trabajo durante 4-6 horas por encima de la norma, pero esto significa que al día siguiente la productividad laboral será en el mejor de 50-70%, por lo que las horas extras constantes no tienen sentido.
Lección 22. Dar prioridad a las tareas del producto
Fue: Métodos MVP: priorización, ICE / RICE, Binario: priorización, período de recuperación.
Útil:Buen tema porque Los desarrolladores constantemente tienen que dar estimaciones de la complejidad de las tareas. No es tan fácil como parece. Gradualmente, puede animarse para hacer estimaciones más o menos adecuadas para no equivocarse en más del 20%. Pero generalmente a PMU no le gustan tales números. Es dificil porque hay tareas interdependientes, el factor de familiaridad con una sección específica del código y / o tecnología, presionando el PM para reducir el tiempo, ya que "Solía ser un desarrollador y recuerda que es simple", una vaga especulación (me encanta cuando el analista agrega nuevos puntos durante el proceso de desarrollo), la opinión subjetiva "La interfaz de usuario se ve bien o necesita ser mejorada", el deseo de no parecer estúpido en comparación con los demás y, por lo tanto, bruscamente reducir su evaluación, la presión de los colegas, una recomendación emitida desde arriba "ya hemos firmado un acuerdo con el cliente para la cantidad y los términos exactos", etc.
Lección 23. Preparación para la defensa del trabajo.
Fue: Tipos de presentaciones. Consejos para hablar Pruebas de informes.
Útil: de nuevo. Si no planea crecer por encima del Desarrollador Medio, omita este punto. Por lo demás, y para su propio desarrollo, no será superfluo aprender a preparar un informe, encender a la audiencia, no caer en preguntas difíciles, debatir constructivamente el tema y defender su punto de vista o cambiarlo sin ir al extremo del Código Penal de la Federación de Rusia en forma de infligir graves daños corporales a los opositores ideológicos. ...
Lección 24. Defensa de trabajos finales
Fue: actuación de lucha frente a una audiencia.
Útil: Bueno, en realidad, una actuación en vivo. Puedes prepararte durante mucho tiempo, lamer la preza, tomar lecciones de hablar en público y actuar. Pero después del primer golpe en la mandíbula (salir al escenario), todo esto se me escapa de la cabeza. No sé por qué en las grandes empresas de TI hablan en conferencias o al menos escriben artículos para publicaciones especializadas al menos un par de personas. Si bien esto mejora enormemente la capacidad de formular pensamientos, la marca personal del orador, desarrolla la comunidad de TI y ahorra a las empresas en costos de relaciones públicas y recursos humanos.
¿De qué otra forma puede un desarrollador dejar de ser solo un codificador de formularios de interfaz de usuario para acceder a una base de datos y embeberse con el pensamiento del producto?
Primero, hay una nueva tendencia para las organizaciones turquesas . Hay un excelente ensayo sobre el tema en habr . Por supuesto, muchas cosas se ven un poco utópicas. Dar responsabilidad sin poder real y compromiso financiero puede ser muy arriesgado. ¿Y quién es fácil ahora?
En segundo lugar, o tal vez este es el manifiesto para el primer punto: " Funky business ". Las citas seleccionadas del libro se pueden leer aquí.... Lo que me encanta de estas letras es que están escritas como una revelación religiosa. Lo más borroso posible, accesible, para todo bien, contra todo lo malo. Esto no es una desventaja, sino, por el contrario, una dignidad. Todos los que lean pensarán y sacarán sus propias conclusiones.
Finalmente, está la reciente tendencia de innovación corporativa . Hackathons, pilotos de inicio, desarrollo interno de emprendimiento, estrategia de transformación digital, Lean, desarrollo de clientes y Design Thinking. Hay un gran esquema sobre el tema de Disruptive.vc :
Conclusión
Estoy seguro de que no he revelado ningún secreto. Mientras mas sabes es mejor. Incluso si hay mucho conocimiento, hay muchas penas. En un edificio de equipo de restaurante con un cliente del Reino Unido, nuestro líder tecnológico mostró un truco de caja de cerillas. Lo puso en el borde de la mesa, lo golpeó desde abajo y lo lanzó al aire y con la misma mano encendió una cerilla contra él. El cliente quedó tan impresionado que pagó la factura de todo el equipo, desde la cerveza hasta los pelos de punta. Y uno de los PM bromeó tan bien que los stand-up y retro se convirtieron en clubes de comedia en los mejores años. Incluso puede decir que las habilidades de un gerente de producto no solo serán superfluas para el desarrollador, sino que cualquier habilidad en general juega un papel positivo en el trabajo, el punto es solo en su aplicación correcta . ¡Por lo tanto, aprendamos, sigamos desarrollando y disfrutemos de nuestro trabajo!