чтобы понять и освоить методологию, которая описана в статье, у меня ушел 1 проект. Больше того, я полезные шаблоны утащил и потом долго еще применял в других местах. А матрицей рисков и проблем пользуюсь до сих пор - простая и удобная
чтобы понять, как применять ГОСТ, у меня ушло несколько лет. Неясно, когда нужна ПЗ к ТП, когда нет. Неясно, зачем заполнять все формальные разделы ТЗ - часто выглядит излишним. Неясно, когда делать кучу других документов (привет "Описанию языков программирования"), а когда не нужно. Но вообще еще раз да - он норм. Вот ему масштабируемость можно было бы попробовать прикрутить и сделать визуализацию - было бы интересно.
А я не призываю такое внедрять. Я буду рад, если РП и начинающие РПО просто прочитают и отложат в голове что "бывает и так" , а потом что-то из этого внедрят у себя.
Визуализацию
Шаблон, в котором будет написано, что и как писать
Разные пакеты документов для разного размера проектов
А уже если вдруг кто-то придет из крупняка и расскажет, что это все фигня - вот у них... Я с удовольствием признаю, что это не идеал.
Любую best practice можно раскритиковать. Но это не повод ничего не делать вообще.
показать РПшникам и РПОшникам, которые не видели подобного максималистского подхода, что он бывает и что гдето - это best practises
что корпоративная методология - это не PMBoK и не ГОСТ и не P3, а что-то индивидуальное, что им не противоречит.
ну и лично для меня важно: я в РФ не видел ни одной методологии, где была бы вшита масштабируемость. Если кто-то это увидит и внедрит - я буду очень рад, считаю это важным для больших отделов.
Аудитория Хабра такова, что как только будет ссылка на идеал комментаторы напишут, что он неидеален, потому что неприменим для их деятельности. И даже будут правы, скорее всего. Потому что для производственных проектов - одни этапы и их наполнение, для проектов разработки ПО - вторые, а для внутренних команд разработки - третье.
А должно быть что-то у всех.
Цель статьи - показать как это может выглядеть "по максимуму" - раз, и что это отличается от PMBoK (хотя и полностью ему соотвествует) - два.
В остальном - спасибо за комментарий. Первоначально пост и правда был на канале, что уж тут сделаешь и да , я даю на него ссылку, там вся аудитория с Хабра, так то :)
Все вместе эти шаги не только убирают хаос (потому что описанный процесс управления убирает бардак), но и снижают стоимость обучения персонала + его конечную цену (людей можно брать дешевле).
и если тут все очевидно, и базара ноль, у меня вопрос: Если это настолько элементарно, почему этого никто не делает?
Почему сейчас, работая как приглашенный эксперт я вижу какую то кашу из документации, которую каждый РП делает так, как ему хочется? И это касется не только SMB, это вполне себе большие конторы и в госухе и в коммерции.
Расскажите, если знаете ответ, мне искренне интересно.
за водой не заметили ребенка - отчасти согласен, чтобы сделать статью краткой и неунылой, я часть сократил.
Но если вы ждете от меня описания всех проектных артефактов - смысла в этом ровно ноль, и я написал ниже, почему: вы (или любой другой комментатор) мне в 2 счета докажет, что эта документация для его проектов не нужна/лишняя.
Тогда зачем описывать детальные артефакты, когда они для каждой компании уникальны?
Сам подход , где есть процесс/роли/шаблоны - обычный.
Подход, где он
а) визуализирован наглядно
б) максимально наполнен
в) при этом гибкий и масштабируемый
уникален.
просто нет других таких методологий. ГОСТ масштабируется, но далеко неочевидно.
Так что есть куда расти крупнякам - я бы на их месте смотрел сюда, а не нанимал десятки администраторов проектов для сведения отчетности по отделам.
А мелким надо понимать, что им не ПМБоК нужен, а совсем другая, простая история.
PS: а про канал сказано в начале ровно один раз - честно говоря, не виду проблемы сказать что это статья реально по мотивам моего поста там. И там он популярен. Могу дать пруф :)
золотые слова. в статье какое то унылое нытье о несправедливости мира. удивительно, но когда нормально работаешь и умеешь в социальные связи, о тебе не дают такого отклика, как выше. А вот когда бездельник - дают, вот дела...
Хорошо все было, все слова правильные и на самом интересном месте - расчете ROI на фичу - никаких деталей.
А ведь оно должно использоваться при приоритизации и его расчет важен.
Больше, по моему опыту, нормально его почти никто (точнее никто, даже часто я сам) посчитать не может. Считают "от балды", а потом никто не проверяет. Так все и живут в приоритетах "ГД сказал - надо", "Коммерческий просил сделать" - вот и весь RICE =)
Я думаю, я вас понимаю, потому что было время, я был сторонником сразу и честно слать нах с невозможными требованиями.
С тех пор я набрался опыта и понял
часто (реально) мое "невозможно" - это просто страх подумать и предложить компромиссы.
тактичное общение и желание искать решение, помогая заказчику, дает более другие отношения, которые в итоге дают больше денег по аккаунту - маркетинг отношений.
тех, кому пофигу на два пункта выше, а "просто пойди и сделай без вопросов и обиняков" - реально мало и с ними можно не работать, но только после выполнения 2х пунктов выше.
Это вопросы, а не отговорки. Ответы на них определяют варианты решения. Без ответов на эти вопросы работа будет зря и не в срок, который вам нужен. Возможно я обосновал недостаточно подробно и понятно, позвольте пояснить пояснить еще раз?
Ну и так далее.
Обычно полный неадекват говорит о том, что вы все равно не сработаетесь. Тут или брать под козырек , а потом получать ушат чувства вины, или вообще с этим не работать.
Но такого даже в госухе обычно мало (если брать интеграторов, которые работают с госами). Такое сильно выражено именно при работе в самом госе (ФОИВ, РОИВ) + силовики любят жестить.
Но в госорганах работать - удовольствие, очевидно, специфическое и радости в виде коррупционных схем "когда то, если повезет подняться" - не для каждого.
А к силовикам без сильной руки ни один РП не ходит, там всегда есть сейлз, которого и надо слушаться.
По опыту - это 10% рынка неадеквата гдето. Работать там или нет - решать каждому. Мой метод не про то, чтобы это терпеть. А чтбы попробовать вывести на конструктив и уходить только потом, а не убегая от проблемы
Я, как менеджер, заложил бы и месяц, да ктож мне даст? Вы всерьез думаете, что менеджер может выбрать комфортные для себя сроки, но почему то раз за разом не выбирает, потому что любит страдать? Это не так
угу
А я и не давал. Они попросили пойти на встречу. Можно было даже отказаться по формальному признаку. Но просто потом ( не точно но вероятно, из опыта), пришли бы ребята, которые в этой ситуации сделали, и в следующий раз заказчик выберет их.
"Да я отлично вас понимаю, вы хотите, чтобы я выполнил ваши указания. Вы же не хотите, чтобы я просто, не думая, взял вашу критичную задачу и сорвал ее исполнение? Я считаю это непрофессиональный подход.
Поэтому перед выполнением я задаю вам вопросы выше, которые надо решить. Так что давайте к ним вернемся."
Я прочитал вашу статью про психологическую безопасность. Мне есть что сказать.
Я считаю верным такой подход. Хотя я сам склонен к тирании (особенно когда поджимают сроки), я всегда слушаю реальные аргументы или стараюсь показать "как надо". Собственно, потому все мои менеджеры (реально) дали мне очень высокие оценки по итогам работы за 5 лет. Мы именно так и работали.
Но. Моя практика показывает, что таких шефов хорошо если 50%, я бы сказал, что у меня за все время было таких 2 из где-то 20ти.
а бОльшая часть или орет, или отдает указания и ловит на неисполнении, ничего не объясняя. Ты попал - значит ты лох, испытай вины.
И мои правила - для работы в том числе в такой среде. Где давят, где прессингуют, где есть откровенно странные дедлайны и те, кто на них уже согласился (внезапно это может быть ваш шеф). Я не хочу исправлять мир Российского ИТ - он за 25 лет не изменился, и, судя по моим наблюдениям, изменится только в худшую сторону. Я хочу дать начинающим менеджерам инструменты, как не выходить из конструктива.
Научатся - значит сделают наш мир чуточку лучше.
Потому что даже самые неадекватные заказчики иногда становятся нормальными, когда понимают, что их не подставляют, а реально дают результаты в озвученные сроки.
В статье сказано, что формат "да, но" - это тоже самое "но", не стоит говорить :)
Про ваш пример, я для начала спрошу вас, как заказчика: что именно вам нужно, какую боль решает ребенок, почему нужен он (сразу ребенка технически родить действительно нельзя), а недостаточно прототипа ребенка, mvp, скажем - вот он в животе, смотрите.
Вы хотите реального ребенка? А вы знаете решения, которые его дадут через месяц? Мне, как профи рынка, известно ровно то, которое дает за 9, не менее.
Как видите, я нигде не сказал "нет" и "да, но" и при этом нигде не согласился. Зато спросил главный вопрос "а зачем?" и "что именно надо?"
Как правило, бизнес может давить/прессинговать, но крайне редко он полностью лишен адекватности. А значит, договариваться можно в 90% случаев по моему личному опыту. Да, 10-15% на истории, когда после выяснения объема имеет смысл сказать: "я понял ваши требования, наше КП содержит несколько вариантов, максимально к нему приближенных. Если заинтересует - дайте знать". Но остальные 90% мой подход поможет договориться.
За 25 лет не обошлось. Подозреваю, что и не обойдется. Больше того: за эти 25 лет я пробовал разные стратегии. Предлагаемая - позволяла с большей вероятностью выстраивать хорошие продуктивные отношения, которые давали +%% YoY если вы понимаете, о чем я.
Уже потом я прочитал у Котлера, что это маркетинг отношений и это крайне важная штука.
И я вам не поверю, у меня есть много опыта (и я сам поступал несколько раз также с менеджерами/поставщиками): если мне долго/дорого объяснять простые вещи - надо менять человека/поставщика услуги. Рынок играет именно так, нравится это мне (вам или кому либо еще) или нет.
И если поставщик услуги отказывается ее исполнять - его сменят.
Конечно , дальше будет много интересностей про то "а было ли это вообще выполнимо" и тут я тоже скажу: практика ИТ рынка показывает, что более менее выполнимо 90% как раз изза метода, предлагаемого мной.
Даже когда вы берете конкурс на 300 млн за 100, и у вас 3 мес на реализацию - вопрос решаемый совершенно официальным путем.
Так что я считаю, это личный выбор каждого человека: сказать "это невозможно" или попробовать и заработать. Никого не принуждаю, ведь тут можно и не заработать, риск, разумеется, есть.
спасибо. Пожалуй, согласен с вами. Почему не писал про такой вариант: его очень сложно объяснить - раз. А второе: бизнес иногда реально не готов услышать "нет" ни в какой форме. Да, это агрессия, да это токсично и блаблабла.
Факт в том, что такого бизнеса у нас - 50% точно (это я аккуратно сказал). Да что там бизнес: мне лично мои манагеры говорили "нет, невозможно", "нет ресурсов". И я показывал , как можно и что ресурсы есть - надо просто голову чуть иначе включить: не искать аргументацию, почему нет, а подумать, что надо, чтобы да.
С точки зрения такого манагера я что - токс? :) Ну ок, а с моей - он непрофессионал :)
Видите как? Именно поэтому лучше просто учиться делать все по шагам, они выстраданы:
уйти подумать, что надо, чтобы "да"
предложить варианты решений, пусть неидеальный
и если там неконструктив ок: "покажите как это сделать мне, я не понимаю" - все.
Перечитал. В части понимания своих профессиональных границ - согласен, их каждый должен понимать (что я готов делать, а где я говорю "хватит" и ищу новое место). Как я сказал выше: по моему опыту, мой подход решал бОльшую часть неконструктива от заказчика и руководства. Хотя исключения бывали.
главный спонсор банкета приезжает на день раньше - показать надо на один день раньше.
Выкатили на прод, миграция предполагалась за день, но в скриптах были ошибки и увы - надо ночью.
Главный и любимый заказчик попросил прикрутить рюшку которая ему очень нужна для формальной отчетности. Вы с этого заказчика кормитесь всей компанией (включая разработчиков, которых попросили выйти в ночь за доп бабки)
могу продолжать дальше: кейс, когда доблестные разработчики обещали сделать "но не шмогла" и надо просто привести систему хоть в какой то порядок, когда упал прод неясно почему и тд т и тп... И это примерно все из личного опыта :)
Можно было отказаться и потерять заказчиков. А можно было поработать и получить премию.
тут не согласен.
я не видел нормальной визуализации проектной методологии.
я не видел в больших компаниях масштабированных пакетов документации внедрения от размера проекта
ну и документов по фазам - бывает, но достаточно редко.
Я считаю, этого достаточно, чтобы рассказать, что так бывает.
все верно. моя статистика такая:
чтобы понять и освоить методологию, которая описана в статье, у меня ушел 1 проект. Больше того, я полезные шаблоны утащил и потом долго еще применял в других местах. А матрицей рисков и проблем пользуюсь до сих пор - простая и удобная
чтобы понять, как применять ГОСТ, у меня ушло несколько лет. Неясно, когда нужна ПЗ к ТП, когда нет. Неясно, зачем заполнять все формальные разделы ТЗ - часто выглядит излишним. Неясно, когда делать кучу других документов (привет "Описанию языков программирования"), а когда не нужно. Но вообще еще раз да - он норм. Вот ему масштабируемость можно было бы попробовать прикрутить и сделать визуализацию - было бы интересно.
А я не призываю такое внедрять. Я буду рад, если РП и начинающие РПО просто прочитают и отложат в голове что "бывает и так" , а потом что-то из этого внедрят у себя.
Визуализацию
Шаблон, в котором будет написано, что и как писать
Разные пакеты документов для разного размера проектов
А уже если вдруг кто-то придет из крупняка и расскажет, что это все фигня - вот у них... Я с удовольствием признаю, что это не идеал.
Любую best practice можно раскритиковать. Но это не повод ничего не делать вообще.
идеал недостижим, если вспомнить про цену.
Задача этой статьи:
показать РПшникам и РПОшникам, которые не видели подобного максималистского подхода, что он бывает и что гдето - это best practises
что корпоративная методология - это не PMBoK и не ГОСТ и не P3, а что-то индивидуальное, что им не противоречит.
ну и лично для меня важно: я в РФ не видел ни одной методологии, где была бы вшита масштабируемость. Если кто-то это увидит и внедрит - я буду очень рад, считаю это важным для больших отделов.
Аудитория Хабра такова, что как только будет ссылка на идеал комментаторы напишут, что он неидеален, потому что неприменим для их деятельности. И даже будут правы, скорее всего. Потому что для производственных проектов - одни этапы и их наполнение, для проектов разработки ПО - вторые, а для внутренних команд разработки - третье.
А должно быть что-то у всех.
Цель статьи - показать как это может выглядеть "по максимуму" - раз, и что это отличается от PMBoK (хотя и полностью ему соотвествует) - два.
В остальном - спасибо за комментарий. Первоначально пост и правда был на канале, что уж тут сделаешь и да , я даю на него ссылку, там вся аудитория с Хабра, так то :)
Ирония понятна, может так и звучит, но я о другом
Все вместе эти шаги не только убирают хаос (потому что описанный процесс управления убирает бардак), но и снижают стоимость обучения персонала + его конечную цену (людей можно брать дешевле).
и если тут все очевидно, и базара ноль, у меня вопрос: Если это настолько элементарно, почему этого никто не делает?
Почему сейчас, работая как приглашенный эксперт я вижу какую то кашу из документации, которую каждый РП делает так, как ему хочется? И это касется не только SMB, это вполне себе большие конторы и в госухе и в коммерции.
Расскажите, если знаете ответ, мне искренне интересно.
за водой не заметили ребенка - отчасти согласен, чтобы сделать статью краткой и неунылой, я часть сократил.
Но если вы ждете от меня описания всех проектных артефактов - смысла в этом ровно ноль, и я написал ниже, почему: вы (или любой другой комментатор) мне в 2 счета докажет, что эта документация для его проектов не нужна/лишняя.
Тогда зачем описывать детальные артефакты, когда они для каждой компании уникальны?
Сам подход , где есть процесс/роли/шаблоны - обычный.
Подход, где он
а) визуализирован наглядно
б) максимально наполнен
в) при этом гибкий и масштабируемый
уникален.
просто нет других таких методологий. ГОСТ масштабируется, но далеко неочевидно.
Так что есть куда расти крупнякам - я бы на их месте смотрел сюда, а не нанимал десятки администраторов проектов для сведения отчетности по отделам.
А мелким надо понимать, что им не ПМБоК нужен, а совсем другая, простая история.
PS: а про канал сказано в начале ровно один раз - честно говоря, не виду проблемы сказать что это статья реально по мотивам моего поста там. И там он популярен. Могу дать пруф :)
золотые слова. в статье какое то унылое нытье о несправедливости мира. удивительно, но когда нормально работаешь и умеешь в социальные связи, о тебе не дают такого отклика, как выше. А вот когда бездельник - дают, вот дела...
эх, автор автор.
Хорошо все было, все слова правильные и на самом интересном месте - расчете ROI на фичу - никаких деталей.
А ведь оно должно использоваться при приоритизации и его расчет важен.
Больше, по моему опыту, нормально его почти никто (точнее никто, даже часто я сам) посчитать не может. Считают "от балды", а потом никто не проверяет. Так все и живут в приоритетах "ГД сказал - надо", "Коммерческий просил сделать" - вот и весь RICE =)
"всем известно" - да ладно вам, теория игр распознает методику win-win как оптимальную именно долгосрочно.
Я думаю, я вас понимаю, потому что было время, я был сторонником сразу и честно слать нах с невозможными требованиями.
С тех пор я набрался опыта и понял
часто (реально) мое "невозможно" - это просто страх подумать и предложить компромиссы.
тактичное общение и желание искать решение, помогая заказчику, дает более другие отношения, которые в итоге дают больше денег по аккаунту - маркетинг отношений.
тех, кому пофигу на два пункта выше, а "просто пойди и сделай без вопросов и обиняков" - реально мало и с ними можно не работать, но только после выполнения 2х пунктов выше.
Это вопросы, а не отговорки. Ответы на них определяют варианты решения. Без ответов на эти вопросы работа будет зря и не в срок, который вам нужен. Возможно я обосновал недостаточно подробно и понятно, позвольте пояснить пояснить еще раз?
Ну и так далее.
Обычно полный неадекват говорит о том, что вы все равно не сработаетесь. Тут или брать под козырек , а потом получать ушат чувства вины, или вообще с этим не работать.
Но такого даже в госухе обычно мало (если брать интеграторов, которые работают с госами). Такое сильно выражено именно при работе в самом госе (ФОИВ, РОИВ) + силовики любят жестить.
Но в госорганах работать - удовольствие, очевидно, специфическое и радости в виде коррупционных схем "когда то, если повезет подняться" - не для каждого.
А к силовикам без сильной руки ни один РП не ходит, там всегда есть сейлз, которого и надо слушаться.
По опыту - это 10% рынка неадеквата гдето. Работать там или нет - решать каждому. Мой метод не про то, чтобы это терпеть. А чтбы попробовать вывести на конструктив и уходить только потом, а не убегая от проблемы
Я, как менеджер, заложил бы и месяц, да ктож мне даст? Вы всерьез думаете, что менеджер может выбрать комфортные для себя сроки, но почему то раз за разом не выбирает, потому что любит страдать? Это не так
угу
А я и не давал. Они попросили пойти на встречу. Можно было даже отказаться по формальному признаку. Но просто потом ( не точно но вероятно, из опыта), пришли бы ребята, которые в этой ситуации сделали, и в следующий раз заказчик выберет их.
"Да я отлично вас понимаю, вы хотите, чтобы я выполнил ваши указания. Вы же не хотите, чтобы я просто, не думая, взял вашу критичную задачу и сорвал ее исполнение? Я считаю это непрофессиональный подход.
Поэтому перед выполнением я задаю вам вопросы выше, которые надо решить. Так что давайте к ним вернемся."
Я прочитал вашу статью про психологическую безопасность. Мне есть что сказать.
Я считаю верным такой подход. Хотя я сам склонен к тирании (особенно когда поджимают сроки), я всегда слушаю реальные аргументы или стараюсь показать "как надо". Собственно, потому все мои менеджеры (реально) дали мне очень высокие оценки по итогам работы за 5 лет. Мы именно так и работали.
Но. Моя практика показывает, что таких шефов хорошо если 50%, я бы сказал, что у меня за все время было таких 2 из где-то 20ти.
а бОльшая часть или орет, или отдает указания и ловит на неисполнении, ничего не объясняя. Ты попал - значит ты лох, испытай вины.
И мои правила - для работы в том числе в такой среде. Где давят, где прессингуют, где есть откровенно странные дедлайны и те, кто на них уже согласился (внезапно это может быть ваш шеф). Я не хочу исправлять мир Российского ИТ - он за 25 лет не изменился, и, судя по моим наблюдениям, изменится только в худшую сторону. Я хочу дать начинающим менеджерам инструменты, как не выходить из конструктива.
Научатся - значит сделают наш мир чуточку лучше.
Потому что даже самые неадекватные заказчики иногда становятся нормальными, когда понимают, что их не подставляют, а реально дают результаты в озвученные сроки.
В статье сказано, что формат "да, но" - это тоже самое "но", не стоит говорить :)
Про ваш пример, я для начала спрошу вас, как заказчика: что именно вам нужно, какую боль решает ребенок, почему нужен он (сразу ребенка технически родить действительно нельзя), а недостаточно прототипа ребенка, mvp, скажем - вот он в животе, смотрите.
Вы хотите реального ребенка? А вы знаете решения, которые его дадут через месяц? Мне, как профи рынка, известно ровно то, которое дает за 9, не менее.
Как видите, я нигде не сказал "нет" и "да, но" и при этом нигде не согласился. Зато спросил главный вопрос "а зачем?" и "что именно надо?"
Как правило, бизнес может давить/прессинговать, но крайне редко он полностью лишен адекватности. А значит, договариваться можно в 90% случаев по моему личному опыту. Да, 10-15% на истории, когда после выяснения объема имеет смысл сказать: "я понял ваши требования, наше КП содержит несколько вариантов, максимально к нему приближенных. Если заинтересует - дайте знать". Но остальные 90% мой подход поможет договориться.
И да, именно 90% - моя личная статистика такая.
За 25 лет не обошлось. Подозреваю, что и не обойдется. Больше того: за эти 25 лет я пробовал разные стратегии. Предлагаемая - позволяла с большей вероятностью выстраивать хорошие продуктивные отношения, которые давали +%% YoY если вы понимаете, о чем я.
Уже потом я прочитал у Котлера, что это маркетинг отношений и это крайне важная штука.
И я вам не поверю, у меня есть много опыта (и я сам поступал несколько раз также с менеджерами/поставщиками): если мне долго/дорого объяснять простые вещи - надо менять человека/поставщика услуги. Рынок играет именно так, нравится это мне (вам или кому либо еще) или нет.
И если поставщик услуги отказывается ее исполнять - его сменят.
Конечно , дальше будет много интересностей про то "а было ли это вообще выполнимо" и тут я тоже скажу: практика ИТ рынка показывает, что более менее выполнимо 90% как раз изза метода, предлагаемого мной.
Даже когда вы берете конкурс на 300 млн за 100, и у вас 3 мес на реализацию - вопрос решаемый совершенно официальным путем.
Так что я считаю, это личный выбор каждого человека: сказать "это невозможно" или попробовать и заработать. Никого не принуждаю, ведь тут можно и не заработать, риск, разумеется, есть.
спасибо. Пожалуй, согласен с вами. Почему не писал про такой вариант: его очень сложно объяснить - раз. А второе: бизнес иногда реально не готов услышать "нет" ни в какой форме. Да, это агрессия, да это токсично и блаблабла.
Факт в том, что такого бизнеса у нас - 50% точно (это я аккуратно сказал). Да что там бизнес: мне лично мои манагеры говорили "нет, невозможно", "нет ресурсов". И я показывал , как можно и что ресурсы есть - надо просто голову чуть иначе включить: не искать аргументацию, почему нет, а подумать, что надо, чтобы да.
С точки зрения такого манагера я что - токс? :) Ну ок, а с моей - он непрофессионал :)
Видите как? Именно поэтому лучше просто учиться делать все по шагам, они выстраданы:
уйти подумать, что надо, чтобы "да"
предложить варианты решений, пусть неидеальный
и если там неконструктив ок: "покажите как это сделать мне, я не понимаю" - все.
Перечитал. В части понимания своих профессиональных границ - согласен, их каждый должен понимать (что я готов делать, а где я говорю "хватит" и ищу новое место). Как я сказал выше: по моему опыту, мой подход решал бОльшую часть неконструктива от заказчика и руководства. Хотя исключения бывали.
Поехали:
главный спонсор банкета приезжает на день раньше - показать надо на один день раньше.
Выкатили на прод, миграция предполагалась за день, но в скриптах были ошибки и увы - надо ночью.
Главный и любимый заказчик попросил прикрутить рюшку которая ему очень нужна для формальной отчетности. Вы с этого заказчика кормитесь всей компанией (включая разработчиков, которых попросили выйти в ночь за доп бабки)
могу продолжать дальше: кейс, когда доблестные разработчики обещали сделать "но не шмогла" и надо просто привести систему хоть в какой то порядок, когда упал прод неясно почему и тд т и тп... И это примерно все из личного опыта :)
Можно было отказаться и потерять заказчиков. А можно было поработать и получить премию.