Esta es una historia de "cualquier parecido con la realidad es pura coincidencia", y además algunas tonterías. Por favor, no os sintáis aludidos. Aquí empieza...

Sostenía mi vaso de agua algo avergonzado, y justo enfrente estaba sentado el Sr. Wang, que había venido de visita. Es alguien que se ha labrado su camino en otros lugares; se dice que en los últimos años le ha ido bastante bien. Al ver lo floreciente que está el Internet móvil, naturalmente también pensó en entrar en este campo. Aunque el negocio del Sr. Wang tiene algo que ver con la informática, llevaba demasiado tiempo sin tocar la tecnología y no estaba muy familiarizado con ciertas cosas, así que quería consultarme a mí, un programador veterano que ha estado en el desarrollo de primera línea durante más de diez años. Tener diez o más años de desarrollo puede deberse a varias posibilidades, pero eso no es lo importante, así que ignoremos ese detalle por ahora.

La razón de mi vergüenza era que no sabía cómo responder a la petición del Sr. Wang; era como si estuviera sumido en una especie de reflexión habitual.

El Sr. Wang se levantó y me acercó su teléfono, diciendo: "Mira, una APP así." Deslizó el dedo por la pantalla varias veces sin mucha soltura. Yo no lo miré con mucha atención, porque sabía que esa pregunta era difícil; es una pregunta que les hacen a todos los desarrolladores y quizá la más frecuente: "¿Cuánto se tarda en desarrollar una APP así?" Me encantaría decir "no lo sé", que probablemente sería la respuesta más directa y precisa, pero ante el Sr. Wang, un viejo amigo, responder así sería un poco descortés. Así que, además de considerar más o menos qué aspectos implicaba la APP que señalaba, también tenía que organizar mis palabras para decirle de manera muy diplomática que no podía calcular eso. "Mira, es una APP así de simple", el Sr. Wang siguió tocando la pantalla unas cuantas veces y luego me miró con una expresión de cierta expectativa.

Dije con cautela: "Francamente, no puedo decirlo con seguridad. No tengo mucha experiencia en este aspecto. Aunque he hecho desarrollo de APPs, esto es muy diferente. Hay que analizar bien toda la lógica para poder estimar el tiempo."

El Sr. Wang pareció no estar de acuerdo con lo que dije. Movió el teléfono y dijo: "No pido mucho, de hecho es más simple que esto". Señaló ciertas partes de la pantalla y continuó: "Esto, esto y esto pueden quitarse. Solo necesito una lista así, con detalles que se puedan ver y modificar..."

En mi interior pensé naturalmente que era la típica actitud de "creer que es simple sin más". Pensé que debía hacerle ver la complejidad del problema, así que le pregunté a mi vez: "¿Necesita inicio de sesión?"

El Sr. Wang hizo una pausa breve y dijo: "Por supuesto."

"¿Qué tipo de inicio de sesión? ¿Con usuario y contraseña, o con número de teléfono, o un inicio de sesión de terceros como QQ, Weibo o WeChat que se pueda aprovechar?"

Esta vez el Sr. Wang pareció pensarlo un poco: "Siendo Internet móvil, creo que el inicio de sesión con teléfono es imprescindible. QQ, Weibo, ah, y WeChat, también sería mejor tener WeChat... Ah, lo que dijiste antes de usuario y contraseña, eso también debería estar, ¿no?"

Continué preguntando con fluidez: "Entonces tiene que haber registro. Si piensas usar inicio de sesión con teléfono, necesitas una plataforma de SMS. Para el inicio de sesión con WeChat, primero tienes que completar la verificación de identidad de la empresa. Ah, y si hay inicio de sesión y contraseña, también debería existir la función de recuperar la contraseña."

"Eso seguro."

"Al haber múltiples formas de inicio de sesión, tienes que idear una lógica razonable para 'integrarlas'. Lo más común es, por supuesto, la vinculación de cuentas; por ejemplo, vincular un número de teléfono a tu cuenta, de modo que puedas usar el número de teléfono para acceder a la misma cuenta. Lo mismo aplica para el inicio de sesión con WeChat. Pero hoy en día los usuarios de Internet móvil detestan los procesos de registro, por lo que a menudo exigen iniciar sesión directamente con el teléfono o con WeChat, completando el registro automáticamente. Considerando este caso, si un usuario primero inicia sesión con WeChat y luego con el teléfono, sin vincularlos, se crearían dos cuentas distintas que no se pueden 'integrar'. Tenemos que idear una solución bastante completa..."

El Sr. Wang parecía un poco impaciente con lo que decía: "No hace falta que sea tan complicado, ¿no? Mira esta APP, ¿no tiene ya todo esto?"

"¿Has probado si tiene el problema que describí antes?"

Pero al Sr. Wang no parecía importarle el problema; solo quería saber cuánto tiempo se tardaba en hacer una APP así y, por supuesto, cuánto costaba, que también era algo que le preocupaba. Con un tono de gran confianza, dijo: "¿Qué importa si hay problemas? ¿Qué son las dificultades? Estoy seguro de que todo esto se puede resolver. Pero el tiempo es crucial, tiene que ser rápido; nuestros competidores no nos van a esperar. Es solo una cosa así, dime, ¿cuánto se tarda?"

Por su actitud, parecía exactamente ese tipo de hombre de éxito que prospera en los negocios, y yo, un programador de humilde posición, realmente no tenía forma de hacerme oír ante él. Iba a seguir hablándole de la importancia de los detalles, pero me interrumpió: "No, no necesito que sea muy preciso. Solo dame un rango: ¿dos semanas? ¿O dos meses?"

Sentí que ya no tenía por qué ocultar nada: "La verdad es que no lo sé. Quizás un buen equipo podría hacerlo en dos semanas (aunque yo personalmente no creo que exista un equipo tan increíble), pero claramente yo no soy el tipo de persona que puede hacer ese milagro." Pensé para mis adentros que incluso si dijera un rango en broma como "de dos semanas a dos años", probablemente también sería incorrecto.

El Sr. Wang pareció muy decepcionado con mi respuesta. Pero es una persona con gran capacidad de ejecución; si quiere hacer algo, seguro que actúa, actúa rápido y tiene que obtener resultados. Ese estilo de hacer las cosas con decisión y rapidez, la verdad, lo admiro. Sin embargo, en este proyecto suyo, realmente no puedo ayudar. Aun así, por cortesía, le dije: "Si tienes algún problema técnico, siempre puedes venir a preguntarme."

====================== Una línea divisoria no muy elegante ======================

"¿Cuánto se tarda en hacer una APP?" Esta pregunta probablemente sea más difícil que calcular cuántos días le quedan de vida a una persona. ¿Cómo se responde a una pregunta con tan poca información?

En general, cuanto más claros sean los requisitos y más maduro sea el equipo, más preciso será el tiempo estimado. Y en el desarrollo de software, sin importar cuántos años pasen ni qué metodologías se propongan, nunca se podrá calcular las "horas de trabajo" con tanta precisión como en la manufactura tradicional, debido a las complejas relaciones lógicas internas. La ingeniería de software jamás podrá producirse en masa.

El usuario solo ve una APP. Si usa iOS, quizá nunca entre en contacto con Android, y no sabe que el desarrollador, además de la versión para iOS, también tiene que hacer una versión para Android (¿o podría haber incluso una versión para Windows? Sin duda eso sería mucho más trabajo), o quizá una versión web lo resuelva todo. Tal vez no lo pienses así después de haberlo hecho realmente. Además, ¿puede el modelo de WeChat Shop aplicarse realmente a todos los casos? Y, a menos que haya algún problema de red, el usuario común tampoco nota la existencia del servidor. El servidor siempre trabaja silenciosamente para los usuarios las 24 horas; su dificultad de desarrollo probablemente no sea menor que la de la propia APP. Y el mantenimiento de la APP requiere personal; cuando crece, incluso hay que formar un equipo profesional. Necesitan un "panel de administración" para ver y procesar datos en cualquier momento. Si necesitan ver y procesar datos desde cualquier lugar y en cualquier momento, quizá tengan que crear una APP específica para el panel.

Esta lógica es un poco similar: vemos al caza completar con elegancia su misión de destruir al enemigo en el cielo y creemos que es solo porque el caza es impresionante, ignorando a menudo todo el equipamiento de apoyo relacionado con el caza. Sin pilotos expertos, centro de mando de operaciones, radar terrestre, aviones de alerta temprana, suministros, aeropuertos o portaaviones, personal de tierra, etc., el caza perdería su capacidad de combate. Lo mismo ocurre con una APP: no es algo que se termina con solo hacer que funcione. La infraestructura que la respalda y el trabajo de mantenimiento no son en absoluto más simples que la propia APP.

Aparte de estos aspectos importantes, también hay muchas incertidumbres en los detalles, por lo que un equipo maduro es especialmente importante. Un desarrollador con experiencia sabrá, al menos aproximadamente, qué problemas encontrará en el proceso de desarrollo, cuáles son relativamente simples y cuáles pueden requerir mucho tiempo. Esto depende de la experiencia. Tengo una frase que siempre repito: ""Las cosas que no has hecho, no las califiques fácilmente de simples.""La actitud de 'creer que es simple sin más' no beneficia en nada al proyecto. Si uno no está seguro, debería consultar a alguien con experiencia en el tema; aunque no se obtenga una respuesta concreta, al menos se tendrá una dirección aproximada. Investigando en esas direcciones, se podrán conocer los problemas a los que se enfrentará, aunque por supuesto a menudo no todos."

Sobre el tema de "subestimar la dificultad", en mi antigua empresa había una historia clásica. En aquel entonces había un proyecto pequeño: se trataba de añadir soporte multilingüe a un programa que ya se usaba en un instrumento y que solo admitía inglés. El programa no era grande y el contenido implicado no era demasiado. Al principio, los ingenieros pensaron que era solo un trabajo de traducción, que como mucho se completaría en dos semanas. Pero una vez que empezaron, descubrieron que no era tan simple. Primero, la traducción debía hacerla un profesional; nosotros no podíamos hacerla bien, nadie dominaba los idiomas europeos. Luego estaba la conversión de unidades: algunos países usan el sistema métrico y otros el imperial, había que tenerlo en cuenta, incluido el formato de visualización de la fecha. De repente, no sabíamos cuánto trabajo extra había aumentado. Cuando casi estaba todo listo, descubrieron que las palabras en alemán eran demasiado largas y no cabían en la pantalla del instrumento; se salían del límite. Así que ajustaron la fuente y la simplificaron. Hubo innumerables reuniones para discutirlo. Finalmente, cuando quisieron hacer el Release, descubrieron que con esos cambios el tamaño del programa había aumentado mucho y la memoria de algunos instrumentos no era suficiente para almacenarlo. Todos se quedaron atónitos. A optimizar, a simplificar; el programa empezó a quedar bastante desordenado. Al final, a duras penas pasó la inspección del departamento de control de calidad y se publicó. Resultó que tardaron nada menos que seis meses. Pero ahora que lo pienso, una razón muy importante por la que se invirtió tanto tiempo fue la falta de experiencia; no estaban familiarizados con los idiomas y la internacionalización, y dieron muchos rodeos. Por eso mencioné antes que un equipo maduro es especialmente importante.

Al estimar el tiempo de un proyecto, a menudo solo calculamos el "tiempo de escribir código" y no incluimos el tiempo dedicado a discutir con jefes o clientes, hacer análisis de requisitos, diseño, pruebas y corregir bugs. Y todos estos tiempos juntos suelen superar con creces el tiempo de escribir código. Personalmente, no digo fácilmente un plazo corto solo para complacer al jefe. ¿Por qué? — Porque simplemente no se puede cumplir, ¿para qué mentir? Si una nueva funcionalidad requiere una semana de desarrollo, normalmente duplico ese tiempo; y eso ya es una estimación "poco conservadora".

Incluso si solo contamos el tiempo de escribir código, a menudo se subestima. Es muy probable que el jefe o el cliente no esté satisfecho con lo que desarrollas: quizá malinterpretaste sus requisitos funcionales, o la interfaz va un poco lenta, o el color del icono no es bonito. Eres desarrollador, no diseñador gráfico; aunque a duras penas puedes hacer de diseñador, al fin y al cabo no eres profesional. Y lo que es más importante, hacer diseño de UI, hacer imágenes, también requiere mucho tiempo. Cuando estás desesperado por "un píxel", ¿no ansías tener un diseñador en el equipo? En ese momento hay que recordarle al jefe: tienes que hacer concesiones entre el tiempo y las funciones. El jefe, por supuesto, se disgusta, pero no tiene más remedio que comprometerse en algunas funciones. Aunque esto permita que un proyecto que iba con dificultades salga a la luz antes, también le da al jefe una excelente excusa para el futuro fracaso del proyecto: nuestros ingenieros son pésimos, no hicieron lo que les dije.

El jefe o los clientes, además de quejarse de que lo que haces no es lo bastante bonito, plantearán muchas otras cosas: si se puede cambiar esta interfaz a selección múltiple, si se puede añadir una función de notificaciones, que debe haber estado de leído/no leído, si la interfaz puede ser más fluida, por qué el programa se "bloqueó" anoche... Los requisitos solo mencionan funciones, pero no dicen lo bonita que debe ser la interfaz, ni que la estabilidad del programa deba ser buena, y mucho menos qué throughput se debe alcanzar. Por supuesto, algo quizá más importante, la seguridad tampoco se menciona. Te sobresaltas: es cierto, si hay hackers, no, basta con que usuarios malintencionados con un poco de conocimientos técnicos quieran saturar nuestros servidores, sería facilísimo, ¡y no he tomado ninguna de estas medidas de protección! Afortunadamente, el proyecto es demasiado poco conocido, de momento no hay que considerar esto. (Parece que la mayoría de las apps no llegan a vivir para tener que considerarlo).

Todos estos, ya los llames funciones, detalles o robustez, no son cosas que crezcan solas de la tierra; requieren tiempo para pensarlas y hacerlas. Algunas incluso son una "ingeniería de sistemas". Si se intenta solucionar los problemas a parches, el sistema estará lleno de "cables sueltos", lo que sin duda dejará muchos riesgos latentes para el mantenimiento futuro. Tú, ingeniero, ¿lo has tenido en cuenta? Ni qué decir de la computadora de bajo rendimiento que el jefe te compró para ahorrar costos y que te vuelve loco todo el día, esos asuntos "sin importancia".

====================== Línea separadora no muy elegante ======================

Bien, después de despedirse de mí, el Sr. Wang registró la empresa con una rapidez fulminante, registró el dominio, consiguió la oficina y, de inmediato, reunió a un montón de gente y se pusieron manos a la obra con gran ímpetu. Ante ese impulso de desarrollo y esa energía, solo podía reconocer mi inferioridad. En el fondo sentía un poco de arrepentimiento por no haber ido a emprender con él; pero eso fue solo un instante de sentimentalismo. La razón me trajo de vuelta en los siguientes cientos de milisegundos: mejor no ir, con él era imposible entenderse.

El proyecto del Sr. Wang luego se desarrolló con un ímpetu arrollador, y hoy en día es CEO de una empresa valorada en cientos de millones. Yo, por mi parte, cada vez me siento más un Loser, sentado solo en la oficina, todavía con esa taza de agua, abatido. ¡Alto! ¿No es esto bastante dramático? Pero aunque desde el principio declaré que esta historia es "cualquier parecido con la realidad es pura coincidencia", no puedo inventarme cualquier cosa. El final real es: efectivamente, trabajaron con gran entusiasmo durante unos meses, y luego, de repente, desaparecieron sin dejar rastro. En un principio quería llamar al Sr. Wang para preguntarle qué había pasado, pero se había convertido en otra persona increíblemente ocupada, sin ánimo de charlar sobre cosas cotidianas conmigo. Bueno, el final es más o menos el mismo: sigo siendo ese programador que continúa sentado amargamente en la oficina. Ay, basta de pensar, ¡a trabajar!

Fuente: http://www.cnblogs.com/guogangj/p/4676836.html