Если вы спорите с идиотом, не исключено, что в это время то же самое делает и он. (С)
Недавно прочитал два поста: этот и этот. В них с разных сторон описывается конфликт между разработчиком, потратившим время на выполнение 95% задачи, и работодателем, не желающим оплачивать неполноценный результат.
Некоторое время назад я попал в похожую ситуацию (на стороне работника) и у меня получилось успешно разрешить ее, причем таким образом, что все остались довольны: и работодатель, и я.
=============
Нет, я ни коим образом не хочу назвать идиотами авторов или комментаторов этих постов. Имеется в виду упорное нежелание уступить собеседнику, даже во вред самому себе.
Но прежде, чем рассказывать о решении моей проблемы, я хотел бы обратить внимание на несколько вопросов, связанных больше с психологией, чем с разработкой ПО.
Не буду объяснять, почему так происходит. Предлагаю принять это за аксиому. Если кому-то интересно, рекомендую прочитать эту книгу.
Теперь попробуем применить это к разработке ПО.
Проблема заключается в несвоевременной реакции на ситуацию, когда время (для заказчика == деньги, для исполнителя == труд) уже потеряно и нельзя его вернуть. В этом случае, каждая сторона старается принудить другую сторону взять на себя возникшие при этом издержки (заказчик пытается завтавить исполнителя бесплатно выполнить остаток работы, а исполнитель пытается заставить заказчика заплатить за работу, которая не принесла заказчику пользы).
При этом в большинстве случаев, не понятно, кто виноват в потере времени: либо дело во внешних причинах, либо виноваты оба: и работодатель, и исполнитель в состоянии были предотвратить потерю времени, но предпочли этого не делать, надеясь, что им удастся свалить ответственность на противоположную сторону. (Согласитесь, в случае, когда видна явная вина одного из участников, никаких споров не возникнет.)
Если попробовать применить правила, которые мы написали выше, то станет видно, что прямая борьба ни к чему не приведет: проигравшими окажутся обе стороны (одна из сторон потеряет деньги (или труд, если речь идет об исполнителе) + обе стороны потеряют время и нервы, затраченные на спор). Ни одна из сторон не может победить, переведя конфликт в «адекватный спор», потому как обе стороны находятся в равном положении (см. выше) и они не смогут привести логичных аргументов, доказывающих свою правоту.
Единственный выход — не допускать этой невосполнимой потери (для работодателя — это время, потраченное на не нужные ему задачи, для исполнителя — это неоплаченное время).
Заранее составленное ТЗ позволяет уменьшить потерю времени. ТЗ дает полный список нужных работодателю задач (гарантия, что работа исполнителя приносит пользу заказчику + гарантия, что эти задачи работодатель готов оплатить). К сожалению, заранее составить ТЗ очень сложно, т.к. нужно предусмотреть очень много деталей. Кроме того, иногда просто невозможно составить ТЗ заранее, потому как задачи меняются в процессе разработки (давайте, не будем себя обманывать: не меняются только очень маленькие задачи).
Выход: нужно постоянно контролировать процесс разработки, поддерживать хорошую «обратную связь» (от заказчика к исполнителю). Это позволит быстро и адекватно реагировать на ситуацию и позволит обеим сторонам сразу замечать, когда время тратится впустую.
Адекватно реагировать на ситуацию — признавать свои ошибки (и исправлять их), справедливо и аргументированно указывать на ошибки собеседника, учитывать чужие проблемы и вместе стараться разрешить их наилучшим образом для обеих сторон.
Собственно, описание моей ситуации:
Долгое время работал за фиксированную зарплату (удаленная работа, трудозатраты рассчитывали исходя из того, что я работаю 2 часа в день). Жесткого контроля задач не было. Мог свободно менять свой план работ в целях выполнения наиболее важных для конторы задач. Часто занимался непрофильной работой: администрированием сервера, внедрением, технической поддержкой пользователей.
Когда начался кризис, директор лично захотел контролировать каждого разработчика (благо разработчиков мало, потому как основное направление деятельности конторы не связано с разработкой ПО). Каждый месяц составлялся план работ и появилось правило: зарплата не выплачивается, пока не сделано 100% задач.
Первое время режим работы оставался старый, регулярно часть работы оставалась не выполненной и это привело к большому конфликту между директором и программистами. В конце месяца директор говорил: «доделайте задачи и получите деньги». Программисты говорили: «мы не будем работать, пока не получим зарплату».
На что ушло время, сложно было определить.
1 вариант: на мелкие не учитываемые в плане задачи.
2 вариант: программист плохо организовал свой труд и часть времени потратил впустую (например, читал форумы).
Насколько сильно повлияла на ситуацию каждая из этих причин, отследить практически невозможно.
Я вышел из сложившейся ситуации следующим образом:
На данный момент все довольны: директор доволен тем, что вовремя выполняется 100% задач, а я доволен тем, что я занимаюсь интересной работой в стандартном режиме и без проблем получаю заработанные деньги.
Попробую подвести итог
Конфликт работодателя и исполнителя возник не из за того, что кто-то из них плохой/нечестный/недобросовестный/идиот (нужное подчеркнуть), а потому, что оба не смогли правильно организовать процесс разработки (или не захотели напрягаться).
Сделать это мог каждый из них.
Ну и… если хочешь, чтобы что-то было сделано — делай это сам.
Всем спасибо за внимание. Если у кого-то есть вопросы — буду рад на них ответить.
Недавно прочитал два поста: этот и этот. В них с разных сторон описывается конфликт между разработчиком, потратившим время на выполнение 95% задачи, и работодателем, не желающим оплачивать неполноценный результат.
Некоторое время назад я попал в похожую ситуацию (на стороне работника) и у меня получилось успешно разрешить ее, причем таким образом, что все остались довольны: и работодатель, и я.
=============
Нет, я ни коим образом не хочу назвать идиотами авторов или комментаторов этих постов. Имеется в виду упорное нежелание уступить собеседнику, даже во вред самому себе.
Но прежде, чем рассказывать о решении моей проблемы, я хотел бы обратить внимание на несколько вопросов, связанных больше с психологией, чем с разработкой ПО.
- Каждый человек любит, когда с ним соглашаются и начинает противодействовать, когда с ним не соглашаются.
- Если нужно, чтобы человек что-то сделал — нужно, чтобы он делал это осознанно и по собственной воле.
- Чтобы победить в споре, ни в коем случае нельзя перечить человеку. Нужно постараться вывести разговор на уровень обсуждения логичных и аргументированных утверждений.
Не буду объяснять, почему так происходит. Предлагаю принять это за аксиому. Если кому-то интересно, рекомендую прочитать эту книгу.
Теперь попробуем применить это к разработке ПО.
Проблема заключается в несвоевременной реакции на ситуацию, когда время (для заказчика == деньги, для исполнителя == труд) уже потеряно и нельзя его вернуть. В этом случае, каждая сторона старается принудить другую сторону взять на себя возникшие при этом издержки (заказчик пытается завтавить исполнителя бесплатно выполнить остаток работы, а исполнитель пытается заставить заказчика заплатить за работу, которая не принесла заказчику пользы).
При этом в большинстве случаев, не понятно, кто виноват в потере времени: либо дело во внешних причинах, либо виноваты оба: и работодатель, и исполнитель в состоянии были предотвратить потерю времени, но предпочли этого не делать, надеясь, что им удастся свалить ответственность на противоположную сторону. (Согласитесь, в случае, когда видна явная вина одного из участников, никаких споров не возникнет.)
Если попробовать применить правила, которые мы написали выше, то станет видно, что прямая борьба ни к чему не приведет: проигравшими окажутся обе стороны (одна из сторон потеряет деньги (или труд, если речь идет об исполнителе) + обе стороны потеряют время и нервы, затраченные на спор). Ни одна из сторон не может победить, переведя конфликт в «адекватный спор», потому как обе стороны находятся в равном положении (см. выше) и они не смогут привести логичных аргументов, доказывающих свою правоту.
Единственный выход — не допускать этой невосполнимой потери (для работодателя — это время, потраченное на не нужные ему задачи, для исполнителя — это неоплаченное время).
Заранее составленное ТЗ позволяет уменьшить потерю времени. ТЗ дает полный список нужных работодателю задач (гарантия, что работа исполнителя приносит пользу заказчику + гарантия, что эти задачи работодатель готов оплатить). К сожалению, заранее составить ТЗ очень сложно, т.к. нужно предусмотреть очень много деталей. Кроме того, иногда просто невозможно составить ТЗ заранее, потому как задачи меняются в процессе разработки (давайте, не будем себя обманывать: не меняются только очень маленькие задачи).
Выход: нужно постоянно контролировать процесс разработки, поддерживать хорошую «обратную связь» (от заказчика к исполнителю). Это позволит быстро и адекватно реагировать на ситуацию и позволит обеим сторонам сразу замечать, когда время тратится впустую.
Адекватно реагировать на ситуацию — признавать свои ошибки (и исправлять их), справедливо и аргументированно указывать на ошибки собеседника, учитывать чужие проблемы и вместе стараться разрешить их наилучшим образом для обеих сторон.
Собственно, описание моей ситуации:
Долгое время работал за фиксированную зарплату (удаленная работа, трудозатраты рассчитывали исходя из того, что я работаю 2 часа в день). Жесткого контроля задач не было. Мог свободно менять свой план работ в целях выполнения наиболее важных для конторы задач. Часто занимался непрофильной работой: администрированием сервера, внедрением, технической поддержкой пользователей.
Когда начался кризис, директор лично захотел контролировать каждого разработчика (благо разработчиков мало, потому как основное направление деятельности конторы не связано с разработкой ПО). Каждый месяц составлялся план работ и появилось правило: зарплата не выплачивается, пока не сделано 100% задач.
Первое время режим работы оставался старый, регулярно часть работы оставалась не выполненной и это привело к большому конфликту между директором и программистами. В конце месяца директор говорил: «доделайте задачи и получите деньги». Программисты говорили: «мы не будем работать, пока не получим зарплату».
На что ушло время, сложно было определить.
1 вариант: на мелкие не учитываемые в плане задачи.
2 вариант: программист плохо организовал свой труд и часть времени потратил впустую (например, читал форумы).
Насколько сильно повлияла на ситуацию каждая из этих причин, отследить практически невозможно.
Я вышел из сложившейся ситуации следующим образом:
- Обсудил с директором текущий план работ: какие задачи выполнены, какие еще осталось выполнить и в каком объеме (кстати, это обсуждение заняло 3.5 часа, но при этом прошло довольно спокойно, несмотря на предшествующие ему разговоры на повышенных тонах). Я пообещал бесплатно доделать эти задачи в следующем месяце, после чего была без проблем выплачена зарплата за текущий месяц.
- Составил ОЧЕНЬ подробное описание того, как я собираюсь выполнять поставленные задачи (вплоть до того, что описал, какие действия происходят при нажатии каждой кнопки) и отправил это директору на утверждение. По сути это то же самое ТЗ. Вполне естественно, что директор сам не будет его писать. Также естественно, что он не понимает смысла платить за написание ТЗ 800$ отдельному человеку. Составленное мною ТЗ не соответствовало стандартам оформления, но, главное, оно отражало список задач. Я потратил на него очень мало времени (около 2 ч.)
- Все задачи перед назначением на меня проходили через директора. Так он смог контролировать выполняемые мной задачи, а я смог уберечься от второстепенных и не нужных задач (т.е. от таких, выполнение которых привело бы к потере времени)
- С возникающими внеплановыми задачами поступили следующим образом:
а) если задача непрофильная, я отказывался от ее выполнения (вполне естественно: мое время ограничено + задача не является тем, что я умею хорошо делать). Обычно директор без проблем соглашался поручить ее кому-то другому.
б) если задача все таки не может быть выполнена без моего участия, то сразу согласовывается изменение утвержденного ранее плана работ (определяются наименее важные задачи, имеющие в сумме такой же объем и переносятся на следующий месяц).
в) если нельзя выкинуть из плана нужное количество задач, то внеурочное время оплачивается в двойном размере (как и должна оплачиваться внеурочная работа). Внеурочная работа оплачивалась по часам по факту выполнения с условием предоставления очень подробного отчета, сколько и на что затрачено времени (с детализацией до 30 минут).
- Я установил себе правило: оповещать обо всем директора настолько рано, насколько это возможно. «Обо всем» — в основном, это о выполнении задач, а также об изменении предполагаемых сроков выполнения задач (как в большую, так и в меньшую сторону с указанием причины).
На данный момент все довольны: директор доволен тем, что вовремя выполняется 100% задач, а я доволен тем, что я занимаюсь интересной работой в стандартном режиме и без проблем получаю заработанные деньги.
Попробую подвести итог
Конфликт работодателя и исполнителя возник не из за того, что кто-то из них плохой/нечестный/недобросовестный/идиот (нужное подчеркнуть), а потому, что оба не смогли правильно организовать процесс разработки (или не захотели напрягаться).
Сделать это мог каждый из них.
Ну и… если хочешь, чтобы что-то было сделано — делай это сам.
Всем спасибо за внимание. Если у кого-то есть вопросы — буду рад на них ответить.
