Аллюр три креста, или Почему проекты так трудно закончить в срок

Один крест (+) означал, что посыльный мог ехать к месту назначения шагом, два креста (++) означало рысь, три креста (+++) — незамедлительный галоп. Поэтому в армии галоп носил неофициальное название аллюр три креста, а позже это выражение вошло в русский язык, имея смыслом максимально быстрое выполнение поручения начальства. [Википедия]
Tar pit (англ., дословно смоляная яма) — 1) неразрешимая проблема, 2) битумное озеро (место, где подземный битум выходит на поверхность, создавая участок природного асфальта). [Англо-русский словарь] Животные, попавшие в битум, не могут выбраться обратно, поэтому такие озера являются отличным местом для раскопок доисторических скелетов [Википедия].

«Воображение представляет динозавров, мамонтов и саблезубых тигров, пытающихся высвободиться из смолы. Как бы ни был силен или ловок зверь, в конечном итоге ему уготована гибель. Такой смоляной ямой в последнее десятилетие было программирование больших систем...» [1, с.16] С этого яркого образа начинается классическая книга Фредерика Брукса, впервые увидевшая свет в далеком 1975 году. Другая классическая книга, опубликованная в столь же древнем 1987-м, начинается ничуть не лучше: «А в это время где-то гибнет проект» [2, с.23]. Идут годы, человечество вступает в новое тысячелетие, но и в 2014 году очередной бестселлер начинается все с той же вечной истории: «3 марта 2010 года Федеральное бюро расследований решило приостановить свой крупномасштабный и многообещающий план модернизации управления информацией… В бюро пытались обновить свою компьютерную систему уже более десяти лет, и, похоже, их постигла катастрофа» [3, с.14].

Через 44 года после Брукса мы можем с чистой совестью повторить: сейчас, когда вы читаете эти строки, очередной проект, подобно своим предшественникам, тонет все в той же смоляной яме. Шансы на успех в управлении проектами меньше, чем при подбрасывании монетки, и не похоже, чтобы они сильно росли:



По данным CHAOS Studies от Standish-Group [4]

Почему прогресс в науке управления (воплотившийся в 6 изданий PMBoK и нескольких десятках других толстых книг) за 40 лет (!) так и не привел к улучшению качества самого управления (если, конечно, под качеством управления понимать вероятность прибытия в заданную точку)? Чтобы разобраться с этим вопросом, начнем с основной проблемы любого проекта, обозначенной во всем известной книге Брукса.

Первая проблема: сложность создаваемого продукта


Если спросить первого попавшегося айтишника — «Что главное в Мифическом человеко-месяце?» — ответом скорее всего будет: «Что все человеко-месяцы разные, у новых работников совсем не те, что у старых». Даже сам Брукс называет «законом» положение, сформулированное в самом начале книги («Если проект не укладывается в сроки, то добавление рабочей силы задержит его еще больше»). Но это лишь эмпирическое наблюдение, известное каждому, что хоть раз «менял коней на переправе»; вопрос заключается в том, как же планировать проект, когда все человеко-месяцы — разные?

«Мифический человеко-месяц» потому и стал бестселлером, что дает ответ на этот вопрос. Вот как Брукс формулирует свое понимание основной проблемы проектирования:

"… классические трудности разработки программного обеспечения проистекают из этой сложности сущности и ее нелинейного роста при увеличении размера. Сложность служит причиной трудности процесса общения между участниками бригады разработчиков, что ведет к ошибкам в продукте, превышению стоимости разработки, затягиванию выполнения графиков работ. Сложность служит причиной трудности перечисления и тем более понимания всех возможных состояний программы, а отсюда возникает ее ненадежность… Сложность структуры служит причиной трудностей при развитии программ и добавлении новых функций так, чтобы не возникали побочные эффекты..." [1, с. 167]

Принципиальное отличие проекта от любого другого производства заключается в том, что создаваемый в нем проект производится впервые [мы в курсе, что многие задачи вроде «прикрутить счетчик посещений на сайт» тоже называются «проектами», но речь-то о настоящих проектах]. Как и любая реальная вещь, этот новый продукт (неважно, программный или «аппаратный») состоит из большого числа компонентов, способных на самые неожиданные взаимодействия (как негативные — талидомид, так и позитивные — виагра). Предвидеть заранее, как все это будут работать вместе, чрезвычайно сложно, и для этого требуются в буквальном смысле «лучшие умы», а вовсе не бесконечные «человеко-месяцы»:

«Выдающиеся проекты создаются выдающимися проектировщиками. Создание программ является творческим процессом. Крепкая методология может придать силу и освободить творческий ум, но она не может воспламенить или вдохновить того, кто занят нудной работой… Поэтому… я считаю, что единственное и наиболее важное усилие, которое мы можем предпринять — это развивать способы воспитания выдающихся проектировщиков» [1, с. 185-186]

Из основного положения Брукса (проектирование это творчество, а творческий процесс невозможно осуществлять толпой) прямо вытекает все реальное содержание «Мифического человеко-месяца»: и требования «диктатуры архитекторов», и «эффект второго проекта», и рекомендация «планируйте выбросить первую версию». Но из него же следует и самый забываемый тезис Брукса — что в управлении проектами «нет серебряной пули»! Сложность проектов объективна, ее невозможно преодолеть ни с помощью новых языков программирования (даже графических), ни подключением искусственного интеллекта. Справляться со сложностью приходится каждый раз заново, и если таланта проектировщика для этого не хватит — проект не будет успешным.

Главный враг проекта по Бруксу — сложность создаваемого продукта. С каждой строчкой нового кода, с каждой страницей технологической документации эта сложность растет, и растет нелинейно. А одновременно с этим в распоряжении менеджера остается все меньше ресурсов — как времени, оставшегося до конца проекта, так и денег, оставшихся до конца бюджета:



В точке пересечения, или незадолго до нее становится ясно, что на самом деле проект требует намного больше денег и времени, чем предполагалось первоначально:

К следующему проекту, названному «Страж», ФБР приступило сразу, в 2005 году. Цена вопроса — 451 миллион долларов, и система «Страж» будет полностью работоспособной в 2009 году… В марте 2010 года компания Lockheed Martin, подрядчик, опаздывала на год, осуществив лишь половину проекта и потратив 405 миллионов. Для завершения, по оценкам независимых экспертов, ей потребовалось бы еще от шести до восьми лет, и дополнительно 350 миллионов долларов. [3, с.17-18].

Но позвольте! Если мы с 1975 года знаем, что сложность проектов растет, к примеру, квадратично, — что мешает точно так же квадратично увеличивать бюджет и команду? Почему все новые поколения менеджеров продолжают вести проекты с прогнозируемой успешностью в 30%, когда можно просто добавить денег?

Вот теперь пришло время перейти к следующей книге.

Вторая проблема: сложность совместной работы


Как мы уже знаем, появившийся через двенадцать лет после «Мифического человеко-месяца» мировой бестселлер «Peopleware» («кадровое обеспечение», переведенное на русский как «Человеческий фактор») начинается с констатации высокой смертности проектов. «Около пятнадцати процентов проектов кончились ничем… В случае крупных проектов картина еще хуже, крах постиг двадцать пять процентов проектов, длительность которых составляла от двадцати пяти человеко-лет» [2, с.24] Это написано в 1987 году (еще был жив СССР!), со ссылкой на исследования 1981 года (еще был жив Брежнев); а что у нас на сегодняший день?



По данным CHAOS Report 2015 [5]

Средний разработчик стоит сегодня 100К долларов в год, добавив накладные расходы, получим, что 25 человеко-лет — это примерно 3-6M долларов. Как видите, с тех давних лет ситуация не изменилась: провал ожидает 26% средних проектов и 43% больших, и мы ничего не можем с этим поделать. Но почему так происходит? Демарко и Листер спросили разработчиков о причинах провалов, и вот что получили в ответ:

«В подавляющем большинстве случаев не было ни одной объясняющей неудачу причины из области технологии. Чаще всего участники наших опросов в качестве причины краха называли »политику"

Вовсе не сложность разрабатываемого продукта, и не недостаточность ресурсов, как можно было бы ожидать, глядя на «крест Брукса»! «Политика», взаимоотношения людей внутри и вовне команды (то, что Демарко и Листер предпочли назвать «социологией») — вот что по мнению разработчиков больше всего мешало добиться успеха.

Вдумайтесь в этот факт: те самые люди (разработчики, начальство и заказчики), которые на первый взгляд были больше всего заинтересованы в успехе, объединившись ради проекта, устраивали в нем «политику», чем и доводили проект до краха! «Мы встретили врага, и он это мы» [6]; у проекта обнаружился второй злейший враг — его собственная команда.

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



Рис. 2 из статьи Putnam, Myers [7]

Собрав численные характеристики 491 проекта по разработке программ от 35 до 95 тысяч строк кода, Патнэм и Майерс пришли к результатам, в которые практически невозможно поверить. Сопоставимые по размерам проекты завершались командами разной численности практически в одно и то же время, причем командам большей численности требовалось не меньше, а больше времени. Закон Брукса («добавить разработчиков — замедлить проект») оказался работающим не только при угрозе срыва проекта, но и с самого начала, начиная с добавления девятого программиста. Если представить те же результаты в терминах пресловутых человеко-месяцах, получается еще более выразительный график. Сколько денег (в месячных окладах) требуется, чтобы решить одну и ту же задачу силами команд разной численности:



Рис. 3 из статьи Putnam, Myers [7]

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

Книга Демарко и Листера содержит массу примеров «социологии», подменяющей работу над проектом работой по поддержанию «порядка» в коллективе. Офисы опен-спейс, где начальству видно, кто отлынивает от работы (а работники постоянно отвлекают друг друга); детальное планирование и постоянные требования выдерживать сроки (заставляющие торопиться и ведущие увеличению числа ошибок); мелочная регламентация (заставляющая тратить массу времени на отчетность о проделанной работе и сдвигающая мотивацию работников с кода на «бумажку»). Все эти меры кажутся необходимыми для организации совместной работы — но, будучи применены в полном объеме, на саму работу уже не оставляют времени.



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

Но что если поменять сами принципы организации совместной деятельности? Демарко и Листер рекомендовали это еще в 1987 году: Чтобы эффективно управлять людьми в области интеллектуального труда, необходимо принимать меры, противоположные перечисленным выше. [т.е. регламентации, стандартизации, работы под страхом увольнения и запрета на какую-либо инициативу]. Предполагалось, что в Peopleware достаточно ясно написано, как должны выглядеть «противоположные» меры [на самом деле, нет]. Посмотрим еще раз на график успешности проектов. И где результат от книги, до сих пор входящей в must read любого менеджера? Что-то не видать.

Так почему? Неужели на пути к эффективному управлению проектами стоит еще один крест?

Третья проблема: сложность планирования нового


На первый взгляд, третье препятствие на пути к совершенному управлению проекта заключается в необычности правильного способа руководства творческим процессом. Один из таких способов, ныне широко известный как Scrum, был описан в статье [8] еще в 1986 году, даже до выхода «Peopleware». Уже через несколько лет, в 1993 году Джефф Сазерленд впервые применил в своем проекте отдельные элементы Scrum, и остался доволен результатом:

Мы сдали комании Easel программный продукт в срок, уложившись в шесть месяцев, не выйдя за рамки бюджета и с минимальным количеством ошибок, — раньше такого никому не удавалось сделать

Однако подробное описание основных идей Scrum было издано лишь через двадцать лет, буквально на днях, в 2014-м году [3]. Все это время Scrum существовал как полусектантская методология, передаваемая буквально от учителя к ученику, и набирал популярность исключительно за счет «сарафанного радио». Все дело в том, что основная концепция Scrum, прямо вытекающая из его философии, не вписывалась в любую разумную логику управления:

Вот о чем я постоянно твержу руководству: «Я смогу назвать срок, только когда увижу, насколько эффективно будет действовать команда» [3, с.28).

Если понимать под «управлением проектом» обеспечение создания продукта с заданными свойствами в заданный срок в пределах бюджета, получится, что Scrum вовсе не является «управлением»! Центром философии Scrum является категорический отказ от придумывания «заданного срока» с потолка (в отрыве от реальной команды и ее производительности), а первым следствием такого отказа — полностью нетрадиционный подход к планированию проекта:

Я пошел к главе компании и заявил, что мы отказываемся от диаграмм Ганта. Возмущенный услышанным, он потребовал объяснений.
— Со сколькими диаграммами Ганта вы сталкивались за свою профессиональную деятельность? — спросил я.
— С сотнями, — сказал он.
— Сколько из них соответствовали действительности?
— Ни одна, — ответил он, на минуту задумавшись.
Тогда я объяснил, что вместо никому не нужных графиков и таблиц к концу месяца мы дадим ему часть вполне работоспособной системы, которую он сам сможет опробовать и воочию убедиться, в правильном ли направлении идет разработка"
[3, c.50]

В рассказываемой Сазерлендом истории босс согласился попробовать. Но мы знаем, что такое «ошибка выживших», и прекрасно понимаем, что на одного такого босса найдется десять, которые пошлют подальше подобного «менеджера проектов». Что за бред, платить деньги под честное слово, что «мы будем работать и через месяц кое-что покажем»? Какой идиот так делает?

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

Идеология Scrum настолько противоречит общепринятым представлениям о проекте («Заказчик обязуется оплатить, а Исполнитель выполнить следующие работы...»), что впору задаться вопросом: а почему Сазерленд вынужден был пойти на такой революционный шаг? Неужели нельзя было оставить диаграммы Ганта «для галочки» и сосредоточиться на организации работы команды (например, на ежедневных совещаниях стоя, в которых многие видят самое главное в Scrum)?

Судя по горячности, с которой Сазерленд атакует в своей книге «диаграммы Ганта», нельзя:

При управлением проектами традиционно требуется наличие двух вещей — подконтрольность и предсказуемость. Такой подход неминуемо приводит к возникновению огромного количества документации, таблиц и диаграмм… Месяцы труда тратятся на то, чтобы предусмотреть все до мельчайших деталей, не допустить ни единого сбоя, не перерасходовать финансовых средств и продвигаться согласно графику. [3, c.23] Беда лишь в том, что как только этот превосходно отточенный план сталкивается с реальностью, он сразу рассыпается в прах. Но вместо того чтобы выбросить в мусорную корзину и сам план, и свой подход к нему, руководители делают вид, будто план работает… По сути, они платят людям за то, что те им лгут. [3, с.20]

Платят за то, что им лгут — вот в чем дело! Составление детального плана и сметы проекта (обобщенно называемых Сазерлендом «диаграммой Ганта») не только само по себе требует значительных трудозатрат, но и ведет к принятию огромного числа проектных решений на основе фантазий планировщиков. Будучи утвержденными заказчиком, эти фантазии оказываются обязательными к исполнению, поскольку на них теперь завязан авторитет начальства («у нас все идет по плану!»). Результат вполне предсказуем:

Как правило, руководство не в курсе, что проект катится в пропасть, по крайней мере до того момента, пока не будут растрачены впустую миллионы долларов и тысячи часов работы [3, с.23]

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



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

Хочешь быстрее — тормози! [9]


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

Почему так происходит? Что за проклятие тяготеет над проектированием новых вещей? Да все то же — сложность. Как только вместо борьбы с самой сложностью (упрощения) мы пытаемся взять ее под контроль с помощью другой сложности — вызванный демон набрасывается на нас с новой силой. Единственный способ справиться с проектом — это справиться со сложностью.

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

  • [1] Брукс Ф. «Мифический человеко-месяц или как создаются программные системы», СПб, Символ-Плюс, 2007
  • [2] Демарко Т., Листер Т. «Человеческий фактор: успешные проекты и команды», СПб, Символ-Плюс, 2005
  • [3] Сазерленд, Джефф. «Scrum. Революционный метод управления проектами», М., Манн, Иванов и Фербер, 2016
  • [4] de.wikipedia.org/wiki/Chaos-Studie
  • [5] CHAOS REPORT 2015
  • [6] We have met the enemy
  • [7] Putnam, Myers «Familiar Metric Management — Small is Beautiful-Once Again», 1998
  • [8] Такеучи, Нонака «Разработка нового продукта: новые правила игры» (1986), русский перевод
  • [9] Маковецкий П.В. «Смотри в корень!», М., 1966

Средняя зарплата в IT

120 000 ₽/мес.
Средняя зарплата по всем IT-специализациям на основании 9 423 анкет, за 1-ое пол. 2021 года Узнать свою зарплату
Реклама
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее

Комментарии 30

    +3
    Чуть слезу не пустил. Прям каждая буква по самому больному. Может в стартапах как-то поадекватнее, но я всю жизнь по корпорациям и «политика» здесь самое невыносимое. А еще для управления внутрикорпоративными сложностями используются 100500+ внутренних корпоративных ресурсов, вносящих неверноятную сложность даже в самые простые действия. Ох.
      +1
      Может в стартапах как-то поадекватнее

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

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

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

        +2
        Из моего личного опыта, в стартапах меньше политики, но зато намного больше так называемых «отношений». На хабре регулярно появляются статьи про «типичные ошибки стартапов», в которых большими буквами пишут: «не делайте стартап с друзьями». Так что если выбирать между корпорациями и стартапами, то еще неизвестно, где хуже.
        +2
        Использовать гениальных проектировщиков, умеющих отсеять лишние требования и организовать оставшиеся в «собирающуюся» систему.
        «Эффективные менеджеры» не просто не понимают этого — они этого не умеют в принципе! Понимание того что не все работники — ресурс/биомасса очень противоречит как их ЧСВ так и очень распространенным сейчас в западном обществе левацким взглядам про равенство-братство.
        Вот теперь мы можем понять, почему не работает способ «просто добавьте денег».
        Очень даже работает, только иногда надо просто сократить-заменить команду на пару-тройку тех самых гениальных и платить им эти «добавленные деньги».
          +2
          Если мы с 1975 года знаем, что сложность проектов растет, к примеру, квадратично, — что мешает точно так же квадратично увеличивать бюджет и команду? Почему все новые поколения менеджеров продолжают вести проекты с прогнозируемой успешностью в 30%, когда можно просто добавить денег?

          Да, многие недооценивают и не понимают, насколько быстро растет квадратичная функция. Да, даже x^(3/2). Представьте, что вы потратили на написание программы 1000 у.е. за 1 год и вы заработали 10 000. У вас поступили заказы (в 10 раз больше), вы уже тратите 100 000 в год (100 раз) на написание новых функций, прибыль выросла в 10 * log 10. Продолжая рост в таком темпе, уже в следующем году расходы составят не 10 млн, а 232 млн!

          1 000 ^ 1.67 = 100 000
          100 000 ^ 1.67 = 240 000 000

            0
            И это еще мы не упоминаем о том, что в модели COCOMO оценка стоимости программного обеспечения является экспоненциальной (что гарантированно хуже любого полинома!). К счастью, с относительно небольшим коэффициентом в показателе экспоненты. Но общий принцип остается тем же: если можно разработать три продукта по 100k строк вместо монолита за 300k строк — это немедленно следует ровно так и делать. А вот уж как обеспечить возможность деления продукта, чтобы команды могли разрабатывать, тестировать и деплоить свои компоненты независимо — это и есть главная головная боль менеджера проектов и архитектора. Микросервисы, ООП, interface-based programming, плагины, embedded scripting и прочее в помощь…
              +3
              В обсуждении на фейсбуке мне упомянули микросервисы (именно «три проекта по 100К строк вместо одного на 300К») и их ближайшую перспективу — возникновение проблем с проектированием их взаимодействия.
                +4
                «От проблем нельзя избавиться, но можно время от времени менять одни на другие» ©.

                Сам по себе микросервис не решает проблему сложности. Потому что — ну в самом деле, что такое микросервис: ну вытащили мы некий код в отдельное адресное пространство. Ну перестали передавать этому куску кода параметры через стек и регистры, а стали сериализовать и толкать через REST API, например. Тут сложность скорее увеличилась, а не наоборот.

                Но если сервис выделен правильно, и архитектура системы изначально такая, что это (правильное!) выделение возможно — тогда вдруг происходит чудо: пользователи сервиса видят красивое и прозрачное API, и сложность выделенного сервиса перестает влиять на сложность остального приложения.

                Приведу пример: при взаимодействии с промышленным оборудованием, оно обычно подключается через последовательный порт. И там все более-менее просто. Но в какой-то момент мы начинаем подключать его через TCP/IP — и (почему-то!) не замечаем, что теперь у нас задействовался TCP, congestion control, весь стек сетевых драйверов, NAT и прочие прелести ядра Linux. Поскольку это все там изолировано, и оттуда торчит только fd (file descriptor), единый как для сокета, так и для последовательного порта — сложность нашего куска системы практически не изменилась.

                Мне кажется, что предупреждения в фейсбуке связаны с тем, что иногда встречается без(д)умное деление системы на микросервисы. При этом они не оказываются логически законченными и изолированными — и мы получаем тот же кошмар масштаба, что и в монолитном приложении, но приправленный еще и чисто специфическими возможными проблемами в контейнеризации, service-discovery, мониторинге и т.п.
                  +3
                  Вот да, реальное решение проблемы — это архитектурно правильное выделение сервиса. А массовое решение — это «все переводим на микросервисы». В результате лет через пять (а может и уже) от них начнут перебегать к какой-нибудь новой модной технологии.
                    0
                    мы начинаем подключать его через TCP/IP — и (почему-то!) не замечаем

                    Не замечаем, пока не протечёт абстракция, а после того начинается тюнинг параметров, отключение алгоритма Нагла, переписывание с TCP на UDP с собственным контролем перегрузки и противодействия потерь.
                    А с распределёнными системами ещё и возникает скрытое состояние в виде сообщений-в-транзите, которое человеку осознать довольно тяжело.
                      0
                      Мы тут дискутируем с коллегой на эту тему периодически. На мой взгляд проблема с микросервисами в том, что по сути предполагается, что они реализованы плюс-минус идеально и никому не надо лезть внутрь для поддержки и развития. А если уже понадобилось соответствовать, то выбросили старый и написали другой. Проблема в наших спорах одна — коллега он такой чистый теоретический программист уровня спикера митапов, а я прикладной математик — 3Dшник. Для него микросервис это блок кода, а для меня в нём возможно запрятан сложный вычислительный алгоритм с прибамбасами. Который реализует какую-то бизнес-логику и требования к ней, в отличие от протоколов TCP/IP могут измениться из разряда «а теперь котики умеют летать».
                      В таком варианте микросервис, на мой взгляд, оказывается адским адом поскольку, во первых, предполагается, что внутри «ящика» разработчик может делать что угодно, главное чтобы интерфейс был удобным. А во вторых… Во вторых по сути поддержка этого дела ничем не отличается от поддержки блока кода кроме усложнённых взаимодействий с внешними элементами системы.
                      А переписать какой-нибудь тесселятор для извращённых геометрий, на который потратили полтора года с нуля — утопия, которую никакому менеджменту не продашь.
                      Так что, как мне кажется, в мире систем с долгим жизненным циклом и сложными компонентами это чревато наоборот деградацией в возможности поддержки и развития кода.
                0
                Я не из ИТ. Занимаюсь инженерными и строительными проектами. Но всё тоже, всё также. «Политика» очень быстро начинает съедать слишком много времени. Большие инженерные команды приводят к отвратительным интерфейсам между дисциплинами. А человеко-месяц опытного инженера не равен даже человеко-году стажёра. Работу опытного инженера не выполнет отдел новичков.
                Жаль, что в инженерии и строительстве метод Scrum неприменим.
                  +2
                  У Сазерленда упомянут «сосед», который сделал себе ремонт дома по Scrum. Так что возможно скрам в строительстве и применим. Другое дело, что никакой скрам не сделает из новичка профессионала — если никто в команде не знает, как правильно сделать Х, Х будет сделано неправильно.
                    0
                    Только что прочитал про ремонт дома «по Scrum». Думаю, я плохо представлял себе методику Scrum. Если всё так, как описано в книге «Scrum» Джефф Сазерленд, то это так, как начинают работать при авралах на строительстве, когда срок окончания не за горами, а сделано мало. Не всегда так, конечно. Но это и понятно. Когда строится большой промышленный объект где-то в Приморском крае и в ходе очередного утреннего обсуждения стало ясно, что нужно купить ещё кабеля, фермы перекрытий нужно укреплять и что-то ещё, не важно что, легче от этого не станет никому. Срок поставки кабеля будет около двух месяцев или он станет золотым по цене, фермы изготавливают пол-года, да и другие проблемы решаются за недели.
                    Я подозреваю, что проблема была в том, что методологии управления инженерными и строительными проектами, когда нужно предусмотреть необходимые ресурсы за пол-года, год, но проект по своей сути не нов, а отличается от ранее реализованных какими-то деталями, масштабом или чем-то ещё стали применять в программировании. Где всё не так.
                      +3
                      Пожалуй, Вы правы, первоначально методологии создания больших программных систем были позаимствованы из «хардварных» проектов, с их обязательными задержками по поставкам комплектующих и (взамен) работоспособностью комплектующих. В программировании же «сборка» проекта из готовых модулей стала работать только в последние десятилетия (когда появилось достаточное количество таких модулей-библиотек). А до этого приходилось фактически каждый раз создавать кабеля, балки и фермы заново, с непредсказуемой работоспособностью. В результате методология, отлично работавшая например в строительстве, оказалась не помощником, а тормозом.
                    0
                    Очень даже применим. Смотрите опыт аэропорта Анапы. Смотрите Евгения Пикулева (http://featmanagement.ru/) из Базэл Аэро. Руководитель проектов по строительству нового/ реконструкции старого аэровокзалов аэропорта Анапы.
                    +1
                    «Я смогу назвать срок, только когда увижу, насколько эффективно будет действовать команда»
                    Старик и путник (длинная версия)
                    По дороге в безлюдной местности шёл путник. А у дороги под деревом в глубокой медитации сидел, закрывши глаза, старик. Путник подошёл к старику и, не обращая внимания на его медитацию, громко поприветствовав его, спросил:
                    — Почтенный, долго ли мне ещё идти до ближайшего города?
                    Старик открыл глаза, и, как будто не выходя из своей медитации, махнул рукой в ту сторону, куда шёл путник и сказал:
                    — А ты иди.
                    Путник понял, что с ним не хотят разговаривать. Обидевшись, он отвернулся от старика и быстро зашагал дальше по дороге. Но, пройдя лишь с десяток шагов, путник услышал позади голос старика:
                    — Если так будешь идти, дойдёшь до захода солнца
                      0
                      Почему проекты так сложно закончить в срок и почему Scrum в этом не поможет? На практике по классике проектного управления при использовании проектного треугольника ограничений (сроки, деньги, функциональность) обычно гонятся за необходимостью обеспечить полную функциональность, отраженную в ТЗ, конечно же по ходу проекта появляются новые требования или существующие проходят уточнения. Отсюда плывут деньги и/или сроки.
                      Что предлагает Scrum? По мнению одного из авторов agile манифеста необходимо фиксировать не функционал, а сроки и деньги. И вот тут и получается, чтобы сделать проект вовремя и в бюджете приходится жертвовать функционалом. Так что опять же на практике бизнес на такое обычно не идёт. Топам нужно понимать, когда деньги вернутся от проекта. Scrum молчит на этот счет.

                      По проблемам: сложность продукта?
                      А разбивать на более мелкие части? Подпроекты? Фичи? В соответствии с ними дробить одну большую команду на несколько мелких? Да и планировать мелкие фичи (подпроекты) удобнее. И не надо детально плнировать, достаточно roadmap сделать.

                      Идем далее. Можете назвать сроки после понимания эффективности команды? И Топы вам такое позволяют? Скажите, где это — мы идем к вам. Обычно же сроки всегда! ограничены. Может не называются топами, но в голове у них они есть. Так что…

                      А все проблемы в проектах из-за людей, из-за их неумения коммуницировать, из-за низкой коммуникативной компетенции руководителя проекта.
                        +2
                        Что все проблемы от людей — это Вы самую суть ухватили! :)
                          +1

                          Как говорил товарищ Сталин — у каждой проблемы есть ФИО

                          0
                          По мнению одного из авторов agile манифеста необходимо фиксировать не функционал, а сроки и деньги.

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

                          А разбивать на более мелкие части? Подпроекты? Фичи? В соответствии с ними дробить одну большую команду на несколько мелких? Да и планировать мелкие фичи (подпроекты) удобнее. И не надо детально плнировать, достаточно roadmap сделать.

                          А всё вместе оно у вас заведется так сразу, как вы ножкой топнете?
                          Разбиение уменьшает сложность, но только частично. Оставшаяся часть сложности просто перемещается на уровень выше (уровень взаимодействия ваших частей, подпроектов, фич, и так далее).

                          Обычно же сроки всегда! ограничены.

                          Так это у вас в аджайле или всё же «обычно <кем-то сверху> ограничены»? Вы уж определитесь.
                            0

                            Ари ван Беннекум — сходите на его тренинг "agile в бизнесе" — полезно будет. А то по вам получается, что agile в компании сам по себе, и вы там пилите и пилите продукт, а топы вам деньги только подваливают и подваливают. Мечта просто. Странный у вас какой то бизнес, не, ну если это очередное сайтостроительство, то наверное. А в энтерпрайзе люди чаще всего деньги считают. И agile там есть, только он там связан с бизнесом, а не сам по себе.

                              0
                              А то по вам получается, что agile в компании сам по себе, и вы там пилите и пилите продукт, а топы вам деньги только подваливают и подваливают. Мечта просто.

                              Может для вас это сюрприз, но де-факто вся сложная деятельность (и разработка тоже) именно так и идёт. В обсуждаемой статье даже подробно расписано, почему именно так.
                          0
                          Вопрос.
                          Проекты сложны из-за инструментов, которые используются или из-за амбиций, которые в них закладываются?
                          У меня нет уверенности в том, что в большинстве случаев, имея продвинутую платформу, дружелюбный персонал, всякие плюшки для работы и расширенные сроки, проект, поднимающийся с нуля, сможет обойтись без передвижений по графику и дополнительных вливаний. Если это проект не включающий в себя уже проторенные дорожки или знакомые инструменты (желательно старых версий) только на одно переобучение и понимание уйдёт первая половина срока.
                          Иногда это походит на новую операционную секцию в которую завезли лапароскоп, но либо наняли, либо уже на местах есть хирурги которые и резать в принципе умеют и хороший послужной список у них, только вот с этой машинкой не работали еще ни разу.
                          По мне, если человеческий фактор играет слишком большую роль в проекте — его нужно всячески урезать. То что ты не сможешь зарезать — умаслить и поставить защиту от дурака.
                          Не нужно забывать, не всё программирование — художественная часть. Нет, ни в коем случае. Тот кто создаёт проект может мыслить творчески, он отвечает и за основную идею и за её продвижение. Работа с начальством и инвесторами это тоже часть твоих обязанностей. Работа с людьми это уже немалая часть обязанностей, которая поможет как и выбить нужный бюджет, так и согласовать сроки. Всё что ниже, вплоть до эникейщика — работники занимающиеся строительством, люки которые забивают гвозди, люди которые ставят окна, заливают фундамент и так далее. Обратная связь конечно же должна иметь место, но при этом не нужно забывать что да, тебе придётся делать сухие телодвижения и думать в основном как робот, чтобы продвинуться дальше.
                          Не обузданная творческая деятельность приведёт к наращиванию ненужных ветвей разработки, которые либо полноценно не будут работать, либо заставят проект повернуться в совершенно другую сторону.
                          Цифровым проектам необходимо эволюционировать хотя бы в плане инструментария. Потихоньку внедрять инструменты для второго и третьего уровней программирования, когда работник не сталкивается с кодом напрямую, а лишь налаживает логическую цепочку между модулями, в то время как модули поддерживаются классическими кадрами и ими же переписываются, причём всё это в опенсорсе.
                            +1
                            Если еще раз посмотреть на графики «крестов», то можно увидеть, что проекты бывают не только сложными, но и простыми. В левых частях графиков — все хорошо. Проблемы начинаются примерно с середины.

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

                            Кстати, «необузданная творческая деятельность» точно так же способна взвинтить сложность продукта до небес и исключить какие-либо шансы на то, что он когда-то заработает :)
                              0
                              Да, уметь преодолеть эти сложности, не потеряв в доле проекта или в нервных клетках людей, это и есть быть хорошим работником или управленцем. Но с этим только опыт поможет. Хотя, некая стандартизация всё же помогает. По сути, ты всегда приходишь к определенным сеткам управления, просто модернизируешь их под свои нужды.
                            +2
                            Еще добавлю в режиме «managerial hat on»: SCRUM/AGILE — не самая удобная или комфортная методология для менеджера. Потому что где-то там во внешнем мире существует понятие сделки. То есть другие люди хотят от вас понимания: какой результат будет достигнут, в какие сроки, и за какие ресурсы?

                            Хотя бы просто для того, чтобы оценить альтернативы.

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

                            Во-первых (и об этом неоднократно упомянуто в статье) — в условиях неопределенности жесткие методологии работают еще хуже. Упрощается только процесс поиска виновных — но легче от этого обычно не становится. И поверьте: если проект израсходовал первоначальный бюджет, но выдал в продакшн 80% функционала (и его не закрыли на итерациях раньше) — значит уже есть реальная выгода от внедрения и можно договориться о выделении дополнительных ресурсов. Такие переговоры — малоприятное занятие, но жить можно. Когда тебя ведут расстреливать за расходование бюджета проекта БЕЗ осязаемых результатов — это куда более печальная история. :-)

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

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

                                Но не все клепают сайты магазинов. Многие делают то, аналогов чего в мире нет, а очень многие — то, что имеет аналоги, но довольно отдалённые и плохо применимые.

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

                              Самое читаемое