Comments 31
Быть может, стоит сменить менеджеров? Если менеджеру плевать и на разрабтчиков, и на качество продукта, то ничем хорошим это не кончится.
искать менеджеров-не мудаков?
… и в начале сидеть вместе с ними рядом и самолично контролировать весь процесс, потом это можно будет делегировать старшему менеджеру в котором уже есть уверенность. Ну и отзывы клиентов.
Выбор только за вами:
1) продолжать пытаться перевоспитывать имеющихся мудаков.
2) искать и обучать (в т.ч и лично) потенциальных не мудаков.
Если вам лень идти по второму пути, то какое право вы имеете
жаловаться на то, что вашим менеджерами и команде тоже лень??
1) продолжать пытаться перевоспитывать имеющихся мудаков.
2) искать и обучать (в т.ч и лично) потенциальных не мудаков.
Если вам лень идти по второму пути, то какое право вы имеете
жаловаться на то, что вашим менеджерами и команде тоже лень??
А если я не владелец студии, а разраюотчик, который хочет как-то избегать описаных проблем?
Вы, как разработчик, можете и должны указать директору на некомпетентность и как следствие общую деструктивность подобного менеджера для команды и, в случае, если этот менеджер директору не друг/брат, у вас есть неиллюзорный шанс занять его место. Ну или как вариант, просто найдут другого. Идиотов, сознательно держащих доказанных мудаков и вредителей, среди руководителей нет.
Ну, если ваша студия — исключение (исключения — не исключены :), то подыщите другую, делов то :))
Ну, если ваша студия — исключение (исключения — не исключены :), то подыщите другую, делов то :))
Не знаю как менеджеров, а разработчиков (ну кроме зп) можно мотивировать реальными сроками, а не «мне клиент сказал, что должно быть готово вчера», как обычно ставят сроки менеджеры-мудаки.
Сколько уже можно постить однообразное говно на хабре?
>>> Как мотивировать менеджеров и команду, чтобы проекты разрабатывались качественно?
Я не претендую на абсолютную точность, но, по-моему, если эти проекты не обладают
общемировой или хотя бы общенациональной или пусть даже локальной значимостью, то
деньгами (не зарплатой, а бонусами за качество исполнения и за уложение в сроки по
отношению к этому конкретному проекту, а также анальными карами за косяки и проёбы)
и привилегиями. В случае же, если-таки обладают, то можно *вдобавок* мотивировать
команду сознанием причастности к великому и общественно-полезному :) 10х за внимание
Я не претендую на абсолютную точность, но, по-моему, если эти проекты не обладают
общемировой или хотя бы общенациональной или пусть даже локальной значимостью, то
деньгами (не зарплатой, а бонусами за качество исполнения и за уложение в сроки по
отношению к этому конкретному проекту, а также анальными карами за косяки и проёбы)
и привилегиями. В случае же, если-таки обладают, то можно *вдобавок* мотивировать
команду сознанием причастности к великому и общественно-полезному :) 10х за внимание
Стараться надо всем, каждому.
Могу сказать как руководитель и в прошлом менеджер, хотя сейчас иногда тоже беру проекты под свое руководство. Главной мотивацией, что может послужить для человека- менеджера это при финале создания работы — добавление этой же работы в портфолио компании в корпоративный сайт, с полным описанием процесса разработки. Объясню почему это так важно, работал когда- то у нас вот такой горе-менеджер, которого боялись клиенты :), и это не шутка действительно мне лично звонили клиенты и с опаской жаловались, чтобы их перевели к другому менеджеру, так вот, сделал, хотя слово «сделал» здесь не совсем уместно, он пару проектов, под его руководством имеется ввиду. Данные работы, как Вы описали выше, естествннно так и делались, закончившись тем что: или заказчик отказывался от всего или мы преводили его на другого человека. Чем все это закончилось для данного человека, кроме увольнения. Вовремя того, когда он искал новую работу, мне лично преодически приходили звонки от схожих компаний, с просьбой дать оценку о человеке и о его отношении к работе. Видимо эму хватало наглости сказать что он работал у нас, а так как многим роботодателям в этой сфере наше имя знакомо, все они связывались с нами, так вот к чему же и ведет эта длинная история: основной оценкой, это было так: что все работы которые вел этот человек в портфолио компании не попали. И после этих слов что то говорить лишнее уже нет нужды.
П. С. Сори за ошибки, пишу с ипада.:)
5+, Автор!)
Материал!!!) Это отдельная лирическая песнь)
Наверное правильнее сказать — вызывает рекурсию всего процесса и вклинивается во все места.
Никто из заказчиков почему-то не понимает, что его нужно не 2 месяца собирать и выдавать разработчикам на сдачу проекта, а до составления ТЗ с ним советоваться с дизайнером.
Материал!!!) Это отдельная лирическая песнь)
Наверное правильнее сказать — вызывает рекурсию всего процесса и вклинивается во все места.
Никто из заказчиков почему-то не понимает, что его нужно не 2 месяца собирать и выдавать разработчикам на сдачу проекта, а до составления ТЗ с ним советоваться с дизайнером.
Платишь арахисом — получаешь обезьян.
Ну и персонал надо тщательно выбирать.
Ну и персонал надо тщательно выбирать.
Всё неутверждённое сразу (а значит, непродуманное в плане сроков/стоимости) скидывается в доп. соглашение. Подписывается, оплачивается, делается.
как объяснить заказчику, что он должен еще денег? ведь тз составлено и подписано…
Хотите что-то? А в ТЗ нету, ТЗ подписано, т.е. мы вам этого не должны.
Раз хотите — за отдельную плату. Юридический договор в таких делах — отличный аргумент, его все понимают.
Раз хотите — за отдельную плату. Юридический договор в таких делах — отличный аргумент, его все понимают.
В вопросах, оставленных незатронутыми в настоящем Техническом задании, Исполнитель действует, руководствуясь собственным опытом.
Но при этом нужно учитывать тот факт, что составляя ТЗ менеджер мог не учесть (и скорее всего, не учел) всех пожеланий заказчика. И тогда у заказчика появляется вполне понятный и объяснимый вопрос — WTF? Он денег заплатил, объяснил, что хочет, а ему и половины не сделали, и требуют дополнительной платы. Такой заказчик довольным не останется и новых клиентов не приведет.
Компании, оказывающие услуги, должны предусмотреть все возможные требования и пожелания заказчика, в том числе и те, которые менеджеру понятны, а заказчик даже и не думал еще о них подумать. )
Хороший менеджер должен знать эту притчу:
Компании, оказывающие услуги, должны предусмотреть все возможные требования и пожелания заказчика, в том числе и те, которые менеджеру понятны, а заказчик даже и не думал еще о них подумать. )
Хороший менеджер должен знать эту притчу:
Некий купец отдыхал в караван-сарае, когда вдруг увидел в стороне проходящий мимо караван. Он подзывает к себе слугу и велит тому узнать, что это за караван. Слуга сломя голову помчался к каравану и через короткое время вернулся с сообщением:
— Это караван из Басры.
— А куда он идёт? — спросил купец.
— Сейчас узнаю, — ответил слуга и снова помчался к каравану.
Вернувшись, он доложил купцу:
— Караван идёт в Медину.
— А кто его владелец? — спросил купец.
— Сейчас… — начал было говорить слуга, но купец прервал его:
— Стой, не нужно.
Он подозвал другого слугу и послал его узнать о владельце каравана. Через некоторое время второй слуга вернулся с сообщением:
— Это караван из Басры в Медину. Его владелец — Абу Али ибн Халуми. Везёт груз шёлка, чтобы продать его на рынке по цене пять динаров за десять локтей. Но если купить весь шёлк, то он готов продать за четыре. Поторговаться с ним?
Статья должна подразумевать ответы.
А у Вас наоборот — заканчивается вопросом. Ладно бы он еще был риторическим…
А у Вас наоборот — заканчивается вопросом. Ладно бы он еще был риторическим…
Соблюдать детально этапы разработки, которые предлагает студия, и проблем возникать не будет.
Описанная Вами ситуация возникает из-за:
а) управленческого фактора (Построения работы)*
б) человеческого фактора (Довольно часто в связи с пунктом «а»)
* Имеется ввиду не средний менеджмент, а общее руководство фирмой/группой разработчиков.
Решение данной проблемы возможно только с изменением обоих факторов.
1. Для начала надо четко прописать механизм.
2. Далее надо добиться следования этому механизму.(Самое сложное)
3. Потом присмотреться к коллективу и оставить только тех кому не плевать.(По факту выполнения первых двух пунктов таких людей сильно поубавится — с остальными Вам не по пути).
По факту работы механизм может итерационно меняться. Но с момента принятия решения следовать тем или иным механизма это должно выполнятся беспрекословно.
Извините за очевидность ответа.
а) управленческого фактора (Построения работы)*
б) человеческого фактора (Довольно часто в связи с пунктом «а»)
* Имеется ввиду не средний менеджмент, а общее руководство фирмой/группой разработчиков.
Решение данной проблемы возможно только с изменением обоих факторов.
1. Для начала надо четко прописать механизм.
2. Далее надо добиться следования этому механизму.(Самое сложное)
3. Потом присмотреться к коллективу и оставить только тех кому не плевать.(По факту выполнения первых двух пунктов таких людей сильно поубавится — с остальными Вам не по пути).
По факту работы механизм может итерационно меняться. Но с момента принятия решения следовать тем или иным механизма это должно выполнятся беспрекословно.
Извините за очевидность ответа.
Все студии на своих сайтах пытаются показать что у них есть «процесс». Это добавляет веса в глазах заказчика. Но если мы говорим о небольших студиях работающих на внутреннем рынке, то реальность такова, что цена для заказчика «правильного» процесса разработки, гораздо выше чем он хотел бы заплатить. И все это длится гораздо дольше чем он хотел бы ждать. И процесс требует его личного времени гораздо больше, чем он хотел бы тратить. И это не совсем вина менеджеров, так как существует сумасшедший демпинг со стороны фриланса и любой заказчик ценен если он готов платить.
Тут много причин, которые создают замкнутый круг, барьер для роста эффективности, и обычные ПМы крутятся в этом кругу как и разработчики. Только титанические усилия руководства могут разорвать этот порочный круг и наладить процесс для всех да и еще сделать так, что бы он не сильно удорожал разработку. Обычно это группа идейных лидеров-создателей компании.
Тут много причин, которые создают замкнутый круг, барьер для роста эффективности, и обычные ПМы крутятся в этом кругу как и разработчики. Только титанические усилия руководства могут разорвать этот порочный круг и наладить процесс для всех да и еще сделать так, что бы он не сильно удорожал разработку. Обычно это группа идейных лидеров-создателей компании.
Яйца нужны :)
По-хорошему ТЗ должно писаться после заключения договора и предоплаты. Ведь ТЗ — это и концепция проекта — это важно. Если в результате написания ТЗ клиенту все равно ничего не нравится, то возврат денег с учетом реально потраченного на тз время.
Sign up to leave a comment.
Создание сайта: мечты и реальность. Или за что платит заказчик