0 просмотренных постов скрыто
Мысли о развитии
Хочу поговорить с вами об эффективности и своем наблюдении, в первую очередь за собой.
Я описывал в своем посте о своем устройстве в IT, и там было сказано, что я работал в поддержке Яндекса, а потом в техподдержке Яндекса. Хочу обратиться к этим временам и построить на этом свою мысль.
В поддержке и техподдержке Яндекс сделал очень мудро. Он установил показатели, по достижению которых выплачивается премия, и самое главное он столкнул всех сотрудников лбами. То есть буквально был рейтинг, и чем ты выше, тем больше ты получишь премию. Люди работали, я сам садился и фигачил все 12 часов, чтобы я был выше в рейтинге (он конечно зависит еще от оценок, но общее количество тоже имеет значение). Дальше они просто показывают тебе, сколько ты заработал в реальном времени. И все это успех, появляется конкурентная среда, все сотрудники работают на премию и на рейтинг! В техподдержке было по-другому, но подобная система.
Казалось бы, причем тут IT? Да при том, ребята, айтишники зажрались, и я сейчас не про деньги, а про аджайлы и прочую дребедень. Айтишник (именно технический специалист) сейчас не слишком хочет работать, а менеджеры им в этом помогают! Нет конкурсной среды, все молодцы, все хорошо работают! Со всеми HR проведет квартальную встречу и расскажет, какие они продуктивные красавчики! И не важно, что ты работаешь 3 часа в день из 8. И самое главное, программисты, девопсы, QA и остальные привыкли к этому.
Основная мысль такова: нужна конкуренция, легкоатлеты на соревнованиях не бегут все одинаково хорошо, кто-то хуже, а кто-то лучше, и им так и говорят: "Ты пробежал хуже, ты второй, вон тот парень лучше тебя". Это мотивирует, и благодаря этому они бегают быстро, а не легкой пробежкой. Так и только так, мы будем развиваться.
Показать полностью
Agile мёртв
Автор: Алексей Александрович Самойлов
Agile продолжает шагать по стране, захватывая умы всё новых адептов и поддерживая своё влияние в головах старых. Различные компании и команды пробуют «внедрять Agile» (подход к управлению проектами) в меру своего понимания и с разной степенью успеха.
Пока в России продолжают активно издавать книги, проводить конференции, продавать обучающие курсы, сертификаты — многие и не знают, что ещё 8 лет назад один из основателей и популяризаторов этого движения заявил, что Agile мёртв.
Но кто же следит за информацией по своей теме, тем более если она только на английском языке?
Специально для уважаемых Читателей канала VIKENT.RU мы разберем основные претензии Дэйва Томаса, одного из Авторов Agile-манифеста, к тому, что сейчас из себя представляет Agile.
Исходная проблема, которая возникла в конце 90-х годов — 99% проектов разработки ПО выглядело, как борьба на баррикадах в формате «сделай или умри». Хотя это было весело, но большая часть проектов умирала.
Разработка ПО была нестабильна, и возникло очень много людей, недовольных этой ситуацией, хотя нельзя сказать, что это было единое движение. Тут и там возникало много различных инициатив, которые пытались решить накопившиеся проблемы — экстремальное программирование, адаптивная разработка ПО, концепция программиста-прагматика, методологии семейства Crystal. Scrum тоже был где-то рядом ещё с 80-х.
Поворотным событием стала встреча в снежной Юте, где несколько представителей профессии собрались обсудить сложившуюся плачевную ситуацию в мире разработки ПО. Тогда и был написан Agile-манифест.
Спустя 15 лет Дэйв Томас — один из Авторов манифеста, накопил ряд претензий к тому, во что последователи превратили исходную идею. Претензий всего 5, и давайте их разберём.
1. Существительное вместо прилагательного
Эта ошибка заявлена, как исходная, которая в дальнейшем привела к искажению понимания принципов Agile, ведь точное название манифеста «Манифест гибкой разработки программного обеспечения», а люди стали сокращать его до «Agile манифест» (гибкий манифест — прим. Алексея Александровича Самойлова)., а надо было называть хотя бы «Манифест гибкости». Agile (гибкий) — это прилагательное и все, кто употребляет его, как существительное («я занимаюсь agile») делает ошибку. Например, нельзя при продаже сказать «купите у меня немного зелёного», это не работает. Можно сказать «зелёный рисунок» или «зелёные овощи». Можно продать существительное, но нельзя продавать прилагательное.
Хотя индустрия, возникшая вокруг этого манифеста, стремится продать вам — тренинги, консалтинг, книги и конференции и у них получается сформировать запрос именно в формате «взвесьте мне килограмм agile (гибкости), пожалуйста».
Но всё даже хуже.
Самое важное для бизнеса — это продажи. И индустрия, которая выросла вокруг этого, работает на страхе.
Появилось много новых слов — скрам, канбан, спайк — которые люди раньше не слышали, поэтому нервничают, не понимая, как их использовать. И теперь нужен переводчик, который придёт к вам на целый день и выставит счёт, чтобы рассказать, что такое спайк.
Сейчас концепция использования Agile, как существительного, стала индустрией. Это машина, работающая на нашем страхе, и просящая нас платить деньги, чтобы успокоить этот страх.
Также появились новые правила в иерархии проекта, и люди боятся, что прежняя структура, которая позволяла управлять организацией сломается, а новая не заработает.
И главное, когда мы начинаем делать что-то новое, появляются сомнения, что мы делаем это правильно.
Успешные люди думают, что у них есть право говорить другим, что и как надо делать.
Если получается добиться успеха в каком-то деле, то возникает иллюзия, что ты что-то знаешь такое, чего не знают остальные. А все, кто видят этот успех, хотят также попробовать этим заняться и повторить. Всегда можно забрендировать этот новый подход. И это подталкивает усложнить жизнь для остальных людей, причём не со зла, а просто так получается само собой.
Например, Ruby-программисты очень сильно продвинулись в деле тестирования, чем кто-то другой в истории вычислений. У них развитая культура тестирования и проводится много экспериментов, разработано много методов тестирования, которые были перенесены потом в другие языки программирования. Но когда кто-нибудь не покрывает всё тестами на 100%, они смотрят на тебя презрительно и говорят: «А я думал, ты программист... Тогда не интересно, чем ты занимаешься, вали отсюда.»
Есть американская поговорка «не позволяй индюкам сломить тебя». Эти люди индюки. Не позволяйте им говорить Вам, что надо делать. Я тоже индюк.
С Agile происходит тоже самое — то, как мы делаем это и есть эталон, если ты делаешь по-другому, то ты второй сорт.
Agile подход создан для маленьких команд и проводятся конференции, чтобы можно было масштабировать лучшие решения. Но открытие заключается в том, что в маленьких командах не очень много денег, поэтому они не интересны для продаж. Деньги находятся в больших компаниях, и надо было найти возможность адаптировать подход на них. Поэтому стали разрабатывать новые варианты, противоречащие изначальным принципам. И Agile, который разработан для маленьких команд, теперь используется для больших корпораций.
Иначе на Agile не заработаешь.
Нет универсальных правил (кроме этого).
Для каждого правила нужен контекст. Например, правило «нельзя тыкать ножом в другого человека» хорошее до тех пор пока это не хирург, которому надо делать операцию. На просьбу прислать хотя бы одно универсальное правило пока никто не откликнулся.
Все правила завязаны на контексте. Любая книга «Как разрабатывать ПО» неправильная, т.к. написана не для вашей команды, компании, проекта, поэтому Авторы не знают точно, как конкретно Вам надо разрабатывать ПО.
Поэтому в Agile не может быть стандартов, подходящих всем.
Дэйв Томас считает, что выход из тупика может быть при использовании в проектах следующего цикла:
1. Определиться, где Вы находитесь.
2. Сделать маленький шаг к Вашей цели.
3. Оценить, что получилось.
4. Вернуться на Шаг-1.
Пытливые умы могут сравнить его с циклом Шухарта-Деминга. А всем остальным рекомендуется ознакомиться в доп. материалах с ошибками изучения творчества, где разбирается метод проб и ошибок.
Но нам с Вами будут больше интересны выводы о совершённых ошибках в истории Agile.
Решения сложных проблем не создаются путём обсуждений и выдумыванием решений из головы.
Простыми декларациями, призывами, манифестами стать лучше, делать всё хорошо и т.п. не решить сложных проблем, которые копятся десятилетиями. Но можно запутать других и кто-то сможет заработать на этом.
Коллективы Разработчиков нового и условия, в которых они работают, слишком разные, чтобы для всех можно было сформулировать общие рекомендации, без учёта контекста.
Всем Разработчикам и Исследователям рекомендуется учиться на чужих примерах и не повторять этих ошибок.
Большинство проектов так и остаются неудачными, т.к. методология их разработки до сих пор не создана. Это касается не только сферы IT, но и большинства других. И чем сложнее проект, тем выше вероятность неудачи.
Автору статьи неизвестно, где КАЧЕСТВЕННО учат (даже за деньги) созданию своих проектов, методик и иных разработок, кроме проекта VIKENT.RU. Если уважаемым Читателям известны такие примеры, то просьба привести их в комментариях.
А для более глубокого погружения в тему рекомендуется проработать дополнительные материалы:
Доп. материалы по теме1) (видео 8 мин.) #тестирование НОВЫХ ТВОРЧЕСКИХ ПРОДУКТОВ / РАЗРАБОТОК
2) (видео 12 мин.) Почему новые методики креатива будут похожи на ТРИЗ?
3) (видео 87 мин.) #консультация № 255 о создании авторских методик по принятию решений
4) (видео 46 мин.) ПРИНЯТИЕ ТВОРЧЕСКИХ РЕШЕНИЙ: ЭТАПЫ / СТАДИИ (ВИДЕОСЛОВАРЬ VIKENT.RU)
5) (видеозадача 3 мин.) Как исказили Waterfall?
Источники материалов
Agile is Dead • Pragmatic Dave Thomas • GOTO 2015 https://www.youtube.com/watch?v=a-BOSpxYJ9M
AGILE IS DEAD (LONG LIVE AGILITY) https://pragdave.me/blog/2014/03/04/time-to-kill-agile.html
Agile-манифест разработки программного обеспечения https://agilemanifesto.org/iso/ru/manifesto.html
CHAOS Reports www.standishgroup.com
Благодарности вычитывающим:Благодарю А. А. Морозова, А. И. Трушинского и И. Л. Викентьева за вычитку и рекомендации по усилению данной статьи. Отдельно А. А. Морозову за иллюстрации.
Показать полностью
6
5
Как мы в компании поделили отдел разработки
Всем лучи добра! Меня зовут Николай Петров, но вы можете звать меня просто Вадим. Я работаю техническим писателем в одной компании компании. Мы разрабатываем систему электронного документооборота, а в статье я хочу поделиться тем, как мы один большой отдел поделили на несколько команд. Я не буду пересказывать очередную историю успешного успеха, а изложу процесс с моей субъективной точки зрения. Всё перевру, приправлю тупыми шутками и в таком духе.
Как у любой другой компании у нас была своя команда разработки, точнее две больших команды. Одна команда разрабатывала один продукт, другая — второй. Всё шло хорошо, приходили новые разработчики, команды постепенно разрастались, и к какому-то моменту стало понятно, что большие команды только усложняют процесс разработки и делают взаимодействие неудобным. Когда одни и те же ошибки исправляются по несколько раз разными людьми — это субоптимально. Также субоптимально, когда на утреннем стендапе 22 человека и пятиминутный разговор о проблемах выливается в получасовой сеанс психотерапии для одного-двух разработчиков. Так мы решили перейти от проектных команд к кросс-функциональным командам. Сейчас всё поясню.
TRIGGER WARNING: Прежде, чем я начну, прошу вас подготовиться к неожиданностям при прочтении статьи. Если текст кажется вам переполненным сарказмом, пожалуйста, не относитесь к нему слишком серьёзно. Если текст вас оскорбляет, не читайте его. Спасибо!
Сам понял, что сказал?
Сложное слово "кросс-функциональные" означает всего лишь, что все команды занимаются всем понемногу. Таким образом каждая команда выполняет задачи из разных проектов и владеет знанием обо всём продукте, а не только о его части. Почему так важно, чтобы каждый знал чуть-чуть обо всём, думаю понятно, но на всякий случай поясню:
- Каждый разработчик видит код разных проектов и немного понимает "как это устроено".
- Если кто-то заболел, ушёл в отпуск или уволился (и такое случается), кто-то другой подхватит его работу.
- Все вместе делают продукт, а не отдельную его часть.
Недолго думая, мы решили организовать встречу в лучших традициях демократии, где каждый может сам выбрать, что ему нравится больше всего. Встречу провели, конечно же, онлайн. Не все сейчас ходят в офис, да и офисы у нас в двух разных городах. Кто-то даже впервые показал своё истинное лицо. Не только аватарку, в смысле. Все дружно перешли по ссылке в Miro, где наш заботливый руководитель Денис заранее подготовил стикеры, на которых каждый записывал, чем он хочет заниматься.
Затем всем было предложено занять место за четырьмя столами. Столы были виртуальные, поэтому закусок не предполагалось, зато каждое место было подписано в духе "frontend-разработчик", "backend-разработчик", "бизнес-аналитик", "тестировщик", ой, простите, "QA-инженер", "технический писатель". Три обычных команды и одна типа сервисная — помогает другим и координирует работу. Всё потому, что бизнес-аналитиков у нас пока не так много да и технический писатель всего один (это я. Привет, мам!).
Где-то после этого была ещё встреча для каждой команды, где они долго и в лучших традициях древнегреческих мудрецов рассуждали о том, кто же должен быть "тимлидом", а кто должен ходить на общекомандные встречи и почему это могут быть разные люди.
После разделения каждая команда обладает всеми необходимыми атрибутами успешного коллектива:
- Дурацкие названия: Вжик, Горыныч, БЭМС (Боевые, Энергичные, Молодые, Симпатичные), Звёздочка
- Логотипы из картинок, найденных в интернете
- Командный дух, компетенции и опыт
Передел YouTrack
Команды есть, теперь надо как-то работать. Работаем мы в YouTrack, точнее с его помощью. Да-да, я знаю, что Agile, спринты, ежедневные стендапы и вот это всё от зарубежного диавола и вообще никому не надо. Если вы согласны, то пропускайте этот раздел и идите лесом дальше по статье.
Постараюсь кратко и на пальцах. Раньше у нас был один общий ютрек: все задачи в одной куче, которая распределялась нашим многозадачным руководителем Денисом. Теперь у нас по-прежнему один общий ютрек, но задачи распределяет маленький избранный народом тимлид.
Раньше каждые две недели мы планировали один общий спринт, на котором можно было просадить полтора часа времени, а теперь команды планируют спринты сами. А могут вообще отказаться от всего лукавого аджайла и планирования, если так проголосуют. Профит в том, что теперь на планирование тратится значительно меньше времени и нервов.
Мне так вообще в планировании не надо участвовать. А смысл? Всё равно каждое требование я потом должен буду задокументировать, вот я и документирую, а не планирую.
Раньше в ютреке было два проекта: платформа и web-клиент. Теперь у нас есть общие задачи производства, которые могут включать любой проект. Были задачи типа WebC и задачи DV5, а стали просто TSK (может быть как WebC, так и DV5, так и вообще что угодно). Раньше ошибки записывались как обычная задача, а теперь в специальную задачу типа ERR. Видишь заголовок и сразу понимаешь, где собака зарыта.
У каждой такой задачи есть поле "команда", в котором указаны ответственные. Приходишь такой в требование, смотришь, кто ответственный, сразу знаешь, на кого наехать, чтобы узнать инфу.
А ещё у меня появился свой тип TSK-задачи — задание на документацию. У моих особых задач нет ревью и тестирования, они сначала открыты, потом в работе, потом закрыты. Всё.
Расскажи ещё, как у вас круто получилось
Работать правда стало намного увлекательнее. Появился чёткий ритм. Утром стендап (5-15 минут) и обсуждение командных проблем, потом избранные приходят на синхронизацию и рассказывают проблемы на общекомандной встрече (обычно минут 5-7). Каждые две недели ретроспектива (как поработали) и планирование (что будет делать дальше) и общекомандное демо (показать всем, как работает сделанное за 2 недели). И это не полуторачасовые встречи как раньше, а реально динамичные и полезные события. Мне особенно нравится демо, потому что теперь мне не надо сидеть и втыкать в требования часами, включая воображалку "а что же тут подразумевалось? а как же это задокументировать". Команды всё покажут и объяснят сами!
Ладно, кого я обманываю, всё равно мне приходится втыкать в требования часами, потому что я тупой.
Команды стали максимально автономными и независимыми. Они не ограничены ничем кроме достижения поставленной цели — выпуск продукта. В своих маленьких коллективах коллеги разработали свои методики автоматизации, особенные алгоритмы взаимодействия и т.д. Например, в Звёздочке разработали систему ачивок за количество закрытых требований в спринте. Если они закроют XX, YY, NN требований, то получат одну, вторую и третью звёздочку соответственно. Причём именно полностью закроют, включая документацию. На вопрос "а что если я не успею задокументировать их требование, и оно не будет закрыто", мне ответили, что могут вежливо попросить меня поторопиться. Что даёт мне некоторую власть над целой командой. Власть опьяняет.
В любом случае получилось классно! Демократичность, открытость и самостоятельность — вот как бы я охарактеризовал нынешний процесс.
Гонишь, не может всё быть так гладко
Может и гоню, но совсем чуть-чуть. Вот настолько:
Дело в том, что у нас в компании налажено ревью кода. Это когда один разработчик приходит к другому и говорит: "смотри, какой классный код я сделал!", а второй ему отвечает: "почитай чистую архитектуру Мартина, тогда поговорим".
Короче, у нас было несколько вариантов организации ревью, и мы не знали, какой из них выбрать:
1. Итеративное ревью.
--- Взяли задачу. Ответвились, сделали доработки по фронту и по бэку.
--- Перед передачей на приёмку бизнес-аналитику делаем ревью фичи целиком. Заодно подмержили develop.
(Есть мнение, что разработка в отдельных ветках — это прошлый век. Вот и пусть будет.)
--- Сделали хорошо, довели ревью до одобрения и передали на приёмку.
--- Если нужна доработка, повторяем предыдущие пункты.
--- Если доработка не требуется, передаём на тестирование.
--- Проводим багфикс.
--- Когда готовы, делаем ревью изменений по багфиксу в целом, обратный мерж и вливаем в develop.
Вот видите, всё просто!
В таком случае ревью будет чуть масштабнее и сложнее, но делать его нужно будет реже. Одна команда сможет ревьюить другую, будет коллективное владение кодом, дети в Африке не будут голодать и будет рай на Земле. Только не спрашивайте, как это работает, моё дело — рассказать.
2. Ревью через merge-реквесты. Работает вот так:
--- Один разработчик написал код и перевёл его на ревью.
--- Автоматически создаётся отдельная ветка и назначается ревьюер.
--- Ревьюер должен обладать теми же знаниями, что и автор кода. Ну, типа клиентский разработчик не может ревьюить серверного, сишарпер не может ревьюить джаваскриптера и т.д.
--- В этой ветке коллеги обсуждают чистоту архитектуры, а затем ветка мержится в девелоп, и все довольны.
--- Можно организовать сразу через гитлаб, минуя upsourсe, в котором всё делалось до разделения.
Знаете, какой вариант мы выбрали? Никакой!
Код-ревью делается по каждой задаче или ошибке по возможности внутри команды. Если это не возможно, то кросс-командно. Ревью создаётся по коммитам для задачи или ошибки в любой ветке.
Неудобные вопросы после разделения на команды
- Как будет проходить регресс?
--- Ожидание: Все задачи регресса будут равномерно распределяться по командам. Или одна команда делает большую часть, а другие помогают.
--- Реальность: После разделения мы ещё не дошли до регресса, поэтому практического подтверждения нет.
- Кто будет брать случайно найденные ошибки из общего чата?
--- Ожидание: Под индивидуальную ответственность. Нашли, записали, а дальше задачу в работу берёт та команда, которой задача больше нравится. Или в зависимости от загруженности.
--- Реальность: Всё так и работает. До сих пор не было проблем.
- Как будут распределяться дежурства по ТП?
--- Ожидание: Очень просто. Дежурят не команды, а дежурят люди. Если загруженность по ТП большая, можно подключать людей из других команд. Если загруженность небольшая, то дежурные могут совмещать дежурство с повседневными задачами.
--- Реальность: В целом всё так. В крайнем случае особенно большой загруженности можно забить на SLA и решать задачи в комфортном темпе. Но это неправильно и мы так не делаем, конечно же. Честно-честно.
- И как полёт сейчас, спустя месяцы?
--- Ожидание: Никто не ожидал, что команды будут статичными.
--- Реальность: Кто-то ушёл, кто-то пришёл, кто-то перевёлся из соседнего отдела. Бизнес-аналитиков набралось на все команды по одному, как и задумывалось. Но есть некоторый недостаток разработчиков.
Выводы
Короче, разделение на команды — это прикольно и совсем безболезненно. Как ни странно, но после разделения мы узнали друг о друге больше, чем до этого. У каждого даже появилась своя карточка с основной информацией о человеке. Типа любимые занятия, почему он тут и к чему стремится. Очень интересно, обожаю такое.
Новичкам теперь легче влиться в небольшую команду, понять процессы и начать работать. Короче, недостаток людей — плохо, избыток — тоже плохо. Если у вас огромная команда и становится сложно управлять процессами, подумайте о разделении, это реально работает.
А если вам нравится стиль статьи, подписывайтесь на мой телеграм. Если стиль не нравился, всё равно подписывайтесь, вдруг телеграм понравится.
Показать полностью
8
Поговорим «по-красному»?
Вначале я опубликовал этот текст на Хабре, но потом понял, что тема гораздо шире. И затрагивает не только it-шников: https://habr.com/ru/post/524812/
Вы совершили ошибку. Все совершают ошибку. Или не совершали. Или у руководства с утра просто «овсянка в сапоге».
- Бэрримор, что у меня хлюпает в сапоге?Или просто руководитель считает, что вы слишком много зарабатываете, хотя при этом выполняете все свои обязанности и даже больше — и не находит иного решения, кроме психологического давление, манипуляции и даже обсценной лексики, чтобы основательно срезать вам зарплату.
- Овсянка, сэр!
- Но что она там делает?
- Хлюпает, сэр!
Причин для поговорить «по-красному» может быть множество. За последний год я их пронаблюдал несколько. И сразу могу сказать «win»-«win» тут и не пахнет. И «бирюзовостью» тоже. Agile тем более. Но встречается такое в наших полях и просторах часто. К чему это может привести?
Компания изначально выглядела прекрасно. Сразу же мне сообщили, что никого не увольняют и нет никакой текучки. Что каждому человеку подыскивают место в зависимости от его способностей и психологической совместимости. Компания позиционировалась, как бирюзовая. И людей не назначали на должности, а люди выполняли обязанности — и постепенно должность как бы формировалась вокруг них.
Через три месяца уволили Нияза, великолепного переводчика — человека, который привёл меня в компанию.
Говорил мне папа в 5 лет: «Не верь в сказки»
Полная дискредитация руководителя в глазах подчинённого
Так уж вышло, что пришлось испытать на собственном примере. На одной из предыдущих работ — название называю не из-за NDA, потому что эта бумажка юридически ничтожна в юридических границах Российской Федерации, а потому что название ничего не придаст к сути рассказа — генеральный директор «внезапна»(!) осознал, что я выполняю все поставленные задачи, но получаю слишком много. Тогда я, кстати, вывел блог компании на 3 место в Хабре с около 30 или 40, точно уже не помню.
Чуть забегая вперёд, отмечу, что через месяц коммерческие и генеральный директор позвонили по по Zoom и сообщили, что я «слишком много получаю». И урезали вдвое. Нет, «не совершил ужасную ошибку, которая привела к финансовым потерям или к уходу важного клиента». Нет, «не разговаривал в офисе матом и не бегал голым по коридорам». Просто «слишком много получаю». Если честно, я занёс это в бриллиантовую книгу цитат.
Но это было потом. Считайте лёгким flashback. За два месяца до этого был «красный разговор», где даже с лёгкой обсценной лексикой мне объясняли, что моё подразделение и я, как руководитель, слишком много кушаем. Не поднимались вопросы, что мы даём компании, что такое долгосрочный эффект, лояльность клиентов, сторителлинг, репутация. Просто много кушаем.
Я слушал примерно 5 минут. После этого очень мягко и корректно, только литературными словами объяснил: «Уважаемый ...., если мы решили поговорить «по-красному», то теперь мой черёд. Говорить со мной в таком тоне и даже с такими словами может крайне ограниченный круг лиц. Во-первых, это очень близкие друзья — и я к ним прислушаюсь. Я тоже могу ошибаться, как любой человек. Во-вторых, это люди, которых я очень уважаю. Это три человека. Полковник ВВС в запасе, полковник ГРУ в запасе и подполковник «Вымпела» в запасе — за их невероятную тяжёлую и мужественную службы стране, за военный опыт и за жизненный опыт. Кроме того, я готов выслушать «по-красному» моих однополчан, когда я работал военным журналистом, и когда мы вместе чудом пережили 2 миномётных обстрела 120-мм минами. Всё. А вам, уважаемый ...., я права говорить со мной «по-красному» не давал. И вы его даже за всю жизнь не заслужили. Весь страшномосковский риск, который у вас в жизни был, это подвернуть ногу, вылезая с кожаного кресла внедорожника. И когда вы со мной пытаетесь говорить по «по-красному», то вызываете даже не обиду или раздражение, а веселье и хихиканье. Про себя, конечно же, потому что я вежливый человек и мажоров в жизни навидался».
Больше со мной «по-красному» говорить не пытались. Говорили с другими — и не раз. Доводили до слёз девушек — и увольняли прямо за столом ресторана после завершение конференции.
Минус этой ситуации: Руководитель больше не вызывал у меня уважения. Обычный московский рвач-мажор. Я скептически относился к его инициативам и зажигательным воодушевляющим спичам. Мне он был просто неприятен, как человек. Мне стало всё равно, что будет с его компанией и с его продуктом. Сотрудник оказался полностью демотивирован работать даже на 110%. Я выполнял необходимые задачи. Я обеспечивал тот результат, что требовалось. Но не больше. Я больше не «горел» идеей.
Профессиональное выгорание
Слава богу, меня это обошло. Я и не то повидал за последние пять лет, чтобы это привело меня к выгоранию. А вот других может.
Постоянный прессинг. Уничижение. Представление достижений сотрудника, как нечто незначительное и не стоящее доброго слова. Лишение премий «просто так», конечно же, с разговором «по-красному». Вместо поддержки, когда приходит сотрудник другого подразделения, потому что первое подразделение не посчитало нужным оповестить о запуске продукта, сотрудник делается виноватым, с ним говорят «по-красному» и просто вышибают в классический когнитивный диссонанс.
На словах в компании Agile. Открытость. Прозрачность. Доверие. Blameless Culture.
На деле «все животные равны, но некоторые животные равнее других»(с)Джордж Оруэлл.
Минус этой ситуации: И на этой разнице происходит фрустрация, неверие в себя, в команду, в продукт. Выгорание. В худшем случае депрессия. То есть сознательный вред здоровью сотрудника со стороны руководителя.
Потеря ценного сотрудника
После разговора «по-красному» можно потерять ценного сотрудника — не будем учитывать вариант прямого в челюсть.
Почему ценного? Потому что «середнячки», невротики и неуверенные в себе люди будут терпеть.
Будут терпеть люди, связанные кредитами, ипотеками, больными родственниками.
Страдать и терпеть. Мучиться. Болеть. Брать отпуска в надежде, что смогут восстановиться. Выгорать. Мучиться бессоницей. Ходить на работу, как на каторгу. И бояться, что следующими уволят их, потому что они всё делают «неправильно», «плохо», «неэффективно», «не так».
Минус этой ситуации: Компания лишается сотрудника, который может принести значительную пользу и прибыль. А также теряет репутацию, потому что сарафанное радио никто не отменял.
Agile превращается в карго-культ
Руководство получает новые игрушки: дейли, грумминг, планирование, демо, ретро. Все ходят строем на эти мероприятия. Пропустить хоть одно из них — это неуважение команды.
Каждый по принципам Agile равен другому сотруднику. Но как сказано чуть выше «есть животные равнее других». И это иногда исподволь, иногда прямо демонстрируется. Вроде бы проходит обычное дейли — и тут коммерческий директор, который взял себе роль scrum-мастера, начинает командовать и говорить, что и кому делать. Бирюзово? Да как-то не очень. Скорее «по-красному».
Это повторяется раз, два, три. Сотрудники приходят к нему за советом, а получают выговор. Вместо scrum-мастера, они получают обычного руководителя. Вместо Agile, так называемый «руджайл», а если проще обычный «карго-культ». Но все его выполняют — потому что каждый боится оказаться слабым звеном.
Минус этой ситуации: Agile превращается в карго-культ. Сотрудники ходят на дейли, демо и ретро, как на каторгу, и считают, что это потеря времени. Вместо открытости, прозрачности, доверия и blameless-культуры сотрудники получают непрозрачные и необъяснимые процессы в стиле «потому что так тут заведено», договорённости за спиной и отдельными группами, закрытость процессов в других отделах и, конечно, вина, вина, вина за это, за другое, за третье. Что опять же ведёт к выгоранию.
А вы встречались с таким «по-красному"? И как поступили? Нашли решение «win»-«win»?
Показать полностью
1