Sábese que a competencia do CTO só se pon a proba a segunda vez que desempeña esta función. Porque unha cousa é traballar varios anos nunha empresa, evolucionar con ela e, estando no mesmo contexto cultural, ir cobrando pouco a pouco máis responsabilidade. E outra ben distinta é chegar directamente ao posto de director técnico nunha empresa con equipaxe de legado e unha morea de problemas varridos ordenadamente baixo a alfombra.

Neste sentido, a experiencia de León Fire, que compartiu DevOpsConf, non precisamente único, pero multiplicado pola súa experiencia e a cantidade de diferentes papeis que conseguiu probar ao longo de 20 anos, é moi útil. Debaixo do corte hai unha cronoloxía de acontecementos ao longo de 90 días e unha morea de historias das que é divertido rirse cando lle suceden a outra persoa, pero que non é tan divertido de afrontar en persoa.

León fala moi colorido en ruso, polo que se tes 35-40 minutos, recoméndoche ver o vídeo. Versión de texto para aforrar tempo a continuación.

A primeira versión do informe foi unha descrición ben estruturada do traballo con persoas e procesos, que contén recomendacións útiles. Pero ela non transmitiu todas as sorpresas que se atoparon no camiño. Por iso, cambiei o formato e presentei os problemas que xurdiron diante de min como un jack-in-the-box na nova empresa, e os métodos para resolvelos por orde cronolóxica.

Un mes antes

Como moitas boas historias, esta comezou co alcol. Estabamos sentados cuns amigos nun bar e, como era de esperar entre os informáticos, todos choraban polos seus problemas. Un deles acababa de cambiar de traballo e falaba dos seus problemas coa tecnoloxía, coa xente e co equipo. Canto máis escoitaba, máis me daba conta de que debería contratarme, porque estes son os tipos de problemas que estiven resolvendo nos últimos 15 anos. Díxenllo, e ao día seguinte xuntámonos nun ambiente de traballo. A empresa chamábase Teaching Strategies.

Teaching Strategies é líder do mercado no currículo para nenos moi pequenos desde o nacemento ata os tres anos de idade. A tradicional empresa "en papel" xa ten 40 anos, e a versión dixital SaaS da plataforma ten 10. Hai relativamente pouco, comezou o proceso de adaptación da tecnoloxía dixital aos estándares da empresa. A versión "nova" lanzouse en 2017 e era case como a antiga, só que funcionou peor.

O máis interesante é que o tráfico desta empresa é moi previsible: de día en día, de ano en ano, podes predecir moi claramente cantas persoas virán e cando. Por exemplo, entre as 13 e as 15 horas todos os nenos dos xardíns de infancia van para a cama e os profesores comezan a introducir información. E isto pasa todos os días, agás os fins de semana, porque case ninguén traballa os fins de semana.

Mirando un pouco cara adiante, notarei que comecei o meu traballo durante o período de maior tráfico anual, o que é interesante por varios motivos.

A plataforma, que parecía ter só 2 anos, tiña unha pila peculiar: ColdFusion e SQL Server de 2008. ColdFusion, se non o sabes, e moi probablemente non o saibas, é un PHP empresarial que xurdiu a mediados dos anos 90, e desde entón nin sequera oín falar del. Tamén estaban: Ruby, MySQL, PostgreSQL, Java, Go, Python. Pero o monolito principal funcionou en ColdFusion e SQL Server.

Problemas

Canto máis falaba cos empregados da empresa sobre o traballo e os problemas que se atopaban, máis me daba conta de que os problemas non eran só de natureza técnica. Está ben, a tecnoloxía é antiga e non traballaron nela, pero houbo problemas co equipo e cos procesos, e a empresa comezou a entender isto.

Tradicionalmente, os seus técnicos sentaban na esquina e facían algún tipo de traballo. Pero cada vez máis empresas comezaron a pasar pola versión dixital. Por iso, no último ano antes de comezar a traballar, apareceron outros novos na empresa: consello de administración, CTO, CPO e director de QA. É dicir, a empresa comezou a investir no sector tecnolóxico.

As pegadas dun legado pesado non estaban só nos sistemas. A empresa tiña procesos legados, persoas legadas, cultura legada. Todo isto houbo que cambialo. Pensei que definitivamente non sería aburrido e decidín probalo.

Dous días antes

Dous días antes de comezar un novo traballo, cheguei á oficina, enchei o último papeleo, coñecín o equipo e descubrín que o equipo estaba loitando cun problema nese momento. Foi que o tempo medio de carga da páxina saltou a 4 segundos, é dicir, 2 veces.

A xulgar polo gráfico, pasou algo claramente e non está claro que. Resultou que o problema era a latencia da rede no centro de datos: a latencia de 5 ms no centro de datos converteuse en 2 s para os usuarios. Non sabía por que ocorreu isto, pero en todo caso soubo que o problema estaba no centro de datos.

Primeiro día

Pasaron dous días e no meu primeiro día de traballo descubrín que o problema non desaparecera.

Durante dous días, as páxinas dos usuarios cargáronse de media en 4 segundos. Pregunto se atoparon cal é o problema.

- Si, abrimos un billete.
- E?
- Pois aínda non nos contestaron.

Entón decateime de que todo o que me falaran antes era só unha pequena punta do iceberg co que tiña que loitar.

Hai unha boa cita que encaixa moi ben con isto:

"Ás veces, para cambiar a tecnoloxía hai que cambiar a organización".

Pero dende que comecei a traballar na época de máis afluencia do ano, tiven que mirar as dúas opcións para resolver o problema: rápida e a longo prazo. E comeza polo que é crítico agora mesmo.

Terceiro día

Así, a carga dura 4 segundos, e de 13 a 15 os picos máis grandes.

O terceiro día durante este período de tempo, a velocidade de descarga era o seguinte:

Desde o meu punto de vista, nada funcionou. Desde o punto de vista dos demais, foi un pouco máis lento do habitual. Pero simplemente non ocorre así, é un problema grave.

Tentei convencer ao equipo, ao que responderon que simplemente necesitaban máis servidores. Esta, por suposto, é unha solución ao problema, pero non sempre é a única e máis eficaz. Pregunteille por que non había servidores suficientes, cal era o volume de tráfico. Extrapolei os datos e comprobei que temos aproximadamente 150 solicitudes por segundo, o que, en principio, está dentro de límites razoables.

Pero non debemos esquecer que antes de obter a resposta correcta, cómpre facer a pregunta correcta. A miña seguinte pregunta foi: cantos servidores frontend temos? A resposta "desconcertame un pouco": tiñamos 17 servidores frontend!

— Dáme vergoña preguntar, pero 150 dividido por 17 dá uns 8? Estás a dicir que cada servidor permite 8 solicitudes por segundo, e se mañá hai 160 solicitudes por segundo, necesitaremos 2 servidores máis?

Por suposto, non necesitamos servidores adicionais. A solución estaba no propio código e na superficie:

var currentClass = classes.getCurrentClass();
return currentClass;

Houbo unha función getCurrentClass(), porque todo no sitio funciona no contexto dunha clase, é certo. E para esta unha función en cada páxina había Máis de 200 solicitudes.

A solución deste xeito era moi sinxela, nin sequera tiñas que reescribir nada: simplemente non volvas pedir a mesma información.

if ( !isDefined("REQUEST.currentClass") ) {
    var classes = new api.private.classes.base();
   REQUEST.currentClass = classes.getCurrentClass();
}
return REQUEST.currentClass;

Estaba moi contento porque decidín que só o terceiro día atopara o principal problema. Como era inxenuo, este era só un dos moitos problemas.

Pero ao resolver este primeiro problema, o gráfico baixou moito.

Ao mesmo tempo, estabamos facendo outras optimizacións. Había moitas cousas á vista que se podían arranxar. Por exemplo, o mesmo terceiro día descubrín que despois de todo había unha caché no sistema (ao principio pensei que todas as solicitudes proviñan directamente da base de datos). Cando penso nunha caché, penso en Redis ou Memcached estándar. Pero eu era o único que pensaba así, porque ese sistema utilizaba MongoDB e SQL Server para almacenar na caché, o mesmo do que se acababan de ler os datos.

Día décimo

A primeira semana tratei problemas que había que resolver agora mesmo. Na segunda semana, vin ao stand-up por primeira vez para comunicarme co equipo, para ver que pasaba e como ía todo o proceso.

Volveuse a descubrir algo interesante. O equipo estaba composto por: 18 desenvolvedores; 8 probadores; 3 xestores; 2 arquitectos. E todos participaban de rituais comúns, é dicir, máis de 30 persoas acudían cada mañá ao stand-up e contaban o que facían. Está claro que a reunión non levou 5 nin 15 minutos. Ninguén escoitou a ninguén porque todos traballan en sistemas diferentes. Nesta forma, 2-3 entradas por hora para unha sesión de aseo xa foi un bo resultado.

O primeiro que fixemos foi dividir o equipo en varias liñas de produtos. Para diferentes seccións e sistemas, asignamos equipos separados, que incluían desenvolvedores, probadores, xestores de produtos e analistas empresariais.

Como resultado obtivemos:

• Redución de stand-ups e concentracións.
• Coñecemento da materia do produto.
• Un sentimento de propiedade. Cando a xente adoitaba xogar cos sistemas todo o tempo, sabían que outra persoa probablemente tería que traballar cos seus erros, pero non eles mesmos.
• Colaboración entre grupos. Nin que dicir ten que QA non se comunicaba moito cos programadores antes, o produto facía as súas propias cousas, etc. Agora teñen un punto de responsabilidade común.

Centrámonos principalmente na eficiencia, produtividade e calidade: estes son os problemas que tentamos resolver coa transformación do equipo.

Día once

No proceso de cambiar a estrutura do equipo, descubrín como contar HistoriaPuntos. 1 SP equivalía a un día, e cada ticket contiña SP tanto para o desenvolvemento como para o QA, é dicir, polo menos 2 SP.

Como descubrín isto?

Atopamos un erro: nun dos informes, onde se introduce a data de inicio e finalización do período para o que se precisa o informe, non se ten en conta o último día. É dicir, nalgún lugar da solicitude non había <=, senón simplemente <. Dixéronme que se trata de tres Story Points, é dicir 3 do día.

Despois disto:

• O sistema de valoración de Story Points foi revisado. Agora as correccións de erros menores que se poden pasar rapidamente polo sistema chegan ao usuario máis rápido.
• Comezamos a fusionar tickets relacionados para o desenvolvemento e as probas. Antes, cada ticket, cada erro era un ecosistema pechado, non ligado a outra cousa. Cambiar tres botóns nunha páxina poderían ser tres tickets diferentes con tres procesos de control de calidade diferentes en lugar dunha proba automatizada por páxina.
• Comezamos a traballar cos desenvolvedores nun enfoque para estimar os custos laborais. Tres días para cambiar un botón non é divertido.

Día vixésimo

Nalgún lugar a mediados do primeiro mes, a situación estabilizouse un pouco, descubrín o que estaba a suceder basicamente e xa comecei a mirar cara ao futuro e pensar en solucións a longo prazo.

Obxectivos a longo prazo:

• Plataforma xestionada. Centos de solicitudes en cada páxina non son serias.
• Tendencias previsibles. Houbo picos de tráfico periódicos que a primeira vista non se correlacionaban con outras métricas; necesitabamos entender por que ocorreu isto e aprender a predicir.
• Ampliación da plataforma. O negocio está en constante crecemento, cada vez chegan máis usuarios e o tráfico aumenta.

No pasado dicíase moitas veces: "Reescribamos todo en [idioma/marco], todo funcionará mellor!"

Na maioría dos casos isto non funciona, é bo que a reescritura funcione. Polo tanto, necesitabamos crear unha folla de ruta: unha estratexia específica que ilustrase paso a paso como se conseguirán os obxectivos empresariais (que faremos e por que), que:

• reflicte a misión e os obxectivos do proxecto;
• prioriza os obxectivos principais;
• contén un calendario para a súa consecución.

Antes diso, ninguén falara co equipo sobre o propósito dos cambios que se fixeran. Isto require as métricas de éxito correctas. Por primeira vez na historia da empresa, establecemos KPI para o grupo técnico, e estes indicadores estaban ligados aos organizativos.

É dicir, os KPI organizativos son compatibles con equipos e os KPI de equipos son compatibles con KPI individuais. En caso contrario, se os KPI tecnolóxicos non coinciden cos organizativos, entón todos tiran a manta sobre si mesmos.

Por exemplo, un dos KPI da organización está a aumentar a cota de mercado a través de novos produtos.

Como podes apoiar o obxectivo de ter máis produtos novos?

• En primeiro lugar, queremos dedicar máis tempo a desenvolver novos produtos en lugar de solucionar os defectos. Esta é unha solución lóxica que é fácil de medir.
• En segundo lugar, queremos apoiar un aumento do volume de transaccións, porque canto maior sexa a cota de mercado, máis usuarios e, en consecuencia, máis tráfico.

Entón, os KPI individuais que se poden executar dentro do grupo estarán, por exemplo, no lugar de onde proveñen os principais defectos. Se te centras especificamente nesta sección, podes asegurarte de que haxa moitos menos defectos e, a continuación, aumentará o tempo para desenvolver novos produtos e, de novo, para apoiar os KPI organizativos.

Así, cada decisión, incluída a reescritura do código, debe apoiar os obxectivos específicos que nos marcou a empresa (crecemento organizativo, novas funcións, contratación).

Durante este proceso, saíu á luz unha cousa interesante, que se converteu en noticia non só para os técnicos, senón en xeral na empresa: todas as entradas deben estar enfocadas polo menos a un KPI. É dicir, se un produto di que quere facer unha nova función, debería facerse a primeira pregunta: "Que KPI admite esta función?" Se non, desculpe, parece unha función innecesaria.

Día trinta

A finais de mes, descubrín outro matiz: ninguén do meu equipo de Operacións viu nunca os contratos que celebramos cos clientes. Podes preguntar por que necesitas ver os contactos.

• En primeiro lugar, porque os SLA están especificados nos contratos.
• En segundo lugar, os SLA son todos diferentes. Cada cliente chegou cos seus propios requisitos, e o departamento de vendas asinaba sen mirar.

Outro matiz interesante é que o contrato cun dos maiores clientes establece que todas as versións de software admitidas pola plataforma deben ser n-1, é dicir, non a última versión, senón a penúltima.

Está claro o lonxe que estabamos de n-1 se a plataforma estaba baseada en ColdFusion e SQL Server 2008, que xa non era compatible en xullo.

Día corenta e cinco

A mediados do segundo mes tiven tempo suficiente para sentarme e facer valorcadeamapeamento completamente para todo o proceso. Estes son os pasos necesarios que hai que dar, desde a creación dun produto ata a entrega ao consumidor, e deben ser descritos co máximo de detalle posible.

Rompes o proceso en pequenos anacos e ves o que está levando demasiado tempo, o que se pode optimizar, mellorar, etc. Por exemplo, canto tempo leva unha solicitude de produto en pasar pola preparación, cando chega a un ticket que pode levar un programador, control de calidade, etc. Así que miras cada paso individualmente en detalle e pensas no que se pode optimizar.

Cando fixen isto, chamáronme a atención dúas cousas:

• alta porcentaxe de boletos devoltos do control de calidade aos desenvolvedores;
• As revisións das solicitudes de extracción tardaron demasiado.

O problema foi que se trataba de conclusións como: Parece que leva moito tempo, pero non sabemos canto tempo.

"Non se pode mellorar o que non se pode medir".

Como xustificar a gravidade do problema? Perde días ou horas?

Para medir isto, engadimos un par de pasos ao proceso Jira: "listo para o desenvolvemento" e "listo para o control de calidade" para medir canto tempo espera cada ticket e cantas veces volve a un determinado paso.

Tamén engadimos "en revisión" para saber cantas entradas hai de media para revisar, e a partir deste podes comezar a bailar. Tiñamos métricas do sistema, agora engadimos novas métricas e comezamos a medir:

• Eficiencia do proceso: rendemento e planificado/entregado.
• Calidade do proceso: número de defectos, defectos de QA.

Axuda moito a entender o que vai ben e o que non.

Día cincuenta

Todo isto, por suposto, é bo e interesante, pero a finais do segundo mes pasou algo que, en principio, era previsible, aínda que non esperaba tal escala. A xente comezou a marchar porque a alta dirección cambiara. A xente nova entrou na dirección e comezou a cambialo todo, e os vellos abandonaron. E normalmente nunha empresa que ten varios anos, todos son amigos e todos se coñecen.

Isto era de esperar, pero a magnitude dos despedimentos foi inesperada. Por exemplo, nunha semana dous líderes de equipos presentaron simultáneamente as súas renuncias por vontade propia. Polo tanto, tiven que non só esquecerme doutros problemas, senón centrarme creando un equipo. Este é un problema longo e difícil de resolver, pero houbo que abordalo porque quería salvar á xente que quedaba (ou á maioría delas). Había que reaccionar dalgún xeito ante o feito de que a xente marchara para manter a moral no equipo.

En teoría, isto é bo: entra unha nova persoa que ten carta branca completa, que pode avaliar as habilidades do equipo e substituír o persoal. De feito, non podes traer xente nova por tantas razóns. O equilibrio é sempre necesario.

• Vello e novo. Necesitamos manter a xente maior que poida cambiar e apoiar a misión. Pero ao mesmo tempo, necesitamos traer sangue novo, diso falaremos un pouco máis tarde.
• Experiencia. Falei moito con bos xuvenís que tiñan ganas e querían traballar connosco. Pero non puiden asumilos porque non había suficientes maiores para apoiar aos xuvenís e actuar como mentores para eles. Primeiro houbo que reclutar á cúpula e só despois á xuventude.
• Cenoria e pau.

Non teño unha boa resposta á pregunta de cal é o equilibrio correcto, como mantelo, cantas persoas manter e canto empurrar. Este é un proceso puramente individual.

Día cincuenta e un

Comecei a mirar ben ao equipo para entender quen tiña, e unha vez máis recordei:

"A maioría dos problemas son problemas das persoas".

Descubrín que o equipo como tal, tanto Dev como Ops, ten tres grandes problemas:

• Satisfacción coa situación actual.
• Falta de responsabilidade - porque ninguén trouxo nunca os resultados do traballo dos intérpretes para influír no negocio.
• Medo ao cambio.

O cambio sempre te saca da túa zona de confort, e cantos máis novos son, máis non lles gusta o cambio porque non entenden por que e non entenden como. A resposta máis común que escoitei é: "Nunca fixemos iso". Ademais, chegou ao punto do absoluto absurdo: os máis mínimos cambios non podían producirse sen que alguén se indignase. E por moito que os cambios afectasen ao seu traballo, a xente dicía: “Non, por que? Isto non funcionará".

Pero non podes mellorar sen cambiar nada.

Tiven unha conversación absolutamente absurda cun empregado, díxenlle as miñas ideas para a optimización, ao que me dixo:
- Ai, non viches o que tiñamos o ano pasado!
- E que?
"Agora é moito mellor do que era".
- Entón, non se pode mellorar?
- Para que?

Boa pregunta - por que? É coma se agora fose mellor do que era, entón todo é o suficientemente bo. Isto leva a unha falta de responsabilidade, o que é absolutamente normal en principio. Como dixen, o grupo técnico estivo un pouco á marxe. A empresa cría que deberían existir, pero ninguén estableceu nunca as normas. O soporte técnico nunca viu o SLA, polo que foi bastante "aceptable" para o grupo (e isto me chamou máis a atención):

• 12 segundos de carga;
• 5-10 minutos de inactividade cada versión;
• A resolución de problemas críticos leva días e semanas;
• falta de persoal de servizo 24x7 / de garda.

Ninguén intentou preguntar por que non o facemos mellor, e ninguén se decatou de que non ten por que ser así.

Como extra, houbo un problema máis: falta de experiencia. Os maiores marcharon, e o equipo xuvenil restante medrou baixo o réxime anterior e foi envelenado por el.

Ademais de todo isto, a xente tamén tiña medo de fracasar e de parecer incompetente. Isto exprésase no feito de que, en primeiro lugar, eles en ningún caso pediu axuda. Cantas veces falamos en grupo e individualmente, e dixen: "Fai unha pregunta se non sabes como facer algo". Confío en min mesmo e sei que podo resolver calquera problema, pero levará tempo. Polo tanto, se lle podo preguntar a alguén que saiba como resolvelo en 10 minutos, preguntareino. Canta menos experiencia teñas, máis medo tes a preguntar porque pensas que serás considerado incompetente.

Este medo a facer preguntas maniféstase de xeitos interesantes. Por exemplo, pregunta: "Como estás con esta tarefa?" - "Quedan un par de horas, xa estou rematando". Ao día seguinte pregunta de novo, recibe a resposta de que todo está ben, pero houbo un problema, definitivamente estará listo ao final do día. Pasa outro día e ata que te pegan á parede e te obrigan a falar con alguén, isto continúa. Unha persoa quere resolver un problema por si mesma; cre que se non o resolve el mesmo, será un gran fracaso.

É por iso os desenvolvedores inflaron as estimacións. Era esa mesma anécdota, cando falaban dunha determinada tarefa, déronme tal figura que me sorprendeu moito. Ao que me dixeron que nas estimacións do desenvolvedor, o desenvolvedor inclúe o tempo en que se devolverá o ticket de QA, porque alí atoparán erros, e o tempo que tardará o PR e o tempo que debe revisar a xente. estará ocupado, é dicir, todo, o que sexa posible.

En segundo lugar, as persoas que teñen medo de parecer incompetentes sobreanalizar. Cando dis o que hai que facer exactamente, comeza: "Non, e se o pensamos aquí?" Neste sentido, a nosa empresa non é única, é un problema habitual para os mozos.

Como resposta, introducín as seguintes prácticas:

• Regra 30 minutos. Se non podes resolver o problema en media hora, pídelle a alguén que te axude. Isto funciona con distintos graos de éxito, porque a xente aínda non pregunta, pero polo menos comezou o proceso.
• Elimina todo menos a esencia, ao estimar o prazo para completar unha tarefa, é dicir, considerar só o tempo que tardará en escribir o código.
• Aprendizaxe ao longo da vida para os que sobreanalizan. É só un traballo constante coa xente.

Día sesenta

Mentres facía todo isto, era hora de descubrir o orzamento. Por suposto, atopei moitas cousas interesantes onde gastamos o noso diñeiro. Por exemplo, tiñamos un rack completo nun centro de datos separado cun servidor FTP, que era usado por un cliente. Resultou que "... mudámonos, pero el quedou así, non o cambiamos". Foi hai 2 anos.

De especial interese foi a factura dos servizos na nube. Creo que a principal razón da alta factura da nube son os desenvolvedores que teñen acceso ilimitado aos servidores por primeira vez na súa vida. Non precisan preguntar: "Por favor, dáme un servidor de proba", poden aceptalo eles mesmos. Ademais, os desenvolvedores sempre queren construír un sistema tan xenial que Facebook e Netflix estarán celosos.

Pero os desenvolvedores non teñen experiencia na compra de servidores nin a habilidade para determinar o tamaño necesario dos servidores, porque antes non o necesitaban. E normalmente non entenden moi ben a diferenza entre escalabilidade e rendemento.

Resultados do inventario:

• Saímos do mesmo centro de datos.
• Rescindimos o contrato con 3 servizos de rexistro. Porque tiñamos 5 deles: cada programador que comezou a xogar con algo tomou un novo.
• 7 sistemas AWS foron pechados. De novo, ninguén detivo os proxectos mortos; todos seguiron traballando.
• Custos de software reducidos en 6 veces.

Día setenta e cinco

Pasou o tempo, e en dous meses e medio tiven que reunirme coa xunta directiva. O noso consello de administración non é mellor nin peor que outros; como todos os consellos de administración, quere saber todo. A xente inviste diñeiro e quere entender o que facemos encaixa nos KPI establecidos.

O consello de administración recibe mensualmente moita información: o número de usuarios, o seu crecemento, que servizos utilizan e como, rendemento e produtividade e, por último, a velocidade media de carga da páxina.

O único problema é que creo que a media é pura maldade. Pero é moi difícil explicar isto á xunta directiva. Están afeitos a operar con números agregados, e non, por exemplo, a propagación dos tempos de carga por segundo.

Houbo algúns puntos interesantes neste sentido. Por exemplo, dixen que necesitamos dividir o tráfico entre servidores web separados dependendo do tipo de contido.

É dicir, ColdFusion pasa por Jetty e nginx e lanza as páxinas. E as imaxes, JS e CSS pasan por un nginx separado coas súas propias configuracións. Esta é unha práctica bastante estándar da que estou falando escribiu hai un par de anos. Como resultado, as imaxes cárganse moito máis rápido e... a velocidade media de carga aumentou en 200 ms.

Isto ocorreu porque o gráfico está construído a partir dos datos que se inclúen con Jetty. É dicir, o contido rápido non está incluído no cálculo: o valor medio saltou. Isto quedou claro para nós, rimos, pero como explicarlle ao consello de administración por que fixemos algo e a cousa empeoraba nun 12%?

Día oitenta e cinco

Ao final do terceiro mes, decateime de que había unha cousa coa que non contara nada: o tempo. Todo o que falei leva tempo.

Este é o meu calendario semanal real: só unha semana laboral, non moi ocupada. Non hai tempo suficiente para todo. Polo tanto, de novo, cómpre contratar persoas que che axuden a afrontar os problemas.

Conclusión

Iso non é todo. Nesta historia, nin sequera cheguei a como traballamos co produto e tentamos sintonizar coa onda xeral, ou como integramos o soporte técnico ou como resolvemos outros problemas técnicos. Por exemplo, aprendín por casualidade que nas táboas máis grandes da base de datos non usamos SEQUENCE. Temos unha función autoescrita nextID, e non se usa nunha transacción.

Había un millón de cousas similares máis das que puidemos falar durante moito tempo. Pero o máis importante que aínda hai que dicir é a cultura.

É a cultura ou a súa falta a que leva a todos os demais problemas. Estamos tentando construír unha cultura onde a xente:

• non teñen medo aos fracasos;
• aprender dos erros;
• colaborar con outros equipos;
• tomar iniciativa;
• asumir a responsabilidade;
• acoller o resultado como un gol;
• celebrando o éxito.

Con isto chegará todo o demais.

León Lume en twitter, Facebook e medio.

Hai dúas estratexias respecto ao legado: evitar traballar con el a toda costa ou superar con valentía as dificultades asociadas. Nós c DevOpsConf Tomamos o segundo camiño, cambiando procesos e enfoques. Acompáñanos youtube, Lista de correo и telegrama, e xuntos implementaremos unha cultura DevOps.

Fonte: www.habr.com