Experiencias y Descubrimientos del emprendedor de Software Robusto

Expondremos las experiencias del emprendedor al desarrollar software robusto utilizando arquitecturas opinadas, modernas y flexibles para cómputo en nube. Comentaremos los descubrimientos acerca de las necesidades y aptitudes que el mercado laboral exige, así como la apremiante necesidad de contar con Arquitectos de Software proactivos y capaces en México.

Transcript

1. Experiencias y descubrimientos del emprendedor de software robusto México necesita Arquitectos de Software proactivos Datos abiertos en instituciones públicas y privadas Salvador Parra Siderare/Pórtica Software México
2. Agenda 1. Presentación, Motivación y Objetivo 2. Del Software Tradicional al Software Robusto 3. Viabilidad de Negocio y Arquitecturas Opinadas 4. Metodologías, artefactos y herramientas 5. Perfil y aptitudes del Arquitecto y el Equipo Emprendedor de soluciones robustas. 6. Sugerencias y Comentarios
3. Presentación • Somos una empresa mexicana compacta formada por profesionales de las ciencias de la computación y la innovación, dedicada al desarrollo de Software Científico y Sistemas de Información y Análisis. • Nuestra experiencia en software es: • Inteligencia de negocios (BI) • Análisis de clima y cambio climático • Bioinformática y procesamiento masivo • Inteligencia Artificial y Minería de Datos • Plataformas de cómputo para el comercio internacional • Sistemas para la Educación, la Industria y el Gobierno • Cómputo en Nube, Redes Sociales y Software Híbrido • Consultoría en Incubación y Vinculación Industria-Gobierno-Universidades
4. Motivación y Objetivos • Nos motiva compartir con nuestra comunidad de futuros profesionales las experiencias y descubrimientos que vivimos a diario, y que son parte de nuestro proceso de emprendimiento y desarrollo de software robusto. • Expondremos las experiencias del emprendedor al desarrollar software robusto utilizando arquitecturas opinadas, modernas y flexibles para cómputo en nube. Comentaremos los descubrimientos acerca de las necesidades y aptitudes que el mercado laboral exige, así como la apremiante necesidad de contar con Arquitectos de Software proactivos y capaces en México.
5. Software, desde la perspectiva del desarrollo • Tradicional • Software de escritorio con capacidades moderadas. • Sistemas que parecen grandes, pero en realidad son soluciones integradas o parcialmente desarrolladas, generalmente basados en plataformas de cómputo robustas e interfaces de integración (APIs, por ejemplo). • “Apps” básicas y sistemas cliente servidor modestos. • Lo encontramos en el mercado laboral y la industria.
6. Software, desde la perspectiva del desarrollo • Robusto • Escalabilidad vertical y horizontal. • Multi-propietario, implantado sobre premisa o nube. • Tolerante a fallos, de alta disponibilidad y con procesos críticos. • Hibrido y distribuido, altamente paralelo y complejo. • Que para su diseño presenta una arquitectura opinada y un proceso de integración continua. • Define a muchos emprendimientos de software-como- servicio con masa crítica de usuarios más allá de los cientos.
7. Ejemplo: Arquitecturas de Servicios
8. Del software tradicional al software robusto • E. Desarrollar software tradicional satisface las necesidades de una buena parte del mercado. México es todavía campo abierto para el desarrollo. • E. Desarrollar software tradicional bien hecho (en tiempo y presupuesto) es cada vez más difícil. • D. En los próximos 5 años el mercado exigirá más soluciones robustas y estables. Pero el mercado no entiende ni tolera nuestras deficiencias como desarrolladores. La mala adaptación de los profesionales hace cruzar las curvas entre competencia y calidad.
9. Del software tradicional al software robusto • D. El software robusto y estable puede alcanzarse después de un proceso de adaptación, estudio y reaprendizaje. Sin embargo, la competencia externa es atroz y se trata del objetivo de las grandes compañías. • D. Si los proyectos de software tradicional fracasan, los proyectos de software robusto corren un riesgo mayor si no se considera seriamente la necesidad de una Arquitectura asequible, flexible y escalable. • D. Las tendencias y efervescencias del sector impactan parcialmente en la naturaleza del software. Las “apps” y el SaaS son software al final.
10. La pregunta Excelente. El software robusto sí puede ser un buen negocio y es posible que lo encuentre como exigencia del mercado laboral en los próximos años. Si no me lo piden, ¡qué bueno!, ahí me la llevo con el boom de las apps móviles o me haré millonario haciendo jueguitos, pero… ¿que sucederá si deseo emprender soluciones basadas en el desarrollo de software robusto? Sucederá que adquiriremos una primera responsabilidad: la Viabilidad del Negocio.
11. Viabilidad de Negocio • D. La viabilidad de un negocio es crucial en un entorno como el nuestro. Nuestro país representa un reto para los emprendedores que deben superar la barrera de los 2 años. El software que fracasa existe. • D. Es importante contar con un estudio de viabilidad de negocio. Los planes de negocio dificultan más el desarrollo de sistemas innovadores y pueden entorpecer los objetivos del emprendimiento. • E. Si no escribimos el estudio de viabilidad de negocio de software, mejor cambiemos de negocio. Se trata de “hacer nuestra tarea”. • E. Escribir el estudio de viabilidad es un ejercicio de salud empresarial que debemos imponernos. Podemos escribirlo pensando en nosotros como principales críticos del proyecto. Debe convencernos de manera objetiva y debe demostrar que somos capaces de redactar. • D. El estudio de viabilidad es una herramienta textual que demuestra nuestra capacidad para enfrentar la realidad y anticiparnos al entorno. Es una excelente herramienta para trabajar con inversionistas.
12. Metodologías, artefactos y herramientas • D. Hace falta una metodología. Segunda responsabilidad adquirida e irrenunciable. • D. Hay muchos artefactos asociados a las metodologías. ¿Cuáles son realmente efectivos? • D. Hay que escoger bien las herramientas de desarrollo. El proceso es largo y requiere de mucha agilidad. Es mejor que sea una tarea especializada. • E. El entorno y la idiosincrasia hace que muchas metodologías fracasen en la práctica, aún en ambientes controlados, no así en el papel. • E. Por ejemplo, SCRUM -región 4- a penas funciona para proyectos de innovación y equipos bien formados.
13. Metodologías, artefactos y herramientas • D. Muchos se contradicen, muchos tienen la razón y muchos parten de suposiciones falsas para llegar a conclusiones “verdaderas”. La verdad es que el resto está trabajando. • E. Vivir el proceso de reaprendizaje retribuye mucho y puede llevar años. Un año es saludable. • E. La realidad es que las herramientas y artefactos son inestables y cambiarán todos los días. Por ejemplo el Domain Driven Design como estrategia de diseño de software ha evolucionado mucho a partir del auge del cómputo en nube. • D. Es difícil que las teorías que fundamentan a la computación involucionen. La teoría de la computación es la base comprobada de todo lo que estamos viviendo en el desarrollo de software moderno. Estudiarla es una ventaja permanente. ¡Uy! Linq to Sql y funciones lambda. Qué novedad para la programación funcional. Modelo de Actores en Scala… ¡es lo de hoy para conseguir pareja!
14. Metodologías, artefactos y herramientas • E. En cuanto a la organización, las metodologías ágiles pueden funcionar bien. Si es posible adaptarse es mejor. Si no es posible adaptarse, debemos inventar algo que funcione: en presupuesto y tiempo. • R. Estudia de 2 a 4 horas diarias adicionales al desarrollo: estrategias (DDD, CQRS, BDD, TDD, SOA, ES y un gran etc.), artefactos, patrones, antipatrones, modelos, tecnologías, frameworks, lenguajes, pruebas e integración continua, componentes, IDEs, APIs, plataformas, servicios de cómputo, teorías de computación, código, proyectos similares y un toque de negocios, fiscal, legal, financiero, ortografía, redacción, buenos modales, ética y moral. • E. El desarrollo en práctica es vertiginoso. Nunca se erra para perder y siempre se aprovecha el fracaso necesario. Nadamás no estudien filosofía ;).
15. Ejemplo: Tecnologías y modelos
16. Ejemplo: Domain Driven Design
18. La Arquitectura Opinada • D. A fin de cuentas, resulta que por causa de la industria, las tecnologías que implantan esos modelos cambian constantemente. No hay paz. • D. Surgen así las arquitecturas opinadas que intentan tomar lo mejor de cada herramienta, modelo o tecnología y materializar una opción asequible para trabajar. Es tierra de nadie y existen figuras clave. • E. La cebolla funciona muy bien; La cebolla de software. A pesar de ser relativamente nueva en la práctica del desarrollo en el cloud computing, hereda muchos conceptos de SOA y es fruto de muchas opiniones acertadas y experiencias desastrosas.
19. La cebolla
21. CQRS Región 4
22. El Arquitecto y el equipo
23. El Arquitecto de Software • D. El arquitecto cumple funciones múltiples y prácticas. Diseña la arquitectura e incluye sus opiniones. Es el responsable de comparar el diseño con el resultado funcional para mejorar y evolucionar positivamente. Posee una perspectiva integral del sistema y sabe que sus responsabilidades son cruciales. • E. En una fábrica de software robusto el arquitecto media entre los requerimientos del negocio y las capacidades del sistema. • D. La sensatez en las decisiones que un arquitecto realiza pueden ser la diferencia entre un software innovador que sirve como base para un negocio viable y un desastre. • E. La principal aptitud de un Arquitecto es su manejo eficaz de patrones, antipatrones y modelos para tomar decisiones proactivas y minimizar las acciones reactivas al opinar la arquitectura.
24. Ej. Patrones
25. El Equipo (emprendimientos robustos) • D. El equipo no será auto organizado ni disciplinado, a menos que alguien muera in situ con regularidad. • D. Si el equipo madura, puede convertirse en una fábrica de software con un nivel de madurez aceptable. Éste debe ser el objetivo común del equipo. • E. Suponiendo un Arquitecto apto, los emprendimientos fallan principalmente por dos razones: porque el Arquitecto no es capaz de comunicar el diseño o porque el equipo no es capaz de seguir instrucciones ni asumir responsabilidades. • E. Una opción viable es establecer una modelocracia dictatorial del Arquitecto-apto-y-eficiente. Otra opción es morir in situ. Naturalmente hablamos de nuestro contexto.
26. El Equipo (emprendimientos robustos) • E. Las opciones metodológicas como “Agile” ayudarán si somos capaces de cambiar el contexto y reeducarnos en nuestra idiosincrasia. • E. La principal aptitud de los miembros del equipo es su capacidad de estudio y reaprendizaje. Lo demás dependerá del sueldo y la creatividad. • E. Suponiendo miembros del equipo responsables y contentos, la principal debilidad del equipo consiste en no comprender que el fracaso es posible y que los emprendimientos robustos tienden a incrementar el riesgo. El enemigo común aquí es el inversionista.
27. Factores externos • E. ¡El inversionista de riesgo es un mal tan necesario! • D. Si el inversionista es experto en el tema, tiende a impactar negativamente en el proyecto sea por avaricia o por control. Si el inversionista es un lego en el tema, tiende hacia la figura de “amado opresor”. • D. El manejo de capital de riesgo es un Alto Riesgo para los desarrollos robustos. Nadie entenderá para qué tanto y por qué “echando a perder se entiende y escalando se aprende”. Por ello no pulula el software. • E. Si ignoramos la usabilidad y el sentido común sobre la utilidad de lo que estamos desarrollando, corremos el riesgo de decepcionar al mundo, como la banca y el futbol. La alternativa es la política.
28. Lo que no sabemos y deberíamos saber • E. Como parte del equipo necesitaremos: • Experto fiscal y contable • Experto jurídico y societario • Experto de negocios serio especializado en innovación • E. Es indispensable conocer la ley y las figuras fiscales y las estrategias contables que usaremos para emprender; así como las estrategias de salida de los inversionistas. Recordemos que son el diablo. • E. Es indispensable estudiar los conceptos societarios y los riesgos laborales, jurídicos, cívicos, contables, de salud, familiares, maritales, extramaritales y emocionales que vienen incluidos con las personas que formarán el equipo.
29. Recomendaciones para los Egresados • Emprendan. Anticípense de manera proactiva. Se ve venir. • Estudien y aprendan por lo menos 2 horas diarias. Entiendan que contamos con las mismas condiciones de acceso y disponibilidad de herramientas y conocimientos que el resto del mundo. Esta disciplina debemos crearla con urgencia. • Evalúen si la figura de Arquitecto les conviene y apuesten al esfuerzo que requiere formarse. México lo necesita. • Formen empresas saludables, compactas y generadoras de confianza, riqueza y prosperidad. La confianza es un factor positivo que debe cultivarse junto con las aptitudes profesionales y los buenos negocios. • Busquen sus verdaderos gurús locales, nacionales y externos. Son el punto de partida a superar.
30. Sugerencias para las Instituciones • Emprendan. Es posible a través de sinergias. • Formen Núcleos Integradores ágiles, eficaces y eficientes. • Vinculen sobre proyectos de largo plazo y alcance. Esto permitirá a varias generaciones participar de una verdadera cultura de responsabilidad heredada y entrenarse adecuadamente para el entorno hostil de los emprendimientos externos. • Flexibilicen los planes y programas de estudio para poder asimilar la práctica cambiante de las tecnologías y arquitecturas en su estado del arte. Creen condiciones especiales para los profesores y alumnos. • Reintegren la programación curricular de la Teoría de la Computación con una orientación práctica sobre las tecnologías emergentes. A nosotros nos tomó 10 años el poder enfrentarlo. • Reaprendan el software e incorporen metodologías y artefactos.
31. Súplicas para el Gobierno • Creen condiciones favorables para los proyectos de largo plazo. Superemos los relojes políticos. • Acrediten los desarrollos paralelos como opciones viables para sistemas robustos ya establecidos. Nada se pierde si se intenta de manera eficiente dar oportunidad a los egresados de proponer sin echar a perder. • Piensen más allá de las PYMES para este sector. Si bien el tamaño de estas empresas es compacto, los impuestos que podemos pagar son atractivos. • Midan diferente y mejor. Los proyectos de software se miden y ejecutan como si fueran de infraestructura. Son de estructura y son una carrera contra el tiempo y el presupuesto.
32. La recomendación Más importante, y especial de hoy: Finalmente
33. ¡Escuchen Jazz! Es en serio. jazzatlanradio.com
34. Gracias Estamos reclutando ASOCIADOS para un stack de +20 proyectos de innovación para los próximos años. ¿Interesados? sparra@gmail.com · sparra@siderare.com Skype: salvador_pr