🦠 Меняться прямо сейчас
Очень удивляет настрой некоторых компаний: «Кажется, мы это пережили! Наконец-то. Ура!»
Надо воспринимать работу в карантине как MVP продукта «удаленка». Компании смогли протестировать своих людей и процессы. Самое время интенсивно улучшать и то, и другое. А если придется — полностью менять.
Не радоваться сохранению рабочего темпа, а открыть проект по обновлению компании. Назначить менеджера этого проекта, определить цели, сформулировать гипотезы и бегом начинать трудиться. Чтобы успеть.
Потому что когда случится «новая волна заражения», или COVID-20, или HRENOVID-21, то тем, кто относительно благополучно пережил этот карантин, второй раз может и не повезти.
А то все ратуют за правильные проектные и продуктовые практики, ходят на семинары, читают книжки, ведут блоги и гордятся своим непрерывным развитием. Но очевидных выводов из вполне конкретного жизненного кейса сделать то ли не могут, то ли не хотят.
Очень удивляет настрой некоторых компаний: «Кажется, мы это пережили! Наконец-то. Ура!»
Надо воспринимать работу в карантине как MVP продукта «удаленка». Компании смогли протестировать своих людей и процессы. Самое время интенсивно улучшать и то, и другое. А если придется — полностью менять.
Не радоваться сохранению рабочего темпа, а открыть проект по обновлению компании. Назначить менеджера этого проекта, определить цели, сформулировать гипотезы и бегом начинать трудиться. Чтобы успеть.
Потому что когда случится «новая волна заражения», или COVID-20, или HRENOVID-21, то тем, кто относительно благополучно пережил этот карантин, второй раз может и не повезти.
А то все ратуют за правильные проектные и продуктовые практики, ходят на семинары, читают книжки, ведут блоги и гордятся своим непрерывным развитием. Но очевидных выводов из вполне конкретного жизненного кейса сделать то ли не могут, то ли не хотят.
🤖🤖 Подкрался незаметно
Утренние новости впечатляют. Алиса Яндексовна научилась писать картины. Может по заказу пользователя изобразить хоть оливковую рощу, хоть натюрморт. Майкрософт уволил журналистов и редакторов из новостного подразделения MSN. Их работу теперь делает искусственный интеллект.
Создание текстов и картин — творческие задачи, но их досконально изучили. А изученное легко алгоритмизировать. И это только начало.
Делаете что-то несложное? Вас очень скоро заменят на ИИ.
Делаете что-то, на первый взгляд, сложное? Разложат на простые компоненты и заменят на ИИ.
Так и вижу новых луддитов, которые ничего не ломают, но тщательно охраняют цеховые секреты, скрывают нюансы своей работы, запутывают алгоритмизаторов, чтобы продержаться на рынке подольше.
ИИ не устает, ему не надо платить зарплату, он не борется за права женщин и не берет отгул для визита к стоматологу. Он не хочет карьерного роста, не устает от рутины и не болеет короновирусом.
Вы правда думаете, что ИИ не справится с юнит-экономикой, проверкой гипотез и кастдевом? Ох уж эти надежды.
Утренние новости впечатляют. Алиса Яндексовна научилась писать картины. Может по заказу пользователя изобразить хоть оливковую рощу, хоть натюрморт. Майкрософт уволил журналистов и редакторов из новостного подразделения MSN. Их работу теперь делает искусственный интеллект.
Создание текстов и картин — творческие задачи, но их досконально изучили. А изученное легко алгоритмизировать. И это только начало.
Делаете что-то несложное? Вас очень скоро заменят на ИИ.
Делаете что-то, на первый взгляд, сложное? Разложат на простые компоненты и заменят на ИИ.
Так и вижу новых луддитов, которые ничего не ломают, но тщательно охраняют цеховые секреты, скрывают нюансы своей работы, запутывают алгоритмизаторов, чтобы продержаться на рынке подольше.
ИИ не устает, ему не надо платить зарплату, он не борется за права женщин и не берет отгул для визита к стоматологу. Он не хочет карьерного роста, не устает от рутины и не болеет короновирусом.
Вы правда думаете, что ИИ не справится с юнит-экономикой, проверкой гипотез и кастдевом? Ох уж эти надежды.
🤦🏽 Perception is always reality
Открыл Облако от Mail.ru, решил выполнить несложную операцию. Облако мне выдало прекрасное сообщение (картинка внизу). Три ошибки и ощущение, что это писал полуразумный дырокол. Обнять и плакать, честное слово.
Я думаю, такие проблемы в интерфейсе надо решать административными методами. )
По тому, что у вас в интефейсе написано, ваш продукт и оценивают. Perception is reality.
Открыл Облако от Mail.ru, решил выполнить несложную операцию. Облако мне выдало прекрасное сообщение (картинка внизу). Три ошибки и ощущение, что это писал полуразумный дырокол. Обнять и плакать, честное слово.
Я думаю, такие проблемы в интерфейсе надо решать административными методами. )
По тому, что у вас в интефейсе написано, ваш продукт и оценивают. Perception is reality.
🧩 О монетизации продукта
Самый честный вариант оплаты продукта — дать пользователям бесплатный начальный период, а потом установить цену выше, чем у конкурентов. Начальный период должен быть достаточным для изучения особенностей продукта. Скажем, месяц, а не неделя и не три дня. Ограничений функций продукта быть не должно.
Это вызов: задается высокий уровень ожидаемого качества и пользы. Если пользы нет, то после начального периода люди просто удалят приложение.
Скачок от бесплатного периода к платному и дорогому использованию — еще больший вызов. Чтобы продукт жил, придется приносить людям больше пользы, чем конкуренты. И у автора только один шанс убедить пользователя заплатить.
Мой пользовательский опыт говорит, что это самый правильный способ привязать меня к продукту. Причем это не зависит от продукта вообще — я предпочитаю эту схему для любого приложения, в какой угодно сфере.
Все остальные варианты меня либо дико раздражают, либо просто не работают.
Самый честный вариант оплаты продукта — дать пользователям бесплатный начальный период, а потом установить цену выше, чем у конкурентов. Начальный период должен быть достаточным для изучения особенностей продукта. Скажем, месяц, а не неделя и не три дня. Ограничений функций продукта быть не должно.
Это вызов: задается высокий уровень ожидаемого качества и пользы. Если пользы нет, то после начального периода люди просто удалят приложение.
Скачок от бесплатного периода к платному и дорогому использованию — еще больший вызов. Чтобы продукт жил, придется приносить людям больше пользы, чем конкуренты. И у автора только один шанс убедить пользователя заплатить.
Мой пользовательский опыт говорит, что это самый правильный способ привязать меня к продукту. Причем это не зависит от продукта вообще — я предпочитаю эту схему для любого приложения, в какой угодно сфере.
Все остальные варианты меня либо дико раздражают, либо просто не работают.
🚙 О создании одного великого продукта
Любопытно взглянуть из нашего времени на проект создания Ford T, самого знаменитого детища Генри Форда.
=> Форд выделил для проектной команды целый этаж своего завода в Дирборне. Вход туда был разрешен только Форду, одному из топ-менеджеров и нескольким лучшим инженерам. Команда не имела права общаться с другими сотрудниками завода. Ее общение с внешним миром тоже ограничили.
Изоляция команды избавила ее от политики, слухов и дрязг. Этим приемом пользовались потом и Стив Джобс, и Илон Маск. В наших реалиях можно хотя бы отгородить зону оупенспейса – уже поможет.
=> Команда работала с раннего утра до позднего вечера. Ей дали все материалы для работы, включая плавильную печь и станки для обработки металла. И обеспечивали всем необходимым по первому требованию.
Люди должны быть полностью сфокусированы на задаче и не отвлекаться на мелочи и быт. Ваш сотрудник не должен тратить время на заказ канцтоваров или ждать, когда сонный админ ему что-то там настроит.
=> Форд проводил с командой все время, что позволяло быстро принимать решения в проекте.
Никаких комитетов и бюрократии. А у менеджера – максимум полномочий.
=> В процессе команда столкнулась со сложной проблемой – расчетный вес автомобиля составлял тонну. Форд требовал не больше 900 кг. Чтобы решить эту задачу, срочно пригласили экспертов из неавтомобильной сферы. Задачу решили, машина стала весить около 850 кг, и команда двинулась дальше.
Форд поощрял нестандартные идеи и использовал любой полезный опыт. Почему мы так редко подключаем профи из других сфер и рынков?
=> Перед проектной командой с самого начала поставили цель: сделать дешевый в производстве автомобиль из простых узлов. Команда сфокусировалась на этом, а не на удобстве использования продукта. Получилась, мягко говоря, необычная машина. В отличие от других марок, у Ford Т педаль газа была не педалью, а маленьким рычажком с правой стороны под рулевой колонкой. Зато передачи переключались педалями, причем этих педалей было три. Владельцам Ford T в некоторых штатах даже пришлось выдавать отдельные права.
На крутых подъемах у автомобиля глох двигатель. Есть байка, что один фермер пообещал купить машину, если она сможет преодолеть холм на пути к его дому. Продавец не растерялся, заехал на подъем до половины, развернулся и доехал до конца задним ходом. Это был единственный способ подняться на этой машине в гору.
Форд прекрасно знал о недостатках, но разрешил выпуск в серию. Он просто распорядился поставлять с каждым автомобилем набор инструментов – видите на фото ящик на подножке?
Вот вам MVP за сто лет до всяких аджайлов. Форд был сначала менеджером, а только потом инженером. И потому продукт вышел на рынок. А было бы наоборот, погрязло бы все в непрерывных улучшениях. Инженеров к управлению проектами и продуктами допускать нельзя, пока они мыслят как инженеры.
=> Форд еще на старте проекта думал о продвижении продукта. Чтобы снизить цену, Форд предложил гениальный маркетинговый ход: продавать автомобиль «в базовой комлектации», а все дополнения – за деньги. Даже зеркала и запасное колесо считались опциями, за них покупателю приходилось доплачивать.
Ну, это до сих пор используется. Во всех продуктах. )
Любопытно взглянуть из нашего времени на проект создания Ford T, самого знаменитого детища Генри Форда.
=> Форд выделил для проектной команды целый этаж своего завода в Дирборне. Вход туда был разрешен только Форду, одному из топ-менеджеров и нескольким лучшим инженерам. Команда не имела права общаться с другими сотрудниками завода. Ее общение с внешним миром тоже ограничили.
Изоляция команды избавила ее от политики, слухов и дрязг. Этим приемом пользовались потом и Стив Джобс, и Илон Маск. В наших реалиях можно хотя бы отгородить зону оупенспейса – уже поможет.
=> Команда работала с раннего утра до позднего вечера. Ей дали все материалы для работы, включая плавильную печь и станки для обработки металла. И обеспечивали всем необходимым по первому требованию.
Люди должны быть полностью сфокусированы на задаче и не отвлекаться на мелочи и быт. Ваш сотрудник не должен тратить время на заказ канцтоваров или ждать, когда сонный админ ему что-то там настроит.
=> Форд проводил с командой все время, что позволяло быстро принимать решения в проекте.
Никаких комитетов и бюрократии. А у менеджера – максимум полномочий.
=> В процессе команда столкнулась со сложной проблемой – расчетный вес автомобиля составлял тонну. Форд требовал не больше 900 кг. Чтобы решить эту задачу, срочно пригласили экспертов из неавтомобильной сферы. Задачу решили, машина стала весить около 850 кг, и команда двинулась дальше.
Форд поощрял нестандартные идеи и использовал любой полезный опыт. Почему мы так редко подключаем профи из других сфер и рынков?
=> Перед проектной командой с самого начала поставили цель: сделать дешевый в производстве автомобиль из простых узлов. Команда сфокусировалась на этом, а не на удобстве использования продукта. Получилась, мягко говоря, необычная машина. В отличие от других марок, у Ford Т педаль газа была не педалью, а маленьким рычажком с правой стороны под рулевой колонкой. Зато передачи переключались педалями, причем этих педалей было три. Владельцам Ford T в некоторых штатах даже пришлось выдавать отдельные права.
На крутых подъемах у автомобиля глох двигатель. Есть байка, что один фермер пообещал купить машину, если она сможет преодолеть холм на пути к его дому. Продавец не растерялся, заехал на подъем до половины, развернулся и доехал до конца задним ходом. Это был единственный способ подняться на этой машине в гору.
Форд прекрасно знал о недостатках, но разрешил выпуск в серию. Он просто распорядился поставлять с каждым автомобилем набор инструментов – видите на фото ящик на подножке?
Вот вам MVP за сто лет до всяких аджайлов. Форд был сначала менеджером, а только потом инженером. И потому продукт вышел на рынок. А было бы наоборот, погрязло бы все в непрерывных улучшениях. Инженеров к управлению проектами и продуктами допускать нельзя, пока они мыслят как инженеры.
=> Форд еще на старте проекта думал о продвижении продукта. Чтобы снизить цену, Форд предложил гениальный маркетинговый ход: продавать автомобиль «в базовой комлектации», а все дополнения – за деньги. Даже зеркала и запасное колесо считались опциями, за них покупателю приходилось доплачивать.
Ну, это до сих пор используется. Во всех продуктах. )
📡 Великие проекты: создание БТА
Один из проектов, поражающих воображение – создание БТА (Большого Телескопа Азимутального).
Для гуманитариев: такой телескоп – это не большая подзорная труба, а что-то вроде спутниковой тарелки. Только она сделана из зеркала.
Проект стартовал в 1960-м году, его менеджером стал Баграт Иоаннисиани, хороший управленец и талантливый конструктор.
Проект разделили на параллельные потоки работ:
1. Изготовить и собрать конструкцию телескопа.
2. Сделать зеркало.
3. Доставить результаты пунктов 1 и 2 на Кавказ, в Карачаево-Черкессию.
4. Установить и собрать телескоп.
Вот несколько фактов:
=> Для изготовления конструкции телескопа построили новый цех высотой с двадцатиэтажный дом.
=> Изготовление конструкции заняло пять лет, а сборка – еще полтора. Конструкция была готова в 1968 году.
=> Самое сложное – сделать зеркало. Представьте себе стеклянную тарелку высотой до второго этажа и массой как 60 легковых автомобилей. Для создания прототипа (!) зеркала построили отдельный цех, чтобы отработать технологию. На нее ушло три года.
=> Надо было отлить зеркало, а потом делать отверстия для крепления, придавать нужную форму, полировать. Для этого сконструировали и сделали новые станки и инструменты.
=> Зеркало отливали два года и закончили в 1966 г. Обработка же была закончена только в 1971 году! Итого 11 лет на зеркало. Почему столько возни? Зеркало такого диаметра очень сложно сделать (в мире никто до нас не делал), и оно должно быть идеальным. Даже микроскопические неровности делают работу бессмысленной. Огромная стеклянная штуковина два года остывала в стерильных условиях.
Где хороший продукт, там всегда куча баек. Одна мне особенно запомнилась, я ее услышал от сотрудника обсерватории.
В проектной команде было много страстно влюбленных в науку молодых людей. Они буквально жили этим проектом. И вот выясняется, что первая заготовка зеркала получилась бракованная. Один из молодых ученых не верит, что кто-то будет заморачиваться с изготовлением нового зеркала. Слишком много в стране делается «для галочки». Он решает, что брак должен быть уничтожен, приносит в цех что-то вроде крупнокалиберного патрона, зажимает его в тисках и ложится сверху. Выстрел, в зеркале круглая дырочка, молодой человек мертв. Такая вот команда. Мотивированная.
=> Телескоп доставили на Кавказ довольно быстро, за год. Но вот с зеркалом получилась засада. Как его везти? Это аморфная субстанция. Диаметром 6 м и массой 42 т. Встряска на кочке – начинаем проект заново. Малейшее колебание температуры – зеркало на выброс.
Тогда сделали масляные амортизаторы, погрузили на них зеркало, уложили в контейнер с постоянной температурой. До этого провели тест на прототипе, свозили его на Кавказ, отработали процесс.
Везли зеркало два месяца на баржах до Ростова-на-Дону. Потом месяц в горы на трейлерах c милицейским эскортом.
=> На месте еще около года конструкцию собирали и тестировали. В 1975 году телескоп запустили в эксплуатацию.
=> Иоаннисиани был настолько крут, что получил степень доктора наук без защиты диссертации. У него даже не было высшего образования.
Привет компаниям, не приглашающим на интервью кандидатов без диплома.
Пятнадцать лет напряженной работы. Преодоление огромного числа технических и административных препятствий. Создание целой отрасли.
А ведь еще надо астрономов завезти.)
БТА смогли превзойти американцы, построив телескоп с зеркалом большего диаметра. Но только двадцать лет спустя.
Один из проектов, поражающих воображение – создание БТА (Большого Телескопа Азимутального).
Для гуманитариев: такой телескоп – это не большая подзорная труба, а что-то вроде спутниковой тарелки. Только она сделана из зеркала.
Проект стартовал в 1960-м году, его менеджером стал Баграт Иоаннисиани, хороший управленец и талантливый конструктор.
Проект разделили на параллельные потоки работ:
1. Изготовить и собрать конструкцию телескопа.
2. Сделать зеркало.
3. Доставить результаты пунктов 1 и 2 на Кавказ, в Карачаево-Черкессию.
4. Установить и собрать телескоп.
Вот несколько фактов:
=> Для изготовления конструкции телескопа построили новый цех высотой с двадцатиэтажный дом.
=> Изготовление конструкции заняло пять лет, а сборка – еще полтора. Конструкция была готова в 1968 году.
=> Самое сложное – сделать зеркало. Представьте себе стеклянную тарелку высотой до второго этажа и массой как 60 легковых автомобилей. Для создания прототипа (!) зеркала построили отдельный цех, чтобы отработать технологию. На нее ушло три года.
=> Надо было отлить зеркало, а потом делать отверстия для крепления, придавать нужную форму, полировать. Для этого сконструировали и сделали новые станки и инструменты.
=> Зеркало отливали два года и закончили в 1966 г. Обработка же была закончена только в 1971 году! Итого 11 лет на зеркало. Почему столько возни? Зеркало такого диаметра очень сложно сделать (в мире никто до нас не делал), и оно должно быть идеальным. Даже микроскопические неровности делают работу бессмысленной. Огромная стеклянная штуковина два года остывала в стерильных условиях.
Где хороший продукт, там всегда куча баек. Одна мне особенно запомнилась, я ее услышал от сотрудника обсерватории.
В проектной команде было много страстно влюбленных в науку молодых людей. Они буквально жили этим проектом. И вот выясняется, что первая заготовка зеркала получилась бракованная. Один из молодых ученых не верит, что кто-то будет заморачиваться с изготовлением нового зеркала. Слишком много в стране делается «для галочки». Он решает, что брак должен быть уничтожен, приносит в цех что-то вроде крупнокалиберного патрона, зажимает его в тисках и ложится сверху. Выстрел, в зеркале круглая дырочка, молодой человек мертв. Такая вот команда. Мотивированная.
=> Телескоп доставили на Кавказ довольно быстро, за год. Но вот с зеркалом получилась засада. Как его везти? Это аморфная субстанция. Диаметром 6 м и массой 42 т. Встряска на кочке – начинаем проект заново. Малейшее колебание температуры – зеркало на выброс.
Тогда сделали масляные амортизаторы, погрузили на них зеркало, уложили в контейнер с постоянной температурой. До этого провели тест на прототипе, свозили его на Кавказ, отработали процесс.
Везли зеркало два месяца на баржах до Ростова-на-Дону. Потом месяц в горы на трейлерах c милицейским эскортом.
=> На месте еще около года конструкцию собирали и тестировали. В 1975 году телескоп запустили в эксплуатацию.
=> Иоаннисиани был настолько крут, что получил степень доктора наук без защиты диссертации. У него даже не было высшего образования.
Привет компаниям, не приглашающим на интервью кандидатов без диплома.
Пятнадцать лет напряженной работы. Преодоление огромного числа технических и административных препятствий. Создание целой отрасли.
А ведь еще надо астрономов завезти.)
БТА смогли превзойти американцы, построив телескоп с зеркалом большего диаметра. Но только двадцать лет спустя.
❓Задачка на интервью
Кандидату на позицию менеджера проектов я даю на интервью всякие задачки. Среди них такая:
“Представьте, что вы — менеджер проекта разработки некой информационной системы. По подписанным договору и ТЗ, система состоит из 10 функций. У вашей команды на создание продукта есть 10 месяцев. Бюджет проекта — 10 рублей.
Итак: 10 функций, 10 месяцев, 10 рублей.
Команда начинает работать, все идет хорошо. Через 6 месяцев к вам приходит заказчик и говорит: “Я очень рад, что с нашим проектом все в порядке. Но я хочу, чтобы вы добавили в мою систему еще две функции”.
Расскажите подробно, как вы будете действовать в этом случае”.
Почти все кандидаты, разумеется, начинают с оценивания возникших доработок. Тогда я говорю: “ОК. Результат оценки — нужно еще 2 месяца и 2 рубля.” Кандидаты предлагают сдвинуть сроки окончания проекта. Или заменить какие-то старые функции на две новые. Или нанять команду, которая бы параллельно запилила две новые функции. Или уговорить клиента сдать сначала старые, а потом открыть еще один проект и сделать новые функции. Или выполнить дополнительную работу бесплатно, если клиент для нас важен. Или послать его куда подальше, договор-то подписан, а в нем про новые функции нет ни слова.
Это все правильно, но задача про другое.)
Поэтому я говорю: “ОК. Заказчик отказывается сдвигать сроки проекта и не дает денег. У вас было 10 функций, 10 месяцев, 10 рублей. А теперь 12 функций, 10 месяцев и 10 рублей. И ваше руководство поддержало заказчика, и денег тоже не даст. Какие у вас еще есть управленческие инструменты, чтобы помочь заказчику?”
И тут примерно 80% кандидатов впадают в ступор. И не знают, что же делать.
Это очень удивительно. Задачка-то совсем простая.
Вы же знаете ответ, да? )
Кандидату на позицию менеджера проектов я даю на интервью всякие задачки. Среди них такая:
“Представьте, что вы — менеджер проекта разработки некой информационной системы. По подписанным договору и ТЗ, система состоит из 10 функций. У вашей команды на создание продукта есть 10 месяцев. Бюджет проекта — 10 рублей.
Итак: 10 функций, 10 месяцев, 10 рублей.
Команда начинает работать, все идет хорошо. Через 6 месяцев к вам приходит заказчик и говорит: “Я очень рад, что с нашим проектом все в порядке. Но я хочу, чтобы вы добавили в мою систему еще две функции”.
Расскажите подробно, как вы будете действовать в этом случае”.
Почти все кандидаты, разумеется, начинают с оценивания возникших доработок. Тогда я говорю: “ОК. Результат оценки — нужно еще 2 месяца и 2 рубля.” Кандидаты предлагают сдвинуть сроки окончания проекта. Или заменить какие-то старые функции на две новые. Или нанять команду, которая бы параллельно запилила две новые функции. Или уговорить клиента сдать сначала старые, а потом открыть еще один проект и сделать новые функции. Или выполнить дополнительную работу бесплатно, если клиент для нас важен. Или послать его куда подальше, договор-то подписан, а в нем про новые функции нет ни слова.
Это все правильно, но задача про другое.)
Поэтому я говорю: “ОК. Заказчик отказывается сдвигать сроки проекта и не дает денег. У вас было 10 функций, 10 месяцев, 10 рублей. А теперь 12 функций, 10 месяцев и 10 рублей. И ваше руководство поддержало заказчика, и денег тоже не даст. Какие у вас еще есть управленческие инструменты, чтобы помочь заказчику?”
И тут примерно 80% кандидатов впадают в ступор. И не знают, что же делать.
Это очень удивительно. Задачка-то совсем простая.
Вы же знаете ответ, да? )
🔆 Ответ к задачке
Задачка действительно детская. Чем управляет менеджер проекта? Временем, стоимостью, содержанием проекта и его качеством. Точнее, он управляет балансом этих характеристик. В нашем кейсе жестко зафиксированы и деньги, и время. По условиям задачи, договориться не удалось, эскалация не помогла. И чтобы впихнуть незапланированные функции в систему, остается только ухудшать качество.
В ИТ-проекте можно снизить количество и детализацию тестов, убрать сложные интеграции. Отказаться можно от всего красивого и удобного, но при этом требующего значительных трудозатрат.
Хотели, чтобы отчеты строились автоматически? Убрать, заменить на ручное построение. Думали сделать удобную админку? Сорри.
Это плохая история для ИТ-проектов: кто ж в здравом уме хочет снижать качество своего продукта? Но ситуации бывают разные. И кандидат должен знать об этой управленческой опции и понимать основы проектного менеджмента.
А кто не понимает — работает в каких-то других компаниях. )
Задачка действительно детская. Чем управляет менеджер проекта? Временем, стоимостью, содержанием проекта и его качеством. Точнее, он управляет балансом этих характеристик. В нашем кейсе жестко зафиксированы и деньги, и время. По условиям задачи, договориться не удалось, эскалация не помогла. И чтобы впихнуть незапланированные функции в систему, остается только ухудшать качество.
В ИТ-проекте можно снизить количество и детализацию тестов, убрать сложные интеграции. Отказаться можно от всего красивого и удобного, но при этом требующего значительных трудозатрат.
Хотели, чтобы отчеты строились автоматически? Убрать, заменить на ручное построение. Думали сделать удобную админку? Сорри.
Это плохая история для ИТ-проектов: кто ж в здравом уме хочет снижать качество своего продукта? Но ситуации бывают разные. И кандидат должен знать об этой управленческой опции и понимать основы проектного менеджмента.
А кто не понимает — работает в каких-то других компаниях. )
🎳 Тренажер для менеджеров и не только: 69-17
Вы — аналитик в команде, работающей над важным проектом в крупной компании. Отвечаете за сбор требований, их анализ и трансляцию исполнителям.
Проект идет шустро, и вы тоже молодец: все успеваете, менеджер проекта вашей работой очень доволен.
Однажды в зоне отдыха, где вы пьете чай и лениво листаете новости на планшете, к вам подсаживается один из сотрудников. Его зовут Олег, вы давно с ним знакомы — два года назад вы почти одновременно пришли в эту компанию работать. Но карьера Олега развивается быстрее, три месяца назад он перешел из специалистов в менеджеры. Ему дали пару небольших проектов и, как он рассказал, даже увеличили зарплату.
Нельзя сказать, что вы большие друзья с Олегом. Но время от времени встречаетесь за чашкой чая поболтать и, чего уж греха таить, посплетничать. Олег — приятный и остроумный собеседник, очень неглупый человек. Благодаря общению с ним, вы всегда в курсе событий в других подразделениях.
В этот раз Олег хочет не просто поболтать, у него к вам большая просьба. Один из его проектов зарулил в тупик, и Олег сам в тупике. По его словам, аналитик в его проекте слабенький. Из-за его странных технических решений команда не понимает, что делать. Проект отстает от графика, клиенты нервничают.
Олег просит вас помочь вытащить проект из болота.
Выслушав общее описание проблемы, вы осознаете, что тема вам знакома и интересна. Но надо выяснить детали. На анализ уйдет неделя или две, в зависимости от вашей загрузки по основному проекту. Еще неделя уйдет на формализацию решения.
Вы — аналитик в команде, работающей над важным проектом в крупной компании. Отвечаете за сбор требований, их анализ и трансляцию исполнителям.
Проект идет шустро, и вы тоже молодец: все успеваете, менеджер проекта вашей работой очень доволен.
Однажды в зоне отдыха, где вы пьете чай и лениво листаете новости на планшете, к вам подсаживается один из сотрудников. Его зовут Олег, вы давно с ним знакомы — два года назад вы почти одновременно пришли в эту компанию работать. Но карьера Олега развивается быстрее, три месяца назад он перешел из специалистов в менеджеры. Ему дали пару небольших проектов и, как он рассказал, даже увеличили зарплату.
Нельзя сказать, что вы большие друзья с Олегом. Но время от времени встречаетесь за чашкой чая поболтать и, чего уж греха таить, посплетничать. Олег — приятный и остроумный собеседник, очень неглупый человек. Благодаря общению с ним, вы всегда в курсе событий в других подразделениях.
В этот раз Олег хочет не просто поболтать, у него к вам большая просьба. Один из его проектов зарулил в тупик, и Олег сам в тупике. По его словам, аналитик в его проекте слабенький. Из-за его странных технических решений команда не понимает, что делать. Проект отстает от графика, клиенты нервничают.
Олег просит вас помочь вытащить проект из болота.
Выслушав общее описание проблемы, вы осознаете, что тема вам знакома и интересна. Но надо выяснить детали. На анализ уйдет неделя или две, в зависимости от вашей загрузки по основному проекту. Еще неделя уйдет на формализацию решения.
🔎 Комментарии к задачке 69-17
Варианты А и В выбирают обычно люди молодые и энергичные. У них нет ни многочисленных обязательств, ни жесткого жизненного графика. Зато нет и опыта решения задач, они с радостью возьмутся за еще одну. Хорошие отношения — это замечательно, но личные приоритеты важнее. Выгода — понятие обтекаемое, если она не выражена в конкретном предложении. Если Олег так хорош в карьере, почему он этого не понимает? Или понимает, но молчит? )
Вариант С годится только в том случае, если задача Олега вам совсем не интересна. Но тягу к новому и жажду учиться ведь никто не отменял? С этой точки зрения вариант D ничем не лучше.
Вариант Е не так уж плох. Никто не знает, как повернется жизнь: вдруг вы дадите аналитику Олега такой совет, от которого всем будет только хуже? Кто будет отвечать за результат? Советы только тогда чего-то стоят, если за них несут ответственность. Иначе это просто легкий треп ни о чем.
А еще советы хоть чего-то стоят, если за них готовы платить. И не обязательно деньгами. Например, в одной компании такой "валютой" были дни дежурства по выходным — разработчики не любили дежурить и обменивали свои часы дежурства на какие-то услуги. Поэтому вариант F весьма жизнеспособен. Хотя с ним надо аккуратнее: если что-то случится с основным проектом, как вы будете разрываться между двух?
Что касается варианта G, то и тут все не очень просто и зависит от культуры компании. Если она предполагает помощь и сотрудничество, то все в порядке. Если же нет, то менеджеру нет смысла делить вас с другими проектами. Зачем ему лишние риски?
Но согласовать свое участие в других задачах — это подход профессионала. Так что вариант G — самый верный. Приятно, что большинство читателей это понимает.
В жизни еще можно комбинировать варианты F и G. Это разумно.
Еще раз:
1) Вы не обязаны делать ничью работу без вознаграждения, которое считаете адекватным. Интересная задача — тоже награда.
2) Вы можете делать все что угодно в свободное время. Но что такое свободное время в жестком и сложном проекте?
3) Ничего не надо делать ради "хороших отношений". Особенно если за дверью офиса у вас еще огромная жизнь и личные планы.
4) Одно дело — дать комментарий, помочь советом, который не требует долгого изучения вопроса, другое дело — работать над задачей.
5) Помощь людям — дело хорошее. Только не увлекайтесь. )
Варианты А и В выбирают обычно люди молодые и энергичные. У них нет ни многочисленных обязательств, ни жесткого жизненного графика. Зато нет и опыта решения задач, они с радостью возьмутся за еще одну. Хорошие отношения — это замечательно, но личные приоритеты важнее. Выгода — понятие обтекаемое, если она не выражена в конкретном предложении. Если Олег так хорош в карьере, почему он этого не понимает? Или понимает, но молчит? )
Вариант С годится только в том случае, если задача Олега вам совсем не интересна. Но тягу к новому и жажду учиться ведь никто не отменял? С этой точки зрения вариант D ничем не лучше.
Вариант Е не так уж плох. Никто не знает, как повернется жизнь: вдруг вы дадите аналитику Олега такой совет, от которого всем будет только хуже? Кто будет отвечать за результат? Советы только тогда чего-то стоят, если за них несут ответственность. Иначе это просто легкий треп ни о чем.
А еще советы хоть чего-то стоят, если за них готовы платить. И не обязательно деньгами. Например, в одной компании такой "валютой" были дни дежурства по выходным — разработчики не любили дежурить и обменивали свои часы дежурства на какие-то услуги. Поэтому вариант F весьма жизнеспособен. Хотя с ним надо аккуратнее: если что-то случится с основным проектом, как вы будете разрываться между двух?
Что касается варианта G, то и тут все не очень просто и зависит от культуры компании. Если она предполагает помощь и сотрудничество, то все в порядке. Если же нет, то менеджеру нет смысла делить вас с другими проектами. Зачем ему лишние риски?
Но согласовать свое участие в других задачах — это подход профессионала. Так что вариант G — самый верный. Приятно, что большинство читателей это понимает.
В жизни еще можно комбинировать варианты F и G. Это разумно.
Еще раз:
1) Вы не обязаны делать ничью работу без вознаграждения, которое считаете адекватным. Интересная задача — тоже награда.
2) Вы можете делать все что угодно в свободное время. Но что такое свободное время в жестком и сложном проекте?
3) Ничего не надо делать ради "хороших отношений". Особенно если за дверью офиса у вас еще огромная жизнь и личные планы.
4) Одно дело — дать комментарий, помочь советом, который не требует долгого изучения вопроса, другое дело — работать над задачей.
5) Помощь людям — дело хорошее. Только не увлекайтесь. )
♟♟ Тренажер для менеджеров и не только: 73-24
Вы — менеджер проекта по разработке софта в крупной компании. Ваша команда уже несколько лет разрабатывает важный продукт.
Вы используете систему управления задачами, которую создавали и развивали не один год. С ее внедрением разработка стала прозрачной, действия членов команды стали измеримы, задачи планируются и исполняются в предсказуемые сроки. Но самое главное — из проекта ушел хаос и критические проблемы в продукте.
В систему включены все процессы: и поддержка на нужном уровне всех тестовых серверов, и регулярный контроль качества, и многое другое. Вы внесли огромный вклад в становление этой системы и гордитесь, что в вашем проекте отсутствуют критические сбои, несмотря на постоянное внедрение новой сложной функциональности, обновляющуюся команду и прочие внешние факторы.
И вот к вам в проект приходит новый программист — Петр. Он хороший специалист, и довольно быстро разбирается в своих задачах. Но вот с дисциплиной у Петра так себе — вам стоит огромных усилий заставить его работать по установленным правилам. Петр следует им неохотно, хотя вы и объясняли ему их важность, и умоляли, и угрожали, и исчерпали свой управленческий арсенал.
Вам приходится специально следить, чтобы он следовал правилам. Вам совсем не хочется расставаться с Петром, но работа с ним доставляет вам много менеджерской головной боли, совершенно неоправданной. Пока вы решили потерпеть.
Однажды Петр подходит к вам и говорит, что ему в голову пришла интересная идея, он посидел несколько выходных и сделал улучшение, которое сильно облегчит работу команды, да и жизнь клиентов тоже. Вы даете это улучшение на оценку экспертам из команды, и они соглашаются, что это свежая и полезная штука. Вы благодарите Петра и долго хвалите его.
Приближается конец отчетного периода, и высокое начальство просит вас выбрать сотрудника, которого можно наградить крупной денежной премией за хорошую работу. Петр кажется лучшим кандидатом. Его разработка всем сильно помогла.
Но как это вяжется с нежеланием Петра следовать процессам? Ведь он неоднократно создавал серьезные риски для команды и продукта.
Вы — менеджер проекта по разработке софта в крупной компании. Ваша команда уже несколько лет разрабатывает важный продукт.
Вы используете систему управления задачами, которую создавали и развивали не один год. С ее внедрением разработка стала прозрачной, действия членов команды стали измеримы, задачи планируются и исполняются в предсказуемые сроки. Но самое главное — из проекта ушел хаос и критические проблемы в продукте.
В систему включены все процессы: и поддержка на нужном уровне всех тестовых серверов, и регулярный контроль качества, и многое другое. Вы внесли огромный вклад в становление этой системы и гордитесь, что в вашем проекте отсутствуют критические сбои, несмотря на постоянное внедрение новой сложной функциональности, обновляющуюся команду и прочие внешние факторы.
И вот к вам в проект приходит новый программист — Петр. Он хороший специалист, и довольно быстро разбирается в своих задачах. Но вот с дисциплиной у Петра так себе — вам стоит огромных усилий заставить его работать по установленным правилам. Петр следует им неохотно, хотя вы и объясняли ему их важность, и умоляли, и угрожали, и исчерпали свой управленческий арсенал.
Вам приходится специально следить, чтобы он следовал правилам. Вам совсем не хочется расставаться с Петром, но работа с ним доставляет вам много менеджерской головной боли, совершенно неоправданной. Пока вы решили потерпеть.
Однажды Петр подходит к вам и говорит, что ему в голову пришла интересная идея, он посидел несколько выходных и сделал улучшение, которое сильно облегчит работу команды, да и жизнь клиентов тоже. Вы даете это улучшение на оценку экспертам из команды, и они соглашаются, что это свежая и полезная штука. Вы благодарите Петра и долго хвалите его.
Приближается конец отчетного периода, и высокое начальство просит вас выбрать сотрудника, которого можно наградить крупной денежной премией за хорошую работу. Петр кажется лучшим кандидатом. Его разработка всем сильно помогла.
Но как это вяжется с нежеланием Петра следовать процессам? Ведь он неоднократно создавал серьезные риски для команды и продукта.
Комментарии к ответам будут завтра. Или послезавтра.)
🔎 Комментарии к задачке 73-24
Задачка не придуманная, а вполне рабочая, хоть и давняя. Так что рассказываю, как оно было на самом деле.
Вариант А выбирают люди, которые о работе менеджеров узнали не из вебинаров. Когда побываешь в такой ситуации, сразу по-другому смотришь на мир. )
Вариант В, напротив, либо свидетельство природной мягкости, либо неопытность.
Менеджер в реальности выбрал вариант С. Он спросил моего мнения, и я рекомендовал ему вариант Е. Он лучше с точки зрения логики событий и мотивированности сотрудника, и так же бессмысленен с точки зрения его воспитания.
Но менеджер был человеком принципиальным. И не прислушался к совету. В итоге это не помогло — Петр разозлился, расстроился, и через некоторое время ушел работать в другое место. Программеры — они такие.
Думаю, это произошло бы в любом случае. Просто бывают люди, заточенные под правильно организованную работу, а бывают те, кому никак ничего не объяснить. И либо вы их терпите, либо расстаетесь.
Тут уж что вам важнее для проекта: держать такого человека в команде, ловить риски и подтачивать систему процессов, или лишиться нестандартного генератора столь же нестандартных решений.
Задачка не придуманная, а вполне рабочая, хоть и давняя. Так что рассказываю, как оно было на самом деле.
Вариант А выбирают люди, которые о работе менеджеров узнали не из вебинаров. Когда побываешь в такой ситуации, сразу по-другому смотришь на мир. )
Вариант В, напротив, либо свидетельство природной мягкости, либо неопытность.
Менеджер в реальности выбрал вариант С. Он спросил моего мнения, и я рекомендовал ему вариант Е. Он лучше с точки зрения логики событий и мотивированности сотрудника, и так же бессмысленен с точки зрения его воспитания.
Но менеджер был человеком принципиальным. И не прислушался к совету. В итоге это не помогло — Петр разозлился, расстроился, и через некоторое время ушел работать в другое место. Программеры — они такие.
Думаю, это произошло бы в любом случае. Просто бывают люди, заточенные под правильно организованную работу, а бывают те, кому никак ничего не объяснить. И либо вы их терпите, либо расстаетесь.
Тут уж что вам важнее для проекта: держать такого человека в команде, ловить риски и подтачивать систему процессов, или лишиться нестандартного генератора столь же нестандартных решений.
🗑 Признаки бесполезной бизнес-книжки
У меня есть набор маркеров, по которым я с высокой достоверностью могу отличить хорошую бизнес-книжку от бесполезной задолго до окончания чтения. А иногда и до начала.
1. Воспоминания о Зиге Зигларе.
Это культовый мотивационный спикер. Учит он позитивному взгляду на жизнь, способам достижения успеха, продажам. Мне не нравятся мотивационные спикеры.) Если в книге его имя встречается больше раза — в топку.
2. Воспоминания о Йоги Берра.
Это самый крутой бейсболист и тренер за всю историю этой коммерческой версии лапты. Его цитируют, на него ссылаются все кому не лень. Обычно отсылка к Йоги означает, что у автора книжки нет идей.
3. Постоянная проверка идей из книжки на соответствие демократическим ценностям.
Демократия — прекрасная штука. Но когда автор на каждой странице книжки про менеджмент это повторяет, начинаешь сомневаться в его профпригодности. И много ли мы знаем компаний, которые управляются демократическими методами?
4. Бесконечные разговоры о миссии компании.
Когда автору нечего писать, когда все его скудные идеи закончились, самое время заполнить пробелы тягомотиной про миссию. Неважно, о чем книжка — для любой сойдет.
5. Цитаты.
6. Притча о строительстве храма.
Эту бородатую притчу особенно любят молодые авторы. Им кажется, что нет повести прекраснее на свете. Сколько можно выдавать несвежую осетрину за только что пойманную?
7. Схема "из грязи в князи".
Редкая книга не повествует нам о тяжелом прошлом автора, которое он волевым усилием победил. А теперь и нас научит. Да, жизнь — это про падения и попытки подняться. Но когда это вываливают нам за шиворот с первой страницы — уж извините. Особенно этим грешат книжки-мотиваторы. И этим они мне искренне несимпатичны.
8. Едкая критика компании Enron.
Да, Enron — символ умышленного корпоративного мошенничества. Да, крах этого гиганта превратил "большую пятерку" в "большую четверку". Но сколько можно? Ни одного из популярных бизнес-авторов и близко не подпустят к управленческим задачам такого масштаба, который был в Enron.
9. Постоянные ссылки на японские управленческие методы.
Экономика Японии давно находится не в самом хорошем состоянии. Нашли с кого пример брать.
Мало кто реально работал в японских компаниях. Зачем писать про то, чего сам не видел?
Ну и большинство японских бизнес-терминов прекрасно переводится на другие языки, нет смысла устраивать терминологический Вавилон.
10. Поучительные истории про Apple, McDonald's, Kleenex и Walmart.
Да, энтузиазм среднестатистического американца вспыхивает, когда он слышит про подвиги основателей этих знаменитых брендов. Подумаешь, всего-то полвека прошло.
Готов также поверить, что все это можно посеять и в нашу каменистую почву. Но уж слишком это удобно и просто — кивнуть на гигантов за спиной. Обычно в текстах, где таких кивков много, одна пустота.
11. Не менее поучительные истории про 11 сентября.
Это ужасная трагедия. Но авторы бизнес-книг так полюбили о ней писать, так им комфортно дать читателю парочку примеров из истории про самолеты и башни, да еще и рассказать, как бы они ее не допустили, что становится противно. Задним умом-то все сильны.
12. Придуманные синтетические аббревиатуры.
Неленивый автор бизнес-книжки обязательно изобретет свою методику чего-нибудь и назовет ее мнемонической аббревиатурой, акронимом. Все эти DREAM, SUCCESS, DISC. Чтобы нам легче было запомнить. Но это как пытаться запомнить "красивый" номер телефона химчистки: вроде там есть только пятерки и семерки, но в какой последовательности и сколько?
Присутствие этих маркеров в книжке еще не приговор, но вот злоупотребление ими — гарантия бесполезности.
Выбросить нельзя читать. Запятую сами поставьте.)
У меня есть набор маркеров, по которым я с высокой достоверностью могу отличить хорошую бизнес-книжку от бесполезной задолго до окончания чтения. А иногда и до начала.
1. Воспоминания о Зиге Зигларе.
Это культовый мотивационный спикер. Учит он позитивному взгляду на жизнь, способам достижения успеха, продажам. Мне не нравятся мотивационные спикеры.) Если в книге его имя встречается больше раза — в топку.
2. Воспоминания о Йоги Берра.
Это самый крутой бейсболист и тренер за всю историю этой коммерческой версии лапты. Его цитируют, на него ссылаются все кому не лень. Обычно отсылка к Йоги означает, что у автора книжки нет идей.
3. Постоянная проверка идей из книжки на соответствие демократическим ценностям.
Демократия — прекрасная штука. Но когда автор на каждой странице книжки про менеджмент это повторяет, начинаешь сомневаться в его профпригодности. И много ли мы знаем компаний, которые управляются демократическими методами?
4. Бесконечные разговоры о миссии компании.
Когда автору нечего писать, когда все его скудные идеи закончились, самое время заполнить пробелы тягомотиной про миссию. Неважно, о чем книжка — для любой сойдет.
5. Цитаты.
6. Притча о строительстве храма.
Эту бородатую притчу особенно любят молодые авторы. Им кажется, что нет повести прекраснее на свете. Сколько можно выдавать несвежую осетрину за только что пойманную?
7. Схема "из грязи в князи".
Редкая книга не повествует нам о тяжелом прошлом автора, которое он волевым усилием победил. А теперь и нас научит. Да, жизнь — это про падения и попытки подняться. Но когда это вываливают нам за шиворот с первой страницы — уж извините. Особенно этим грешат книжки-мотиваторы. И этим они мне искренне несимпатичны.
8. Едкая критика компании Enron.
Да, Enron — символ умышленного корпоративного мошенничества. Да, крах этого гиганта превратил "большую пятерку" в "большую четверку". Но сколько можно? Ни одного из популярных бизнес-авторов и близко не подпустят к управленческим задачам такого масштаба, который был в Enron.
9. Постоянные ссылки на японские управленческие методы.
Экономика Японии давно находится не в самом хорошем состоянии. Нашли с кого пример брать.
Мало кто реально работал в японских компаниях. Зачем писать про то, чего сам не видел?
Ну и большинство японских бизнес-терминов прекрасно переводится на другие языки, нет смысла устраивать терминологический Вавилон.
10. Поучительные истории про Apple, McDonald's, Kleenex и Walmart.
Да, энтузиазм среднестатистического американца вспыхивает, когда он слышит про подвиги основателей этих знаменитых брендов. Подумаешь, всего-то полвека прошло.
Готов также поверить, что все это можно посеять и в нашу каменистую почву. Но уж слишком это удобно и просто — кивнуть на гигантов за спиной. Обычно в текстах, где таких кивков много, одна пустота.
11. Не менее поучительные истории про 11 сентября.
Это ужасная трагедия. Но авторы бизнес-книг так полюбили о ней писать, так им комфортно дать читателю парочку примеров из истории про самолеты и башни, да еще и рассказать, как бы они ее не допустили, что становится противно. Задним умом-то все сильны.
12. Придуманные синтетические аббревиатуры.
Неленивый автор бизнес-книжки обязательно изобретет свою методику чего-нибудь и назовет ее мнемонической аббревиатурой, акронимом. Все эти DREAM, SUCCESS, DISC. Чтобы нам легче было запомнить. Но это как пытаться запомнить "красивый" номер телефона химчистки: вроде там есть только пятерки и семерки, но в какой последовательности и сколько?
Присутствие этих маркеров в книжке еще не приговор, но вот злоупотребление ими — гарантия бесполезности.
Выбросить нельзя читать. Запятую сами поставьте.)
🚹 🚺 🎦 Тренажер для менеджеров и не только 927-800
Представьте, что вы - один из руководителей в продуктовой компании. Атмосфера в ней приятная, проекты интересные и сложные.
У вас запускается новый продукт, и надо найти для него менеджера.
Высокое руководство у вас в компании специфическое, оно начиталось каких-то книжек и решило проверить, сможете ли вы отобрать себе кандидатов для интервью по фото.
Эйчары у вас фоткать не умеют нормально, вы уж их простите, что было, то и прислали. )
Кандидатов всего девять. Надо выбрать с кем, как вам кажется, комфортно работать. Кто разберется в новых идеях, не спасует перед аналитическими задачами, сможет быть полезным и качественным менеджером.
Поймете по фото, кого стоит звать, а кого не нужно?
Представьте, что вы - один из руководителей в продуктовой компании. Атмосфера в ней приятная, проекты интересные и сложные.
У вас запускается новый продукт, и надо найти для него менеджера.
Высокое руководство у вас в компании специфическое, оно начиталось каких-то книжек и решило проверить, сможете ли вы отобрать себе кандидатов для интервью по фото.
Эйчары у вас фоткать не умеют нормально, вы уж их простите, что было, то и прислали. )
Кандидатов всего девять. Надо выбрать с кем, как вам кажется, комфортно работать. Кто разберется в новых идеях, не спасует перед аналитическими задачами, сможет быть полезным и качественным менеджером.
Поймете по фото, кого стоит звать, а кого не нужно?
Кого из этих девяти кандидатов на интервью к себе позовете? Выбрать можно нескольких.
Anonymous Poll
51%
1
26%
2
36%
3
8%
4
27%
5
21%
6
21%
7
11%
8
60%
9
Комментарии к ответам будут завтра. Или послезавтра.)
🔍 Комментарии к задачке 927-800
Кандидат 1 — Мариам Мирзахани, первая в истории женщина-лауреат Филдсовской премии, аналога нобелевки для математиков. Учитывая, что она иранка, воли и менеджерских качеств ей не занимать.
Кандидат 2 — Наталья Касперская. Ну, тут вы и сами все знаете.
Кандидат 3 — Джефф Хокинс, основатель компании Palm и создатель карманных компьютеров.
Кандидат 4 — Андреа Йейтс, американская домохозяйка, утопила пятерых своих детей.
Кандидат 5 — Николай Бухарин, революционер, блестящий аналитик, но крайне слабый и бесхарактерный руководитель.
Кандидат 6 — Карла Гомолка, канадская серийная убийца.
Кандидат 7 — Сергей Королев, основатель нашей космической отрасли и менеджер многих значимых ее продуктов. )
Кандидат 8 — американский серийный убийца Дэвид Берковиц.
Кандидат 9 — Сьюзен Войчицки. В 1998 году сдала гараж мужу своей сестры, которого звали Сергей Брин. Стала 16-м сотрудником молодой компании Google. Сейчас CEO Ютуба.
Приятно, что в большинстве случаев вы не только угадали хороших кандидатов, но и определили безусловно плохих. Королеву не повезло, но и это нормально.
Важное правило найма: лучше не взять хорошего, чем взять плохого.
Кандидат 1 — Мариам Мирзахани, первая в истории женщина-лауреат Филдсовской премии, аналога нобелевки для математиков. Учитывая, что она иранка, воли и менеджерских качеств ей не занимать.
Кандидат 2 — Наталья Касперская. Ну, тут вы и сами все знаете.
Кандидат 3 — Джефф Хокинс, основатель компании Palm и создатель карманных компьютеров.
Кандидат 4 — Андреа Йейтс, американская домохозяйка, утопила пятерых своих детей.
Кандидат 5 — Николай Бухарин, революционер, блестящий аналитик, но крайне слабый и бесхарактерный руководитель.
Кандидат 6 — Карла Гомолка, канадская серийная убийца.
Кандидат 7 — Сергей Королев, основатель нашей космической отрасли и менеджер многих значимых ее продуктов. )
Кандидат 8 — американский серийный убийца Дэвид Берковиц.
Кандидат 9 — Сьюзен Войчицки. В 1998 году сдала гараж мужу своей сестры, которого звали Сергей Брин. Стала 16-м сотрудником молодой компании Google. Сейчас CEO Ютуба.
Приятно, что в большинстве случаев вы не только угадали хороших кандидатов, но и определили безусловно плохих. Королеву не повезло, но и это нормально.
Важное правило найма: лучше не взять хорошего, чем взять плохого.
👩🏻💻🧑🏿💻👨🏼💻 О важных критериях оценки разработчиков
Как оценить разработчика? Какие его качества важны для успеха проекта и что делает разработчика хорошим? Вот небольшой чек-лист, основанный на личном опыте.
С1. Умение понять задачу — получить на вход требование и на выходе продемонстрировать понимание того, как он это требование будет выполнять.
Задача менеджера: давать людям качественные требования.
С2. Способность верно оценивать время решения задачи и укладываться в эту оценку. Начинающие или некомпетентные разработчики склонны к оптимистичным оценкам трудоемкости.
Задача менеджера: уменьшить длительность итераций разработки и регулярно с человеком разбирать ситуации, когда оценки оказались точными, и когда они были ошибочны. На достаточно длительном интервале и при условии качественных требований это помогает — точность оценок растет.
С3. Способность задавать вопросы (при разумном уровне самостоятельности) — разработчик должен общаться с коллегами, не стесняясь и не боясь спрашивать их совета по сложным для него вопросам.
Задача менеджера: поддерживать в команде культуру общения, поощрять обсуждение задач разных типов.
С4. Умение писать качественный код. Это самый сложный критерий. Если вкратце, то чем меньше критических ошибок допускает разработчик, тем лучше. ) При этом требования должны быть выполнены, а необходимые тесты пройдены успешно.
Задача менеджера: давать разработчику возможность учиться и решать все более сложные задачи, приобретая необходимый опыт.
С5. Умение разработчика оперировать сложными абстракциями.
Обычные люди оперируют конкретными понятиями и простыми абстракциями, поэтому могут решать только простые, очень конкретные задачи. Продвинутые люди умеют абстрагироваться от несущественного и видеть суть проблемы. Для них не важен ни инструмент, ни алгоритмы решения, ни технологические особенности. Поэтому они умеют решать задачи быстрее и дешевле, а их решения эстетически прекрасны.
Задача менеджера: давать разработчику соответствующие задачи и контролировать успешность результата.
С6. Умение разработчика разбираться в чужом коде — часто приходится заниматься развитием и поддержкой того, что написано другими.
Задача менеджера: давать разработчику соответствующие задачи и контролировать успешность результата.
C7. Мнение коллег о разработчике как о специалисте и человеке. Это своего рода page rank, показатель, позволяющий ранжировать разработчиков в команде и за ее пределами. Если много разработчиков считают коллегу хорошим спецом, это прекрасно его характеризует. Особенно при прочих высоких показателях.
Задача менеджера: не забывать интересоваться этим вопросом.
С8. Стабильность мотивированности. Уставший и разочаровавшийся в работе и задачах разработчик это плохо. Но гораздо хуже, если он в таком состоянии длительное время.
Задача менеджера: быть менеджером. )
Как оценить разработчика? Какие его качества важны для успеха проекта и что делает разработчика хорошим? Вот небольшой чек-лист, основанный на личном опыте.
С1. Умение понять задачу — получить на вход требование и на выходе продемонстрировать понимание того, как он это требование будет выполнять.
Задача менеджера: давать людям качественные требования.
С2. Способность верно оценивать время решения задачи и укладываться в эту оценку. Начинающие или некомпетентные разработчики склонны к оптимистичным оценкам трудоемкости.
Задача менеджера: уменьшить длительность итераций разработки и регулярно с человеком разбирать ситуации, когда оценки оказались точными, и когда они были ошибочны. На достаточно длительном интервале и при условии качественных требований это помогает — точность оценок растет.
С3. Способность задавать вопросы (при разумном уровне самостоятельности) — разработчик должен общаться с коллегами, не стесняясь и не боясь спрашивать их совета по сложным для него вопросам.
Задача менеджера: поддерживать в команде культуру общения, поощрять обсуждение задач разных типов.
С4. Умение писать качественный код. Это самый сложный критерий. Если вкратце, то чем меньше критических ошибок допускает разработчик, тем лучше. ) При этом требования должны быть выполнены, а необходимые тесты пройдены успешно.
Задача менеджера: давать разработчику возможность учиться и решать все более сложные задачи, приобретая необходимый опыт.
С5. Умение разработчика оперировать сложными абстракциями.
Обычные люди оперируют конкретными понятиями и простыми абстракциями, поэтому могут решать только простые, очень конкретные задачи. Продвинутые люди умеют абстрагироваться от несущественного и видеть суть проблемы. Для них не важен ни инструмент, ни алгоритмы решения, ни технологические особенности. Поэтому они умеют решать задачи быстрее и дешевле, а их решения эстетически прекрасны.
Задача менеджера: давать разработчику соответствующие задачи и контролировать успешность результата.
С6. Умение разработчика разбираться в чужом коде — часто приходится заниматься развитием и поддержкой того, что написано другими.
Задача менеджера: давать разработчику соответствующие задачи и контролировать успешность результата.
C7. Мнение коллег о разработчике как о специалисте и человеке. Это своего рода page rank, показатель, позволяющий ранжировать разработчиков в команде и за ее пределами. Если много разработчиков считают коллегу хорошим спецом, это прекрасно его характеризует. Особенно при прочих высоких показателях.
Задача менеджера: не забывать интересоваться этим вопросом.
С8. Стабильность мотивированности. Уставший и разочаровавшийся в работе и задачах разработчик это плохо. Но гораздо хуже, если он в таком состоянии длительное время.
Задача менеджера: быть менеджером. )
