El esquema clásico del departamento es el siguiente: la gente se sienta en la oficina (bueno, o como está ahora en una ubicación remota) por un pago basado en el tiempo (8 horas al día) o en talleres por horas. Póngase a trabajar en 30 a 120 minutos. Se contrata a una persona a través de hh o sitios similares, el candidato pasa por hr'a, seguridad técnica donde intentan elaborar una matriz de competencias. Hay muchos candidatos en Moscú con cualquier nivel de conocimiento, en las regiones esto es un problema.Si no hay una universidad técnica cerca, pero quieres tener un negocio, ve al millonario más cercano y paga los salarios locales. Esto último es especialmente desagradable para una startup. Es bueno si en el proyecto donde se llevó a la persona existe y hay documentación sobre soluciones con una descripción de esquemas de flujo de datos, etc., pero nunca me he encontrado con esto. Hay borradores, registros caóticos, actas de reuniones con motivos de decisiones, pero la documentación del desarrollo sistemático es como un doble eclipse de luna. ¿Por qué necesita documentación con diagramas y justificaciones? Cuando un arquitecto esboza un modelo para un proyecto futuro, es portador de un conocimiento único que nadie más tiene. Este es un problema grave, si un especialista se enferma, muere, se va, entonces sus competencias también desaparecerán con él.Restaurar competencias sin documentación y un portador de conocimientos es una tarea tan no trivial que es más fácil reescribir todo de nuevo (ambos son mucho dinero). Introducir un nuevo luchador o uno antiguo de otro proyecto en un proyecto son seis meses de tutoría y distraer la atención de los que ya están trabajando. Al mismo tiempo, la nueva unidad también tiene una funcionalidad limitada en general. El sistema de enunciado de problemas puede ramificarse, dividirse en subtareas y fusionarse desde lugares inesperados. Es posible que la tarea no pase a través de clientes potenciales o arquitectos, lo que agrega basura y frenesí en los intentos de expandir la arquitectura o abarrotar lo imparable.Al mismo tiempo, la nueva unidad también tiene una funcionalidad limitada en general. El sistema de enunciado del problema puede ramificarse, dividirse en subtareas y fusionarse desde lugares inesperados. Es posible que la tarea no pase a través de prospectos o arquitectos, lo que agrega basura y frenesí en los intentos de expandir la arquitectura o meter lo imparable.Al mismo tiempo, la nueva unidad también tiene una funcionalidad limitada en general. El sistema de enunciado del problema puede ramificarse, dividirse en subtareas y fusionarse desde lugares inesperados. Es posible que la tarea no pase a través de clientes potenciales o arquitectos, lo que agrega basura y frenesí en los intentos de expandir la arquitectura o meter lo imparable.
Problemas con el esquema clásico.
Los recursos humanos están limitados en disponibilidad y prácticamente no son susceptibles de cambios operativos. De ahí el problema del tiempo de inactividad y las horas extraordinarias.
No es rentable tener especialistas limitados. Dichos especialistas son una fuente única de conocimiento, pero los costos de mantenimiento son altos y las tareas raras. De ahí el problema del tiempo de inactividad y el estancamiento de las competencias.
Las personas de los equipos se especializan en las tareas actuales y comienzan a degradarse si no se esfuerzan o no se ven obligadas a hacerlo.
Encontrar una persona con las competencias necesarias es difícil o incluso imposible por el dinero y el tiempo asignados.
Falta de documentación que describa el proyecto para una incorporación rápida para un principiante.
La necesidad de mentores.
El problema de expandir la funcionalidad sin un análisis profundo de tal posibilidad, y tal análisis es posible solo por el portador de amplias competencias en el proyecto: un arquitecto.
El problema de dejar fuera a los poseedores de conocimientos únicos sobre el proyecto.
El problema del clima moral en el equipo y las relaciones personales que influyen en la adopción de decisiones importantes.
El problema de la falta de transparencia de las finanzas para el cliente y los artistas intérpretes o ejecutantes sobre la remuneración.
El problema de aumentar el estatus del ejecutante y el tipo de tareas realizadas.
¿Es posible nivelar de alguna manera estos problemas sin cambiar el paradigma (modelo) de gestión del desarrollo? ¡La respuesta corta es no! En el futuro, dicho modelo ralentizará el trabajo y, con un aumento de los negocios y la burocratización de los procesos, generalmente puede forzar la transferencia del desarrollo a la subcontratación. ¿Es bueno subcontratar el desarrollo? - La respuesta corta es sí, ¡si acelerará y facilitará el desarrollo de productos! ¿Puede la subcontratación ser interna de la empresa? - Fácil. ¿Y externo? - Aquí es más difícil, cierto, la seguridad lo es todo ... ¡pero posible! ¿Y qué pasa con lo interno y lo externo? - Puedes y aquí te explicamos cómo hacerlo.
El servicio es
- El sistema de comunicación del cliente y los artistas.
- Proporciona conexión dinámica de especialistas con las competencias requeridas.
- Realiza liquidaciones con el cliente y contratistas.
- Muestra rápidamente el estado del proyecto y el progreso de las tareas.
- .
- .
- .
- .
- .
- . , , , .
- . . “, , , ” — . “ ” — , , , , . “” — , , , . “” — . “ ” — , , . “ ” — , , , .
- . . , . .
- . . , , .
Cada uno de los roles de nivel superior forma un grupo de subtareas descompuestas para los de nivel inferior, especifica los criterios para realizar y el costo de completar la tarea. El rol superior no puede asignar directamente un ejecutor o asignarse a sí mismo a una subtarea.
Al descomponer una tarea, el rol de nivel inferior debe recibir la confirmación de su solución del rol de nivel superior que estableció la tarea original.
El rol subordinado, luego de recibir el problema, puede enviarlo para revisión al director con justificación de los errores o inexactitudes encontradas, o abrir una disputa con arbitraje y votación.
El rol superior puede asumir cualquier tarea subordinada si no es su director (de tareas).
La tarea completada se encuentra en un grupo especial para su revisión y aprobación. La tarea puede ser revisada por el rol actual (pero no por el ejecutante) o uno superior o inferior.
Para la tarea completada y aprobada, al ejecutante se le cobra el pago especificado en la tarea (menos la comisión de servicio por la transacción) y los puntos de calificación.
Para una revisión completa con una indicación razonable de un error o desviación de los criterios de revisión, se otorgan puntos y se cancelan de la persona revisada. Las disputas basadas en los resultados de la revisión se resuelven automáticamente mediante una votación general de los roles que participaron en la revisión.
La transición a un rol superior ocurre automáticamente al alcanzar un cierto número de puntos para el ejecutante. Así, puedes recorrer toda la jerarquía hasta llegar al gerente sin resolver un solo problema, pero ganando puntos en la revisión de los problemas de otras personas.
Cada tarea y árbol de descomposición de tareas va acompañado de la creación de un conjunto de documentos que justifican la elección de una solución y la describen brevemente. Cada tarea que no sea una rama de una existente, es decir, expandir la funcionalidad, debe comenzar con la aprobación del gerente y luego pasar por la aprobación por roles hasta el ejecutor final.
La tarea se considera automáticamente incumplida si se puso en funcionamiento, pero el plazo venció y el contratista no envió ninguna justificación para ampliar el plazo.
La tarea no cumplida se devuelve al grupo de tareas para su ejecución, y el ejecutor recibe una multa en forma de cancelación de puntos.
El conjunto de un cierto nivel negativo de puntos conduce al bloqueo automático del ejecutante para la competencia seleccionada.
La falta de tareas o revisiones completadas dentro de un cierto período de tiempo conduce a una disminución automática en la puntuación general.
Cuando la puntuación cae por debajo del nivel de umbral del rol, el estado del ejecutante se transfiere a un rol inferior.
Esquema de movimiento de pedidos desde el cliente hasta el producto terminado
El cliente inicia un proyecto en el servicio que describe una tarea comercial (esta es la información principal). Aporta a su cuenta en el servicio la cantidad mínima de fondos necesarios para la experiencia económica y de marketing, o si ya existe, para la preparación de una tarea técnica por parte del líder (desarrollo, arquitecto). La experiencia económica y la justificación técnica incluyen opiniones de expertos sobre la viabilidad económica de este producto. La viabilidad económica es un estudio de análogos, demanda, recursos disponibles, viabilidad práctica presentada en forma de documento con recomendaciones. La tarea pasa a la siguiente etapa cuando hay fondos suficientes en la cuenta del cliente en el servicio. El cliente puede proporcionar su experiencia o conocimientos tradicionales (especificaciones técnicas, arquitectura del proyecto) para su aprobación. Si no se aprueba el acuerdo,entonces la tarea (proyecto) no puede llevarse a cabo en desarrollo. El cliente puede salir del servicio en cualquier paso o congelarlo en el servicio por una tarifa. El cliente tiene acceso de lectura a toda la documentación y códigos fuente del proyecto, a los ensamblajes del paquete o recursos de la aplicación, al progreso del proyecto y tareas, hojas de pago a los ejecutantes.
El desarrollo se lleva a cabo de acuerdo con las reglas establecidas al inicio del proyecto, esto se refiere al lenguaje de redacción de documentos y descripciones, un acuerdo sobre el diseño del código y comentarios autodocumentados. La prioridad en la escritura de clases y funciones se le da al código más simple y limpio. En todos los casos, cuando es posible, el código está cubierto por pruebas unitarias. En desarrollo, debe haber especialistas que aseguren el trabajo de control de versiones, ensamblaje automático, conexión remota de los ejecutantes al equipo necesario por parte del servicio o cliente.
La introducción de los artistas intérpretes o ejecutantes al servicio es posible después de recibir la matriz de competencias. La matriz de competencias se puede obtener en servicios especializados en testing de forma automatizada. Los servicios acreditados proporcionan una API con la que puede obtener una matriz para un solicitante. Dependiendo de los resultados obtenidos, los roles y competencias iniciales para los que se verán tareas especializadas se establecen para la cuenta del ejecutante. En resumen, el ejecutante se registra en el servicio y recibe un enlace al servicio de pruebas de competencia y lo pasa. Los resultados de las pruebas llenan la matriz de competencias y la cuenta tiene la oportunidad de realizar tareas, realizar revisiones, leer la documentación disponible para su función.
Se recomienda en una primera etapa introducir en el servicio a los ejecutores ejecutados en la base existente de la “oficina”. Consultar trabajo con el cliente en proyectos reales. Realizar una campaña publicitaria en comunidades especializadas y redes sociales con tesis - “Total transparencia y honestidad, sin secretos. Trabaja en lo que quieras, de dónde quieras y cuando quieras. Nadie te lo ordena. Gana tanto como puedas, sin límites para todos y para siempre. "
Problemas que requieren un estudio por separado
- La seguridad.
- Pago y liquidaciones con el cliente y contratistas.
- Asuntos legales ante contratos con el cliente y pago a destajo a los artistas intérpretes o ejecutantes, transferencias transfronterizas.
- Protección de derechos de autor.