Заказчики читают рейтинги. Смотрят отзывы. Читают хабр, в конце концов.
Какое то время, в случае повального бегства с фриланса, это будет продолжаться из за реактивности системы в целом, но в конце концов они оттуда так же слиняют.
Поддерживаю, отзыв закину в пост, чтобы можно было сформировать представление обо всех биржах. В свою очередь, могу сделать это для почти всех российских и пары забугорных.
Да это не просто пичалька. Сайт free-lance — самая крупная биржа. А вот их политика, ИМХО, нацелена на то, чтобы стать самой мелкой. Хрен его знает, на новый сервер у них денег чтоль не хватает (всякие там «ололо фрилансер айда бухать» денег тоже стоят), или просто жадность неуемная. Но факт остается фактом — фриланс превращается в компанию, прибравшую к рукам и взимающую мзду за каждый чих, который может привести к старту проекта.
Предлагаю бойкотировать их к монахам, совсем зажрались, скоты.
Для нескольких проектов менеджер — обязателен. Общение с заказчиком, встречи, составления планов по 2-4 проектам одновременно просто не оставят места для программирования.
Только в данном случае задача менеджера — выстроить техпроцесс таким образом, чтобы оптимально использовать имеющиеся ресурсы, а не как обычно — вау, какой крутой проект, ну ка срочно кодить!
В данном контексте рассматривается задача поиска оптимального алгоритма для решения поставленной проектом задачи. Вопрос, где найти такое количество проектов, которое позволит поддерживать в тонусе все участки команды, не рассматривается.
Представьте себе да, договор можно заключать с кем угодно и как угодно. В том числе и с частным лицом.
Общая тенденция, в настоящее время, такова, что работы выполняются без соблюдения сроков и стоимости работ. Соответственно, цикл статей и направлен на выработку решения, которое позволит свести влияние проблем управления к минимуму.
Спасибо за развернутый комментарий, постараюсь ответить последовательно.
Дизайнер в штате. Не важно, как именно это реализовано, является ли он фрилансером или сидит в офисе. Разница же работы в пакетном режиме в том, что весь процесс нормализуется по самому слабому звену, которое является ограничением в работе над конкретным проектом.
Я не стремлюсь уменьшить до невероятных величин срок работ, задача стоит в том, чтобы срок, который определяется производительностью ограничения, не увеличивался. Понятно, что быстрее, чем выполнит работы самое слабое звено в проекте, проект не выполнится, но, как показывает практика, эти сроки не соблюдаются.
Что касается разноплановости — тут Вы правы, но это будет рассмотрено в отдельной статье. Можно работать по старинке, а можно попытаться нормализовать процессы, увеличив производительность не привычным путем наращивания мощностей, а путем менеджмента проекта.
По поводу замороженных средств — какая разница, в штате ли человек или нет?
Теория вполне себе адаптирована для управления проектами. Родившись в среде промышленного производства, она благополучно преобразовалась для управления проектами. Даже там, где каждый производимый товар является штучным, в отличие от серии в промышленном производстве, ТОС действительно помогает планировать и реализовывать проекты. Проверено на личном опыте.
Что касается очевидного минуса — это задача балансирования нескольких проектов. Вы правы, на данный момент это кажется невозможным, но это не так.
Гарантий вообще нигде нет. Даже договор не является гарантом, даже с заказчиком. Тем не менее, описанная Вами проблема решается путем договоренностей. И задача руководителя в данном случае — выполнить балансирование работы дизайнера, который будет загружен на 100%, при этом выдавая то, что нужно проектам, и тогда, когда нужно. Если работа дизайнера не является критической цепью работ, то построение работ выполняется таким образом, чтобы для критических цепей материал подавался тогда, когда нужен. Кстати, можно рассмотреть ситуацию, в которой работа уже дизайнера будет являться критической цепью, и весь процесс будет выстраиваться вокруг него.
Что касается пакетности, то Вы не правы. потребуется 2 дня работы дизайнера в неделю в приведенном примере для бесперебойной работы верстальщика
Вариант линейного наращивания мощности слабого звена мной упомянут, но это не выход. Что производство, что проекты столкнутся с одним — поиск подрядчиков с достаточным уровнем выполнения работ. Ситуация еще более плоха, если ритм работ «рваный» — сегодня есть, а завтра нет. Ожидать, что кто то будет держать мощности «спешл фо ю» — глупо. Таким образом, неизбежны накладки и срыв плана работ.
Постараюсь учесть Ваши замечания относительно содержания в следующей статье.
Спасибо.
По порядку. Если вы выполняете работы только одного типа — то да, сбалансировать команду еще как то можно, тем не менее 100% отдачи в любом случае не получите. Если же проекты разноплановые — то вы потеряете всех работников. Сегодня это веб система для ведения проектов, с кучей JS обработчиков, и слабое звено — верстальщик. Завтра — промо-сайт, слабое звено дизайнер. Послезавтра — сайт для обработки статистики, и слабое звено — программист.
Что касается заказчиков — то в данном случае нужно в договоре прописывать, что заказчик оплачивает время простоя. Как правило, действует отрезвляюще. Вред от «рваного» ритма работы, по опыту, самый максимальный.
Вам же нужен красивый пример, с построением диаграмм и прочего? Да и самому написать такой хочется, потому как только пока все просто — можно на словах оперировать. Когда речь пойдет о паре десятков задач и связей между ними — без картинок не обойтись.
Кстати — не сочтите за труд, если знаете — где то в хабре встречал ссылку на то, куда надо выкладывать картинки, чтобы не падало, только вот теперь найти не могу. Не подскажете случаем?
Ага, поставил. Я считаю, что человека, который выполз в инет в возрасте 20+ лет, поздно перевоспитывать. Кроме этого, не отрицаю того факта, что среди соотвечественииков есть образчики адекватного поведения. Им честь и хвала. Остальным и посвящаю сей пост.
Какое то время, в случае повального бегства с фриланса, это будет продолжаться из за реактивности системы в целом, но в конце концов они оттуда так же слиняют.
Предлагаю бойкотировать их к монахам, совсем зажрались, скоты.
Только в данном случае задача менеджера — выстроить техпроцесс таким образом, чтобы оптимально использовать имеющиеся ресурсы, а не как обычно — вау, какой крутой проект, ну ка срочно кодить!
Общая тенденция, в настоящее время, такова, что работы выполняются без соблюдения сроков и стоимости работ. Соответственно, цикл статей и направлен на выработку решения, которое позволит свести влияние проблем управления к минимуму.
Спасибо за развернутый комментарий, постараюсь ответить последовательно.
Дизайнер в штате. Не важно, как именно это реализовано, является ли он фрилансером или сидит в офисе. Разница же работы в пакетном режиме в том, что весь процесс нормализуется по самому слабому звену, которое является ограничением в работе над конкретным проектом.
Я не стремлюсь уменьшить до невероятных величин срок работ, задача стоит в том, чтобы срок, который определяется производительностью ограничения, не увеличивался. Понятно, что быстрее, чем выполнит работы самое слабое звено в проекте, проект не выполнится, но, как показывает практика, эти сроки не соблюдаются.
Что касается разноплановости — тут Вы правы, но это будет рассмотрено в отдельной статье. Можно работать по старинке, а можно попытаться нормализовать процессы, увеличив производительность не привычным путем наращивания мощностей, а путем менеджмента проекта.
По поводу замороженных средств — какая разница, в штате ли человек или нет?
Теория вполне себе адаптирована для управления проектами. Родившись в среде промышленного производства, она благополучно преобразовалась для управления проектами. Даже там, где каждый производимый товар является штучным, в отличие от серии в промышленном производстве, ТОС действительно помогает планировать и реализовывать проекты. Проверено на личном опыте.
Что касается очевидного минуса — это задача балансирования нескольких проектов. Вы правы, на данный момент это кажется невозможным, но это не так.
Гарантий вообще нигде нет. Даже договор не является гарантом, даже с заказчиком. Тем не менее, описанная Вами проблема решается путем договоренностей. И задача руководителя в данном случае — выполнить балансирование работы дизайнера, который будет загружен на 100%, при этом выдавая то, что нужно проектам, и тогда, когда нужно. Если работа дизайнера не является критической цепью работ, то построение работ выполняется таким образом, чтобы для критических цепей материал подавался тогда, когда нужен. Кстати, можно рассмотреть ситуацию, в которой работа уже дизайнера будет являться критической цепью, и весь процесс будет выстраиваться вокруг него.
Что касается пакетности, то Вы не правы. потребуется 2 дня работы дизайнера в неделю в приведенном примере для бесперебойной работы верстальщика
Постараюсь учесть Ваши замечания относительно содержания в следующей статье.
Спасибо.
По порядку. Если вы выполняете работы только одного типа — то да, сбалансировать команду еще как то можно, тем не менее 100% отдачи в любом случае не получите. Если же проекты разноплановые — то вы потеряете всех работников. Сегодня это веб система для ведения проектов, с кучей JS обработчиков, и слабое звено — верстальщик. Завтра — промо-сайт, слабое звено дизайнер. Послезавтра — сайт для обработки статистики, и слабое звено — программист.
Что касается заказчиков — то в данном случае нужно в договоре прописывать, что заказчик оплачивает время простоя. Как правило, действует отрезвляюще. Вред от «рваного» ритма работы, по опыту, самый максимальный.
А сайт, ставший последней каплей, «рекламировать» не буду. С той же долей вероятности это мог быть любой его «сотоварисч»
Вам же нужен красивый пример, с построением диаграмм и прочего? Да и самому написать такой хочется, потому как только пока все просто — можно на словах оперировать. Когда речь пойдет о паре десятков задач и связей между ними — без картинок не обойтись.
Кстати — не сочтите за труд, если знаете — где то в хабре встречал ссылку на то, куда надо выкладывать картинки, чтобы не падало, только вот теперь найти не могу. Не подскажете случаем?