с недавних пор я руковожу небольшой группой разработчиков, и встала проблема стимула к работе. каждый раз проводить лекции, что надо работать, а не сидеть часами в аське — помогает, но не надолго, на следующей недели все начинается по новой. грозить начальством или лишением премии не хочется, портить отношения с людьми тоже. как быть?
Здравствуйте, Аноним, Вы писали:
А>с недавних пор я руковожу небольшой группой разработчиков, и встала проблема стимула к работе. каждый раз проводить лекции, что надо работать, а не сидеть часами в аське — помогает, но не надолго, на следующей недели все начинается по новой. грозить начальством или лишением премии не хочется, портить отношения с людьми тоже. как быть?
Здравствуйте, Аноним, Вы писали:
А>с недавних пор я руковожу небольшой группой разработчиков, и встала проблема стимула к работе. каждый раз проводить лекции, что надо работать, а не сидеть часами в аське — помогает, но не надолго, на следующей недели все начинается по новой. грозить начальством или лишением премии не хочется, портить отношения с людьми тоже. как быть?
Вы либо хреновый лидер, либо у вас плохая команда. Скорее всего первое. Так как набрать команду, ПОЛНОСТЬЮ состоящую из плохих испольнителей очень сложно.
В вашем случае нужно не бить людей, но понять
1. Их мотивацию, что ими движет, когда они приходят на работу.
2. Какая работа приносила бы им удовлетворение, и что предлагаете им Вы. Иногда простой перестановкой задач, можно мотивировать людей.
3. Посмотреть на себя со стороны, вы бы работали с удовольствием с таким начальником как Вы ? Если нет , то почему и что нужно исправить в Вас.
4. Финансовый вопрос. Соответствие зп рынку.
5. Выяснить, нет ли объективных причин, которые мешают людям работать. Принять меры по устранению.
7. Понять систему мотивации в вашей организации, соспоставить ее с пунктами 1-4. Сделать выводы.
8. Дополнить мой список самостоятельно.
И вот еще что. Никогда не пишите посты под анонимным ником.
Re: как заставить людей работать?
От:
Аноним
Дата:
08.02.08 08:48
Оценка:
проблема еще в том, что мы достаточно давно друг друга знаем — а теперь мне надо заставлять их работать. с большей частью проблем никаких нет, но некоторые, видимо, не воспринимают меня как начальника...
Здравствуйте, Аноним, Вы писали:
А>с недавних пор я руковожу небольшой группой разработчиков, и встала проблема стимула к работе. каждый раз проводить лекции, что надо работать, а не сидеть часами в аське — помогает, но не надолго, на следующей недели все начинается по новой. грозить начальством или лишением премии не хочется, портить отношения с людьми тоже. как быть?
А может вы не очень адекватно воспринимаете сидение людей в аське? Мне например аська в работе не мешает. Может вы думаете, что програмист должен 8 часов в день без остановки писать код?
Здравствуйте, Аноним, Вы писали:
А>проблема еще в том, что мы достаточно давно друг друга знаем — а теперь мне надо заставлять их работать. с большей частью проблем никаких нет, но некоторые, видимо, не воспринимают меня как начальника...
Добавлю к списку Ваше общее развитие. "Грамотный повелитель не повелевает, он убеждает." Ф. Герберт "Дюна"
Вы все делаете общее дело. Провалите — плохо будет всем, будете успешными — победят все.
Вы видимо концентрируетесь на внешней атрибутике ВЛАСТИ. И демонстриуете это явно и резко. Без Вашей на то внутренней готовности. За это получили саботаж.
Еще раз подумаете о ЦЕЛЯХ. Цель — не показать всем, что вы начальник. Цель сделать задачу вовремя и хорошо. Если вы в руководство пришли из разработчиков — покажите свою стремление к цели собственным примером (да, да лабать код)
То что, вас давно знают добавляет в ситуацию сложности, которые легко трансформировать в опозитную ситуацию.
Здравствуйте, Аноним, Вы писали:
А>проблема еще в том, что мы достаточно давно друг друга знаем — а теперь мне надо заставлять их работать. с большей частью проблем никаких нет, но некоторые, видимо, не воспринимают меня как начальника...
В дополнение к уже присоветованным книгам:
— Введите формальную систему учета выданных тасков, оценки требуемного времени и контроля выполнения. Например, абсолютно все таски учитывайте — сразу будет видно кто что делал и собственно сделал. Можно использовать jira, хотя это не самый лучший вариант для управления проектом имхо, но вполне годный. Не надо угроз и начальственного давления. Просто для начала введите формальный учет задач.
— Введите daily standup по типу как принято в скраме — быстрая беседа о том что делалось, сколько нужно времени чтобы доделать, что буду делать сегодня, какие проблемы. Банально стыдно будет говорить коллегам что "вчера я на самом деле ничего не сделал".
Здравствуйте, malkolinge, Вы писали:
M>Вы все делаете общее дело. Провалите — плохо будет всем, удете успешными — победят все.
нет. у каждого в команде своя цель. попробую перечислить разные возможные цели:
1) получить опыт
2) показать опыт
3) сделать карьеру
4) получить зарплату
5) получить кучу денег
6) отдохнуть от дома
цель лида — направить "сумарную состовляющую броуновского движения" в нужном направлении.
и еще. если лид провалит проект, ему будет плохо наверно, а может только пм-у. я не знаю.
но рядовой разработчик просто сменит работу при самом плохом раскладе.
и это правильно!!!
M>Вы видимо концентрируетесь на внешней атрибутике ВЛАСТИ. И демонстриуете это явно и резко. Без Вашей на то внутренней готовности. За это получили саботаж.
там не было про саботаж.
M>Еще раз подумаете о ЦЕЛЯХ. Цель — не показать всем, что вы начальник. Цель сделать задачу вовремя и хорошо. Если вы в руководство пришли из разработчиков — покажите свою стремление к цели собственным примером (да, да лабать код)
одни из самых плохих лидов в моей практике были те, кто упорно продолжал доказывать свою позицию руководителя — лобанием кода.
самый показательный случай, когда в цейтноте лид лабает код, а у него за спиной стоит 5 человек и спрашивают, что делать. и так дня 3.
во
Здравствуйте, Аноним, Вы писали:
А>с недавних пор я руковожу небольшой группой разработчиков, и встала проблема стимула к работе. каждый раз проводить лекции, что надо работать, а не сидеть часами в аське — помогает, но не надолго, на следующей недели все начинается по новой. грозить начальством или лишением премии не хочется, портить отношения с людьми тоже. как быть?
Не заниматься глупостями. Контроллировать выполнение задач, а не сидение/несидение в аське.
Здравствуйте, bastrakov, Вы писали:
B>нет. у каждого в команде своя цель. попробую перечислить разные возможные цели: B>1) получить опыт B>2) показать опыт B>3) сделать карьеру B>4) получить зарплату B>5) получить кучу денег B>6) отдохнуть от дома
Дела в том, что у нормального спеца всегда более однйо цели. Весы важности разные
B>цель лида — направить "сумарную состовляющую броуновского движения" в нужном направлении.
да
B>и еще. если лид провалит проект, ему будет плохо наверно, а может только пм-у. я не знаю. B>но рядовой разработчик просто сменит работу при самом плохом раскладе. B>и это правильно!!!
Да правильно. И как был линейным кодописателем, так и и останется. Опыт участия в успешных и неуспешных проектах разнится. Проваленный проект бьет по всем участникам. Правда по разному.
M>>Вы видимо концентрируетесь на внешней атрибутике ВЛАСТИ. И демонстриуете это явно и резко. Без Вашей на то внутренней готовности. За это получили саботаж.
B>там не было про саботаж.
Между строк смотрите
M>>Еще раз подумаете о ЦЕЛЯХ. Цель — не показать всем, что вы начальник. Цель сделать задачу вовремя и хорошо. Если вы в руководство пришли из разработчиков — покажите свою стремление к цели собственным примером (да, да лабать код)
B>одни из самых плохих лидов в моей практике были те, кто упорно продолжал доказывать свою позицию руководителя — лобанием кода. B>самый показательный случай, когда в цейтноте лид лабает код, а у него за спиной стоит 5 человек и спрашивают, что делать. и так дня 3.
Именно. Все должны заниматся своей работой. Главное чтобы не было позиции — вы негры а я ПМ. Поэтому пару дней можно пописать. Нос вашим вектором рассуждений полностью согласен.
А>>проблема еще в том, что мы достаточно давно друг друга знаем — а теперь мне надо заставлять их работать. с большей частью проблем никаких нет, но некоторые, видимо, не воспринимают меня как начальника...
— а вам надо, чтобы воспринимали, или чтобы дело делали? Долго объяснять; почитайте про эволюцию команды и про место руководителя в ней на поздних этапах
— а их надо "заставлять" работать? А когда вы не были руководителем, как и кто их заставлял?
D_>- Введите формальную систему учета выданных тасков, оценки требуемного времени и контроля выполнения. Например, абсолютно все таски учитывайте — сразу будет видно кто что делал и собственно сделал. Можно использовать jira, хотя это не самый лучший вариант для управления проектом имхо, но вполне годный. Не надо угроз и начальственного давления. Просто для начала введите формальный учет задач.
— я бы не посоветовал это делать "в пику" нескладывающимся отношениям руководителя с командой
Здравствуйте, <Аноним>, Вы писали:
А>каждый раз проводить лекции, что надо работать, а не сидеть часами в аське — помогает, но не надолго, на следующей недели все начинается по новой.
Люди сидят в аське и работа стоит, или люди сидят в аське и задачи вполне нормально решаются? Если задачи решаются в запланированные сроки и качество не страдает, то какие вы видите проблемы в данной ситуации?
А> грозить начальством или лишением премии не хочется, портить отношения с людьми тоже. как быть?
Для начала нормально описать, что происходит со сроками и качеством проектов.
На самом деле, я эту ситуацию видел давно, пережил сам и со смесью удовольствия и брезгливости наблюдаю со стороны уже далеко не первый год.
Одни и те же люди сначала уверены в том, что все менеджеры — круглые идиоты, которые только мешают програмистам нормально работать, а потом становятся менеджерами сами и упс... а оказывается, что заставить проект завершиться успешно — задача черезвычайно сложная, причем программисты — не самая большая, но и не самая маленькая проблема на этом пути.
Это я к тому, что я решительно не понимаю, о чем думают люди, которые в ответ на такие послания пишут "ты — хреновый менеджер". Хреновым менеджером он станет, когда у него будет стаж этой работы хотя бы годик, а пока он — начинающий менеджер. Программист, который "волею судеб" оказался вытолкнут на эту работу. Все мы (или просто многие) либо были в таком положении, либо будем. И с чего-то нужно начинать.
Завязываю с offtopic-ом.
Самый простой и короткий ответ. Вспомните менеджера, с которым вы работали сами и под руководством которого проекты завершались успешно. Делайте, как он. Лучше спрашивая советов. Вы ведь не единственный менеджер в компании (на худой конец — в городе)?
Основой управления является планирование и контроль.
Вы обязаны(!) заранее(!) иметь приблизительный(!) график выполнения работ всеми(!) исполнителями. Если его нет — значит именно вы делаете свою работу хуже всех и вам теперь понятно, как исправляться. Если он есть, это значит, что у вас есть задания, оцененные в человекочасах в первом приближении (ошибка по времени в два раза за ошибку не считается).
Вам достаточно ввести систему учета рабочего времени, которая бы обязывала исполнителей привязывать каждый час рабочего времени к конкретной задаче. Тогда вам остается:
— следить за тем, чтобы люди не забывали отчитываться — этого можно добиваться как по-хорошему, так и по-плохому — не заполненный timesheet приравнивается к прогулу (с одним отличием — его можно заполнить задним числом)
— следить за сильными отклонениями между ожидаемым потраченным временем и фактическим. Следить — не значит наказывать исполнителя. Это значит — разбираться в причине расхождения с тем, чтобы в будущем ваши оценки были более точными.
Такая система мобилизует всех и начисто ликвидирует необходимость следить за аськой, rsdn-ом и прочими радостями жизни. Следить остается за той единственной вещью, за которой следить на самом деле нужно — за реальной проивзодительностью работы.
Внедрение такой системы там, где ее раньше не было — дело непростое. Оно воспринимается с сопротивлением, протестами, попытками саботажа — тут нужно проявить волю. Другая проблема — свои собственные оценки — поначалу они будут неадекватны абсолютно, даже с учетом совещания с исполнителем. Со временем ситуация наладится.
Это, конечно, только самое начало, первые шаги. Но без их выполнения я себе нормальной работы вообще не представляю.
Если такая система есть и работает, но люди систематически(!) срывают сроки выполнения простых(!) задач по причине лени — значит у них проблемы с мотивацией. Проблема с мотивацией — одна из сложнейших.
Есть класс людей, которые плохо мотивированы просто потому, что работать по-жизни не желают, а потерять работу не боятся из-за благоприятной ситуации на рынке труда. Тут ничего поделать нельзя, остается либо мириться с низкой производительностью и учитывать ее при планировании, либо искать замену. У кого-то нет таланта, у кого-то опыта, а у кого-то — ответственности. У всех свои недостатки.
К остальным нужно искать подход — деньги, карьера, похвала, критика, определенный тип задач, разнообразие задач, самостоятельность в планировании/проектировании, формальная постановка всех задач — ответ может быть любым, порой неожиданным. Просто своих людей нужно знать. Если понимать людей вы не умеете, то и управлять ими не сможете — это вообще не всем дано (я этим, к примеру, одарен слабо).
Универсальная мотивация — премиальные. Чтобы эта мотивация работала — нужно, чтобы компания выплачивала высокие премиальные в дополнение к не низкой зарплате тогда и только тогда, когда проект (или его стадия) завершается успешно.
Ну и момент, про который часто забывают, рвение команды практически никогда не бывает выше рвения ее менеджера. Если собственная планка находится низко — заставить других прыгать в полную силу не получится. Если вас выделили из группы разработчиков и поставили ими руководить, то в 9 случаях из 10 это значит не то, что вы самый компетентный, а то, что вы — самый ответственный. Со всеми вытекающими.
Re: как заставить людей работать?
От:
Аноним
Дата:
13.02.08 13:40
Оценка:
Рецепт простой
1. Обеспечить ясное понимание того, что нужно сделать, т.е. предотвратить ненужную работу. Каждый работник должен знать какой код ему сейчас нужно создать.
2. Поставить процесс так, чтобы он не позволял людям на долго отвлекаться.
3. Не давать людям тратить на задачи избыточное количество сил.
Стратегически эти требования достигаются одним простым маневром — каждая задача должна выполняться несколькими работниками, результаты деятельности одного чела должны зависеть от результатов другого (при этом работники не должны мешать друг другу). А уж тактическая поддержка этого — сугубо вопрос жизненного опыта менеджера.
Здравствуйте, Аноним, Вы писали:
А>с недавних пор я руковожу небольшой группой разработчиков, и встала проблема стимула к работе. каждый раз проводить лекции, что надо работать, а не сидеть часами в аське — помогает, но не надолго, на следующей недели все начинается по новой. грозить начальством или лишением премии не хочется, портить отношения с людьми тоже. как быть?
Здравствуйте, Аноним, Вы писали:
А>с недавних пор я руковожу небольшой группой разработчиков, и встала проблема стимула к работе. каждый раз проводить лекции, что надо работать, а не сидеть часами в аське — помогает, но не надолго, на следующей недели все начинается по новой. грозить начальством или лишением премии не хочется, портить отношения с людьми тоже. как быть?
Моя личная точка зрения:
Проблему решит планирование задач и контроль их выполнения.
Причем, планирование должно быть еженедельным и ежедневным.
На неделю формируется план в соответствии с общим планом проекта. В конце недели люди присылают отчёты.
Каждое утро начинается с небольшого обсуждения задач на сегодня.
При планировании задач необходимо опираться на временную оценку самих исполнителей.
То есть спрашиваем человека, сколько времени ему потребуется на задачу и, исходя из этого, планируем задачи на день.
Вечером подводим итоги и смотрим по факту, сколько заняла поставленная задача. Результаты регистрируем в общем файле так, чтобы все могли посмотреть.
Со временем накапливается статистика. Видно, какие сроки ставит себе исполнитель и какие реально получаются.
Исходя из этой статистики при возникновении сходных задач можно опираться на ранее выполненные работы и обоснованно корректировать оценку исполнителя.
Чтобы исполнитель необоснованно не завышал временную оценку, под рукой всегда есть время, которое тратят другие разработчики на похожие задачи.
Не пускайте всё на самотёк. Обязательно в течение дня поинтересуйтесь у каждого разработчика, как идёт процесс, что в данный момент он делает, какие возникают трудности.Люди не должны расслабляться и всегда чувствовать, что Вы в курсе дел.
Если человек периодически не справляется с задачами в срок, есть повод для разговора. В воспитательных целях заставляем человека поработать сверхурочно без компенсации, чтобы успеть выполнить поставленные задачи. Пару таких выходов в выходные или сидений по вечерам приведут человека к мысли, что надо эффективнее использовать своё рабочее время и не разбазаривать его на аську и т.п.
По поводу лишения премии
Премии не должны быть автоматическими. То есть система, когда человек каждый месяц или квартал получает очередную фиксированную премию, неправильная.
(Я не говорю, что она неправильная вообще, она неправильная для специфики разработки ПО)
Премии каждый раз должны привязываться к конкретному результату в проекте (завершение проекта, очередного прототипа в срок и т.п.) и должна заранее обговариваться сумма премии.
Если работа человека не устраивает, его не премии надо лишать, а расставаться с ним.
У каждого человека должно быть понимание его целей и морковок в долгосрочной перспективе (год). Фиксируем на год реперные точки и связанные с ними повышения оклада или премии. Старайтесь ставить задачи чуть большие, чем реально возможно выполнить. Но не для того, чтобы потом отказать в поощрении, а для того, чтобы людям всегда куда было стремится и они не "зазнавались".
Про нематериальные стимулы тут люди уже писали. Иногда простой апгрейд компьютера сотрудника даёт увеличение мотивации.
Насчет порчи отношения с людьми
У Вас не получится одновременно быть хорошим парнем и успешно выполнять проекты в срок. Дружеские отношения с подчинёнными делают Вас несвободными в принятии решений. От этого надо избавляться. Хотя исключения из этого правила возможны. Например, если Вас с человеком связывают давние дружеские отношения и идейная близость, если это ответственный человек, которому вы доверяете, и который наравне с Вами болеет за исход дела.
_>планирование должно быть еженедельным и ежедневным.
В стародавние ремена придумали планёрки. Зачем выбрасывать то что работает?
_>Каждое утро начинается с небольшого обсуждения задач на сегодня.
Но каждый день — это имхо перебор, хотя тут всё зависит от специфики.
_>При планировании задач необходимо опираться на временную оценку самих исполнителей.
+1
_>Исходя из этой статистики при возникновении сходных задач можно опираться на ранее выполненные работы и обоснованно корректировать оценку исполнителя.
А то, что со временем он научится корректировать себя сам, мы в расчёт не берём?
_>Чтобы исполнитель необоснованно не завышал временную оценку, под рукой всегда есть время, которое тратят другие разработчики на похожие задачи.
"похожие задачи" вещь очень субъективная. Так Вы запросто можете потерять хорошего разработчика. Тем более, что завышение времени — это по большей части миф. Его придумали те менеджеры, которые любят "безнадёжные проекты"(с). Обычно экономия времени в таких жёстких случаях идёт за счёт тестирования и отладки, что в последствии значительно затягивает общий срок (или просто снижает качество).
_>Если человек периодически не справляется с задачами в срок, есть повод для разговора. В воспитательных целях заставляем человека поработать сверхурочно без компенсации, чтобы успеть выполнить поставленные задачи. Пару таких выходов в выходные или сидений по вечерам приведут человека к мысли, что надо эффективнее использовать своё рабочее время и не разбазаривать его на аську и т.п.
-1
Проще сразу предложить уволиться, чем мучать человека, прежде чем он сделает это сам.
_>По поводу лишения премии _>Премии не должны быть автоматическими. То есть система, когда человек каждый месяц или квартал получает очередную фиксированную премию, неправильная.
-1
Фиксированная премия работает как кнут в случае серьёзных проступков. Так устроено трудовое законодательство.
_>Премии каждый раз должны привязываться к конкретному результату в проекте (завершение проекта, очередного прототипа в срок и т.п.) и должна заранее обговариваться сумма премии.
-1
Это ничем не отличается от фиксированной премии. Причём на эмоциональном уровне оказывает даже большее давление.
_>Если работа человека не устраивает, его не премии надо лишать, а расставаться с ним.
+500
_>У каждого человека должно быть понимание его целей и морковок в долгосрочной перспективе (год). Фиксируем на год реперные точки и связанные с ними повышения оклада или премии. Старайтесь ставить задачи чуть большие, чем реально возможно выполнить. Но не для того, чтобы потом отказать в поощрении, а для того, чтобы людям всегда куда было стремится и они не "зазнавались".
-1
_>Про нематериальные стимулы тут люди уже писали. Иногда простой апгрейд компьютера сотрудника даёт увеличение мотивации.
-1000
Никакой это нафиг не стимул. Рабочее место — это обязательное условие работы. Этим вы результаты напрямую стимулируете, а не работника. Абсолютно независимый ресурс.
_>Насчет порчи отношения с людьми _>У Вас не получится одновременно быть хорошим парнем и успешно выполнять проекты в срок. Дружеские отношения с подчинёнными делают Вас несвободными в принятии решений. От этого надо избавляться. Хотя исключения из этого правила возможны. Например, если Вас с человеком связывают давние дружеские отношения и идейная близость, если это ответственный человек, которому вы доверяете, и который наравне с Вами болеет за исход дела.
-1
Делая то, за что я Вам поставил минус, у Вас есть все шансы испортить отношения с людьми. Дружеские отношения и панибратство — не синонимы. Я часто имел дружеские отношения с начальством и никогда не считал их за это чем-то мне обязанными.
Это касается и подчинённых.
Может быть я — исключение. Просто я жёстко разделяю для себя бизнес-цели и личные отношения.
Дружеские отношения — основа доверия, а вот это важно! Хотя бы для душевного спокойствия в коллективе.
