Mi nombre es Vladimir. Estoy a cargo del desarrollo móvil en Vivid Money.
Vivid Money es una startup fintech para el mercado europeo con una amplia gama de funcionalidades: pagos y transferencias, multidivisa, análisis financiero, uso compartido de cuentas, inversiones y mucho más. Los competidores más cercanos son Revolut y N26.
Logramos hacer y lanzar con éxito una aplicación móvil de tecnología financiera en un año. Durante este año, recopilé ideas que se fueron formando en mi cabeza durante aproximadamente 4 años, mientras era líder en otros proyectos. En este artículo, estas ideas se recopilan en forma de consejos para gerentes / clientes potenciales de ingeniería de software que inician proyectos a largo plazo y a gran escala desde cero.
Introducción
Hace poco más de un año, llegué al proyecto como líder de un equipo de Android. Me enfrenté a una tarea ambiciosa e interesante: elegir tecnologías, formar un equipo, configurar procesos y, lo más importante, hacerlo todo bien. Lo bueno es un concepto vago, pero para mí es un producto de calidad desde el punto de vista técnico y de producto.
Empezar un proyecto desde cero es una tarea tan interesante y apasionante como incomprensible y difícil. Al principio no sabes a qué agarrarte, luego hay tantas cosas que hacer que todo el proceso de trabajo es como apagar incendios.
Para evitar que esto suceda, es necesario en primer lugar definir claramente las prioridades de las actividades.
En mi opinión, las principales actividades de un cliente potencial se pueden organizar en el siguiente orden:
- Construyendo el proceso de contratación;
- Seleccionar una pila de tecnología;
- Configurar la interacción del equipo;
- Construyendo un proceso de desarrollo y prueba.
En esta parte del artículo, me enfocaré solo en el primer punto.
Descargo de responsabilidad:
este artículo contiene mis pensamientos y conclusiones basados en mi experiencia de trabajo en proyectos grandes y a largo plazo. Algunos de los consejos pueden parecer trillados, pero como ha demostrado la práctica, no todos se aplican incluso en grandes empresas y proyectos.
Edificio de contratación
Para mí, este punto está en primer lugar, ya que el trabajo posterior del equipo depende de la “calidad” de las personas.
Teníamos un plazo muy ambicioso para lanzar el banco: 1 año. Durante este tiempo, fue necesario realizar cualitativamente una gran cantidad de funcionalidad. Simplemente no había tiempo para empleados dependientes y mal capacitados. Por lo tanto, sigue el siguiente consejo:
Consejo número 1. Recuerda la importancia de contratar
Además del hecho de que un desarrollador débil afecta directamente la calidad del código y la cantidad de errores en el producto, es imposible delegar en él, ya que no habrá plena confianza y se requerirá un monitoreo constante. Por tanto, surgirán dificultades en un proyecto de rápido crecimiento.
Consejo número 2. Verifique no solo las habilidades duras en una entrevista, sino también las habilidades blandas
A menudo, una entrevista de desarrollador en Rusia se reduce a preguntas de idioma / marco. De hecho, las habilidades blandas juegan un papel igualmente importante y son más difíciles de desarrollar. Además, es más probable que una persona con una mentalidad similar encaje en el equipo.
Para nosotros mismos, hemos identificado las siguientes habilidades blandas:
- Pensamiento sistemático;
- Pulcritud y perfeccionismo saludable;
- Depender de la experiencia, no de los consejos; cuestionando hechos no verificados.
Y, por supuesto, el no conflicto básico y la capacidad de comunicarse con la gente.
Por ejemplo, le hacemos una pregunta a un candidato: "¿Por qué deja su trabajo anterior y cuáles son sus criterios para elegir un nuevo trabajo?". La respuesta en sí misma no es tan importante como lo es el enfoque sistemático: esperamos que el candidato sea consciente de que no está satisfecho, que pudo llegar a esto de una manera lógica y poner todo en los estantes en su cabeza.
Ejemplos de estas preguntas que nos ayudan a comprender la mentalidad y los principios de un candidato podrían ser: "¿Cómo es su equipo ideal?" o "¿Cómo es el proceso de desarrollo ideal?"
Consejo número 3. Optimiza tu entrevista
La entrevista debe verse como un mecanismo que se puede mejorar y optimizar. O como un programa que se puede refactorizar.
Daré ejemplos de las optimizaciones que hicimos.
Ejemplo 1
Dos desarrolladores necesitan aproximadamente 1,5 horas para entrevistar a cada candidato. Para optimizar este tiempo y no desperdiciarlo en candidatos obviamente débiles, introdujimos el cribado. La evaluación consiste en algunas preguntas cerradas y simples que tienen respuestas preparadas. Los propios reclutadores le hacen estas preguntas al candidato, lo que demora entre 10 y 15 minutos.
Pocos números:
De cada 100 candidatos, después de la selección, se elimina alrededor de un tercio, es decir, unos 30. Un reclutador dedica unos 15 minutos a cada selección, es decir, aproximadamente 8 horas de tiempo neto para 30 candidatos eliminados. En una entrevista clásica para los mismos 30 candidatos, habríamos gastado unas 60 horas-hombre en el escenario más optimista.
Ejemplo 2
El propósito de la entrevista es seleccionar al candidato más relevante. Analizamos e identificamos las habilidades y habilidades críticas para el proyecto, teniendo en cuenta la pila de tecnologías seleccionadas, lo que nos permitió eliminar algunas preguntas irrelevantes y reducir el tiempo de la entrevista.
Por ejemplo, hemos eliminado las preguntas relacionadas con partes del SDK de Android que no se utilizan en nuestro proyecto: ContentProvider, JobScheduler, etc. Los SDK rara vez se utilizan.
Ejemplo 3
Inicialmente, la entrevista técnica se llevó a cabo en dos etapas separadas: preguntas teóricas y tareas prácticas. Esto aumentó enormemente el tiempo para pasar todas las etapas de la entrevista para el candidato, y muchos postulantes se perdieron, ya que el mercado de TI es muy competitivo: los buenos desarrolladores obtienen ofertas rápidamente.
Para optimizar el embudo, colapsamos la entrevista en la etapa 1: eliminamos preguntas poco informativas y resolvimos problemas algorítmicos. Escribí sobre preguntas no informativas en el párrafo anterior. Pero reemplazamos las tareas algorítmicas con tareas prácticas para el marco. También ponen a prueba sus habilidades de codificación y conocimientos de SDK.
Como resultado, solo hubo una entrevista técnica durante 1,5 horas, pero se volvió lo más pulida posible en contenido.
Consejo número 4. "La comprensión es más importante que el conocimiento"
El criterio más importante para elegir un desarrollador fue "comprensión". Para que una persona no solo sepa dar definiciones y conocimientos académicos, sino que demuestre comprensión de la estructura de un marco particular. Un desarrollador sin este conocimiento, enfrentado a problemas, no podrá encontrar una solución por sí mismo o no resolverá el problema de manera óptima. Por eso, hicimos abiertas todas las preguntas de la entrevista para que el candidato no dé los términos aprendidos, sino razone sobre un tema u otro. Y seguimos su conocimiento del tema y el curso de su lógica.
Por ejemplo, hacemos una pregunta abierta: "¿Cómo hacer un detector ANR (Aplicación que no responde) en Android?". Esta pregunta prueba el conocimiento de cómo funcionan los hilos en Android, pero evita la pregunta directa sobre Looper y Handler. También le permite cambiar de manera concisa a un tema con subprocesos múltiples.
Consejo número 5. Distribuir la función de entrevistas
Con el rápido crecimiento del equipo, las entrevistas se vuelven tan numerosas que toma todo el día y no queda tiempo para otras actividades. Por tanto, resulta útil delegar parcialmente la función de entrevista al equipo.
Esto no solo alivia la carga del líder, sino que también incluye al desarrollador en la elección de su posible colega, lo que además lo motiva.
Además, el candidato llega a conocer al equipo y se crea una impresión más holística.
Consejo número 6. Equilibrar el equipo
Al contratar, siempre debe recordar el equilibrio de las personas en términos de competencias en el equipo. Demasiados desarrolladores senior pueden llevarlos a crear nuevas soluciones, pero los desarrolladores no crearán funciones. Pero al comienzo del proyecto, cuando se sienta la base técnica para los próximos años, es necesario. Además, para escribir el código habitual de características, el firmante resultará excesivamente caro. Demasiados juniors, a su vez, degradarán el código base y, como resultado, hundirán el proyecto a largo plazo. Sin embargo, los jóvenes inteligentes se convierten rápidamente en medios y se vuelven mucho más leales a la empresa y al equipo que los medios del mercado. En mi opinión, este balance es diferente para cada proyecto y situación concreta, por lo que no daré porcentajes concretos.
A menudo, los equipos se diluyen con los contratistas para acelerar el desarrollo. El equilibrio también es muy importante aquí, ya que una gran cantidad de contratistas también pueden degradar el código en el proyecto. Los contratistas rara vez tienen la misma motivación e interés en un proyecto que un empleado a tiempo completo.
Consejo número 7. No tengas miedo de disparar
Finalmente, no hay por qué tener miedo de despedir a personas del equipo. Una persona que no encaja en el equipo en términos de principios y espíritu o en habilidades técnicas hará mucho más daño a largo plazo que el beneficio de la codificación a corto plazo.
Suena fácil de disparar, pero ¿cómo hacerlo de la forma más sencilla posible para el empleado y el equipo? El principio funciona aquí: "No importa lo que hagas, pero es importante cómo ". Si hace todo con anticipación (discuta las expectativas del puesto, brinde comentarios sobre el trabajo a tiempo, sin esperar el final del período de prueba y discuta sus comentarios), esto no sorprenderá al empleado.
También es importante que el equipo comprenda públicamente por quéel empleado fue despedido. De lo contrario, puede infundir miedo en el equipo y arruinar la atmósfera del equipo.
Consejo número 8. Recopile comentarios de los empleados recién llegados
El proceso de contratación consta de 2 etapas: entrevista e incorporación de un principiante.
La incorporación debería ser útil no solo para el principiante, sino también para el proyecto.
Después de la inmersión en el proyecto, las personas nuevas pueden ver las áreas problemáticas con una mirada abierta y dar nuevas ideas. Por lo tanto, hemos desarrollado una regla: escuchar y analizar conscientemente sus opiniones y recomendaciones para mejorar los enfoques y la base del código. Algunas de estas recomendaciones se han implementado con éxito en el proyecto.
Por ejemplo, después de la llegada de uno de los miembros del equipo de Android, revisamos por completo el enfoque para almacenar datos en la caché en memoria.
Salir
En conclusión, me gustaría decir que nuestro equipo móvil ha crecido a 26 personas en casi un año y medio. Todos los desarrolladores hacen un buen trabajo y nadie abandonó el equipo por su propia cuenta. Hemos lanzado con éxito el producto y pasamos la prueba del trabajo remoto sin pérdida de calidad y velocidad de desarrollo.
Espero que los consejos recopilados en este artículo también te sean útiles.
En las siguientes partes, hablaré sobre nuestros enfoques para elegir una pila de tecnología y configurar la interacción del equipo.