• Неукротимая Маша: разбор кейса

    Posted on April 11th, 2010 Александр Орлов No comments

    За всеми путешествиями и тренингами (за последний месяц умудрился посетить 5 городов и провести 15 тренинговых дней) настало время поговорить о кейсе “Неукротимая Маша”. Большое спасибо тем, кто принял участие в обсуждении. Если не ошибаюсь, этот кейс стал самым обсуждаемым на happy-pm.com. Много мнений, вполне разумных, думаю, автор кейса получил интересную обратную связь.

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

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

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

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

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

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

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

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

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

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

    1. Если вы приходите в проект не с начал – обязательно поговорите с предыдущим менеджером. Не только про состояние проекта, планы, отчеты, риски и прочие проектные прибамбасы. Поговорите про людей. Кто есть кто, кто чего хочет, к кому какой подход нужен? Не только про сотрудников в проекте – про коллег менеджеров тоже поговорите. И про начальника поговорите. Чтобы потом не было такого, что начальник неожиданно ни с того, ни с сего посылает. :)

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

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

  • Кейс “Неукротимая Маша”

    Posted on March 12th, 2010 Александр Орлов 54 comments

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

    Кейс “Неукротимая Маша”

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

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

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

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

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

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

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

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

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

  • Невозвращенный долг: разбор кейса

    Posted on March 9th, 2010 Александр Орлов 3 comments

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Кейс “Невозвращенный долг”

    Posted on February 19th, 2010 Александр Орлов 8 comments

    На этой неделе – второй кейс от Димы Лысенко.

    Кейс “Невозвращенный долг”

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

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

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

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

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

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

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

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

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

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

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

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

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

    Вариант 1

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

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

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

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

    Вариант 2

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

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

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

    Вариант 3

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

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

  • Между дедлайном и хулиганами: разбор кейса

    Posted on January 29th, 2010 Александр Орлов 8 comments

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

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

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

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

    • Отвозить всех ребят на своей машине вечером до метро. Именно так делает, например, Слава Панкратов. Их офис находится в отдалении от жизни и вечером там довольно неуютно идти по безлюдным улицам. Поэтому девушек из своего отдела Слава иногда подвозит.
    • Если машины нет, попросить того, у кого из команды есть, подвозить всех остальных.
    • Оплатить ребятам такси, если они сидят на работе до 22. Раз уж все равно бонусы дают за преждевременную сдачу проекта.
    • Можно поговорить с заказчиками, объяснить им ситуацию и предложить им оплачивать такси. Скорее всего, это не бог весть какие деньги по сравнению с бюджетом проекта.
    • Сделать ребятам возможность работы из дома. (Возможно, для этого придется надавать в торец сис.админу, чтобы он наконец проснулся. J) Пусть у ребят будет возможность уехать домой в 19, а дальше работать из дома.

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

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

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

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

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

  • Кейс “Между дедлайном и хулиганами”

    Posted on January 15th, 2010 Александр Орлов 36 comments

    Дима Лысенко (с которым мы в кругу коллег неплохо пообсуждали обучение тестированию на круглом столе питерских SQA Days) прислал очень любопытный кейс:

    Кейс “Между дедлайном и хулиганами”

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

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

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

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

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

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

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

    Последним ударом стало просьба-требование топ-менеджмента закончить проект на месяц раньше, чем было запланировано – потребности бизнеса…

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

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

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

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

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

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

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

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

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

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

    P.S. Хочешь предложить свой кейс? Пиши на info@happy-pm.com

  • Задача от Сергея Мартыненко

    Posted on November 13th, 2009 Александр Орлов 25 comments

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

    Пусть Некто заявляет,  что в их команде по производству ПО:

    1. Работают только профессионалы
    2. Все сотрудники работают максимально эффективно
    3. В фирме четкое разделение обязанностей. Аналитики анализируют, дизайнеры дизайнят, кодировщики кодируют.

    Вопросы:

    • Могут ли эти утверждения быть истинными одновременно? Почему?
    • Какое из этих утверждений, скорее всего, ложно?
    • Какие из этих утверждений стоит сделать ложными?
  • Давайте не будем ругаться – разбор кейса

    Posted on November 6th, 2009 Александр Орлов 2 comments

    Итак, пришла пора разобраться в кейсе “Давайте не будем ругаться”. Ответим на первый вопрос:

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

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

    • Direct
    • Objective
    • Positive
    • Timely

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

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

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

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

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

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

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

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

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

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

    В данном случае прав aavezel:

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

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

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

  • Кейс “Давайте не будем ругаться”

    Posted on October 23rd, 2009 Александр Орлов 9 comments

    Сегодня будет немного необычный кейс.

    Довольно интересно бывает обсуждать проблему конструктива со слушателями тренингов. Слушатели время от времени жалуются на коллег, что те ведут себя не конструктивно. Спрашиваешь: “А что такое конструктивно?” Тут возникает пауза. “Ну, он совсем не слушает, что я ему говорю.” :)

    Надо понимать. что умение слушать и умение вести конструктивное обсуждение – это немного разные вещи, хотя и сильно связанные. Помнится, в Intel были даже отдельные курсы: Effective Listening и Constructive Confrontaion. (Мастер-класс по последнему, кстати, давеча довелось читать на корпоративном тренинге в одной небольшой московской компании.)

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

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

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

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

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

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

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

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

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

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

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

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

    P.S. Хочешь предложить свой кейс? Пиши на info@happy-pm.com

  • Напряженная борьба – разбор кейса

    Posted on October 22nd, 2009 Александр Орлов No comments

    Итак, вернемся к менеджеру Алексею из кейса “Напряженная борьба”, которого мы оставили две недели назад в глубокой задумчивости. Что ему делать?

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

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

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

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

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

    • Время, потраченное на разработку первого сценария
    • время на обучение человека инструменту
    • Количество дефектов, обнаруженное в инструменте

    Чем больше данных и фактов, тем объективней выглядит точка зрения.

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

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

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

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

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

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