четверг, 31 марта 2011 г.

Бонусы, бонусы, бонусы....

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

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

Упростим сценарий до следующего:

  • У нас есть команда - 3 разработчика, 1 тестировщик и 1 менеджер. Ну вообщем классический расклад с классическим процессом, классические проблемы и классические ответственности.
  • Поставили цель - бонус $2000 на команду, если скажем через 1 месяц парни попадут в свои планы и клиент будет удовлетворен.

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

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

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

К чему это все.
Такие эксперименты стоит проводить ? Да! Однозначно да!
А проблемы будут возникать? Да! Однозначно да!
Это хорошо или плохо? Да на самом деле это уже не важно. Команда, это такой-же организм как и каждый человек в ней, со своими проблемами, желаниями и целями. Каждого из нас учит опыт (сын ошибок трудных). Так-же и с командой.

1 комментарий:

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

    ИМХО, тут нужно кроме анализа ситуации нужно проводить отдельный анализ поведения-коммуникаций. Причем во втором случае с четким запретом разборок "по сути".

    ОтветитьУдалить