[IT-инфраструктура, ERP-системы, CRM-системы, Управление проектами, Управление продуктом] Новый формат отдела разработки ПО
Автор
Сообщение
news_bot ®
Стаж: 6 лет 9 месяцев
Сообщений: 27286
В начале зафиксируем, что имеем сейчас по разработке ПО, какие есть проблемы и к чему необходимо прийти.
Классическая схема отдела такая — народ сидит в офисе (ну или как сейчас на удалёнке) за повременную оплату (8 часов в день) или в бодишопах на почасовке. Добираются на работу в течении 30 — 120 минут. Найм человека происходит через hh или похожие сайты, кандидат проходит hr’а, техсобес где пытаются составить матрицу компетенций. В Москве кандидатов много с любым уровнем знаний, в регионах с этим проблема. Если нет технического вуза поблизости, а бизнес вести хочется, едь в ближайший миллионник и плати местные зарплаты. Последнее для стартапа особенно неприятно. Хорошо если на проекте куда взяли человека существует и ведётся документация по решениям с описанием схем движения данных и т.д., но я такого не встречал ни разу. Бывают обрывки, хаотично ведущиеся записи, протоколы собраний с обоснованиями принятых решений, но систематически ведущаяся документация по разработке — это как двойное затмение луны. Зачем нужна документация со схемами и обоснованиями? Когда архитектор набрасывает макет будущего проекта, то он является носителем уникальных знаний которых нет больше ни у кого. Это серьёзная проблема, если спец заболеет, погибнет, уйдёт — то с ним уйдут и компетенции. Восстановление компетенций без документации и носителя знаний настолько нетривиальная задача, что проще переписать всё заново (и то и другое большие деньги). Ввод в проект нового бойца или старого с другого проекта — это полгода наставничества и отвлечения внимания уже работающих. При этом новая единица тоже ограниченно функциональна по большему счёту. Система постановки задачи может ветвиться, разделяться на подзадачи и сливаться вновь возвращаясь из неожиданных мест. Задача может не проходить через лидов или архитекторов, что добавляет треша и угара в попытках расширить архитектуру или впихнуть непвихуемое.
Проблемы при классической схеме
Человеческие ресурсы ограничены наличным количеством и оперативному изменению практически не поддаются. Отсюда проблема простоев и переработок.
Невыгодно держать узких специалистов. Такие спецы уникальный источник знаний, но и расходы на содержание высоки, а задачи редки. Отсюда проблема простоя и застоя в компетенциях.
Люди в командах специализируются на текущих задачах и начинают деградировать если не делают над собой усилий или их не принуждают к таким усилиям.
Найти человека с нужными компетенциями трудно или вообще невозможно за выделенные деньги и время.
Отсутствие документации с описанием проекта для быстрого онбординга новичка. Необходимость менторов.
Проблема расширения функционала без глубокого анализа такой возможности, а такой анализ возможен только носителем широких компетенций в проекте — архитектором.
Проблема выбывания носителей уникальных знаний по проекту.
Проблема моральной атмосферы в коллективе и личных отношений влияющих на принятие важных решений.
Проблема непрозрачности финансов для заказчика и исполнителей по оплате труда.
Проблема повышения статуса исполнителя и типа выполняемых задач.
Можно ли как-то нивелировать указанные проблемы не меняя парадигму(модель) управления разработкой? Короткий ответ — нет! В дальнейшем такая модель будет тормозить работу, а при увеличении бизнеса и бюрократизации процессов вообще может вынудить к переводу разработки на аутсорс. Хорошо ли это — вынос разработки на аутсорс? — Короткий ответ — да, если это ускорит и облегчит развитие продукта! Может ли быть аутсорс — внутренним для компании? — Легко. А внешним? — тут сложнее, права, безопасность это всё… но возможно! А внутренним и внешним? — Можно и вот как это сделать.
Сервис представляет собой
- Систему коммуникации заказчика и исполнителей.
- Обеспечивает динамическое подключение специалистов с требуемыми компетенциями.
- Осуществляет расчеты с заказчиком и исполнителями.
- Оперативно показывает статус проекта и прогресс по задачам.
- Предоставляет заказчику отчёт о потраченных средствах с детализацией выплат.
- Позволяет войти в сервис с проектом на любом шаге и также выйти из него.
- Контролирует исполнение задач и их качество.
- Позволяет находить узких специалистов для решения задач.
- Позволяет динамически организовывать ресурсы на проекте в зависимости от нагрузки.
Вертикальная иерархия ролей специалистов в сервисе
- Менеджеры проектов. Роль осуществляет общее управление старшими специалистами, коммуникации между ними, разрешение спорных ситуаций, утверждает решения или обосновывает отказ.
- Лидеры направлений. Роль формирует декомпозиционное дерево подзадач и установку их в пул для нижестоящих ролей данной ветви компетенций. “Графика, анимация, дизайн, эффекты” — решает задачи по разработке общих концепций по всему что касается графики и звука. “Экономика и маркетинг” — маркетинговое исследование про спросу на продукт, таргет группы, инвестирование в проект, аналоги, примерные сметы расходов на этапы. “Разработка” — создание программной версии продукта на всех этапах его жизненного цикла, архитектура, сборки пакетов, платформы. “Тестирование” — ручное и автоматизированное. “Юридическое обеспечение” — защита авторских прав и патентные исследования, проверки чистоты сделок с средствами заказчика, обоснование выплат исполнителям в автоматическом режиме. “Игровой дизайн и сценарии” — относится в основном к игровой индустрии, занимаются механиками, фичами, сценами и монетизацией.
- Старший специалист. Роль получает из пула специализированную но всё ещё общую задачу созданную лидерами. Имеет опыт в решении подобных задач, широкую компетенцию в специализации. Может решить задачу сам или оценив сложность исполнения декомпозировать в пул задач для следующей роли.
- Специалист. Роль получает из пула подготовленную задачу не требующую дальнейшей декомпозиции. Задача точно поставлена, оговорены сроки исполнения, необходимые технологии и критерии успешного результата.
Каждая из вышестоящих ролей формирует пул декомпозированных подзадач для нижестоящей, указывает критерии выполнения и стоимость выполнения задачи. Вышестоящая роль не может директивно назначить исполнителя или назначить себя на подзадачу.
Нижестоящая роль при декомпозиции задачи обязана получить подтверждение на своё решение у вышестоящей роли поставившей исходную задачу.
Нижестоящая роль, после получения задачи, может отправить её на ревью постановщику с обоснованием обнаруженных ошибок или неточностей либо открыть спор с арбитражем и голосованием.
Вышестоящая роль может взять задачу любой нижестоящей если не является её(задачи) постановщиком.
Выполненная задача находится в специальном пуле для ревью и утверждения. Ревью задачи может проводить текущая роль(но не исполнитель) или на одну выше и ниже.
За выполненную и утвержденную задачу исполнителю начисляется указанная в задаче оплата (за вычетом комиссии сервиса за транзакцию) и балы рейтинга.
За выполненное ревью с обоснованным указанием об ошибке или отступлении от критериев ревьюиру начисляются балы, а у ревьюируемого они списываются. Споры по результатам ревью решаются автоматически общим голосованием ролей участвовавший в ревью.
Переход к вышестоящей роли происходит автоматически по достижении определённого количества балов у исполнителя. Таким образом можно пройти всю иерархию вплоть до менеджера не решив ни одной задачи, но набрав балы в ревью чужих задач.
Каждая задача и декомпозиционное дерево задач сопровождается созданием набора документов обосновывающих выбор решения и кратко описывающих его. Каждая задача не являющаяся веткой уже существующей, то есть расширение функционала — должна начинаться с утверждения у менеджера и далее проходить утверждения по ролям вплоть до конечного исполнителя.
Задача автоматически считается невыполненной если была взята в работу, но сроки выполнения завершились и от исполнителя не было направлено обоснование на продление сроков.
Невыполненная задача устанавливается обратно в пул задач на выполнение, а исполнителю назначается штраф в виде списания балов.
Набор определённого отрицательного уровня балов ведёт к автоматической блокировке исполнителя по выбранной компетенции.
Отсутствие выполненных задач или ревью за определенный срок ведёт к автоматическому понижению общего бала.
При снижении бала ниже порогового уровня роли происходит переход статуса исполнителя на нижестоящую роль.
Схема движения заказа от заказчика до готового продукта
Заказчик заводит в сервисе проект описывая бизнес задачу (это является первичной информацией). Вносит на свой счёт в сервисе объём средств минимально необходимый для экономико-маркетинговой экспертизы или если она уже есть, то для составления технического задания лидером(разработки, архитектором). Экономическая экспертиза и техническое обоснование включает в себя заключения экспертов о экономической целесообразности данного продукта. Экономическая целесообразность — это исследование аналогов, спроса, доступных ресурсов, практической реализуемости представленное в виде документа с рекомендациями. На следующий этап задача переходит при достаточности средств на счету заказчика в сервисе. Заказчик может предоставить свою экспертизу или ТЗ(техническое задание, архитектуру проекта) на согласование. Если согласование не пройдено, то задача(проект) не может быть взята в разработку. Заказчик может выйти из сервиса на любом шаге или заморозить его в сервисе за отдельную плату. Заказчик имеет доступ на чтение ко всей документации и исходникам по проекту, к сборкам пакета приложения или ресурсов, к прогрессу выполнения проекта и задач, ведомостям по оплате исполнителям.
Разработка ведётся согласно правил установленных на старте проекта, это касается языка составления документов и описаний, соглашению по оформлению кода и самодокументирующимся комментариям. Приоритет в написании классов и функций отдаётся максимально простому и чистому коду. В каждом случае, когда это возможно, код покрывается Unit тестами. В разработке должны быть специалисты обеспечивающие работу контроля версий, автоматической сборки, удалённое подключение исполнителей к необходимому оборудованию на стороне сервиса или заказчика.
Ввод исполнителей в сервис возможен после получения матрицы компетенций. Матрицу компетенций возможно получить в сервисах специализирующихся на тестировании в автоматизированном режиме. Аккредитованные сервисы предоставляют API с помощью которого можно получить матрицу по соискателю. В зависимости от полученных результатов для аккаунта исполнителя устанавливаются стартовые роли и компетенции для которых будут видны специализированные задачи. Резюмируя, исполнитель регистрируется в сервисе и получает ссылку на сервис тестирования компетенций и проходит их. Результаты тестирования заполняют матрицу компетенций и аккаунту открывается возможность брать задачи, проводить ревью, читать документацию доступную для своей роли.
Рекомендуется на первом этапе ввести в сервис оформленных исполнителей на существующей базе “офиса”. Проверить работу с заказчиком в реальных проектах. Провести рекламную компанию в специализированных сообществах и соцсетях с тезисами — “Полная прозрачность и честность, никаких секретов. Работай над чем хочешь, откуда хочешь и тогда когда хочешь. Тебе никто не приказывает. Заработай сколько сможешь унести, никаких ограничений для всех и навсегда. ”
Вопросы требующие отдельной проработки
- Безопасносность.
- Оплата и расчёты с заказчиком и исполнителями.
- Юридические вопросы до договорам с заказчиком и сдельной оплате исполнителям, трансграничные переводы.
- Защита авторского права.
===========
Источник:
habr.com
===========
Похожие новости:
- [Управление продуктом] Product Manager & Product Designer: поиск сходств и отличий
- [*nix, Управление проектами, Венчурные инвестиции, Бизнес-модели, Финансы в IT] Apple 4:1 – не упустите шанс заработать
- [Анализ и проектирование систем, Проектирование и рефакторинг, Управление продуктом] Смешение уровней абстракции закладывает бомбу в основание вашего проекта
- [IT-инфраструктура, Серверное администрирование, Облачные сервисы, IT-компании] Боли стартапов: как правильно развивать ИТ-инфраструктуру
- [Тестирование веб-сервисов, Управление проектами, Развитие стартапа, Будущее здесь, IT-компании] Определились победители открытого конкурса готовых цифровых решений «Инновации против кризиса»
- [Управление проектами, Управление персоналом, IT-компании] Простые средства информирования внутри компании
- [IT-инфраструктура, Периферия] «Чёрный ящик» для вашего офиса
- [Системное администрирование, IT-инфраструктура, Nginx, DevOps] Как случайно продолжить писать Web-GUI для Haproxy
- [Разработка веб-сайтов, Программирование, ReactJS, Управление проектами] Как не закопаться в рефакторинге на фронте. Советы новичку
- [Big Data, Разработка для интернета вещей, Управление проектами, Облачные сервисы] Мониторинг производственного оборудования: как с этим дела в России
Теги для поиска: #_itinfrastruktura (IT-инфраструктура), #_erpsistemy (ERP-системы), #_crmsistemy (CRM-системы), #_upravlenie_proektami (Управление проектами), #_upravlenie_produktom (Управление продуктом), #_upravlenie_personalom (управление персоналом), #_upravlenie_proektami (управление проектами), #_upravlenie_razrabotkoj (управление разработкой), #_itinfrastruktura (
IT-инфраструктура
), #_erpsistemy (
ERP-системы
), #_crmsistemy (
CRM-системы
), #_upravlenie_proektami (
Управление проектами
), #_upravlenie_produktom (
Управление продуктом
)
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:54
Часовой пояс: UTC + 5
| Автор | Сообщение |
|---|---|
|
news_bot ®
Стаж: 6 лет 9 месяцев |
|
|
В начале зафиксируем, что имеем сейчас по разработке ПО, какие есть проблемы и к чему необходимо прийти. Классическая схема отдела такая — народ сидит в офисе (ну или как сейчас на удалёнке) за повременную оплату (8 часов в день) или в бодишопах на почасовке. Добираются на работу в течении 30 — 120 минут. Найм человека происходит через hh или похожие сайты, кандидат проходит hr’а, техсобес где пытаются составить матрицу компетенций. В Москве кандидатов много с любым уровнем знаний, в регионах с этим проблема. Если нет технического вуза поблизости, а бизнес вести хочется, едь в ближайший миллионник и плати местные зарплаты. Последнее для стартапа особенно неприятно. Хорошо если на проекте куда взяли человека существует и ведётся документация по решениям с описанием схем движения данных и т.д., но я такого не встречал ни разу. Бывают обрывки, хаотично ведущиеся записи, протоколы собраний с обоснованиями принятых решений, но систематически ведущаяся документация по разработке — это как двойное затмение луны. Зачем нужна документация со схемами и обоснованиями? Когда архитектор набрасывает макет будущего проекта, то он является носителем уникальных знаний которых нет больше ни у кого. Это серьёзная проблема, если спец заболеет, погибнет, уйдёт — то с ним уйдут и компетенции. Восстановление компетенций без документации и носителя знаний настолько нетривиальная задача, что проще переписать всё заново (и то и другое большие деньги). Ввод в проект нового бойца или старого с другого проекта — это полгода наставничества и отвлечения внимания уже работающих. При этом новая единица тоже ограниченно функциональна по большему счёту. Система постановки задачи может ветвиться, разделяться на подзадачи и сливаться вновь возвращаясь из неожиданных мест. Задача может не проходить через лидов или архитекторов, что добавляет треша и угара в попытках расширить архитектуру или впихнуть непвихуемое. Проблемы при классической схеме Человеческие ресурсы ограничены наличным количеством и оперативному изменению практически не поддаются. Отсюда проблема простоев и переработок. Невыгодно держать узких специалистов. Такие спецы уникальный источник знаний, но и расходы на содержание высоки, а задачи редки. Отсюда проблема простоя и застоя в компетенциях. Люди в командах специализируются на текущих задачах и начинают деградировать если не делают над собой усилий или их не принуждают к таким усилиям. Найти человека с нужными компетенциями трудно или вообще невозможно за выделенные деньги и время. Отсутствие документации с описанием проекта для быстрого онбординга новичка. Необходимость менторов. Проблема расширения функционала без глубокого анализа такой возможности, а такой анализ возможен только носителем широких компетенций в проекте — архитектором. Проблема выбывания носителей уникальных знаний по проекту. Проблема моральной атмосферы в коллективе и личных отношений влияющих на принятие важных решений. Проблема непрозрачности финансов для заказчика и исполнителей по оплате труда. Проблема повышения статуса исполнителя и типа выполняемых задач. Можно ли как-то нивелировать указанные проблемы не меняя парадигму(модель) управления разработкой? Короткий ответ — нет! В дальнейшем такая модель будет тормозить работу, а при увеличении бизнеса и бюрократизации процессов вообще может вынудить к переводу разработки на аутсорс. Хорошо ли это — вынос разработки на аутсорс? — Короткий ответ — да, если это ускорит и облегчит развитие продукта! Может ли быть аутсорс — внутренним для компании? — Легко. А внешним? — тут сложнее, права, безопасность это всё… но возможно! А внутренним и внешним? — Можно и вот как это сделать. Сервис представляет собой
Вертикальная иерархия ролей специалистов в сервисе
Каждая из вышестоящих ролей формирует пул декомпозированных подзадач для нижестоящей, указывает критерии выполнения и стоимость выполнения задачи. Вышестоящая роль не может директивно назначить исполнителя или назначить себя на подзадачу. Нижестоящая роль при декомпозиции задачи обязана получить подтверждение на своё решение у вышестоящей роли поставившей исходную задачу. Нижестоящая роль, после получения задачи, может отправить её на ревью постановщику с обоснованием обнаруженных ошибок или неточностей либо открыть спор с арбитражем и голосованием. Вышестоящая роль может взять задачу любой нижестоящей если не является её(задачи) постановщиком. Выполненная задача находится в специальном пуле для ревью и утверждения. Ревью задачи может проводить текущая роль(но не исполнитель) или на одну выше и ниже. За выполненную и утвержденную задачу исполнителю начисляется указанная в задаче оплата (за вычетом комиссии сервиса за транзакцию) и балы рейтинга. За выполненное ревью с обоснованным указанием об ошибке или отступлении от критериев ревьюиру начисляются балы, а у ревьюируемого они списываются. Споры по результатам ревью решаются автоматически общим голосованием ролей участвовавший в ревью. Переход к вышестоящей роли происходит автоматически по достижении определённого количества балов у исполнителя. Таким образом можно пройти всю иерархию вплоть до менеджера не решив ни одной задачи, но набрав балы в ревью чужих задач. Каждая задача и декомпозиционное дерево задач сопровождается созданием набора документов обосновывающих выбор решения и кратко описывающих его. Каждая задача не являющаяся веткой уже существующей, то есть расширение функционала — должна начинаться с утверждения у менеджера и далее проходить утверждения по ролям вплоть до конечного исполнителя. Задача автоматически считается невыполненной если была взята в работу, но сроки выполнения завершились и от исполнителя не было направлено обоснование на продление сроков. Невыполненная задача устанавливается обратно в пул задач на выполнение, а исполнителю назначается штраф в виде списания балов. Набор определённого отрицательного уровня балов ведёт к автоматической блокировке исполнителя по выбранной компетенции. Отсутствие выполненных задач или ревью за определенный срок ведёт к автоматическому понижению общего бала. При снижении бала ниже порогового уровня роли происходит переход статуса исполнителя на нижестоящую роль. Схема движения заказа от заказчика до готового продукта Заказчик заводит в сервисе проект описывая бизнес задачу (это является первичной информацией). Вносит на свой счёт в сервисе объём средств минимально необходимый для экономико-маркетинговой экспертизы или если она уже есть, то для составления технического задания лидером(разработки, архитектором). Экономическая экспертиза и техническое обоснование включает в себя заключения экспертов о экономической целесообразности данного продукта. Экономическая целесообразность — это исследование аналогов, спроса, доступных ресурсов, практической реализуемости представленное в виде документа с рекомендациями. На следующий этап задача переходит при достаточности средств на счету заказчика в сервисе. Заказчик может предоставить свою экспертизу или ТЗ(техническое задание, архитектуру проекта) на согласование. Если согласование не пройдено, то задача(проект) не может быть взята в разработку. Заказчик может выйти из сервиса на любом шаге или заморозить его в сервисе за отдельную плату. Заказчик имеет доступ на чтение ко всей документации и исходникам по проекту, к сборкам пакета приложения или ресурсов, к прогрессу выполнения проекта и задач, ведомостям по оплате исполнителям. Разработка ведётся согласно правил установленных на старте проекта, это касается языка составления документов и описаний, соглашению по оформлению кода и самодокументирующимся комментариям. Приоритет в написании классов и функций отдаётся максимально простому и чистому коду. В каждом случае, когда это возможно, код покрывается Unit тестами. В разработке должны быть специалисты обеспечивающие работу контроля версий, автоматической сборки, удалённое подключение исполнителей к необходимому оборудованию на стороне сервиса или заказчика. Ввод исполнителей в сервис возможен после получения матрицы компетенций. Матрицу компетенций возможно получить в сервисах специализирующихся на тестировании в автоматизированном режиме. Аккредитованные сервисы предоставляют API с помощью которого можно получить матрицу по соискателю. В зависимости от полученных результатов для аккаунта исполнителя устанавливаются стартовые роли и компетенции для которых будут видны специализированные задачи. Резюмируя, исполнитель регистрируется в сервисе и получает ссылку на сервис тестирования компетенций и проходит их. Результаты тестирования заполняют матрицу компетенций и аккаунту открывается возможность брать задачи, проводить ревью, читать документацию доступную для своей роли. Рекомендуется на первом этапе ввести в сервис оформленных исполнителей на существующей базе “офиса”. Проверить работу с заказчиком в реальных проектах. Провести рекламную компанию в специализированных сообществах и соцсетях с тезисами — “Полная прозрачность и честность, никаких секретов. Работай над чем хочешь, откуда хочешь и тогда когда хочешь. Тебе никто не приказывает. Заработай сколько сможешь унести, никаких ограничений для всех и навсегда. ” Вопросы требующие отдельной проработки
=========== Источник: habr.com =========== Похожие новости:
IT-инфраструктура ), #_erpsistemy ( ERP-системы ), #_crmsistemy ( CRM-системы ), #_upravlenie_proektami ( Управление проектами ), #_upravlenie_produktom ( Управление продуктом ) |
|
Вы не можете начинать темы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Вы не можете отвечать на сообщения
Вы не можете редактировать свои сообщения
Вы не можете удалять свои сообщения
Вы не можете голосовать в опросах
Вы не можете прикреплять файлы к сообщениям
Вы не можете скачивать файлы
Текущее время: 22-Ноя 14:54
Часовой пояс: UTC + 5