Как стать автором
Обновить

Комментарии 95

Интересно, как компании в разных отраслях приходят к очень схожим решениям. Примерно такую-же систему ставят в одном крупном автодилере.
В малом бизнесе всё стихийно, в среднем уже появляются работающие методологии. Много веток похожи в целом.
Вот не всегда, к сожалению. Многие крупные компании с миллиардными оборотами работают практически без методологий…
Ну, если они живы, то что в этом плохого?
Но если бы работали по методологии, то обороты могли бы быть больше? А могли бы и не быть ¯\_(ツ)_/¯
Совершенно верно. Правда у топов таких крупных компаний периодически кое-что «поджимает» и вот здесь на арену выходят крупные консалтинговые компании и внутренние отделы методологии. Которые по результату дают ну очень красиво оформленные отчеты с совершенно бесполезной и часто оторванной от жизни информацией (сужу лично по опыту работы с двумя компаниями с мировым именем и одним внутренним отделом методологии). Слава богу зачастую полномочий навредить у них нет и они просто тратят деньги.
отчеты с совершенно бесполезной и часто оторванной от жизни информацие

Можно хотя бы поверхностно описать пример бесполезной информации от консалтинговых компаний?
Я видел обратные примеры, когда метрики снимали хорошие, рекомендации давали правильные, но топ менеджмент в силу недостатка знаний не понимал и не принимал изменения.
Вот была рекомендация для одной вроде не ИТ-компании разогнать отдел разработки как чуть ли не основной центр непрофильных затрат (зарплата отдела из 10 человек в центральном офисе на 100 человек составляла чуть ли не половину всего его ФОТ, если без топов, то больше половины) и использовать аутсорс. Компания чуть не загнулась, потому что ни один из нескольких подрядчиков не смог за те же деньги обеспечить ту же скорость реакции на изменения бизнес-требований.
Ну например в предложении по стратегии развития (для ритейла) встречались такие пункты:
— Внедрение IoT
— Внедрение дронов
— Внедрение машинного обучения
Для каждого пункта с ведро воды пояснений, из которого нельзя выцедить ничего, кроме того, что можно почитать в Википедии. Конкретики — что именно они рекомендуют, какие кейсы покрывают эти технологии и какую пользу это принесет бизнесу нет.

Были конечно и конкретные рекоментации по улучшению бизнес процесса. Но главного — обоснования почему так не было. На такие вопросы у них один стандартный ответ — это наше экспертное мнение.
О, это философский вопрос. Они могут быть живы, например, на коррупции или выплате чёрной зарплаты сотрудникам. Или быть полугос компаниями, неэффективно осваивающими бюджет. Но да, это не вопрос методологии по большому счёту.
Ну почему плохо, просто отличный пример «ошибки выжившего». Хваля чей то успех и приводя его в пример, почему-то предпочитают умалчивать о количестве провалов и банкротств оппонентов. Так и хочется сказать — «пирог уже давно поделен», а желающий откусить кусочек чаще всего идет в начинку, изредка добиваясь успеха.
То, что это скорее всего результат кумовства и протекционизма, ухудшающий уровень услуг/продукции относительно честной рыночной экономики с нормальной конкуренцией.
и поставить одного директора по фигне. То есть по развитию

чую, это если и сработает, то ненадолго.
любая активность в конторах требует внимания и на поддержку существующего, и на развитие.
и HR, и логистика, и оффлайн-ритейл, и онлайн-ритейл, и ит, и т.д. — все должны и прямо сейчас работать как часы, и одновременно перестраиваться под будущее.

Тот же пиар — он, в целом, как коммерческий инструмент нафиг никому отдельному в компании не нужен, потому что работает множителем.… Но оценить его шаманский эффект сложно, поэтому он выносится на уровень подчинения генерирующему прибыль модулю CEO (в нашем случае) и сидит там как стратегический ресурс.

Пиар то понятно что можно вынести.
А вот скажем оффлайн-ритейл. Как без человека, которые прямо сейчас отвечает за оффлайн-ритейл, можно думать и развивать завтрашний оффлайн-ритейл?
Понятно, что конфликт тактика-стратегия вечный. Но и вариант, поделить тактику и стратегию по разным людям, тоже не панацея.

Речь как раз про это. Тактика почти всегда задавливает стратегию, поэтому функции в разных местах. Это уже точно понятно.

А про начало — это вопрос лимита управляемости.
Вангую, что с новым витком развития конторы, вернетесь к новому старому варианту — тактика-стратегия по конкретному направлению у одной персоны.
Хотя может быть это и прямо сейчас присутствует (или планируется), возможно неявно. Когда у конкретного ответственного две руки, правая отвечает за текущее состояние, левая — за change.
Когда у конкретного ответственного две руки, правая отвечает за текущее состояние, левая — за change.
В результате и то и другое сделано отвратительно. Если не удаётся найти людей, которым нравится тактика и стратегия (чтобы посадить их на эти роли «на постоянку») — можно периодически меняться ролями, но устраивать постоянный внутренний конфликт внутри человека — это садизм.
А ввести оперативный уровень, более глобальный чем тактический, но менее чем стратегический? Говорят именно это помогло СССР выиграть ВОВ.
Я вам больше скажу: у нас в отделе 3 человека. И всё равно — конфликты между тактикой и стратегией постоянно. Поскольку нас мало — да и всем хочется заниматься стратегией, никому тактикой, то человек (иногда два), «выделенный на тактику» периодически сменяется, но всегда есть кто-то, кто занимается тактикой и кто-то, кто занимается стратегией. Попытка заниматься и статегией и тактикой ни к чему хорошему не приводит…

P.S. Видимо это касается любого проекта, где есть долгосрочное развитие, а не бесконечный цикл «в беличьем колесе».
Например, мы уже поняли, что ИТ-отделов в компании должно быть два: тактический и стратегический. Тактический — это хелпдеск, железнячники, отслеживание ресурсов и лицензий, мониторинг и вообще всё то, что повторяется больше 2 раз. Стратегический — это реализация major-фич, планирование на 2-3 года вперёд и финансы.

Ну развитие телефонии и сайта, понятно, стратегическое направление.
А вот скажем, автоматизация в HR, бухгалтерии — тактика?
Да, про ИТ хотелось бы подробнее :)
Автоматизация смотря чего. Если дописать мелкую фичу в известной истории — явно тактика. Это, например «нарежьте мне отчёт такой-то, чтобы приходил каждую неделю». А если это что-то системное вроде нового процесса — стратегия. Если подходит слово «развитие» вместо слова «поддержка» — то стратегия. Имхо.
Имхо, деление ИТ, как и любых поддерживающих активностей, лучше не по стратегическое-тактическое, а помогает развивать основной бизнес/помогает развивать все остальное.
С этой колокольни запуск какого-нибудь документооборота для hr, бухгалтерии может бы ть и облегчит жизнь последних, но если это не почувствует основной бизнес — тогда резонный вопрос, а зачем внедряться.
HR нужен для обслуживания основного бизнеса. Вот вам вопрос: а вы можете обосновать, что от этой фичи в HR получит основной бизнес? Если нет — зачем она? Речь не только про прямые последствия первого порядка, но и про второй-третий слой.
То что помогает развивать основной бизнес, оплачивается основным бизнесом. И бюджет этот может быть внушительным.
То что неочевидно помогает основному бизнесу, но польза видится в рамках поддерживающей активности, оплачивается самой активностью. У активности (HR, бухгалтерия, ИТ и пр.) есть свои бюджеты для этого. Они, понятно, меньше бюджета развития основного бизнеса.
В нашей логике эйчары не производят прибыль. Они не могут что-то оплачивать. Только модуль, которому они дают пользу, может оплачивать. Это либо бюджет типа «выделяем вам столько-то на год и можете перезаказывать у кого-то», либо прямая оплата от уровня генерации прибыли.
Для HR определена внутренняя стоимость услуг, оказываемых другим подразделениям?
Да, с точностью до 100 рублей примерно. По основным. Есть куча неоценённых, но они пока идут одним блоком «сервис».
Было бы интересно посмотреть, хотя-бы в условных баллах.
Например, сокращение количества персонала?
За счёт автоматизации? Тогда это точно поможет основному бизнесу, и это легко посчитать и выразить как проект.
А если проект автоматизации предлагает ИТ-отдел, а HR отдел не хочет сокращения?
НЛО прилетело и опубликовало эту надпись здесь
В некоторых компаниях финансовый такой мелочёвкой не марается :)
нун тут уже прослеживается явное соответствие с git-flow, master — тактика, feauture — стратегия, в любом его проявлении.

Предусмотрены ли какие-нибудь формальные методы противодействия ситуациям «эти проектанты из развития напроектировали и дальше пошли, а нам теперь со всей этой фигнёй взлетать»?

Это вот вопрос мышления крупными релизами. Ещё раз: текущая парадигма такая, что изменения делаются сильно быстрее и непрерывнее. Если рассматривать бизнес как процесс постоянного изменения, в целом, не сильно ошибётесь. А это означает другую историю согласований и прочего — я описывал в постах про планирование изменений примерно полгода назад.

И это, мы этот уровень до конца не прошли, если что.
насколько я понял, вопрос был про другое.
про риск того, что тот кто отвечает за развитие, что-то задумал, и это плохо соотносится с тем что есть «в поле», задуманное не взлетает

ggo совершенно верно пояснил мой вопрос. Я постоянно наблюдаю проекты развития типа «ракета из вибраниума на анобтаниевом топливе», а потом начинается «давайте заменим первое алюминием а второе — квашеной капустой». Ракета после такого если и летит, то очень низко.

Есть пара разных подходов. Мы идём в сторону демократуры, я её описывал. Вкусвилл тот же вот делает так: группа развития открывает магазин, доказывает, что он может хорошо работать, передаёт рознице.
Эту вероятность исключать нельзя.
НЛО прилетело и опубликовало эту надпись здесь
> что для нас самое главное — это доставить до любого человека его любимые игры.

Я больше не ваш клиент, раз мои любимые игры уже до меня доставлены? Разве что одну (не вашу) сам доставил до друга на ДР, а теперь локти кусаю…
НЛО прилетело и опубликовало эту надпись здесь
В моём случае крайне мала вероятность того, что будет доставлена любимая игра. Потому что любимыми они становятся или не становятся после доставки, до того это просто игра, в которую ещё не играл.
А теперь мы поработаем над тем, чтобы у вас было больше любимых игр. Вот вы в Сопротивление играли?
НЛО прилетело и опубликовало эту надпись здесь
Со мной в такие игры играть не любят, потому что я люблю не смотреть кто я, а люблю при каждом ходе бросать монетку или более подходящий рандом-генератор, чтобы определить чью роль я буду отыгрывать в этом ходу :)
НЛО прилетело и опубликовало эту надпись здесь
Тогда жаль, если не имею права. Мимикрировать под правильного не моё, если хоть как-то вредить всё равно нужно и одним действием общий выигрыш неправильной стороне обеспечить нельзя. А не мимикрировать — со мной никто не играет больше двух раз :)
Нет. И если играть в неё как положено, то, судя по описанию, у неё есть шансы стать третьей ненавидимой мною игрой, а если играть как я люблю в такого плана игры играть, то со мной никто играть не будет. :) Хотя, акцент на статистике, логики и комбинаторике, если я правильно понял, мне нравится.

Как-то у вас все очень технично...


Могли бы, например, определять иногда стратегию развития, бросая руны. Или вести дерево навыков, давать ачивки, прокачивать бухгалтера до 80 уровня...

Мы так УЖЕ не делаем.
Со всеми этими разделениями на отдельные ветви и компании со своими бюджетами нужно быть уверенным, что сотрудники рядовые это все тоже понимают правильно.

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

То есть с моей точки зрения это выглядело как «трачу деньги компании чтобы сделать работу на благо компании, только в другом отделе в соседней комнате», а с точки зрения начальства это выглядело как «трачу их деньги на помощь посторонним людям»
Бывает и с другой стороны подстава — разово сделал другому отделу то, чего раньше не делали (это может быть отчет, например). И начальство другого отдела начинает пребывать четком понимании, что это теперь делаете вы, не забывая об этом упомянуть в случае какого-нибудь просера. А потом прилетает по шапке уже от собственного от начальства, ибо создал прецедент, теперь надо будет делать постоянно, и вообще другие тоже теперь такое хотят.
При этом ходить на ковер и выбивать деньги на автоматизацию и дополнительные ресурсы никто не хочет, зато хотят, чтобы и дальше делали за них.
Естественно, вы же начальство не предупредили? Вас дрючили не за доброе дело, а за самовольное изменения в функциональной модели системы. В рамках большой компании это вполне себе может привести к катастрофе. Это в маленьких компаниях, где вы знаете все 10 сотрудников и кто чем занимается, а ваш производственный экспромт не сломает процесс взаимодействия каждого с каждым, можно помогать кому угодно и сколько угодно, и это хорошо. Потому что для маленькой компании это экономия средств и времени.
В больших компаниях все иначе. Большая компания — огромный и сложный механизм. Менеджмент годами налаживает процессы, чтоб на долгосрочных активностях получать от функциональных команд предсказуемый результат. И тут появляется альтруист, который делает что-то в обход процессов. Любое однократное нарушение процесса, если оно удобно всем участвующим, становится постоянным.
От одного раза ничего не случится. От повторения одного раза на протяжении года, может как сильно испортиться результат, так и сильно улучшиться. С испорченным результатом и так понятно. А вот видимое «лучше» — не всегда действительно «лучше». С позиции работника тяжело оценить реальную цену вашего поступка. Например, если вы нажали на педаль газа, а машина поехала быстрее, чем вы ожидали. На прямом участке дороги это хорошо — быстрее доедете. В городе на поворотах плохо — не успеете вовремя остановиться. С позиции педали газа, ей должно казаться, что она эффективнее других педалей и вообще очень помогла автомобилю.
Как вам будет ездиться на машине, которые сама без вашего ведома оптимизирует процессы внутри? Непредсказуемо тормозит сильнее чем нужно, разгоняется быстрее чем ожидаете, колеса и руль поворачиваются асинхронно. Сможете соревноваться на такой машине с другими? Вряд ли, даже если в отдельных показателях ваша машина будет лучше других. Бизнес гораздо сложнее автомобильных гонок.
Не приведи бог работать в такой компании…
На самом деле может быть проще. Сделал раз что-то критическое для другого отдела (например, для бухгалтерии сделал отчёт конечный вместо того, чтобы сделать модуль или скрипт для этого отчёта), другой, третий, из бухгалтерии уволился человек, который объяснял тебе как его делать, четвёртый, пятый, а потом уволился сам, и какой-то очень важный отчёт никто в компании ни то, что сделать не может, а даже объяснить твоему преемнику как его делать. И компания, например, лишается лицензии на свой основной вид деятельности, потому что все уверены, что отчёт делает бухгалтер либо сам, либо знает какую кнопку нажать, а по факту только преемник первого бухгалтера знает, что надо написать тебе и ты сделаешь отчёт. И хорошо если уволился хорошо и тебя хорошо попросили сделать отчёт в последний раз и объяснить преемнику как его делать. А если уволился нехорошо или попросили так, что самый разумный вариант послать?
А пароли, явки, имена будут? Ну, в смысле, вы компанию назвать-то можете? Потому что теоретически такая опасность существует. А вот практически — я не знаю ни одной компании, пострадавшей от избытка «горизонтальных связей». Зато знаю массу от этого пострадавших — собственно это наиболее распространённая причина краха больших компаний. Которые начинают действовать по принципу «правая рука не знает, что делает левая нога» или, что ещё хуже, вбухивать ресурсы в никому не нужные вещи не выделяя достаточно ресурсов на то, что нужно делать срочно. Потому что бюджет каждого отдела священен и перераспределить, разумеется, ничего нельзя.
Конкретный случай закончился хорошо, расстались штатно и попросили хорошо, поэтому не послал.
А вы точно уверены, что проблема была в том, что вы помогли там кому-то из соседнего отдела, а не в том, что кто-то решил «порезать косты» и вместо специалистов не набрал «таджиков из Бурятии»?

Так я вас разочарует: подобное «резанье костов» без «горизонтальной помощи» приводит к краху ещё быстрее.
На 99% уверен, что в данном конкретном случае с важным отчётом для регулятора алгоритм его формирования из нашей технической схемы данных был только у меня в голове, а из наших бизнес-данных — у человека из другого отдела, главы этого отдела, между прочим. И оба уволились не из-за «резанья костов». Глава отдела передал дела по этому отчёту типа «Вову прошу подготовить отчёт», а я по нему не передавал вообще, потому что в мои обязанности это не входило, я просто помогал другому отделу делать общее дело.

P.S. И скорее помогал не отделу, а конкретному человеку. Кто-то другой обратился бы, скорее сказал бы «пиши заявку на разработку нового отчёта», а не сделал бы сам отчёт.
В моих глазах, ваше описание процессов в большой компании очень похоже на то, что описано в «Сила привычки» Ч. Дахигга. Краткий отрывок в вольном пересказе:
Каждое подразделение было отдельным княжеством, и вмешательство в дела другого подразделения считалось недопустимым на всех уровнях иерархии. Когда руководитель одного департамента обратил внимание, что многочисленные слои краски на потолке нарушают пожарную безопасность, то услышал в ответ «занимайтесь своими делами, и никто не будет вам мешать»

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

Также замечу, что Сергей в своем посте рассказывает о пользе горизонтальных связей и распределении центров принятия решения. И не как о собственных открытиях, а как о best-practices. Это делается в том числе для более гибкой структуры и быстром «апгрейде» процессов — полная противоположность того, что вы написали.

И да, Мосигра — это не «маленькая компания».
То есть альтруисту, решившего действовать в обход процесса (на самом деле активному человеку, думающего не об отделе, а о компании)

Это разное. Одно дело активно влиять на процессы в рамках вашей функциональной команды, другое — без предупреждения лезть в процессы других команд. Благими намерениями сами знаете куда дорога вымощена. Или, думаете, альтруисты думающие о благе компании, не могут совершать фатальных ошибок?

приказали сидеть ровно и не рыпаться

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

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

Также замечу, что Сергей в своем посте рассказывает о пользе горизонтальных связей и распределении центров принятия решения. И не как о собственных открытиях, а как о best-practices. Это делается в том числе для более гибкой структуры и быстром «апгрейде» процессов — полная противоположность того, что вы написали.

Ничего подобного. Горизонтальные связи и распределенные центры принятия решений требуют такого же точно контроля за процессами внутри. Почему-то у многих гибкость ассоциируется с уменьшением контроля. Как раз горизонтальные связи требуют еще больше контроля и хорошо прописанных процессов. Матричная структура может дать гораздо большую производительность и сократить расходы, если процессы хорошо наладить — роли прописаны и строго соблюдаются. Любое нарушение правил обходится компании дорого. Простую функциональную структуру с классической пирамидой в основе гораздо удобнее контролировать, требования к соблюдению правил процессов более мягкие. Для гибкости, при сохранении эффективности, увы, нужен повышенный контроль.
Я хочу подчеркнуть, что человек из моей цитаты увидел брак, плохую работу в соседнем отделе другого департамента. А текущий процесс был не вмешиваться в дела другого департамента (как вы и предлагаете). Он не мог исправить ситуацию внутри своей команды, и находился на должном уровне иерархии, чтобы указать коллеге-руководителю на ошибки в работе департамента коллеги. Помочь могло только изменение обычных процессов.
Любое нарушение правил обходится компании дорого.
Нет, т.к. правило может быть устаревшим. Опыт с обезьянами, не берущими банан вам знаком?
В книге правилам и обычаям в организациях посвящено несколько глав, а я пересказал полглавы с одним разбором в одном абзаце. Я опустил много чего. Ограничусь выводом: часто, но не всегда, следование правилам/обычаям обходится компании слишком дорого.
Я рекомендую прочитать книгу Дахигга там приводится статистика сколько правил по умолчанию складываются случайным образом, без весомых причин.
Компании, где все сидят ровно и не рыпаются, обычно представляют из себя старое неэффективное бюрократизированное болото

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

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

Горизонтальные связи и распределенные центры принятия решений требуют такого же точно контроля за процессами внутри
Я говорю только про «сохранение процессов». Про контроль у меня нет ни знаний, ни опыта, поэтому не могу ничего сказать.
Milfgard, вы не могли бы прокомментировать:
1. Нужен ли больший контроль при наличии горизонтальных связей?
2. Необходимы ли хорошо прописанные процессы при наличии горизонтальных связей?
3. Нужен ли повышенный контроль «для гибкости, при сохранении эффективности»?
Я хочу подчеркнуть, что человек из моей цитаты увидел брак, плохую работу в соседнем отделе другого департамента. А текущий процесс был не вмешиваться в дела другого департамента (как вы и предлагаете).

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

Нет, т.к. правило может быть устаревшим. Опыт с обезьянами, не берущими банан вам знаком?

Внимание вопрос: как реагировать на устаревшее правило, которое мешает? Молча его нарушать, помогая другим, или согласовать эту помощь с руководством, чтоб все были в курсе проблемы, разобрались с ее причинами, решили, нужна ли там помощь, одобрили ваше решение помочь, приняли меры по речению причин проблемы. О каком варианте писал я выше?
Ограничусь выводом: часто, но не всегда, следование правилам/обычаям обходится компании слишком дорого.

Уже вижу инженеров NASA, пилотов гражданских рейсов и хирургов в больницах скипающих чеклисты (кому нужны эти правила?).

Моя критика — к призывам не менять процессы.

Где я призываю не менять процессы? Как раз менять надо именно процессы. И инициирование изменений в эти процессы должно идти как сверху, так и снизу. Но не путем нарушение правил, а согласованно, через руководителей. Видите проблему — сообщите. И это, внимание, тоже процесс. Процессы можно менять, но их нельзя игнорировать. Если правила установлены, то их нужно соблюдать. Если правила мешают делать работу эффективно, их все равно нельзя нарушать. Потому что нарушение этих правил может помочь вам, но навредить другим. Например, правила дорожного движения — каким бы неудобным не был светофор на перекрестке, если вы его проигнорируете, то можете помешать другим. С позиции стоящего на красный свет, светофор — вселенское зло, а правило, запрещающее проезд на красный — неэффективное.
Банальный пример: нельзя обращаться напрямую к генералутоп-руководству с предложениями. Только по цепочке. А если пожар? Или генерал пошел на минное поле? Искать полковника или нарушать процесс?

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

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

В конце концов для коллектива с хорошо налаженными процессами, можно допустить прямое обращение к любому руководству. И строгие правила помогут эти обращения сделать действительно эффективными.
То что в цитате — плохо отлаженный процесс.
Видимо, я недостаточно акцентировал факт, что человек, говоривший о проблеме с краской — руководитель департамента, топ-менеджер, который говорит на совещании топ-менеджеров о проблеме. Проблема уже дошла до верха, но не получила решения, т.к. процесс менять никто не хотел.

Впрочем, это неважно в свете
Как раз менять надо именно процессы. И инициирование изменений в эти процессы должно идти как сверху, так и снизу
Значит я неверно понял ваш первый пост. Я именно в этом и хотел вас убедить :)
Я не спорю, что такой метод организации может иметь какой-то смысл. Но для человека, всю жизнь работавшего в маленьких компаниях этот принцип «отдел отделу — волк» может оказаться неприятной неожиданностью. Особенно если никто этого не объяснил и не предупредил.

Ситуация там еще осложнялась тем, что я не просто помог какому-то отделу, а доделал часть работы для старого отдела после перехода в новый. Старый частично расформировали и сократили, но какая-то поддержка проекта там осталась. Меня перевели в другой отдел, но какое-то время что-то по мелочи по старой памяти я фиксил в старом в свободное время. А потом оказался виноват.
По большому счету в этой ситуации вы вообще не виноваты, не сочтите за обвинени в свой адрес то, что я там выше написал. Там было не про личности, а пояснение процессов.
Особенно если никто этого не объяснил и не предупредил.

А это уже другая проблема — менеджмент, который должен был бы грамотно описать обязанности, очертить границу ответственности, установить правила. А когда проблемы возникла, не душевную травму вам оставлять, а спокойно объяснить, что было не так, как именно нужно было сделать, помочь разобраться в процессах, поблагодарить за инициативу, отметить вас, как перспективного сотрудника. В теории :)
НЛО прилетело и опубликовало эту надпись здесь
Есть гугловый метод «делайте что хотите N рабочего времени». Может оказаться отличной заменой выделенного R&D, у которого энтузиазма на full-time может и не хватать.
Часто неправильно понимают эту фразу. Более корректно она звучит «Делайте, что хотите, N рабочего времени, если это на благо Гуглу. Все результаты деятельности принадлежат Гуглу».
Не. «Делайте что хотите (креативное), результаты работы принадлежат гуглу». Часто компенсируется публикацией под свободной лицензией.

Если «на благо гуглу» — это уже обычная работа. Вся идея состоит в том, чтобы люди попробовали что-то интересное. Может оказаться, что никто не ожидал, а из этого что-то офигенное появилось.

В одной из железячных компаний делают что попало — манипуляторы для NASA, системы активного шумоподавления для офисного туалета (чтобы смыва не было слышно) и т.д.

Штук пять у них ушло в крутейшее IP, остальное — так, игрушки. Но эти пять штук никто бы не придумал «на благо компании». Их придумали только потому, что прикольно.
директора по фигне. То есть по развитию.
Скажите, а ваш директор по развитию не обижается, что вы уравняли развитие и фигню? ;-)
Наш директор по фигне не обижается )
НЛО прилетело и опубликовало эту надпись здесь
О. Пока вы формулируете, вы мне напомнили про то, как правильно представляться — социнжиниринг от наших аниматоров. Расскажу постом при случае.
НЛО прилетело и опубликовало эту надпись здесь
Заметьте, я так и не ответил на ваш вопрос.
Официальный сайт утверждает, что Сергей — «руководитель маркетингового отдела».
До директора ему еще расти и расти ;-)

Кстати, если мне не изменяет склероз, то именно Milfgard в своей книжке не рекомендует представляться директором. Со вполне логичным обоснованием.
НЛО прилетело и опубликовало эту надпись здесь

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

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

Судя по посту, организационная структура меняется и непонятно, старое описание это баг или фича. Я рассчитывал на комментарий Сергея, но это чистое любопытство.
Я не совладелец Мосигры )
Но я владею другой компанией. Не входящей в группу.
Пардон :)

Сергей, дайте ответ пожалуйста, кто же у вас директор по фигне развитию? А может, место вакантно и вам надо фигню напридумывать?
Представляю вакансию «Директор по фигне» :-D
Или круче, запись в трудовой! Такого человека в будущем будут звать на собеседования только чтобы услышать эту историю! А история будет наравне с епископом — Senjor Developer
Круче записей, чем после регистрации для колл-центра ООО «Огого» вряд ли найдёте.

Менеджер по продажам Огого? :)

«Настоящим подтверждаю свою дееспособность и даю ООО „Огого“ согласие на обработку персональных данных в целях исполнения заказа...»

У нас в компании тоже сейчас активно меняют оргструктуру по рекомендациям Адизеса. Всё очень похоже :) Красные/жёлтые/зелёные, стратегия/тактика.


Но вот с IT сложнее.
Это по умолчанию operations для вас (т.е. IT не занимается разработкой продукта), поэтому, кмк, мало смысла делить его на прям разные отделы. Точнее не так — отделы могут быть разные (а-ля эксплуатация/развитие), но должны быть под одним CIO.

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

Такой подход ещё Генри Форд использовал.
А теперь он, значит, называется «микросервисами» :)
Возможно, в скором времени запись в резюме «Проходил полугодовую управленческую стажировку в Мосигре» будет цениться выше, чем все эти MBA. )
И кстати, не планируете провести оффлайновые встречи с рассказами, как до такой жизни докатились? и опять таки, заработок… возможно, рассказывать о том, как делать игры, будет выгоднее, чем делать игры! ;)
Спасибо, но пока мы спасуем. Хотя на конференции по подобным вопросам выступать часто зовут, да.
Тяжёлая статья, но частично проясняет вашу идею ведения деятельности. Спасибо, что прогрессируете! :)
Зарегистрируйтесь на Хабре , чтобы оставить комментарий