• Кейс “Опять двадцать пять”

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

    Очередной кейс от Димы Лысенко – на тему, вечную как мир, вечную как отношения двух персонажей на картинке. :) (Кейс навеян кейсами Майкла Болтона.)

    Кейс “Опять двадцать пять”

    Максим (руководитель проекта) и Алексей (руководитель группы тестирования) работают в небольшой продуктовой компании.

    Однажды вечером между ними состоялся такой диалог.

    М: Привет! Слушай, похоже тебе и твоим ребятам придется поработать в субботу. Извини, что сообщаю об этом всего лишь за два дня.

    А: Опять? Надо же…

    М: Да. Разработчики буквально пару минут назад сообщили мне, что завтра к обеду будет готов билд, в котором будут исправлены все пять оставшихся критичных багов, восемь второго приоритета и еще куча мелких. Всего 27 штук! И это они за 4 дня успели сделать, такого у нас уже давно не было. Они действительно классно поработали. Давай и вы тоже продолжите в том же духе.

    А: Мда… они молодцы, конечно. Они сами что-нибудь потестили? Билд хотя бы собирается нормально?

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

    А: … да еще и старых.

    М: Ну да, старых, но это же все время, ты же в курсе. Каждый из них, конечно же, проверил все пофикшенные баги у себя локально, куда ж без этого. И все было нормально. Но чтоб узнать, как оно все вместе работает, вы нам и нужны. Так ведь? У них на это просто никогда не будет времени, да и не их это задача. Вы же должны обеспечить качество продукта.

    А: Хорошо, я могу протестировать продукт, но как обеспечить его качество и качество их чудо-кода… я не знаю.

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

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

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

    А: Знаешь, я не думаю, что у меня получится в субботу…

    М: Как?! Послушай, до релиза осталось каких-то две недели. И весь проект зависит от вашей работы. Нам просто жизненно нужно успешно проведенное тестирование. Ты же помнишь, что в каждом предыдущем релиз-кандидате обязательно находилось по несколько критичных багов. Я не такой оптимист, чтобы думать, что в этот раз будет иначе. Без тестирования и дальнейшего багфикса я не могу отдать билд заказчику. А с ним дата уже согласована, и на уступки он идти не склонен. Потерпите еще пару недель, ок? А пока мы не можем терять ни дня, надо убедиться, что все протестировано как следует.

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

    М: Но ведь вы можете покрыть их этими… исследовательскими тестами, да вы уже и так это делаете, насколько я знаю. Ребята у тебя квалифицированные, с продуктом знакомы, так что можно сэкономить на тест-кейсах. У нас, еще раз повторю, на это нет времени. Проект вот-вот закончится, и каждый человеко-час на счету!

    К тому же, мы согласовали с заказчиком приемочные тесты. Там уж все описано и задокументировано как надо.

    На них, кстати, и советую сосредоточиться сразу после проверки багфиксов.

    А: Ммм.. я не думаю, что этого будет достаточно. У нас там еще важные непокрытые вещи есть. И я все-таки неуверен насчет субботы.

    М: Ладно, пришли мне сейчас краткий план ваших действий в субботу. Что и в каком порядке вы собираетесь покрыть. Только не усердствуй, чтоб вам еще и в воскресение не пришлось работать. Я уверен, что и за один день можно как следует протестить. Жду вас в субботу. Руководитель программистов, кстати, будет на связи, звони ему если что. Можете там себе пиццу заказать или пиво вечером – компания оплатит.

    А: Ok, мы будем.

    М: Спасибо, Леха!

    Какие ошибки во время данного разговора допустили Максим и Алексей?

    Какие ошибки были допущены в ведении проекта вообще?

    Что бы предприняли на месте Алексея?

    Как бы вы построили разговор на месте Максима?

    P.S. Хочешь, чтобы обсудили твой кейс? Присылай его на info@happy-pm.com !

     

    11 responses to “Кейс “Опять двадцать пять””

    1. Странные ощущения от этого разговора возникают. Как будто люди только-только начали работать, и вообще, и вместе. Все эти “я могу протестировать продукт, но как обеспечить его качество и качество их чудо-кода” – звучит просто фантастически. Если ты не можешь обеспечить качество, зачем ты вообще занимаешься тестированием?

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

      1. При оценке сроков окончания разработки явно недооцениваются возможные задержки. Максим сам же говорит “они сказали, что завтра все будет готово к обеду … можно рассчитывать что-то получить к вечеру”, но, похоже, не считает нужным заложиться на аналогичные сдвиги сроков в течение всей разработки. Из-за этого и появляется необходимость работать по выходным.

      2. Почему Максим планирует ресурсы тестеров? Почему это происходит в авральном режиме? Неужели нельзя было заранее, называя заказчикам сроки, обсудить с тестерами будущий продукт и получить от них оценку сроков. Так можно было бы избежать ситуации “вы как хотите, а мы через две недели улетаем”. Фраза “проект вот-вот закончится, и каждый человеко-час на счету” – наглая ложь. Учётом тут и не пахнет.

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

      4. Алексей ведёт себя очень вяло. Ему опять навязывают неурочную, незапланированную и несогласованную заранее работу – и он соглашается. Раз так, то ничего не изменится, его сотрудники будут трудиться без отдыха. Пока им это не надоест и они не начнут увольняться, конечно.

      5. Подозреваю, что качество продукта будет невысоким. Давление со стороны Максима “только не усердствуй, чтоб вам еще и в воскресение не пришлось работать” упадёт на благодатную почву – и тестирование будет проведено абы как и с минимальным напрягом.

      В общем, стыдно должно быть обоим. И меняться надо тоже обоим: Максиму учиться нормальному планированию, не в вакууме; Алексею – укреплять характер и защищать своих сотрудников.

      Прошу прощения за ссылку, но я пишу ровно об этих проблемах в своём блоге http://www.control-freak.ru/

    2. M: “Вы же должны обеспечить качество продукта.”

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

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

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

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

    4. Общее замечания к ведению проекта:
      1. Внутри команды разработчиков должен QA, который сам убедиться в отсутствие критичных багов и работоспособности продукта. После чего он (или руководитель проекта) передаёт это команде разработчиков.
      2. Все важные мейлстоуны должны назначаться не на последний день недели, и тем более не на выходные. Оптимальный вариант – четверг, чтобы пятница была запасом.
      3. Мало кто любит работать на выходные, только те, кому нужны деньги (в большинстве случаев). И принужденный выход негативно сказывается на сотрудниках.
      4. Руководитель проекта должен проводить периодические встречи, толи в рамках скрама, толи в обычных еженедельных планах, на которых обсуждаются все важные моменты проекта (мейлстоуны).
      5. Разговор должен быть построен в виде «сендвича»: мягкое начало, плавно подводя к основному запросу, ну и закрытие. (для Максима)

    5. Ниже замечания по диалогу разделены на «Плохо» и «Хорошо»
      1. Плохо. Со стороны М. слишком директивный тон со с первой же фразы «Слушай, похоже тебе и твоим ребятам придется поработать в субботу.». На которой, у А. срабатывает самозащита («Опять? Надо же…»), которая сразу оборачивается нехотением принимать всё остальное сказанное.
      Как надо. М. должен был начать разговор со всем по другому, сделать мягкое начало, подвести человека к серьёзному разговору.

      2. Плохо. М. перекладывает ответственность на разработчиков: «Разработчики буквально пару минут назад сообщили мне».

      3. Хорошо. Похвалили своих ребят: «Они действительно классно поработали.»
      Плохо. Очень наглядное провокационное сообщение «Давай и вы тоже продолжите в том же духе.». Совсем не мотивирует к работе, такие обращения могут адресоваться к молодым сотрудникам, которые горят проявить себя. «Мда… они молодцы, конечно.»

      4. Плохо. «Но чтоб узнать, как оно все вместе работает, вы нам и нужны. Так ведь? … Вы же должны обеспечить качество продукта.» М. упрекает или просто не знает процесса.

      5. «…стоит отправить кого-то из моих ребят плотно поработать с разработчиками. Узнать там все подробности по тестовые данные, скрипты. Проконсультироваться насчет тестового окружения.»
      Хорошо. Что А. хочет войти в курс проекта, изучить все детали.
      Плохо. Это должно быть выполнено на этапе «начала» или «развития», а не на этапе последующего релиза. На этих этапах вся документация должна только дополняться.

      6. М.: «Дело в том, что мы рискуем не получить билд завтра, если они будут отвлекаться на эти вопросы.»
      Плохо. Отказ М. в запросе на помощь в тестирование. Доказывает тот факт, что внтури команды должен быть QA.

      7. М.: «Как?! Послушай, до релиза осталось каких-то две недели. И весь проект зависит от вашей работы. Нам просто жизненно нужно успешно проведенное тестирование.»
      Хорошо. За две недели практически подготовили кандидат-релиз.
      Как надо. Подготовить билд в четверг. Возможно без некоторых фич/исправленных ошибок.

      8. М.: « Без тестирования и дальнейшего багфикса я не могу отдать билд заказчику. А с ним дата уже согласована»
      Плохо. О данной дате должен знать руководитель тестового департамента, и о всех ближайших этапах тестирования.

      9. М.: «Но ведь вы можете покрыть их этими… исследовательскими тестами»
      Хорошо. Фри-тесты – это очень хорошо.
      Плохо. Ними нельзя покрыть всё. Фри-тесты хорошо дополняют только тесты по кейсам.

      10. М: «Ладно, пришли мне сейчас краткий план ваших действий в субботу. Что и в каком порядке вы собираетесь покрыть. Только не усердствуй, чтоб вам еще и в воскресение не пришлось работать. Я уверен, что и за один день можно как следует протестить. Жду вас в субботу. Руководитель программистов, кстати, будет на связи, звони ему если что. Можете там себе пиццу заказать или пиво вечером – компания оплатит.»
      Плохо. Скрытые угрозы со стороны М.: «чтоб вам еще и в воскресение не пришлось работать».
      М. не получив позитивного ответа от А. директивно сказал «Жду вас в субботу». А. и его ребята выйдут в субботу, но это негативно скажется на отношение А. к М. И А. постарается найти упреки в будущем, чтобы доказать, что данная идея была не очень хороша.
      Хорошо. Мотивация пиццей и пивом. Молодым тестировщикам это будет интересно.

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

    6. Я бы назвал этот кейс по другому – “телепаты недоделанные, или Вольф Мессинг нервно курит в сторонке”. :)

      Если бы я был таким, как Максим или Алексей, то на этом бы и закончил, безо всяких объяснений. Или нет! я бы вообще ничего не писал, а просто послал бы телепатический импульс, чтобы мысль дошла до читателей прямо из моего мозга.

      Но поскольку я не верю в телепатию, попробую все же объяснить письменно.

      —————————

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

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

      В результате, на мой взгляд, получился типичный проект-”авоська”. Ну то есть когда все идет на авось и невозможно (за две недели до сдачи!) оценить, устроит ли он заказчика. С вероятностью процентов 50 продукт не пройдет приемку клиента. Или пройдет позже оговоренного срока.

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

      —————————

      Какие ошибки были во время данного разговора? в ведении проекта вообще? что бы я предпринял на их месте? Ответы на все эти вопросы на мой взгляд в основном одинаковые.

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

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

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

    7. sergii.markov

      Какие ошибки были допущены в ведении проекта вообще:

      1. “М: Да. Разработчики буквально пару минут назад сообщили мне…” Планирование проходит плохо. Если девелоперы сами не знают когда выкатят “что-то”, то тест тим обречен.
      Фраза “А: Опять? Надо же…” подтверждает, что это уже не первый раз. Значит, девелопмент плохо планирует время (не учитывают риски, возможно в спринты всовывают новые таски и т.д.)

      2. “М: … Вы же должны обеспечить качество продукта.” Никто никому ничего не должен :)
      Если жить с идеей что качество продукта зависит от QA – ничего не получится. Качественный продукт – это, прежде всего, качественный процесс (любой подходящий под проект). Нужен качественный анализ, качественное планирование. Нет анализа – все меняется, нет планов – сроки “полетят”. Качества в таком случае ждать не приходится.

      3. “А: Мда… они молодцы, конечно. Они сами что-нибудь потестили? Билд хотя бы собирается нормально?” заставляет задуматься… Нет доверия совсем. Скорей всего пару раз слажали крепко (может даже в подобных ситуациях). Выкатили билд, тестеры вышли в выходной – а тестить то по сути и нечего.

      4. “М: И юнит-тесты прошли все, хоть их и немного.” Опять говорит о том, что нет необходимого времени на написание юнит-тестов. Значит берем слишком много задач в спринт. Это можно в пункту 1 отнести.

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

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

      Какие ошибки во время данного разговора допустили Максим и Алексей:

      1. “А: Хорошо… наверно тогда стоит отправить кого-то из моих ребят плотно поработать с разработчиками.” Я не очень люблю использовать слова “наверное”, “скорей всего”, “было бы не плохо”… Если нужно – говори “мне нужно”. Требуй то, без чего тебе тяжело, или то, что упростит жизнь.

      2. “М. Сейчас нужно их оставить в покое”. Пытаемся оградить девелопмент тим. Будьте добры ребята помочь нам, коль мы вас выручаем (тем более в выходной). Не очень похоже на сплоченную работу тест и девелопмент команд. Всегда найдется девелопер, с которым пьешь кофе и куришь, и который найдет пол часа времени для тебя. Не стоит ограждать разработчиков, объяснял тем что у них нет времени.

      3. “М. Руководитель программистов, кстати, будет на связи, звони ему если что” а вот это не есть очень хорошо… Если что пойдет не так и потребуется какой-то быстрый фикс – нужен девелопер. Коль уже весь тест тим вышел на работу в выходной – будьте добры, пускай и девелопер уже выйдет. Получается, “я пью пиво”, а вы, ребята, тестируйте.

      4. “А: Хорошо, я могу протестировать продукт, но как обеспечить его качество и качество их чудо-кода… я не знаю.” и далее “А: Знаешь, я не думаю, что у меня получится в субботу…” Плохо. Не давай заранее ответов, только когда уверен в чем-то – говори. ВТорая фраза проигнорится, ты ведь уже согласился :)

      5. “М: Ладно, пришли мне сейчас краткий план ваших действий в субботу. Что и в каком порядке вы собираетесь покрыть. Только не усердствуй, чтоб вам еще и в воскресение не пришлось работать.” Занавес. “Дайте воды, ато так есть хочется, что аж переночевать негде”.
      Выбора не оставили + намек на воскресенье… Наврятли это оставит позитивные эмоции.

    8. Из кейса складывается впечатление, что Алексей либо новичок, либо его просто Максим “задавил авторитетом” – ибо все безропотно принимать (я бы даже сказал – обреченно) – это режет глаз.

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

      Далее, про координацию действий с разработчиками – надо четко обозначить, что если не будет координации действий, то результаты тестирования будет процентов на 30% хуже (ибо мы не знаем, что правили, не знаем, на что обратить внимание, а телепатия, как уже было замечено gnat выше, пока что еще недостаточно развита). Если их дергать нельзя – пусть выходят на работу в субботу и консультируют. Заодно могут сразу “на живую” поправить найденные ошибки.

      Резюмируя, основные проблемы – это организация процесса разработки, планирование, и игра в одни ворота со стороны команды разработки и ПМа.

    9. Прочитал все комменты — почему все думают, что у ребят какие-то проблемы?

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

      Лично мне больше всего понравился комментарий Алексея Лупана про представителей древнейшей профессии.

      Но только я бы его вывернул наоборот — никакого битья морды Алексей не ожидал.

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

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

    10. 2 Alexei Barantsev

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

      действительно, похоже на то, что процесс сложившийся.

      А почему ты считаешь, что он – нормальный? Работать в субботу за пиццу и пиво – это нормально?

    11. [...] пришла пора разобрать кейс «Опять двадцать пять». Спасибо всем, кто откликнулся со своим решением! И [...]

    Leave a reply

    You must be logged in to post a comment.