Я внимательно прочитал Вашу статью, да еще и просмотрел обсуждения в группах на гугле, т.к. тема действительно интересна. Если у меня смешались в голове текст из статьи, комментариев к ним и старые обсуждения из группы, то приношу извинения.
> «менеджер формирует команду». Это не верно. Команда на проект формируется сама
Да, формируется то она сама, но если подают заявку несколько человек, то выбирает именно менеджер.
> «В общий фонд? Так это ничейные деньги будут»
Ничейные потому, что никто не может сказать это мои деньги. Если на рекламу и развитие расходы обосновать можно и получить подтверждение расходов от большинства, то вот разделить между лучшими вряд ли получится большинством.
> «Единственное решение всех этих проблем — отдать реальную власть ген. директору.». Вы спрашивали у директора, нужна ему эта власть?
Тогда я просто не понимаю зачем вам вообще директор? Только для того, чтобы заполнять договора и удерживать штрафы? Это больше похоже на секретаря, в лучшем случае менеджера, который сидит на р/с и имеет возможность наказывать провинившихся рублем.
Теперь давайте посмотрим на преимущества такого варианта.
Для фрилансеров. Тут все понятно, можно объединиться в группу, с единым брендом и заниматься только тем, что хорошо умеешь, не отвлекаясь на мелочи.
Для учредителя. Большая оперативность в работе — нет, т.к. будут постоянные утверждения кандидатур сообществом. Больший выбор исполнителей — опять нет, на фрилансе народу больше. Зачем искусственно ограничивать выбор 50 людьми? Лучше качество — будет такое же, как и для проверенных фрилансеров, но только тут выбор ограничен сообществом. Ниже цены — вряд ли, т.к. сообщество наоборот подразумевает увеличение стоимости работ.
Для клиента. Оперативность — ниже, за счет согласований с сообществом. Цены — выше, чем на фрилансе. Ответственность за результат — выше, т.к. оно контролируется сообществом, но все же ниже, чем у обычной веб-студии.
Получается что мне, как учредителю, выгоднее нанять менеджера, полностью контролировать его и сказать ему аутсорсить заказы на фриланс, чем строить сообщество, которое будет само определять что и как делать. А клиенту выгоднее обратиться ко мне, т.к. если менеджер начинает терять контроль всегда есть куда обратиться выше и это конкретное лицо, связанное со мной договором, а не обезличенное сообщество с ген. директором, контролирующим некий резервный фонд, но не имеющего контроля над исполнителями.
Получается что выгодно это по сути только фрилансерам, так что можно создать сайт типа мини-фриланс.ру по инвайтам и с абонентской платой. Далее идет вся ваша логика по выбору менеджера и декомпозицией проекта… Ну а клиенты уж найдутся при правильном позиционировании.
Мне ваша идея нравится, что-то в этом есть, но давайте пройдемся по всему процессу.
1. поступил заказ, сообщество выбрало менеджера — т.е. получается, что ген. директор сообщества ответственен перед клиентом, но при этом не может влиять на выбор менеджера, а менеджера выбирают программисты и дизайнеры. А менеджер всегда выберет не того, у кого карма больше, а того, с кем он работал. Вероятно он будет отдавать приоритет тем, кто с ним в одном городе. В результате московские программисты будут голосовать за менеджера из Москвы. И чем больше будет представительство Москвы, тем больше будут зажимать других. И кармой тут не поможешь, т.к. плевать какая карма у менеджера, если он тебе отдаст проект.
2. менеджер запрашивает оценку — каждый член сообщества должен произвести оценку работ, маловероятно что будет желание оценивать даже бесперспективные проекты. Но несколько оценок вероятно все же будут. Будем считать, что здесь все ок. Но если бы я точно знал, что получу этот заказ, то моя оценка была бы точнее, а риски меньше.
3. менеджер формирует команду — опять же один менеджер будет выбирать только тех, с кем он работал. А может ему даже будут предлагать откат за то, чтобы он выбрал именно их.
4. получили оплату от клиента — если оплата точно по оценке, то все нормально. Но если клиент платит больше (менеджер постарался, выбил больше денег, чем отдал исполнителям), то что? Распредилить между командой? А зачем, член команды назвал цену, получил ее. Все менеджеру — жирно будет. В общий фонд? Так это ничейные деньги будут, сообщество никогда единогласно не решит кого ими поощрить, кому отдать. А ген. директор хоть и имеет доступ к фонду, но не управляет им.
5. ответственность перед клиентом — отвечает ген. директор, который не может влиять на менеджера или команду, а может только вынести вопрос на суд сообщества. Программисты и дизайнеры посмотрят, скажут клиент неадекватен, менеджер прав. Ну прав то он может и прав, но ген. директор подписал договор и несет по нему ответственность, а исполнители сказали ему что клиент дурак, делать ничего не будем, разбирайся сам как хочешь.
Единственное решение всех этих проблем — отдать реальную власть ген. директору.
Он отвечает перед клиентом и он назначает менеджера, а не сообщество программистов. Выбирая менеджера, он фактически выбирает команду, но может исключить человека из нее по итогам прошлых работ и включить другого. Так исключаем возможность фаворитизма менеджера.
Каждый член команды знает, что в случае адекватной оценки именно он получит работу, так что здесь все точнее и ответсвеннее. А лишние деньги (или лишние траты) ложатся на плечи ген. директора. Он уже будет решать надо ли кого поощрить, либо просто отдать все деньги учредителям.
К чему мы пришли? Да все к той же небольшой студии с менеджером в штате или вне, у которого своя команда для выполнения проекта. Сообщество оказалось лишним, т.к. не может беспристрастно выбрать менеджера и сформировать команду, точно оценить объем работ, ее качество и адкватность клиента, разделить лишние деньги. Получается команда со слабым царем и влиятельными боярами. Кажется мы это уже проходили…
Вы слишком много просите от систем управления проектами. Управление бюджетом не их основные функции, поэтому реализация в виде счетов совместно с учетом времени — это уже плюс. В Worksection для проекта можно ввести бюджет проекта и расходы по нему, но только одно число, без истории что и когда.
С указанными вами требованиями — это опять надо CRM-системы смотреть. Но там уже не будет той простоты, что есть в системах управления проектами.
Вы все правильно делаете. Учитывайте только, что перевод не 100% и местами английский вылезает. Если же вообще русский не появляется, то даже не знаю что посоветовать, лучше им в поддержку написать.
Наверное это только вопрос времени. Если саму систему перевели, то сайт наверняка где-то в планах. Домен в зоне .com тоже этому способствует, хотя в наше время это уже просто признак хорошего тона :)
Я начинал поиск своего инструмента управления с CRM-систем, где автоматизируется весь цикл от звонка клиента до конечной оплаты и поддержки. Отсюда и требования, выходящие за рамки управления проектами. В той CRM, что использовал (да в принципе и сейчас стоит, но данные не забиваются) все было как вы написали: шаблоны документов (счета, акты, в том числе можно и типовой договор сгенерить), красивые отчеты откуда клиенты, кто больше платит, какие направления приносят больший доход и т.д. и т.п. Все в одном.
Но все-таки не слишком удобно данные вбивать и возникли некоторые технические трудности с ней… Поэтому и решил посмотреть в сторону систем управления проектами с функционалом, немного выходящим за рамки собственно управления проектами.
Выступал и в роли исполнителя, и в роли заказчика. Топик — попытка лучше понять подводные камни в общении заказчика и исполнителя. Судя по оценкам я снова открыл Америку.
Работал на таком предприятии. Те же строгие правила, журналы, охрана… На практике охране глубоко пофигу что вы там несете. А если ужесточат и будут все проверять, то есть большая дыра — арендаторы. Они находятся в том же здании. Передаешь что угодно арендатору и он может уже выносить что хочешь без каких-либо осмотров и разрешений.
По возможностям уступает представленным в статье аналогам. Интерфейс системы на мой взгляд недостаточно удобен. Получается что никаких особых преимуществ система не имеет.
Если вам понравилась эта система и вы придерживаетесь методологии Scrum, то посмотрите на tinypm. Просто чумовой интерфейс. Нужно потратить немного времени, чтобы разобраться, но потом будет очень удобно. Есть бесплатная версия на 5 пользователей, правда все что выше довольно дорого.
Есть идея составлять разные FAQ, советы, описание возможностей в вики-формате с сохранением истории изменений и выводить их на сайте в виде контента. Таким образом при обновлении какой-либо функции вашего продукта программист делает пометку о ней в вики, и тут же она обновляется и на сайте. Из таких советов и описаний можно динамическое руководство пользователя собирать.
Только для этого нужен либо API для экспорта данных из системы управления проектами, либо чтобы она была на одном хосте с сайтом (либо на разных, если правильно настроите доступы).
> «менеджер формирует команду». Это не верно. Команда на проект формируется сама
Да, формируется то она сама, но если подают заявку несколько человек, то выбирает именно менеджер.
> «В общий фонд? Так это ничейные деньги будут»
Ничейные потому, что никто не может сказать это мои деньги. Если на рекламу и развитие расходы обосновать можно и получить подтверждение расходов от большинства, то вот разделить между лучшими вряд ли получится большинством.
> «Единственное решение всех этих проблем — отдать реальную власть ген. директору.». Вы спрашивали у директора, нужна ему эта власть?
Тогда я просто не понимаю зачем вам вообще директор? Только для того, чтобы заполнять договора и удерживать штрафы? Это больше похоже на секретаря, в лучшем случае менеджера, который сидит на р/с и имеет возможность наказывать провинившихся рублем.
Для фрилансеров. Тут все понятно, можно объединиться в группу, с единым брендом и заниматься только тем, что хорошо умеешь, не отвлекаясь на мелочи.
Для учредителя. Большая оперативность в работе — нет, т.к. будут постоянные утверждения кандидатур сообществом. Больший выбор исполнителей — опять нет, на фрилансе народу больше. Зачем искусственно ограничивать выбор 50 людьми? Лучше качество — будет такое же, как и для проверенных фрилансеров, но только тут выбор ограничен сообществом. Ниже цены — вряд ли, т.к. сообщество наоборот подразумевает увеличение стоимости работ.
Для клиента. Оперативность — ниже, за счет согласований с сообществом. Цены — выше, чем на фрилансе. Ответственность за результат — выше, т.к. оно контролируется сообществом, но все же ниже, чем у обычной веб-студии.
Получается что мне, как учредителю, выгоднее нанять менеджера, полностью контролировать его и сказать ему аутсорсить заказы на фриланс, чем строить сообщество, которое будет само определять что и как делать. А клиенту выгоднее обратиться ко мне, т.к. если менеджер начинает терять контроль всегда есть куда обратиться выше и это конкретное лицо, связанное со мной договором, а не обезличенное сообщество с ген. директором, контролирующим некий резервный фонд, но не имеющего контроля над исполнителями.
Получается что выгодно это по сути только фрилансерам, так что можно создать сайт типа мини-фриланс.ру по инвайтам и с абонентской платой. Далее идет вся ваша логика по выбору менеджера и декомпозицией проекта… Ну а клиенты уж найдутся при правильном позиционировании.
1. поступил заказ, сообщество выбрало менеджера — т.е. получается, что ген. директор сообщества ответственен перед клиентом, но при этом не может влиять на выбор менеджера, а менеджера выбирают программисты и дизайнеры. А менеджер всегда выберет не того, у кого карма больше, а того, с кем он работал. Вероятно он будет отдавать приоритет тем, кто с ним в одном городе. В результате московские программисты будут голосовать за менеджера из Москвы. И чем больше будет представительство Москвы, тем больше будут зажимать других. И кармой тут не поможешь, т.к. плевать какая карма у менеджера, если он тебе отдаст проект.
2. менеджер запрашивает оценку — каждый член сообщества должен произвести оценку работ, маловероятно что будет желание оценивать даже бесперспективные проекты. Но несколько оценок вероятно все же будут. Будем считать, что здесь все ок. Но если бы я точно знал, что получу этот заказ, то моя оценка была бы точнее, а риски меньше.
3. менеджер формирует команду — опять же один менеджер будет выбирать только тех, с кем он работал. А может ему даже будут предлагать откат за то, чтобы он выбрал именно их.
4. получили оплату от клиента — если оплата точно по оценке, то все нормально. Но если клиент платит больше (менеджер постарался, выбил больше денег, чем отдал исполнителям), то что? Распредилить между командой? А зачем, член команды назвал цену, получил ее. Все менеджеру — жирно будет. В общий фонд? Так это ничейные деньги будут, сообщество никогда единогласно не решит кого ими поощрить, кому отдать. А ген. директор хоть и имеет доступ к фонду, но не управляет им.
5. ответственность перед клиентом — отвечает ген. директор, который не может влиять на менеджера или команду, а может только вынести вопрос на суд сообщества. Программисты и дизайнеры посмотрят, скажут клиент неадекватен, менеджер прав. Ну прав то он может и прав, но ген. директор подписал договор и несет по нему ответственность, а исполнители сказали ему что клиент дурак, делать ничего не будем, разбирайся сам как хочешь.
Единственное решение всех этих проблем — отдать реальную власть ген. директору.
Он отвечает перед клиентом и он назначает менеджера, а не сообщество программистов. Выбирая менеджера, он фактически выбирает команду, но может исключить человека из нее по итогам прошлых работ и включить другого. Так исключаем возможность фаворитизма менеджера.
Каждый член команды знает, что в случае адекватной оценки именно он получит работу, так что здесь все точнее и ответсвеннее. А лишние деньги (или лишние траты) ложатся на плечи ген. директора. Он уже будет решать надо ли кого поощрить, либо просто отдать все деньги учредителям.
К чему мы пришли? Да все к той же небольшой студии с менеджером в штате или вне, у которого своя команда для выполнения проекта. Сообщество оказалось лишним, т.к. не может беспристрастно выбрать менеджера и сформировать команду, точно оценить объем работ, ее качество и адкватность клиента, разделить лишние деньги. Получается команда со слабым царем и влиятельными боярами. Кажется мы это уже проходили…
С указанными вами требованиями — это опять надо CRM-системы смотреть. Но там уже не будет той простоты, что есть в системах управления проектами.
Но все-таки не слишком удобно данные вбивать и возникли некоторые технические трудности с ней… Поэтому и решил посмотреть в сторону систем управления проектами с функционалом, немного выходящим за рамки собственно управления проектами.
Если вам понравилась эта система и вы придерживаетесь методологии Scrum, то посмотрите на tinypm. Просто чумовой интерфейс. Нужно потратить немного времени, чтобы разобраться, но потом будет очень удобно. Есть бесплатная версия на 5 пользователей, правда все что выше довольно дорого.
Только для этого нужен либо API для экспорта данных из системы управления проектами, либо чтобы она была на одном хосте с сайтом (либо на разных, если правильно настроите доступы).