Rusia es irracional. Hay prácticas correctas, hay cientos de veces un rastrillo sentido, pero aún así, algo épico sucede con una constancia envidiable. A veces por la razón: "Bueno, sin duda me dejará boquiabierto", a veces: "Siempre lo hice y funcionó", a veces solo por errores. Quizás en los genes.
El primer ejemplo vívido de un juego increíble (los detalles se modifican ligeramente a petición de los guardias de seguridad). El cliente se dedica a la construcción de capital. Hace varios años solicité un sistema a un contratista que maneja todo esto (en particular, el trabajo estimado). El sistema se instaló en una docena de objetos bastante grandes y se introdujo. De repente, el cliente decidió pedirle que le diera el código fuente. Al final resultó que, su contratista existente tenía planes para que desarrollen software y luego vendan el resultado como SaaS en el mercado. El contrato no dice nada sobre el código. Tuvimos una pelea.
Cuando nos llamaron para entender, había alrededor de 10 versiones de software diferentes (versiones de 0.9 a 2.4). Hay 1.5 fuentes, esta versión se recopiló una vez de ellas. Sin documentación Y el sistema necesita ser desarrollado y desarrollado. Contaron "reescribir todo de nuevo" y "finalizar 1.5" y se decidieron por el segundo: TtM de tres a cuatro meses contra el año. Nos enseñaron cómo recopilar especialistas de soporte, corrigieron las fuentes, redujeron las bases de código, construyeron la infraestructura, organizaron un "embotellado", donde se recibe, recolecta y distribuye la fuente. Nos costó a nosotros y al cliente muchas hemorroides.
Entra, te mostraré algo más sobre cómo puedes cometer un error con el proceso de desarrollo y las consecuencias interesantes que esto conlleva.
Otro ejemplo
El cliente, también una gran empresa, lanza los lanzamientos de ERP. Y la broma es que el sistema es tan saludable que no hay ningún lugar para probarlo en una base completa o algo similar. Simplemente no hay infraestructura. Más precisamente, la hay, pero es imposible hacer una prueba de carga, solo se comprueban las cosas locales pequeñas. La liberación aumenta, y nadie sabe cómo se comportará en la práctica. Una vez, todo cayó notablemente, así que cuando el lanzamiento no se comportó como quería. Al final, nos invitaron a ver lo que se puede hacer. Hablamos de que quieren ver el Centro de rendimiento de HP, hicieron un piloto, luego lo integraron, capacitaron y entregaron. Ahora libera a través de él. Estas operaciones normalizadas se prueban, un resumen de las operaciones SLA.
O bien, el cliente estatal ha venido a sustituir la importación. Los negocios se nos acercan y nos dicen: nuestros especialistas en TI nos dijeron que es muy difícil reemplazar la base de Oracle con Postgress. No les creemos, consultar. Dos semanas de procedimientos, y el resultado: “Bueno, sí, cambiar la base es fácil. En ese momento, debe reescribir todo el nivel de la aplicación. Un poquito Aproximadamente el 90%. Tiene paquetes enormes, necesita transferir la capa de lógica de negocios y venga. Los desarrolladores que escribieron el núcleo ya no se pueden encontrar, porque el sistema tiene ocho años ". Creyeron en el equipo de TI. Resultó que simplemente discutían con insuficiente claridad.
Buscamos un lugar seguro,
aquí hay un ejemplo épico . Afortunadamente, este sigue siendo simple, simplemente nadie ha hecho nada durante cinco años, y el negocio no es de escala federal.
El siguiente ejemplo. Ponemos la misma historia con la aceptación de lanzamientos. Situación ideal: un contratista externo escribe el código, lo pasa a prueba, pasa las pruebas, lo pone todo en el repositorio y, desde allí, lo recoge y distribuye. ¿Es hermoso? Agradable Hemos estado viviendo dentro de nuestra empresa durante tres años sin excepción (antes de eso, no había todos los departamentos y equipos). Pero el cliente tiene un "fondo de algoritmos y programas". Allí, cada artista envía un espacio en blanco o una lista del código fuente. Ellos arden allí. Como resultó durante la auditoría, el anime se grabó en un disco en general. E incluso si hay un código de facto en el fondo, entonces no tiene sentido.
Otro cliente similar. Tienen un dolor típico: muchos contratistas. Crearon un integrador dentro de la industria, verifican que el contratista traiga el software correcto. Hubo problemas en el hecho de que existen derechos de terceros (bibliotecas de código abierto con licencias virales abiertas, por ejemplo): los contratistas sin escrúpulos pueden entregar todo esto sin licenciar en orden. En el caso del código abierto, aún puede hacer frente al problema, pero a veces aparecen bibliotecas comerciales. Culpable de quién será, adivina tres veces. Luego, uno de sus contratistas se declaró en quiebra y el cliente vivió con este código. Tales situaciones deben ser atrapadas en una etapa temprana. Ayudamos a configurar el proceso correctamente. Tenemos una solución como la automatización de un fondo de algoritmos y programas. Documentación técnica, versiones, códigos fuente, contratos y todos los enlaces a licitaciones. Con una vida promedio de CIO de dos a tres años, realmente ayuda al siguiente a resolverlo de inmediato.
También estamos introduciendo ágil en Rusia. No me río del circo ahora. Casi siempre comienza como una historia de moda sobre digitalización empresarial. Lo principal es que todos están tratando de entender cuáles son estas palabras. Pero nadie lo entiende. Los conceptos ordenan, contratan personas extrañas. Dicen las palabras "parece", "hipótesis", las nuevas empresas están invitadas, la aceleración está enlodada, los batidos están borrachos; en general, todo tiene los signos externos de algún tipo de valle. Entonces Agile comienza a aplicarse, pero no despega. Si crea un sistema serio, debe verificarlo durante mucho tiempo. Si no coloca los procesos, entonces los sprints serán largos (un mes o dos), si configura los procesos, debe comenzar con la infraestructura de prueba, los desempaques, hacer el proceso de entrega, los procesos de trabajo entre equipos y dentro de los equipos. Y todo esto generalmente se olvida. Si los procesos de los Viejos Creyentes son del 98%, ese proyecto no se realizará. Al final, luego rastrillamos y corremos. En general, no nos quejamos: pan también. Pero a veces solo quiero explicar de alguna manera, o qué, que TI es primero una infraestructura, y luego TtM rápido. Y no al revés.
¿Qué suele salir mal? Conjunto de ejemplos
Mis colegas y yo hemos reunido aquí un conjunto de problemas pendientes que no son muy objetivos, pero que describen muy bien la situación. Por supuesto, solo vamos a lugares donde es malo y no es necesario extrapolarlo al estado de la industria. Pero aún así, estoy seguro de que aprenderá algo de su empresa. Una pequeña parte En general, todo se describe con las palabras: "ineficiencia del proceso, empleados desmotivados, herramientas deficientes o herramientas mal utilizadas". Bueno, ahora, ejemplos.
1. Penalización por errores en el software aportados por los desarrolladores.Ni siquiera sé cómo describirlo racionalmente. Solo una multa por errores identificados. Vive ahora con este conocimiento. Naturalmente, cualquier lanzamiento (incluso pequeño) se lanza diez veces más lento de lo que podría.
2. Reuniones de mañana a tarde.El desarrollador debe atenderlos. Él está en silencio y asiente con la cabeza hacia el teléfono. Estas son las mismas reuniones cuando se necesita todo el equipo del proyecto en la reunión, más el jefe del departamento para controlar. Es imposible no venir. Pero casi no tiene sentido participar. Este es el error tradicional del gerente del proyecto, llamado "control excesivo".
3. Culto de carga. Tomamos metodologías flexibles y las implementamos rígidamente.Lo mejor que he visto: implementado ágil, pero funcionó como antes. Acaban de hacer que los desarrolladores lleguen al stand-up diario. Están construidos y dicen: no hice nada. Sucede todos los dias.
4. Herramientas: implementamos para informar que implementado."Tenemos un servidor de integración continua, y solo un administrador puede agregar una tarea". "Hemos implementado un repositorio de ensamblaje binario, y hay un disco muy pequeño, necesita eliminar los viejos, y solo hay las últimas tres versiones". O aquí: un sistema de gestión de tareas en un archivo ex en un disco compartido. Por lo tanto, la cartera de pedidos a menudo lidera incluso en grandes empresas, a pesar del hecho de que existe Jira. En este caso, hasta que la tarea caiga en este archivo, nadie lo hará. El es oficial.
Otra empresa tiene una base de conocimiento interna, pero todo se almacena directamente en el sistema de control de versiones: es más conveniente para el gerente. Las distribuciones del sistema operativo incluso se agregan allí. Cuando no hay una persona responsable del sistema de control de versiones, los gerentes pueden colocar archivos de gigabytes para transferirlos a la contraparte, porque en Dropbox el lugar se ha agotado.
5. Normas de codificación: escritas sin entender o no actualizadas durante 10 años.Solo un par de ejemplos: requerimos una cobertura del 100% del código con pruebas y documentación. En particular, todas las bibliotecas de terceros. La desventaja es la falta de pruebas estándar. Recientemente vi cómo un ingeniero implementó el sistema, y el usuario no puede iniciar sesión, porque no se cambió la clave de la prueba al producto.
Una vez más, vi cómo el líder escribió el código en Notepad.exe, luego lo arrojó al compilador sin errores. Seguía estudiando con tarjetas perforadas. Tal habilidad ciertamente merece respeto. Pero solo hasta que esta deformación profesional comience a influir en los estándares para el resto del departamento de desarrollo.
6. Errores de normativa.Por ejemplo, un horario fijo para el almuerzo, que se camina por completo. Este es un síntoma. Pregunto por qué Explican: si estás sentado en el lugar de trabajo a la hora del almuerzo, entonces eres el objetivo. Debe responder a las cartas en cinco minutos y así sucesivamente.
Burocratización excesiva: a menudo, siguiendo procedimientos documentados que conducen a una pila de papeles. Los mismos planes de prueba para cada estornudo. Y esta es una descripción de cada filtro, incluidos los tipos de datos en cada campo de interfaz, la longitud del campo, etc. Esto generalmente se resuelve con ejemplos, y no con todo detalle.
En una empresa no había ninguna persona responsable de la versión actual, a veces se rompieron los plazos para el lanzamiento de productos durante dos semanas.
Comunicaciones: algo viene del cliente por correo. Además, le escribe a quien habló por última vez con él. Incluso si desea hacer esto, los comentarios sobre la tarea pueden estar en diferentes lugares, incluidos los mensajeros instantáneos. Entonces alguien se fue, alguien vino, alguien borró el correo, eso es todo.
7. Luchando contra los guardias de seguridad.Esto incluye actualizaciones manuales de todos los sistemas (y necesita derramarlo automáticamente, esto ahorra mucho tiempo), soluciones físicas con una unidad flash en los nodos de la red, asignación de puertos durante tres semanas, etc.
8. La comunicación entre desarrolladores y analistas no está establecida.Esta es una jamba que se repite en cada quinto proyecto. Es solo que el analista escribió lo que se necesita, el desarrollador lo desarrolló y un mes después lo mostró listo. El analista corre horrorizado porque no quiso decir esto. Durante tres semanas este mes, el desarrollador trabajó en vano, aunque pudo mostrar parte del proyecto, y el analista pudo preguntar cómo van las cosas. Hay metodologías que simplemente cierran esto, pero el problema es que en esta situación ambas partes no entienden por qué se necesita el proyecto y cómo funciona.
9. Desarrollo impulsado por la conferencia.El líder vio algo genial en la conferencia, y lo presentaron sin dejar rastro. Tres meses después repite. Como resultado, el informe es hermoso, pero el trabajo lo vale.
Debido a las conferencias internas, todavía es posible llevar al resultado de acuerdo con el esquema "Siempre 80% listo". En informes públicos: "Casi terminado", y es interminable. Llevar al 100% nunca sucede. Por qué Bueno, por ejemplo, ver el punto 1.
Por separado, tomo nota de la falta de examen de los sistemas de terceros. Usted leyó el artículo: guau, genial, usémoslo y luego aprendamos cómo. Y te encuentras con muchas restricciones, porque el vendedor vertió miel en sus oídos solo en las dos primeras reuniones. Nosotros mismos pisamos un rastrillo. Hubo una implementación interna de un sistema para tiendas en línea de documentación sobre el diseño de infraestructuras, incl. Centros de datos para objetos muy interesantes. Se descubrió un caso de limitar el costo de los bienes de 100 millones. El truco es que en el área temática el precio unitario del documento es más alto. Y allí, el sistema tuvo que palear el índice para buscar, y tenemos inversiones de 1 gigabyte en los documentos. Y el tiempo de indexación esperado es de un mes. El vendedor no advirtió sobre esto.
10. Da miedo hacer cambios.Existe tal estado del proyecto: necesita refactorización, regrese en un mes. Pero no hay pruebas, ni documentos, nada. Y los desarrolladores están sentados: "Tenemos miedo de hacer cambios, tenemos miedo de romper todo".
También vi cómo una compañía desarrolló la integración con un sistema que no se puede implementar del lado del desarrollador, porque es muy difícil. Los probadores prueban la transferencia de datos por parte del servicio (en la medida de lo posible). Salga a los puestos del cliente antes de la entrega, y otras dos semanas de mejoras, porque el modelo de transacción era incorrecto. Es una buena práctica hacer un trozo para este sistema que devuelva algún tipo de respuestas. Como resultado, lo hicieron, se hizo más fácil de probar y aceptar.
Otro cliente puede escribir descripciones económicas en su idioma habitual. En ese proyecto, dimos algún tipo de constructor de pseudo-lenguaje (un conjunto de estándares), que luego se convierte en datos de analista. En el espíritu de "Si Vanya está de baja por enfermedad, no podrá ir a producción".
Y el acorde final. Alguien más en una compañía está codificando directamente en el producto. "Hay un pequeño violín, sé lo que estoy haciendo". Gracias, querido hombre, pero si te encuentro, ni siquiera sé qué hacer contigo.
En general, habló. Si descubre sus problemas, escriba a oeremeev@croc.ru. Para las grandes empresas, tenemos pilotos casi gratuitos con diagnóstico rápido (busca cuellos de botella en 3-5 días). Si alguien de su negocio necesita que le expliquen que es imposible soportar la deuda técnica, escriba también, podemos contar esto normalmente.