gifts2017

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

Опубликовал Александр Белов (AlexWhite) в раздел Управление - Бизнес-процессы

Когда-то давно я совсем не умел петь и играть на музыкальных инструментах. Но возникло желание и решил, научиться. Сложно было, пожалуй, начать, но за началом последовали регулярные занятия от простого к более сложному, теория и практика. В результате, за пару лет мне удалось освоить один основной и несколько "вторых" музыкальных инструментов, научиться петь и аккомпанировать на гитаре и решиться на творческий эксперимент - создать музыкальное вступление к докладу https://youtu.be/FkgeXRODcgI . Управлять программными проектами - это, как песню разучить. В обоих случаях приходится сталкиваться с различными сложностями, искать способы упрощения - то есть, управлять сложностью. Я буду рассказывать об управлении сложностью проектов.  

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

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

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

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

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

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

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

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

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

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

Определение: Сложность – это усилия, затраченные коллективом на создание какого-то определенного материала. В нашем случае это может быть программный код, могут быть работы, выраженные в стоимостном выражении, или оцененный результат. О концептуальной формуле усилий я уже рассказывал в докладе "Основы управления распределенными программными проектами на платформе 1С:Предприятие" http://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 2015 CONNECTION 15-17 октября 2015 года.

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

См. также

Подписаться Добавить вознаграждение

Комментарии

1. Сергей (Che) Коцюра (CheBurator) 05.04.16 23:49
Все правильно
Но как же иногда сложно бить себя по рукам, когда начинаешь строить защиты от дурака
Думаешь - вот нафига клиенту такая система с кучей возможностей которые ему (типа) нужны, если львиная доля усилий уходит на то, чтобы управлять этой сложностью???
Так и просится в статью фраза про то, что самым ненадежным жлементом в сложной системе есть (интерактивные) действия пользователя. И как с этим бороться? И нужно ли?
2. Галахад (dmt) 06.04.16 07:45
(1) CheBurator, не нужно. Нужно предоставить доп. услуг "обучение пользователей".
3. Александр Белов (AlexWhite) 06.04.16 09:15
что самым ненадежным элементом
- тут, думаю, больше подходит фраза, "компьютеры ненадежны, но более ненадежны люди" :-)
По поводу
строить защиты от дурака
- мне больше нравится формулировка - снижать влияние человеческого фактора :-)
Но, по опыту, часто простое решение найти сразу очень сложно, приходится решить сложно, потом упрощать :-)
4. Марина Шепелева (m@riu/\@) 06.04.16 09:44
Очень понравилась статья, дам начальству почитать. Особенно сокращение каналов коммуникаций, очень верное правило.
5. Роберт В е р т и н с к и й (v3rter) 06.04.16 11:15
Мне показалось, или последнего параграфа вполне себе достаточно?
6. Александр Белов (AlexWhite) 06.04.16 12:10
(5) v3rter, убрать резюме выступления? :-)
7. Роберт В е р т и н с к и й (v3rter) 06.04.16 13:24
Как убрать, зачем убрать? Там же самый жир - идеи :)
8. Сергей (Che) Коцюра (CheBurator) 06.04.16 14:55
(2) угу. много раз. сценарий: косяк/затык... аааааааа!!! мы не понимаем оно работает, поэтому ошибаемся, аааааа!!! не вопрос - если надо - планируйте занятие, предупредите меня за дня два - я ВСЕ ГОТОВ РАССКАЗАТЬ. дале: тишина... итолько мертвые с косами стоят... до следующего ааааа!!! справедливости надо отметить, что такие варианты бывают редко. все работает достаточно ок. только за счет того. что вся сложность спрятана "вниз". менеджеру доступны "простые" вещи. Однако самое печальное что бизнес/продажники/бухи порождают кучу усложнений - НЕ ПРОИГРЫВАЯ/НЕ СОГЛАСОВЫВАЯ их - в результате это выливается в ацкий гемор.
9. Александр Анисков (vandalsvq) 06.04.16 22:50
Позволю себе цитату из книги "Цель 3" (Голдрат)

Эй, Ленни! В чем, по-твоему, заключается главная причина столь долгого времени реакции наших центров поддержки? Ну, давай же, рассказывай! Ты единственный, кто действительно знает, в чем там дело.
Ленни неохотно возвращается к ним.
- Разве это не очевидно? - бормочет он, глядя то на Скотта, то на Мэгги. - Наш продукт, наша система ERP стала слишком сложной.
Истинный смысл сказанного начинает доходить до Скотта и Мэгги
по мере того, как Ленни продолжает:
- Я еще помню время, когда любой наш программист знал все модули. Теперь, я боюсь, даже я их не знаю. Вообще, мне кажется, что уже не осталось никого, кто знал бы досконально хотя бы один модуль. Этот монстр стал слишком большим и сложным.
Его голос становится напряженным.
- Это приводит к целому ряду серьезных последствий. Ленни начинает их перечислять:
- Требуется гораздо больше времени на встраивание новых функций. Поскольку программист лишь поверхностно знает структуру программы, каждая новая функция порождает как минимум три ошибки где-то еще. Наши гарантии качества становятся злой шуткой. В системе содержится столько внутренних связей, что практически невозможно отследить и проверить все из них.
- Неудивительно, - продолжает он, - что для реакции на многие вопросы требуется столько времени. Я должен был это предвидеть. Несколько лет назад мы могли легко отследить источник ошибки и устранить его. Теперь же программа настолько сложна, что сбой можно объяснить целым множеством возможных причин. При этом даже опыт лучших программистов не позволяет свести это множество к какому-то разумному количеству. Поэтому им приходится проверять все подряд, а на это уходит много времени. Слишком много.
10. Александр Анисков (vandalsvq) 06.04.16 22:50
Там есть классная фраза "Чем лучше становится наша система, тем хуже.".
Описывает большинство проектов и разработок, которые мне встречались. )))))
11. Александр Анисков (vandalsvq) 06.04.16 23:07
12. Сергей (Che) Коцюра (CheBurator) 07.04.16 00:11
В рассылке автором данной ветки значится Alraune
C наращиванием возможностей потрала ИС теряет контроль...
Это к теме сложности и упрощения
13. Сергей (Che) Коцюра (CheBurator) 07.04.16 00:13
(9) это про типовые 8-ве конфы???? ;-)
14. Сергей (Che) Коцюра (CheBurator) 07.04.16 00:14
(10) а то! Я даже на саоих костылях на тис уже не помню что где есть - такое еоличество печатных форм, обработок и прочего - я уже по некоторым вопросам к менеджерам хожу спрашиваю как/откуда они делают некоторые вещи....
15. Александр Анисков (vandalsvq) 07.04.16 00:26
(13) CheBurator, там про внедрения ERP. Книга занимательная, по возможности советую почитать, весело.
(14) CheBurator, примерно так же бывает. Выручает то, что уже 7 лет ведем базу всех разработок. Аналог 1С-овского СППР, только написана давно и проще. Но позволяет собрать по объектам всю историю, со всеми пунктами, заданиями, исполнителями и связями. И все равно, никакая база знаний пока не поспевает.
16. Ирина Павленко (PAVI) 09.04.16 16:08
"Все гениальное просто" - сказал Эйнштейн. Можно перефразировать так: "Эйнштейн достаточно гениален, чтобы делать просто" ))) Респект Белову
17. Александр Белов (AlexWhite) 12.04.16 17:18
18. Роберт В е р т и н с к и й (v3rter) 12.04.16 17:52
Оду декомпозиции задекламировали, процедуры декомпозиции управления евагелизировали, пора выходить на новый уровень - управление масштабированием сложности ) Документировать, документировать и еще раз документировать - и лучше до того, как проект перестанет умещаться в одной голове )
19. Александр Белов (AlexWhite) 12.04.16 18:10
(16) PAVI, хотя,
Эйнштейн достаточно гениален, чтобы делать просто
- что просто для Эйнштейна, для других может быть очень даже сложно :-) (сложность - понятие относительное).
20. Александр Белов (AlexWhite) 12.04.16 18:20
(18) v3rter,
Документировать, документировать и еще раз документировать
=> усложнять в кубе? :-) Документация полезна только в необходимом объеме. Хорошо, когда она совмещена с кодом, как у коллег из коллектива "Silver Bulleters". Думаю, вскоре, Леонид опубликует тут свой доклад.
А так... у нас проекты уже давно вышли за предел одной головы :-)
Для написания сообщения необходимо авторизоваться
Прикрепить файл
Дополнительные параметры ответа