Самоорганизующаяся команда фрилансеров - инструментарий
2008-02-22 11:44. Хотелось бы самоорганизующейся команды специалистов, способных некоторое время прокормить себя самостоятельно (поскольку не платим друг другу и не можем гарантировать зарплату, а также есть шанс несвоевременной оплаты заказчиком или обмана с его стороны). Это компенсируется более высокими заработками, зависящими от вклада в общее дело. Получая проект, декларируем сумму его фонда зарплаты: часть может идти в запас, на поддержание технической стороны бизнеса, общий резервный фонд на случай экстремальных событий -- допустим, 10%. Остальное делится между блоками работ: для примера, 2/3 на админку и проектирование, 1/3 на фронт-энд. Отдельные задачи тоже могут содержать атрибут цены, фиксированной или выраженной в долях от суммы родительской задачи. Это даст возможность перекраивать цены, пересмотрев разделение блоков проекта и их денежных долей на верхнем уровне; фиксированная цена может пригодиться для выяснения всей суммы работ (при подходе, когда заказчик платит регулярно или при планировании перед выставлением счета). Это также легко обеспечивает возможность отдать некоторые задачи наружу: неизвестным новым членам команды.
После разбивки проекта в него включаются разработчики, разбирая задачи на себя, детализируя блоки проекта декомпозицией на задачи и подзадачи (эта работа тоже оплачивается и не обязана делаться одним человеком). Wiki-подобная организация работы, одним словом. Каждый уточняет то, что лучше всего знает. Подключающиеся разработчики могут назначать на себя только неназначенные задачи: для снятия части нагрузки нужно получить согласие забравшего себе ранее задачу (возможно, будет лучше, чтобы только владелец задачи мог ее переназначить, и еще менеджер всего проекта: это нужно для разрешения конфликтов и укладывания в отведенные сроки в условиях, когда проект хотят сделать 2-3 человека, а на него претендуют например 5 человек, и руководитель понимает, что нам нужно для уменьшения рисков 4 человека для этого проекта, и часть задач продублировать, сделав их силами двух человек: старичков и новых членов команды). Этому могут противиться некоторые старые члены команды (это уменьшит их заработок), но это необходимый элемент здорового развития и роста команды.
Итого:
Вопросы:
Ещё ссылки по теме:
После разбивки проекта в него включаются разработчики, разбирая задачи на себя, детализируя блоки проекта декомпозицией на задачи и подзадачи (эта работа тоже оплачивается и не обязана делаться одним человеком). Wiki-подобная организация работы, одним словом. Каждый уточняет то, что лучше всего знает. Подключающиеся разработчики могут назначать на себя только неназначенные задачи: для снятия части нагрузки нужно получить согласие забравшего себе ранее задачу (возможно, будет лучше, чтобы только владелец задачи мог ее переназначить, и еще менеджер всего проекта: это нужно для разрешения конфликтов и укладывания в отведенные сроки в условиях, когда проект хотят сделать 2-3 человека, а на него претендуют например 5 человек, и руководитель понимает, что нам нужно для уменьшения рисков 4 человека для этого проекта, и часть задач продублировать, сделав их силами двух человек: старичков и новых членов команды). Этому могут противиться некоторые старые члены команды (это уменьшит их заработок), но это необходимый элемент здорового развития и роста команды.
Итого:
- таск-менеджер должен быть древовидным;
- для целей планирования элементы должны иметь атрибуты "планируемое время", "цена" (фиксированная или доля от parent task price), выстраивание цепочек задач (для облегчения планирования сроков реализации);
- для статистики и корректирования оценок времени элементы должны иметь атрибуты "реальное затраченное время";
- статистика для разработчика и руководителя: набрано задач на такую сумму, длительность столько-то; сделано столько-то % запланированного, получено денег по этому проекту столько-то, оплачено столько (и инструмент массовой отметки оплаченных задач);
- хорошо бы иметь возможность ограничения переназначения задач (необязательно: может решаться email-уведомлениями в адрес старого, нового владельцев задачи и менеджера проекта, и личными переговорами)
Вопросы:
- не хватает возможности задания нижней планки стоимости работ по разработчикам (открытая или закрытая должна быть информация в пределах команды?) и сигнализация о приближении или выходе за границы при планировании: дальше возможные пути в привлечении более дешевых разработчиков или снижение планки существующих, или пересмотр сроков и бюджета (блока или проекта);
- а как багфиксы оценивать? Вообще в идеале это опирается на спецификацию: есть в ней и неправильно работает -- переделывай без дополнительной оплаты (а если фиксит другой человек? забирать у делавшего? но там могут быть совершенно разные объемы, у реализации и фиксов), не описано в спецификации -- это новая работа и может расцениваться в рамках дополнительного бюджета.
Ещё ссылки по теме:
- http://baadoo.livejournal.com/100759.html#comments (Streber PM, WackoWiki, Trac, Mantis, time tracker...)
- http://baadoo.livejournal.com/119797.html (Trac, Redmine)
- http://lemalakoff.livejournal.com/19033.html (Многопользовательская работа). [...] В августовском номере "Harvard Business Review" статья о том, что завтра мы будем работать так как сегодня играем в многопользовательские игры. [...]
- http://habrahabr.ru/blogs/coworking/49125/ -- Наш ответ финансовому кризису: результаты первого месяца (Коворкинг-центр "Башня", Екатеринбург; "Полигон" + "ИНК")