[Но вообще-то автор не скрывает того, что эта книжка -- про дрессуру животных, примеры применения бихевиористических подходов к человеку встречаются там нечасто и весьма условны или примитивны. Причина в том, что такие приёмы хорошо работают для научения относительно простому поведению, грубо говоря -- для выработки и поддержания привычек или условных реакций. "Настоящие" мотивации таким способом не вырабатываются.

Если построить лабиринт для крысы и для человека и при каждом эксперименте класть в конце лабиринта кусочек сыра (для крысы) и пятьдесят долларов (для человека, не перепутайте!), то человек найдёт правильный маршрут намного быстрее крысы.

Но если перестать подкладывать сыр и деньги, то крыса очень скоро перестанет ходить по лабиринту. А человек будет снова и снова проходить лабиринт до конца в надежде найти там ещё пятьдесят баксов. :)

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

Я вот тут подумал: а зачем вам вообще кого-то мотивировать? Мотивация ведь сама по себе не может быть целью.

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

Другие проблемы (или риски), которые приходят на ум: недостаточная производительность, несоответствие культуре компании ("нерадивый" работник не вписывается в команду или расхолаживает остальных). Что ещё?

1. Составить градацию профессинализма своих сотрудников: младший тест-дизайнер, тест-дизайнер, старший тест-дизайнер и т.д. - количество ступеней и названия на Ваше усмотрение
...
4. Выясните проф. уровень каждого сотрудника.
5. Определите, что нужно каждому для достижения следующей ступени и в какие сроки (на Ваш взгляд).
...

Люди обычно склонны себя переоценивать. imho эти градации неизбежно приведут к конфликтам (начальник придирается, молодой коллега обошёл в должности и т. п.) Какая уж тут мотивация.

Кроме того, такая система рангов и аттестаций мне кажется попыткой менеджера перенести ответственность с себя на "процесс". Вместо того чтобы работать с каждым индивидуально, он кивает на таблицу - пусть она "мотивирует".


Кстати, в школах сравнительно недавно разрешили директорам самостоятельно устанавливать размер зарплаты учителям. То есть у каждого учителя есть некоторая базовая зарплата (категория, часы и т. п.), и есть отдельный фонд, из которого директор платит надбавки в соответствии с заслугами или, наоборот, проступками. Во многих школах директора попытались ввести "объективную" метрику для расчёта надбавок на основе баллов. То есть провёл общественное мероприятие - получи плюс десять баллов. Опоздал на педсовет - вот тебе минус пять.

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


Как обычно, всё сугубо imho.

А начинающим менеджерам могу порекомендовать вот эту книгу:
Любите их, или вы их потеряете

Представление о книге можно (надеюсь) составить по этим цитатам.

Нате вам сказочку на ночь, горячие финские парни и девушки.

Притча о кризисном менеджере Самсонове

Нет, не все зануды.

Некоторые - гении.

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

проблема в том, что часто бывает - управление рисками берет на себя вышестоящее начальство. Наталья, у по вашей логике в такой ситуации, тим-лид - козел отпущения. За результат спросят с него. А он процесс-то наладил...

Так что делает вышестоящее начальство - управляет рисками или ищет козла отпущения? Это взаимосключающие параграфы.

Главное - стребовать хорошую медицинскую страховку. Молоко не поможет.

Ага, запустил компилятор и ушёл курить. Вернулся, исправил ошибку, и опять курить. А тут, глядишь, и рабочий день закончился. Мне так приходилось работать одно время (правда, я не курю, приходилось чай пить с девочками).

У разработчика должна достаточно быстрая рабочая станция, чтобы не тормозила разработку. А ещё у него должны быть чёткие требования к производительности до начала проектирования.

А ещё у компании должен быть тестировщик с отдельным сервером, позволяющим эти требования проверить.

Это уже давно не философский вопрос, а организационный.

В общем, опять тестировщики не могут найти общий язык с разработчиками. :)

А виноват, как обычно, тот, кто организует процесс.

Медленно работает сервис? Значит нужно купить ещё один мощный сервер, чтобы программа работала быстро... Иногда это оправдывается тем, что дешевле купить сервер, чем оплачивать много-много часов рабочего времени разработчика, который оптимизирует свое, ранее написанное медленное поделие. Так почему бы не писать быстро сразу?

Потому что писать быстро сразу тоже может оказаться дороже, чем купить новый сервер.

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

К счастью, эти времена давно прошли. Теперь разработчики должны писать программы, максимально удовлетворяющие их пользователей. ;)

Для того чтобы начать думать над быстродействием своей программы разработчик сначала должен понять, что его программа работает медленно. Запуская программу на быстром сервере он никогда этого не поймет.

Так у вас ведь есть тестовый сервер, на котором вы обнаружили проблему! Посадите возле него разработчика, пусть попользуется и поймёт.
Низкая производительность - это только одна из проблем. Дав разработчику медленное оборудование, вы действительно забудете об этой проблеме, потому что её заслонит куча других.

Разработчик, передавая сервис на нагрузочные тесты, понятия не имеет быстрый он сервис написал или медленный. И нам (нагрузочному тестированию), приходится открывать глаза разработчику.

А должен бы знать. Если требования по производительности сформулированы сразу, то она должна быть заложена ещё на этапе проектирования.
Если требований нет, то и спроса с разработчика быть не может.

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

Я не уверен, что "оптимизация на ходу" - это вообще оптимизация. Над оптимизацией производительности нужно очень хорошо думать вперёд, а не задним числом.

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

Пользователя обычно не интересует, сколько ресурсов потребляет программа, пока она не вызывает проблем. Слава богу, прикладные программы на языке ассемблера уже никто не пишет, хотя двадцать лет назад это ещё давало конкурентные преимущества.

Зачастую так и делаем, сажаем, рассказываем, разработчик видит и пытается улучшить, но на это тратится кучу времени, которое в принципе можно не тратить, если внедрить то, что я предлагаю. Куча других проблем - это какие?

Замедление разработки.
Пропущенные разработчиком баги из-за удлинения итерации (не командной, а личной итерации разработчика).
"Оптимизация" тех частей, которые в реальности оптимизировать не надо.
Уход разработчика из-за невыносимых условий работы, наконец. :)


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

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

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

То есть ты бы сам у себя собеседование не прошёл. :)

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

По поводу креативности и способности генерировать новые идеи - мой любимый пример из литературы:

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

А поменять ничего не можем.

Да можете, конечно. Откуда эта безысходность?

Мне не нравится слово "пинать". Здесь больше подходит выражение "капать на мозги". :)
А капать на мозги нужно, да. Если только, конечно, вы не Wally из Дилберта.

Напоминать о делах, которые должен сделать менеджер задача только высшего менеджмента.

А кто должен напоминать о делах высшему менеджменту? А если высший менеджмент забудет напомнить?
Строго иерархические модели подчинения работают только в армии, причём только во время войны.

Если входит в систему, что подчиненные контролируют своего руководителя, то должен подняться вопрос о компетентности такого управленца.

"Должен подняться вопрос" - это хорошо сказано. :) Он сам себя должен поднять?

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

У "идеальных" бизнес-процессов есть один недостаток: они рассчитаны не на людей, а на роботов. Или, как минимум, на сверхчеловеков. :)

Классно придумано!

Может на Хабре стоит попиариться? Сказать мол есть такой проект классный и бесплатный. Нужна мол дизайнерская мысль и рука для логотипа.
Заодно и пользователей прибавится и устойчивость сайта можно проверить :)

Да, кстати, легенду по цветам хотел узнать - что-то желтое, что-то оранжевое.

Не надо пока на хабре. Хаброэффекта сайт не выдержит, кэширование ещё не дописано.
Цвета кислотные, сам знаю. Зато все из таблицы "безопасных цветов". :)

Сайт очень удобный, наглядный и полезный, и да, большое за него спасибо!

Только непонятно, почему, если верить карте, все вебинары проводятся в Сыктывкаре? :)

А где на карте должен быть Интернет? :)

Давно хочу поблагодарить за столь грамотно продуманный интерфейс ресурса -- в очередной раз добавляла информацию и поняла, что это интерфейс ресурса один из самых удобных из всех известных мне сайтов для размещения информации о мероприятиях.

Спасибо! Кстати, на страницах учебных центров появилась кнопочка "рекомендовать" для facebook:
http://www.it-map.ru...testing-ru.html

Кстати, на сайте it-map.ru появилась карта. Теперь название домена стало осмысленным.

Вот, например, карта тренингов Software-Testing:
http://www.it-map.ru...testing-ru.html

Вот логотип для сайта я никак не придумаю. Так и висит черновой вариант.

Слишком общее описание ситуации, трудно определить, кто кому и что должен.

Но в общем случае, если у вас есть ТЗ и договор, а в них ничего не сказано об особенностях реализации, то об этом и надо говорить с заказчиком.

Должен ли Разработчик согласовывать детали технического решения с Заказчиком?

Если об этом заранее не договорились и если задание на разработку изначально не предполагает использование какого-то технического решения, то не должен. Но если обеим сторонам очень хочется, то можно. :)

Имеет ли право Заказчик потребовать это на заключительной стадии?

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

Неужели такое бывает в регламенте взаимодействия?

Если такие регламенты где-то и существуют, то они не работают.

podfm.ru позволяет создавать слайдкасты, которые, в отличие от slideshare (когда он ещё работал), нормально воспроизводятся в жежешечке.

Пример.

Посмотрел, вроде бы все понятно. Но есть неудобства по сравнению со слайдшарой.

...

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

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

А вообще, давно вынашиваю идею делать слайдкасты в виде flash-роликов с помощью видеоредактора (в любимом VirtualDub с последующей конвертацией, например). Пока не было острой необходимости, но, может быть, попробую сделать такие слайдкасты после ЛАФ-2010.

У слайдшары тоже есть несколько очень неприятных глюков. Если запись длится больше определённого времени (грубо: больше часа), то синхронизация со слайдами пропадает. В редакторе всё, вроде бы, нормально, но при воспроизведении невозможно добраться до слайдов, находящихся за границей этого времени. Приходилось из-за этого, например, доклады с TrainingLabs рвать на части (после нескольких часов бесплодной борьбы).
Минимальный интервал между слайдами довольно большой, из-за чего невозможно провести точную синхронизацию с речью (особенно если докладчик быстро листает презентацию). Ну и результаты редактирования терялись несколько раз, приходилось всё начинать сначала.

Я, собственно, на podfm и наткнулся в поисках альтернативы slideshare.