Как стать автором
Обновить

Комментарии 26

Вы понимаете, что заставив дядю обрабатывать треть деталей от максимальной мощности — вы заставляете его работать всего треть времени, но и получать всего треть зарплаты. Мало кто на это согласится.
И дизайнер пошлет вас через пару недель с таким графиком, потому что к нему придет клиент на 20 дней, а вы его каждые Х дней отвлекаете.
А кто говорил, что будет легко?

И потом — что мешает того же дизайнера посадить на другой проект?
В топике вы этого не сказали, а в реальности так бы все равно и получилось. Почему бы вообще не нанять 1 дизайнера и 3 верстальщика.
А потом, когда ситуация изменится, уволить 2-х верстальщиков и нанять 1 дизайнера? А через месяц снова? Глупо, не кажется?

Задача — дать универсальный инструмент для построения проекта, решить вопрос методом наема допсотрудников всегда успеется.
n+1 верстальщиков будут работать над одним макетом медленнее, чем 1 верстальщик.
Возможное решение: делаем одного верстальщика тимлидом верстальщиков, верстающим только ключевые страницы и следящим за коммитами от «подопечных».
Идея топика понятна, но решение однобокое, вот я и пытаюсь докопаться до других решений.
Главное, чтобы пример из указанного топика был понятен. И не вызывал отторжения. Тогда следующий пример будет гораздо проще переварить, учитывая, что будет он приближен к реальному проекту, а не к вымышленным персонажам.
Этот пример понятен. Ждем следующий пример.
Как только, как только…

Вам же нужен красивый пример, с построением диаграмм и прочего? Да и самому написать такой хочется, потому как только пока все просто — можно на словах оперировать. Когда речь пойдет о паре десятков задач и связей между ними — без картинок не обойтись.

Кстати — не сочтите за труд, если знаете — где то в хабре встречал ссылку на то, куда надо выкладывать картинки, чтобы не падало, только вот теперь найти не могу. Не подскажете случаем?
Нужен не красивый, а реальный пример, с учетом всех переменных. Графики только при необходимости :)
Возможно habrastorage.org/
Во! Низкий поклон шлемом об асфальт, мил человек.
Так все же, дизайнер в штате или нет. Если в штате то вы регулярно платите зарплату. Не вижу финансовой разницы между схемами дизайнер работает над 3 проектами паралельно, выдавая каждый по кускам, и он их обрабатывает последовательно, отдавая целиком. Все равно у вас средства «заморожены» на минимальный срок (в реальности больше) который потребуется на выполнения работы «слабым звеном». Без увеличения производительности слабого звена вы срок не уменьшите, как бы вы не оперировали сильными.

Второй момент, проекты разноплановые, т.е. требующие разной загрузки по разным типам работ или однотипные. В первом случае, нет смысла тормозить слабые звенья, в сумме проектов они более-менее компенсируют друг-друга. Во втором все решается балансом количества людей, так что-бы производительность всех звеньев вышла на один уровень.
По поводу замороженных средств, опять же нужно смотреть, в штате или нет.

Мне кажется вы пытаетесь привести теорию туда где она не работает. Аналогии опасны. С промышленностью понятно, кроме зарплаты, много денег уходит на материалы, электричество и пр. Тут возможно имеет смысл затормозить некоторые станки. В случае же веб-разработки, основные расходы это зарплата, а результат который скапливается, не занимает складов, не портится и пр. Возможно ТО и можно применять в IT, например чтобы определять слабые звенья, и работать с ними, но тормозить сильные звенья, не вижу смысла.

Ну и очевидный минус, люди будут работать в рваном ритме, то расслаблено, то на полную выкладку, плюс возможно параллельно на нескольких проектах. Плохая мотивация, согласитесь.

А если фриланс, то все еще веселее, где гарантия что дизайнер будет свободен в то время когда вам потребуется третий кусок работы, или вы считаете что он должен работать только с вами, при такой то схеме загрузки? И ему в таком режиме работать не приятно будет думаю. Взгляните на схему с обратной стороны, вам нужен допустим дизайнер на 100% занятость, вы нашли, а он говорит «я могу выделить только 30% часов в месяц на вас, или ждите в 3 раза дольше, или ищите еще 3 дизайнеров :)». Вас это устроит, или вы пойдете искать дизайнера который сможет выделить вам 100% времени.

«Скажите, для вас будет нормальной практикой договориться с дизайнером, что он передает материалы пакетами, каждый из которых оплачивается отдельно?» — Пакетами возможно, в процессе работы, чтобы верстальщик начал работу до полного окончания работы дизайнером, но не в том виде который описали вы (я правильно понял что между пакетами дизайнер по 3 недели отдыхает, и 1 неделю работает над пакетом?).
доброе утро.

Спасибо за развернутый комментарий, постараюсь ответить последовательно.

Дизайнер в штате. Не важно, как именно это реализовано, является ли он фрилансером или сидит в офисе. Разница же работы в пакетном режиме в том, что весь процесс нормализуется по самому слабому звену, которое является ограничением в работе над конкретным проектом.

Я не стремлюсь уменьшить до невероятных величин срок работ, задача стоит в том, чтобы срок, который определяется производительностью ограничения, не увеличивался. Понятно, что быстрее, чем выполнит работы самое слабое звено в проекте, проект не выполнится, но, как показывает практика, эти сроки не соблюдаются.

Что касается разноплановости — тут Вы правы, но это будет рассмотрено в отдельной статье. Можно работать по старинке, а можно попытаться нормализовать процессы, увеличив производительность не привычным путем наращивания мощностей, а путем менеджмента проекта.

По поводу замороженных средств — какая разница, в штате ли человек или нет?

Теория вполне себе адаптирована для управления проектами. Родившись в среде промышленного производства, она благополучно преобразовалась для управления проектами. Даже там, где каждый производимый товар является штучным, в отличие от серии в промышленном производстве, ТОС действительно помогает планировать и реализовывать проекты. Проверено на личном опыте.

Что касается очевидного минуса — это задача балансирования нескольких проектов. Вы правы, на данный момент это кажется невозможным, но это не так.

Гарантий вообще нигде нет. Даже договор не является гарантом, даже с заказчиком. Тем не менее, описанная Вами проблема решается путем договоренностей. И задача руководителя в данном случае — выполнить балансирование работы дизайнера, который будет загружен на 100%, при этом выдавая то, что нужно проектам, и тогда, когда нужно. Если работа дизайнера не является критической цепью работ, то построение работ выполняется таким образом, чтобы для критических цепей материал подавался тогда, когда нужен. Кстати, можно рассмотреть ситуацию, в которой работа уже дизайнера будет являться критической цепью, и весь процесс будет выстраиваться вокруг него.

Что касается пакетности, то Вы не правы. потребуется 2 дня работы дизайнера в неделю в приведенном примере для бесперебойной работы верстальщика
Маленькое незначительное уточнение, но привлекло внимание. Станок с браком должен делать не 110=100*110% деталей, а 111=100/90%. Если считать по первому способу, деталей будет не хватать. На бОльших числах еще заметнее.
на 10 хороших в среднем 1 плохая. Не вижу разночтений
А можно попробовать продавать «на сторону» те лишние «детали/работы» которые могут выполнять более скоростные станки в то время когда ждут медленный станок. Таким образом все станки могут быть по максимуму загружены.
В случае с командой — дизайнер может заниматься проектом где нужен только дизайн, без верстки.

Либо другой вариант — станков номер 2 не один, а десять, и таким образом линия выпускает 1000 изделий, а не 100.
Так и в команде — дизайнер может вести несколько проектов, под двух/трех верстальщиков.

А что касается вопросов — то их надо както «ярче» определять, так как суть вопроса теряется к моменту когда уже прочитан весь текст. И уже не вспоминаешь о том что был задан вопрос в начале, зато есть мысли по тексту.
Вариант линейного наращивания мощности слабого звена мной упомянут, но это не выход. Что производство, что проекты столкнутся с одним — поиск подрядчиков с достаточным уровнем выполнения работ. Ситуация еще более плоха, если ритм работ «рваный» — сегодня есть, а завтра нет. Ожидать, что кто то будет держать мощности «спешл фо ю» — глупо. Таким образом, неизбежны накладки и срыв плана работ.

Постараюсь учесть Ваши замечания относительно содержания в следующей статье.
Спасибо.
В таком случае — любой из вариантов будет так или иначе «ущербным». Поскольку либо мы недозагружаем сильное звено, тем самым мы либо выводим его из постоянного рабочего тонуса, либо платим ему меньше и тем самым стимулируем на поиск новой работы и т.д. и т.п.

Если же мы увеличим количество слабых звеньев с одного до того количества, которое необходимо для соответствия сильным звеньям, то возможны простои в работе, и это скажется на всех звеньях, а не только на сильных. И в этом случае получается, что проблема уже не в балансе сильных и слабых звеньев, а в том, умеет ли менеджер, или кто там сверху, нагрузить их постоянным потоком работы.

А вообще, мне кажется наиболее адекватный способ решения проблемы — иметь большой контакт лист хороших исполнителей на каждый из возможных этапов работы. Когда нужна услуга того или иного исполнителя — он задействуется в проекте. А в постоянном штате держать только тех специалистов, которые постоянно загружены.
И мы опять возвращаемся к схеме — менеджер + фрилансеры.
Для нескольких проектов менеджер — обязателен. Общение с заказчиком, встречи, составления планов по 2-4 проектам одновременно просто не оставят места для программирования.

Только в данном случае задача менеджера — выстроить техпроцесс таким образом, чтобы оптимально использовать имеющиеся ресурсы, а не как обычно — вау, какой крутой проект, ну ка срочно кодить!
В данном контексте рассматривается задача поиска оптимального алгоритма для решения поставленной проектом задачи. Вопрос, где найти такое количество проектов, которое позволит поддерживать в тонусе все участки команды, не рассматривается.
Лучше найти коллег по команде под себя, когда и дизайнер, и верстальщик, и кодер работают примерно в одинаковых темпах. Знаю, под сим изречением можно было подписаться «Ваш К.О.». И к тому же это не так-то легко, как кажется. Но оно себя оправдывает на 100%.

По своему опыту тим-лидера скажу так: слабое звено — долой! Если человек работает из-под палки/через задницу/лениво (нужное подчеркнуть), такому не место в нормально работающей команде. Перевоспитывать такого — нет времени. Лучше, хоть и не проще, найти нормально работающего человека. Даром, что одиночным фрилансом сейчас много кто занимается.

Кроме того иногда слабым звеном является сам заказчик. Скажем, отправили ему макет на одобрение, а он даже на связь не выходит днями, если не неделями. Разумеется можно сделать по умолчанию в расчёте «на-исправления». Однако, впоследствии это чревато потерями времени. Мы часто говорим своим заказчикам, кстати, чтобы они на связи были постоянно. Ну, методика работы у нас соответствующая — заказ на лету. Обеспечивает высокую гибкость ТЗ и, как следствие, минимум переделок. Однако, именно к такой методике и можно отнести описанное выше. Здесь слабое звено — сам заказчик.
Вы в корне не правы.

По порядку. Если вы выполняете работы только одного типа — то да, сбалансировать команду еще как то можно, тем не менее 100% отдачи в любом случае не получите. Если же проекты разноплановые — то вы потеряете всех работников. Сегодня это веб система для ведения проектов, с кучей JS обработчиков, и слабое звено — верстальщик. Завтра — промо-сайт, слабое звено дизайнер. Послезавтра — сайт для обработки статистики, и слабое звено — программист.

Что касается заказчиков — то в данном случае нужно в договоре прописывать, что заказчик оплачивает время простоя. Как правило, действует отрезвляюще. Вред от «рваного» ритма работы, по опыту, самый максимальный.
Договор? Простите, Вы о чём? Большая часть фрилансеров работает не отрывая седалища от стула — безо всяких договоров. С кем заказчику договариваться? С частным лицом? Говорить о конторах, имеющих в своей основе ИП/ЧП/ПБОЮЛ — это одно. А совсем другое — говорить о командах, члены которых порой разбросаны по городам, если не по странам. Там не может быть и речи о каких-либо официальностях. Да, знаю, существует множество форм договоров. Только в большинстве случаев ими попросту пренебрегают обе стороны. Всё сводится к общению через интернет или, в лучшем случае, по телефону.

Насчёт разноплановости проектов тут Вы правы. Согласен с Вами. Только я говорил об общих тенденциях, а не о частных случаях. Если при любых проектах слабым звеном является, скажем, верстальщик, тогда верстальщик и является причиной простоев, а не разноплановость. В случаях с нормальным числом заказчиков и, как Вы говорите, разноплановости проектов «слабость звеньев» очень легко компенсируется перекрытием по проектам. Пока, скажем, верстальщик с кодером доделывают сайт статистики, дизайнер начинает работу над промо-сайтом. Соотвественно впоследствии кодер с верстальщиком нагоняют дизайнера. Ну, или другие варианты перекрытия. А вообще сяду-ка я напишу одну статейку…
Представьте себе да, договор можно заключать с кем угодно и как угодно. В том числе и с частным лицом.

Общая тенденция, в настоящее время, такова, что работы выполняются без соблюдения сроков и стоимости работ. Соответственно, цикл статей и направлен на выработку решения, которое позволит свести влияние проблем управления к минимуму.
Мне близка ваша точка зрения. Внесу свои пять целковых. Возможно, это просто специфика моей работы, так как я работаю скорее с индивидуальными творческими проектами. Здесь нужна именно «банда».
«Банда»
Это как в музыкальном коллективе, где процесс создания протекает в режиме реального времени, как репетиция. Играется одна композиция, затем другая, потом снова первая. Вместо песен — заказы, сайты. И поэтому, коммада должна быть одним целым и примерно одного уровня. В случае, если, например, верстальщик, сейчас не нужен он либо курит, либо занимается своими делами — учит теорию, новинки, отрабатывает новые приемы. Из примера музыкальной группы — он может, например, просто выйти в коридор и подумать «о своем». Что так же очень хорошо сказывается на работоспособности, так как самые творческие идеи приходят в состоянии «отключки», да и просто полезно когда мозги очищаются.
«Конвеер»
Здесь, схема другая, когда нет единого сплоченного коллектива, а есть костяк (допустим менеджер и дизайнер или программист) и остальные. В таком случае остальные, опять по аналогии с музыкальным коллективом, — это сессионщики. То есть, они привлекются за $$$ на какой-то фронт работ. Например, подстучать партию на там-тамах в какой-то песне. После чего получают мани и уходят.
Я так понимаю, статья как раз про такой вариант. Здесь уже оптимизация иная. Тут задача — как сделать, так чтобы сессионнщик не курил, пока вы репетируете песню, а занимался чем-то, ведь время вы ему оплатили. Наверное, если это время действительно большое, тогда целесообразно его не отпускать (так как его могут заграбастать на другой проект), а загрузить, например, изучением нового материала ваших будущих совместных проектов (читай следующих заказов, если они намечаются) — пусть выйдет и поизучает самостоятельно. Или он может поучаствовать в разработке, как сторонний эксперт. В случае с веб-разработкой (если в одном помещении) он смог бы «как бы со стороны» вносить свои мысли в работу дизайнера и программиста, в рабочий процесс. Либо последнее — не париться и смирится с тем, что это время будет потеряно. В конце — концов, щедрость тоже сказывается хорошо на взаимоотношениях с сотрудниками.
Зарегистрируйтесь на Хабре , чтобы оставить комментарий

Публикации

Истории