Справедливости ради отмечу, что в компании, где я работаю, проповедуется (хотя и не всегда соблюдается) принцип “Пообещал - сделай без отмазок, чтобы не стоило. Не можешь - не обещай, имеешь право”. Это означает для программиста возможность сказать “Нет” на просьбу - и тогда даже мелкий вопрос идет по регламенту и официальным путем. Для меня, как менеджера, это означает:
1. Дополнительные “разборки” с теми, кто оказался недоволен отказом.
2. Комфортные условия для программистов, над которыми [b]никогда[/b] не появляются недовольные, бьющиеся в истерике заказчики, требующие все бросить и обслужить его.

А теперь “сюрпрайз” - через некоторое время они (программист и заказчик) все равно научились договариваться без меня. Но уже не в ущерб делу

Кстати, для работы в пределах одного подразделения это тоже подходит - так как даже сидящие за соседними столами должны знать, что один их вопрос выбивает их коллегу на длительное время из работы и он “тупо не получит свои деньги”

“Пирамида - самая устойчивая фигура однозначно” :))) Сразу вспоминаются разные пирамиды типа “МММ”
Так, что пирамида устойчива только если ее правильно строить и когда она стоит на основании

Именно поэтому вышла такая неразбериха.

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

Действительно, самое важное, чтобы подразделение работало хорошо. И вообщем-то высшему руководству все равно, как оно работает внутри.

Что, я просто пытался описать в статье, как собственно говоря сделать так, чтобы оно внутри работало. Причем с одной стороны, чтобы оно не требовало слишком много усилий от начальника подразделения, с другой стороны, чтобы все шло по приоритетам/приказам расставленным начальником.

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

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

“Принципиальный момент - у нас команда. Мы либо вместе проигрываем, либо побеждаем.”. Командный дух - вещь очень неплохая, но ей нельзя злоупотреблять. Из команды люди уходят и приходят, меняются цели и направления. Да, бывают сладкие промежутки, когда можно жить одно большой семьей (в смысле командой). Но такие промежутки - бывают не часто.

Скажем так, все таки программирование мне больше нравиться сравнивать с строительством дома, чем с походом в горы. Это при походе в горы не тянущего человека нельзя бросить на пол пути и все должны дойти до конца. Для бизнеса - этот подход совсем не оптимальный. Если человек не тянет и не собирается тянуть, то проще как при строительстве дома - уволить и взять нового человека. Да, может быть это не по командному. Но цель бизнеса - это в конечном счете зарабатываение денег, а не создание идеальной команды.

С чем я согласен, что овертайм должен оплачиваться. Иначе, получается, что помогающий человек должен быть просто меценатом (тратить свое время помогая ближнему и не получая не копейки).

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

И хотя, сама идея правости и виноватости противостоит командной идее. Но в конечном счете, люди которые работают хорошо и правильно должны поощряться, а те кто работают плохо - не поощряться.
Без некоторых разумных правил, все это становится крайне субъективным.