воскресенье, 16 сентября 2012 г.

Халтура.Ру: Как "халтурят" отечественные ИТ-консультанты?


У меня складывается впечатление, что модные словечки типа "аджайл", "скрам", "канбан", "гибкие методологии" постепенно становятся ругательными в профессиональной среде. У такого положения вещей есть несколько объективных причин:

1.      Отсутствие конкретных пошаговых методик ведения ИТ-проектов, которые позволяли бы заканчивать проекты в срок с заданной функциональностью и без выхода за пределы отведённого бюджета.

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


2.      Неточное оперирование фактами. Выдача желаемого за действительное.

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

Недолгий поиск в Google расставил всё на свои места. Оказалось, что на заводах Тойота внедрён не канбан, а Toyota Production System. Это вариант серийного производства, который специально разработан для того, чтобы уменьшить запасы готовой продукции на складах. Основная фишка такой производственной системы заключается в том, что нормы выпуска деталей для каждого производственного участка задаются на основе заказов от дилеров на конкретные марки автомобилей.

Следует сказать, что Toyota Production System действительно использует канбан. Но это просто японское название накладной.

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

Недавно я получил приглашение участвовать в одной из ИТ-конференций. В рамках  этой конференции будет проводиться тренинг одного украинского скрам-мастера (по этическим и гуманитарным соображениям я не сообщаю его имя и фамилию). Привожу фрагмент его рекламной листовки:

"Цели тренинга

·        Заложить мощный фундамент для практикующих Скрам-мастеров, Agile-практиков и будущих коучей.

Аудитория тренинга:

·        менеджеры проектов
·        тим/тех лиды
·        де факто Скрам-мастера существующих проектов
·        все - кто видит себя Скрам-мастерами - агентами по внедрению гибких итеративных подходов разработки.

Участники тренинга научатся

·        объяснять преимущества гибких подходов заказчикам, менеджерам и коллегам
·        знать область применения Скрам
·        понимать принципы, лежащие в основе каркаса Скрам
·        запускать проекты и переводить существующие проекты на Скрам
·        проводить сессии релиз планирования, планирование итераций, демонстрации и ретроспективы
·        пользоваться инструментами визуального менеджмента"

Меня в этой листовке насторожили два обстоятельства:

1.      Текст листовки составлен таким образом, чтобы в каждом предложении встречалось ключевое слово "скрам". Нередко к такому приёму – "повтор" – прибегают рекламисты, которые желают внедрить какое-то ключевое слово (например, название бренда) в память клиента.
2.      Отсутствие упоминания реальных проблем, с которыми сталкивается на проекте технический руководитель или ПМ.

Желая проверить квалификацию автора тренинга, я отослал ему e-mail с вопросами, на которые нетрудно ответить практикующему специалисту. Вот эти вопросы:

1.      В каких коммерческих ИТ-проектах Вы принимали участие?
2.      Какого уровня сложности эти проекты? (тысячи строк кода? десятки тысяч строк кода? сотни тысяч строк кода? миллионы строк кода?)
3.      Какой объём работы в рамках этих проектов сделан лично Вами?

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

Между тем, стоимость участия в тренинге составляет $800.

15 комментариев:

  1. Без предложения альтернативы статья выглядит не законченной.

    ОтветитьУдалить
    Ответы
    1. 1) В данном блоге предлагается альтернатива.
      2) Рекомендую также почитать - http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080008301_2008008500.pdf

      Удалить
  2. Есть бизнес - разработка ПО, а есть придумывание и чтение лекций о разных методологиях. Вторые заинтересованы, чтобы первые купили их книжек, получили провалы по срокам и заказали лекций/консультаций.
    Если и после этого будут провалы, консультант всегда найдет что делалось "не так" и почему задержки "неудивительны" )

    ОтветитьУдалить
  3. Читая такие статьи появляется два вопроса:

    1) если все так плохо, то почему не выгнали всех "коучей" и "тренеров" ссаными тряпками?

    2)И что дальше делать? Где и как обучаться новым подходам? Ведь на своем опыте не всегда получается?

    ОтветитьУдалить
    Ответы
    1. Станислав,

      1) рынок большой - эти деятели долго будут его портить;
      2) можно начать изучение обычного инженерного подхода, например, с чтения этой книги - http://ntrs.nasa.gov/archive/nasa/casi.ntrs.nasa.gov/20080008301_2008008500.pdf

      Удалить
    2. Интересно, сколько фирм делает проекты по этой книге?

      Сходу в ней тоже не нашел способов решения проблем. Мне кажется что описанный там процесс только в NASA и работает.

      Получается что вы сейчас пытаетесь "продать" мне этот подход, но гораздо менее умело, чем продавцы того же скрама.

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

      То что я прочитал в книце по ссылке выше создает ровно обратное впечатление. Это конечно не PMBoK, но близко к нему.

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

      Удалить
    3. 1) По опыту сотрудничества с западными компаниями - как серьёзными корпорациями, так и небольшими стартапами - могу сказать, что адекватный процесс есть у всех.

      Более того, во многих вещах он похож на тот, что описан в руководстве NASA.

      2) У меня нет цели что-либо продать. Вы спросили - я ответил. Я не продажник, я - технарь.

      Удалить
  4. Мне видится, что дело не столько в самих методологиях, сколько в том, кто, как и зачем их применяет. Собственно, это верно для любых инструментов.

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

    Так что, проблема не в том, что гибкие методологии чем-то плохи. Проблема в том, что нам их навязчиво пытаются продать. Многие ведутся. В результате у методологий плохая репутация.

    ОтветитьУдалить
    Ответы
    1. Понятно, что методология должна соответствовать цели. Но, помимо этого, она ещё должна быть адекватной, т.е. предоставлять технологичные инструменты решения задач, а не быть сборником банальных житейских рецептов.

      Удалить
    2. Гибкие методологии вполне адекватны. Они предлагают некоторый способ решения вполне определенных проблем. И предъявляют немалые требования к тем, кто их использует.

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

      Повторюсь, это все не означает, что методологии плохи. Они такие какие есть. Из них можно получить реальную пользу. И я согласен, что упомянутых вами "тренеров" нужно, как тут уже предлагали выше, гнать "ссаными тряпками". А не делается это потому (отвечаю на заданный выше вопрос), что принимающие решение о внедрении той или иной методологии часто не имеют достаточного опыта, чтобы противостоять натиску тренеров, массированной рекламы и т.п.

      Удалить
  5. С уверенностью могу сказать что RUP, управление проектом по ГОСТ и прочие PMBoKи продают не меньше, а если пересчитать в деньгах, то гораздо больше. Рынок только другой.

    ОтветитьУдалить
    Ответы
    1. Вопрос не в продажах, а в халтуре. О ней и речь.

      Удалить
  6. Почему методики, вроде, Microsoft Operation Framework не устраивают? (Если Вы пишете: "Нет, методик").

    ОтветитьУдалить
    Ответы
    1. В своё время И.Л. Викентьев опубликовал хорошую статью - "Методика оценки методик" (http://www.triz-chance.ru/estimation_techniques.html). В статье предлагаются критерии оценки методики. Так вот, на мой взгляд, MOF не удовлетворяет сразу трём критериям из приведённой статьи, а именно:
      1. Доступность изложения методики.
      2. Инструментальность методики.
      3. Затратность методики для Клиента.

      Кроме того, самый большой недостаток MOF - она описывает, что надо делать, но не даёт ответа на вопрос, КАК это надо делать.

      Удалить
  7. > Следует сказать, что Toyota Production System действительно использует канбан. Но это просто японское название накладной.
    Может не совсем накладная, но ваше определение удивительно точное.

    > Оказалось, что на заводах Тойота внедрён не канбан, а Toyota Production System. Это вариант серийного производства, который специально разработан для того, чтобы уменьшить запасы готовой продукции на складах.
    Здесь очень, очень серьезная ошибка. Действительно "Toyota Production System", но не для "уменьшить запасы готовой продукции на складах", а для уменьшения связанного капитала в первую очередь.

    > Основная фишка такой производственной системы заключается в том, что нормы выпуска деталей для каждого производственного участка задаются на основе заказов от дилеров на конкретные марки автомобилей.
    Это только один момент. Есть еще два. И они гораздо прикольнее и существенно сложнее для понимания:
    2. На рабочих центрах с серьезным запасом мощности увеличивай потери на переключение с целью уменьшения размера партии.
    3. Если правило 2 привело к тому, что запас мощности стал небольшим, прекрати уменьшать размер партии и занимайся уменьшением времени переключения.

    Понять это тяжело, но когда поймешь, познаешь дзен.

    ОтветитьУдалить