Да у Вас в Москве хватает и приличных работодателей. Нужен только ОДИН

Почему один? А другие тестировщики что, хотят работать у неприличных работодателей?

Для одного работника нужен один работодатель, на двух работодателей трудно работать :)

Хорошая дискуссия. Поучаствую.
Ответ: нисколько, 0, ни минуты не должны "сидеть на одном месте". Это преступление, халатность и т.д. Представьте себе, человек работает за рабочим местом, руководитель спрашивает (возможно, провокационно, а может и просто не в курсе) "чем занимаешься?". Ответ "сижу" повергнет его в шок! (Если юмора нет, юмор не у всех есть). Новый работодатель не в курсе Вашей бывшей работы, но если, например, мне сказать, что "я просидел 1-25 лет", мой ответ будет простым - "замечательно, пришло время размяться, желаю удачи". "Массажером" уже никак я не буду.
Поэтому встаньте на позиции Вашего работодателя, а у него, на мой взгляд на Ваше сообщение, будут следующие:
Во-первых, подозрения вызывают сроки работы - т.е. на предпоследнем 2 года, на последнем 1, на новом 0,5? :) Это действительно Ваше слабое место. Говорите, что ушли, потому что работа была не в сфере ваших интересов профессионального роста. Что это значит? Предположим Вы хотите работать тестеровщиком это сфера Ваших интересов, а на Вас вдруг навесили обязанности по установке и поддержке эксплуатации продукта. Но Вы должны честно признавать причины, по которым ушли с предыдущих мест. В любом случае хороший работодатель проверит, и, если причина "надоело работать", она поставит на Вас крест.
Во-вторых, возможно, начальнику досмерти самому надоело, ему хочется перспектив, денег и т.д и вдруг Вы!!! Покажите, что Ваша перспектива отличается от его перспективы. Имеется в виду - руководитель ищет управленческого роста, специалист - профессионального.
В-третьих, очередная пафосная тирада в адрес фирмы, действительно бальзам на самолюбие руководства, ну даже если не бальзам, то Вас уже не сбросить со счетов. Узнайте до собеседования о фирме как можно больше.
А вообще на самом деле, главное - это желание работать в этом коллективе над решением данной конкретной проблемы в данной конкретной фирме на определенный (вполне возможно, до пенсии) конкретный срок, при этом обладая требуемыми навыками, вот это хочет услышать работодатель.
И мой Вам (в смысле любому) совет - не работайте там, где ответ - хочу больше денег - воспринимается в штыки. Бывают разные времена у фирм, но если материальный интерес работников идет в разрез с интересами руководства - фирма обречена и работники вместе с ней, в конце концов, в ней соберутся одни неудачники. А от кого в первую очередь избавляются неудачники? Кого они обвинят в своих неудачах (а их будет достаточное количество)? Оно Вам надо?

Мне? Нет.
Но если бы, к примеру, оказалось, что таких работодателей скажем 90 процентов, то... т.к. платят деньги все же они, пришлось бы подстраиваться.

Да у Вас в Москве хватает и приличных работодателей. Нужен только ОДИН :)

Я бы предложил сразу начать с выращивания роз. Умение тестировать корнями :) уходит в умение наблюдать и анализировать поведения объектов. Наблюдение за живой природой с практическим применением, не это ли лучшая школа тестировщика?

Я понимаю это, но в моем городе (Днепропетроск) я не нашла предложений.

В Москву надо, в Москве вся сила

Москва- это хорошо :rolleyes:

Буквально, вчера вернулся, благодать там.
Причем полностью отсутствует какое-то негативное впечатление как от города так и от жителей. Очень доволен поездкой

И вам не советую :)

"Не годен"?

Вообще-то, себя имел ввиду. Совпало :)

Я понимаю это, но в моем городе (Днепропетроск) я не нашла предложений.

В Москву надо, в Москве вся сила

Ну что ж, опять все на круги своя вернулось. Да, я только о RUP. Потому как с главным вопросом все (стало) понятно.
Алексей, разве трудно было ответить на мои вопросы да, нет, нет, да и т.д. и т.п.? :)
Теперь я запутался в Ваших словах еще больше.
Что такое деятельностно-ориентированный подход? Не знаю. Сам третий раз спрашиваю, не хочу быть еретиком!!! Хочу быть честным рупером!!! Хочу целиком и полностью включиться в этот унифицированный процесс, где никто не будет спрашивать, где результаты моего труда, а особенно в самые неподходящие для меня моменты!!!
Вот это был самый главный вопрос. А есть и второй:
Чем процессно-ориентированный подход отличается от деятельностно-ориентированного подхода? Судя по Вашим слова - ничем? Тогда опять возвращаемся к первому вопросу и к местам его возникновения :).

О магии и ереси
Если я пишу что: итеративно программа с малой функциональностью становится программой с большей функциональностью и часть этого итерационного процесса разработки ПО - деятельность "тестирование"
так тут никакой магии или ереси нет. Вот вам вопросы на проверку: как получается программный продукт с большей функциональностью? Магически? - Нет, итеративно
В результате чего появляется большая (ударение на первом слоге) функциональность? Использования магии? - Нет, в результате процесса разработки?
Тестирование программы в RUP- это деятельность? Это ересь?
А если взять (хотя смею Вас и Светлану заверить, я не случайно написал именно не так) программа с малой функциональностью становится программой с большей функциональностью
то тут можно и магию заподозрить, и торговца в переулке, и слесаря из ЖКХ, и много чего еще.

Что касается остально (по качеству), я боюсь, Алексей, что те вопросы будут многим не интересны, хотя меня лично это интересует. Буду ждать Ваших сообщений на эту тему.

Viktor, мне, честно говоря, казалось что то что вы тут называете процессом, на самом деле есть activity в RUPе. То есть, я всегда себе представлял так, что activity это элементарное действие, которое совершается в рамках одной роли, имеет на входе некий набор артифактов, а на выходе - другой набор. Например, один round тестирования есть деятельность, выполняемая тестировщиком, имеющая на входе partial test plan, а на выходе - баги и логи исполнения тестов. Понятно, что одна activity может включать в себя другие, но в общем случае activity выполняется в рамках одной роли.  Так, тест-менеджер на входе в цикл тестирования опять-таки имеет master (system) test plan и test strategy в процессе распределяет выполнение тестов и получает логи исполнения (а так же баги), а на выходе выдаёт отчёт о проведённом тестировании.

Я и сам до этого разговора так думал, однако это, как мне показал Алексей, не совсем так.
Т.е. подход в RUP другой - не процессный, мне сложно это объяснить, так как у меня нет примеров полноценной разработки по RUP.
Но то что вы говорите про Вашу организацию - этот к чему я стремился у себя, а Алексей показал, что это искажение RUP (здесь под RUP я понимаю не просто методологию разработки, а некий стандарт, правила).
В статье рассказывается как сглаживаются эти грани, но слово грубо (roughly) в определении process мне не нравится. Кстати, еще одна оценка RUP для процессно-ориентированного подхода - слабый (weak)

А у Вас процессы имеются?
ИСО 12207 соблюдаете?

Виктор, пожалуйста, можете ещё раз объяснить, что вы подразумеваете под "процессом", а так же "задачей" (task) и work (это вообще не знаю, как перевести).

Что такое ИСО 12207, к сожалению, не знаю (я собственно, управлением качеством не занимаюсь - я тестировщик). Вы не могли бы привести ссылочки и название этого документа?

Мы сертифицированы по ISO 9001:2000 (уточнил).

процесс - система действий, которая использует ресурсы для преобразования входящих элементов в выходящие
Фишка в том что RUP говорит - достаточного одного процесса снаружи, а внутри все занимаются деятельностью.
А в ИСО - внутри занимаются процессами, а снаружи - деятельностью

work - работа?

ИСО 12207 - основной стандарт, устанавливает, используя четко определенную терминологию, общую структуру процессов жизненного цикла программных средств, на которую можно ориентироваться в программной индустрии.

PS. фишку можно аргументировать :)

Перечитал тему. Не вижу, чем моё описание activity отличается от цитаты, которую приводил Алексей, и не виже никаких противоречий. Речь, я так понимаю, всё-таки идёт не о подходе а исключительно о терминологии (если Вы считаете, что это не так - пожалуйста, поясните в чём отличие "процессного" подхода от "деятельностно-ориентированного" :). Ну хорошо, называете вы, предположим, набор деятельностей, в которых задействованы роли тестировщика, тест-менеджера и тест-дизайнера процессом тестирования, и что от этого меняется в подходе? По-моему, ничего. Но, IMHO, удобнее работать именно с activities а не "процессами". То что вы называете процессами, как мне представляется, есть не более чем куски (ветки) Workflow.

И не увидите, Вы же внедрили и RUP и ИСО :)
Но ведь это очевидно:
Предположим, Вы тестируете :)
По исо Вы преобразуете в результате процесса тестирования нетестированную программу в тестированную :)
По rup Вы никаких преобразований с программой не делаете :), просто итеративно программа с малой функциональностью становится программой с большей функциональностью :) и часть этого итерационного процесса разработки ПО - деятельность "тестирование"

Ох и люблю я цитаты!

Остальные упомянутые Вами термины (process, thread, task, work) в RUP не используются.

Хорошо, отдаю Вам должное, я провокационно ввел первые три (process, thread, task)
(Они используются, но для других целей :), да?)
Поэтому, пойманный за руку, должен согласиться, что RUP не использует "процессный" подход
RUP использует какой-то другой подход, discipline-ный, что это значит надо будет как-нибудь обсудить :)

Насколько мне известно, нет, а что? Где это постулируется в качестве основополагающего принципа? В основу можно положить и другой принцип, если он работает.

Я всегда думал, почему это так трудно применить RUP в нашей конторе, внедрившей систему качества 9000, теперь мне ответ очевиден :) - ISO 9000 использует процессный подход как основополагающий в системе менеджмента качества.

Вообще-то я это вопрос не задавал.

Никаких претензий :)

А Вы, кстати, знаете на него ответ?

Так ведь ..., Э-ээ ...., Затем, что ..., А как иначе?
У меня весь офис (образно) увешан этими плакатами, я чихнуть не могу, попаду в очередное руководство или политику. Думаю, ответ уже где-то на подходе. :). А если вообще несерьезно, иногда очень удачно можно вставить: "А как же! Иван Васильевич! Менеджмент качества требует соблюдения этих процессов здесь, здесь и особенно здесь. Поэтому нет никакой возможности закончить данную работу в такие короткие сроки. Правда, можно попросить ребят напрячься, но это, сами понимаете, во что выливается!"

Нет, Алексей, не правы Вы, вот если бы Вы спросили меня, что-такое процессно-ориентированый подход, я бы Вам ответил, хотя наверное, я более ленивый. А Вы не можете ответить, потому как нет такого явления. Вот Вы делаете упор что в реальной жизни нет "процессов", так мы здесь моделируем. Мы не берем всю жизнь, какой интересной нам она не казалось. Жизнь ставит перед нами конкретные задачи, но чтобы успешно их решать, необходима нам модель или процесс или методология или стандарт, чтобы не изобретать велосипеды в поте лица, а наконец, оседлать своего верного моторного друга, и ехать навстречу любимой жене и детям.

Ладно, останусь магом и еретиком. :), сейчас какую-нибудь цитатку подберу в подпись :), кстати, если у кого есть, с благодарностью приму.
Вот тут уже нам намекали, что мы говорим об одном и том же, теперь и я уже (в очередной раз) склоняюсь к тому, что (мой или ИСО, я всегда к нему аппелирую) "процесс" - это "деятельность" в Вашем (и RUP?) понимании. Так как "процесс" в Вашем понимании, ни как не вяжется с моими определениями, которые я уже приводил.
Вы упоминали М$Project, специально установил свежую версию с русским языком (что бы не было неточностей перевода), открыл диаграмму ГАНТА, посмотрел в справке - там представлены "зависимости задач", на худой конец "действий". Нет никаких "деятельностей".
Мой ПМ (странно, да?) вообще таких слов не говорит как "деятельность".
Поэтому и интересно мне что это за подход такой к моделированию ЖЦ? И в чем его отличия от процессно-ориентированного подхода?
Вот ближе Вас нет ко мне никаких менеджеров, поэтому, Вы уж простите, я Вас и террризирую :) (Это не опечатка, это что бы кое-кто не нервничал за пультом :))

Подпроцесс (discipline)
A discipline is a collection of related activities that are related to a major 'area of concern' within the overall project. The grouping of activities into disciplines is mainly an aid to understanding the project from a 'traditional' waterfall perspective - typically, for example, it is more common to perform certain requirements activities in close coordination with analysis and design activities. Separating these activities into separate disciplines makes the activities easier to comprehend but more difficult to schedule.

Поясняю, из ссылки только что выдернул

Process. An ISO 12207 process corresponds roughly to the RUP
concept of a Discipline, but there are more processes in ISO 12207
than there are Disciplines in the RUP.

Качество обеспечивается, когда процессный подход накладывается на деятельностный! (или наоборот?)

Извините, что вмешиваюсь в вашу дискуссию. У меня вопросы к Виктору.
1. Почему Вы считаете, что при использовании одной модели "никто не будет спрашивать, где результаты моего труда, а особенно в самые неподходящие для меня моменты!!", а при использовании другой модели Вам эти вопросы задавать будут?
2. Почему Вы считаете, что правильно понимаете ISO, RUP и т.д.? (Я не говорю, что Вы не понимаете чего-то. Я только интересуюсь на чем основана такая безграничная уверенность).
3. Почему Вы считаете, что один (не важно какой) подход может быть универсальным? (Во всяком случае, впечатление сложилось именно такое). Почему нигде не упоминается масштаб и направленность проекта?

Повторюсь, выше изложены вопросы, а не утверждения. Мне интересно Ваше мнение в этом аспекте.

С удовольствием отвечаю (возможно, пока я отвечаю, Алексей перестанет лениться и ответит на мои вопросы)

1. В своей жизни я встретил (:)) только процессно-ориентированный подход (который ориентирован на результат), вот я и подумал, что если он требует результаты, то, возможно, новейший современный подход Алексея будет свободен от этого недостатка. (Но, вообще-то, это была такая серьезная шутка :))
2. Я привык сомневаться в словах (будь они мои или чьи-то еще), но свои слова я стараюсь подкрепить аргументами, который любой может оспорить, и не ссылаюсь на мифических авторитетов. Нет, я так не считаю, скорее всего я даже ошибаюсь и очень хочу разобраться, но наверное так и умру еретиком на костре ортодоксов :).
3. Во всей теме я видел только один подход - ИСО, других просто не видел, возможно, они есть, возможно, даже есть тот, который упоминает Алексей. Подход ИСО -универсальный, так как он таким и задумывался, возможно, получился не очень удачным (раз возникли такие споры), а мне нравится. Масштаб и направленность каких проектов следовало упомянуть?
Мне в дискуссии этой приходится сложно, с одной стороны есть сильная теория функционального моделирования, сторонником которой я являюсь. С другой стороны - Алексей с её практическим применением, но который не желает признавать ее корней. И вот я мечусь в поисках правды, безудержно впадаю в ересь, и нет никаких возможностей спасти мою мятущуюся душу!!!

Ну, господа, даже и не знаю что сказать... Компания в которой я работаю сертифицирована по CMM Level 5, и при этом использует RUP. По-крайней мере, все артифакты у нас пишутся именно по RUPовским шаблонам. Да и роли, по-большей части соответствуют.  Сертифицированы ли мы по 9000 не помню, но, кажется, да...

Слава Богу!!! А то я уж испугался :)

Слушайте, ну я так не играю, шаблоны ... роли ..., я, например, реквизит использую

Где практики? Дайте нам объективные доказательства :)

PS. Сейчас почитаю
12207 и RUP

Ну, господа, даже и не знаю что сказать... Компания в которой я работаю сертифицирована по CMM Level 5, и при этом использует RUP. По-крайней мере, все артифакты у нас пишутся именно по RUPовским шаблонам. Да и роли, по-большей части соответствуют.  Сертифицированы ли мы по 9000 не помню, но, кажется, да...

А у Вас процессы имеются?
ИСО 12207 соблюдаете?

Я -- руководитель проекта по разработке ПО. И я Вам говорю, что модель, построенная на разделении процессов и синхронизации их в контрольных точках не работает в современных условиях на проектах такого масштаба, какими мне лично приходится обычно заниматься -- протяжённостью несколько месяцев и с штатом порядка 10 человек. Вот не работает и всё. Может это я такой тупой, но почему-то ни у кого, с кем я говорил, кто выполняет похожие по масштабу проекты, тоже не работает.

А какая же модель работает? Основанная на деятельностях и потоках, примерно так, как описывает RUP. Деятельности можно условно распределить по подпроцессам, которые позволяют получить более высокоуровневый взгляд на процесс в целом. Их можно также условно разделить по стадиям, которые суть не что иное, как учёт временного фактора -- ближе к началу или к концу обычно выполняется та или иная деятельность; какие деятельности обычно выполняются одновременно и параллельно.

RUP в этом вопросе не оригинален. Возьмите любое современное руководство по проектному менеждменту и увидите, что практически везде рекомендуется подход, основанный на деятельностях, а не на процессах. Такова жизнь. И стандарты в ней не всегда помогают выжить.

Подождите, Алексей, для участников поясните:
Разве process, thread, task, work, activity не синонимичны в RUPe?

В чем отличия процессной модели от модели RUP?

Разве есть противоречия между RUP и стандартом 12207?

Разве процессный подход не основополагающий принцип менеджмента качества?

Разве зачем (:)) управлять качеством это вопрос ?

На какие ши-ши?

К сожалению, я не всегда понимаю Ваши высказывания.

:(
The truth is ... (skipped) I'm tryin' real hard to be ...(skipped)
(С) Pulp Fiction

Предположим, Вы тестируете  :)
По rup Вы никаких преобразований с программой не делаете :), просто итеративно программа с малой функциональностью становится программой с большей функциональностью :)

Т.е. в процессе тестирования программа обретает новую функциональность? :)

На какие ши-ши?

И не увидите, Вы же внедрили и RUP и ИСО :)

Виктор, расскажите нам, что Вы такое видите, чего мы не видим? Интересно же :)

RUP -- это процесс, а ISO -- набор требований к процессу. Ничто не мешает сделать процесс, построенный на RUP так, чтобы он удовлетворял этим требованиям. Что Вас смущает в этом сочетании?

По rup Вы никаких преобразований с программой не делаете :), просто итеративно программа с малой функциональностью становится программой с большей функциональностью :)

Это не RUP, это ересь какая-то! Магия и ересь :)

Видит бог - я держался,
но Алексей, как можете Вы передергивать? Вырывать из контекста? как нам продолжать беседу?

Вот Undi легко намесила из моих и своих слов какую-то абракадабру (непонятный набор слов) - я намесил ей в ответ, она не понимает, я ее не понимаю, да, Undi, Вашу абракадабру я не понял, Вы уж меня простите.

Давайте теперь и я Ваши, Алексей, слова надергаю.
RUP- процесс (в ед.числе), никто не спорит, а то что ISO - требования к процессам (многим), так там это написано, перечитайте
Вот тут намешали все понятия в кучу, хотя Вы же их разделяете
Вы говорите что discipline - это не процесс, хотя RUP говорит наоборот, правда добавляет слово "грубо", мне же это упрощение (для Вас усложнение, см. цитата про синхронизацию ниже) непонятно, зачем вообще нужно слово discipline? Вы его переводите как подпроцесс - Вам не нравится, мне нравится, никому не нравится, что это за зверь такой? Слон? За какую часть мы все держимся? Ну пусть я за хвост, так покажите мне его целиком. Вот, я немножко пощупал с Вашей стороны - действительно "грубо" похож на хвост.
И соглашаюсь с Вами хвост действительно похож на хобот, Ваша точка зрения в чем-то верна, и я понимаю что процессно-ориентированный подход, слишком дорого обходится в однодневных (имеется ввиду не один день, а просто их небольшое количество вплоть до 5 лет) проектах, в которых Вам доводилось участвововать.
А беспорядочно (прошу заметить, сначало хотел применить другое синонимичное слово)-ориентированный подход - очень даже поможет сэкономить. Удастся - хорошо, не удастся - господь с ним.

То что в RUPe идет первой строкой для Вас (вдруг) магия и ересь. Я приведу ее, а то опять передернут: Iterative Development. Для вас ересь, что тестирование - часть итеративного процесса разработки?
Магия, что в результате процесса разработки появляются программные продукты?
Может аист их приностит менеджеру проекта?

Вот Вы пишите

И я Вам говорю, что модель, построенная на разделении процессов и синхронизации их в контрольных точках не работает

А я Вам говорю, что в моем случае работает и даже больше - не работает ни какая другая модель. И RUP у меня (и у всех внедривших ИСО) будет работает на разделении и контроле в точках. А в цитате выше Вы сказали что такой модели ничто не мешает. Ну хорошо, многие часто меняют свое мнение, так передерните свои слова, Ваших слов больше!!! Так и скажите - я ошибался в RUP - он процессно-ориентированный.
Вот Вы пишите

Они намеренно и сознательно сужают тему и выделяют деятельности по тестированию из всех остальных, пытаясь рассматривать их хотя бы в частично изоляции

А я говорю, что при создании внутреннего ПО нет никакого сужения в этом вопросе - так оно и есть, а для процессов создания ПО широкого потребления возможно нужны другие методологии и стандарты(Многим достаточно только шаблонов и названия должностей)

Остальные упомянутые Вами термины (process, thread, task, work) в RUP не используются

(выделено мной) процесс в RUP не используется, почему? Почему они придумали кучу своих терминов, далеких от реалий жизни, что это за модель, из которой все берут только шаблоны и названия должностей?

Поэтому я бы сказал, что RUP эксплуатирует деятельностно-ориентированный подход

А ИСО - процессно-ориентированный и это термин определен в ИСО, а деятельностно-ориентированный подход это Ваш термин и это Ваша задача придумать 10 различий и мне показать

Насколько мне известно, нет, а что? Где это постулируется в качестве основополагающего принципа? В основу можно положить и другой принцип, если он работает.

А заглянуть и убедиться трудно в ИСО9000? Я заглянул, убедился, что Вы абсолютно не правы, во теперь и Вам это будет известно
Да! Есть еще системный подход к управлению

Процессы трудно синхронизировать в milestones, если что-то пошло не очень гладко и один из процессов, например, отстаёт от плана, а остальные нет

Да, только ГОСТ требует(это четко зафиксировано) синхронизации и четко выполнения плана, прозрачности деятельности, а RUP - нет? (Я поставил здесь вопрос: разве RUP требует или предлагает какую-то другую синхронизацию?). Вообще трудно синхронизировать. Как же снизить риск перерасхода ресурсов и выхода за график, если не синхронизировать в вехах? А если кто не следует ГОСТу - так это его проблема и его заказчиков, и не объясняйте, что просто им этого не надо - не поверю заранее.

Качество обеспечивается, когда его обеспечивают

Каким образом без синхронизации в контрольных точках, Вы обеспечиваете качество?
Применение методологии RUP гарантирует качество продукта или процесса его создания? Выполнение требований ГОСТ гарантирует.

Если кому-то мои слова покажутся резкими, прошу меня извинить.

Ну и на последок, определение:
модель жизненного цикла: Структура, состоящая из процессов, работ и задач, включающих в себя разработку, эксплуатацию и сопровождение программного продукта, охватывающая жизнь системы от установления требований к ней до прекращения ее использования.
За какую часть этого зверя вы держитесь, господа?

Про семью, Dmitry_NJ, ты правильно заметил. Семья требует средств.

Странно, что люди, занимающие вроде бы немаленькие посты и по идее обязанные понимать мотивацию работников лучше других ( в статье это директор по HR-консалтингу «Аддити», консалтингового подразделения «АйТи»)  живут в плену каких-то романтических иллюзий про интересную работу.

Вот здесь как раз все понятно:
интерес - это тоже товар, и владелец пытается его выгодно продать. Чем больше заработная плата, тем меньше прибыль. Заинтересовать, уменьшив затраты на специалиста, вот истинная цель руководителя. Ведь не зря руководители так пекутся о системе мотивации.
И не пишут, что за обучение специалист должен расплачиватся кабалой (реальные случаи!!!).

Я думаю, специально участник(и) дискуссии в статье вводит(ят) в заблуждение читателя. Правда в том, что ради каких-то своих целей, человек может поступиться своими принципами и интересами. Цель руководителя - найти это слабое звено, и через него вытащить специалиста всего с потрохами.
А интерес это понятие субъективное, даже у конвейера его находят. Плох тот работник, который не заинтересован в работе, но еще хуже тот, кто не заинтересован материально, этот орел клюнет в самый неподходящий момент, бросит дело, когда станет жарко.

И в чем же смысл пропаганды участников? В строках
Как показывает опыт, для ИТ-специалиста не всегда важно, где он работает (насколько известна та или иная компания на рынке), но всегда имеет значение качество задач, которые он решает. Интересная и захватывающая задача - для этих людей один из самых сильных мотивационных факторов. Предоставить такую возможность можно всегда
Прямое руководство к действию - руководитель всегда должен пытаться мотивировать сотрудников, отдавая приоритеты незатратным средствам (но и денежкой иногда), приговаривая, ай-да работа у вас - интересная и захватывающая. Специалист должен всегда требовать повышения зарплаты (при этом не забываясь), приговаривая, ай-да работа у меня - сложная и ответственная.
И в этом танце рождается лучшее :).