¿Modifico código o hago una extensión?

Los problemas del Open Source

Con el fin de permitir la alteración del código estándar, desde siempre, Dynamics NAV ha sido open source, lo cual ha le ha otorgado una aurea de simplicidad precisamente debido a lo sencillo de alterar dicho código.

El código se alberga en la misma base de datos de Dynamics NAV sin ofuscar, con lo que el acceso a dicho código por parte de terceros, otros partners por ejemplo, ha sido siempre posible.

Éste, siempre ha sido un punto de discordia referente a la propiedad intelectual, ya que utilizar este código en beneficio propio por parte de otro distinto al creador, en España, es “causa penal”.

Como es lógico este modelo tiene ventajas e inconvenientes. La principal ventaja es la simplicidad nombrada anteriormente, además de la libertad del cliente final a la hora de sustituir a su proveedor. El principal inconveniente es el “upgrade” y cambios de versión del sistema. Recordemos que Microsoft está liberando un upgrade mensual.

Aunque Microsoft ha trabajado mucho en estos últimos tiempos en aras de favorecer la migración de código, no se ha conseguido automatizar al 100%, con lo que unos días de parada del sistema y la intervención de un técnico siempre es requerida.

Mucha parte de la “beauty of simplicity” de Dynamics NAV ha sido debido a su modelo Open Source

¿Sería Closed Source la solución?

El lenguaje de programación de Dynamics NAV, C/AL, no está orientado a objetos con lo que los programadores de Dynamics NAV no podemos ni sustituir ni complementar lo que el código estándar hace mediante la herencia de clases estándar en nuestras propias clases.

Sin embargo, C/AL está orientado a eventos, lo que significa que la mayoría de cosas que pasan durante la ejecución, desencadenan un evento, como por ejemplo: abrir o cerrar un formulario, insertar un registro en una tabla, modificar la información de un determinado campo, el registro de una factura, y así muchísimas más. Es lo que Microsoft ha denominado como Eventing.

Como programador ¿y si pudiera suscribirme a determinados eventos y asegurarme así ser llamado cuando ocurran? Esto me permitiría no tener que alterar el código estándar. Perfecto, esto son las extensiones. Es lo que se denomina decoupling, y este desacoplamiento permite que mi código sea totalmente independiente. Entonces, si es independiente ¿por qué debo hacerlo visible a los demás? Bienvenido a la discordia. Microsoft cierra el código de las extensiones, es decir, protege la propiedad intelectual del creador.

El modelo Closed Source tiene más implicaciones que las meramente técnicas, pues el creador debería depositar el código en una agencia de Escrow.

La discordia, Open vs Closed

La discordia viene porque algunos (veteranos) profesionales de Dynamics NAV estamos enamorados de esta “beauty of simplicity” que, por el hecho de ser open source, siempre ha caracterizado a Dynamics NAV, y, aunque nos encantan las extensiones, nos aterramos si pensamos que Microsoft puede algún día llegar a prohibir modificar código estándar, aunque si bien es cierto que no hay absolutamente ninguna noticia en este sentido.

Este pensamiento está fundamentado en que actualmente Dynamics 365 (Project Madeira) tiene extensiones, algunas de ellas programadas por la propia Microsoft, y es de suponer que Dynamics NAV 2017 va a seguir el mismo camino. Con esta acción, Microsoft está dejando de publicar código abierto en Dynamics NAV, que todos podíamos ver, estudiar y modificar, para pasar a liberar funcionalidades en modo de código cerrado.

¿Es Microsoft el único creador de funcionalidad que debería programar sin utilizar el modelo de extensiones?

Entonces qué, ¿modifico código o hago una extensión?

Si modifico código, va a ser rápido y simple, con lo que será barato, hasta que llegue el momento de hacer “upgrade” donde habrá un mínimo de intervención manual para poder mover dicho código. Con lo que lo de barato no va a ser cierto.

Si modifico código, va a facilitar que el cliente final pueda fácilmente cambiarse de partner, aunque esto podría entrar en conflicto con las leyes sobre protección de la propiedad intelectual.

Si hago una extensión, será algo más complejo de desarrollar, pero como anuncia la técnica del decoupling, tendré un código independiente que no altera el código estándar con lo que se está garantizando que los futuros upgrades serán 100% automáticos, sin intervención humana.

Además, como creador, estaré protegiendo mi propiedad intelectual aunque seguramente esto puede dificultar el hecho de que el cliente final pueda cambiar de partner al no tener el código fuente. Eso sí, deberé depositarlo en una agencia de Escrow.

¿Supondrá el modelo de extensiones otro cambio importante como lo fue el paso de Classic a Roles?

Mi opinión personal

Mi opinión personal es que las extensiones son fantásticas para los ISV, ya que favorecen la repetibilidad, su despliegue en multitenant y protegen la propiedad intelectual.

Son medianamente fantásticas para los VAR, ya que en ocasiones requieren lo mismo que un ISV, pero en ocasiones necesitan la “simplicity”, es decir, solucionarlo ahora, rápido y tocando código estándar que de otra manera sería imposible. Es decir, se necesita acceso al código fuente estándar para siempre. Sobre todo en los upgrades.

Son nefastas si las utiliza Microsoft, ya que desde siempre ha liberado funcionalidad en modo Open Source estándar, el cual podemos estudiar y alterar si conviene. Las extensiones, en este caso, no aportan ninguna ventaja.

Y para el cliente, depende. Si su solución se basa en un vertical especializado de un ISV seguramente le interesará el modelo de extensiones, ya que favorece la continua actualización y evolución independiente tanto de Dynamics NAV estándar como del vertical, al estar ambos “decoupled”.

Si su solución se basa en una personalización, es probable que lo que más le interese sea disponer del código fuente para asegurar la evolución de su Dynamics NAV. En este punto creo que lo más conveniente es el modelo de extensiones, por los motivos expuestos en el párrafo anterior, pero disponiendo del código fuente.

Como mantener la sincronía del código compilado que se está ejecutando con el código fuente entregado al cliente es complicado y difícil de comprobar por el cliente, éste debe ser cauteloso. Si no tiene la certeza de que este punto se va a cumplir, opte por el sistema tradicional, es decir, sin el uso de extensiones.

Liderazgo / Dirección de proyectos

Existen ciertos comportamientos de la condición humana que pueden alterar inevitablemente los tiempos y el propio desarrollo de las tareas de un proyecto. Navegando me encontré con este post de Diseño Social en el que he hallado algo de ciencia con la que acompañar mi exposición.

Primer error al repartir las tareas: ¿cómo identificar correctamente los individuos a los que encomendar la ejecución de determinadas tareas de un proyecto?

El efecto Dunning-Kruger dice que los individuos con escasa habilidad o conocimientos sufren de un sentimiento de superioridad ilusorio, considerándose más inteligentes que otras personas más preparadas, midiendo incorrectamente su habilidad por encima de lo real, por el contrario, los individuos altamente cualificados tienden a subestimar su competencia relativa, asumiendo erróneamente que las tareas que son fáciles para ellos también son fáciles para otros.

Dunning-Kruger: los individuos con escasas habilidades sufren de un sentimiento de superioridad ilusorio, por el contrario, los individuos altamente cualificados tienden a asumir que las tareas que son fáciles para ellos también son fáciles para otros.

Como director de proyectos, al repartir las tareas, seguramente alinearas los requerimientos con las habilidades de cada individuo pero ten cuidado, podrías estar afectado tanto por la primera parte del efecto Dunning-Kruger como de la segunda.

Por la primera porque podrías encomendar trabajos a la persona que da la sensación que es la que más sabe sobre algo porque así lo aparenta. Y por la segunda porque podrías pensar que si para ti es una tarea fácil también lo va a ser para los demás.

La solución no es otra que conocer muy bien al equipo, saber de lo que es capaz cada uno de sus integrantes y fomentar por todos los medios la compartición de conocimientos entre ellos.

Segundo error al establecer los tiempos: ¿por qué las tareas de un proyecto siempre toman como mínimo el máximo del tiempo disponible para hacerlas? (Aún y habiendo hecho bien el enunciado anterior)

Tal como dispone la Ley de Parkinson “el trabajo se expande hasta llenar el tiempo disponible para que se termine”. Para muchos, cuando más tiempo se tenga para hacer algo, más divagará la mente y más problemas serán planteados.

Parkinson: el trabajo se expande hasta llenar el tiempo disponible para que se termine.

Podríamos añadir otra ley del mismo Parkinson que dice que “el tiempo dedicado a cualquier tema de la agenda es inversamente proporcional a su importancia”, lo que viene a avalar la teoría que cuando más tiempo se tenga para hacer algo, más divagará la mente, y en cambio no se dedicará, proporcionalmente, el tiempo necesario a los temas importantes.

El recurso para corregir este problema es acortar los tiempos asignados para el desarrollo de las tareas sencillas adelantando su fecha de vencimiento, de esta forma, si acaba sobrando, podrá reasignarse a las tareas complicadas o importantes.

Tercer error en la ejecución de las tareas: ¿por qué algunas de las tareas se hacen mal y hay que repetirlas? (Con lo que se va a requerir más tiempo del disponible)

En el libro Gödel, Escher, Bach: un eterno y grácil bucle, Douglas Hofstadter, enuncia una ley que ha adquirido cierta popularidad en ambientes de programación: la Ley de Hofstadter. Dicha ley dice que “hacer algo te va a llevar más tiempo de lo que piensas, incluso si tienes en cuenta la ley de Hofstadter”.

Hofstadter: hacer algo te va a llevar más tiempo de lo que piensas, incluso si tienes en cuenta la ley de Hofstadter.

De forma general, la gente va a tratar de eludir las tareas menos atractivas y empezará siempre por las más interesantes, dejando inevitablemente menos tiempo al resto de tareas que podrían haber sido catalogadas como críticas. Además, en cuanto a su realización, pondrá mayor atención en lo que sabe que va a ser inspeccionado, no en lo que tu esperas que lo haga.

Por lo tanto, al analizar la lista de tareas pendientes individualmente hay que establecer el orden de ejecución y catalogarlas por importancia.

Conclusión

Resumiendo, estos son los puntos importantes en relación con la lista de tareas de un proyecto:

  1. Establecer apropiadamente el grado de complejidad o importancia.
  2. Dividir tareas complejas grandes en otras más pequeñas, si es posible.
  3. Acortar los tiempos de las tareas sencillas y guardarlo para reasignar.
  4. Alinear requisitos de las tareas con habilidades y conocimientos individuales.
  5. Fijar el orden de ejecución.

Además, en cuanto al efecto Dunning-Kruger, y de acuerdo con el post de Diseño Social mencionado al principio, se trata de comprender que probablemente es un tema de formación:

  1. El consejo es apostar por la formación continua y de calidad para mejorar el conocimiento del capital humano y la capacidad para reconocer las carencias propias que tenemos que solucionar.
  2. Si pueden ser entrenados para mejorar sustancialmente su propio nivel de habilidad, estos individuos pueden reconocer y aceptar su falta de habilidades previa.
  3. Hay que formar al individuo tanto para que pueda entender el problema como para que se dé cuenta de verdad de que antes no lo entendía.

 

El uso (complejo) de las extensiones en Dynamics NAV

En este momento existe un debate en la comunidad Dynamics NAV sobre si es adecuado el uso de las extensiones en las instalaciones de este ERP. Si me permiten, voy a dar mi opinión, aunque me centraré en la parte conceptual y no en la parte técnica.

Las extensiones son un nuevo componente de software que, a partir de la versión NAV 2017 y mediante la plataforma AppSource.com, pueden descargarse, instalarse y, si se desea, desinstalarse en cualquier ERP Dynamics NAV, incluido Dynamics 365, en cuestión de minutos, y ¡lo más importante! sin interferir en absoluto con el estándar de NAV y sus localizaciones, lo que permite que las actualizaciones se hagan sin ningún tipo de problema.

AppSource.com es el market-place para la distribución masiva de componentes de software para la familia Microsoft Dynamics, tanto SaaS como on-premise, que permite escoger una app, instalarla, probarla y posteriormente o bien pagarla, o desinstalarla.

Como muchos de vosotros sabéis, Dynamics NAV se caracteriza por ser Open Source. Esto tiene la ventaja que, tanto el código fuente de los nuevos desarrollos como el estándar personalizado, permanece en la base de datos, con todas las ventajas que eso conlleva para el cliente: Asegurar la inversión, posibilidad de cambio de partner, proteger el know-how frente a competidores, etc. Pero esto no es así en las extensiones, ni en consecuencia, tampoco en Dynamics 365.

Las extensiones en Dynamics NAV, por contra, son verdaderos componentes especializados, es decir, que un ISV con la experiencia y el conocimiento suficiente, invierte en su creación para luego venderlo el mayor número de veces posible mediante AppSource.com. Aquí el que asegura la inversión, la IP y el know-how es el ISV. Por tanto, no existe el código fuente en la base de datos del cliente y, consecuentemente, nadie puede tener acceso a él.

Dynamics NAV (Navision) se caracteriza por ser Open Source, sin embargo esta filosofía no se ha mantenido en las extensiones.

Es cierto que ha existido un modelo similar, denominado Add-on, que vendría a ser un mezcla de los 2 modelos expuestos arriba, pero siempre ha sido un poco complicada su distribución y posterior actualización.

Llegados a este punto, podemos establecer algunas conclusiones:


Las extensiones son válidas para componentes poco complejos pero muy específicos, como conexión con plataformas de comercio electrónico, pasarelas de pago electrónico, bancos, administración, agencias de transporte, EDI, etc.

No requieren consultoría de implantación ni formación para su puesta en marcha, tan sólo configuración. Son componentes baratos que requieren muchas ventas, con lo que su distribución a través del market-place AppSource.com es muy adecuada.


Las extensiones son válidas para verticales u horizontales, de forma que permiten la protección de la IP del ISV y su fácil instalación y actualización.

A no ser que se trate de una solución con pocos cambios y ninguna personalización su distribución a través del market-place AppSource.com es poco adecuada ya que se trata de soluciones altamente especializadas que requieren consultoría de implantación y formación para su puesta en marcha.

Si determina que su solución no es adecuada para AppSource.com, una opción interesante es desplegarla mediante Microsoft Dynamics NAV Managed Service.


Las extensiones NO son válidas para realizar personalizaciones en los procesos de la empresa usuaria ya que, como personalizaciones, es conveniente que el código fuente permanezca en posesión del cliente al formar parte de su know-how.

Aunque una opción interesante es que se realice como extensión pero el cliente debería asegurarse la entrega del código fuente aparte. Esto simplificaría las actualizaciones y permitiría a la empresa usuaria asegurar la inversión y evolución.

En estos casos no se podrá optar a su distribución a través del market-place AppSource.com.

 


Vale la pena recordar que el futuro Dynamics 365 (NAV en modo SaaS) solo va a permitir extensiones y éstas deberán estar publicadas en AppSource.com, por lo tanto, no se van a permitir personalizaciones.

Captura

Microsoft está haciendo hincapié en el uso de extensiones ya que si lo consigue vamos a tener un market-place con un extenso catálogo de componentes, muchos de ellos baratos, lo que significará muchas ventas para el ISV, y se va a terminar sufrir en las actualizaciones. Todo ventajas.

Pero está claro que aún quedan algunos conceptos no muy claros y faltará ver qué sucede en el futuro con la plataforma de Dynamics NAV, ya que el desarrollo de personalizaciones y disponer del 100% del código fuente siempre han sido una ventaja clara en las ventas de este ERP.

Microsoft está haciendo hincapié en el uso de extensiones, sin embargo da la sensación que se está yendo en contra del “beauty of simplicity” que siempre ha caracterizado a Dynamics NAV (Navision).

Por el momento no está muy claro si el uso de la plataforma en Dynamics 365 va a resultar en una ventaja o en un inconveniente para el futuro de Dynamics NAV. A esperar toca.

¿Crees que ganas suficiente respecto a lo que sabes?

Estos son los conocimientos que debes tener para ser el “Sheriff” del lugar.
A más skills, más sueldo.

Captura

Dynamics 365 y AppSource

CSPSHero365

Microsoft Dynamics NAV ha sido incluido en lo que Microsoft denomina Dynamics 365, que incluye CRM y ERP, y además se integra con las herramientas de inteligencia Microsoft Power BI y Cortana Intelligence.

AppSource es un catálogo de aplicaciones para que los usuarios empresariales puedan encontrar y probar aplicaciones SaaS listas para conectar y trabajar con Dynamics 365. Los partners e ISVs pueden publicar sus aplicaciones en dicho catálogo.

Lee más sobre Dynamics 365 en https://www.microsoft.com/en-us/dynamics/dynamics-365
Lee más sobre AppSource en http://appsource.microsoft.com

¿Quién es tu amigo? ¿El jefe o el cliente?

prisionoficina

Si estás trabajando en un partner o consultora tecnológica y debes estar en contacto con clientes, desconfía cuando uno de ellos intente empatizar contigo, crear vínculos, buscar amistad o algo similar.

¿Que por qué?

Mira, si en un proyecto informático que se va a llevar a cabo por el PARTNER en casa del CLIENTE separamos los objetivos de cada uno de ellos podremos observar como no sólo son distintos sino que en ocasiones incluso son contrarios.

PARTNER: Proyecto cerrado en precio y acotado en trabajo.
CLIENTE: Proyecto cerrado en precio pero no en trabajo.

PARTNER: Busca la satisfacción del cliente.
CLIENTE: No busca la satisfacción del partner.

PARTNER: Busca la satisfacción de sus empleados, incluida la tuya.
CLIENTE: Busca la satisfacción de sus empleados, pero no la tuya.

PARTNER: Proyecto rentable significa ganar dinero, y pagarte a ti.
CLIENTE: Proyecto rentable puede significar que el partner pierda dinero.

PARTNER: Invierte en tu formación.
CLIENTE: Utiliza y aprovecha tu experiencia.

Es muy probable que el síndrome de estocolmo se apodere de ti en muchas partes del proyecto. Es lógico, tu eres el que está en contacto permanente con el cliente y vives en tus propias carnes la delicada situación.

“¿Por qué no debo ayudarle un poco más de la cuenta? Total, son horas mías personales. Vamos, encima que hago el esfuerzo, no creo que mi jefe pueda decir nada. Además, el cliente me ha invitado a comer, se lo debo.”

Y es en este momento cuando más fuerte debes ser y recordar los objetivos. Cuéntale a tu jefe lo que te pasa y como te sientes, él lo comprenderá y te adiestrará para que te enfrentes a estas situaciones con soltura. Sabe de lo que le hablas, no es nada nuevo.

Los objetivos del partner y del cliente respecto al proyecto, aunque hay puntos en común, suelen ser distintos.

Para terminar me gustaría matizar que esta situación es generalizada pero hay excepciones, y no sería justo omitirlas.

Por ejemplo, guardo un grato recuerdo de la implantación de Dynamics NAV que realicé en ESADE Alumni. Os aseguro que saben alinear sus objetivos con los tuyos para que la relación sea win-win. Aprendí mucho de ellos.

EDITO: Me gustó cómo lo explica Ramón Rautenstrauch en este post de LinkedIn: Por qué el cliente NO siempre tiene la razón

Medir el muro construido (avance del proyecto)

En los proyectos informáticos es indispensable medir los metros de muro construidos, como decía un colega. Pero es obvio que al no poder medir algo físico, la subjetividad será el valor predominante: Para el programador está 90% acabado pero para el cliente apenas supera el 60%.

Desde mi punto de vista, el grado de avance es uno de los valores más importantes en la gestión de proyectos, ya que de él se deriva el KPI Desvío previsto. Su valor determina si vamos a ser capaces de terminar dentro del presupuesto y se mide calculando el diferencial entre el avance y el ejecutado en un momento dado.

% Desvío previsto = % Avance – % Ejecución

Por ejemplo, siguiendo con el enunciado del primer párrafo, y tomando como correcto el criterio sobre el grado de avance el del cliente, en un proyecto de 100 horas presupuestadas, hay 90 ejecutadas y un grado de avance del 60%. El presupuesto restante es de 10 horas pero quedan 40 por hacer, lo que significa un déficit previsto de 30 horas, un -30% de desvío previsto según la fórmula propuesta, 60% – 90%.

Por lo tanto, es importante certificar el grado de avance bastante a menudo porque en un momento determinado el % de desvío previsto se puede poner en negativo y cuando antes se detecte, antes se podrá gestionar.

KPIdesvioprevisto

En el ejemplo, en la semana 7 se lleva un 55% ejecutado pero con un grado de avance certificado del 50%, con lo que el % de desvío previsto ha empezado a ser negativo. Alarma importante para los responsables del proyecto que deberán empezar a gestionar las correcciones a aplicar.

¿Cómo certificar el grado de avance en proyectos informáticos?

La medición de “los metros de muro construidos” sólo es posible comparando los requisitos previamente aceptados con los realmente construidos, con lo que, cuanto menos conceptuales y más detallados sean, mejor se podrá realizar la comparación confrontándolos uno a uno. En la toma de requisitos hay que bajar a un nivel de detalle suficiente que permita inventariar, chequear y validar cada requisito construido y posteriormente aceptado por el cliente.

Por ejemplo, si el requisito es -construir un proceso que asistirá al usuario para que a partir de los datos registrados pueda liquidarlos entre sí- se debe construir una lista a partir de las respuestas a las siguientes preguntas de ejemplo:

  • ¿Deben aplicarse filtros a los datos al abrir la pantalla? ¿Cuáles?
  • ¿Se permite que el usuario deje liquidaciones sin terminar?
  • Y en ese caso, ¿las puede recuperar un usuario distinto?
  • ¿Qué criterios se han de cumplir para que una liquidación se pueda realizar?
  • ¿Es necesario que las liquidaciones pasen a un histórico?
  • ¿La pantalla debe mostrar registros ya liquidados?
  • ¿La pantalla debe mostrar registros en proceso de liquidación de otros usuarios?
  • Y en ese caso, ¿hay que establecer estados o códigos de colores?
  • ¿Una liquidación se puede deshacer?
  • Y en ese caso, ¿debe cumplir algún criterio para que se pueda?
  • Y en ese caso, ¿se borra del histórico o se añade una marca?
  • ¿Qué pasa con los registros no liquidados? ¿Tienen caducidad?
  • Y en ese caso, ¿qué se debe hacer con ellos?

En los proyectos informáticos en ocasiones ocurre que se lleva un 20% ejecutado y un avance del 80% pero para terminar se deba invertir más del 80%. Es la famosa norma de que el 20% final del proyecto nos va a tomar más del 80% del tiempo.

La cuestión principal es determinar el grade de avance lo más ajustado posible a la realidad. Medir lo construido, como si fuera un muro.

Creo que esta situación se produce por la falta de una lista de requisitos más o menos exhaustiva, ya que es en el 20% final cuando la persona que verifica y valida echa en falta esos pequeños detalles que hace que el desarrollo sea plenamente funcional y debido a ello se produzca la diferencia de criterios, pues para el programador el desarrollo hace lo que se pidió (liquidar entre sí datos registrados) pero para el cliente no es funcional (no hay históricos, no se pueden deshacer en caso de error, etc.).