A partir de mañana comenzamos a vivir de una nueva manera. Tendremos Scrum y habrá felicidad. Democracia completa: sin jefes, el equipo decide qué hacer, se cancela la burocracia, lo principal es hacer el bien al cliente.
Un entrenador vino y nos enseñó lo básico. Habló sobre el éxito inminente, sobre la eficiencia y el enfoque al cliente, sobre la flexibilidad e importancia sin precedentes de involucrar a un cliente en el proceso de desarrollo, y sobre las naves espaciales que aran el Teatro Bolshoi.
Bien bien Espera y mira.
Comenzamos un nuevo proyecto. Bueno, gracias a dios!
Y luego ya estaba cubierto de musgo por estar sentado sobre el código Legacy. Mi fuerza ya no existe, no puedo hacer frente a este gran monstruo de la pasta. De alguna manera intenté mover el botón en el formulario de inicio de sesión, así que obtuve errores del módulo de correo. Piensa dónde está la conexión ...
Nos presentaron a un nuevo empleado, tendremos un propietario del producto o, en ruso, un representante del cliente. Me llamo Rita Mujer encantadora. Le encanta hablar
Hágale una pregunta simple, para que empiece un discurso durante media hora. La miras y piensas: "¡Uh, no entiendes nada!"
Cinco minutos después, comienzas a dudar: "No, es como si dijera".
Al final, te das cuenta de que no has recibido una respuesta a tu pregunta. Entonces te vas.
Lo principal es interrumpirlo de ninguna manera. Intentando encajar y dirigir el flujo verbal en la dirección correcta, pero allí, se sabe que se vierte y nuevamente cuenta sobre los barcos y el Teatro Bolshoi.
Ya teníamos miedo de hacerle preguntas incluso simples. Puede obtener una respuesta, pero puede ahogarse en el océano verbal.
Sí, la burocracia se ha vuelto menos. Porque todos puntuaron en la documentación en general. Ahora la información se transmite principalmente de boca en boca. Por supuesto, entiendo todo, somos muy ágiles, pero no en la misma medida ...
Dada la tarea: desarrollar en la puerta de enlace la capacidad para que el cliente reciba datos para mostrar el gráfico. Debe ir al servicio, obtener los datos sin procesar, volver a contarlos y entregárselos al cliente. No se especifica qué y cómo contar, nadie lo sabe. Solo existe el nombre del gráfico. Bueno, ¿cómo debo hacer esto, me pregunto?
Bien, busqué algo similar en nuestros viejos proyectos, hice un patrón. No hay certeza de que esto es lo que se necesita, no. Extraño, pero a nadie realmente le importa. Lo principal es que introdujimos con éxito una nueva funcionalidad en una manifestación de demostración.
Vengo a trabajar hoy, allí, las mujeres que hicieron pruebas rodearon a nuestra maestra Scrum Kolya, y exigen explicarles cómo funciona la nueva funcionalidad. Kolya mira con ojos de estaño al monitor y murmura algo sobre los modelos y sobre los requisitos cambiantes.
Puedes entender a Kolya: cambiaste algo hace un mes, y es difícil recordar exactamente qué, no hay documentación. Pero las chicas no son azúcar: se les indicó que probaran algo, no sé qué.
Los conocí en el pasillo media hora después: Kolya estaba caminando, las chicas lo seguían y todos se reían: "Modelo nuevo ... modelo antiguo ... requisitos del cliente ...".
Los pobres ...
Tengo una solicitud de extracción para una revisión. Error al exportar el gráfico: las proporciones de la altura y el ancho son diferentes de las originales. Es extraño, porque una vez resolví este problema y me ocupé de todas las proporciones ... El problema se resolvió de una manera original: un colega simplemente multiplicó la altura por 1.25.
Le pregunto
- ¿Qué significa este coeficiente?
"Y esto", dice, "lo recogí". Ahora todo estará bien.
A que hora Él recogió ... ¿Y qué pasará con la exportación de otras cartas? Comenzaron a entender, resultó que solo necesita cambiar ligeramente la secuencia de llamadas. En algunos casos muy raros, se utiliza la configuración de su lienzo, y debe volver a calcular las proporciones después de eso.
Uno tiene la impresión de que a veces es importante que las personas informen sobre su trabajo por cualquier medio, y el resultado final realmente no les molesta ...
Hoy, Rita dijo que decidió usar el desplazamiento infinito al mostrar una lista de documentos. Traté de convencerla de que la situación en el servicio REST está cambiando constantemente: algunos usuarios agregan documentos, otros eliminan. Como resultado, aparecerán elementos adicionales en el formulario o desaparecerán, por lo que es mejor usar la buena vejez. A lo que me dijeron que tal situación es rara, y que el desplazamiento sin fin está de moda y es sexy, los usuarios estarán felices.
Estas satisfecho Hmm ... me enojaría si descubriera que la lista no corresponde al estado actual ...
No entiendo cómo es posible construir un edificio a partir de mierda y palos, sin una base, comenzando al mismo tiempo desde cuatro ángulos simultáneamente. A veces pienso que si los aviones, los barcos de vapor y los rascacielos se diseñaron de la misma manera que el software moderno, los aviones se cayeron inmediatamente, los barcos se volcaron y nuestras ciudades quedarían en ruinas. Está claro que nuestro precio de error es mucho más bajo. Al final, no creamos software médico o espacial. Pero nuestro software es complicado, utiliza muchos microservicios. ¡Es necesario prestar atención al estudio preliminar de los detalles!
Es bueno que no construyamos aviones ...
Miró al departamento vecino y desde el umbral sintió que algo andaba mal. Todos están sentados, golpeando furiosamente los teclados, y en el aire hay una especie de sensación de desgracia general.
De repente, su maestro scrum Vitya salta y cómo gritarle a alguien:
- ¿Qué me estás escribiendo a todos? ¡Dilo oralmente!
Y luego se abrieron paso. De repente se mareó. Oralmente El ruido se levantó extraordinario.
Me quedé un minuto tosiendo, todos se callaron y me miraron. De repente me sentí algo incómodo.
Victor dice:
- ¿Cambiaste la autorización en el servicio?
"Sí", respondo, "cambiado". Ahora los usuarios sin derechos no pueden leer el recurso. Es necesario usar una forma diferente.
- Entonces cambiaste - dice - y ahora la aplicación dejó de funcionar para nosotros.
Estuvo en silencio por un momento y agregó:
- Hiciste todo bien, este es nuestro canto. Pero nosotros, ya sabes, necesitamos implementar el lanzamiento después de tres horas, y no podemos solucionar el error tan rápido.
Quería decirles: "Bueno, demonios, ¡nunca corriste las pruebas, porque la semana ya pasó!", Pero les miró a la cara, se dio la vuelta y fue a hacer un retroceso en el servicio.
El jefe nos reunió hoy y dice:
- Deberíamos tener una epopeya. Queremos introducir el aprendizaje automático para personalizar los resultados de búsqueda.
La gente, por supuesto, está interesada en lo que significa y si hay una descripción del problema.
- Todavía no hay una descripción completa, te lanzaré enlaces a lo que es. Piensa por ahora, - respuestas. Y se fue.
Luego miré la página por su enlace: título y dos párrafos. ¿Y cómo crees que deberías pedir, si no está claro en qué pensar?
Lo que les sucede, porque había personas técnicas, surgieron de desarrolladores simples, y ahora es como si se degeneraran en clientes. Escuché en alguna parte que la inteligencia artificial está de moda y genial, y comencemos una épica. Ni una tarea para concretar, ni una especificación exacta para escribir, todo es materia alta y naves espaciales con teatros ...
Me encuentro con Vitya hoy en el corredor y pregunto:
"Bueno, ¿encontraste un error?" Ha pasado un mes. Sería necesario restaurar la autorización en el servicio, de lo contrario vivimos con un agujero.
Vitya mira hacia otro lado y dice:
- No, aún no encontrado. No hay suficiente tiempo en absoluto ...
Bueno, aqui estas. Durante un mes, las personas no pueden encontrar un lugar donde se use el punto final incorrecto. Aparentemente, ya han abandonado esto y se dedican a los asuntos actuales. Es extraño, porque el programa, de hecho, usa datos incorrectos ...
Sí, aquí nuestro nuevo portal se ha convertido en una bola de pasta apretada, y ya es imposible encontrar los extremos. ¡Rápidamente, lo logramos!
Estoy tratando de convencer a mis colegas para que hablen con mis superiores sobre el estado actual de las cosas. Desde mi punto de vista, el proyecto se encuentra en un estado deplorable: diferentes equipos, resolviendo sus tareas, realizan ediciones que aumentan el caos, la entropía está creciendo. Cada vez, resolver problemas se vuelve cada vez más complicado.
Los chicos están de acuerdo conmigo, pero mis iniciativas son geniales. Y pueden entenderse: todos tienen tareas actuales que deben resolverse durante el sprint. No depende de filosofar, hay que hacer cosas ...
Admito: inventé este diario. Todos los personajes son ficticios, las coincidencias son aleatorias. Esto es solo una broma.
A veces sucede que la gerencia percibe a Agile un tanto vulgar: es suficiente para delinear ligeramente la tarea y un buen equipo se ocupará de todos los problemas arquitectónicos y conceptuales por sí solo. A menudo se olvidan de la necesidad de una documentación exhaustiva, aunque el uso de Agile no significa en absoluto un rechazo de la documentación.
Sin embargo, no quería hablar sobre Agile o las tecnologías de desarrollo. Quiero especular sobre la calidad del software que creamos y cómo las malas decisiones pueden destruir este software.
Conflicto de intereses
Eres un desarrollador El proyecto o parte del proyecto en el que está trabajando es su hijo favorito. Lo creas y lo nutres, quieres que tengas una creación perfecta. Para que sus colegas y usuarios puedan decir: "¡Sí, esto es algo genial!".
Pero trabajas para el negocio que te contrató. Las empresas no están interesadas en tus ambiciones. El objetivo principal de un negocio es el beneficio, y con razón. Aquí estás al mismo tiempo que en el negocio, ¿porque quieres que la mayor cantidad de gente posible use tu proyecto?
Pero por una razón u otra, una empresa puede tomar decisiones que violan la armonía de su proyecto. Digamos que necesita ajustar algo muy rápidamente, de lo contrario el cliente se irá. No hay tiempo para resolver el problema correctamente.
Que hacer
Lo más probable es que tenga que romperse, esperando que las muletas actuales se puedan quitar más tarde ...
Sin embargo, no todo es tan triste. A la larga, el negocio es su aliado en la lucha por la calidad, a menos que, por supuesto, sea un enemigo de sí mismo.
Sin embargo, era necesario cumplir con un enfoque tal que a veces se puede descuidar la elaboración cuidadosa de detalles y análisis, ya que la satisfacción rápida y barata del cliente es lo más importante. ¿Es posible el éxito en este caso?
¿Es posible el éxito?
La paradoja es que dichos productos pueden tener éxito comercial, al menos en la primera etapa. Los clientes, por supuesto, están molestos por muchas deficiencias e inconsistencias en el sistema, pero, en general, el producto resuelve sus problemas.
Los clientes están satisfechos con el nivel de soporte: están atentos a sus necesidades y tratan de satisfacer rápidamente nuevas necesidades. Es cierto que algunos de ellos con el tiempo notan que el sistema se está volviendo cada vez más inconsistente e impredecible en el comportamiento, la interfaz se está volviendo más complicada, se está volviendo cada vez más difícil entender lo que está sucediendo en el interior, cómo resolver un problema en particular correctamente, hay problemas con el tiempo de respuesta, etc. Pero esto sucede gradualmente y al principio imperceptiblemente.
Nadie sospecha que el proyecto está condenado. Pronto, inevitablemente colapsará debido a la severidad de todas las extensiones unidas a él a toda prisa.
¿Qué tan conectada está la armonía interna del producto con sus cualidades de consumo? A menudo sucede que los desarrolladores están en un estado de horror permanente por el estado interno del sistema, mientras que los clientes están aparentemente satisfechos. ¿Pero puede un avión feo ser bueno? ¿Y no debería reflejarse la armonía interna de un producto en sus cualidades de consumidor?
No es ningún secreto que a menudo se esconden interiores obscenos detrás de una hermosa fachada, y esto se aplica no solo a las pequeñas empresas, sino también a los gigantes de la industria del software. Aquí hay solo un
ejemplo .
Las compañías monstruosas pueden permitirse el lujo de contratar a miles de programadores para apoyar el gigantesco plato de espagueti en el que se ha convertido su producto a lo largo de los años y décadas, pero para las pequeñas empresas es una forma asesina. Y, por cierto, incluso para los monstruos, la baja calidad del código no pasa sin dejar rastro y se convierte en un tiempo de desarrollo e implementación exponencialmente creciente para cada nueva característica, un proceso más costoso y una calidad de soporte que disminuye constantemente.
¿Qué es más importante: la calidad del producto o las habilidades de ventas?
Un producto de calidad, por desgracia, no es garantía de éxito.
Tuve un caso en la práctica cuando un programa altamente especializado que funcionó bien en Rusia tuvo que ser promovido al mercado europeo. El programa utilizó su propio formato de datos, y la conversión de los datos de clientes disponibles en ese momento no fue particularmente difícil. Si logramos celebrar contratos, nos convertiríamos en monopolistas en Europa por un tiempo. Parece que todo está de nuestro lado: la demanda en el mercado es grande, hasta ahora nadie puede ofrecer algo completo y realmente funcionando, excepto nosotros, el programa ya está trabajando en cientos de puestos de trabajo en Rusia, los clientes rusos responden positivamente sobre el producto.
Y entonces, ¿hemos tenido éxito? Por desgracia no. La licitación fue ganada por una empresa europea que ya ha trabajado con clientes en otras áreas. En ese momento, solo estaban al comienzo del camino que ya habíamos recorrido, pero lograron vencernos. Lamentablemente, no contamos con buenos especialistas en promoción y ventas, y no pudimos convencer a las personas para que tomaran una decisión a favor de nuestra empresa. Luego, después de un tiempo, fue muy decepcionante ver nuestros logros en la organización de la interfaz de usuario en su nuevo producto ...
Malas decisiones
Un producto de alta calidad es un objetivo estratégico, y una empresa inteligente siempre estará del lado del desarrollador, luchando por la excelencia. Pero mantener la armonía interna del producto no es fácil. Con el desarrollo del producto, nos llegan nuevos requisitos que pueden destruir la armonía original de los conceptos. Las decisiones que se toman en este caso juegan un papel decisivo en el futuro destino del producto.
Nadie está a salvo de las malas decisiones. Si se toma una decisión estratégica en la etapa de diseño, y con el tiempo, queda claro que estaba equivocado, esto lleva a la muerte del proyecto. Pero a menudo se toman malas decisiones durante el desarrollo cuando se agrega una nueva funcionalidad. Todo depende, en primer lugar, de la globalidad de las decisiones tomadas, es decir, del grado de su influencia en el sistema en su conjunto, y en segundo lugar, del número de malas decisiones. Cuando el número de malas decisiones y el grado de su influencia excede un cierto umbral, comienza una larga y dolorosa agonía.
Me gustaría compartir con ustedes algunos ejemplos de malas decisiones de mi propia experiencia. Por supuesto, estos ejemplos de ninguna manera reclaman amplitud académica y sistematización.
Reglas laxas
A veces nos parece que para la conveniencia del usuario, las reglas deben ser flexibles.
Por ejemplo, su sistema funciona con diferentes tipos de jerarquías creadas por los usuarios. Decide que para uno de los tipos la clave de nodo es única solo dentro del nivel y no en toda la jerarquía. Esto parece conveniente ya que el usuario carga la jerarquía en niveles.
Consecuencias: ahora, los programadores de todas partes del código tendrán que encargarse de preparar la clave compuesta, y esto a menudo conducirá a errores. Si los usuarios tienen acceso a los sitios por clave, esto también será un dolor de cabeza para ellos.
Puede valer la pena considerar reglas más estrictas y requerir la singularidad de una clave en toda la jerarquía. Esto beneficiará tanto a los desarrolladores como a los usuarios.
Violación de las reglas.
Tiene una jerarquía compleja de objetos creados por el usuario. Cada objeto contiene la propiedad Nombre, que es la clave, y el Título con texto arbitrario. Hay un conjunto de reglas formales para un nombre, por ejemplo, el nombre no debe contener espacios ni caracteres especiales. En algún momento, surge la tarea de generar automáticamente objetos de un tipo a partir de otro. El nombre debe basarse en el título y ser reconocible. Decide romper las reglas y usar Título como nombre: le parece que será más conveniente para los usuarios.
Prepárese para los problemas en su sistema que ocurrirán en lugares inesperados.
Configuraciones de complejidad
Usted ingresa configuraciones que son válidas solo bajo ciertas condiciones. Cuando algunas instalaciones funcionan bajo la condición de que otras estén incluidas, esta es una situación bastante común. Pero si tiene una jerarquía compleja de actitudes, algunas de las cuales funcionan cuando otras están encendidas, y esas, a su vez, son condicionales, este es el camino hacia el caos. La experiencia muestra que, en este caso, nadie está listo para predecir cómo el cambio en una instalación en particular afectará el comportamiento: ni los usuarios ni los desarrolladores. El sistema de configuración debe ser claro, tan obvio como sea posible y cuidadosamente pensado. Debe esforzarse por reducir las dependencias de algunas configuraciones en otras.
Falta de análisis del problema.
Su sistema permite al usuario crear informes basados en DSL. Al principio se decidió que DSL contiene todas las propiedades del informe. Después de un tiempo, uno de los clientes le pide que agregue la capacidad de almacenar parte de las instalaciones por separado; esto es necesario para resolver algunos problemas internos del cliente. Iniciar una tarea en "Agregar configuraciones externas" de Jira sin analizar primero el problema es un error. En primer lugar, es necesario responder la pregunta: ¿por qué se necesitaba en absoluto? Es posible que el cliente solo quiera ocultar parte de la configuración para algunos usuarios. ¿Quizás debería considerar dividir DSL en partes con la autorización de estas partes? La decisión no es tan rápida, pero quizás estratégicamente correcta.
Decisiones políticas
A veces las decisiones se toman por razones organizativas. Por ejemplo, ciertos recursos se almacenan en un microservicio especialmente diseñado para esto. Se requieren varios tipos de recursos similares. Un equipo está involucrado en el servicio, y otros necesitan nuevos tipos de recursos. Para compartir la responsabilidad, se toma la decisión de agregar nuevos tipos no al servicio original, sino a los servicios administrados por otros equipos.
El problema es que el servicio no solo almacenó datos, sino que también proporcionó autorización. Ahora debe de alguna manera ocuparse de reutilizar el código. Pero esto no es lo principal. Lo principal es que ahora no es obvio qué servicio se debe utilizar para obtener los datos necesarios.
La evidencia interna de construir un sistema se sacrifica por motivos organizativos o políticos.Conclusión
Como desarrollador, quiero estar orgulloso de los resultados de mi trabajo. Para mí, la belleza interior, la elegancia y la armonía del proyecto son importantes. Pero no menos importante es la demanda. No quiero trabajar para la canasta, quiero que la mayor cantidad de gente posible use el producto y esté satisfecho. Entiendo que a veces tienes que ir a los costos y estropear un poco la armonía interior para complacer los intereses de los clientes individuales. Pero estoy convencido de que detrás de la hermosa fachada no debe haber vergüenza, los interiores feos tarde o temprano saldrán, no importa si se trata de una confusión externa en los conceptos, o un tiempo de respuesta cada vez mayor a los problemas de los clientes.La belleza y la armonía del producto es lo más importante. Sí, a veces nos vemos obligados a comprometernos en interés de los negocios y estamos listos para difuminar la claridad de los enfoques en interés de un cliente en particular, especialmente si es un cliente muy importante, pero esta es una pendiente resbaladiza.Más de una vez tuve que observar la extinción gradual y la muerte de los proyectos, cuando las personas no se molestaron en estudiar cuidadosamente los detalles e introdujeron nuevas funcionalidades sin pensar, sin preocuparse por las inconsistencias en el producto y sin prestar atención a la aparición de conexiones nuevas e innecesarias entre los módulos. Esto siempre conduce a la confusión, cuando se hace cada vez más difícil corregir el error más simple, ya que no hay certeza de que esta corrección no tendrá un efecto inesperado en componentes y partes completamente extrañas del sistema.¡Deseo desearles una larga vida a sus proyectos!