Moitas persoas pensan nos problemas que lles preocupan antes de deitarse ou ao espertar. Non son unha excepción. Esta mañá apareceume un na cabeza de Habr:
Un compañeiro compartiu unha historia nun chat:
O ano anterior tiven un cliente fantástico, isto estaba de volta cando estaba lidando cunha pura "crise".
O cliente ten dous equipos no grupo de desenvolvemento, cada un que se ocupa da súa propia parte do produto (condicionalmente, o back office e o front office, é dicir, software que traballa na formación de pedidos e software que traballa na execución de pedidos), integrándose ocasionalmente entre si.
O equipo de back office foi completamente costa abaixo: seis meses de problemas continuos, os donos ameazan con despedir a todos, contrataron un consultor, despois do consultor contratáronnos máis que outro (a min). Ademais, o segundo equipo (storfront) traballou con normalidade e seguiu traballando con normalidade, foi o equipo de back-office, que tamén traballara con normalidade antes, o que comezou a estropear. Os equipos sentan en diferentes oficinas e están afeitos a cabrearse uns aos outros.Motivo: tenda e volta son un só sistema, hai moitas dependencias nel, os equipos das distintas oficinas non se comunicaban entre si. Os propietarios "miran" a parte frontal todo o tempo, polo que teñen novas funcións, ideas e control alí. Era un neno de todos os oficios, unha combinación de BA, deseñador e "tráenos café". Este rapaz, desapercibido para o seu equipo, estaba a realizar un montón de pequenas tarefas como “avisar ao segundo equipo sobre o despregamento”, “actualizar a documentación”, etc. rutina, ata "introducir todo tipo de números de versión e compoñentes no ticket". Pero o neno non escribiu ningún código, e nun momento dado os donos decidiron optimizalo e despedilo. Para o equipo da tenda, nada cambiou, simplemente non fixeron nin actualizaron os peiraos, e o equipo de backoffice atopouse nunha situación na que os lanzamentos da tenda rompen algo para eles, e ese é o seu problema, e se os seus lanzamentos rompen algo para eles. a tenda, ese son de novo os seus problemas, porque a tenda está á vista dos propietarios :)
O que me chamou a atención con este comentario e o que o buscador atopará no título, baixo o corte.
Levo 20 anos desenvolvendo aplicacións web, polo que fronte/traseira non son só palabras para min. Son cousas moi relacionadas. Por exemplo, non podo imaxinar unha situación na que a fronte se desenvolva nun illamento completo (ou moi forte) da parte traseira. Ambos os dous lados operan cos mesmos datos e realizan operacións moi similares. Podo imaxinar aproximadamente canta información se move entre os desenvolvedores de ambos os equipos para coordinar o desenvolvemento, e canto tempo e cantas veces hai que facer estas aprobacións. Os equipos non poden evitar comunicarse estreitamente, aínda que estean en zonas horarias diferentes. Especialmente se tes JIRA.
Sei que non ten sentido advertir aos desenvolvedores posteriores sobre o despregamento da fronte. A nova versión da fronte non pode romper nada na parte traseira, pero pola contra, si. Son os desenvolvedores front-end os que están interesados en notificarlles aos desenvolvedores back-end que necesitan funcionalidades novas ou modificadas. A fronte depende dos despregamentos traseiros, e non viceversa.
que rapaz quen"tráenos café", non pode haber un BA (se por BA queremos dicir "analista de negocios"), e un BA non pode ser "rapaz, tráenos café". E certamente, "engadir todo tipo de números de versión e compoñentes"Nin o "neno" nin o BA poden facelo sen discutir cos equipos de desenvolvemento. É como o carro antes que o cabalo.
Dende que o "neno" foi despedido, entón estas funcións, desde "traer café"e antes"poñer en graxa", debería ter sido redistribuído entre outros membros do equipo. Nun grupo establecido, os fluxos de información e os roles están fixados; se o intérprete dun ou varios papeis abandonou o escenario, entón o resto dos membros do grupo aínda teñen a necesidade de recibir familiares. información de roles coñecidos. Simplemente non poden evitar notar que a información necesaria para o traballo deixou de chegar a eles. É como se un drogadicto non puidese evitar notar o feito de que a subministración de drogas cesou. E así como un drogadicto busca e atopa outras canles, polo que os membros do grupo tratarán de buscar fontes da información que necesitan no "outro" lado e novos intérpretes de antigos papeis. E definitivamente atoparán, polo menos, alguén que, na súa opinión, debería dar lles a información necesaria.
Aínda que asumimos que se pecharon as canles habituais de información e quen debería, non pensa que debería, entón os desenvolvedores posteriores, baixo ameaza de despedimento, non ocultarán ao propietario as razóns dos seus propios fallos. seis meses, sabendo que os seus problemas se deben á falta da información necesaria. Os propietarios non serán "parvos" durante seis meses, xa que antes necesitaban a información".estaba cuberto de graxa", e agora ninguén o engade alí. E o primeiro consultor non foi tan pouco profesional como para non falar cos desenvolvedores back-end e non chegar á orixe do problema: a falta de coordinación entre os equipos. Este é o motivo dos problemas descritos, e non o despedimento do "neno".
Unha banal falta de comunicación entre desenvolvedores é unha causa típica de moitos problemas no desenvolvemento e moito máis. Non necesitas ser un gran consultor para atopalo. Basta con ser razoable.
Creo que toda esta historia está ben pensada e ben contada. Ben, non está totalmente inventado: todos os elementos son tomados da vida (diante, traseiro, desenvolvemento, neno, café, "graxa", ...). Pero están conectados de tal xeito que tal deseño non ocorre na vida. Por separado, todo isto pódese atopar no mundo que nos rodea, pero en tal combinación, non. Escribín arriba por que .
Non obstante, preséntase de forma moi plausible. Léase con interese e hai implicación persoal. Simpatía por "rapaz práctico", o pequeno mecanismo pouco apreciado da gran máquina (trátase de min!). Condescendencia cara aos desenvolvedores que son tan intelixentes e experimentados, pero que non poden ver máis aló dos seus propios narices (están ao meu redor!). Unha lixeira burla dos propietarios, os mozos ricos que se fixeron "bo-bo" coas súas propias mans e non entenden as razóns (Ben, a imaxe cuspida do meu liderado!). Desdén ao primeiro "consultor" que non atopou unha fonte de problemas tan sinxela (si, recentemente este tipo entrou con lentes e andou con aspecto intelixente), e unha unión entusiasta cun consultor "de verdade", que era o único que podía apreciar o verdadeiro papel dun rapaz de todo tipo (é dicir, eu!).
Sentes satisfacción interior despois de ler este comentario? O noso papel como pequenos engranajes nun gran mecanismo en realidade non é tan pequeno! Maravillosamente afirmado, aínda que non sexa verdade. Pero que regusto máis agradable.
Non sei que tipo de colega e en que charla compartín esta revelación co meu compañeiro e por que colega mkrentovskiy Decidín publicalo baixo o artigo ""Excelente autor-habr 'a (que, por certo, está neste momento no primeiro posto da clasificación de Habr!), pero recoñezo que o meu compañeiro mkrentovskiy fíxoo moi ben. A mensaxe do comentario e o estilo de presentación son tan coherentes coa mensaxe e o estilo doutras publicacións nmivan'ben, que pode pensar que un consultor de crise do comentario e GG de moitas publicacións nmivan'a é a mesma persoa.
Lin bastantes publicacións de Ivan Belokamentsev cando o autor comezou as súas actividades sobre Habré (en 2017). Algúns incluso disfrutan (, ). Ten un bo estilo e unha presentación interesante do material. As súas historias son moi similares ás historias da vida real, pero case non teñen posibilidades de que sucedan realmente . Así é con esta historia no comentario.
A verdade, persoalmente non creo que Habr mellorou coas publicacións de Ivan. Pero a súa valoración e outros habitantes de Habr din o contrario:
Non entendo o teu lamento. Habr esvareu hai tempo, pero o autor dá un chisco e mellora o estado de ánimo dos lectores) sacando o recurso do abismo.
Si, Habr non é unha organización benéfica, Habr é un proxecto comercial. Habr é un espello que reflicte os nosos desexos. Non os meus desexos persoais nin os desexos de cada visitante individual, senón a totalidade de todos os nosos desexos: a "media para o hospital". E Ivan Belokamentsev sente mellor que ninguén o que todos necesitamos colectivamente, e dánolo.
Quizais non tería escrito este artigo se non comezara a ver a serie"".
"Perdemos a Deus" (Con)
Isto é da serie. E isto é sobre nós.
Xa non nos cativa a realidade creada polo Creador.
Deus, a Natureza, o Big Bang - o que sexa. A realidade está aí. Ao noso redor e independentemente de nós.
Vivimos nel de acordo coas leis da natureza (Plan de Deus). Aprendemos as leis (Plan) e aprendemos a utilizar a realidade na que vivimos para vivir aínda mellor. Comprobaremos con práctica as nosas adiviñas, descartando as incorrectas e deixando as pertinentes. Interactuamos coa realidade e cambiámola.
E tivemos moito éxito nisto.
Hai moita xente no planeta. Moitos. Coa produtividade laboral actual, xa non necesitamos sobrevivir: a minoría pode proporcionar á maioría todo o que precisa. A maioría da xente necesita manterse ocupada con algo. Historicamente, o exceso de recursos destinados á creatividade foi para os máis talentosos (ou os máis disruptivos, que tamén é talento). Agora hai tantos recursos gratuítos que todo o mundo con calquera talento pode obtelo, independentemente do seu nivel. Compara cantas películas se estrean ao ano en todo o mundo e cantas delas podes ver. Cantos libros se escriben e cales deles se poden ler. Canta información se vierte en Internet e cal é utilizable.
Por que é tan popular a profesión de TI? Si, porque podes verter un abismo de recursos na informática e ninguén vai pestanexar un ollo (só lembrar o problema do ano 2000). Despois de todo, en TI podes pasar anos desenvolvendo aplicacións que quedarán obsoletas incluso antes de que sexan lanzadas, podes tentar integrar compoñentes incompatibles e aínda así facelos funcionar, podes reinventar as túas propias rodas unha e outra vez, ou podes agora mesmo. comezar a apoiar programas en Fortran, que estivo cuberto de musgo hai outros 20 anos. Podes pasar toda a vida en informática e non facer nada útil. E o máis importante, ninguén o notará! Mesmo ti mesmo.
Poucos de nós poderemos deixar marca no sector das TIC. E aínda menos persoas poderán deixar atrás un bo recordo. Os resultados do noso traballo depreciaranse nos próximos 10-20 anos, no mellor dos casos, ou incluso antes. E por suposto na nosa vida (se chegamos á idade de xubilación). Non poderemos mostrar aos nosos netos os sistemas informáticos nos que traballaba o seu avó na súa mocidade. A xente simplemente esquecerá os seus nomes. Ao comezo da miña carreira levantei estacións postais baixo "". Estou a 20 anos da xubilación e a 10 de ter netos, pero a maioría de vós xa non escoitaches nada sobre a "excelente aplicación de correo electrónico de mediados dos 90" ("paquete de software de correo electrónico principal de mediados da década de 1990").
Quizais en realidade sexamos pouco conscientes da inutilidade da nosa carga informática, pero no subconsciente esforzámonos por escapar a onde nos sentimos cómodos. A mundos ficticios onde o uso de Scrum e Agile leva inevitablemente á aparición de produtos que conquistan o mundo coa súa utilidade durante décadas. Onde non somos simples engrenaxes pequenas de grandes mecanismos, senón engrenaxes sen as que rompen grandes mecanismos. Onde a nosa vida non se desenvolve na execución sen sentido de accións rutineiras, senón que está chea de creatividade e creación, dos que podemos estar orgullosos dos resultados.
Escapamos a estes mundos fermosos e ficticios da nosa propia inutilidade no mundo real. Nós buscamos consolo para eles.
Buscamos consolo, incluso en Habré. E Iván dánosllo aquí.
Fonte: www.habr.com