🐒 Опыт Ганса
Каждый раз, когда мне пытаются подсунуть очередного эксперта “экс-Яндекс, экс-Сбер, экс-Мэйлру”, я представляю, как на сцену провинциального дома культуры выходит конферансье и говорит:
— А теперь перед вами выступит Ганс Шульц, участник первой и второй мировых войн! Ганс расскажет, как правильно воевать и побеждать!
Ганса я готов слушать только чтобы расширить список историй из цикла “так делать не надо”.
А если про победы, мы лучше кого-нибудь еще послушаем.
Каждый раз, когда мне пытаются подсунуть очередного эксперта “экс-Яндекс, экс-Сбер, экс-Мэйлру”, я представляю, как на сцену провинциального дома культуры выходит конферансье и говорит:
— А теперь перед вами выступит Ганс Шульц, участник первой и второй мировых войн! Ганс расскажет, как правильно воевать и побеждать!
Ганса я готов слушать только чтобы расширить список историй из цикла “так делать не надо”.
А если про победы, мы лучше кого-нибудь еще послушаем.
🪳 Тренажер для менеджеров и не только 955-828
Вы — владелец компании, которая успешна на рынке и переросла рамки стартапа. Основной ее продукт — сервис поиска и покупки автомобилей в интернете.
В команде тридцать человек, большая часть которых с вами не первый год. Вы все еще руководите компанией, но подумываете нанять нового гендиректора, а себя посвятить стратегии и работе с инвесторами.
Сейчас вечер пятницы. Вы решили посмотреть, как там поживает продукт. Тем более, позавчера был большой релиз. Берете пивка и открываете ноутбук.
Через некоторое время вы понимаете, что при некоторых условиях сервис работает не совсем корректно: пользователю наравне с обычными машинами предлагаются игрушечные. В алгоритме явно где-то ошибка. Вас она раздражает.
Вы — владелец компании, которая успешна на рынке и переросла рамки стартапа. Основной ее продукт — сервис поиска и покупки автомобилей в интернете.
В команде тридцать человек, большая часть которых с вами не первый год. Вы все еще руководите компанией, но подумываете нанять нового гендиректора, а себя посвятить стратегии и работе с инвесторами.
Сейчас вечер пятницы. Вы решили посмотреть, как там поживает продукт. Тем более, позавчера был большой релиз. Берете пивка и открываете ноутбук.
Через некоторое время вы понимаете, что при некоторых условиях сервис работает не совсем корректно: пользователю наравне с обычными машинами предлагаются игрушечные. В алгоритме явно где-то ошибка. Вас она раздражает.
Комментарии к задачке, как обычно, послезавтра)
🪲 Комментарии к задачке 955-828
Вариант A не для директора. Даже если у вас за плечами сто лет опыта в тестировании, заводить баг — не ваше дело. А если нет опыта, то, поверьте, правильно описать ошибку — дело непростое.
Варианты D, E и F — для невменяемых директоров. В коде были, есть и будут ошибки, это нормально. Тестировщики тоже ошибаются, они же люди. Наказывать за это, тем более увольнением, вредно для работы и бессмысленно для проекта. Можно добиться только того, что большая часть команды разбежится. А парализованные страхом остатки станут недееспособны.
Вариант H — очень милый и бирюзовый, но вообще-то мы решаем другую задачу. Сначала надо разобраться с неправильной работой сервиса, и только потом переходить к инсайтам.
Плох и вариант G. Зачем отрывать людей от работы дурацкими вопросами? Так Гугл не построить. ) Есть процессы обработки ошибок, им надо следовать. Меньше пустой болтовни — больше дела.
Вариант C предполагает, что вы дергаете РМа, он дергает команду, и они работают все выходные. Для этого нет оснований: сервис не лежит, вполне можно дотерпеть до понедельника. Работа без выходных должна иметь более веские причины.
“Но я же владелец! Для меня любая ошибка критична!” — скажете вы. А ваша команда — отнюдь не владельцы. Они не могут относиться к продукту так, как вы. И не работают в выходные.
Лучше иметь отдохнувшую и готовую к подвигам команду в понедельник, чем злую, уставшую и демотивированную на всю неделю или дольше.
Но надо же как-то обозначить, что вы заметили баг и недовольны? Для этого есть тонкий вариант B. Баг заводит тестировщик, он хорошо умеет это делать. Менеджер проекта открывает в понедельник почту, а там уведомление о новой ошибке. С вашей фамилией в поле Reporter и не самым низким приоритетом. РМ и команда получают сигнал: есть проблема, начальство нашло ее само, тестировщики облажались. Умных людей после этого даже можно и не ругать, они сами все поймут и сделают выводы.
В реальности нормальный директор обычно так и поступает.
Вариант A не для директора. Даже если у вас за плечами сто лет опыта в тестировании, заводить баг — не ваше дело. А если нет опыта, то, поверьте, правильно описать ошибку — дело непростое.
Варианты D, E и F — для невменяемых директоров. В коде были, есть и будут ошибки, это нормально. Тестировщики тоже ошибаются, они же люди. Наказывать за это, тем более увольнением, вредно для работы и бессмысленно для проекта. Можно добиться только того, что большая часть команды разбежится. А парализованные страхом остатки станут недееспособны.
Вариант H — очень милый и бирюзовый, но вообще-то мы решаем другую задачу. Сначала надо разобраться с неправильной работой сервиса, и только потом переходить к инсайтам.
Плох и вариант G. Зачем отрывать людей от работы дурацкими вопросами? Так Гугл не построить. ) Есть процессы обработки ошибок, им надо следовать. Меньше пустой болтовни — больше дела.
Вариант C предполагает, что вы дергаете РМа, он дергает команду, и они работают все выходные. Для этого нет оснований: сервис не лежит, вполне можно дотерпеть до понедельника. Работа без выходных должна иметь более веские причины.
“Но я же владелец! Для меня любая ошибка критична!” — скажете вы. А ваша команда — отнюдь не владельцы. Они не могут относиться к продукту так, как вы. И не работают в выходные.
Лучше иметь отдохнувшую и готовую к подвигам команду в понедельник, чем злую, уставшую и демотивированную на всю неделю или дольше.
Но надо же как-то обозначить, что вы заметили баг и недовольны? Для этого есть тонкий вариант B. Баг заводит тестировщик, он хорошо умеет это делать. Менеджер проекта открывает в понедельник почту, а там уведомление о новой ошибке. С вашей фамилией в поле Reporter и не самым низким приоритетом. РМ и команда получают сигнал: есть проблема, начальство нашло ее само, тестировщики облажались. Умных людей после этого даже можно и не ругать, они сами все поймут и сделают выводы.
В реальности нормальный директор обычно так и поступает.
🍪 Спрашивали — отвечаем 26
“Сергей добрый день и спасибо огромное за ваш канал! У меня такой вопрос. Как я понимаю, управление проектами в целом универсально и не зависит от отрасли. В каких то отраслях есть своя специфика, но общие идеи универсальны.
А теперь собственно вопрос. ))) Планируем с подругой открыть сеть уникальных кондитерских. Сейчас учимся печь и разбираемся с рецептурой и тому подобым. Как нам правильно начать наш проект? С чего? Что порекомендуете?“
Вы правы, управление проектами — штука универсальная. Но ваш вопрос лежит, скорее, в продуктовой плоскости.
Если бы я решил открыть кондитерскую, да еще и с уникальным продуктом, то я бы начал не с рецептуры этого продукта. Я бы сначала разобрался, как продают такие продукты. И, главное, как мне продавать свой. Только так вы создадите MVP — тестируя воронку продаж, а не выпекая оригинальную булочку.
Булочку испечь кто угодно может. Рецептов полно, мука, сахар и масло в любом магазине есть. А вот продать булочку может далеко не каждый. Так что лучше сначала научиться продавать, а только потом печь.
Рецептура — второстепенная фигня, продажи — все. И это справедливо для любого продукта. Вообще любого.
“Сергей добрый день и спасибо огромное за ваш канал! У меня такой вопрос. Как я понимаю, управление проектами в целом универсально и не зависит от отрасли. В каких то отраслях есть своя специфика, но общие идеи универсальны.
А теперь собственно вопрос. ))) Планируем с подругой открыть сеть уникальных кондитерских. Сейчас учимся печь и разбираемся с рецептурой и тому подобым. Как нам правильно начать наш проект? С чего? Что порекомендуете?“
Вы правы, управление проектами — штука универсальная. Но ваш вопрос лежит, скорее, в продуктовой плоскости.
Если бы я решил открыть кондитерскую, да еще и с уникальным продуктом, то я бы начал не с рецептуры этого продукта. Я бы сначала разобрался, как продают такие продукты. И, главное, как мне продавать свой. Только так вы создадите MVP — тестируя воронку продаж, а не выпекая оригинальную булочку.
Булочку испечь кто угодно может. Рецептов полно, мука, сахар и масло в любом магазине есть. А вот продать булочку может далеко не каждый. Так что лучше сначала научиться продавать, а только потом печь.
Рецептура — второстепенная фигня, продажи — все. И это справедливо для любого продукта. Вообще любого.
✈️ Тренажер для менеджеров и не только 956-829
Вы — менеджер проектов в компании, занимающейся ИТ-консалтингом. У вас начинается дорогой и масштабный проект с крупным производственным холдингом.
Вы надеваете лучший галстук, берете список вопросов, ноутбук с презентацией и едете на первую встречу с одним из топов. Его зовут Клим Юрьевич, это очень влиятельный человек в компании. В проекте он будет принимать ключевые решения со стороны клиента, выдвигать требования, принимать результаты и подписывать акты.
Вы поднимаетесь на 48-й этаж и на пороге кабинета сталкиваетесь с Климом Юрьевичем. Он решительными шагами направляется к лифту, вы пристраиваетесь рядом.
— К сожалению, я должен уехать по важным делам на две недели, — говорит Клим Юрьевич. — Вот, в аэропорт спешу. А вы пока начните проект без меня. Если есть какие-то важные вопросы, задавайте прямо сейчас, пока мы в лифте едем.
Вы — менеджер проектов в компании, занимающейся ИТ-консалтингом. У вас начинается дорогой и масштабный проект с крупным производственным холдингом.
Вы надеваете лучший галстук, берете список вопросов, ноутбук с презентацией и едете на первую встречу с одним из топов. Его зовут Клим Юрьевич, это очень влиятельный человек в компании. В проекте он будет принимать ключевые решения со стороны клиента, выдвигать требования, принимать результаты и подписывать акты.
Вы поднимаетесь на 48-й этаж и на пороге кабинета сталкиваетесь с Климом Юрьевичем. Он решительными шагами направляется к лифту, вы пристраиваетесь рядом.
— К сожалению, я должен уехать по важным делам на две недели, — говорит Клим Юрьевич. — Вот, в аэропорт спешу. А вы пока начните проект без меня. Если есть какие-то важные вопросы, задавайте прямо сейчас, пока мы в лифте едем.
Комментарии к задачке, как обычно, послезавтра)
🐠 Комментарии к задачке 956-829
Вариант А выбирают обычно романтичные, то есть совсем неопытные, стартаперы, начитавшиеся вдохновляющих историй. Но лифт — плохое место и для презентации нового Убера, и для обсуждения деталей консалтингового проекта. Как и любое другое место, где вы встретитесь с кем-то на минуту в некомфортных условиях. И очень плохо, что место некомфортно не только для вас, оно некомфортно и для клиента. Обсуждать серьезный проект и принимать решения в спешке категорически нельзя.
Вариант В еще хуже: вас в аэропорт никто не приглашал, не надо навязываться.
Не нужно также выбирать вариант D и выражать недовольство ситуацией, если только вы не хотите, чтобы ваш проект закончился плохо. Или чтобы вас с него сняли еще на старте. Клиенты не обязаны вести себя так, как вам удобно. Это правило справедливо и для ИТ-проекта, и для покупки колбасы в ближайшем продуктовом.
Вариант Е кажется логичным, но только тем, кто никогда толком не работал с крупными клиентами. Такой проект часто помогает топу усилить влияние в компании. Там же непрерывно воюют за власть. Интриги, подковерная борьба, подставы, захват территории. Влиятельный человек просто так не возьмется участвовать в каком-то проекте — есть причина, о которой вы можете и не знать. О какой замене тут говорить? Чтобы кто-то в отсутствие главного человека принимал ключевые решения в зоне его интересов?
Так что самое правильное в подобной ситуации — вариант C. Пожелаем Климу Юрьевичу хорошей поездки, улыбнемся и сдвинем начало проекта на две недели. А наше руководтсво, скорее всего, этому даже не удивится. В консалтинге и не к такому привыкли.
В реальности менеджер так и поступил. Много позже Клим Юрьевич в задушевной беседе признался, что спонтанно решил использовать эту ситуацию для проверки компетентности менеджера. Как он отреагирует? Как будет выходить из положения? Климу Юрьевичу было приятно, что менеджер не растерялся. Хотя, конечно, менеджер еще как растерялся. )
Но хочешь жить среди акул — думай так, как думает акула.
Вариант А выбирают обычно романтичные, то есть совсем неопытные, стартаперы, начитавшиеся вдохновляющих историй. Но лифт — плохое место и для презентации нового Убера, и для обсуждения деталей консалтингового проекта. Как и любое другое место, где вы встретитесь с кем-то на минуту в некомфортных условиях. И очень плохо, что место некомфортно не только для вас, оно некомфортно и для клиента. Обсуждать серьезный проект и принимать решения в спешке категорически нельзя.
Вариант В еще хуже: вас в аэропорт никто не приглашал, не надо навязываться.
Не нужно также выбирать вариант D и выражать недовольство ситуацией, если только вы не хотите, чтобы ваш проект закончился плохо. Или чтобы вас с него сняли еще на старте. Клиенты не обязаны вести себя так, как вам удобно. Это правило справедливо и для ИТ-проекта, и для покупки колбасы в ближайшем продуктовом.
Вариант Е кажется логичным, но только тем, кто никогда толком не работал с крупными клиентами. Такой проект часто помогает топу усилить влияние в компании. Там же непрерывно воюют за власть. Интриги, подковерная борьба, подставы, захват территории. Влиятельный человек просто так не возьмется участвовать в каком-то проекте — есть причина, о которой вы можете и не знать. О какой замене тут говорить? Чтобы кто-то в отсутствие главного человека принимал ключевые решения в зоне его интересов?
Так что самое правильное в подобной ситуации — вариант C. Пожелаем Климу Юрьевичу хорошей поездки, улыбнемся и сдвинем начало проекта на две недели. А наше руководтсво, скорее всего, этому даже не удивится. В консалтинге и не к такому привыкли.
В реальности менеджер так и поступил. Много позже Клим Юрьевич в задушевной беседе признался, что спонтанно решил использовать эту ситуацию для проверки компетентности менеджера. Как он отреагирует? Как будет выходить из положения? Климу Юрьевичу было приятно, что менеджер не растерялся. Хотя, конечно, менеджер еще как растерялся. )
Но хочешь жить среди акул — думай так, как думает акула.
🌹 Нюхать розы
Один из технарей нашей компании каждое утро, примерно в половине девятого, в корпоративном чатике желал всем хорошего рабочего дня. Его никто об этом не просил. И нельзя сказать, что эти его ежедневные два-три предложения отличались особой оригинальностью. Он старался менять формулировки, но каждый день это делать не так-то просто.
Неделю назад он уволился и переехал жить в другую страну. Оказалось, что все в компании читали эти пожелания, и теперь без них скучнее. Даже у меня ощущение, что мы чего-то лишились, хотя я не любитель корпоративных чатиков и не слишком сентиментален.
Параллельно пытались запустить какого-то бота, который поздравлял каждый день с праздниками. Но тексты бота никаких чувств не вызывают, а пожелания живого человека — вызывают.
В английском есть такая идиома: to smell the roses — "нюхать розы". Означает "наслаждаться тем, что часто мы не замечаем, на что не обращаем внимания". Ловить позитивные моменты жизни, даже если это какая-то ерунда. Есть даже исследования, подтверждающие, что "нюхать розы" важно для удовлетворенности людей работой.
Я знаю компании, в которых эта практика используется. Где-то на несколько минут включают пение соловья, приятные звуки природы. Кто-то покупает сотрудникам изысканные вкусняшки, устраивает не относящиеся к работе мастер-классы, кулинарные, например. Да и просто хорошим кофе с плюшками поят.
Нюхать розы — это классно. Даже если это просто пара строчек утром в корпоративном чатике.
Один из технарей нашей компании каждое утро, примерно в половине девятого, в корпоративном чатике желал всем хорошего рабочего дня. Его никто об этом не просил. И нельзя сказать, что эти его ежедневные два-три предложения отличались особой оригинальностью. Он старался менять формулировки, но каждый день это делать не так-то просто.
Неделю назад он уволился и переехал жить в другую страну. Оказалось, что все в компании читали эти пожелания, и теперь без них скучнее. Даже у меня ощущение, что мы чего-то лишились, хотя я не любитель корпоративных чатиков и не слишком сентиментален.
Параллельно пытались запустить какого-то бота, который поздравлял каждый день с праздниками. Но тексты бота никаких чувств не вызывают, а пожелания живого человека — вызывают.
В английском есть такая идиома: to smell the roses — "нюхать розы". Означает "наслаждаться тем, что часто мы не замечаем, на что не обращаем внимания". Ловить позитивные моменты жизни, даже если это какая-то ерунда. Есть даже исследования, подтверждающие, что "нюхать розы" важно для удовлетворенности людей работой.
Я знаю компании, в которых эта практика используется. Где-то на несколько минут включают пение соловья, приятные звуки природы. Кто-то покупает сотрудникам изысканные вкусняшки, устраивает не относящиеся к работе мастер-классы, кулинарные, например. Да и просто хорошим кофе с плюшками поят.
Нюхать розы — это классно. Даже если это просто пара строчек утром в корпоративном чатике.
🗿 Мотивация
Менеджер учит молодого коллегу:
— Я каждый раз готовлюсь ко встрече или презентации так, как будто в комнате собрались Сталин, Берия и Жуков. И мне перед ними выступать.
Наверное, когда видишь вместо таких людей обычных, это заставляет облегченно вздохнуть, расслабиться и выступить лучше. А так, неплохая мысль. Главное — подобрать персонажа для себя. )
Менеджер учит молодого коллегу:
— Я каждый раз готовлюсь ко встрече или презентации так, как будто в комнате собрались Сталин, Берия и Жуков. И мне перед ними выступать.
Наверное, когда видишь вместо таких людей обычных, это заставляет облегченно вздохнуть, расслабиться и выступить лучше. А так, неплохая мысль. Главное — подобрать персонажа для себя. )
🪆 Солдатики, машинки и менеджеры
На собеседовании я часто спрашиваю кандидатов: «Вы в детстве играли в солдатиков или в машинки?»
Я заметил, что мальчики делятся на две группы. Первые любили играть в солдатиков. Такая игра предполагает историю: вот синие солдатики, это пираты, вот красные, это варвары с побережья. Вот этот, пузатый, самый главный у варваров, он любит сырое мясо. Начинаются переговоры, и армии готовы броситься в бой, и уже показались на горизонте суровые индейцы...
Все игры с солдатиками — про коммуникации. Моделирование действий игрушечных людей порождает общение людей живых. Истории позволяют строить сложный мир, раздвигать рамки игры. Тема развивается, моделируются отношения, возникают нестандартные ситуации, приходится искать выходы из них, договариваться.
Любители солдатиков чаще склонны к обобщению, к охвату картины в целом — так генерал наблюдает за битвой издалека. Из них получаются хорошие гуманитарии, математики, врачи, физики-теоретики.
Мальчики из второй группы любили машинки и конструкторы. Чтобы собрать конструктор, не нужна история, зато нужна логика. Вот этот винт не подойдет к тому отверстию. А вот эта опора не удержит груз, надо усилить. А здесь нужно соединение на шарнире.
Эти мальчики имеют врожденное чутье к анализу рисков: если в основании закрепить эту деталь, то вся система рухнет, она же неустойчива!
У них тоже развита фантазия, но она более функциональна. Они хорошо видят цель, результат их игры измерим. Если они строят подъемный кран, то игра закончится, когда кран построен. Им в голову не придет посадить в кран рабочего и два часа поднимать тяжести. Скорее, они начнут новую игру и создадут что-то еще. А кран сразу же разберут после тестирования.
Так же и с машинками — гораздо интереснее построить трассу, обсудить, у кого мотор мощнее.
Им больше нравятся точные науки. Сопромат не вызывает у них желания застрелиться, а черчение не кажется скучным. Из них получаются хорошие программисты, архитекторы, инженеры, физики-экспериментаторы и прочие технари. Если мальчик из второй группы станет врачом, то хирургом или стоматологом: точные движения, внимание к деталям, логика взаимосвязи деталей в конструкторе.
С появлением компьютерных игр ситуация не поменялась. Есть игры, явно ориентированные на первую группу, есть те, что ближе второй. Красивая графика и обязательная история в каждой игре немного размывают границы, но, если присмотреться, как и во что дети играют, можно сразу понять, из какой они группы.
Только не надо делать этот вопрос центральным на интервью. Это просто индикатор, который поможет вам лучше чувствовать кандидата и задавать ему нужные вопросы.
Например, ищете вы менеджера. Какой менеджер лучше соответствует вашим задачам? Активный коммуникатор? Тот, кто быстро разрулит конфликт со сложным клиентом? Или вдумчивый технократ, который сразу видит риски проекта?
Если вы нанимаете программиста, который любил солдатиков, будет ли ему интересно заниматься однотипными проектами?
Если вы нанимаете любителя конструкторов директором по маркетингу, будет ли он общаться с другими подразделениями и внешним миром? Создаст ли в своем отделе культуру коммуникаций? Или приведет команду суровых аналитиков, которые завалят вас таблицами и графиками?
И еще. В детстве этим двум группам довольно сложно друг с другом. Они не понимают внутренних правил игр, которые очевидны для детей другой группы. Но дети быстро приспосабливаются друг к другу и принимают в игру кого угодно. Взрослым сложнее. Поэтому если вам выпала возможность создать продуктовую команду с нуля, такие факторы тоже надо учитывать. У вас же на создание продукта не бесконечное число попыток.
"А что с девочками?" — спросите вы. А с девочками все гораздо сложнее. )
На собеседовании я часто спрашиваю кандидатов: «Вы в детстве играли в солдатиков или в машинки?»
Я заметил, что мальчики делятся на две группы. Первые любили играть в солдатиков. Такая игра предполагает историю: вот синие солдатики, это пираты, вот красные, это варвары с побережья. Вот этот, пузатый, самый главный у варваров, он любит сырое мясо. Начинаются переговоры, и армии готовы броситься в бой, и уже показались на горизонте суровые индейцы...
Все игры с солдатиками — про коммуникации. Моделирование действий игрушечных людей порождает общение людей живых. Истории позволяют строить сложный мир, раздвигать рамки игры. Тема развивается, моделируются отношения, возникают нестандартные ситуации, приходится искать выходы из них, договариваться.
Любители солдатиков чаще склонны к обобщению, к охвату картины в целом — так генерал наблюдает за битвой издалека. Из них получаются хорошие гуманитарии, математики, врачи, физики-теоретики.
Мальчики из второй группы любили машинки и конструкторы. Чтобы собрать конструктор, не нужна история, зато нужна логика. Вот этот винт не подойдет к тому отверстию. А вот эта опора не удержит груз, надо усилить. А здесь нужно соединение на шарнире.
Эти мальчики имеют врожденное чутье к анализу рисков: если в основании закрепить эту деталь, то вся система рухнет, она же неустойчива!
У них тоже развита фантазия, но она более функциональна. Они хорошо видят цель, результат их игры измерим. Если они строят подъемный кран, то игра закончится, когда кран построен. Им в голову не придет посадить в кран рабочего и два часа поднимать тяжести. Скорее, они начнут новую игру и создадут что-то еще. А кран сразу же разберут после тестирования.
Так же и с машинками — гораздо интереснее построить трассу, обсудить, у кого мотор мощнее.
Им больше нравятся точные науки. Сопромат не вызывает у них желания застрелиться, а черчение не кажется скучным. Из них получаются хорошие программисты, архитекторы, инженеры, физики-экспериментаторы и прочие технари. Если мальчик из второй группы станет врачом, то хирургом или стоматологом: точные движения, внимание к деталям, логика взаимосвязи деталей в конструкторе.
С появлением компьютерных игр ситуация не поменялась. Есть игры, явно ориентированные на первую группу, есть те, что ближе второй. Красивая графика и обязательная история в каждой игре немного размывают границы, но, если присмотреться, как и во что дети играют, можно сразу понять, из какой они группы.
Только не надо делать этот вопрос центральным на интервью. Это просто индикатор, который поможет вам лучше чувствовать кандидата и задавать ему нужные вопросы.
Например, ищете вы менеджера. Какой менеджер лучше соответствует вашим задачам? Активный коммуникатор? Тот, кто быстро разрулит конфликт со сложным клиентом? Или вдумчивый технократ, который сразу видит риски проекта?
Если вы нанимаете программиста, который любил солдатиков, будет ли ему интересно заниматься однотипными проектами?
Если вы нанимаете любителя конструкторов директором по маркетингу, будет ли он общаться с другими подразделениями и внешним миром? Создаст ли в своем отделе культуру коммуникаций? Или приведет команду суровых аналитиков, которые завалят вас таблицами и графиками?
И еще. В детстве этим двум группам довольно сложно друг с другом. Они не понимают внутренних правил игр, которые очевидны для детей другой группы. Но дети быстро приспосабливаются друг к другу и принимают в игру кого угодно. Взрослым сложнее. Поэтому если вам выпала возможность создать продуктовую команду с нуля, такие факторы тоже надо учитывать. У вас же на создание продукта не бесконечное число попыток.
"А что с девочками?" — спросите вы. А с девочками все гораздо сложнее. )
🔀 Тренажер для менеджеров и не только 957-830
Вы — разработчик в стартапе, куда попали после крупной ИТ-компании. Трудитесь вы тут два месяца, и пока все идет неплохо. Атмосфера приятная и динамичная, деньги есть, продукт интересный, рынок его принимает.
Основатель и владелец стартапа, Руслан, в прошлом разработчик. Код он уже не пишет, занимается продвижением продукта. Ваш руководитель, Матвей, тоже опытный разработчик, пришел в компанию за полгода до вас. Он отвечает за архитектуру продукта и управляет командой из четырех человек.
Сегодня утром вы открыли систему тасктрекинга, а там задача от Матвея — надо сделать новую сложную фичу. Задача помечена как критически важная.
Вы идете на кухню, наливаете вкусного кофе, любуетесь видом из окна и обдумываете, как будете делать задачу.
Входит Руслан и тоже наливает себе кофе. “Над чем работаешь?” — спрашивает он. Вы рассказываете о новой фиче. Руслан меняется в лице. “Да ты что!” — восклицает он. — “Ни в коем случае эту функцию не надо делать! Наш продукт вообще не про это! Надо делать другую функцию!” И Руслан на клочке бумажки объясняет, что именно нужно делать. Это в корне отличается от задачи, которую поставил Матвей.
Вы — разработчик в стартапе, куда попали после крупной ИТ-компании. Трудитесь вы тут два месяца, и пока все идет неплохо. Атмосфера приятная и динамичная, деньги есть, продукт интересный, рынок его принимает.
Основатель и владелец стартапа, Руслан, в прошлом разработчик. Код он уже не пишет, занимается продвижением продукта. Ваш руководитель, Матвей, тоже опытный разработчик, пришел в компанию за полгода до вас. Он отвечает за архитектуру продукта и управляет командой из четырех человек.
Сегодня утром вы открыли систему тасктрекинга, а там задача от Матвея — надо сделать новую сложную фичу. Задача помечена как критически важная.
Вы идете на кухню, наливаете вкусного кофе, любуетесь видом из окна и обдумываете, как будете делать задачу.
Входит Руслан и тоже наливает себе кофе. “Над чем работаешь?” — спрашивает он. Вы рассказываете о новой фиче. Руслан меняется в лице. “Да ты что!” — восклицает он. — “Ни в коем случае эту функцию не надо делать! Наш продукт вообще не про это! Надо делать другую функцию!” И Руслан на клочке бумажки объясняет, что именно нужно делать. Это в корне отличается от задачи, которую поставил Матвей.
Комментарии к задачке, как обычно, послезавтра)
🛶 Комментарии к задачке 957-830
Вариант С странный для взрослого человека. Если вы не готовы работать в хаосе, хотите четких процессов, то что вы делаете в стартапе? А если понимаете, что жизнь в стартапе несовершенна, то чего ж сразу увольняться-то? Хаос, конфликты, неопределенность — стартаповская неизбежность. Потому и вариант F тоже не годится. Боитесь конфликтов — работайте в библиотеке.
Не стоит выбирать и вариант G. Вы же не очную ставку хотите устроить Руслану с Матвеем. И не посмотреть, как каждый бьется за свою точку зрения. Вообще, встреча — инструмент бюрократической структуры, когда с самого начала понятно, что договориться будет сложно. Если в стартапе такая же атмосфера, долго он не проживет.
Вариант D — для романтичных фантазеров. Фантазеров-вредителей. ) Если каждый будет в продукте делать то, что лично ему кажется правильным, продукт быстро отправится на кладбище. И, нет, это не ваш продукт, не надо иллюзий.
Варианты А и В вам одинаково не подходят. У вас просто нет оснований принимать решение самостоятельно. Матвея вы не можете проигнорировать — он ваш руководитель. Руслан — слишком значимая для компании фигура, чтобы не учитывать его точку зрения.
Так что верный вариант в этой ситуации — E. Эскалируете Матвею, пусть они с Русланом быстренько тет-а-тет все обсудят и решат, как действовать. Нужно будет ваше мнение — позовут. Но вряд ли.
История, когда менеджер говорит сотруднику делать одно, а основатель — совсем другое, типична для стартапов. Компания молодая, нет еще ни процессов, ни регламентов. Основатели редко задумываются о последствиях своих действий, им хочется быстрее бежать вперед. Но сотрудники совсем не обязательно такие. Многие пришли из компаний с выстроенными процессами. Работать в хаосе они не привыкли. И когда хаоса становится еще больше, люди теряются.
Ну и в идеальной ситуации мои комментарии должны были бы прочитать не вы, а Руслан. Потому что ты уж или в коде копаешься, или компанией управляешь. Пора определиться.
Вариант С странный для взрослого человека. Если вы не готовы работать в хаосе, хотите четких процессов, то что вы делаете в стартапе? А если понимаете, что жизнь в стартапе несовершенна, то чего ж сразу увольняться-то? Хаос, конфликты, неопределенность — стартаповская неизбежность. Потому и вариант F тоже не годится. Боитесь конфликтов — работайте в библиотеке.
Не стоит выбирать и вариант G. Вы же не очную ставку хотите устроить Руслану с Матвеем. И не посмотреть, как каждый бьется за свою точку зрения. Вообще, встреча — инструмент бюрократической структуры, когда с самого начала понятно, что договориться будет сложно. Если в стартапе такая же атмосфера, долго он не проживет.
Вариант D — для романтичных фантазеров. Фантазеров-вредителей. ) Если каждый будет в продукте делать то, что лично ему кажется правильным, продукт быстро отправится на кладбище. И, нет, это не ваш продукт, не надо иллюзий.
Варианты А и В вам одинаково не подходят. У вас просто нет оснований принимать решение самостоятельно. Матвея вы не можете проигнорировать — он ваш руководитель. Руслан — слишком значимая для компании фигура, чтобы не учитывать его точку зрения.
Так что верный вариант в этой ситуации — E. Эскалируете Матвею, пусть они с Русланом быстренько тет-а-тет все обсудят и решат, как действовать. Нужно будет ваше мнение — позовут. Но вряд ли.
История, когда менеджер говорит сотруднику делать одно, а основатель — совсем другое, типична для стартапов. Компания молодая, нет еще ни процессов, ни регламентов. Основатели редко задумываются о последствиях своих действий, им хочется быстрее бежать вперед. Но сотрудники совсем не обязательно такие. Многие пришли из компаний с выстроенными процессами. Работать в хаосе они не привыкли. И когда хаоса становится еще больше, люди теряются.
Ну и в идеальной ситуации мои комментарии должны были бы прочитать не вы, а Руслан. Потому что ты уж или в коде копаешься, или компанией управляешь. Пора определиться.
✂️ Спрашивали — отвечаем 27
“Сергей, давно и с удовольствием читаю ваш блог и наконец-то решилась на вопрос.) Я несколько лет управляю командами разработки, и каждый раз я стараюсь построить в команде процессы так, как мне нравится, но чтобы учитывалиись особенности окружающей среды в компании. Я беру за базу практики Agile и выстраиваю на их основе какой-то фреймворк имени меня. Может есть какой-то путь, которого я не вижу? Какие-то обязательные вещи, которые надо точно делать? Как вообще правильно такие процессы строить? Извините за сумбур. )”
Подход, который вы выбрали — создавать процессы каждый раз, с учетом специфики места работы и команды, — очень правильный. Я делаю точно так же. То, что сработает в маленькой компании, где утром что-то придумали, а вечером выложили на прод, вряд ли подойдет для огромной окологосударственной структуры, где на согласование документа могут уходить месяцы. Так что вы делаете все верно. )
Теперь про то, как это делать. Есть такое понятие — функционализм. Это когда мы смотрим на какой-то объект и пытаемся понять, каковы функции элементов, из которых он состоит. И, главное, насколько эти функции важны для нас, если сравнить с ценой, которую мы платим за этот элемент.
Ценой за использование обычно является время, которое команда тратит на следование процессу.
Сопоставляя важность элемента и цену, которую мы платим за его использование, можно решить, нужен он нам или нет. И если нет — смело от этого элемента избавиться.
Например, регламент управления рисками на двести страниц в вашей команде из трех человек нужен? Вряд ли — время на его создание и работу команды с ним явно перевесит пользу от его использования. Лучше придумать какой-то другой, не такой тяжелый способ управлять рисками.
Этот способ, кстати, универсален и применим в дизайне, в разработке, в строительстве, да где угодно. Функция элемента не оправдывает его цены? Долой элемент.
Убирая из проекта все лишнее, вы помогаете команде фокусироваться на главном. Чем проще людям работается — тем лучше.
“Сергей, давно и с удовольствием читаю ваш блог и наконец-то решилась на вопрос.) Я несколько лет управляю командами разработки, и каждый раз я стараюсь построить в команде процессы так, как мне нравится, но чтобы учитывалиись особенности окружающей среды в компании. Я беру за базу практики Agile и выстраиваю на их основе какой-то фреймворк имени меня. Может есть какой-то путь, которого я не вижу? Какие-то обязательные вещи, которые надо точно делать? Как вообще правильно такие процессы строить? Извините за сумбур. )”
Подход, который вы выбрали — создавать процессы каждый раз, с учетом специфики места работы и команды, — очень правильный. Я делаю точно так же. То, что сработает в маленькой компании, где утром что-то придумали, а вечером выложили на прод, вряд ли подойдет для огромной окологосударственной структуры, где на согласование документа могут уходить месяцы. Так что вы делаете все верно. )
Теперь про то, как это делать. Есть такое понятие — функционализм. Это когда мы смотрим на какой-то объект и пытаемся понять, каковы функции элементов, из которых он состоит. И, главное, насколько эти функции важны для нас, если сравнить с ценой, которую мы платим за этот элемент.
Ценой за использование обычно является время, которое команда тратит на следование процессу.
Сопоставляя важность элемента и цену, которую мы платим за его использование, можно решить, нужен он нам или нет. И если нет — смело от этого элемента избавиться.
Например, регламент управления рисками на двести страниц в вашей команде из трех человек нужен? Вряд ли — время на его создание и работу команды с ним явно перевесит пользу от его использования. Лучше придумать какой-то другой, не такой тяжелый способ управлять рисками.
Этот способ, кстати, универсален и применим в дизайне, в разработке, в строительстве, да где угодно. Функция элемента не оправдывает его цены? Долой элемент.
Убирая из проекта все лишнее, вы помогаете команде фокусироваться на главном. Чем проще людям работается — тем лучше.
💳 Влияние вознаграждения на результаты работы
Специалисты в экономике и менеджменте из уважаемых американских университетов выполняли эксперимент для Федеральной резервной системы. Они хотели понять, как влияет размер вознаграждения на результаты работы людей.
Собрали около ста человек и предложили им играть в разные игры — и моделирующие рутинную деятельность, и творческие. Участников разделили на три группы.
Первая группа за достижение определенного уровня результативности получала маленькое вознаграждение, примерно равное среднему дневному заработку.
Вторая группа получала двухнедельный заработок.
Третья группа — четырехмесячный заработок.
Итоги эксперимента удивили. Результативность второй группы была ничуть не лучше первой. А третья группа показала гораздо худшие результаты, чем первая и вторая.
Эксперименты повторяли с разными вариациями, в разных группах, в разных странах. Результат был один: при решении одинаковых задач более высокая награда сопутствовала худшим результатам.
Я ни в коем случае не призываю платить людям меньше. Но об этой истории полезно помнить всякий раз, когда вы нанимаете нового человека в команду. Правда ли его высокие зарплатные ожидания стоит немедленно удовлетворять?
Специалисты в экономике и менеджменте из уважаемых американских университетов выполняли эксперимент для Федеральной резервной системы. Они хотели понять, как влияет размер вознаграждения на результаты работы людей.
Собрали около ста человек и предложили им играть в разные игры — и моделирующие рутинную деятельность, и творческие. Участников разделили на три группы.
Первая группа за достижение определенного уровня результативности получала маленькое вознаграждение, примерно равное среднему дневному заработку.
Вторая группа получала двухнедельный заработок.
Третья группа — четырехмесячный заработок.
Итоги эксперимента удивили. Результативность второй группы была ничуть не лучше первой. А третья группа показала гораздо худшие результаты, чем первая и вторая.
Эксперименты повторяли с разными вариациями, в разных группах, в разных странах. Результат был один: при решении одинаковых задач более высокая награда сопутствовала худшим результатам.
Я ни в коем случае не призываю платить людям меньше. Но об этой истории полезно помнить всякий раз, когда вы нанимаете нового человека в команду. Правда ли его высокие зарплатные ожидания стоит немедленно удовлетворять?
📲 Тренажер для менеджеров и не только 958-831
Вы — руководитель отдела тестирования продуктовой компании. Ваши сотрудники прекрасно разбираются во всех продуктах, поэтому сосредоточены не только на внутренних технических задачах, но и много работают с продавцами: консультируют, помогают в пресейлах.
Один из продавцов, Назар, пытается заполучить нового клиента. Тот выдвинул требование: хочет посмотреть, как ваш продукт работает на iPad’e. Требование нетипичное, обычно продукт используют на телефонах или ноутбуках. Поэтому среди корпоративных тестовых девайсов iPad’a не нашлось.
Назар не сдался и решил найти iPad иным способом — у коллег.
Оказалось, что iPad есть только у одного человека — вашей сотрудницы, тестировщицы Дианы. Диана купила его за свои деньги, это ее личный гаджет. На нем она ведет дневник, смотрит видео, проходит онлайн-курсы.
Назар попросил Диану подключиться к этому пресейлу и дать попользоваться iPad’ом для демонстрации возможностей продукта. Диана отправила Назара к вам: именно вы выделяете своих сотрудников для пресейлов и прочих задач.
Назар написал вам письмо, в котором попросил дать сотрудника для участия в пресейле. Назар просит именно Диану, поскольку у нее есть нужный для демонстрации планшет.
Вы — руководитель отдела тестирования продуктовой компании. Ваши сотрудники прекрасно разбираются во всех продуктах, поэтому сосредоточены не только на внутренних технических задачах, но и много работают с продавцами: консультируют, помогают в пресейлах.
Один из продавцов, Назар, пытается заполучить нового клиента. Тот выдвинул требование: хочет посмотреть, как ваш продукт работает на iPad’e. Требование нетипичное, обычно продукт используют на телефонах или ноутбуках. Поэтому среди корпоративных тестовых девайсов iPad’a не нашлось.
Назар не сдался и решил найти iPad иным способом — у коллег.
Оказалось, что iPad есть только у одного человека — вашей сотрудницы, тестировщицы Дианы. Диана купила его за свои деньги, это ее личный гаджет. На нем она ведет дневник, смотрит видео, проходит онлайн-курсы.
Назар попросил Диану подключиться к этому пресейлу и дать попользоваться iPad’ом для демонстрации возможностей продукта. Диана отправила Назара к вам: именно вы выделяете своих сотрудников для пресейлов и прочих задач.
Назар написал вам письмо, в котором попросил дать сотрудника для участия в пресейле. Назар просит именно Диану, поскольку у нее есть нужный для демонстрации планшет.