Классическая схема отдела такая народ сидит в офисе (ну или как сейчас на удалёнке) за повременную оплату (8 часов в день) или в бодишопах на почасовке. Добираются на работу в течении 30 120 минут. Найм человека происходит через hh или похожие сайты, кандидат проходит hrа, техсобес где пытаются составить матрицу компетенций. В Москве кандидатов много с любым уровнем знаний, в регионах с этим проблема. Если нет технического вуза поблизости, а бизнес вести хочется, едь в ближайший миллионник и плати местные зарплаты. Последнее для стартапа особенно неприятно. Хорошо если на проекте куда взяли человека существует и ведётся документация по решениям с описанием схем движения данных и т.д., но я такого не встречал ни разу. Бывают обрывки, хаотично ведущиеся записи, протоколы собраний с обоснованиями принятых решений, но систематически ведущаяся документация по разработке это как двойное затмение луны. Зачем нужна документация со схемами и обоснованиями? Когда архитектор набрасывает макет будущего проекта, то он является носителем уникальных знаний которых нет больше ни у кого. Это серьёзная проблема, если спец заболеет, погибнет, уйдёт то с ним уйдут и компетенции. Восстановление компетенций без документации и носителя знаний настолько нетривиальная задача, что проще переписать всё заново (и то и другое большие деньги). Ввод в проект нового бойца или старого с другого проекта это полгода наставничества и отвлечения внимания уже работающих. При этом новая единица тоже ограниченно функциональна по большему счёту. Система постановки задачи может ветвиться, разделяться на подзадачи и сливаться вновь возвращаясь из неожиданных мест. Задача может не проходить через лидов или архитекторов, что добавляет треша и угара в попытках расширить архитектуру или впихнуть непвихуемое.
Проблемы при классической схеме
Человеческие ресурсы ограничены наличным количеством и оперативному изменению практически не поддаются. Отсюда проблема простоев и переработок.
Невыгодно держать узких специалистов. Такие спецы уникальный источник знаний, но и расходы на содержание высоки, а задачи редки. Отсюда проблема простоя и застоя в компетенциях.
Люди в командах специализируются на текущих задачах и начинают деградировать если не делают над собой усилий или их не принуждают к таким усилиям.
Найти человека с нужными компетенциями трудно или вообще невозможно за выделенные деньги и время.
Отсутствие документации с описанием проекта для быстрого онбординга новичка. Необходимость менторов.
Проблема расширения функционала без глубокого анализа такой возможности, а такой анализ возможен только носителем широких компетенций в проекте архитектором.
Проблема выбывания носителей уникальных знаний по проекту.
Проблема моральной атмосферы в коллективе и личных отношений влияющих на принятие важных решений.
Проблема непрозрачности финансов для заказчика и исполнителей по оплате труда.
Проблема повышения статуса исполнителя и типа выполняемых задач.
Можно ли как-то нивелировать указанные проблемы не меняя парадигму(модель) управления разработкой? Короткий ответ нет! В дальнейшем такая модель будет тормозить работу, а при увеличении бизнеса и бюрократизации процессов вообще может вынудить к переводу разработки на аутсорс. Хорошо ли это вынос разработки на аутсорс? Короткий ответ да, если это ускорит и облегчит развитие продукта! Может ли быть аутсорс внутренним для компании? Легко. А внешним? тут сложнее, права, безопасность это всё но возможно! А внутренним и внешним? Можно и вот как это сделать.
Сервис представляет собой
- Систему коммуникации заказчика и исполнителей.
- Обеспечивает динамическое подключение специалистов с требуемыми компетенциями.
- Осуществляет расчеты с заказчиком и исполнителями.
- Оперативно показывает статус проекта и прогресс по задачам.
- Предоставляет заказчику отчёт о потраченных средствах с детализацией выплат.
- Позволяет войти в сервис с проектом на любом шаге и также выйти из него.
- Контролирует исполнение задач и их качество.
- Позволяет находить узких специалистов для решения задач.
- Позволяет динамически организовывать ресурсы на проекте в зависимости от нагрузки.
Вертикальная иерархия ролей специалистов в сервисе
- Менеджеры проектов. Роль осуществляет общее управление старшими специалистами, коммуникации между ними, разрешение спорных ситуаций, утверждает решения или обосновывает отказ.
- Лидеры направлений. Роль формирует декомпозиционное дерево подзадач и установку их в пул для нижестоящих ролей данной ветви компетенций. Графика, анимация, дизайн, эффекты решает задачи по разработке общих концепций по всему что касается графики и звука. Экономика и маркетинг маркетинговое исследование про спросу на продукт, таргет группы, инвестирование в проект, аналоги, примерные сметы расходов на этапы. Разработка создание программной версии продукта на всех этапах его жизненного цикла, архитектура, сборки пакетов, платформы. Тестирование ручное и автоматизированное. Юридическое обеспечение защита авторских прав и патентные исследования, проверки чистоты сделок с средствами заказчика, обоснование выплат исполнителям в автоматическом режиме. Игровой дизайн и сценарии относится в основном к игровой индустрии, занимаются механиками, фичами, сценами и монетизацией.
- Старший специалист. Роль получает из пула специализированную но всё ещё общую задачу созданную лидерами. Имеет опыт в решении подобных задач, широкую компетенцию в специализации. Может решить задачу сам или оценив сложность исполнения декомпозировать в пул задач для следующей роли.
- Специалист. Роль получает из пула подготовленную задачу не требующую дальнейшей декомпозиции. Задача точно поставлена, оговорены сроки исполнения, необходимые технологии и критерии успешного результата.
Каждая из вышестоящих ролей формирует пул декомпозированных подзадач для нижестоящей, указывает критерии выполнения и стоимость выполнения задачи. Вышестоящая роль не может директивно назначить исполнителя или назначить себя на подзадачу.
Нижестоящая роль при декомпозиции задачи обязана получить подтверждение на своё решение у вышестоящей роли поставившей исходную задачу.
Нижестоящая роль, после получения задачи, может отправить её на ревью постановщику с обоснованием обнаруженных ошибок или неточностей либо открыть спор с арбитражем и голосованием.
Вышестоящая роль может взять задачу любой нижестоящей если не является её(задачи) постановщиком.
Выполненная задача находится в специальном пуле для ревью и утверждения. Ревью задачи может проводить текущая роль(но не исполнитель) или на одну выше и ниже.
За выполненную и утвержденную задачу исполнителю начисляется указанная в задаче оплата (за вычетом комиссии сервиса за транзакцию) и балы рейтинга.
За выполненное ревью с обоснованным указанием об ошибке или отступлении от критериев ревьюиру начисляются балы, а у ревьюируемого они списываются. Споры по результатам ревью решаются автоматически общим голосованием ролей участвовавший в ревью.
Переход к вышестоящей роли происходит автоматически по достижении определённого количества балов у исполнителя. Таким образом можно пройти всю иерархию вплоть до менеджера не решив ни одной задачи, но набрав балы в ревью чужих задач.
Каждая задача и декомпозиционное дерево задач сопровождается созданием набора документов обосновывающих выбор решения и кратко описывающих его. Каждая задача не являющаяся веткой уже существующей, то есть расширение функционала должна начинаться с утверждения у менеджера и далее проходить утверждения по ролям вплоть до конечного исполнителя.
Задача автоматически считается невыполненной если была взята в работу, но сроки выполнения завершились и от исполнителя не было направлено обоснование на продление сроков.
Невыполненная задача устанавливается обратно в пул задач на выполнение, а исполнителю назначается штраф в виде списания балов.
Набор определённого отрицательного уровня балов ведёт к автоматической блокировке исполнителя по выбранной компетенции.
Отсутствие выполненных задач или ревью за определенный срок ведёт к автоматическому понижению общего бала.
При снижении бала ниже порогового уровня роли происходит переход статуса исполнителя на нижестоящую роль.
Схема движения заказа от заказчика до готового продукта
Заказчик заводит в сервисе проект описывая бизнес задачу (это является первичной информацией). Вносит на свой счёт в сервисе объём средств минимально необходимый для экономико-маркетинговой экспертизы или если она уже есть, то для составления технического задания лидером(разработки, архитектором). Экономическая экспертиза и техническое обоснование включает в себя заключения экспертов о экономической целесообразности данного продукта. Экономическая целесообразность это исследование аналогов, спроса, доступных ресурсов, практической реализуемости представленное в виде документа с рекомендациями. На следующий этап задача переходит при достаточности средств на счету заказчика в сервисе. Заказчик может предоставить свою экспертизу или ТЗ(техническое задание, архитектуру проекта) на согласование. Если согласование не пройдено, то задача(проект) не может быть взята в разработку. Заказчик может выйти из сервиса на любом шаге или заморозить его в сервисе за отдельную плату. Заказчик имеет доступ на чтение ко всей документации и исходникам по проекту, к сборкам пакета приложения или ресурсов, к прогрессу выполнения проекта и задач, ведомостям по оплате исполнителям.
Разработка ведётся согласно правил установленных на старте проекта, это касается языка составления документов и описаний, соглашению по оформлению кода и самодокументирующимся комментариям. Приоритет в написании классов и функций отдаётся максимально простому и чистому коду. В каждом случае, когда это возможно, код покрывается Unit тестами. В разработке должны быть специалисты обеспечивающие работу контроля версий, автоматической сборки, удалённое подключение исполнителей к необходимому оборудованию на стороне сервиса или заказчика.
Ввод исполнителей в сервис возможен после получения матрицы компетенций. Матрицу компетенций возможно получить в сервисах специализирующихся на тестировании в автоматизированном режиме. Аккредитованные сервисы предоставляют API с помощью которого можно получить матрицу по соискателю. В зависимости от полученных результатов для аккаунта исполнителя устанавливаются стартовые роли и компетенции для которых будут видны специализированные задачи. Резюмируя, исполнитель регистрируется в сервисе и получает ссылку на сервис тестирования компетенций и проходит их. Результаты тестирования заполняют матрицу компетенций и аккаунту открывается возможность брать задачи, проводить ревью, читать документацию доступную для своей роли.
Рекомендуется на первом этапе ввести в сервис оформленных исполнителей на существующей базе офиса. Проверить работу с заказчиком в реальных проектах. Провести рекламную компанию в специализированных сообществах и соцсетях с тезисами Полная прозрачность и честность, никаких секретов. Работай над чем хочешь, откуда хочешь и тогда когда хочешь. Тебе никто не приказывает. Заработай сколько сможешь унести, никаких ограничений для всех и навсегда.
Вопросы требующие отдельной проработки
- Безопасносность.
- Оплата и расчёты с заказчиком и исполнителями.
- Юридические вопросы до договорам с заказчиком и сдельной оплате исполнителям, трансграничные переводы.
- Защита авторского права.
