VAB>Но и Максим не зря запустил тему, хорошо видно что гладко все только на бумаге.
Что от бумаги, что от обсуждения толк будет лишь в том случае, если суметь применить идеи на практике.
По-моему устраивать обсуждение исходя из предпосылки "на практике это не применимо, потому, что..." несколько странно
Как раз интереснее всего (с моей точки зрения) будет обсудить — что и как можно сделать именно в реальных (а не идеализированных — книжных) условиях, обменяться опытом, поэкспериментировать и расказать о результатах

Здравствуйте, savaDAN, Вы писали:

DAN>С другой стороны у PMа не так уж много рычагов воздействия на разработчика. У нас например системы штрафов не существует, а некоторым просто объяснять — не действует.
Это как объяснять
Кроме того если человек "не понимает" — возможно, что у него есть мотив не понимать. Возможно он хочет делать что-то другое или не понял, зачем это надо.

DAN>У нас оплачиваются переработки, но это совсем другая история: проверяется чем человек в это время занимался и оплачивается только если он грубо говоря за 50 часов в неделю сделал больше чем сделал бы за 40.
Тут есть сложность. Кто определяет сроки. Если сам разработчик — это одно (да и в этом случае он может ошибаться), если же кто-то за него — то на выходных работать должны как минимум оба. Продуктивность то у всех разная. Кроме того частенько бывает ситуация, что менеджер просто не видит "мелких" деталей, которые возникают при реализации его гениальных замыслов и не понимает "что там делать столько времени"

Здравствуйте, AndreyFedotov, Вы писали:

VAB>>Но и Максим не зря запустил тему, хорошо видно что гладко все только на бумаге.
AF>Что от бумаги, что от обсуждения толк будет лишь в том случае, если суметь применить идеи на практике.
AF>По-моему устраивать обсуждение исходя из предпосылки "на практике это не применимо, потому, что..." несколько странно
я не говорил что неприменимо — но в такой формулировке красивой был изложен тезис что напомнило что-то из серии "А давайте чтобы мир во всем мире!". Связи с реальностью немного захотелось добавить — и добавил в пред сообщении

AF>Как раз интереснее всего (с моей точки зрения) будет обсудить — что и как можно сделать именно в реальных (а не идеализированных — книжных) условиях, обменяться опытом, поэкспериментировать и расказать о результатах
Хорошо, но тут не бывает совета на все случаи, тогда надо описывать хотя бы паттерн — по типу как сделал Максим — и пытаться к нему подобрать оптимальный ключик? Второй момент — люди работают с людьми. Возможно поднаторевшие в науке психологии могут описать харизму лидера каким-то прототипом а-ля "Наполеон", оцифровать характер по их классификации и потом оперировать этими терминами, но я тут не силен. Просто сложно не зная коллектива давать советы — точнее давать их легко, но не факт что они будут нужны\применимы

Впрочем это выливается во флейм ни о чем, нужны конкретные ситуации чтобы дальнейшее обсуждение имело смысл. Хотел тут остановиться, но подумав, решил написать чуть больше

---

Можно конкретизировать: скажем как добиться работоспособности тезиса: "доводить до людей цели, которые они преследуют, учитывать их мнение и вовлекать в процесс принятия решений. То есть строить отношения таким образом, что бы каждый человек на фирме видел себя частью единого целого, а так же видел — какую цель преследует его деятельность и для чего она нужна. "

Конкретные реально работающие способы могут быть:

— сформулировать цели четко и ясно нарпимер путем презентации на годовом собрании фирмы roadmap и публикацией его в интранете, чтобы всегда любой новичек мог ознакомиться

— четкий критерий проверки достигнута ли цель (есс-но цели для sales & QA будут разные, но всегда есть одна глобальная — принести прибыль): например, продать в этом году миллион лицензий продукта или продать на миллион рублей или пройти сертификацию по СММ уровня такого то

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

— объективные метрики везде где можно. Обязанности не должны в основной массе меряться субъективными критериями иначе их невозможно будет проверить и это лиюо прямой путь к одному из паттернов Максима, либо к моему дополнению что либо босс либо сотрудник будет неадекватен. По объективным критериям зависимость от личной симпатии уменьшается и соотв уменьшается вероятность сотруднику свалить критику шефа на "необъективность и потому что я ему ж не лижу как мой сосед". по этому поводу я писал здесь кстати: Re[6]: C# job in Spb

Автор: Valerio
Дата: 15.02.05

— аттестация преследует 2 цели — проверить что достигнуто по плану с пред аттестации (с применением объективных критериев, а не субъективных!) и наметить аналогичный план на след период. План должен включатьчтото типа таблички: цель, что сделать чтобы ее достигнуть, как проверить что цель достигнута,дата\подпись как аттестуемого так и тех кто аттестует, копия док-та у каждой стороны чтобы потом небыло разборок про "а на берегу ты мне обещал...". Одно дело если боссу не кажется что сотрудник был инициативным, другое дело если было обцее правило по отделу — 3 одобренных разпредложения в квартал — это значит что все-таки сотрудник инициативный. И легко проверяется по итогам квартала — нет возможности быть недовольным, если не внес 3 толковых предложения. Правда слождее в этой схеме будет тем, кто привык горлом и мельтешением ежедневным на обеде перед глазами шефа статус "инициативного" нарабатывать.

— корпоративный ящик idea@acme.com + назначить ответственного (а лучше несколько человек скажем тех экспертов ответственных за тех идеи, и т.п.) за проверку почты в нем и роутинг на ответственных лиц с автором идеи в Сс + жесткие сроки на ответы скажем в течении 3х дней по орг вопросами и неделю на тех инновацию. Реакция может быть и такой что "идея принята и будет рассмотрена после приезда главного на собрании после такого числа", чтобы автор идеи не гадал дошло ли письмо, читали ли его и т.п. В принципе тут на базе всяких Lotus Notes или новых технологий из Офиса даже можно замутить машину состояний и позволять отслеживать запросы как авторам так и ответственным лицам, но это только для больших компаний. Возможно есть коммерческие продукты или системы управления требованиями можно какие-то присобачить сюда. Итог этого пункта — человек получает обратную связь, по крайней мере шанс быть услышанным не только своим непосредственным боссом (который может потом его идею выдать за свою или просто единолично счесть ее ненужной), а вплоть до высшего руководства, которого иногда и в лицо то не знает. За принятые идеи поощрять материально и как минимум публичной благодарностью с отмечанием авторства.

— заинтересовать материально в общем успехе по итогам проекта\фин года, при этом четко сформулировав критерии ДО наступления события итог проекта\года и сделав прозрачным способ проверки этого сотрудниками. Не работает к сожалению для рядовых сотрудников в большинстве случаев, ибо проблемы и с прозрачносью и с формулировкой критериев ДО (все равно проверить бухгалтерию конторы никто не даст кому-то из QA). В маленьких командах напарников-основателей стартапов по определению все позиции ключевые. На западе давно это решили через систему опционов\акций и там таким образом проблема с прозрачностью попроще — ибо не руководство компании решает какие цифры показать коллективу, а сколько взять себе. У нас тоже постепенно компании вроде SW-Soft начинают внедрять эти технологии, насколько мне известно — жаль что опять это недоступно бойцам невидимого фронта, только относительно ключевым фигурам в компании и возможно каким-то ветеранам.

Это сходу, пока думаю зватит? Комментарии, добавления?

DAN>>С другой стороны у PMа не так уж много рычагов воздействия на разработчика. У нас например системы штрафов не существует, а некоторым просто объяснять — не действует.
AF>Это как объяснять
AF>Кроме того если человек "не понимает" — возможно, что у него есть мотив не понимать. Возможно он хочет делать что-то другое или не понял, зачем это надо.
Какой-то крайне общий и отвлеченный ответ получился. Т.е. непонятно что с ним делать.

Я в общем-то осознаю, что если человек не делает то что ему говорят, значит он считает что это неправильно.
А вот тут уже начинаются варианты в зависимости от которых применяется разное лекарство.
Например (это не совсем касается предыдущего моего поста, скорее анализ почему "не понимают"):
1. человек не компетентен, т.е. просто не понимает почему именно так. Классический пример: неопытный программист считает что пока в его программе не найдутся баги — багов нет, опытный программист считает, что пока в его программе не будут найдены и устранены все баги — они там есть (извиняюсь за недословную цитату) — иногда область некомпетенции может быть достаточно обширна, чтобы все объяснять потребуется даже не день — в таком случае имеет смысл дать ссылку на книжку и сказать "пока поверь мне на слово".
2. человек видит только часть картины, в то время как полная картина совсем другая — опять же или ссылка на книжку, или просто сказать "делай так, потому что я лицо принимающее решение".
Понимаю, что ни 1 ни 2 не самый лучший вариант, по хорошему у разработчика должен быть ментор который им будет заниматься, но на практике к сожалению это не позволяют сроки, бюджет проекта и т.п.
Заставлять переделывать в таком случае ессно грех.

3. человек все отлично знает, но не делает потому что понимает. Варианты "да че тут, фича на полчаса, ща забацаем" — в этом случае торжественно заассайнить найденные баги и заставить их фиксить в субботу обязательно имхо нужно чтобы знания перешли в понимание
4. человек все знает и понимает но не делает. Саботаж. Возможные причины: недоволен зарплатой, его классного девелопера заставляют заниматься всякой фигней и т.п. — Зависит от человека/состояния проекта. Иногда приходится заставлять переделывать плохой код.

Ваши варианты, мнения по поводу вышесказанного.

DAN>>У нас оплачиваются переработки, но это совсем другая история: проверяется чем человек в это время занимался и оплачивается только если он грубо говоря за 50 часов в неделю сделал больше чем сделал бы за 40.
AF>Тут есть сложность. Кто определяет сроки. Если сам разработчик — это одно (да и в этом случае он может ошибаться), если же кто-то за него — то на выходных работать должны как минимум оба. Продуктивность то у всех разная. Кроме того частенько бывает ситуация, что менеджер просто не видит "мелких" деталей, которые возникают при реализации его гениальных замыслов и не понимает "что там делать столько времени"
Вы не так поняли. Это со сроками никак не вяжется. если менеджер просит выйти поработать в субботу потому что планы были херовые — эта переработка оплачивается в любом случае. Если человек хочет добровольно поработать в субботу (а к концу проекта он всегда горит , поэтому такое желание только welcome) — это тоже оплачивается, если человек написал код который по результатам ревью признан непригодным — не оплачивается. если слишком много багов и они ляповые (off by one error или обработка ошибок хромает) — тоже не оплачивается. Ну и т.п.
В общем и целом система не идеальна, но это имхо лучше чем вообще не оплачиваемый овертайм

VAB>Конкретные реально работающие способы могут быть:
Вопрос к Валерию и к общественности: а окупит ли себя введение всего перечисленного в предыдущем сообщении? Или не получится ли так, что после внедрения всех этих вкусностей не останется денег на хорошую зарплату разработчикам, из-за чего они все разбегутся по другим конторам? И не получится ли так, что пустив эти доп. средства на повышение зарплаты выше уровня рынка в компанию при активности HR-ов постепенно стекутся лучшие люди, из-за чего контора станет работать на порядок лучше чем высокомотивированные середняки?

Здравствуйте, savaDAN, Вы писали:

VAB>>Конкретные реально работающие способы могут быть:
DAN>Вопрос к Валерию и к общественности: а окупит ли себя введение всего перечисленного в предыдущем сообщении? Или не получится ли так, что после внедрения всех этих вкусностей не останется денег на хорошую зарплату разработчикам, из-за чего они все разбегутся по другим конторам? И не получится ли так, что пустив эти доп. средства на повышение зарплаты выше уровня рынка в компанию при активности HR-ов постепенно стекутся лучшие люди, из-за чего контора станет работать на порядок лучше чем высокомотивированные середняки?

Хороший вопрос, но времени развить тему нет прямо сейчас. Пока напишу только по поводу следующей ситуации: Допустим ср-ва есть, но весьма ограниченны. Я не думаю что невозможно внедрить ВСЕ упомянутые мной вкусности даже в начинающих стартапах без больших ср-в\инвестиций.

Смотрим:
— накропать цели на 6 мес\год возможно и без общегодового собрания компании, можно и на кухне написать, главное в этом док-те чтобы за деревьями лес не потерять потом. Цена близка к нулю

— Публикация roadmap в интранете необязательна — intranet может ведь и не быть? Но сам документ должен быть и должен быть доступен в виде файла, не думаю что это стоит больших денег.

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

— провести аттестацию можно и в 30 мин на листике бумаги глаз на глаз — не обязательно загружать этой волокитой HR отдел особенно если его нет и весь коллектив 2 человека . Это просто как расписка при заеме денег — друзьям в принципе она не нужна.... но до определенного размера суммы! В любом случае с такой распиской жить проще потом и легко разобраться в случае конфликтов, а не опереровать формулировками "я помню мне сказали что..." и "я такого не говорил а имел ввиду что...". Цена вопроса гораздо меньше чем долгое убеждение штата компании на политзанятиях, что они работают в крутой фирме и как они должны быть счастливы что строят Нью-Васюки — это по определению более долго, ибо чтобы закрепилось в мозгах требует поторения не менее 100 раз в неделю

— корпоративный ящик не требует вложений. Обязанность по его просматриванию может совмещаться кем-то, а в совсем маленьких проектах просто предложения имеют свойство забываться после озвучивания соседу — лучше привить практику оформления всех идей либо на ящик либо приспособить систему хоть контроля версий — иметь документ ideas.doc и в него коммиттать появляющееся... денег не надо опять

— в итоге самое главное — заинтересовать материально и вот сюда нужны деньги. инвестиции тут помогают пережить трудное время на старте, ибо когда проетк финансируется из своего кармана — тут и жена одного из партнеров может оказаться самым большим неучтенным риском... такое сложнее просчитывается чем что либо еще

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

Собственно даже Google начинался с заема 100,000 баксов на прокупку старых винтов у одного богатого еврея Ну это неважно, важно что просто команда энтузиастов работаюзих днем в приличных компаниях а по вечерам\ночам\выходным пишущих нечто свое заранее в неравных условиях стоит и этот случай стоит рассматривать не в этом форуме, а в shareware.business. Но идеи выше применимы и там, как я показал выше — главное не думать что успех проекта целиком зависит от успеха на технической стороне.

VAB>Хороший вопрос, но времени развить тему нет прямо сейчас. Пока напишу только по поводу следующей ситуации: Допустим ср-ва есть, но весьма ограниченны. Я не думаю что невозможно внедрить ВСЕ упомянутые мной вкусности даже в начинающих стартапах без больших ср-в\инвестиций.
Под средствами также стоит рассматривать время которое будет тратить менеджер. Написать роадмап это не сложно и необходимо, совершенно с вами согласен, а вот мерить метрики и проводить аттестатцию уже значительно больше времени занимает. Впрочем все реализуемо, вопрос в том насколько это даст реальную отдачу.
Позвольте прокомментировать по пунктам.

VAB>- накропать цели на 6 мес\год возможно и без общегодового собрания компании, можно и на кухне написать, главное в этом док-те чтобы за деревьями лес не потерять потом. Цена близка к нулю
Нужно. Однако что это даст в смысле мотивации конкретному девелоперу? Только наверное спокойствие: "начальство знает куда нас вести". С другой стороны стоит быть осторожным с цифрами, т.к. возможна даже демотивация: "эти сволочи бабки загребают лопатой — миллионы копий продают, а я тут на 600 зеленых в месяц горбачусь". Впрочем это тема совсем отдельного разговора.

VAB>- объективные метрики тоже не требуют вложений, достаточно потратить пару часов на обсуждении с той же командой единомышленников и родить критерии с которыми все согласятся и далее соотв работают по этому своду внутренних правил, деньги тут нужны только на оплату времени сотрудников занятых на собрании. В компаниях побольше конечно тут стоит подумать получше, но тоже не сильно ресурсоемкое дело.
Уточните пожалуйста что вы понимаете под метриками? Я так понимаю речь идет о неких корпоративных правилах о скажем качестве кода и т.п.?
Что это даст с точки зрения мотивации?

VAB>- провести аттестацию можно и в 30 мин на листике бумаги глаз на глаз — не обязательно загружать этой волокитой HR отдел особенно если его нет и весь коллектив 2 человека .
По хорошему нужно строить career plan, иначе опять возможна демотивация: "я такой крутой по аттестатам, а мне денег нифига не платят/фигней всякой заставляют заниматься".
Т.е. аттестация ради самой аттестации имхо бессмыслена.
Что касается career plan-а: к сожалению тоже не все гладко: так или иначе развитие сотрудника зависит от развития команды в целом и в результате запросто можно человека "обломать" — не дали денег заказчики, продукт продается хуже чем ожидалось и т.п. Может быть более разумных/достаточным будет: появилась потребность в новом начальнике — отобрал самого перспективного/подходящего — его назначил.

VAB>В любом случае с такой распиской жить проще потом и легко разобраться в случае конфликтов, а не опереровать формулировками "я помню мне сказали что..." и "я такого не говорил а имел ввиду что...".
Опять, каким образом это повысит мотивацию?
VAB>Цена вопроса гораздо меньше чем долгое убеждение штата компании на политзанятиях, что они работают в крутой фирме и как они должны быть счастливы что строят Нью-Васюки — это по определению более долго, ибо чтобы закрепилось в мозгах требует поторения не менее 100 раз в неделю
Имхо на ИТ-people это вообще не действует склад характера не тот.

VAB>- корпоративный ящик не требует вложений. Обязанность по его просматриванию может совмещаться кем-то, а в совсем маленьких проектах просто предложения имеют свойство забываться после озвучивания соседу — лучше привить практику оформления всех идей либо на ящик либо приспособить систему хоть контроля версий — иметь документ ideas.doc и в него коммиттать появляющееся... денег не надо опять
Делали общий анонимный ящик — за год работы ни одного сообщения
ideas.doc для каждого проекта существует, но там больше фичи для самого проекта, чем общие пожелания по процессу.
Опять же эти предложения удобней в bugtracking системе вести.

VAB>- в итоге самое главное — заинтересовать материально и вот сюда нужны деньги. инвестиции тут помогают пережить трудное время на старте, ибо когда проетк финансируется из своего кармана — тут и жена одного из партнеров может оказаться самым большим неучтенным риском... такое сложнее просчитывается чем что либо еще
Вот! И это ключевое имхо! К сожалению зарплата среднего разработчика все таки слишком далека чтобы думать о чем-то еще. В смысле чтобы зарплата не была решающим аргументов. Следовательно, стоит ли затевать весь сыр бор, если соседняя контора поставив на 20% бОльшую зарплату заберет разработчика с потрохами? Хотя то что вы выше перечислили скорее улучшает процесс, нежели мотивирует.
Вот с менеджерами нужен уже более тонкий подход...

VAB>Сейчас я вижу что оптимистичный вариант развития компании планирующей не стать однодневкой вряд ли возможен без серьезных инвестиций (хотя бы на ЗП выше средней по отрасли на срок проекта * на Pi для аккумулирования лучших кадров, которые как известно решают все).
Скорее тут лучше работает (да и на практике чаще встречается) подход когда начинает работать небольшая команда профессионалов на перспективу: станем большой конторой, будем все в шоколаде.

VAB>Но идеи выше применимы и там, как я показал выше — главное не думать что успех проекта целиком зависит от успеха на технической стороне.
Не целиком, но предопределяющее.
Я собственно что хотел сказать всеми этими постами: нет смысла активизироваться на мотивации девелоперов если процесс не поставлен, нет заказчика/идеи.

Т.е. хорошо мотивированный девелопер работающий на коленке без требований, без багтрекинга, планов, SCM систем и т.п. будет все равно работать хуже чем человек работающий за деньги но с хорошо поставленным процессом. И вся мотивация у него испарится когда он будет вручную мержить код нескольких человек или получит по башке от менеджера за то что забыл пофиксить баг, о котором тот ему вчера в курилке говорил
А по моему хоть и небогатому, но все же опыту большинство компаний даже находящихся в москве похвастать хорошо поставленным процессом не могут. СММ3 компании по пальцам пересчитать можно. А уж СММ5 по моему вообще всего две компании — Luxsoft и CQG.

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

Здравствуйте, savaDAN, Вы писали:

VAB>>Хороший вопрос, но времени развить тему нет прямо сейчас. Пока напишу только по поводу следующей ситуации: Допустим ср-ва есть, но весьма ограниченны. Я не думаю что невозможно внедрить ВСЕ упомянутые мной вкусности даже в начинающих стартапах без больших ср-в\инвестиций.
DAN>Под средствами также стоит рассматривать время которое будет тратить менеджер. Написать роадмап это не сложно и необходимо, совершенно с вами согласен, а вот мерить метрики и проводить аттестатцию уже значительно больше времени занимает. Впрочем все реализуемо, вопрос в том насколько это даст реальную отдачу.

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

VAB>>- накропать цели на 6 мес\год возможно и без общегодового собрания компании, можно и на кухне написать, главное в этом док-те чтобы за деревьями лес не потерять потом. Цена близка к нулю
DAN>Нужно. Однако что это даст в смысле мотивации конкретному девелоперу? Только наверное спокойствие: "начальство знает куда нас вести". С другой стороны стоит быть осторожным с цифрами, т.к. возможна даже демотивация: "эти сволочи бабки загребают лопатой — миллионы копий продают, а я тут на 600 зеленых в месяц горбачусь". Впрочем это тема совсем отдельного разговора.

Про ЗП важно — но при прочих равных когда все в порядке в компании на лишнии 100 уе никто не бросится.

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

Одно дело когда ты недоволен потому что тебе кажется что тебя не оценили\не любят\не понимают и другое когда как я сказал по возмоности объективные (=порверяемые легко кем угодно) критерии действуют. Тут сложнее быть недовольным кем-то кроме себя — раз ты правила знаешь и согласился с ними когда-то.

И увереннось что нач-во знает что делает а не сборище балбесов которое вызывает резкое согласие с тезисом "у нас каждая кухарка может управлять страной а уж я то всяко лучше знаю что делать чем новый хрен с горы (босс Петя) до прихода к нам торговавший лесом и думающий тока о новых тачках + нихрена не парящий в нашем деле" и желание сменить обстановку даже с потерей 100 уе!

VAB>>- объективные метрики тоже не требуют вложений, достаточно потратить пару часов на обсуждении с той же командой единомышленников и родить критерии с которыми все согласятся и далее соотв работают по этому своду внутренних правил, деньги тут нужны только на оплату времени сотрудников занятых на собрании. В компаниях побольше конечно тут стоит подумать получше, но тоже не сильно ресурсоемкое дело.
DAN>Уточните пожалуйста что вы понимаете под метриками? Я так понимаю речь идет о неких корпоративных правилах о скажем качестве кода и т.п.?

нет, я имел в своем сообщении прежде всего не технические моменты!
под объективными метриками я привел пример с инициативностью, а термин пошел от моего давнего сообщения Re[6]: C# job in Spb

Автор: Valerio
Дата: 15.02.05

не путать с метриками о которых проповедует Gaperton

Кстати правила на качество кода — трудновато ввести будет
а вот на стиль кодирования — да, полезно (но не всегда оправданно штрафовать за несоблюдение)

DAN>Что это даст с точки зрения мотивации?
это даст как я выше заметил уверенность что ты работаешь в компании профи, а это стоит дорогого ИМХО. соотв неявно это даст мотивацию и поможет избежать ужасов в заглавии ветки

VAB>>- провести аттестацию можно и в 30 мин на листике бумаги глаз на глаз — не обязательно загружать этой волокитой HR отдел особенно если его нет и весь коллектив 2 человека .
DAN>По хорошему нужно строить career plan, иначе опять возможна демотивация: "я такой крутой по аттестатам, а мне денег нифига не платят/фигней всякой заставляют заниматься".
есс-но человек который удовлетворил условиям Individual expectation agreement (у нас так это называется) рассчитывает что это найдет материальное выражение — и об этом я уже писал, это само сабой иначе не будет работать. просто одно дело когда нач-к в зависимости от своего настроения выдает бонусы и когда ты сам можешь прийти и сказать — вот бумага, вот я все сделал — получите, распишитесь. Если нач-к это знает, он сам ответственнее будет с людьми себя вести, иначе сотрудник легко покажет все то же самое боссу повыше и тут уже не будет ситуации когда слово сотрудника против слова ПМа перед боссом повыше, который априори склонен доверять все же ПМу.

DAN>Т.е. аттестация ради самой аттестации имхо бессмыслена.
не спорю

DAN>Что касается career plan-а: к сожалению тоже не все гладко: так или иначе развитие сотрудника зависит от развития команды в целом и в результате запросто можно человека "обломать" — не дали денег заказчики, продукт продается хуже чем ожидалось и т.п. Может быть более разумных/достаточным будет: появилась потребность в новом начальнике — отобрал самого перспективного/подходящего — его назначил.

"не дали денег заказчики" — это не должно вообще никак волновать кого-то из тех спецов, это работа СЕО и ответственных лиц добывать деньги, нельзя сказать разработчику "извини братан, денег нет ибо заказчики не заплатили, поэтому ЗП я тебе не дам всю а только через полгода если получится отдам половину". Человек подписавший контракт должен по нему получить деньги и не решать чужие проблемы, тем более что в такой ситуации производительность только падает.

VAB>>В любом случае с такой распиской жить проще потом и легко разобраться в случае конфликтов, а не опереровать формулировками "я помню мне сказали что..." и "я такого не говорил а имел ввиду что...".
DAN>Опять, каким образом это повысит мотивацию?
выше

VAB>>Цена вопроса гораздо меньше чем долгое убеждение штата компании на политзанятиях, что они работают в крутой фирме и как они должны быть счастливы что строят Нью-Васюки — это по определению более долго, ибо чтобы закрепилось в мозгах требует поторения не менее 100 раз в неделю
DAN>Имхо на ИТ-people это вообще не действует склад характера не тот.
действует хоть и вызывает отторжение ИТ-people
тем не менее молодых меньше не становится и пока они это пройдут кто-то на них покатается... а иногда ситуации безвыходные, что вынуждены скрепя забуами матерые профи соглашаться. Это жизнь. но это не принесет стабильности — нормальные кадры утекут как тока так сразу в нормальное место

VAB>>- корпоративный ящик не требует вложений. Обязанность по его просматриванию может совмещаться кем-то, а в совсем маленьких проектах просто предложения имеют свойство забываться после озвучивания соседу — лучше привить практику оформления всех идей либо на ящик либо приспособить систему хоть контроля версий — иметь документ ideas.doc и в него коммиттать появляющееся... денег не надо опять
DAN>Делали общий анонимный ящик — за год работы ни одного сообщения

В Новософте (немного о Новософте у меня тут: Re[5]: О роли HR

Автор: Valerio
Дата: 06.10.04

) это работало, правда после усилий описанных выше — по прозрачности запросов и гарантированном времени отклика со стороны ответственных лиц.

DAN>ideas.doc для каждого проекта существует, но там больше фичи для самого проекта, чем общие пожелания по процессу.
DAN>Опять же эти предложения удобней в bugtracking системе вести.
да, приспособить можно что угодно, я вариант с CVS просто первый пришедший в голову из простых привел

VAB>>- в итоге самое главное — заинтересовать материально и вот сюда нужны деньги. инвестиции тут помогают пережить трудное время на старте, ибо когда проетк финансируется из своего кармана — тут и жена одного из партнеров может оказаться самым большим неучтенным риском... такое сложнее просчитывается чем что либо еще
DAN>Вот! И это ключевое имхо! К сожалению зарплата среднего разработчика все таки слишком далека чтобы думать о чем-то еще. В смысле чтобы зарплата не была решающим аргументов. Следовательно, стоит ли затевать весь сыр бор, если соседняя контора поставив на 20% бОльшую зарплату заберет разработчика с потрохами? Хотя то что вы выше перечислили скорее улучшает процесс, нежели мотивирует.
выше

DAN>Вот с менеджерами нужен уже более тонкий подход...
суть та же

VAB>>Сейчас я вижу что оптимистичный вариант развития компании планирующей не стать однодневкой вряд ли возможен без серьезных инвестиций (хотя бы на ЗП выше средней по отрасли на срок проекта * на Pi для аккумулирования лучших кадров, которые как известно решают все).
DAN>Скорее тут лучше работает (да и на практике чаще встречается) подход когда начинает работать небольшая команда профессионалов на перспективу: станем большой конторой, будем все в шоколаде.
все так начинают\говорят. но когда начинается шоколад часто оказывается что один работал больше всех, а его не оценили и т.п. Я просто пишу все это для того чтобы такие ситуации было легче разруливать — для этого загодя приготовиться.

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

DAN>Я собственно что хотел сказать всеми этими постами: нет смысла активизироваться на мотивации девелоперов если процесс не поставлен, нет заказчика/идеи.
если нет закачика\идеи = нет работы, то действительно говорить не о чем

DAN>Т.е. хорошо мотивированный девелопер работающий на коленке без требований, без багтрекинга, планов, SCM систем и т.п. будет все равно работать хуже чем человек работающий за деньги но с хорошо поставленным процессом. И вся мотивация у него испарится когда он будет вручную мержить код нескольких человек или получит по башке от менеджера за то что забыл пофиксить баг, о котором тот ему вчера в курилке говорил
насчет хуже — не факт, достаточно почитать мнение Максима по поводу драйверных проектов где излишняя бюрократия не всегда оправданна (согласен я тут с ним) просто в силу специфики нашей области. но и вещи типа системы контроля версий и качества все же должны быть у любого даже работающего в одиночку профи (здесь профи=зарабатывающий этим делом на жизнь, а не гуру).

DAN>А по моему хоть и небогатому, но все же опыту большинство компаний даже находящихся в москве похвастать хорошо поставленным процессом не могут. СММ3 компании по пальцам пересчитать можно. А уж СММ5 по моему вообще всего две компании — Luxsoft и CQG.
процесс ради процесса... им это нужно самое глаавное потому что они уже вышли на этот уровень и им маркетинг надо наводить, я думаю.

DAN>Т.е. проблема психологической мотивации для большинства компаний преждевременна или не имеет большого значения.
не согласен Предлагаю завернуть на пост Максима в начало ветки: Психологические проблемы мотивации девелоперов.

Автор: Maxim S. Shatskih
Дата: 22.08.05

откуда это берется если есть практически в каждой компании\команде? И почему дажеко не везде с этим вообще пытаются бороться, а не то что справляются?

Здравствуйте, AndreyFedotov, Вы писали:

AF> Кроме того частенько бывает ситуация, что менеджер просто не видит "мелких" деталей, которые возникают при реализации его гениальных замыслов и не понимает "что там делать столько времени"

Это точно...

AF>Я думаю, что проблема несколько в другом. А именно в том, что большинство учебников по экономике, бизнесу, ПМ рассматривают людей просто как некие абстарктные ресурсы. При этом как правило даже забывают упомянуть, что это всего лишь одна из точек зрения — некая абстрактная модель, подобная математической. И что существуют другие аспекты и точки зрения, которые так же стоит учитывать. В результате многие менеджеры (разных уровней от низшего до самого верха) смотрят на подчинёных или людей уровнем ниже именно так — как на мебель или оборудование. Поскольку подобное отношение рождает адекватную реакцию — появляются многочисленные схемы мотивации, которые (если исследовать предположения, часто неосознанные, которые за ними стоят) изначально предполагают наличие у человека злого умысла — не желание работать или желание обманывать работодателя. Ну и что из этого может выйти?

ППКС.

Моя неприязнь к "научному прожект-менеджменту" — основана вот именно на этом.

AF>Если в кратце — то работать с людьми — показывать им связь между их действиями и деньгами

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

Подачками их не мотивируешь. Подачками мотивируется психология рвачества, которая хороша, например, у сэйлов, но не всегда хороша у девелопера.

AF>Однако тут вполне может быть вариант a) — когда код на 6+, но на два месяца позже срока... Тут нужно сначала похвалить за великолепную работу, а потом отдельно оценить её последствия.

То есть? Руководитель два месяца не интересовался статусом?

AF> Однако есть и другой путь. Он состоит в том, что бы доводить до людей цели, которые они преследуют, учитывать их мнение и вовлекать в процесс принятия решений.

Я бы сказал так. Нужна трехзвенная архитектура. Бизнес-руководитель (в мелкой компании это гендиректор). Технический руководитель, который есть профессиональный девелопер по опыту работу, но способен мыслить бизнес-категориями. И сами девелоперы.

Роль "среднего звена" — внести элемент бизнес-ориентации в работу девелоперов, чтобы не башни из слоновой кости городили, а делали то, что реально надо.

DAN>Вопрос к Валерию и к общественности: а окупит ли себя введение всего перечисленного в предыдущем сообщении? Или не получится ли так, что после внедрения всех этих вкусностей не останется денег на хорошую зарплату разработчикам, из-за чего они все разбегутся по другим конторам? И не получится ли так, что пустив эти доп. средства на повышение зарплаты выше уровня рынка в компанию при активности HR-ов постепенно стекутся лучшие люди, из-за чего контора станет работать на порядок лучше чем высокомотивированные середняки?

Прочитал предложение Валерия. Мое предложение немного проще. Нужно разделение на "ветеранов" и на "новичков". "Ветераны" должны оплачиваться выше рыночного. "Новички" же — рыночно, а то и ниже, но должен быть некий шанс попасть в "ветераны". Это снизит "смотрение налево", ибо есть шансы для роста здесь. Особенно с ростом компании.

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

Как мне кажется, эта нехитрая схема очень хорошо работает.

VAB>- провести аттестацию можно и в 30 мин на листике бумаги глаз на глаз — не

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

Аттестация не расматривается ни как мотиватор, ни как какой бы то ни было еще инструмент.

И еще. Насчет объективных метрик. Если эта метрика становится сложной — человек перестает понимать интуитивно, что именно и как именно влияет на его зарплату, и потому как мотиватор она работать перестает.

B>Мне кажется, что во моногом все определяется личными качествами руководителя. Есть харизма/нет харизмы,

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

B>Гуляя с ребенком, я смотрю на детей, — выделяются явные "заводилы", "тихони", "плаксы" и т.д..

А еще есть и те, что испытывают отвращение к любым "заводилам". Как правило такие люди оседают в коллективах, где нет "заводил". Если же он есть — то данный человек становится "антилидером", а "антилидер" в персонале компании — вредно.

B>Многие мои дни проходят примерно так: 1) прийти на работу; 2) проверить почту, полазить по сети и т.д.; 3) решить что я мог бы пообедать прежде чем начать работать; 4) вернуться с обеда; 5) проверить почту, полазить по сети и т.д.; 6) окончательно решить что пора взяться за работу; 7) проверить почту, полазить по сети и т.д.; 8) опять решить что, действительно пора поработать; 9) запустить чёртов редактор; и 10) безостановочно писать код, пока я не осознаю что уже полвосьмого. "[/i]

Ага, бывает у многих.

_D>1. Опытному девелоперу поручают рутиную работу, которую может сделать любой менее опытный девелопер.

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

_D>2. Девелоперу поручают работу, сложность которой, значительно превышает его квалификацию.

Так это ж челлендж! Могучий мотиватор! Развитие! вот только со сроками тут нельзя давить.

_D>3. Систематическое неукладывание в сроки.

Ага. Депрессию наводит (и как следствие — лень и паралич активности). Причем не всегда понятно, кто виноват — девелопер, который на форумах общается, в ЖЖ и на Удафф.Ком или же менеджер, который нереально занизил сроки.

_D>4. Сворачивание работ по направлению, которое было интересно девелоперу и которому было уделено значительное время.

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

DAN>Решения: выявлять и беседовать (оговорка: если тем не менее работает 5х8 — все хорошо, пусть сидит себе в ЖЖ дальше). Заставлять оставаться по вечерам и субботам чтобы успеть по планам.

Качество кода падает.

Пример. Анисимович в Abbyy. Очень жесткий руководитель. Но он всегда был категорически против переработки сотрудников, работы в выходные и по ночам. "Написанный в таких условиях код потом невозможно понять, и он пойдет на выбор" — говорил он.

DAN>Но быть не в потоке можно тоже по разному: можно книжки по ИТ читать, можно RSDN (опять же много полезного), а можно например на love.mail.ru

ооо! это да. Я не знаю большей помойки в русской сети, чем этот сайт.

S>склонение руководства к использованию техологий, которые либо бесполезны в данном проекте и для фирмы, либо вообще вредны, однако позволяют конкретному девелоперу за счет оплаченного рабочего времени изучить "модную" технологию. основная ель — пополнение собстенного "портфолио", позволяющего найти более высокооплачиваемую работу.

О! Это любимое просто! Особенно в этом вопросе OLE DB прославилось

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

Впрочем, этим занимаются не только девелоперы, но и выходцы из, например, ПиАра и околоITшной журналистики. Они судят по новым технологиям — по глянцевым журналам.

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

A>Для того чтобы не игнорировали нужно правильно доносить. А если человек игнорирует — значит ему наплевать на компанию, а соответсвенно сотрудников, в которой он работает. Он одиночка и не командный игрок! Вы считаете это нормальным?

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

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