Get best of the week

¿Cómo evitar la indignación de la programación? Consejos integradores

En un artículo anterior sobre los problemas de introducir ERP en empresas industriales como un estudio de caso, uno de los puntos fue llevado al "Caos programático".

Tenemos un cliente cuyos empleados ahora, enviándonos requisitos dudosos, especifican si se trata de una ilegalidad programática. Y algunos no especifican, sino que lo crean.

imagen

El tema es relevante, y decidí escribir un artículo separado al respecto.

¿Qué es?


¿Qué tipo de pinturas pinta tu imaginación cuando escuchas la frase "ilegalidad programática"?
Un hombre barbudo con una mirada pensativa inteligente golpea al contable jefe lloroso con un volumen de Knut, diciendo: "Kopek, ¿dices que no has aceptado la factura? ¿El destinatario no cabe en la celda? ¡Ahora lo estamparemos con un libro y todo encajará! ”
, - . , : « 10 , ? ? , ?» — , - … : « – : , . : … …»
Este fenómeno es menos colorido de lo que puedes imaginar, pero más terrible. Al final, el contador principal puede calmarse, enjuagarse las lágrimas y enviar a un psicólogo, los maestros pueden ser desatados de una silla y enviados a trabajar. Pero las curvas de publicación en InventTrans y rotas debido a errores de cálculo en la arquitectura de la solución y mejoras innecesarias, el psicólogo no corregirá la planificación sumaria.

La ilegalidad programática es una situación en la que, como resultado de la programación, el propósito de esto era resolver ciertos problemas de un negocio, se crean otros problemas para los negocios, a menudo más serios.

Dejame darte un par de ejemplos:

  • , , . - , .
  • . , , «» . . , , .

Quería nombrar el artículo "Caos del programador. Integrador llorando ”, pero me di cuenta de que a nadie le importan nuestras lágrimas. Pero los consejos sobre cómo evitar tales situaciones pueden ser útiles.

Intentaré delinear los límites de mis recomendaciones de antemano; estamos hablando de:

  • programadores que participan en la implementación o mantenimiento de sistemas ERP. Creo que tienen requisitos ligeramente diferentes que, por ejemplo, los desarrolladores de un nuevo producto o tecnología;
  • programadores que trabajan con el cliente. Los desarrolladores integradores son menos propensos a la "indignación".

Entonces, ¿cuáles son las causas de este fenómeno y qué se puede hacer al respecto?

Falta de voluntad o incapacidad para mirar la esencia del proceso


A menudo veo esto con analistas y programadores novatos. Simplemente responden la pregunta que el cliente les hizo. No piensan en ello. ¿Por qué preguntó al respecto? ¿Realmente lo necesita? Con el tiempo, esto pasa, pero al principio tienes que atrapar y explicar.
"¿Y puedes aumentar el número de decimales para este coeficiente a 4?" - "Por supuesto". ¿Pero nada de que este coeficiente se use para indexar el parámetro, que tiene una precisión de 1 decimal, y los valores no exceden de 50? Toda la precisión del coeficiente irá al redondeo. Entonces, ¿tal vez es mejor no hacer esto?

“Agregue un nuevo campo de este tipo a la referencia de nomenclatura” - “Bien. La complejidad de 15 minutos ". Entonces, ¿por qué necesita este campo en las nomenclaturas? Esta es una característica que varía de una fiesta a otra. ¿Quizás sea mejor agregar este campo al directorio de partes?
Un desarrollador en ERP no tiene que ser solo un implementador de los cambios que realizan los usuarios. Necesita comprender la lógica del sistema y actuar como su protector contra todas las tonterías. Para hacer esto, sería bueno comprender los procesos de negocio al menos al nivel del sentido común y poder hacer preguntas incómodas a los usuarios.

Por lo tanto, si uno de los usuarios nunca ha recurrido a usted con quejas sobre la imprudencia de un programador que se negó a implementar su Lista de Deseos, este desarrollador debería analizarlo más de cerca. Quizás solo hace lo que dicen. Y esto rara vez termina con algo bueno.

Falta de resistencia en la lucha contra el deseo de dejar todo a la antigua usanza


Este es el caso cuando el desorden del programador no es creado por los desarrolladores, sino con su connivencia.

Cualquier producto serio conlleva no solo un conjunto de ciertas funciones, sino también una ideología, mejores prácticas. Y la gente quiere trabajar a la antigua usanza. Y presionaron al programador para que le brindara esta oportunidad. Y si no podía probar que esto no debía hacerse, entonces todo podría terminar tristemente.

, , , . . : « 1974 , , ». , , , , . « , , – ». , , , . , . , , . : , , - , . : «».
¿Qué se puede hacer con esto? Para empezar, no subordine al programador a los servicios económicos. Debe trabajar en otra unidad y tener cierta independencia de la gestión de los departamentos cuyo trabajo está automatizado.

Sería bueno agregar un enlace a esta cadena: cualquier mejora seria debe ser aprobada no solo por el contratista, sino también por alguien que entienda el negocio de la empresa en su conjunto y tenga poder. Tal persona definitivamente puede decir: "No."

El hábito de resolver todos los problemas programando


El amor por la automatización conduce al progreso, pero a veces perjudica. He sido testigo de cómo, en lugar de indicar a las personas que ingresen datos manualmente en el sistema, esta entrada se automatizó. Automatizado, olvidando algunos detalles o características que necesariamente se habrían notado, discutido y probablemente corregido con la entrada manual. Y así, todos están seguros de que no hay errores, pero después de un tiempo las consecuencias surgen en masa, lo que ya es mucho más difícil de solucionar que la causa raíz.

, , . , , , . . , . , , . : .

Por lo tanto, cuando se le pide a un programador que escriba un script para corregir 200 errores que surgieron debido al hecho de que los usuarios no trabajaron de acuerdo con las instrucciones, no debe precipitarse de cabeza al teclado. Necesitamos estimar cuánto tiempo lleva corregir un error manualmente, y si el tiempo para corregir manualmente todos los errores no excede la complejidad de escribir un script en un orden de magnitud, haga que los usuarios corrijan estos errores por sí mismos: hay más posibilidades de que funcionen de acuerdo con las instrucciones en el futuro. Esto se debe introducir como regla, colgado en la pared cerca del programador para que pueda meter a todos los visitantes en este pedazo de papel.

Además, por alguna razón, creemos que si las personas se liberan del trabajo de rutina debido a la automatización, harán algo útil: comenzarán a ofrecer ideas para mejorar los procesos comerciales, optimizar los informes y capacitar a colegas menos experimentados. Pero lo más probable es que simplemente tengan más tiempo para el té, las pausas para fumar y la Internet en el trabajo. Entonces ¿Vale la pena?

Auto confianza


Hay una funcionalidad que no debe modificarse. En Axapt, esto es, por ejemplo, planificación maestra. En mi memoria, lo tocamos solo 2 veces. Y cada vez no se incrustaba en el código, sino una especie de "mancha", funciones que se realizaban antes o después de la planificación consolidada. Y aun así, recuerdo estas mejoras con añoranza.

Hay lugares menos obvios donde no debes subir. Y una excelente manera de distinguir a un programador experimentado de un principiante es ofrecerle refinar dicha funcionalidad: uno experimentado se sorprenderá y rechazará, puede aconsejarle que optimice el proceso comercial, y el principiante dirá: "Vamos".

Aquí se puede aconsejar una cosa: contratar personas con experiencia que, ya de otros clientes o en otros proyectos, obtuvieron todos los obstáculos que, en principio, podrían llenarse.

Falta de regulaciones de desarrollo


Cuando tomamos un proyecto de soporte, uno de los primeros documentos que le pedimos al cliente son las regulaciones de desarrollo que describen el entorno de desarrollo, las reglas para nombrar objetos, prohibiciones y restricciones. Lo más extraño es que a veces no sucede. Y esta es una señal segura: habrá basura en el código: a partir de la clásica falta de comentarios y terminando con situaciones en las que los valores específicos de los directorios para diferentes ramas del algoritmo se escribieron directamente en el texto. Y la basura en el código es el primer paso para los problemas con el negocio.

Por lo tanto, no hable sobre el hecho de que “programar es un arte. No está regulado "," pero ¿qué pasa con ágil? " y eso es todo. Si se está desarrollando, entonces debería haber una regulación. Y esto no es 3 puntos:

  1. el desarrollo se lleva a cabo en la aplicación de desarrollo;
  2. la prueba se lleva a cabo en la aplicación de prueba;
  3. El código debe tener comentarios.

Este debería ser un documento completo con diez páginas con secciones:

  1. Requisitos para aplicaciones de desarrollo.
  2. Requisitos para escribir la declaración del problema.
  3. Requisitos para escribir código.
  4. Requisitos de prueba.
  5. Requisitos de migración entre aplicaciones.

Como regla general, todo el código duro se realiza de acuerdo con el principio "Hagámoslo rápido y luego hagámoslo normalmente". Se hace rápidamente, y luego se olvida ... Y cuando hay un documento firmado que dice que esto no se puede hacer, siempre se puede meter en él y decirle al usuario: "No funcionará rápidamente, tengo prohibido trabajar así. Lo siento, Alevtina Svetozarovna, me gustaría comentar todos los cheques directamente sobre el trabajador, pero luego me despedirán ".

Soledad y falta de control


Un programador solitario es malvado. Siempre debe haber alguien que diga: "Bueno, ¿qué has hecho, tonto?" - De lo contrario, el desarrollador se relaja, olvida las reglas, olvida la responsabilidad. Aquí es donde comienza el hardcode, dudosas decisiones arquitectónicas, errores que afectan al negocio.

De una manera inteligente, esto se llama una "revisión de código" y esto es algo que siempre debe acompañar a las regulaciones de desarrollo. Después de cada revisión, antes de probarlo, debe verificarse el cumplimiento del código con las normas de desarrollo y las mejores prácticas. Una revisión del código permitirá:

  • controlar la calidad del desarrollo;
  • capacitar a programadores menos experimentados.

Por lo tanto, los desarrolladores deben tener al menos 3 piezas (dos siempre estarán de acuerdo en que no puede hacer nada, un tercero en el sistema reducirá significativamente la probabilidad de colusión). Y deben funcionar de acuerdo con las regulaciones internas, uno de los puntos clave es la revisión obligatoria del código.
imagen


Conclusión


Por lo tanto, para reducir la probabilidad de "ilegalidad programática", es necesario formar su propio departamento de desarrollo interno de acuerdo con las siguientes reglas:

  • Este debe ser un equipo de al menos 3 personas.
  • Al menos uno de este equipo debe tener experiencia en la implementación o mantenimiento de un sistema ERP, debe ser su noveno proyecto, donde n> 3.
  • Lo ideal es que el departamento de desarrollo informe directamente al CEO.
  • Los usuarios finales a veces deben quejarse de que los programadores se niegan a implementar algunos de sus requisitos.
  • Incluso para un departamento tan pequeño, se deben desarrollar regulaciones, cuya violación debe ser castigada.

Naturalmente, esta es mi visión. Se puede argumentar que, para cada uno de estos puntos, incluso puedo dar contraejemplos de mi experiencia cuando el requisito no se cumplió, pero todo fue perfecto. Pero estas recomendaciones pueden usarse como punto de partida para la formación de sus principios de lucha contra la ilegalidad programática.

More articles:


All Articles