Инрэко ЛАН

inreco_lan


Группа компаний «Инрэко ЛАН»

«Инрэко ЛАН» — интеллект вашего бизнеса


Previous Entry Поделиться
SQA Days 8: Вячеслав Панкратов «Как договариваться о раннем релизе с командой разработки»
Инрэко ЛАН
inreco_lan

В ноябре мне довелось побывать на конференции SQA Days 8, и посетить мастер-класс Вячеслава Панкратова, который назывался «Как договариваться о раннем релизе с командой разработки».

Начну с краткого представления докладчика.
Вячеслав Панкратов – карьерный консультант, бизнес-тренер в IT и редактор http://www.it4business.ru/. Основные специализации: тест-менеджмент, тест-дизайн, управление командами, управление временем, личная эффективность, построение карьеры.
Вячеслав Пакратов
Знакомство началось с того, что Вячеслав предложил всем желающим поучаствовать в игре и попробовать угадать его вес. Для этого надо было написать предполагаемое количество килограмм на обратной стороне визитки (у кого их не было, можно было воспользоваться любой бумажкой, указав имя, фамилию и почту). Победителю была обещана бесплатная консультация по Skype, если победителей будет несколько, то приз – закрытый онлайн-семинар на тему карьеры и карьерного развития. К сожалению, выигравшим был только один человек, причем не я (предположившая только 106 кг, хотя на самом деле было 128).

На мой взгляд, смысл данной игры сводился к нескольким пунктам:

  1. Определить насколько правильно мы можем сделать какую либо оценку, причем нужно было найти баланс между «хочу выиграть» и «не обидеть человека, назвав большое значение».
  2. Неплохой способ получить сразу стопку визиток.
  3. Данной игрой был завоеван интерес большой части аудитории.


В-общем, это был хороший ход. Мне понравился.

Дальше нас всех, каждый ряд, рассчитали на «первый», «второй», «третий». Рядом сидящие 1, 2, 3 – это одна группа. Каждому номеру сообщили его роль: 1 – наблюдатель; 2 - руководитель группы тестирования; 3 - руководитель группы разработки. Все люди одной роли поочередно выходят в коридор и получают задание.

Я была наблюдателем и получила задание: просто смотреть и записывать ход разговора, не судить, не отдергивать, а только отмечать «кто пришел», «кто и как поставил свой вопрос», «кто пошел по кругу»; и в конце мне нужно было сказать, что бы обе стороны, когда придут к решению, каждый в своей тетради без разговоров уже записал до чего договорились.

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

После того, как всем была задана модель поведения, всем была озвучена тестовая ситуация:

  • команда выпускает билд каждые 2 недели, по четвергам;
  • в пятницу команда тестирования тестирует, а силы разработки направлены на следующую версию;
  • обычно билд проходит 2-3 попытки в статусе релиз-кандидат и по результатам приемочного тестирования какой-то из релизов-кандидатов становится релизом;
  • на прошлой неделе произошел сбой: было выпущено 9 релизов кандидатов;
  • время релиза было перенесено на вечер понедельника;
  • время выпуска следующей версии не сдвигается;
  • во вторник руководитель крупы тестирования приходит к руководителю группы разработки и предлагает перенести выдачу релиза-кандидата с четверга на среду, что было больше времени на тестирование;
  • руководитель группы разработки, должен предложить тестировщику отдать версию в пятницу утром, а не четверг, что бы успеть доделать функционал).
 
На попытку договориться было отведено 15 минут, если раньше договорятся до оптимального решения – то это даже лучше. По окончании этого времени был опрос (для подсчетов 1 человек от команды поднимает руку):
  • сколько всего команд;
  • скольким удалось договориться;
  • не удалось;
  • не успели договориться;
  • другое (например, один из участников решил уволиться).
 

После подсчетов начались обсуждения.

Многие из тех, кто «договорились» совершили ряд ошибок:

  1. Приняли решение об урезке функционала.
  2. Для компенсации задержки возможна работа в выходные и/или переработка по будням. В этом случае можно выявить пару недостатков:
    • менеджер, принял решение, не согласовав это со своими сотрудниками.
    • программисты апеллировали, что будут работать в субботу, и поэтому тестировщикам тоже нужно выйти. Но это неконструктивная аргументация для тестировщиков, т.к. программисты сами совершили ошибки, провалили релиз, а выставили как уступку свою работу в выходной день.
 
Если стороны не смогли договориться, то возможны следующие ошибки:
  1. На аргументы выдвигались не контраргументы, а собственные новые аргументы. То есть не слушаю собеседника, а хочу убедить.
  2. Выдвигались требования (например: тестировщики начинали требовать оправдание, почему был провален релиз).
  3. В разговоре использовались обвинения: например, что в прошлый раз затянули релиз.
  4. Сильное давление. В этом случае существует несколько возможных исходов:
    • продавилась вторая сторона;
    • один выдвигает аргументы, другой упирается;
    • ответное давление.
 

К тому, что люди не могут договориться, была приведена хорошая цитата Л. П. Берия: "Если два коммуниста не могут договориться по вопросу, имеющему оборонное значение, значит, один из них – враг".

Конечно, единого «рецепта» построения разговора дать невозможно. Нужно постараться: избегать ошибок и строить конструктивное общение, направленное на достижение оптимального результата.

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

Источники:

  1. Профиль Вячеслава Панкратова в Моем Круге
  2. Страница Вячеслава Панкратова сайте учебного центра Luxoft
  3. Тезисы доклада на сайте SQA Days
Автор: Марина Лагерь

Оригинальная статья в копроративном блоге.

?

Log in

No account? Create an account