Comments 48
Все талантливые люди амбициозны
И этот человек — вице-президент по науке в Сколково. :(
Так в Сколково же не нужно наукой
заниматься
Есть мнение, что гораздо важнее уметь обосновывать научные и псевдонаучные траты для освоения бюджетов, договариваться с другими предприятиями и загребать деньги, выполняя госзаказы
По-моему, вы просто слишком узко трактуете слово «амбициозны». Ожидать, что твои идеи будут реализовываться, сильные стороны — применяться, ну и вообще, требовать, чтобы твой труд тратился на достижение какого-то ощутимого результата — вполне распространённые проявления амбициозности, даже оставляя за рамками амбиции карьерные или материальные. По-моему, они настолько широко распространены, что использование квантора всеобщности вполне оправдано.
В любом случае, рад, что статья порождает дискуссию!
В любом случае, рад, что статья порождает дискуссию!
Я использую общепринятые (словарные) значения слов. Трактовать их как-то иначе, конечно, можно, но вряд ли имеет смысл для любого содержательного разговора, поскольку тогда он сведется к терминологическому спору.
В частности, амбициозность (в положительном контексте) — это энергичное стремление добиваться собственных целей, а талант — природные способности к тому или иному виду деятельности. И, по-моему, достаточно очевидно, что одно с другим связано примерно никак (если только мы не говорим непосредственно о таланте добиваться своего :)). Вы никогда в жизни не сталкивались с ситуациями, когда тихий скромный человек предлагал решение, более амбициозные проталкивали свои (а тот просто пожимал плечами и уходил в свой угол), а с течением времени становилось ясно, что прав-то был тот тихий и скромный? :) Увы, руководители, которые способны в подобной ситуации поддержать правильное, но не проталкиваемое активно решение, не так уж часто встречаются, к сожалению.
Обратите внимание, что ни один из других спикеров прямой связи таланта и амбиций не углядел — только сколковец. Может быть, это и случайность, но по мне так весьма симптоматично.
То, что амбиции являются чем-то хорошим — распространённое заблуждение. Как раз словарно амбиции являются, скорее, негативным качеством.
«Обострённое самолюбие, а также спесивость, чванство» — по Ожегову.
«Чувство чести, благородства; самолюбие, спесь, чванство; требование внешних знаков уважения, почета» — по Далю.
Никакого положительного контекста у «амбициозности» на самом деле нет.
«Обострённое самолюбие, а также спесивость, чванство» — по Ожегову.
«Чувство чести, благородства; самолюбие, спесь, чванство; требование внешних знаков уважения, почета» — по Далю.
Никакого положительного контекста у «амбициозности» на самом деле нет.
Категоричность — частое свойство незрелого разума.
В сколково сидят очень умные люди и не просто так их туда поставили, они руководят проектами идеями, развитием, какие то проекты могут для бизнеса одобрить и не одобрить. По сути это госслужба, и шума конечно же на счет технопарков больше чем дела.
Но, в Сочи как и в других городах есть ребята которые могут действительно интересные вещи рассказать и доказать. Но, многие системы как и законодательство — работают отлично лишь в теории, на практике — это в основном максимальный выжим соков. Например взять Кванториумы? Текучка ребят педагогов — и методистов — просто бешеная.
Но, в Сочи как и в других городах есть ребята которые могут действительно интересные вещи рассказать и доказать. Но, многие системы как и законодательство — работают отлично лишь в теории, на практике — это в основном максимальный выжим соков. Например взять Кванториумы? Текучка ребят педагогов — и методистов — просто бешеная.
Оказывается у нас любят таланты — а как же Перельман
А трансляции случаем не будет?
Лучшая мотивация для талантливого человека, помимо конечно его интереса к тому, что он делает, это понимание того, что то, во что он вкладывается, будет иметь финансовую отдачу на протяжении всего жизненного цикла его творения. Разрабатывает, например, группа разработчиков сервис проигрывания музыки, значит все, кто составляют ядро разработки должны непосредственно иметь долю с прибыли этого сервиса, на протяжении всей жизни этого сервиса. Понятно, что в реальности дело обстоит иначе. Тебя мотивируют премиями разовыми, полностью выжимают как лимон, а потом работа в проекте заканчивается. Проект потом приносит прибыли компании, а те кто его разрабатывают в лучшем случае работают на поддержку его за зарплату. Главное, самое интересное, над тобой куча всяких сотрудников, с экзотическими должностями, которые пытаются придумать какие-то смешные способы мотивации. Пока молодой, талантливый мотивация одна(, и все эти CRM -ы этим пользуются), а именно, получение реального опыта, хотя, на мой взгляд, талантливые программисты, создают этот опыт для будущих менее талантливых программистов, талантливым программистам, интересен предмет, он их мотивирует, их мотивирует пределы возможного. Когда программист начинает думать, что его вклад несоразмерен тому, что он имеет — это уже программист другого типа. Он уже понимает, что его когда-то использовали. Это проблема, которую описал, она очень сложная. Можно встать на место владельцев компании и найти кучу контр примеров, например один из самых любимых, типа программист, который уже на доле, начинает пробуксовывать, теряет форму. Или как определить прибыль, которую приносит конкретный проект, который в свою очередь использует разработанную инфраструктуру других проектов. Например, может сервис проигрывания музыки сам по себе не имел бы таких прибылей, если бы не находился в среде других смежных проектов. Но мне бы хотелось владельцам компаний заметить, что их благосостояние неуклонно растет, ну это если взять все известные крупные IT компании. Таким образом однозначным считаю, на протяжении всего жизненного цикла работы (не разработки) программного продукта, программисты, которые вносили основной вклад в разработку ядра этого продукта, должны получать «обратку», сколько или даже что — это уже другой вопрос, самое главное, создатели должны быть отблагодарены их творениями.
> все, кто составляют ядро разработки должны непосредственно иметь долю с прибыли этого сервиса, на протяжении всей жизни этого сервиса
Примерно для решения этой проблемы существуют программы премирования опционами, кажется. Если сотрудники регулярно получают опционы, то:
1. Их доход просто существенно больше.
2. Их доход зависит от стоимости компании, т.е. от её общей успешности.
3. Чтобы продолжать получать доход опционами, нужно держать себя в форме длительное время, пока происходит вестинг.
Примерно для решения этой проблемы существуют программы премирования опционами, кажется. Если сотрудники регулярно получают опционы, то:
1. Их доход просто существенно больше.
2. Их доход зависит от стоимости компании, т.е. от её общей успешности.
3. Чтобы продолжать получать доход опционами, нужно держать себя в форме длительное время, пока происходит вестинг.
Вот это неплохо, правильно. Есть конторы, которые сразу акции делят среди разработчиков. Но мне ничего подобного не встречалось здесь в России, было бы интересно узнать о реальных таких ситуациях.
Так делают многие компании. Вот, например, так делает Яндекс :)
Ну а что яндекс платит ниже рынка — так это нюансы.
UFO just landed and posted this here
Во-первых, компенсация опционами по определению выше, чем аналогичная компенсация за счёт величины оклада. Действительно много денег вы можете зарабатывать только за счёт опционов.
Во-вторых, возможность влияния «обычного разработчика» на стоимость акций компании сильно недооценивается, даже в больших компаниях :)
Если говорить об опционах в стартапах, то это любопытная штука. Проблема в том, что, пока стартап «не взлетит», опционы этого стартапа не стоят вообще ничего, поэтому учитывать их в качестве полноценной части компенсации не получается. Из-за этого сотрудник, имеющий опционы и переходящий из «большой компании» в стартап, может очень сильно терять в деньгах.
Во-вторых, возможность влияния «обычного разработчика» на стоимость акций компании сильно недооценивается, даже в больших компаниях :)
Если говорить об опционах в стартапах, то это любопытная штука. Проблема в том, что, пока стартап «не взлетит», опционы этого стартапа не стоят вообще ничего, поэтому учитывать их в качестве полноценной части компенсации не получается. Из-за этого сотрудник, имеющий опционы и переходящий из «большой компании» в стартап, может очень сильно терять в деньгах.
UFO just landed and posted this here
Не стоит тут рассказывать, что цель компаний, платящих разработчикам опционы вместо денег — сделать их (рзработчиков) миллионерами.— на этом собственно можно и закончить — у компании нет никаких причин делать разработчиков богаче, чем они есть сейчас, кроме разве что клинического случая, где разработчик работает хуже, так как чтобы поесть и заплатить за квартиру ему ещё приходится грузчиком подрабатывать по ночам…
А теперь предложите сотруднику выбор, либо з/п больше здесь и сейчас или з/п поменьше, но в придачу дадите ему опцион, на который нужно ещё будет работать несколько лет.
Большая часть людей из СНГ выберут первое, в противоположность, к примеру, США. Потому что всё это для нашего рынка в новинку и психология людей работает так, что они хотите быструю прибыль, нежели работать на перспективу.
Большая часть людей из СНГ выберут первое, в противоположность, к примеру, США. Потому что всё это для нашего рынка в новинку и психология людей работает так, что они хотите быструю прибыль, нежели работать на перспективу.
Для этого надо решить труднейший вопрос — разделения авторских прав между нанимателем и работниками. Реально имеем — никто авторских прав наемному персоналу не даст, даже на этом форуме для того чтобы напечатать статью, надо отказаться от авторских прав на нее в пользу якобы сайта. А раз нет авторских прав, платить опционы на весь срок жизненного цикла будет только сказочный принц.
Разрабатывает, например, группа разработчиков сервис проигрывания музыки, значит все, кто составляют ядро разработки должны непосредственно иметь долю с прибыли этого сервиса, на протяжении всей жизни этого сервиса.
Эммм, и долю с прибыли и зарплату рыночную?
А если сервис убыточный? А затраты которые были до выведения сервиса на рентабельность?
А те десятки (если не сотни) неудачных попыток что были до создания коммерчески успешного продукта?
Ну и в принципе, наемный сотрудник (пусть даже интеллектуального труда) всего-лишь инструмент (зачастую с обратно пропорциальным скиллу эго), как инструмент может претендовать на долю?
Ха, ха инструмент, а вы наверное мастер, который держит чемоданчик с инструментами. Если бы Стив Джобс считал Возняк инструментом, он бы давно закончил бы где-то в Индии свой путь на пляже с косяком во рту. В очередной раз сталкиваюсь с мнениями сформированные людьми, которые кроме как амбиций за собой ничего не имеют. Никогда человек сотворивший что-то дельное своими талантами не писал бы то, что написали вы.
Есть один нюанс — очень часто чем талантливее человек, тем у него труднее характер, ведь недостатки часто являются продолжением достоинств.
С такими лучше сразу расставаться, они очень токсично влияют на остальную команду. А проекты все же делают не конкретные, пусть даже очень талантливые люди, а команды. Для достижения успеха вам нужна талантливая и мотивированная команда, а не ее отдельные «выдающиеся»… мемберы (хотел написать русское слово но подумал что выйдет двусмысленно).
Вообще люди часто раскрываются именно в составе команды и в процессе работы над проектом и ценными они являются именно как часть команды и в контексте проекта. Но то есть в звёзд которые сами по себе звезды я не очень верю. Хотя наш HR думает что именно такие люди нам нужны…
Вообще люди часто раскрываются именно в составе команды и в процессе работы над проектом и ценными они являются именно как часть команды и в контексте проекта. Но то есть в звёзд которые сами по себе звезды я не очень верю. Хотя наш HR думает что именно такие люди нам нужны…
Извините, но Вы противоречите главной идее статьи по поиску и развитию талантов. К сожалению Ваше мнение разделяют многий эйчарники, закрывая путь специалистам, имеющим суперкомпетенцию. Зачем нужен кто-то способный изобрести порох, когда командой легче пилить бюджет. Всех подобных основателям мелкомягких, яблока и прочего подобного надо изгонять в гаражи. Пусть там работают, нечего командам мешать. И вообще власть авторитета должна быть заменена авторитетом власти. Идеал — винтик в команде без лишних амбиций. :)
Если вы воспринимаете Билла Гейтса и Стива Джобса как технических гениев из которых первый единолично написал Windows, а второй лично собрал на коленках первый iPhone, вы ошибаетесь. Все было с точностью до наоборот это были люди которые смогли вокруг себя собрать единомышленников, каждая из которых работая как одна команда смогли создать беспрецедентные прежде продукты. Предлагаю вам обратится к первоисточникам например на TED.com можно найти многочисленные интервью их обоих. Уверен Вам будет интересно.
Извините, но Вы спутали два понятия — трудоустройство специалиста в действующую организацию и роль лидеров по организации новой команды. В обоих случаях у них были проблемы с трудоустройством. Реализовать себя они смогли только на созданном своими руками рабочем месте с последующим привлечением других. Но сначала был гараж.
Специалист должен полагаться на знания, а не на ощущение персональной талантливой исключительности. Для охарактеризования специалиста лучше подходит слово «компетентность».
Командной работе нужно учить. Вот что говорит по этому поводу Кент Бек:
Молодые специалисты часто устраивают соревнования умом в кодовой базе, разгоняя уровень ее сложности. На самом деле они тем самым демонстрируют собственную некомпетентность, потому что:
Ну и если человек на самом деле талантлив, то он направит свои усилия не на то чтобы оторваться от толпы и продемонстрировать свою исключительность, а на то, чтобы сделать команду лучше:
Всю информацию сюда не впихнуть, если кому интересно, то "How to quickly develop high-quality code. Team work."
«Чтобы стать экспертом в практической или научной области, нужны огромный труд и долгое время. Если человек добросовестно трудится каждый час рабочего дня, когда-нибудь он проснется одним из самых компетентных специалистов своего поколения.» (Уильям Джеймс)
«Компетентный программист полностью осознает строго ограниченные размеры своего черепа, поэтому подходит к задачам программирования со всей возможной скромностью.» (Дейкстра 1972)
Командной работе нужно учить. Вот что говорит по этому поводу Кент Бек:
«It’s hard to collaborate. Our whole education system is tuned to individual achievement. If you work with someone on a project, the teacher calls it cheating and punishes you. The reward systems in most companies, with individual evaluations and raises (often cast as a zero sum game), also encourages individual thinking. You will likely have to learn new people skills, interacting as closely with your team as you will in XP.» («Extreme Programming Explained» by Kent Beck)
Молодые специалисты часто устраивают соревнования умом в кодовой базе, разгоняя уровень ее сложности. На самом деле они тем самым демонстрируют собственную некомпетентность, потому что:
«Software’s Primary Technical Imperative is managing complexity. This is greatly aided by a design focus on simplicity.» (Steve McConnell)
«Simplicity and elegance are unpopular because they require hard work and discipline to achieve and education to be appreciated.» (Edsger W. Dijkstra)
Ну и если человек на самом деле талантлив, то он направит свои усилия не на то чтобы оторваться от толпы и продемонстрировать свою исключительность, а на то, чтобы сделать команду лучше:
"… it encourages communication. I like to think of the analogy of a pool of water. When an important new bit of information is learned by someone on the team, it is like putting a drop of dye in the water." (Kent Beck, XP)
Всю информацию сюда не впихнуть, если кому интересно, то "How to quickly develop high-quality code. Team work."
Извините, но я уже вырос из возраста, когда верят в сказки. Командная работа это нечто из области коллективного секса в котором главным достоинством является возможность сачкануть. В спорте, откуда пришел термин «команда» известно много случаев разрушения команд при уходе тренера или пары ведущих игроков-лидеров. Еще раз персонально для Вас повторю: Очень часто талантливость человека сопровождается проблемным характером потому что недостатки являются продолжением достоинств. Никакие знания и воспитания не изменяют сути человека. Команду может создать только лидер. Без лидера можно создать только «кружок кройки и шитья».
Командная работа это нечто из области коллективного сексаНу… если так подходить к командной работе, то может тогда персональная талантливость и первостепенна… Не знаю… Я только XP (Agile) пробовал, а там без «Collective Ownership» — никак.
Спасибо за демонстрацию недопонимания. Я говорю о том, что собрать команду троечников довольно просто, двоечники в команду соберутся еще легче, а собрать команду из талантливых и грамотных очень и очень тяжело.
Если бы Вам пришлось самому собирать команду, то в правильности моих слов Вы бы быстро убедились на практике.
Если бы Вам пришлось самому собирать команду, то в правильности моих слов Вы бы быстро убедились на практике.
Я мог бы с Вами согласиться, если бы Вы использовали слово «менеджер» вместо слова лидер. Действительно, мне приходилось наблюдать, как смена топ-менеджмента и бездарное управление уничтожили отличную команду менее чем за месяц.
Но… если Вы знаете что такое истинный Agile, особенно в его натуральном виде — Extreme Programming, и хоть раз в жизни работали по нему, то Вы понимаете, что в команде просто не может быть ни одного «не таланта», иначе он потопит всю команду. Настоящий Agile без команды невозможен.
По опыту скажу, что найти в команду готового специалиста — практически нереально. Основная задача отбора — оценить насколько быстро человек сможет подтянуться до среднего уровня команды. Остальное зависит от того, насколько у Вас в команде эффективны совместные методики разработки (формальные инспекции, парное программирование и пр.).
«One team that used formal inspections reported that inspections quickly brought all the developers up to the level of the best developers (Tackett and Van Doren 1999).» (Steve McConnell)
Делая акцент на индивидуальный талант, можно легко попасть в ситуацию описанную в статье "Рик, ты уволен: мы избавились от нашего лучшего сотрудника и не пожалели об этом". Разумеется, вина была не в Рике, а опять, же в менеджменте, который полагал, что для успеха достаточно иметь в команде одного «таланта». И Рик — действительно был талантливым парнем, только с недостатком знаний. Он оперировал огромным уровнем сложности (и никто не мог с ним в этом сравниться), просто потому, что не знал, что хорошая архитектура как раз и заключается в устранении этой сложности.
Но… если Вы знаете что такое истинный Agile, особенно в его натуральном виде — Extreme Programming, и хоть раз в жизни работали по нему, то Вы понимаете, что в команде просто не может быть ни одного «не таланта», иначе он потопит всю команду. Настоящий Agile без команды невозможен.
По опыту скажу, что найти в команду готового специалиста — практически нереально. Основная задача отбора — оценить насколько быстро человек сможет подтянуться до среднего уровня команды. Остальное зависит от того, насколько у Вас в команде эффективны совместные методики разработки (формальные инспекции, парное программирование и пр.).
«One team that used formal inspections reported that inspections quickly brought all the developers up to the level of the best developers (Tackett and Van Doren 1999).» (Steve McConnell)
Делая акцент на индивидуальный талант, можно легко попасть в ситуацию описанную в статье "Рик, ты уволен: мы избавились от нашего лучшего сотрудника и не пожалели об этом". Разумеется, вина была не в Рике, а опять, же в менеджменте, который полагал, что для успеха достаточно иметь в команде одного «таланта». И Рик — действительно был талантливым парнем, только с недостатком знаний. Он оперировал огромным уровнем сложности (и никто не мог с ним в этом сравниться), просто потому, что не знал, что хорошая архитектура как раз и заключается в устранении этой сложности.
Я мог бы с Вами согласиться, если бы Вы использовали слово «менеджер» вместо слова лидер.
Рекомендую почитать стандарты на системы менеджмента. Сейчас во всех отдельный раздел про лидерство и его необходимость. Без лидера создание команды принципиально невозможно. Толпа равняется на отстающего.
в команде просто не может быть ни одного «не таланта», иначе он потопит всю команду.
Все зависит от задачи этой команды. Для проекта уровня «Миссия невыполнима» — то есть реального прорыва нужна команда с IQ членов значительно выше среднего. Это только в голливудских фильмах такие команды собираются «по свистку». В реале собрать и обеспечить согласованную команду ярких личностей великая проблема!
Остальное зависит от того, насколько у Вас в команде эффективны совместные методики разработки
Я Вас удивлю тем, что не только на мой взгляд костяк команды серьезной разработки в любой области состоит из трех человек — генератора идей, критика проблемных мест в предлагаемых разработках и руководителя, принимающего компромиссное решение при обсуждениях идей и сводящего первых двух к общему знаменателю. Реализация принятых идей это второй этап, на котором возможно использование Вами названного. Но без первого (Планирования на языке процессного подхода) второй этап невозможен. Реальный кризис отсутствия талантов более всего проявляется именно на этапе проектирования.
В технической среде не может быть никакого лидера без авторитета. А авторитет в технической среде достигается знаниями, продемонстрированными на практике. Иначе получится Рик-2.
> Рекомендую почитать
Я ценю Ваше беспокойство о моем графике чтения. Смею Вас заверить, он расписан на два года вперед, а с уже прочтенным (причем, прочтенным на Английском) списком литературы Вы можете ознакомиться по ссылке. Я искренне надеюсь, что Ваш совет «почитать» не голословен, и Вы так же, с удовольствием, похвастаетесь не только способностью раздавать советы, но и личными практическими достижениями в Ваших же советах.
Вы конечно, имеете право на любое мнение. Но когда Вы противопоставляете свое мнение мнению Кента Бека, ученику Уорда Каннингема, учителю Мартина Фаулера, автору первой (и по сей день — самой эффективной) Agile методологии XP, автору TDD, автору рефакторинга, другу Эрика Гаммы, человеку, внесшему большой вклад в развитие паттернов проектирования и создавшему самые эффективные команды разработчиков на планете, то как Вы думаете, кому больше поверят? Вам, человеку, признавшемся в неспособности создавать эффективные команды (за исключением «сачков» и «равняющихся на отстающих»), или Кенту Беку?
Из Ваших слов явствует только то, что вы никогда не работали по Agile, и даже не понимаете его смысла. Иначе расскажите пожалуйста, кому Вы отводите роль лидера в XP-команде? Ни инструктор, ни администратор для этой роли не подходят. Тимлидов — нет. Есть ревизор, но опять — мимо.
> Для проекта уровня «Миссия невыполнима»
Вы снова продемонстрировали полное незнание Agile. Ни про экономику разработки ПО, ни про минимизацию рисков, ни про раннюю обратную связь, вы, похоже, никогда не слышали. Ибо проектов «Миссия невыполнима» в Agile не может быть в принципе.
> Реальный кризис отсутствия талантов более всего проявляется именно на этапе проектирования.
Опять же, в Agile проектирования как такового нет. Это не Waterfall. Проектирование там делается через рефакторинг. Делается всеми, каждым членом команды. Поэтому нет и архитектора (в этом он и отличается от инструктора, — инструктор не принимает решений). Вы об этом бы знали, если бы хоть раз прошли хотя бы по одной моей ссылке, вместо того, чтобы усердно демонстрировать нам всем здесь Вашу талантливость.
> Рекомендую почитать
Я ценю Ваше беспокойство о моем графике чтения. Смею Вас заверить, он расписан на два года вперед, а с уже прочтенным (причем, прочтенным на Английском) списком литературы Вы можете ознакомиться по ссылке. Я искренне надеюсь, что Ваш совет «почитать» не голословен, и Вы так же, с удовольствием, похвастаетесь не только способностью раздавать советы, но и личными практическими достижениями в Ваших же советах.
Вы конечно, имеете право на любое мнение. Но когда Вы противопоставляете свое мнение мнению Кента Бека, ученику Уорда Каннингема, учителю Мартина Фаулера, автору первой (и по сей день — самой эффективной) Agile методологии XP, автору TDD, автору рефакторинга, другу Эрика Гаммы, человеку, внесшему большой вклад в развитие паттернов проектирования и создавшему самые эффективные команды разработчиков на планете, то как Вы думаете, кому больше поверят? Вам, человеку, признавшемся в неспособности создавать эффективные команды (за исключением «сачков» и «равняющихся на отстающих»), или Кенту Беку?
Из Ваших слов явствует только то, что вы никогда не работали по Agile, и даже не понимаете его смысла. Иначе расскажите пожалуйста, кому Вы отводите роль лидера в XP-команде? Ни инструктор, ни администратор для этой роли не подходят. Тимлидов — нет. Есть ревизор, но опять — мимо.
> Для проекта уровня «Миссия невыполнима»
Вы снова продемонстрировали полное незнание Agile. Ни про экономику разработки ПО, ни про минимизацию рисков, ни про раннюю обратную связь, вы, похоже, никогда не слышали. Ибо проектов «Миссия невыполнима» в Agile не может быть в принципе.
> Реальный кризис отсутствия талантов более всего проявляется именно на этапе проектирования.
Опять же, в Agile проектирования как такового нет. Это не Waterfall. Проектирование там делается через рефакторинг. Делается всеми, каждым членом команды. Поэтому нет и архитектора (в этом он и отличается от инструктора, — инструктор не принимает решений). Вы об этом бы знали, если бы хоть раз прошли хотя бы по одной моей ссылке, вместо того, чтобы усердно демонстрировать нам всем здесь Вашу талантливость.
Извините, но я перестал понимать, эта тема по обсуждению поиска и развития талантов или это реклама Agile?
Про то, что лидерские качества человека не имеют прямой связи с его знаниями я даже боюсь говорить.
Про то, что лидерские качества человека не имеют прямой связи с его знаниями я даже боюсь говорить.
Agile — это и есть способ командной работы, причем, не нуждающийся в рекламе… Я обсуждаю Ваше утверждение о том, что командная работа — это сказки.
Вероятно, случай с талантливым Риком (а это, как мне рассказывали, описан реальный эпизод) прошел мимо Вашего внимания. Ок, есть не менее интересный эпизод касательно команды, талантов и лидеров. Я лишь слегка модифицировал оригинальный текст.
Вопрос, кто здесь лидер, кто здесь талант, есть ли здесь команда и какова ее роль, и кого из персонажей Вы персонально взяли бы в свою команду?
Вероятно, случай с талантливым Риком (а это, как мне рассказывали, описан реальный эпизод) прошел мимо Вашего внимания. Ок, есть не менее интересный эпизод касательно команды, талантов и лидеров. Я лишь слегка модифицировал оригинальный текст.
A boy went fly-fishing for the first time in the Idaho panhandle.
After a fruitless, sweaty day in pursuit of brook trout, he and his friends headed for home. After half an hour of stumbling through dense trees, they realized they were lost. The boy started to panic—fast breathing, tunnel vision, chills. Then someone suggested a plan—they would walk uphill until they hit a logging road they knew was up there. Instantly, the panic disappeared.
Вопрос, кто здесь лидер, кто здесь талант, есть ли здесь команда и какова ее роль, и кого из персонажей Вы персонально взяли бы в свою команду?
прочитал… ощущение вечера пятницы в пивной… там часто так рассуждают, вот правда!
Скажите, пожалуйста, есть сотрудник X, есть сотрудник Y, занимаются подобным родом задач с переменным уровнем сложности…
сотрудник X иногда дольше делает то что Y способен сделать быстрее, но иногда сотрудник Y решает задачу ооочень быстро и сложно… иногда такие быстрые решения сотрудника Y усложняют процесс усовершенствования решения к похожей задачи, иногда в несколько раз увеличивая затраченное ранее время.
Надеюсь мне удалось описать обычную ситуацию с которой почти каждая компания хоть раз сталкивалась.
У меня вопрос:
Сотрудник X получает зарплату Z, сколько должен получать сотрудник Y?
PS: сотрудник Y таналтнив, не важно почему и как — все его таковым считают, и он сам.
PS2: дайте цифры, хотя бы соотношения зарплат и реально выделяемом времени на работу X к Y.
ну или реальные примеры…
… ато собрались, поговорили обовсем и неочем, и разошлись.
Скажите, пожалуйста, есть сотрудник X, есть сотрудник Y, занимаются подобным родом задач с переменным уровнем сложности…
сотрудник X иногда дольше делает то что Y способен сделать быстрее, но иногда сотрудник Y решает задачу ооочень быстро и сложно… иногда такие быстрые решения сотрудника Y усложняют процесс усовершенствования решения к похожей задачи, иногда в несколько раз увеличивая затраченное ранее время.
Надеюсь мне удалось описать обычную ситуацию с которой почти каждая компания хоть раз сталкивалась.
У меня вопрос:
Сотрудник X получает зарплату Z, сколько должен получать сотрудник Y?
PS: сотрудник Y таналтнив, не важно почему и как — все его таковым считают, и он сам.
PS2: дайте цифры, хотя бы соотношения зарплат и реально выделяемом времени на работу X к Y.
ну или реальные примеры…
… ато собрались, поговорили обовсем и неочем, и разошлись.
Простите, далеко не ответ. Так, чуть холивара в «ночную смену».
Если сотрудник X хочет получать больше, то пусть он пойдёт и попросит себе прибавку. А может его и сейчас всё устраивает и вы вообще зря переживаете. Ну, подумаешь, 10-15% разницы? Лично я бы начал шевелиться, если бы речь шла о разнице в 40-50%.
Подумайте, что есть ещё нематериальные стимулы, например, работать из дома? Может X-у до работы час добираться на машине и пара дней в неделю работы из дома компенсирует ему затраты на бензин? Вот вы и сэкономили на ЗП. Все довольны. )
сотрудник X иногда дольше делает то что Y способен сделать быстрееВесьма субъективная вводная, т.к. никогда ни одна компания не даст одну и ту же задачу разным сотрудникам с целью посмотреть, а кто тут у нас самый быстрый? Отсюда несколько бессмыслен вопрос, сколько должны они получать по отношению к друг другу? Тут иногда даже на работу берут по непонятным критериям (ну вот прям срочно и сейчас надо взять человека и даже на тёплое место).
Если сотрудник X хочет получать больше, то пусть он пойдёт и попросит себе прибавку. А может его и сейчас всё устраивает и вы вообще зря переживаете. Ну, подумаешь, 10-15% разницы? Лично я бы начал шевелиться, если бы речь шла о разнице в 40-50%.
Подумайте, что есть ещё нематериальные стимулы, например, работать из дома? Может X-у до работы час добираться на машине и пара дней в неделю работы из дома компенсирует ему затраты на бензин? Вот вы и сэкономили на ЗП. Все довольны. )
Этот сказал то, тот сказал это… Так как же выявлять и развивать таланты в IT?
Как говорил товарищ Саахов в фильме «Кавказская пленница»
«Все это, конечно, так, все это верно, да, да, верно, да, бумага написана правильно, все, все хорошо, верно, да. Только с одной стороны, да. Но есть и другая сторона медали.»
А другая сторона медали и одновременно суровая реальность заключается в том, что компании стараются платить минимальную допустимую (в реалиях рынка) з.п. работникам, лишь бы они выполняли свои задачи. И повышение денежного довольствия всегда проходит для руководства через боль, потому что они, фактически, отдают деньги из своего кармана. Даже если разработчик сыграет ключевую роль в становлении системы, которая будет приносить миллионы компании, максимум на что он может рассчитывать — премия 20-50 % от з.п., повышение з.п. на 10-20%, ну или, в лучшем случае, новую модельку iphone (шутка). Вот она жиза, задача компаний не раскрыть таланты, способности человека, а выжать из него максимум прибыли, пользы для их сереньких дел. Ведь, по большому счету, мы для них — это шестеренки в бизнес-машине прибыли.
«Все это, конечно, так, все это верно, да, да, верно, да, бумага написана правильно, все, все хорошо, верно, да. Только с одной стороны, да. Но есть и другая сторона медали.»
А другая сторона медали и одновременно суровая реальность заключается в том, что компании стараются платить минимальную допустимую (в реалиях рынка) з.п. работникам, лишь бы они выполняли свои задачи. И повышение денежного довольствия всегда проходит для руководства через боль, потому что они, фактически, отдают деньги из своего кармана. Даже если разработчик сыграет ключевую роль в становлении системы, которая будет приносить миллионы компании, максимум на что он может рассчитывать — премия 20-50 % от з.п., повышение з.п. на 10-20%, ну или, в лучшем случае, новую модельку iphone (шутка). Вот она жиза, задача компаний не раскрыть таланты, способности человека, а выжать из него максимум прибыли, пользы для их сереньких дел. Ведь, по большому счету, мы для них — это шестеренки в бизнес-машине прибыли.
Все люди, и в том числе ваши сотрудники, талантливы. Есть лишь две проблемы: неправильная область деятельности и вера в себя. Есть области деятельности, при столкновении с которыми человек начинает сыпать идеями и высказывать разумное недовольство текущим положением дел — это и есть те области, которые способны раскрыть его таланты.
В точку! Это утверждение затмевает все остальные в этой публикации.
Выявлять — давать задачи которые человек еще не делал. Повышая трудность. Разговоры, или количество идей, или тренинги как поверить в себя и т.д. ничего не дадут, если делать изо дня в день предстоит одно и тоже.
Sign up to leave a comment.
Как выявлять и развивать таланты в IT