• Кейс “Замкнутый круг”

    Posted on September 25th, 2009 Александр Орлов 12 comments
    Новый пятничный кейс – о старой дилемме менеджера “цели проекта vs. цели людей”.
    Кейс “Замкнутый круг”

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

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

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

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

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

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

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

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

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

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

     

    12 responses to “Кейс “Замкнутый круг””

    1. 1)

      Предпоследний абзац достоин пера Дюма-отца!

      2)

      По тексту не ясно, чем именно хочет заняться тестировщик, поэтому после “а как бы мне сменить характер работы” надо прямо спросить – на что именно? Ткни пальцем, чем хочешь заниматься. В проекте у нас такие-то должности/роли. Вот занятые. Вот свободные. Куда попадешь?

      Прямо перевести тестировщика в разработку в контексте уже устаканенного процесса – сложно. Был бы нужен команде программист – не сидел бы тут Коля со своими амбициями…

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

      Если же нет – ну, похоже, что молодой тестировщик просто увлекся автоматизацией. Чему именно он хочет обучиться? В автоматизации тоже много течений и уровней…

      Если другой работы нет, я бы назначил Колю главой отдела тестирования. Пусть из QC станет QA. Пусть отвечает за качество В ЦЕЛОМ. Пусть начнет метаться. Придется потерпеть, но если он дометается до куда надо – все будет хорошо.

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

      В каком-то смысле это можно рассматривать как “перевести Колю на разработку”…

      А когда у него полностью захватит дух, он уйдет сам :)

      Или не уйдет, а скажет непрестанно наливающему кофе с валокордином Алексею, что хочет (нужно) сделать вот еще это и это, такими вот способами…

      3)

      Я сейчас в роли Коли – сам себе автоматизатор, и чую, что это дело затягивает и форматирует моё восприятие всего дела под другую “файловую систему”. Это чем-то похоже на переходный возраст, что взрывоопасно.

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

      Возня со скриптами (отладка, уточнение, внесение изменений) занимает много больше времени, чем ручная проверка продукта. Но греет осознание того, что уж потом…

      В общем, желание Коли “заняться чем-то еще” мне понятно в контексте его окружения, а не “в принципе”.

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

      Например:
      - Нафига, тебе, Коля, быть слабым программистом? На, стань сильным тестировщиком! Разрули разработку! Делай им по ночам код-ревью, а утром оставляй на столе результаты ревью! Заставь их писать юнит-тесты! Повесь себе на стол металлическую табличку со словом “начальник”!

      И так далее ;)

    2. Согласен с Алексеем по п2
      Если сделать его уже как никак зав подразделением и, И при возможности приставить в роли обучателя(студ практику еще не отменяли). Хотя плодить отдел начальников не очень бы хотелось.

      От себя:
      Несколько смутило что 10% тестирования занимает 90% рабочего времени. Можно “оттянуть” срок серьезного действия под предлогом автоматизации по максимуму. В освободившееся время выяснять у других, если имеется, команд наличие вакансий или мест на продвижение.
      Так же интересен пункт с единственным заказчиком. Другие заказчики есть? Средства разработки теже??? если нет, то попробовать организовать рокировку кадров если имееются.

      А этот второй джуниор настолько прям уперся рогом в землю??? Почему у него такое странное чувство вины. С ним стоит поговорить. Разьяснить что к чему. Может напридумывал и реально боится место потерять. А разговор построить таким образом, что просто попробовать. Мол, Коля лишь “попробует”. Может вообще не понравится. А у Коли тесты автоматизированны почти все;) Считай как отпуск на работе. (хотя самому верится с трудом).

      И опять же выяснить у Коли чего он действительно хотел бы

      С уважением, Саша

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

    4. Сначала поговорить с Колей чтобы точно понять проблему: почему он хочет сменить характер работы и что за этим стоит. А также понять чего он хочет в дальнейшем. Из примера вроде бы следует что Колю напрягает ручное тестирование и отсутствие развития, но лучше перепроверить, чтобы не решать вымышленную проблему.
      Допустим, возможно что Коля согласится тестировать и разрабатывать 50% / 50%.

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

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

    5. Я бы не снимал с Коли обязанности по тестированию полностью. По сути, он единственный в команде обладатель уникального опыта – как тестировать их продукт. Можно предложить ему несколько направлений развития.
      Во-первых (в любом случае), стоит рассказать остальным членам команды, что тестируется и как, какие есть сложности, почему 10% тестов не удалось автоматизировать, как работают автотесты и т.д. Общую схему все наверняка и так знают, а вот подробности скорее всего неизвестны. Возможно, более опытные лиды подскажут, как обойти часть проблем по автоматизации; возможно какое-то относительно небольшое изменение в продукте (например во внутреннем устройстве GUI) позволит автоматизировать уже 99% тестов. Кроме того, при создании такой презентации Коля сам себе нарисует картину сделанного и потенциальных путей развития (про них, кстати, тоже стоит рассказать всем), а остальные увидят, чего он достиг и как его достижения помогли всей команде.
      Далее, можно оставить Колю ответственным за автоматичесое тестирование, а ручные тесты распределить между всеми членами команды. Эти тесты отнимали у Коли 90% времени, то есть если их распределить равномерно на четверых, то каждый потратит 25-30% своего времени. В принципе можно распределить не равномерно, но чтобы такое распределение предложить, нужно команду знать хорошо (Алексей наверное знает, я – нет :) ). Плюс: второй джуниор увидит, что это не его “ссылают в тестирование”, изменения затрагивают всю команду. Минусы: неизвестна реакция двух техлидов на такую инициативу (но если они правда “куда скажешь, туда и плывут”, то проблем быть не должно); дорогое время техлидов будет тратиться на тестирование. Впрочем последнее может опять же обернуться плюсом – возможно, покликав, они придумают, как уменьшить затраты на тестирование. Коля во время свободное от прямого тестирования может как работать над продуктом, так и над улучшениями [авто]тестов.
      Другой вариант – предложить Коле создать GUI для работы с автотестами. Конфигурирование, запуск, работа с результатами – все это было бы здорово делать через GUI. Кроме того, это позволило бы легко запускать автотесты любому члену команды, когда нужно. Формально в этом случае обещание (переведу тебя на разработку GUI) будет исполнено, но скорее всего Коля будет не очень доволен, так что надо будет нарисовать дальнейшую перспективу – как проблема выполнения ручных тестов одним Колей будет решаться в будущем и куда будет расти Коля. Для этого стоит выяснить, чего он сам желает, что ему интересно. Вообще, стоило спросить об этом Колю еще тогда, когда он подошел с вопросом – он же не просил направить его на разработку GUI, а пришел советоваться, как “сменить характер работы”. Может ему и тестирование интересно, но он просто не знает, что еще можно сделать. Тогда можно было бы проконсультироваться с каким-нибудь матерым QA инженером – наверняка такие в компании есть.
      И да, предупредить заказчика о повышенном риске срыва сроков в этот раз (обоснование: во-первых, сроки меньше обычного, во-вторых – подумать)

      На будущее – понимая наличие проблемы (“рано или поздно ему все это надоест”) искать пути решения заранее. Узнавать, что интересно подчиненным, ротировать обязанности или распределять их на несколько человек (речь о “больших” активностях, конечно), спрашивать, как подобные проблемы решались в других командах…

    6. А вот еще хинт, но уже как тема для размышления после разруливания ситуации.

      Можно Колю познакомить с НАСТОЯЩИМИ тестировщиками. Чтобы у него колени дрожали и терялась клавиша Enter от мысли о своем несоответствии званию “настоящего тестировщика”. Чтобы он мечтал работать рядом с ними.

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

      Но, конечно, это корыстный ход, плюс будет только проекту и менеджеру.

      То есть, если Коля талантливый художник, его надо сводить с художниками. Если он талантливый шахматист, его надо сводить с шахматистами. Если он в тестировании случайно, и рассматривает это как переходный период в светлый мир программирования на COBOL для банка на Аляске – ему все ваши шахматисты и тестировщики нафиг не сдались…

    7. 1. Решения внутри команды нет (перераспределение обязанностей, ротация и т.д.).
      Единственный возможный вариант был – это 2й джуниор. Но он отказался.

      2. Есть 2 варианта решения проблемы:
      а) попытаться сделать ротацию с кем-то из других команд.
      б) предложить Коле искать новую работу.

      3. Возможные варианты предотвращения подобных проблем в будущем:
      а) сделать систему ротации кадров между командами в компании (если это возможно). НО! Ключевых членов команд не менять.
      б) нанять сотрудника по ПСИХОЛОГИЧЕСКИМ ХАРАКТЕРИСТИКАМ СООТВЕТСТВУЮЩЕГО этой работе. Т.е.: обычный средний работник, инициативы особой не проявляет, склонен к стабильности. Я бы искал либо девушку, либо девушку с ребенком 3-7 лет, либо женщину за 40.
      в) смириться с тем, что на этой позиции люди долго работать не будут, постоянная текучка. И поэтому планировать работу соответствующим образом.

    8. Судя по количеству человек в команде и по том как часто происходят релизы – это похоже на аджайл.
      Можно посадить двох джуниоров в пару:
      Оба кодят и оба тестируют. Так как релиз через 2 недели, значит много фич не будет, тоесть риски не высокие.

      Результаты:
      1.Таким образом Коля попробует разработку и сможет помогти в тестировании, а GUI девелопер попробует немного тестирования в перемешку с разработкой. Это хороший экпириенс для двоих
      2. Обое джуниоров будут довольны, так как полочили то что хотели

      После релиза поговорить с Колей что ему ближе – тестирование или разработка.

      На будущее:
      1. не давать зразу ответы на вопросы которые влияют на роли в команде.
      2. Воспитывать взаимозаменаемых людей (что будет если Коля уйдет в отпуск)

    9. “…был еще час. Нужно было что-то придумать…
      что сделать Алексею?”

      Отложить разговор на неделю :)

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

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

      Итак, 3 варианта:

      1) Идеальный – проблема в тех 10% что занимают 90% времени Коли и которые собственно его и “тащат на дно”. Перестроить работу всё команды, что бы тестирование этих 10% занимало не 90%, а хотя бы 50% времени (для начала). Перестраивать придется на ходу, потери в виде сорванных сроков и превышения плановых трудоемкостей неизбежны – но это плата за инертность Алексея – ну а начальству объяснить, что это неизбежные траты – если Коля уйдет – будет еще хуже.

      2) Тяжелый – перераспределить работу в команде, так, что бы Коля мог расти и второй джуниор сразу же не ушел. (Хотя со временем со вторым джуниором может и стоит распрощаться.) Опять же – те же проблемы что и в первом варианте + орг. проблемы (вряд ли остальные в команде будут в восторге от этой затеи).

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

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

      “И как ему избежать подобных проблем в будущем?”

      В целом – не обещать подчиненным то, что есть вероятность не сделать. Обещать легко и приятно, но на то ты и менеджер, что бы делать то, что нужно.

      В частности (по этой ситуации): не ждать, когда сотрудник перерастет свою должность, а действовать на опережение.

    10. Взять бы этот кейс да разобрать на винтики…

    11. > Вопрос: что сделать Алексею? И как ему избежать подобных проблем в будущем?

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

      Как думаете камрады?

    12. Постарался закрыть глаза на ответы и не читать) Ладно, первый пост прочитал))

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

      Так вот. Поскольку релиз “горит”, то я бы ничего не менял. Я бы встретился с Колей, спросил бы, где он себя видит, почему так, а не так, вник бы лучше. Объяснил ему ситуация с релизом и думаю, что Коля потерпел бы.

      После этого релиза, я бы поставил перед фактом второго девелопера и перевел бы в тестирование. Да, это не хорошо, вот так насильно кого-то, куда-то переводить. НО, если Алексей об этом задумался, повторюсь, значит у него есть повод.

    Leave a reply

    You must be logged in to post a comment.