SOBRE EL SOFTWARE Y OTROS PROBLEMAS
Una situación muy
común en el desarrollo de software que vemos por montones en empresas de
tecnología es la ausencia de los propósitos específicos en la construcción,
muchas empresas esperan obtener buenos resultados en su construcción, sin
embargo sienten que por más esfuerzo que se invierta en el desarrollo, el
software resultante carece de calidad o produce errores no previstos, sienten
que soportar las funcionalidades existentes es una pesadilla y al mismo tiempo
quieren que su software crezca a medida que avanzan las exigencias de los
usuarios. Este tipo de situaciones lo
que evidencian es una clara falta de estructura y desconocimiento sobre lo que
hacemos, a continuación se presentan algunas preguntas que suelen ser claves en
la adquisición de este conocimiento y que pueden representar la diferencia
entre alcanzar el resultado que deseamos y fracasar en el intento.
¿Qué es
nuestro producto?
Toda empresa debe
saber de manera clara a que se dedica, si no sabemos lo que queremos no debe
extrañarnos que no obtengamos lo que deseamos.
Esto lo entienden personas sin educación especializada que administra un
negocio familiar, si se le pregunta, probablemente su respuesta sea “fabrico
zapatos” o “fabrico trajes”. Aunque el
software es un tanto más difícil de definir ya que el concepto toma diferentes
significados dependiendo de las soluciones que este brinde a los clientes, el
caso de la producción de software no es la excepción, si pensamos que el
resultado de nuestras operaciones es un conjunto de líneas de código que
implementan diversas funcionalidades, probablemente no hemos definido
apropiadamente nuestro producto. El
código fuente de una aplicación es sólo una parte de nuestra fábrica, una parte
muy importante ya que nuestro trabajo se ve reflejado de manera directa en su
funcionamiento, sin embargo, un código fuente que requiere ser modificado
permanentemente incrementa los costos al
momento de hacerlo crecer, un código
fuente que ha sido el resultado de solucionar situaciones particulares de
negocio probablemente no tenga la generalidad necesaria para ser extensible a
mediano plazo. Un código fuente que se
ha creado de manera tal que no se puedan sacarse conclusiones sobre la forma en
la que ejecutamos nuestras tareas es un artículo que únicamente ha generado
valor a los usuarios finales y nos ha impedido adquirir un nuevo conocimiento
sobre la manera en la que hacemos las cosas. Un código fuente cuya calidad no
es susceptible de cuantificarse suele representar un problema frente a futuros
cambios. Un código fuente carente de
documentación crea problemas potenciales de dependencias de recursos humanos,
mala comunicación y rendimiento frente a cambios imprevistos de personal. Todos estos aspectos tienen sus consecuencias
en los costos de implementación del mismo.
Por las razones
mencionadas anteriormente y muchas otras es necesario que tengamos una visión
clara de lo que esperamos producir que en el caso de software, evidentemente es
algo más que simples líneas de código en un sistema de administración de
versiones. Para definir sin ambigüedades
lo que espera que sea su producto tenga en cuenta los siguientes puntos:
·
Qué
problema general del mundo real se resuelve con la aplicación del producto
realizado?
·
Cuál es el
público objetivo beneficiado de la utilización del producto?
·
Que
características agregan mayor valor al producto?
¿Con que
contamos?
Algo importante para
alcanzar el producto definido previamente es tener una idea realista de los
recursos con los cuales contamos, muchas pequeñas empresas establecen sus
expectativas al nivel de otras empresas que llevan mucho tiempo, años de
experiencia en el desarrollo de software y mucho más personal estructurado y
trabajando en equipo de manera coordinada.
Esta situación inevitablemente nos llevará a un sobre esfuerzo
(posiblemente inhumano) o a un resultado fallido en nuestro proceso de
construcción.
Con lo anterior no
queremos decir que deba redefinir su producto por uno con un menor alcance, lo
que se pretende es mostrar que existe un conjunto de limitaciones sobre cuanto
podemos producir. Aunque no cuente con
los recursos necesarios para asistir a todos los aspectos relacionados con su
producto, Usted siempre tendrá la opción de hacer lo mínimo (siempre que se
haga bien) y postergar las oportunidades de mejora sobre el producto. Tenga en cuenta que postergar significa en
este contexto que deberá idear un plan y fijarse unas metas para poder alcanzar
el objetivo, significa que se ha cambiado la prioridad a estas oportunidades y
no que se hayan descartado. A medida que
pase el tiempo debemos tratar de darle una prioridad cada vez mayor de otra
manera nunca realizaremos estos trabajos postergados.
Si se le pregunta a un
fabricante de zapatos cuantas suelas tiene, cuántos trabajadores tiene, cuanto
cuero le queda, si tiene martillo o no, probablemente éste le contestará de
manera inmediata y esto se debe a que para la elaboración de sus productos se
tiene inventariada la materia prima, las herramientas, y mucho mas, esto nos
permite estimar cuantos zapatos es capaz de producir dicha fábrica. De igual manera en la construcción de
software es conveniente contar con un inventario que nos ayude a inferir la
cantidad y la calidad de lo que podemos producir en un momento dado. Para poder realizar esto de manera efectiva,
tenga en cuenta que la materia prima de un equipo de desarrollo de software son
el conocimiento, las habilidades y el talento humano de los miembros del equipo,
hecho por lo cual deberíamos conocer los aspectos mencionados anteriormente en
detalle. Tenga en cuenta que la cantidad
y la calidad de las características generadas no son necesariamente
proporcionales al número de miembros del equipo de trabajo, esto se puede
explicar por el desconocimiento de las habilidades que redundan en malas
asignaciones en la construcción o simplemente por los errores introducidos por
la interacción y la mala comunicación entre los miembros del equipo de trabajo. Existen proyectos, por ejemplo, con
funcionarios extremadamente calificados que realizan sus asignaciones o tareas
de trabajo en tiempo record y al momento de integrar todo en una misma solución
el proyecto se alarga de manera estrepitosa,
esto suele ocurrir debido a una distribución inapropiada o a la poca
claridad de las responsabilidades individuales teniendo en cuenta su función
dentro del desarrollo colectivo.
De una manera bien
estructurada, la fabricación de productos de software puede crecer a medida que
se incrementa la mano de obra, de otra forma simplemente se incurre en
sobrecostos y se extienden las fechas de entrega.
Pero no solo
necesitamos personas y una estructura organizacional, también necesitamos las
herramientas, si ya contamos con herramientas especializadas no hay problema,
sino, deberemos definir si contamos con recursos económicos para adquirirlas o
si podemos hacer uso de herramientas gratuitas disponibles en internet.
¿Cómo lo
hacemos?
Definir la forma en la
que vamos a realizar nuestras operaciones suele ser inicialmente una tarea
ardua y compleja, sin embargo, en el tiempo se mejoraran los procedimientos a
medida que se vayan identificando las necesidades de nuestro equipo de
desarrollo. Defina un plan de
mejoramiento continuo sobre sus procesos, esto estará allí recordándole que
existen oportunidades de mejora sobre dichos procedimientos. Cada vez que finalice una construcción
identifique aquellas cosas que fueron muy útiles en el proceso y las que causaron problemas,
intente darle un orden viendo las actividades como un todo.
¿Qué
aprendemos de lo que hacemos?
Pareciera que muchas
empresas de tecnología trabajan arduamente y obtienen los resultados esperados
en algunas ocasiones, sin embargo, notamos que muchas veces se comienzan a producir
errores en los procedimientos que han ocurrido anteriormente. En algunas situaciones no se cuenta con el
tiempo o los recursos suficientes para tomar medidas al respecto, algunas veces
es simplemente falta diligencia en la toma de decisiones. Todos estos temas pueden estudiarse con una
simple pregunta ¿Qué aprendemos de lo
que hacemos? Esta parece una
pregunta sencilla pero que puede ser muy difícil de responder si no tenemos la disposición
suficiente para autoevaluarnos.
Aprender de lo que
hacemos puede ayudarnos en los
siguientes aspectos:
·
Nos brinda
posibilidades para mejorar nuestros procedimientos y encausarlos por una
dirección que esté alineada con los objetivos de la construcción.
·
Nos ayuda
a aprender a detectar donde están las fallas de dichos procedimientos para
poder establecer planes para corregirlas.
·
Nos
permite agrupar las experiencias y de esta manera identificar áreas de interés
común.
·
Nos
permite establecer procedimientos claros frente a situaciones particulares para
poder invertir nuestros esfuerzos en aspectos importantes del negocio.
·
Nos lleva
a cuestionarnos sobre otros aspectos en los procedimientos que anteriormente no
hubiéramos tenido en cuenta.
Esta pregunta puede
dividirse en muchas otras dependiendo de la naturaleza del negocio. Por ejemplo, podríamos preguntarnos ¿Qué
hemos aprendido de nuestro manejo con los clientes? Esto nos ayudará a mejorar nuestra relación
con los mismos y consecuentemente se reflejará finalmente en su satisfacción y
lealtad. Muchas compañías invierten
cantidades significativas de su presupuesto en sistemas de información para la
administración de las relaciones con los clientes y aún así fracasan en sus
estrategias, esto se debe a que no basta con tener los datos, no basta con tener la infraestructura sino
que adicionalmente toca comprender de manera objetiva la información.
Otra pregunta que
podríamos hacernos es ¿Qué hemos aprendido de nuestros costos? Muchos proyectos de tecnología podrían verse
como “agujeros negros de capital” ya que se invierte en personal calificado, se
invierte en recursos, se invierte en tecnología y aun así los tiempos de
construcción se alargan hasta el infinito lo que finalmente se refleja en los
costos de la construcción. Este tipo de
proyectos suelen consumir todos los recursos invertidos y perderlos sin ningún
resultado, esto puede ser consecuencia de un riesgo asumido durante las
negociaciones previas a la construcción o a ideas mal definidas o poco claras
sobre lo que se espera de dicha construcción.
Una mala o excesiva gestión de los requerimientos podría también
impactar significativamente en los tiempos de implementación. Una fábrica podría operar de esta forma en
los desarrollos iniciales, sin embargo si esto se vuelve recurrente
probablemente no estamos aprendiendo nada de lo que hacemos con nuestras
inversiones.
¿Qué hemos aprendido del
trabajo en equipo? El trabajo en equipo
suele adoptar diferentes formas en una organización, esto se debe a factores
externos tales como las relaciones interpersonales, aspectos culturales colectivos e
individuales. Identificar puntos de
falla y buenas prácticas en nuestro trabajo de equipo nos ayudará a ser más
productivos, a reestructurar ciertas áreas y a visualizar algunas que antes no
se tenían previstas. De manera adicional aprender de nuestro trabajo en equipo
nos ayudará a identificar habilidades dentro de nuestros grupos de trabajo y de
esta manera tener una base experimental a partir de la cual se puedan asignar
de una manera coherente las responsabilidades dentro de los miembros de la
organización, de otra forma termina Albert Einstein siendo un secretario de la
recepción y personas menos capacitadas o menos interesadas en la administración
dirigiendo aspectos fundamentales sin ningún rumbo.
¿Qué hemos aprendido
de las negociaciones? Aparentemente cada
negociación es única y depende de muchos factores en la mayoría
circunstanciales por lo que es difícil tratar de predecir como resultarán, sin
embargo, es necesario que se adopten políticas dependiendo del aprendizaje
previo, de no verse de esta forma se corre el riesgo de tener negociaciones que
redunden en pérdidas para la fabrica.
Resolver esta pregunta es vital para tener una base sobre el
comportamiento de nuestras negociaciones y poder tomar acciones correctivas y
definir estrategias que nos ayuden a
crecer en estos aspectos.
¿Podemos medir
nuestros productos?
Como podría un
zapatero tener utilidades numerosas si no sabe cuánto material gasta en la
construcción de un articulo? ¿Cómo
podría el mismo saber cuánto puede producir si no conoce su inventario? ¿Cómo
puede establecer el precio del artículo si no conoce las diferencias en calidad
y esfuerzo invertido para cada uno de sus modelos? Estas preguntas nos llevan a entender que
mientas más información tengamos de nuestros productos y nuestros procesos
podremos darle el valor. En el caso de
la construcción de software una fábrica que no conoce la arquitectura ni el
estado de su código fuente, que no puede medir la producción o que no puede
cuantificar la calidad de sus desarrollos es una fábrica que trabaja a ciegas,
con una incertidumbre muy alta y esperando siempre resultados fantásticos. Para tener una visión apropiada al respecto,
debemos pensar primero en nuestras métricas, saber que deseamos medir y como repercuten las mejoras a dichas métricas
en el objetivo final de nuestra fábrica.
¿Podemos
medir nuestros procedimientos?
En nuestra fábrica
podemos medir el tiempo para realizar todas las tareas requeridas para la
producción del software? Probablemente
el zapatero si lo sabe. En muchas ocasiones los gerentes de proyectos de
tecnología no conciben la idea de no poder estimar cuanto tomará en tiempo por
ejemplo la definición de los requerimientos de determinada aplicación, o cuanto
tomará en recursos la construcción de un módulo o una funcionalidad.
¿Podemos
predecir los impactos? ¿En cuántos Niveles?
Predecir el impacto
que pueda producir un cambio sobre una solución no es una tarea fácil si no se
tiene una idea general suficientemente clara de la estructura de nuestros
desarrollos, existen relaciones y reglas conceptuales o implícitas entre las
componentes de nuestro producto que no se reflejan de manera directa en la
programación y mientras menos información se tenga sobre las dependencias de
cada uno de los componentes que conforman la solución o conjunto de soluciones,
será más difícil estimar dicho impacto.
El diseño dirigido por modelos arquitectónicamente bien construidos
suele ser una aproximación interesante y poderosa al momento de asignar e
identificar claramente dependencias entre componentes con distintas responsabilidades.
Como usualmente
ocurre, una solución por software a un problema general estará compuesta de un
subconjunto de problemas particulares e independientes que de manera conjunta
interactúan para dar una solución completa a un caso de negocio específico. De esta manera algunos estructuran el
software en capas, otros en anillos, otros por funcionalidad, sin embargo,
parece que no importa de qué manera delimitemos las componentes de nuestro
desarrollo, siempre debería ser posible cuantificar cuantos niveles se
afectarían por los cambios realizados.
Si ya tenemos el conocimiento sobre el número de dependencias sobre los
componentes de la solución, entonces debemos dar el siguiente paso, y este
consiste en diagnosticar los segmentos de código que podrían presentar efectos
indeseados. Posteriormente se presentan
algunas estrategias para combatir este tipo de problemas.
¿Tenemos
problemas heredados del pasado?
¿Cómo los combatimos?
Los problemas
heredados del pasado suelen ser una de las causas más relevantes de resistencia
a cambios al momento de revaluar la arquitectura de un producto. Si se plantea reestructurar una solución de
software, pensamos inmediatamente en problemas de arquitectura que se presentan
actualmente debido a correcciones del pasado que aún se soportan. Como combatimos estas circunstancias? Una forma es separar la implementación comercial
de la implementación reestructurada.
No hay comentarios:
Publicar un comentario
Los comentarios son parte activa de este blog y no serán moderados. Siéntete cómodo al dar tu opinión. Esta es muy importante para nosotros.