Pull to refresh

Comments 44

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

З.Ы. Под «коробкой» я имел ввиду то, что это продукт с определенной функциональностью.
Абстрагируясь от тем всех трёх постов, хочется заметить, что Ваши сравнения и аналогии, которые Вы используете для демонстрации абсурдности чего-либо, доставляют.
Only those users with full accounts are able to leave comments. Log in, please.