ИСТОРИЯ О ТОМ, КАК МЫ SCRUM ВНЕДРЯЛИ
В далеком теперь уже 21 году случилась у нас в компании Lineate реорганизация. И стал я тогда руководителем всего продакшна. А вместе с задачей по построению новой оргструктуры была нам с командой поставлена задача внедрить везде Scrum.
А команда тогда у нас была шикарная, может быть даже лучшая для меня. Но это тема отдельного большого поста 🙂
Scrum - стильно, модно, молодежно. Сложновато, но интересно. И плюсов от такого изменения не счесть. Выглядит перспективно!
Но во всей этой ложке меда была нормальная такая бочка дегтя: у нас было больше 30 проектов, и все абсолютно разные. Были проекты поддержки на пару часов в неделю одного инженера. Были ватерфольные фиксбиды с командой в 15 человек. Были средненькие T&M-ы на 5-7 человек. Очевидно, взять и сходу раскатать одинаковую схему Scrum-а на все проекты не получится. Пришлось креативить.
Это не инструкция, как надо внедрять Scrum. И не рассказ о новом франкенштейне на базе Scrum-а, которого мы придумали. Это, скорее, история о том, что все решения руководства надо пропускать через голову. И ваша задача, как руководителя на своем уровне, не слепо выполнять приказы, а быть консультантом, адаптировать идеи к реальности, при этом попадая в ожидания руководства.
Так вот, история. Мы пошли к нашему руководству и стали выяснять, почему и зачем Scrum. Оказалось, что нужен не так чтобы прям Scrum, но нужен удобный механизм для контроля и управления скоростью работы команды и каждого человека в ней, который будет очевиден и понятен всем в индустрии. А Scrum это умел из коробки. И любой человек в IT уже знает про Scrum. Словом, идеальный кандидат.
Неидеальными были только наши проекты. Поэтому мы взяли кусок Scrum-а, который позволял нам следить за скоростью и как-то прогнозировать успех проекта, отбросили все ненужное, и стали раскатывать по проектам. По сути, нам нужны были спринты, сторипоинты, велосити, коммитмент, объем бэклога. Остальное - опционально.
Да да, знаю. В умных книжках пишут, что Scrum можно внедрять только полностью, иначе он не работает и блаблабла. Все так. Иначе Scrum, действительно, работать не будет. Но нам нужен был не Scrum, а его часть, поэтому все получилось.
Спустя полгода мы развернули наш Scrum уже на 90% проектов и смогли сильно выровнять эти проекты, сделав заказчиков счастливыми. Наш продакшн стал управляемым и эффективным, а руководство получило метрики контроля за ситуацией, как в разрезе всей компании, так и в разрезе каждого проекта и даже сотрудника.
А реальный результат мы увидели уже в 22 году. Когда компания была сильно отвлечена на вопросы релокации и масштабирования, а продакшн продолжал работать, как надежный механизм, поставляя заказчикам решения и делая их, все так же, счастливыми. Во многом этот наш внедренный Scrum сильно помог тогда.
Мораль - понимайте ожидания вашего руководства и не бойтесь креативить. Менеджер - не безмолвный исполнитель, а творец, создатель. И инициативность, на самом деле, ценится.
В далеком теперь уже 21 году случилась у нас в компании Lineate реорганизация. И стал я тогда руководителем всего продакшна. А вместе с задачей по построению новой оргструктуры была нам с командой поставлена задача внедрить везде Scrum.
А команда тогда у нас была шикарная, может быть даже лучшая для меня. Но это тема отдельного большого поста 🙂
Scrum - стильно, модно, молодежно. Сложновато, но интересно. И плюсов от такого изменения не счесть. Выглядит перспективно!
Но во всей этой ложке меда была нормальная такая бочка дегтя: у нас было больше 30 проектов, и все абсолютно разные. Были проекты поддержки на пару часов в неделю одного инженера. Были ватерфольные фиксбиды с командой в 15 человек. Были средненькие T&M-ы на 5-7 человек. Очевидно, взять и сходу раскатать одинаковую схему Scrum-а на все проекты не получится. Пришлось креативить.
Это не инструкция, как надо внедрять Scrum. И не рассказ о новом франкенштейне на базе Scrum-а, которого мы придумали. Это, скорее, история о том, что все решения руководства надо пропускать через голову. И ваша задача, как руководителя на своем уровне, не слепо выполнять приказы, а быть консультантом, адаптировать идеи к реальности, при этом попадая в ожидания руководства.
Так вот, история. Мы пошли к нашему руководству и стали выяснять, почему и зачем Scrum. Оказалось, что нужен не так чтобы прям Scrum, но нужен удобный механизм для контроля и управления скоростью работы команды и каждого человека в ней, который будет очевиден и понятен всем в индустрии. А Scrum это умел из коробки. И любой человек в IT уже знает про Scrum. Словом, идеальный кандидат.
Неидеальными были только наши проекты. Поэтому мы взяли кусок Scrum-а, который позволял нам следить за скоростью и как-то прогнозировать успех проекта, отбросили все ненужное, и стали раскатывать по проектам. По сути, нам нужны были спринты, сторипоинты, велосити, коммитмент, объем бэклога. Остальное - опционально.
Да да, знаю. В умных книжках пишут, что Scrum можно внедрять только полностью, иначе он не работает и блаблабла. Все так. Иначе Scrum, действительно, работать не будет. Но нам нужен был не Scrum, а его часть, поэтому все получилось.
Спустя полгода мы развернули наш Scrum уже на 90% проектов и смогли сильно выровнять эти проекты, сделав заказчиков счастливыми. Наш продакшн стал управляемым и эффективным, а руководство получило метрики контроля за ситуацией, как в разрезе всей компании, так и в разрезе каждого проекта и даже сотрудника.
А реальный результат мы увидели уже в 22 году. Когда компания была сильно отвлечена на вопросы релокации и масштабирования, а продакшн продолжал работать, как надежный механизм, поставляя заказчикам решения и делая их, все так же, счастливыми. Во многом этот наш внедренный Scrum сильно помог тогда.
Мораль - понимайте ожидания вашего руководства и не бойтесь креативить. Менеджер - не безмолвный исполнитель, а творец, создатель. И инициативность, на самом деле, ценится.
👍14
ПРО МЕНТОРИНГ И КОУЧИНГ
На днях готовил доклад по менторингу, и подумалось вот о чем.
Кстати, доклад для митапа DevRel Meetup SPb #3, будет 17 марта в баре на Ваське. Приходите, будет 4 разных и интересных темы на повестке. Ссылочка на мероприятие вот https://www.meetup.com/devrel-spb/events/291069709/
Так вот, готовил доклад, и один из вопросов в нем касается менторинга и коучинга. А именно: может ли коучинг считаться менторингом? Или наоборот?
Тема дискуссионная. Мое личное мнение - нет. И основная ценность ментора как раз в том, что у него ЕСТЬ собственные знания и опыт, которыми он МОЖЕТ и ДОЛЖЕН делиться. Коучинг же про поиск ответа ВНУТРИ себя. Коуч НЕ ДОЛЖЕН давать советов, только направлять.
Но коучинг активно используется менторами, это правда. Как инструмент для прояснения запроса. Потому что часто вопрос, с которым приходит человек на сессию довольно поверхностный, а для решения его проблемы требуется "закапываться" глубже. Уж простите за абстракцию.
Менторинг - это долгосрочный процесс, это про развитие. Цель ментора - научить, "дать удочку, а не рыбу". Поэтому приходится погружаться в каждый кейс.
А бывают запросы на "рыбу", без "удочки". Конкретная проблема с конкретным решением. И решается она, зачастую за 1-2 часа сессии. Но это уже не совсем менторинг, скорее консалтинг/эдвайзинг. Тут и коучинг будет излишним, все и так понятно.
Согласны? Подискутируем? Делитесь своими мнениями, обсудим.
На днях готовил доклад по менторингу, и подумалось вот о чем.
Кстати, доклад для митапа DevRel Meetup SPb #3, будет 17 марта в баре на Ваське. Приходите, будет 4 разных и интересных темы на повестке. Ссылочка на мероприятие вот https://www.meetup.com/devrel-spb/events/291069709/
Так вот, готовил доклад, и один из вопросов в нем касается менторинга и коучинга. А именно: может ли коучинг считаться менторингом? Или наоборот?
Тема дискуссионная. Мое личное мнение - нет. И основная ценность ментора как раз в том, что у него ЕСТЬ собственные знания и опыт, которыми он МОЖЕТ и ДОЛЖЕН делиться. Коучинг же про поиск ответа ВНУТРИ себя. Коуч НЕ ДОЛЖЕН давать советов, только направлять.
Но коучинг активно используется менторами, это правда. Как инструмент для прояснения запроса. Потому что часто вопрос, с которым приходит человек на сессию довольно поверхностный, а для решения его проблемы требуется "закапываться" глубже. Уж простите за абстракцию.
Менторинг - это долгосрочный процесс, это про развитие. Цель ментора - научить, "дать удочку, а не рыбу". Поэтому приходится погружаться в каждый кейс.
А бывают запросы на "рыбу", без "удочки". Конкретная проблема с конкретным решением. И решается она, зачастую за 1-2 часа сессии. Но это уже не совсем менторинг, скорее консалтинг/эдвайзинг. Тут и коучинг будет излишним, все и так понятно.
Согласны? Подискутируем? Делитесь своими мнениями, обсудим.
👍4
ВОПРОСНИК#4
Вопрос про процессы в IT, конкретно – про роль архитектора.
Вопрос:
Какова роль архитектора в небольшой команде (10-15)? Насколько этот архитектор будет эффективен в середине или в конце проекта (если берем стандартный цикл разработки, где конец проекта это выпуск в прод и отдача его на поддержку)?
Насколько эффективно будет выполнять роль архитектора одному из back/front или вообще аналитику?
Ответ:
Основная роль архитектора – обеспечить оптимальное соответствие продукта и требований. Соответственно, работа архитектора обычно необходима и до старта проекта, во время проекта, и даже после завершения проекта.
До старта проект – это оценка и проектирование той самой архитектуры. И здесь главный нюанс – специфика проекта. Если проект, скорее, технологический, то роль архитектора уходит к технарю. Если проект больше про бизнес, то основной архитектурой решения занимается как раз аналитик, а техническую архитектуру может спроектировать уже тимлид или синьорный разработчик, потому что она заведомо проще.
Бывают очень сложные проекты, где нужен и бизнес-архитектор, и технический. Но там, как правило, архитектурой будет заниматься не один человек, а целая команда. Поэтому такой пример оставим в стороне.
Во время проекта у архитектора 2 задачи:
1. Обеспечивать соответствие реализации тому плану, который он сделал. И тут вопрос даже не в каких-то инспекциях кода и супервизиях, а в принятии решений, когда реализация начинает расходиться с тем, что напроектировали вначале. А такое встречается сплошь и рядом. Архитектор решает, делаем так, а не иначе.
2. Помогать команде в экспертизе, т е закрывать собой все возникающие пробелы в знаниях и компетенциях.
И здесь также, как и на оценке: если проект про бизнес, то нужнее бизнес-архитектор, аналитик. Если проект технологический, то технарь.
После завершения проекта обычно наступает этап поддержки, обкатывания решения в проде, обучения заказчика и т п. И важную часть работы по передаче знаний выполняет снова архитектор, потому что никто лучше него не опишет архитектуру и какие-то нюансы работы системы.
Ну и отвечая на последний вопрос, кто это будет: фронт, бек или аналитик. Это должен быть человек, способный выполнять роль архитектора, а именно обеспечивать оптимальное соответствие продукта с требованиями. Если на конкретном проекте человек справляется с этой задачей, то он будет эффективен, и не важно, в чем он больше эксперт.
Надеюсь, получилось ответить на вопрос.
P.S. Задавайте новые вопросы: в комментах, в личку, в анонимную форму https://forms.gle/yguM6swyLCvFbJ858
Вопрос про процессы в IT, конкретно – про роль архитектора.
Вопрос:
Какова роль архитектора в небольшой команде (10-15)? Насколько этот архитектор будет эффективен в середине или в конце проекта (если берем стандартный цикл разработки, где конец проекта это выпуск в прод и отдача его на поддержку)?
Насколько эффективно будет выполнять роль архитектора одному из back/front или вообще аналитику?
Ответ:
Основная роль архитектора – обеспечить оптимальное соответствие продукта и требований. Соответственно, работа архитектора обычно необходима и до старта проекта, во время проекта, и даже после завершения проекта.
До старта проект – это оценка и проектирование той самой архитектуры. И здесь главный нюанс – специфика проекта. Если проект, скорее, технологический, то роль архитектора уходит к технарю. Если проект больше про бизнес, то основной архитектурой решения занимается как раз аналитик, а техническую архитектуру может спроектировать уже тимлид или синьорный разработчик, потому что она заведомо проще.
Бывают очень сложные проекты, где нужен и бизнес-архитектор, и технический. Но там, как правило, архитектурой будет заниматься не один человек, а целая команда. Поэтому такой пример оставим в стороне.
Во время проекта у архитектора 2 задачи:
1. Обеспечивать соответствие реализации тому плану, который он сделал. И тут вопрос даже не в каких-то инспекциях кода и супервизиях, а в принятии решений, когда реализация начинает расходиться с тем, что напроектировали вначале. А такое встречается сплошь и рядом. Архитектор решает, делаем так, а не иначе.
2. Помогать команде в экспертизе, т е закрывать собой все возникающие пробелы в знаниях и компетенциях.
И здесь также, как и на оценке: если проект про бизнес, то нужнее бизнес-архитектор, аналитик. Если проект технологический, то технарь.
После завершения проекта обычно наступает этап поддержки, обкатывания решения в проде, обучения заказчика и т п. И важную часть работы по передаче знаний выполняет снова архитектор, потому что никто лучше него не опишет архитектуру и какие-то нюансы работы системы.
Ну и отвечая на последний вопрос, кто это будет: фронт, бек или аналитик. Это должен быть человек, способный выполнять роль архитектора, а именно обеспечивать оптимальное соответствие продукта с требованиями. Если на конкретном проекте человек справляется с этой задачей, то он будет эффективен, и не важно, в чем он больше эксперт.
Надеюсь, получилось ответить на вопрос.
P.S. Задавайте новые вопросы: в комментах, в личку, в анонимную форму https://forms.gle/yguM6swyLCvFbJ858
Google Docs
Напиши свой вопрос / кейс
Форма полностью анонимная, но вы можете подписаться для более адресного ответа
👍4
ПРО ЦЕЛИ
Целеполагание - важная вещь! Иначе теряешься, куда ты и зачем. И это важно и на уровне компании, и на уровне самого себя любимого.
Про то, как ставить цели и планировать, написано очень и очень много. А это значит, что единого универсального рецепта не придумали. Ничего удивительного. Как и любой таймменеджмент и лайфменеджмент, здесь все индивидуально.
Расскажу про свою версию, которую я обкатал на личных целях и на целях компании в этом году.
В основе лежит мой любимый SOSTAC. Это модель, которая пришла к нам из маркетинга, преследующая задачу соединить стратегические цели с ежедневной рутиной. И с этим она прекрасно справляется.
Из чего состоит SOSTAC:
S – Situation analysis → Анализ текущей ситуации, где мы находимся
O – Objectives → Цели, к которым мы должны прийти
S – Strategy → Стратегия, как мы собираемся достичь цели
T – Tactics → Тактика/инструменты, которые мы будем использовать
A – Actions → Конкретные действия, задачи и сроки
С – Control → Контроль, как и по каким показателям мы поймем, что достигли цели или отклонились от курса
А теперь что внутри. Разберу для личных целей, потому что для целей компании получается посложнее, получится слишком много букв.
Анализ ситуации - тут все понятно. Для личных целей хорошо подходит колесо баланса. Строим, понимаем, осознаем.
Цели - вытекают из колеса баланса. Тут может быть 2 подхода: закрывать самые большие пробелы или фокусироваться на самых важных составляющих. Кому какой ближе. А сами цели мне нравится формулировать через OKR-ы. Получается воодушевляющая и мотивирующая формулировка цели, как девиз, с которой хочется просыпаться по утрам, например "в здорово теле - здоровый дух". И для нее несколько измеримых и засмартованных ключевых результатов, которые и раскрывают, а что это все значит для вас: вылеченные старые болезни, комфортный вес, спорт и т п.
Стратегия - верхнеуровневый план, как достигать цели. По каждой цели! Главное в стратегии - некоторая киллерфича, почему именно эта стратегия приведет именно вас к именно этой цели.
Тактика - здесь уже расшифровка стратегии. Например, если вы ставите себе целью подтянуть здоровье, стратегией будет заняться спортом. Тогда в тактике следует прописывать, каким спортом, может несколько вариантов, которые вы попробуете и выберите. И т д.
Действия - а вот здесь в дело вступает декомпозиция. В моей схеме действия - это цели на более короткий период, например на квартал. Они должны приводить к достижению основных годовых целей, с поправкой на достижимость и некоторую реальность. И обязательно с учетом стратегии и тактики, над которыми вы поработали! Цели на более короткие периоды тоже можно расписывать по SOSTAC, но это, на мой взгляд, уже перебор.
Контроль - снова декомпозиция. По квартальным целям расписываем, чего мы хотим добиться каждый месяц. Это и будет для нас понятным индикатором, насколько мы, что называется, "on track" с целью, или отклонились от плана.
Зачастую результаты месяца - это уже некоторые проекты, которые легко разбиваются на задачи, понятные и осязаемые. Задачи, которые можно брать и делать. Я вся это схема целеполагания через SOSTAC наглядно показывает, что очень и очень многого можно добиться, если просто оторвать свою самую тяжелую точку с дивана.
Попробуйте! И расскажите о результатах 🙂
Целеполагание - важная вещь! Иначе теряешься, куда ты и зачем. И это важно и на уровне компании, и на уровне самого себя любимого.
Про то, как ставить цели и планировать, написано очень и очень много. А это значит, что единого универсального рецепта не придумали. Ничего удивительного. Как и любой таймменеджмент и лайфменеджмент, здесь все индивидуально.
Расскажу про свою версию, которую я обкатал на личных целях и на целях компании в этом году.
В основе лежит мой любимый SOSTAC. Это модель, которая пришла к нам из маркетинга, преследующая задачу соединить стратегические цели с ежедневной рутиной. И с этим она прекрасно справляется.
Из чего состоит SOSTAC:
S – Situation analysis → Анализ текущей ситуации, где мы находимся
O – Objectives → Цели, к которым мы должны прийти
S – Strategy → Стратегия, как мы собираемся достичь цели
T – Tactics → Тактика/инструменты, которые мы будем использовать
A – Actions → Конкретные действия, задачи и сроки
С – Control → Контроль, как и по каким показателям мы поймем, что достигли цели или отклонились от курса
А теперь что внутри. Разберу для личных целей, потому что для целей компании получается посложнее, получится слишком много букв.
Анализ ситуации - тут все понятно. Для личных целей хорошо подходит колесо баланса. Строим, понимаем, осознаем.
Цели - вытекают из колеса баланса. Тут может быть 2 подхода: закрывать самые большие пробелы или фокусироваться на самых важных составляющих. Кому какой ближе. А сами цели мне нравится формулировать через OKR-ы. Получается воодушевляющая и мотивирующая формулировка цели, как девиз, с которой хочется просыпаться по утрам, например "в здорово теле - здоровый дух". И для нее несколько измеримых и засмартованных ключевых результатов, которые и раскрывают, а что это все значит для вас: вылеченные старые болезни, комфортный вес, спорт и т п.
Стратегия - верхнеуровневый план, как достигать цели. По каждой цели! Главное в стратегии - некоторая киллерфича, почему именно эта стратегия приведет именно вас к именно этой цели.
Тактика - здесь уже расшифровка стратегии. Например, если вы ставите себе целью подтянуть здоровье, стратегией будет заняться спортом. Тогда в тактике следует прописывать, каким спортом, может несколько вариантов, которые вы попробуете и выберите. И т д.
Действия - а вот здесь в дело вступает декомпозиция. В моей схеме действия - это цели на более короткий период, например на квартал. Они должны приводить к достижению основных годовых целей, с поправкой на достижимость и некоторую реальность. И обязательно с учетом стратегии и тактики, над которыми вы поработали! Цели на более короткие периоды тоже можно расписывать по SOSTAC, но это, на мой взгляд, уже перебор.
Контроль - снова декомпозиция. По квартальным целям расписываем, чего мы хотим добиться каждый месяц. Это и будет для нас понятным индикатором, насколько мы, что называется, "on track" с целью, или отклонились от плана.
Зачастую результаты месяца - это уже некоторые проекты, которые легко разбиваются на задачи, понятные и осязаемые. Задачи, которые можно брать и делать. Я вся это схема целеполагания через SOSTAC наглядно показывает, что очень и очень многого можно добиться, если просто оторвать свою самую тяжелую точку с дивана.
Попробуйте! И расскажите о результатах 🙂
👍4🔥2
Написал небольшую статью про правильную постановку задач и контроль с учетом особенностей сотрудника https://habr.com/ru/post/718114/
Хабр
Как “заставить” сотрудников работать
Вы ставите задачи, но их не делают. Или делают, но не так. Или так, но слишком долго. Обычный день обычного тимлида или руководителя. Почему так происходит?...
❤4👍2
ПРО СТРАТЕГИЮ ГОЛУБОГО ОКЕАНА
Сегодня немного о высоком - о стратегии.
Есть такая стратегия "голубого океана". Про нее даже книги пишут. Многие считают, что это главная "серебряная пуля" в бизнесе. Идея в том, чтобы придумать продукт, которого еще не было. Чтобы занять нишу рынка, которой раньше не существовало. Чтобы там потом без конкуренции расти и развиваться.
Яркий пример - компания Apple. Придумали iPod - дали толчок развитию медиаиндустрии. Придумали iPhone - стартанули индустрию смартфонов. Придумали AirPods - теперь на полках только такие наушники кругом. В общем, законодатели.
Но есть и прямо противоположное мнение, которое часто слышишь от опытных предпринимателей (не уровня Джобса и Гейтса, а обычных, которые по земле ходят). Они утверждают, что не надо ничего изобретать. Наоборот, надо смотреть на рынок, что ему нужно, и давать именно это. Простой пример - если открыть цветочный магазин рядом с другим успешным цветочным магазином, у вас будут покупатели. Если открыть магазин там, где его нет - не факт.
И как это все понимать? Кто прав?
На самом деле, здесь нет никакого противоречия. Бизнес работает по вполне четким законам. Да, здесь нужно много креатива. Но это не отменяет того, что бизнес - это система. И чтобы система работала, нужно делать вполне конкретные действия. И если на рынке есть спрос на цветы в определенной локации, то надо открывать свой магазин именно там. Если вы хотите добиться успеха, тогда это верный путь.
А если вы хотите не просто успеха, а сверхуспеха, то нужно изобретать что-то новое. Но представьте только, сколько ресурсов потратил тот же Apple на создание любого своего продукта? Такие ресурсы есть у среднестатистического бизнеса? Чаще всего, нет.
Отсюда и простой вывод: стратегия "голубого океана" - отличная возможность для развития, но только если вы исчерпали все остальные возможности, или если вы хотите добиться сверхрезультатов. Но для сверхрезультатов нужны и сверхресурсы. А если таковых нет - не думайте о "голубом океана". Анализируйте свой рынок и ищите место на нем.
Сегодня немного о высоком - о стратегии.
Есть такая стратегия "голубого океана". Про нее даже книги пишут. Многие считают, что это главная "серебряная пуля" в бизнесе. Идея в том, чтобы придумать продукт, которого еще не было. Чтобы занять нишу рынка, которой раньше не существовало. Чтобы там потом без конкуренции расти и развиваться.
Яркий пример - компания Apple. Придумали iPod - дали толчок развитию медиаиндустрии. Придумали iPhone - стартанули индустрию смартфонов. Придумали AirPods - теперь на полках только такие наушники кругом. В общем, законодатели.
Но есть и прямо противоположное мнение, которое часто слышишь от опытных предпринимателей (не уровня Джобса и Гейтса, а обычных, которые по земле ходят). Они утверждают, что не надо ничего изобретать. Наоборот, надо смотреть на рынок, что ему нужно, и давать именно это. Простой пример - если открыть цветочный магазин рядом с другим успешным цветочным магазином, у вас будут покупатели. Если открыть магазин там, где его нет - не факт.
И как это все понимать? Кто прав?
На самом деле, здесь нет никакого противоречия. Бизнес работает по вполне четким законам. Да, здесь нужно много креатива. Но это не отменяет того, что бизнес - это система. И чтобы система работала, нужно делать вполне конкретные действия. И если на рынке есть спрос на цветы в определенной локации, то надо открывать свой магазин именно там. Если вы хотите добиться успеха, тогда это верный путь.
А если вы хотите не просто успеха, а сверхуспеха, то нужно изобретать что-то новое. Но представьте только, сколько ресурсов потратил тот же Apple на создание любого своего продукта? Такие ресурсы есть у среднестатистического бизнеса? Чаще всего, нет.
Отсюда и простой вывод: стратегия "голубого океана" - отличная возможность для развития, но только если вы исчерпали все остальные возможности, или если вы хотите добиться сверхрезультатов. Но для сверхрезультатов нужны и сверхресурсы. А если таковых нет - не думайте о "голубом океана". Анализируйте свой рынок и ищите место на нем.
👍8
Коллеги, хочу напомнить про Вопросник!
Задавайте вопросы, я подробно их разберу и опубликую ответ.
Вопрос по любой тематике. Но ценны будут ответы про менеджмент в IT 🙂 Про остальное с радостью порассуждаю.
Можете писать в личку @ilya_prakht, можете сюда в комментарии, можете в анонимную форму https://forms.gle/yguM6swyLCvFbJ858
Задавайте вопросы, я подробно их разберу и опубликую ответ.
Вопрос по любой тематике. Но ценны будут ответы про менеджмент в IT 🙂 Про остальное с радостью порассуждаю.
Можете писать в личку @ilya_prakht, можете сюда в комментарии, можете в анонимную форму https://forms.gle/yguM6swyLCvFbJ858
Google Docs
Напиши свой вопрос / кейс
Форма полностью анонимная, но вы можете подписаться для более адресного ответа
ИСТОРИЯ О ТОМ, КАК МЫ SCRUM ВНЕДРЯЛИ #2
Небольшой сиквел к истории о нашем внедрении Scrum в Lineate, о котором писал ранее. В этот раз расскажу про наш процесс контроля состояния проектов, и как Scrum повлиял на него.
Начну с этого самого процесса. Еженедельно мы собирались со всеми деливери-менеджерами и топ-менеджментом компании, чтобы обсудить, что происходит с нашими проектами. Событие это называлось Portfolio Review - достаточно распространенный подход, многие его используют, и мы не были исключением.
На этой встрече мы от лица продакшена рапортовали о состоянии проекта, награждая его каким-то цветным значком, и немного расшифровывали, что это все значит. Значков было 4, названия их говорящие, так что не запутаешься: critical, warning, good, uncertain. Критикалы - плохо, ворны - не очень, но ситуация под контролем, гуд - значит мы в порядке, а ансертн (как же странно это пишется по-русски) значит, что информации нам недостаточно.
Были определенные правила выставления этих статусов: по наличию кризисов, по просроченным дедлайнам и т д. И вот, с появлением Scrum в нашей продакшенской жизни, появились и интересные цифры, которые нашли отражение в статусах проектов. Помните, я как раз рассказывал, зачем нам нужен был Scrum, и что из него мы внедрили? Вот это все и работало здесь: commitment, velocity, backlog size.
Львиная доля наших проектов показывали одну и ту же картинку из недели в неделю: велосити постоянно было ниже коммитмента. С одной стороны, это ок для Scrum-а, некий коридор нужно закладывать. Это правда. Но расхождения были серьезные, больше 50%, и это происходило постоянно.
Да, Scrum помог и подсветил нам проблемные точки. Хотя бы этим он уже окупил все наши страдания по его внедрению)
Пока мы разбирались, в чем же дело (а причин там много, и на каждом проекте, по сути, они были свои), наш топ-менеджмент не хотел ждать. И мы получили новую инструкцию по определению проектных статусов: если велосити ниже 80% коммитмента - это warning, если ниже 50% - critical.
Ох как же неудобно нам стало жить с этим. Вместо типичных 1-2 критикалов в неделю, мы стали показывать до 10 критов! И ведь за каждый надо было отчитываться, показать план, а что мы делаем, чтобы проект вернуть к жизни, и т д. Пришлось поработать нашим деливери-менеджерам...
Мы ворчали, жаловались, что Portfolio Review превратился в какой-то шум, теперь непонятно, что на самом деле с проектом, и как вообще можно на это ориентироваться и все в этом духе. Даже пытались внедрить штуку аля "реальный статус проекта", но не получилось (спойлер - и хорошо).
Но в итоге это все дало свои плоды. Буквально за квартал количество критикалов стало 3-4 в неделю, а по прошествии еще одного квартала мы снова стали показывать типичные 1-2 критикала. И при этом, команды работали, выдавали результат, и проекты стали управляемыми и прогнозируемыми. Прозрачность была на таком уровне, как вода в Адриатическом море. Именно этого хотел от нас топ-менеджмент. Да и мы сами, честно говоря, очень облегчили себе жизнь после такой трансформации.
Мораль этой истории. Люди делают хорошо то, что будут проверять. Это касается и линейных сотрудников, и менеджеров любого уровня. И если вы хотите повысить приоритет и сфокусировать работу сотрудников на какой-то проблеме или какой-то задаче, то повысьте, в первую очередь, свое внимание к этому вопросу. Это даст плоды. Это может потребовать и от вас уделять время проблеме, но результат того стоит, поверьте.
Небольшой сиквел к истории о нашем внедрении Scrum в Lineate, о котором писал ранее. В этот раз расскажу про наш процесс контроля состояния проектов, и как Scrum повлиял на него.
Начну с этого самого процесса. Еженедельно мы собирались со всеми деливери-менеджерами и топ-менеджментом компании, чтобы обсудить, что происходит с нашими проектами. Событие это называлось Portfolio Review - достаточно распространенный подход, многие его используют, и мы не были исключением.
На этой встрече мы от лица продакшена рапортовали о состоянии проекта, награждая его каким-то цветным значком, и немного расшифровывали, что это все значит. Значков было 4, названия их говорящие, так что не запутаешься: critical, warning, good, uncertain. Критикалы - плохо, ворны - не очень, но ситуация под контролем, гуд - значит мы в порядке, а ансертн (как же странно это пишется по-русски) значит, что информации нам недостаточно.
Были определенные правила выставления этих статусов: по наличию кризисов, по просроченным дедлайнам и т д. И вот, с появлением Scrum в нашей продакшенской жизни, появились и интересные цифры, которые нашли отражение в статусах проектов. Помните, я как раз рассказывал, зачем нам нужен был Scrum, и что из него мы внедрили? Вот это все и работало здесь: commitment, velocity, backlog size.
Львиная доля наших проектов показывали одну и ту же картинку из недели в неделю: велосити постоянно было ниже коммитмента. С одной стороны, это ок для Scrum-а, некий коридор нужно закладывать. Это правда. Но расхождения были серьезные, больше 50%, и это происходило постоянно.
Да, Scrum помог и подсветил нам проблемные точки. Хотя бы этим он уже окупил все наши страдания по его внедрению)
Пока мы разбирались, в чем же дело (а причин там много, и на каждом проекте, по сути, они были свои), наш топ-менеджмент не хотел ждать. И мы получили новую инструкцию по определению проектных статусов: если велосити ниже 80% коммитмента - это warning, если ниже 50% - critical.
Ох как же неудобно нам стало жить с этим. Вместо типичных 1-2 критикалов в неделю, мы стали показывать до 10 критов! И ведь за каждый надо было отчитываться, показать план, а что мы делаем, чтобы проект вернуть к жизни, и т д. Пришлось поработать нашим деливери-менеджерам...
Мы ворчали, жаловались, что Portfolio Review превратился в какой-то шум, теперь непонятно, что на самом деле с проектом, и как вообще можно на это ориентироваться и все в этом духе. Даже пытались внедрить штуку аля "реальный статус проекта", но не получилось (спойлер - и хорошо).
Но в итоге это все дало свои плоды. Буквально за квартал количество критикалов стало 3-4 в неделю, а по прошествии еще одного квартала мы снова стали показывать типичные 1-2 критикала. И при этом, команды работали, выдавали результат, и проекты стали управляемыми и прогнозируемыми. Прозрачность была на таком уровне, как вода в Адриатическом море. Именно этого хотел от нас топ-менеджмент. Да и мы сами, честно говоря, очень облегчили себе жизнь после такой трансформации.
Мораль этой истории. Люди делают хорошо то, что будут проверять. Это касается и линейных сотрудников, и менеджеров любого уровня. И если вы хотите повысить приоритет и сфокусировать работу сотрудников на какой-то проблеме или какой-то задаче, то повысьте, в первую очередь, свое внимание к этому вопросу. Это даст плоды. Это может потребовать и от вас уделять время проблеме, но результат того стоит, поверьте.
👍10
ВОПРОСНИК#5
Интересный вопрос про "средних сотрудников". Есть ли в этом проблема и как с ними быть.
Вопрос:
Что делать если кажется что сотрудник работает плохо, но при этом по метрикам вроде не особо плохо и не особо хорошо, все средненько и отзывы коллег нормальные. Можно не трогать и забить, но есть ощущение что что-то не так
Ответ:
Как сказали в одном фильме, "если вам что-то кажется, то, скорее всего, так оно и есть". Где-то на уровне подсознания вы видите проблему, но рационализировать ее не получается.
При анализе этого вопроса мне хочется погрузиться в коучинг. Хочется задавать много встречных вопросов.
Почему ощущение, что что-то не так? Что заставляет так думать? Что означает "работает средненько"? Какие метрики это показывают? Какие отзывы для вас "нормальные"?
В общем, мало контекста для анализа проблемы. Но порассуждать и задать вектор для решения можно.
Если считать, что перед вам действительно обычный средний сотрудник, который работает в среднем темпе, показывает средние результаты, но вас это не устраивает, то может быть 2 проблемы. Они проистекают ровно из 2 основных задач руководителя, которые на каком-то воркшопе классно сформулировал Александр Зиза: "У руководителя есть 2 основные задачи: добиться выполнения всех необходимых работ сегодня, и обеспечить возможность выполнения всех необходимых работ завтра". Тактика и стратегия.
Так вот, проблема первая - ваши завышенные ожидания и перфекционизм. Людям свойственно мерить все и всех по себе. И когда вы видите, что кто-то работает хуже, он автоматически попадает в кагорту "лоуперформеров". Это достаточно распространенное искажение для руководителей, с которым нужно бороться. И ключевой вопрос, который нужно задать себе - "средний результат, который показывает сотрудник, удовлетворяет меня или нет?" Имеется в виду то, как он делает текущие задачи. С ним вы добиваетесь выполнения работ сегодня? И если ответ "да" (а судя по приведенным вами метрикам и отзывам, так оно и есть), значит все ок, в рамках первой задачи руководителя все нормально, работаем дальше.
Вторая проблема (скорее даже не проблема, а риск) - средние результаты могут ухудшится, что поставит под сомнение работу команды в будущем. Или останутся теми же на фоне роста эффективности всей команды, что также станет якорем для общего перфоманса. И судя по всему (могу ошибаться, так как пытаюсь сделать вывод на основании 2 предложений вопроса:) именно это и вызывает вашу тревогу.
С одной стороны, сложно здесь что-либо прогнозировать в будущее. И это не ваша проблема, а проблема "вас через х дней/месяцев/лет". Тогда и данных будет больше, и решение принять будет проще.
С другой стороны, проактивность полезна, почему бы ее здесь не применить. Я бы предложил обсудить с сотрудником текущую ситуацию, обрисовать ему перспективу, что будет, если его результаты не станут лучше. Только не в форме ультиматума, а предложить свою помощь: поменторить его, уделить больше внимания его работе, своевременной обратной связи и т д. Если причина в том, что его вовлеченность не полная (например фрилансит на сторону), то в ходе разговора это, скорее всего вскроется. Ну или, как минимум, вы заставите сотрудника задуматься, стоит ли ему все оставлять как есть. Если причина в том, что это его реальный комфортный темп работы, то у вас будет шанс все исправить, не прибегая в последствии к сложным кадровым решениям.
Ну и в самом неудобном для вас варианте, сотрудник забеспокоится сам и захочет уйти. Будет ли это для вас проблемой, если он показывал довольно средние результаты? Наверное нет. Проблемой может оказаться быстро найти замену, но это уже совсем другая история.
Надеюсь, получилось ответить на вопрос.
P.S. Задавайте новые вопросы в анонимную форму https://forms.gle/yguM6swyLCvFbJ858
Интересный вопрос про "средних сотрудников". Есть ли в этом проблема и как с ними быть.
Вопрос:
Что делать если кажется что сотрудник работает плохо, но при этом по метрикам вроде не особо плохо и не особо хорошо, все средненько и отзывы коллег нормальные. Можно не трогать и забить, но есть ощущение что что-то не так
Ответ:
Как сказали в одном фильме, "если вам что-то кажется, то, скорее всего, так оно и есть". Где-то на уровне подсознания вы видите проблему, но рационализировать ее не получается.
При анализе этого вопроса мне хочется погрузиться в коучинг. Хочется задавать много встречных вопросов.
Почему ощущение, что что-то не так? Что заставляет так думать? Что означает "работает средненько"? Какие метрики это показывают? Какие отзывы для вас "нормальные"?
В общем, мало контекста для анализа проблемы. Но порассуждать и задать вектор для решения можно.
Если считать, что перед вам действительно обычный средний сотрудник, который работает в среднем темпе, показывает средние результаты, но вас это не устраивает, то может быть 2 проблемы. Они проистекают ровно из 2 основных задач руководителя, которые на каком-то воркшопе классно сформулировал Александр Зиза: "У руководителя есть 2 основные задачи: добиться выполнения всех необходимых работ сегодня, и обеспечить возможность выполнения всех необходимых работ завтра". Тактика и стратегия.
Так вот, проблема первая - ваши завышенные ожидания и перфекционизм. Людям свойственно мерить все и всех по себе. И когда вы видите, что кто-то работает хуже, он автоматически попадает в кагорту "лоуперформеров". Это достаточно распространенное искажение для руководителей, с которым нужно бороться. И ключевой вопрос, который нужно задать себе - "средний результат, который показывает сотрудник, удовлетворяет меня или нет?" Имеется в виду то, как он делает текущие задачи. С ним вы добиваетесь выполнения работ сегодня? И если ответ "да" (а судя по приведенным вами метрикам и отзывам, так оно и есть), значит все ок, в рамках первой задачи руководителя все нормально, работаем дальше.
Вторая проблема (скорее даже не проблема, а риск) - средние результаты могут ухудшится, что поставит под сомнение работу команды в будущем. Или останутся теми же на фоне роста эффективности всей команды, что также станет якорем для общего перфоманса. И судя по всему (могу ошибаться, так как пытаюсь сделать вывод на основании 2 предложений вопроса:) именно это и вызывает вашу тревогу.
С одной стороны, сложно здесь что-либо прогнозировать в будущее. И это не ваша проблема, а проблема "вас через х дней/месяцев/лет". Тогда и данных будет больше, и решение принять будет проще.
С другой стороны, проактивность полезна, почему бы ее здесь не применить. Я бы предложил обсудить с сотрудником текущую ситуацию, обрисовать ему перспективу, что будет, если его результаты не станут лучше. Только не в форме ультиматума, а предложить свою помощь: поменторить его, уделить больше внимания его работе, своевременной обратной связи и т д. Если причина в том, что его вовлеченность не полная (например фрилансит на сторону), то в ходе разговора это, скорее всего вскроется. Ну или, как минимум, вы заставите сотрудника задуматься, стоит ли ему все оставлять как есть. Если причина в том, что это его реальный комфортный темп работы, то у вас будет шанс все исправить, не прибегая в последствии к сложным кадровым решениям.
Ну и в самом неудобном для вас варианте, сотрудник забеспокоится сам и захочет уйти. Будет ли это для вас проблемой, если он показывал довольно средние результаты? Наверное нет. Проблемой может оказаться быстро найти замену, но это уже совсем другая история.
Надеюсь, получилось ответить на вопрос.
P.S. Задавайте новые вопросы в анонимную форму https://forms.gle/yguM6swyLCvFbJ858
Google Docs
Напиши свой вопрос / кейс
Форма полностью анонимная, но вы можете подписаться для более адресного ответа
👍8
СИСТЕМНЫЙ ОТВЕТ НА НЕСИСТЕМНЫЙ ВОПРОС
По ходу своей тренерской деятельности часто получаю запросы вида "сделай курс/доклад/презентацию про НЕЧТО". Наверняка, и вы такие задачи получаете. Про презентации так уж точно.
И все легко и просто, когда НЕЧТО - одно или два слова. Например, сделать презентацию по результатам продаж за январь. Или сделать доклад про правильный 1/1. Или даже сделать курс по подготовке к переговорам.
Здесь работает декомпозиция: разбиваем НЕЧТО на темы, далее на вопросы, потом на тезисы. И у вас хороший системный материал. Все четко и по полочкам.
Хуже, когда НЕЧТО - это список вопросов. Например, рассказать про гибкие методологии, метрики, примеры задач сертификации PMI и управление рисками. Здесь уже так не получится.
Нет, конечно можно использовать этот список слов как набор тем, далее по известному алгоритму разбить на вопросы, тезисы. Но получится каша. Каша-малаша. И заказчик, не смотря на то, что он хотел осветить именно эти темы, останется недовольным. Потому что непонятно, картинка не сложится.
В таких случаях приходится включить немножко методолога и разбираться.
Во-первых, уточнить запрос, а что именно ваш заказчик хочет получить от этих тем. Потому как, если запрос несистемный, то очень вероятно, что он сыроват, и заказчик хочет немного другого. Просто не проработал еще до конца. Эти подробности стоит выяснить.
Во-вторых, сделать обратный шаг и заняться композицией. В какие общие рубрики/тематики можно сгруппировать все эти запросы, что их объединяет, и т д. Получится некоторая структура модулей, о чем нужно будет рассказывать. В примере выше явно напрашиваются темы про проектные методологии (все, не только Agile), области управления проектами (причем, я бы разбил на планирование и ведение проекта), метрики и инструменты контроля (опять же по всем методологиям и фреймворкам, особенности их использования) и практические примеры/кейсы.
В результате этих 2 шагов запрос проясняется, и можно возвращаться к обычной декомпозиции на темы, вопросы, тезисы. И у вас снова получится хороший структурированный материал.
Да, не каждому нужно делать курсы и доклады. Во всяком случае, не каждый день, или даже месяц. Но повторюсь, это правило работает и для простой презентации или отчета руководителю. Ведь мы хотим своим материалом удовлетворить руководителя, правда?
А ключ к пониманию вашей презентации - простота и система. Поэтому излюбленным инструментом всех консалтеров и аналитиков являются матрицы 2 на 2 🙂
P.S. По вопросам обучения лучше пишите сразу в личку @ilya_prakht
По ходу своей тренерской деятельности часто получаю запросы вида "сделай курс/доклад/презентацию про НЕЧТО". Наверняка, и вы такие задачи получаете. Про презентации так уж точно.
И все легко и просто, когда НЕЧТО - одно или два слова. Например, сделать презентацию по результатам продаж за январь. Или сделать доклад про правильный 1/1. Или даже сделать курс по подготовке к переговорам.
Здесь работает декомпозиция: разбиваем НЕЧТО на темы, далее на вопросы, потом на тезисы. И у вас хороший системный материал. Все четко и по полочкам.
Хуже, когда НЕЧТО - это список вопросов. Например, рассказать про гибкие методологии, метрики, примеры задач сертификации PMI и управление рисками. Здесь уже так не получится.
Нет, конечно можно использовать этот список слов как набор тем, далее по известному алгоритму разбить на вопросы, тезисы. Но получится каша. Каша-малаша. И заказчик, не смотря на то, что он хотел осветить именно эти темы, останется недовольным. Потому что непонятно, картинка не сложится.
В таких случаях приходится включить немножко методолога и разбираться.
Во-первых, уточнить запрос, а что именно ваш заказчик хочет получить от этих тем. Потому как, если запрос несистемный, то очень вероятно, что он сыроват, и заказчик хочет немного другого. Просто не проработал еще до конца. Эти подробности стоит выяснить.
Во-вторых, сделать обратный шаг и заняться композицией. В какие общие рубрики/тематики можно сгруппировать все эти запросы, что их объединяет, и т д. Получится некоторая структура модулей, о чем нужно будет рассказывать. В примере выше явно напрашиваются темы про проектные методологии (все, не только Agile), области управления проектами (причем, я бы разбил на планирование и ведение проекта), метрики и инструменты контроля (опять же по всем методологиям и фреймворкам, особенности их использования) и практические примеры/кейсы.
В результате этих 2 шагов запрос проясняется, и можно возвращаться к обычной декомпозиции на темы, вопросы, тезисы. И у вас снова получится хороший структурированный материал.
Да, не каждому нужно делать курсы и доклады. Во всяком случае, не каждый день, или даже месяц. Но повторюсь, это правило работает и для простой презентации или отчета руководителю. Ведь мы хотим своим материалом удовлетворить руководителя, правда?
А ключ к пониманию вашей презентации - простота и система. Поэтому излюбленным инструментом всех консалтеров и аналитиков являются матрицы 2 на 2 🙂
P.S. По вопросам обучения лучше пишите сразу в личку @ilya_prakht
👍5💯2
ПРО ПЕРЕГОВОРЫ #1
Что самое главное в переговорах?
Техники и приемы? Нет.
Умело манипулировать, а самому на манипуляции не поддаваться? Нет.
Сохранять здравость ума и трезвость памяти? Тоже нет.
Самое главное в переговорах - быть к ним готовым. Да-да, к переговорам нужно готовиться. Интересно, что эта простая мысль для многих кажется очевидной, но также многих заставляет задуматься и погрузиться в бездну инсайтов.
Когда ты руководитель, переговоров в твоей жизни много. Их итак много, даже за пределами работы. Но у руководителя они еще и каждый день здесь.
У меня было много разных ситуаций. Были сложные переговоры, к которым я долго готовился, и они проходили легко. Были простые переговоры, к которым я не был готов совсем, и они становились сложными. Про правильную подготовку можно писать и писать, не один и не пару постов. Сегодня хочу затронуть самое начала подготовки - первые шаги про стратегию.
Первым делом надо понять цель переговоров. Цель свою, и цель оппонента. Чего хотите по итогу добиться вы, а чего хочет он. Бывает, и притом нередко, что цели совпадают. Это не отменяет переговоров, как таковых, но сильно меняет стратегию. Как минимум, у вас будет общая проблема, с которой вы хотите справиться (и да здравствует здесь конструктивная конфронтация).
А дальше сложнее, так как надо абстрагироваться. Стратегия ж. Ничего не поделать.
Следующим шагом нужно прикинуть и понять интересы сторон. Некий базис, с чем и ради чего вы и ваш оппонент вступают в переговоры.
Например, в переговорах по прекращению контракта 2 представителя разных компаний будут преследовать похожую цель: добиться наиболее выгодных условий прекращения контракта. А вот интересы могут быть у каждого свои. Например, человек из компании А на испытательном сроке, и от результатов переговоров сильно зависит его будущее в компании. Ему важно, кроме всего прочего, доказать, что он классный переговорщик. А человек из компании Б ждет отпуска, и единственное, что его еще удерживает - незавершенные переговоры. Ему будет важно закончить поскорее, может быть даже не в угоду результатам.
На эти штуки следует смотреть, как бы, со стороны. Иногда фантазировать. Естественно, мы не знаем наверняка всех интересов другого человека, пока не спросим у него это "в лоб". Да и тогда он может быть не до конца откровенным. Поэтому следует считать, что все, что вы видите и считаете интересами оппонента - гипотезы. И каждую гипотезу нужно будет проверять в разговоре, с помощью правильных вопросов.
Далее уже из целей и интересов, а также дополнительных внешних обстоятельств, формируются переговорные позиции. Это некая точка старта, от которой вам начинать разговор.
Как в "странной" передаче, которая шла когда-то по телевизеру, называлась "Большие гонки" или что-то в этом духе. Там команды носились по конкурсам, и в итоге набирали очки, благодаря которым в финальном испытании ближе к финишу смещалась их точка старта. Вот в переговорах примерно также.
Про переговорные позиции хочется написать побольше, а получилось уже многовато букв. Так что отложу до следующего раза, с них и начнем следующий пост ПРО ПЕРЕГОВОРЫ.
Что самое главное в переговорах?
Техники и приемы? Нет.
Умело манипулировать, а самому на манипуляции не поддаваться? Нет.
Сохранять здравость ума и трезвость памяти? Тоже нет.
Самое главное в переговорах - быть к ним готовым. Да-да, к переговорам нужно готовиться. Интересно, что эта простая мысль для многих кажется очевидной, но также многих заставляет задуматься и погрузиться в бездну инсайтов.
Когда ты руководитель, переговоров в твоей жизни много. Их итак много, даже за пределами работы. Но у руководителя они еще и каждый день здесь.
У меня было много разных ситуаций. Были сложные переговоры, к которым я долго готовился, и они проходили легко. Были простые переговоры, к которым я не был готов совсем, и они становились сложными. Про правильную подготовку можно писать и писать, не один и не пару постов. Сегодня хочу затронуть самое начала подготовки - первые шаги про стратегию.
Первым делом надо понять цель переговоров. Цель свою, и цель оппонента. Чего хотите по итогу добиться вы, а чего хочет он. Бывает, и притом нередко, что цели совпадают. Это не отменяет переговоров, как таковых, но сильно меняет стратегию. Как минимум, у вас будет общая проблема, с которой вы хотите справиться (и да здравствует здесь конструктивная конфронтация).
А дальше сложнее, так как надо абстрагироваться. Стратегия ж. Ничего не поделать.
Следующим шагом нужно прикинуть и понять интересы сторон. Некий базис, с чем и ради чего вы и ваш оппонент вступают в переговоры.
Например, в переговорах по прекращению контракта 2 представителя разных компаний будут преследовать похожую цель: добиться наиболее выгодных условий прекращения контракта. А вот интересы могут быть у каждого свои. Например, человек из компании А на испытательном сроке, и от результатов переговоров сильно зависит его будущее в компании. Ему важно, кроме всего прочего, доказать, что он классный переговорщик. А человек из компании Б ждет отпуска, и единственное, что его еще удерживает - незавершенные переговоры. Ему будет важно закончить поскорее, может быть даже не в угоду результатам.
На эти штуки следует смотреть, как бы, со стороны. Иногда фантазировать. Естественно, мы не знаем наверняка всех интересов другого человека, пока не спросим у него это "в лоб". Да и тогда он может быть не до конца откровенным. Поэтому следует считать, что все, что вы видите и считаете интересами оппонента - гипотезы. И каждую гипотезу нужно будет проверять в разговоре, с помощью правильных вопросов.
Далее уже из целей и интересов, а также дополнительных внешних обстоятельств, формируются переговорные позиции. Это некая точка старта, от которой вам начинать разговор.
Как в "странной" передаче, которая шла когда-то по телевизеру, называлась "Большие гонки" или что-то в этом духе. Там команды носились по конкурсам, и в итоге набирали очки, благодаря которым в финальном испытании ближе к финишу смещалась их точка старта. Вот в переговорах примерно также.
Про переговорные позиции хочется написать побольше, а получилось уже многовато букв. Так что отложу до следующего раза, с них и начнем следующий пост ПРО ПЕРЕГОВОРЫ.
👍15
ГЛАВНАЯ ОШИБКА ТИМЛИДА
Какая ошибка тимлида самая распрастраненная? И она же самая вредная? Особенно у начинающих тимлидов.
Да вы и сами знаете. Конечно, брать все на себя.
Это плохо, потому что тимлид перегружен, выгорает, команда не развивается, басфактор, не все задачи закрываются вовремя и т п прелести. Ничего нового.
Я хотел немного поразмышлять, откуда это берется, и что со всем этим делать. Давайте попробуем.
Откуда берется? Тут есть 2 основных механизма:
1. Новая роль, по сути даже новая метапозиция, к которой нужно привыкнуть и в которую нужно крепко вжиться. У кого-то этот процесс занимает месяцы. Знаю примеры, когда даже годы. Но в среднем, 3-6 месяцев при грамотной помощи от руководства
2. Новые задачи, которые непонятные и неродные. И те самые понятные и родные с другой стороны. Просто пишешь больше кода, и ты молодец. Просто работаешь больше часов, и закрывается больше задач. Мозг коварен. И здесь легко попасть в его ловушку. Кажется, что прежний путь к успеху, а именно закрывать больше задач, будет помогать и тут. Но увы.
Как бороться? Идем от обратного:
1. Все понять и осознать, выделить время на саморазвитие и подтягивать вопросы, где не хватает экспертизы (например, то же делегирование и контроль). Помните притчу про дровосеков и заточку пилы?
2. Попросить помощи, в идеале, у руководителя, который вас на эту тимлидскую роль назначил. В конце концов, это его непосредственная задача, провести вам полноценный онбординг. Попросите его выделять время, помогать советами и обратной связью
3. Запретить себе заниматься инженерской работой. Не, ну не полностью конечно, тимлид - играющий тренер. Но ограничить эту работу. Допустим, не больше 5 часов в день. Остальное время - строго на менеджмент и подтягивание своих тимлидских хвостов. Сколько времени на управление нужно именно вам - знаете только вы. Но это нормальная практика, когда при команде в 5-7 человек у вас уходит до 50% времени не на написание кода
4. Нагружать сотрудников в первую очередь, только потом распределять задачи себе. Вроде банально, но многие делают наоборот, а потом дисбаланс и басфактор. Не надо так
5. Начать делать пипл-менеджмент. Забукать 1/1 со своими сотрудниками, посмотреть на их планы развития, обсудить текущие сложности и проблемы. Прям выделить на это время и прям его использовать. Это сильно помогает осознать свою новую роль, быстрее привыкнуть к "шкуре руководителя"
Может что-то забыл, пишите свои мысли.
А может и не забыл, тогда просто оцените, полезно или нет :)
--
Седой директор - про менеджмент "на пальцах"
@ilya_prakht
Какая ошибка тимлида самая распрастраненная? И она же самая вредная? Особенно у начинающих тимлидов.
Да вы и сами знаете. Конечно, брать все на себя.
Это плохо, потому что тимлид перегружен, выгорает, команда не развивается, басфактор, не все задачи закрываются вовремя и т п прелести. Ничего нового.
Я хотел немного поразмышлять, откуда это берется, и что со всем этим делать. Давайте попробуем.
Откуда берется? Тут есть 2 основных механизма:
1. Новая роль, по сути даже новая метапозиция, к которой нужно привыкнуть и в которую нужно крепко вжиться. У кого-то этот процесс занимает месяцы. Знаю примеры, когда даже годы. Но в среднем, 3-6 месяцев при грамотной помощи от руководства
2. Новые задачи, которые непонятные и неродные. И те самые понятные и родные с другой стороны. Просто пишешь больше кода, и ты молодец. Просто работаешь больше часов, и закрывается больше задач. Мозг коварен. И здесь легко попасть в его ловушку. Кажется, что прежний путь к успеху, а именно закрывать больше задач, будет помогать и тут. Но увы.
Как бороться? Идем от обратного:
1. Все понять и осознать, выделить время на саморазвитие и подтягивать вопросы, где не хватает экспертизы (например, то же делегирование и контроль). Помните притчу про дровосеков и заточку пилы?
2. Попросить помощи, в идеале, у руководителя, который вас на эту тимлидскую роль назначил. В конце концов, это его непосредственная задача, провести вам полноценный онбординг. Попросите его выделять время, помогать советами и обратной связью
3. Запретить себе заниматься инженерской работой. Не, ну не полностью конечно, тимлид - играющий тренер. Но ограничить эту работу. Допустим, не больше 5 часов в день. Остальное время - строго на менеджмент и подтягивание своих тимлидских хвостов. Сколько времени на управление нужно именно вам - знаете только вы. Но это нормальная практика, когда при команде в 5-7 человек у вас уходит до 50% времени не на написание кода
4. Нагружать сотрудников в первую очередь, только потом распределять задачи себе. Вроде банально, но многие делают наоборот, а потом дисбаланс и басфактор. Не надо так
5. Начать делать пипл-менеджмент. Забукать 1/1 со своими сотрудниками, посмотреть на их планы развития, обсудить текущие сложности и проблемы. Прям выделить на это время и прям его использовать. Это сильно помогает осознать свою новую роль, быстрее привыкнуть к "шкуре руководителя"
Может что-то забыл, пишите свои мысли.
А может и не забыл, тогда просто оцените, полезно или нет :)
--
Седой директор - про менеджмент "на пальцах"
@ilya_prakht
👍19💯2
Выпустили подкаст с ITBizRadio про текущую ситуацию на рынке РФ, некоторые перспективы и тренды его развития. Живенько получилось. И, на мой взгляд, познавательно :)
https://vk.com/itbizradio?w=wall-140413150_326
https://vk.com/itbizradio?w=wall-140413150_326
VK
ITBizRadio | Бизнес-шоу. Запись со стены.
Как выживают IT компании, которые остались в России, какие перспективы их ждут? Выделили и обсудили ... Смотрите полностью ВКонтакте.
🔥9🤔1
Коллеги, у меня в VK https://vk.com/ilyaprakht всякие разные видеоролики, стараюсь делать каждый день. Они тоже про типичные проблемы/вопросы в менеджменте, но в формате видео.
Сюда публиковать не буду, здесь посерьезнее вопросы решаются) Но если кому-то интересно - welcome! Приму все заявки.
Сюда публиковать не буду, здесь посерьезнее вопросы решаются) Но если кому-то интересно - welcome! Приму все заявки.
🔥4
А еще хочу напомнить про Вопросник. Вот ссылка на форму https://forms.gle/yguM6swyLCvFbJ858
Пишите туда все, что хотите знать. Мне нужна ваша обратная связь! Мне важно понимать, что вас интересует, про что писать в первую очередь.
И спасибо всем, кто уже оставил свой вопрос :)
Пишите туда все, что хотите знать. Мне нужна ваша обратная связь! Мне важно понимать, что вас интересует, про что писать в первую очередь.
И спасибо всем, кто уже оставил свой вопрос :)
Google Docs
Напиши свой вопрос / кейс
Форма полностью анонимная, но вы можете подписаться для более адресного ответа
👍2
ВОПРОСНИК #6
Как-то я выпал немного из рабочего процесса. Были уважительные причины, правда :) Но буду исправляться!
Сегодня очередной Вопросник. Про "водопад".
Вопрос:
Был ли успешный кейс работы по waterfall и в чём он заключался?
Ответ:
Если смотреть на канонический водопад, то нет, не было. Были очень приближенные форматы проектов, но все равно с некоторой долей креатива и итерационности внутри.
В IT водопад встречается крайне редко. Не потому что старо и не модно, вовсе нет. Причина в другом.
Классический водопад подразумевает, что вы сильно заранее распланировали все. Ну т е вообще все. У вас есть практически пошаговый план, что нужно делать в проекте, чтобы он стал успешным.
В IT каждый проект - некоторое творчество. Иногда совсем RnD. И по итогу неясного больше, чем ясного. А значит какой тут может быть водопад.
Таким образом, конкретно в IT водопад жизнеспособен в 2 случаях:
- У вас небольшой и понятный проект, который можно сразу сходу декомпозировать до задач и уместить в одной голове менеджера
- У вас какой-то конвеерный однотипный с другими проект, может быть довольно крупный, но тем не менее, поддающийся планированию до старта, вы знаете все от и до в таких проектах
И то и другое встречается, скажем так, нечасто. IT ж.
Секрет успеха водопадного проекта - буферизация. Обкладываться буферами везде, где только можно, закрывая любые, возможные и не очень, риски. Это приводит к порой катастрофическому увеличению стоимости (вплоть до 50% буферов, как вам?), но зато проект может закончиться хорошо. Может - не равно "точно закончится" :) Все снова упирается в степень неизвестности того, что мы будем делать. Ну и в фазу луны. И в ретроградный Меркурий.
Вот такие проекты были. Внутри были некоторые крупные вехи (например дизайн), которые обкладывались буферами на креатив вокруг требований и фидбека заказчика. И иногда, они становились успешными.
Но больше было, честно сказать, провальных водопадов. Где бюджет -10% считался просто невероятной победой. Ребята поопытнее всегда закладывают такой минус в маржу, поэтому все ок :)
Резюмируя, у меня примеров канонических водопадных проектов, можно сказать, не было. Были примеры околоводопадных проектов, с мощными буферами, которые были или чуть-чуть провальными, или совсем никуда не годились. А водопад будет работать, если вы можете все заранее хорошо распланировать, декомпозировать весь проект до уровня задач, также заранее, и назакладываете вдоволь буферов на все, что только можно, смело умножая бюджет на 1.5, не меньше.
Надеюсь, получилось ответить на вопрос.
P.S. Задавайте новые вопросы в форму https://forms.gle/yguM6swyLCvFbJ858
Как-то я выпал немного из рабочего процесса. Были уважительные причины, правда :) Но буду исправляться!
Сегодня очередной Вопросник. Про "водопад".
Вопрос:
Был ли успешный кейс работы по waterfall и в чём он заключался?
Ответ:
Если смотреть на канонический водопад, то нет, не было. Были очень приближенные форматы проектов, но все равно с некоторой долей креатива и итерационности внутри.
В IT водопад встречается крайне редко. Не потому что старо и не модно, вовсе нет. Причина в другом.
Классический водопад подразумевает, что вы сильно заранее распланировали все. Ну т е вообще все. У вас есть практически пошаговый план, что нужно делать в проекте, чтобы он стал успешным.
В IT каждый проект - некоторое творчество. Иногда совсем RnD. И по итогу неясного больше, чем ясного. А значит какой тут может быть водопад.
Таким образом, конкретно в IT водопад жизнеспособен в 2 случаях:
- У вас небольшой и понятный проект, который можно сразу сходу декомпозировать до задач и уместить в одной голове менеджера
- У вас какой-то конвеерный однотипный с другими проект, может быть довольно крупный, но тем не менее, поддающийся планированию до старта, вы знаете все от и до в таких проектах
И то и другое встречается, скажем так, нечасто. IT ж.
Секрет успеха водопадного проекта - буферизация. Обкладываться буферами везде, где только можно, закрывая любые, возможные и не очень, риски. Это приводит к порой катастрофическому увеличению стоимости (вплоть до 50% буферов, как вам?), но зато проект может закончиться хорошо. Может - не равно "точно закончится" :) Все снова упирается в степень неизвестности того, что мы будем делать. Ну и в фазу луны. И в ретроградный Меркурий.
Вот такие проекты были. Внутри были некоторые крупные вехи (например дизайн), которые обкладывались буферами на креатив вокруг требований и фидбека заказчика. И иногда, они становились успешными.
Но больше было, честно сказать, провальных водопадов. Где бюджет -10% считался просто невероятной победой. Ребята поопытнее всегда закладывают такой минус в маржу, поэтому все ок :)
Резюмируя, у меня примеров канонических водопадных проектов, можно сказать, не было. Были примеры околоводопадных проектов, с мощными буферами, которые были или чуть-чуть провальными, или совсем никуда не годились. А водопад будет работать, если вы можете все заранее хорошо распланировать, декомпозировать весь проект до уровня задач, также заранее, и назакладываете вдоволь буферов на все, что только можно, смело умножая бюджет на 1.5, не меньше.
Надеюсь, получилось ответить на вопрос.
P.S. Задавайте новые вопросы в форму https://forms.gle/yguM6swyLCvFbJ858
Google Docs
Напиши свой вопрос / кейс
Форма полностью анонимная, но вы можете подписаться для более адресного ответа
👍4🔥1
ПРО ПЕРЕГОВОРЫ #2
Продолжение темы про подготовку к переговорам. Теперь поподробнее поговорим про переговорные позиции.
Как уже писал выше, переговорная позиция - есть некоторая стартовая точка, из которой вы начинаете. Если ваша позиция сильная, нужно этим пользоваться. Если позиция слабая, то нужно ее усиливать. Тоже самое и с оппонентом. Если его позиция слабая, нужно доминировать. Если его позиция сильная, нужно пытаться ее ослабить или (что лучше) усиливать свою, чтобы она стала доминирующей.
Чтобы понять, как это работает, разберем простой пример. Ситуация: вам нужно обсудить с заказчиком урезание скоупа. Допустим, вы не успели что-то сделать, и теперь надо резать, чтобы выдать хоть что-то вменяемое и законченное. Какие тут позиции? Из того, что описано, у вас - слабая, у заказчика - сильная. Правильно? Ок, запомнили.
Развиваем тему. А если ко всему прочему, заказчик сам долго выдавал доступы, профакапил свои же обязательства и договоренности, сам это постоянно признавал. Изменятся ли переговорные позиции? Однозначно! В таком разрезе, ваша стала сильнее, а позиция заказчика - сильно ослабла.
Следующий шаг. Теперь представьте, что ваш заказчик - очень импульсивный испанец, с жутчайшим акцентом, но очень сильным скиллом переговорщика. Как это повлияет? На мой вкус, его позиция усиливается, ваша - слабеет. Но тут можно поспорить, конечно.
Ну и последняя вводная. Допустим, заказчик - ваш давний знакомый, и несмотря на все его коммуникативные нюансы, вы прекрасно его понимаете и можете предугадывать его слова и действия в разговоре. Чья позиция побеждает? Как минимум, все это усиливает вашу переговорную позицию. Логично?
Таким образом, переговорная позиция складывается из нескольких основных блоков:
1. Человек: его психотип, эмоциональность, склонность к конструктиву и скиллы переговорщика
2. Ваши взаимоотношения: влияют ли на интересы в переговорах, и будет ли результат переговоров влиять на эти отношения в дальнейшем
3. Интересы: коррелируют ли с оппонентом, доставляют ли дискомфорт друг другу
4. Внешние обстоятельства: способствуют ли договариванию, влияют ли на скорость принятия решений
5. Необходимость договориться: срочно или несрочно, и надо ли вообще кому-то
В разных ситуациях сюда могут добавляться и другие блоки. Например, тот же уровень английского в переговорах на английском. Или техническая грамотность при обсуждении чисто технического жира по проекту. Можно еще придумать примеров.
В самом простом варианте, можно оценить все эти блоки по 5-бальной шкале, для себя и оппонента, и прикинуть, чья позиция сильнее. Получится наглядная картинка, где вы сильны, а где проседаете.
Если проседаете, то надо усиливать. А как это сделать - напишу в следующем посте. Продолжение следует...
--
Седой директор - про менеджмент "на пальцах"
@ilya_prakht
Продолжение темы про подготовку к переговорам. Теперь поподробнее поговорим про переговорные позиции.
Как уже писал выше, переговорная позиция - есть некоторая стартовая точка, из которой вы начинаете. Если ваша позиция сильная, нужно этим пользоваться. Если позиция слабая, то нужно ее усиливать. Тоже самое и с оппонентом. Если его позиция слабая, нужно доминировать. Если его позиция сильная, нужно пытаться ее ослабить или (что лучше) усиливать свою, чтобы она стала доминирующей.
Чтобы понять, как это работает, разберем простой пример. Ситуация: вам нужно обсудить с заказчиком урезание скоупа. Допустим, вы не успели что-то сделать, и теперь надо резать, чтобы выдать хоть что-то вменяемое и законченное. Какие тут позиции? Из того, что описано, у вас - слабая, у заказчика - сильная. Правильно? Ок, запомнили.
Развиваем тему. А если ко всему прочему, заказчик сам долго выдавал доступы, профакапил свои же обязательства и договоренности, сам это постоянно признавал. Изменятся ли переговорные позиции? Однозначно! В таком разрезе, ваша стала сильнее, а позиция заказчика - сильно ослабла.
Следующий шаг. Теперь представьте, что ваш заказчик - очень импульсивный испанец, с жутчайшим акцентом, но очень сильным скиллом переговорщика. Как это повлияет? На мой вкус, его позиция усиливается, ваша - слабеет. Но тут можно поспорить, конечно.
Ну и последняя вводная. Допустим, заказчик - ваш давний знакомый, и несмотря на все его коммуникативные нюансы, вы прекрасно его понимаете и можете предугадывать его слова и действия в разговоре. Чья позиция побеждает? Как минимум, все это усиливает вашу переговорную позицию. Логично?
Таким образом, переговорная позиция складывается из нескольких основных блоков:
1. Человек: его психотип, эмоциональность, склонность к конструктиву и скиллы переговорщика
2. Ваши взаимоотношения: влияют ли на интересы в переговорах, и будет ли результат переговоров влиять на эти отношения в дальнейшем
3. Интересы: коррелируют ли с оппонентом, доставляют ли дискомфорт друг другу
4. Внешние обстоятельства: способствуют ли договариванию, влияют ли на скорость принятия решений
5. Необходимость договориться: срочно или несрочно, и надо ли вообще кому-то
В разных ситуациях сюда могут добавляться и другие блоки. Например, тот же уровень английского в переговорах на английском. Или техническая грамотность при обсуждении чисто технического жира по проекту. Можно еще придумать примеров.
В самом простом варианте, можно оценить все эти блоки по 5-бальной шкале, для себя и оппонента, и прикинуть, чья позиция сильнее. Получится наглядная картинка, где вы сильны, а где проседаете.
Если проседаете, то надо усиливать. А как это сделать - напишу в следующем посте. Продолжение следует...
--
Седой директор - про менеджмент "на пальцах"
@ilya_prakht
👍5
СКАЗ О ТОМ, ПОЧЕМУ В IT "МЕНЕДЖЕРЫ НЕ НУЖНЫ"
Да-да, вы не ослышались. Или овиделись, как правильно?
Имел я неосторожность в последнее время выдать на Хабр несколько статей, исключительно менеджерской направленности. А там не любят такое, от слова совсем.
Причем интересно, что если статья относительно нейтральная, то вы просто тихо-спокойно отгребаете свои минусы, и жизнь продолжается. Но если тема хоть сколько-нибудь прославляющая менеджмент (или, прости господи, менеджеров!!), то к минусам летят вслед еще и гневные комментарии из серии "все фигня, менеджеры не нужны!".
Но я не обиделся) Это крайне интересная история, что публика, состоящая на 80-90% из инженеров, считает именно так. Ведь это неспроста, согласитесь?
Стал я думать долгими темными вечерами (а в Питере день все еще короткий, поэтому времени у меня было навалом), как же так получилось-то. Ну и сформировалось несколько идей-гипотез у меня. Хочу с вами поделиться, да обсудить, что из этого правда, а что вымысел. А потом статью на Хабр напишу про это. Естественно :)
Так вот. Почему же так получилось, что инженеры искренне убеждены в том, что без менеджеров не просто будет норм, а даже, можно сказать, будет намного лучше работаться?
Гипотеза #1 - историческая. На заре становления отрасли с менеджментом в IT-шечке было не очень радужно. А поскольку вся работа в IT - это проекты, то вот этих самых менеджеров проектов и наблюдался колоссальный дефицит. В большинстве случаев, позиции эти отдавались людям, которые умели управлять проектами в принципе, но были ни в зуб ногой (да и любой другой частью тела) в само IT. Ребята, с гордым наименованием РП-шники. Помните таких? А IT ж сложное, надо понимать специфику. А еще инженеры своей тонкой душевной организацией ну никак не смогут уважать и принимать "за своего" какого-то IT-невежду. Вот и получилось, что первое поколение IT-шников глубоко пропитались всем этим негативом к менеджерам. Ну и, сказать по чести, они имели на это право. Встречал я таких "плагинов к джире" в своей практике, действительно жалкое зрелище. Гораздо эффективнее работается в режиме полной анархии, чем с таким "лидером".
Гипотеза #2 - эволюционная. Заря прошла, и солнце всей необъятной IT-отрасли стало светить ярче экрана телефона, когда ты пытаешься среди ночи посмотреть время. Менеджмент тоже эволюционировал, стали появляться менеджеры "изнутри". Такие скилловые инженеры, которые вырастали в управленцев. Они были гораздо грамотнее, имели больший авторитет. И даже считались нормальными такими менеджерами. Но было их мало. И дыры продолжали затыкать ребята либо не очень из IT, либо не очень руководители, либо еще в чем-то не очень. Ну и не всегда своим наличием они приносили пользу команде.
Гипотеза #3 - революционная. А дальше стало еще интереснее. Дефицит управленцев никуда не девался, но стали появляться, как грибы после радиационного дождя, разного рода учебные площадки и центры. И все с похожими слоганами "войди в IT". И вот дефицит хороших управленцев стали восполнять начинающие, сразу после учебноцентрской скамьи. Многие из них были неплохими, перспективными. Но большинство могли это показать не сразу. Вот и не показывали.
Гипотеза #4 - туманная. Есть еще один момент. Задам вопрос. Как часто вы знаете и понимаете, что делает ваш менеджер? Это ж не солидно, отчитываться перед сотрудниками, правда?) Вот они и не знают. И думают, что менеджер - чувак, который раз в день пишет в чат и спрашивает как дела. Ну еще на дейликах странные вопросы задает, "я ему про архитектуру и чистоту кода, а он мне про какие-то сроки". Информационный барьер, который мы, руководители, сами построили, и сами же поддерживаем. А инженеры - люди простые. Им показал - они все поняли. Не показал - значит не будут пытаться разбираться. Вот и складывается в их голове на месте пустоты понимания, простая, но очень навязчивая мысль: "менеджеры не нужны".
Как считаете? С чем согласны? С чем не очень?
Давайте пообсуждаем!
--
Седой директор - про менеджмент "на пальцах"
@ilya_prakht
Да-да, вы не ослышались. Или овиделись, как правильно?
Имел я неосторожность в последнее время выдать на Хабр несколько статей, исключительно менеджерской направленности. А там не любят такое, от слова совсем.
Причем интересно, что если статья относительно нейтральная, то вы просто тихо-спокойно отгребаете свои минусы, и жизнь продолжается. Но если тема хоть сколько-нибудь прославляющая менеджмент (или, прости господи, менеджеров!!), то к минусам летят вслед еще и гневные комментарии из серии "все фигня, менеджеры не нужны!".
Но я не обиделся) Это крайне интересная история, что публика, состоящая на 80-90% из инженеров, считает именно так. Ведь это неспроста, согласитесь?
Стал я думать долгими темными вечерами (а в Питере день все еще короткий, поэтому времени у меня было навалом), как же так получилось-то. Ну и сформировалось несколько идей-гипотез у меня. Хочу с вами поделиться, да обсудить, что из этого правда, а что вымысел. А потом статью на Хабр напишу про это. Естественно :)
Так вот. Почему же так получилось, что инженеры искренне убеждены в том, что без менеджеров не просто будет норм, а даже, можно сказать, будет намного лучше работаться?
Гипотеза #1 - историческая. На заре становления отрасли с менеджментом в IT-шечке было не очень радужно. А поскольку вся работа в IT - это проекты, то вот этих самых менеджеров проектов и наблюдался колоссальный дефицит. В большинстве случаев, позиции эти отдавались людям, которые умели управлять проектами в принципе, но были ни в зуб ногой (да и любой другой частью тела) в само IT. Ребята, с гордым наименованием РП-шники. Помните таких? А IT ж сложное, надо понимать специфику. А еще инженеры своей тонкой душевной организацией ну никак не смогут уважать и принимать "за своего" какого-то IT-невежду. Вот и получилось, что первое поколение IT-шников глубоко пропитались всем этим негативом к менеджерам. Ну и, сказать по чести, они имели на это право. Встречал я таких "плагинов к джире" в своей практике, действительно жалкое зрелище. Гораздо эффективнее работается в режиме полной анархии, чем с таким "лидером".
Гипотеза #2 - эволюционная. Заря прошла, и солнце всей необъятной IT-отрасли стало светить ярче экрана телефона, когда ты пытаешься среди ночи посмотреть время. Менеджмент тоже эволюционировал, стали появляться менеджеры "изнутри". Такие скилловые инженеры, которые вырастали в управленцев. Они были гораздо грамотнее, имели больший авторитет. И даже считались нормальными такими менеджерами. Но было их мало. И дыры продолжали затыкать ребята либо не очень из IT, либо не очень руководители, либо еще в чем-то не очень. Ну и не всегда своим наличием они приносили пользу команде.
Гипотеза #3 - революционная. А дальше стало еще интереснее. Дефицит управленцев никуда не девался, но стали появляться, как грибы после радиационного дождя, разного рода учебные площадки и центры. И все с похожими слоганами "войди в IT". И вот дефицит хороших управленцев стали восполнять начинающие, сразу после учебноцентрской скамьи. Многие из них были неплохими, перспективными. Но большинство могли это показать не сразу. Вот и не показывали.
Гипотеза #4 - туманная. Есть еще один момент. Задам вопрос. Как часто вы знаете и понимаете, что делает ваш менеджер? Это ж не солидно, отчитываться перед сотрудниками, правда?) Вот они и не знают. И думают, что менеджер - чувак, который раз в день пишет в чат и спрашивает как дела. Ну еще на дейликах странные вопросы задает, "я ему про архитектуру и чистоту кода, а он мне про какие-то сроки". Информационный барьер, который мы, руководители, сами построили, и сами же поддерживаем. А инженеры - люди простые. Им показал - они все поняли. Не показал - значит не будут пытаться разбираться. Вот и складывается в их голове на месте пустоты понимания, простая, но очень навязчивая мысль: "менеджеры не нужны".
Как считаете? С чем согласны? С чем не очень?
Давайте пообсуждаем!
--
Седой директор - про менеджмент "на пальцах"
@ilya_prakht
👍5🔥3😁1
Сегодня был мой день в трехдневке Стратоплана в "Школе технического директора". Модуль называется "Карта трансформации СТО" - про построение своего плана развития.
Делился опытом по поводу роли СТО в аутсорсинге: типы, особенности, компетенции, развитие. Большой полноценный воркшоп, теория и практика. Много вопросов.
Прошло хорошо, я остался доволен :) Ну а как студентам - скоро узнаем, когда придут фидбеки.
Непросто собрать себя и отработать полноценный рабочий день в выходной. Но заряд энергии, который получаешь в ответ, всегда того стоит! Кайфую от своей работы!
Продолжение следует.
@ilya_prakht
Делился опытом по поводу роли СТО в аутсорсинге: типы, особенности, компетенции, развитие. Большой полноценный воркшоп, теория и практика. Много вопросов.
Прошло хорошо, я остался доволен :) Ну а как студентам - скоро узнаем, когда придут фидбеки.
Непросто собрать себя и отработать полноценный рабочий день в выходной. Но заряд энергии, который получаешь в ответ, всегда того стоит! Кайфую от своей работы!
Продолжение следует.
@ilya_prakht
👍4🔥3
ВОПРОСНИК #7
Сегодня вопрос про классический конфликт красивой книжной схемы с жесткой штаткой и матрицами компетенций с ее величеством реальностью. А она корректирует, всегда.
Вопрос:
Кандидат стоит сильно выше рынка, но нужно как можно раньше "заткнуть дыру" на проекте. Чем может грозить решение о найме такого кандидата?
Ответ:
О, кто бы только мог представить, сколько раз мы сами задавались таким вопросом. Особенно на протяжении безумного 21 года, когда на рынке творилось броуновское движение и хайринг был больше похож на рыбалку "нахлыстом".
Вот есть у вас хороший системный процесс развития людей. ЗП по штатке, в зависимости от грейда, требования, зафиксированные в матрице компетенций, периодические аттестации, цели и все дела. Люди растут внутри компании, с мотивацией все ок, все счастливы.
А потом приходит кандидат, и просит 1,5х от своего грейда. Или 2х. Совсем лайтовый вариант, когда где-нибудь 1,2х. И вот стоит ли рисковать, ломать работающую систему ради кандидата?
Любая система может выдерживать некоторые исключения. Главное, чтобы их не было много. По опыту, если она выстроена хорошо, то может справиться с индивидуальными кейсами объемом до 10%. Чем хуже система - тем ниже будет эта цифра.
Поэтому если бизнесу ну очень надо "заткнуть дыру" и нанять кандидата с завышенной ЗП, то прикиньте, влазиете вы в этот объем исключений, или нет. Условно 1 из 10 человек.
Чем больше будет индивидуального в системе, тем в более ручном режиме придется ей потом управлять. Как итог - система быстро разваливается. Это как регулировщики во время пробок. Замечали? Если они держат 1-2 перекрестка, иногда даже польза есть. Если больше четверти загруженных дорог - капец, город встал. Вот также и тут.
Важный момент, который хочу подсветить. Если вы договариваетесь о каких-то индивидуальных условиях с кандидатом, и притом хотите сохранить работающую систему, обязательно проговаривайте все это. Скажите честно, что есть горящая позиция, поэтому готовы сделать исключение и выдать ЗП выше. Но на ближайшей аттестации не жди повышения, так как ты, по сути, догонишь свою же ЗП.
Если этого не делать, то народная молва быстро разнесет среди сотрудников, что прежний процесс уже не тот, система "прогнила", надо идти к начальству, трясти офером и требовать повышения ЗП. А такие новости распространяются с невероятной скоростью. По каким-то телепатическим форумам и каналам.
Ну и ожидания самого сотрудника надо подровнять. Он будет думать, что в компании повышают каждый год ЗП на 20%, а спустя год обнаружит, что его это не касается. Неприятно ведь? Такие вещи надо обсуждать "на берегу".
Резюмируя. Исключения возможны, и если бизнесу очень надо, то можно нанимать. Но не часто. И если такое решение принимаете, то следует обязательно прозрачно все обсудить с кандидатом, почему вы готовы на это пойти и как это отразится на его собственном развитии в компании. Иначе получите толпу жаждущих выбить себе тоже исключительных условий работы. И притом быстро.
Надеюсь, получилось ответить на вопрос.
P.S. Задавайте новые вопросы в анонимную форму https://forms.gle/yguM6swyLCvFbJ858
Сегодня вопрос про классический конфликт красивой книжной схемы с жесткой штаткой и матрицами компетенций с ее величеством реальностью. А она корректирует, всегда.
Вопрос:
Кандидат стоит сильно выше рынка, но нужно как можно раньше "заткнуть дыру" на проекте. Чем может грозить решение о найме такого кандидата?
Ответ:
О, кто бы только мог представить, сколько раз мы сами задавались таким вопросом. Особенно на протяжении безумного 21 года, когда на рынке творилось броуновское движение и хайринг был больше похож на рыбалку "нахлыстом".
Вот есть у вас хороший системный процесс развития людей. ЗП по штатке, в зависимости от грейда, требования, зафиксированные в матрице компетенций, периодические аттестации, цели и все дела. Люди растут внутри компании, с мотивацией все ок, все счастливы.
А потом приходит кандидат, и просит 1,5х от своего грейда. Или 2х. Совсем лайтовый вариант, когда где-нибудь 1,2х. И вот стоит ли рисковать, ломать работающую систему ради кандидата?
Любая система может выдерживать некоторые исключения. Главное, чтобы их не было много. По опыту, если она выстроена хорошо, то может справиться с индивидуальными кейсами объемом до 10%. Чем хуже система - тем ниже будет эта цифра.
Поэтому если бизнесу ну очень надо "заткнуть дыру" и нанять кандидата с завышенной ЗП, то прикиньте, влазиете вы в этот объем исключений, или нет. Условно 1 из 10 человек.
Чем больше будет индивидуального в системе, тем в более ручном режиме придется ей потом управлять. Как итог - система быстро разваливается. Это как регулировщики во время пробок. Замечали? Если они держат 1-2 перекрестка, иногда даже польза есть. Если больше четверти загруженных дорог - капец, город встал. Вот также и тут.
Важный момент, который хочу подсветить. Если вы договариваетесь о каких-то индивидуальных условиях с кандидатом, и притом хотите сохранить работающую систему, обязательно проговаривайте все это. Скажите честно, что есть горящая позиция, поэтому готовы сделать исключение и выдать ЗП выше. Но на ближайшей аттестации не жди повышения, так как ты, по сути, догонишь свою же ЗП.
Если этого не делать, то народная молва быстро разнесет среди сотрудников, что прежний процесс уже не тот, система "прогнила", надо идти к начальству, трясти офером и требовать повышения ЗП. А такие новости распространяются с невероятной скоростью. По каким-то телепатическим форумам и каналам.
Ну и ожидания самого сотрудника надо подровнять. Он будет думать, что в компании повышают каждый год ЗП на 20%, а спустя год обнаружит, что его это не касается. Неприятно ведь? Такие вещи надо обсуждать "на берегу".
Резюмируя. Исключения возможны, и если бизнесу очень надо, то можно нанимать. Но не часто. И если такое решение принимаете, то следует обязательно прозрачно все обсудить с кандидатом, почему вы готовы на это пойти и как это отразится на его собственном развитии в компании. Иначе получите толпу жаждущих выбить себе тоже исключительных условий работы. И притом быстро.
Надеюсь, получилось ответить на вопрос.
P.S. Задавайте новые вопросы в анонимную форму https://forms.gle/yguM6swyLCvFbJ858
Google Docs
Напиши свой вопрос / кейс
Форма полностью анонимная, но вы можете подписаться для более адресного ответа
👍11
В этот четверг, 16 марта, в 19.00 мск поучаствую в онлайн-митапе OTUSа для руководителей и тимлидов "Как сохранить эффективность команды в условиях перемен?".
Пообсуждаем, почему команду нужно беречь, как это делать, и как самому не "сгореть" от всего происходящего.
Приходите!
https://meetup.otus.ru/company-leadership
Пообсуждаем, почему команду нужно беречь, как это делать, и как самому не "сгореть" от всего происходящего.
Приходите!
https://meetup.otus.ru/company-leadership
meetup.otus.ru
Как сохранить эффективность команды в условиях перемен?
Бесплатное мероприятие от исполнительного директора IT-компании, посвященное работе с мотивацией в кризисное время
👍4