Взаимоотношения в коллективе разработчиков ПО: ложь, предательство и зависть

Предисловие

В данном документе приведен расширенный и дополненный конспект лекции, которую я прочитал для групп 589-1 и 589-2 (кафедра КСУП, ТУСУР) 23 мая 2012 года. Вообще, последние года три я не писал конспектов лекций. Но для данной лекции конспект мне был необходим, что бы не забыть все, что хотел сказать. Позже я его немного дополнил и выложил сюда – в свой блог.

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

Update: эта лекция была использована также в СБИ для широкого круга слушателей в СБИ “Дружба” 9 апреля 2013 года. Поэтому к ней появились картинки здесь.

ИШ

Три пули мне отлили до утра
Мои друзья – они вчера так звались.
Три пули: ложь, предательство и зависть.
Ирина Орищенко, Три пули.
Текст песни полностью.

Зависть

Откуда берется зависть

Ситуация 1

Вася получает зп 40тр, а Коля выполняя такую же работу, получает 45тр. Вася завидует Коле.

 Почему зп может различаться. Вариантов много. Например:

  • Коля выполняет ту же самую работу но качественнее

  • Коля выполняет ту же работу но быстрее

  • Начальство считает, что Коля выполняет работу быстрее и/или качественнее.

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

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

  • У Коли “более тесные” отношения с начальством. Хороший пример.

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

Как можно избежать зависти

Вариант 1. Скрывать размер зарплат

В этом случае, Вася (теоретически) просто не узнает зп Коли и поэтому, у него не будет поводов для зависти.

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

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

Вариант 2. Вводить формальные критерии.

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

Мое убеждение – все критерии ложны. Как только появляются формальные критерии, работник начинает работать на критерии (на табличку), а не на реальный результат.

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

Есть только одно неоспоримое мерило — ответственность. Чем выше ответственность за принимаемые решения, тем выше зп. Но в реальности, на текущий момент у ведущих программистов зачастую зарплата выше, чем у менеджера. Хотя степень ответственности чаще всего выше все же у менеджера.

Предательство

Ситуация 2.

Проект провалился. Извечный русский вопрос — кто виноват?

Например, виноват Вася. Но Вася близкий друг ПМ. Что скажет ПМ о виноватом в проекте?

Если скажет «Вася» – Вася потеряет работы или премию, ПМ предал дружбу.

Если скажет «Я» – сам потеряет работу или премию.

Если уж Вася на самом деле балласт в команде, то ПМ должен был избавиться от Васи еще в первой трети проекта. Но это все равно будет предательство дружбы.

На самом деле ответ простой. Если проект успешен, то это успех всей команды, а если проект провален, то в этом виноват, только ПМ.

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

Ситуация 3

Разработчик Вася утром, примерно, в 9:55 подходит к техническом писателю, которого зовут, пускай для определенности, Катя. И говорит:

– Катя, я тебе вчера вечером документик выслал на полторы странички на перевод. Когда сделаешь?

Казалось-бы. Нормальная рабочая просьба. Но разработчик нарвался на скандал.

– Что вы тут ходите все с утра пораньше!? Я еще почту не всю разобрала! (формально в этой компании до 10:00 нужно разбирать почту, время 9:55). Разберу — напишу.

Ну Вася в непонятках ушел к себе.

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

– ОК, решил разработчик, подойду через пару часов.

Через час Катя сама прибежала с шоколадкой и извинениями. Чтобы Вы думали, что стало, по ее словам, причиной? Она утром поссорилась со своим МЧ, а туалетная вода, которой пользуется Вася, совершенно случайно оказалась точно такая же как у ее МЧ… То есть она среагировала на запах! Ну тем самым она подтвердила предположения Васи.

А теперь представьте, что в подобной ситуации Вася был бы, на самом деле, МЧ Кати. Какая тут эффективная работа может быть?!!!

А если Катя, при этом ПМ, а Вася разработчик?! Тогда, если Катя поступит как нормальный ПМ и выбросит Васю из проекта в первой трети, то это будет предательство на всю жизнь. Поэтому, лучше не надо.

Но еще раз. Исключения бывают.

Ложь

Ситуация 4

В понедельник ПМ дал разработчику задачу: сделать сериализацию и десериализацию компонента в/из файл(а)

В среду ПМ спрашивает разработчика: “Как успехи?”

Разраб: “Все отлично, основное работает, осталось немного мелочей”.

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

В пятницу после обеда, ПМ подходит к разрабу и спрашивает: “Нет ли у тебя не закоммиченных изменений – мы будем бранчить транк для новой версии?”

Вариант 1.

Разраб: “Тут такое дело… Ну в общем… Я столкнулся с неожиданными сложностями. В общем, я не успеваю сегодня сделать. Давай я в отдельной ветке доделаю”.

Что не так? Те изменения, которые будут сделаны в рамках новой функциональности затронут все классы компонента, в первую очередь те, в которых разработчик должен был сделать сериализацию. Если начать делать новую функциональность и сериализацию в разных ветках, то потом смержить их будет очень непросто. Фактически, сериализацию для новой версии компонент нужно будет делать заново. Стопроцентной гарантии, что сериализация новой версии компонент будет сделана в точности совместимой со старой версией компонент нет. Это значит, что тесты через сохраненный файл сделать невозможно. А значит нет гарантии, что существующая функциональность не будет сломана при разработке новой. А это значит, что сейчас стартовать изменения нельзя. И старт проекта, сдача которого была намечена через 4 недели, откладывается. И тестироващики и QAD, которые должны были в понедельник заняться тестированием через файлы будут сидеть без работы (ну на самом деле, тестировщикам всегда есть чем заняться, потому, что их, как правило, всегда не хватает). И разработчик, который должен был заняться переделкой компонент тоже будет заниматься всякой ерундой. Все это в голове ПМ пролетело за 2 секунды, пока он хотел задушить разработчика, не предупредившего его о том, что у него есть проблемы в реализации задачи еще в среду. Остановило ПМ только пронесшиеся в голове следующие 10 лет: похороны разработчика, суд и отсидка.

Вариант 2.

“Неа, у меня все закоммиченно”.

Это еще хуже, потому что ПМ отбранчил ветку. А в понедельник или во вторник, когда в новой ветке уже все сломали, разраб. внезапно сообщает, что он закоммитил в транк сериализацию или “небольшие последние правки” к сериализации. То есть, уже по факту, вариантов нет – придется для новой версии компонента делать сериализацию с нуля, а неделя, которую разраб, якобы, потратил на реализацию сериализации можно смело внести в пассив – деньги потрачены, сделано ноль. Я бы, возможно, плюнул на последующие 10 лет… (наверное, поэтому, я не люблю быть ПМ :)).

Почему разработчик врал?

Чаще всего: ответом будет:

  • в среду он соврал скорее всего потому, что с понедельника по четверг он все еще доделывал предыдущую задачу, и не хотел показаться тормозом (что он медленно разрабатывает), а то вдруг ему премию урежут;

  • а в пятницу он соврал (это при варианте 2), потому что… да потому же, собственно говоря.

Как нужно было поступить разработчику? Нужно было сказать правду о том, что предыдущая задача не сделана еще в понедельник (или даже на прошлой неделе). Если есть не сделанная задача, то предложить менеджеру расставить приоритеты. Что делать вперед, что потом.

Ситуация 5

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

Что подумает заказчик?

Скорее всего, он очень быстро откажется от услуг вашей компании. Ибо хуже всего — это вранье. Лучше вообще не врать. Если уже нет объективной причины, лучше не называть никаких причин. Просто «нет» и все. Или сказать — внутренние проблемы. Адекватный заказчик поймет, что у вас проблемы с управлением.

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

Если Вам не нравится слово «отмазка» – не надо выдумывать какие-то несуществующие причины, А то ведь, эти причины могут внезапно исчезнуть. И совсем не факт, что менеджеру от этого станет лучше. Например, ПМ сказал заказчику, что у него не хватает ресурсов. А на утро получает от заказчика письмо, что есть команда в Индии из 20 человек и они готовы получать задачи. Легче ли от этого будет ПМ? Вряд-ли.

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

Взаимопонимание

Ситуация 6 (вариант ситуации 4)

ПМ подходит к Васе и спрашивает прогресс по задаче сериализации.

Вася отвечает: “Да там все нормально, основное сделал, осталось несколько мелочей”.

Почему Вася не услышал менеджера?

Причина 1.

А у Васи в Хроме 10 закладок exist.ru или сайт знакомств. Или поисковый запрос: “чем лечить…”. Или у Кати в поисковике “Эффективность пастинора через 36 часов”… Люди просто заняты своими делами, и им нужно просто скорее от ПМ отмахнуться, потому что у них личные проблемы. То есть, они просто действительно не слышат.

Что делать? Подойти еще раз.

Причина 2.

О чем вам говорит вот такие строки:

…Как молью изъеден я сплином…
Посыпьте меня нафталином,
Сложите в сундук и поставьте меня на чердак,
Пока не наступит весна.

Что это? Группа Сплин? На самом деле студенты здесь испортили мне шутку. Я знал, что среди них есть поклонники группы Сплин, и был уверен, что они сразу узнают эти строки. Но оказалось, что они не достаточно хорошо знают историю и дискографию своей любимой группы. Хотя их можно простить. Эта песня написана в 1992-м году. Это первый альбом группы Сплин, и собственно, с этой песни появилось название этой группы. А эти студенты только в 1992-м году родились.

Но для знатоков поэзии серебрянного века — это Саша Черный.

Кстати, еще о различии в восприятии.

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

Ситуация 7

ПМ говорит:

  • Нужно сделать бранч от транка.

  • Нужно сделать сериализацию.

  • Нужно сделать сериализацию до бранча от транка.

Как это может воспринимать Вася: “Кому то что-то нужно сделать, вот пусть кто-то это что-то и делает.”

Разными людьми мир воспринимается по-разному. Вася просто ПМ не понял. Что делать? Подойти еще раз. Как ПМ должен говорить:

  • Петя ты в следующий понедельник будешь делать бранч от транка и там делать новую функциональность

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

Leave a Reply