Вначале мы обрисуем, что мы имеем сейчас в разработке программного обеспечения, какие есть проблемы и чего необходимо добиться.
Классическая схема отдела такая: люди сидят в офисе (или, как сейчас, удаленно) за повременную оплату (8 часов в день) или в кузовных цехах с почасовой оплатой.
Они приступают к работе в течение 30–120 минут. Человека нанимают через hh или подобные сайты, кандидат проходит HR, техническую безопасность, где пытаются создать матрицу компетенций.
В Москве много кандидатов с любым уровнем знаний, а вот в регионах с этим проблема.
Если поблизости нет технического вуза, но хочется заняться бизнесом, езжайте в ближайший город-миллионник и платите там зарплату.
Последнее особенно неприятно для стартапа.
Хорошо, если проект, куда наняли человека, существует и ведет документацию по решениям, описывающим закономерности потоков данных и т. д., но я такого ни разу не видел.
Есть обрывки, хаотично хранящиеся записи, протоколы совещаний с обоснованиями принятых решений, но систематически ведущаяся документация разработки подобна двойному лунному затмению.
Зачем нужна документация со схемами и обоснованиями? Когда архитектор рисует модель будущего проекта, он является носителем уникальных знаний, которых нет ни у кого.
Это серьезная проблема; если специалист заболеет, умрет или уйдет, то его компетенции уйдут вместе с ним.
Восстановление компетенций без документации и носителя знаний — настолько нетривиальная задача, что проще все переписать с нуля (и то, и другое стоит больших денег).
Привести в проект нового бойца или старого из другого проекта — это полгода наставничества и отвлечения внимания уже работающих.
Более того, новый агрегат еще и по большому счету ограничен по функциональности.
Система постановки задач может разветвляться, разбиваться на подзадачи и снова сливаться, возвращаясь из неожиданных мест. Задача может не пройти через лидов или архитекторов, что добавляет хлама и суеты в попытках расширить архитектуру или впихнуть в нее то, что невозможно впихнуть.
Проблемы классической схемы
Человеческие ресурсы ограничены имеющимся количеством и практически не поддаются оперативным изменениям.Отсюда и проблема простоев и сверхурочной работы.
Содержать узких специалистов невыгодно.
Такие специалисты являются уникальным источником знаний, но затраты на содержание высоки, а задачи выполняются редко.
Отсюда и проблема простоев и застоя в компетенциях.
Люди в командах специализируются на текущих задачах и начинают деградировать, если не прилагают усилий над собой или их не заставляют прилагать такие усилия.
Найти человека с необходимыми компетенциями сложно или даже невозможно за выделенные деньги и время.
Отсутствие документации, описывающей проект для быстрого адаптации новичка.
Потребность в наставниках.
Проблема в расширении функционала без глубокого анализа этой возможности, а такой анализ возможен только человеком с широкими компетенциями в проекте - архитектором.
Проблема истощения уникальных носителей знаний для проекта.
Проблема моральной атмосферы в коллективе и личных взаимоотношений, влияющая на принятие важных решений.
Проблема финансовой непрозрачности для заказчика и подрядчиков по расчету заработной платы.
Проблема повышения статуса исполнителя и типа выполняемых задач.
Можно ли как-то смягчить эти проблемы, не меняя парадигму (модель) управления разработкой? Короткий ответ - нет! В будущем такая модель будет тормозить работу, а при росте бизнеса и бюрократизации процессов может вообще вынудить аутсорсинг разработки.
Выгодно ли отдавать разработку на аутсорсинг? — Короткий ответ — да, если это ускорит и облегчит разработку продукта! Может ли аутсорсинг быть внутренним для компании? - Легко.
А как насчет внешних? - тут сложнее, права, безопасность превыше всего.
но это возможно! А как насчет внутреннего и внешнего? - Это возможно и вот как это сделать.
Услуга
- Система коммуникации между заказчиком и исполнителями.
- Обеспечивает динамическое подключение специалистов с необходимыми компетенциями.
- Осуществляет расчеты с заказчиком и подрядчиками.
- Быстро показывает статус проекта и ход выполнения задач.
- Предоставляет клиенту отчет о потраченных средствах с детализацией платежей.
- Позволяет войти в сервис с проектом на любом этапе, а также выйти из него.
- Контролирует выполнение заданий и их качество.
- Позволяет найти профильных специалистов для решения проблем.
- Позволяет динамически организовывать ресурсы проекта в зависимости от нагрузки.
Вертикальная иерархия ролей специалистов в службе
- Менеджеры проекта.
Роль осуществляет общее руководство старшими специалистами, коммуникации между ними, разрешение спорных ситуаций, утверждение решений или обоснование отказов.
- Лидеры направлений.
Роль формирует дерево декомпозиции подзадач и установку их в пул для ролей нижнего уровня данной ветки компетенции.
«Графика, анимация, дизайн, эффекты» — решает задачу разработки общих концепций всего, что связано с графикой и звуком.
«Экономика и маркетинг» - маркетинговое исследование о спросе на продукт, целевой группе, инвестициях в проект, аналогах, примерная смета затрат по этапам.
«Разработка» — создание программной версии продукта на всех этапах его жизненного цикла, архитектуры, сборки пакетов, платформ.
«Тестирование» – ручное и автоматизированное.
«Юридическое сопровождение» — защита авторских прав и патентные исследования, проверка чистоты операций со средствами клиентов, обоснованность выплат исполнителям в автоматическом режиме.
«Игровой дизайн и сценарии» — относится в основном к игровой индустрии, занимающейся механикой, функциями, сценами и монетизацией.
- Старший специалист. Роль получает из пула специализированную, но все же общую задачу, созданную лидерами.
Имеет опыт решения подобных задач, широкую компетенцию по специализации.
Может решить задачу сам или, оценив сложность исполнения, разложить ее на пул задач для следующей роли.
- Специалист. Роль получает из пула подготовленную задачу, не требующую дальнейшей декомпозиции.
Точно определена задача, указаны сроки выполнения, необходимые технологии и критерии успешного результата.
Вышестоящая роль не может напрямую назначить исполнителя или назначить себя подзадаче.
При декомпозиции задачи подчиненная роль должна получить подтверждение своего решения от вышестоящей роли, поставившей исходную задачу.
Роль нижнего уровня после получения задания может отправить его на рассмотрение директору с обоснованием обнаруженных ошибок или неточностей или открыть спор с арбитражем и голосованием.
Высшая роль может взять на себя задачу любой низшей, если она не является ее (задачой) создателем.
Выполненная задача помещается в специальный пул для рассмотрения и утверждения.
Обзор задачи может осуществляться текущим должностным лицом (но не исполнителем) или выше и ниже.
За выполненное и одобренное задание исполнителю начисляется указанная в задании оплата (за вычетом комиссии сервиса за транзакцию) и баллы рейтинга.
За завершенную рецензию с обоснованным указанием на ошибку или отклонение от критериев рецензенту начисляются баллы, которые снимаются с рецензента.
Споры по результатам проверки решаются автоматически путем общего голосования ролей, участвующих в проверке.
Переход на более высокую роль происходит автоматически при достижении исполнителем определенного количества баллов.
Таким образом можно пройти всю иерархию вплоть до руководителя, не решая ни одной проблемы, но набирая очки при рассмотрении чужих проблем.
Каждая задача и дерево декомпозиции задач сопровождается созданием набора документов, обосновывающих выбор решения и кратко его описывающих.
Каждая задача, не являющаяся ответвлением существующей, то есть расширением функционала, должна начинаться с утверждения менеджером и далее проходить согласование по ролям до конечного исполнителя.
Задача автоматически считается невыполненной, если она была принята, но срок выполнения истек и подрядчик не прислал обоснование продления срока.
Невыполненное задание возвращается в пул заданий для выполнения, а исполнителю назначается штраф в виде списания баллов.
Приобретение определенного отрицательного уровня баллов приводит к автоматической блокировке исполнителя по выбранной компетенции.
Отсутствие выполненных заданий или отзывов в течение определенного периода времени приводит к автоматическому снижению общего балла.
При снижении балла ниже порогового уровня роли статус исполнителя переходит на более низкую роль.
Схема движения заказа от заказчика до готового изделия
Заказчик создает в сервисе проект с описанием бизнес-задачи (это первичная информация).Вносит на ваш счет в сервисе минимальную сумму средств, необходимую для экономической и маркетинговой экспертизы или, если она уже есть, то для подготовки технического задания руководителем (разработчиком, архитектором).
«Экономическая экспертиза и техническое обоснование включает в себя экспертные заключения об экономической целесообразности данной продукции.
Экономическое обоснование – это исследование аналогов, спроса, имеющихся ресурсов, практической осуществимости, представленное в виде документа с рекомендациями.
Задача переходит на следующий этап при наличии достаточных средств на счету клиента в сервисе.
Заказчик может предоставить на согласование свою экспертизу или техническое задание (техническое задание, архитектуру проекта).
Если согласование не пройдено, то задачу (проект) нельзя взять в разработку.
Клиент может выйти из сервиса на любом этапе или заморозить его в сервисе за определенную плату.
Заказчик имеет доступ на чтение ко всей документации и исходникам по проекту, к сборкам пакета приложения или ресурсам, к ходу проекта и задачам, а также ведомостям об оплате исполнителей.
Разработка ведется в соответствии с правилами, установленными на старте проекта, это касается языка оформления документов и описаний, соглашения о форматировании кода и самодокументируемых комментариев.
Приоритет при написании классов и функций отдается максимально простому и чистому коду.
В каждом случае, где это возможно, код покрывается модульными тестами.
В команде разработчиков должны быть специалисты, обеспечивающие контроль версий, автоматическую сборку и удаленное подключение исполнителей к необходимому оборудованию на стороне сервиса или заказчика.
Ввод исполнителей в сервис возможен после получения матрицы компетенций.
Матрицу компетенций можно получить в сервисах, специализирующихся на автоматизированном тестировании.
Аккредитованные сервисы предоставляют API, с помощью которого можно получить матрицу для заявителя.
В зависимости от полученных результатов на аккаунте исполнителя устанавливаются стартовые роли и компетенции, для которых будут видны специализированные задания.
Подводя итог, исполнитель регистрируется в сервисе, получает ссылку на сервис тестирования компетенций и проходит их.
Результаты тестирования заполняют матрицу компетенций, и у учетной записи есть возможность брать задания, проводить обзоры и читать документацию, доступную для ее роли.
Рекомендуется на первом этапе ввести в сервис зарегистрированных исполнителей на существующей «офисной» базе.
Проверьте работу с заказчиком на реальных проектах.
Провести рекламную кампанию в профильных сообществах и социальных сетях с тезисом – «Полная прозрачность и честность, никаких секретов.
Работайте над чем хотите, где хотите и когда хотите.
Никто тебе не приказывает. Зарабатывайте столько, сколько сможете унести, никаких ограничений для всех, навсегда.
»
Вопросы, требующие отдельного изучения
- Безопасность.
- Оплата и расчеты с заказчиком и исполнителями.
- Юридические вопросы по договорам с заказчиком и сдельной оплате исполнителям, трансграничным переводам.
- Защита авторских прав.
-
Парсинг: Oom На Узле Kubernetes
19 Oct, 24 -
Еженедельный Подкаст №70
19 Oct, 24 -
Триллиан Астра: Концепция Im
19 Oct, 24
