Hace un par de años, Vedomosti
escribió sobre un "mensajero ruso protegido", que pretenden implementar en las agencias gubernamentales. Incluso volver a contar esta noticia en una oración da en la cabeza el sonido de martillos que caminan con lentitud. Imagínese, en algún lugar detrás de una valla alta, con erizos en la entrada y dos centinelas, algunos de los programadores uniformados se levantan alarmados y se lanzan a la batalla en beneficio de la sustitución de importaciones.
Los estereotipos son algo terrible, lo sé.
El mensajero junto con Beeline fue desarrollado por Staply. Ahora abandonaron esta empresa y transfirieron los desarrollos a un nuevo producto: "Mobile Enterprise". Resulta que este es un pequeño equipo de trabajadores remotos que no aceptan tanto el microcontrol que viven sin gerentes e incluso líderes de equipo, trabajan cuando quieren y donde quieren.
Cómo lograron hacer esto, le pregunté al Director Técnico de Staply, Maxim Indykov (
maks_ohs ).
La compañía fue incluida en la clasificación reciente de los mejores empleadores en My Circle IT con una calificación promedio de 4.81 para los doce criterios, de los cuales los empleados de Staply son la tecnología moderna mejor calificada, salario adecuado, crecimiento profesional, reconocimiento de resultados de trabajo y comunicación con la alta gerencia.
¿Qué es Staply?
Maxim Indykov"Todo comenzó hace unos seis años". Me gradué de ITMO, Tecnología de la Información. Este es un batiburrillo de todas las materias, hasta el desarrollo curricular, historia, filosofía, matemáticas, física, programación. Luego pensamos con los chicos qué cosas interesantes hacer. Tuvimos varios intentos, y el primer proyecto, que tuvo cierto peso, se llamó Cloudiverse.
Con él, los chicos tomaron el segundo lugar en el hackathon Techrunch. La esencia era esta: se toma un archivo, se divide en pedazos en el navegador, cada pieza se cifra y estas piezas cifradas se envían a diferentes nubes. Una pieza está en Dropbox, una pieza está en Google Drive y la pieza permanece localmente. Para volver a armar todo, debe conocer la clave y saber dónde se encuentran las piezas.
Esto se hizo en un contexto de exageración según Snowden. Pero, de hecho, el proyecto fue más interesante para nosotros desde un punto de vista técnico: un trabajo inusualmente grande en el cliente en ese momento. Pero entonces el tema de seguridad de alguna manera se desvaneció.
- ¿Fue tu exageración o algún tipo de convicción tu motivación?- La exageración no es para nada, solo fue una buena ventaja. Motivado para hacer un proyecto interesante. Y cuando lo mostramos, todos estaban interesados. Parece ser una idea simple, pero al mismo tiempo se visualiza bien en la cabeza de las personas. Aquí el archivo se divide y solo queda un conjunto de caracteres. No te culpes en absoluto.
- ¿Y cómo te metiste en TechCrunch?- Acabo de enviar una solicitud y todo. Obtuve una distribución gratuita de boletos en línea y logré registrarse. Siempre tratamos de hacer lo más simple posible. Sin búsqueda de soluciones, sin esquemas complicados. ¿Por qué TechCrunch? Quería intentar lo mejor. En aquellos días, era un buen hackathon publicitario.
Éramos pocos, tres personas. Yo (desarrollador), diseñador, organizador. Todavía había una persona, se ocupó de las patentes.
Todo fue bastante rápido. Después de que comenzamos a desarrollar un chat de servicio para correspondencia, algo así como Slack. Acaban de ser un buen mensajero conveniente. Y justo en ese momento había una historia con sustitución de importaciones, en algún lugar del año 14.
Probamos el producto en Rosenergoatom y en el gobierno de la región de Moscú. La característica principal fue que se instaló en servidores internos. Solución totalmente en caja. Le permite comunicarse de manera realmente segura, porque simplemente no hay acceso a Internet. Por lo tanto, las grandes corporaciones lo han intentado.
Un par de noticias salieron sobre este tema, escribieron en Vedomosti. Nosotros mismos escribimos mucho, en "Habr", en VC, y de alguna manera era PR. Nunca compraron publicidad, solo hicieron artículos con buen material, temas interesantes. Escribí sobre programación, Dima, nuestra abogada, escribió sobre los antecedentes legales del proyecto. Compartieron con la comunidad lo que sabemos.
En ese momento, no teníamos grandes recursos para el desarrollo y el apoyo. Éramos pocos, y comenzamos a expandirnos, buscar personas, formar un equipo, aprender todo.
¿Qué tipo de producto está haciendo Staply en este momento?
Ahora Staply tiene tres productos: el editor de ofertas comerciales de Octaplan, Emny es uno de los servicios de búsqueda de empleo de VK. Y el producto principal es Mobile Enterprise. Los tres están formados por un equipo de treinta personas.
"Mobile Enterprise" es un servicio para pequeñas y medianas empresas, que incluye un conjunto completo de herramientas: chat para empleados, seguimiento de llamadas, análisis de llamadas, sistema de configuración de tareas, sistema CRM, bloc de notas, análisis publicitario y mucho más.
"El caso de uso es bastante simple", dice Maxim. “El dueño del negocio coloca los números en un anuncio: en un periódico, en la radio, en la televisión. Se asigna un canal separado para cada número; se hacen llamadas para cada uno. Un empleado puede analizar aplicaciones allí y continúa trabajando con un cliente allí.
Puede establecer una tarea para su equipo, por ejemplo, devolver la llamada a un cliente, firmar un contrato, guiar al cliente a través del embudo de ventas, cambiar su estado en el tablero de Kanban.
Para este cliente, los empleados pueden comunicarse en grupos, en salas de chat, crear discusiones. Las salas de chat tienen un mini teclado para almacenar información común a todo el equipo de notas ".
Como dice Maxim, la característica principal del servicio es que es simple, no necesita configurar nada y todo está listo para usar.
- ¿Qué pasa con el hecho de que todos usan Slack?- Este es un nicho completamente diferente. Aunque estamos desarrollando algo similar, pero nunca competimos con ellos, no nos propusimos tal objetivo.
- por qué?- Slack es una cosa para aquellos que prefieren todo tipo de integraciones, como configurar algo. No solo estoy hablando de la comunidad de TI, creo que se usa mucho donde. Y "Mobile Enterprise" es un producto para aquellos a quienes no les gusta configurar nada, no saben cómo o no quieren hacerlo.
En primer lugar, se trata de pequeñas y medianas empresas en las regiones. La gente quiere que todo funcione de inmediato.
- ¿Y con qué te utilizas, con qué te comunicas?- En lo que estamos desarrollando - en la "Empresa móvil". Lo usamos todos los días para comprender por nosotros mismos qué problemas, dónde mejorar. Bueno, Skype para llamadas grupales es una parte integral. ¿Sería más simple ...
- Leí que intentaste lanzar el messenger primero en Estados Unidos, pero no fue así. Por qué- Cuando era solo el comienzo, tratamos de trabajar para todo el mundo. La localización tomó mucho poder. El producto cambia constantemente, debe admitir dos tipos de textos, traducir. En ese mercado, no teníamos un trabajo a gran escala. Avanzaron de manera muy simple, con artículos. Hacker News fue probablemente la principal fuente de tráfico.
Los usuarios de TI son los primeros probadores. Pero no había salida específicamente para los negocios. Y no funcionó, probablemente porque el énfasis se trasladó fuertemente a Rusia. Quedó claro que también es interesante aquí, y que hay mucho por hacer: dar a las personas que aún usan Excel o incluso blocs de notas algún servicio simple.
Trabajo a distancia sobre responsabilidad personal
- ¿Cómo sucedió que distribuiste remotamente?- Todos los que comenzaron este negocio vivían en San Petersburgo. Los objetivos de hacer una oficina nunca han sido. Pero siempre remotamente, también. Solo quería armar un buen equipo. Mucha gente buena en términos de programación vive en Ekaterimburgo, Novosibirsk, Kazan. Entonces formaron un equipo completamente remoto.
Inicialmente, nos propusimos la tarea de evitar la microgestión y el control tanto como sea posible. El microcontrol puede matar el medio ambiente orgánico en una empresa. Cuando todos se despiertan a las nueve, se sientan en la oficina, reparten tareas, comienzan a hacerlas, se van, no pueden irse a ningún lado a voluntad, posponen el trabajo para más tarde. Por lo tanto, tratamos de evitar el control, y hasta ahora lo hemos logrado.
- Me parece que para muchas empresas esto suena como una pesadilla: trabajar sin control y sin una oficina.- Ni siquiera tenemos gerentes y líderes de equipo. Si no hay cosas que se queman, entonces una persona puede tomarlo, ir a un lugar para relajarse. No hay problema si es predecible. Una persona puede trabajar desde donde convenientemente.
Pero para algunos también es difícil. Cuando hay una oficina, todos organizan para usted, todo su horario y trabajo. Y aquí tienes que hacerlo tú mismo. No se recicle, trabaje usted mismo cuando lo necesite. Esta es una gran responsabilidad que recae en cada persona. Nadie organiza tu vida por ti.
- ¿Cómo lidias?- Cuando no hay presión desde arriba, desde abajo y desde un lado, la responsabilidad de sus promesas, acciones y palabras sale a la luz. Ahora, dentro del marco de los sistemas de configuración de tareas, todo tipo de KPI, la responsabilidad personal ha sido puesta en un segundo plano.
Todos confiamos el uno en el otro y sabemos que esta persona está aquí, si dijera que lo haría. Si no tiene tiempo, dirá que no tiene tiempo.
- ¿Y si no lo hizo?- Eso se considera individualmente. No hay control, pero hay una moderación del proceso. Observación, toma de decisiones estructurales. Tenemos solo treinta personas. Probablemente, todavía puedes hacer frente a un equipo así.
Siempre tratamos de no crecer tanto como sea posible. Hubo momentos en que había más personas en proyectos, pero luego todo se volvió borroso.
- ¿Qué ciudades has distribuido?- Nuestro diseñador vive en Italia. Y luego: Peter, Moscú, Ekaterimburgo, Krasnoyarsk, Krasnodar, etc.
- ¿Las zonas horarias no interfieren?- No No requerimos un trabajo permanente de nueve a seis. Solo necesita llevar a cabo las cosas que prometió hacer, encontrar puntos en común con el equipo y acordar un momento conveniente para todos.
Nosotros, los fundadores, también nos sentamos en casa, nos reunimos en la ciudad. Y con el equipo, generalmente en conferencias. Supongamos que nos sentamos en una conferencia por un día, escuchamos, y al día siguiente ya estamos discutiendo cosas de trabajo en coworking. En Moscú, probablemente, "Mesa" es la mejor opción para tales reuniones.
Sucede que después de trabajar con una persona durante seis meses, ni siquiera sabes cómo es. Siempre es muy divertido encontrarse en una conferencia. Te ves así: "Hola. ¿Eres tú? ¡Acordamos encontrarnos en la fuente!
- ¿Y cómo se dividen ustedes en equipos?Aproximadamente por igual: cinco a seis personas. Quien comenzó a desarrollar el proyecto es un centro de conocimiento y, a su alrededor, un equipo que está interesado en desarrollarlo en este momento. Los proyectos dentro de la empresa están abiertos, todos pueden ver lo que está sucediendo, ayudar o también participar en el desarrollo.
Los equipos son fluidos, pero aún así, todos trabajan solo en el campo de su producto. Cuando un desarrollador trabaja en tres proyectos a la vez, es muy deprimente y agotador. De todos lados quieren algo de él. Vi a diez personas colgando de personas en otras compañías, y tuvieron un agotamiento terrible.
"Tú lo dices y parece que tienes total libertad". Haz lo que quieras, cuando quieras y como quieras. Sin gerentes, sin presión. Pero cuando leí tu página en HeadHunter, tuve una impresión completamente diferente. Plazos, hoja de ruta, llamadas diarias.- La presión se produce por sí misma. Pero esto es diferente del desarrollo personalizado. Allí, el cliente hace demandas, es necesario llegar a esa fecha y pagará por lo que se haga. Esta no es una motivación fuerte. Bueno, él pagará a la compañía, pero ¿en qué está interesado el desarrollador?
Pero cuando el equipo sabe que se ha comprado un anuncio de un socio para las fechas, saben que los equipos trabajan allí y nos están esperando: hay una motivación interna, una responsabilidad. Ya no trabaja por dinero y plazos, pero es responsable de garantizar que otros también tengan éxito.
Y hay una presión interna que organiza a las personas. El equipo mismo comienza a ofrecer qué hacer, cómo distribuir y cómo mantenerse al día.
- ¿Esto no difumina las responsabilidades? En lugar de escribir código, un desarrollador comienza a corresponder, piensa en cuestiones organizativas. Y al final, nada bueno se hará.- Tales casos suceden. Pero hay otro lado. A veces una persona ha escrito su parte y ayuda a organizar el trabajo en su interior. Incluso es genial: es increíble entender lo que realmente se necesita allí. Después de todo, con los gerentes suele ser como: "Dame un estado, lo pensaré". Y aquí el programador está dentro del proceso y sabe dónde se puede hacer.
Esta es la cuestión del hecho de que realmente no tenemos líderes de equipo. Timlid aparece en términos de habilidades difíciles, y si todavía existe la capacidad de comunicarse, construir relaciones, automáticamente se convierte en un líder.
- Sin gerentes, sin leads. ¿Pero qué haces entonces como director técnico?- La última vez, principalmente por contratación. Las entrevistas toman mucho tiempo, especialmente si necesita pasar varias rondas.
Y generalmente, solo una moderación técnica del desarrollo, observación. Puedo hacer prototipos rápidamente, sé que puedo hacerlos en un día, así que prototipo de características.
Para el trabajo, utilizamos el servicio Notion, mantenemos completamente nuestra base de conocimiento allí y pintamos las etapas. Así que estoy organizando estas etapas, hablando con socios. En general, trato de no mantener el conocimiento en mí mismo. Cuando aprendes algo y lo pones rápidamente en la base de conocimiento, todo se vuelve mucho más fácil, especialmente en un equipo remoto.
- En el esquema clásico, cuando el gerente está esperando el estado y el cliente de lanzamiento son los desarrolladores, pueden dar un paso al frente y finalizarlo, incluso si no están satisfechos con la calidad. ¿Y en tus condiciones el perfeccionismo sin fin no florece? ¿Cuándo todavía no es de alta calidad y no es necesario tirarlo con urgencia?- Si el término puede posponerse en aras de la calidad, entonces será mejor posponerlo. La opción con una fecha límite sin pruebas y controles aún conducirá al efecto contrario, a la fatiga, una gran deuda técnica.
- En el mismo HeadHunter ha escrito que si la fecha límite está establecida, no necesita moverla.- Bueno, este es un caso individual cada vez. Puede mover la fecha límite, lo principal es informar todo. Puedo reducir todos nuestros intentos de organizar algo a una sola cosa: una persona debería ser predecible.
Si un equipo puede predecir el comportamiento de una persona, puede confiar en él. Si ella sabe que una persona cumple sus promesas, y él realmente las cumple, está bien. Si una persona tiene una fecha límite y escribe que no tiene tiempo, no importa por qué razones, también está bien. Si escribe una hora antes del lanzamiento, entonces esto es malo, esto es absolutamente impredecible. Discutimos una cosa, obtuvimos otra. Lo principal es la comunicación. Escriba, informe, diga: siempre se le ocurre algo.
- ¿Es cierto que todos tienen tareas para ti?- si.
"¿La confusión no comienza?"- Una vez a la semana hay una gran llamada cuando analizamos y pensamos que deberíamos hacer el bien en una semana. En consecuencia, las tareas se establecen dentro del equipo. Primero discutimos la hoja de ruta de desarrollo de productos. La discusión es bastante global, en general todos participan en ella.
Por ejemplo, digo: "Necesitamos hacer un módulo con envío de SMS". Y todos entran en discusión: cómo lo haremos, cuándo y quién lo hará. Como resultado, se forma un plan elaborado en la base de conocimiento, y tratamos de mantenerlo. No establecemos deducciones ni plazos. Tenemos un plazo bastante común, que nosotros mismos hemos elegido.
Es decir, estamos de acuerdo y solo tratamos de cumplir con nuestro propio plan.
- ¿Todos son responsables de todo?- si.
- Esto a menudo lleva al hecho de que nadie es responsable de nada."Por supuesto que podría ser". Pero no importa cómo una persona hace todo, él tiene su propia especialización. El desarrollador de la interfaz es responsable de la interfaz. Lo que hizo él mismo es responsable de eso.
Y la responsabilidad colectiva (aunque no me gusta esta palabra en absoluto) es más bien decir en el momento correcto: "Escucha, pero no lo estás haciendo, estás haciendo demasiado trabajo, es más fácil". Probablemente la responsabilidad es ayudar al otro a no hacer demasiado.
Por lo tanto, es difícil buscar personas. Con un trabajo tan remoto, una buena comunicación es muy importante para que la persona sea abierta. De hecho, si hay una estructura rígida, una jerarquía donde una persona puede ponerse de pie como un tornillo como especialista, pero absolutamente sin habilidades de comunicación, entonces no puede comunicarse con nadie, realizar tareas y hacer bien su trabajo.
Pero en el trabajo remoto no basta con ser un buen especialista: debe ser capaz de encontrar contacto, comunicarse.
Contratación creativa de personas interesantes.
"¿Dónde reclutas a esas personas?"- Básicamente, "My Circle", un poco más pequeño que HeadHunter, canaliza en "Telegram", en general, donde haya programadores. A menos que usemos LinkedIn.
Escribimos, como lo llamamos, "trabajos creativos". Por ejemplo, pusieron texto cifrado allí, contaron algunas historias. O vacantes, donde no hay texto ordinario, sino diálogo. ¿Por qué escribir "necesitamos un desarrollador" cuando puedes escribir algo inusual!
Esta es una forma de tratar de encontrar personas que sean interesantes con nosotros.
Y sucede que buenos especialistas están justo al lado. Una vez encontré un desarrollador de Android mientras estábamos esquiando en Rosa Khutor.
- Gente interesante - es genial. ¿Pero deberían pasar por filtración técnica?- Intentamos entrevistar lo más rápido posible, filtrar de manera aproximada y ya en un período de prueba para ver cómo funciona una persona. ¿De repente alguien simplemente no sabe cómo obtener una entrevista? Este enfoque no funcionó.
Una persona está incluida en el trabajo, y la comprensión ya se está volviendo borrosa, lo está entendiendo o no. No lo notarás rápidamente. Por lo tanto, ahora estamos probando el conocimiento fundamental. No manejamos alrededor de los marcos, pero preguntamos lo básico, cómo funciona todo, cómo funciona. El mismo protocolo HTTP: es uno para todos. O cómo funcionan los índices en las bases de datos, cómo están organizadas las propias bases de datos, no solo haciendo consultas, sino entendiendo qué procesos están sucediendo y cómo están organizados los encabezados.
Muchas personas ni siquiera saben cómo se organizan las codificaciones comunes, por qué UTF-8, por qué "ocho".
- ¿Crees que realmente necesita ser conocido? ¿Por qué exactamente el "ocho"?- Creo que esta es una comprensión fundamental de los conceptos básicos, es realmente importante. Una persona puede ser un buen especialista, pero se encontrará con problemas que requieren conocimientos de bajo nivel.
Por ejemplo, ¿por qué esta consulta es tan lenta? Una persona parecía escribir bien las consultas SQL, pero necesita investigar, comprender qué puede cambiar en la estructura de la base de datos, descubrir por qué este índice en particular es tan lento.
Una persona que no conocía los fundamentos fundamentales se pierde de inmediato. Se vuelve muy difícil para él. Por supuesto, este no es un filtro tan grueso que no respondió, eso es todo a la vez. No hay lista de verificación.
Si él no sabe una cosa, pero sabe en otras áreas, está bien.
- ¿Le das una tarea de prueba?- De nuevo, de diferentes maneras. Probablemente, las tareas de prueba son un intento de filtrar a las personas que simplemente no están interesadas. Si una persona se muestra bien en una entrevista, podemos decir que una prueba no es necesaria. Y a veces es imposible evaluarlo en una entrevista.
, 70 Github — - , , . , , , , .
, , — Rest API . — , .
, . , , .
— ?"Sí, por supuesto". , . : « , , -, ». , : « ?» : «-, ». .
Ruby Go
— , ?— Ruby on Rails, - . , MySQL — .
Go. , . Go, , , Go .
, . Ruby- — Elixir, Go. .
— , Go?— . — , Go - . — Go . — , .
— , Go, « », .* *— , . . . , .
Go . ? , . , , .
Go .
— React . Vue, TypeScript.
«»
— , Staply Primavera. Staply «». ?— — «» . , . — , , . — , .
— , . . — , — , , . . , , .
— ?— . . — .
— , «» « »?— , . , .
— , «».— , . , , « », «», .
. — .
— , ?— . — , - . . — — , .
, . . , , , .
, . .
— — , — . 3000 — . .
. .
— ? , — .— . , , , . , — . , .
Puede que no haya aceleración debido a condiciones externas, puede que no haya nada. Pero debe haber un buen producto que resuelva el problema real.