• Путь наверх по руинам

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

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

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

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

    У нас, говорит, Сань, есть вице-президент, сделавший стремительную карьеру. Мы потом решили посмотреть, что случилось с проектами, которые он вел. Все проекты провалились.

    Почему так получилось? Вероятно, человек бодро стартовал проекты, получал какие-то первые обнадеживающие результаты, а дальше говорил: “Ну дальше тут справятся и простые ребята”, получал свои звезды на погоны и шел наверх.

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

    Виноваты одни, ответственность несут другие. Те, кто заложил причину неминуемого провала, получают плюшки и идут наверх. Есть в этом что-то несправедливое, а?

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

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

     

    8 responses to “Путь наверх по руинам”

    1. > Другой пример из жизни. В одной компании годами существовал фрэймворк для прогона тестов. Менеджер из одного регионального подразделения стартовал проект, частью которого было написание аналогичного фрэймворка. Зачем это делается – на уровне инженеров не понимал никто. В итоге через два года новый фрэймворк был-таки благополучно погребен. Но где в этот момент был предприимчивый менеджер? Где-то в другом месте.

      ————–

      если это тот пример, про который я думаю, то могу поделиться уточненными фактами.

      - насчет того, что к концу погребения “предприимчивый менеджер” был в другом месте верно, только это немного другая (грустная) история

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

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

      ————–

      *) внезапно обнаружилось — могу предположить, что для того предприимчивого-менеджера в этом не было ничего внезапного. Но его к тому времени уже отодвинули от руля проекта гораздо-более-предприимчивые эгм corporate tapeworms (http://gapingvoid.com/2004/07/31/your-company-needs-you-now-more-than-it-ever-did/)

      ————–

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

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

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

    3. Пост в защиту “стартаперов”.

      У нас, говорит, Сань, есть вице-президент, сделавший стремительную карьеру. Мы потом решили посмотреть, что случилось с проектами, которые он вел. Все проекты провалились.

      Я придерживаюсь мнения, что есть разные типы менеджеров. Кто-то по своей душе “стартапер” и обожает новое и готов 24 часа в сутки работать над раскруткой проекта. Когда же проект входит в спокойную фазу, то менеджер, не находя выхода своей “первопроходческой” натуре начинает скучать или направлять энергию в негативное (для проекта русло).
      Другой тип менеджера “все под контролем”. Это когда человек может долгое время четко и правильно вести команду к предсказуемым результатам. От него не стоит ждать ярких идей, “огня в глазах” и т.д. Но он незаменим/совершенен/надежен (все нужное подчеркнуть :) ) в том, как он ведет предсказуемые проекты (например саппорт или распланированные последующие версии ПО).
      В ИДЕАЛЕ, менеджер должен сочетать в себе обе эти роли новатор-зануда, но в реальности я не встречал такого баланса.

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

      Хотя, когда настанет пора “платить по счетам”, новенькому менеджеру будет намного проще сказать: “А…, чего же меня ругать-то? Я вообще тут недавно, Вася/Коля/Игорь (имена вымышлены, совпадения случайны :) ) тут год в начале такого наворотили, я потом 2 года пытался привести все в порядок, так и не вышло”. Но вот виновт ли в провале приславутые Вася/Коля/Игорь – вопрос открытый.

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

    5. 2 gnat. В общем, сложно судить, как надо было делать. Но выглядело оно немного того, странно. :) Я как сейчас помню, взял первый раз новый фрэймворк и из него тут же выпало сорок (40!) P1 багов. :)

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

      Кто-то здесь точно был не прав – предлагаю сойтись на этом. :)

    6. 2 Gres – в общем, надо разбираться всегда, кто был виноват, на самом деле. И давать по башке, или наоборот награждать, даже если виновник провала/торжества уже в другом месте. С этим согласен, да.

    7. 2 Anton Kukoba. Антон, ну я надеюсь, ты потом научился внимательно следить за своими детьми (ака прототипами) – как их там последователи используют? :)

    8. 2 Alex

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

      Неа. Я давно в другом проекте, но помню – код тестов не понадобилось перелопачивать под новый фреймворк. Есть такой паттерн проектирования “адаптер”, вот как я понимаю его и применили на стороне фреймворка, чтобы эгм скрестить ежа с ужом.

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

      ———

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

      Знаешь, когда новый фреймворк наконец стабилизировался, то будто пазл сложился. И получилась картинка, похожая на то, что Фаулер называет “technical debt” (http://martinfowler.com/bliki/TechnicalDebt.html). Я имею в виду, когда сперва делается дешевая простенькая эгм подпорка – только для того, чтобы застолбить жирный кусок рынка. А потом полученная сверхприбыль инвестируется обратно, на замену подпорки нормальной вещью. И в результате ты продолжаешь контролировать рынок, но уже с нормальным продуктом.

      Описанный Фаулером трюк вполне респектабельный, спору нет. Но вот чувства тех, кто пользуется “подпоркой” совсем далеки от респекта. Насчет сорока P1 багов это ты не в бровь, а в глаз. Я же успел поработать с тем фреймворком и как пользователь (тестер) – ну гонял с ним тестциклы, как положено. Тогда же и придумал ему backronym по смыслу примерно такой, “пытка даже при прогоне простых тестов, ломается везде и всегда, никогда не работает стабильно”.

      Что любопытно, заказчики тоже это терпели. За свои-то (немаленькие) деньги, прикинь. Кряхтели, жаловались, но терпели. Удивительно. Не по-ни-ма-ю… ну наверно поэтому я и не маркетолог :)

    Leave a reply

    You must be logged in to post a comment.