Желаю смерти большинству IT-проектов

Да-да, именно так.

Я хочу, чтобы большинство IT-проектов ушло из жизни. Более того, хочу, чтобы они вообще никогда не родились. Хочу, чтобы само понятие проектов, применительно к разработке программного обеспечения вымерло, и осталось в далеком-далеком прошлом, как покинувшие эту землю динозавры много миллионов лет назад. А наши дети, лишь улыбались при упоминания слова IT-проект, и рассуждали, а существовали-ли они (проекты) на самом деле, или это все бабушкины сказки.

В чем же причина, моего недовольства?

Определение проекта согласно PMBOK: Временные усилия, направленные на создание уникального продукта или сервиса.

  • Почему команда должна быть временная?
  • почему мы должны собирать временную организацию (проектная команда), которая потом сделает что-то (продукт) и по окончании распадется и передаст это (продукт) в руки других людей, которые видят этот продукт впервые?

Если пытаться рассуждать логично то кажется, что поддержкой должны заниматься те же люди, кто в первую очередь и создал тот или иной продукт. А вот передавать сделанное кому-то другому «Мол, вот вам чудо вам его теперь поддерживать» — не логично. Также нелогично распускать эффективную команду. Люди потратили кучу времени на то, чтобы наладить внутрикомандные взаимодействия, долго притирались друг к другу, а мы пришли и одним махом уничтожили все это, причем зачастую, чтобы пересадить членов эффективной команды в новые временные (пока неэффективные) команды, которым теперь снова надо притираться.

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

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

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

А как вы считаете, есть ли смысл в проектах? поделитесь своим мнением в коментариях.

8 комментариев on “Желаю смерти большинству IT-проектов”

  1. Соглашусь. ИТ- проекты в старом формате испортили заказчика. Нет доверия, уже сразу на берегу тебе руки выкручивают и делают не выгодным проект. А это влечет за собой ТЗ (кто по читает, не понятно) , сложности со сдачей и закрытием. И везде заказчик ждет подвох. Он же знает, что потом будет сопровождение, команда будет другая и надо будет платить за rfc.

  2. Константин Разумовский:

    Мне кажется, не совсем корректно отождествлять временность проекта и разрушение команд. Обратимся к классической статье «New New Product Development Game». Закончив разработку продукта, команда не разрушается — она переходит к созданию нового продукта, целиком или частично. Да, есть проблема того, что новым людям придется поддерживать незнакомый продукт. Но есть и много плюсов такого подхода, главные из которых состоят в том, что ни в одной организации не бывает много звезд, могущих разработать действительно классный продукт, а качества, которые нужны для этого членам команды, могут сильно отличаться от качеств, требуемых для рутинной поддержки.

    • Спасибо за комментарий, Константин.

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

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

      К тому же «рутинная поддержка» это самое сложное что есть в разработке. Я не говорю про первую линию, типа воткните в розетку, а именно о той работе, когда надо непосредственно искать и исправлять ошибки, это точно быстрее и качественнее сделают:
      а) высококвалифицированные специалисты
      б) именно те, которые эту ошибку и написали

  3. Слава Панкратов:

    Привет!

    Слушай, а почему из определения проекта, как временной активности следует, что команда должна быть временной?.. Это раз. А на вопрос «почему одни должны делать, а другие эксплуатировать?» дает ответ психология с определением наиболее предпочитаемого типа деятельности.

    Я согласен, что команда должна жить продуктом, но я также знаю, что на разных этапах жизни команде нужны разные люди. Совсем разные. Так что или смирится с тем, что ты «привязан» к продукту и тебя начнет от него толнить каким-бы хорошим он не был или менять вместе с командой проект/продукт за проектом/продуктов.

    А зачем ты противопоставляешь проекта как время и усилия продукту, который набор решаемых задач?

    • Привет, Слава,

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

      В том-то и дело, что следовать не должно, но у большинства индустрии следует 🙁

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

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

      А зачем ты противопоставляешь проекта как время и усилия продукту, который набор решаемых задач?

      Тут я если честно вопроса не понял 🙂

  4. Oleksiy:

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

    Взгляните на мир с другой стороны. Если объем разрабатываемого функционала снижается, спрос на новинки падает (впрочем, это работа сэйлов), то разработчиков зачастую просто перестает интересовать проект и они стремятся к новым вершинам, т.к. не все мечтают тихо фиксить дефекты 90% рабочего времени, люди расходятся, команды распадаются и собираются. Люди развиваются, делятся знаниями и опытом, расширяют кругозор, круг знакомств etc. И потом, переход на другую компанию/проект — пока самый простой способ поднять должность/зп для разработчика. 🙂

    • В статье прослеживается некий максимализм смешанный с обидой за распавшуюся дружную команду

      Признаюсь есть и то и другое 🙂

      Цель бизнеса — деньги, а не собрание людей по интересам.

      А вот тут хочу не согласиться с вами. Бизнес у которого цель деньги не жилец. Деньги могут быть следствием, но не основной целью.

      Создают и обслуживают автомобили, например, также разные люди и при передачи автомобиля от завода к сервисным салонам, ревности ни у кого не вызывает.

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

      разработчиков зачастую просто перестает интересовать проект и они стремятся к новым вершинам

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

      И потом, переход на другую компанию/проект — пока самый простой способ поднять должность/зп для разработчика.

      Тут вы затрагиваете другой больной вопрос, который достоен отдельного поста :). Здравый смысл подсказывает, что это неправильно. А значит это неправильно и это нужно чинить. Надеюсь все больше и больше компаний станут отдавать себе отчет в этом.

  5. […] Исходя из всего выше изложенного, я приглашаю вас присоединиться к нашему призыву (полностью читаем в статье «Желаю смерти большинству IT-проектов»): […]


Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *