В начале зафиксируем, что имеем сейчас по разработке ПО, какие есть проблемы и к чему необходимо прийти.

Классическая схема отдела такая — народ сидит в офисе (ну или как сейчас на удалёнке) за повременную оплату (8 часов в день) или в бодишопах на почасовке. Добираются на работу в течении 30 — 120 минут. Найм человека происходит через hh или похожие сайты, кандидат проходит hr’а, техсобес где пытаются составить матрицу компетенций. В Москве кандидатов много с любым уровнем знаний, в регионах с этим проблема. Если нет технического вуза поблизости, а бизнес вести хочется, едь в ближайший миллионник и плати местные зарплаты. Последнее для стартапа особенно неприятно. Хорошо если на проекте куда взяли человека существует и ведётся документация по решениям с описанием схем движения данных и т.д., но я такого не встречал ни разу. Бывают обрывки, хаотично ведущиеся записи, протоколы собраний с обоснованиями принятых решений, но систематически ведущаяся документация по разработке — это как двойное затмение луны. Зачем нужна документация со схемами и обоснованиями? Когда архитектор набрасывает макет будущего проекта, то он является носителем уникальных знаний которых нет больше ни у кого. Это серьёзная проблема, если спец заболеет, погибнет, уйдёт — то с ним уйдут и компетенции. Восстановление компетенций без документации и носителя знаний настолько нетривиальная задача, что проще переписать всё заново (и то и другое большие деньги). Ввод в проект нового бойца или старого с другого проекта — это полгода наставничества и отвлечения внимания уже работающих. При этом новая единица тоже ограниченно функциональна по большему счёту. Система постановки задачи может ветвиться, разделяться на подзадачи и сливаться вновь возвращаясь из неожиданных мест. Задача может не проходить через лидов или архитекторов, что добавляет треша и угара в попытках расширить архитектуру или впихнуть непвихуемое.

Проблемы при классической схеме

Человеческие ресурсы ограничены наличным количеством и оперативному изменению практически не поддаются. Отсюда проблема простоев и переработок.

Невыгодно держать узких специалистов. Такие спецы уникальный источник знаний, но и расходы на содержание высоки, а задачи редки. Отсюда проблема простоя и застоя в компетенциях.

Люди в командах специализируются на текущих задачах и начинают деградировать если не делают над собой усилий или их не принуждают к таким усилиям.

Найти человека с нужными компетенциями трудно или вообще невозможно за выделенные деньги и время.

Отсутствие документации с описанием проекта для быстрого онбординга новичка.
Необходимость менторов.

Проблема расширения функционала без глубокого анализа такой возможности, а такой анализ возможен только носителем широких компетенций в проекте — архитектором.

Проблема выбывания носителей уникальных знаний по проекту.

Проблема моральной атмосферы в коллективе и личных отношений влияющих на принятие важных решений.

Проблема непрозрачности финансов для заказчика и исполнителей по оплате труда.

Проблема повышения статуса исполнителя и типа выполняемых задач.

Можно ли как-то нивелировать указанные проблемы не меняя парадигму(модель) управления разработкой? Короткий ответ — нет! В дальнейшем такая модель будет тормозить работу, а при увеличении бизнеса и бюрократизации процессов вообще может вынудить к переводу разработки на аутсорс. Хорошо ли это — вынос разработки на аутсорс? — Короткий ответ — да, если это ускорит и облегчит развитие продукта! Может ли быть аутсорс — внутренним для компании? — Легко. А внешним? — тут сложнее, права, безопасность это всё… но возможно! А внутренним и внешним? — Можно и вот как это сделать.

Сервис представляет собой

• Систему коммуникации заказчика и исполнителей.
• Обеспечивает динамическое подключение специалистов с требуемыми компетенциями.
• Осуществляет расчеты с заказчиком и исполнителями.
• Оперативно показывает статус проекта и прогресс по задачам.
• Предоставляет заказчику отчёт о потраченных средствах с детализацией выплат.
• Позволяет войти в сервис с проектом на любом шаге и также выйти из него.
• Контролирует исполнение задач и их качество.
• Позволяет находить узких специалистов для решения задач.
• Позволяет динамически организовывать ресурсы на проекте в зависимости от нагрузки.

Вертикальная иерархия ролей специалистов в сервисе

• Менеджеры проектов. Роль осуществляет общее управление старшими специалистами, коммуникации между ними, разрешение спорных ситуаций, утверждает решения или обосновывает отказ.
• Лидеры направлений. Роль формирует декомпозиционное дерево подзадач и установку их в пул для нижестоящих ролей данной ветви компетенций. “Графика, анимация, дизайн, эффекты” — решает задачи по разработке общих концепций по всему что касается графики и звука. “Экономика и маркетинг” — маркетинговое исследование про спросу на продукт, таргет группы, инвестирование в проект, аналоги, примерные сметы расходов на этапы. “Разработка” — создание программной версии продукта на всех этапах его жизненного цикла, архитектура, сборки пакетов, платформы. “Тестирование” — ручное и автоматизированное. “Юридическое обеспечение” — защита авторских прав и патентные исследования, проверки чистоты сделок с средствами заказчика, обоснование выплат исполнителям в автоматическом режиме. “Игровой дизайн и сценарии” — относится в основном к игровой индустрии, занимаются механиками, фичами, сценами и монетизацией.
• Старший специалист. Роль получает из пула специализированную но всё ещё общую задачу созданную лидерами. Имеет опыт в решении подобных задач, широкую компетенцию в специализации. Может решить задачу сам или оценив сложность исполнения декомпозировать в пул задач для следующей роли.
• Специалист. Роль получает из пула подготовленную задачу не требующую дальнейшей декомпозиции. Задача точно поставлена, оговорены сроки исполнения, необходимые технологии и критерии успешного результата.

Каждая из вышестоящих ролей формирует пул декомпозированных подзадач для нижестоящей, указывает критерии выполнения и стоимость выполнения задачи. Вышестоящая роль не может директивно назначить исполнителя или назначить себя на подзадачу.

Нижестоящая роль при декомпозиции задачи обязана получить подтверждение на своё решение у вышестоящей роли поставившей исходную задачу.

Нижестоящая роль, после получения задачи, может отправить её на ревью постановщику с обоснованием обнаруженных ошибок или неточностей либо открыть спор с арбитражем и голосованием.

Вышестоящая роль может взять задачу любой нижестоящей если не является её(задачи) постановщиком.

Выполненная задача находится в специальном пуле для ревью и утверждения. Ревью задачи может проводить текущая роль(но не исполнитель) или на одну выше и ниже.

За выполненную и утвержденную задачу исполнителю начисляется указанная в задаче оплата (за вычетом комиссии сервиса за транзакцию) и балы рейтинга.

За выполненное ревью с обоснованным указанием об ошибке или отступлении от критериев ревьюиру начисляются балы, а у ревьюируемого они списываются. Споры по результатам ревью решаются автоматически общим голосованием ролей участвовавший в ревью.

Переход к вышестоящей роли происходит автоматически по достижении определённого количества балов у исполнителя. Таким образом можно пройти всю иерархию вплоть до менеджера не решив ни одной задачи, но набрав балы в ревью чужих задач.

Каждая задача и декомпозиционное дерево задач сопровождается созданием набора документов обосновывающих выбор решения и кратко описывающих его. Каждая задача не являющаяся веткой уже существующей, то есть расширение функционала — должна начинаться с утверждения у менеджера и далее проходить утверждения по ролям вплоть до конечного исполнителя.

Задача автоматически считается невыполненной если была взята в работу, но сроки выполнения завершились и от исполнителя не было направлено обоснование на продление сроков.
Невыполненная задача устанавливается обратно в пул задач на выполнение, а исполнителю назначается штраф в виде списания балов.

Набор определённого отрицательного уровня балов ведёт к автоматической блокировке исполнителя по выбранной компетенции.

Отсутствие выполненных задач или ревью за определенный срок ведёт к автоматическому понижению общего бала.

При снижении бала ниже порогового уровня роли происходит переход статуса исполнителя на нижестоящую роль.

Схема движения заказа от заказчика до готового продукта

Заказчик заводит в сервисе проект описывая бизнес задачу (это является первичной информацией). Вносит на свой счёт в сервисе объём средств минимально необходимый для экономико-маркетинговой экспертизы или если она уже есть, то для составления технического задания лидером(разработки, архитектором). Экономическая экспертиза и техническое обоснование включает в себя заключения экспертов о экономической целесообразности данного продукта. Экономическая целесообразность — это исследование аналогов, спроса, доступных ресурсов, практической реализуемости представленное в виде документа с рекомендациями. На следующий этап задача переходит при достаточности средств на счету заказчика в сервисе. Заказчик может предоставить свою экспертизу или ТЗ(техническое задание, архитектуру проекта) на согласование. Если согласование не пройдено, то задача(проект) не может быть взята в разработку. Заказчик может выйти из сервиса на любом шаге или заморозить его в сервисе за отдельную плату. Заказчик имеет доступ на чтение ко всей документации и исходникам по проекту, к сборкам пакета приложения или ресурсов, к прогрессу выполнения проекта и задач, ведомостям по оплате исполнителям.

Разработка ведётся согласно правил установленных на старте проекта, это касается языка составления документов и описаний, соглашению по оформлению кода и самодокументирующимся комментариям. Приоритет в написании классов и функций отдаётся максимально простому и чистому коду. В каждом случае, когда это возможно, код покрывается Unit тестами. В разработке должны быть специалисты обеспечивающие работу контроля версий, автоматической сборки, удалённое подключение исполнителей к необходимому оборудованию на стороне сервиса или заказчика.

Ввод исполнителей в сервис возможен после получения матрицы компетенций. Матрицу компетенций возможно получить в сервисах специализирующихся на тестировании в автоматизированном режиме. Аккредитованные сервисы предоставляют API с помощью которого можно получить матрицу по соискателю. В зависимости от полученных результатов для аккаунта исполнителя устанавливаются стартовые роли и компетенции для которых будут видны специализированные задачи. Резюмируя, исполнитель регистрируется в сервисе и получает ссылку на сервис тестирования компетенций и проходит их. Результаты тестирования заполняют матрицу компетенций и аккаунту открывается возможность брать задачи, проводить ревью, читать документацию доступную для своей роли.

Рекомендуется на первом этапе ввести в сервис оформленных исполнителей на существующей базе “офиса”. Проверить работу с заказчиком в реальных проектах. Провести рекламную компанию в специализированных сообществах и соцсетях с тезисами — “Полная прозрачность и честность, никаких секретов. Работай над чем хочешь, откуда хочешь и тогда когда хочешь. Тебе никто не приказывает. Заработай сколько сможешь унести, никаких ограничений для всех и навсегда. ”

Вопросы требующие отдельной проработки

• Безопасносность.
• Оплата и расчёты с заказчиком и исполнителями.
• Юридические вопросы до договорам с заказчиком и сдельной оплате исполнителям, трансграничные переводы.
• Защита авторского права.