Давно собирался написать обзор на книгу, которая оставила наибольшее впечатление за весь предыдущий год и наконец-то это свершилось. Пока что публикую сам обзор на хабре, но в дальнейшем планирую перетянуть его и в блог.
https://habr.com/ru/articles/786334/
#Книги
https://habr.com/ru/articles/786334/
#Книги
Хабр
Книга года — Become an Effective Software Engineering Manager
Наверное, обзор этой книги стоило бы сделать под Новый Год когда я и закончил её чтение, но как-то подведение итогов подзатянулось, но всё равно мне бы хотелось назвать эту книгу именно книгой года и...
Ходите на собеседования
В студенчестве у нас преподавали замечательные люди - молодые и амбициозные знающие инженеры-практики и один из них Алексей Копачёв читал предмет по базам данных. Предмет настолько интересно и всесторонне излагался, что я ходил на все лекции и у меня был полный конспект.
На одной из лекций преподаватель на полном серьезе, но с ноткой юмора дал нам рекомендацию, которую я использую по сей день - "Всегда ходите на собеседования". И очень простое объяснение "во-первых вы будете представлять сколько вы стоите на рынке как специалист и второе - вы настолько можете задолбать понравившуюся вам компанию, что вас в конечном итоге возьмут туда на работу".
C годами это трансформировалось в то, что я сам люблю и хожу на собеседования и никогда не отказываюсь, при соблюдении одного важного условия, так и людей, с которыми я работаю или работал, никогда не отговариваю сходить на собеседование в другую компанию и на это есть ряд причин:
• Во-первых, формируется понимание и представление о стоимости себя как специалиста на рынке, с чётким осознанием переплачен ты или недоплачен, или же оценён по достоинству;
• Во-вторых, я получаю шанс узнать что-то новое. Например, мне как менеджеру интересно посмотреть, как процесс найма и интервьюирования устроен в других компаниях. Можно судить о компании уже исходя из её процессов на входе;
• В-третьих - возможность завести личные знакомства(networking) и выстроить профессиональные связи;
• И, в-четвёртых, подстегнуть карьерный рост. Иногда чтобы прогрессировать приходится сменить работу. Несколько лет назад подобное встречалось сплошь и рядом, когда люди меняли раз в полгода\год работу для карьерного или финансового продвижения.
Есть и спорные моменты:
• Считается, что, проходя собеседования можно узнать о новых трендах на рынке, в частности это актуально для инженеров - какие фреймворки, какие либы или языки программирование сейчас подходят под категорию стильно-модно-молодёжно. Но очень часто я был свидетелем обратного - когда на собеседовании спрашивают про космические корабли, а задачи из разряда сделай кнопочку розовее.
• Не все начальники относятся лояльно к желанию сотрудников сходить на собеседование в другую компанию (посмотреть, а как оно там, за забором). Обсуждение причин подобного нежелания оставлю на потом. Но на отношение с начальством это может сказаться.
• Можно столкнуться с выгоранием. Если очень сильно увлечься походами по собеседованиям и добавить серьёзную подготовку к каждому.
И моё главное условие для прохождения интервью - обратная связь(feedback) по результатам.
А вы ходите на собеседования?
В студенчестве у нас преподавали замечательные люди - молодые и амбициозные знающие инженеры-практики и один из них Алексей Копачёв читал предмет по базам данных. Предмет настолько интересно и всесторонне излагался, что я ходил на все лекции и у меня был полный конспект.
На одной из лекций преподаватель на полном серьезе, но с ноткой юмора дал нам рекомендацию, которую я использую по сей день - "Всегда ходите на собеседования". И очень простое объяснение "во-первых вы будете представлять сколько вы стоите на рынке как специалист и второе - вы настолько можете задолбать понравившуюся вам компанию, что вас в конечном итоге возьмут туда на работу".
C годами это трансформировалось в то, что я сам люблю и хожу на собеседования и никогда не отказываюсь, при соблюдении одного важного условия, так и людей, с которыми я работаю или работал, никогда не отговариваю сходить на собеседование в другую компанию и на это есть ряд причин:
• Во-первых, формируется понимание и представление о стоимости себя как специалиста на рынке, с чётким осознанием переплачен ты или недоплачен, или же оценён по достоинству;
• Во-вторых, я получаю шанс узнать что-то новое. Например, мне как менеджеру интересно посмотреть, как процесс найма и интервьюирования устроен в других компаниях. Можно судить о компании уже исходя из её процессов на входе;
• В-третьих - возможность завести личные знакомства(networking) и выстроить профессиональные связи;
• И, в-четвёртых, подстегнуть карьерный рост. Иногда чтобы прогрессировать приходится сменить работу. Несколько лет назад подобное встречалось сплошь и рядом, когда люди меняли раз в полгода\год работу для карьерного или финансового продвижения.
Есть и спорные моменты:
• Считается, что, проходя собеседования можно узнать о новых трендах на рынке, в частности это актуально для инженеров - какие фреймворки, какие либы или языки программирование сейчас подходят под категорию стильно-модно-молодёжно. Но очень часто я был свидетелем обратного - когда на собеседовании спрашивают про космические корабли, а задачи из разряда сделай кнопочку розовее.
• Не все начальники относятся лояльно к желанию сотрудников сходить на собеседование в другую компанию (посмотреть, а как оно там, за забором). Обсуждение причин подобного нежелания оставлю на потом. Но на отношение с начальством это может сказаться.
• Можно столкнуться с выгоранием. Если очень сильно увлечься походами по собеседованиям и добавить серьёзную подготовку к каждому.
И моё главное условие для прохождения интервью - обратная связь(feedback) по результатам.
А вы ходите на собеседования?
Вопросы на интервью.
Люблю задавать case(ситуационные) и нестандартные вопросы на интервью. Одна из подобных задачек: «давайте представим, что вы хотите перевести команду со SCRUM’а на Waterfall, каким образом вы можете убедить вашего заказчика\менеджмент в эффективности Waterfall’а по сравнению со SCRUM’ом». По моей личной статистике 80% кандидатов «ломается» на этом вопросе и в итоге сводят это к теме про какой эффективный и замечательный SCRUM. И в лучшем случае только 20% кандидатов пытаются рассуждать и предложить какие-то варианты.
Люблю задавать 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 - разделение прибыли между всеми сотрудниками и коллективное вознаграждение и признание (запах социализма).
Сегодня мало кто держится за одну из этих крайностей; чаще всего в действии микс, где есть место и тому, и другому.
А как у вас в компании? Считают ли вас за полноценного члена команды или всё-таки за ресурс?
Решил ещё немного позависать на теме про управление персоналом и обнаружил забавную вещь в работах британцев - оказывается, они с невероятной тщательностью анализируют всё до мелочей. Разумеется, делают они это не в книгах однодневках, которые впаривают через раскрученные издательства мамонтам, а в толстых талмудах, которые и открывать страшно - слишком много букав и страниц.
Сейчас хочу копнуть глубже по двум основным направлениям в управлении персоналом: 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 - информация, которая является ложной, бессмысленной или вводящей в заблуждение).
Набулшитить клиента. (от англ. bullshit - информация, которая является ложной, бессмысленной или вводящей в заблуждение).
PoC vs PoV
Многие слышали такую аббревиатуру как PoC (Proof of Concept) – как правило под этим понимается доказательство концепции, когда берём и проверяем идею на реализуемость, аналог вопроса – «можно ли это сделать?»
Когда занялись анализом присейлов, случился диалог:
- Это можно сделать?
- Да.
- А зачем?
И действительно – зачем? Набулшитить клиента – сомнительный подход. И на помощь приходит как раз PoV(Proof of Value) – подтверждение практической ценности, когда идея не только проверяется на реализуемость, но и проводится оценка, какую практическую ценность получит клиент в результате применения решения. Разумеется, сейчас все вокруг адепты Data Driven (подтверждённое данными) – и это правильно, цифрами манипулировать сложнее, поэтому выражать «выхлоп» от PoV надо в каких-то величинах измеримых для заказчика: сокращение затрат на поддержку, сокращения таймлайна на разработку и т.п. Главное не превратить PoV в ещё один buzzword – когда под этим термином пытаются пропихнуть, что угодно, но только не то что окажет пользу клиенту.
Многие слышали такую аббревиатуру как 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% случаев у сотрудника есть ожидания о повышении зп. Знаю случаи, когда люди работали по два-три месяца в разных компаниях, для того чтобы «набить» повышение зарплаты при переходе от одного работодателя к другому.
В начале были слова и слова эти были: «дайте нам три человека, которые умеют в 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 лет назад можно было неплохо жить на посредничестве, то сейчас для сохранения того же уровня чистой прибыли компании должны эволюционировать: решать проблемы масштабируемости, повышать доходность через повышение ответственности и принятия дополнительных рисков и т.д. Но об этом всём мы поговорим в других моих постах.
Минусы для компаний-клиентов:
🗿 Нет приверженности и лояльности к компании. Если компания-клиент может уволить сотрудника одним днём, то и сотрудник может уволиться точно так же. Со временем аутсорс фирмы (посредники) стали всё больше и больше играть в правовом поле, поэтому появились различные договора, контракты и так 30-дневный нотис (от англ. notice - уведомление) сейчас применяется как к компаниям-клиентам, так и к сотрудникам. Но я видел и компании, которые оперировали долгосрочными соглашениями и наотрез отказывались увольнять сотрудников в течение года, например. Конфликты в подобных ситуациях решались по-разному – кого-то продавливали и человек работал до конца своих обязательств, кто-то устраивал «итальянскую» забастовку – ходил на работу и ничего не делал, кто-то забивал на увольнение по статье и через 30 дней получал трудовую книжку заказным письмом.
🗿 Качество работы. Если аутсорс компания представляет только услуги посредника – этакое IT-сводничество, то за отслеживание качества работы отвечает компания клиент и нет никаких гарантий, что предложенный сотрудник будет работать качественно и эффективно.
🗿 Масштабируемость. В противовес быстрому доступу к необходимым ресурсам у аутсорс компаний часто страдала масштабируемость. Поэтому либо компания брала на вооружение подход бэнча (от англ. bench – скамейка запасных) куда нанимались люди впрок, либо коротали время между окончанием одного и началом другого проекта; или же Маша-рекрутер-hr получала вечером в плечи срочную задачу – к утра обеспечить найм трёх программистов-сеньоров, где она их возьмёт – это уже её проблемы. Поэтому на запросах из разряда «дайте нам 200 человек» очень часто аутсорс-системы ломалась и не работали, или применялись хитрые джедайские техники, о которых мы поговорим как-нибудь в другой раз.
Минусы для сотрудников:
🗿 Отсутствие социальных гарантий. На заре аутсорса сотрудники не имели таких же социальных гарантий, как их «заокеанские» коллеги. Сейчас ситуация выглядит немного иначе, но если посмотреть внимательно на различные условия от государств о технопарках, то становится понятно, что ИТ-шка одна из самых социально-незащищённых отраслей, хоть и с неплохими зарплатами.
🗿 Отсутствие карьерного и профессионального роста. Если сотрудника наняли для работы в карьере, то его задача работать в карьере и год, и два, и три. Начальником карьера и экскаваторщиком ему не стать. Аутсорс компания в подобных случаях не инвестирует деньги в профессиональное развитие сотрудников. Поэтому очень часто люди получали опыт, знания и меняли одного работодателя на другого.
🗿 Ненадёжность и неопределённость. Знаю, что и сейчас есть на рынке аутсорс компании, которые увольняют сотрудников в день окончания проекта.
Но времена меняются и если ещё 20–25 лет назад можно было неплохо жить на посредничестве, то сейчас для сохранения того же уровня чистой прибыли компании должны эволюционировать: решать проблемы масштабируемости, повышать доходность через повышение ответственности и принятия дополнительных рисков и т.д. Но об этом всём мы поговорим в других моих постах.
#ФразаНедели
«Давайте execute’нем, а там посмотрим» (от англ. execute – выполнить/сделать).
«Давайте execute’нем, а там посмотрим» (от англ. execute – выполнить/сделать).
#CaseStudy
Проект аутсорс-разработки сталкивается с настойчивым требованием одного из менеджеров клиента из США перейти на модель стафог. До этого момента команды работали в режиме почти PES (Professional Engineering Services). О разнице между StaffAug vs PDS vs PES я расскажу в историческом очерке (первая часть про StaffAug). Менеджер проекта на стороне исполнителя базируется в Центральной Европе, в то время как часть команды разработчиков находится в Латинской Америке.
Проблематика:
✏️ Серебряной пули нет: проблему необходимо решать комплексно по нескольким направлениям.
✏️ Низкая маржинальность: стафог наименее прибыльная модель для исполнителя.
✏️ Микроменеджмент: Постоянное вмешательство клиента в процесс разработки может снизить мотивацию команды и увеличить текучесть кадров.
✏️ Технологические ограничения: Избыточный контроль со стороны заказчика может затруднить принятие качественных решений.
✏️ География проекта: заказчик в США, проектный менеджер в Европе, часть команды в Латинской Америке. Эффективной работы 24/7 для ПМ невозможно организовать.
Решения:
🛠 Мы так не работаем. Самый рискованный и простой способ. Прямой отказ от перехода на StaffAug должен быть подкреплён крепкой позицией и высоким уровнем доверия со стороны спонсора проекта (project sponsor). Дипломатичность, уверенность в своих силах и уверенная аргументация – будут вам необходимы.
🛠 Анализ причин. Выяснить, почему менеджер клиента настаивает на StaffAug’е. Помогут регулярные личные встречи с менеджером клиента, выстроенная система репортинга — это приведёт к появлению, а затем и росту доверия со стороны представителя заказчика. Я использую термины «гладить по голове» и «сидеть на коленках» - фривольно описывают, что нужно делать.
🛠 Нанять или вырастить помощника. Закрывать, контролировать все задачи и оставаться эффективным одному ПМу не получится, особенно когда команда находится в 7 часах от вас и команд несколько. Наймите или вырастите себе помощника, который будет находиться рядом с командами, делегируйте часть полномочий и ответственности. И не забудьте договориться о зонах ответственности – это поможет избежать конфликтов в дальнейшем.
Кстати если у вас есть интересные кейсы для разбора – пишите мне в личку tg – @Antonio_Ingegnere
Проект аутсорс-разработки сталкивается с настойчивым требованием одного из менеджеров клиента из США перейти на модель стафог. До этого момента команды работали в режиме почти PES (Professional Engineering Services). О разнице между StaffAug vs PDS vs PES я расскажу в историческом очерке (первая часть про StaffAug). Менеджер проекта на стороне исполнителя базируется в Центральной Европе, в то время как часть команды разработчиков находится в Латинской Америке.
Проблематика:
✏️ Серебряной пули нет: проблему необходимо решать комплексно по нескольким направлениям.
✏️ Низкая маржинальность: стафог наименее прибыльная модель для исполнителя.
✏️ Микроменеджмент: Постоянное вмешательство клиента в процесс разработки может снизить мотивацию команды и увеличить текучесть кадров.
✏️ Технологические ограничения: Избыточный контроль со стороны заказчика может затруднить принятие качественных решений.
✏️ География проекта: заказчик в США, проектный менеджер в Европе, часть команды в Латинской Америке. Эффективной работы 24/7 для ПМ невозможно организовать.
Решения:
🛠 Мы так не работаем. Самый рискованный и простой способ. Прямой отказ от перехода на StaffAug должен быть подкреплён крепкой позицией и высоким уровнем доверия со стороны спонсора проекта (project sponsor). Дипломатичность, уверенность в своих силах и уверенная аргументация – будут вам необходимы.
🛠 Анализ причин. Выяснить, почему менеджер клиента настаивает на StaffAug’е. Помогут регулярные личные встречи с менеджером клиента, выстроенная система репортинга — это приведёт к появлению, а затем и росту доверия со стороны представителя заказчика. Я использую термины «гладить по голове» и «сидеть на коленках» - фривольно описывают, что нужно делать.
🛠 Нанять или вырастить помощника. Закрывать, контролировать все задачи и оставаться эффективным одному ПМу не получится, особенно когда команда находится в 7 часах от вас и команд несколько. Наймите или вырастите себе помощника, который будет находиться рядом с командами, делегируйте часть полномочий и ответственности. И не забудьте договориться о зонах ответственности – это поможет избежать конфликтов в дальнейшем.
Кстати если у вас есть интересные кейсы для разбора – пишите мне в личку tg – @Antonio_Ingegnere
Нет мы так не работаем.
В предыдущем примере я затронул самый рискованный и простой способ отказаться от чего-либо – сказать: «мы так не работаем». Хотят вашу команду засунуть в лютый стафог – мы так не работаем; хотят внедрить непонятные решения – мы так не работаем. Сказали, отказались, всё по красоте за исключением одной маленькой детали – контракт и деньги вы скорее всего потеряете. Но в моём опыте был успешный случай, когда мы сказали, что так не работаем, но контракт с нами не расторгли. И так продолжение предыдущего #CaseStudy.
Ситуация: аутсорс проект делается длительное время (30+ человек), нет сорванных релизов всё вовремя и в рамках бюджета. И словно гром среди ясного небу - уходит руководитель продукта (представитель со стороны заказчика), уведомление за 2 недели и увольнение. Нанимают другого и у проекта и команды начинаются проблемы:
🤦 Новый руководитель продукта упарывается в микроменеджмент – любой чих в бэклоге должен быть с ним согласован. Основное отличие от предыдущего продуктового менеджера – раньше давалось общее направление развития продукта плюс необходимые знания в рамках бизнес домена, описание и реализация были на стороне бизнес-аналитиков и команды разработки.
🤦 Начинается хаотичное изменение продукта – был намечен долгосрочный план развития, который выкидывают на свалку, но нового не предоставляют.
🤦 Требования меняются по несколько раз – формализовали требования, реализовали их в коде и это неправильно, переделывайте.
Промежуточный итог.
🤔 Коммуникация становится неэффективной между бизнес-аналитиками и руководителем продукта – команда в Европе, менеджер продукта в US. Пересечение всего несколько часов в день, но из-за желания микроменеджмента объём создаваемых сторей падает, на ревью затрачивается много времени.
🤔 У меня есть правило – все стори должны быть утверждены руководителем продукта. После нескольких переделок и из-за отсутствия плана развития новые стори не утверждаются и копится большой бэклог, команда в разработку может взять крохи.
🤔 И результатом всего этого стала демотивация команды – всё по классике.
Как решали.
Т.к. я выступаю за сознательный менеджмент мы проанализировали ситуацию и пришли к таким выводам:
💡 Новый руководитель продукта до этого работал в основном с Индией, работа же с сотрудниками из Восточной Европы отличается весьма сильно. Стало понятно его желание микроменеджмента.
💡 Отсутствие плана развития и пустой бэклог – следствие непонимания существующего продукта и как оказалось слабых знаний доменной области.
💡 Неутверждённые стори – нежелание брать на себя ответственность и следовать имеющимся процедурам.
Итак, первый подход:
😎 Было проведено несколько сессий, где ненавязчиво и в деталях рассказали про продукт и план развития. Итогом стало то, что достали предыдущий план из небытия, объявили его новым, новым, совершенным и ура.
😎 Отсутствие знаний доменной области – проблема более сложная, но и она решаема. К сожалению, нет способа быстро обучить доменной области особенно когда нет и особого стремления её изучать. Поэтому мы расширили команду бизнес-аналитиков, добавили менее опытных и для матёрого костяка сместили немного фокус на проработку сторей в рамках доменной области.
🤔 Микроменеджмент попытались решить через укрепление сотрудничества и мягкое обучение о том, как работать с ребятами из Восточной Европы. Не взлетело, слишком въелся подход на основании опыта с Индией.
Стало легче, но проблемы остались: микроменеджмент и неутверждённый бэклог не хотели решаться. И вот дальше настало время сказать: «мы так не работаем». Но сделали мы это правильно:
😎 На еженедельных митингах со спонсором проекта мы отобразили падение скорости работы команды (работа велась по SCRUM, поэтому velocity метрика в помощь).
😎 Провели анализ причин и выяснили (хотя и так об этом знали), что у нас большой объём неутверждённых сторей. Поэтому ввели ещё одну метрику для еженедельных митингов - созданные и утверждённые стори в разрезе недели.
В предыдущем примере я затронул самый рискованный и простой способ отказаться от чего-либо – сказать: «мы так не работаем». Хотят вашу команду засунуть в лютый стафог – мы так не работаем; хотят внедрить непонятные решения – мы так не работаем. Сказали, отказались, всё по красоте за исключением одной маленькой детали – контракт и деньги вы скорее всего потеряете. Но в моём опыте был успешный случай, когда мы сказали, что так не работаем, но контракт с нами не расторгли. И так продолжение предыдущего #CaseStudy.
Ситуация: аутсорс проект делается длительное время (30+ человек), нет сорванных релизов всё вовремя и в рамках бюджета. И словно гром среди ясного небу - уходит руководитель продукта (представитель со стороны заказчика), уведомление за 2 недели и увольнение. Нанимают другого и у проекта и команды начинаются проблемы:
🤦 Новый руководитель продукта упарывается в микроменеджмент – любой чих в бэклоге должен быть с ним согласован. Основное отличие от предыдущего продуктового менеджера – раньше давалось общее направление развития продукта плюс необходимые знания в рамках бизнес домена, описание и реализация были на стороне бизнес-аналитиков и команды разработки.
🤦 Начинается хаотичное изменение продукта – был намечен долгосрочный план развития, который выкидывают на свалку, но нового не предоставляют.
🤦 Требования меняются по несколько раз – формализовали требования, реализовали их в коде и это неправильно, переделывайте.
Промежуточный итог.
🤔 Коммуникация становится неэффективной между бизнес-аналитиками и руководителем продукта – команда в Европе, менеджер продукта в US. Пересечение всего несколько часов в день, но из-за желания микроменеджмента объём создаваемых сторей падает, на ревью затрачивается много времени.
🤔 У меня есть правило – все стори должны быть утверждены руководителем продукта. После нескольких переделок и из-за отсутствия плана развития новые стори не утверждаются и копится большой бэклог, команда в разработку может взять крохи.
🤔 И результатом всего этого стала демотивация команды – всё по классике.
Как решали.
Т.к. я выступаю за сознательный менеджмент мы проанализировали ситуацию и пришли к таким выводам:
💡 Новый руководитель продукта до этого работал в основном с Индией, работа же с сотрудниками из Восточной Европы отличается весьма сильно. Стало понятно его желание микроменеджмента.
💡 Отсутствие плана развития и пустой бэклог – следствие непонимания существующего продукта и как оказалось слабых знаний доменной области.
💡 Неутверждённые стори – нежелание брать на себя ответственность и следовать имеющимся процедурам.
Итак, первый подход:
😎 Было проведено несколько сессий, где ненавязчиво и в деталях рассказали про продукт и план развития. Итогом стало то, что достали предыдущий план из небытия, объявили его новым, новым, совершенным и ура.
😎 Отсутствие знаний доменной области – проблема более сложная, но и она решаема. К сожалению, нет способа быстро обучить доменной области особенно когда нет и особого стремления её изучать. Поэтому мы расширили команду бизнес-аналитиков, добавили менее опытных и для матёрого костяка сместили немного фокус на проработку сторей в рамках доменной области.
🤔 Микроменеджмент попытались решить через укрепление сотрудничества и мягкое обучение о том, как работать с ребятами из Восточной Европы. Не взлетело, слишком въелся подход на основании опыта с Индией.
Стало легче, но проблемы остались: микроменеджмент и неутверждённый бэклог не хотели решаться. И вот дальше настало время сказать: «мы так не работаем». Но сделали мы это правильно:
😎 На еженедельных митингах со спонсором проекта мы отобразили падение скорости работы команды (работа велась по SCRUM, поэтому velocity метрика в помощь).
😎 Провели анализ причин и выяснили (хотя и так об этом знали), что у нас большой объём неутверждённых сторей. Поэтому ввели ещё одну метрику для еженедельных митингов - созданные и утверждённые стори в разрезе недели.
Итогом стало то, что спонсор проекта вместе с руководителем продукта просмотрели совместно все стори и утверждали их, и так происходило до тех пор, пока состояние бэклога не стабилизировалось. Рецидива не было по одной простой причине – метрика, о которой я говорил, выше показывалась каждую неделю.
Как мы решили проблему микроменеджмента? А никак. 😆 Она рассосалась сама, на нас просто обиделся менеджер продукта и сократил общение до необходимого минимума.
Но всё описанное выше было возможно по ряду причин:
🤘 У нашей команды был огромный кредит доверия со стороны спонсора проекта: выше я указал про успешное долгосрочное сотрудничество.
🤘 Спонсор проекта действительно был заинтересован в развитии продукта, успех продукта позволил ему построить головокружительную карьеру.
🤘 Мы не сказали нет напрямую, мы сказали это через спонсора проекта.
И самый-самый итог руководителя продукта уволили через год. На мой вопрос почему не раньше я получил ответ – контракт, до истечения срока его нельзя было уволить. Первый квартал он адаптировался, полгода показывал, что умеет и ещё квартал подводили итоги.
Как мы решили проблему микроменеджмента? А никак. 😆 Она рассосалась сама, на нас просто обиделся менеджер продукта и сократил общение до необходимого минимума.
Но всё описанное выше было возможно по ряду причин:
🤘 У нашей команды был огромный кредит доверия со стороны спонсора проекта: выше я указал про успешное долгосрочное сотрудничество.
🤘 Спонсор проекта действительно был заинтересован в развитии продукта, успех продукта позволил ему построить головокружительную карьеру.
🤘 Мы не сказали нет напрямую, мы сказали это через спонсора проекта.
И самый-самый итог руководителя продукта уволили через год. На мой вопрос почему не раньше я получил ответ – контракт, до истечения срока его нельзя было уволить. Первый квартал он адаптировался, полгода показывал, что умеет и ещё квартал подводили итоги.
This media is not supported in your browser
VIEW IN TELEGRAM
Нам не нужен проектный менеджер. (с)
#минуткаЮмора
#минуткаЮмора
Нефинансовая мотивация - бэджики
У нас в компании есть специальный портал для выдачи бэджиков сотрудникам - обычный цифровой бэджик: дизайнерская красивая картинка, можно прикрепить небольшой текст и виден отправитель, а так же можно уведомить коллег и прямого менеджера о том, что выдан бэджик, есть страница где отображаются все бэджи сотрудника.
Так вот, если вы думаете, что получить бэджик - детские игры в песочнице и не имеет ничего общего с мотивацией, то вы глубоко ошибаетесь.
Однажды я выдал бэджик своему прямому менеджеру потому, что он сидел со мной пару часов и помогал настраивать отчёты, которые потом мы использовали для улучшения процессов стафинга и найма персонала. Он помог сэкономить моё время и объяснил как работает наш репортинг тул - человек заслужил, чтобы его похвалили. Я зашёл в портал, написал пару строк и нажал кнопку выдать бэдж. Потом во время одного из личных разговоров: “знаешь я получил бэдж от тебя и чёрт возьми это было приятно, я даже не ожидал”, и это директор у которого в подчинении несколько сот человек.
Ещё один случай. Делаем ревью присейла и надо проверить стоимость для индийской и польской локации. Из-за условий сделки мы не можем использовать рейт карту, а только себестоимость. Все финансовые расчёты делались коллегами в США, где на момент событий глубокая ночь. А ревью должно быть закончено срочно и результаты нужны к раннему утру в Америке. Что делать? Просим о помощи коллективный разум - у нас есть чат для экстренных вопросов - где собраны менеджеры из разных стран. Откликается главный ПМ всея Индии, 15 минут и цифры проверены. Выдал вице-президенту бэджик. Получаю сообщение в личку: “спасибо, приятно”.
И казалось бы - это люди на высоких должностях, они высоко забрались по карьерной лестнице и не первый год в бизнесе, но даже им приятно получать такую казалось бы мелочь, знак внимания. Это подтверждает ещё раз - простейшая похвала работает не только с джунами.
Поэтому когда есть возможность и когда заслуженно, похвалите подчинённых, коллег или начальство и сделайте это публично.
Хорошее слово и кошке приятно. (с)
Но это не отменяет финансовую мотивацию, а лишь дополняет её. 😉
У нас в компании есть специальный портал для выдачи бэджиков сотрудникам - обычный цифровой бэджик: дизайнерская красивая картинка, можно прикрепить небольшой текст и виден отправитель, а так же можно уведомить коллег и прямого менеджера о том, что выдан бэджик, есть страница где отображаются все бэджи сотрудника.
Так вот, если вы думаете, что получить бэджик - детские игры в песочнице и не имеет ничего общего с мотивацией, то вы глубоко ошибаетесь.
Однажды я выдал бэджик своему прямому менеджеру потому, что он сидел со мной пару часов и помогал настраивать отчёты, которые потом мы использовали для улучшения процессов стафинга и найма персонала. Он помог сэкономить моё время и объяснил как работает наш репортинг тул - человек заслужил, чтобы его похвалили. Я зашёл в портал, написал пару строк и нажал кнопку выдать бэдж. Потом во время одного из личных разговоров: “знаешь я получил бэдж от тебя и чёрт возьми это было приятно, я даже не ожидал”, и это директор у которого в подчинении несколько сот человек.
Ещё один случай. Делаем ревью присейла и надо проверить стоимость для индийской и польской локации. Из-за условий сделки мы не можем использовать рейт карту, а только себестоимость. Все финансовые расчёты делались коллегами в США, где на момент событий глубокая ночь. А ревью должно быть закончено срочно и результаты нужны к раннему утру в Америке. Что делать? Просим о помощи коллективный разум - у нас есть чат для экстренных вопросов - где собраны менеджеры из разных стран. Откликается главный ПМ всея Индии, 15 минут и цифры проверены. Выдал вице-президенту бэджик. Получаю сообщение в личку: “спасибо, приятно”.
И казалось бы - это люди на высоких должностях, они высоко забрались по карьерной лестнице и не первый год в бизнесе, но даже им приятно получать такую казалось бы мелочь, знак внимания. Это подтверждает ещё раз - простейшая похвала работает не только с джунами.
Поэтому когда есть возможность и когда заслуженно, похвалите подчинённых, коллег или начальство и сделайте это публично.
Хорошее слово и кошке приятно. (с)
Но это не отменяет финансовую мотивацию, а лишь дополняет её. 😉