Preámbulo de la DTE

[Casimiro Noteví]

espero que ahora se vea bien

[[Al González]]

¡Gracias!

[[Delphius]]

Hola a todos,
Disculpen que habra este hilo después de hace ya tiempo.
Ya antes lo había leído y volví a leerlo ahora mientras reordenaba algunas cosas en mi cabeza, investigo y leía el blog de Al.

Ahora que he podido tener el gusto (y/o desagrado según se mire) de estar en varios trabajitos (por su corta duración)... creo que puedo meterme en la conversación.

Bueno. Quisiera preguntar si Al y/o otros profesionales ha visto un mayor avance y/o refinamiento de la DTE dentro de las organizaciones, sobre todo en aquellas en las que poseen un organigrama un tanto complejo.

Me suena lógico este tipo de trabajo. Yo le encuentro sentido y practicidad a esto, aunque en las empresas en donde he estado sus organigramas no brinda un fácil amolde de la DTE. Su estructura son demasiados rígidas y demasiadas piramidal plana.

Mi pregunta va más que nada para preguntar de que modo creen que pueda adaptarse este enfoque en empresas en donde su organigrama es matricial.
Por un lado siento que llevar a cabo DTE en estos tipos de organizaciones es viable pues, por lo general en estas organizaciones el trabajo se distribuye en base a funciones y proyectos. Es un modelo simple:
--- P1 -- P2 -- P3 --
A1
A2
A3

Un proyecto, se lleva a cabo en diversas áreas, y un área (o depto. como prefieran llamar) trabaja en uno o más proyectos.

La idea que se me cruza por la cabeza es que en un Area determinada exista diversos especialistas que se reparten el trabajo según la demanda y/o exigencias de los proyectos. Por ejemplo un especialista se concentra mayormente al AN (Análisis) en P1, mientras que en el P3 podría aportar apoyo en DO (Diseño Operativo)

Pero si bien este tipo de organizaciones propician la aparición de las especialidades (a mi humilde modo de ver) sigue teniendo dificultades para comunicarse y respetar la cadena de mando.

Según lo que vengo leyendo del tema de DTE, veo más ventajoso su uso si se lo aplica como una especie de consultoria, o como un Experto en Información... que son figuras más externas a las organizaciones que internas (algo que ya muchos han dicho). Como menciona el artículo, la aparición de empresas que aporten especialistas. (Que las he visto).

En la empresa que tuve que realizar la práctica profesional por el título de ingeniería habia una serie de especialistas... pero todos venían de afuera. Y algunos hasta en ocasiones no venían... hacia teletrabajo... No he visto, ni he tenido conocimiento de que en Salta las empresas establezcan el DTE "puro".

En definitiva ¿Vieron progresos de DTE dentro de organizaciones?

Saludos,

[[Al González]]

Estoy escribiéndote una respuesta Marcelo, respecto a mi experiencia particular. Sólo me faltan algunos párrafos.

[[Al González]]

¡Hola Marcelo!

Me llegó un aviso automático en el mensajero de que alguien había respondido a uno de los hilos a los que estoy subscrito. Y para mi sorpresa se trató de este tema tan, tan especial. Como autor del artículo me siento obligado a responder a tus preguntas, en cuanto al contexto que me ha tocado vivir a mí. Aunque no dispongo de mucho tiempo, trataré de dejar claro lo que quiero decir.

Hace dos años llegué a Morelia con la ilusión de desarrollar sistemas bajo este paradigma de trabajo hasta ahora casi 100% teórico. Mi naturaleza es la de un tipo poco convencional que no le gusta atenerse a un orden establecido cuando detecta que dicho orden tiene vicios o desventajas respecto a mejores formas de hacer las cosas. Mis primeras reflexiones sobre la DTE surgieron a raíz de las típicas frustraciones que suele acarrear un desarrollador de software que trabaja solo: su vida se convierte en un verdadero caos, o cuando menos se nubla la vivacidad de su existencia por tener menos tiempo libre o nivel de vida de los que serían sanos para su salud o aspiraciones personales de felicidad.

Cuando vivimos eso, muchos llegamos a pensar que algo anda mal y algunos de esos muchos nos aventuramos a intentar un cambio. Mi caos personal era ya insoportable. 2002, uno de los más felices y excitantes años de mi vida no se parecía en nada a 2003, el año en que MS Access me acompañó al infierno. Dos proyectos relativamente importantes, uno mal planeado y el otro mal baratado. Yo no sabía nada de sistemas cliente-servidor y me abrumaba pensar en ese “extraño” mundo del SQL por TCP/IP, lo mío era solamente programación lógica de ingeniosas rutinas Delphi, algoritmos para mecatrónica, radiofrecuencia y comunicaciones (cosas que me apasionaban positivamente); estaba muy verde en cuestión de bases de datos y mis diseños de interfaces eran pésimos. Opté por cambiar de Paradox a MS Access pensando en que estarían más estables mis bases de datos (tremendo error). Entre cientos de problemas técnicos inesperados por resolver en los dos proyectos y mis propias situaciones personales de amores perdidos, terminé vencido, cayendo en un profundo letargo del que ni siquiera sé si ya salí del todo. Entonces una luz en la oscuridad me hizo caer en la cuenta de que “debería existir una mejor forma de hacer sistemas de software sin acercarse tanto al averno, los desarrolladores no deberíamos trabajar bajo estas estresantes condiciones”.

Después de renunciar a casi todo en mi ilusoria vida, me dediqué a sobrevivir en una escuela de computación por menos de 400 USD al mes, parchando su increíblemente mala aplicación de gestión interna hecha en Visual Fox Pro. Al poco tiempo terminé de vender mis escasas pertenencias, volví a casa de mis padres derrotado y sólo esperé que un milagro sucediera. Me iría con la primera empresa que me ofreciera algo que me despejara la mente. Así fue como terminé viajando a Cuernavaca a principios de 2004, para trabajar en la pequeña empresa de un nuevo amigo que habría de hacer.

Mi primera condición del contrato era ninguna labor después de las 3:00 PM. Y vaya que resultaba fantástico, el clima me sentó sensacional. Corría todas las mañanas, trabajaba con enorme entusiasmo desde las 8:30, por las tardes asistía a un taller de teatro, posteriormente al gimnasio y en la noche me conectaba a Club Delphi para ver los nuevos temas en Humor y Debates (muchos de los cuales dignos de la actual Taberna). Y por qué no decirlo, para convivir con muy buenos amigos en este Club. Escribía unas cuantas líneas y a dormir como angelito nuevamente. Los fines de semana, cuando no salía a ver una película de cine alternativo, me iba a escribir los borradores de mi libro al Café Buba o escalaba una pared de roca artificial. Vaya que me sentía más feliz que hoy, debo confesarlo.

Al poco tiempo le planteé a mi jefe el asunto de la DTE (en ese entonces le llamaba “División Horizontal del Trabajo”). Le pareció muy buena iniciativa, tuvimos varias charlas muy productivas para enriquecer el concepto y sabíamos que entre él y yo haríamos muy buena mancuerna si nos lo proponíamos. Hablamos incluso de la posibilidad de trabajar en proyectos “colaborativos” invitando a desarrolladores que trabajarían desde sus casas si así lo quisieran. Él es buen diseñador visual, con muy buenas noticiones de la estética gráfica, mientras que lo mío siempre ha sido escribir código Delphi bien refinado, modestia aparte. Sólo que nos faltaba alguien que fuera bueno en bases de datos (entonces llegamos a considerar a Antonio Castillo para ese puesto) y una persona más desenvuelta como analista. Concluimos que cuando menos esos cuatro puestos deberían estar cubiertos para cumplir con un modelo de trabajo tipo DTE.

Primera gran barrera: No había buen volumen / presupuesto de trabajo. Los proyectos que cotizábamos no tenían el alcancé económico como para cubrir el salario de cuatro personas. Pero lo interesante y rescatable de la DTE es que si una empresa se hace de tres, cinco o diez proyectos, las posibilidades de poder implantar un modelo DTE aumentan muchísimo. Lamentablemente nosotros, en ese entonces (año 2004) no contábamos con el suficiente volumen de contratos como para meter a más personal. Pero, en descargo de esto, debemos considerar que tampoco estábamos cobrando buenos dividendos, de hecho estimo que rayábamos en precios baratos.

Después de ocho meses de exilio en Cuernavaca, volví a Chihuahua con la esperanza de implantar en mi tierra natal el modelo, una vez recuperado física y anímicamente. Conocí a una persona que consideré muy bueno para las cuestiones de análisis de sistemas, y lo invité a trabajar en un nuevo proyecto de empresa. Tocamos muchas puertas e hicimos varias estimaciones de costos DTE como las del ejemplo que subí. Una estuvo a punto de concretarse, el cliente había dicho después de entregarle el presupuesto “Perfecto, vengan el lunes para que firmemos el contrato”. Y el domingo, un día antes, nos llega un correo informándonos que siempre no podrían cerrar el trato. Iba a ser un proyecto de 20 mil USD, el más grande que entonces hubiera tomado. Nunca supimos cuáles fueron realmente las razones del cliente para cancelar su decisión de días antes (argumentó cuestiones internas, pero nunca nos quedamos del todo seguros). Habíamos estimado los costos en montos nada malos. Curiosamente, mi amigo y paisano había planeado ir a conocer Rusia con las ganancias que le tocarían a él. Curioso también mencionarlo ahora que Rusia le puso buen billete a CodeGear. Todo esto nos llevó a descubrir la segunda gran barrera: el mercado al que te diriges. Como seguramente leerás en otro de mis referidos comentarios, Chihuahua no se prestaba entonces para que una empresa pequeñita de sistemas se hiciera de proyectos de software bien pagados. Todavía hoy en día escucho historias de paisanos que están cobrando proyectos de 6 mil USD en tan sólo mil USD, porque el mercado no está dispuesto a pagar más a un pequeño desarrollador.

Después de ocho infructíferos meses de pobre estadía en mi tierra, con todo el dolor del mundo me regresé a Cuernavaca. Me dije “si quiero que la DTE funcione debo estar cerca de los grandes mercados” (Cuernavaca está a 1 hora de Ciudad de México). Establecí mi negocio “virtual” en Cuernavaca, rentando apartamento nuevamente en el mismo y tranquilo lugar (¡ah cómo extraño escuchar los ruidos de la naturaleza por la ventana y esas lluvias tan apacibles!). Nuevamente trabajé para mi amigo el diseñador visual, pero ahora en plan de proveedor. Estábamos más preparados para establecer la DTE. El IMTA, importante instituto del gobierno federal, había prometido importantes contratos para nosotros. Y así como los prometió, los fue cancelando, parte por parte. Había gente al interior a quien no le gustaba que mi amigo se hiciera de tal éxito. Al final nos dejaron sólo con unos cuantos módulos que no alcanzaban para contratar más gente. Y tuvimos mucha “grilla” (crítica negativa) interna acerca de por qué usábamos Delphi y esa base de datos que “nadie conoce” llamada Firebird. Aún recuerdo el comentario de una de esas personas, que durante una junta nos dijo, palabras más, palabras menos, “es que fui a la UNAM en Ciudad de México y vi que todo lo tienen en PHP y MySQL, no estamos muy seguros de que Delphi y Firebird sea lo adecuado para nuestros sistemas de gestión, Delphi es muy raro verlo”. Las discusiones con ciertas personalidades del instituto se hacían cada vez más frecuentes y los golpes bajos no se hacían esperar. Amén de que ya comenzarían las campañas electorales y muchos andaban haciendo ya sus “movimientos”. Así fue como descubrimos la tercera barrera: falta de ética en los negocios.

Yo entonces hacía algunos trabajos por mi parte a algunos clientes de Ciudad de México y mis viajes a esa metrópoli eran frecuentes. Uno de ellos tiene una empresa de software consolidada, con más de 10 desarrolladores en su equipo y muy importantes proyectos. Un día lo visité con la intención de hablarle sobre la DTE e invitarlo a poner el modelo en práctica. Días antes le había hecho llegar una copia de mi artículo, sin recibir opinión concreta de su parte (sospeché que no le había causado mucha mella que digamos). Me recibió a eso de las 8:30 PM más o menos. Llegó con cierta prisa, aunque se veía relativamente tranquilo. Mi olfato me decía que acababa de tener una reunión algo estresante con alguno de sus clientes. Le noté que no tenía todo en orden, vi a algunos de sus desarrolladores todavía trabajando a esa hora en la oficina, con cierto apuro dos de ellos se dirigieron a él para informarle sobre ciertos avances. Se les veía tensos, cualquiera diría que no eran felices. Finalmente logré hablar con él en su despacho. No puedo opinar nada personal contra él, porque hasta cierto punto lo he considerado un amigo, pero me decepcionó totalmente la manera en que evadía la propuesta de intentar poner en práctica la DTE en su empresa. “¡Es que no hay manera, no es tan fácil!”, me decía, y cuando intentaba exponer mis argumentos, los desacreditaba antes de escucharlos por completo. Ahí descubrí la cuarta barrera: la apatía o miedo por intentar algo diferente a lo “establecido”.

Para colmo a mi amigo de Cuernavaca terminaron de tronarlo en el IMTA, y ahora fue él quien se exiliaba derrotado. Vive en Cancún actualmente y trabaja para una empresa europea. No lo he visto desde entonces. Obviamente esto repercutió en mis planes de empresa y bajó considerablemente mi nivel de vida. Las cosas habían salido mal y se estaban complicando las ventas de componentes Delphi en Ciudad de México porque muchos comenzaban a abandonar a Borland ante el pánico causado por los bruscos movimientos de esa época. Yo fui de los que nunca dejé de creer en Delphi, porque Delphi es más que un CEO que renuncia o una mala estrategia de mercado. Ahora que CodeGear está corrigiendo el rumbo, me lleno de esperanza y alegría.

Milagrosamente apareció un programador Clipper en Morelia que quería aprender Delphi. Yo ya no estaba encontrando la puerta en Cuernavaca ante la repentina situación del IMTA, y las bajas ventas de componentes y asesorías Delphi en el D.F. Así que no lo pensé dos veces y me trasladé a la capital de Michoacán (ciudad donde nunca había estado) en noviembre de 2005 para darle clases a esta persona, que resultó ser un gran ser humano y excelente amigo. Al poco tiempo me propuso un proyecto de software bastante interesante que ya traía él entre manos y que creo firmemente nos dará grandes frutos en un futuro cercano. Le hablé de la DTE, ofreciéndole que trabajáramos bajo ese modelo. El análisis quedó a su cargo, la base de datos sería trabajada por un gran amigo de Guatemala, yo me encargaría de la programación operativa y algo de lógica de negocios, pero nos hacía falta un diseñador visual. Buscamos entre varias opciones y finalmente me decidí a contratar a un programador Delphi de mi Chihuahua natal, pero que yo no había tratado antes, pero que decía tener buen nivel en Delphi. Mientras tanto, a nuestro DBA se le presentaron dificultades personales y después de un mes de no localizarlo avisó que no podría trabajar con nosotros. Por otra parte, el programador que había venido de Chihuahua demostraba cada día el bajo nivel técnico que realmente poseía. No le culpo, ni me siento mal con él, porque hoy en día lo considero un muy buen amigo. Sólo que entonces él era algo inexperto en Delphi como para trabajar en ese proyecto. El plan DTE se desestabilizó por completo, el análisis no quedaba bien hecho y los tiempos de entrega se dispararon.

Para entonces ya había comenzado mi relación personal con mi última ex novia (vaya término que he escrito ), con quien nunca me sentí del todo comprendido a pesar del enorme cariño y respeto que nos llegamos a tener. Nuestros mundos siempre han sido tan diferentes. Y para colmo descubrí que la altitud de Morelia no es muy buena para mi salud que digamos. Las cosas se estaban tornando turbias, me sentía algo insatisfecho en el amor, muy insatisfecho en lo profesional y físicamente cada vez más deteriorado. Comenzaba a perder el ánimo y la condición física que había ganado viviendo dos largas temporadas en Cuernavaca.

En Mayo de 2006 invité a otro programador Delphi a venir a Morelia para tratar de enmendar un poco la situación del proyecto de software. Tampoco a él lo conocía en persona, pero sí me constaba que tenía un nivel mínimo como desarrollador. Es difícil describir lo que sucedió con esta persona, pero para tratar de ser justos, podríamos decir que simplemente no encajábamos como equipo de trabajo. Filosofías distintas de vida-trabajo quizá. El caso es que después de 6 meses tuve que prescindir de él porque eran más los disgustos de ambas partes que los avances laborales. Y el proyecto aún seguía atrasado.

Aquí podríamos decir que la quinta barrera es una mezcla de falta de motivación, profesionalismo y compromiso y problemas personales físicos, económicos e incluso sicológicos de los colaboradores. Y creo que yo en particular vengo adoleciendo de todo ello desde que las cosas comenzaron a complicarse en Morelia, aunque quizá menos desde la pasada primavera cuando me di la oportunidad de viajar a Chihuahua y ver a mi familia y las cosas comenzaban a verse más prometedoras con nuestros nuevos clientes del D.F. CodeGear hacía grandes eventos y por un instante me ilusioné pensando que me invitarían a colaborar profesionalmente con ellos.

Entonces contaba yo con tres colaboradores muy leales y estimados. Dos de ellos ordenados y de muy buenos hábitos. Uno de éstos con excelente nivel técnico y analítico, además de experiencia, pero a los otros dos no podía encargarles todavía cosas demasiado elaboradas de programación. No podíamos establecer la DTE todavía porque no estábamos todos especializados. Entonces ya teníamos varios meses con el proyecto que menciono en el hilo “Situación Incómoda”, pero todavía no terminábamos el primero. Me preocupaba demasiado el asunto de la nómina y los pocos ingresos que teníamos, las cuestiones fiscales se complicaron con cinco inesperadas multas del fisco, un nuevo cliente de Ciudad de México no me pagó un servicio de consultoría de una semana por supuestos problemas financieros y nuestro framework no estaba listo como para instalar módulos estables. Mi afán por perfeccionarlo me llevó a poner en peligro la estabilidad del negocio, logré sacar los componentes Magia Data que tanto había idealizado para facilitar la labor de los dos proyectos, pero había descuidado casi por completo la administración y lo peor de todo: había consumido demasiados meses en ello. Ahora ya tenemos un framework y unos componentes relativamente aceptables, yo diría que hasta envidiables, para instalar módulos funcionales, incluso para venderlos a otros desarrolladores dentro de pocas semanas, pero estamos atrasadísimos en los dos proyectos. Lo más terrible es haber dejado de contar con dos de esos tres compañeros. Ahora sólo está el de más reciente ingreso, quien cada día hace mejor su trabajo y a quien veo por muchos años en esta organización. Es curioso decir esto, pero ahora sí tenemos infraestructura de software para tomar proyectos medianos y grandes. Ya tenemos astillero para construir barcos.

Entonces podemos decir que la sexta barrera es una falta de balance e infraestructura. Si un programador bibliotecario se ve obligado a encargarse de la mayor parte de un proyecto, y no se tiene la infraestructura de software (framework, plantillas, bibliotecas de funciones, componentes) suficiente para dedicar la mayor parte del tiempo al los objetivos concretos del cliente, terminará dándole prioridad a su área y descuidando las demás. Sobre todo si es alguien con cierta espina de perfeccionismo o poco conformista, como un servidor. Lo mismo puede pasar con cualquiera de las otras áreas si no existe un balance de personas especializadas trabajando en equipo (¿cuántas veces no se habla por ejemplo de un súper analista UML que por sí solo no saca un solo formulario funcional?) Y si encima, el que tiene más carga de trabajo técnico es también el gerente de la empresa, ¡olvídate!. Por eso es que desde hace mucho tiempo me visualizo como director y programador bibliotecario solamente.

Es curioso verlo de esta manera, pero pareciera que la Providencia me ha hecho pasar por todo esto para vivir en carne propia las vicisitudes típicas de una empresa de software viciada, para luego poner en práctica las teorías que he tenido sobre una base de sólida experiencia. Un duro camino que se recorre para encontrar la respuesta final a la empresa de software exitosa. La compañía diferente y sana que algunos emprendedores semiautistas y soñadores como yo deseamos forjar.

No canto victoria aún, todavía debo entregar ese famoso módulo de cotizaciones por el que se me amenazó con demandarme. Pero la estabilidad empresarial y las satisfacciones personales ya se vislumbran, sospecho que están muy cerca. La DTE será una realidad.

Un abrazo sin barreras.

Al González.

[[Delphius]]

Muchas gracias Al por brindar detalles sobre el tema, plasmar tu sabia y valiente experiencia. No era obligación que respondieras tan rápido. Se que estás demasiado ocupado con tu trabajo... yo expuse el tema con la intención de que quedara allí y que cada persona, en su tiempo libre y si lo desea, exponga sus ideas.

Como ya muchos saben es mi intención tratar de establecer un negocio en forma independiente... y debido a las circunstancias actuales me veo obligado a empezar a ponerme más serio en el tema... pues ya no debo dejar pasar más tiempo.

Por ahora estoy medio ocioso porque debido a serios problemas de salud de uno de los miembros del equipo de trabajo debimos suspender indefinidamente las actividades. Aprovecho este tiempo para actualizarme en mis conocimientos sobre UML, POO, un poco sobre organizaciones, y otras cosas. Teniendo la tesis parada, por recomendaciones más que nada de ánimos y de trabajo... sumado al hecho de que no consigo un disco para reemplazar el que tengo dañado (ya no se consigue discos IDE de 80)... he tenido más tiempo libre que de costumbre.

En fin, estoy más que seguro y dispuesto a arriesgarme, una vez que termine el trabajo al que me veo sometido (o en cuanto avanze lo suficiente como para no depender demasiado), y consiga reparar los desperfectos técnicos de mi equipo, continuar con mi tesis. Luego, en lo posible en dentro de dos meses, adquirir la licencia profesional de Turbo Delphi y empezar... Ya desde hace meses que ando revolviendo entre mis libros y apuntes sobre teorias de stock, inventarios, sobre facturación (muy poco) para empezar a armar (al menos en mi mente) modulos, y/o bibliotecas como para tener algo de base para sustentar algunos posibles trabajos.

Entre amigos de la facultad, hemos estado siguiendo el enfoque DTE implicítamente y nos ha funcionado... pero claro... estamos entre amigos y llevando ya 6 años de estar conociendonos. Muy distinto fue la comunicación en las empresas en donde he pisado.

Todo esto me lo ando planteando por el hecho de que yo ya se perfectamente que no tengo el mejor nivel de programación. Muy a pesar de que hago un gran esfuerzo en llevar una buena regla y nomeclatura. Su documentación minuciosa y sus pruebas.
Yo me siento más cómodo en el área del análisis y diseño, me gusta ver mis modelos y llevarlos a la programación. Y se perfectamente que mi enemigo es la parte del acceso a base de datos (que no así el modelo de la base de datos. A esto le tengo de amigo. Pero hasta allí nomas)
Como dije muchas veces, mucho sobre Delphi aquí en Salta no hay... aunque hace unos días estuve en contactos con gente de Salta que lo está empezando a usar (y tengo la sospecha que se contactaron conmigo porque me han localizado gracias a los foros, y pretender seguir mis novatos pasos)... recien están estudiandolo ya que son ingresantes y/o por hobby.

Emplear DTE tiene sus ventajas, y para alguien que está pensando en meterse en forma independiente... no va a ser demasiado ventajoso... El círculo de amigos, por circunstancias de la vida se está desarmando... ya uno se fue a Bs As a vivir porque recibió una muy buena oferta de trabajo, otros están trabajando y no se animan a dejar sus trabajos (a pesar de que no son bien pagados), Y si bien hemos tenido la idea de que formemos todos juntos una empresa. He notado como el estado anímico por el que cada uno está atravesando nos separa aún más y hace más dificil la unión y poner el juego DTE.

Alberto, tu experiencia me sirve para darme cuenta de las dificultades que puedo llegar a tener si intento aplicar esa forma de trabajar con gente que desconozco si es que llego a tener la oportunidad de formar una mini o minúscula empresa con alguien más. Siento que me falta un poco más de confianza para asumir todas la etapas de trabajo si es que me llego a tropezar con algo medianamente grande (sobre todo si es que luego la empresa en la que estoy metido ahora me pide nuevas alternativas... que es la más cercana a ofrecerme algo).

Y si le sumo mi estado emocional, anímico y personal, el cual siento que debo darle arreglo urgente, más dificil se hace comenzar prontamente...
La verdad es que esto se me hace complicado pero ya, como sea... tengo que arreglar muchas cosas.

Lo más urgente: reparar una relación deteriorada. No es agradable ver en una cena, entre amigos en común, a una persona que le tienes mucho afecto... sentir ese silencio vacío, pero que te pide y te lleva a querer hablar de nuevo.

Muchas gracias Alberto por tu rica experiencia de vida.
A ver si una vez por todas, termino (o empiezo según se mire) con algo.

Me gustaría que alguien más pueda aportar sus perspectivas del asunto.

Saludos,

[[Al González]]

¡Hola de nuevo!

No te preocupes por mi tiempo amigo, sentí que si no escribía eso una parte de mi alma acabaría por morir. Algún día estos textos tendrán un gran valor de orientación en la vida de otras personas, no descarto que incluso los lleguen a usar académicamente. Y que bien, mientras sirvan a otros para alcanzar los mismos objetivos que se plantean.

Has mencionado casi sin querer las dos barreras adicionales que detecto:

7. Falta de comunicación, documentación, estandarización y establecimiento de procedimientos claros y respetables.

8. Desconfianza para iniciar el emprendimiento y / o trabajar en equipo con otras personas.

Empresa de software que supere esas ocho barreras, será una empresa de software verdaderamente exitosa, integrada por individuos felices y satisfechos con lo que están haciendo. Si te das cuenta, las ocho barreras mencionadas son susceptibles de amenazar a cualquier emprendimiento de una empresa de software, no sólo cuando se intenta adoptar el paradigma DTE. Sólo que el paradigma DTE, por su propia naturaleza de orden y eficiencia, exige que las ocho circunstancias adversas estén superadas en una muy buena medida. Mientras que sin DTE, la empresa de software puede sobrevivir "más fácilmente", pero arriesgándose tremendamente a que sus desarrolladores trabajen demasiadas horas a la semana, con la moral baja, desorganizadamente, en ambientes estresantes y algo insatisfechos con su vida. Amén de los círculos viciosos que tales estados generan.

Por eso creo que un esquema similar a la DTE y la superación de esas ocho adversidades típicas es la clave final para que las empresas de software sean empresas verdaderamente sanas.

No me rindo y menos ahora que ya se ve el final del túnel a unos cuantos kilómetros.

Al González.