N_C>>Т.е. ты все-таки подтверждаешь различия по национальному признаку...
MSS>Нет, я описываю конкретные виденные мною (и плотно) социальные среды, они как правило были русские.
MSS>Я совсем не удивлюсь, если в Америке то же самое.
Ты начинаешь себе противоречить... Если ты не знаешь, как в Америке, то почему ты споришь с теми, кто видел (я не про себя)?

Здравствуйте, Maxim S. Shatskih, Вы писали:

G>>Ерунда. Личный кабинет удобен по другой причине — он используется как личная переговорная руководителя по разным вопросам, в том числе и конфиденциальным. В крупной компании это также подчеркивает статус руководителя.

MSS>То есть вы полностью отрицаете соображения _комфорта_, связанные с наличием личного кабинета?

Отнюдь. Личный кабинет дает тишину и комфорт. Также, начальнику очень удобно в нем переодеваться в костюм при необходимости, приходя на работу в джинсах .

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

MSS>Помимо высказанных вами (и верных) мыслей, личный кабинет — это комфорт. Точно так же как и, например, снижение плотности рассадки в общем зале или увеличение размеров личного рабочего стола.

Есть плюсы для начальника и сидения в общем зале, которые нивелируют этот комфорт. Они не менее важны.

MSS>Пересадив людей из кабинетов по 1 (лиды) — 2 (рядовые) человека в общий зал или кубиклы, компания снизила их комфорт. Считайте, что это равносильно отъему премии.

Не думаю.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Русские не работают в аврале. Это раз. У русских авралы бывают время от времени, обычно к майлстону — это да. Но это не значит, что русские не работают равномерно и прямолинейно между авралами. Совсем нет.

MSS>Видел я и американцев, работающих в аврале. Это два.

MSS>Ничего в этом удивительного нет, хотя, конечно, любые авралы (возникающие, естественно, к майлстону, а не как общий стиль работы команды — общем стилем работы они не являются и являться не могут) есть огрехи ПиЭма, но огрехи таки случаются, и в России, и в Америке.

Эта... Про "майлстон".
Опенсоурсник я. Нет у меня ни майлстонов ни дедлайнов.
А работаю авралами. Почему? Потому что мысль.
Если мысль забудешь, то придется думать ее снова.
Вот и работаю — месяц подготовки + 1 день (на самом деле ночь ) аврала.

A>>А то, что русский учится "в процессе", а американец на курсах?

MSS>Роль курсов крайне низка и в России, и в Америке. Они скорее играют роль на уровне разницы между "полным валенком" и "начинающим". Не более. На уровнях повыше курсы не играют никакой роли ни там, ни там.

MSS>Так что еще один тупой штамп.

Не-а. Поработай в американской конторе.

A>>А то, что американцы "думают хором", а русским нужен "командир"?

"MSS>Толковым русским девелоперам никакой командир никак не нужен. Более того — они крайне, чудовищно склонны к занятию роли "оппозиционера". У них есть некие амбиции, если компания может их удовлетворить — она получает великолепно лояльного себе толкового сотрудника. Если не может — получает неудобного оппозиционера.

MSS>Все это видено мною много раз. Бестолочам, возможно, командир нужен, но я изначально не о бестолочах.

MSS>В среде умных русских человек с лидерско-харизматическими качествами, претендующий на "командирство", вызовет немедленное отвращение, крайне сходное с отвращением многих людей (опять же не самых глупых) к политической партии "Единая Россия".

MSS>Вы никогда этого не видели? а я видел почти всегда

Какой маленький у тебя опыт...
У русских всегда должен быть Генеральный Конструктор — человек, который видит проблему в целом.
Примеры таких персонажей — Королев, Микоян и т.п. У ГК есть подчинённые, у тех свои подчиненные.
И так далее. Пирамидальная иерархическая система, структура которой соответсвует структуре задачи.

А у американов... как-то всё иначе — на горизонтальных связях.
Они вполне могут втроем делать процессор.
Причем один отвечает за ядро, другой за векторные операции, а третий за прерывания.
И НИКТО из этих троих не знает, как это работает в целом. Как-то справляются.

А насчет "лидерско-харизматических" качеств... Вы "лидера" от "хама" отличить можете?
Я это к тому, что русские умных людей уважают. В отличие от американцев,
которые придумали поговорку "если ты такой умный, то почему такой бедный".

А насчет "толковым девелоперам командир не нужен" — это детский комплекс.
"Мания величия" называется (не путать с "комплексом Наполеона")

A>Опенсоурсник я. Нет у меня ни майлстонов ни дедлайнов.

Угу, ни сроков, ни требований. Вы не работаете, вы играетесь. Играться можно разными способами, но к работе это все имеет малое отношение.

A>Не-а. Поработай в американской конторе.

С 99 года работаю только с американцами. До того работал в достаточно крупной российской команде. Разницы в девелоперах просто нет. В стиле руководства — есть.

A>У русских всегда должен быть Генеральный Конструктор — человек, который видит проблему в целом.

Утверждение неверно. Потому что видел в жизни иное.

A>А у американов... как-то всё иначе — на горизонтальных связях.
A>Они вполне могут втроем делать процессор.
A>Причем один отвечает за ядро, другой за векторные операции, а третий за прерывания.
A>И НИКТО из этих троих не знает, как это работает в целом. Как-то справляются.

Видел и русских, которые так могут. Кстати, это наиболее эффективные команды.

A>А насчет "лидерско-харизматических" качеств... Вы "лидера" от "хама" отличить можете?
A>Я это к тому, что русские умных людей уважают. В отличие от американцев,
A>которые придумали поговорку "если ты такой умный, то почему такой бедный".

Эта поговорка и в России активно применяется, думаю, не меньше, чем в Америке.

A>А насчет "толковым девелоперам командир не нужен" — это детский комплекс.

Так это сами толковые девелоперы так думают, а иногда и не очень толковые.

Я ни разу не видел паттерн "следуй за лидером!" у людей с развитым интеллектом.

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

С точки зрения качества продукта и эффективности работы это все не нужно. Но это очень нужно с психологической точки зрения. Тупая отдача приказа "копать от забора и до обеда" неизбежно породит оппозицию, а это чисто психологическое явление потом и на качестве и сроках разработки продукта скажется. Если же уступить человеку в непринципиальных мелочах — то человеку это будет приятно, к нему прислушались, он значим.

Если же строить команду в стиле "несколько умных, понимающих друг друга с полуслова людей" — то там вообще лидера нет как такового.

Вы почти во всем правы, кроме того, что человеку все равно, где сидеть — в кубиклах или в кабинете.

MSS>>Пересадив людей из кабинетов по 1 (лиды) — 2 (рядовые) человека в общий зал или кубиклы, компания снизила их комфорт. Считайте, что это равносильно отъему премии.

G>Не думаю.

Попробуйте на практике — найдите сотрудника "с кабинетом" и пересадите в дальний угол общего зала. Недовольство гарантировано. Он это воспримет как понижение.

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

Особенно это ощутимо, если не только кабинета (т.е. перегородок) лишили, а и метраж личного пространства сократили.

Не зря в Микрософте программисты не сидят в кубиклах и залах, ой не зря

MSS>Не зря в Микрософте программисты не сидят в кубиклах и залах, ой не зря

А где они там сидят, если не секрет?

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Вы почти во всем правы, кроме того, что человеку все равно, где сидеть — в кубиклах или в кабинете.

MSS>>>Пересадив людей из кабинетов по 1 (лиды) — 2 (рядовые) человека в общий зал или кубиклы, компания снизила их комфорт. Считайте, что это равносильно отъему премии.

G>>Не думаю.

MSS>Попробуйте на практике — найдите сотрудника "с кабинетом" и пересадите в дальний угол общего зала. Недовольство гарантировано. Он это воспримет как понижение.

Он воспримет это как понижение статуса. Потому, что он в кабинете, как белый человек, и к нему все ходили на ковер, а теперь он как лох в общем зале сидит.

Это, разумеется, не равносильно отъему премии, про которое никто кроме нашего сотрудника не узнает. Однако, если пересадить всех ночальнегов одновременно, объяснив всем, с какой целью это делается, и аккуратно адресовав момент статуса, то все будет в порядке.

Здравствуйте, Аноним, Вы писали:

MSS>>Не зря в Микрософте программисты не сидят в кубиклах и залах, ой не зря

А>А где они там сидят, если не секрет?

В кабинетах по 1-2 человека. Размер кабинета — метра 3 на 4, ну, может, 4 на 5 — я там с рулеткой не бегал. Достаточно большой, чтобы на одного сотрудника могло приходится 2 больших стола и куча компов.

У кабинетов стеклянная стена с дверью в сторону коридора. Закрыта жалюзами.

G>Он воспримет это как понижение статуса. Потому, что он в кабинете, как белый человек, и к нему все ходили на ковер, а теперь он как лох в общем зале сидит.

И это тоже, а еще есть вопрос личного пространства. Скажем, девушке зимой в Москве придется переобуваться в своем личном помещении — или посреди зала. Есть разница?

Кубиклы, кстати, потому и придумали, что они максимально дешевым для компании образом дают личное пространство.

G>Это, разумеется, не равносильно отъему премии, про которое никто кроме нашего сотрудника не узнает. Однако, если пересадить всех ночальнегов одновременно, объяснив всем, с какой целью это делается, и аккуратно адресовав момент статуса, то все будет в порядке.

Помимо статуса, есть еще комфорт. Я понимаю, что скорее всего никто не уволится и не уйдет на новую работу, где будет кабинет , но чем черт не шутит.

MSS>У кабинетов стеклянная стена с дверью в сторону коридора. Закрыта жалюзами.
Кстати, это тоже не сильно дорогое решение... Сейчас такие стенки возводятся за один рабочий день (если не меньше)...

Здравствуйте, Gaperton, Вы писали:

G>Это, разумеется, не равносильно отъему премии, про которое никто кроме нашего сотрудника не узнает. Однако, если пересадить всех ночальнегов одновременно, объяснив всем, с какой целью это делается, и аккуратно адресовав момент статуса, то все будет в порядке.
это несомненно сгладит несколько положение, но все равно довольных много не будет — сужу по своему личному опыту и тому что наблюдаю вокруг прямо сейчас: некоторое время назад в компании после продажи пиндосам провозгласили "SCRUM в каждый дом" и имел\имею счастье наблюдать как сам переезд в "общее пространство" одновременно (то есть в целом все делают правильно — все долго, нудно и заранее предупреждали, вообще PR переезда на SCRUM проведен был на 4+), так и то как люди к этому относятся с обоих сторон баррикад.


кстати, часть начальников (например архитектор) стала постоянно работать из дома, появляясь в этом open space (у нас неск SCRUM команд рядом сидят) только по крайней необходимости, другая тоже не сильно счастлива и дистанцировалась от разработчиков по углам, которые на общем фоне теперь выглядят обособленно — как кабинеты до этого... желание прикрыть спину присуще людям с древних времен. равно как не очень довольны и разрабы\QA, сдернутые с насиженных мест. но все конечно не бузят в открытую — понимают что ничего не изменить, только натянуто улыбваются "it's OK... I'm fine... not a problem for me", правда с кислыми минами.

а ведь до этого в старом офисе мы сидели как Максим про MSFT описывает, и тоже было очень не здорово переезжать еще до SCRUM просто в совершенно новый офис хоть и мега дорогой "самый модный в Люксе — по посл слову строительства бизнес-центров". Старые немодные кабинеты однозначно всем с кем обсуждали нравились больше — чем этот модный офис где всех стали сажать в open space стиле. А теперь еще и с этим SCRUMом скучили народ еще больше — личное пространство уменьшилось, шума прибавилось — со всеми вытекающими по ДеМарко\Листеру.

такие дела.

Здравствуйте, Valery A. Boronin, Вы писали:

VAB>а ведь до этого в старом офисе мы сидели как Максим про MSFT описывает, и тоже было очень не здорово переезжать еще до SCRUM просто в совершенно новый офис хоть и мега дорогой "самый модный в Люксе — по посл слову строительства бизнес-центров". Старые немодные кабинеты однозначно всем с кем обсуждали нравились больше — чем этот модный офис где всех стали сажать в open space стиле. А теперь еще и с этим SCRUMом скучили народ еще больше — личное пространство уменьшилось, шума прибавилось — со всеми вытекающими по ДеМарко\Листеру.

Ну, это уже плохо. Есть мнение, что в данном случае Scrum использовался как оправдание экономии на рабочих местах.

Здравствуйте, Maxim S. Shatskih, Вы писали:

A>>Опенсоурсник я. Нет у меня ни майлстонов ни дедлайнов.

MSS>Угу, ни сроков, ни требований. Вы не работаете, вы играетесь. Играться можно разными способами, но к работе это все имеет малое отношение.

Дык как тебе сказать... Вот прихожу я на Митинский рынок и вижу свои программы.
И те, что писал за деньги, и те что наваял после работы. А Линус Торвальдс — тот вообще...
В любом случае это никак не опровергает того факта, что некоторые (например я )
устраивают себе аврал ДОБРОВОЛЬНО.


A>>У русских всегда должен быть Генеральный Конструктор — человек, который видит проблему в целом.

MSS>Утверждение неверно. Потому что видел в жизни иное.

Чего ты иное видел? Людей без царя в голове? Так и я видел. Нужно чтобы у этих людей были
выдающиеся результаты. Ну как у Королёва например.

A>>А у американов... как-то всё иначе — на горизонтальных связях.
A>>Они вполне могут втроем делать процессор.
A>>Причем один отвечает за ядро, другой за векторные операции, а третий за прерывания.
A>>И НИКТО из этих троих не знает, как это работает в целом. Как-то справляются.

MSS>Видел и русских, которые так могут. Кстати, это наиболее эффективные команды.

Наиболее эффективные в каких условиях? Когда каждый член команды Керниган и Ричи и Страуструп,
в одном лице, то наверное. А как эта метода будет работать с рядовыми программистами?

A>>А насчет "лидерско-харизматических" качеств... Вы "лидера" от "хама" отличить можете?
A>>Я это к тому, что русские умных людей уважают. В отличие от американцев,
A>>которые придумали поговорку "если ты такой умный, то почему такой бедный".

MSS>Эта поговорка и в России активно применяется, думаю, не меньше, чем в Америке.

Молодой ты ышшо. 20 лет назад этой поговорки не было. Ее деррьмократы с собой принесли.

A>>А насчет "толковым девелоперам командир не нужен" — это детский комплекс.

MSS>Так это сами толковые девелоперы так думают, а иногда и не очень толковые.

MSS>Я ни разу не видел паттерн "следуй за лидером!" у людей с развитым интеллектом.

Практически любой военный с большими звездочками на погонах. А то, что лично ты не видел,
это скорее вопрос о том, кого ты считаешь человеком "с развитым интеллектом".
У всех наших (СССР-овских) нобелевских лауреатов был учитель Иоффе.

MSS>Если строить команду в стиле "один архитектор и рядовые", то значительная часть времени архитектора уходит на _уговоры_ рядовых. Дело в том, что они обязательно норовят что-то сделать не "как сказано", а "по своему". Желательно это "по-своему" отследить на ранних этапах и принять к сведению, обсудить, разжевать, чтоб потом продукт собрался из частей.

MSS>С точки зрения качества продукта и эффективности работы это все не нужно. Но это очень нужно с психологической точки зрения. Тупая отдача приказа "копать от забора и до обеда" неизбежно породит оппозицию, а это чисто психологическое явление потом и на качестве и сроках разработки продукта скажется. Если же уступить человеку в непринципиальных мелочах — то человеку это будет приятно, к нему прислушались, он значим.

Ага. А в модели горизонтальных связей половина (да, да половина) времени тратится на написание
спецификаций и их обсуждении, составлении и увязывании планов. То-же самое уговаривание, только
организованное другим способом.

Вообще-то в административно-командной модели есть такая вещь как разграничение компетентностей.
На КАЖДОМ уровне иерархии есть круг вопросов, которые решает человек этого уровня.
Конечно, бывают глупые люди, которые не умеют пользоваться этой моделью. Ну так они
любой другой моделью не сумеют воспользоваться.

(Ссылочка мелким шрифтом — в нормальных конторах начальник является не источником приказов, а арбитром.)
Вот примерчик того, как это происходит, при абсолютной (монархической) власти например Королёва.
http://www.rtc.ru/encyk/bibl/golovanov/korolev/54.html
Читать со слов "Ньютон соавтор солидный".

MSS>Если же строить команду в стиле "несколько умных, понимающих друг друга с полуслова людей" — то там вообще лидера нет как такового.

А если эти разработчики не Керниганы и Ричи, или "не понимают с полуслова" то что делать?
Или хуже того, каждый умный имеет СВОЁ видение проблемы? Ага. Вот именно.

Похоже, что ты сумел освоить ровно один способ построения команды (подходящий для белых
американцев очень высокой квалификации), и пытаешься его использовать для всех случаев жизни.
При этом у тебя возникает естественное для такого подхода ограничение — сначала найти девелоперов,
которыми лично ты умеешь управлять. Соответсвенно, и заявления у тебя "сначала сделаем из человека
американца, а уж потом Maxim S. Shatskih сможет с ним работать". При этом возникает две беды.
Первая — не идут последнее время американцы в IT. Вторая — сделав из русского (или другой нации)
подобие американа, мы а) получаем плохого американа (например умнейший Страуструп не смог обьяснить
С++ так же хорошо как Керниган) б) теряем сильные стороны русского (или другой нации).

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

Здравствуйте, Аноним, Вы писали:

А>http://www.e-xecutive.ru/reading/newfolder2921/article_5964/

А>Кто что думает по этому поводу?

Статья конечно очень поверхностная. Это весьма популярный сейчас жанр, я бы назвал его «драматический менеджмент» – истории о том, как отчаянные одиночки меняют корпорации, сражаясь против инертной корпоративной бюрократии и анахронизмов классического менеджмента.

На самом же деле, идеи Сэмлера гораздо глубже и фундаментальнее, чем кажется на первый взгляд. (Они конечно не новы, и не правильно называть их «идеями Сэмлера». Это, скорее, часть теории постиндустриального менеджмента, начинающей обретать сейчас все более отчетливые очертания.)

Основной посыл деятельности Сэмлера – борьба с бюрократизацией компании. Бюрократизация — это действительно эпидемия, все сильнее охватывающая растущую индустрию постсоветского софтосроя. По этому, опыт Semco было бы полезно изучить нынешним лидерам ИТ бизнеса.

Фактически, есть два основных фактора ведущих к излишней бюрократизации корпоративного механизма (именно с ними и боролся Сэмлер, и, победив, вывел Semco из кризиса):

Перегруженная, слишком глубокая корпоративная иерархия

Излишняя формализация Roles and Responsibilities

Рассмотрим каждый из факторов.

Перегруженная корпоративная иерархия

Собственно дилемма «иерархическая организация VS плоская организация» давно стала Holy War современного менеджмента. У обеих моделей есть свои плюсы-минусы.

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

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

Что касается индустрии софтостроя, то типичная аусторсинговая компания с высокой степенью диверсификации по технологиям и типам продуктов должна тяготеть к плоской модели. Проекты должны быть центрами принятия решений, менеджеры проектов — обладать широкими полномочиями и масштабным видением развития проекта. Проект в такой компании – это как бы бизнес в бизнесе. Построив систему таким образом, компания обеспечивает высокую динамичность и скорость реакции на внешние изменения. Так вот, проблемы многих аутсорсерв во многом заключаются в неправильном выборе пути развития и преобразования структуры. В качестве реакции на рост организации они выбирают повышение количества уровней иерархии, а не деятельность до децентрализации. Появляются новые функционеры, но центры принятия решений остаются на вершине иерархии. И тогда возникают все негативные последствия неуместно примененной иерархической модели: executive layer становится узким местом в трафике решений, своеобразным бутылочным горлышком организации. Это приводит к высокой степени инертности корпоративного организма, медленной реакции на изменения и, в итоге, к сдаче рыночных позиций. Очевидно, с этим и боролся Сэмлер, упраздняя лишние уровни в иерархии Semco.

Продуктовые компании, в отличие от аусорсинговых имеют более монолитные бизнес-цели и более монолитную производственную модель. Соответственно, таким компаниям имеет смысл выстраивать структуру, смещенную в сторону иерархии, обеспечивая тем самым единые подходы, дисциплину и слаженность разных подсистем идущих к единым целям. Здесь высокая децентрализация опасна по понятным причинам.

В общем, нужно четко понимать, правоту Питера Друкера, утверждающего, что не существует правильных организационных моделей. Риски иерархии – плохая реакция, медленное принятие решений, бюрократия. Риски плоских структур – вероятность распада, высокие требования к среднему менеджменту. Адаптивность и гибкость – вот рецепт успеха.


Излишняя формализация Roles and Responsibilities

Вторым важным шагом Сэмлера стало упразднение должностей. Подозреваю, что он руководствовался следующими соображениями.

В организации с железобетонно формализованной иерархией, схемами подчинения и должностными обязанностями, зачастую также железобетонно подразумеваются блага связанные с занятием тех или иных должности. Т.е. складывается такая система ценностей, при которой должность рассматривается как монопольный источник благ. Это провоцирует борьбу внутри компании за занятие должности. Фактически, происходит переключение усилий сотрудников на внутреннюю борьбу за распределение ресурсов, а не на внешнюю – за эффективность базовых процессов в компании. Монополизировав должность, индивидуум начинает деятельность по ее удержанию, препятствуя естественному отбору.

Чтобы избежать этого, нужно выстроить правильную культуру, насаждающую мысль о том, что каждый сотрудник получает блага за СОЗДАВАЕМУЮ ИМ ЦЕННОСТЬ, а не за ЗАНИМАЕМУЮ ДОЛЖНОСТЬ. Технически – это очень трудная задача. Фактически нужно построить в компании некий управляемый дарвинизм, обеспечивающий с одной стороны эффективный и быстрый естественный отбор, а с другой гасящий связанные с этим риски. Сэмлер – быть может единственный, и вряд ли массово воспроизводимый пример удачного разрешения этой задачи. Большинство крупных организаций пытающихся внедрить управляемый дарвинизм у себя приходили к организационному кризису, и вынуждены были обращаться к жестким антикризисным методам управления. Нужно искать золотую середину, в виде мягко, динамически распределяемых ролей, командной работы, постоянных оценок, влияющих на ротацию персонала на должностях, бонусов за результаты, эффективной схемы горизонтального роста.

В общем, темы Сэмлер затронул достаточно интересные, и поразмышлять на эти темы будет безусловно полезно.

Здравствуйте, Gaperton, Вы писали:

VAB>>а ведь до этого в старом офисе мы сидели как Максим про MSFT описывает, и тоже было очень не здорово переезжать еще до SCRUM просто в совершенно новый офис хоть и мега дорогой "самый модный в Люксе — по посл слову строительства бизнес-центров". Старые немодные кабинеты однозначно всем с кем обсуждали нравились больше — чем этот модный офис где всех стали сажать в open space стиле. А теперь еще и с этим SCRUMом скучили народ еще больше — личное пространство уменьшилось, шума прибавилось — со всеми вытекающими по ДеМарко\Листеру.

G>Ну, это уже плохо. Есть мнение, что в данном случае Scrum использовался как оправдание экономии на рабочих местах.
мимо. у нас наоборот в связи с тем что американцы предпочитают у себя народ держать и развиваться в Штатах (там по всем штатам минимум 4 R&D центра сейчас), а не где-то далеко в Европе (что логично) — прошли уволльнения а часть сама свалила все поняв (им для этого создали условия) — и поэтому места стало больше — реально было два зала — в одном саппорт+QA сидел — во втором разработчики. Сейчас остался саппорт (поредевший) один и места в их части офисе — дополна. У нас людей не прибавилось — тоже люди уходят как в QA так и в девелопменте. Hiring сейчас бурно идет в штатах, а часть QA вообще в Китай, как положено, аутсорсить начали. Поэтому с местом точно не вопрос. Топы уровня VP давят именно на то что — "так требует SCRUM" поэтому "все будут сидеть как можно ближе". Будем посмотреть что будет дальше и как в будущем это дело учесть.

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

Формальное единоначалие необходимо — да и есть везде, и в России, и в Америке, просто с делегированием сочетается. Опять же везде сочетается.

Совсем другое дело неформальное лидерство. Я знаю колоссальное количество людей, попытка установить над которыми неформальное лидерство вызовет у них сильнейшее отвращение.

Страуструп на пару с Эллис объяснил Си++ просто великолепно, все идеально понятно, объяснены причины введения всех фич в язык, главнейшие задачи, поставленные перед собой проектировщиками языка, и прочее.

Уж не знаю, куда лучше.

Я надеюсь, что кто-то уже уволился в место получше, где нет SCRUMов, зато есть кабинеты?

VAB>положено, аутсорсить начали. Поэтому с местом точно не вопрос. Топы уровня VP давят именно на то что — "так требует SCRUM"

Плохо работать в компании, в которой тупые VP.

Здравствуйте, Maxim S. Shatskih, Вы писали:

VAB>>положено, аутсорсить начали. Поэтому с местом точно не вопрос. Топы уровня VP давят именно на то что — "так требует SCRUM"

MSS>Плохо работать в компании, в которой тупые VP.
хм, сложно сказать тупые они или нет коли смогли 15 миллионов лицензий окучить и пока исправно добиваются своих целей, поставленных советом директоров.... так что спорный вопрос, хоть ты и прекрасно понял ситуацию.


видишь ли, тут проблема осложняется тем что у новых хозяев до этого совсем не было опыта ядерной\системной разработки и как назло был очень удачно внедрен SCRUM в обычных user-mode проектах — см в products list — все, за исключением Sanctuary. Sanctuary

Автор: Valery A. Boronin
Дата: 09.05.06

это уже наше. Соотв. одно дело что-то на managed языках и Java колбасить, причем где основной challenge это как сделать GUI поудобнее пользователю, то да се (agile штучки тут несомненно рулят) — и совсем другое дело как вот например быть с тяжелыми research тасками в рамках спринтов

Вот кстати, буквально на той недели проходил тренинги по SCRUM и так и не смог добиться по этому вопросу ничего вразумительного от ведущего — краснознаменного эксперта по SCRUM с многолетним (когда успел? ) опытом. У него реально просто никогда такого не было — за всю его карьеру консультанта по SCRUM и не только по всему миру. Придумать же ничего разумного, похожего на правду, с ходу тоже не смог. Аналогично проблемы, чувствую, с масштабируемостью — я про SCRUM of SCRUM, тоже есть о чем серьезно задуматься тем кто на это решается (по идее).

Буду признателен, если у кого есть поделиться реальный опыт работы по методологии SCRUM с задачами требующими капитального research, с высоченными рисками и сроками длиннее спринта. У меня есть соображения по этому поводу и готов ими поделиться чуть позже — возможно это все лучше сделать в отдельной ветке.

Короче что касается нас — проблемы у нас будут. Но позже. Точнее они есть но их пока мало кто видит. Пока же все новое руководство, а это именно американцы — которые как покупатели за полгода распространились на все ключевые посты по всем континентам (и как водится завели много новых с красивыми названиями) — ну никто, совершенно никто не понимает куда влезли и чем это грозит всему, теперь общему бизнесу (пока линейки продуктов продаются отдельно) в скором будущем. Например, есть светлая идея разрабатывать драйвера двумя бригадами — в США и в Люксе. Еще и наш QA разогнали так, что теперь предлагается на аутсорсе в Китае драйвера тестить — при этом там люди элементарно продукту не обучены и сидят под VmWare ESX, не говоря уже про уровень кадров: что они нам натестят когда мы фильтруем практически ВСЕ реальные устройства, которые есть на рынке и втыкаются в PC? Как мы будем их там отлаживать? Как с repro cases быть? много, очень много вопросов есть у меня и пары других толковых ребят... но они пока все без ответов, так как новое рук-во элементарно не совсем хорошо понимает что есть продукт с компонентами уровня ядра в основе.

Т.е. фактически новый менеджмент пришел, разломал все что было хорошего + начал игры под знаменем "кто против SCRUM тот против нас", да еще и текущий QA как неэффективный (было за что) разогнан напрочь (что уже чересчур) — с мудрым решением все слить в Китай, а немногих выживших и не ушедших QA ребят — внедрить в состав SCRUM бригад по остаточному принципу. Весело? не то слово. Мы и раньше только на себя (как любые вменяемые разработчики ядра, тем более нас очень мало — а вообще все держится на нас) надеялись — а сейчас фактически и QA как такового вообще не имеем. Все это несомненно сыграет — но сыграет не раньше лета по моим прогнозам. А то и позже.



Пока же все идет слишком отлично, чтобы кто-то сверху почесался: рекордные кварталы по продажам, агрессивнейшая политика на рынке, вот нас и других ребят вроде как бывших на тот момент лучшими в мире по своей части прикупили

Автор: Valery A. Boronin
Дата: 13.09.07

, соотв. серьезная заявка на капитальное лидирование на мировом рынке (первые по рейтингу IDC) на долгий срок, скорый выход на биржу с ожидаемым немерянным успехом — вот скажи, что же может быть лучше для топов? впарят этот SCRUM через полгодика на IPO так что мама не горюй...

только вот новых фич продукт пока за почти скоро как год — пока особо не получил да героически боремся с тем, что новая метла нам намела (without value to the product, actually): сменили bugtracking & change request системы, поломали все билды. Внедрили TFS, героически починили билды — классика жанра Теперь вот играемся в SCRUM... слова не доходят до высокого рук-ва, у них все слишком хорошо сейчас благодаря тому труду, что мы вложили в Sanctuary ДО всей этой канители. И это счастье, что продукт сейчас продается миллионами копий, при этом почти не нагружает саппорт и пока держится без QA — надолго ли хватит ехать на старой базе? не знаю. Может быть и надолго — мы реально потрудились на славу и то что есть сейчас в Sanctuary в принципе можно продавать годами и под Висту (уже поддерживаем в т.ч. х64 почти год как) и под 2008 (не думаю что что-то серьезно придется переделывать, раз с KPP ужились худо-бедно).


Так что остается ждать наглядной демонстрации необходимости иметь правильных людей с правильным опытом на правильных позициях и с правильным vision. Сейчас дергаться бесполезно — убил уже на это неск месяцев, надоело. Тоска одним словом. Устал. Отпуск через неделю очень кстати подходит.

Здравствуйте, Maxim S. Shatskih, Вы писали:

MSS>Я надеюсь, что кто-то уже уволился в место получше, где нет SCRUMов, зато есть кабинеты?
скажем так — очень нехорошие прецеденты есть.
так что Макс — если знаешь места получше, необязательно с кабинетами — дай знать, pls.