Мотивация на селе. И не только.

[Ольга Кряжич]

Так устроена система. Назвался груздем-полезай в кузов.

Нет, ну эта проза жизни мне известна... Только в рамках данной темы она слишком "приземленная".

[Евгений_Кс]

Мы равнозаинтересованные партнеры. Это совсем другая ситуация

(Кажись... Кажись... Редкое счастье консенсуса близко...)
Да та эта ситуация!!!

[Михаил_Шустер]

Да та эта ситуация!!!

Для двоих - та
Для 7,5 тыс чел. - не та

[Михаил_Шустер]

Только в рамках данной темы она слишком "приземленная".

Похоже, тут "приземлятелями" работаем только мы с Болдиным
Злые потому что
Или потому что крупные предприятия. "Размер имеет значение"?

[Евгений_Кс]

Для двоих - та
Для 7,5 тыс чел. - не та

А для троих?
А для четверых?

[Ольга Кряжич]

Или потому что крупные предприятия. "Размер имеет значение"?

Чем больше система, тем сложнее управляемость.
А если "отсечь" все лишнее?

[via]

А для троих?
А для четверых?

Вспомнился мультик про мартышку и слонёнка. Там мартышка, допытывалась у слонёнка, с какого количества бананов, «несколько» становится «кучей».
Не берусь количественно определить точку бифуркации, а вот качественно, «несколько» становятся «кучей», когда теряется способность/возможность договориться. Тогда, либо происходит иерархическое структурирование, либо «куча» остаётся, ни на что не способной, кучей.
В связи с этим напрашивается вывод - в социальных группах «куча» может быть меньше «несколько». Двое, не могущих, договориться – куча. Четверо договорившихся – несколько.

[alex9994]

Чем больше система, тем сложнее управляемость.
А если "отсечь" все лишнее?

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

[Ольга Кряжич]

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

Ох уж эта постоянная величина.... "лишних"...

[Михаил_Шустер]

А если "отсечь" все лишнее?

Все просто.
Иерархия (оргструктура) - это и есть отсечение лишних

[Евгений_Кс]

Все просто.
Иерархия (оргструктура) - это и есть отсечение лишних

Не скажите.
В соседней ветке Болдин утверждает, что топы (звено замов) - лишний уровень управления: "Интересно. Мне что каждое слово сопровождать 100к пояснений? Топ-менеджемент не нужен"
Так что иерархия иногда и порождение лишних!

[Евгений_Кс]

Вспомнился мультик про мартышку и слонёнка. Там мартышка, допытывалась у слонёнка, с какого количества бананов, «несколько» становится «кучей».
Не берусь количественно определить точку бифуркации, а вот качественно, «несколько» становятся «кучей», когда теряется способность/возможность договориться. Тогда, либо происходит иерархическое структурирование, либо «куча» остаётся, ни на что не способной, кучей.
В связи с этим напрашивается вывод - в социальных группах «куча» может быть меньше «несколько». Двое, не могущих, договориться – куча. Четверо договорившихся – несколько.

+1
Михаил, в компании Google сумели договориться несколько тысяч человек.
Извиняюсь за мой ломаный английский, но даже термин есть такой:
engineer-centric компания.
То есть компания, центрированная на сотрудниках, а не на верхних звеньях иерархии.

[Bend]

В одной из тем была ссылка на интервью с русским сотрудником Google.
Очень интересная и про это говорили

[Ольга Кряжич]

Все просто.
Иерархия (оргструктура) - это и есть отсечение лишних

Ну, судя по тому, что на месте "лишних" появляются новые "лишние"... То в итоге резать-то нечего будет.
А вообще мне тут один умный человек (В. Пикуза) по электронной почте "нашептал", что "чем больше система - тем легче управлять"....

...Только что-то от мотивации на селе мы ушли как село от колхоза...

[Георгий Лейбович]

... А вообще мне тут один умный человек (В. Пикуза) по электронной почте "нашептал", что "чем больше система - тем легче управлять"....

Потому что Владимир умный. Только он имел в виду, я думаю, не просто размер, а связность системы, ибо чем больше связей, тем меньше степеней свободы и легче управлять, если разобрался, где точки управления. См. Теория ограничений (The Theory of Constraints), ограничения (Constraints), управления в точках ограничений (Constraint Management). Или не смотри, так как, как я уже цитировал, "Выживание есть дело добровольное".

[Ольга Кряжич]

Потому что Владимир умный. Только он имел в виду, я думаю, не просто размер, а связность системы, ибо чем больше связей, тем меньше степеней свободы и легче управлять, если разобрался, где точки управления. См. Теория ограничений (The Theory of Constraints), ограничения (Constraints), управления в точках ограничений (Constraint Management). Или не смотри, так как, как я уже цитировал, "Выживание есть дело добровольное".

Совершенно верно!!! С этим не поспоришь (относиться абсолютно ко всему сказанному).

[Евгений_Кс]

один умный человек (В. Пикуза) ....
...Только что-то от мотивации на селе мы ушли как село от колхоза...

1. Пикузу в студию!
2. Ольга, не тяните нас назад в село - оно было только иллюстрацией.

[cotbur]

))) А почекму бы и нет? Хотя я никогда не верил, что за селом будущее, но может я просто ошибаюсь? Кто может сказать точно... Я думаю, что в будущем мы посмотрим как быдет на самом деле.

[Ольга Кряжич]

Ольга, не тяните нас назад в село - оно было только иллюстрацией.

Вот так значит! Как поговорить - так сразу все! А в селе нонче - горячая пора, каждые свободные руки (не уши!) на счету!
... Я то думала "танки" (читать как гуру) грязи не боятся!

[Bend]

Вот так значит! Как поговорить - так сразу все! А в селе нонче - горячая пора, каждые свободные руки (не уши!) на счету!
... Я то думала "танки" (читать как гуру) грязи не боятся!

Ольга, "все" или "всё"? Смысл меняется))

.... село - оно было только иллюстрацией.

Живые люди со своими особенностями, спецификой отношения к окружающему миру и потребностями.

[Евгений_Кс]

Нарыл замечательную статью Дениса Войханского:
http://www.dtf.ru/articles/read.php?id=46346

Вот две цитаты оттуда.


Закон Листера
Физическую работу, да, можно ускорить, но наши-то бойцы занимаются умственным трудом. Думать быстрее от того, что кто-то давит, не получится. Это известно как закон Тома Листера: Если надавить как следует, люди не будут думать быстрее, но любить свою работу будет меньше. Это ключевая мысль. Наша способность производить умственные усилия - она fixed rate...


Мотивация полувековой давности была смещена в сторону внешней мотивации - деньги, признание. Наша мотивация скорее внутренняя: развитие, интересная работа, самоуважение, познание. Внешняя мотивация, так называемый метод кнута и пряника, эффективен, если люди испытывают сильную нужду или запуганы. Сытые не станут плясать под вашу дудку, надеясь получить пряник, а уверенные в себе не позволяет себя бить.
Традиционный менеджмент, пинание людей, это менеджмент Подчинения. "Вы делаете, что мы вам говорим, а мы компенсируем это зарплатой". Вот второе фундаментальное отличие - тип работы сейчас поменялся. То, чем мы сейчас занимаемся, называется Knowledge Work, мы работники знания.
В современных условиях сотрудники должны сами думать, предлагать оригинальные идеи, ставить перед собой сложные цели и самостоятельно определять пути их достижения. А это требует не просто подчинения, это требует истинной приверженности компании, отождествления человека с компанией, способствование успеху компании. Это и есть современное руководство - добиваться не подчинения, а приверженности, которая рождается в чувствах и умах людей.

[Евгений_Кс]

Есть область производственной деятельности, в которой принципы командной работы и сотрудничества становятся необходимым условием конкурентного преимущества.
Это разработка программного обеспечения.
По-видимому, масштаб программных проектов, сложность работы, необходимость координации работ многих людей, творческий характер работы привели к таким вещам, как Agile технологии, engineer-centric компания, то есть к выстраиванию работы предприятий на принципах командной работы.

Вот несколько ссылок.
1. Интервью с сотрудником Google Артемом Бойцовым, ссылку уже давал в другой теме:
http://www.happy-pm.com/HPM-Interview-Artem_Boytsov.mp3
2. Аудиозапись "Круглого стола" по team building:
http://www.happy-pm.com/mp3/HPM_roun...ding_part1.mp3
http://www.happy-pm.com/mp3/HPM_roun...ding_part2.mp3
3. Интернет - ресурсы по гибким методологиям разработки программ:
http://agilerussia.ru/
http://agiledev.ru/

[Andruxa]

По поводу agile... долго можно говорить.
Я их не очень люблю, хоть и применяю. Строго говоря, это не методики управления проектами, это - управление процессом разработки. На такой подход должен согласиться спонсор (обычно заказчик).

Гибких методик много, и все они достаточно разные. И чаще всего их всё же применяют для небольших команд. XP - экстремальное программирование - действительно экстремальное. Я больше люблю feature driven development - когда продукт разрабатывается мелкими итерациями по списку features. Но что в них общего - так это невысокая степень детализации задач, а разработка мелкими итерациями. Это весьма своеобразные методики, и если заказчик платит fixed volume, то далеко не всегда подходит, а вот если он готов платить за свои "хочухи" сколько влезет - то пожалуйста, но это уже не проект, а сервис, организованный по гибким методикам. Это действительно новый способ взаимодействия, этот сервис по разработке, но не сказать что оригинальный Это как бы если бы Вы парикмахера походу постоянно поправляли, вначале сказав лишь "покороче"... а вот я обычно сразу говорю что нужно.

На самом деле, не так-то с ними всё и страшно, выросли они действительно из-за признания изначальной проблемности деятельности по разработке ПО как творческой, и из-за этого, сложно прогнозируемой. Гибкие технологии как бы достраивают проектный треугольник "время-стоимость-объём" до тетраэдра вершиной "характер организации работ". Т.е. тот же объем работ осваивается постепенным продвижением, мелкими итерациями.

Для поддержания качества уже используются гибкие техники разработки ПО. Вот тут действительно находки. Например, регрессионное тестирование (когда тесты накапливаются в процессе и прогоняются постоянно), парное программирование (спорный момент, особенно финансово) и другие.

Но я предпочитаю нечто по типу RUP, когда процессы пересекаются, имеют итерации, но всё же они раскладываются каскадом. Не люблю изначальную кашу из всего. Может просто из-за того что так привык.

[Евгений_Кс]

По поводу agile... это - управление процессом разработки.

Вот и специалист по Agile рядом. Классно.
Я бы хотел сделать одно уточнение.
Да, речь идет об организации работы коллектива по созданию программного продукта.
И в этой организации можно выделить две особенности.
Первую, о которой говорит Андрей.
И вторую, которая интересна мне.
Первая особенность - это организация работы с активной, частой обратной связью от заказчика: "невысокая степень детализации задач, разработка мелкими итерациями. ... Это как бы если бы Вы парикмахера по ходу постоянно поправляли, вначале сказав лишь "покороче""
Вторая особенность для меня более важна в контексте темы топика.
Это организация работы коллектива по принципам командного взаимодействия. Когда все принципиальные вопросы решает команда. А роль руководителя сводится к обеспечению условий работы и разрешению возникающих проблем.
Как говорит Сергей Архипенков в Круглом столе по team building, он даже не назначает работы. Он создает и пополняет список работ, и этот список "разбирается" членами команды...

[Andruxa]

Как говорит Сергей Архипенков в Круглом столе по team building, он даже не назначает работы. Он создает и пополняет список работ, и этот список "разбирается" членами команды...

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

[Bend]

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

А есть такие области производственной деятельности, где конкурентное преимущество командной работы не может быть обязательным?
Просто интересно...
P.S. Интервью с Бойцовым интересное очень

[Ольга Кряжич]

Шустер в отпуске, Болдин в отпуске...
Форум хоть закрывай!
Тишина.
А еще говорят - незаменимых не бывает!
Ауу!!! Возвращайтесь побыстрее!

[Евгений_Кс]

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

Хороший вопрос.
Полагаю, есть два критерия.
Необходимая скорость принятия решений и сложность деятельности.
В бою может работать только единоначалие.
В несложной, повторяющейся деятельности (физическая работа, конвейер) администрирование, вероятно, предпочтительнее.

[vespol]

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

То, что здесь описывается, очень похоже на результаты использования технологии "открытого управления".

Но, что очень важно, она родилась не в сложных проектах, типа разработки ПО, а в обычном производственном процессе

[Bend]

Хороший вопрос.
Полагаю, есть два критерия.
Необходимая скорость принятия решений и сложность деятельности.
В бою может работать только единоначалие.

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

В несложной, повторяющейся деятельности (физическая работа, конвейер) администрирование, вероятно, предпочтительнее.

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