​​Переработанная модель Маслоу

Читаю книгу и наткнулся на интересную трактовку модели Маслоу (кому привычнее, могу назвать её “пирамидой”). Автор вполне удачно отразил её на рабочую среду.

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

Отмечу, что это действительно напоминает больше мотивационную модель, нежели “пирамиду” и работает оно просто прекрасно на мой взгляд, например:
⁃ Долго ли будет работать в компании человек, у которого замечательная компенсация, но его коллеги мудаки или проект - унылое легаси?
⁃ Долги ли будет ли развивать человек науку через полную отдачу себя в само-актуализацию, но которому нечем кормить свою семью?


Насчёт самой книги напишу обзор, когда закончу чтение.

​​Евгеника в проектном менеджменте

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

​​Наиболее частые причины неудач в аутсорсе

Попытались несколько лет назад проанализировать на основании анализа причин провалов проектов в ряде компаний. Делалось это не в СНГ разумеется, что за компании не раскрывается, но исследование публиковалось на PMI (Project Management Institute) в рамках Outsourcing Center. Информацию перевёл на русский язык и её можно увидеть на картинке в закрепе.
Все причины ясны и понятны, за исключением "другое", и это я бы отнёс к категории "обложались, но не захотели даже анализировать". И на мой взгляд эти пункты интереснее объединить по группам:

- коммуникация (communication)
- управление (management)
- взаимодействие с поставщиками услуг (vendor management)

Затем пересчитать относительно этих групп и на коммуникацию получается более 50%. Всё таки 50% успеха или провала - это коммуникация.

​​Upsale & Cross-sale

Сегодня во время мита скинули классную картинку, и она просто идеально передаёт разницу между Upsale'ом и Cross-sale'ом (повышением продаж и перекрёстными продажами). Делюсь.

Deadlines

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

Джуниор увольняется 🙀

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

"Представь к тебе приходит джуниор-тестировщик и говорит об увольнении из компании. По закону мы должны его отпустить из компании в течение 30 дней. С одной стороны, он – всего лишь джуниор, не критически важный для проекта. С другой стороны – достаточно умный и многообещающий молодой специалист, а терять толковых людей я не люблю." Варианты начального вопроса могут варьироваться от: "что делать в такой ситуации?" до "что делать в этой ситуации и что делать чтобы избегать таких ситуаций?", с возможностью потенциально донабросить условий или вопросов по ходу ответа соискателя.
 
Для меня этот кейс - отличный способ узнать о кандидате следующее:
 
• Насколько кандидат шарит за people management и понимает жизненный цикл сотрудника.
• Насколько он понимает специфику IT рынка.
• Соответствие опыта и культуры работы с персоналом у кандидата с тем, что постулируется в компании. И этичное управление персоналом.
• Способность кандидата стратегически подходить к решению проблем и умению в коммуникацию.
 
Варианты ответов могут различаться в силу опыта соискателя, и за несколько лет я услышал много вариантов и зачастую самые распространённые решения - предложить больше денег и использовать различные манипулятивные техники в стиле нефинансовый мотивации а-ля "мы же одна семья". Радует, что я ни разу не услышал что-то на подобии: "гнать ссаными тряпками".
 
Решения проблемы могут быть разными, но данная головоломка складывается иначе.
 

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

 
Мотивами проблемы может быть всё, что угодно: недостаточная компенсация, отсутствие видения карьерных перспектив, домашние неурядицы, конфликты на рабочем месте и т.д. и т.п.
 
Выявить их можно через обычное общение с сотрудником. Отказ сотрудника обсуждать причины ухода – тревожный сигнал о проблемах в менеджменте.
 
Как заранее предотвращать подобные случаи – обширный вопрос из People Management Life Cycle. Весь цикл от формирования заявки на найм нового сотрудника и до увольнения из компании оказывает влияние. Но часто вы ограничены в возможностях влиять на весь жизненный цикл(например на найм) и должны работать с сотрудниками в рамках своих возможностей. Поэтому на мой взгляд, важно следующее:

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

Анонимные опросники в менеджменте

Написал статью для хабра - https://habr.com/ru/articles/780658/
Прошу читать и критиковать. 😉

Культурный контекст важен

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

В период с 1988 по 1998 год число аварий самолетов Korean Air в 17 раз превышало средний показатель по отрасли. Следователи обнаружили, что первопричиной был перенос корейского социально-культурного контекста в кабину пилотов. Социальный статус капитана был настолько высок, что младшие офицеры в кабине могли общаться только уклончиво и почтительно. Капитан управлял самолетом в одиночку. Современные реактивные самолеты требуют команды из двух или трех человек для безопасного полета. Никакое индивидуальное обучение летному мастерству не поможет. Сегодня показатели Korean Air такие же хорошие, как и в целом по отрасли, потому что эксперты из Aleton (дочерней компании Boeing) изменили культурно-социальный контекст, создав команду равных.

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

https://habr.com/ru/articles/786334/

#Книги

Ходите на собеседования

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

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

• Считается, что, проходя собеседования можно узнать о новых трендах на рынке, в частности это актуально для инженеров - какие фреймворки, какие либы или языки программирование сейчас подходят под категорию стильно-модно-молодёжно. Но очень часто я был свидетелем обратного - когда на собеседовании спрашивают про космические корабли, а задачи из разряда сделай кнопочку розовее.
• Не все начальники относятся лояльно к желанию сотрудников сходить на собеседование в другую компанию (посмотреть, а как оно там, за забором). Обсуждение причин подобного нежелания оставлю на потом. Но на отношение с начальством это может сказаться.
• Можно столкнуться с выгоранием. Если очень сильно увлечься походами по собеседованиям и добавить серьёзную подготовку к каждому.
 
И моё главное условие для прохождения интервью - обратная связь(feedback) по результатам.
 
А вы ходите на собеседования?

Вопросы на интервью.

Люблю задавать case(ситуационные) и нестандартные вопросы на интервью. Одна из подобных задачек: «давайте представим, что вы хотите перевести команду со SCRUM’а на Waterfall, каким образом вы можете убедить вашего заказчика\менеджмент в эффективности Waterfall’а по сравнению со SCRUM’ом». По моей личной статистике 80% кандидатов «ломается» на этом вопросе и в итоге сводят это к теме про какой эффективный и замечательный SCRUM. И в лучшем случае только 20% кандидатов пытаются рассуждать и предложить какие-то варианты.

Культурные различия.

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

Разные взгляды на управление персоналом.

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

Сейчас хочу копнуть глубже по двум основным направлениям в управлении персоналом: HRM (Human Resource Management, или Управление человеческими ресурсами) и People Management (Управление людьми).

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

Разница видна во всех аспектах:

👨‍💻 Подход: HRM любит гоняться за новинками, которые как метеоры взлетают и так же стремительно падают в небытие. People Management же стоит на твёрдой почве фактов и аналитики. Нельзя однозначно сказать, что классический HRM плох, т.к. за короткое время можно сгенерировать большое количество идей, возможно какие-то из них выживут и приживутся.

👨‍💻 Вовлечение: В HRM ключевые решения – это удел топов, а в People Management к процессу подключают всех, делая акцент на благополучии сотрудников.

👨‍💻 Производительность: HRM ставит на интенсификацию, а People Management – на качество.

👨‍💻 Взаимодействие: HRM общается через опросы один-два раза в год, People Management – на постоянной основе с фокусом на обратную связь (feedback).

👨‍💻 Ответственность: HRM фокусируется на индивидуальной, People Management – на коллективной.

👨‍💻 Обучение: HRM - регулярное обучение, организация определяет план и подходы обучения. People Management - обучение фокусируется на основании собственного или коллективного опыта, экспериментов и знания воспринимаются как один из краеугольных камней в фундаменте организации.

👨‍💻 Развитие: HRM играет в игру "кто круче” через покупку лучших в ресурсных войнах. People Management ставит на рост и развитие каждого.

👨‍💻 Вознаграждение. HRM - финансовое вознаграждение сильно различается для разных сотрудников, бонусы выплачиваются за личную эффективность. People Management - разделение прибыли между всеми сотрудниками и коллективное вознаграждение и признание (запах социализма).

Сегодня мало кто держится за одну из этих крайностей; чаще всего в действии микс, где есть место и тому, и другому.

А как у вас в компании? Считают ли вас за полноценного члена команды или всё-таки за ресурс?

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

PoC vs PoV

Многие слышали такую аббревиатуру как PoC (Proof of Concept) – как правило под этим понимается доказательство концепции, когда берём и проверяем идею на реализуемость, аналог вопроса – «можно ли это сделать?»

Когда занялись анализом присейлов, случился диалог:
- Это можно сделать?
- Да.
- А зачем?

И действительно – зачем? Набулшитить клиента – сомнительный подход. И на помощь приходит как раз PoV(Proof of Value) – подтверждение практической ценности, когда идея не только проверяется на реализуемость, но и проводится оценка, какую практическую ценность получит клиент в результате применения решения. Разумеется, сейчас все вокруг адепты Data Driven (подтверждённое данными) – и это правильно, цифрами манипулировать сложнее, поэтому выражать «выхлоп» от PoV надо в каких-то величинах измеримых для заказчика: сокращение затрат на поддержку, сокращения таймлайна на разработку и т.п. Главное не превратить PoV в ещё один buzzword – когда под этим термином пытаются пропихнуть, что угодно, но только не то что окажет пользу клиенту.

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

Эволюция аутсорса. Часть первая.

В начале были слова и слова эти были: «дайте нам три человека, которые умеют в Java, .Net, SQL, C++, HTML, Windows, Linux».

На заре времён аутсорса, как сервиса, был бодишоп (от англ. bodyshop), много позже из-за неблагозвучности этого слова (а также шуточек в адрес компаний), многие компании стали от него отходить и словарь весьма и весьма расширился появились: outstaffing, staff augmentation, personnel leasing, contract staffing, co-employment services, managed staffing services или просто managed services. В каждый из этих терминов пытались, что-то привнести, но основная идея осталась неизменна: где-то далеко в другой стране, где рабочая сила стоит дорого и её не хватает, расширяют штат за счёт привлечения сотрудников, работающих по факту на удалёнке. Какие-то фирмы так и остались в начале эволюционного пути - продают услуги разработчика за два рубля, платят сотруднику рубль, на эти два процента и живут, кто-то пошёл дальше и о других моделях я напишу позже.
По факту эта бизнес-модель простая и надёжная, как швейцарские часы со своими плюсами и минусами.

Плюсы для компаний-клиентов:

🥕 Упрощение ресурсной работы – очень часто контракты весьма жёсткие и отказаться от услуг сотрудника компания может день в день. Нет необходимости тратить деньги на найм, увольнение, дарить подарки за 10 лет работы в компании. Наняли, уволили – упрощённый жизненный цикл сотрудника для подобных компаний-клиентов.

🥕 Снижение затрат – изначально аутсорс зародился по причине наличия более дешёвой рабочей силы по сравнению с США или Европой, но при сопоставимой квалификации. Разница в зарплатах, налогах и издержках на соц. пакет на гипотетического сотрудника в США с лихвой перекрывалась возможностью нанять несколько инженеров из экс-СССР стран. Сейчас ситуация выглядит немного иначе, но на заре аутсорса этот подход работал великолепно.

🥕 Быстрый доступ к ресурсам – поиск, подбор, найм – это затраты и сложности не только с точки зрения финансов, но и с точки зрения времени. При наличии аутсорс компаний можно просто обратиться к ним с запросом из разряда: «песчаный карьер – два человека, уборка улиц – три человека, мясокомбинат…»

Плюсы для сотрудников:

🥕 Разнообразие проектов – разные проекты, разные индустрии, разные технологии. Смена проекта не занимает много времени.

🥕 Компенсация – аутсорс достаточно конкурентная среда и многие компании промышляли и промышляют перекупкой специалистов, есть даже отдельный термин хэдхант (хэдхантинг, хэдхантеры от англ. head hunt – охота за головами) поэтому, но при переходе в другую компанию в 90% случаев у сотрудника есть ожидания о повышении зп. Знаю случаи, когда люди работали по два-три месяца в разных компаниях, для того чтобы «набить» повышение зарплаты при переходе от одного работодателя к другому.

Теперь же посмотрим на минусы бодипош подхода в аутсорсе.

Минусы для компаний-клиентов:

🗿 Нет приверженности и лояльности к компании. Если компания-клиент может уволить сотрудника одним днём, то и сотрудник может уволиться точно так же. Со временем аутсорс фирмы (посредники) стали всё больше и больше играть в правовом поле, поэтому появились различные договора, контракты и так 30-дневный нотис (от англ. notice - уведомление) сейчас применяется как к компаниям-клиентам, так и к сотрудникам. Но я видел и компании, которые оперировали долгосрочными соглашениями и наотрез отказывались увольнять сотрудников в течение года, например. Конфликты в подобных ситуациях решались по-разному – кого-то продавливали и человек работал до конца своих обязательств, кто-то устраивал «итальянскую» забастовку – ходил на работу и ничего не делал, кто-то забивал на увольнение по статье и через 30 дней получал трудовую книжку заказным письмом.

🗿 Качество работы. Если аутсорс компания представляет только услуги посредника – этакое IT-сводничество, то за отслеживание качества работы отвечает компания клиент и нет никаких гарантий, что предложенный сотрудник будет работать качественно и эффективно.

🗿 Масштабируемость. В противовес быстрому доступу к необходимым ресурсам у аутсорс компаний часто страдала масштабируемость. Поэтому либо компания брала на вооружение подход бэнча (от англ. bench – скамейка запасных) куда нанимались люди впрок, либо коротали время между окончанием одного и началом другого проекта; или же Маша-рекрутер-hr получала вечером в плечи срочную задачу – к утра обеспечить найм трёх программистов-сеньоров, где она их возьмёт – это уже её проблемы. Поэтому на запросах из разряда «дайте нам 200 человек» очень часто аутсорс-системы ломалась и не работали, или применялись хитрые джедайские техники, о которых мы поговорим как-нибудь в другой раз.

Минусы для сотрудников:

🗿 Отсутствие социальных гарантий. На заре аутсорса сотрудники не имели таких же социальных гарантий, как их «заокеанские» коллеги. Сейчас ситуация выглядит немного иначе, но если посмотреть внимательно на различные условия от государств о технопарках, то становится понятно, что ИТ-шка одна из самых социально-незащищённых отраслей, хоть и с неплохими зарплатами.

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

🗿 Ненадёжность и неопределённость. Знаю, что и сейчас есть на рынке аутсорс компании, которые увольняют сотрудников в день окончания проекта.

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

#ФразаНедели
«Давайте execute’нем, а там посмотрим» (от англ. execute – выполнить/сделать).

#CaseStudy

Проект аутсорс-разработки сталкивается с настойчивым требованием одного из менеджеров клиента из США перейти на модель стафог. До этого момента команды работали в режиме почти PES (Professional Engineering Services). О разнице между StaffAug vs PDS vs PES я расскажу в историческом очерке (первая часть про StaffAug). Менеджер проекта на стороне исполнителя базируется в Центральной Европе, в то время как часть команды разработчиков находится в Латинской Америке.

Проблематика:

✏️ Серебряной пули нет: проблему необходимо решать комплексно по нескольким направлениям.

✏️ Низкая маржинальность: стафог наименее прибыльная модель для исполнителя.

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

✏️ Технологические ограничения: Избыточный контроль со стороны заказчика может затруднить принятие качественных решений.

✏️ География проекта: заказчик в США, проектный менеджер в Европе, часть команды в Латинской Америке. Эффективной работы 24/7 для ПМ невозможно организовать.

Решения:

🛠 Мы так не работаем. Самый рискованный и простой способ. Прямой отказ от перехода на StaffAug должен быть подкреплён крепкой позицией и высоким уровнем доверия со стороны спонсора проекта (project sponsor). Дипломатичность, уверенность в своих силах и уверенная аргументация – будут вам необходимы.

🛠 Анализ причин. Выяснить, почему менеджер клиента настаивает на StaffAug’е. Помогут регулярные личные встречи с менеджером клиента, выстроенная система репортинга — это приведёт к появлению, а затем и росту доверия со стороны представителя заказчика. Я использую термины «гладить по голове» и «сидеть на коленках» - фривольно описывают, что нужно делать.

🛠 Нанять или вырастить помощника. Закрывать, контролировать все задачи и оставаться эффективным одному ПМу не получится, особенно когда команда находится в 7 часах от вас и команд несколько. Наймите или вырастите себе помощника, который будет находиться рядом с командами, делегируйте часть полномочий и ответственности. И не забудьте договориться о зонах ответственности – это поможет избежать конфликтов в дальнейшем.

Кстати если у вас есть интересные кейсы для разбора – пишите мне в личку tg – @Antonio_Ingegnere