Maneiras de aprender

Maneiras de aprender

Durante toda a vida aprendemos cousas, que poden ser máis ou menos útiles, pero gran parte desas cousas non as cremos totalmente ata que as poñemos en práctica. Ou sufrimos as consecuencias de non aplicar o aprendido.

A historia que vou contar vai de materias inútiles, inexperiencia e sobre todo dificultade para dicir non.

Unha das materias que calquera enxeñeiro informático estuda ao longo da carreira é Enxeñería do Software. Ao longo da materia explícase o que é o software, os procesos de enxeñería para elaborar un software, as metodoloxías para o desenvolvemento, a documentación necesaria para que todo o desenvolvemento se leve a cabo de maneira axeitada e miles de cousas máis. Os profesores énchense a boca con normativas ISO, estándares IEEE e demais.

Ti xa vas intuíndo que a realidade non é tan bonita como os académicos a pintan… e que dende logo pretender facer toda a documentación que din que hai que facer, encher todas esas plantillas que din que hai que encher, e validar e revalidar por miles de persoas distintas é algo que nun desenvolvemento real dun producto é… cando menos, complexo.

Superamos as 130 páxinas documentando como se supón que din os estándares un software que non superaba as 200 liñas de código, para conseguir esa documentación nun software real fai falta un equipo únicamente encargado diso, cousa pouco habitual cando se fala de empresas pequenas.

A pesar de todo isto a ti quédache a esperanza de que algo do que viches fora útil… pero nada máis lonxe da realidade.

Mentres aprendíamos todo iso de estándares, documentos e demáis alguén lanzou por Twitter unha proposta para facer un traballo. Eu intuía de que ía o conto, e a verdade apetecíame moito facelo, así que dixen que si, enganchei polo medio a Silvia, Rubén e Adrián e reunímonos con quen ofrecía o traballo.

A proposta gustábame, presentárama esta persoa había cousa de un ano, e agora tratábase de facela para outro país, pero básicamente era o mesmo. Tratábase dun proxecto algo grande, pero asumible para 4 persoas.

Deberíamos ter sospeitado que todo non ía ir moi ben cando á pregunta “ao ser un proxecto para a administración, teremos algún documento oficial coas especificacións non?” a resposta foi “non non, isto decidímolo todo nós”. E tiñamos que ter sospeitado moito máis cando nos din que martes da seguinte semana hai que entregar 3 propostas de deseño da web… aínda que case seguro se quedarán con unha similar a doutro proxecto.

E ese foi o primeiro erro. Aceptar o proxecto, acordar un prezo, e non asinar un contrato especificando todo. E o segundo foi aceptar que a primeira data de entrega xa fose absurda.

Ademáis do apretado da primeira data de entrega, sumábase que había que traballar con tecnoloxías que non coñecíamos moito, polo que montar o entorno de desenvolvemento xa levou unhas cantas horas.

Cada día que pasaba había máis presa para entregar cousas, e o desenvolvemento complicábase porque non había nada especificado, ían xurdindo ideas que había que ir metendo. A idea inicial foi medrando sen moito control pola nosa parte, e o código tamén, polo que acabou habendo unha morea de liñas que ían facendo cousas, non sempre como debían, pero que ía servindo para ensinar que se avanzaba.

E ese foi o segundo e maior erro, ir metendo o que pedían sen control. Se aceptas ir introducindo modificacións sen ningún tipo de control acabas con un código ilexible, totalmente.

Nesa época cursabamos unha materia na que nos ensinaban boas prácticas para o deseño da lóxica de negocio das webs. Aplicar patróns de deseño, cousa que non fixemos e que tamén nos levou a problemas, posto que o mesmo código en varios ficheiros, que accedían aos mesmos datos, e que non che acordaba de cambiar en todos os sitios facía que todo acabase rompendo por algún sitio.

Ao final deixamos o proxecto, moito máis tarde do debido e con moita menos saúde do debido. Eu aínda estiven un pouco máis a voltas para pasarlle o proxecto a outra persoa. Hai que dicir que cobrar cobramos rápido, pero foron demasiadas horas de un proxecto moi mal levado.

En resumo, foi un desastre de proxecto, levounos a moitas horas de traballo, pero o peor é que foron moitas horas improductivas, por inexperiencia. Visto en retrospectiva creo que seríamos capaces de facelo moito mellor, pero fomos (sobre todo eu) incapaces de dicir “non” cando o tiñamos que facer, ou de dicir “isto non se pode facer neste tempo”, e de aí todos os erros cometidos.

Non me parei moito en pensar sobre o proxecto ata agora porque a verdade é que acabei moi queimado, pero agora que xa pasou máis de un ano e se ve todo con máis frialdade, caio na conta de que nos 3 primeiros cursos da carreira non se fala case nada do trato co cliente, e teño a lixeira sensación de que no último tampouco moito. Se ben é certo que en Enxeñería de Software se fala algo, é de maneira abstracta e non eres consciente da importancia de saber definir un proxecto ata que estás metido nun.

Tampouco se fala nada de cómo negociar, e se ben é certo que tampouco é algo sinxelo de introducir nun programa dunha materia, e o tempo é algo bastante limitado, eu plantexaríame introducir dalgunha maneira algo sobre negociación, xa que ao final imos ter que facelo, e ter unha base sobre o tema aforraría moitos quebradeiros de cabeza.

A conclusión que saco é que se agora me propuxeran un proxecto así non diría que si sen antes establecer todo o que se debe establecer, dende datas ata especificacións, e non as movería un ápice. Está claro que isto non é tan fácil cando estás falando co cliente, e sobre todo se o cliente se manexa moito mellor ca ti nas artes da negociación (cousa que no meu caso non é difícil, non son o mellor negociador do mundo), pero dicir que non, e non deixarte controlar é básico para non acabar coa metade de pelo ao finalizar o proxecto.

A min persoalmente serviume de bastante facer este proxecto, a pesar de todo, porque agora véxome moito máis capaz de negociar e de levar a cabo outros proxectos. Creo que non cometería o erro de dicir que si tantas veces, e moito menos o erro de arrastrar a ninguén conmigo a non ser que esté totalmente convencido de que vai ser levadeiro, como fixen desta vez.

En definitiva, apréndese cando che toca lidiar na rúa. 12 créditos dunha materia na que se teoriza sobre a creación dun proxecto non che axudan en nada, agás quizais en saber que a ISO 12207 fala dos ciclos de vida do software. A iso e a plantexarse, unha vez máis, quen decide os contidos das materias, pero iso queda para outro post.

Publicado en: proxectos, universidade
2 comentarios en “Maneiras de aprender
  1. Trasniña di:

    Como ves, Isaac, a caminar se aprende andando. Y esa lección no la olvidarás en la vida. Tienes razon en decir que deberían daros alguna indicación en ese sentido, pero, en ninguna carrera lo hacen. Sales con el título y unos conocimientos teoricos (el que los tiene) y la profesión se aprende ejerciendo. Te felicito porque has demostrado que la experiencia te sirvió para espabilar y no dejar que nadie más se aproveche de tu inexperiencia o de tu buena voluntad, y porque, además, quieres poner sobre aviso a otros que vengan detrás de ti. Es muy generoso de tu parte.

  2. Moitas grazas polo comentario. Está claro que a única maneira de aprender é enfrontarse aos problemas, pero a universidade podería axudar nalgunhas cuestións, pero se os profesores non as coñecen non poderán axudar… e ese é o maior problema, que os que ensinan non coñecen a realidade.

Deixa unha resposta

O teu enderezo electrónico non se publicará Os campos obrigatorios están marcados con *

*