{:en}This article is shared by:


#Business Intelligence #Product Management

This article is for you, the plucky entrepreneur with an app idea in your heart and a bit of cash in the bank. The diagrams that you’ve scribbled on cocktail napkins will disrupt the entire world, and dump trucks full of money have already been dispatched to your house. To ensure that they arrive on time, here’s some simple advice for making your production cycle run smoothly.

Why You Need A Project Manager In The First Place

“Computer programs are the most complex things that humans make”, says Douglas Crockford. You may not have heard that name before, but he’s pretty famous for a programmer. He’s currently a senior software architect at Paypal, and he has pioneered all sorts of cool technology that is beyond the purview of this article. He is someone who knows a great deal about working on large projects.

As for myself, I’ve been programming for 13 years, and even now, at some point, every project takes me into uncharted territory. There are so many different technologies out there, and new techniques are being devised at such an alarming rate that I never feel I’m completely on top of what’s going on. While every project has its unique challenges, there are some constants:

Clearly, we need a babysitter. Someone has to step in to establish the ground rules, keep everyone honest and make sure that we’re not forgetting anything important. Someone has to facilitate communication between all parties.

This someone, this hero, is the project manager.

The hero of our tale, the product manager!

Why is the product manager in a box? He’s a cat. Cats love boxes.

Toptal did not offer contracts with project managers when I began writing this article, but they do now. Synergy! I can only imagine that the powers that be read the following advice and realized that they were missing a great opportunity.

Why A Programmer Does Not Make A Good Project Manager

Certification by the Project Management Institute aside, the most important thing that a project manager can bring to the table is experience. As a result, many programmers would make pretty decent project managers; we have more experience with technical projects than anyone else and our analytical minds are adept at cataloguing information and setting concrete goals.

Goodness knows, you’re paying us enough, so it seems reasonable to expect that we could manage ourselves rather than force you to pay for someone else’s time as well, right?

Well, for starters, you’re paying us to code.

When we come out of our programming daze to make decisions about what to prioritize, or to argue about how much is actually going to get done this week, code is not being written. It then takes at least 10 minutes to get back into “the zone”, especially if we’re stressed out by the conversation that we just had, which is likely if we’re arguing feature priority. Boo hoo, I know, but this is all about making the most efficient use of costly resources.

Most importantly, we really can’t see the forest for the trees. If you take nothing else away from this article, please understand this: When I spend all day staring at a few specific bugs, my brain loses track of the bigger picture.

My brain rewards me when I fix those bugs, and I assume that I’ve done great things and can go play video games now. When someone reminds me that the home page is still broken, it comes as a complete surprise because I have spent the day filling my brain with very detailed knowledge of a very small piece of the overall project and sort of forgot about the rest of it. That’s just how my brain works, and a lot of other programmers have a similar psychological make up.

Grumpycat the programmer does not make a good project manager.

When we come out of our programming daze to make project decisions, code is not being written.

Why A Client Does Not Make A Good Project Manager

Well then, if we programmers don’t want to take the responsibility for getting project managerial things done, then it must fall to you, the client. It’s your money. It’s your vision. You’re ultimately responsible for the whole thing, anyway.

You, however, also have a lot on your plate.

Many clients are mere mortals with day jobs like the rest of us, and some have even been known to suffer from procrastination or forgetfulness. Although this certainly does not describe you, please entertain the idea of having a Professional Rememberer around so that you can get back to the important work of keeping the whole project alive.

If you have worked on, or overseen, a technical project of similar scope, you may indeed make a good manager for your project. If you have not, please don’t underestimate the value of someone who can predict the issues that may arise. Time estimates are always just estimates, and bugs tend to pop up at the least opportune times. It’s worth the cost of another (if only part-time) employee to have someone around who knows which parts of the process need, or are likely to need, the most attention.

Take quality assurance (QA) for example. Proper QA is essential for getting what you want out of any project, and it never ever gets the attention that it deserves. A good project manager will make the most of limited QA resources, and also quality-assure your programmers for you. Sometimes, we get out of our depth, and sometimes we make mistakes. You need a technically-proficient person in a supervisory role to determine whether your programmer is just having an off day, or if he or she is, in fact, a bad fit for the project. Heading off personnel problems early could mean the difference between life and death for your project.

Lastly, even you, oh glorious client, sometimes need a little check and/or balance. That’s hard for me to write since we computer programmers are not well known for our outspoken natures. Suffice to say, I have worked on many projects where the client was adamant that everything was top priority and absolutely everything needed to get done. While I have no doubt that this was absolutely true, these clients, sadly, did not have control over the number of hours in a day. They did not end up with the positive result they desired and/or deserved, and I feel that this outcome could have been avoided had the client entrusted a project manager with the authority to assess the workload and tactfully, yet firmly, keep things in check. It’s difficult to make the dispassionate judgment calls that most technical projects require when it’s your idea and your money on the line and the computer doesn’t care if you or I cry and scream at it. (I know this to be true because I’ve tried it many times.)

An Incomplete List Of Techniques For Managing A Technical Project

Whether you’ve decided to ignore the previous 1,000-something words and manage your project yourself, or whether you are going to hire someone but want to be more knowledgeable about the process, this list will help you. I have never (officially) been a project manager, so I can’t say which tools any given project manager would use, but I’ve had good success with all of these techniques:


When beginning a new project, most people intuitively know that it’s important to split the project into slightly-more-manageable chunks, with each chunk ranging from a couple of weeks to a couple of months worth of work. At the beginning of the project, it’s good to have a kick-off meeting to establish these milestones. It’s OK to be a little vague on how you’ll reach them, the most important thing is to keep checking in after each milestone so as to benefit from everyone’s enhanced understanding of the project, and to make sure that the project’s milestones are still (roughly) the same size as initially believed.

Time Estimates

We programmers absolutely detest estimates because we know they will be wrong and we know they will be used against us. It’s OK that they’re wrong because, by definition, they’re based on a handful of unknowns. It’s also OK that they’re used against us because our jobs are pretty cushy and it doesn’t hurt to have the whip cracked every now and again.

So feel free to ask for estimates every time work begins on a new milestone. You should expect a line or two for each major feature along with a rough estimate of how long that feature will take. I usually make an optimistic estimate, then double it. More often than not, this extra time accounts for unseen pitfalls.

User Stories

User stories are brief descriptions of a single piece of functionality within the app. They are useful as a record of important features and should be bite-sized, able to fit on an index card and often accompanied by a little drawing. More importantly, they serve as a bridge between what the client wants and what the programmer has to tell the computer. They are simple enough for you, the client, to knock out in a couple of minutes, but detailed enough for us, the programmers, to sink our teeth into.

For some quick info on user stories, I found these tutorials by Mountain Goat Software and Roman Pichler to be high-quality and succinct. For more information on the entire philosophy of “Agile Project Management”, try this Toptal blog post The Ultimate Introduction To Agile Project Management by Paul Barnes

Compositions (mock-ups)

This is not an article about why you need a designer because I feel like most clients already understand that, but it bears repeating because you will see enormous productivity gains if you slap a concrete, well-considered design in front of your programmers. Every time we have to make a design decision we have to leave “the zone,” and every time we have to go back and change something because we weren’t provided with the final draft, well, you do the math… I’m not complaining because design is fun, but in my experience, this is the No. 1 source of avoidable, extra billable hours.

Most designers provide compositions, also known as comps, in Adobe Photoshop, Adobe Illustrator, or Sketch. If you are doing it yourself, you can use one of the countless online tools such as Balsamiq or InVision. The comp doesn’t have to have the same colors and styles as the finished product (since these can be easily changed later), but please take extra time to ensure that all UI elements are present and accounted for.

Stand-Up Meetings

Long meetings are sometimes unavoidable, but you really don’t want to overload your programmers or take up more of their time than is necessary. I’ve had clients who seemed to expect me to remember everything that was said during a two-and-a-half hour meeting; they were sorely disappointed. A stand-up meeting is generally limited to 15 minutes, and it’s customary to stand for the duration. The standing aspect is supposed to ensure that everyone is participating, as well as to keep the meeting short.

During stand-ups, everyone goes around in a circle to provide a brief status report, keeping all team members up-to-date on each others’ progress. You can find more about stand ups at ExtremeProgramming.Org. If you all work remotely and don’t want to get everyone on Skype every day, you could try a fun tool such as 15Five as an alternative to stand-ups. 15Five lets team members provide their input whenever it’s convenient for them, and it will prompt them with survey questions to tease out more in-depth responses.

Ticketing System

While anyone can maintain a system of sticky notes and Google Docs (with everyone’s tasks highlighted in different colors), it’s really not necessary; plenty of people have tried to solve this problem for you. Basecamp and Trello are famed for their ease-of-use, while Pivotal tries to encapsulate the whole “agile” philosophy into a very slick package. Whatever your choice, a good ticketing system will allow you, at minimum, to:

When a project manager shows you 40 bright red top-priority tickets all due on the same day, you will truly understand the value of this bird’s-eye view of the project.

Glassescat the client does not make a good project manager.

You don’t have to use sticky notes to track open bugs.

Source Control

You may never even look at the code in your project’s version control system, but source control (or versioning) is one of the most important tools at our disposal, the greatest backup system imaginable.

Most modern projects use Git, although sometimes you’ll run into Subversion (SVN) when working on projects that have been around for a while. Github allows you to host unlimited public repositories for free (plus, it contains most of the world’s open-source projects), while Bitbucket allows you to host unlimited private repositories and is therefore the favored choice for commercial projects.

Whichever version control system you choose, it stores our code remotely in case anything happens, plus tracks each time we “commit” code to it while forcing us to write a little message describing what we were working on. This prevents different developers from overwriting each other’s code, it lets us see all changes that were made over a given time period, and it lets us create new code branches to store features that aren’t going live right away. It even has a command called “blame” that shows who was responsible for a given line of code, and when it was committed.

Test-driven Development

This is a relatively expensive practice, which means it’s not frequently employed in projects where the budget is limited to a couple of freelancers. So you, as a start up, shouldn’t feel too bad for not doing this, but I must dangle the idea in front of you because it provides the ultimate defense against bugs. Basically, your programmers spend additional precious hours writing tests (small code blocks) that ensure certain parts of the app behave in specific, predictable and repeatable ways. For example, I might write a test asserting that when the “login” button is clicked, a popup opens with a username field in it.

The beauty of tests is that once I’ve written them, I can run them all with a single command. If I have 200 tests written, I can run them after releasing a new version of the app to make sure that no bugs have been introduced into any of those 200 features. It’s not perfect, but it’s as close as we can get to guaranteeing bug-free (bug-lite, at least) apps.


That’s about all I know about project management. I’m not sure how much of this would pass muster over at the Project Management Institute, but it’s all stuff that I’ve picked up by working on web projects over the course of the last decade. Of course, I recommend that you hire someone in order to get the benefit of his or her experience, but I hope you find this information helpful even if that’s not something that you’re able to do. You will be the ultimate authority on this project, so the more you understand about its inner workings, the more likely you are to lead it to victory.{:}{:es}Éste artículo es compartido por:


#Business Intelligence #Product Management

This article was originally written in English

Este artículo es para ti, un empresario valiente con una idea para una aplicación en tu corazón y un poco de dinero en el banco. Los diagramas que has garabateado en servilletas interrumpirán en el mundo entero, y camiones llenos de dinero ya han sido enviados a su casa. Para asegurar que lleguen a tiempo, aquí hay algunos sencillos consejos para hacer que tu ciclo de producción funcione sin problemas.

La Razón por la que Necesitas un Gestor de Proyectos

“Los programas de computadoras son las cosas más complejas que los seres humanos crean”, dice Douglas Crockford. Puede que no hayas oído ese nombre antes, pero para un programador es bastante famoso. Él es actualmente arquitecto de software senior de PayPal, y ha sido pionero en todo tipo de tecnología de vanguardia que está más allá del alcance de este artículo. Es alguien que tiene mucho conocimiento acerca de cómo trabajar en grandes proyectos.

En cuanto a mí, he estado programando desde hace 13 años y todavía hay momentos en que cada proyecto me lleva a un territorio desconocido. Hay muchas tecnologías diferentes, al igual que nuevas técnicas que se están diseñando a un ritmo tan alarmante, que nunca siento que estoy completamente al tanto de lo que está pasando. Mientras que cada proyecto tiene sus desafíos únicos, hay algunas constantes:

Obviamente, necesitamos una niñera.Alguien tiene que intervenir para establecer las reglas de juego, mantener a todos honestos y asegurarse de que no estamos olvidando algo importante.Alguien tiene que facilitar la comunicación entre todas las partes.

Esta persona, este héroe, es el Gestor de Proyectos (Project Manager).

The hero of our tale, the product manager!

¿Por qué el gestor de producto está en una caja? Él es un gato. Los gatos aman las cajas.

Toptal no ofrecía contratos con gestores de proyectos cuando empecé a escribir este artículo, pero ahora si lo hacen (Toptal Projects). ¡Sinergia! Sólo puedo imaginar el poder que trajo el leer los siguientes consejos y se dieron cuenta que estaban perdiendo una gran oportunidad.

La Razón por la que un Programador no es un buen Gestor de Proyectos

Poniendo de lado la Certificación por el Instituto de Gestión de Proyectos (Project Management Institute), lo más importante que un Gestor de Proyectos puede traer a la mesa es la experiencia. Como resultado, muchos programadores serían gestores de proyectos bastante decentes; tenemos más experiencia que nadie con proyectos técnicos y nuestras mentes analíticas son expertas en la catalogación de información y el establecimiento de objetivos concretos.

Claramente nos estás pagando suficiente por lo que es razonable esperar que nos podamos gestionar nosotros mismos diferentes tareas en lugar de forzarte a pagar por el tiempo de otra persona también, ¿verdad?

Bueno, para empezar, nos estás pagando para codificar.

Cuando salimos de nuestro estupor de programación para tomar decisiones sobre qué priorizar, o para discutir sobre la cantidad de trabajo que en realidad se hará ésta semana, el código se deja de escribir. Después de esto, toma al menos 10 minutos para volver a “la zona”, sobre todo si estamos estresados ​​por la conversación que acabamos de tener, que es probable, sobre todo si estamos discutiendo sobre la prioridad de las funciones. No es gran cosa, lo sé, pero todo esto se hace para lograr hacer un uso más eficiente de los recursos costosos.

Lo más importante es que enfocarse en los detalles no permite apreciar el entorno general. Si este artículo no te deja nada, solo trata de entender esto: Cuando me paso todo el día mirando algunos bugs específicos, mi cerebro pierde de vista el panorama más grande.

Mi cerebro me recompensa cuando arreglo esos bugs, y supongo que he hecho grandes cosas y ahora puedo ir a jugar videojuegos. Cuando alguien me recuerda que la página de inicio todavía no funciona, llega como una completa sorpresa porque he pasado todo el día llenando mi cerebro con un conocimiento muy detallado de una pieza muy pequeña del conjunto del proyecto, y me olvide de lo demás. Así es como funciona mi cerebro, y muchos otros programadores tienen una estructura psicológica similar.

Grumpycat the programmer does not make a good project manager.

Cuando salimos de nuestro estupor de programación para tomar decisiones, el código se deja de escribir.

La Razón por la que el Cliente no es buen Gestor de Proyectos

Pues bien, si nosotros los programadores no queremos tomar la responsabilidad de hacer cosas de gestión de proyectos, entonces la responsabilidad te queda a ti, el cliente. Es tú dinero.Es tú visión.De todas formas, tú eres el responsable de todo esto.

Sin embargo, también tienes mucho qué hacer.

Muchos clientes son simples mortales con trabajos diarios, como el resto de nosotros, y algunos incluso sufren de procrastinación u olvido. Aunque esto ciertamente no te describe a ti, por favor, considera la idea de tener un Professional Rememberer (Recordador Profesional) alrededor, de modo que puedas regresar a la importante labor de mantener el proyecto con vida.

Si has trabajado en, o supervisado, un proyecto técnico de alcance similar, tal vez sí seas un buen gestor para tu proyecto. Si no es así, por favor, no subestimes el valor de alguien que puede predecir los problemas que puedan surgir. Las estimaciones de tiempo son siempre sólo estimaciones y los bugs tienden a aparecer en los momentos menos oportunos. Vale la pena el costo de otro (aunque sólo sea a tiempo parcial) empleado, alguien que sepa qué partes del proceso necesitan, o pueden llegar a necesitar, la mayor atención.

Haz control de calidad, por ejemplo. Un control de calidad adecuado es esencial para conseguir lo que quieres de cualquier proyecto, y esto nunca recibe la atención que merece. Un buen Gestor de Proyectos sacará lo mejor de los recursos limitados de un control de calidad y también asegura la calidad de tus programadores para tu seguridad. A veces salimos de nuestra profundidad y a veces cometemos errores. Se necesita una persona técnicamente competente en un papel de supervisión para determinar si tu programador está teniendo un mal día, o si él o ella son, de hecho, una mala adición para el proyecto. Corregir problemas de personal desde el comienzo podría hacer la diferencia entre la vida y la muerte para tu proyecto.

Por último, incluso tú, oh glorioso cliente, a veces necesitas un poco de verificación y / o equilibrio. Eso es difícil para mí de escribir, ya que nosotros, los programadores no somos bien conocidos por nuestra franqueza al hablar.Basta con decir que he trabajado en muchos proyectos en los que el cliente estaba convencido de que todo era de primera prioridad y absolutamente todo era necesario que se lograra. Aunque no tengo ninguna duda de que esto era absolutamente cierto, estos clientes, por desgracia, no tenían control sobre el número de horas en un día. Ellos no obtuvieron el resultado positivo que deseaban y/o merecían, y siento que este resultado pudo haber sido evitado si el cliente hubiese dado a un Gestor de Proyectos la autoridad para evaluar la carga de trabajo y con mucho tacto, pero con firmeza, mantener las cosas bajo control. Es difícil tomar las desafortunadas decisiones a juicio personal que requieren la mayoría de los proyectos técnicos, cuando es tu idea y tu dinero en juego y a la computadora no le importa si tú o yo lloramos y le gritamos a ella. (Sé que esto es cierto porque lo he intentado muchas veces).

Una Lista Incompleta de Técnicas para la Gestión de un Proyecto Técnico

Ya sea que hayas decidido hacer caso omiso a las más de 1.000 palabras anteriores y quieres gestionar tu proyecto por ti mismo, o si vas a contratar a alguien, pero deseas tener más conocimientos sobre el proceso, ésta lista te ayudará. Nunca he (oficialmente) sido Gestor de Proyectos, así que no puedo decir qué herramientas utilizaría cualquier Gestor de Proyectos, pero he tenido buen éxito con todas estas técnicas:


Al comenzar un nuevo proyecto, la mayoría de las personas saben intuitivamente que es importante dividir el proyecto en trozos ligeramente más manejables, cada trozo podría ir desde un par de semanas a un par de meses en términos de trabajo. Al comienzo del proyecto, es bueno tener una reunión inicial para establecer estas milestones o puntos específicos. Está bien ser un poco vago en cómo se va a llegar a alcanzarlas, lo más importante es supervisar después de cada etapa, con el fin de beneficiarse de la comprensión del proyecto, mejorada, de todo el mundo y para asegurarse de que las etapas del proyecto son todavía (más o menos) del mismo tamaño que inicialmente se creía.

Las Estimaciones de Tiempo

Nosotros los programadores detestamos absolutamente las estimaciones, porque sabemos que van a salir mal y que serán utilizadas en nuestra contra. Está bien que estén mal, ya que, por definición, están basadas en un puñado de enigmas. También está bien que se usen en nuestra contra, porque nuestro trabajo es bastante cómodo y no se pierde nada con sentir algo de presión de vez en cuando.

Así que no dudes en preguntar por las estimaciones cada vez que se comienza el trabajo de una nueva etapa. Debes esperar una explicación de una o dos líneas por cada característica importante, junto con una estimación aproximada de cuánto tiempo tomará esa característica. Normalmente suelo hacer una estimación optimista, para después duplicarla. Muchas veces, este tiempo extra se le dedica a los obstáculos invisibles.

Historias de Usuario

Las historias de usuario son breves descripciones de una sola pieza de funcionalidad dentro de la aplicación. Son útiles como un registro de las características importantes y deben ser del tamaño de un bocado, capaz de encajar en una ficha y, a menudo, acompañado de un pequeño dibujo. Más importante aún, sirven como un puente entre lo que el cliente quiere y lo que el programador tiene que decirle a la computadora. Las historias son lo suficientemente simples para que tú, el cliente, puedas entender en un par de minutos, pero lo suficientemente detalladas para que nosotros, los programadores, podamos sacarle el mejor provecho.

Para alguna información rápida en historias de usuario, me pareció que estos tutoriales de Mountain Goat Software y Roman Pichler, son de alta calidad y concisos. Para obtener más información sobre toda la filosofía de “Agile Project Management”, prueba este blog post de Toptal The Ultimate Introduction To Agile Project Management, de Paul Barnes.

Composiciones (Mock-ups)

Esto no es un artículo sobre por qué necesitas un diseñador, porque siento que la mayoría de los clientes ya entienden eso, pero vale la pena repetirlo porque verás enormes ganancias de productividad si le muestras a tus programadores un diseño bien planeado y concreto. Cada vez que tenemos que tomar una decisión de diseño tenemos que salir de “la zona”, y cada vez que tenemos que regresar y cambiar algo, porque no se nos proporcionó el borrador final, bueno, saca la cuenta… no me estoy quejando, porque el diseño es divertido, pero en mi experiencia, esta es la fuente Nº 1 de horas facturables adicionales que se pueden evitar.

La mayoría de los diseñadores proporcionan composiciones, también conocidas como “comps” en Adobe Photoshop, Adobe Illustrator o Sketch. Si lo estás haciendo tú mismo, puedes utilizar una de las innumerables herramientas en línea como Balsamiq o InVision. El comp no tiene que tener los mismos colores y estilos como el producto terminado (ya que estos se pueden cambiar fácilmente más adelante), pero por favor toma un tiempo extra para asegurarte de que todos los elementos de interfaz de usuario están presentes y verificados.

Reuniones Stand-Up

Las reuniones largas a veces son inevitables, pero no sobrecargues a tus programadores ni tomes más tiempo del que sea necesario. He tenido clientes que parecían esperar que me acordara de todo lo que se dijo durante una reunión de dos horas y media; estaban muy decepcionados. Una reunión stand-up se limita generalmente a 15 minutos, y se acostumbra a estar de pie durante ésta. El hecho de estar de pie se supone que debe garantizar que todo el mundo participe, así como para mantener la reunión corta.

Durante stand-ups, todo el mundo se mueve en un círculo para proporcionar un breve informe sobre la situación, manteniendo a todos los miembros del equipo al día sobre el progreso de los demás. Puedes encontrar más información sobre soporte de UPS en ExtremeProgramming.Org. Si todos trabajan a distancia y no quieres reunirte en Skype todos los días, podrías usar una herramienta divertida como 15Five, como una alternativa a stand-ups. 15Five permite a los miembros del equipo proporcionar su opinión siempre que sea conveniente para ellos, y les hará preguntas de encuesta para generar respuestas más profundas.

Ticketing System

Si bien cualquier persona puede mantener un sistema de notas adhesivas y Google Docs (con las tareas de cada uno resaltadas en diferentes colores), no es realmente necesario. Muchas personas han tratado de resolver este problema por ti. Basecamp y Trello son famosos por su facilidad de uso, mientras que Pivotal intenta encapsular toda la filosofía “ágil” en un paquete muy sofisticado. Sea cual sea tu elección, un buen ticketing system te permitirá, como mínimo:

Cuando un Gestor de Proyectos te muestra 40 tickets de máxima prioridad de color rojo brillante que se deben entregar en el mismo día, realmente vas a entender el valor de esta visión del proyecto.

Glassescat the client does not make a good project manager.

No tienes que utilizar notas adhesivas para realizar un seguimiento de bugs.

Control de Versiones

Tal vez ni siquiera llegues a mirar el código en el sistema de control de versiones de tu proyecto, pero el control de versiones (o versionado) es una de las herramientas más importantes de las cuales disponemos, el mayor sistema de copia de seguridad imaginable.

La mayoría de los proyectos modernos usan Git, aunque a veces te encontrarás con Subversion (SVN) cuando trabajes en proyectos que han salido al público desde hace un tiempo. Github permite alojar un número ilimitado de repositorios públicos de forma gratuita (además, contiene la mayor parte de los proyectos de código abierto del mundo), mientras que Bitbucket permite alojar repositorios privados ilimitados y por lo tanto es la opción favorita para los proyectos comerciales.

Cualquiera que sea el sistema de control de versiones a elegir, éste almacena nuestro código de forma remota en caso de que algo suceda, además de un seguimiento cada vez que “comprometemos” el código, al mismo tiempo que nos obliga a escribir un pequeño mensaje que describe en que estábamos trabajando. Esto evita que distintos desarrolladores sobrescriban el código de cada uno, nos permite ver todos los cambios que se realizaron durante un período de tiempo determinado, y nos permite crear nuevas ramas de código para almacenar características que no van a salir en vivo de forma inmediata. Incluso tiene un comando llamado “culpa” que muestra quien fue responsable de una determinada línea de código, y cuando se cometió.

Control de Versiones es lo mejor.

Desarrollo basado en pruebas

Esta es una práctica relativamente cara, lo cual significa que no se emplea con frecuencia en los proyectos donde el presupuesto se limita a un par de trabajadores freelance. Así que para comenzar, no deberías sentirte muy mal por no hacer esto, pero tengo que presentarte la idea, ya que ofrece la mejor defensa contra los bugs. Básicamente, tus programadores pasan preciadas horas adicionales escribiendo pruebas (pequeños bloques de código) para asegurar que ciertas partes de la aplicación se comporten de manera específica, predecible y repetible. Por ejemplo, podría escribir una prueba asegurando que cuando se hace clic en el botón de “inicio de sesión”, una ventana emergente se abre con un campo de nombre de usuario en el mismo.

La belleza de las pruebas es que una vez que las he escrito, puedo ejecutarlas a todas con un solo comando. Si tengo 200 pruebas escritas, las puedo ejecutar después de lanzar una nueva versión de la aplicación para asegurarme de que ningún bug se ha introducido en cualquiera de las 200 características. No es perfecto, pero es lo más cercano que podemos llegar a garantizar aplicaciones libres de bugs (bug-lite, por lo menos).

Para Cerrar

Eso es todo lo que sé acerca de la gestión de proyectos. No estoy seguro de cuánto de esto pasaría el examen en el Instituto de Gestión de Proyectos, pero es todo el material que he recogido mediante el trabajo en proyectos web en el transcurso de la última década. Por supuesto, recomiendo que contrates a alguien con el fin de obtener el beneficio de su experiencia, pero espero que esta información sea útil aunque no sea algo que tengas la oportunidad de hacer. Serás la máxima autoridad en este proyecto, así que cuanto más sepas acerca de su funcionamiento interno, más probabilidades hay de que lo lleves a la victoria.

Artículo via Toptal{:}

Leave a Reply

Your email address will not be published. Required fields are marked *