«21 КЕЙС ОТ ПРОЕКТА HAPPY-PM.COM В августе 2009 года я предложил для расмотрения читателям забавный кейс с неосторожным автоответчиком на письма, который мог стоить автору автооответчика каких-нибудь страшных ...»

Система метрик верная – используется в компании не первый год. Решение о зарплате, большей чем в 1.5 раза тоже верное – надо же было команду Олега заполучить. Просто Олегу забыли намекнуть, что у них теперь зарплаты больше, чем в среднем по корпорации. Но на уровень выше вынести проблему можно попробовать, да. Надо только придумать, почему это проблема. Об этом ниже, в резюме.

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

Абсолютно точно.

2 coredeveloper 1) Вася и Петя повышения по ЗП не получают, но придется проводить сеансы психотерапии и гипноза, с целью убеждения в том, что они и так в “шоколаде”. Тут поможет лёгкий намёк на финансовое превосходство перед другими. Т.к. многим не важно сколько они получаю – а важно получать больше остальных.

Хорошее замечание, на самом деле. Когда человек узнает, что получает в 1.5 раза больше других, то ему становится так приятно, что и повышения не надо. Но наш опрос чего-то показывает обратное: http://www.happy-pm.com/blog/?p=2572 Гипнотизировать будет тяжело. Люди не получат того, что они ожидали.

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

5% тех, кому не повышать, все равно надо будет найти.

3) И самое главное поднять вопрос о пересмотре метрик. Т.е. текущие метрики не отражают возникшую ситуацию. И я бы поговорил о том, что бы комманду 1.5 (я бы так назвал те кто в 1.5.больше раз получает) варили как лягушек медленно и отдельно. Т.е. оценивали и поднимали ЗП, но отдельно от других и при этом чуть медленнее, что бы через 1-2 года ситуация выровнялась.

Пересмотреть метрики аттестаций в копрорации – без шансов.

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

Стоит донести им два сообщения:

Позитивное: их оклад на данный момент превосходит оклад большинтва сотрудников того же уровня (благодаря из ценности для компании в момент слиения/заслугам/и т.п.), поэтому пересмотр в данный момент не предсталяется возможным. Также отметить их хорошую работу (таким образом не проивореча своим письменным благодарностям), которая УЖЕ оплачивается лучше, чем та же работа у остальных. Это должно удовлетворять теории справедливости.

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

То есть, фактически, придется им сказать: “Вы ребята работали хорошо. Но повышения не получите, потому что, как выяснилось, у других зарплаты меньше вашей. И чтобы получить прибавку в будущем, вам надо работать еще лучше.” Так? Первое, что спросят ребята: “Чего ты раньше-то не сказал, что надо работать еще лучше? А то спасибо, спасибо – а повышений нет.” 2 covrom Олег: те кто много получают, обычно, умеют понимать организационные проблемы, из-за которых им могут не прибавить оклад. Нет смысла их обманывать.

Хорошее замечание, на самом деле, как и у coredeveloper’а выше. Когда человек узнает, что получает в 1.5 раза больше других, то ему становится так приятно, что и повышения не надо. Но тут как карта ляжет. Человек, ожидания которого не оправдались, может повести себя всяко.

Олег: С другой стороны, нужно рассказать правду и “наверх”, т.е. другим манагерам и руководству. Они должны знать, к чему реально приведет то, что вот этим конкретным людям не повысят зарплату.

Это да, это хороший шаг.

2 Alex ИМХО, ситуация нелогична. После повышения зп в 1.5 раза Васю с Петей нужно было убрать из пула людей на пересмотр зп. Они должны понимать, что получать прибавки каждые х месяцев нереально. Если ПМ видит, что они “должны, но не понимают”, то ситуацию нужно прояснить, переговорив с глазу на глаз.

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

2 George В условиях кейса ничего не сказано, квалификация команды Олега находится на примерно одном уровне с другими командами (по стоимости на рынке труда в ДАННЫЙ МОМЕНТ) или нет.

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

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

Квалификация у людей примерно одинакова. Не зря же, Вася и Петя оказались в середине списка.

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

2 Antonio 1. Метрики неправильные – это однозначно. Исправить? Да никак, их (команду) купили и они не просчитали этот вариант (вариант, что если больше платят, то и оценивать будут соответственно). Идти убеждать босса? Не нужно.

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

Поздно. Олег уже фактически согласился с метриками, когда он с другими менеджерами расставлял людей от 1 до N. С метриками он согласен. Его удивила разница в зарплатах с соседними отделами.

2. Если у них зарплата изначально была больше в 1.5 раза, то вряд ли у них она будет сейчас меньше, чем у остальных. Так что можно смело приходить и говорить: “Ребята, мы все молодцы, мы в ТОПе, теперь посмотрим кто и как работал. И да, кстати, независимо от результатов, все члены нашей команды будут зарабатывать больше, чем в других командах (дальше типа “УрАА”)”. Смотрим на эффективность относительно метрик и люди сами начинают понимать кому будет прибавка, а кому нет. Когда все обсудили, нужно подойти к этим двум ребятам и пообщаться с ними, чтобы они не думали убегать. Если они сильно расстроились, нужно попробовать их переубедить и настроить, чтобы в след. году они дали результат повыше. Если же они окончательно расстроились, то нужно сразу находить замену, ибо они будут тормозить остальную команду.

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

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

Это как в истории про человека, который покорил Эверест:) (”И как Вы, что чувствуете?” – “Так же, как и все прошлые разы, когда я это себе представлял”. Помоему так:)) Ребята про метрики знают. Они не знают, что у их коллег зарплата в 1.5 раза ниже их. А именно этот факт влияет на то, какой рэйтинг на аттестации человек получает. И получает он прибавку или нет.

2 SoHo Мой вариант: Подойти к начальству с предложением повысить з.п. кому планировалось не в полтора раза, а например в 1.4-1.3 раза и за этот счет сделать прибавку Васе и Пете.

Почему именно так: повышение з.п. – это уже положительный момент, и если сотрудники получат прибавку не 50%, а 40%, это конечно их немного расстроит, но пережить это проще чем полное отсутствие повышения, в итоге негатив от этой новости сойдет на “нет”.

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

В итоге имеем: команда осталась в полном составе и сохранила мотивировку.

Предложение рабочее. Надо будет только а) переформулировать для началства фразу “для них будет ооочень приятно” и б) объяснить начальству, почему из N инженеров не найдено ни одного для 5%. 5% – это требование на уровне корпорации.

А еще можно Пете и Васе дать разовые премии, а не повышение зарплаты.

Премии в корпорациях придется обосновывать. Да иногда там просто и нет такого понятия “разовая премия”.

2 gnat Наколько я понял, эта аттестация – первая у Олега и его команды? То есть, они находятся в неравном положении с остальными командами и менеджерами, у которых уже есть опыт борьбы-за-выживание и аттестационных интриг?

Если так, то думаю надо в первую очередь идти к HR-менеджеру, который в курсе деталей приема команды на работу и прояснять ситуацию В частности, пробивать идею оформления аттестации как “пробной”, “тренировочной”, эмуляции… я по ходу думаю что она так и была затеяна – свеженанятых сотрудников и менеджера пропускать через ту же мясорубку, что и людей с опытом работы-интриг в компании как-то нелогично, даже в Интеле. При этом надо принять во внимание, что скорее всего оформление аттестации как “тренировочной” будет означать не только отмену понижения Васе и Пете, но и отмену повышения остальным (на мой взгляд, это и логично, и эгм честно).

Хорошая опция, но это надо было делать заранее. А Олег уже ввязался в игру и фактически ее слил.

Если идея “тренировочной” аттестации не встретит понимания (”ну эт вряд ли” (с) тов Сухов), то готовиться к серьезному конфликту. Зондировать почву насчет перехода сотрудников к “одному из бывших клиентов” (ну, который пытался переманить сотрудников), идти с жалобой вверх по служебной лестнице и все такое.

Жесткий такой вариант. Но почему нет?

Если пройдет идея “тренировочной” аттестации, то надо самому переварить и донести lessons-learned до членов команды. Вычислить, по каким критериям принято эгм “начислять позитив” сотрудникам других команд и заняться прокачкой этих критериев (желательно не в ущерб собственно программированию). При необходимости предупредить Васю и Петю, что по меркам компании они на следующей не-пробной аттестации рискуют поиметь понижение.

Ну и все такое прочее… Вот предупредить Васю и Петю надо будет обязательно, конечно.

2 covrom Что надо делать менеджеру? Первое – полностью понять систему мотивации, завладеть всей информацией на эту тему. Рассказать ее своей команде. Сориентировать команду на достижение такого результата, чтобы в следующий раз не попасть в “серый” список. Далее, выстроить план, при котором в следующий раз эти ребята получат повышение з/п. Это может быть перевыполнение плана и разовое премирование или еще что-то. Так или иначе, данная система мотивации заставляет менеджера использовать весь набор прочих инструментов повышения производительности команды и ее позиции в рейтинге организации.

На будущее – да, отличные шаги. Но сейчас Вася и Петя на получат ожидаемого повышения. Что может означать, что дальнейшие шаги менеджер будет делать уже без них.

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

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

Можно попробовать аргументировать низким качеством/сроками реализации продукта в случае ухода членов команды. Это пожалуй единственная надежда менеджера:) В таком духе, да: “Сотрудники будут демотивированы и пр, и пр.” 2 gnat Пользуясь случаем, заодно поясню почему “свеженанятых сотрудников и менеджера пропускать через ту же мясорубку… нелогично”.

Дело в том, что такой эгм кульбит, как понижение зарплаты с-в-е-ж-е-н-а-н-я-т-ы-м сотрудникам, отрицательно скажется на репутации компании. “А, корпорация Х… знаемзнаем, как же, как же. Это же те самые ребята, что при найме обещают золотые горы, а потом быстренько их отнимают под предлогом аттестации. Таким веры нет.” Особо хочу подчеркнуть, что упомянутые проблемы с репутацией в первую очередь затронут HR-менеджера. Кандидаты на работу в компании будут относиться к его предложениям как к пустому месту. “Ну да, конечно, ты мне сейчас обеаешь золотые горы, зато на первой же аттестации их отнимут, как отняли у Васи с Петей. Я так не играю. Пойду работать не к вам, в другую компанию, где нет таких закидонов.” Отсюда вывод – извините за повтор – надо в первую очередь идти к HR-менеджеру, который в курсе деталей приема команды на работу и прояснять ситуацию.

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

Интересная мысль.

2 mikola > По процедуре дальше открывались разряды и зарплата сотрудников При переходе изначально каким образом разряды присваивались ? Никак ?

И зарплата тоже с разрядами не связывалась ?

> 5% сотрудников должны были получить негативный месседж и нулевую прибавку к зарплате.

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

Это прибавка или все-таки аттестации ?

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

2 pbear 1. Давайте посмотрим исходную ситуацию.

Небольшую продуктовую компанию (назовем её “small comp”) покупает корпорация Х. Почему их купили?

Да, потому что покупка small comp способствовала достижению неких стратегических целей корпорации Х.

Почему подняли зарплату сотрудникам small comp? Да, потому что это сфера ИТ и вся ценность компании содержится в головах сотрудников. Если в момент покупки не удержать сотрудников, то деньги фактически будут выброшены на ветер. Мы ведь не покупаем производственную компанию со станками, зданиями, землей и т.д.

Именно поэтому, корпорация Х легко и непринужденно поднимает зарплату сотрудникам small comp в 1.5 раза. Нужно понимать, что деньги считают все, в том числе и корпорации.

Т.е. ожидаемая выгода (в деньгах) от покупки small comp покрывала повышение зарплаты сотрудников в 1.5 раза от планируемой выгоды. Либо (повторюсь), покупка small comp соответствовала стратегическим целям корпорации Х и повышение зарплаты – это копейки в масштабах корпорации.

К чему я это всё говорю? Да, к тому, что этим людям повысили зарплату не потому, что они высококласные специалисты, а потому, что это СОТРУДНИКИ ЭТОЙ КОНКРЕТНОЙ компании.

Они оказались в нужное время в нужном месте.

Именно, так все и было.

2. HR-менеджер.

Почему-то многие решили, что нужно идти к HR-менеджеру. А кто Вам сказал, что HR решит Вашу проблему? Первым делом необходимо выяснить КТО принимал решение о покупке компании и КТО принимал решение о повышении зарплаты сотрудникам.

Не забывайте – это корпорация. Решения вообще могли приниматься НЕ в РОССИИ. И тогда поход к местному HR-менеджеру – бесполезная затея.

Более того, иногда местный HR – это бывший HR маленькой компании, которого купили вместе со всеми. И он сам может быть еще не до конца в курсе всех тонкостей корпоративной процедуры аттестаций.

3. Про метрики и систему оценки.

Большинство отвечающих решили, что метрики “неправильные”. С какого перепугу? В таких корпорациях метрики формируют специальные люди.

Метрики – это следствия принятой в корпорации Х системы мотивации/стимуляции и работы с персоналом. Наверняка они рассчитываются, обосновываются.

Мало того, я почти уверен, что систему оценки и метрики “спускают” из головного офиса гденибудь в Калифорнии. И что? Тут появляется некто Вася Пупкин и говорит, что метрики неправильные? Да Вас пошлют быстренько в пешеходно-эротическое путешествие! С Вами даже никто разговаривать по этому поводу не будет.

+ Кстати, 5% – это тоже не случайная цифра. Для сведения: в России нормальной считается 5-6%-ая в год текучесть кадров на предприятии. Допускается текучесть до 15% (в год), но это уже критическое значение Я слышал версию, что автором (по крайне мере, горячим пропагандистом) системы является Джек Уэлс, легендарный CEO General Electric. Там, правда, речь шла про 10% и их раз в год увольняли.

4. Ещё про метрики и систему оценки.

Как я говорил уже выше, корпорации тоже считают деньги. И в этом смысле система оценки подтверждает действительно ли сотрудник настолько хорош, что мы ему платим ТАКИЕ деньги.

Действительно ли, сотрудник ПРОДОЛЖАЕТ работать хорошо в этом году? Или он успокоился и ничего не делает? На это и направлена система оценки. (Послушайте один из кастов ITрадио, где Панкратов рассказывает как он “испортил” людей большими зарплатами. Только из слов Панкратова я не понял осознал ли он сам, что нельзя сотрудникам давать ту зарплату, которую они хотят.) Да, это подход западных корпораций – постоянно держать морковку спереди и морковку сзади, причем морковка сзади значительно больше. Но они могут себе это позволить. Спросите своих знакомых работающих в Intel, IBM, Microsoft, Schlumberger, Shell.

Справедливости ради замечу, что не во всех корпорациях на аттестациях нужно обязательно найти установленный процент “остающих”. Точно не нужно в Sun’е (его, правда, уже купили ) и в Google. Также слышал слухи об исследовании, которое никак не подтвержадо связь установленного процента на отстающих и успеха компании.

А что будет дальше? Ну, хорошо. В этот раз вы напряжете всех, всем всё объясните, добьетесь чтобы всем вашим сотрудникам повысили зарплату. А через год будет СЛЕДУЮЩАЯ АТТЕСТАЦИЯ. А вы уверены, что на следующий год ситуация не повторится? И что? Вы снова пойдете к руководителям с поклонами? Второй раз такой номер не пройдет, да ещё вам припомнят предыдущую аттестацию.

Т.е. сейчас вы устраняете СЛЕДСТВИЕ, а ПРИЧИНА остается. И, неправильно поступив СЕЙЧАС, Вы готовите себе широкомасшабное наступление на большие грабли в будущем.

На следующий год сотрудники будут говорить Вам: “Ну, ты же в прошлом году смог сделать.

А почему в этом году не можешь сделать? Мы что хуже Васи, Пети, которых ты вытянул в прошлом году?” и т.д.

Очень важный момент, на самом деле.

то в реальности может сделать менеджер Олег?

а). Учитывая российскую ментальность, попросить равномерно распределить повышение з/пл на всех своих сотрудников, без изменения общего ФОТ. Запасной вариант – никому не повышать зарплату.

б). Предупредить всех сотрудников о “правилах игры” в компании. Сообщить, что сейчас з/пл всем поднимается, НО не на много. Или не поднимается, потому что …. (придумываем аргументы).

И ТАКОЕ происходит ПЕРВЫЙ и ПОСЛЕДНИЙ раз. В дальнейшем будем работать по правилам, установленным в корпорации. И по другому не будет.

Очень рабочее предложение.

2 kstref Мне кажется, что тут для определения тактики и стратегии важно следующее: сколько времени прошло с момента влияния команды Олега в корпорацию. Если менее полугода, то, с моей точки зрения, нужно исключать команду Олега из процедуры аттестации целиком.

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

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

Да, можно попробовать объявить аттестацию тестовой.

В случае же, если проработали больше полугода, то соглашусь с остальными, что нужно чтото делать с системой аттестации. Чего-то более разумного сходу предложить сложно.

Изменить систему аттестаций в корпорации – без шансов. Тем более, что она уже 30 лет успешно работает.

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

Так оно обычно и бывает. Бури негодования – да, проходили… Решение проблемы, в любом случае, находится не на уровне компетенции Олега.

А ему, тем не менее,, нужно что-то делать… Ладно. Значит, как оно было на самом деле. На самом деле, это была не первая аттестация. А вторая. Но она была первой именно с этими командами. Команды были из других городов, и у них разряды, неожиданно для Олега, оказались всреднем на 2 меньше, чем у его инженеров.

Сооответственно, и зарплаты тоже.

Как выкрутился Олег? Олег поговорил со своим HR’ом и выяснил, что в корпорации есть следующее правило при проведении аттестаций. Присвоение людям статуса below expectations и неприбавки зарплаты должно быть для человека ожидаемо. То есть, человек должен в течение года получать от своего менеджера письменные замечания по поводу своей работы.

На финальной сессии, на которой был HR и синьор менеджер Олег сказал примерно следующее:

Я не согласен с тем, что Вася и Петя получают статус below expectations и, соответственно, не получают прибавки. До наших обсуждений я был не в курсе того, что зарплаты у коллег ниже в 1.5 раза. Я был абсолютно уверен, что и Вася, и Петя трудятся хорошо и где-то даже очень хорошо. Поэтому решение о неприбавке им зарплаты будет для них неожиданным. У меня нет ни одного письменного замечания к Васе или Пете.

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

Это решение было принято синьор менеджером и HR’ом под неодобрительное молчание остальных менеджеров.

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

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

Час спорили про то, оставлять статус бага “LATER” в Багзилле или нет, потом обсуждали структуру пространства для кода тестовых сюит. И совсем не осталось времени на обсуждение тестовых скриптов. Дима, главный тестовый менеджер так и сказал напоследок: “Коллеги, не успеваем обсудить тестовые скрипты. Давайте послезавтра?” По пути на обед попался Иван, тех лид его команды. “О, вот и компания,” – обрадовался Леша и начал жаловаться подчиненному на менеджеров других городов: “Вообще ничего решить с ними не можем! Час, Ваня, час! Обсуждали статус LATER. Атас… Кстати, не посмотришь, как бы нам обустроить тестовые скрипты?” На следующий день Иван доложил, что все скрипты написаны, проверены и готовы к использованию. Это он после ужина посидел, пописал… Леша даже не удивился. Иван всегда отличался резкостью вкупе с производительностью. То, что другие делали неделю, он обычно укладывал в два часа.

Леша решил не писать сразу о скриптах, а сначала их хорошенько самостоятельно оттестировать.

Чтобы на совещании тестовых менеджеров ненароком так обронить: “Скрипты? А, кстати, мы тут посидели немного, и уже их написали.” На совещании, однако, случилась неожиданность. Оказалось, что московская команда тоже посидела и тоже написала аналогичные скрипты. Не на bash’е, как Иван, а на perl’е.

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

Дима слушал их первые полчаса, после чего сказал: “Нет коллеги, так мы ничего не решим.

Давайте сравним ваши скрипты между собой.” Попрошу вас обоих составить список метрик, по которым вы будете их сравнивать и провести сравнение.

Вернувшись с митинга, Леша вызвал к себе Ивана: “Вань, может, ну их? Скрипты же делают одно и то же. Пусть будет их версия?” Ваня, конечно, обиделся: “Леш, а чего ты меня тогда просил их посмотреть? Я что, получается, зря их писал, что ли?” На метрики и сравнения ушло два дня. По московской версии сравнения – получались лучше московские скрипты, по новгородской версии – новгородские смотрелись гораздо убедительнее.

От такого компаранса Дима пришел в неописуемую ярость: “Значит так! Я смотрю, и там, и там есть свои плюсы. Ок. Пусть ваши инженеры садятся на телефон и сращивают эти скрипты между собой.” Началась процедура сращивания… Вопрос: сколько ошибок сделал участники истории, какие именно и как надо было сделать понормальному?

РАЗБОР

Ну, в самом деле, суммируя то, что было сказано участниками:

Были ошибки в проведении совещаний (выпали за регламент и пр.) Была критика коллег-начальников перед лицом подчиненного Было противопоставление “нас умных” “им дуракам” Было предложено “объективно” оценить результаты своей работы исполнителям Было принято компромиссное решение о сращивании скриптов Многие фактически так или иначе подчеркнули все эти ошибки. Мне, честно говоря, очень понравилось решение pbear51 – довольно точно угадана подоплека событий из ситуации, имевшей место в реальности:

1. Cудя по первым 3-м абзацам кейса была и повестка совещания, и понимание проблемы у Ивана.

Об этом говорят слишком короткие фразы между участниками (Димой, Алексеем, Иваном).

Вот если бы Дима сказал что-то вроде: “На этом совещании я предполагал обсудить вопрос текстовых скриптов, которые …. Но сейчас не успеваем, поэтому перенесем этот вопрос.” Тогда можно было бы предположить, что повестки совещания не было. К тому же Иван понял Алексея с полуслова. А это значит, что вопрос ранее поднимался и обсуждался.

Предполагаю, что на совещании Дима планировал принять решение кто конкретно будет заниматься скриптами, но не успел.

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

3. Дальше с Ваней в кейсе есть “скользкий” момент. С Ваней может быть 2 варианта: либо сотруднику действительно нравится его работа и он готов решать любые поставленные задачи, либо сотрудник специально сделал больше, чем ему поручено (аттестации из прошлого кейса никто не отменял). Я предполагаю, что имеет место нечто среднее между 2мя озвученными вариантами.

4. А дальше Алексей делает всё ПРАВИЛЬНО Только надо понимать, что цели у Алексея – закрепить за своей командой эту задачу и выполненный объем работ. Тот факт, что московская команда делала тоже самое говорит о том, что есть СКРЫТАЯ КОНКУРЕНЦИЯ между командами!

bpgz совершенно прав. Всё зависит от целей (см. у bpgz п. 13). А цели у Алексея совершенно не соответствуют общим целям и целям Димы.

В таких случаях (управленческой борьбы) важно предоставить ГОТОВЫЙ и ПРОВЕРЕННЫЙ продукт, поэтому он всё досконально проверяет. Если Алексей на совещании скажет: “А вот мы написали скрипты, сейчас тестируем.” Я почти уверен, что в ответ прозвучит от московской команды: “А у нас скрипты написаны и проверены”. ДАЖЕ если это неправда. (ложь должна быть правдоподобной и труднопроверяемой). И тогда будет ожидаемое решение Димы: “Так, у москвы всё уже сделано, поэтому не тратьте время на тестирование, берем московский вариант”.

5. Я думаю, что скрытая конкуренция обусловлена системой оценки работы команд/сотрудников с помощью KPI.

Здесь нужно сделать небольшое отступление и рассказать об одном большом недостатке системы BSC (ССП) и KPI (КПЭ). Заключается он вот в чём. Как только вводится оценка работы сотрудника по KPI, сотрудник перестает работать на цели компании, непосредственного начальника и т.д. Он начинает работать только на свои показатели и каждое задание будет оценивать только с точки зрения улучшения СВОИХ показателей.

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

ответы Александра Орлова на предыдущий кейс).

НО! менеджер команды знает об методике оценки!

Алексей, зная о методике оценки, и, имея готовые скрипты, готовится их продемонстрировать их на совещании. Не забудьте, что если москвичи найдут ошибки в скриптах, то это будет поводом сказать: “А вот он предоставил непроверенное решение, у нас возникли проблемы и т.д. и т.п.” Таким образом при наличии ошибок работа команды Алексея будет дискредитирована в глазах главного менеджера Димы. В случае успеха команда Алексея и сам Алексей получили бы “плюсик” в репутацию. И возможность предоставить на следующей аттестации “железный” аргумент подтверждающий, что его команда работала больше московской. Успешная аттестация -> повышение зарплаты.

Подчеркиваю, именно из-за совершенно других целей и условий, действия Алексея ПРАВИЛЬНЫЕ.

Да, был риск, что его опередят. Но это другой этап борьбы 6. А вот Диме пришлось столкнуться с описанным выше недостатком системы BSC, точнее с её следствием. Его поставили перед фактом, что 2 команды сделали одно и тоже.

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

В ситуацих с противоречиям, конфликтами между Вашими подчиненными нужно помнить одно правило: “НИКОГДА, никогда не выступать третейским судьей для Ваших подчиненных.

Либо они договорятся САМИ между собой, либо обоим будет плохо.” Зная это правило, становится понятным, что Дима в целом выбрал правильное направление своих действий. Он стал ЗАСТАВЛЯТЬ команды ДОГОВАРИВАТЬСЯ между собой. Мало того, ему необходимо принять ОБОСНОВАННОЕ решение.

Поэтому он и слушает спор в течение получаса, и заставляет их провести сравнения.

И вот здесь он сделал ОДНУ небольшую ОШИБКУ (я считаю это единственной ошибкой за весь кейс).

Вместо: “Попрошу вас обоих составить список метрик, по которым вы будете их сравнивать и провести сравнение”.

Ему надо было сказать: “Попрошу обоих составить список метрик, провести сравнение и предоставить ОДИН, СОГЛАСОВАННЫЙ вариант сравнения”.

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

Следует отметить, что несмотря на сделанную ошибку в дальнейшем он всё равно придерживался правильной линии поведения. Фразу “сращивайте скрипты между собой” нужно понимать как: “Я не собираюсь погружаться в технические детали и решать чьи скрипты лучше. Не можете договориться сразу, значит трахайтесь как хотите, но в результате должно быть ОДНО решение”. Т.е. командам в любом случае придется договориться.

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

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

Подводя итог: ошибка и решение указаны в п. 6, профилактические действия указаны в п. Я не вполне согласен с выводами (об этом ниже), но ситуация угадана на 90%. pbear51, мои поздравления!

Мне бы хотелось подчеркнуть две вещи.

Вещь №1. Если кто-то думает, что чтобы не попасть в эту ситуацию, достаточно будет не совершать ошибок, которые перечислены участниками кейса, то это тоже ошибка.

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

Во-вторых, и тут сто раз прав pbear51, вступает в игру KPI. Во многих компаниях, в него включается impact вашей деятельности на деятельность подразделения и компании. Внедрили ваши скрипты в соседней команде – вы получаете плюшку. Внедрили чужие скрипты у вас – плюшку получаете не вы.

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

Вещь №2. Я не вполне согласен, что не надо быть третейским судьей при споре подчиненных.

Опять же, даже если вы сами не совершаете каких-либо ошибок, эти ошибки наверняка совершат ваши подчиненные. И рано или поздно принесут вам на сравнение свои “скрипты”.

И тут я очень сильно на стороне товарища Роберта Таунсенда, который в своей книге “Сломай систему!” сказал следующее:

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

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

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

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

Второй джуниор (звали его Коля) оказался весьма сообразительным товарищем. Собственно, то, что он стал заниматься тестированием GUI, было обусловлено скорее историческими причинами – он пришел в команду последним.

Коля довольно быстро разобрался с тематикой, в свое свободное время посмотрел средства автоматизации, выбрал Selenium и быстренько автоматизировал 90% тестов. Оставшиеся 10% остались ручными и отнимали у Коли как раз 90% его времени.

Алексей, видя Колину проактивность и резкость в действиях, понимал, что надо парня двигать вперед. Но как это делать – вот этого Алексей не понимал. Точнее, времени не было. Релизы надо было выпускать каждый месяц, а если убрать Колю с тестирования – то что тогда будет? Точно, ничего хорошего не будет. “Но делать с парнем что-то надо, – думал Алексей, – рано или поздно ему все это надоест.” И действительно, две недели назад, Коля подошел в конце рабочего дня и немного растерянно так спросил: “Леш, а как бы мне сменить характер работы? А то я тут уже все изучил, сделал все, что мог…” Алексей понял, что надо что-то решать, и пообещал Коле, что со следующего релиза переключит его на новую дейтельность: “Коль, давай сейчас этот релиз сдадим, чтобы у заказчика никаких проблем не было? А на следующем, я тебе обещаю, переведу тебя на разработку GUI.” Обнадеженный Коля ушел, и Алексей вернулся к тушению очередного факапа. Прошло десять дней, и Алексей внезапно вспомнил, что Колю надо переводить на разработку GUI. Однако, тут возникли проблемы. Изначально Алексей предполагал, что на тестирование он переведет второго джуниора. Но тот встал в глухую оборону, решив, что он в чем-то провинился и его за это хотят сослать в тестирование. Дошло даже до прямых угроз, что “если меня посадят кликать, то я уйду”.

А тут еще и заказчик решил, что следующий релиз ему нужен не через месяц, а через две недели.

Стало понятно, что если тестированием в этом релизе будет заниматься не Коля, то качество продукта просядет так, что мама не горюй.

Алексей налил себе кофе и задумался. До встречи с Колей, на которой он должен был объявить ему о новой работе, был еще час. Нужно было что-то придумать… Вопрос: что сделать Алексею? И как ему избежать подобных проблем в будущем?

РАЗБОР

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

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

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

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

Кроме того, Коля и сам может не знать, чего хочет.

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

Совершенно согласен. Более того, вопрос, как известно, рождает ожидание.

Итак, что я бы предложил. Что хочет Коля? Коля хочет расти. Если человек хочет расти, надо:

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

Нужно показать Коле, что он теперь отвечает не только за прогон тестов и анализ падений, а еще за ревью кода, круиз контроль и пр., и пр.

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

Как опять же предлагал Алексей Лупан, хорошо бы пригласить матерых тестировщиков (можно даже извне), которые личным примером показали и объяснили бы Коле, насколько это круто – быть тестировщиком. Сколько там всего можно сделать и чего можно реально достичь. Примерно про это, кстати, я как раз буду выступать на грядущих SQA Days.

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

Можете попросить директора уделить Коле десять минут, чтобы директор рассказал, как ОН видит Колю во главе отдела тестирования этого проекта. Но что тому предстоит еще долгий путь. И если он будет внимательно слушать Алексея, то вот тогда… Примерно так. Ну и, конечно, как подметили многие участники, Алексею надо быть поосторожней с обещаниями. И побольше внимания уделять сотрудникам. Чтобы знать, почему заартачился второй джуниор – это тоже ведь неспроста… Алексей программировал кофейный автомат на выдачу утренней порции кофе, когда увидел выходящего из-за угла Федора. Кофейный автомат был популярным местом сбора. Особенно у менеджеров, коими Алексей с Федором и являлись.

- Леха, здорово! – привычно завопил Федор, – Слышал, к нам Саймон приезжает?

- Клево. А когда?

- Через неделю. Сможете показать ему свою автоматизацию тестирования GUI?

- Наверное, да.

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

Собственно, успехов было несколько. Но работой, которая особенно волновала начальство, была автоматизация тестирования GUI. Автоматизация выполнялась при помощи инструмента, разработанного в другом офисе компании пару лет назад. И начальство очень волновалось по этому поводу – надо было наконец выяснить, толковый был разработан инструмент, или деньги были потрачены зазря.

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

Поговорив с Сергеем Леша понял, что все на мази – до прогона первого сценария остается чутьчуть. Со спокойным сердцем он улетел на недельный тренинг в Англию, надеясь, что в его отсутствие Сергей доборет первый сценарий. В Англии с интернетом было не очень, но Леша успел обменяться с Сергеем смс-ками: “Как там?” – “Нормально, боремся”.

Демо Саймону была назначена на 12:00 понедельника и включена в программу визита. Леша решил на всякий случай прогнать дему самостоятельно с Сергеем в 10:00.

В 10:00 Сергея на работе еще не было. Леша начал нервничать. В 10:40 Сергей появился. “Лех, ты знаешь…” – начал он неуверенно. У Леши внутри все замерло.

- Короче, сценарий мы сделали, но он падает два раза из трех. Может быть, на демо повезет… - Серега, блин, а где ты раньше был?

- Ну, я думал, что мы ее доборем… Кто знал, что они в своем Саратове такой инструмент кривой написали?!

До демы Саймону оставалось час десять. Мозг Леши начал лихорадочно придумывать, как выкрутиться из положения… Вопрос: что делать Леше?

РАЗБОР

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

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

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

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

Ни в коем случае не допускайте неконструктивной критики инструмента. Постарайтесь насытить эти четыре пункта максимальным количеством данных:

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

Список же действий в последнем пункте хорошо бы завершить так: “Послать детальный отчет на участников опс ревью”, чтобы начальство окончательно убедилось, что ситуация под контролем и ему будет доложено об исходе.

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

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

Примерно так.

P.S. После написания разбора прочитал ответы участников обсуждения. С радостью увидел, что пратикчески переписал ответ Targyсвоими словами.

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

P.P.P.S. История в комментариях про ген. директора, который говорил про выпадающие ошибки, что так и должно быть – это пять!

7. КЕЙС «ДАВАЙТЕ НЕ БУДЕМ РУГАТЬСЯ»

Рассмотрим небольшой пример – диалог между разработчиком и тестировщиком:

Леша: Слава, ну вы утомили выставлять баги в последний момент! Сегодня перед обедом я все закрыл, прихожу с обеда – вы мне опять наповыставляли! Ну сколько можно-то?

Слава: Пишите код качественно, и не будет проблем.

Леша: Да причем тут качественно?!! Где вы раньше-то были со своей ошибкой? Этот модуль не меняется уже месяц.

Слава: Мы не можем оттестировать все сразу, у нас ресурсов нет.

Леша: О, старая песня: «Нет ресурсов…» Ни у кого нет ресурсов. Только мы код почему-то пишем, а вы со своей работой явно не справляетесь!

Слава: Ну да, конечно! Кода вы пишете много, с этим не поспоришь. Зато ошибки никто не исправляет. Код писать куда интересней, чем править ошибки. Зачем мы их вообще тогда находим?

Леша: Надо же вам за что-то зарплату получать, вот и находите. Слав, я вообще не понимаю, чем конкретно ты как руководитель тестирования занимаешься. У тебя вечно какой-то бардак и авралы.

Слава: Леша, знаешь что. Ты стал неадекватен, с тобой общаться стало невозможно.

Леша: Взаимно.

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

РАЗБОР

В чем конкретно неконструктив в этом обсуждении?

Есть такой старый добрый критерий конструктивности разговора – критерий ADOPT. Который говорит, что адресовать проблемы следует в следующей манере:

Direct – то бишь, решать проблему нужно с тем человеком, который может ее решить. Вот, например, орать на уборщицу, что у вас недостаточно мягкая туалетная бумага в туалете – неправильно. Скорее всего, эту проблему может решить офис менеджер. А уборщица не выделяет бюджет на туалетную бумагу.

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

Objective – использовать факты и данные при обсуждении. Если фактов и данных нет, то собеседник обязательно подумает, что вы к нему придираетесь. Если факты вспомнить не можете, но уверены, что правы – это вам никак в обсуждении не поможет. Нужно будет вспоминать.

В разбираемом кейсе таки был один факт:

Леша: Слава, ну вы утомили выставлять баги в последний момент! Сегодня перед обедом я все закрыл, прихожу с обеда – вы мне опять наповыставляли!

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

Вот с этим в кейсе полная беда. Слава и Леша костерят друг друга на чем свет стоит.

Timely – проблему надо поднимать своевременно. Если коллега что-то сделал не так – решите с ним сразу, если эта проблема стоит решения. Если прийти к нему через две недели, то возникнет ощущение, что вы достали проблему из сундука ровно для того, чтобы поругаться.

И в какой момент оно вышло из-под контроля, т.е. коллеги ударились в неконструктив?

Конечно, практически сразу. Так происходит всегда, когда один из собеседников переходит на личности. Заметим, что в начале Леша даже помнил о проблеме, с которой он пришел.

Проблемой были баги, которые выставляются в последний момент. Но потом случился переходи на личности, ответный удар и пошли рубиться… В данном случае прав aavezel:

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

Это достаточно просто сделать, если обсуждение идет по почте. (Хотя и там некоторые товарищи умудряются основательно поругаться.) В личном обсуждении – это верно на 100%. Если человек начинает на вас орать матом, то слушать его будет весьма затруднительно. А для того, чтобы разрешить ситуацию конструктивно, человека нужно уметь слушать и слышать.

Я бы только советовал не “убегать” от человека (это может задеть его тем, что вы не хотите решать его проблему), а сказать прямо в лоб: “Коллега, извини, но когда ты так кричишь, я не могу помочь тебе решить твою проблему. Давай остынем. Заходи через полчаса?”

8. КЕЙС «МЕЖДУ ДЕДЛАЙНОМ И ХУЛИГАНАМИ»

Олег работал руководителем проекта в филиале большой международной компании.

Исторически сложилось, что большинство разработчиков находились в Чикаго, в киевском же тестировщики и бизнес-аналитики.

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

Однажды первый «свой» проект был получен! Первый «отечественный» руководитель Олег пообещал начальству «не подкачать» и приступил к работе.

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

Одной из наиболее насущных проблем стала разница во времени в восемь часов. Ведь ведущие разработчики все еще были в Чикаго (и большинство неведущих тоже). Обещание перевести и программистские должности в Киев все еще набирало бюрократическую силу.

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

Последним ударом стало просьба-требование топ-менеджмента закончить проект на месяц раньше, чем было запланировано – потребности бизнеса… Одной из мер по их удовлетворению стало решение «попросить» киевлян на оставшееся время перейти на рабочий график с 13 до 22. Взамен были обещаны солидные бонусы. «Просить» о том же американцев никто не стал, но, впрочем, это отдельная тема.

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

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

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

Через несколько дней Таня попросила Олега перевести ее на «нормальный» график. Но сделать это без ущерба для проекта было никак нельзя, а объяснить американцам причину тоже непросто.

Олег как мог уговорил Таню потерпеть еще немного и вернулся к своим делам.

Еще через пару дней Таня написала Олегу официальное письмо все с той же просьбой перевести ее на прежний график работы, «так как руководство компании не в состоянии обеспечить мою безопасноть при возвращении домой». В копию были добавлены руководители HR-отдела и всего филиала.

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

Он понимал, что дело не в законодательстве и даже не в безопасности (она лишь повод), а в том, что Тане не хочется работать по неудобному графику.

Что Олегу можно сделать прямо сейчас?

Как предотвратить появление подобных ситуаций в будущем?

РАЗБОР

«Он понимал, что дело не в законодательстве и даже не в безопасности (она лишь повод), а в том, что Тане не хочется работать по неудобному графику.» – на месте Олега я бы тут подумал чуть глубже. «А почему Тане не хочется работать по такому графику?» Вероятно потому, что девушка не хочет, чтобы хулиганы на пустыре таки добились как-нибудь своей цели. То есть, за себя боязно.

Когда за себя боязно, желание думать о работе как-то притупляется. Поэтому даже если Таню заставить административно-приказными способами приходить в 13 и уходить в 22, работать она все равно будет плохо. Голова не о том. А тут еще менеджер давит приказами, что автоматически покажет человеку, что менеджер – идиот и не заботится о сотрудниках.

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

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

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

Можно поговорить с заказчиками, объяснить им ситуацию и предложить им оплачивать такси. Скорее всего, это не бог весть какие деньги по сравнению с бюджетом проекта.

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

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

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

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

Почему чикагцы не могут прийти на работу к 4 утра?..» Отсюда и опоздания и все остальное.

Так это, надо объяснять решения. И команде, и один на один. «Мы работаем на то, чтобы перетащить позиции разработчиков в Киев. Мы зарабатываем деньги.» и пр., и пр. – с каждым человеком в зависимости от того, что его лично мотивирует.

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

Что делать в текущей ситуации?

Поговорить с Таней 1:1, извиниться, постараться выяснить, в чем реально проблема. Если такси решает– решаем.

Поговорить 1:1 с каждым членом команды. Так и сказать: “Есть ощущение, что не совсем понятно, нафига мы тут сидим до пол-ночи”. Объяснить, на фига сидим-то, правда.

Если никто не понимает, собрать команду и обсудить ситуацию со всеми. Дернуть каждого конкретно и спросить – подписываешщься или нет?

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

Предложение такое: (варианты) вы нам оплачиваете такси; вы начинаете приходить сами чуть раньше, мы уходим чуть раньше.

Как-то так. Если вкратце:

Проблемы по всем признакам есть, и у многих.

Проблемы у людей могут быть разными.

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

Второй кейс от Димы Лысенко:

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

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

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

В тот момент свободные люди были. Но вот только на 2, а не на 3 месяца. Дело в том, что через месяца планировалась довольно важное и срочное, но и нетрудное задание продолжительностью в 2-3 недели.

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

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

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

Киевляне, как и договаривались, приступили к работе.

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

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

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

После того, как Алексей рассказал о сложившейся ситуации своему руководителю, они решили, что для начала нужно написать письмо руководителю харьковского офиса Константину.

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

Предлагается 3 возможных варианта письма (темы письма, приветствия, прощания и подписи опущены, текст также несколько сокращен).

Что плохого и хорошего в каждом из вариантов? Какой из них вы считаете лучшим? Что бы вы в нем изменили?

Вариант Прошу Вашего содействия в выполнении обязательств харьковского филиала в лице руководителя направления N перед киевским филиалом и сообщить о принятых по этому вопросу мерах.

Суть дела такова: по договоренности с руководителем направления N наши сотрудники выполняют работы по проекту Х.

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

Однако этого до сих пор не произошло.

Вариант В соответствии с договоренностью с руководителем направления N Андреем К. сотрудники нашего филиала выполняют часть работ по вашему проекту Х в объеме 12 человеко-месяцев. Но до сих пор в наше распоряжение не поступили сотрудники вашего филиала, что также входило в договоренность с Андреем.

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

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

Сообщите возможность выделения 4 человек сроком на 3 недели.

РАЗБОР

Некоторые решения мне даже присылали на почту. Настало время написать, что я думаю по этому поводу.

Вначале о наболевшем.

Наболевшее №1. Коллеги, фиксируйте свои договоренности. копии писем с договоренностями по поводу ресурсов недурно и менеджерам повыше отправлять. Чтобы в случае чего, не приходилось ломать голову над такими вот кейсами.

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

Наболевшее №3. Не надо такие проблемы решать по почте. Судя по всему, тут срочный вопрос, который людей волнует. Тут надо минимум звонить, максимум ехать в Харьков. Звоните.

Теперь, что делать в сложившейся ситуации. Вначале решение партнерское. Как известно.

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

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

Сообщите возможность выделения 4 человек сроком на 3 недели.

Не производится нападок вроде “Однако этого до сих пор не произошло” как в 1-м варианте. И не высказывается сразу же давящая позиция: “В противном случае мы будем вынуждены отозвать наших сотрудников, занятых на проекте Х”, как во 2-м варианте.

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

Если же отношения между Киевом и Харьковом натянутые и задача киевского офиса продавить харьковчан, то тогда можно сразу посылать 2-й вариант:

В соответствии с договоренностью с руководителем направления N Андреем К. сотрудники нашего филиала выполняют часть работ по вашему проекту Х в объеме 12 человеко-месяцев.

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

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

Потом можно отключить почту и телефон и свалить на харьковчан то, что они поздно засуетились.

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

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

Один из читателей прислал вопрос, который было решено сделать кейсом:

Дело было так. Была в моей группе девушка, программистка.

И вот я говорю ей: “Маша, надо сделать вот такую функцию, и сделать ее надо вот таким образом, потому что так будет удобно нашему заказчику”. На что Маша мне отвечает:

“Делать как ты сказал я не буду, потому что мне так не нравится. И вообще, ты для меня не авторитет”.

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

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

И все, затык. Как строить дальнейший диалог – совершенно непонятно. А работу делать надо, деваться некуда.

Бежать к директору жаловаться – глупо, означает расписаться в собственном бессилии. Как-то воздействовать на Машу – так нет никаких реальных рычагов у руководителя группы. Не может он ни рублем наказать, ни взять на место Маши более сговорчивого сотрудника. Такие вопросы только директор решает, и тратить несколько месяцев на замену Маши, которая давно работает и знает все о продукте, он не станет.

Мотивировать, бегать вокруг такого сотрудника – честно говоря, никакого желания нет. К слову, “уговаривать” – это был единственный способ заставлять Машу делать как нужно, а не как ей хочется.

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

Я бы сам так делать не стал. Директору легко – он погрозил и исчез далеко и надолго. А мне с Машей каждый день рядом работать. Ей пригрозишь – так она вообще разговаривать перестанет.

Нужно хоть какие-то отношения сохранить, иначе работа встанет.

А как бы Вы поступили? Как эффективно реагировать на выпендреж в духе “ты мне не авторитет и не указ”?

РАЗБОР

Что я думаю по поводу всей этой ситуации.

То, что Маша вот так открыто послала своего руководителя со словами “ты для меня не авторитет” – это хорошо. Гораздо хуже, если бы она таила в себе злобу, молчала и делала что-то такое нехорошее за спиной менеджера. Скрытые конфликты решать сложнее. Тут конфликт открытый, и это уже неплохо.

Что делать, когда подчиненный тебя открыто посылает. Точно не надо вступать с ним в перепалку при всех. Иначе получится как на всех форумах – оба оппонента друг друга измазали не буду говорить чем в попытках выяснить, кто из них Д’Артаньян. Если подчиненный посылает публично, переводите в конструктив: “Маша, ок, возможно я чего-то не понимаю. Давай это обсудим с тобой после общего собрания.” И далее – на личную встречу. Но вначале определитесь, хотите вы с этим человеком работать в одной команде или нет. Если хотите, то дальше можно говорить. Иначе лучше идти и с директором обсуждать, как бы от Маши избавиться, предварительно скопив фактов о недопустимом Машином поведении и его пагубном влиянии на проект.

Если же вы хотите работать с этим человеком, то проблемы стоило бы обсудить вот какие:

1. Маша не смотрит на продукт с точки зрения пользователя. Не стоит искать причины обязательно в Машиной лени. Вполне может оказаться, что она просто никогда не задумывается над пользователями. И имеет скорее дизайнерскую культуру. Попробуйте объяснить проблему, как вы ее видите.

2. “Посылать руководителя при всех – не конструктивно. Если есть какие-то проблемы, то я открыт для их решения. Что-то не устраивает – приходи, расскажи, решим что делать.” – можно прямо так и сказать.

3. “Авторитет менеджера не зарабатывается словами. Он зарабатывается делами. Маша, если ты видишь, что я как руководитель должен сделать – скажи прямо, давай обсудим и посмотрим, что можно будет сделать.” – можно прямо так и сказать.

Дальше – Маша может прислушаться, и тогда вы договоритесь и придумаете, как жить дальше.Может не прислушаться – не намеренно или намеренно. В этом случае вам нужно будет планировать ее уход. Готовить другого сотрудника для ее задач и помогать Маше искать себя в другом проекте или компании. Но это уже немного другой разговор. Вначале надо обсудить все с ней.

На будущее пара важных вещей:

1. Если вы приходите в проект не с начал – обязательно поговорите с предыдущим менеджером.

Не только про состояние проекта, планы, отчеты, риски и прочие проектные прибамбасы.

Поговорите про людей. Кто есть кто, кто чего хочет, к кому какой подход нужен? Не только про сотрудников в проекте – про коллег менеджеров тоже поговорите. И про начальника поговорите.

Чтобы потом не было такого, что начальник неожиданно ни с того, ни с сего посылает.