Aunque a muchos les parezca que esto no tiene sentido alguno, es necesario comprender que el desarrollo no solo es un proceso artesanal, sino que hasta podría considerarlo artístico. Sé que esto puede malinterpretarse pero en las siguientes líneas tratare de explicarme tan claro como el lenguaje escrito me lo permita.
La idea de un sistema, programa, herramienta de software o como quiera denominarse a una pieza de código compilado que cumple una función especifica es la de solucionar un problema o una situación dada para el manejo de información y/o cumplimiento de un proceso que puede o no ser administrado por una persona/s.
Esto puede llegar a ser una explicación muy simple en lo que a la cantidad de cosas que una pieza de código puede hacer, para alguno, para otros la explicación calza bastante bien; pero la idea de estas líneas no es la de tirar una verdad absoluta o de intentar conquistar los cerebros de los desarrolladores, sino, la de establecer una forma de entendimiento al momento de encarar el análisis de un proyecto de esta índole.
Es conocido por todos que el ser humano es el único ser de la creación que no es capaz de llevarse bien con su entorno, al plantear esta idea saltan a mi mente todos los conflictos bélicos y demás cosas que no son parte de este articulo, salvo que, hablemos de la forma en la que entablamos las negociaciones. Que tiene que ver esto con el desarrollo? bueno al momento de analizar una situación en la que es necesario implementar una pieza de cogido, es 100% seguro que deberemos entrar en negociaciones no solo con la persona que está encargando esta pieza, sino con el mismo equipo con el que se trabaja. Tenemos dos tipos de equipos de trabajo los cuales se dividen a su vez en más partes, definamos las primeras dos clases:
Grupos pequeños
Los grupos pequeños tienen a ser muy agiles, claro está, si es que este equipo se conoce bien, a fondo, conocen sus fortalezas y sus debilidades. En este punto quiero hacer hincapié.
Un equipo que conoce sus debilidades puede usarlas para fortalecerse a sí mismo al trabajar sobre ellas.
Un equipo pequeño que no tenga conciencia de sus debilidades es por lo general un equipo susceptible al conflicto, cada uno de los integrantes de este ve en su compañero de trabajo no a una persona que trabaja a su lado sino a una persona que le puede quitar su trabajo. Suena duro, pero así se presentan las cosas. Es sobre este tipo de equipo que me explayare y analizare cuales son los factures que debiesen tomar en cuenta sus integrantes para comenzar a fortalecerse.
Cada uno de los integrantes del equipo debiese conocer a todos sus compañeros, no solo en el ámbito laboral, sino como persona, esto podría parecer que no tiene relevancia y ahora explico porque si la tiene.
Al encarar una negociación muchas veces no logramos exactamente lo que queremos hacer, es en este momento que la personalidad de cada uno manifiesta su estado de ánimo de diferente manera. Algunos entablan una negociación en la que tanto uno como el resto salgan ganando, esta es la negociación ideal, así todos quedan contentos y el trabajo se aliviana tremendamente. Pero qué pasa si un miembro del equipo no está conforme con lo que se le asigno, o como termino la negociación, este miembro del equipo no ha ganado, es mas siente que ha perdido, he aquí el inicio de un problema muy grave.
El hecho que evite que no nos sintamos orgullosos del trabajo realizado comprende un fracaso tanto en lo personal como en lo profesional
Muchas veces me he encontrado en la situación en que uno de los miembros de mi equipo se siente frustrado por la forma en la que la negociación ha concluido, y es necesario que esa frustración sea:
Comunicada (de la mejor forma posible)
Tratada (entablar una negociación)
Solucionada (no puede quedar así)
Si estos pasos no son ejecutados tenemos una bomba de tiempo dentro del equipo, no porque aquella persona que no está "feliz" con el trabajo sea la bomba, sino por la situación en la que esta se encuentra, es necesario que el equipo se mantenga como tal.
Como comunicar frustraciones:
Al sentir que estamos perdiendo cada quien demuestra su sentir de diferente manera, depende de muchos factores, estado de ánimo, carácter, entorno, retribuciones, etc. la única forma de transmitir este sentimiento de frustración es hablando francamente con el equipo, mejor aun si se lo hace antes de cerrar la negociación (ideal) pero de no poderse tratar este asunto en una mesa redonda, el equipo de trabajo es como una familia, ya que durante un tiempo (tiempo de vida del proyecto) tendrán que compartir sus experiencias y verse las caras a diario.
(Continuará...)
El día 22 de febrero tuvimos el agrado de compartir un desayudo/presentación del grupo arquitectum.org en la ciudad de Córdoba. Pudimos ver que en muchas de las definiciones sobre el rol que cumple el arquitecto de software en una empresa estaban bien concebidas dentro del perfil que se está desarrollando en Harriague & Asociados. Entre los temas que se discutieron entra la forma recomendada por Microsoft del organigrama del área de Arquitectura, además, cuales son las responsabilidades del arquitecto en cada una de sus "facetas" por decirlo así, comencemos por el principio.
Definición del área de arquitectura (el qué, cómo y con qué)
Si bien el rol del arquitecto de software viene circulando desde hace mas de 10 años por los laboratorios de sistemas y las áreas de ingeniería de software, no se ha estandarizado una definición exacta de que es un arquitecto de software, es en este sentido que se busca en diferentes fuentes bibliográficas definiciones más claras de que es o como este debiera ser tanto como rol unipersonal como de un área que se dedique a la arquitectura de software, la siguiente definición.
“Arquitectura de software es la suma de los módulos complejos, procesos y los datos del sistema, su estructura y exactas relaciones entre sí, cómo puede ser y se espera que sea, sus extensiones y qué tecnologías participan, deducir las capacidades exactas y flexibilidad del sistema desde el cual se puede formar un plan para la implementación o modificación del sistema.” (Hohmann, 2003)
Con seguridad esta definición no abarca todos los aspectos de un arquitecto de software pero, toca las esenciales. Cabe mencionar que dentro de la gran gama de definiciones de diferentes autores se puede considerar que la arquitectura es diseño, si bien una de las tareas del arquitecto es “diseñar” una solución, el término diseño está siendo mal empleado y causa confusión al momento de la delegación de responsabilidades.
Si bien al momento de la creación de una solución de software para un cliente participan muchos roles y con responsabilidades muy claras sería bueno definir el objetivo (en términos no técnicos) que es lo que un arquitecto y el resto de su equipo debe hacer.
¿Qué?
El “Que” del desarrollo de una solución es el resultado de la unión de los requerimientos de un cliente que llegan a un arquitecto y este al tener una visión clara del entorno en el que se encuentra el cliente, las necesidades del mismo y las expectativas de crecimiento de este como resultado del uso de la solución que vamos a proveer, definen el propósito u objetivo de la aplicación de la mano de un modelado de negocios que es realizado en forma conjunta con los analistas que forman parte del equipo. Considérese que el arquitecto es el director de una orquesta sinfónica se encarga de coordinar a cada uno de los músicos para que la pieza que interpretan salga de acuerdo a la partitura.
¿Cómo?
Una vez con el modelado de negocios en mano y con un equipo de analistas funcionales, se confecciona la documentación técnica del proyecto, esto consiste en el análisis, modelado y diseño de la solución a los requerimientos del cliente. El arquitecto cumple el rol de organizador y facilitador de definiciones y como un validador de la evidencia del modelado.
¿Con qué?
Esta tarea es orquestada ( de nuevo por el arquitecto) y esta vez cambia el equipo de trabajo, ahora seguirá su trabajo junto con un metodólogo y un líder técnico con un framework de trabajo bien consolidado para definir cada una de las partes de la solución, esta vez si se toma muy en detalle a la solución, las decisiones deberán ser tomadas de acuerdo a la tecnología que vaya ser utilizada por el equipo de desarrollo, presupuesto y cronograma del proyecto (a esta altura ya debiera estar bien definido el equipo de trabajo del proyecto).
Organigrama propuesto
Esta más que claro que cada compañía tiene sus propios organigramas y definiciones de puestos de trabajo, y no es intención de nadie tratar de cambiar esto, lo que se intenta es dar una guía de cómo se pudiese que un área de desarrollo de soluciones se organice.
Si bien este organigrama toma en cuenta todas las áreas que se puedan involucrar en el mantenimiento y medianamente el desarrollo de aplicaciones, no cuenta con un área específica de ingeniería de software esta es esencial para toda aquella empresa que desee brindar servicios de software factory.
Calidad del servicio de arquitectura
Así como el término es aun algo poco definido, el servicio de arquitectura es aun más desconocido, la pregunta es, ¿Necesito un arquitecto para el proyecto? La respuesta a esa pregunta (si uno hace las cosas bien) va a ser siempre SI. Un arquitecto es aquel individuo que posee la visión más clara del negocio donde va a implementar una solución, y es capaz de hablar varios idiomas, por esto entiéndase, que es capaz de hablar con el cliente acerca de cómo encarar la solución en el mismo lenguaje que usa el cliente (lenguaje de negocios) y por otra parte es capaz de bajar a tierra todos esos conceptos en la forma más clara y técnica posible para poder comunicarse con los desarrolladores.
Características
A grandes rasgos se considera que un arquitecto de software debiese tener algunas (sino todas) de las siguientes características:
Conclusiones
Está claro que el rol de un arquitecto, de forma estándar, no está definida del todo, sobretodo en nuestro entorno latinoamericano de trabajo, y depende de las buenas definiciones y trabajo arduo que tenemos por delante el definir a cabalidad el rol, sus responsabilidades y habilidades.
Bibliografía
Albin, S. T. (2003). The Art of Software Architecture—Design Methods and Techniques. Indianapolis, Indiana: Wiley Publishing, Inc.
Hohmann, L. (2003). Beyon Software Architecture: Creating and Sustanining winning Solutions. Boston Ma: THE ADDISON-WESLEY .
Como ya se había tratado de establecer en un post anterior la forma de trabajar con Ingenieros de sistemas (y ramas anexas) para poder realizar un proyecto en grupo, debe obedecer a ciertos lineamientos que todo ser humano debe seguir para tener exito en todos los proyectos que emprende (si, se a determinado científicamente que el Ing. de sistemas es un ser humano :D)
Grupos grandes.
Entendamos como grupo grande a un conglomerado de personas que manteniendo su individualidad pretenden afrontar un reto en el que todos deben dirigirse a un mismo punto desde diferentes caminos. aunque este enunciado suene algo rimbombante, es eso lo que se pretende cuando se trabaja en grupo.
Tomemos el punto de vista de la teoría de sistemas; cada sistema puede estar en el marco de un sistema mas grande, es esta relación simbiótica la que permite que un macro sistema compuesto de muchos subsistemas pueda realizar una tarea específica por ejemplo el cuerpo humano. Imaginen que uno de los pulmones no esta de acuerdo con el funcionamiento de el corazón, o que un riñón decide dejar de funcionar sin ninguna razón aparente, ésto causa problemas no solo a esos organos sino a todo el cuerpo ocasionando un sinfin de síntomas que evitan que el resto del cuerpo funcione como deba. se podría decir que esto es una enfermedad.
Asi como las enfermedades el hecho que uno o varios de los integrantes de un equipo de trabajo no se sienta bien ya sea con el trabajo que realiza, con su grupo de compañeros, con el entorno en el que trabaja o algun otro elemento de su mundo laboral, causa que el equipo entero comience a experimentar los síntomas de una enfermedad comunmente llamada "empleado descontento".
Sintomas claros de esta "enfermedad" son:
Trabajo mediocre.-
Podría calificarse de trabajo mediocre al resultado de:
Las sutilizas del comportamiento humano deben ser bien identificadas, y es en este campo donde se deben realizar reuniones unipersonales con el equipo para recibir un "feedback" de la situación de "la persona" que esta detras del empleado, es muy factible que las inconformidades que ese empleado tenga sean muy fáciles de satisacer o de negociar, las negociaciones deberán encararse de forma Ganar - Ganar, es decir que ni la empresa ni el empleado deben sentir que despues de una negociación han perdido algo.
Si, como lo debes estar pensando, estas trabajando con un grupo grande de gente el hecho de reunirse con cada uno de ellos sería un problema logístico de proporciones bíblicas(bueno no tanto) entonces ¿que se debiera hacer?
DIVIDE Y VENCERAS
Hay formas(muy prácticas) de poder dividir al personal que esta asignado a un grupo de trabajo de tal forma que la comunicación ya sea de abajo hacia arriba o vice versa sea fluida y sin distorciones; una sola persona no es capaz de tener toda la visibilidad en detalle de la gestión de un proyecto y de recursos humanos.
Una de estas técnicas es la de dividir los grupos de trabajo, demasiado sencilla, pero, es muy efectiva, de esta forma podemos afrontar el reto de tener una idea muy clara de que pasa con el equipo de trabajo desde diferentes ópticas. Ahora, hay que saber que preguntar y como preguntarlo.
Muchas veces nos vamos a encontrar con desarrolladores y analístas que son muy sueltos y relajados al momento de hablar, con estas personas es muy poco probable que tengamos problemas al momento de la entrevista de feedback(llamemoslo asi por ahora); donde es posible que encontremos algo de dificultad en la comunicación es en esas personas que por alguna razón se sienten intimidados ya sea con el jefe o con el líder de proyectos. Es aquí donde el equipo de recursos humanos entra en acción y se encarga de las entrevistas, lo ideal sería comenzar por los mas juniors hacia arriba.
Esta temporada de entrevistas debiera tomar como máximo un par de semanas... sí solo un par y esto debido a que si se emplea demasiado tiempo en esta etapa la muestra recogida puede no estar del todo real, ya que la coyuntura se ha distendido y muchas situaciones pueden darse (ya se positivas o negativas) que afecten la información.
"... Como mantener a sus recursos rentables..."
La frase que acaban de leer es uno de los temas a tratar en una convención de dueños de empresas de diferentes rubros. Si bien el término rentable esta ampliamente aceptado, no es el correcto (o por lo menos para los recursos que son rentables).
En algún punto las empresas dejaron de contratar personas y empezaron a incrementar su bienes inmuebles? la respuesta a esa pregunta es un categórico NO, una de las cosas que podrian hacer para "mantener a sus tan apreciados recursos rentables" es dejar de considerarlos un mueble o un equipo que se conecta a la empresa de 9-5 (o el horario que sea) y empezar a tratarlos como personas.
SI SEÑORES los empleados son personas (aunque hay varios que clasificaron con la mínima nota), muchas veces el empleado migra a otra empresa en busca no solo de un sueldo mas alto, sino de un trato mas digno o de mejores oportunidades de crecimiento.
Quiero terminar con ese ultimo parrafo ya que este tema da para mas
(Continuará)
Después de tantas acaloradas discuciones con personas de diferentes grupos y profesiones tengo ahora el agrado de decirles que yo tengo la razón!!!
Esta declaración viene a consecuencia de una nota la cual respalda los constantes errores de los que yo fuí partícipe en la empresa donde trabajaba antes (por razones mas que evidentes no puedo decir el nombre, pero aquellos que me conocen saben de quien hablo), constantes perdidas de datos, corrupción de versiones y etiquetas de VSS, pantallas azules al menos 1 por día en alguna PC y un sin fin de errores que no solo interrumpian el trabajo sino que lo volvian frustrante.
En una oportunidad tuve la "suerte" de trabajar en la localización de un demo para dicha empresa, este demo tenía errores muy particulares, cansado de esa situación (y hechandole la culpa a la PC) cambie de máquina y me puse a trabajar en mi notebook donde tengo todo el software licenciado (gracias a un buen amigo que me regalo el msdn universal) y grande fue mi sorpresa cuando el demo comenzo a funcionar perfectamente sin realizar ninguna modificación.
¿Cosa de Mandinga? Tal vez, pero de algo estoy seguro, desarrolladores capaces de crear un SO que es utilizado por gran parte de los usuarios de PC del mundo son capaces de PROTEGER su trabajo y sus productos con backdoors como estos.
Si bien a muchos esto perjudica, hay que considerar que al usar un software pirata se perjudica al creador de ese software.
Si, ya se, "Las empresas de software son moustros llenos de dinero y poder asi que no les afecta"
Y la pregunta del millon es, ¿Y que pasa si el software que hacemos nosotros llega a ser pirateado y usado de forma masiva?
Las leyes se cumplen, no se negocian.
_513.png){kind=small}