Comments 63
Да, целиком и полностью соглашусь, что хвалить починенного надо. И ругать надо так, чтобы не выглядело, что он виноват во всем — тогда работа будет спорится лучше.
мне кажется, что «Тотальный контроль» с ростом количества подчинённых превратится в проблему. обычно наоборот рекомендуют учиться правильно делегировать обязанности и ответственности.
А какую пм-систему выбрали? И почему?
Если честно — не помню точное название, завтра посмотрю обязательно сообщу. Выбрали ее потому, что работали с ней в стороннем проекте и она удовлетворяла нашим требованиям и была проста в освоении.
Заглянул по хистори браузера(она синхронизируется). Система называется ActiveCollab.
Прикольно, совсем недавно меня тоже поставили в положение, описанное в «Предыстория. Начало пути.» ))
К сожалению пропустил, обязательно прочитаю, спасибо.
Тотальный контроль говорит про то, что вы набрали недостаточно мотивированных работников. Или не получилось наладить информационные потоки в команде. Лично я всегда знаю, что если у человека трудности с реализацией, он придет ко мне. И он никогда не придет ко мне, если у него все хорошо, все получается, проблем нет. Узнать о неправильности действий работника можно только со временем, когда нужно будет переделывать этот кусок кода, расширять его функциональность, изменять его. Тотальный контроль убивает желание работать, не оставляя места для рабочего креатива.
Немного несогласен с вами. Я видим неоднозначно выразился. Иногда бывают ситуации когда человек не совсем верно понял задачу, которая перед ним стоит и совершает немного не те действия. Если в программировании это уже пройденный этап благодаря четко составленным ТЗ, то в менеджменте мне пока видимо опыта недостает, и такие ситуации происходят, поэтому и осуществляется постоянный контроль. К тому же он ненавязчивый, это на уровне общения во время перекуров, ежедневных отчетов и т.д. Ну и про отстуствие рабочего креатива я с вами несогласен, так как ребята всегда пытаются предложить идеи по поводу каждого этапа, что всячески поощрается и мы всегда обсуждаем их предложения.
К тому же он ненавязчивый, это на уровне общения во время перекуров, ежедневных отчетов и т.д.
FFFFUUUUUU
смотря как эти ежедневные отчеты построить. Если в виде устной беседы — какие задачи выполнил, что собираешься делать завтра — буквально на 5 минут беседа — то вполне нормально по-моему. Плюс все равно же видно кто чем занят в task managerе
Это типичный микроменеджмент. Не удивлюсь, если у вас хорошая текучка кадров или напряженная обстановка. На Хабре была уже отличная статья про микроменеджмент, найдите ее и почитайте.
На хабре статьи не нашел, прочитал вот эту:
www.jobsmarket.ru/?get_page=239&content_id=6339875
Собственно не совсем согласен с тем, что ежедневные отчеты формата
это микроменеджмент. ПО-моему это вполне комфортная рабочая обстановка, которая по-сути аналогична выставлению «задача выполнена» в таск менеджере, только по некоторым задачам сразу можно обсудить какие то интересные вопросы — с какими проблемами столкнулся в процессе, как решил, пополнить корпоративную базу знаний.
www.jobsmarket.ru/?get_page=239&content_id=6339875
Собственно не совсем согласен с тем, что ежедневные отчеты формата
— Вась, ты n закончил?
— Да, n сегодня с утра дописал, отдал на тестирование. Пока занимаюсь m.
это микроменеджмент. ПО-моему это вполне комфортная рабочая обстановка, которая по-сути аналогична выставлению «задача выполнена» в таск менеджере, только по некоторым задачам сразу можно обсудить какие то интересные вопросы — с какими проблемами столкнулся в процессе, как решил, пополнить корпоративную базу знаний.
Комфортная для руководителя, но не для работника. Вы работаете над задачей. В процессе реализации сталкиваетесь с проблемой. Проблема требует дополнительного анализа, тесткейзов, изучения матчасти и прочего. Менеджер считает, что вы должны уже пол часа как справиться с задачей, а вы занимаетесь в это время исследованиями. Он начинает вас пинговать запросами, сделано или нет. Вы нервничаете, раздражаетесь, пытаетесь пояснить проблему, но менеджеру ваше пояснение не нужно, у него уже стоит красный флажок. В итоге все скатывается к тому, что работнику либо нужно показывать эффективность любыми способами, либо делать вид, что показываешь эффективность.
Я могу неделю не трогать человека, если он работает над какой-то большой проблемой. Он работает над ней, и его трогать не нужно. Он сам придет с вопросами, или уточнениями, и это отлично покажет, на каком этапе он находится.
Я могу неделю не трогать человека, если он работает над какой-то большой проблемой. Он работает над ней, и его трогать не нужно. Он сам придет с вопросами, или уточнениями, и это отлично покажет, на каком этапе он находится.
Соглашаясь или возражая, важно помнить, что любая любой выбор хорош или плох только в конкретном контексте, а не в общем.
Например, это хорошо, если:
а) Вы уверены в человеке и знаете, что он действительно тратит время не зря
б) В любой момент у вас есть текущие оценки по времени, например «еще день занимаюсь анализом, потом нужно принимать решение, стоит ли изучать проблему дальше, менять постановку или план». Иначе проект может завалить все сроки.
в) Есть какое-то управление рисками. Во время планирования вы учли, что вот тут есть N темных пятен, с ними могут возникнуть проблемы, поэтому нужно заложить на 30% больше времени (или провести research, а потом уточнить сроки).
Это плохо, если:
а) У вас есть план итерации, скажем на 2 недели. Вы просто не можете позволить себе ждать неделю, не зная возможных последствий по времени. Часто, только заказчик может оценить, стоит ли какая-то возможность этой недели или нет. Возможно, давно пора:
— изменить постановку и уйти от проблемы, пусть даже ценой уменьшения функциональности;
— вынести задачу в следующую итерацию, чтобы успеть с другими задачами;
— согласовать с заказчиком изменения сроков (ну да, не для всех agile методологий сроки итераций священны :)
б) Программист может не найти простого решения «а» и увлечется способом «б», который как раз и потребует дополнительного анализа, изучения матчасти и пр. При этом ему вообще может не прийти в голову, что есть простой вариант, так что вы узнаете о всем этом только через неделю
в) Программист столкнулся с проблемой, не может ее решить, но отчаянно тратит на это время, не обращаясь за помощью, так как боится, что остальные решат, что он плохой программист (мы же говорим не об идеальной, а реальной команде, верно?).
Правила, которым стараюсь следовать я:
а) Если у кого-то не получается разобраться с проблемой в течении X часов (X зависит от типа проекта и жесткости плана) — ему нужно прерваться и обсудит это с другими. Если ваши итерации 2-3 недели — хорошо подходят утренние stand-up митинги (т.е. X = 1 день).
б) План всегда должен быть актуальный. В него постоянно могут вносится изменения, но:
— «разбираюсь, не трогай меня, я сам приду и спрошу, когда будут проблемы» — неправильный вариант
— «разбираюсь еще X часов, потом по результатам примем решение: разбираться дальше, менять постановку или сдвигать сроки» — правильный вариант
Иначе вписаться в сроки и оставить довольным заказчика будет крайне трудно.
Например, это хорошо, если:
а) Вы уверены в человеке и знаете, что он действительно тратит время не зря
б) В любой момент у вас есть текущие оценки по времени, например «еще день занимаюсь анализом, потом нужно принимать решение, стоит ли изучать проблему дальше, менять постановку или план». Иначе проект может завалить все сроки.
в) Есть какое-то управление рисками. Во время планирования вы учли, что вот тут есть N темных пятен, с ними могут возникнуть проблемы, поэтому нужно заложить на 30% больше времени (или провести research, а потом уточнить сроки).
Это плохо, если:
а) У вас есть план итерации, скажем на 2 недели. Вы просто не можете позволить себе ждать неделю, не зная возможных последствий по времени. Часто, только заказчик может оценить, стоит ли какая-то возможность этой недели или нет. Возможно, давно пора:
— изменить постановку и уйти от проблемы, пусть даже ценой уменьшения функциональности;
— вынести задачу в следующую итерацию, чтобы успеть с другими задачами;
— согласовать с заказчиком изменения сроков (ну да, не для всех agile методологий сроки итераций священны :)
б) Программист может не найти простого решения «а» и увлечется способом «б», который как раз и потребует дополнительного анализа, изучения матчасти и пр. При этом ему вообще может не прийти в голову, что есть простой вариант, так что вы узнаете о всем этом только через неделю
в) Программист столкнулся с проблемой, не может ее решить, но отчаянно тратит на это время, не обращаясь за помощью, так как боится, что остальные решат, что он плохой программист (мы же говорим не об идеальной, а реальной команде, верно?).
Правила, которым стараюсь следовать я:
а) Если у кого-то не получается разобраться с проблемой в течении X часов (X зависит от типа проекта и жесткости плана) — ему нужно прерваться и обсудит это с другими. Если ваши итерации 2-3 недели — хорошо подходят утренние stand-up митинги (т.е. X = 1 день).
б) План всегда должен быть актуальный. В него постоянно могут вносится изменения, но:
— «разбираюсь, не трогай меня, я сам приду и спрошу, когда будут проблемы» — неправильный вариант
— «разбираюсь еще X часов, потом по результатам примем решение: разбираться дальше, менять постановку или сдвигать сроки» — правильный вариант
Иначе вписаться в сроки и оставить довольным заказчика будет крайне трудно.
+1
у нас самые успешные тимлиды стараются разбивать задачи на подзадачи, которые должны решаться максимум за 2 часа, так проще видеть, где возникает затык-кто пробуксовывает в команде и можно оперативно выправить до того, как наступил дедлайн.
Но, конечно, не всегда так получается дробить, зависит от проекта.
у нас самые успешные тимлиды стараются разбивать задачи на подзадачи, которые должны решаться максимум за 2 часа, так проще видеть, где возникает затык-кто пробуксовывает в команде и можно оперативно выправить до того, как наступил дедлайн.
Но, конечно, не всегда так получается дробить, зависит от проекта.
Вы не доверяете своим работникам, считая, что они могут неправильно вас понять, не то сделать, не в ту сторону пойти. Лично я рассказываю сначала вводные данные, какую проблему мы реализовываем, потом мы долго общаемся на уровне каких-то абстракций, формируя логику системы в целом, потом расходимся по своим местам и реализовываем задуманное. Если кто-то находит проблему, то о ней немедленно сообщает, и снова возвращаемся к обсуждению. Сделать что-то не то в такой схеме почти нереально. Изучайте литературу про экстремальное программирование.
На счет креатива. Или контроль, или креатив. Выбирайте. Креатив — это способ вольной работы над задачей или задачами. Человек должен сам для себя выбрать, что он хочет сегодня делать, думать или работать, или отдохнуть. Постоянный контроль подстегивает его делать вид, что он работает, хотя ему хочется именно думать сегодня. Доверяйте работнику, пусть он три раза лучше шишки набьет на своем коде, но в итоге научится делать что-то и понимать что-то с первого раза.
На счет креатива. Или контроль, или креатив. Выбирайте. Креатив — это способ вольной работы над задачей или задачами. Человек должен сам для себя выбрать, что он хочет сегодня делать, думать или работать, или отдохнуть. Постоянный контроль подстегивает его делать вид, что он работает, хотя ему хочется именно думать сегодня. Доверяйте работнику, пусть он три раза лучше шишки набьет на своем коде, но в итоге научится делать что-то и понимать что-то с первого раза.
По поводу контроля я больше говорил о менеджменте. В программистах я уверен больше, так что мы приближаемся к тому варианту, который описываете вы. По менеджменту я осуществляю более плотный контроль по нескольким причинам:
1)Недостаток опыта у меня;
2)Недостаток опыта у менеджеров.
Хотя возможно вы правы, я перегибаю палку.
1)Недостаток опыта у меня;
2)Недостаток опыта у менеджеров.
Хотя возможно вы правы, я перегибаю палку.
Менеджерами не рождаются. Стоит серьезно пересмотреть систему доверия к людям. Люди будут факапить, будут писать неверный код, будут совершать простые ошибки. Лучше силы направить на то, чтобы человек был более самостоятельным в выборе решения. И тогда эффективность такого работника будет впечатлять, а работа менеджера будет состоять в указании морковки в том или ином углу.
Если честно, ежедневные отчёты — это одна из самых нелюбимых программистами вещей.
Возможно вы просто не очень верно выражаете свои мысли, но от слов «Тотальный контроль» и «Ежедневные отчеты» думаю, многих передернуло.
Если «Тотальный контроль» — это реально «Знание того, чем в данный момент занимаются непосредственные подчиненные» — это замечательно. Если же это контроль за написанием кода(а то и за объемом кода, написанного в день) за каждым программистом — это полнейшая жесть.
Аналогично про отчёты. Если ежедневный отчет выглядит как диалог:
— Вась, ты n закончил?
— Да, n сегодня с утра дописал, отдал на тестирование. Пока занимаюсь m.
То это замечательно. Если же ежедневный отчет письменный и выглядит, как у Ашманова:
«Сегодня крутили гайку #28 ключом на 14 по часовой стрелке в течение 4 часов» — то это ужасно и пользы от этого никакой нет.
Возможно вы просто не очень верно выражаете свои мысли, но от слов «Тотальный контроль» и «Ежедневные отчеты» думаю, многих передернуло.
Если «Тотальный контроль» — это реально «Знание того, чем в данный момент занимаются непосредственные подчиненные» — это замечательно. Если же это контроль за написанием кода(а то и за объемом кода, написанного в день) за каждым программистом — это полнейшая жесть.
Аналогично про отчёты. Если ежедневный отчет выглядит как диалог:
— Вась, ты n закончил?
— Да, n сегодня с утра дописал, отдал на тестирование. Пока занимаюсь m.
То это замечательно. Если же ежедневный отчет письменный и выглядит, как у Ашманова:
«Сегодня крутили гайку #28 ключом на 14 по часовой стрелке в течение 4 часов» — то это ужасно и пользы от этого никакой нет.
На фотографии Декстер? =)
Всегда удивляла высокая корреляция между руководящей должностью и неумением писать на русском языке.
Да, «проектировка проектов» — это круто ))))) Хотелось бы узнать боле подробные подробности о том как проектировать проекты )))
Видимо с русским у меня хуже, чем я думал. Спасибо за критику, впредь буду внимательней.
Можете сделать апдейт к своей статье — «Неважно насколько профессионален и опытен руководитель. Если у него серьёзные проблемы с русским языком, то на объяснение подчинённым того, чего от них хотят, будет уходить в 2-3 раза больше времени, чем у тех, кто русским языком владеет нормально. Сами подумайте какова будет эффективность такого руководителя».
Естественно, это не касается таких руководящих должностей, как, например, прораб. Там достаточно знать в совершенстве русский матерный, чтобы разговаривать с подчинёнными на одном языке ;)
Естественно, это не касается таких руководящих должностей, как, например, прораб. Там достаточно знать в совершенстве русский матерный, чтобы разговаривать с подчинёнными на одном языке ;)
В этом смысле ОЧЕНЬ порекомендую книгу www.ozon.ru/context/detail/id/2449712/
В интернете можно найти, где скачать.
В интернете можно найти, где скачать.
в конце п2 противоречит п3. Вы не обязаны знать или понимать все, чем занимаются подчиненные. Это называется делегированием ответственности и доверием в команде, без него никуда.
Неплохо но лично я хотел бы больше конкретных примеров их жизни. Так сказать для наглядности. Спасибо за статью
Вы пишете про сложности, с которыми Вы столкнулись при работе с «продажниками». Как Вы думаете, всегда ли технарь может стать хорошим менеджером по продажам и направлять работу остальных в правильное русло? И насколько критичны его возможные ошибки в процессе?
Ну, как минимум — это очень сложно. Все таки это значительно отличается от руководства «технарями».
Ошибок никак не избежать, нужно максимально минимизировать эти ошибки и их последствия. В любом случае у этого человека должно быть понимание схемы продаж, существенный опыт в руководстве. В небольших компаниях, как наша, это не всегда возможно, поэтому мне просто дали шанс проявить себя. Не мне судить, почему именно я, возможно личные качества повлияли.
Ошибок никак не избежать, нужно максимально минимизировать эти ошибки и их последствия. В любом случае у этого человека должно быть понимание схемы продаж, существенный опыт в руководстве. В небольших компаниях, как наша, это не всегда возможно, поэтому мне просто дали шанс проявить себя. Не мне судить, почему именно я, возможно личные качества повлияли.
Когда менеджер пытается прямо или скрытно изучать психологию подчиненного, он сам невольно создает барьер (дистанцию) в общении с этим сотрудником. Если называть вещи своими именами, в этом случае роли распределяются так:
Менеджер — исследователь или экспериментатор.
Сотрудник — объект исследования или подопытный кролик.
Есть предположение, что некоторые менеджеры занимаются этим просто от того, что сами не знают, чем им еще заняться.
Менеджер — исследователь или экспериментатор.
Сотрудник — объект исследования или подопытный кролик.
Есть предположение, что некоторые менеджеры занимаются этим просто от того, что сами не знают, чем им еще заняться.
*читал заголовок, много думал*
Просто любопытно, у вас сотрудники получают долю в компании или просто з/п?
З/п. Вы думаете, что нас эксплуатируют? :)
По крайней мере у меня в голове вещи «зарплата» и «гореть на работе, реально много работать» просто не совмещаются. Имхо, вкладывать душу, быть действительно увлеченным, болеть за проект можно только когда работаешь на себя.
Кент Бек — Экстремальное программирование, прочтите.
UFO just landed and posted this here
Спасибо за ваше мнение. У нас все довольны, развиваются творчески, постоянно генерируют идеи, по собственному желанию часто читают околорабочую литературу в свободное время, совершенствуются, всегда рады поделиться интересными находками, ходим на пикники иногда. Так что судя по всему ваши выводы касательно нашей фирмы не верны.
С уважением.
С уважением.
третья столица россии это (вспоминая плакат на въезде) Луховицы? :D
Sign up to leave a comment.
Банальные шишки, актуальные для многих