Size: a a a

DocOps-сообщество

2020 August 29

ML

Maksim Lapshin in DocOps-сообщество
ID:0
📈 Высокой культуры пост

Если вы хотите привнести что-то новое в компанию — вы всегда будете сталкиваться с сопротивлением.
Одним из них может быть сказка про якобы уже существующую "высокую культуру", которой нет на самом деле. Некоторые топ-менеджеры, с которыми вам предстоит общаться, к месту и не к месту включают режим защиты своих решений, своего кода и своего наследия — даже не вникая в то, что вы им говорите. При этом на практике свою "высокую культуру" применить они не способны и их собственное поведение идёт полностью в разрез с декларируемым.
Вам говорят про открытость — но цели и причины остаются в головах. Вам говорят про agile и гибкость — но жить нужно по заранее определённому плану и сбор обратной связи игнорируется. Вам говорят про инновации и идеи — но каждая секунда времени должна трекаться в задачи. Вам говорят про высокую культуру обмена знаниями — но запрещены попытки формулировать best practice.
Подобный абсурд смешно звучит тогда, когда вы его осознали, но если у вас не так много опыта — легко поверить рассказам про высокую культуру на серьёзных щах.
Старайтесь избегать дутых щёк в себе и окружающих, смотрите вокруг и задавайте неудобные вопросы.
Почему-то упущен момент с тем, что когда новый человек приходит в компанию, то его движения по внесению нового как правило неуклюжи и организация естественным образом сопротивляется
источник

ЕД

Егор Доронин... in DocOps-сообщество
Новому человеку, если это не профессионал именно по улучшению процессов и привнесению культуры, первый год можно вообще не отсвечивать с новыми инициативами
источник

ЕД

Егор Доронин... in DocOps-сообщество
Не разобравшись досконально, почему все делается так, как делается (а причина всегда есть где-то в прошлом) можно в лучшем случае только хуже сделать
источник
2020 August 30

IA

Ivan Abashkin in DocOps-сообщество
Егор Доронин
Не разобравшись досконально, почему все делается так, как делается (а причина всегда есть где-то в прошлом) можно в лучшем случае только хуже сделать
Плюсую!
источник

IA

Ivan Abashkin in DocOps-сообщество
Компания - работающий, живой организм. Факт её существования в данный момент на конкурентном рынке - показывает, что она прошла этапы  естественного отбора. Значит  то, как сейчас устроена компания - как минимум оправдано фактом её существования.
Компания - это система, которая перерабатывает ресурсы в ценность для клиентов.
В любой системе, как правило есть только одно бутылочное горлышко, которое ограничивает её производительность.

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

Поэтому любое изменение - это проект. Он должен быть очень хорошо продуман и осознан. Должно быть четкое понимание для чего он делается и какие результаты принесёт. На что этот проект повлияет, что затронет? Какие риски привнесёт? Эти риски должны быть так же отработаны и нивелированы  в ходе внедрения проекта по изменению.

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

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

Если вы оказались на месте такого новичка, то имеет смысл в первую очередь осознать реальное место в системе (компании), которое необходимо изменять. Сделать это возможно вычленив ключевые "болевые" точки и придумать решение, которое закроет большинство этих проблем. Формализовать это в презентацию и донести до руководства. Если от руководства вы получаете сопротивление, значит что-то не до конца проработано.  Либо предлагаемое изменение, либо его риски. Имеет смысл обсудить это с руководством и пойти на второй круг. И так до победного.

Пожалуйста, подходите к любым изменениям осознанно! Не должно быть изменения ради изменения.
Делать резкие движения с закрытыми глазами опасно для жизни!
источник
2020 August 31

a

akater in DocOps-сообщество
Ivan Abashkin
Компания - работающий, живой организм. Факт её существования в данный момент на конкурентном рынке - показывает, что она прошла этапы  естественного отбора. Значит  то, как сейчас устроена компания - как минимум оправдано фактом её существования.
Компания - это система, которая перерабатывает ресурсы в ценность для клиентов.
В любой системе, как правило есть только одно бутылочное горлышко, которое ограничивает её производительность.

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

Поэтому любое изменение - это проект. Он должен быть очень хорошо продуман и осознан. Должно быть четкое понимание для чего он делается и какие результаты принесёт. На что этот проект повлияет, что затронет? Какие риски привнесёт? Эти риски должны быть так же отработаны и нивелированы  в ходе внедрения проекта по изменению.

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

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

Если вы оказались на месте такого новичка, то имеет смысл в первую очередь осознать реальное место в системе (компании), которое необходимо изменять. Сделать это возможно вычленив ключевые "болевые" точки и придумать решение, которое закроет большинство этих проблем. Формализовать это в презентацию и донести до руководства. Если от руководства вы получаете сопротивление, значит что-то не до конца проработано.  Либо предлагаемое изменение, либо его риски. Имеет смысл обсудить это с руководством и пойти на второй круг. И так до победного.

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

Сильное утверждение.  Оно чем-то подтверждено?
источник

IA

Ivan Abashkin in DocOps-сообщество
akater
> В любой системе, как правило, есть только одно бутылочное горлышко

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

Применительно к менеджменту этот вопрос очень хорошо расписан в Теории Ограничений Голдратта.
источник

И

Иван in DocOps-сообщество
akater
> В любой системе, как правило, есть только одно бутылочное горлышко

Сильное утверждение.  Оно чем-то подтверждено?
Ну если «бутылочное горлышко» — это самый «медленный» элемент системы, то очевидно, что оно всегда одно. Избавились от одного — теперь «не самый медленный» элемент стал бутылочным горлышком :)
источник

a

akater in DocOps-сообщество
Иван
Ну если «бутылочное горлышко» — это самый «медленный» элемент системы, то очевидно, что оно всегда одно. Избавились от одного — теперь «не самый медленный» элемент стал бутылочным горлышком :)
Тогда да.
источник

OK

Olya Kirillova in DocOps-сообщество
Егор Доронин
Новому человеку, если это не профессионал именно по улучшению процессов и привнесению культуры, первый год можно вообще не отсвечивать с новыми инициативами
Я не думаю, что это хорошая идея предлагать поменять почти все на третий рабочий день, но и сидеть и не отсвечивать целый год это долго, имхо. За такой год можно и работу сменить, так как устанешь разгребаться.
Надо просто предлагать изменения соразмерные своей роли в проекте. Например, не нужно ждать год, чтобы предложить коллегам использовать бранчи в гите, а не лить все в один-единственный мастер.
Ну и конечно надо задавать больше вопросов на собеседовании, чтобы не оказаться там, где ты не хочешь :) Например, мне не интересно какая там драма предшествовала решению использовать word и кучу копипасты, если компания в 2020 году не готова двигаться куда-то дальше и хочет тащить этот багаж в силу каких-то важных для них причин. Но я в такой проект не хочу :))
источник

ML

Maksim Lapshin in DocOps-сообщество
Olya Kirillova
Я не думаю, что это хорошая идея предлагать поменять почти все на третий рабочий день, но и сидеть и не отсвечивать целый год это долго, имхо. За такой год можно и работу сменить, так как устанешь разгребаться.
Надо просто предлагать изменения соразмерные своей роли в проекте. Например, не нужно ждать год, чтобы предложить коллегам использовать бранчи в гите, а не лить все в один-единственный мастер.
Ну и конечно надо задавать больше вопросов на собеседовании, чтобы не оказаться там, где ты не хочешь :) Например, мне не интересно какая там драма предшествовала решению использовать word и кучу копипасты, если компания в 2020 году не готова двигаться куда-то дальше и хочет тащить этот багаж в силу каких-то важных для них причин. Но я в такой проект не хочу :))
с другой стороны именно в таком месте можно быстро вырасти до начальника, потому что там ясно что менять и надо лишь справиться с изменениями.
источник

OK

Olya Kirillova in DocOps-сообщество
Согласна! Это челлендж и очень интересный опыт. Я оспаривала аргумент о том, что надо ждать год, все изучать досконально и только потом предлагать что-то улучшать. Я не согласна год тащиться по инерции :) поэтому я и буду искать проекты, где мы друг другу подходим.
источник

ML

Maksim Lapshin in DocOps-сообщество
Olya Kirillova
Согласна! Это челлендж и очень интересный опыт. Я оспаривала аргумент о том, что надо ждать год, все изучать досконально и только потом предлагать что-то улучшать. Я не согласна год тащиться по инерции :) поэтому я и буду искать проекты, где мы друг другу подходим.
ну да, за год можно вполне принять те причины по которым в компании принято коммитить ворд в csv и громким ором согласовывать очередность коммитов =)
источник

OK

Olya Kirillova in DocOps-сообщество
Принять и простить :)
источник

ЕД

Егор Доронин... in DocOps-сообщество
Никто не заставляет ждать год) Тем более, что далеко не каждому нужно и позволят энтропию уменьшать вокруг себя.
Я был бы осторожен с мелкими улучшениями. Во-первых, подобные очевидные low hanging fruit, хоть их и рекомендуют решать в первую очередь, часто бывают верхушкой айсберга
источник

ЕД

Егор Доронин... in DocOps-сообщество
Во-вторых, сначала обязательна инвентаризация и оценка зрелости процессов в компании. Смысл что-то улучшать, если они на уровне 1
источник

ЕД

Егор Доронин... in DocOps-сообщество
источник

OK

Olya Kirillova in DocOps-сообщество
Острожность и risk management никто не отменяет!
источник

ЕД

Егор Доронин... in DocOps-сообщество
Думаю, все видели эту картинку
источник

ЕД

Егор Доронин... in DocOps-сообщество
Risk management - это если вообще в компании есть такой
источник