С новым днем уважаемые. Кто нибудь может за символическую плату собрать вики игру?

призываются проджекты. Вот есть рабочий ресурс из отдела в три-четыре человека-мультизадачника. И есть допустим 10 клиентов разной степени упоротости и масштабности - от скромных лендосников под быстрый трафик до им мебели и строительного инструмента. Все эти клиенты логичным образом генерируют определенный вал задач на ресурс, при этом условная точка перехода в режим asap уже давно пройдена и весь отдел работает в режиме пожарного производства, то и дело факапя сроки то одним, то другим клиентам. Собственно вопрос - как можно реорганизовать работу отдела, чтобы 10 клиентов разом не могли задать вопрос "какого черта не соблюдены сроки"? Я предполагаю, что имеет смысл тупо поделить клиентов на дни - и в определеные дни хреначить исключительно одного клиента. Но интересно послушать мнений

призываются проджекты. Вот есть рабочий ресурс из отдела в три-четыре человека-мультизадачника. И есть допустим 10 клиентов разной степени упоротости и масштабности - от скромных лендосников под быстрый трафик до им мебели и строительного инструмента. Все эти клиенты логичным образом генерируют определенный вал задач на ресурс, при этом условная точка перехода в режим asap уже давно пройдена и весь отдел работает в режиме пожарного производства, то и дело факапя сроки то одним, то другим клиентам. Собственно вопрос - как можно реорганизовать работу отдела, чтобы 10 клиентов разом не могли задать вопрос "какого черта не соблюдены сроки"? Я предполагаю, что имеет смысл тупо поделить клиентов на дни - и в определеные дни хреначить исключительно одного клиента. Но интересно послушать мнений

Сливать на субподряд раз сами не справляетесь

Сливать на субподряд раз сами не справляетесь

это само собой, огненные задачи все едут к фрилансу - время на копирайты и первичные макеты мы не тратим почти

призываются проджекты. Вот есть рабочий ресурс из отдела в три-четыре человека-мультизадачника. И есть допустим 10 клиентов разной степени упоротости и масштабности - от скромных лендосников под быстрый трафик до им мебели и строительного инструмента. Все эти клиенты логичным образом генерируют определенный вал задач на ресурс, при этом условная точка перехода в режим asap уже давно пройдена и весь отдел работает в режиме пожарного производства, то и дело факапя сроки то одним, то другим клиентам. Собственно вопрос - как можно реорганизовать работу отдела, чтобы 10 клиентов разом не могли задать вопрос "какого черта не соблюдены сроки"? Я предполагаю, что имеет смысл тупо поделить клиентов на дни - и в определеные дни хреначить исключительно одного клиента. Но интересно послушать мнений

Расширить штат сотрудников

Штат не решит проблемы

Или как вариант посмотреть на клиентов и расстаться с теми кто приносит много геммора, но мало дохода.

Расширить штат сотрудников

взяли одного, но чисто чтобы вручить ему все не глобальные и внутренние проекты. Штат не решает проблему таймменеджмента в полной мере.

Или как вариант посмотреть на клиентов и расстаться с теми кто приносит много геммора, но мало дохода.

парадокс в том, что тот кто приносит много геммора - приносит и нормально денег)

призываются проджекты. Вот есть рабочий ресурс из отдела в три-четыре человека-мультизадачника. И есть допустим 10 клиентов разной степени упоротости и масштабности - от скромных лендосников под быстрый трафик до им мебели и строительного инструмента. Все эти клиенты логичным образом генерируют определенный вал задач на ресурс, при этом условная точка перехода в режим asap уже давно пройдена и весь отдел работает в режиме пожарного производства, то и дело факапя сроки то одним, то другим клиентам. Собственно вопрос - как можно реорганизовать работу отдела, чтобы 10 клиентов разом не могли задать вопрос "какого черта не соблюдены сроки"? Я предполагаю, что имеет смысл тупо поделить клиентов на дни - и в определеные дни хреначить исключительно одного клиента. Но интересно послушать мнений

я бы весь гневный шквал принимал на себя, а сотрудникам поставил задачу каждого клиента доводить до рабочего состоянии в порядке финансового приоритета (сначала жирные и долгосрочные, в конце те с кем не жалко потерять контакт). ну и какие-то задачи брал частично на себя в ночь с помощью фрилансеров либо самому если позволяют скилы. но это в случае, если разговор про разовые такие пожарные ситуации, на постоянке понятно что по ночам не сможешь долго работать

я бы весь гневный шквал принимал на себя, а сотрудникам поставил задачу каждого клиента доводить до рабочего состоянии в порядке финансового приоритета (сначала жирные и долгосрочные, в конце те с кем не жалко потерять контакт). ну и какие-то задачи брал частично на себя в ночь с помощью фрилансеров либо самому если позволяют скилы. но это в случае, если разговор про разовые такие пожарные ситуации, на постоянке понятно что по ночам не сможешь долго работать

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

доброе утро) и день!)

доброе утро) и день!)

доброе!

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

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

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

А производственный план нормальный или авральный?

А производственный план нормальный или авральный?

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

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

/ban Hamza

/ban

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

а если в понедельник не успеете, задача переносится на вторник, а вторник мебельщик, в голове каша.

+ нервяк к концу понедельника, что не успеваете

а если в понедельник не успеете, задача переносится на вторник, а вторник мебельщик, в голове каша.

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

неделю без трафика?)

вот. грамотный вопрос)

выходит что да - неделю без трафика)

undefined_memes_pack

маркетолухи туборга совсем ебнулись

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

undefined_memes_pack

аааа это помните был бот от Туборга! там надо было свой домашний адрес писать! они прислали наклейки свои :DD

аааа это помните был бот от Туборга! там надо было свой домашний адрес писать! они прислали наклейки свои :DD

а щас работает он?

а щас работает он?

даже не знаю.) давно это было, как назывался не помню

а щас работает он?

ВОТВОСДАТ @whatwasthatbot

Это как мне когда то сказали, что тот кто остается работать после окончания своего рабочего времени не справляется со своими обязанностями и плохой работник

при 2-4 клиентах планировать работу абсолютно реально и необходимо. Но вот с ростом их количества и объемов оперативно вбрасываемых задач (из разряда - цена сменилась, нужно баннер перерисовать, обновить офферы везде и тд.) - планирование начинает выбиваться из рук)

Это как мне когда то сказали, что тот кто остается работать после окончания своего рабочего времени не справляется со своими обязанностями и плохой работник

смотря что этот работник делает после окончания рабочего дня

техподдержка (=процесс) отдельно от разработки (=проект) планируется. точнее даже не планируется, а просто выстраивается бизнес-процесс

при 2-4 клиентах планировать работу абсолютно реально и необходимо. Но вот с ростом их количества и объемов оперативно вбрасываемых задач (из разряда - цена сменилась, нужно баннер перерисовать, обновить офферы везде и тд.) - планирование начинает выбиваться из рук)

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

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

вах, бабек сам позвонит. как цукерберг.

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

ВОТВОСДАТ @whatwasthatbot

заказал себе тоже :) спасибо?

И я заказал, кстати удобная тема с рассылкой рекламной продукции

заказал себе тоже :) спасибо?

я вообще не поняла сначала что за наклейки мне прислали, пока не спросила в чате про этот пак))

призываются проджекты. Вот есть рабочий ресурс из отдела в три-четыре человека-мультизадачника. И есть допустим 10 клиентов разной степени упоротости и масштабности - от скромных лендосников под быстрый трафик до им мебели и строительного инструмента. Все эти клиенты логичным образом генерируют определенный вал задач на ресурс, при этом условная точка перехода в режим asap уже давно пройдена и весь отдел работает в режиме пожарного производства, то и дело факапя сроки то одним, то другим клиентам. Собственно вопрос - как можно реорганизовать работу отдела, чтобы 10 клиентов разом не могли задать вопрос "какого черта не соблюдены сроки"? Я предполагаю, что имеет смысл тупо поделить клиентов на дни - и в определеные дни хреначить исключительно одного клиента. Но интересно послушать мнений

Классифицировать клиентов по 6м квадрантам - богатые/бедные и наш/чужой/экибана в голове. Выделить тех, кто попадает в квадрант пересечение наш-багатый. Фокусировать усилия разработки на нем. Остальных меньшим приоритетом. Тех кто попадает в чужой-бедный и экибана в голове отсеить. Фильтровать клиентов на входе. С ключевыми клиентами работать открыто, включить agiity и на старте прорабатывать с ними прозрачный беклог без привязки к срокам сдачи полного скоупа, отгружать частями, ориентировать их на короткие циклы поставки.

Классифицировать клиентов по 6м квадрантам - богатые/бедные и наш/чужой/экибана в голове. Выделить тех, кто попадает в квадрант пересечение наш-багатый. Фокусировать усилия разработки на нем. Остальных меньшим приоритетом. Тех кто попадает в чужой-бедный и экибана в голове отсеить. Фильтровать клиентов на входе. С ключевыми клиентами работать открыто, включить agiity и на старте прорабатывать с ними прозрачный беклог без привязки к срокам сдачи полного скоупа, отгружать частями, ориентировать их на короткие циклы поставки.

наш/чужой/хищник

Классифицировать заказчиков считаю не правильным. Отношение должно быть ко всем одинаковое.

весь relationship management на этом строится) если обслуживание заказчика требует больше денег, чем с него заработать можно (т.е. когда он убыточен) - зачем его обслуживать так же, как прибыльного?

весь relationship management на этом строится) если обслуживание заказчика требует больше денег, чем с него заработать можно (т.е. когда он убыточен) - зачем его обслуживать так же, как прибыльного?

Зачем тогда такой клиент

об этом и речь

Классифицировать заказчиков считаю не правильным. Отношение должно быть ко всем одинаковое.

Это нужно говорить клиентам, но не строить на этом работу. Без приоритизации хаос будет только возрастать. Команда повесится. Качество снизится. Оно Вам надо при ресурсных ограничениях?

Это нужно говорить клиентам, но не строить на этом работу. Без приоритизации хаос будет только возрастать. Команда повесится. Качество снизится. Оно Вам надо при ресурсных ограничениях?

Клиент рано или поздно это заметит

так если он убыточен - мы заинтересованы в том, чтобы он это заметил и свалил

Клиент рано или поздно это заметит

он такой же бизнесмен и если не дурак, предпримет какие-то действия, чтобы его лучше обслуживали

так если он убыточен - мы заинтересованы в том, чтобы он это заметил и свалил

Зачем такого клиента брать изначально то

как будто можно предвидеть, сколько он будет покупать и сколько мозг парить

как будто можно предвидеть, сколько он будет покупать и сколько мозг парить

Excellent

как будто можно предвидеть, сколько он будет покупать и сколько мозг парить

Ну тут вроде все по ТЗ работают на стадии разработки можно все выяснить же

он такой же бизнесмен и если не дурак, предпримет какие-то действия, чтобы его лучше обслуживали

Ага будет платить больше бабок, и так у нас вся страна работает

Ага будет платить больше бабок, и так у нас вся страна работает

не понял это сарказм или что?)

он такой же бизнесмен и если не дурак, предпримет какие-то действия, чтобы его лучше обслуживали

Ну я про совсем мудаков не говорю конечно

ERROR: S client not available

не понял это сарказм или что?)

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

как вариант - перестанет мозг парить или свалит туда, где будут лучше обслуживать

вероятности исходов зависят от)

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

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

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

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

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

Друзья, мой Великий Ускоглазый Сосед до которого менее 100 км, зорко поглядывая выдал однажды из глубин тысячелетий наблюдение: Богат не тот кто дорого продаёт, а тот у кого есть оборот.

вообще это можно как расизм воспринять)

МОЧЕРАТОР ТУТ ЭТ САМОЕЕЕ!1111

а все

спс

Самые вкусные баны!

был взволнован

Бан бан бан

Вторая реклама за сегодня

ублюдки

Совсем распоясались маркетологи??

МОЧЕРАТОР ТУТ ЭТ САМОЕЕЕ!1111

?

Ну и еще если я тут не вписываюсь в тусовку вы мне скажите я больше не буду генерить сообщения.

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

Ага. А среди разрабов есть техлид? Может его замотивировать на общение с клиентами, а в идеале на дружелюбный FAQ или скрипт для аккаунта, чтобы тот ровно на ногах стоял?

И вы клиенту план-график даете под заказ?

Если сроки факапятся - на чьей стороне проблема?

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

Ага. А среди разрабов есть техлид? Может его замотивировать на общение с клиентами, а в идеале на дружелюбный FAQ или скрипт для аккаунта, чтобы тот ровно на ногах стоял?

когда аккаунта нет или он не вывозит - на контакт идет тот, кто отвечает за вопрос клиента - по контексту/sео/дизайну - ээто один человек, по вебдеву - другой, по контенту - третий. План-график мы присылаем клиенту вместе с отчетами сейчас - чтобы условится на объемах работ на месяц вперед. Но пока это весомо не упростило процесс, клиенты все равно качают лодку)

Тогда дайте им скраму). Делайте под клиентский проект доску в trello и все коммуникации сведите туда. Доступ клиенту только для их представителя. Двигайте карточки с задачами (декомпозируйте задачи на мелкие таски, чтоб клиент видел объем работ и прогресс) и пусть клиент отдыхает)

Клиенты качают - у них основание план-график и завышенные ожидания. Приземлите их.

скрам хорошее решение было бы, если среди наших клиентов не было бы мелкашей из продавцов фанеры со склада оптом и арендодателей фасадных подъемников)) так то внутри у нас все через тм, чтобы окончательно не заварится

пока просто клиентский вал чередуем в режиме реального времени, исходя из приоритетности

скрам хорошее решение было бы, если среди наших клиентов не было бы мелкашей из продавцов фанеры со склада оптом и арендодателей фасадных подъемников)) так то внутри у нас все через тм, чтобы окончательно не заварится

я так понимаю правила игры в приоритеты между клиентами плавают. попробуйте их зафиксировать и пожить с этим какой-то период. команда тоже не железная. а обратка с клиентов бьет по nps, если клиентского трафика достаточно и есть потенциал для его роста, возможно и вовсе стоит отказаться от мелких проектов. нет ничего хуже плавающих правил игры изнутри и снаружи)