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

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

«Качество появляется только тогда, когда кто-нибудь несёт ответственность лично».
— Фредерик Ф. Брукс



Привет, хабр!

Предлагаю вашему вниманию вольный перевод эссе "A Generation Lost in the Bazaar" Пола-Хеннинга Кампа, повествующего нам о печальной судьбе поколения IT-профессионалов, выросших в период бума доткомов, а также о фундаментальных проблемах в UNIX, напрямую влияющих на качество и портабельность ПО. Обо всём по порядку.

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

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

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



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

Где же золотая середина, баланс базара и матрицы? Навряд ли в обозримом будущем появится однозначный универсальный ответ на этот вопрос. Но есть принципы планирования и совершенствования совмещения труда на отдельно взятом производстве (организации), которые и представлены в данной статье с упором на сферу разработки программного обеспечения.

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

После прочтения прошу всех пройти опрос.

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

Предисловие

Есть распространенное мнение: «если бы строители строили дома так же, как программисты пишут программу — первый залетевший дятел разрушил бы цивилизацию». С подачи индийского гуру-программиста Мурали Кришна Чимутури (Murali Krishna Chemuturi), Интернет настойчиво приписывает авторство этой цитаты Джеральду Вайнбергу (Gerald Weinberg), хотя на личном сайте Джеральда она не ищется. Скорее всего, человек, который первый заговорил о психологии в программировании, к этому высказыванию не имеет никакого отношения. И вот, почему.

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

Материальное производство (обработка объектов физического мира) насчитывает десятки тысяч лет истории. На этом пути был накоплен колоссальный объем знаний естественных наук: математики, физики, химии, географии, геологии, биологии и проч.

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

Время — судья

Книга “мифический человеко-месяц”, заслуживает того, чтобы её читали и перечитывали, издавали и переиздавали. В 2025 году, а он не за горами, будет 50 лет первому изданию. Т.е. проверка временем пройдена. В 1995 году вышло юбилейное издание (ждём юбилейного издания 2К25), в предисловии к которому, автор, помимо прочего, сообщает:

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

Кто празднику рад, тот накануне пьян

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

В споре рождается истина

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

А заодно расслабиться, и повеселиться. Не воспринимайте написанное слишком буквально — без смешного нельзя понять серьёзное.

Написано в сотрудничестве с Ревазом Бухрадзе (редактор: Ангелина Кипелова)

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