¿Qué sucede durante la automatización normal? Se elabora una tarea técnica, requisitos funcionales, arquitectura y un montón de otros papeles. Describe todas las condiciones, limitaciones, algoritmos de trabajo según el entorno, la apariencia de los formularios, la validación de datos, etc. A menudo, el diseño y la coordinación de estos papeles lleva más tiempo que la automatización en sí.
Aparece un proyecto, un cronograma, una descomposición de tareas, un cierto gerente de proyecto, o incluso varios. Las formalidades se hacen cargo, es decir forma, no contenido.
Está claro que en algunas situaciones esta es la forma de actuar. Por ejemplo, si una empresa externa se dedica a la automatización, no sobrevivirá sin dichos documentos. solo perseguirá después de alcanzar los requisitos de fugitivo. Los documentos garantizan la estabilidad, la previsibilidad de los pagos y la entrega del trabajo. Pero para el cliente, estos trozos de papel garantizan solo una cosa: un proyecto largo y aburrido que no traerá ningún beneficio.
En la programación empresarial, este enfoque no es adecuado. Permítame recordarle que la programación de negocios es un cambio complejo, al mismo tiempo para los procesos, la motivación, los objetivos, el sistema de gestión, respaldado por la automatización.
Por ejemplo, usted decide cambiar el proceso. No es una que afecte a mil personas: no hay solución en su rodilla. El proceso, por ejemplo, concierne a cinco personas de un departamento. Todas estas personas, como su líder, están sentadas a tu lado, aquí están, con el brazo extendido. Y decidiste, junto con ellos, cambiar el proceso. Se sentaron, hablaron, descubrieron, pensaron y decidieron. Por ejemplo, te tomó un día cambiar el proceso.
En la mayoría de los casos, después de cambiar el proceso, necesita automatización, debe realizar cambios en el sistema de información. Si dice: necesita una tarea técnica, un cronograma, un proyecto con un líder, curador y patrocinador, entonces eso es todo. Aquí es donde terminarán sus cambios. Un proyecto de automatización largo con formalidades negará el cambio de proceso.
Lo que es especialmente importante: los cambios en los procesos son experimentos. Usted, incluso siendo un programador de negocios sofisticado, no puede saber con certeza si su cambio funcionará o no. El método elegido podría mostrarse bien en otro proceso, o incluso exactamente en el mismo, pero en una empresa diferente, pero en este contexto puede resultar inoperante.
Como se trata de un experimento, tiene límites de tiempo: hoy se pensó, se lanzó mañana, lo miramos durante una semana y tomamos una decisión. Si todo está bien, vete. Si no, pensamos más: cancele el cambio o refine y mejore.
¿Qué pasará con la automatización esta semana? Si elige el camino tradicional, en una semana solo tendrá la tarea técnica, y luego en el mejor de los casos. En consecuencia, la implementación de los cambios tendrá que hacerse manualmente, sin automatización. Bueno, si realiza cambios que no requieren automatización, puede verificarlos "a simple vista". Y si no?
Aquí es donde se necesita el principio de automatización rápida. En realidad, su esencia radica en el nombre: los cambios en el sistema deben realizarse rápidamente, sin coordinación y requisitos, exactamente en la medida que sea necesario para probar la hipótesis principal que usted presenta al cambiar el proceso.
No tiene que preocuparse mucho por la interfaz, verificando los datos de entrada, la optimización del código, la estructura de datos y otros pilares de la automatización "correcta". Su tarea es apoyar rápidamente la automatización de los cambios en el proceso para verificar si funcionan o no.
El principio de la automatización rápida es conocido por todos los programadores. Solo ellos lo conocen no como un principio, sino como un gran mal: se cree que la ignorancia, la mediocridad y los principiantes están involucrados en tal automatización.
En parte los programadores tienen razón. Pero tienen un contexto fundamentalmente diferente. Por lo general, ¿cómo se hace? Hay algunos "tramposos": analistas de negocios, usuarios y sus líderes. Se les ocurrió algo allí, y dicen, así que rápidamente háganme una forma / campo / ventana. Qué, cómo, por qué, por qué, no explique. Todavía agregue, vamos rápidamente, botas. ¿Qué le queda al programador? Si hay una oportunidad, comenzará a improvisar: diga que es imposible, por lo que necesita una tarea técnica, una arquitectura reflexiva, una refactorización, etc. Pero, como regla, no hay posibilidad de hacer trampa, y el programador simplemente lo hace rápidamente, "de rodillas", en modo de programación extrema.
Bueno, más o menos, y está bien, al diablo con él, ¿verdad? Propuse exactamente eso: ¿rápidamente, sin problemas, si tan solo funcionara?
Un momento clave surge cuando los "traidores" ven la falta de sentido del cambio. El programador de negocios simplemente cancela dichos cambios y le pide al programador que elimine los fragmentos de código introducidos. ¿Qué pasa con el "tramposo"? O, más precisamente, "tramposo"?
No cancelará nada. Simplemente déjelo como está y, en el mejor de los casos, continúe haciendo cambios. ¿Entiendes? Sin cancelar los anteriores, terminará nuevos, más y más.
Hay un momento político, especialmente si el jefe del departamento presentó los cambios. Es extremadamente importante para él no parecer estúpido, por lo tanto, no importa qué tontería haya inventado, no lo cancelará. Además, si lo empujas contra la pared, protegerá sus cambios.
La mayoría de las veces sucede que nadie usará los cambios realizados. Si eres un programador, entonces esta situación puede ser familiar para ti. Preguntaron, ordenaron, exigieron hacer algún tipo de sistema, y luego no lo usaron. Incluso se puede hacer no "sobre la rodilla", sino que normalmente cumple con todos los requisitos y condiciones de la automatización "correcta", pero aún así no la usan. Ahora ya sabes por qué. Y por qué nadie elimina esta funcionalidad del sistema, también lo sabe ahora.
Así es como los pasteles en capas de automatización de patchwork sin sentido resultan y crecen. Los programadores se ríen, pero hacen lo que dicen. El fango, la no optimización, la estructura curva y la arquitectura crecen como una bola de nieve. Y cuanto más lejos, más difícil será detener este proceso y revertirlo.
Otro problema es la falta de sentido de los cambios propuestos en su conjunto.
En la programación empresarial, cualquier cambio tiene un objetivo que todos los participantes entiendan. El proceso debería ser más rápido, más confiable o más controlado. Por lo tanto, tanto el propósito de los cambios como los criterios para evaluar su efectividad son siempre claros.
Pero cuando los cambios se hacen "así", o "para que sea más conveniente para mí", o "¡bueno, igual de bien!", Es imposible evaluar el resultado. Por lo tanto, los cambios, por insignificantes que sean, siguen vivos, tanto en el proceso como en la automatización.
Ahora comprende cuál es el problema: la brecha entre el cambio de proceso y la automatización. Cuando algunas personas presentan cambios en el proceso y luego establecen tareas de automatización para otras personas, sin explicar el significado y la esencia, obtenemos un desastre normal que no beneficia a nadie.
Según los estándares de la programación empresarial, el trabajo se lleva a cabo en un equipo: hay personas de procesos y personas de automatización. Aún mejor, cuando este trabajo es dirigido por una persona: un programador de negocios. Aún mejor cuando hace la automatización él mismo.
En este caso, entendemos y gestionamos el ciclo de vida de los cambios temporales: por qué se hacen, cuándo comienzan y, lo más importante, cuándo y en qué condiciones terminan.
Supongamos que los cambios fueron incorrectos: esto es normal, no hay nada de malo en eso. Luego, los programadores tienen un trabajo inusual: eliminar los cambios en el sistema. Por supuesto, a veces hacen ese trabajo ellos mismos, refactorizando, por ejemplo. Pero en el caso de la programación empresarial, dicho trabajo debe realizarse periódicamente.
¿Y si los cambios fueran correctos? Luego, entran en juego todas las habilidades de la automatización "correcta", de la que los programadores están muy orgullosos. Debe estimar la arquitectura, la estructura de datos, los algoritmos, la verificación de los datos ingresados, la interfaz, etc. Pero, ¿cuál es la diferencia, ves?
La diferencia en la forma del enunciado del problema. Por lo general, esta es una tarea técnica, es decir, un trozo de papel. En nuestro caso, la tarea es un prototipo. Un trabajador que ha demostrado su utilidad y efectividad, probado, por así decirlo, en la batalla. Solo es necesario recordarlo. Realmente no necesita coordinar y discutir nada, solo tómelo y cree un sistema de acuerdo con las reglas y estándares del entorno en el que se crea el programa.
Si participa en una programación rápida todo el tiempo, adquirirá rápidamente la habilidad, hágalo de inmediato para que pueda solucionarlo más tarde. Aquí la "pereza correcta" del programador jugará en nuestras manos: no estará dispuesto a resolver el mismo problema dos veces, y él mismo descubrirá cómo hacer rápidamente un prototipo y convertirlo en una solución completa con un mínimo esfuerzo. Aunque, en programación de negocios, por supuesto, no hay soluciones completas.
Ahora se ha convertido en una práctica común, como la creación de prototipos y el modelado, cuando antes del inicio de un gran proyecto de automatización, rápidamente, con un mínimo esfuerzo, sin problemas con la interfaz, crean un cierto prototipo del sistema futuro. Como saben, esto es muy similar al principio de la automatización rápida, aunque el punto, por supuesto, no es cómo se creó el prototipo, sino cómo se adaptará a un entorno cambiante.
Si la creación de prototipos es solo una estratagema de marketing de una empresa integradora, y de todos modos aparece un gran pedazo de papel, como una tarea técnica, entonces esto es solo un truco. Crea la ilusión del cliente de que "todo será como lo necesito", pero, por desgracia, no será así en la vida. El prototipo no vivirá mucho y desaparecerá en la oscuridad.
Y ahora entiendes por qué. La automatización es casi siempre un carro, no un caballo. El caballo es un cambio en los procesos, y el carro sigue. Pero solo monta si está unido a un caballo.
El caballo giró, el carro lo siguió. Con retraso, con contragolpes y derivas, pero girado. Y si cada caballo y carro viven sus propias vidas, entonces el carro debe ser llevado por programadores infelices. Un gran prototipo de un gran sistema creado antes de un gran proyecto de automatización es una instantánea, una instantánea de un caballo enganchado a un carro. Todo es hermoso, todos están felices, a todos les gusta, pero pasa un día, una semana o incluso un mes, y el caballo tira el carro y va a donde necesita. Y el carro es hermoso, elegante, hecho de acuerdo con todos los cánones, queda solo en el campo.
Por lo tanto, los prototipos "grandes" no valen la pena. Así como la "gran" automatización. Para comenzar y llevar a cabo un gran proyecto de automatización, uno debe tener una mente extraordinaria, previsión y un talento increíble en la gestión. Si estas palabras son sobre ti, te felicito sinceramente y te deseo todo el éxito.
Recomiendo el resto para utilizar el principio de automatización rápida.
Y una vez más les recuerdo: la automatización sigue el cambio de procesos. No antes de un cambio, no en lugar de un cambio, no separado del cambio. Cambiaron el proceso, automatizaron rápidamente, observaron el resultado. Bien, tráelo rápidamente a la mente. No es bueno, tíralo a la basura.