Управление сложностью проектов, или как просто усложнять и как сложно упрощать

Любая задача имеет решение. Сложностью можно управлять

Начну с давней истории, которая случилась со мной примерно в 1984 году, когда я поступал на отделение океанологии в Дальневосточный государственный университет. Отделение океанологии было достаточно привлекательным для поступления: конкурс туда составлял 2.5 человека на место. После первых двух экзаменов отсев был нулевой, а третий экзамен был – математика устно. Я получил билет, все, что можно, решил, рассказал, и экзаменатор для получения отличной оценки предложил мне дополнительно упростить вот это выражение:

Видите, что здесь крайняя скобка находится в положении показателя степени? Я сел, стал пытаться упрощать – долго возился, пока другие отвечали. Нашел примерно три решения, но не одно из них не упрощало это выражение. Решил через пересечения графиков, нашел какие-то примерные значения, посчитал какие-то пределы, кое-как разложил, перемножил – в конечном итоге, экзаменатор подходит и говорит: «целый час прошел – что вы так долго возитесь?». Я ему отвечаю: «у меня три решения, смотрите». Он взял эти три решения, отошел, потом подходит и говорит: «извините, я ошибся – правильный пример должен выглядеть вот так»:

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

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

Тот день стал для меня наукой – я осознал, что любая задача имеет решение.

Ave novie nostra ales! – что означает «ежели один человек построил, другой завсегда разобрать может» https://youtu.be/YEdJe2whw1I .

С того самого времени я часто использую эти слова по жизни.

И, кроме того, пришло понимание, что сложностью можно управлять. Помните отрывок из фильма «Формула любви»: « За сколько сделаешь?» — «За день сделаю» — «А за два?» — «Сделаем и за два» — «А за пять дней?» — «Ежели постараться, можно и за пять»… https://youtu.be/ESDZPSrO128

То есть, очень легко усложнять, но гораздо сложнее упрощать.

Определение: Сложность – это усилия, затраченные коллективом на создание какого-то определенного материала. В нашем случае это может быть программный код, могут быть работы, выраженные в стоимостном выражении, или оцененный результат. О концептуальной формуле усилий я уже рассказывал в докладе "Основы управления распределенными программными проектами на платформе 1С:Предприятие" //infostart.ru/public/318707/, хотя, ранее говорил, что "сложность проектов примерно одинаковая". Но сложность — понятие относительное. Что для одних коллективов сложно, для других оказывается простым. Для одного коллектива один проект может оказаться простым, а другой аналогичный сложным до невыполнения. Таким образом, в любом проекте возникает потребность, уменьшить его сложность.

Давайте разберемся, как это делать. Для этого рассмотрим деятельность как ряд процессов.

Важность правильной формулировки на этапе выявления требований

Сложность, как усилия, можем рассматривать в отношении всех процессов, связанных с управлением проектами. Например, сложность процесса выявления требований или сложность анализа и достижения понимания требований. Рассмотрим эти процессы на примере Земли – так выглядит наша планета со стороны Тихого океана из космоса.

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

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

Найм и обучение.
Важность навыка конструктивного письменного общения

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

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

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

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

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

Ограничение нововведений

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

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

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

Потом примерно через 10 лет правило поменялось: сделали так, что тот, кто едет по кругу, должен пропустить того, кто въезжает на круг по правилу "уступи тому, кто справа". Это нововведение привело к тому, что стали возникать так называемые «мертвые захваты»: когда человек не мог выехать с круга, потому что должен был пропустить на круг того, кто въезжает, а те, кто хочет заехать на круг, не могут въехать, потому что круг занят.

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

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

Упрощение усилий

• Упрощение усилий через пошаговую разработку. Когда у нас есть какой-то крупный проект, он кажется очень сложным. Чтобы упростить проект, возьмем его малую часть, выполним первый шаг в направлении достижения целей проекта, получим первый результат, уточним требования и планы и так дальше.
• Использование правила Парето (правило 80/20) предлагается для того, чтобы постараться первый шаг сделать как можно меньшими усилиями, но при этом достичь как можно большей функциональности. Буквально, достичь 80% необходимой функциональность, используя 20% усилий.
• И параллельная работа – это, конечно, очень важный фактор: организовать работу так, чтобы не было каких-то последовательных действий. Когда все работают параллельно и относительно самостоятельно. Некоторые заказчики требуют, а некоторые коллективы разработчиков выполняют доработки программных продуктов последовательно, четко разделяя работу на этапы. Одни специалисты готовят требования, после подготовки требований начинается разработка, после разработки тестирование и т.д. Однако, программые проекты имеют очень низкую определенность на ранних этапах проекта, что существенно осложняет процесс создания набора требований. Плохие требования приведут к плохой разработке. При параллельной работе возможно улучшение понимания требований по мере создания проекта, понимание проекта — по мере создания кода и т.д. Еще в 1996 году Центр поддержки программных технологий (STSC) военно-воздушных сил США опубликовал двухтомник статей, предназначенных для помощи персоналу, осваивающему большие программные системы. В самом начале первого тома жирным выделен следующий совет: "В целом водопадный метод (последовательные действия — прим. автора) сам по себе НЕ рекомендуется для крупных программно-ориентированных проектов…". 

Отказ от лишних материалов и каналов коммуникаций

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

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

Вообще, чем больше придумано различных правил, тем сложнее ими руководствоваться в момент принятия решения. Отличный тому пример — Правила Дорожного Движения. Сколько из правил вы держите в голове, когда едете, например, по оживленной загородной трассе или при подъезде к оживленному перекрестку, на котором есть разметка, регулируемые и не регулируемые пешеходные переходы, обычные светофоры со стрелками и без и светофоры для общественного транспорта? Сколько из тех правил, которые вспоминаете, вы успеваете соблюсти или нарушить? Пожалуй, в программировании аналогично — наличие большого количества правил осложняет процесс программирования. Совсем без правил тоже плохо, но, может, достаточно известных 10 заповедей, как "не укради", "возлюби ближнего" и др.?

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

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

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

Одним из следующих способов уменьшения сложности проекта можно считать:

Повторное использование кода.

Естественно, лучше взять и повторно использовать что-то готовое, чем разрабатывать новое. Отличное подспорье в этом вопросе обеспечено конфигурациями 1С:БСП (Библиотека стандартных подсистем) и 1С:БСО (Библиотека стандартного оборудования). Однако, руководитель всегда должен контролировать, насколько повторное использование кода актуально для текущего проекта, иногда лучше новый и короткий, чем повторный и длинный.

Декомпозиция проекта.

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

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

10 заповедей по упрощению проектов.

• Нанимайте квалифицированных специалистов, развивайте специальные навыки, включая навыки конструктивного письменного общения.
• Ограничивайте количество нововведений.
• Сокращайте число каналов коммуникаций.
• Разбивайте крупные задачи на несколько меньших, относительно самостоятельных.
• Используйте пошаговую разработку.
• Организуйте параллельную работу в проекте, избегайте создания последовательных действий.
• Понимайте и применяйте правило 80/20. Иногда можно отказаться от оставшихся 20% функций, требующих 80% усилий, создав 80% функций двадцатью процентами усилий.
• Достигайте функциональности насколько можно меньшим количеством кода.
• Используйте повторно архитектуру, код, алгоритмы и другие результаты работы над проектами.
• Избегайте создания лишних материалов и правил.

Желаю всем благополучия и процветания!

**********************

Данная статья написана по итогам доклада, прочитанного на конференции INFOSTART EVENT 2024 CONNECTION 15-17 октября 2024 года.

Приглашаем вас на новую конференцию INFOSTART EVENT 2024 INCEPTION.