10.10.2026
Про сроки
Менеджер:
— Сколько тебе нужно времени, чтобы сделать эту задачу?
Программист:
— Два дня.
— А если поднапрячься?
— Тогда четыре.
Почему этот анекдот смешной и грустный одновременно
Если вы хотя бы раз заказывали сайт, приложение или кнопку «Отправить» на сайте, вы знаете эту магию. Вы спрашиваете: «Сколько займёт?» И слышите заклинание: «Ну, дней пять, если ничего не всплывёт».
«Всплыть» может всё. API упадёт. Дизайнер передумает. Клиент скажет: «Давайте синий, но не такой синий». Меркурий войдёт в ретроградную фазу. Кот пройдётся по клавиатуре и закоммитит в прод.
Этот анекдот — не шутка. Это документально подтверждённая реальность. В 1975 году Фредерик Брукс, инженер IBM и автор книги «Мифический человеко-месяц», сформулировал закон, от которого менеджеры до сих пор просыпаются в холодном поту: **«Добавление людей в опаздывающий проект задерживает его ещё больше»** .
Если вы думаете, что «поднапрячься» — это нанять двух разработчиков и ускориться, вы не просто неправы. Вы катастрофически неправы. И Брукс объяснил почему ещё полвека назад. А мы всё равно наступаем на те же грабли. С завидным упорством. Каждый день.
1 часть. Человеко-месяц — главный миф IT
Логика, которая работает только для рытья ям
Человеко-месяц — единица измерения, которую обожают менеджеры, никогда не писавшие код. Логика простая: один программист делает месяц, два — две недели, четыре — неделю. Восемь — за три с половиной дня. Красиво, правда?
Это работает для сбора картошки. Для покраски забора. Для рытья ям. С разработкой — не работает. Никогда.
Почему? Потому что разработка — это не механический труд. Это коммуникация. Это согласование. Это двадцать минут спора о том, назвать переменную `data` или `payload`. Это код-ревью, где три взрослых человека обсуждают, нужна ли здесь запятая.
Брукс писал: «Человеко-месяц — опасный миф. Люди и месяцы не взаимозаменяемы». Перевод: если вы думаете, что можно просто «добавить людей», вы живёте в мире фантазий. В реальном мире каждый новый человек — это не пара рук, а узел в сети коммуникации. Два человека — одна связь. Пять — десять связей. Десять — сорок пять. Попробуйте держать это в голове и писать код. Удачи.
Это работает для сбора картошки. Для покраски забора. Для рытья ям. С разработкой — не работает. Никогда.
Почему? Потому что разработка — это не механический труд. Это коммуникация. Это согласование. Это двадцать минут спора о том, назвать переменную `data` или `payload`. Это код-ревью, где три взрослых человека обсуждают, нужна ли здесь запятая.
Брукс писал: «Человеко-месяц — опасный миф. Люди и месяцы не взаимозаменяемы». Перевод: если вы думаете, что можно просто «добавить людей», вы живёте в мире фантазий. В реальном мире каждый новый человек — это не пара рук, а узел в сети коммуникации. Два человека — одна связь. Пять — десять связей. Десять — сорок пять. Попробуйте держать это в голове и писать код. Удачи.
История одного провала: миллионы долларов в никуда
В поисковых результатах есть реальный кейс: IT-программа по обработке страховых требований опаздывала. Менеджер предложил «поднапрячься» — нанял двадцать-тридцать разработчиков и открыл второй офис в Санта-Кларе .
Что дальше? Руководители проектов вместо кода тратили 50-75% времени на обучение новичков и координацию между офисами. Продуктивность упала. Расходы выросли на миллионы. К дедлайну было готово половина запланированного.
Один из менеджеров потом сказал: «Если бы мы не создали команду в Санта-Кларе, мы, вероятно, сделали бы то же самое за то же время».
Прочитайте ещё раз. Они потратили миллионы и не получили ничего. Ноль. Абсолютный ноль ускорения. Это не исключение. Это правило. Это гравитация IT.
Что дальше? Руководители проектов вместо кода тратили 50-75% времени на обучение новичков и координацию между офисами. Продуктивность упала. Расходы выросли на миллионы. К дедлайну было готово половина запланированного.
Один из менеджеров потом сказал: «Если бы мы не создали команду в Санта-Кларе, мы, вероятно, сделали бы то же самое за то же время».
Прочитайте ещё раз. Они потратили миллионы и не получили ничего. Ноль. Абсолютный ноль ускорения. Это не исключение. Это правило. Это гравитация IT.
2 часть. Сколько на самом деле занимает разработка
Лендинг: «от трёх дней» и другие сказки
Когда я вижу «сайт на Tilda за 3 дня», у меня дёргается глаз. Не потому, что невозможно. А потому, что возможно только при условиях, о которых умалчивают.
Смотрим реальные цифры. СПбГУ публикует официальные сроки: лендинг на Tilda — **от 10 рабочих дней**. Многостраничник — от 14. Кастом — от 30 . Агентство SiteLabs: 10-30 дней .
А теперь смотрим фриланс-платформы. Kwork: сайт до 4 блоков — 3 дня . Разница в три с лишним раза. Почему?
Потому что «сайт до 4 блоков» — это не сайт. Это заглушка. «Здравствуйте, я компания такая-то, вот контакты». Никакой аналитики, структуры, копирайтинга, интеграций, тестирования.
Если вам нужен лендинг, который **продаёт**, три дня — фантастика. Двадцать лет назад это называлось «сделать сайт». Сейчас — «сделать вид, что у вас есть сайт».
Смотрим реальные цифры. СПбГУ публикует официальные сроки: лендинг на Tilda — **от 10 рабочих дней**. Многостраничник — от 14. Кастом — от 30 . Агентство SiteLabs: 10-30 дней .
А теперь смотрим фриланс-платформы. Kwork: сайт до 4 блоков — 3 дня . Разница в три с лишним раза. Почему?
Потому что «сайт до 4 блоков» — это не сайт. Это заглушка. «Здравствуйте, я компания такая-то, вот контакты». Никакой аналитики, структуры, копирайтинга, интеграций, тестирования.
Если вам нужен лендинг, который **продаёт**, три дня — фантастика. Двадцать лет назад это называлось «сделать сайт». Сейчас — «сделать вид, что у вас есть сайт».
Приложения: где время течёт, как песок
Приложение — не «сайт, только в телефоне». Это отдельная вселенная. Нужно: разработать под iOS и Android (или выбрать кроссплатформу и страдать от ограничений), протестировать на десятках моделей, пройти модерацию в App Store и Google Play (отдельный вид боли), настроить push, обеспечить безопасность, и всё это — с учётом того, что Apple и Google выпускают новые ОС каждые полгода.
Сроки на приложения измеряются месяцами. И даже тогда «месяц» — очень оптимистичная оценка. Очень.
Сроки на приложения измеряются месяцами. И даже тогда «месяц» — очень оптимистичная оценка. Очень.
Фактор «поднапрячься»
Возвращаемся к анекдоту. Почему «поднапрячься» = четыре дня вместо двух?
Потому что «поднапрячься» означает:
1. Добавить людей — которые не знают проект, будут отвлекать ключевых разработчиков, увеличат коммуникационную нагрузку.
2. Срезать углы — пропустить тестирование, забить на документацию, не делать код-ревью.
3. Работать сверхурочно — что ведёт к выгоранию, ошибкам и ещё большему времени на исправление.
Брукс сформулировал это как закон: на поздних стадиях проекта добавление ресурсов не ускоряет, а замедляет его.
Контринтуитивно. Бесит. Правда.
Потому что «поднапрячься» означает:
1. Добавить людей — которые не знают проект, будут отвлекать ключевых разработчиков, увеличат коммуникационную нагрузку.
2. Срезать углы — пропустить тестирование, забить на документацию, не делать код-ревью.
3. Работать сверхурочно — что ведёт к выгоранию, ошибкам и ещё большему времени на исправление.
Брукс сформулировал это как закон: на поздних стадиях проекта добавление ресурсов не ускоряет, а замедляет его.
Контринтуитивно. Бесит. Правда.
3 часть. Откуда берутся сроки и почему они врут
Парадокс планирования
Почему программисты не могут точно сказать, сколько займёт задача? Потому что разработка — исследовательская деятельность. Каждый проект уникален. Каждая интеграция — приключение. Каждая функция — гипотеза.
Представьте, что вас просят оценить, сколько времени займёт написание книги. Конкретной книги, которую вы ещё не написали. Вы знаете тему и объём. Но не знаете: пойдёт ли текст, сколько раз перепишете первую главу, не выяснится ли на середине, что концепция — чушь.
С кодом то же самое. Только код имеет обыкновение не компилироваться по причинам, которых вчера не существовало.
Представьте, что вас просят оценить, сколько времени займёт написание книги. Конкретной книги, которую вы ещё не написали. Вы знаете тему и объём. Но не знаете: пойдёт ли текст, сколько раз перепишете первую главу, не выяснится ли на середине, что концепция — чушь.
С кодом то же самое. Только код имеет обыкновение не компилироваться по причинам, которых вчера не существовало.
Откуда взялась «оценка в человеко-месяцах»
Брукс: «Наши методы оценки основаны на предположении, что человеко-месяцы взаимозаменяемы. Но люди и месяцы не взаимозаменяемы».
Перевод: если вы думаете, что можно «добавить людей» и уложиться в срок, вы в мире фантазий. В реальном мире новые люди замедляют проект, обучение отвлекает опытных, коммуникация растёт, продуктивность падает, проект опаздывает сильнее, чем если бы вы ничего не делали. Это не теория. Это эмпирический факт .
Перевод: если вы думаете, что можно «добавить людей» и уложиться в срок, вы в мире фантазий. В реальном мире новые люди замедляют проект, обучение отвлекает опытных, коммуникация растёт, продуктивность падает, проект опаздывает сильнее, чем если бы вы ничего не делали. Это не теория. Это эмпирический факт .
4 часть. Как говорить о сроках, не сходя с ума
Клиентам: что спрашивать вместо «сколько времени?»
Не спрашивайте «сколько займёт». Спросите:
- «Какие этапы выделим, чтобы я видел прогресс?»
- «Что входит в базовую стоимость, а что — доплата?»
- «Что мне подготовить, чтобы не тормозить?»
- «Как решим, что проект готов?»
Хороший исполнитель даст диапазон, а не дату. И объяснит, от чего зависит, попадёте вы в нижнюю границу или в верхнюю.
- «Какие этапы выделим, чтобы я видел прогресс?»
- «Что входит в базовую стоимость, а что — доплата?»
- «Что мне подготовить, чтобы не тормозить?»
- «Как решим, что проект готов?»
Хороший исполнитель даст диапазон, а не дату. И объяснит, от чего зависит, попадёте вы в нижнюю границу или в верхнюю.
Исполнителям: как не обещать невозможного
Хочешь рассмешить бога — расскажи о планах. Хочешь рассмешить программиста — расскажи о дедлайне.
Если оцениваете проект:
1. Умножайте на два. Не пессимизм. Статистика.
2. Не соглашайтесь на «поднапрячься». Ловушка. Не ускоритесь. Будете работать больше и получите хуже.
3. Фиксируйте объём, а не срок. «Сделаем вот это» честнее, чем «закончим к пятнице».
4. Помните о Бруксе. Проект опаздывает? Не добавляйте людей. Сокращайте объём.
Если оцениваете проект:
1. Умножайте на два. Не пессимизм. Статистика.
2. Не соглашайтесь на «поднапрячься». Ловушка. Не ускоритесь. Будете работать больше и получите хуже.
3. Фиксируйте объём, а не срок. «Сделаем вот это» честнее, чем «закончим к пятнице».
4. Помните о Бруксе. Проект опаздывает? Не добавляйте людей. Сокращайте объём.
5 часть. Нейросети и ИИ — новое слово в старом анекдоте
«Но подождите! — скажете вы. — Есть же ИИ! ChatGPT! Copilot! Они пишут код за секунды!»
Да, пишут. И это меняет правила. Но не так, как вы думаете.
ИИ ускоряет типовой код. Шаблонные функции, CRUD, простая вёрстка — да, быстрее. Но: архитектуру проектирует человек. Интеграции с легаси требуют ручной работы. Отладка сгенерированного кода иногда занимает больше времени, чем написание с нуля. Ответственность всё равно на человеке.
И главное: ИИ не отменяет закон Брукса. Добавьте десять нейросетей — проект не станет быстрее. Он станет страннее.
Да, пишут. И это меняет правила. Но не так, как вы думаете.
ИИ ускоряет типовой код. Шаблонные функции, CRUD, простая вёрстка — да, быстрее. Но: архитектуру проектирует человек. Интеграции с легаси требуют ручной работы. Отладка сгенерированного кода иногда занимает больше времени, чем написание с нуля. Ответственность всё равно на человеке.
И главное: ИИ не отменяет закон Брукса. Добавьте десять нейросетей — проект не станет быстрее. Он станет страннее.
Заключение: почему четыре дня — это честно
Вернёмся к анекдоту. Программист говорит «два дня». Вы говорите «поднапрячься». Он говорит «четыре».
Это не лень. Не неуважение. Не желание выбить побольше денег. Это профессиональная честность человека, который знает: «поднапрячься» означает работать больше с меньшей продуктивностью, пропускать проверки, создавать техдолг и в итоге потратить вдвое больше времени, чем если бы вы просто дали ему спокойно сделать работу за два дня.
Брукс написал книгу в 1975 году. С тех пор появились персональные компьютеры, интернет, смартфоны, облака, ИИ и Tilda. А закон Брукса всё ещё работает. Потому что он не про технологии. Он про людей.
А люди не меняются. Люди всё ещё думают, что «поднапрячься» — это стратегия.
Это не стратегия. Это ловушка.
И если ваш программист говорит «четыре дня», когда вы просите «поднапрячься», — поздравляю. Вы нашли человека, который читал Брукса. Или, что ещё лучше, сам дошёл до этого на практике.
Берегите его.
Это не лень. Не неуважение. Не желание выбить побольше денег. Это профессиональная честность человека, который знает: «поднапрячься» означает работать больше с меньшей продуктивностью, пропускать проверки, создавать техдолг и в итоге потратить вдвое больше времени, чем если бы вы просто дали ему спокойно сделать работу за два дня.
Брукс написал книгу в 1975 году. С тех пор появились персональные компьютеры, интернет, смартфоны, облака, ИИ и Tilda. А закон Брукса всё ещё работает. Потому что он не про технологии. Он про людей.
А люди не меняются. Люди всё ещё думают, что «поднапрячься» — это стратегия.
Это не стратегия. Это ловушка.
И если ваш программист говорит «четыре дня», когда вы просите «поднапрячься», — поздравляю. Вы нашли человека, который читал Брукса. Или, что ещё лучше, сам дошёл до этого на практике.
Берегите его.
Это часть серии IT-разбор с юмором. Смотрите больше ➜