¿Cómo ser un programador muy productivo?

ser programador más productivo

Ser mejor o peor desarrollador de software no depende de la herramienta de software que utilices. Depende más de qué herramienta eliges según qué proyecto de software tengas enfrente. Lo mejor es tener una buena caja de herramientas y saber qué debo utilizar para según que cosa, y especializarse en un nicho de mercado que te permita sacarle la máxima rentabilidad a las herramientas de desarrollo por la que has optado.

Una vez que ya sabes qué plataforma de desarrollo tienes que usar para afrontar un proyecto de software y el nicho al que te vas a dirigir, hay una serie de consejos prácticos que te pueden ayudar a ser un programador más productivo.

5 claves para mejorar programando

¿Acabas de empezar a programar? ¿Llevas 10 años programando? Da igual, este artículo es para ti, siempre y cuando busques mejorar, ser buen programador y crecer profesionalmente. Vamos a explicar 5 claves para mejorar programando y poder optar a mejores puestos y evolucionar desarrollando software. Aquí van las reflexiones de un programador senior sobre este tema.

8 consejos para ser un programador más productivo

Tus horas de trabajo como programador suponen un coste para ti si eres trabajador autónomo o una inversión importante para tu empresa si trabajas por cuenta ajena. Todo consiste en usar el sentido común y retirar los obstáculos que te impiden trabajar al 100% de tus capacidades.

Los programadores en términos generales tenemos ingresos superiores a la media si nos comparamos con otros puestos de la oficina con igual experiencia y nivel de formación y en muchos lugares escasean los buenos programadores. No hace falta señalar que debido al coste por hora de un programador, tiene sentido que hagamos un esfuerzo por mejorar nuestra productividad. En cualquier caso, en este artículo vamos a compartir 8 consejos para ser un programador más productivo.

Deja de pensar inútilmente

Cuando hablo con otros desarrolladores sobre la complejidad de un código, a menudo me dicen que quieren escribir un código más sencillo, pero que los plazos o otros asuntos no les permiten tener el tiempo o el conocimiento necesario para completar la tarea, y muchísimo menos refinar hacia un código más simple.

La verdad es que poner más presión sobre los programadores tiende a que escriban códigos más complejos. Sin embargo, los plazos no deberían llevarnos a escribir un código más complejo. En vez de decir que un plazo no te permite escribir código sencillo, podríamos enfocarlo de la siguiente manera: no soy un programador lo suficientemente rápido para hacer esto sencillo. Es decir, cuanto más rápido seas como programador, menos afectado quedará  la calidad de tu código por los plazos. El secreto para programar rápido es dejar de pensar inútilmente.

Barreras que debes superar cuando estás aprendiendo a programar

Muchas personas de mi entorno viven de la programación de alguna u otra manera. Algunos son programadores de software de gestión empresarial, otros desarrolladores web, otros hacen consultoría, otros son analistas-programadores, y otros se dedican a formar a programadores novatos. Cada uno me habla sobre los motivos de éxito y de fracaso de un programa, o de una web, o de un curso de formación.

Pero, ¿qué  barreras debes sortear cuando estás aprendiendo a programar? ¿Cómo las superas? Aquí van 8 barreras que debes superar cuando aprendes a programar.

Artículos relacionados: 10 consejos para mejorar destrezas de programación y ser mejor desarrollador, Consejos para programadores de software, Consejos prácticos para programadores,

Este artículo ¿Cómo ser un programador muy productivo? es original de Velneo.

Cuando un desarrollador dice: “Eso no se puede hacer…”

La visión de las cosas del programador

Es difícil para los no programadores, entender cuán complejo puede ser el desarrollo de software. Sólo tienes que decirle al al ordenador qué hacer, ¿verdad? ¿Qué tan difícil es eso?

Bueno, es engañosamente difícil, porque el ordenador carece completamente de lo que los teóricos han descrito como un marco de conocimiento. Por ejemplo, puedo pedirle que haga algo simple, como “tráeme un bocadillo de jamón”. Puedes intuir rápidamente que yo en realidad lo que quiero decir es “vete a la cocina,” haz un bocadillo de jamón, y tráemelo “o”vete a la bocatería, pídeme un sándwich de jamón, y me lo traes” basado en el contexto en el que físicamente estamos y lo que ha sucedido las últimas veces que esa misma petición se ha realizado.

Se puede intuir, en el caso del escenario de ir a la cocina, que hay que ir a la nevera, encontrar el jamón, el queso cheddar blanco (porque sabes que me gusta, y no el americano), la mostaza Djion (porque sabes que me gusta en el bocadillo de jamón y no la mayonesa) , encontrar una barra de pan, montar todo el asunto, guardar los ingredientes de nuevo en la nevera, averiguar dónde están los platos, emplatarlo, y traerlo. Y si eres muy observador, notarás que me estoy saltando un mogollón de pasos como saber cuánta mostaza a utilizar, sacarle la envoltura plástica al queso, cuánto jamón entra en un bocadillo estándar de jamón, qué es en realidad un bocadillo, y si nos ponemos qué es el “jamón”…

Cuando te sientas a programar no te puedes saltar ni uno de esos pasos minúsculos. Si no se especifican detalladamente los pequeños pasos aparentemente microscópicos que son intuitivamente obvios para ti, como ser humano, que vives en un mundo lleno de contextos y matices, el ordenador hace lo incorrecto, o falla, o a veces las dos cosas.

Un poco de empatía a la hora de hacer peticiones

Como no programador, probablemente le estés diciendo a los programadores que están trabajando en un software cosas del estilo: “¿puedes hacer que esa ventana sea más grande?” o “dirigirte al usuario por su nombre de pila” o “deja que el usuario publique eso en su página de Facebook” o cosas vagas e indeterminadas del estilo, en un contexto de una gran variedad de cosas de las que el ordenador “no sabe” absolutamente nada.

Para ti es intuitivo, y parece muy fácil…. entonces, ¿Cuál es el problema?

El problema está en que los programadores con este tipo de tareas tienen que manejar diferentes capas de complejidad. Hoy en día, hay que dar por hecho que no han escrito todo el código con el que trabajan ellos mismos, han usado una librería (trozos de código escrito por otra persona para solucionar problemas muy comunes) proporcionada por un tercero, para hacer todo el trabajo “gordo”. Normalmente esto implica usar más de una librería, ya que hay muchos tipos de dependencias e interdependencias.

Así que cuando le dices a un desarrollador: “deja que los usuarios posteen en Facebook”, tienes que tener en cuenta que van a esccuchar tu pertición y van a pensar “eh, claro, eso se puede hacer más o menos de forma sencilla quizás, creo que tenemos su información de Facebook en una base de datos por aquí, creo que tenemos las librerías apropiadas para eso aquí, sí, se puede hacer fácilmente”, lo que conduce a hacer una estimación optimista de cuanto tiempo puede tomar.

Empiezan los problemas imprevistos

Pero cuando se ponen a hacer la tarea en cuestión, los desarrolladores caen en la cuenta de que uno o más de los supuestos que habían pensado estaban equivocados, o que para usar la librería que querían usar implica que no pueden usar la versión de una librería que están usando ahora, y tienen que usar una nueva librería distinta de la versión actual, lo que implica volver a programar todo el código que hace uso de esa librería (nada de esto tiene que ver con el trabajo que tú habías solicitado, si te fijas)  y luego ponerse con la tarea encomendada, para luego darse cuenta de que algo que pensaban que podían usar ahora se ha quedado obsoleto y ahora necesitan encontrar otra librería que luego tienen que volver a valorar para ver si es compatible con el código que tienen montado ahora…

Todo este proceso se va haciendo cada vez más complejo en el momento en que un supuesto mal asentado de base resulta ser equivocado. Al principio todos los supuestos parecen tener lógica y aparentemente están bien planteados, pero cuando te metes a programar es cuando puedes aseverar al 100% que todo va a salir según lo previsto.

La técnica del descargo de la responsabilidad

Los mejores programadores con los que he trabajado empiezan a establecer sus previsiones y estimaciones de tiempo de trabajo en torno a fórmulas de descargo de responsabilidad del tipo: “si damos por cierto X, entonces…” 0 “si algo no funciona como está documentado…” y cosas parecidas. Saben, por experiencia, que siempre hay algo escondido, al acecho, en las profundidades como un oso polar que sorprende a la foca para devorarla. Y por ello preparan al cliente que les paga las aplicaciones en consecuencia, mentalizándolo de que estas cosas suelen pasar de forma inevitable.

Los programadores menos experimentados, llenos de confianza en si mismos tanto a la hora de programar, como a la hora de pensar que saben todo lo que tiene que hacerse y dando a entender que lo tienen todo bajo control, son menos cautos y caen en el “sí, claro, eso me toma una semana”. Pues aveces sí, tienen algo de presupuesto y pueden tapar los problemas que surgen de temas inesperados, pero muchas otras veces no, y se meten en un problemón con el cliente y con la empresa para la que trabajan.

Conclusión: hay que saber traducir lo que dice un programador

Conclusión, hay que saber traducir. Si un programador dice “eso no se puede hacer”, casi siempre lo que quiere decir es “ni de broma voy a poder hacer eso dado que mi forma de percibir intuitivamente las limitaciones operativas reales con las que me tengo que desenvolver en la empresa, y es tan difícil explicarte todo esto, que me va a explotar la cabeza. Vete. Lejos.”

Si eres el jefe de proyectos y recibes muchos “eso no se puede hacer”, es hora de volver a evaluar no solo tus expectativas, sino el entorno de trabajo en el que están los programadores a tu cargo. No hay suficientes, no tienen suficientes recursos, les estás exigiendo demasiado en cosas que no les permite avanzar en tareas fundamentales -algo está fallando…

En vez de poner cara de frustración e incredulidad, enfoca el asunto con un “Vale, ¿y que podemos hacer para que esto sea posible de hacer?”. Llegarás mucho más lejos, y con un poco de suerte podrás corregir la deriva de un barco que va hacia el naufragio.

Nota: este texto es de Stan Hanks, ingeniero de software, y lo publicó originariamente en Quora.

 

 

 

Este artículo Cuando un desarrollador dice: “Eso no se puede hacer…” es original de Velneo.

30 consejos para tener éxito como desarrollador autónomo (II)

La semana pasada publicamos la primera entrega de 30 consejos para tener éxito como desarrollador autónomo. Repasamos las primeras 14 recomendaciones para pasar de ser programador dentro de una empresa por cuenta ajena a ser un desarrollador autónomo. En esta entrada seguiremos con el resto.

Este artículo está pensado para aquellos que quieren iniciarse como desarrolladores autónomos o aquellos que tienen una pequeña empresa de programación con 2 ó 3 desarrolladores, y se dediquen especialmente al desarrollo de aplicaciones empresariales y software de gestión.

#15 Cuida a tu principal activo

Tú eres el principal activo de tu negocio. Si te quemas, o enfermas, o si tus conocimientos se quedan desfasados, tu empresa lo pasará mal. Apenas tienes vacaciones, las bajas por enfermedad no existen y tienes que cumplir los plazos sí o sí sin apoyo.

Como desarrollador tienes que mantenerte actualizado, pero invierte el tiempo en investigar y aprender de forma inteligente, y no solo en las cosas que puedan demandar tus clientes, sino también en aquellas que te gusten a ti.

De vez en cuando apaga el ordenador y sal a dar un paseo. Socializa con tus amigos, invierte en tiempo de calidad para estar con tu familia y seres queridos, haz lecturas no-técnicas y disfruta de ser humano.

Y lo más importante, cuando las cosas en la empresa se ponga difíciles, cógete un tiempo para recargar pilas y recuerda por qué te embarcaste en esta aventura. Compensa muchísimo el tiempo libre para poder coger de nuevo el foco y centrarte en el proyecto.

#16 No piques código hasta la quiebra

Una muy buena calidad en el código es vital para tener éxito como desarrollador independiente, pero solo programar es un empleo, no una empresa. Para estar seguro, siempre tienes que ser exigente y exhaustivo, con el fin de crear el mejor software que puedas. Pero asegúrate también de tener algo más que hacer en tu flujo de trabajo cuando termines de programar.

Al estar programando solo, es demasiado fácil caer en la trampa de focalizar solo en el trabajo que tienes delante. De hecho es mucho más efectivo -siendo realista- hacer una tarea a la vez que estar haciendo múltiples tareas (desarrollando, marketing, ventas, contratos, facturación, planificación, administración, etc…). Lo malo de esta historia es que para tener éxito como autónomo y empresario tu fuerte tiene que estar en justo eso, en hacer varias cosas a la vez y bien a lo largo del tiempo. Hacer el trabajo que vas a facturar paga los gastos, pero encontrar más clientes es lo que permite que el negocio se mantenga a flote.

#17 Nunca te olvides de que eres una marca

Igual no te das cuenta al empezar, pero incluso si estás trabajando como externo para un solo cliente, tienes una marca, y tu marca eres tú.

Recuerda: la marca es una promesa de calidad y consistencia, y aunque puede representar cualquier cosa que consideres fundamental como desarrollador, tiene que ser preciso y unívoco.

La forma en la que te presentas a ti mismo, tu trabajo, tu equipo, tu filosofía de programación es la base de tu marca, y debe estar reflejada en todas las facetas de tu empresa, desde tu página web hasta tu tarjeta de empresa o hasta como hablas de tu negocio con un conocido fuera del trabajo. Si no eres constante o hablas vagamente sobre lo que haces, tu empresa lo tendrá difícil.

Muy a menudo las empresas de desarrollo de autónomos definen a su negocio usando uso de una herramienta o una moda pasajera. ¿Prefieres contratar a “Java Pro” o a un “experto en aplicaciones empresariales”? Las marcas que se desarrollan en torno a una herramienta de moda pueden ser lucrativas al principio y temporalmente, pero rápidamente se convierten en estándares o básicos, perdiendo identidad, personalidad y exclusividad.

Cuanto más específico seas sobre lo que haces, por qué lo haces y lo que representas, más fácil será distinguir tu marca de otros, y en consecuencia más fácil será identificar y encontrar clientes potenciales. El hecho de fijar una marca clara e unívoca se traduce en mayores oportunidades a medio y largo plazo.

#18 No puedes contentar a todo el mundo

Como autónomo la satisfacción de los clientes es primordial, pero no puedes obsesionarte con intentar contentar a todo el mundo porque corres el riesgo de hundir el negocio. Hacerlo te obliga a exprimir a fondo todos tus recursos, en exceso, y al final no trabajas bien para nadie. Esto no quiere decir que no haya que volcarse con los clientes lo mejor que sepas, ni que no aceptes trabajos fuera de tu zona de confort. Pero presta atención a los límites de tus habilidades y recursos. Comprometerse más de la cuenta y aceptar proyectos que no puedas realizar con la calidad esperada por tus clientes puede rápidamente derrumbar tu empresa.

Por el contrario, tienes que ser muy estricto a la hora de registrar cuánto tiempo te toma cada tarea, para que seas capaz de saber cuánto trabajo puedes asumir en momentos de sobrecarga. Ten en cuenta que tienes que guardar tiempo para formarte, tienes una empresa que gestionar y tener el dominio técnico necesario para dar el servicio de calidad que quieres también te quita tiempo del trabajo para los clientes.

#19 Preocúpate de estar apuntando al nicho correcto

Las PYMES que buscan escapara del trabajo basado en procesos manuales pueden a priori ser un cliente ideal para tu pequeña empresa de software incipiente que busca despegar, ya que al final todas a¡las empresas buscan recoger los frutos de los procesos automatizados. Al mismo tiempo son las PYMES las empresas más desconfiadas hacia la tecnología y hacia los proveedores autónomos desconocidos, y quizás su tesorería no es la más boyante para poder costear tus servicios.

Dirigirse al nicho apropiado es más un arte que una ciencia, pero una máxima muy simplificada es buscar una combinación de clientes potenciales a los que les encaje tu producto, que lo puedan pagar y que no tengan resistencia ni miedo al cambio. ¿Fácil no? 😉

Encontrar a clientes potenciales a los que les cuadre tu producto es un proceso complejo y volátil donde se mezclan ambiciones, problemas, necesidades, destrezas, lagunas, beneficios y tiempos.

Lo más común es que no haya signos externos de los anteriores, así que tienes que hablar y tantear a muchísimas personas de varios sectores y organizaciones para averiguar si les encaja.

Y mientras estás en ello puedes evaluar la parte económica -si una empresa no puede pagar tus servicios, todo el proceso es un sinsentido.

Medir la capacidad de asumir el cambio y el no tener miedo a cambiar es algo que se percibe más con intuición que con otra cosa. ¿Los clientes potenciales del nicho de mercado elegido tienen el valor y pueden ver la luz si se convierten en tu socio tecnológico? Los sistemas de software cambian los procesos de negocio: para muchos sectores y muchas organizaciones, los cambios dan miedo. No pierdas el tiempo buscando oportunidades que al final no van a atreverse a dar el salto.

#20 ¿Quién defiende tu proyecto? ¡Identifícalo!

Todo proyecto de software que hagas para una empresa tendrá un “defensor” de tu producto dentro de la compañía. Normalmente es la persona que tiene autoridad para decidir las inversiones, y si ha apostado por ti defenderá tu proyecto para garantizar que tenga éxito. Es fundamental identificar a esta persona y establecer con ella una relación de confianza, cuando sea posible.

Muchas veces en las reuniones consultivas en casa del cliente, la persona que decide finalmente no está presente, o no se revela ni  menciona. Y lo que es peor, muchas veces los jefes de departamento afirman tener la autoridad y el presupuesto para llevar a cabo un proyecto, pero no siempre es verdad.

Siempre fíjate en quién financia el proyecto. En algunas empresas los responsables de departamento pueden gestionar el presupuesto a discreción, y en tal caso ellos son tu aliado dentro de la organización. En otras empresas, hay directivos de rango superior -y muchas veces hay más de uno- que son los que realmente han evaluado y aprobado tu proyecto sin tú saber precisamente quién ha sido. En estos casos esa persona es clave: se necesita su aprobación para futuras inversiones en proyectos.

No es inusual, especialmente en PYMES, que el gerente de la empresa tenga la apariencia de ser la figura decisoria, pero en realidad es el dueño o el financiero el que firma los presupuestos… No te dejes engañar y no confíes en que existe un compromiso más serio que el que tienes en realidad.

#21 Establece y conserva un flujo comercial

Vender desarrollos de software hechos a medida para nicho es un proceso lento y consultivo. Los clientes potenciales puede que sepan que tienen una necesidad, pero lo más probable es que no tengan mucha idea de cómo solucionar ese problema.

Al fin y al cabo, la decisión de adoptar una solución de software echo a medida puede variar el rumbo y los cimientos de una empresa completamente: cuanto más grande la empresa, más se tarda en la toma de decisiones y en seguir el nuevo rumbo.

Los cierres de presupuesto se eternizan, incluso si tienes muy buenas referencias y recomendaciones, y puedes estar meses esperando a que se firme un proyecto

Por estas razones, debes intentar tener clientes potenciales entrando en tu flujo de ventas. Siempre tienes que medir el tiempo invertido y los resultados obtenidos. Estos indicadores son cruciales a la hora tener un flujo comercial constante.

Imagínate que necesitas de media un cliente para que durante 6 meses puedas mantener la empresa a flote, y que averiguas que de cada 600 potenciales clientes, cierras 1 de media. En este ejemplo simplista, si entran menos de 100 clientes potenciales en tu flujo comercial al mes ya sabes que te va a costar mucho poder financiarte.

En el mundo real, los números son más complicados, pero la estructura de tu embudo de ventas es siempre la misma: entra un cliente potencial, tiempo transcurrido, cierre de la venta. Hay que medir los tiempos de cualificación de clientes, los tiempos de cierre de presupuestos y ventas, la facturación media por proyecto vendido, y los porcentajes de cierre de presupuestos de venta.

Aprende a usar esos números para proyectar ingresos futuros del actual embudo de venta y fíjate más en las tendencias que en un resultado particularmente bueno o malo en un mes.

#22 Diversifica tu base de clientes, minimiza riesgos

La mayoría de los desarrolladores de software independientes saltan a la aventura de tener su propia empresa cuando tienen la oportunidad de hacer un proyecto importante para una empresa. Esto puede ser bueno para empezar, pero hay que tener cuidado porque no puedes sostener tu negocio con un solo cliente. Si ese cliente te deja, tú te hundes.

Otro inconveniente de tener un solo cliente es que su trato contigo será como la de un trabajador “externo”, no como la de un “socio tecnológico consultor de valor”. Esto se traduce en que cada vez te van a exigir más al mismo precio, como hacen todas las empresas con sus empleados, pero sin los derechos de los empleados contratados por cuenta de ajena.

Es mejor tener tres clientes medianos que uno grande. Y lo óptimo es tener 20 pequeños, ya que no te van a dejar tirado los 20 a la ves.  Recuerda la máxima: tener un cliente es como tener un mal puesto de trabajo, tener varios clientes, y diferentes fuentes ingresos, es tener una buena empresa.

#23 Piensa en impuestos y costes fijos

Tener problemas con Hacienda por no tener una buena estrategia fiscal es algo que puede ahogar tu negocio. No se trata solo de contratar una gestoría para que te “muevan los papeles” o hacer tu los trámites online para estar al día con tus impuestos, se trata más bien de estar bien informado y planificar una estrategia fiscal. Si no tienes recursos al principio para pagar el servicio de un asesor, puedes empezar tu mismo, pero dedica tus primeros ingresos a buscar la ayuda de un profesional que te asesore en estos asuntos.

Te puede parecer una inversión innecesaria al principio, pero a medio plazo te darás cuenta de todo el dinero que te ayuda a retener. No hablamos en ningún caso de defraudar, pero si de estudiar para cada caso cuál es el mejor plan según tus circunstancias profesionales y personales. Una mala estrategia fiscal te puede llevar a la ruina por falta de previsión y conocimiento.

Lo mismo se puede decir sobre los costes fijos, aunque estos son más previsibles y no dan lugar a muchas sorpresas.

# 24 Gestiona bien los cobros y procura tener liquidez

La mayoría de las pequeñas empresas de desarrollo se gestionan de forma ligera en términos de liquidez. Lo normal es no tener una tesorería muy boyante, sobre todo al principio de la actividad. La gestión de los cobros es otra piedra angular de cualquier empresa y es una tarea que requiere dedicarle más tiempo a medida que crecen el número de clientes para los que programas aplicaciones.

En el mundo real tenemos que tener cierta flexibilidad con los clientes, no todos siempre pagan en plazo y es importante saber empatizar, siempre y cuando sean situaciones puntuales ya que ayuda a tu relación con él. Si ves que un cliente entra en un comportamiento repetitivo en el que siempre se retrasa en los pagos de forma injustificada, o por problemas administrativos de gestión de facturas, retraso en la ejecución de las transferencias, etc… El cliente puede que esté pasando por problemas internos de los que no te está informando.

Puede que sea una situación temporal, pero si se prolonga mucho en el tiempo, puede que te quedes sin liquidez para cubrir tus costes fijos. Haz todo lo que puedas por cobrar a tiempo. Estudia el proceso de pagos de cada cliente, quién participa, quién está implicado, cuánto tiempo le toma, y ponte en alerta si el cliente empieza a fallar en el proceso.

#25 Contrata solo cuando tengas suficientes proyectos para pagar nóminas

Una gran preocupación a la hora de hacerse autónomo es determinar en qué momento ya no puedes seguir solo. Muchos optan por disponer de menos liquidez con tal de tener a alguien que les ayude. Pero es fácil sobrestimar el alcance o la certeza de nuevos proyectos y contratar a personas con ganas y talento, incluso a un coste razonable, Al fin ya al cabo, la única forma de crecer es creciendo, ¿no?

El problema es que esto incrementa tus costes fijos desde el día 1 sin necesariamente incrementar tu facturación. Implica cambios en tus presupuesto y en tu forma de organizar el tiempo. El hecho de cambiar los procesos de trabajo para acomodar a una nueva persona, formarla, gestionarla, etc… Todo esto te puede descolocar y lastrar tu capacidad de cerrar ventas y hacer los proyectos con la calidad esperada. Contrata con cuidado.

#26 Sal a la calle y habla con potenciales clientes

La mayoría de los programadores que se hacen autónomos lo hacen para solucionar problemas, crear aplicaciones, y dar buenos resultados. Quizás no disfruten de las tareas relacionadas con Marketing y Comercial, pero estas tareas no se pueden dejar de lado, y no te recomiendo que las subcontrates. Al menos no las fundamentales.

No existen los atajos en el proceso de ventas, no si quieres montar un flujo más o menos fiable. Puede que te salga alguna buena venta por suerte, pero lo mejor es apostar por un método de venta constante, fijo, fiable y que puedas ir ajustando. Y lo más importante, que entiendas al 100%. Evalúa cada táctica y herramienta de marketing y ventas con el mismo ojo crítico que usarías a la hora de decidir qué nuevo lenguaje de programación o entorno de desarrollo adoptar.

Haz pruebas y compara, analiza los flujos, busca por dónde te entran los clientes mejor y apuesta por un método, dale tiempo y no caigas en la tentación de hacer giros ni cambios bruscos. Incluso los métodos de ventas más probados en el tiempo necesitan ajustarse a tu negocio para funcionar. Debes fijar expectativas realistas y plazos asequibles, y date tiempo para entender bien los sistemas. Si fueras dando saltos por cada nueva tendencia de programación cada mes, nunca terminarías de entender ninguna y estarías perdiendo el tiempo. Lo mismo se puede decir de las tendencias y herramientas de ventas y marketing. Para decirlo en otras palabras, no hay forma de escapar de el proceso de aprendizaje en ventas y marketing, tiene una curva de aprendizaje y requiere mucho esfuerzo.

Una empresa que no vende no es una empresa, y vender no es nada fácil. Lo mejor es ir aprendiendo por el camino, habla con clientes potenciales y usa esa experiencia para ajustar los procesos a mejor.

#27 Documenta, afina y automatiza los procesos

Todo lo que suena a procesos y documentación suena a organizaciones elefantiásicas del jurásico, y son de esas cosas que te empujan a dejar una empresa grande por la lentitud con lo que se mueve todo.

No te confundas, una empresa pequeña se debe hacer diferencial basándose en ello. Si lo piensas, seguro que ya tienes procesos que sigues, que repites y que llevas años afinando. Y si ya tienes años de experiencia probablemente se los hayas enseñado a otros.

Hazte un favor, documéntalos, contrástalos con otros, mejóralos y automatízalos cuando sea posible. La automatización es tu pan de cada día. Cuando vendes un proyecto, ensalzas las ventajas de la automatización todo el rato, ¿no? ¿Y tú a nivel interno? ¿Tus procesos son manuales o directamente no existen?

No seguir procedimientos hace que los resultados del trabajo sean impredecibles, y lo que es peor, te hace perder el tiempo, y para un empresario, su tiempo es el recurso finito más crítico.

Hacer cosas de forma manual está bien al principio, pero si una tarea se vuelve muy tediosa y repetitiva, automatízala ya que ayuda a reducir fricciones a lo largo de todos los demás procedimientos. Analiza dónde pierdes el tiempo haciendo tareas improductivas, y automatízalas. El concepto de “Automatización” debes verlo en sentido amplio, desde sistemas de software automático que hacen cosas por ti mientras duermes o estás en tu tiempo libre, hasta asistentes virtuales, asistentes personales, servicios subcontratados, etc…

#28 ¿Cómo vas a dar soporte técnico?

Prestar un mal servicio técnico es una de las razones principales por las que un cliente se te puede ir a la competencia. Cuanto menos soporte tengas que dar, mejor, en un mundo de color de rosas… Pero si tienes muy buena reputación por dar un soporte excelente, eres oro puro con piernas, y no solo porque te permite mantener una buena relación con el cliente, sino porque tus clientes se convierten en tus evangelistas cuando siente que les solucionas los problemas con rapidez y sencillez.

Esto no quiere decir que tengas que privarte de dormir para solucionar problemas por la noche (como norma :)). Significa que tienes que educar a tus clientes para que puedan entender cada aspecto de tu aplicación, enseñándoles como resolver problemas y hacer tareas por sí mismos, y también formarles para que tengan la sensación de que tienen toda la información que necesitan y confíen en ti y en tu producto, reafirmándoles que su decisión de estar contigo es lo mejor para su empresa.

Tú no haces software para un cliente, lo que creas es su futuro. Quizás tú no tengas que vivir en su futuro mucho tiempo, pero ellos van a vivir ahí para siempre. Apoya su visión y sus decisión, dales refuerzo y garantías. No existe tal cosa como “eso no es mi problema”. La prevención es clave, los clientes no quieren hablar contigo por temas de soporte.

#29 Aprende a delegar de forma efectiva

Cuando emprendes en solitario, cualquier decisión que tengas que tomar es importante, y dado que est tu empresa, te toca a ti tomarlas todas. A medida que crezca tu empresa, las decisiones que tienes que tomar se van amontonando: ¿qué proyectos emprender? ¿cómo gestionar la sobrecarga de trabajo? ¿dónde conseguir nuevos prospectos y clientes? Ten mucho cuidado. Puedes verte envuelto en un cuello de botella que puede arruinarte.

Con directrices claras, responsabilidades bien asignadas, y procedimientos funcionales, la delegación puede convertirse en tu herramienta más valiosa, incluso si eres de esos perfiles obsesivos que necesitan tener absolutamente todo bajo control.

#30 Apuesta por herramientas rentables y especializadas

Si eres un desarrollador autónomo o si tienes una pequeña empresa de desarrollo con 2 ó 3 desarrolladores, lo más normal es que tus cliente sean PYMES que están buscando modernizar o mejorar procesos dentro de la empresa mediante el uso de aplicaciones empresariales, páginas web, soluciones de movilidad, cloud, etc…

Una buena herramienta no hace un buen programador. Como dice mi compañero Jesús Arboleya: “un buen programa nace del trabajo que realizan los buenos desarrolladores no de que el lenguaje o herramienta utilizada sean buenas, ya que en realidad no existen buenas o malas herramientas sino malas selecciones o usos de herramientas de forma inadecuada”. 

Si vas a apostar por hacer aplicaciones empresariales, lo mejor es que elijas una herramienta especializada para ello, una herramienta que tenga en cuenta la problemática de este tipo de desarrollos, la fiabilidad y la seguridad de la base de datos, que aporte características propias del ámbito de la empresa (cloud, multiplataforma, fácil refactorización y mantenimiento, etc…).

Eligiendo la herramienta adecuada para cada proyecto además ganas en rentabilidad y tienes más tiempo para otras cosas.

Citando de nuevo a mi compañero Arboleya: ” todos los que nos dedicamos al desarrollo de software sabemos desde el primer día que el elemento más importante en nuestro trabajo es el tiempo. El tiempo no solo es el más importante, además también es limitado, no se puede ampliar, por lo que lo mejor que podemos hacer es ser lo más productivos posible en nuestras horas de trabajo”.

Espero que todos estos consejos te hayan resultado útiles. Están pensados para aquellos que quieren iniciarse como desarrolladores autónomos o aquellos que tienen una pequeña empresa de programación con 2 ó 3 desarrolladores, y se dediquen especialmente al desarrollo de aplicaciones empresariales y software de gestión.

Si quieres hacer cualquier otra recomendación, te invito a que lo hagas en la zona de comentarios. ¡Ánimo con tus proyectos!

Este artículo 30 consejos para tener éxito como desarrollador autónomo (II) es original de Velneo.

5 consejos técnicos para desarrollar aplicaciones empresariales

En este artículo hacemos una recopilación de consejos técnicos para desarrollar aplicaciones empresariales de la mano de Jesús Arboleya, evangelista y consultor de Velneo en el departamento de éxito de clientes. Es el autor del curso Mi primera aplicación con Velneo, que puedes hacer gratis. Todos los conceptos que se comentan a continuación están explicados en la documentación de Velneo

#1 Pensar en listas es más natural

Hoy en día la gran mayoría de personas usamos a diario algún tipo de aplicación. Casi todas las aplicaciones gestionan información y disponen de interfaces adecuados para conseguir la mejor experiencia de usuario posible.

A nivel de interfaz como usuario solemos navegar por la información igual que lo hacemos en un mapa, que no deja de ser un tipo de información que nos hemos acostumbrado a visualizar de forma gráfica, es decir solemos comenzar con un mapa general sobre el que vamos haciendo zoom para acercarnos y ver con detalle solo aquello que realmente nos interesa.

Seguir leyendo

#2 Ficha y lista de registro

Este es un concepto que debemos tener claro al programar con Velneo ya que algunos de los comandos de instrucción de acceso a la base de datos están orientados a listas y no a fichas. Por este motivo podemos llegar a buscar un registro concreto usando un comando como cargar lista o un objeto como la búsqueda que devuelven listas.

Cuando resolvemos de forma precisa todas las partes de un índice de clave única de una tabla, Velneo nos devolverá ese registro, si estamos usando cargar lista o una búsqueda, por ejemplo, nos encontraremos que lo que obtenemos es una lista de un registro.

Seguir leyendo

#3 Formularios de alta, baja y modificación

Uno de los aspectos más cómodos de Velneo para los programadores es la sencillez con la que declaramos en un objeto de lista como una rejilla o grid cuáles serán los formularios de alta, baja y modificación.

Podemos no declarar ninguno, declararlos todos o declarar solo algunos según nuestras necesidades funcionales. Por ejemplo, no poner el formulario de alta si no queremos que el usuario pueda añadir registros, o no declarar el de baja si no queremos permitir al usuario eliminarlos.

La cuestión que en algunos casos nos podemos plantear es ¿Uso el mismo formulario para las tres operaciones o creo formularios diferentes? ¿Qué ventajas o inconvenientes tiene hacerlo de una u otra forma?

Seguir leyendo

# 4 Funciones y procesos

Funciones y procesos. Cada objeto tiene sus virtudes y también sus limitaciones. Conocerlas nos ayuda a decidir cuando usar uno u otro.

Seguir leyendo

# 5 Índice de los campos punteros a maestros

Algo que es habitual cuando diseñamos la estructura de la base de datos de nuestra aplicación es la creación de las relaciones entre tablas. Al crear dichas relaciones en las tablas se añaden campos de tipo de enlace maestro. Si este campo lo añadimos usando las herramientas del esquema, el asiente de creación de tablas o la opción de la toolbar del editor de tabla, además de crearse el campo puntero a maestro se crea su correspondiente índice de tipo acepta repetidas.

Sin embargo, en ocasiones creamos estos campos de forma manual o duplicando otro campo puntero a maestro. En estos caso no se crea el índice. Y ya te adelanto que no es conveniente eliminar estos índices que se crean automáticamente.

Seguir leyendo

Este artículo 5 consejos técnicos para desarrollar aplicaciones empresariales es original de Velneo.

Los secretos de buen análisis en los proyectos de software

¿Quieres aprender las claves para hacer un buen análisis en tus proyectos de software? Te presentamos aquí el podcast de un valor incalculable de nuestros expertos compañeros Jesús Arboleya y Mario Conde, en el que te destripan los secretos de un buen análisis que asegure el éxito de un proyecto de software.

En todo proyecto es necesaria la figura del analista. El trabajo de un analista consta de varias facetas:

1. Escuchar

Tenemos 2 orejas y 1 boca para escuchar el doble de lo que hablamos.
Cuidado con hablar más de la cuenta.
Levantar acta de todas las reuniones.

2. Pensar

El 80% del éxito de un proyecto software depende de un buen análisis.
Documenta tu análisis para que lo puedan entender todos.

3. Abstraer

El papel lo soporta todo, pero las bases de datos no.

4. Concretar

Define la estructura de la base de datos.
La complejidad no es una buena compañera.
Lo complejo suele ser un síntoma de falta de conocimiento.

5. Programar

Analiza, analiza y analiza antes de escribir tu primera línea de código.
En un proyecto de software un mal análisis garantiza un 100% de fracasos.
Evidentemente, tras un buen análisis debe seguir un buen desarrollo.

6. Comunicación

Un buen analista debe ser también un buen comunicador.
Todos los stakeholders deben participar en el proyecto para que tenga éxito.
Al cliente siempre hay que informarlo con antelación de todo, de lo bueno y lo malo.
Por muy buen analista que seas, cometerás errores.

7. Funcionalidad

No caer en el error del efecto “barra libre”.
Menos es más.
No añadir nada que no nos hayan pedido.
Lo que sobra es tan malo como lo que falta”.
Una aplicación nunca está terminada.

Este artículo Los secretos de buen análisis en los proyectos de software es original de Velneo.

Consejos para vender software

 

PageLines-header.jpg

En este post hacemos una recopilación de artículos que ofrecen consejos para vender software.

¿Cuánto vale el software que crea un desarrollador? ¿Cuánto vale el tiempo? Es una pregunta que nos deberíamos hacer cada mañana, porque vivimos en una sociedad que se mueve tan rápido que nos parece que las semanas son días y los días son minutos. Tenemos que valorar cada minuto de nuestro tiempo, pero como hacerlo en el mundo del desarrollo de software, aquí van unas notas sobre mi experiencia personal, son cosas obvias pero a mí me ayudó tenerlas en un papel y no olvidarme de ellas. Espero que os valgan. Seguir leyendo ¿Cuánto vale tu software?

El mercado del software empaquetado está mucha más que obsoleto. Pero, ¿cómo vender software? ¿Cuál es el mejor modelo de negocio para las pequeñas empresas de software? Mientras las ventas de ordenadores de sobremesa y de portátiles cae, los fabricantes de hardware no son los únicos que sufren el impacto de un mercado menguante. Los vendedores tradicionales de software para PC, aquellos que en su día vendían productos de software instalables, están viendo como sus mercados se evaporan. Ocupando el lugar de los productos de software tradicionales tan comunes durante la época de Windows hay dos categorías de ofertas relativamente nuevas: las apps móviles y las aplicaciones SaaS -software como servicio- basado en software en la nube. Seguir leyendo ¿Cómo vender software?: modelos de negocio.

¿Por qué razones concretas fracasan los proyectos de software? ¿Cómo podemos evitarlo? Conociendo las razones más comunes que conducen al fracaso de un proyecto de software podemos intentar no caer en ellas o al menos poner en práctica medidas para paliar sus efectos de antemano, anticipándonos para controlarlos daños. En este post recogemos 7 motivos de fracaso de un proyecto de software en modo numerus apertus ya que seguro que por vuestra experiencia podéis aportar más razones. Seguir leyendo.

Hace 6 meses, un grupo de programadores y consultores de SAP, se interesaron por Velneo; de hecho estaban encantados con el producto y su única obsesión era trabajar exactamente igual que lo hacían, pero apoyándose en nuestras plantillas empresariales de código abierto. Sus necesidades más importantes, que lo siguen siendo, eran comprar todas las plantillas empresariales y en especial el ansiado CRM. En una primera fase están desarrollando unos módulos para temas financieros, en los cuales de las plantillas empresariales hay más bien poco y por otro desarrollando un esqueleto básico para la parte de producción (escandallos, trazabilidad y demás). La verdad es que me quede un poco con la mosca detrás de la oreja y abusando de su confianza, ya que eran antiguos conocidos les pedí, poder asistir a alguna demo de su producto y ver como vendían el famoso SAP. Seguir leyendo ¿Cómo vender mejor tu software al cliente final?.

Como sabéis, una parte del trabajo del consultor consiste en presentar las características del producto que va a ser utilizado para el desarrollo del proyecto final.

Además de esto, las empresas a las que nos dirigimos quieren conocer quien está detrás del producto Velneo, algo lógico si van a invertir en nuestra tecnología y con un proveedor no tan conocido como Microsoft, Google, … 😉 Uno de los servicios que venimos realizando es la consultoría de apoyo comercial. En proyectos de gran interés para vosotros y, normalmente, en empresas de cierta envergadura, os ayudamos presencialmente a presentar la tecnología con la que vais a solucionar las necesidades de vuestros clientes finales de la forma más productiva y eficaz. Seguir leyendo ¿Cómo hacer una presentación comercial de software?.

 

 

Este artículo Consejos para vender software es original de Velneo.

Consejos para programadores de software

Velneo productividad y rentabilidad programando

Al blog de Velneo se acercan todos los días desarrolladores de software de todo tipo y por ello nos gusta publicar artículos sobre consejos para programadores de software. Hoy he decidido hacer una recopilación de aquellos artículos más visitados por nuestros lectores.

Vivimos en una época en la que abundan muchos expertos en lenguajes de programación pero no hay muchos programadores de los de verdad. Es relativamente sencillo entender palabras clave, métodos y APIs del lenguaje de programación de Java, pero al mismo tiempo resulta complicado solucionar problemas reales, diseñar software robusto y re-utilizable y sacar el máximo de la estructura de los datos y de los algoritmos. Seguir leyendo 10 consejos para mejorar destrezas de programación y ser mejor desarrollador.

Programar es prever. Debes ir por delante y ser capaz de ver lo que va a ocurrir. Si no eres previsor tendrás que tirar muchas veces tu trabajo lo que minará y repercutirá en tu confianza y en la de los que te rodean. Seguir leyendo 8 características importantes de un buen analista programador

Muchas personas de mi entorno viven de la programación de alguna u otra manera. Algunos son programadores de software de gestión empresarial, otros desarrolladores web, otros hacen consultoría, otros son analistas-programadores, y otros se dedican a formar a programadores novatos. Cada uno me habla sobre los motivos de éxito y de fracaso de un programa, o de una web, o de un curso de formación.Seguir leyendo 8 barreras que debes de superar cuando aprendes a programar.

Ante la eterna pregunta de cuál es el mejor programa para hacer software para empresas,  la respuesta como todo en esta vida es que depende. Hay programas que tienen una curva de aprendizaje mucha más larga que otros, hay programas que van orientados a grandes empresas de programación, hay programas que son ideales para pequeñas empresas de programación y hay otros que han sido muy buenos en el pasado y que se siguen usando a pesar de que ya están descontinuados y que no tienen soporte. En todo caso, en este post hablaremos de programas de software que sirven para crear software empresarial. seguir leyendo ¿Cuál es el mejor programa para hacer software para empresas?

En el mundo de la programación los desarrolladores de software tienen un gran problema, al final todo recae sobre ellos y me explico: si un programador comete un error, pues lo corrige y ya está, lo normal. Si su jefe comete un error, al final lo tiene que arreglar el programador también. Si el cliente toma una decisión equivocada, ¿qué pasa? Estará el programador intentando arreglarlo a las 3 de la mañana. Y así sucesivamente… Como consecuencia, los buenos programadores experimentados aprenden a “gestionar” con mentirijillas piadosas a todas las personas que le rodean para evitar que estos errores sucedan porque bien saben que los demás (mandos, clientes, etc.) no tendrán que pagar el precio de una planificación descuidada, una toma de decisiones errónea, etc…Y es por esto que los programadores “mienten”, o al menos ocultan cositas, para evitar sobresaltos, sorpresas desagradables, experimentos y decisiones alocadas. Seguir leyendo Las mentiras más comunes que dicen los programadores. 

 

 

Este artículo Consejos para programadores de software es original de Velneo.

6 cosas que todo buen código de programación tiene

Buen código

Buen código

No todo código fuente nace en igualdad. Aquí se presenta una lista de las cosas que los desarrolladores piensan que marcan la diferencia entre un buen código y uno malo: 6 cosas que todo buen código de programación tiene.

Hay un montón de software hoy en día por el mundo, solo Google tiene más de 2 mil millones de líneas de código en su repositorio. Pero no todo el código fuente es creado igual. Los desarrolladores de software normalmente tienen unas preferencias muy marcadas en relación con lo que hace que un código fuente  sea etiquetado como decente y bueno.

Para averiguar qué es lo que hace que el código detrás del software sea mejor o peor, he consultado varias páginas webs y foros de desarrollo de software sobre el tema. El objetivo no es otro que intentar determinar qué expectativas tienen los programadores a la hora concebir un buen código fuente y con qué tipo de código les gusta trabajar.

#1 Es fácil de leer

Todos los desarrolladores parecen estar de acuerdo con que una de las más importantes cualidades de un buen código es que sea legible.  El código que está escrito de forma que sea fácil de leer por otros desarrolladores y que puedan entenderlo con poco tiempo y esfuerzo es considerado un buen código-

Si no puedo entender la intención de un programador en 5 minutos o menos creo que el código es claramente mejorable. Al ordenador no importan los nombres de las variables o el Inter espaciado entre líneas pero las personas sí. El código se escribe una vez, pero se lee cientos de veces a lo largo de su vida útil. Usar variables con sentido y insertar espacios para que la legibilidad del código hará que ese código sea mejor

Una vez un desarrollador senior de aplicaciones web con más de 10 años de experiencia programando aplicaciones profesionales me recomendó seguir un estilo consistente, siempre el mismo, con espaciados, sangrías y un flujo general que siempre sea igual. Además me insistió en la importancia de elegir nombres de variables que tengan sentido. 

También me dijo que si la función tenía dos argumentos, que las pusiera en dos líneas distintas o que si una expresión aritmética tenía varios términos, darle a cada uno de sus términos y su propia línea.

Resumiendo, un código más legible implica que sea más fácil de entender y le facilita la vida a todo el mundo.

#2 Está bien comentado

Además de estar bien formateado nombrado, los comentarios también hacen que el código sea más fácil de entender. Pero no cualquier tipo de comentarios, yo no necesito comentarios que me digan lo que hace un “for loop”. Necesito comentarios que me digan por qué el código está haciendo lo que está haciendo. Un buen código tiene comentarios que explican qué es lo que está en el autor de la cabeza del programador mientras se escribe el código.

Los buenos comentarios pueden ayudar no solo a otros programadores que ha leído tu código, pero también a ti mismo. Sé bueno contigo mismo en el futuro y no hagas que todo dependa de tu memoria. Incluso si eres la única persona que va a inspeccionar o modificar o revisar el código del futuro, te puede facilitar mucho la vida al elegir nombres con sentido y añadir comentarios informativos.

#3 Es sencillo

Puede que parte del código haga cosas muy complejas pero el mejor código, según muchos desarrolladores, normalmente es muy sencillo. Los buenos programadores sabrán cómo hacer una tarea sin complicar demasiado las cosas.

Cada trozo de código debería hacer sólo una tarea, y hacerla muy bien, y permitir que el siguiente trozo de código haga la siguiente tarea. Divide y vencerás. Las mejores soluciones son siempre las soluciones más sencillas.

Tampoco es bueno duplicar demasiado el código. Es recomendable implementar funciones cortas y bien definidas que realizan bien una tarea.

Es fundamental la sencillez. Simplifícalo todo lo que puedas. El mejor código es un código “vago”, que realiza poco trabajo pero de la forma más efectiva posible. He visto ejemplos de muchos códigos que hacían todo tipo de peripecias pero luego el programa se cerraba por los fallos más simples que te puedas imaginar.

Y es que al final la mayoría de los programadores piensan que si mantienes el código sencillo,  el software será mejor.  Lo normal es que un código complejo esté lleno de bugs,  mientras que la incidencia de bugs en códigos más sencillos es menor.

#4 Es flexible

La funcionalidad el código normalmente tiene que ser cambiado, ampliado o reutilizado en cualquier otro programa en el futuro. Un buen software está escrito pensando en los requisitos de hoy, pero también teniendo en cuenta las expectativas del mañana. Obviamente predecir el futuro es imposible, pero puedes escribir un código que sea lo suficientemente flexible para requerir solo cambios mínimos para adaptarlo a los requisitos futuros.

El código es bueno si los programadores futuros son capaces de añadir o cambiar ciertas partes del código sin tener que desmenuzar otras partes del código. En el momento en que te paras modificar el código de otros es cuando realmente te das cuenta de si ese código es bueno o malo.

#5 Es fácil de mantener

No importa cuan bien escrito un software, siempre inevitablemente tendrá errores y obviamente alguien tendrá que arreglarlo. Pónselo fácil a esa persona, ya que en cualquier momento tú podrías estar en ese lugar.

Que sea fácil de mantener es un atributo clave de un buen código, ya que todo el software necesita mantenimiento y no hay necesidad convertir esa tarea es un infierno para otros.

#6 Funciona

Para rematar, hay una característica obvia de un buen código que probablemente debemos citar aquí:tiene que funcionar. Tiene que hacer el trabajo para el que ha sido diseñado. No importa cuán bonito se vea, si no hace su trabajo, no sirve de nada.

 

Este artículo 6 cosas que todo buen código de programación tiene es original de Velneo.

8 consejos para ser un programador más productivo

consejos hacer software

Programación productiva

Tus horas de trabajo como programador suponen un coste para ti si eres trabajador autónomo o una inversión importante para tu empresa si trabajas por cuenta ajena. En cualquier caso, en el artículo de hoy vamos a compartir 8 consejos para ser un programador más productivo. Todo consiste en usar el sentido común y retirar los obstáculos que te impiden trabajar al 100% de tus capacidades.

Los programadores en términos generales tenemos ingresos superiores a la media si nos comparamos con otros puestos de la oficina con igual experiencia y nivel de formación y en muchos lugares escasean los buenos programadores. No hace falta señalar que debido al coste por hora de un programador, tiene sentido que hagamos un esfuerzo por mejorar nuestra productividad.

#1: Minimiza las distracciones

La mayoría de nuestros superiores son conscientes de que la programación es un trabajo que requiere largos periodos de concentración continua. Sin embargo, de lo que no se dan cuenta es que nos hacen la vida más difícil si no nos dejan centrarnos en nuestro trabajo. Las distracciones vienen de todos los colores y formas: mensajes instantáneos, emails, solicitudes de informes del estado del proyecto, ruidos, conversaciones tontas, etc… La lista tiende a infinito. ¿Qúe podemos hacer?

Puedes hablar con tus superiores y pedirles que se cambie la forma de comunicación. Llamadas y conversaciones en persona para temas críticos, y que te dejen tener el email y la mensajería instantánea desactivada en las horas centrales del día. El lugar de trabajo es importante. Lo ideal es tener espacios aislados de ruidos para cada equipo de programación. Por último, fijar días concretos para la entrega de informes y no a petición del superior.

#2: Maximiza el tiempo trabajando

Las jornadas laborales duran 8 horas y no solo depende de ti optimizarlas. Tu jefe igual se piensa que vas a ser más productivo trabajando más de 8 horas diarias programando. Si te fijas, muchas de esas 8 horas son horas tiradas. Reuniones, por ejemplo. No solo es el tiempo de la reunión, pero el tiempo que destinas a preparar las reuniones, ir de puesto a la reunión, cortar lo que estás programando, volver y retomarlo en el punto que te habías parado, y así sucesivamente. Una reunión de 30 minutos puede llegar a consumir hasta 60 minutos de tiempo efectivo. Si hablas con tus compañeros y tus responsables seguro que se pueden sacar varios agujeros negros de pérdida de tiempo. Ten claro desde ya que tu trabajo programando al 100% es de 6 horas diarias. Destina las otras dos a otras cosas y organízate con tu responsable.

#3: Mantente sano física y mentalmente

Una buena salud mental y física son esenciales para trabajadores efectivos. No eres muy útil para el trabajo si estás estresado. Una mala condición física hace más difícil estar alerta y cómodo en un ambiente de oficina. Es importante marcarse unos objetivos y priorizarlos en este aspecto. Si para ser más productivo tienes que entrenar por la mañana y llegar un poco más tarde, busca la flexibilidad de tu empresa. Si luego un día te tienes que quedar un poco más, se flexible con tu empresa. También es interesante tener en la máquina expendedora otras bebidas que no sean cafés y refrescos. Si te sientes estresado o un poco quemado da la voz de alarma antes de que la situación vaya a peor.

#4: Deja de martillar clavos con destornilladores

Hay algo en el mundo de los programadores de software que nos hace pensar que todas las herramientas son gratis. Mucho de esta cultura también se ha trasladado a los jefes. Quizás es por la abundancia de herramientas de código abierto gratuitas… Pero no se puede insistir en que con este tipo de herramientas se puede hacer de todo, ya que esto muchas veces va en detrimento de tu propia productividad y de la de tus compañeros.

Si necesitas la versión completa de un software, pídela sin miedo. Dile a tus superiores que la compren. Muchas de las herramientas más productivas, como Velneo, no son gratis, para lo bueno y lo malo. Hay pocas herramientas en el mercado que cuestan más que el sueldo de una semana de un desarrollador, pero muchas veces el uso de software equivocado o limitado te hace perder semanas de desarrollo. De vez en cuando hay que comprar software para rematar las tareas de programación. Acostúmbrate a pedir herramientas. Eres el profesional y tienes que hacer de consultor con los superiores si quieres sacar los desarrollos en plazo.

#5: Programa, solo programa

Hace unos años tenía que reservar un vuelo para ir a un curso de programación. Me tiré 10 minutos buscando el vuelo a un precio que me parecía razonable. A mi superior no le gustó el precio y me dijo que buscara otro vuelo. Me tiré un día y medio buscando un precio más razonable para terminar ahorrando 50€. Me tirñe 12 horas de trabajo como programador buscando un vuelo. ¿La moraleja? Déjame programar. Todo lo que se salga de mi descripción de puesto es por definición una pérdida de tiempo. Si tienes que volar a un curso, que otros en la empresa se encarguen de buscarte el vuelo.

#6: Ten las especificaciones del proyecto muy claras

Todo proyecto de desarrollo empieza con alguna que otra especificación :) Las especificaciones malas o confusas termina siempre en horas de trabajo perdidas ya que al final tienes que volver a consultar y solicitar nuevas especificaciones. Si tienes dudas, pregunta. Las especificaciones siempre por escrito para poder volver a ellas siempre que se necesite. Con un proceso de definición de proyecto te ahorras decenas de horas al año.

A los programadores nos gustan los argumentos razonados. Si me das unas indicaciones ilógicas me pongo nervioso y reacio a seguir. Las indicaciones tienen que tener sentido para ti. Yo personalmente ODIO reprogramar cosas.

#7: Fíjate en tu actitud y cuida de tus seres queridos

Esto no solo sirve para programadores. La actitud que muestras en el trabajo revierte en la forma en la que te tratan los demás. Si tienes una buena actitud, tus compañeros trabajaran mejor para ayudarte. Si tienes una actitud mejorable, salen siempre luchas internas y el rendimiento personal se ve afectado. Así de simple.

No te olvides de tu familia, de las personas que quieres. Es muy importante estar contento fuera del entorno de trabajo para tener una buena actitud en la oficina y en la vida en general.

#8: Formación continua

Una de las quejas más habituales de mis compañeros de profesión es que sus jefes no invierten lo suficiente en su formación continua, aspecto vital para tener una carrera longeva como programador con tanta innovación cada año. Como programador se espera de ti que aprendas cosas constantemente de forma autodidacta. Pero a la hora de la verdad nunca hay ni tiempo ni ganas. Como resultado nos tenemos que pegar unos atracones descomunales con tecnologías nuevas a la vez que las estamos usando para programar.

¿Cómo evitarlo? Busca mentores, jóvenes o mayores, da lo mismo. Los jóvenes te pueden encaminar en ese nuevo lenguaje que tanto bum tiene, mientras que los mayores te enseñan a trabajar mejor en general. Solicita asistir a cursos. El NO ya lo tienes sentado detrás de la pantalla. Tienes que buscar momentos de menos carga de trabajo para asistir a cursos y centrarte solo en eso. Tu empresa y tu carrera profesional te lo agradecerá a la larga.

Este artículo 8 consejos para ser un programador más productivo es original de Velneo.

Consejos prácticos para programadores

En los últimos 12 meses hemos procurado desde el blog de Velneo publicar artículos dirigidos a ofrecer consejos prácticos para programadores. En este post hago una recopilación de los mismos.

consejos hacer software

El hecho de que te cueste programar y desarrollar software al principio es lo que realmente te puede impedir que te conviertas en un buen programador. Personalmente mi experiencia me dice que el hecho de programar y picar código, y el diseño de aplicaciones le cuesta mucho a un programador medio. Se debe a que la mayoría en su día a día en el trabajo no pican el código suficiente ni realizan muchos desarrollos. Por cierto, hay una gran cantidad de consejos para ser mejor programador pero yo me ciño a mi lista, la cual sigo y me ha ayudado siempre: 10 consejos para mejorar destrezas de programación y ser mejor desarrollador.

Si siempre te han interesado los ordenadores, te encantan tanto los sistemas de software complejos como las nuevas tecnologías y quieres llegar a ser un buen desarrollador de softwaret, te vamos a ayudar y te dejamos aquí información importante y esencial en relación con la mejora general de las habilidades como desarrollador de aplicaciones de software: ¿Cómo mejorar en mi oficio de desarrollador de software?

En múltiples ocasiones, las personas que se acercan hasta nuestra web nos plantean algunas dudas a través de alguno de nuestros canales de comunicación, bien el blog, a través de lo foros o en las redes sociales. Pensamos que es interesante compartirlas con todos pues podrían servir de respuesta a otros. Una de las preguntas más recurrentes tiene respuesta en este post: ¿Cual es el mejor programa para crear apps sin saber código?

La contratación de un desarrollador o programador senior para tu startup es un asunto de “vida o muerte”. Èsta es la persona sobre cuya visión creativa y saber-hacer tecnológico pende el éxito de tu producto. Éste es el líder que dirigirá a los ingenieros que contrates en adelante, encargado de sacar el máximo provecho de sus cualidades en busca de innovación. Y será esta persona la que determinará, mediante su habilidad y ambición, si tu producto destaca o si es solo un poco de ruido más en una escena tecnológica abarrotada de voces chillonas: 5 Formas de Encontrar un Desarrollador Senior para Tu “Startup”

Si lo que buscas son 10 consejos breves para programar de forma exitosa, puedes visitar el siguientes post: 10 claves para programar con éxito

El proceso de desarrollo de un nuevo producto de software también se conoce como SDLC -ciclo de vida del desarrollo de software- (siglas en inglés de software development life cycle) y puede considerarse una subcategoría del ciclo de vida de desarrollo de sistemas. Existen varios modelos de SDLCs y se pueden estandarizar bajo la ISO/IEC 12207, la cual enumera todas la tareas que deben formar parte del desarrollo y mantenimiento de software. El ciclo de vida del desarrollo de software

Este artículo Consejos prácticos para programadores es original de Velneo V7.