Человеко месяц это: Что значит человеко-месяц во время разработки?

6 ответов

• Как проверить, существует ли запись на основе месяца и имени человека (где имя дублируется)?

  У меня есть набор данных с некоторыми именами и месяцами, образец: Name Month Max 2 Sally 5 Max 1 James 11 Richard 9 Sally 9 Тогда у меня есть стол как таковой: Month Name 1 2 3 4 5 6 7 8 9 10 11 12 Max Sally James Richard Как создать формулу, которая может вводить Yes или No для каждого месяца на…

• MPI сложность коммуникации

  Я изучаю коммуникационную сложность параллельной реализации Quicksort в MPI и нашел что-то подобное в книге: Один процесс собирает p регулярных образцов из каждого из других процессов p-1. Поскольку передается относительно мало значений, задержка сообщения, вероятно, будет доминирующим термином.2). См . Обозначение Big-O .

  Поделиться Tyler McHenry     07 августа 2009 в 14:15

  ---

  
  1
  
  

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

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

  Поделиться Greg D     07 августа 2009 в 14:15

  ---

  
  0
  
  

  Я думаю, ты переоцениваешь это. Мифический месяц человека — это не компьютерная книга, как Научиться программировать Ruby за 21 день. Это бизнес-книга о том, как взаимодействуют команды. Таким образом, он относится к людям как к людям, а не как к машинам. Это означает, что аппроксимации и эвристика-это порядок дня, а не алгоритмы и точность.

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

  Поделиться Jeff Hornby     07 августа 2009 в 14:31

  ---

  
  0
  
  

  Я не помнил точно, что написано в книге, поэтому снял свой экземпляр с полки. Возможно, вы будете рады узнать, что в главе 2, которая также является эссе, давшим книге ее название, Брукс на самом деле говорит, что количество путей связи равно n(n — 1)/2, что соответствует тому, что вы сказали.2 «quote»-это просто упрощение в соответствии с нотацией O(n).

  Поделиться PTBNL     07 августа 2009 в 14:37

  ---

  Похожие вопросы:

  
  Наибольший ‘n’ на группу по месяцам

  У меня есть таблица mysql с датой, именем и рейтингом человека. Мне нужно построить запрос, чтобы показать лучшего человека каждого месяца. Запрос выше дает мне максимальный рейтинг месяца, но…

  
  Angular 2 Брата Компонент Коммуникации

  У меня есть ListComponent. Когда элемент щелкнут в ListComponent, детали этого элемента должны быть показаны в DetailComponent. Оба они находятся на экране одновременно, так что маршрутизация не…

  
  Шифрует ли BLE связь все коммуникации?

  У нас есть некоторые характеристики, которые помечены как связанные / зашифрованные, а некоторые-как несвязанные. Очевидно, что если у нас есть два несвязанных устройства, связь по несвязанным…

  
  Как проверить, существует ли запись на основе месяца и имени человека (где имя дублируется)?

  У меня есть набор данных с некоторыми именами и месяцами, образец: Name Month Max 2 Sally 5 Max 1 James 11 Richard 9 Sally 9 Тогда у меня есть стол как таковой: Month Name 1 2 3 4 5 6 7 8 9 10 11 12…

  
  MPI сложность коммуникации

  Я изучаю коммуникационную сложность параллельной реализации Quicksort в MPI и нашел что-то подобное в книге: Один процесс собирает p регулярных образцов из каждого из других процессов p-1. Поскольку…

  
  Преобразование название месяца в номер месяца, используя JavaScript

  Есть ли лучшее решение, чем то, что я имею ниже, чтобы преобразовать имя месяца в номер месяца, используя JavaScript или PHP? Мне это действительно нравилось: $monNum =…

  
  Как определить, является ли данная дата N-М будним днем месяца?

  Вот что я пытаюсь сделать: Учитывая дату, день недели и целое число n , определите, является ли эта дата n -м днем месяца.n)?

  Домашнее задание моего класса алгоритмов утверждает, что O(n 3 ) более эффективно, чем O (2 n ). Когда я помещаю эти функции в калькулятор graphing, f (x)=2 x оказывается последовательно более…

  Мифический человеко-час — PCNEWS.RU

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

  Меня зовут Гелий Шаров, и я работаю тим-лидом в Orion Innovation. Проработав 24 года в IT-компании на разных должностях, включая менеджерские, я понял, что существует путаница в понятии человеко-час и в том, как им можно манипулировать в IT-проектах. Эта статья поможет развеять мифы и подскажет как правильно планировать работы в проектах. От правильной оценки проекта зависит очень многое. И то, согласится ли с ней ваш клиент и даст ли проекту старт. И то, насколько сложно вам будет делать коррекцию этой оценки в процессе, что неизбежно, и сможете ли вы эту коррекцию обосновать, и то, как вы будете выстраивать бизнес-процессы в управлении проектом. Поэтому в оценке IT-проекта задействована масса факторов, шкал и расчетов. Тем не менее, основная масса клиентов ориентируется на очень понятную и четкую единицу измерения — человеко-час.

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

  Человеко-час — это единица измерения, которой пользуются в проектах для двух разных целей:

  1. Оценки объёма/сложности разработки программного продукта/компонента — то есть оценки необходимых усилий на его создание и тестирование.

  2. Подсчёта стоимости работ по проекту.

  Например, если пять человек выполняют работу в течение рабочей недели, то это составляет 5×40 = 200 человеко-часов. Человеко-часы — это удобный инструмент, который широко используется в аутсорсинговых организациях по разработке ПО.

  Если сравнить человеко-месяц и человеко-час, то в разных проектах ситуация может отличаться. Чаще всего человеко-месяц это 20 рабочих дней * 8 часов = 160 человеко-часов, но в некоторых проектах может быть 21 рабочий день. Если работы по проекту начались 1 февраля и закончились в конце месяца, то это не то же самое, что с 1 марта до конца марта, так как количество рабочих дней разное. Поэтому термин человеко-месяц нужно употреблять аккуратно при оценке и планировании работ, лучше использовать человеко-часы. Более того в разных странах отличается длительность рабочей недели. Например, во Франции она составляет 35 часов, то есть во Франции термин человеко-месяц может содержать меньшее количество человеко-часов, чем в России.

  Ещё больше сложностей в определении термина человеко-год. Для подсчёта суммарного количества человеко-часов в одном человеко-годе необходимо взять количество календарных дней — 365 для невисокосного года и 366 для високосного, вычесть из него количество выходных дней в этом году и количество праздничных нерабочих дней. Также стоит вычесть длительность отпуска, что составляет в России 28 календарных дней или 20 рабочих.

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

  Дополнительным преимуществом человеко-часа перед человеко-месяцем и человеко-годом является его точность. Так если программист работает параллельно в двух проектах, его отработанные часы легко поделить между проектами пропорционально отработанному времени.

  Планирование и учёт человеко-часов

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

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

  Фредерик Брукс в своей книге «Мифический человеко-месяц» писал:

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

  Производительность программистов

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

  В одном из исследований Сакман (Sackman), Эриксон (Erikson) и Грант (Grant) измеряли производительность труда в группе опытных программистов. Внутри одной лишь этой группы соотношение между лучшими и худшими результатами составило примерно 10:1. Это означает, что какие-то задачи в проекте будут выполнены быстрее чем ранее сделанные оценки по объёму работ, а другие наоборот будут задержаны. Поэтому самых опытных программистов нужно планировать на выполнение задач на критическом пути проекта, от выполнения которого зависят сроки отсылки кода и продукта заказчику. Самый ценный ресурс в любом проекте — это календарное время. Если оно упущено, обратно его уже не вернуть, в то время как другие ресурсы проекта восполнимы в течение жизненного цикла проекта.

  Тестирование продукта

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

  К счастью, процесс тестирования в IT проектах довольно стандартизирован и подсчитать трудозатраты QA немного проще. Обычно при таких расчётах учитываются требования заказчика к видам тестирования, которые довольно несложно собрать уже перед началом проекта. Есть мнение, что в среднем трудозатраты в человеко-часах на тестирование в среднем составляют 0.7 от трудозатрат на разработку. Можно сказать, что если расчеты очень сильно отклоняются от этого показателя, то это как минимум повод провести их еще раз.

  Выполнение крупных проектов

  Существует мнение что объём потраченных человеко-часов в ИТ-проектах линейно зависит от объёма написанного кода. График ниже демонстрирует результаты, полученные в исследовании, проведенном Нанусом (Nanus) и Фарром (Farr) в System Development Corporation. В нем выявляется зависимость с показателем степени 1,5. На графике по горизонтали указан объём написанного кода, по вертикали — объём потраченных человеко-месяцев, в виде жирных точек приведена статистика из реальных проектов. Пунктиром изображена линейная зависимость. Сплошной кривой изображена степенная зависимость.

  Объем работы = (константа) × (количество команд)1,5

  То есть в проектах по разработке сложных объёмных продуктов средняя производительность инженеров в машинных командах в единицу времени ниже, чем в небольших проектах, что необходимо учитывать при планировании таких проектов.

  Fixed cost vs T&M

  Планирование работ в человеко-часах зависит от используемой бизнес-модели. Существуют две основные бизнес-модели оплаты услуг аутсорсинговых организаций Fixed Cost и Time&Material. Давайте их рассмотрим поподробнее:

  В модели Fixed Cost оценивается стоимость всех работ по проекту, которую указывают в контракте вместе со списком основных требований к программному продукту. Заказчик оплачивает работу после получения предварительных версий продукта и финальной версии. В случае изменений требований к продукту пересматривается контракт для согласования новой стоимости. В этой модели для заказчика не важно, сколько инженеров и на какой срок привлечено в реализацию проекта. Для компании-исполнителя важно построить такую команду, чтобы выполнить обязательства в полном объёме и не превысить планируемые расходы на проект. В этом случае от грамотного расчёта исполнителя будет зависеть то, реализует ли он проект в срок и заранее рассчитанным количеством человек, или, если расчет окажется неверным, будет ли работать себе в убыток, превысив бюджет и/или выйдя за дедлайн.

  В модели Time&Material также оценивается объём работ по проекту в человеко-часах, но в контракте указывается стоимость одного человеко-часа и базовые принципы по их планированию, отчётности и оплате. После привлечения сотрудников в проект в конце каждого месяца отсылается отчёт по проделанной работе и затраченным человеко-часам. Оплата происходит ежемесячно при условии, что исполнитель не превышает заранее установленных планов и критериев по суммарным человеко-часам. В этой модели заказчик видит часы каждого сотрудника, вовлечённого в проект. В случае изменения проектных требований они оцениваются и бюджет может быть увеличен для вовлечения дополнительных сотрудников.

  В проектах, где есть устойчивые требования к разрабатываемому программному продукту, модель Fixed Cost обладает преимуществами как для заказчика, так и для исполнителя. В других проектах, включая Agile, T&M модель более предпочтительна так как эта модель не требует пересматривать контракт при изменении требований.

  Заключение

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

  В заключение я бы хотел процитировать слова Фредерика Брукса:

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

  © Habrahabr.ru

  Что случилось с шаблоном «Хирургическая бригада» из «Мифического человека-месяца»?

  Есть некоторые аспекты этой концепции, которые иногда реализуются сегодня, есть и другие аспекты, которых следует избегать .

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

  Кросс-функциональные команды также являются основой Agile, но распространены и за пределами Agile.

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

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

  Один из аспектов, который мы стараемся избегать сегодня, заключается в том, что не более двух человек понимают систему. Только хирург гарантированно понимает систему полностью, второй пилот может или не может. Это дает коэффициент шины от 1 до 2. Если хирург заболел, проект мертв. Период. Agile ответом на это является коллективное владение кодом, которое является полной противоположностью этой модели: никто не несет особой ответственности за какую-либо часть системы. Вместо этого каждый несет ответственность за все как группа .

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

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

  Обзор книги «Мифический человеко-месяц» | Школа программирования ProgTips

  Книга Фредерика Брукса «Мифический человеко-месяц, или Как создаются программные системы» — это книга обязательная к прочтению для каждого программиста. Она вышла еще в 1975 году, но совершенно не утратила своей актуальности.

  Мне эта книга повстречалась очень вовремя. Я только что закончил ВУЗ и начал работать программистом. Вначале было очень трудно. Книг по IT тогда было мало. Эту книгу я читал в библиотеке, она была изрядно потрепана. И я поразился, сколько ценного она содержит. Советы Брукса очень помогли мне в начале карьеры. А особенно эта книга пригодилась, когда я сам стал руководить программистами.

  Фредерикс Брукс работал в IBM и руководил созданием операционной системы System/360. На тот момент — это был самый крупный программный проект в мире. В процессе работы возникли неожиданные сложности. Брукс был наблюдательным человеком и сумел понять природу этих сложностей. Он сумел сформулировать основные принципы разработки ПО, которые отличают программирование от других отраслей производства.

  Что же это за принципы?

  Закон Брукса

  Главный вывод, который он назвал законом Брукса гласит:

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

  Этот закон обычно иллюстрируют так: «Даже если собрать девять женщин, то они не смогут родить ребенка за месяц».

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

  Метод Вирта

  Согласно Бруксу лучший метод разработки ПО — это метод Никлауса Вирта, автора языка Паскаль.

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

  Именно этот метод разработки программ я взял на вооружение и долгие годы он помогает мне писать программы более эффективно.

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

  ООП — это болезнь

  В этой книге я впервые прочитал критическое мнение о модной в те времена объектно-ориентированной технологии разработки программ.

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

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

  Исправления портят программу

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

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

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

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

  Производительность программистов различается в разы

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

  В одном из исследований Сакман (Sackman), Эриксон (Erikson) и Грант (Grant) измеряли производительность труда в группе опытных программистов. Внутри одной лишь этой группы соотношение между лучшими и худшими результатами составило примерно 10:1 по производительности труда и 5:1 по скорости работы программ и требуемой для них памяти! Короче, программист, зарабатывающий 20 тысяч долларов в год, может быть в десять раз продуктивнее программиста, зарабатывающего 10 тысяч долларов.

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

  Серебряной пули нет

  Самый интересный прогноз Брукса о том, что в ближайшее время не будет технологий, способных на порядок увеличить скорость разработки. Прошло уже очень много лет, а прогноз Брукса полностью сбылся. Как и сорок лет назад программисты пишут программы вручную. Нет технологии, в которую засунешь ТЗ заказчика, а она выплюнет готовый код.

  Конечно же, все идеи Брукса не перескажешь. Рекомендую к прочтению, чтобы не наступать на многие грабли.

  Можно ли стать программистом за год с нуля?

  Читайте в моей бесплатной мини-книге «Путь в программисты». Скачать её можно здесь.

  Фредерик Брукс, «Мифический человеко-месяц или как создаются программные системы»

  Фредерик Брукс

  Мифический человеко-месяц или как создаются программные системы

  Как многие программисты, я весьма нетерпелив, и люблю как можно быстрее переходить к делу, а лучше — к реальным и осязаемым результатам. Поэтому с большим трудом читаю книги по профессии, где уж слишком много словоблудия, и особенно осторожен, когда кто-то пытается чего-то там теоретизировать. Я глубоко уверен, что кумиров “по умолчанию” в профессии иметь опасно, а лучше вообще не иметь, и любую веру в “крутизну” кого-либо надо проверять лично, поэтому я распечатал себе эту книгу (у меня получилось около 70 листов А4 с двух сторон), и решил полистать вечерком у телевизора.

  В итоге, я не отрываясь внимательно прочитал ее до конца часа за два, и некоторые куски потом пересматривал. По моему мнению, это надо прочесть любому программисту или руководителю программистов. Несмотря на то, что книге скоро стукнет 35 лет, и ее переиздание 1995 года практически повторяет оригинальное, в новом издании всего добавили пару глав, но старые главы остались в исходном виде. Даже когда автор употребляет несколько угловатые в наши дни выражения типа “выйти на машину” или “обратиться к журналу с дисплейного терминала” — это совершенно не искажает сути. Видимо из-за собственной самоуверенности, я считал, что такие значимые для меня вещи как многоуровневое тестирование, самодокументируемый код, контроль версий, готовность вносить изменения и т.д. придуманы совершенно недавно, можно сказать, на моих глазах. “Ах какой удар от классика!” — все это придумано и применялось уже тогда.

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

  Вывод

  Два часа прочтения будут отзываться в вас еще долго, а необычные сегодня картины вычислительной техники “тех” дней только помогут кристаллизовать абсолютно актуальные до сих пор выводы Фредерика Брукса.

  Посты по теме:

  эссе по разработке программного обеспечения, юбилейное издание: Брукс-младший, Фредерик: 8580001065793: Amazon.com: Книги

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

  К моему удивлению и радости, «Мифический человеко-месяц» продолжает оставаться популярным спустя двадцать лет. Распечатано более 250 000 экземпляров. Часто спрашивают, каких мнений и рекомендаций 1975 года я придерживаюсь, какие изменились и как. Хотя я время от времени обращался к этому вопросу на лекциях, я давно хотел ответить на него в письменной форме.

  Питер Гордон, ныне издательский партнер в Addison-Wesley, терпеливо и услужливо работал со мной с 1980 года. Он предложил нам подготовить юбилейное издание. Мы решили не редактировать оригинал, а перепечатать его без изменений (за исключением тривиальных исправлений) и дополнить более актуальными мыслями.

  Глава 16 перепечатывает статью «Серебряной пули: сущность и случайности разработки программного обеспечения», опубликованную в 1986 году IFIPS, которая выросла из моего опыта руководства исследованием оборонного научного совета по военному программному обеспечению.Мои соавторы этого исследования и наш исполнительный секретарь Роберт Л. Патрик сыграли неоценимую роль, вернув меня в контакт с реальными крупными программными проектами. Статья была переиздана в 1987 году в компьютерном журнале IEEE Computer, что дало ей широкое распространение.

  «Серебряная пуля» оказалась провокационной. Он предсказал, что через десять лет не будет никаких методов программирования, которые сами по себе улучшили бы производительность программного обеспечения на порядок. У десятилетия есть год; мой прогноз кажется безопасным.»NSB» вызывал в литературе все более оживленные дискуссии, чем «Мифический человеко-месяц». Глава 17, таким образом, комментирует некоторые опубликованные критические статьи и обновляет мнения, высказанные в 1986 году.

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

  Глава 19 — это само обновленное эссе. Следует предупредить читателя, что новые мнения далеко не так хорошо основаны на опыте в окопах, как исходная книга. Я работал в университете, а не в промышленности, и над небольшими проектами, а не над крупными. С 1986 года я преподавал только программную инженерию, а не исследовал ее вообще.Мои исследования, скорее, были посвящены виртуальной реальности и ее приложениям.

  При подготовке этой ретроспективы я изучал текущие взгляды друзей, которые действительно работают в области разработки программного обеспечения. Я благодарен Барри Бёму, Кену Бруксу, Дику Кейсу, Джеймсу Коггинсу, Тому ДеМарко, Джиму Маккарти, Дэвиду Парнасу, Эрлу Уиллеру и за прекрасную готовность делиться взглядами, вдумчиво комментировать проекты и перевоспитывать меня. Эдвард Йордон. Фэй Уорд великолепно справилась с технической подготовкой новых глав.

  Я благодарю Гордона Белла, Брюса Бьюкенена, Рика Хейс-Рота, моих коллег из Целевой группы Совета оборонной науки по военному программному обеспечению и, особенно, Дэвида Парнаса за их идеи и стимулирующие идеи, а также Ребекку Бирли за техническое производство программного обеспечения. Статья напечатана здесь как Глава 16. Анализ проблемы программного обеспечения по категориям сущности и случайности был вдохновлен Нэнси Гринвуд Брукс, которая использовала такой анализ в статье о скрипичной педагогике Судзуки.

  Домашний обычай Аддисон-Уэсли не позволил мне в Предисловии 1975 года признать ключевые роли, которые играет их персонал.Особо следует отметить вклад двух человек: Нормана Стэнтона, тогдашнего исполнительного редактора, и Герберта Боэса, тогдашнего арт-директора. Боес разработал элегантный стиль, который особенно процитировал один рецензент: «широкие поля и творческое использование шрифта и макета». Что еще более важно, он также дал важную рекомендацию: в каждой главе должна быть начальная картинка. (В то время у меня были только Тар-Пит и Реймсский собор.) Поиск фотографий потребовал от меня дополнительного года работы, но я бесконечно благодарен за совет.

  Deo soli gloria или Soli Deo Gloria — Только Богу слава.

  Чапел-Хилл, Северная Каролина, Ф.
  

  0201835959P04062001

  С задней стороны обложки

  Немногие книги по управлению проектами программного обеспечения были столь же влиятельными и неподвластными времени, как Мифический человеко-месяц . Сочетая в себе факты о программной инженерии и наводящие на размышления мнения, Фред Брукс предлагает понимание для всех, кто управляет сложными проектами. Эти эссе основаны на его опыте в качестве руководителя проекта для семейства компьютеров IBM System / 360, а затем для OS / 360, его огромной программной системы.Теперь, спустя 20 лет после первой публикации своей книги, Брукс пересмотрел свои первоначальные идеи и добавил новые мысли и советы как для читателей, уже знакомых с его работой, так и для читателей, открывающих для себя ее впервые.

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

  Об авторе

  Фредерик П. Брукс младший, родился в 1931 году в Дареме, Северная Каролина. Он получил A.B. с отличием по физике от Дьюка и доктора философии. в области информатики из Гарварда, под руководством Ховарда Эйкена, изобретателя первых гарвардских компьютеров.

  В Чапел-Хилл доктор Брукс основал Департамент компьютерных наук и возглавлял его с 1964 по 1984 год. Он работал в Национальном научном совете и Научном совете обороны.В настоящее время он преподает и исследует компьютерную архитектуру, молекулярную графику и виртуальные среды.

  Он присоединился к IBM, работая в Покипси и Йорктауне, штат Нью-Йорк, с 1956 по 1965 год. Он наиболее известен как «отец IBM System / 360», когда он работал менеджером проекта по его разработке, а затем руководил программным проектом «Операционная система / 360» на этапе его разработки. За эту работу он, Боб Эванс и Эрик Блок были награждены Национальной медалью технологий в 1985 году.

  Доктор Брукс и Дура Суини в 1957 году запатентовали систему прерывания Stretch для компьютера IBM Stretch, которая представила большинство функций сегодняшних систем прерывания. Он ввел термин компьютерная архитектура . Его команда System / 360 сначала добилась строгой совместимости, восходящей и нисходящей, в семействе компьютеров. Его ранний интерес к обработке текстов привел к его выбору 8-битного байта и строчного алфавита для System / 360, разработке многих новых 8-битных устройств ввода / вывода и предоставлению типа данных в виде символьной строки в PL / I.

  В 1964 году он основал факультет компьютерных наук в Университете Северной Каролины в Чапел-Хилл и руководил им в течение 20 лет. В настоящее время он Кенан профессор компьютерных наук . Его основные исследования связаны с трехмерной компьютерной графикой в ​​реальном времени — «виртуальной реальностью». Его исследования помогли биохимикам определить структуру сложных молекул и позволили архитекторам «пройти через» строящиеся здания. Он является пионером в использовании отображения силы в дополнение к визуальной графике.

  Брукс описал успехи и неудачи разработки операционной системы / 360 в книге Мифический человеко-месяц: очерки программной инженерии , (1975). Далее он исследовал программную инженерию в своей известной статье 1986 года «Нет серебряной пули». Он только что завершает двухтомную исследовательскую монографию Computer Architecture с профессором Герритом Блаау. Теперь, спустя 20 лет после первой публикации своей книги, Брукс пересмотрел свои первоначальные идеи и добавил новые мысли и советы в «Мифический человеко-месяц», юбилейное издание .

  Брукс работал в Национальном научном совете и Научном совете обороны. Он является членом Национальной инженерной академии и Американской академии искусств и наук. Он получил медаль IEEE John von Neumann Medal, награду McDowell и Computer Pioneer от IEEE Computer Society, награду ACM Allen Newell and Distinguished Service Awards, премию AFIPS Harry Goode и почетного доктора технических наук ETH-Zürich.

  
  

  Выдержка. © Печатается с разрешения автора.Все права защищены.

  ПРЕДИСЛОВИЕ К моему удивлению и восторгу, «Мифический человеко-месяц» продолжает оставаться популярным спустя двадцать лет. Распечатано более 250 000 экземпляров. Часто спрашивают, каких мнений и рекомендаций 1975 года я придерживаюсь, какие изменились и как. Хотя я время от времени обращался к этому вопросу на лекциях, я давно хотел ответить на него в письменной форме.

  Питер Гордон, ныне издательский партнер Addison-Wesley, терпеливо и услужливо работал со мной с 1980 года.Он предложил подготовить юбилейное издание. Мы решили не редактировать оригинал, а перепечатать его без изменений (за исключением тривиальных исправлений) и дополнить более актуальными мыслями.

  Глава 16 перепечатывает статью «Серебряной пули: сущность и случайности разработки программного обеспечения», опубликованную в 1986 году IFIPS, которая выросла из моего опыта руководства исследованием оборонного научного совета по военному программному обеспечению. Мои соавторы этого исследования и наш исполнительный секретарь Роберт Л. Патрик сыграли неоценимую роль, вернув меня в контакт с реальными крупными программными проектами.Статья была переиздана в 1987 году в компьютерном журнале IEEE Computer, что дало ей широкое распространение.

  «Серебряная пуля» оказалась провокационной. Он предсказал, что через десять лет не будет никаких методов программирования, которые сами по себе улучшили бы производительность программного обеспечения на порядок. У десятилетия есть год; мой прогноз кажется безопасным. «NSB» вызывал в литературе все более оживленные дискуссии, чем «Мифический человеко-месяц». Таким образом, глава 17 комментирует некоторые опубликованные критические замечания и обновляет мнения, высказанные в 1986 году.

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

  Глава 19 — это само обновленное эссе. Следует предупредить читателя, что новые мнения далеко не так хорошо основаны на опыте в окопах, как исходная книга. Я работал в университете, а не в промышленности, и над небольшими проектами, а не над крупными. С 1986 года я преподавал только программную инженерию, а не исследовал ее вообще. Мои исследования, скорее, были посвящены виртуальной реальности и ее приложениям.

  При подготовке этой ретроспективы я изучал текущие взгляды друзей, которые действительно работают в области разработки программного обеспечения.Я благодарен Барри Бёму, Кену Бруксу, Дику Кейсу, Джеймсу Коггинсу, Тому ДеМарко, Джиму Маккарти, Дэвиду Парнасу, Эрлу Уиллеру и за прекрасную готовность делиться взглядами, вдумчиво комментировать проекты и перевоспитывать меня. Эдвард Йордон. Фэй Уорд великолепно справилась с технической подготовкой новых глав.

  Я благодарю Гордона Белла, Брюса Бьюкенена, Рика Хейс-Рота, моих коллег из Целевой группы Совета оборонной науки по военному программному обеспечению и, особенно, Дэвида Парнаса за их идеи и стимулирующие идеи, а также Ребекку Бирли за техническое производство программного обеспечения. , бумага напечатана здесь как Глава 16.Анализ проблемы программного обеспечения на категории сущности и случайности был вдохновлен Нэнси Гринвуд Брукс, которая использовала такой анализ в статье о скрипичной педагогике Судзуки.

  Домашний обычай Аддисон-Уэсли не позволил мне в Предисловии 1975 года признать ключевые роли, которые играет их персонал. Особо следует отметить вклад двух человек: Нормана Стэнтона, тогдашнего исполнительного редактора, и Герберта Боэса, тогдашнего арт-директора. Боес разработал элегантный стиль, который особенно процитировал один рецензент: «широкие поля, [и] творческое использование шрифта и макета.«Что еще более важно, он также дал важную рекомендацию, чтобы каждая глава имела начальную картинку (в то время у меня были только Тар-Пит и Реймсский собор). На поиск этих картинок мне потребовался дополнительный год работы, но я бесконечно благодарен за это.

  Deo soli gloria или Soli Deo Gloria — Слава Богу одному. Чапел-Хилл, Северная Каролина, Ф.

  человеко-месяцев Определение | Law Insider

  Связано с

  человеко-месяцем

  Месяц означает календарный месяц.

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

  Финансовый месяц означает любой из месячных отчетных периодов Заемщика.

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

  Календарный месяц означает период времени, начинающийся в соответствующий числовой день календарного месяца и для последующих календарных месяцев, начиная с (i) того же числового дня следующего календарного месяца или (ii) последний день следующего календарного месяца.Каждый календарный месяц заканчивается в день, непосредственно предшествующий началу следующего последующего календарного месяца.

  Месяц выставления счетов означает период, начинающийся с 25-го числа календарного месяца и заканчивающийся 24-го числа следующего календарного месяца.

  Год означает календарный год.

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

  Квартал означает, если контекст не требует иного, финансовый квартал Партнерства или, в отношении финансового квартала Партнерства, который включает Дату закрытия, часть такого финансового квартала после Даты закрытия.

  Расчетный период имеет значение, присвоенное такому термину в Разделе 6.1 (b).

  Школьный финансовый год означает финансовый год, который начинается 1 июля и продолжается до 30 июня.

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

  Календарный квартал означает соответствующие периоды из трех (3) последовательных календарных месяцев, заканчивающихся 31 марта, 30 июня, 30 сентября и 31 декабря.

  Полугодовой период означает каждый из следующих периодов: период, начинающийся с включительно 1 января и до 30 июня включительно; и период, начинающийся 1 июля включительно и заканчивающийся 31 декабря включительно.

  старый финансовый год означает финансовый год эмитента, который непосредственно предшествует переходному году;

  Неделя означает семь дней подряд.

  Программный год означает годовой период, начинающийся 1 января и заканчивающийся 31 декабря.

  Текущий месяц означает месяц, для которого

  Год годовщины Годовой период, начинающийся в Дату закрытия и заканчивающийся первого числа годовщину его, и каждый последующий годичный период, начинающийся в день после окончания предыдущего Юбилейного года и заканчивающийся в следующую годовщину Даты закрытия.Сумма примененного убытка: в отношении любой Даты распределения, сумма, если таковая имеется, на которую (x) совокупная основная сумма сертификата сертификатов после возмещения всех реализованных убытков, понесенных в отношении ипотечных кредитов в течение соответствующего периода взимания, и распределение основной суммы в такую ​​Дату распределения, но до того, как вступит в силу какое-либо применение Приложенной суммы убытка в отношении такой даты, превышает (y) Баланс Пула на такую ​​Дату распределения.

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

  Год газа означает период из 365 или 366 газовых дней, в зависимости от обстоятельств, начинающийся 1 октября в 06:00 (бельгийское время) и заканчивающийся 30 сентября в 06:00 (бельгийское время) в следующем году.

  Отпуск, совпадающий с днем ​​отпуска Если работник находится в отпуске и на этот период приходится день оплачиваемого отпуска, оплачиваемый отпуск не считается днем ​​отпуска.

  Выходной, выпадающий на день отдыха‌ Когда день, обозначенный как выходной, совпадает с днем ​​отдыха Сотрудника, Работодатель предоставляет оплачиваемый отпуск либо:

  Период выплаты означает, для EA, 30 -дневный период, начинающийся с даты выдачи первого платежа и заканчивающийся на 30-й день после даты выдачи платежа.

  Трехмесячная вторичная ставка CD означает для любого дня ставку вторичного рынка для трехмесячных депозитных сертификатов, действующих в этот день (или, если такой день не является Рабочим днем, на следующий предшествующий день). Рабочий день) Правлением через телефонную линию для общественной информации Федерального резервного банка Нью-Йорка (ставка, которая, в соответствии с текущей практикой Правления, будет опубликована в статистическом выпуске Федеральной резервной системы H.15 (519) в течение недели, следующей за в такой день) или, если такая ставка не сообщается в такой день или такой следующий предшествующий Рабочий день, среднее значение котировок вторичного рынка для трехмесячных депозитных сертификатов крупных банков денежного центра в Нью-Йорке, полученных примерно в 10 раз: 00 а.м. по времени Нью-Йорка в такой день (или, если такой день не является рабочим днем, в следующий предшествующий Рабочий день) административным агентом из трех выбранных им оборотных сертификатов депозитных дилеров с признанной репутацией.

  Срок действия означает 12-месячный период, начинающийся в первый день Срока и каждый последующий 12-месячный период после него.

  человеко-месяц FTE Определение | Law Insider

  Относится к

  человеко-месяцу FTE

  Программный год означает годовой период, начинающийся 1 января и заканчивающийся 31 декабря.

  старый финансовый год означает финансовый год эмитента, который непосредственно предшествует переходному году;

  Квартал означает, если контекст не требует иного, финансовый квартал Партнерства или, в отношении финансового квартала Партнерства, который включает Дату закрытия, часть такого финансового квартала после Даты закрытия.

  Календарный квартал означает соответствующие периоды из трех (3) последовательных календарных месяцев, заканчивающихся 31 марта, 30 июня, 30 сентября и 31 декабря.

  Контрактный год означает в отношении начального Контрактного года период, начинающийся в Дату коммерческой операции и заканчивающийся в 12.00 ночи 31 марта этого финансового года. Каждый последующий Контрактный год должен совпадать с последующим Финансовым годом, т. Е. Периодом в двенадцать месяцев, начинающимся 1 апреля и заканчивающимся 31 марта следующего года, за исключением того, что последний Контрактный год заканчивается в дату истечения Срока или прекращения настоящего Соглашения, в зависимости от того, что наступит раньше.

  Месяц означает календарный месяц.

  Финансовый месяц означает любой из месячных отчетных периодов Заемщика.

  Год газа означает период из 365 или 366 газовых дней, в зависимости от обстоятельств, начинающийся 1 октября в 06:00 (бельгийское время) и заканчивающийся 30 сентября в 06:00 (бельгийское время) в следующем году.

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

  Бюджетный год означает финансовый год муниципалитета, на который должен быть утвержден годовой бюджет в соответствии с разделом 16 (1) MFMA;

  Дата сверки означает последний календарный день каждого периода сверки.

  Год урожая означает годичный период, заканчивающийся 28 февраля каждого года.

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

  Финансовый квартал означает период, начинающийся в день после Даты одного квартала и заканчивающийся в Дату следующего квартала.

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

  Школьный финансовый год означает финансовый год, который начинается 1 июля и продолжается до 30 июня.

  Финансовый год Академии означает учебный год с 1 сентября по 31 августа следующего года;

  Год продаж означает календарный год, в течение которого Компания продавала Сигареты в Государстве-бенефициаре, требуя внесения депозита Принципала QEF.

  Отчетный период начинается в первый день каждого календарного квартала и заканчивается в последний день такого календарного квартала.

  Еженедельный отчетный период означает любой период (а), в течение которого произошло событие неисполнения обязательств, или (б) начиная с даты, когда Избыточная доступность меньше, чем большее из (i) 10% ограничения строки и (ii) 8 500 000 долларов США в течение трех (3) последовательных Рабочих дней до тех пор, пока Избыточная доступность не станет как минимум большей из (i) 10% от ограничения строки и (ii) 8 500 000 долларов США в течение как минимум 30 последовательных календарных дней.

  Контрактный квартал означает трехмесячный период, который начинается 1 января, 1 апреля, 1 июля или 1 октября и заканчивается 31 марта, 30 июня, 30 сентября или 31 декабря, соответственно.

  Год означает календарный год.

  Расчетный период означает (в соответствии со Статьей 6.1 Соглашения) календарный месяц, заканчивающийся Датой измерения. Первый Расчетный период начинается с Даты коммерческой операции и заканчивается Датой измерения, соответствующей месяцу, в котором наступает Дата коммерческой операции.

  Юбилейный год Годовой период, начинающийся в Дату закрытия и заканчивающийся в первую годовщину этого года, и каждый последующий годичный период, начинающийся в день после окончания предыдущего Юбилейного года и заканчивающийся в следующую следующую годовщину Дата закрытия. Сумма примененного убытка: в отношении любой Даты распределения, сумма, если таковая имеется, на которую (x) совокупная основная сумма сертификата сертификатов после возмещения всех реализованных убытков, понесенных в отношении ипотечных кредитов в течение соответствующего периода взимания, и распределение основной суммы в такую ​​Дату распределения, но до того, как вступит в силу какое-либо применение Приложенной суммы убытка в отношении такой даты, превышает (y) Баланс Пула на такую ​​Дату распределения.

  Дата коммерческой операции означает день, когда коммерческая операция впервые осуществляется в соответствии с разделом 4.2 настоящего Соглашения.

  Дата плановой коммерческой эксплуатации имеет значение, определенное в пункте 5.4.1;

  Работает ли метрика в человеко-месяцах сегодня?

  В начале своей управленческой деятельности я прочитал книгу, в которой описывалось, что такое «человеко-месяц» или «человеко-день», что можно перефразировать как количество продуктивного времени, которое вы можете ожидать от сотрудника в определенный период.Шесть часов из восьмичасового рабочего дня — это общее практическое правило. Это дает вам около 120 часов продуктивной работы каждый месяц. Вы не поверите, но этот показатель по-прежнему является довольно неплохим способом оценки ожидаемых оплачиваемых часов в год на консультанта — 1440 часов. Это очень простой, но эффективный метод консервативной оценки ваших способностей.

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

  • Среднее время администрирования в месяц, которое включает встречи компании, работу с клиентами, не оплачиваемую, исследования, расписания / расходы и т. Д., Составляет около 21 часа. Я удалил время на скамейке, так как оно не соответствует рабочему времени.
  • Среднее время в пути каждый месяц составляет около 17 часов
  • Отпуск каждый год составляет всего 120 часов
  • Компания ежегодно отмечает 8 праздников, что составляет всего 64 часа

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

  • 2080 часов
  • — 252 часа Администратор
  • — время в пути 204 часа
  • — 120 часов отпуска
  • — 64 выходных

  ——————————

  1440 часов продуктивности в год

  Хорошо, это потрясающе! Я уверен, что если вы внимательно посмотрите мои расписания, у вас может быть несколько часов в любом случае, которые следует включить или исключить. Все дело в том, как вы определяете и фиксируете метрики (разве цифры не прекрасны?).Возможно, вы заметили, что я не включил время продажи. Я считаю, что продажи считаются продуктивным временем просто потому, что это средство закрыть новый бизнес. Инвестиции в продажи — это необходимость.

  Я должен отметить, что эти продуктивные показатели по-прежнему основаны на определении ожидаемой рабочей недели — 40 часов в этом примере. В мире «наемных сотрудников» 40-часовая рабочая неделя кажется неслыханной, если только вы не отправляетесь в отпуск на этой неделе. Обычно рабочая неделя от 45 до 50 часов является довольно распространенным явлением, и даже больше в зависимости от вашей отрасли.Так почему бы просто не сделать определение рабочей недели выше? 9 часов в день? 10 часов в день? Моя теория заключается в том, что увеличение количества часов в день на самом деле не повысит вашу продуктивность за день. Это просто делает день дольше с большим количеством перерывов, чтобы не выгореть вашу команду. Когда крайние сроки вырисовываются большими, ваша команда, скорее всего, подойдет к делу, работает много часов и в выходные, и зарабатывает чувство гордости, когда крайние сроки соблюдены. Сотрудникам сложно выдерживать такой график работы, поэтому определенно не стоит составлять план мощности, ориентированный на такой уровень усилий.

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

  Мифический мифический человеко-месяц — Smashing Magazine

  Краткое резюме ↬ Как вы продвигаетесь быстрее, если добавление людей в проект якобы замедляет его? CPO Mailchimp знакомит читателя с некоторыми соображениями по сохранению импульса при расширении масштабов.

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

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

  Изданная Фредериком Бруксом еще в 1975 году (вы же помните 1975 год, верно? Когда разработка программного обеспечения на 100% напоминала разработку программного обеспечения в 2020 году?), Эта книга довольно известна среди программистов.В частности, во всей книге есть один известный пункт (я не уверен, что люди читали что-либо, кроме этого, если они вообще читали эту книгу):

  «… добавление большего количества мужчин удлиняет, а не сокращает график».

  Простое исправление. С этого момента я буду просто нанимать женщин для проектов (см. «Возвращение короля », «» и «Битва с королем-чародеем Ангмара»).

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

  Больше после прыжка! Продолжить чтение ниже ↓

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

  Вот график из книги, иллюстрирующий эту точку:

  Добавьте людей, чтобы они не торопились (большой превью)

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

  Когда я, как главный исполнительный директор, говорю: «Мы сделаем это!» тогда часто отвечают: «Хорошо, тогда что мы собираемся убивать?» Мифический человеко-месяц превращает разработку продукта в игру с нулевой суммой. Если мы хотим одного, мы должны остановить другое. Это настоящий миф, и я называю это чушью.

  И, учитывая его патологически неверно истолкованный (мы еще дойдем до этого) вывод, в книге, очевидно, говорится, что самая быстрая технологическая компания — это та, в которой работают все четыре человека — четыре человек, очевидно, .Все, что угодно, только замедляет все это. Кто-то должен отправить копии книги Amazon, Apple и Google, чтобы они могли исправить свои явно раздутые организации.

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

  И как владелец отдела управления продуктами в моей компании, мне не безразлична необходимость сбавить обороты и сосредоточиться.Мы должны безжалостно расставлять приоритеты! Без сомнений. Но запуск продукта — это упражнение в противоречии. Я должен уделять первоочередное внимание тому, что у меня есть, одновременно планируя сделать больше. Но что мне делать перед лицом Мифического Человеческого Месяца ?

  Удивительно, но ответ на этот вопрос содержится в той же книге Брукса. Вот еще один график из той же главы:

  (Большой превью)

  Идет битва за масштабирование разработки продукта.Если работа, которую вы пытаетесь выполнить, полностью разделяется, тогда добавляйте людей! Если ваша работа взаимосвязана, то в какой-то момент добавлять людей просто неправильно.

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

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

  Конфликт для руководителя продукта между масштабированием и безжалостной установкой приоритетов можно разрешить.

  1. Вы безжалостно расставляете приоритеты в однопоточных местах (например, отставание для продуктовой команды).
  2. Вы масштабируете, добавляя еще ядер для обработки независимой работы.

  Однако очень редко бывает что-то полностью независимое от всего остального в компании.Как минимум, ваша компания собирается централизовать вспомогательные функции (глобальные ИТ, юридические вопросы, кадры и т. Д.), Что приведет к возникновению узких мест.

  Все об управлении зависимостями

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

  Одно из решений — сформировать стратегическое направление для компании, которое минимизирует или ограничивает зависимость посредством тщательно подобранного портфеля инициатив. Самое смешное, что многие люди будут сопротивляться этому. Скажем, у меня есть два варианта: один, в котором я могу выполнять проекты A, B и C, которые имеют очень слабую координацию (скажем, они влияют на различных продуктов ), и другой вариант с проектами D1, D2 и D3, которые имеют тонны взаимозависимости (скажем, все они влияют на один и тот же продукт ).Часто бывает, что мифический человеко-месяц будет применяться против первого плана, а не второго. Потому что на бумаге больше похож на .

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

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

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

  Утверждение Мифического Человеческого Месяца состоит в том, что по мере того, как вы добавляете людей в программный проект, коммуникация должна увеличиваться геометрически. Например, если у вас в проекте 3 человека, это 3 канала связи. Но если у вас их 4, это 6 линий связи.Один лишний человек в этом случае увеличивает общение вдвое! Веселье. (Это, конечно, чрезмерное упрощение коммуникации в проектах разработки программного обеспечения.)

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

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

  Итак, начало. Но взаимозависимости принимают множество форм, выходящих за рамки кода. Приведу пример от Mailchimp.

  Риск для клиента: скрытая (но приемлемая?) Стоимость работ по установке межсетевого экрана

  Поскольку клиент Mailchimp часто является владельцем малого бизнеса или новичком в области маркетинга (а миллионы владельцев малого бизнеса стали маркетологами по всему миру), мы должны обеспечить бесперебойную и понятную работу с клиентами. end-to-end .Мы не можем позволить себе роскошь собрать монстра Франкенштейна из облаков путем приобретения так, как это могут сделать корпоративные игроки. Мы не можем избавиться от плохо интегрированного программного обеспечения с консультантами и менеджерами по работе с клиентами.

  Как потребительский продукт (например, Instagram, Nintendo Switch или Roomba), мы должны быть готовы к использованию прямо из коробки. Для универсальной маркетинговой платформы, предназначенной для поддержки вашего бизнеса, это сложно! А это означает, что все, что создает Mailchimp, должно быть легко связано с точки зрения опыта.

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

  Таким образом, вы пытаетесь объединить работу всех вместе — не только на сервере, но и на интерфейсе.В эпоху экосистемы, в которой доминируют передовые навыки CX от таких игроков, как Apple, это стало почти полной ставкой в ​​потребительском пространстве. Но это кошмар Мифического Человеческого Месяца , хотя на этот раз не с инженерной точки зрения. Это с точки зрения дизайна услуг. По мере того, как мы добавляем больше людей ко всей этой «сквозной» подключенной работе, все замедляется до совместного сканирования.

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

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

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

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

  Не забывайте о более мягкой стороне масштабирования

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

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

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

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

  (ра, ил)

  Месяц Мифического Человека. Фредерик П. Брукс составляет… | by CodeBug

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

  Человеко-месяц определяется как «гипотетическая единица, представляющая работу, выполненную одним человеком за один месяц». [Большое спасибо Википедии] Идея состоит в том, что труд и месяцы взаимозаменяемы, и, следовательно, если мы поместим людей и месяцы на декартовую ось, мы можем думать о площади под кривой в человеко-месяцах.

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

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

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

  Первоначальная оценка

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

  Первый наивный подход

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

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

  Восстановительные эффекты первого подхода

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

  Секунда Наивное предположение

  «Добавление рабочей силы в поздний программный проект сделает это позже».

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

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

  Напротив, количество людей, которые мы назначаем для программного проекта, зависит не от количества строк кода, которые нужно написать, а от количества независимых подзадач, на которые можно разделить проект.Под независимыми мы подразумеваем, что подзадачи не имеют сложных взаимосвязей. Сложные взаимоотношения требуют времени синхронизации / общения. При добавлении людей в проект обучение не может быть разделено, и поэтому предельные усилия линейно зависят от количества рабочих. При общении мы еще хуже, поскольку если предположить, что каждая группа должна разговаривать друг с другом, добавленное предельное усилие варьируется как O (n²) или n (n-I) / 2.

  Идеально разбиваемая задача Последовательная задача

  Секрет в расписании: изменение мифического человеко-месяца

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

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

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

  Автор книги « Мифический человеко-месяц », Фредерик П. Брукс, Младший выдвигает идею, которая, вероятно, не слишком шокирует большинство из нас. Он считает, что программная инженерия радикально отличается от все другие формы инженерии в первую очередь потому, что нет физического представление нашего продукта. Он утверждает, что, изучая организация других инженерных направлений может быть полезной, но не может полностью управлять нашим конкретным ремеслом. Я расширю эту идею даже далее с еще одним не столь новаторским заявлением: компьютер игровая инженерия на сегодняшний день является самой эзотерической из всех программных разработок, потому что по сути своей является сложность разработки важнейшего фактор удовольствия.

  О расписаниях

  Два основных способа контролировать наложенные ограничения by Мифический человеко-месяц проходят через график и процесс. Хотя в этой статье рассматривается планирование, дополнительный характеристика, охватывающая технологическую сторону, будет дана в части 2. Мифический человеко-месяц гласит, что добавление людей к проекту закон убывающей доходности до точки, когда растет команда фактически создает чистый незавершенный убыток.Суть этой идеи заключается в сложности разработки программного обеспечения, где каждая команда член работает с виртуальным объектом со значительным количеством вложений на другие штуки. Все эти отдельные части должны быть правильно выстроены. для успеха конечного продукта, поэтому общение между людьми становится экспоненциально сужающимся узким местом по мере расширения команды. Перевод: большую часть дня вы проводите на собраниях. Это особенно актуально по мере того, как проект приближается к концу и объем исторических знаний достигает своего пика.Однако пока этот генерал догмат верен, скорость спада и переход, когда добавление нового человека вызывает переменную чистую потерю производительности. Лучший способ контролировать эти переменные — это знать масштаб и ресурсы вашего проекта, особенно людские ресурсы. И это понимание должно выходить за рамки простого подсчета голов и достигать истинное понимание того, что ваша команда состоит из самых разных люди, которыми нужно управлять по-разному. Эффективный стратегия управления, включая график и процесс, может значительно повысить продуктивность данной команды и, таким образом, расширить The Mythical Человеко-месяц до предела.

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

  Удивительно, но я до сих пор встречаю команды с очень плохими или даже очень плохими несуществующие графики. В первые годы своей карьеры я работал в трех играх под названием Esoteria , Tube Racer и Beneath .Никогда о них не слышали? Точно. Первую еле выпустили и вероятно, было продано всего пару сотен единиц, а следующие два были оба были отменены после многочисленных превышений графика. Все бесконечно страдали из-за отсутствия надлежащего расписания. С тех пор я отправил каждые игру, которую я провел вовремя, в основном из-за отличных графиков, которые давали мне нужна информация, чтобы изменить мою команду, когда возникнут новые проблемы возникла. За последний год работы в издательстве Microsoft я видел много игр. корабль и многие игры убиты: постоянная тема пробегает по ним все дело в том, что плохое планирование приводит к отмене проектов.

  Этапы жизненного цикла проекта

  Чтобы понять планирование игры, вы должны сначала понять этапы существования, через которое проходят все проекты. Пока абсолютное время каждой фазы колеблется в зависимости от общей продолжительности проекта, там являются обычными отношениями времени между ними. Первый этап — концепция разработка. Вы находитесь в творческом периоде, когда мозговой штурм голубого неба это цель. На данный момент вам не нужны реальные графики помимо простой установки крайнего срока для завершения этих первоначальных встреч.По завершении этого этапа у вас должен быть четко определенный дизайн. документ с обсуждением не только игрового процесса, но и арта, и Инженерно-ориентированные секции. Это должно занять примерно 1/8 от общего срока или около трех месяцев из 24-месячного проект.

  Следующий этап — это ваш прототип, где вы доказываете основные неизвестные, прежде всего забавный фактор. Этот раздел запланирован как и вся игра, только с сокращенным таймфреймом, обычно около 1/8 от общего объема проекта, но иногда увеличивается в зависимости от по исходной технологии.Очевидно, что чем стабильнее набор инструментов и двигатель, с которым вы стартуете, тем больше вероятность того, что прототип упадет в пределах трехмесячной сметы. Если прототип удачен, вы должны покинуть этот этап с четким пониманием того, что сделает игру интересной, и пример программы, которая передает это идея. Наряду с этим также будет список задач системного уровня с расчетное время, отведенное на разработку этих новых систем. В других словами, не все основные системы могут быть созданы, но вы должны знать кто они, и имеют приблизительное представление о людях, необходимых для завершить свой первый проход.Это этап, когда независимые разработчики следует начать поиски издателей. Хотя некоторые разработки домам посчастливилось подписаться только с бумажными презентациями, появление рабочего прототипа идет значительно дальше, когда пытаясь заключить сделку.

  Ваш следующий этап — подготовка к съемке, когда команда решает оставшиеся незавершенные системы, по крайней мере, после первой реализации. Например, ваша новая экспериментальная система освещения с динамическим тени должны работать вместе с решением продолжить поработайте над ним или отрежьте из-за проблем.Вы также должны иметь первая пара уровней завершена до альфа-качества для экстраполяции усилия, необходимые для прохождения оставшихся уровней. Первый уровень всегда занимает больше всего времени и обычно оказывается худшим, потому что ваша команда привыкает к процессу и новой игре вы изготовление. Итак, вы должны пройти два или три уровня, чтобы команда начала приближаясь к тому, какой будет реальная рабочая сила на каждый уровень. Один раз вы сделали это, вы сможете обозначить остальное время кадра и знайте, нужно ли вам немедленно уменьшить количество уровней.Этот этап должен занять около шести месяцев из 24-месячного проекта. или 1/4 от всего проекта.

  Теперь вы входите в полноценное производство, что обычно происходит, когда ваша команда достигает своего максимального размера (без дополнительных функций, необходимых для тестирования, которые обычно появляется позже). На этом этапе игра должна доставлять удовольствие и его следует знать полностью. Здесь уровень вашей системы список задач постоянно уточняется, уменьшая и уменьшая разрешения. Теперь процесс становится механическим, а не произвольным. концептуальные этапы в начале.Ваше расписание теперь конец всего в основе существования проекта. Вы должны ожидать, что на этот раз длиться около девяти месяцев или полных 3/8 проекта, что делает его самый длинный этап. Этот раздел разработки заканчивается кодом и контентом. полное значение все в игре так, как было изначально планируется. Это не значит, что игра должна быть полностью заблокирована. поскольку окончательные изменения все еще могут быть внесены в альфа-версию, если это предлагается изменения значительно улучшают общее качество игры с ограниченный риск.

  И вот мы подошли к концу, финальному этапу. Вот что вы достигли альфа- и бета-версии, также известной соответственно в Microsoft как полный код / ​​контент и релиз без ошибок (ZBR). Эти этапы в основном определяются длительным временем кризиса. Программирование ориентировано по исправлению ошибок, художественный отдел по финальной полировке и тест команда работает на полную мощность. График становится менее структурированным и вместо этого команда управляется ежедневными и ежечасными обновлениями полученный от группы тестирования вместе с надзором со стороны ведомственного ведет и продюсер.По сути, ваше программное обеспечение для отслеживания ошибок становится ваше расписание, когда вы делаете последний спринт, который обычно длится примерно три месяца из 24 или 1/8 всего.

  Как только вы поймете эти этапы развития, вы станете лучше возможность их планировать. Важным моментом является то, что эти дроби предназначены для руководства, а не для строгих правил. Все проекты расширяются и уменьшайте эти этапы по мере необходимости. Пока один проект требует больше времени на прототипирование, другому нужно меньше на производство.Или возможно, ваш проект представляет собой одновременный выпуск для трех консолей, вероятно увеличит ваше абсолютное время, потраченное на последнюю ошибку толкать. Однако эти рекомендации должны помочь вам определить более ранние когда конкретный этап превосходит все ожидания. Например, если вы работали над прототипом девять месяцев, вы не должны ожидать завершить игру в следующем году. Ваша команда явно создала много новых технологий и игрового процесса, если на прототип, поэтому только время наращивания при сборке полной игры будет помешать вашей команде финишировать в наступающем году.Работа в Издательство Microsoft показало, что эти временные соотношения работают успешно. для многих проектов, включая Counter-Strike для Xbox, который был по сути пятимесячным проектом, а Whacked , который был двухлетним. У этих двух проектов были совершенно разные абсолютное время, но аналогичные отношения между сегментами.

  ______________________________________________________

  ---

  Построение расписания

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

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

  Понять команду

  Следующий этап — понимание кадрового состава вашей команды. Вам следует начните с определения типа разработчика (любой член команды, включая программисты, художники, дизайнеры уровней и т. д.) каждый человек в вашей команде есть. Один простой способ сделать это — проанализировать, как они делятся на четыре основных типа, основанные на комбинации навыков и преданности делу.Эти типы могут быть представлены в простой матрице 232 с их уровень мастерства на одной оси и их преданность делу на другой. Разработчики около нижнего конца обеих осей, малоопытные и плохие моральный дух, должен быть удален из проекта после того, как будут предприняты попытки чтобы улучшить их преданность делу. Для улучшения навыков требуется значительное время, поэтому не ожидайте, что это повысится в течение одного проекта, но моральный дух человека, конечно, может. Однако, если вы не можете способствовать улучшению в разумные сроки, скажем, на 1/4 общей длины проекта, удалите их либо от проекта, либо от компании.Слишком много лидов позволяют плохие исполнители, чтобы оставаться в позициях, где они бросают мяч и подорвать моральный дух окружающих. Удаление плохого исполнителя довольно часто может принести чистую прибыль всей команде, даже если потеря головы. Моя предыдущая работа в Presto Studios показывала лично мне, какой ущерб может нанести один или два низкоуровневых участника общая загруженность и моральный дух команды.

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

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

  И, наконец, мы познакомились с самыми важными людьми на команда: суперзвезды. Они высококвалифицированные, высокомотивированные команда, которая делает невозможное возможным. Это раскаленный добела огненный ядро солнца, которое будет двигать ваш проект, когда ситуация станет жесткой. Они будут работать по выходным, даже если их не попросят. Они принесут в спальных мешках при необходимости и работать всю ночь при необходимости вернуться к расписанию. Работайте над соотношением 1: 3 между суперзвездами и два других типа разработчиков.(Помните, вы уже должны были уволили первую группу, так что у нас осталось всего три группы.) Ваши суперзвезды — ваша первая и последняя линия защиты от не хватает ваших вех.

  Назначьте команду

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

  С людьми, назначенными на список задач, лидерство должно взять на себя первый проход при назначении времени для каждой работы. Будьте либеральны со своими оценками; оптимизм быстро убивает любой график, поэтому предполагайте, что ошибки быть сделано. Идите вперед и возьмите на вооружение ваши сложные системы, определяющие продукт нужно будет переписывать два-три раза.После завершения принесите ваша команда вместе и в группе обсудите ваши оценки, соберите Мнения противоположные, и согласовываем окончательную смету по графику. Помните, что даже если вы ведущий, это люди, которых вы назначили к задаче, которая должна выполнить ее в назначенное время. Давать за ними последнее слово, если вы не можете прийти к консенсусу.

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

  Теперь мы должны заложить эти данные в наше программное обеспечение для расписания. Положите каждый человек бездействует по шесть часов в день пять дней в неделю. Даже если ты ожидайте марша смерти, не начинайте с его планирования. Это Верная ставка на то, что вы сорвете ваши дедлайны в будущем. Шестичасовой рабочий день охватывает время в течение восьмичасового рабочего дня, когда человек будет на собраниях, обедать или гулять на кухне, есть булочку с команда. Не забудьте поставить праздники. (Я смеюсь каждый раз, когда вижу расписание, в котором кто-то выполняет задание на Рождество.) А также как правило, предполагается, что каждый разработчик возьмет один личная неделя времени каждые четыре месяца.

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

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

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