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

Разработка ПО – нелинейный процесс

Разработка программного обеспечения — нелинейный процесс. Если на проект выделено 5 разработчиков, которые за 5 месяцев должны разработать продукт (25 чел./мес.), то 25 разработчиков не смогут сделать эту же работу за 1 месяц (те же 25 чел./мес.).

Брукс в своей книге “Мифический человеко-месяц” приводит замечательное выражение: 9 женщин не могут родить ребёнка за 1 месяц. Этим он намекает на существование некого предела, до которого вы можете сжимать сроки разработки. Стив Макконнелл (Steve McConnell) утверждает, что этот порог определён как 25% от исходных оценок.

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

Оценка проекта и цена ошибки

Для иллюстрации “цены ошибки” часто используют конус неопределенности — график, на горизонтальной оси которого указано время, а на вертикальной оси — значение ошибки, которая закладывается при оценке трудоёмкости. C течением времени, по мере того, как становится известно всё больше данных об оцениваемом проекте, о том, что же конкретно и в каких условиях придётся делать, «разброс» ошибки становится всё меньше.

Как цена ошибки растет в случае с переоценкой и недооценкой? Оказывается, что при переоценке цена ошибки растет линейно, при недооценке цена ошибки растет по экспоненте.

Линейный рост в первом случае объясняется законом Паркинсона, готорый гласит: работа заполняет время, отпущенное на неё. Также этот закон называют “синдромом студента” — сколько бы времени не дали на выполнение курсовой, всё равно она делается до последнего дня перед сдачей.

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

Простой подход. Берем количество часов, умножаем на часовой рейт, добавляем 20-30% (риски): (N * hourly_rate) * [1,2-1,3] = project_cost

20-30% — по статистике среднее значение недооценки проектов. Итогда это значение может быть 10% (значит, у вас работает блестящая команда), иногда — 50% (ну тоже нормально), часто — еще больше.

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

Более сложный подход:

Где:

• Cbc (стоимость проекта — оптимистическая оценка)
• Cwc (стоимость проекта — пессиместическая оценка)
• Pbc (вероятность оптимистического сценария)
• Pwc (вероятность пессимистического сценария)

Рассмотрим пример. Оптимистическая оценка — $20 млн. с вероятностью 30%, пессимистическая — $75 млн. с вероятностью 70%.

Итоговая оценка — $58,5 млн. гораздо выше “среднего” значения, которое равняется $47,5 млн. (ошибка около 23%) и которое, скорее всего, выберут большинство менеджеров в качестве компромиссного. Таким образом, еще одно подтверждение того, что к вашей “обычной” оценке в среднем нужно добавлять 20-30%.

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

Технический долг

Осознанное компромиссное решение, когда заказчик и исполнитель четко понимают все преимущества от быстрого, пусть и не идеального технического решения, за которое придется расплатиться позднее. Этот термин ввёл Вард Каннингем.

Общие причины технического долга:

1. Давление бизнеса, когда бизнес требует выпустить что-то раньше, чем будут сделаны все необходимые изменения, — появится накопление технического долга, включая эти незавершенные изменения.
2. Отсутствие процессов или понимания, когда бизнес не имеет понятия о технической задолженности, и принимает решения без учета последствий.
3. Отсутствие созданных слабо связанных компонентов, когда компоненты созданы не на основе модульного программирования, программное обеспечение не является достаточно гибким, чтобы адаптироваться к изменениям бизнес-потребностей.
4. Отсутствие тестов — поощрение быстрой разработки и рискованных исправлений («костылей»), чтобы исправить ошибки.
5. Отсутствие документации, когда код создается без необходимой сопроводительной документации. Работа, необходимая для создания вспомогательной документации, — это также долг, который должен быть оплачен.
6. Отсутствие взаимодействия, когда база знаний не распространяется по организации и страдает эффективность бизнеса, или младшие разработчики неправильно обучены их наставниками.
7. Параллельная разработка одновременно в двух или нескольких ветках может вызвать накопление технического долга, который в конечном итоге будет необходимо восполнить для слияния изменений воедино. Чем больше изменений, которые сделаны изолировано, тем больше итоговый долг.
8. Отложенный рефакторинг — пока создаются требования к проекту, может стать очевидным, что части кода стали громоздкими и должны быть переработаны в целях поддержки будущих требований. Чем дольше задерживается рефакторинг и чем больше написано кода, использующего текущее состояние проекта, тем больше накапливается долга, который должен будет быть оплачен в момент последующего рефакторинга.
9. Отсутствие знаний, когда разработчик просто не умеет писать качественный код.

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

Принцип Парето (принцип 20/80)

Эмпирическое правило, названное в честь экономиста и социолога Вильфредо Парето, в наиболее общем виде формулируется как «20% усилий дают 80% результата, а остальные 80% усилий — лишь 20% результата». Нужно понимать, что цифры 20 и 80 — условные (например, компании Google, Apple и Microsoft любят распределение 30 на 70 для своих магазином приложений), но общего смысла это не меняет.

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

Важнейшие следствия закона Парето:

1. Значимых факторов немного, а факторов тривиальных множество — лишь единичные действия приводят к важным результатам.
2. Большая часть усилий не даёт желаемых результатов.
3. То, что мы видим, не всегда соответствует действительности — всегда имеются скрытые факторы.
4. То, что мы рассчитываем получить в результате, как правило, отличается от того, что мы получаем (всегда действуют скрытые силы).
5. Обычно слишком сложно и утомительно разбираться в том, что происходит, а часто это и не нужно — необходимо лишь знать, работает ваша идея или нет, и изменять её так, чтобы она заработала, а затем поддерживать ситуацию до тех пор, пока идея не перестанет работать.
6. Большинство удачных событий обусловлено действием небольшого числа высокопроизводительных сил; большинство неприятностей связано с действием небольшого числа высокодеструктивных сил.
7. Большая часть действий, групповых или индивидуальных, являет собой пустую трату времени. Они не дают ничего реального для достижения желаемого результата.

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

В упрощенном виде – правило треугольника: быстро, качественно, недорого — выберите любые 2 пункта.

Правило одного процента

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

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

Рассмотрим пример. Вы провели некое мероприятие, на котором присутствовало 30 человек. Вы хотите получить обратную связь путем проведения анкетирования после мероприятия. Есть ли в этом смысл? Если не пытаться придумать какие-то синтетические условия, то смысла в таком анкетировании нет, так как на него откликнется… 0,3 человека. Даже если ответит один человек (что эквивалентно 3%, что уже само по себе является отличным вариантом), то 1 ответ вряд ли вас устроит. Проще спросить мнение людей на выходе из здания :-)

Принцип Питера

Принцип Питера гласит: в иерархической системе каждый индивидуум имеет тенденцию подняться до уровня своей некомпетентности.

Особенности:

1. Является частным случаем общего наблюдения: любая хорошо работающая вещь или идея будет использоваться во всё более сложных условиях, пока не станет причиной катастрофы.
2. Согласно принципу Питера, человек, работающий в любой иерархической системе, повышается в должности до тех пор, пока не займёт место, на котором он окажется не в состоянии справиться со своими обязанностями, то есть окажется некомпетентным. Этот уровень и называется уровнем некомпетентности данного сотрудника.
3. Нет возможности заранее определить, на каком уровне сотрудник достигнет уровня некомпетентности.

Именно по этой причине в 37signals отказались от повышения сотрудников по карьерной лестнице, а предлагают сотрудникам повышать свои навыки и знания (а, значит, и оплату) в рамках своей должности.

Когда число сотрудников компании 37signals перевалило за 25 человек, случилось кое-что странное. Из неё ушла сотрудница, у которой было слишком много амбиций. Она хотела повышения, но плоская структура компании не подразумевала наличия менеджеров. После этого Джейсон Фрид написал колонку, в которой рассказал, почему для них так важно сохранить именно эту структуру организации. По его словам, обычно компаниям свойственно развивать в сотрудниках «вертикальные» амбиции, то есть желание продвигаться вверх по карьерной лестнице. А в 37signals стараются брать тех, кому близки «горизонтальные» амбиции, то есть потребность становиться более профессиональным в том, что ты любишь больше всего на свете. The Village

Для более глубокого погружения в тему рекомендую книги Rework и Remote.

Бритва Хэнлона

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

Бринва Хэнлона — одно из моих любимых принципов. В большинстве случаев все косяки пытаются спихнуть на “действия непредвиденной силы”, “теорию заговоров”, хотя легко объясняются обычной тупостью сотрудников.

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

В формальном виде:

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

Следствие действия закона Мерфи при разработке ПО: нужно внедрять «защиту от дурака» — дополнительные проверки, дополнительные уровни абстракции и изоляции и другие приемы, более известные как “лучшие практики”.

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

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

Надеюсь, что понимание описанных принципов и законов поможет вам разрабатывать программное обеспечение более качественно и завершать его всегда в намеченные сроки и бюджет!

Автор: Chebanov

Источник