Русский
Русский
English
Статистика
Реклама

Менеджмент

Интервью с Марселем Ибраевым о распиле монолита или Успех распила монолита грамотный менеджмент

17.06.2021 20:21:19 | Автор: admin
Я как-то видел, когда в команду разработки закинули задачу распилить монолит. И всё. Люди должны были работать в два раза больше это ужасно.
Когда поступает похожий запрос, важно не наворотить дел и понять, как избежать новых трудностей. Об этом рассказал Марсель Ибраев, технический директор Слёрма.

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



Давай представим, что перед нами стоит задача распилить монолит.

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

Так, и какими дальше будут наши действия?

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

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

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

Нет. Я в корне не согласен с этим. Монолит и микросервис это две разные архитектуры под две разные задачи. Например, если проект представляет собой магазин носков, который ежедневно посещают пять человек и в будущем их будет не сильно больше, то, скорее всего, лучше делать монолит. Так будет быстрее и проще. Главное не упустить момент, когда требования к проекту и подходам сильно изменились, а ваш магазин стал вторым Amazon. :)

А есть ли какое-то решение в обход распила монолита?
Допустим, мы мигрируем в облако, и нам требуется при миграции подготовить свое приложение к Кубу, а именно распилить на сервисы.


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

То есть не получится запихать legacy в контейнер и сказать, вот, пожалуйста, влезло.

Нет. Такая идея может возникнуть. Например, кто-то написал какое-нибудь древнее legacy, которое все боятся трогать. Допустим, этот человек пару лет назад уволился, а сейчас кто-нибудь предлагает взять и запихать его код в контейнер со словами: Пусть это там само работает. Звучит дико, согласен. И я бы не поверил, что такое может быть, если бы не увидел своими глазами.

Ты говоришь, что если мы собираемся пилить монолит, то нам нужен человек, который будет курировать процесс работы, прикинет затраты.
А вот что делать, если ни у кого нет опыта в этом?


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

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

Почему?

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

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

Есть какие-то выходы из этой ситуации?

Это, скорее всего, будут кадровые решения и набор компромиссов. Можно нанять новых сотрудников или отправить на учебу имеющихся, как я уже сказал ранее. Можно какие-то кадровые перестановки сделать. Также стоит учесть, что теперь команде нужен человек, который будет понимать инфраструктуру будущего проекта. Идея просто засунуть всё в Kubernetes кажется легкой, конечно, но не стоит забывать что Kubernetes это дополнительная абстракция в вашей инфраструктуре. Да, она позволяет решать ряд операционных задач проще, но по факту делает жизнь админов и поддержку проекта сложнее.

Ты сказал, что людей нужно обучить. Можно ли упаковать информацию по распилу в какое-то единое знание? Будь то гайд или курс для разработчиков или админов.

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

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

Проекты бывают разные. У кого-то интернет-магазин, у кого-то платформа для торгов. Отличаются ли аспекты распила для них?

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

Копнём про гибкость глубже. Распил какой-то части отодвигается на месяц, как тогда быть?

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

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

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


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

С кем важно договориться в первую очередь?

С бизнесом. Важно понимать, что-то 100% пойдет не по плану. Это часть процесса, так точно будет. Как бы хорошо и правильно вы всё не распланировали, вы с этим точно столкнетесь, к сожалению. Но может быть, просто мне так не везло, и бывает что все проходит идеально.

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

Сколько нужно разработчиков и админов для распила монолита? Кто из них будет работать дольше или больше?

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

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

Да, у нас было такое. Пришел к нам клиент, которому нужен был Kubernetes. Поскольку мы ребята опытные, то сразу задаём встречный вопрос: А вам это зачем? Бывали случаи, когда мы отказывали клиентам, потому что не видели необходимость в Kubernetes, естественно всё объясняли. Человек услышал что-то про Kubernetes, решил, что это круто, и захотел. Расскажу про ситуацию, когда мы не отказали.

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

Часть монолита хостилась на нескольких серверах в разных частях. Примерно всей кодовой базы была неизвестна: туда никто не лез, потому что люди, которые ее писали, уволились, и изучение того, что там, оставляли на потом. Проект был в сложном состоянии. Контейнеры крутились в Docker Swarm. В одном контейнере был просто запущен кусок монолита, хотя ради справедливости стоит отметить, что было и несколько микросервисов. В итоге, конечно, мы разобрались со всем этим.

И всем стало хорошо?

Вроде бы и да, но счастье почему-то всё не наступало. То есть технически проект стал работать стабильнее, деплой стал удобнее. Но радости от этого со стороны заказчика мы почему-то не ощущали. Мы поняли, что стоило бы глубже обсудить вопрос, зачем все же клиенту нужен был Kubernetes.

Оказалось, история была следующей. У проекта изначально были некоторые бизнес-проблемы, в которых видели техническую причину. Один из разработчиков тогда сказал, что причина, почему так все плохо в монолите. В тот же день поставили задачу переезд на микросервисы. И действительно даже начали распил и частично заехали в Docker SWARM. Только счастье все равно не наступало, просвета не наблюдалось, проблемы не решались. Тогда решили, что проблема в Docker Swarm. И обратились к нам.

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

Что именно вы делали?

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

Не знал, что Southbridge оказывает такую услугу (прим. Кейс с того времени, когда Маресль работал инженером в Southbridge).

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

Как понять, что мы действительно распилили монолит на микросервисы, а не сделали микросервисный монолит?

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

Приведи пример.

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

Подведём итог. Рецепт распила монолита состоит в следующем: компетентные кадры, грамотное планирование, четкое понимание целей и гибкость в работе. Ничего не упустил?

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

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

Зачем разработчику развивать эмпатию?

27.03.2021 02:13:42 | Автор: admin

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

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

Эмоциональный интеллект: введение

Эмпатия это одна из составляющих эмоционального интеллекта (EQ). Поэтому я предлагаю начать разговор с него.

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

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

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

Американский социальный психолог Питер Саловей рассматривает пять главных областей эмоционального интеллекта:

  1. Знание своих эмоций. Мы понимаем, что чувствуем.

  2. Управление эмоциями. Мы понимаем, что чувствуем, и умеем справляться с этим.

  3. Мотивация для самого себя. Мы понимаем, что нужно чувствовать, чтобы достичь поставленной цели.

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

  5. Поддержание взаимоотношений. Мы понимаем свои и чужие эмоции и можем контролировать их при коммуникации.

Теперь, когда у вас есть общее понимание контекста, можно приступить к разговору об эмпатии.

Что такое эмпатия и почему она нужна разработчику?

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

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

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

Эмпатию часто практикуют в UI/UX дизайне, чтобы представить возможные пользовательские действия и реакции. В таком же ключе можно использовать эмпатию и в написании кода, но поможет она и в личном общении. Вот короткий список моментов, когда, по моему мнению, развитая эмпатия будет полезна разработчику:

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

  • процесс написания кода нужно помнить, что мы пишем код для людей, а не для машин, и с вашим кодом будут потом работать другие люди;

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

  • общение с коллегами тут, думаю, всё понятно и без объяснений.

Как начать работать над прокачкой эмпатии?

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

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

  • Разберитесь со своими эмоциями. Даже испытывать гнев это нормально, важно это осознавать и быть в состоянии объяснить другим, почему вы его чувствуете. Есть уйма приложений, где вы можете фиксировать изменение своего настроения и описывать его причину.

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

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

  • Старайтесь понять эмоцию вашего собеседника и соответственно реагировать. Это непросто, но, если вы начнёте лучше понимать свои эмоции, вам откроется и эмоциональный мир людей вокруг.

С тех пор как я стал больше внимания уделять развитию эмоционального интеллекта, в моей жизни произошли такие изменения:

  • мне стало проще понимать решения или желания других людей, как в команде, так и в семье;

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

  • упростилось прогнозирование действий или решений других людей;

  • я легче нахожу мелкие радости, которые могут сделать мой день ярче и продуктивнее;

  • мне стало проще и приятнее договариваться с людьми.

Какие изменения развитие эмоционального интеллекта и эмпатии принесёт в вашу личную и профессиональную жизнь не берусь судить. Но советую как минимум поинтересоваться этой темой.

Подробнее..

Коты и лебеди на выпасе листаем книги для введения в профессию менеджера

22.03.2021 20:04:15 | Автор: admin

Привет! Это Кирилл, куратор потока Менеджмент. На Хабр часто выкладывают посты про интересную профессиональную литературу. В итоге наша площадка давно превратилась в одну из самых крупных библиотек с отзывами на книги про IT, но структурировать это никто пока не пытался. Чтобы это исправить, запускаем серию библиотечных подборок. Под катом первая из них с книгами, которые помогут новичку освоиться в роли руководителя, а маститому боссу освежить знания и стать ещё лучше.

1. Нассим Николас Талеб. Чёрный лебедь. Под знаком непредсказуемости
Теория чёрного лебедя рассматривает редкие, труднопрогнозируемые события, следом за которыми идут серьёзные последствия. Если вы имеете дело с разработкой ПО, книга поможет расширить кругозор и увидеть потенциальные опасности, которые раньше были незаметны.
Рассмотрев эту теорию можно понять актуальность потенциальной фундаментальной уязвимости в любой автоматизированной системе. Проблема достаточно старая, существует столько же сколько и язык C.
Krasnoglazik

2. Фредерик Брукс. Мифический человеко-месяц, или Как создаются программные системы
Классическая книга об управлении разработкой ПО. В 2018 году журнал PC World поставил её на первое место в своём топе IT-книг, которые стыдно признать, что не читал, а несколько сотен пользователей StackOverflow поместили её на восьмое место в списке самых важных книг по программированию из когда-либо написанных.
О книге Фредерика Брукса я услышал ещё учась в универе. Через пару лет я к ней вернулся. К тому моменту у меня уже было несколько лет работы в IT-индустрии. И когда я начал читать, то удивился, насколько книга, написанная в 1975 актуальна!
devmark

3. Дж. Х. Рейнвотер. Как пасти котов. Наставление для программистов, руководящих другими программистами
Книга о том, как совмещать лидерство с руководством, если управляешь IT-проектами. Будет полезна тем, кто оказался в менеджерской позиции после работы обычным программистом или уже давно руководит людьми, но хочет улучшить свои навыки.
Книга Как пасти котов подкупает своей предметностью: здесь описываются хорошо всем знакомые ситуации, разбираются по косточкам разные составляющие и условия работы команды, даже приводятся авторские технологические решения.
ProductivityInside

4. Джефф Сазерленд. Scrum. Революционный метод управления проектами
Одна из тех книг, которые точно нужно прочитать, если пытаетесь разобраться в этой методике. Как минимум потому, что её написал сам создатель Scrum.
Вся книга поделена на главы, которые являются основными акцентами фреймворка Scrum, а заодно и основными его преимуществами. Отдельно выделяется первая глава, где описываются времена, когда методология только зарождалась. Читается на одном дыхании, оторваться невозможно.
dmitriyabr

5. Джим Кэмп. Сначала скажите нет
Кэмп учит проводить переговоры с позиции силы. Задавать правильные вопросы, противостоять манипуляциям, не обращать внимания на вещи, которые не получится изменить и концентрироваться на своём поведении. Словом, это универсальная книга, которая будет полезна и при трудоустройстве на новую работу, и во время сложных переговоров с партнёрами.
Лучшая презентация та, которую ваш клиент не увидел. Кэмп утверждает, что презентация ставит вас в положение ниже противника. Если же вы действуете в рамках системы Кэмпа, если вы описали противнику его боль, то сделали тем самым самую лучшую презентацию. Если же вы не смогли описать боль, презентация не поможет и ничего не даст.
navff

6. Том ДеМарко. Deadline. Роман об управлении проектами
Автор этой книги глава консалтинговой компании Atlantic Systems Guild, которая выстраивает сложные бизнес-системы и помогает управлять рисками. Из 13 написанных книг эту он считает самой сильной. Написанная в форме художественного романа, она раскрывает закономерности и говорит о проблемах, которые могут поджидать зазевавшегося менеджера.
Deadline своеобразная пародия на приключения Джеймса Бонда. История про попаданца, рассказанная в мире информационных технологий планеты, похожей на нашу. После прочтения будет сложно взяться за любую другую книгу по управлению проектами неизбежно покажется скучной.
Arch_Stanton

7. Джейсон Фрайд и Дэвид Хайнемайер Хенссон. Rework: бизнес без предрассудков
Эту книгу написали основатели компании 37signals, которая сейчас известна как BaseCamp. При 14 постоянных сотрудниках продуктами этой организации регулярно пользуются более 3 млн человек по всему миру. В книге их опыт о том, как начать своё дело или просто довести проект до удачного финала. Даже если у вас нет времени и кажется, что чего-то не хватает.
Rework читается легко и быстро. Чем-то напоминает смесь Берись и делай Ричарда Брэнсона и Партизанского маркетинга Джея Конрада Левинсона: мотивирует и содержит много полезных и применимых на практике рекомендаций для IT-компаний.
VitaliyACTIVITI

8. Психбольница в руках пациентов. Алан Купер об интерфейсах
Первая и самая известная книга отца Visual Basic о том, как делать интерфейсы, которые будут понятны и удобны пользователям.
Все мы безумцы, живущие в технологическом сумасшедшем доме, и создали этот безумный мир мы сами. Своими руками сотворили этот кошмар: интерфейсы, которые нас раздражают и утомляют глаза, устройства, которые приводят к болям в спине и в запястьях.
ph_piter

9. Максим Батырев. 45 татуировок менеджера
Относительно короткое руководство о том, как вести дела, чтобы успешно их завершать и приходить к прогнозируемому результату.
Все татуировки очень напомнили мне и самому не чуждый армейский опыт. 45 татуировок менеджера написаны кровью управленца и его подчиненных, и уже хотя бы поэтому я рекомендую эту книгу всем, вне зависимости от занимаемой должности.
jasiejames
Подробнее..

Осторожно! Маркировка

02.04.2021 22:17:15 | Автор: admin

И было сказано слово: "Маркировка!" И набежали тучи, и застили небо. И повис в воздухе вопрос: "Что делать?" И закралась надежда: "Авось пронесёт!"


Часть 1. Глаза боятся, а руки делают

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

1. Определить Владельца бизнес-процесса "Маркировка" - центр ответственности и Ключевого пользователя - центр компетенций по операциям маркировки товара/продукции.

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

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

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

6. Разработать план-график запуска процесса маркировки с учетом графика запуска маркировки в отрасли.

7. Сотруднику компании, имеющему право подписи документов без доверенности, пройти процедуру регистрации в личном кабинете "Честного знака" (далее ЛК ЧЗ) . Подключить тестовый ЛК ЧЗ.

8. Выпустить усиленную квалифицированную электронную подпись (УКЭП) с расширением "Маркировка" для Ключевого пользователя и подключить его в рабочий и тестовый ЛК ЧЗ с ролью "Администратор".

9. Выделить 25 - 40 часов Ключевому пользователю по маркировке на изучение нормативной документации, пользовательских инструкций, видео-инструкций и т.д..

10. Настроить интеграцию между тестовой средой ГИС МТ ("Честный знак") и тестовой учетной системой, используя стандартные механизмы.

11. Ключевому пользователю провести функциональное тестирование операций по маркировке. Результаты оформить Протоколом.

12. Разработать схему бизнес-процессов компании и встроить в неё операции по маркировке. Согласовать с участниками рабочей группы.

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

14. Сформировать пул задач на доработку учетной системы компании, в т.ч. по интеграции с ГИС МТ. В зависимости от имеющегося в распоряжении времени установить задачам первый или второй приоритет, разработать график реализации.

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

16. Подготовить тестовый контур. Провести демонстрацию разработанного функционала участникам рабочей группы и сквозное тестирование. Исправить ошибки по результатам тестирования.

17. При наличии технических и производственных возможностей выполнить пилотный запуск процесса маркировки.

18. Подготовить инструкции для пользователей, при необходимости провести обучение. Подключить пользователей в рабочий ЛК ЧЗ, настроить УКЭПы в учетной системе.

19. Запустить процесс маркировки в эксплуатацию. Контролировать корректность проведения операций и передачи данных в "Честный знак".

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

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

Часть 2. Спасение утопающих - дело рук самих утопающих

Интерфейс и инструментарий ЛК Честный знак не предназначены для использования в ручном режиме, если потребности бизнеса подразумевают массовые операции по эмиссии кодов, вводу и выводу из оборота, перемаркировке, продаже или передаче на комиссию другому юр.лицу и т.д..

Не спасает ситуацию вариант массовой загрузки данных в ГИС МТ через csv-файл или xml-файл. Формат csv требует дополнительных действий пользователя: экранирование специальных символов, изменение настроек Windows, контроль разделителей и формата кодировки.

Вариант xml-файла, как способ перегрузки данных из учетной системы в ГИС МТ, не вызвал бы вопросов, если бы не формат вывода данных в ЛК Честный знак в виде строки. Например, документ Отгрузка в ЛК Честный знак предстанет перед грузоотправителем и грузополучателем в следующем виде.

Не существует в ЛК Честный знак и возможности экспортировать данные в файлы Excel или csv. Разве что выгрузка из Национального каталога отчета по карточкам товара, находящихся в статусе Опубликована.

Оптимальным вариантом взаимодействия с ГИС МТ является обмен данными через методы API. Для этого можно воспользоваться либо сторонними сервисами (Мой склад, Таском и т.д.), либо стандартными механизмами, встроенными в учетные системы, либо разработать функционал с нуля.

Часть 3. На 1С надейся, но сам не плошай

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

1. Различие в названиях объектов и реквизитов между 1С и ЛК Честный знак. Например, документ Ввод в оборот спрятан за названием Маркировка товаров ИС МП. В документации на сайте https://честныйзнак.рф используется сокращение ГИС МТ, а в 1С - ИС МП. Способ ввода в оборот Производство вне ЕАЭС в 1С называется Импорт и т.д.

2. В регистре сведений Очередь сообщений ИС МП скапливаются неотправленные запросы, исправление ситуации требует вмешательства разработчика.

3. Через сервис Обмен с ИС МП (обувь, одежда, табак) невозможно получить актуальный статус кода маркировки или списка кодов маркировки. Статус кода можно увидеть непосредственно в ЛК Честный знак.

4. Для того, чтобы узнать под каким номером упал документ в ГИС МТ, необходимо пройти квест по Протоколу обмена.

5.1С не запрашивает актуальный статус документов в ГИС МТ, поэтому в журналах присутствуют документы со статусом "ошибка", тогда как по факту в ЛК Честный знак пользователь видит статус обработан. Возможность изменить статус вручную не предусмотрена.

6. Через сервис Обмен с ИС МП (обувь, одежда, табак) невозможно создать Заказ на эмиссию со способом ввода в оборот Перемаркировка. Как следствие пользователю необходимо выпустить коды маркировки непосредственно из ЛК Честный знак. Документ Перемаркировка, который вводит коды в оборот, не только не предусматривает возможности ввода в оборот без указания предыдущего кода, но и реализован с ошибками. Требуется тестирование функционала и доработки.

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

Подробнее..

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

06.04.2021 16:12:32 | Автор: admin

Привет, Хабр! Меня зовут Лена Хасанова, я заместитель руководителя в агентстве аутсорс тестирования Кавычки. Я занимаюсь постановкой процессов, руковожу проектами, курирую команды, сотрудников и, конечно, еще и тем, о чем дальше пойдет речь развиваю внутреннее обучение.

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

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

Предыстория

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

Нам нужен был более рабочий планНам нужен был более рабочий план

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

И я решила, раз сейчас появилось свободное время, значит пора заняться обучением.

Задачи, которые нужно решить

Запуск обучения похож на череду задач, к которым нужно подобрать свое решение:

  • Организовывать процесс

Думаю, что одна из главных причин, почему многие компании (в частности IT) не занимаются обучением у них нет понимания, как организовать процесс. Это должен делать тот, кто так или иначе имел какое-то отношение к педагогике. Большинство IT-специалистов все-таки люди с техническим образованием и таким же складом ума. А когда запускаешь сложный проект, связанный с людьми и мотивацией, нужен педагогический подход, понимание психологии и килограмм сто терпения.

Решение:

Можно пригласить на консультацию специалиста, у которого есть такой опыт. В нашем случае помог мой бэкграунд до карьеры в IT я 13 лет работала педагогом. Я знаю, как готовить лекции, как ставить процесс обучения и т.д. Поэтому у меня изначально было понимание, что делать и как.

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

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

Решение:

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

  • Найти лекторов

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

Решение:

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

Но начиналось все, конечно, такНо начиналось все, конечно, так
  • Поставить обучение на поток

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

Решение:

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

  • Выбрать время

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

Решение:

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

  • Продумать подачу контента и сформировать базу знаний

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

Решение:

У нас есть несколько форматов: лекция и обсуждение. Для лекции обязательно нужно подготовить презентацию, а доклад уже по желанию. Для обсуждения презентация и доклад только по желанию. Мы созваниваемся, сотрудник показывает презентацию в режиме демонстрации экрана под запись. После каждой лекции мы обсуждаем, как это можно применить для наших проектов и разных ситуаций. А запись лекции и дополнительные материалы выкладываем в библиотеку.

Вот так выглядит наша библиотекаВот так выглядит наша библиотека
  • Найти мотивацию и сформировать ценность

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

Решение:

Запуск обучение это сложный, динамичный и многоэтапный процесс, в котором должна быть стратегия. Я вывела для себя такой план:

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

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

3 этап: создать регламент и правила: правила подготовки, правила проведения лекций, учет посещений.

4 этап: сформировать ценность и уникальность разбить обучение по группам и проводить отбор в группы в соответствии с уровнем знаний, т.е. в группу могут попасть не все желающие.

5 этап: ввести санкции за пропуски исключать из групп тех, кто пропускает без уважительной причины.

Варианты обучения: что мы пробовали и к чему пришли

Начало

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

Первый вариант обучения

Потом я уже стала предлагать темы всем ребятам. У нас сформировался план лекций на месяц. Мы старались подбирать лекции, которые имели практическое значение, или же брали темы на обсуждение, чтобы затронуть интересные моменты. К примеру, у нас была тема что делать тестировщику, если нет работы. Также у нас появились: правила, регламент обучения с требованиями к лекциям.

Что изменилось и улучшилось:

  • Лекции стали распределяться между ребятами;

  • Появилось расписание лекций на месяц вперед;

  • Появилось несколько разновидностей: лекция, обсуждение;

  • Присутствие по-прежнему было обязательным;

  • Подготовка к лекциям обязательна: тема даетсяминимум за неделю-две, асогласовать презентацию нужно минимум за несколько дней до даты лекции;

  • Появились правила и регламенты.

Милота после лекцииМилота после лекции

Второй вариант обучения

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

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

В месяц мы проводим четыре лекции по одной на каждое направление.

Что изменилось и улучшилось:

  • Появилось распределение тем по группам;

  • Стали проводить отбор людей в группы;

  • Начали вести журнал посещений;

  • У каждой группы появились кураторы;

  • Ввели санкции за пропуски.

Так выглядит наш календарь лекцийТак выглядит наш календарь лекций

Третий вариант обучения

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

Третий формат повлек за собой изменения регламента:

Из-за того, что многие рванули сразу на несколько курсов, начало страдать качество обучения и работа. Ребята просто не успевают работать и учиться, поэтому мы ввели новые правила в регламент:

  • Теперь мы контролируем количество курсов, которые посещают ребята. Для всех есть обязательный курс по тестированию, плюс можно выбрать один дополнительный курс. Если человек хочет несколько дополнительных курсов, то он обсуждает это с куратором и со мной;

  • Мы оставляем за собой право отчислять ребят из групп, если пошли косяки в работе: либо совсем исключаем, либо переводим в режим пассивного слушателя, пока сотрудник не стабилизирует ситуацию на работе;

  • Ребята могут сами перейти в режим пассивного слушателя или сделать перерыв. А когда вернутся, куратор поможет им обратно включиться в процесс;

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

Что изменилось и улучшилось:

  • Полностью поменяли программу общих лекций в сторону изучения инструментария;

  • Пересмотрели программу группы по подготовке к ISTQB;

  • Внесли изменения в регламент: теперь у нас есть ограничения по количеству курсов для одного сотрудника, а также санкции для тех, кто не справляется с работой/учебой.

Планы на будущее:

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

Есть ли прогресс?

Мы запустили обучение в апреле прошлого года. На данный момент мы провели более 60 лекций. И у нас действительно большой прогресс:

  • Каждый второй сотрудник повысил свою эффективность или смог внедрить полученные знания на проекте, чтобы улучшить качество работы;

  • Первая группа ISTQB уже сдала экзамен и получила сертификаты;

  • У команды значительно повысились скиллы и уровень знаний, а наша компания стала брать в работу более сложные проекты;

  • Внутри компании ребята могу вырастать до мидлов, лидов, автотестеров и в будущем до тест-аналитиков;

  • Ребята стали сами проявлять инициативу: что они хотят изучить или внедрить на своем проекте; какую тему подготовить для лекции. Уже сейчас наш план лекцийрасписан на 4 месяца вперед.

Лучше начинать, когда вы еще небольшая компания

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

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

Подробнее..

Встречи планирования разработки в пандемию, или Как устроить электро PIP

15.04.2021 14:13:15 | Автор: admin
Сегодня мне хотелось бы с помощью моих коллег Agile-коучей Ани Родионовой, Макса Зотова и владельца продукта в Трайбе Розничное взыскание и урегулирование Свята Божухина рассказать о практике применения интересного инструмента. Итак, речь пойдёт о Program Increment Planning Meeting aka PI Planning.

Это метод планирования из SAFe (Scaled Agile Framework) гибкого фреймворка для крупных компаний. Ну, знаете, это когда люди стоят у стены, оклеенной стикерами, лепят всякие ниточки от одного стикера к другому, но при этом в городе не орудует маньяк.

Ниже пример места встречи одной из команд для PI в Сбере (обратите внимание на ту самую стену на заднем плане):

image

Все мы помним, что в марте 2020 года всё стало иначе: пандемия и режим самоизоляции внесли свои коррективы. Мы переобувались на лету за неделю, а то, что ранее, как нам казалось, было возможно только оффлайн, переместилось в онлайн.

С чего началось


В марте 2020 года бОльшая часть команд перешла на дистанционный формат работы. Со встречами по планированию нужно было что-то делать. С технической точки зрения у нас были Zoom и Confluence, но организационно нужно было немного докрутить.

Вот так выглядит SAFe, и скромную часть в нём занимает PI:

image

Вот что должны сделать разные участники, чтобы планирование прошло успешно:

image

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

Scrum-мастерам поручили подготовить все шаблоны флипов (флипчартов). В онлайне они трансформировались в таблички на Confluence в специальном пространстве для совместной работы.

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

Группа фасилитаторов следила за тем, чтобы все шаблоны в Confluence были подготовлены и всё логистически готово.

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

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

Сама история почти не поменялась: если раньше были физические флипчарты, то теперь они стали виртуальными.

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

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

image

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

Потом риски. Если команда видит, что у неё, возможно, будут проблемы при реализации какой-то задачи, то она его обозначает, и потом уже мы решали, кто с этим работает и как.

image

И дальше распределение по спринтам. Мы смотрели на оптимистичность, пессимистичность и реалистичность команд и приводили их к чему-то единому, равному. Кто был не нагружен нагружали, а кто был перегружен чуть помогали освободить их бэклог.

И ещё один флип, на котором участники указывали контакты, по которым всегда можно было выйти на команду и обсудить бэклог на квартал.

Процесс


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

Дальше идёт работа команд:

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

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

В электронном виде стало удобнее: появилась чёткая структура, добавилась лучшая сохранность артефактов. Каждая задача ставится в Confluence.

В среднем из запланированного делается по факту 7080 %. Это очень качественный показатель.

Инвестиция в будущее


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

Вот так, если вкратце про PI Planning. Если хотите больше подробностей, то можно посмотреть выступление коллег тут.
Подробнее..

Стартап-гид основы выживания

02.05.2021 14:07:38 | Автор: admin

Вводная лекция

1.Идея

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

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

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

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

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

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

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

2.Задачи курса

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

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

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

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

Я познакомлю вас с юридическими аспектами оформления проектов, с азами российского и международного корпоративного права.

Мы порешаем с вами примеры на определение стоимости стартапов и выясним, какие из широкой линейки методов оценки бизнеса могут оказаться наиболее эффективными для вашего проекта.

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

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

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

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

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

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

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

Второй немаловажный блок это Финансы и налоги. Если право нацелено на урегулирование всех процедур, связанных с оформлением сделок по проекту, то финансовая сторона вопроса это управление бюджетами и денежными потоками компании, их аудит и оптимизация, это привлечение инвестиций в проект и обоснование, почему инвесторы должны вложиться именно в него. Сюда же отнесены фискальные требования, как неотъемлемая часть финансового блока любой компании: мы поговорим о том, как облагаются налогами источники финансирования проекта, что влечет за собой получение доходов от проекта основателями и компанией.

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

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

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

3.Основные определения

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

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

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

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

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

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

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

Что такое стратегия и чем она отличается от тактики? Скажем так: Тактика включает в себя набор приемов для выигрывания отдельной битвы, в то время как стратегия - для победы в войне.

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

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

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

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

Проект (англ. project от лат. projectus брошенный вперёд, выступающий, выдающийся вперёд) для наших целей, то есть, в управленческой деятельности - временное предприятие, направленное на создание уникального продукта, услуги или результата. Это определение дано по PMBOK - Project Management Body Of Knowledge (Свод знаний по управлению проектами). Дальше мы немного коснемся основных составляющих проектной деятельности, но для более глубокого изучения я вам рекомендую литературу, список которой представлен в конце материала.

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

Еще одно немаловажное понятие для наших целей это лидерство. Это интуитивно понятное для вас слово, но все-таки я дам ему определение.

  • Субъективно лидерство это способность вести за собой людей

Англ. слово lead вести. Можно быть лидером революционеров, как всем вам известный Ульянов-Ленин, например. Можно лидером нации. Таковым себя называют избранные президенты США, а еще диктаторы. Лидером нации однозначно был, например, Фидель Кастро. Можно - главарем банды, как, к примеру, Томас Шелби в Острых козырьках или крестный отец итальянской мафии Дон Корлеоне. Прекрасный образец лидерства в бизнесе Стивен Джобс, но о нем мы еще поговорим позднее.

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

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

Команда может формироваться под отдельный проект, либо, благодаря сплоченности и взаимодополнению друг друга профессиональными качествами каждого члена команды, такие команды являются устойчивыми субъектами на рынке и могут долгие годы работать либо в одной компании, либо подбирая под себя отдельные проекты, реализация которых требует именно hard and soft skills этой конкретной команды.

Пару слов о hard and soft skills.

Очень хайповое название. И сильно расшарено особенно в среде HR, коучей и всякого рода психологов и консультантов. Но что же это такое по своей сути?

Если говорить по-русски, hard skills это так называемые жёсткие навыки ваши профессиональные навыки то, что вы приобретаете в процессе учебы в качестве своей специальности. Понимаю, что для физтехов эти навыки можно смело назвать и гибкими, то есть, soft skills, учитывая какое огромное множество областей может стать опорой приложения ваших фундаментальных знаний, но, чтобы не создавать путаницы, пусть это будут hard skills.

Что же такое soft skills? Гибкие или мягкие навыки - это навыки, связанные с вашей личностью. Как их определяют современные специалисты, - это комплекс неспециализированных, важных для карьеры надпрофессиональных навыков, которые отвечают за успешное участие в рабочем процессе, высокую производительность и являются сквозными, то есть не связаны с конкретной предметной областью.

Какие гибкие навыки мы можем привести сразу в пример? Коммуникативные навыки (умение поддержать разговор, убеждение и аргументация, самопрезентация, навыки продаж, умение работать в команде и т.п.), навыки управления (планирование, мотивирование, делегирование, постановка задач и т.п.).

Термины hard и soft skills берут также начало в военном деле, как рассмотренные нами выше стратегия и тактика. В конце 50х годов XX века армия США начала разрабатывать научно обоснованный подход к подготовке военнослужащих. В ходе разработки исследователи выявили важность для военнослужащих не только профессиональных навыков (hard skills), но универсальных компетенций (soft skills), которые не поддаются планомерному обучению. Понимание различий между soft и hard skills было выражено в доктрине "Системы проектирования военной подготовки" 1968 года таким образом: hard skills являются навыками работы преимущественно с машинами, soft skills - навыками работы с людьми и бумагами. После того, как термины прижились в военной науке и психологии, они перешли в свободное употребление в сфере бизнеса. Сегодня в вакансиях, в том числе на русском языке, можно встретить вместо разделов "профессиональные навыки" и "личные качества" - hard skills и soft skills.

Эмпатия (греч. в + греч. страсть, страдание, чувство) осознанное сопереживание текущему эмоциональному состоянию другого человека без потери ощущения внешнего происхождения этого переживания[1]. Соответственно эмпат это человек с развитой способностью к эмпатии.

Эмпатия не имеет связи с какими-либо определёнными эмоциями (как, например, в случае со словом сострадание) и в равной мере применяется для обозначения сопереживания любым эмоциональным состояниям.

Эмпатия, являясь составной частью эмоционального интеллекта (EI - emotional intelligence), относится к качествам лидера.

На этом предлагаю завершить вводную лекцию.

Благодарю за внимание.

Продолжение следует.

Подробнее..

Recovery mode Когда люди не занимают первую строчку приоритетов руководителя, он становится ограниченным

14.05.2021 12:21:34 | Автор: admin
image

Непрофессиональное управление, нередко, загоняет руководителя (даже сильного, успешного и опытного) в состояние зависимости от сотрудников. А, происходит это примерно так:

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

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

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

Проходит время, и новый босс уже считается не новым. Он уже уверенно чувствует себя на троне, к нему привыкли, работы как-то выполняются, люди как-то работают. Все стабильно и хорошо! Босс начинает расслабляться и у него происходит смена приоритетов. Люди, которые раньше занимали первую строку его рейтингов, стремительно теряют позиции. Это, конечно, касается не всех. Часть людей остаётся для него важными, потому что, либо они ему выгодны, либо с ними просто приятно попить кофе. Им он продолжает уделять внимание. Остальные же довольствуются крохами со стола и смиренно ждут, когда он про них вспомнит.

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

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

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

За проблемами идут ещё большие проблемы. Сотрудники начинают покидать компанию. И ладно бы уходили слабые и не важные. Но, уходят, либо крепкие середнячки, либо звёзды, на которых все держится. И ладно бы один, ну или два. Нет! Компанию покидают в короткий промежуток ряд экспертов. Босс начинает чувствовать запах жареного и возвращает людей в первый приоритет своего рейтинга, но уже поздно. Люди разочарованы, люди демотивированы, люди не верят и не поверят, что все будет хорошо.

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

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

P.S. Я ни в коем случае не говорю, что ласковое и аккуратное отношение с сотрудниками это плохо, и, что руководитель должен хамовато общаться сверху вниз, и сидеть с надменным видом. Ничуть! Плохо в этом то, что руководитель теряет один из ключевых своих инструментов власть. Он становится ограниченным, испуганным и нерешительным. А это не лучшие качества для руководителя.

Дальнейшее развитие истории оставляю вам на подумать

Почему руководители не ставят людей приоритетом 1 в списке своих задач?



Люди это самая нелюбимая часть работы руководителя (как бы странно это не звучало). Не зря есть шутка: в управлении было бы хорошо работать, если бы не люди.

Люди это всегда больше стресса, больше расхода энергии, больше усилий. Не проекты пугают руководителей по ночам, а люди, которые могут их не выполнить

С людьми сложно! У каждого из них свои тараканы, каждый требует уникальный подход

Люди, в отличии от машин, не стабильны. Сегодня они работают на 100%, а завтра что-то нет настроения...

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

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

Больше о менеджменте в telegram-канале: t.me/OS_management
Подписывайтесь!
Подробнее..

Recovery mode Так Product или Project Manager?

17.05.2021 18:06:47 | Автор: admin

УЖЕ РАССУЖДАЛ О ТОМ ЧТО ПM-ОМ НАЗВАЮТ МЕНЕДЖЕРА ВСЕГО И ВСЯ. ДАВАЙТЕ ТЕПЕРЬ РАЗБЕРЕМСЯ В ЧЕМ РАЗНИЦА МЕЖДУ ПРОДАКТ И ПРОДЖЕКТ МЕНЕДЖЕРОМ.

Тут у меня в голове сразу три варианта возникают:

  1. Чистый проджект- когда речь идет конкретно о построении чего либо, и это может быть вовсе не продуктом для рынка. Результатом может быть что угодно, например процесс или мероприятие. Главное чтоб у него были четкие рамки по результату, времени и качеству. Качество тут (да и вообще) - это соответствие заявленным требованиям. И вот наш манагер этим всем руководит.

  2. Чистый продакт- когда объект внимания это продукт, и и все что с ним связано. При этом у него может не быть всех трех характеристик проекта. Например временных рамок - максимум это цикл развития продукта который может длиться десятилетиями.

  3. Гибрид- самая распространенная история. Когда у нас есть проект, со всеми вытекающими, и объект этого проекта - это продукт.

Как же быть? Как назвать?

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

Или проектная деятельность существует в рамках матричной структуры. То есть у нас есть функциональные подразделения типа Маркетинга, Финансов, Логистики, Разработки с одной стороны. Они выполняют конкретные функции - то есть повторяющиеся операции в рамках конкретных задач.

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

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

Ключевой момент здесь в фокусе.

Сценарий 1- для простоты возьмем пример IT аутсосрсинга. Компания ставит на поток разработку софта. По сути она делает IT продукты для внешнего заказчика.

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

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

То есть думать: а что там пользователи, а как сделать лучше. Смотреть аналитику, писать стратегию. У него есть внятная цель, описаная в ТЗ - он к ней идет, остальное на плечах стэйкхолдеров на стороне заказчика.

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

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

И тут наш доблестный продакт уже не фокусируется на конкретном ТЗ, а дальше суппорт и следующий проект. У него ежедневно в уме вся махина продукта, его дорожная карта и многочисленные варианты развития. А во главе всего удовлетворение интересов стейкхолдеров, ну и чисто по капиталистически - зарабатывание денег и рост. Кстати рост важнее.

Резюмирую:

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

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

Часто продакт совмещает в себе две роли на ранних стадиях. То есть и о стратегии думает, и операционкой руководит. Но это непросто.

А еще есть распространенное заблуждение - что подчиненный продакта по операционке это проджект. Если у него нет цели, дедлайна и требований по качеству - нет. Он просто операционный менеджер.

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

Смотрим - какие задачи ставятся, и ресурсы даются. Долгосрочные, стратегические и при этом более размытые задачи - это однозначно продакт.

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

И наоборот. Кратко или среднесрочные задачи, с внятными требованиями и операционкой каждый день? Типа постановки задач и контроля за реализацией, первичное тестирование и все то что нужно чтоб конкретная фича была разработана и выполняла свою функцию? Это проджект.

Если и то и другое, стратегия и операционка - снова продакт.

Вообще я тут накатал лонгрид как обычно, а все на самом деле просто: Вас спрашивает 8-ми летний ребенок - чем вы занимаетесь на работе?

Если вы не состоянии ему коротко и точно объяснить - то вы шарлатан )

А если в состоянии - то это сводится к тому что вы думаете и работаете большую часть времени либо над Продуктом, либо над Проектом.

И вот вы сами легко ответили на вопрос из заголовка. И ребенку картину мира расширили.

Подробнее..

Фактор демотивации 1 Отсутствие стратегии в головах сотрудников

28.05.2021 08:05:31 | Автор: admin
image

Введение



Дорогие читатели, в моей картине мира существует 48 демотиваторов, которые влияют на работу сотрудников компании. И, так как каждый человек уникален, одни демотиваторы могут оказывать на него сильное влияние, другие среднее, а некоторые могут быть практически незаметными. Поэтому, нумерация демотиваторов никак не отображает их мощность и влияние на сотрудника. Это просто нумерация.
Cейчас вы ознакомитесь с демотиватором под номером 1 в моем списке. Через какое-то время я выложу второй, потом третий,. Когда вы ознакомитесь со всеми, каждый сам для себя сможет определить правильную приоритетность и выбрать, какой будет на первом месте, какой на втором и так далее.

Итак, начинаем серию. Приятного чтения!

Covid-19 Карантин Кризис Компании закрываются Бюджеты сокращаются...


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


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


Люди боятся
С одной стороны, летит информация: массовые сокращения достигли x%, а с другой стороны: компании приостановили поиск новых кандидатов на y%. Они ощущают страх, они находятся в состоянии стресса. Вот-вот, и их позовет руководитель и сообщит о прекращении сотрудничества.


К чему это приводит?


Люди теряют задор и снижается продуктивность. Во-первых, это естественная реакция организма на состояние страха, стресса и давления. Сотрудник, особенно интеллектуально труда, не может эффективно работать в таком состоянии. Он быстро устает, у него меньше энергии, он не может творить. Он не может собрать мысли и сконцентрироваться. Во-вторых, а зачем напрягаться, если компания завтра пойдет на дно, если меня завтра уволят, если компания мне не заплатит? Если сотрудник и до этого был не очень вовлечен и раньше пытался увильнуть от работы, то сейчас у него для этого есть прекрасный повод и аргумент. Чем он с удовольствием и воспользуется.
И это все происходит во время кризиса!!! В то время, когда нужно мобилизоваться и увеличить эффективность! Вы понимаете всю абсурдность и печальность ситуации? Когда компании нужно увеличить свою эффективность, чтобы выжить люди уменьшают эффективность своей работы. Это усугубляет ситуацию и приводит к логичным последствиям.


Кто виноват в этой ситуации?


Начнем с сотрудников. Разве они виноваты? На чем строят они свои выводы? На том, что говорят руководители и как они об этом говоря. Но, проблема в том, что не говорят. Тогда, приходится пользоваться всем остальным: слухи, новости, друзья, свои умозаключения (мол, глядя на трещину в стене, мне кажется, что нам трындец), . Более рациональные попробуют логически рассуждать в разрезе компании и ее результатов, и попытаются вспомнить:


  • какие у нас были раньше результаты?
  • что раньше говорило руководство о положении компании?
  • всегда ли вовремя платили зарплаты?
  • были ли раньше проблемы?

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


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


Если бы сотрудник владел всей необходимой для адекватной оценки информацией, он бы, либо перестал боятся, либо осознанно боялся. А осознанный страх это совершенно другое состояние. Оно заставляет выходить на вопрос: Как это изменить? Как этого избежать? Как на это повлиять?.


image

.


Что делают руководители?


Они никак не коммуницируют с сотрудниками. Почему? Выделяю три популярные причины:


1) Мы сами ничего не знаем.


Руководители, вместо того, чтобы включаться и работать над антикризисными мерами ждут. Ждут, когда все рассосется само, когда все стабилизируется, когда закончится карантин. Ждуны!


Самые популярные фразочки:


  • Нас это не затронет.
    Фраза опирается, либо на безумную самоуверенность, либо на специфику деятельности. Мол, если мы работаем в IT, значит нам кризис не страшен. У нас все процессы настроены и готовы для удаленной работы. Нам нечего боятся!.
    Да, вы можете работать с клиентами удаленно. Но, нужны ли вы вашим клиентам? Кризис же это не только проблема процессов, но и проблема уменьшения потребительской составляющей. Прекрасно, что вы готовы предоставлять свои услуги в удаленном формате. Но, ваши клиенты для этого должны иметь деньги. Если их убьет этот кризис он убьет и вас.
  • Мы уже 2 кризиса пережили и этот переживем.
    То, что компания пережила несколько кризисов (хоть десять) не делает ее бессмертной. Кризисы, как и болезни, разные. Каждый новый кризис это новая болезнь, с новыми условиями, с новыми симптомами, с новыми побочными эффектами. Мы не знаем, какая комбинация этих условий сейчас будет работать против компании. И, как раз, возможно, именно эта комбинация станет роковой.
  • Давайте подождем месяцок-другой. Если ничего не изменится начнем действовать.
    Достаточно популярный выжидательный вариант. Чаще всего встречается в негибких компаниях, руководители которых понимают насколько сложно будет попытаться изменить движение этой махины. Решения в таких компаниях принимаются всегда запоздалые и сильно затянутые. Им проще выждать, чем это все перенастраивать.

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


2) Руководители не считают это важным.


Первый вариант: руководители просто не думают об этом. Раньше никогда подобная коммуникации не проводилась, нет такой практики. Да и времени сейчас нет на совещания: Работать нужно, а не совещаться!.
Работать нужно, но вместе с этим работа должна быть точной и эффективной. Люди должны понимать, какая ситуация сейчас, что их ждет завтра и куда мы бежим и почему. Это снимет страх и повысит точность выстрелов (правильных решений и действий).
Но, скажу больше. Состояние турбулентности, в котором находится компания во время кризиса, укорачивает период заряженности сотрудника. То есть, если вы провели мотивационную беседу с людьми, эффект такой мотивации будет в разы короче, чем в спокойное время. Поэтому, во время кризиса, время на коммуникацию должно выделяться в большем объеме, чем это было ранее! А если ранее не выделялось самое время начать.


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


3) Руководители боятся, что люди негативно отреагируют.


Попросту говоря, руководители боятся, что люди услышав какое-то непопулярные решения начнут сопротивляться в его реализации. Начнут бунтовать, саботировать и увольняться.
Могут и будут :) Никогда не будет ситуации, когда все сотрудники спокойно примут неприятные для них новости. Но, вопрос в масштабах сопротивления. Если вы вообще не выйдете к людям, они все равно все додумают сами и этот их вариант будет еще страшнее выглядеть. Поэтому, я считаю, что, если даже в стратегии есть плохие новости их все равно нужно озвучить публично. Это, во-первых, действие сильного человека и руководителя не бояться и говорить все, как есть. Во-вторых, у вас же все равно есть вариант выхода из этой плохой ситуации. Правда? А если так, то вы его также озвучите и люди увидят: Да, есть проблемы. Но, компания знает, как с ними бороться и что для этого нужно делать. И есть план И есть сроки. Это выглядит сильно!


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


Рассматриваю ли я эту компанию как ту, в которой я планирую долго работать?


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


К вам в компанию приходят разные люди. Одни с самого начала настроены на режим от работы кони дохнут, а другие ищут плацдарм для старта своей карьеры. Но, вот вопрос: увидят ли они в вашей компании те нужные характеристики плацдарма, которые убедят их разделить большой кусок своей карьеры именно с вами? А это все стратегия. Даже если ваша компания маленькая, ваша стратегия, которая имеет амбициозные и реальные цели, убедит с вами работать хороших специалистов.
P.S. Развитие компании с нуля часто является драйвером для амбициозных.


Рассмотрим еще один пример. Есть молодой амбициозный человек, который только что закончил Университет. Он хорошо учился, во время учебы подрабатывал и имеет неплохие софт скилы. Сейчас он выбирает для себя компанию, в которой начнет свою карьеру. Он понимает, что на высокую позицию ему пока претендовать рано, так как нет, ни опыта, ни знаний, да и годков ему маловато. Он это понимает и готов начать с нуля. И вот, он попадает в вашу компанию и начинает работать. Проходит два месяца, и он прекрасно понимает, насколько долго он с вами. Как он делает этот выбор? На основе стратегии компании! Он сопоставляет перспективы развития компании со своими планами на карьеру. Если стратегия никакая либо ее нет он не будет рассматривать компанию, как такую, в которой можно долго работать и расти.


Итоги


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


image

.
Руководители, с достаточной для этого регулярностью, должны коммуницировать с сотрудниками о:


  • текущем состоянии компании;
  • успехах;
  • проблемах;
  • перспективах;
  • стратегии (изменениях в стратегии).

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


Лирическое отступление
Кризис 2020 я считаю полезным, в части того, как он повлиял на управление в компаниях. Компании пересмотрели свои бизнес-процессы, компании оптимизировались, компаниям пришлось разработать стратегию, компаниям пришлось пересмотреть отношение к бизнесу. Абсолютно все компании, которые остались на плаву, зашли в 2021 более подготовленными и более подтянутыми. Управленцы стали более профессиональны и более мудры.
Подобный опыт я приравниваю к выживанию в экстремальных условиях. Ведь, прохождение экстремальных испытаний, которые грозят ему смертью это опыт, который позволит ему будущем справляться с любыми трудностями. Опыт антикризисного управления. Он бесценен!


Продолжение серии и другие статьи о менеджменте находите в моем telegram-канале: https://t.me/OS_management
Подписывайтесь! Далее будет
.
.
.

Подробнее..

Перевод Разработчики не могут исправить ошибки управленцев

18.06.2021 12:04:53 | Автор: admin
Мне постоянно попадаются статьи, в которых разработчиков упрекают за нежелание вникать, зачем нужна их работа, и доказывают им, что это неправильно вслепую вносить изменения, не разбираясь, какая за этим стоит цель. Звучат призывы в духе оглянитесь вокруг, не уходите с головой в написание кода!. На мой взгляд, эти статьи обращены не к тем людям.

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

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

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

В истории уже такое было


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

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

К 1981 году, когда Япония подтачивала позиции Форда на рынке уже десятки лет, руководство наконец сдалось и пригласило Деминга отладить производство. В их преставлении проблема заключалась в качестве изготовления деталей иными словами, в рабочих, которые изготавливали недостаточно качественные детали. Ведь не начальство же этим занимается. К большому их удивлению, Деминг заявил, что 85% проблем, негативно влияющих на качество продукции, происходят от неправильного руководства. Компании понадобилось шесть лет, чтобы перейти на новую модель, и результатом стала линейка автомобилей Taurus-Sable на голову выше того, что они делали до этого.

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

Теперь вернемся к тем статьям с призывами разработчики, подтянитесь!, которыми кишит Интернет. Давайте представим, что они обращены к рабочим, занятым в автомобилестроительстве. Прямо вижу эти заголовки:

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

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

И даже когда компания, работающая по традиционной модели, решает переключиться на Agile, зачастую всё выливается во внедрение антипаттерна Date Scrum, который прекрасно уживается со стандартным подходом к руководству. Растущая популярность Date Scrum привела к тому, что у многих разработчиков сложилось неприязненное отношения к практикам Agile вообще. Их сложно винить: если до внедрения Agile им приходилось терпеть собрания с отчетом по текущим задачам раз в пару недель, то с Date Scrum приходится страдать ежедневно!

Что такое Date Scrum?
Это практика из сферы R&D, которая предписывает разработчикам оценивать проектные требования сразу для всей протяженности работ целиком. Когда проекту дают зелёный свет и утверждают бюджет на базе конечных оценок, команда каждый день собирается на встречах (скрамах), чтобы отчитаться по текущему положению и нейтрализовать рискованные моменты; таким образом решение итерируется по мере продвижения к дате релиза. Некоторые воспринимают этот подход как каскадную модель, только реализованную спринтами.

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

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

Форду понадобилось сорок лет, чтобы перенять модель, разработанную Демингом. Сейчас темп жизни ускорился, и компании, которые ещё сорок лет намерены продолжать дёргать талантливых разработчиков, просто не вытянут. Полагаю, что большая часть тех, кто будет сопротивляться изменениям, пойдет ко дну уже лет через десять. Подобные мрачные предзнаменования вызваны тем, что компании с традиционным подходом работают по методичкам, написанным для промышленной сферы. Они разбивают сотрудников на группы по типу работ, а затем оптимизируют все отделы при помощи одного набора жёстких, шаблонных лучших практик, которые обычно один в один списаны с фабричных. Именно это препятствует созданию продуктов, которые несли бы ценность за счёт выявления и закрытия важных потребностей, и приводит к тому, что разработчики вынуждены с головой уходить в код, который в конечном счёте никому не нужен. По той же причине в компаниях упорно закрывают глаза на все знаки того, что проект сошел с рельсов в них слишком крепко прижились застарелые антипаттерны из университетских программ. Например:

  • Разработчики, которые тратят вполне разумное количество дополнительного времени на то, чтобы проверить то, что сделано, и устранить хаос, считаются какими-то неспешными.
  • Разработчиков, которые замечают какое-либо несоответствие между продуктом и запросами рынка, мягко отправляют обратно за клавиатуру, строгать новый функционал. Всё, на что они могут рассчитывать обещание, что группа, генерирующая идеи, обо всём позаботится.
  • Разработчики, которые быстро выкатывают продукты на суд соответствующей сторонней группы, ценятся, потому что оперативно приводят всё в состояние Готово.
  • Разработчиков, которые ведут полевые наблюдения и видят, что пользователи испытывают трудности с продуктом, ненавязчиво возвращают в рамки общей программы.
  • Техлидов, которые пытаются вникнуть в Общую Картину (как продукт приспособлен к рынку, как определяются цены и состав пакетов услуг), похлопывают по плечу и отправляют обратно, мотивировать разработчиков на производство очередного функционала сомнительной полезности.
  • Разработчикам, которые пытаются держать ситуацию под контролем при помощи техник статистического управления хаосом, рекомендуют оставить всё это группе, ответственной за Качество как будто люди, которые не писали код, справятся с делом лучше!

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

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

Следует обратить внимание и на то, чего разработчики просят не делать:

  • Избегать контроля в мелочах: код всё-таки пишут разработчики, не менеджеры;
  • Не приходить в команду с нулём технических знаний: нет ничего хуже, чем руководитель, который смотрит мутным взглядом, когда пытаешься ответить на его вопрос.
  • Не прогибаться под любым давлением: корпоративная политика однозначно входит в сферу ответственности менеджера. Пожалуйста, представляйте интересы команды на совесть.

Учитывая мнение разработчиков, руководство должно отказаться от следующих практик, которые плохо приспособлены для проектов, связанных с ПО:

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

Что за группы, генерирующие идеи?
Это структуры внутри компании, которым поручается придумывать новые продукты и новый функционал. Затем их идеи передаются на реализацию другой группе. Во многих компаниях за этот круг задач отвечают менеджеры продуктов.

В команде iiSM.ORG бытует мнение, что ПО меняет в жизни, работе и развлечениях людей очень многое за счет оптимизации и автоматизации. Доля IT-предприятий среди мировых топ-компаний неуклонно растёт по экспоненте, и вскоре наш ждёт целый поток изменений, который вызовет переворот в бизнесе и видоизменит общество. Если мы правы (а я полагаю, что правы), то руководителям, работающим по старинке, придётся подстраиваться под реалии мира после цифровой трансформации. Поэтому давайте не пожалеем времени на то, чтобы донести: традиционные техники менеджмента попросту не работают применительно к разработке ПО и продержаться на них в долгосрочной перспективе невозможно.
Подробнее..

Сиджизмондо Малатеста. Психопат который смог

20.04.2021 14:21:11 | Автор: admin
Я делаю то, о чем вы мечтаете, но боитесь.
Сиджизмондо Малатеста.

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

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

И тут к вашему предводителю, с погонялом Волк (для своих) или Тиран (для чужих), прибывает посол с предложением. Волку предложение не нравится. Он убивает сопровождение посла, самого посла скручивает. Вытаскивает на плац, что бы всем было видно, ставит раком, сдирает штаны и содомирует.

Вам покажется это смешным?

Кондотьерам Волка Римини показалось. Источники единодушны все присутствующие решили, что эта хохма удалась.

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

Звали его его Сиджизмондо Пандольфович Малатеста.
image
Кто же этот Малатеста, без своего бронекостюма? Не много ни мало, как антихрист, безумный распутник и выдающийся убийца. Человек прожил интересную и насыщенную жизнь, умудрившись выделиться даже на фоне кровавого и золотого конфетти Ренессанса.

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

О покойнике плохо нельзя, но тут особый случай. Хотя, все что о нем можно было сказать плохого, уже сказали еще при его жизни. Правда многие говоруны после этого очень быстро умерли. Строго говоря, почти единственный кто смог сказать Малатесте пару гадостей и остаться в живых Папа Римский, хотя тут надо упомянуть несколько нюансов, включающих место имения (если вы понимаете о чем я).

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

Родился Сиджизмондо в 1417 году, в городке Бреши. Папа у Малатеста был Пандольфо III и, что ожидаемо, тоже Малатеста. Он правил городком Фано и был, разумеется, кондотьером. Почему разумеется? Ну время такое. Надо понимать что Италия того времени представляла собой довольно мутное образование. Да собственно, если уж смотреть правде в лицо, как страна Италия оформилась только при Бенито Муссолини. А уж тогда, в 1400-е, итальянцы даже и не пытались. После развала Римской Империи, Италия Рима, бывший центр, медленно скатывалась, пока наконец не превратилась в Италию Ренессанса. Десятки, а может и сотни местечковых образований, некоторые независимые лишь формально, другие независимые по факту, преследовали свои цели, грабили соседей, объединялись против крупных врагов, и рвали на куски тех кто слабее. Посередине сидел Папа, и пытался всю эту кашу сожрать в себя. Одновременно с ним, в дело активно вмешивались две супердержавы того времени Испания и Франция. Вмешивались не только финансово и политически, но и бесстыдно вторгаясь экспедиционными корпусами.

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

В общем шел активный передел собственности, и прав был тот у кого была сила. Или наоборот.

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

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

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

Однако, когда в Италию вторглись Испанцы, дать им бой решился только Малатеста. И что удивительно победил.

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

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

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

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

Зато на почве внезапных религиозных разногласий с банальными католиками, Малатеста подружился с жрецами древних богов (видимо греческих, но судя по описаниям, больше похоже на слаанешистов) и прекрасным человеком по фамилии Сфорца. Тоже кондотьером, чья фамилия переводится как насиловать. Надо сразу сказать что Сфорца были строгой, благовоспитанной семьей. Даже имея сотни врагов, моральный облик семьи Сфорца в целом, как и отдельных представителей, никогда не ставился под сомнение, что несомненно редкость в те времена. Разумеется инцест, замужние любовницы которых оперативно и против воли делают вдовами, убийство племянников и прочие милые капризы у них были, ну да кто тут не без греха. (Я напоминаю, Италия, 1400-е, Ренессанс).

В процессе дружбы Малатеста отмел от Папской Области владение Римини сейчас прекрасный курортный город, надеюсь однажды там увидимся что сильно расстроило многих людей. Одно дело захватить и удерживать небольшой городок в труднодоступной местности, но захапать крупный порт?! Подобные вещи затронули всех власть предержащих либо они потеряли личные владения, либо семейные интересы через брачные союзы, либо торговые возможности. Это как если бы сейчас курды внезапно Стамбул захватили. Короче, весь мир ополчился против Сиджизмондо.

Вот тут то Папа Римский анафему с него и снял. Италия

Ну а сам Сиджизмондо разумно рассудил, что раз он решил вопрос с жилплощадью (Римини был один из крупных городов Адриатического побережья) то пора и о свадьбе подумать.

Сваты далеко от стен отойти не могли постоянно приходилось убивать агрессивных гостей, а это хоть и весело, но выматывает поэтому выбор пал на Джиневру дЭстэ, дочь правителя соседнего городка, Феррара. Джиневра, как вы наверно уже догадались, была из добропорядочной, уважаемой и богобоязненной семьи (Помните, Италия, Ренессанс).

Жили они некоторое время, да вот детей это некоторое время все не было. А потом старый кореш Сиджизмондо, тот который Франческо Сфорца, случайно упомянул в письме что у него как раз есть одна дочь. Почти что законнорожденная, кстати. Полиссеной зовут. А с разводом в то время беда. Единственный ЦОН что справки о разводе выдает собор Папы Римского в Риме. А с Папой в последний раз как-то неудобно получилось Тут то Джиневра и удавилась, потому что у неё не было детей. Удачное, конечно, совпадение.

Женился тогда наш вдовец на Поллисенне. От неземной любви, конечно.

Но за этими делами мы чуть не пропустили основное веселье. Пока, просто пару слов, для затравки.

Римини никогда не был городом снобов, но то какие оргии устраивал в нем Сиджизмондо Малатеста, заставили бы покраснеть даже опытного админа с порнохаба. Называлось это карнавал. Подберите рифму сами.

Одна маленькая деталь он покупал рабов у турков, и потом эти рабы тусили по городу одетые только в яркие краски и маски. Римини быстро стал востребованным туристическим центром.

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

Поллисенна на это все посмотрела и так как характером пошла в батю, решила взять мужа в свои крепкие женские руки.

Похоронили её рядом с Джиневрой.

Сфорца обиделись. Казалась бы пустяк, ну дочь, так ведь не прямая наследница, у тебя таких еще десяток будет но факт есть, Франческа убийство дочули не простил. Сиджизмондо на претензии ответил крайне нецензурно. Ну вы же знаете этих Итальянских герцогов эпохи Ренесанса они ж прямо как русские. Сфорца орал что-то там про: Да я эту самку собаки в анальное отверстие содомирую!. Только на итальянском и руками размахивая.

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

Но об изящной словесности не будем. Надо только отметить что адский замес из крови и золота, который потом назовут Итальянским Ренессансом, еще не раз поставит Сфорца и Малатеста по одну сторону поля битвы. Но это не меняет того факта что с этого момента Сфорца опасные и сильные враги молодого Тирана Римини.

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

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

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

Тем временем, город Римини под мудрым руководством нашего психопата процветал и это не шутка. Он процветал во многих смыслах, но производил наибольшее впечатление своим карнавалом.
Карнавал Римини очень трудно описать

Трансы тайланда? Двенадцатилетние девственницы конго? По сравнению с тем что вы могли встретить на карнавале Римини это как фотография с женского журнала мод 1930-х, против жизни Хью Хефнера.
Понятие секстуризм тогда не было, но вполне могло бы и появиться.
А карнавал мог длиться полгода.
Это действительно забавно, ведь Малатеста (кстати, с итальянского его фамилию можно перевести как Больноголовый) был из очень приличной семьи. Ну серьезно, порывшись в источниках, нашел только Джовани Малатеста, жившего задолго до нашего героя, однажды убивший жену с любовником. Тут бы и говорить было не о чем Италия. Мы бы даже никогда не узнали о подобном мелком инциденте, если бы не заметная деталь он отрубил обоим голову одним ударом. А так, нао семью Малатеста никакого компромата только слухи. На фоне тех же Сфорца, семья Малатеста смотрятся, как я уже говорил, тихонями. Ну да, мама Малатесты, как говорили, крала детей и жарила их в каком-то подземном логове но давайте не будем пересказывать сплетни.

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

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

А тут еще Тиран Римини. Поставьте себя на место Пия перед вами лебезят герцоги, преклоняют колени короли, даже императоры ищут вашей дружбы! А тут мелко чл феодал некрупного города, делает заявления в том смысле, что 10 заповедей это мало, и нарушать их скучно, и он (Малатеста) придумал еще пару десятков, которые изобретательнее и нарушить которые нужно еще суметь. И разумеется, Сиджизмондо смог.
Пий II конечно гневно обличал гадкого Малатеста, одновременно обогащая лексикон Святой Церкви. Банальных насильник, убийца жен, отравитель, еретик, фальшивомонетчик, богохульник, язычник остро не хватало, появились некрофил, содомит и конечно гражданин ада. Последнее Малатесте понравилось.
Небольшая цитата лично от Пия II:

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

Короче терпение людское, божье, а главное Папы Римского кончилось. И вместо крестового похода на Османов, он начал крестовый поход на мерзкого еретика, который уже год нагло портящего имидж Святого Престола одним своим существованием рядом с самим Римом.

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

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

Папа сильно поторопился со сроками. Это потом заметно подгадило ему жизнь. Но ничему история политиков не учит.

Так как Малатеста на суд предусмотрительно не явился, а спецоперация по его захвату позорно провалилась (не смогли найти исполнителей), дело решили поправить по старой Итальянской методике. Опустошительной войной.

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

Слово замотивирован тогда не было, но подозреваю что наемники Святого Престола очень похоже объясняли поведение солдат Малатесты. Внезапно выяснилось что граждане Римини и наемники Волка готовы не только убивать но и умирать. А вот контрактники Святого Престола и остальных Великих Государей не очень.
Поход кончился ничем. Нет, конечно Малатеста извинился, и даже отдал какие-то никому не нужные церковные земли, но это была победа абсолютно не равнозначная затраченным усилиям. Святое войско развалилось, и начало грабить все подряд, Италия в очередной раз провалилась в кровавую яму междоусобной резни, а Малатеста по этому поводу отпускал едкие шутки.

Он искренне раскаялся в перерыве между пьянкой и оргией, и с этим известием отправил в Рим посла. Папа выслушал посланца, который объяснил престарелому понтифику, что король (!), раскаялся в своих грехах (!) и сейчас замаливает их в возведенном в честь Господа храме. Последняя шутеечка требует пояснения храм в Римини Малатеста действительно построил. Tempio Malatestiano, до сих пор стоит в Римини. Но по утверждению самого Папы, то что происходило в святых стенах, было скорее филиалом языческих дионисий, чем богослужениями. На картинке тот самый католический храм в Римини.
image

Вам показалось что он слегка напоминает греческие языческие храмы? Так вот, вам не показалось.
Папа был в ярости. И не только он. В Римини зачастили убийцы и отравители, но Малатесту словно и в самом деле защищал сам дьявол.

Тем временем Венецианцы не особо лезли в дела Италии, они искали счастья (читай денег) за морем. И там им сильно мешали Османы. Назревал хороший вариант отбить Грецию у проклятых Турков и освободить бедных христиан, одновременно засадив причудливый венецианский торговый интерес прямо в самую нежную часть торговых коммуникаций всего исламского мира. Венецианцы были не дураки попиратствовать, но остро не хватало баз для флота. Турки врагом были опасным и трудным, командующий против них требовался хороший. Разумеется, лучшим выбором стал Малатеста, которого не могли сковырнуть с лица Италии всей кодлой уже много лет.

Тирану Римини как раз в тот момент стало скучно. Поэтому он согласился.

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

Это Италия, сеньоры.

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

Тем более что за всеми этими войнами я забыл сказать о самом главном о прекрасной принцессе пленившей черное сердце Сиджизмондо.

Она была юна, кротка и прекрасна. Ее звали Изотта

Первый раз он изнасиловал ее, когда ей было девять, но это было походя и только со временем он распробовал и втянулся. За муж она не хотела, помня историю первых двух жен, но он настоял. Женой она была отменной всегда отпускала его посидеть с друзьями, и, надо думать, не ругалась если он задержится допоздна.

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

Но лично я думаю, что Сиджизмондо, как и большинство мужчин, не особенно вникал в женские косметические процедуры. Позже Изотта умерла, Сиджизмондо похоронил её в соборе Римини сделав изумительной красоты надгробие. Вот оно. Там есть надпись Божественной Изотте.
image
Рассказ о Малатеста будет не полным, если не упомянуть что Малатеста был поборником красоты во всех проявлениях. Он щедро жертвовал поэтам, собирал при дворе ученых, не скупился на приобретения предметов искусства. В этом от него не отставало более примитивное в желаниях, но куда более кровавое чудовище Франческо Сфорца, и многие, многие другие ужасающие порождения своего времени. Именно эта мода и положила начало Эпохе Возрождения, а прикормленные на кровавые деньги интеллектуалы, смогли со временем внедрить в сознание людей идеи гуманизма.

Вообще, надо всегда помнить о второй стороне медали.

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

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

Так вот, Малатеста добился того, что крик Я из Римини! действительно отпугивал мародеров и грабителей. Потому что с высокой долей вероятности, за ущемление своих подданных, он мог найти виновных и покарать. Покарать по всякому, с изысками.

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

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

И история правления Волка Римини жутковатое тому подтверждение.

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

Вернемся к нашему герою, он как раз умер.

В возрасте 51 года, в своем дворце. Конечно рановато, но при его образе жизни И знаете что? Его не отравил яд убийцы, не сразила пуля в бою. Он тихо и без мучений скончался в роскоши и неге.

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

Так жил и умер Сиджизмондо Малатеста человек душу которого жгли темные страсти, и который делал то, чего желал.
Подробнее..

Боли менеджера. Обсудим опыт, факапы и успехи в секции Product на DUMP-2021

08.04.2021 14:12:31 | Автор: admin

Начинаем рассказывать детали про секции DUMP. Встречайте впервые на конференции будет отдельная секция Product.

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

Поэтому у нас появилась отдельная большая секция - 8 спикеров, 320 минут концентрированной пользы (с перерывами, конечно :) и общением.

О чем мы будем говорить?

  • О продуктовых компетенциях: какие хардскиллы и софтскиллы нужны продактам (и продуктовым командам!) в зависимости от целей

  • Об инструментах, которые помогают продактам в их работе: быстро и качественно проверять гипотезы, доносить ценность до пользователей и зарабатывать много денег (зачеркнуто) приносить им счастье

  • Про глобальное развитие продукта: выход на новые ниши, расширение географии и все вопросы, подводные камни и тонкости, которые с этим связаны. Здесь конечно ждем интересные факап-истории, но и истории успеха будут обязательно

  • Поговорим и про тренды. Про поколения Z и А - вы задумывались о них? А продукты для них создаете? А планируете? Это не просто абстрактные вопросы, это интересная тенденция развития рынков, о которой стоит подумать уже сейчас, чтобы через несколько лет быть на коне. Инсайты гарантированы!

Для кого эта секция?

Для всех, кто развивает продукт!

Это продуктовые/бизнес аналитики, продакты и те кто хочет им стать, менеджеры по развитию продуктов, product owner'ы, владельцы собственного бизнеса или носители стартаперских идей. Полезно и интересно будет всем!

Нам самим уже не терпится послушать выступления и задать вопросы.

Билеты на офлайн и онлайн уже на сайте!

Присоединяйся к DUMP-2021!

Подробнее..

Как масштабировать разработку при 400 000 RPM и не надорваться

04.06.2021 16:20:58 | Автор: admin
Если бизнес идет вверх, тозапросы инагрузка наразработку увеличиваются вразы. Рано или поздно каждый управленец сталкивается свыбором издвух крайностей: встать насторону бизнеса, двигать продукт идемотивировать разработчиков бесконечным техдолгом или дать свободу разработке ипотерять контроль над задачами бизнеса.

Mindbox 15лет развивает B2B-продукт ивырос с3до70человек вразработке. Мытестировали разные подходы кмасштабированию иготовы поделиться опытом, чтобы вам непришлось наступать натеже грабли. Ниже расскажу, как попробовали полную автономию команд ицентрализацию, роняли надежность, демотивировали команды, как врезультате сэтим справились ивыработали свою систему масштабирования.

По материалам выступления на Agile Days 2021:



Надежность как ядро разработки


Чтобы оценить, окаких масштабах разработки инагрузке пойдет речь, расскажу оразмере компании.

ВMindbox одна изсамых нагруженных разработок вРоссии, нопри этом она сохраняет высокую надежность. Когда покупатель пробивает чек накассе вБургер Кинге или аптеке Ригла, транзакция идет кнам. За200 миллисекунд мырассчитываем суммы иотвечаем кассе. Если сервис упал, томного людей повсей стране 24/7 становятся несчастны.

Запоследние 34 года бизнес растет по4050% вгод инагрузка удваивается ежегодно. Внешне всё отлично, ноуMindbox был длинный период становления, который влиял намасштабирование разработки.

Масштаб бизнеса и разработки




Эволюция разработки




Как работает автономия ицентрализация разработки


Проблема масштабирования разработки сводится кпоиску баланса между автономией ицентрализацией. Есть две организационные крайности:

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

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

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

Как внедрили автономию


С2007 по2013 год было мало клиентов ибизнес рос медленно, потому что писали большой исложный продукт. При этом управление разработкой было простым: один главный бизнес-эксперт иглавный архитектор это я и34команды. Делал статусы раз внеделю, потом раз вдве недели ходил покомандам эффективно илегко.

Дали автономию командам. Постепенно бизнес стал прибавлять по4050% вгод, поэтому нужно было запускать больше продуктов ипродвигаться быстрее. Втоже время мыначали строить бирюзовую культуру, прочитали книгу Лалу ирешили, что нужны автономные продуктовые команды сменеджерами продуктов. Иэто заработало запустили новые продукты.

Бирюзовая компания вРоссии: открытые зарплаты, самоуправление, прозрачность иошибки
Фредерик Лалу: Открывая организации будущего

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

Уронили надежность. Потом появились нюансы. Большинство наших клиентов изe-commerce, поэтому проводят черную пятницу большую распродажу вконце года, когда унагрузки пиковое значение. Кроме этого, нагрузка ещё иудваивалась каждый год. Втакую черную пятницу сервис упал.

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

Как внедрили централизацию


Централизовали управление. Прочитали книгу оLeSS (Large Scale Scrum), сходили натренинг ирешили централизовать разработку: внедрить общий roadmap, единое управление иразгрумить эпик надежности.

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

Внедрили LeSS ироль CTO. Надежность разово починили, ноостался монолит на2миллиона строк кода. Несмотря наточто мыцентрализованно внедрили roadmap ивкаждой команде работали эксперты поинфраструктуре, техдолг ипроблема корневой надежности децентрализованно нерешались.

Так мысоздали роль CTO (chief technical officer), хотя доэтого небыло менеджмента, отвели30% ресурса натехдолг ивнедрили LeSS. Это значит, что70% разработчиков занимались roadmap бизнеса, а30% техническим roadmap, который определяет CTO. Врезультате техдолг начал сокращаться, имыувидели положительные изменения.

LeSS Scrum набольших масштабах

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

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

Главное, что год мыпрожили врежиме LeSS изаметили негативные эффекты для компании. Инженеры именеджеры попродукту были демотивированы. Уинженеров небыло домена ичувства собственности, как увавтономных команд: три месяца они работали над одним продуктом, потом три месяца над другим. Менеджеры попродукту загрустили, потому что roadmap планируется централизованно иtime tomarket стал огромным. Нельзя было взять ивнедрить небольшую доработку для клиента, потому что roadmap управляют централизованно.

Как нашли баланс между автономией ицентрализацией


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

Вернули команду инфраструктурной платформы. Фактически инфраструктура это тоже внутренний продукт, аCTO выполняет роль менеджера попродукту, поэтому выделили отдельную команду под инфраструктуру.

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

Оставили30% ресурса команды налокальный техдолг. Мыдоговорились одвухуровневом разделении. Наверхнем уровне30% всего ресурса разработки отдали CTO наинфраструктурную команду итехнический roadmap. Ещё30% отдали натехдолг, который приоритезирует команда. Фактически смомента, когда начались проблемы снадежностью имасштабированием, почти50% всего ресурса это технические задачи.

Техдолг ~30% платформы и 30% команды


около 50% в целом



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

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


Из LeSS оставили кросс-командный рефайнмент, чтобы снять риск монолита и управлять roadmap

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

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

Нарушения SLA среднего клиента вмесяц надежность повышается




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

Создали роль Scrum-мастера. После того как разобрались срисками вдецентрализованном roadmap, справились стехдолгом инадежностью, решили повышать эффективность разработки. Для этого создали роль Scrum-мастера, который собирает весь опыт разработки (developer experience) изаносит вспециальную форму все препятствия ипричины, мешающие разработке. Потом поаналогии состатусами понадежности Scrum-мастера централизованно обсуждают сCTO задачи замесяц, приоритезируют ихичасть добавляют втехдолг.

Создали круги управления. Чтобы комплексно управлять общими аспектами разработки, мыорганизовали виртуальную команду, или круг управления, представители которого сидят вразных командах. Уэтого круга есть набор ритуалов, которые собраны надоске вTrello: встречи побюджету, демонстрации продукта или найму. Такое кросс-командное общение помогает сфокусироваться накаждом процессе инатом, как его улучшить вовсех командах сразу.

Виртуальная команда (круг) управления




Ритуалы управления



Круг управления помогает аккумулировать кросс-командные аспекты: надежность, стоимость железа, найм, developer experience. Для этого проводятся встречи ритуалы управления


Определили метрики разработки. Пока мымасштабировали разработку, нас волновал один вопрос: какие метрики позволяют оценить разработку ичто нужно оптимизировать. Это было неочевидно.

Мызнали, что скорость иroadmap нельзя измерять, потому что есть проблемы стехдолгом иэто только демотивирует разработчиков. Науровне стратегии разработки мысформулировали, что цель разработки оптимизировать непрерывный запуск продуктов (time tomarket) врамках ограничений надежности, стоимости железа ибез увеличения технического долга. Ировно такиеже ожидания сформировали для команды. Команда должна непрерывно поставлять фичи, увеличивать time tomarket, нопри этом поддерживать определенные обязательства понадежности, SLA истоимости.

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

Показатель эффективности


врамках SLA, стоимости железа ибез увеличения техдолга
Разработка Команда
Непрерывный запуск и оптимизация time to market новых продуктов, которыми можно гордиться Непрерывный релиз и оптимизация time to market инкрементов, которые принял клиент на продакшене


Какую выработали систему масштабирования разработки


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

Разумное регулирование общего. Как ядро оставили общие задачи, над которыми должны работать централизованно: roadmap монолита, надежность иинфраструктура, стоимость железа иdeveloper experience. Если нет общих знаний отом, как создаются базовые вещи, топеремещение разработчиков между командами будет затруднено, код будет дублироваться иесть риск потерять эффект масштабной разработки, когда каждая команда существует изолированно отвсех.
Подробнее..

Перевод Никаких митингов, дедлайнов и сотрудников на полную ставку

06.05.2021 12:20:25 | Автор: admin

Я основал компанию Gumroad в 2011 году. В 2015 году у нас было рекордное количество людей - 23 штатных сотрудника с полной занятостью. В 2016 году, после неудачной попытки поиска финансирования, я вернулся в точку, с которой начинал. В компании снова был всего один сотрудник - я сам.

В настоящее время, когда меня спрашивают, сколько человек работает в Gumroad, я отвечаю: "десять или около того". Таким образом я перевожу число людей, которые работают в компании, в понятные другим цифры. На самом деле, все обстоит несколько сложнее:

Если посчитать всех, кто работает в Gumroad, получится 25 человек.

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

У нас нет совещаний и нет дедлайнов.

И этот подход работает: наши авторы зарабатывают более 175 миллионов долларов в год, а компания в среднем зарабатывает 11 миллионов долларов в год, и эта цифра растет каждый год в среднем на 85%.

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

Свобода любой ценой

После массовых сокращений в 2015 году компания Gumroad продолжила расти, несмотря на потери среди персонала.

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

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

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

Тем временем я переехал в Юту и пытался работать в качестве полноценного автора контента.

У меня не было цели, чтобы Gumroad стал приносить миллиарды, но зато у меня появился новый актив - время. Я использовал это время, чтобы обучаться написанию текстов и рисованию.

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

Взамен прошлой цели увеличивать прибыль любой ценой, у меня появилась новая - "свобода любой ценой".

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

Как мы работаем

На сегодняшний день работа в Gumroad похожа на работу в проекте Open Source, например, таком как Rails. За исключением того, что это не Open Source, и эта работа оплачивается.

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

Все пишут хорошо, и пишут много.

Никаких дедлайнов у нас тоже нет. Мы постепенно улучшаем сервис и выпускаем обновления, когда версия, которая находится в разработке, становится лучше, чем текущая версия. Есть исключения, например, строго установленные сроки подачи налоговых деклараций, но обычно я стараюсь не говорить никому, что им делать и с какой скоростью. Когда в компании появляется новый человек, он делает то же, что и все: заходит в наш канал в приложении Notion, берёт задачу и приступает к ее выполнению, обращаясь к коллегам за разъяснениями, если необходимо.

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

Но мы не ставим жестких рамок и приоритетов.

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

Точно таким же образом мы работаем над масштабными задачами.

В ноябре 2020 года мы запустили проект Gumroad Memberships, который действует уже год и благодаря которому сотни авторов, использующих новую систему, зарабатывают более 1 500 000 долларов в месяц.

Ниже приведен скриншот из нашей дорожной карты, чтобы показать, как это выглядит на практике:

Также я записал часовой видеоролик о том, как мы работаем над созданием такого масштабного проекта, как Gumroad Memberships.

По словам разработчика Gumroad Хелен Худ, которая работала над созданием Memberships: "Это был один из самых масштабных запусков продукта за всю мою карьеру, и мы сделали этот проект без единого митинга или видеозвонка. У меня есть опыт работы в обычном стартапе с известной всем корпоративной культурой - открытый офис без дверей, множество белых досок, стендап-митинги и планирование спринта, пиво с коллегами после работы. Также у меня был проект, где все работали удаленно, было мало коммуникации, и программисты в основном работали каждый над своей задачей, они не были одной командой. Для меня то, как мы работаем в Gumroad - это идеально. Это позволяет мне с максимальной пользой использовать часы, когда я продуктивна, и заканчивать работу, когда я достигла своего предела".

Это весьма краткое описание, но мы опубликовали еще несколько статей, в которых подробно описано, как мы работаем:

  • Как мы решаем, над чем работать? "И конечно, нельзя не отметить, что в Gumroad вкладывается очень много эмоций, этим он ничем не отличается от других арт-проектов. Иногда мы выбираем то, что интересно и над чем нам нравится работать! Мы любим прислушиваться к авторам! Мы никогда не проводим масштабный анализ данных, чтобы решить, над чем стоит работать дальше".

  • Как мы общаемся? "Отключите все уведомления в телефоне!"

  • На что похожа работа в Gumroad?

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

  • Есть ли негативная сторона у работы в Gumroad? "В компании не так уж много возможностей для роста. Компания приносит доход, и мы не планируем увеличивать команду каждый год и набирать много людей. Хотя у нас скорее всего и будут руководящие должности, их немного, и они не являются ступенькой какой-либо внутренней карьерной лестницы, по которой мог бы двигаться сотрудник Gumroad".

Сотрудник Gumroad Крис Максимин сообщает: "Этот принцип работы позволил мне достичь наибольшей продуктивности, которая у меня когда-либо была. Возможность сконцентрироваться только на работе и на том, что действительно важно, создает благоприятный цикл взаимодействия, который приносит положительные результаты и компании, и сотрудникам: 1) компании не нужно платить огромные зарплаты программистам за то, что они часами сидят на бесконечных и бесполезных митингах, и 2) программисты могут сделать больше задач и научиться многим вещам, что принесет им огромную пользу в долговременной перспективе".

И так работают не только программисты.

Джастин Миколай, занимающийся написанием текстов в Gumroad, точно так же работает над каждой публикацией Creator Spotlights, хотя над каждой статьей трудятся минимум три человека, плюс создатель контента.

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

Мы не можем конкурировать с другими крупными компаниями

Такой способ работы не для всех.

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

Но мы можем конкурировать (и выигрывать!) за счет нашей гибкости.

Сид Ядав, ранее занимавший должность вице-президента по продукту в компании Teachable, стал частью команды Gumroad в 2018 году.

По его словам: "У большинства предпринимателей есть два варианта: они могут работать на полной ставке, а своим делом заниматься по вечерам или на выходных, или уйти с работы и рискнуть всем, чтобы основать свою компанию. Gumroad предлагает третий вариант: я могу работать на договорной основе 20-35 часов в неделю, или пару дней в неделю, воплощать свои идеи и затем работать над своим следующим проектом".

В 2020 году Сид ушел из компании и вместе со своим бывшим коллегой из Gumroad Руди Сантино основал свою собственную компанию Circle, которая также предоставляет площадку, где авторы могут продавать свои работы и услуги.

Я основал новую компанию: cycle.so! В течение следующих недель я подробнее расскажу о ней, но сегодня я хотел бы выразить благодарность тем жизненным обстоятельствам, благодаря которым это стало возможным - это моя работа на гибком удаленном проекте @gumroad. Без Gumroad мне бы не удалось достичь этого.Я основал новую компанию: cycle.so! В течение следующих недель я подробнее расскажу о ней, но сегодня я хотел бы выразить благодарность тем жизненным обстоятельствам, благодаря которым это стало возможным - это моя работа на гибком удаленном проекте @gumroad. Без Gumroad мне бы не удалось достичь этого.

Работа в Gumroad не является ни для кого главным приоритетом и основным способом самореализации.

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

Программист Нэйтан Чан, работающий в Gumroad, рассказывает: "За всю мою карьеру именно здесь у меня значительно больше времени для по-настоящему важных вещей в жизни, чем у меня было, когда я работал в других компаниях. Я могу полноценно участвовать в воспитании своих детей и смотреть, как они растут".

Я тоже разделяю эту точку зрения.

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

Компания авторов контента

Однажды совершенно неожиданно я получил электронное письмо от Дэниела Вассалло. Я знал Дэниела; он является автором, который меньше чем за год заработал в Gumroad более 250 000 долларов.

Он был пользователем нашего сервиса, так что имел представление о том, какие задачи стоят перед компанией Gumroad и что необходимо улучшить, и у него было несколько идей о том, как он мог бы в этом помочь:

Я люблю Gumroad (и я зарабатываю себе на жизнь с его помощью!), мне нравится заниматься разработкой стратегий и постановкой задач. Думаю, я мог бы заниматься проект-менеджментом в Gumroad. В среднем я мог бы уделять этой работе всего 2 часа в день, но я буду доступен каждый день. Не знаю, готовы ли вы пойти на такие условия, но я подумал, что если кто-то и может на такое согласиться, то это Gumroad :)

Он подходил нам идеально. Дэниел стал нашим новым менеджером по продукту.

Для Gumroad это тоже было выгодным предложением. До того, как Дэниел ушел из компании Amazon, он зарабатывал более 400 000 долларов в год. Мы же платим ему 120 000 долларов в год.

Как это возможно? У нас он работает 10 часов в неделю. По его словам:

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

Зарплаты

Фактически у нас почасовая оплата для всех сотрудников, и размер ставки зависит от занимаемой должности. Зарплаты варьируются от 50 долларов (специалист поддержки) до 250 долларов (менеджер по продукту) в час.

Недавно я установил стандартные зарплаты для локаций по всему миру:

С радостью сообщаем, что мы зарплаты в Gumroad больше не зависят от местоположения сотрудников! Теперь Gumroad будет платить всем равные зарплаты, неважно, живете ли вы в Сан-Франциско, Бангалоре, Лагосе, или в любой другой локации.С радостью сообщаем, что мы зарплаты в Gumroad больше не зависят от местоположения сотрудников! Теперь Gumroad будет платить всем равные зарплаты, неважно, живете ли вы в Сан-Франциско, Бангалоре, Лагосе, или в любой другой локации.

Зарплата обсуждается во время прохождения собеседования:

  1. Подача заявки через форму.

  2. Неоплачиваемое тестовое задание на несколько часов, которое похоже на одну из сложных задач, над которыми мы работаем в Gumroad. Задание может включать в себя разделение большого проекта (как Gumroad Memberships) на мелкие подзадачи, планирование схемы для нового функционала, или написание статьи для центра справки и поддержки.

  3. Оплачиваемый испытательный срок длительностью в несколько недель, который напоминает ежедневную работу, которой мы занимаемся в Gumroad. Он может включать в себя устранение багов, работу над новым функционалом или работу в службе поддержки.

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

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

Больше нет никаких бонусов, за исключением гибкости и зарплаты.

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

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

После того, как Дэниел присоединился к нашей команде и стал менеджером по продукту, работая на четверть ставки, с нами также стала работать Рэндалл Калла, заняв должность комьюнити-менеджера на четверть ставки, а Филип Кьели стал менеджером по маркетингу на четверть ставки. Все они также являются успешными авторами в Gumroad.

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

Именно такой должна быть работа в экономике творчества.

Будущее работы в том, чтобы не работать

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

Никто не согласился.

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

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

На главной странице Gumroad перечислены преимущества, которые есть у авторов, которые пользуются платформой: "Избавьтесь от офисной работы с 9 до 5. Снимите костюм и галстук. Больше никаких поездок на работу. Зарабатывайте на своем творчестве".

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

Познакомьтесь с командой Gumroad:

Благодаря Интернету сейчас появляются новые способы работы, мы только начинаем их открывать. Есть много других способов и форматов работы. Выбранный нами - всего лишь один из вариантов.

Подробнее..

Смысл стараться? или пагубные следствия недостатка похвалы

10.05.2021 00:07:48 | Автор: admin

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

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

Смысл стараться?

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

Когда компания, в лице руководителя, не замечает и не признает успехов, это приводит к таким последствиям:

1) Сотрудники не видят смысл повторять те действия, которые привели к сверхрезультату

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

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

2) Лучшие сотрудники получают демотивационный разряд

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

3) Обычные сотрудники не видят смысл подтягиваться к уровню результатов лучших сотрудников

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

Почему руководители недостаточно хвалят сотрудников?

1) Не считают это нужным

К сожалению, несмотря на состояние рынка труда, боссы продолжают жить в парадигме: Это их работа, они за нее деньги получают. Да, это "их работа", но они ее могут делать по-разному. Можно просто выполнять указания (что сказали - то и сделал), а можно: помогать, подсказывать, показывать недочеты, предлагать новые решения, влиять на процесс и результаты, проявлять инициативу,... . Это тоже входит в их работу?

2) Стесняются

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

3) Бояться, чтобы сотрудники не возомнили о себе много и не попросили больше денег

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

Да, такой расклад возможен. Но, возможен при условии, что сотрудник, либо не понимает ценообразования оплаты своей позиции, либо вы ему реально недоплачиваете (по рыночным расценкам), либо он неадекватен. Если сотрудник не понимает ценообразования - объясните, если вы ему недоплачиваете - доплатите, если неадекватен - поступите, как считаете правильным. Но, независимо от ситуации, вам нужно что-то предпринять, иначе он уйдет.

О нематериальном аспекте

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

Если мы не можем платить больше?

Допустим, что, все-таки, вы недоплачиваете сотруднику, и вы оба об этом знаете. В таком случае, у вас есть три варианта:

1) Ничего не предпринимать и всячески уходить от обсуждения этого вопроса

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

2) Почаще ругать, поменьше хвалить

Можно пойти по стандартному пути: почаще ругать и поменьше хвалить. Тогда, возможно, сотрудник подумает, что он не такой классный и не захочет уйти.

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

3) Разделить вопросы вознаграждения и поощрения

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

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

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

P.S. Для любителей решать материальные проблемы - морально. По-хорошему, понятия оклад и похвала лежат в разных плоскостях и не должны замыкаться друг другом. Если сотрудник старается - он должен быть похвален, если сотрудник недополучает - ему нужно доплачивать. Попытка решать материальные проблемы путем воздействия на нематериальные факторы достаточно краткосрочна. Как говорится: спасибо на хлеб не намажешь и огурчиком не закусишь.

Больше полезностей находите в telegram-канале

Подробнее..

Что делать если ценный сотрудник опаздывает?

03.06.2021 10:20:31 | Автор: admin
image

Уточнение:

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


________________________________________________

Что для вас означает термин опоздание?


Для начала стоит разобраться с правилом, которое было нарушено. Итак, требование приходить на работу вовремя это ваша шалость, система или обоснованная необходимость?

Если результативность сотрудника никак не зависит от времени прихода на работу, и компания никак не пострадает от свободного графика посещения, стоит ли на этом аспекте останавливать внимание? Хороший вопрос, на который вам нужно найти ответ.

Если все же для требования есть обоснования идем дальше
________________________________________________

Что для вас означает термин ценный сотрудник?


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

Почему он опаздывает?


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

К примеру, в моей практике было два сотрудника, причины регулярных опозданий которых я считаю объективными и стоящими:

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

2) Сотрудница хотела завтракать вместе с мужем и ехать на работу вместе с ним. Но, так как у ее мужа был более свободный график, он не спешил, и она из-за него опаздывала.

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

Возможно вы сами спровоцировали сотрудника опаздывать?

Так, если в компании не было правила приходить вовремя, все приходили и приходят, как хотят, виноват ли сотрудник в его опоздании? Несомненно, его вина есть, но стоит ли начинать решение проблемы именно с его персоны.

Лирическое отступление

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

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

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


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

При таком подходе руководителя могут посетить такие опасения:

1) Имею ли я на это полномочия?


Я считаю, что руководитель имеет полный объем полномочий на определение условий сотрудничества со своими подчиненными. Он имеет право определять, кто и когда должен приходить на работу, кому и какое задание поручать, кого и чему обучать/развивать, . Если у него таких полномочий нет такой руководитель является неполноценным и не может на 100% нести ответственность за результаты вверенных сотрудников и структуры в целом.

Поэтому, если вы руководитель и вас терзает сомнение могу ли я это решать, ответ можете (если вам это прямо не запрещено).

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

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

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

2) Остальные обидятся, что ему можно, а им нельзя...


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

После того, как было принято решение об индивидуальных условиях одного из сотрудников, вам нужно провести небольшое информационное собрание, на котором вы:

объявите об этом решении;

объясните причины;

объясните вашу логику.

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

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

3) Остальные также захотят опаздывать...


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

К примеру, у меня работал сотрудник, который всегда опаздывал и просто не мог не опоздать. Попытка сдвинуть график его работы на +1 час (начало рабочего дня сделать не в 9, а в 10) ни к чему не привела он все равно опаздывал на стандартные для него 5-15 минут. Тогда, я пошел на более гибкий подход. Я ввел для сотрудника график отработки нужного количества часов и лишил его необходимости опаздывать (его функционал это позволял). Он мог прийти в любое время, но должен был отработать ровно 8 часов (плюс час обеда). Это сработало, вопрос был решен. И, что самое интересное, сотрудник начал приходить раньше, так как перспектива сидеть допоздна его не очень радовала.
________________________________________________

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

Другие кейсы находите в моем telegram-канале: t.me/OS_management

Подписывайтесь! Далее будет
Подробнее..

Фактор демотивации 2 Расхождение по фундаментальным ценностям

07.06.2021 10:04:02 | Автор: admin

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

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

Несмотря на всю качественную подготовку, план не выполнялся практически ни в одной торговой точке. Тогда в работу пошли классические методы давления на персонал. Результата это не принесло. Люди, как и раньше, не делали кросс-продажи всем клиентам. В добавок ко всему, начались массовые увольнения.

Руководство задумалось и начало анализировать ситуацию. Оказалось, что фармацевты не хотят делать кросс-продажи, так как они это считают морально неправильным и даже бесчеловечным. Они говорили: Основная масса наших клиентов - пенсионеры, мамочки и далеко не богатые люди. У большинства из них нет денег на то, чтобы купить все лекарства (они вместо пачки берут пластинку, потому что сразу не могут заплатить за пачку). И мы всем им должны впаривать сомнительные витамины?

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

Увольнения закончились, продажи пошли в гору

________________________________________________

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

  • любовь;

  • семья;

  • дружба;

  • честность;

  • понимание;

  • уважение;

  • толерантность;

  • терпение;

  • прощение;

  • благодарность;

  • сострадание.

Все эти ценности можно объединить в одно понятие - мораль.

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

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

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

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

________________________________________________

Когда возникают ситуации с расхождением по ценностям:

1) Целенаправленное решение руководителей

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

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

2) Ошибка рекрутера

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

3) Не подумали об этом

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

4) Не объяснили сотрудникам

Когда в компании реально продается вредный продукт или используются вредные алгоритмы его производства, тогда у сотрудников возникает естественное сопротивление на уровне морали. Оно обосновано. Но, ведь бывают еще ситуации, когда сотрудники думает, что продукт вреден, а на самом деле это не так. Например, он не мог не до конца разобраться в вопросе или ему кто-то неправильно обьяснил или ему так показалось . Сотрудник сам себя накрутил. В таком случае, получается самый печальный вариант: сотрудник необоснованно считает компанию некорректной и аморальной.

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

________________________________________________

Итоги

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

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

Продолжение серии кейсов о демотивации и другие кейсы о менеджменте находите в telegram-канале: https://t.me/OS_management

Подписывайтесь! Далее будет...

Подробнее..

8 последствий переработок руководителя

09.06.2021 12:21:23 | Автор: admin
image

Как вы охарактеризуете руководителя, который работает не 8-9 часов, а 11-12? Это хорошо и можно его назвать вовлеченным, или есть нюансы?

Надеюсь перед ответом на эти вопросы вы немного задумались и не спешили отвечать. На самом деле, действительно есть нюансы и нет единого правильного ответа.

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

________________________________________________

Возможные последствия переработок руководителя:



1. Усталость и выгорание



Логичным следствием регулярных переработок является усталость. И, не столько физическая, сколько моральная и умственная. Когда руководитель работает по 12-14 часов, его мозг устает, и на следующий день долго запускается и в течении дня сильно тормозит. От чего руководитель может: упускать важные детали, принимать не оптимальные решения, допускать ошибки, говорить глупости, резко реагировать на ошибки сотрудников, .

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

2. Лишние расходы компании



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

Чтобы было проще понять, разберем на примере:

Вводные

Задание: посчитать, сколько осталось в наличии винтовых гвоздей.
Ориентировочная продолжительность выполнения: 4 часа
Тариф руководителя: 10$/час
Тариф сотрудника: 5$/час

Моделируем ситуацию

Руководителю приходит такое задание. Он, глянув на своих сотрудников и на их серьезный вид, делает вывод, что все заняты, и решает взять это задание на себя. Плюс ко всему, он уверен, что никто лучше него с этим не справится и он сможет сделать его быстрее и качественнее. На выходе так и получается: руководитель выполняет задание за 3 часа (на час быстрее). Но, действительно ли это победа для компании? Подобьем итоги:

  • задание выполнено быстрее и обошлось в 30$. При этом, даже, если бы оно было выполнено за 4 часа, оно было-бы дешевле 20$. Даже, если бы за 5 часов это было бы 25$, что, также, дешевле;
  • компания сэкономила 3 часа работы штатного сотрудника, при этом потеряла 3 часа работы руководителя (более квалифицированного и более важного).


Не утверждаю, что подобная математика это всегда правильно. Иногда выгоднее потратить время руководителя, чем время сотрудника. Особенно, если сотрудник работает над уникальным проектом, его нельзя отрывать и его никто заменить не может. Но, всегда ли это так?

3. Не успевает выполнять свои обязанности, которые более сложны



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

Часто такой работой становится именно управленческая функция: планирование, делегирование, контроль,. Руководитель не успевает проводить анализ достижения целей подразделения, руководитель не успевает вырабатывать решения по нейтрализации отклонений, руководитель не успевает проводить профилактические мероприятия для недопущения отклонений. Сотрудники такого руководителя недосмотрены, недохвалены, недообучены. Ему некогда!

Как понимаете это замкнутый круг: чем больше руководитель работает руками -> тем меньше у него времени на то, чтобы обучить этой работе кого-то -> тем больше ему приходится выполнять работ самостоятельно

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

4. Разрешение быть непрофессиональным



Переработки позволяют руководителю избегать развития и практики управления. Ему не нужно учится делегировать, не нужно учиться контролировать. Зачем ему кого-то принуждать и становится плохим человеком? Можно поработать больше и сделать все самому.

Кроме того, есть же правило: хочешь сделать хорошо сделай это сам. Это еще один аргумент, почему не стоит кому-то поручать.

5. Разрешение быть неэффективным



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

6. Балованная структура



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

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

7. Демотивация



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

Когда это временная акция это терпимо. Если же это постоянная необходимость это может быть сильным фактором демотивации.

8. Игнорирование человеческого потенциала



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

Так, если руководитель не может задерживаться, он всячески будет стараться находить внутри структуры возможности. Он изучит своих сотрудников, он их будет развивать, он будет использовать их потенциал на 100%. Все для того, чтобы успеть вовремя. Его это мотивирует, чтобы находить возможности!
________________________________________________

Выводы:



1) Если ваш подчиненный руководитель и он перерабатывает разберитесь, с чем это связано.

Я выделяю три популярные причины:

  • личное желание руководителя;
  • производственная необходимость;
  • так принято.


Самая страшная причина так принято. Она означает, что в компании существует негласное правило: кто много работает тот молодец. Угадайте кто виноват в существовании такого правила?:)

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

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

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

Общий вывод:


Переработки это не плохо и не хорошо. Факт переработок просто показывает время, которое сотрудник тратит на выполнение своих функций и никак не может являться показателем его эффективности. Мы не должны ориентироваться на стереотипы перерабатывает значит молодец и вовлеченный или в 18:00 его уже нет значит ему пофиг на компанию. Нет! Увы, все намного сложнее и в каждом отдельном случае стоит покопаться в деталях. Что вам и советую регулярно делать!

Другие кейсы находите в telegram-канале: t.me/OS_management
Подписывайтесь! Далее будет
Подробнее..

Коллектив-змеюшник как фактор демотивации персонала

14.06.2021 10:08:37 | Автор: admin
image

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

________________________________________________

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

1) Адаптация сотрудника в нездоровом коллективе проходит дольше и сложнее.

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

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

2) На взаимодействие в ненормальном коллективе уходит больше времени.

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

Но главное демотивационное состояние будет отражаться во всех делах сотрудника. Пока он не уйдет
________________________________________________

Руководитель не видит проблемы



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

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

Ну и напоследок, руководитель всегда занят. Он погружен в работу и отстранен от всего мирского и житейского. И даже, если его стол находится в центре коллектива, он просто не обращает внимание на то, что происходит вокруг.
________________________________________________

Всем же рты не закроешь



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

Да, если, к примеру, мы говорим про сплетни, то всем рты закрыть невозможно. Да и не нужно пытаться это делать. При этом, можно провести такой комплекс действий:

1) Погасить зачинщиков



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

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

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

2) Отрегулировать отбор



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

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

3) Не участвовать в барделе



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

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

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

Двойных стандартов быть не должно! Если вы хотите, чтобы в компании не было сплетен или гнобления или матов, вы должны сами возненавидеть это все и всячески пресекать:

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

________________________________________________

Последствия для руководителя



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

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

________________________________________________

Всегда-ли это критично?



Существует и альтернативное мнение. Так, одна знакомая мне написала следующее: Чем хуже к тебе относятся в коллективе тем лучше!. И рассказала свою историю, как она, благодаря дебильному коллективу, смогла подняться по карьерной лестнице. Как ее мотивировал факт пренебрежения со стороны коллег и как она хотела им всем утереть нос. Это ее драйвило и она достигла успеха!

Да, бывает и такое. Но

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

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

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

Поэтому, мне все-таки кажется, что рассматривать токсичный коллектив со стороны мотивации на достижение, можно только в виде исключения.

________________________________________________

Итоги



Коллектив, как и другие рабочие инструменты, может, как увеличить эффективность сотрудника, так и уменьшить ее. Увеличит он ее в случае сплоченности и синергичного эффекта, уменьшит за счет деструктивности и конфликтов.

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

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

Продолжение серии кейсов о демотивации и другие кейсы о менеджменте находите в telegram-канале: t.me/OS_management

Подписывайтесь! Далее будет
Подробнее..

Категории

Последние комментарии

  • Имя: Макс
    24.08.2022 | 11:28
    Я разраб в IT компании, работаю на арбитражную команду. Мы работаем с приламы и сайтами, при работе замечаются постоянные баны и лаги. Пацаны посоветовали сервис по анализу исходного кода,https://app Подробнее..
  • Имя: 9055410337
    20.08.2022 | 17:41
    поможем пишите в телеграм Подробнее..
  • Имя: sabbat
    17.08.2022 | 20:42
    Охренеть.. это просто шикарная статья, феноменально круто. Большое спасибо за разбор! Надеюсь как-нибудь с тобой связаться для обсуждений чего-либо) Подробнее..
  • Имя: Мария
    09.08.2022 | 14:44
    Добрый день. Если обладаете такой информацией, то подскажите, пожалуйста, где можно найти много-много материала по Yggdrasil и его уязвимостях для написания диплома? Благодарю. Подробнее..
© 2006-2024, personeltest.ru