• Кейс “Напряженная борьба”

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

    Сегодня кейс из реальной жизни. Примерно так оно и было.

    Кейс “Напряженная борьба”

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

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

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

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

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

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

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

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

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

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

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

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

    - Серега, блин, а где ты раньше был?

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

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

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

     

    14 responses to “Кейс “Напряженная борьба””

    1. На главный и вечный вопрос “Что делать?” ответ один: Не выкручиваться, а честно признаться Саймону, что первый кейс провален. Это даст Саймону ответы на его вопросы о правильности инвестиций и потраченного времени, даже не смотря на то, что это негативно повлияет на имидж команды-разработчика. Кроме того, во время демо можно проработать план выхода из сложившейся ситуации. Врать – не работает.

      Рабор полетов:
      * почему разработка сценария началась всего за неделю до демо, не смотря на то, что проект имеет приоритет в компании?
      * почему Леша поверил Сергею что “все на мази”, когда за короткое время до демо первый сценарий “не ходил”?
      * связано ли “слепая” вера словам Сергея с тем, что опытный специалист с 10-летним стажем недооценил “масштаб трагедии”?
      * почему Леша решил сделать проверку своими руками перед самым началом демо? почему не раньше?
      * где отчетность? Почему Леша все узнает о проблемах в последний момент? Не мог ли Сергей предупредить, что совсем все плохо за 2-3 дня до демо?
      * Почему после разговора у кофейного аппарата Федор больше не появлялся? Скорее всего он также заинтересованный человек тоже, так как именно от него исходила просьба сделать демо.

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

    2. в моем посте выше прошу читать “кейс”, как “сценарий”

    3. Соглашусь с Романом – надо честно рассказать все Саймону на счет того, что внедрение пока что идет неудачно. Для того, чтобы не оказаться крайним в этой ситуации, за оставшееся время надо сесть вместе с Сергеем и составить презенташку по результатам внедрения:
      – что хорошо/удобно?
      – что плохо/не удачно сделано?
      – список проблем, с которыми столкнулись при внедрении
      – выводы: пытаться внедрять дальше (ожидаемые сроки на решение проблем, как можно ускорить процесс – например, послать Сергея на командировку в Саратов или Марию вытащить в этот офис) или имеет смысл отказаться в виду каких-то архитектурных недостатков инструмента (перечислить с учетом затрат на решение для каждого)

      PS: вообще, оценивать внедрение по истечении 2 недель (с учетом того, что раньше инструментарием не пользовались) – не слишком удачный подход. Свидетельствует скорее о том, что инструмент пока сыроват, и ни о чем более.

    4. Мысль Targy (спасибо) заставила меня снова посмотреть на свой пост (“вообще, оценивать внедрение по истечении 2 недель (с учетом того, что раньше инструментарием не пользовались) – не слишком удачный подход”).

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

    5. Я бы задался следующим вопросом: что ожидает увидеть Саймон, и что ему интересно?

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

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

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

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

    6. Я бы на месте Алексея сперва – на всякий случай – уточнил бы у Федора, был ли обещан Саймону какой-то конкретный формат демонстрации. И если в компании работают нормальные люди, то наверно услышал бы в ответ что речь шла о “демо вообще” – без уточнения формата.

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

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

      ————————————

      PS. “сценарий… падает два раза из трех” какоюжас. А если бы он падал один раз из десяти – что, идти на демонстрацию с живым сценарием? он ведь все равно может упасть.

      Надо отделять мух от котлет. Отдельно – информация о том, как автоматизация спроектирована, отдельно – информация о степени ее готовности на текущий момент. Цель демы – не нажимание кнопочек перед светлыми очами начальства, а передача информации о проекте.

      ————————————

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

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

      Все по честному и никаких авралов.

    7. в принципе уже все мои мысле выше изложили, вариантов несколько
      1) сказать правду,провести разбор полетов
      2) в зависимости от ожиданий и обещаний вышестоящему руководству сделать демо в виде презентации или нарезать видео и с отмазкой, что то у нас тут софт на этом нотнике не запускается,но мы все предусмотрели и специально записали видео

      ну и вариант который бы точно выбрал мой бвыший ген директор (несколько раз именно таким образом и проходила презентация софта)- на момент выпадания ошибки/падения софта он рассказывал что тут специально в код внесена бага которая должна защитить софт от копирования/нелегального распространения/ещечегонибудь но наши мега программисты обязательно ее исправят (БЕСПЛАТНО) в момент деплоя, даже перед лицом руководства из очень крупных компания этот трюк удавался :)

    8. :) Интересный подход, rkononov, использует Ваш бывший ген. директор. Имидж, конечно, дело хорошее, но я считаю, что намного перспективнее говорить правду, какой бы она не была.
      А профессиональный имидж будет более позитивным, если предложить эффективный план выхода из ситуации и предоставлением относительной прозрачности. Конечно, негатив не должен быть постоянным …

    9. Да, и враньё, по горькому опыту, отнимает слишком много энергии у всех, кто учавствует в “заговоре”. Хорошее “вранье” должно быть оч. хорошо контролируемым, что требует времени для организации. Просто представте, а вдруг Саймон имеет какой то контакт с Машей из Саратова, которую вдруг не предупредили, что на демо мы будем врать? Насколько пострадает репутация, если все расскроется?

    10. Полностью согласен с ek_artem.
      Хотел бы добавить одно соображение.

      Если Саймону обещали работающий сценарий – то это однозначно ошибка Алексея.

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

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

      Спасибо!

    12. Привет, у меня такие мысли:

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

      Почему:
      1) Это даст Саймону ответ на воспрос “толковый был разработан инструмент, или деньги были потрачены зазря.”

      2) Начальству нужно знать правду, чтобы сделать правильные выводы.

      3) Доверие к Алексею не будет потеряно.

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

    14. опять с опозданием, но все же :)

      Этот кейс – чисто менеджерский. Здесь нужно применить все техники убеждения и “выкручивания”, какими только владеет менеджер. Да, нужно сказать правда, что так и так.
      Показать систему в лучшем свете, “заглаживая” на словах ее баги. Не нужно винить свою команду, можно обвинить кого угодно, но не команду (сам виноват, не досморел за мис-комьюникейшн). Дать четкие сроки на все исправления.

      Кратко и просто)

    Leave a reply

    You must be logged in to post a comment.