Пользователь
0,0
рейтинг
30 ноября 2011 в 05:14

Управление → Разработка ПО: 3. Теплое и мягкое

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

image

Странно, но методики, которые родились непосредственно в области разработки ПО совсем не похожи на пришедшие извне.

Например достаточно простой SCRUM, описание которого вполне можно уместить на листок A4, но которым пользуется CERN. Или Agile, который можно описать десятом абзацев где содержатся весьма общие и идеалистические принципы в соответствии с которой был сделан GitHub и много других клевых штук. Можно ли их использовать в строительстве? А при создании самолетов?

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

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



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

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

Отражая реальный мир в программном продукте мы по сути создаем химеру и ее составные части живут по разным законам, управляются по разным законам и могут начать отторгать друг-друга в непредсказуемый момент. Разработка большой универсальной базы данных — это совершенно иное, нежели создание в ней описания связей между деталями автомобиля. Увы, многие менеджеры путают это чаще, чем хотелось бы.

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

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

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

Универсальность — это не всегда хорошо, но всегда хорошо звучит.

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

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

Когда мы моделируем реальный мир мы имеем дело с его объектами, их измеримыми свойствами и их взаимоотношениями.

Программный продукт может предполагать что в него будут заложена модель определенной части реального мира. Реальный мир, в свою очередь, может быть описан так, чтобы его модель было проще занести в программу.

Когда мы считаем это тождественным, то мы начинаем путать теплое и мягкое.

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

Для примера: если мы хотим заняться классификацией и управлением камнями, то нам придется создать класс камень или таблицу в базе данных, описывающую камни.

В наименее затратном виде камни будут унифицированы: камень №1, камень №2, камень №3… В реальном мире не существует идентичных камней. Чтобы описать все камни нужно их полностью воспроизвести. Мы можем ввести в нашу систему множества камней, сгруппированных по весу, и с ее точки зрения унифицированность камней сильно уменьшится, нам будет проще определить к какой из групп относится конкретный камень в реальном мире. Для каких-то задач, информация о том, влезет ли эта группа камней в грузовик, может быть полезной. Вопрос в том, какая степень детализации окажется полезной и насколько эта польза будет сочетаться с затратами.

Чем более тиражурем и неспецифичен объект, тем проще обрабатывать информацию о нем. И тем меньше нужно работы, чтобы создать ПО, которое ее обрабатывает и преобразовывает.

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

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

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

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

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

И если молодой руководитель IT проекта или руководитель группы разработки сейчас видится нам действительно молодым человек в возрасте от 15 до 30 лет, то молодой архитектор (который проектирует здания) попадает скорее в возрастные рамки 30-45 лет и открыв альбом “20 молодых архитекторов” первая ваша мысль будет: “А кто все эти старперы?!”. Просто потому что 5-7 лет обучения и 10 лет практики это достаточно мало даже для того, чтобы хорошо спроектировать даже хрущевку.

В следующей заметке я хочу спуститься на уровень ниже и попробовать на прочность такие понятия, доставшиеся нам в наследство, как заказчик и требования.
mrjj @mrjj
карма
100,7
рейтинг 0,0
Реклама помогает поддерживать и развивать наши сервисы

Подробнее
Реклама

Самое читаемое Управление

Комментарии (44)

  • +2
    Все-таки некоторые принципы можно взять и из строительства.
    Мне кажется если бы программисты, как и архитекторы, были вынуждены думать о том что их проектом будут пользоваться люди, то качество разработки увеличилось бы в разы.
    Программируя большинство подменяет конкретную цель, погоней за формой. Вряд ли архитектору пришла бы мысль строить здание руководствуясь только каким-нибудь особо удобным способом проектирования, не оглядываясь на конечные цели, но в среде программистов такое встречается до обидного часто. В результате возникают моснтруозные «универсальные» проекты, понять логику работы которых представляется весьма затруднительно.
    • +6
      Термин overarchitected возник раньше, чем overdesigned :)
      Это означает что на начальной стадии проекта архитектора мало волновали материалы, конструктив, и прочие «детали» реализации.
      Практически все, что можно видеть в лучших архитектурных альбомах это Overarchitected проекты или как их у нас называют «бумажная архитектура», так как эти проекты очень редко идут дальше бумажного макета.

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

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

      • +6
        Пример overarchitected сайта:
        digitalevent.ru/#program
        Попробуйте покрутить скролл. (Вопрос удобства тут где-то на втором плане.)
        • +4
          По моему очень удобно. И необычно. А это привлекает.
          • 0
            А мне кажется, немного раздражает.
            • +2
              Ну да, тупо диссонанс с направлением скролла на мыши и на сайте.
              Зато горизонталка выглядит свежо и модно (если она присутствует в единичных случаях), это тоже ценно.
          • +5
            С точки зрения дизайнера/маркетолога, необычный интерфейс — это хорошо. Привлекает.
            С точти зрения всех, кто будет этим пользоваться, необычный интерфейс — плохо. Раздражает.
            Есть такой анекдот: «член длинной два метра — очень эффектно и абсолютно непрактично».
            • 0
              ну задача сайта — привлечь внимание к конференции, причем конференции маркетинга.

              Если б это был webmail или банк которым тысячи людей пользуются ежедневно — тогда это было бы плохо.
  • 0
    В предыдущей заметке я сделал вывод о том, что разработка ПО настолько уникальная область что говорить о «схожих областях» человеческой деятельности можно лишь только лишь в целях упрощения понимания некоторых терминов, связанных со стадиями разработки и управления ей.
    — разработка ПО ничем не отличается от других областей.

    Проваливаются и вылетают из бюджета они потому, что софт слишком часто взбрыкивал и отвергал детали проекта. Ну не влезла в систему разузловка из полумиллиона деталей, а все строилось на предположении, что влезет.
    — софт не может «взбрыкивать» сам по себе. Неверно расчитали — вариантов ровно два:
    — заговаривать зубы заказчику, рассказывать о волшебстве программирования
    — переделывать всё за свои деньги

    первый вариант, конечно, удобней с точки зрения исполнителя.

    Аналогия — неверно расчитали нагрузку на плотину, она рухнула и убила сотню человек. Тут заговорить зубы не получится, кто-то должен сесть.
    • +1
      >Аналогия — неверно расчитали нагрузку на плотину, она рухнула и убила сотню человек. Тут >заговорить зубы не получится, кто-то должен сесть.

      это верно для крупных проектов. для средних \ мелких нередка ситуация, когда Вам говорят: «Привет, возможно Вы не в курсе, но мы решили вместо плотины построить каток. И мы считаем что фундамент и стены от плотины вы вполне сможете использовать»
    • +1
      Понимаете, со временем софт до последней строчки написанный на заказ заменяется адаптацией софта из коробки, большой или не очень.

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

      Рано или поздно приведение в соответствии с нуждами натыкается на принципиальные ограничения, которые являются следствием видения разработчиков содержимого коробки, и «софт взбрыкивает». Никакого волшебства.

      А если кто-то утверждает, что учел все подобные технологические риски, то это уже не волшебство а мошенничество.

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

      Утверждение что таким же образом можно спокойно «рассчитать» хотя бы средний программный продукт для нужд конкретного заказчика странно, но хорошо иллюстрирует количество и масштаб провалов на проектах. Претендовать на точные методы там, где их быть не может — это еще одно катастрофическое заблуждение.
  • –2
    Как-то наивно на мой взгляд всё расписано. И дифирамбы Agile, мол, раз строительство не то же самое, то и проектная технология — не подходит.
    Подходит.
    Современная проектная технология допускает прототипы и итерации (PMBoK 2008). Но и дело даже не в этом. Дело в том, что есть процессы производства продукта, и процессы управления. Производство в строительстве и в ИТ — разное. Но управление проектом — достаточно универсально.
    Цена ошибки может быть значительной — например — взломанные сайты Sony если вспомнить. Представьте, если бы за ошибки ну пусть не сажали бы, но штрафовали разработчиков — вы бы стали этим заниматься? Или если бы стали — делали бы вы это по Agile? Я бы 500 раз подумал.
    • +1
      Я вот, кстати, думаю, что в Sony был вполне себе замечательный, идеальный, сертифицированный на каждую запятую процесс управления. Стопицот менеджеров управляли. А в результате получили говно.

      А управление проектом универсально лишь на уровне терминов.
      • 0
        У Sony-japan изначально японские модели управления, означающие дикую стандартизацию и формализацию каждого чиха, а также серьезные кадровые особенности. Увы, со сменой разреза глаз исполнителей магия рассеивается. Я читал достаточно много книг шатовских авторов по японской модели управления и как бы неплохо было бы делать так же. Не взлетело.
        • +1
          Про японское управление отлично написано у Керра (Dogs and demons). Там действительно всё радикально завязано на особенности японского менталитета, с другим народом не сработает, да и с японцами тоже уже не особо срабатывает.
          • 0
            Почему вообще предполагается, что производство программного обеспечения такое другое? Может люди другие?
      • 0
        А то все работающие по agile команды выдают конфетки. Выдать плохой продукт можно при любой методологии.

        > управление проектом универсально лишь на уровне терминов.

        Начну с того, что если терминология одинакова — то разных методов управления быть не должно. Из определений вытекают (теоремы) методы и подходы. Далее, если вы согласитесь с тем, что планирование — неотъемлемая часть проекта — то все хорошие практики (универсальные, насколько это возможно в принципе, и подходящие к ИТ — опробовано неоднократно) описаны, например, в PMBoK (и в других хороших книжках). Если планирование вы не признаете частью проекта, то тогда не называйте то, что делается проектом, а как-то иначе. Потому что проект — это по определению нечто не существующее материально, и существующее только в будущем (которого можно достигнуть только хоть как-то запланировав свои действия).
        • +1
          >Начну с того, что если терминология одинакова — то разных методов управления быть не должно.

          Содержание терминов совершенно разное. Если методика это не учитывает, то она ни о чем.

          У планирования есть разные формы. Некоторые формы, особенно свойственные каскадным IT проектам, имеют свойство систематически вылетать в трубу вместе со всеми заложенными рисками и буферами.
          Чем точнее такое планирование, тем большее количество работы, затраченной на него, также вылетит в трубу.
          • –1
            Чего-то вы пугаете что что-то там систематически в трубу, но я причины чаще всего этого в трубу вижу в обыкновенном разгильдяйстве (всех, и руководства компании в том числе). Еще частые причины в трубу — некомпетентность кого-либо, или нескольких сразу.

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

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

            Я не против agile, но я за то, чтобы не выбрасывать целый пласт знаний под названием управление проектами. И считаю, что agile сам по себе не несет ценности, в отрыве от управления проектом, основанном на планировании, поскольку является лишь процессом разработки/тестирования, а кроме этого в проектах есть еще куча других активностей, о которых почему-то не говорят. И когда мне говорят — давайте делать по agile — я говорю — делайте как умеете, лишь бы в срок и без превышения трудозатрат. И все почему-то делают по задачам.
    • +1
      Да, если штрафовать — мы бы лишились многих продуктов. Изначально разработчики стали аккуратнее (мечта менеджера), но уже потом начнется деградация. Софт, а особенно веб-софт снижает планку допустимого права на ошибку, право на изменение по ходу пьесы, и массу других компромиссов. Разве получили бы мы фейсбук или гугл, если бы разработчики перестраховывались, анализировали все пути развития продукта? Скорость развития технологий сильно замедлилась бы. А там, где есть набор компромиссов — всегда будут дебаты по какой формуле их приемлемо сочетать. И какая проектная методика для каких случаев подходит. И статьи типа этой, про то, что люди начинают неверно оценивать сами аргументы применимости тех или иных методик.
    • 0
      Странно, моей целью не были диферамбы agile, мое мнение заключается в том, что это просто некоторый набор принципов, к которому и так интуитивно приходит много мелких и средних компаний.

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

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

      Санкции за ошибку скорее относятся к вопросам зоны ответственности и обязательств они со своей стороны нарушили соглашение с пользователем? Я вот не уверен, обычно степень ответственности компании, предоставляющей подобные услуги, там крайне невелика.
      • 0
        > И, самое главное, строительство это всегда работа со внешним заказчиком. В IT подобная модель раз за разом демонстрирует свою несостоятельность.

        Вот тут, кстати, интересно. Если бы в айти хорошо работали с заказчиком, то итоговый продукт гораздо качественнее получился бы. А сейчас в этом вопросе с обеих сторон непонимание: исполнитель не хочет работать с заказчиком, потому что не знает, что на встречах делать, а заказчик думает, что исполнитель его мысли читает, и тоже не видит необходимости встречаться поэффективнее.
        • 0
          Так в этом же и есть проблема. Люди в среднем по больнице везде одинаковые: и в строительстве, где всех хорошо формализовано, и в софте, где как выясняется нет. Понять что хочет Заказчик построить и показывать ему промежуточные результаты несоизмеримо проще, чем тоже самое для софта. Говорю, т.к. постоянно имею реальную возможность видеть оба варианта.

          Поэтому нет плохих архитекторов софта (в среднем по больнице, повторюсь), есть объективная сложность конкретной предметной области. Цель проектных методик в строительстве — оптимально построить безопасный дом. В софте — сделать процесс хоть как-то управляемым и прогнозируемым.
      • +1
        > PMBoK носит иконический статус
        В среде разработчиков гибкие методы носят тот же статус. Только структурированы хуже, видимо потому что «кто во что горазд». В моей компании вообще говорят, «по agile может работать та команда, которая хорошо работает и без agile».

        Для проекта важно достигнуть маржи, разработав продукт. Если продукт разрабатывается по методологии разработки (и даже неважно, гибкая она или водопадная), то маржа достигается соответствующим управлением проектом. И для этого необходимо планировать, сроки, бюджет, качество. Хоть одна гибкая методология говорит про оценку бюджета? Нет, они все сконцентрированы вокруг чуть ли не личностей разработчиков, говоря при этом о командной работе. А проект — дело коммерческое, соответственно и подходы должны быть не только организационными, но и финансово-аналитическими. Как добиться максимальной прибыли от проекта (от которой может зависеть премиальный фонд)? Только моделированием — надо построить план и покатать его на сценариях. Хоть одна гибкая технология этим озадачивается? Да нет. Там важно совсем другое. Вот и получается, что гибкие методологии — это только о том, как вместе быстро писать код, но не как управлять (инициировать, планировать, мониторить, завершать) проектами, достигая не только цели — сделать продукт, но и цели — как сделать его с минимальными затратами, в срок и с надлежащим качеством.
        • 0
          >«по agile может работать та команда, которая хорошо работает и без agile».
          Да, я где то выше или ниже написал, что к этой методике очень часто приходят совершенно естественным образом. По своей сути это просто набор общих рекомендаций.

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

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

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

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

          В остальных случаях не нужно с усилием втискивать проекта в рамки каскада.
          • 0
            Я не сравниваю каскад с agile. Я сравниваю управление проектами с agile, и говорю, что в лучшем случае, agile — это процесс разработки ПО (один из). Процесс разработки ПО, может быть и итерационным, и не следователь техникам agile при этом (RUP например). При том, что разработка ведется итеративно, я утверждаю, что планирование и методы управления проектами никуда не пропадают от возможности быть примененными.
            Я веду проекты итерационны, когда это возможно, но делаю это по (внутреннему регламенту конечно) ближе к PMBoK, нежели к agile. Особенно когда в проекте есть разработка устройства с софтом (а в последнее время у меня такие в основном проекты).
            Agile родился не из академической среды, как раз PMBoK более академичен. Agile — изобретение разработчиков, а не менеджеров, поэтому, хоть я сам и работал разработчиком, я его рассматриваю как разработку продукта, но не управление проектом.
    • 0
      Я понял мессадж про agile. Конкретизировать не буду, всё равно не отнимешь.
      Не подскажете, на каких ресурсах у народа голова болит об эффективности?

  • +1
    Неплохой текст, популярно разъясняющий хорошо известный всем архитекторам факт: любая модель только до какой-то степени соответствует реальному объекту.

    В проектном управлении это сродни одному древнему спору — может ли бесконечная система дифференциальных уравнений описать мир.
    • 0
      Я считаю этот момент столь важным для понимания всего остального, что не мог не остановиться на нем. Есть еще один момент, многие продукты не имеют прямого взаимодействия с материальным миром и не воспроизводят его сущности. И их среда в теории полностью формализуема, а множество состояний конечно.
      То есть исчерпывающее описание таки в определенных случаях возможно.
      • 0
        Но они редко нужны кому-то кроме программистов, поэтому об этом вообще мало кто задумывается. Например, модуль для подсчета квадратного корня вполне предсказуем, а вот под «движком сайта» (который как модель вообще говоря тоже условно соответствует реальному миру, точнее сайту) понимают настолько разные вещи, что это превращается в сильно неформализуемый процесс выбора. То, что движок сам по себе формулизуемый нисколько не влияет на обсуждаемую проблематику. (вопросы технологического качества движка тут опускаем).
  • +1
    Что за зверь на картинке?) Сын фотошопа?)
    • 0
      совокот
  • +1
    На Agile Base Camp Kiev 2010 парень рассказывал как внедрил SCRUM в строительной организации. Daily Standup, недельные итерации, ретроспективы.… очень ржачный доклад получился.
  • –2
    Такое ощущение, что Вас где-то кто-то очень обидел.
    По мне так эти методологии направлены именно на предложение способов. Сами по себе они не гарантируют никакого результата. Но в зависимости от того как Вы их применяете — результат будет разным.
    Ведь правда сложно будет представить, что все проекты делаются итерациями? Или же только каскадными? Или вообще как делают военные: одновременно запускают 3-4 параллельных проектов, а там какой выживет:)
    Не обращайте Вы столько внимания на фанатиков.
    • 0
      Вовсе нет.

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

      Крупные военные вроде DARPA, ну или NASA знают толк в своем деле, у них целый пантеон подходов, сильно варьирующихся от программы к программе.

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

      И когда во главу угла ставится решение, а не уникальность процессов в конкретной организации, которые часто и является тем, что принесло деньги на заказ или адаптацию подобных штук. Как только возникает вопрос о серьезном изменении архитектуры решения и софта, а не процессов в организации, начинаются проблемы и провалы.
      • 0
        Поверьте, не все там так плохо. Я работал в компании, которая оказывала как раз услуги по автоматизации бизнес-процессов. И в каскадной схеме есть достаточно большое количество плюсов и веских причин. Другое дело, что на практике никто на 100% не следовал этой схеме.
        Если Вы попытаетесь с нуля автоматизировать уникальность процессов на крупняковом бизнесе, то это надолго. Пока напишется система — 1-3 года далеко не из 1-го программиста. И кстати, она никогда не будет закончена. Доработки будут всегда. А это не малое количество денюшек.
        А когда процессы можно автоматизировать за полгода. Да, они не будут удовлетворять уникальности. Да, будут шероховатости. Да, они не позволяют делать ряд вещей, или же заставят делать дополнительные действия. Но зато они покрывают ряд проблем уже сейчас. И в дальнейшем вложения минимальны.

        Тут наверно больше вопрос в том, что более выгодней для компании. А тут все просто: «листочек, ручка, калькулятор и вперед».
        • 0
          >Если Вы попытаетесь с нуля автоматизировать уникальность процессов на крупняковом бизнесе, то это надолго. Пока напишется система — 1-3 года далеко не из 1-го программиста. И кстати, она никогда не будет закончена. Доработки будут всегда. А это не малое количество денюшек.

          Мне кажется, когда все стороны это понимают, то процесс изначально можно поставить более внятно, с другой стороны с точки зрения вендора/внедренца — главное втянуть. Если есть явные итерации, не этапы, а именно итерации когда промежуточная стадия работоспособна, то со стороны заказчика появляется возможность сделать ручкой и перевести проект в режим support-only. Это обоснование каскада политического характера.

          Ну и, разумеется, больной вопрос какая часть системы пришла в коробке. Если это действительно крупняк, то мое мнение совпадает с Bernard Mathasel, который в одном из немногочисленных интервью однозначно характеризовал крупные ERP системы сторонних разработчиков как тупик, ниша для которого скоро стагнирует.

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

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

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

          >Другое дело, что на практике никто на 100% не следовал этой схеме.
          Она просто избыточно сложная. Это как техдокументация, которую после первой трети пишут абы как и никто не читает.
          • 0
            А Вам не кажется, что SaaS — это вообще-то все та же коробка. Только схема работы организована таким образом, что они стоят дешевле.
            • 0
              > люди готовы отказываться от кастомизации, чтобы не гемороиться с процессом внедрения

              Даже больше чем обычная коробка, так как в коробке еще инфраструктура. Мне просто кажется, что сократится количество компромиссов, либо коробка или сервис почти без кастомизации, либо собственные решения.
              • 0
                А мне кажется появятся (и получат популярность) сервисы с кастомизацией. Типа как есть сейчас платформа 1С: Предприятие, есть коробочные решения на базе её, как от самой 1С, так и от третьих фирм, и есть «внедренцы», кастомизирующие коробочные решения (или же пользователи кастомизируют своими средствами). Как мне кажется, популярность 1С во многом обеспечена этой моделью и вряд ли её пренебрегут в «облаках».
              • 0
                Конечно, сократится количество компромиссов. В сервисе Вам просто поставят в рамки, и все. Ну и как это Вас приближает к идеи уникальности бизнес процессов?

                З.Ы. Когда-нибудь сервисы дойдут и до возможности кастомов, и будет коробка с кастомами. Только дешевле и без аппаратуры на стороне клиента. Правда дешевле.
            • 0
              Для пользователя может и выглядит как коробка с абоненткой, для разработчика-владельца инфраструктуры в целом — во многом другие процессы, в чём-то более удобные для него, в чем-то менее. Например, с одной стороны сам продукт сложнее, да ещё его надо обеспечить инфраструктурой и администрировать, с другой — между администраторами и разработчиками куда меньше барьеров, они сотрудники.

              • 0
                Простите, но вроде как, по чистой случайности, наверное, не затрагивались вопросы реализации. Естественно, сервис имеет свои технические особенности и сложности.
                Речь идет больше о функциональности. С точки зрения тех кому это внедряется, и что в дальнейшем будет. То бишь о потребителе.
                Это не значит, что кто-то хуже, а кто-то лучше. Это значит, что каждый из них имеет свои плюсы и минусы. Каждый решает какую-то часть задач. На внедрение каждого уходят разные сроки. И выход с них разный.

                З.Ы. Под «коробкой» я имел ввиду то, что это продукт с определенной функциональностью.
  • +1
    Абстрагируясь от тем всех трёх постов, хочется заметить, что Ваши сравнения и аналогии, которые Вы используете для демонстрации абсурдности чего-либо, доставляют.

Только зарегистрированные пользователи могут оставлять комментарии. Войдите, пожалуйста.