Привет. Недавно начал руководить небольшой командой разработчиков и начал задумываться над разными типами управления проектом. Надумал такую вещь:
Есть некоторые задачи, которые нужно выполнить. Мы делим из на группы типа: "HTML, CSS", "UX Design" и т.д. Члены моей команды заходят на сайт и если они занимаются веб-разработкой, то получают задания типа HTML, CSS в виде большого листа. Для каждого задания есть уровень сложности, описание, вознаграждение (будь то деньги или какая-то внутренняя валюта, думаю, это добавит соревновательный момент). Человек выбирает ту задачу, которая ему нравится больше, она удаляется из общего списка и он ее спокойно выполняет. Тобишь выходит таск менеджер для определенной группы людей, которые работают в одном направлении. Лист с заданиями, естественно, выводится по приоритету выполнения и ограничивается сроками.
В моей команде это работало бы отлично. Но это исключительно для моей задачи. Как думаете, будет ли такая система работать в крупных командах в разных сферах IT? Надеюсь, смог описать свою мысль.
Да. Будет работать 100%.
Остался лишь один вопрос: насколько эффективно?!
Описанное Вами можно называть "пулом распределения задач" (или "стеком разбора проектных зависимых задач").
Т.е., это ситуация, когда: есть дерево, есть зависимости и есть сферы работ.
Вытащить на данном этапе (взять задачу в работу) - можно только ту, которую можно!
Т.е., своего рода аналог правил игры в маджонг.
Но здесь нужно думать глубже:
1. Что будет, если останется задача, которую никто не захочет брать?!
2. Что будет, если человек не смог справиться со своей задачей, он остановил весь проект? (например, это разработка внутренней информационной шины API, которая имеет тучу зависимостей)
и т.д.
Sanes: если люди могут САМИ разбирать задачи, то это уже режим иной: с минимальным участием руководителя, а если еще система тестирования каждого этапа есть или отдельный отдел службы контроля качества работ - то....
Sanes, Действительно, в пуле будут появляться задачи в зависимости от того, какие задания были выполнены у другой группы разработчиков и того, что можно выполнить на данном этапе. Я, как организатор, прописываю все задачи по проекту заранее. Делаю между ними связи, типа: "После выполненного задания НАРИСОВАТЬ КАРТИНКУ и выполненного задания СОЗДАТЬ ШРИФТ программистам поступает в пул задача СДЕЛАТЬ ШАПКУ САЙТА". Остается вопрос о том, что будет если задача не выполняется никем - повысить для нее те самые баллы. Они могут конвертироваться потом в премии или другие вознаграждения.
Гриша Никольский: xmoonlight: Это называется страдание ерундой. Ничего само-собой работать не будет. Проще и быстрей назначить ответственного, а потом с него спросить результат.
Вы сейчас описали фриланс-биржу внутри команды.
xmoonlight: Не получится так структурировать. Практически всегда будет несостыковка по разным моментам. Компетенция, время и т.п.
Не забывайте, что недостаточно сделать, надо свое поделие поддерживать, хотя бы на этапе разработки проекта и гарантийного срока.
xmoonlight: Как по вашему мнению, если платить разработчикам только после выполнения всех задач, то можно будет добиться нужного результата (выполнение проекта)?
Гриша Никольский: Нет, никогда...
Вы никогда не должны использовать барское плечо и делать подачки!
Всегда должны быть равные права между работником и работодателем!
И только тогда будет успех!
По-моему, самая лучшая система управления проектом это когда менеджер ищет исполнителя на работу и они договариваются сколько это будет стоить. Что там под капотом, не важно. Фундаментально это правило должно быть соблюдено. У меня работа и деньги, у тебя навыки делать эту работу. Если это правило соблюдается хорошо и нет дисгармонии в коллективе и ресурсах, то можно начинать думать о каких то методологиях, практиках. Но как показывает практика, подавляющее большинство IT компаний не имеют отработанного костяка именно в этом базовом правиле. При этом у них может быть множество дорогих сотрудников и инструментов но все в большой дисгармонии и не работает так как хотелось бы.
Я бы рекомендовал научится делать Рефлексию, что бы грамотно разобраться в своих желаниях и желаниях коллектива и найти решения как всего достичь. И не забыть о стратегическом планировании, попробовать использовать Канву Бизнес Модели и посмотреть на вашу стратегию.
Начинайте с фундамента, судя по вопросу, он у вас не построен.
Простой
