Хабр Курсы для всех
РЕКЛАМА
Большая витрина: от крупнейших школ до частных авторов. Сравнивайте по цене, длительности, формату и выбирайте самый подходящий курс!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 42
Хорошая статья.
Про Milfgard-а Вы зря — там бизнес другой, наблюдать за его эволюцией интересно и если Вы также сумеете продолжать выбранную тему, раскрывая больше деталей (несмотря на Disclaimer) — буду настолько же благодарен и Вам.
Про Milfgard-а Вы зря — там бизнес другой, наблюдать за его эволюцией интересно и если Вы также сумеете продолжать выбранную тему, раскрывая больше деталей (несмотря на Disclaimer) — буду настолько же благодарен и Вам.
Мне очень симпатичен Milfgard и все, что он делает.
Думаю, что он намного лучше меня знает, как управлять командами(результаты налицо), поэтому я его и не критиковал, а просто написал про свой опыт.
Думаю, что он намного лучше меня знает, как управлять командами(результаты налицо), поэтому я его и не критиковал, а просто написал про свой опыт.
Суть моего комментария была в том, что, во-первых, задачи различаются, а во-вторых, как следствие, и команды должны быть разными и работать по разному.
Т.е. вы знаете не хуже. Вы знаете другое. И если мне вид бизнеса (деятельности), который выбрал для себя Milfgard просто любопытен, то в Вашем опыте (как коллеги) — я уже заинтересован по настоящему.
Т.е. вы знаете не хуже. Вы знаете другое. И если мне вид бизнеса (деятельности), который выбрал для себя Milfgard просто любопытен, то в Вашем опыте (как коллеги) — я уже заинтересован по настоящему.
Какие детали интересуют?
Жизненные, конечно! )
Вот тот же опыт с «политиками» внутри группы.
Интересно, как у вас происходит найм специалистов.
Бывают ли у вас ситуации, когда заказчик не внутри компании (не клиент, а именно заказчик) и как это сказывается на процессе.
Ну и еще — можете ли Вы оценить степень влияния культурного кода участвующих. Я верю, что все инженеры мира в культурном плане ближе друг к другу, чем к жителям своей страны, но все-же.
Вот тот же опыт с «политиками» внутри группы.
Интересно, как у вас происходит найм специалистов.
Бывают ли у вас ситуации, когда заказчик не внутри компании (не клиент, а именно заказчик) и как это сказывается на процессе.
Ну и еще — можете ли Вы оценить степень влияния культурного кода участвующих. Я верю, что все инженеры мира в культурном плане ближе друг к другу, чем к жителям своей страны, но все-же.
Про опыт с «политиками» это сложно. Я не думаю, что тут есть универсальные рецепты.
Но, в целом, чем прозрачнее процессы принятия решений, тем меньше пространство для маневров.
С наймом ничего интересного не придумали, все интервьювят, как хотят. По алгоритмам не гоняют, все больше прикладные технологии. Бывают удачные наймы, бывает не очень, но тут рынок довольно дохлый, поэтому очень трудно нанимать.
Про культурные коды придется отдельную статью писать.
Но, в целом, чем прозрачнее процессы принятия решений, тем меньше пространство для маневров.
С наймом ничего интересного не придумали, все интервьювят, как хотят. По алгоритмам не гоняют, все больше прикладные технологии. Бывают удачные наймы, бывает не очень, но тут рынок довольно дохлый, поэтому очень трудно нанимать.
Про культурные коды придется отдельную статью писать.
>В процессе чтения статьи от Milfgard про то, как виноватить людей
Попробовали бы прочитать до конца что ли. Не «как виноватить», а наоборот.
Попробовали бы прочитать до конца что ли. Не «как виноватить», а наоборот.
Первый раз читаю о таком опыте. Респект!
Я бы добавил еще один пункт к «Что делать с работником, который постоянно косячит» — «вывести человека на прямой диалог, понять проблемы, договориться о способах их преодоления». Например, забывает тесты гонять и/или писать. Договориться ввести чеклист, с которым разработчик будет сверяться перед каждым коммитом. Если и в этом случае буксует, наверное, стоит расстаться.
Я бы добавил еще один пункт к «Что делать с работником, который постоянно косячит» — «вывести человека на прямой диалог, понять проблемы, договориться о способах их преодоления». Например, забывает тесты гонять и/или писать. Договориться ввести чеклист, с которым разработчик будет сверяться перед каждым коммитом. Если и в этом случае буксует, наверное, стоит расстаться.
Доводилось работать на проекте не точь в точь, но с подобной организацией, это рай. И ненапряжно, и продуктивно работалось. Постарался перенести опыт в следующий проект — не получилось. Наверно, потому что в первом случае результат спрашивали со всей команды, а во втором с тим-лида.
Вставлю свои 5 копеек.
От статьи может сложиться впечатление, что команде вообще не нужен управляющий. Это, конечно же, не так. Представьте ситуацию, когда на перекрестке сломан светофор. Если машин мало, они худо-бедно смогут проехать, потеряв немного сил и нервов. В час пик отсутствие регулирования приведет к огромной орущей и матерящейся толпе, пробкам и ДТП.
Если команда небольшая, то такой подход оправдан. Но только если собраны адекватные люди с системным мышлением.
В команде всегда есть управляющий, направляющий или хотя бы арбитр. Если начальник устраивает laissez-faire, то такие люди выдвигаются из самой команды. Дай бог, чтобы у них были нужные управленческие навыки, а не только громкий голос.
От статьи может сложиться впечатление, что команде вообще не нужен управляющий. Это, конечно же, не так. Представьте ситуацию, когда на перекрестке сломан светофор. Если машин мало, они худо-бедно смогут проехать, потеряв немного сил и нервов. В час пик отсутствие регулирования приведет к огромной орущей и матерящейся толпе, пробкам и ДТП.
Если команда небольшая, то такой подход оправдан. Но только если собраны адекватные люди с системным мышлением.
В команде всегда есть управляющий, направляющий или хотя бы арбитр. Если начальник устраивает laissez-faire, то такие люди выдвигаются из самой команды. Дай бог, чтобы у них были нужные управленческие навыки, а не только громкий голос.
Средний размер команды — 8 человек. Арбитров нет и управляющих тоже.
Громкий голос — это весело, на первых митингах народ орал от души.
Со временем это проходит и приходит конструктив.
Громкий голос — это весело, на первых митингах народ орал от души.
Со временем это проходит и приходит конструктив.
Пример про перекресток не работает — поищите ролики про движение на улицах во Вьетнаме например
Пример со светофором не подтверждается на практике (безотносительно темы про управляющих).
Вот поэтому half life 3 до сих пор не вышел :-)
По опыту, самые психологически активные всё равно «захватывают власть» и разжигают нешуточные срачи.
Например вот так: masuk0.livejournal.com/36623.html
«Когда я говорю “неистово убеждал” я должен упомянуть, что это единственный способ спорить, который использовался в Blizzard — со всей юношеской горячностью и заносчивым высокомерием. Единственным вопросом, по которому в Blizzard не возникало неистовых споров это то, что есть на ланч.»
А уровновешенные и спокойные люди не высказываются и не возражают, так как у них нет возможности даже слова сказать.
Ещё есть такая проблема, что люди начинают брать интересные задачи, выгодные им а не проекту. Например разобраться с новой технологией. Лично для человека это инвестиция в будущее, а команде и проекту в данный момент может быть нужно что-нибудь рутинное и неинтересное, за что никто добровольно не возьмётся когда есть выбор.
По опыту, самые психологически активные всё равно «захватывают власть» и разжигают нешуточные срачи.
Например вот так: masuk0.livejournal.com/36623.html
«Когда я говорю “неистово убеждал” я должен упомянуть, что это единственный способ спорить, который использовался в Blizzard — со всей юношеской горячностью и заносчивым высокомерием. Единственным вопросом, по которому в Blizzard не возникало неистовых споров это то, что есть на ланч.»
А уровновешенные и спокойные люди не высказываются и не возражают, так как у них нет возможности даже слова сказать.
Ещё есть такая проблема, что люди начинают брать интересные задачи, выгодные им а не проекту. Например разобраться с новой технологией. Лично для человека это инвестиция в будущее, а команде и проекту в данный момент может быть нужно что-нибудь рутинное и неинтересное, за что никто добровольно не возьмётся когда есть выбор.
Угу. Автору видимо просто не попался человек-катастрофа, который просто в силу качеств своего характера может
1) занять роль неформального лидера — а если у вас роль формального лидера не определена, то и роль формального лидера тоже — при этом не обладая достаточным профессионализмом для принятия верных решений,
2) перессорить каких-то ключевых сотрудников между собой, в результате чего ценные кадры могут уволиться, либо просто эффективность взаимодействия упадет,
3) «подсиживать» какие-то неугодных ему людей, выставляя себя ангелом, а их — демонами.
Оптимизируя эффективность работы, получая выигрыш в производительности на 10% по сравнению с иерархичной командой, не забывайте о риск-менеджменте — в один день может вся ваша 300-сильная компания посыпаться, как карточный домик. Внутренние конфликты плохи тем, что они часто поначалу скрытые и когда «прорываются» — то становится уже поздно, т.к. открытый конфликт (ссора, ругань и прочее) практически всегда случается только тогда, когда всех действительно «достало». Вам нужен в команду человек, который будет пристально мониторить атмосферу и все эмоциональные флуктуации в коллективе, вовремя распознавать угрозы и избавляться от них.
1) занять роль неформального лидера — а если у вас роль формального лидера не определена, то и роль формального лидера тоже — при этом не обладая достаточным профессионализмом для принятия верных решений,
2) перессорить каких-то ключевых сотрудников между собой, в результате чего ценные кадры могут уволиться, либо просто эффективность взаимодействия упадет,
3) «подсиживать» какие-то неугодных ему людей, выставляя себя ангелом, а их — демонами.
Оптимизируя эффективность работы, получая выигрыш в производительности на 10% по сравнению с иерархичной командой, не забывайте о риск-менеджменте — в один день может вся ваша 300-сильная компания посыпаться, как карточный домик. Внутренние конфликты плохи тем, что они часто поначалу скрытые и когда «прорываются» — то становится уже поздно, т.к. открытый конфликт (ссора, ругань и прочее) практически всегда случается только тогда, когда всех действительно «достало». Вам нужен в команду человек, который будет пристально мониторить атмосферу и все эмоциональные флуктуации в коллективе, вовремя распознавать угрозы и избавляться от них.
Компания сыпалась до этого, иначе эти изменения не стали бы проводить просто так, по фану.
Мне кажется, это какой-то слишком громкий эпитет — «человек-катастрофа».
Прямо Омен какой-то, обычно люди не такие односторонние.
Если есть прозрачность и все знают, кто что делает и кто что не делает, то пространство для маневра маленькое и не получится сильно вредить.
Ну и в принципе, Scrum-мастер — это и есть сервисный инженер программерских душ. Его задача — налаживать общение в команде и помогать, но он не руководит.
Мне кажется, это какой-то слишком громкий эпитет — «человек-катастрофа».
Прямо Омен какой-то, обычно люди не такие односторонние.
Если есть прозрачность и все знают, кто что делает и кто что не делает, то пространство для маневра маленькое и не получится сильно вредить.
Ну и в принципе, Scrum-мастер — это и есть сервисный инженер программерских душ. Его задача — налаживать общение в команде и помогать, но он не руководит.
Конечно, люди разносторонние, и в этом весь цимес.
Я лично видел как минимум 2 примера, когда пришедшая в компанию стервочка перессорила между собой несколько человек. Специально они это делали или неосознанно — не знаю. Скорее всего что-то второе, перемешанное с какими-то комплексами. Ну вы же знаете, некоторые девочки любят стравливать мальчиков, смотреть как они потом за нее дерутся. ЧСВ повышается.
В одном случае один сотрудник ушел. Во втором все остались (как минимум несколько месяцев точно, что потом было не знаю т.к. мы перестали работать с той компанией по иным причинам). В обоих случаях эти инсинуации были «темой дня» в течение нескольких месяцев — еще бы, целая санта-барбара разворачивается на глазах! Думаю, не надо добавлять, что вместо обсуждения маркетинговой кампании или юзабилити нового сайта, все (особенно женская часть коллектива) охотнее перемывали кости главным героям. Атмосфера в коллективах была испорчена и в целом все пошло «не по плану».
Я лично видел как минимум 2 примера, когда пришедшая в компанию стервочка перессорила между собой несколько человек. Специально они это делали или неосознанно — не знаю. Скорее всего что-то второе, перемешанное с какими-то комплексами. Ну вы же знаете, некоторые девочки любят стравливать мальчиков, смотреть как они потом за нее дерутся. ЧСВ повышается.
В одном случае один сотрудник ушел. Во втором все остались (как минимум несколько месяцев точно, что потом было не знаю т.к. мы перестали работать с той компанией по иным причинам). В обоих случаях эти инсинуации были «темой дня» в течение нескольких месяцев — еще бы, целая санта-барбара разворачивается на глазах! Думаю, не надо добавлять, что вместо обсуждения маркетинговой кампании или юзабилити нового сайта, все (особенно женская часть коллектива) охотнее перемывали кости главным героям. Атмосфера в коллективах была испорчена и в целом все пошло «не по плану».
Добавлю что мне кажется хорошей схема с формальной иерархией, в который руководитель не управляет людьми а помогает им. Не мешает сотрудникам ошибаться, не мешает принимать решения и работать. И не делает всей той воспалённой хрени, что в россии ассоциируется со словом «начальник».
Ну, это, по сути, монархия, когда во главе стоит мудрый царь.
Я не спорю, это, пожалуй, самая эффективная схема, но, если хороший царь меняется на плохого, то все рушится.
За примерами можно обратиться к истории.
Если же правила игры установлены, то система продолжит быть довольно сильно устойчивой.
Я не спорю, это, пожалуй, самая эффективная схема, но, если хороший царь меняется на плохого, то все рушится.
За примерами можно обратиться к истории.
Если же правила игры установлены, то система продолжит быть довольно сильно устойчивой.
подход — «давайте все сломаем, и потом хаос может быть сам организуется» иногда может сработать, но это не системное решение. Это как поставить на зеро.
при аккуратном подходе — делая маленькие системные улучшения каждую неделю, можно добиться того же результата, но с гораздо большей вероятностью.
при аккуратном подходе — делая маленькие системные улучшения каждую неделю, можно добиться того же результата, но с гораздо большей вероятностью.
+1
Тоже считаю что с нуля не построить лучше чем есть сейчас, и это применимо практически везде. То что есть сейчас это хоть как-то работающая схема, причём она уже укоренилась в сознании стольких людей. Менять потихоньку маленькими шажками — мне кажется намного проще, нужно только направить эти постепенные изменения в нужную сторону.
Тоже считаю что с нуля не построить лучше чем есть сейчас, и это применимо практически везде. То что есть сейчас это хоть как-то работающая схема, причём она уже укоренилась в сознании стольких людей. Менять потихоньку маленькими шажками — мне кажется намного проще, нужно только направить эти постепенные изменения в нужную сторону.
А откуда возьмутся эти изменения?
Если сверху, то это на самом деле — микроменеджмент, когда руководитель начинает влезать в детали, которые можно оптимизировать.
В 99% случаев это не срабатывает и приводит к недовольству.
В конце концов, кому виднее, что надо поменять — вам с коллегами или начальнику?
Если вам, то вам нужна свобода принимать решения самостоятельно.
На начальном этапе такая свобода приводит к хаосу, это неизбежно.
Но, если вы решили что-то сами, внутри команды и пусть даже сфакапили, то это психологически лучше, чем когда чужое навязанное решение приводит к проблемам.
Если сверху, то это на самом деле — микроменеджмент, когда руководитель начинает влезать в детали, которые можно оптимизировать.
В 99% случаев это не срабатывает и приводит к недовольству.
В конце концов, кому виднее, что надо поменять — вам с коллегами или начальнику?
Если вам, то вам нужна свобода принимать решения самостоятельно.
На начальном этапе такая свобода приводит к хаосу, это неизбежно.
Но, если вы решили что-то сами, внутри команды и пусть даже сфакапили, то это психологически лучше, чем когда чужое навязанное решение приводит к проблемам.
изменения берутся из проблем. находится проблема и все вместе решают, какое маленькое улучшение можно сделать прямо на этой неделе.
кажется, вы не считаете менеджера частью команды :)
но это не так — все в одной лодке, но он еще и отвечает за результат команды перед своим начальником. и заказчиком.
если забить на менеджера и отдать власть команде — через пару месяцев будет нормальным решение: «заказчик хочет срочно впилить фичу — не дадим ему, у нас же спринт, мы тут по скраму работаем».
кажется, вы не считаете менеджера частью команды :)
но это не так — все в одной лодке, но он еще и отвечает за результат команды перед своим начальником. и заказчиком.
если забить на менеджера и отдать власть команде — через пару месяцев будет нормальным решение: «заказчик хочет срочно впилить фичу — не дадим ему, у нас же спринт, мы тут по скраму работаем».
Да, вы правы и это абсолютно нормальное решение. Если команда против, то не нужно ничего впиливать.
Понимаете, все эти «срочно впилить фичу» проистекают от недостатка планирования, в том числе на этапе анализа задач. Поэтому до планирования делают PBR, где рассматривают задачи и пытаются ответить на вопрос: «нет ли разницы между тем, что написано и что заказчик действительно хочет».
В любом случае команда должна напрямую работать с тем, кто ставит требования.
Понимаете, все эти «срочно впилить фичу» проистекают от недостатка планирования, в том числе на этапе анализа задач. Поэтому до планирования делают PBR, где рассматривают задачи и пытаются ответить на вопрос: «нет ли разницы между тем, что написано и что заказчик действительно хочет».
В любом случае команда должна напрямую работать с тем, кто ставит требования.
не соглашусь. заказчик платит деньги, и если он сказал, что надо — задача команды предложить решение, как это может быть сделано. например, убрать какие-то другие задачи из релиза.
если появилась необходимость «срочно впилить фичу» — у нее есть причины. или требования поменялись, или заказчик увидел решение и понял — «не то, надо иначе». это как раз повод копнуть глубже и найти простое решение, чтобы в будущем такие проблемы возникали реже.
недостаток планирования возможен в потоковых методологиях разработки.
если же команда работает по гибким методологиям и не готова к изменения — это повод задуматься.
если появилась необходимость «срочно впилить фичу» — у нее есть причины. или требования поменялись, или заказчик увидел решение и понял — «не то, надо иначе». это как раз повод копнуть глубже и найти простое решение, чтобы в будущем такие проблемы возникали реже.
недостаток планирования возможен в потоковых методологиях разработки.
если же команда работает по гибким методологиям и не готова к изменения — это повод задуматься.
Это как раз ложное представление, что бардак и гибкость — это одно и тоже.
Суть гибких методологий в том, что команда соглашается брать задачи, для которых нет формалированного описания и прорабатывает их сама через общение с заказчиком, а не через документы типа пресловутого ТЗ.
В процессе анализа задачи (да, планирование — это часть процесса, почитайте про backlog refinement) и в процессе работы над задачей требования могут меняться и это OK, но меняться не так, что сегодня мы пишем виджет для сайта, а завтра внезапно какой-то web-service. Это будет уже другая задача. То, что она появилась — это OK, но мы не берем ее сразу в работу.
Заставлять команду брать задачу посередине Спринта — это значит нарушать ту самую внутреннюю мотивацию, когда команда сама выбирает над чем ей работать.
Суть гибких методологий в том, что команда соглашается брать задачи, для которых нет формалированного описания и прорабатывает их сама через общение с заказчиком, а не через документы типа пресловутого ТЗ.
В процессе анализа задачи (да, планирование — это часть процесса, почитайте про backlog refinement) и в процессе работы над задачей требования могут меняться и это OK, но меняться не так, что сегодня мы пишем виджет для сайта, а завтра внезапно какой-то web-service. Это будет уже другая задача. То, что она появилась — это OK, но мы не берем ее сразу в работу.
Заставлять команду брать задачу посередине Спринта — это значит нарушать ту самую внутреннюю мотивацию, когда команда сама выбирает над чем ей работать.
команда соглашается брать задачи
честно, вот это выглядит так, как будто команда делает заказчику одолжение…
если в процессе работы над задачей заказчик понял, что ему нужен не виджет, а веб-сервис — смысл до конца спринта пилить то, что уже не нужно?
в том самом agile manifesto есть 2 важных пункта:
люди важнее процессов.
гибкость важнее следования плану.
если для команды следовать плану спринта важнее, чем отклониться от плана ради помощи заказчику — это не agile.
Опыт определенно интересный. Дополнительно было бы интересно узнать, не увеличились ли сроки с момента такой самоорганизации? Какое-то сравнение проводилось?
Первое время безусловно, но я бы не сказал, что все было по нулям.
Вначале все испытывают легкую эйфорию, как если бы камень упал с плеч.
Потом как-бы осторожно тестируют границы возможного.
Потом уходит какое-то время, чтобы научиться эффективно коммуницировать друг с другом.
Без оров и эго.
Удовлетворение от работы понемногу растет и это влияет на производительность, но не напрямую.
Тут надо понимать, что плохой дев не станет хорошим только потому, что ему дали свободу.
Но, при наличии открытой среды, где можно не бояться признавать свои ошибки и просить помощи, можно реально расти. А это уже приведет к росту результатов.
Вначале все испытывают легкую эйфорию, как если бы камень упал с плеч.
Потом как-бы осторожно тестируют границы возможного.
Потом уходит какое-то время, чтобы научиться эффективно коммуницировать друг с другом.
Без оров и эго.
Удовлетворение от работы понемногу растет и это влияет на производительность, но не напрямую.
Тут надо понимать, что плохой дев не станет хорошим только потому, что ему дали свободу.
Но, при наличии открытой среды, где можно не бояться признавать свои ошибки и просить помощи, можно реально расти. А это уже приведет к росту результатов.
Ничего удивительного что в другой команде по вашему мнению народ лучше-было бы страннго если бы было по другому.
По поводу свободы-нет смысла давать свободу, это приводит к анархии. К свободе надо прийти или даже завоевать. Только такая свобода ценится. Ну и кто сказал что мотивация не нужна? Команду нужно постоянно мотивировать, воспитывать, иначе нет смысла что-либо начинать.
По поводу свободы-нет смысла давать свободу, это приводит к анархии. К свободе надо прийти или даже завоевать. Только такая свобода ценится. Ну и кто сказал что мотивация не нужна? Команду нужно постоянно мотивировать, воспитывать, иначе нет смысла что-либо начинать.
из шкафа на нас опять выглядывает призрак штрафов за опоздания
Есть много видов деятельности, где опоздания не допустимы.
Выходя утром из дома, иногда наблюдаю очередь у дверей отделения всем известного банка на букву «С». И хотя в режиме работы указано, что банк открывается в 9:00, иногда это происходит на 10-15 минут позднее. Наверное, управляющий поддерживает «дух свободы и творчества», а также свободный график работы.
Компания размером в 300-400 девелоперов.
Интересно, как решились на эксперимент сразу со всей компанией? Хоть Ларман и крутой мужик, но вот так сразу…
Я не писал, что я поддерживаю опоздания. Я писал, что с ними борятся контр-продуктивно.
Страх и наказания — не лучшие мотиваторы.
У нас это решалось тем, что стэндап — это обязательный митинг и всех просят на нем быть.
Первое время народ опаздывал, но постепенно ситуация выравнялась.
На эксперимент решились, потому как бизнес идет вниз и перемены назрели.
Поэтому перешли от component-teams к feature-teams, а заодно поменяли процесс.
На самом деле, очень смелый эксперимент и хороший кейс, но об успехах пока рано говорить.
Тут около 200 человек только в 1м офисе, а есть еще разработка в 2-3х разных странах.
Про распределенный скрам можно отдельную статью писать.
Страх и наказания — не лучшие мотиваторы.
У нас это решалось тем, что стэндап — это обязательный митинг и всех просят на нем быть.
Первое время народ опаздывал, но постепенно ситуация выравнялась.
На эксперимент решились, потому как бизнес идет вниз и перемены назрели.
Поэтому перешли от component-teams к feature-teams, а заодно поменяли процесс.
На самом деле, очень смелый эксперимент и хороший кейс, но об успехах пока рано говорить.
Тут около 200 человек только в 1м офисе, а есть еще разработка в 2-3х разных странах.
Про распределенный скрам можно отдельную статью писать.
Вы не поверите, но большинству людей нужен как пряник, так и кнут. Можно сколько угодно говорить о начальниках-самодурах, но факт остается — должна быть система разумных наказаний за невыполнение правил трудового договора. Как и система поощрений за обратное, кстати говоря.
Прежде чем спорить, подумайте, что ваш стэндап мотивировался только страхом, хоть Вы в это не захотите поверить. Какие плюшки давались за участие на митинге? Видимо, никаких. Зато был отличный мотиватор — страх показаться лентяем, «нелояльным компании» человеком и прочее. Ну или просто страх «меня будут осуждать коллеги». Если бы на стэндап попросила явиться ваша уборщица, на следующее утро никто бы не пришел на него. Но наверняка идею стэндапа озвучил какой-то начальник (и теперь все на него ходят из-за того же самого страха перед начальником), или неформальный лидер коллектива (и теперь все ходят на стэндап чтобы коллеги не смотрели косо по типу «как это так, все ходят, встают рано, а Иванов не ходит! наглец!»).
Прежде чем спорить, подумайте, что ваш стэндап мотивировался только страхом, хоть Вы в это не захотите поверить. Какие плюшки давались за участие на митинге? Видимо, никаких. Зато был отличный мотиватор — страх показаться лентяем, «нелояльным компании» человеком и прочее. Ну или просто страх «меня будут осуждать коллеги». Если бы на стэндап попросила явиться ваша уборщица, на следующее утро никто бы не пришел на него. Но наверняка идею стэндапа озвучил какой-то начальник (и теперь все на него ходят из-за того же самого страха перед начальником), или неформальный лидер коллектива (и теперь все ходят на стэндап чтобы коллеги не смотрели косо по типу «как это так, все ходят, встают рано, а Иванов не ходит! наглец!»).
Интересная вещь. Я читаю ваши «морковки спереди и сзади», ничего не цепляет.
Премия? Поощрения? Прикольно, но в общем-то не мотивирует.
Показаться лентяем или нелояльным, будут осуждать коллеги? Да какая разница, что обо мне думают неофициально, лишь бы не мешали работать.
Официально предъявят штраф? В течение 5 минут будет написано заявление об увольнении.
Понравилась цитата из недавно прочитанной книги Дж. Коллинза «От хорошего к великому» (очень рекомендую):
«… если у вас на борту нужные люди, то проблема мотивации и управления, в принципе, исчезает сама собой. Нужные люди не нуждаются в непосредственном руководстве или стимулах; у них достаточно самомотивации, обусловленной внутренним стремлением добиться исключительных результатов и участвовать в создании чего-то великого.»
Можно допустить, что в описанной автором компании как-то так «волшебным образом» собралась критическая масса нужных людей. Или осознанный подбор остался за кадром :)
Премия? Поощрения? Прикольно, но в общем-то не мотивирует.
Показаться лентяем или нелояльным, будут осуждать коллеги? Да какая разница, что обо мне думают неофициально, лишь бы не мешали работать.
Официально предъявят штраф? В течение 5 минут будет написано заявление об увольнении.
Понравилась цитата из недавно прочитанной книги Дж. Коллинза «От хорошего к великому» (очень рекомендую):
«… если у вас на борту нужные люди, то проблема мотивации и управления, в принципе, исчезает сама собой. Нужные люди не нуждаются в непосредственном руководстве или стимулах; у них достаточно самомотивации, обусловленной внутренним стремлением добиться исключительных результатов и участвовать в создании чего-то великого.»
Можно допустить, что в описанной автором компании как-то так «волшебным образом» собралась критическая масса нужных людей. Или осознанный подбор остался за кадром :)
Нет, это не страх, это такой дискомфорт, когда вы сами понимаете, что делаете что-то неправильно.
Например, вот у вас посуда не помыта.
Вы ее моете, потому что боитесь, что жена/подруга вынесет вам мозг, когда ее найдет.
Или вам просто не нравится, когда дома непорядок?
«Разумных» наказаний, к сожалению, не бывает, есть просто наказания.
Например, вот у вас посуда не помыта.
Вы ее моете, потому что боитесь, что жена/подруга вынесет вам мозг, когда ее найдет.
Или вам просто не нравится, когда дома непорядок?
«Разумных» наказаний, к сожалению, не бывает, есть просто наказания.
Еще пять копеек.
Знаю такие примеры, да и на своей шкуре разок прочувствовал.
Человек может косячить, потому что работает не «в своем режиме». И человек может косячить, потому что так пошло и все привыкли, что он косячит.
Второй случай — и так понятен. Первый — был со мной. Я очень хорошо работаю в режиме «черного ящика», когда на входе описание интерфейса или задачи, на выходе результат, что внутри никого не должно волновать. Оно работает и соответствует спеке. В идеале — изначально пишутся тесты, покрывающие все сценарии. А когда начинают описывать по частям структуру конечного модуля, да еще и спека толком отсутствует, хочется застрелиться. Плюс поскольку приходится удерживать в голове требования по внутренней архитектуре — периодически бывают косяки и тормоза. Разговор с руководителем ни к чему не привел, ведь «ты же даже в маленьких вещах косячишь, как тебе можно доверить что-то большое».
Что делать с работником, который постоянно косячит
Знаю такие примеры, да и на своей шкуре разок прочувствовал.
Человек может косячить, потому что работает не «в своем режиме». И человек может косячить, потому что так пошло и все привыкли, что он косячит.
Второй случай — и так понятен. Первый — был со мной. Я очень хорошо работаю в режиме «черного ящика», когда на входе описание интерфейса или задачи, на выходе результат, что внутри никого не должно волновать. Оно работает и соответствует спеке. В идеале — изначально пишутся тесты, покрывающие все сценарии. А когда начинают описывать по частям структуру конечного модуля, да еще и спека толком отсутствует, хочется застрелиться. Плюс поскольку приходится удерживать в голове требования по внутренней архитектуре — периодически бывают косяки и тормоза. Разговор с руководителем ни к чему не привел, ведь «ты же даже в маленьких вещах косячишь, как тебе можно доверить что-то большое».
Могу сказать по себе, что адекватно воспринимать чужое мнение — это скилл, который сложно прокачивать.
Не всегда люди выражают себя так, что можешь абстрагироваться от, так скажем, формы и понять содержание.
Но в разработке коммуникации — это половина успеха.
У нас все, даже самые опытные девелоперы не садятся за большие задачи, не обсудив с коллегами.
Я бы даже больше сказал, если я не могу удержать в голове цельную картину, я открыто попрошу еще кого-то поработать вместе.
Это ok и не воспринимается никем, как слабость.
Лучше вначале потратить немного времени и выработать верный подход, чем потом переделывать.
Не всегда люди выражают себя так, что можешь абстрагироваться от, так скажем, формы и понять содержание.
Но в разработке коммуникации — это половина успеха.
У нас все, даже самые опытные девелоперы не садятся за большие задачи, не обсудив с коллегами.
Я бы даже больше сказал, если я не могу удержать в голове цельную картину, я открыто попрошу еще кого-то поработать вместе.
Это ok и не воспринимается никем, как слабость.
Лучше вначале потратить немного времени и выработать верный подход, чем потом переделывать.
Могу сказать по себе, что адекватно воспринимать чужое мнение — это скилл, который сложно прокачивать.
Не всегда люди выражают себя так, что можешь абстрагироваться от, так скажем, формы и понять содержание.
Но в разработке коммуникации — это половина успеха
По себе могу сказать, что от этого качества больше всего зависит слаженная работа команды. Конечно в большой команде работать не доводилось, но даже в малой группой из 2-3 разработчиков без этого качества работать невозможно.
В свое время у нас сложился ряд правил, или скорее принципов, которых мы всегда придерживаемся при работе:
1. Каждый может высказать свое мнение, не стесняясь в выражениях, и восприниматься оно должно как есть, без поиска скрытого смысла и двойного дна.
2. Любое замечание или идея, даже самая бредовая на первый взгляд, должна обязательно быть беспредвзято рассмотрена всей командой;
3. Последнее и, наверно, самое нелогичное после первых двух: у проекта может быть только 1 «лидер» и он, и только он, принимает окончательное решение как быть дальше, а остальные только советуют.
Последнее правило правда будет нормально работать только в устоявшейся команде, когда «начальник» только первый среди равных, а иначе будут проблемы.
PS. И наверно только благодаря этим принципам и абсолютному доверию мы смогли познать дзен и фан парного программирования. Это оказалось очень весело и очень продуктивно, особенно при правке багов.
PSS. Удачного завершения ваших начинаний.
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
Как управлять командой — история одного успеха