Каждый год (ну или практически каждый) ODOO публикует (обновляет) документ под названием «Implementation Methodology. The ultimate guide to successfully implement and sell Odoo projects.». Естественно он на английском языке и здесь я хочу дать вольный перевод этого документа со своими комментариями.
Вступление
Внедрение ERP системы процесс нелегкий, особенно если речь идет о системе, которая призвана объединить работу всех подразделений компании, что естественно вызывает необходимость изменения процессов в компании. Не все компании к этому готовы и как показывает статистика, более 50% проприетарных внедрений ERP терпят неудачу.
Но если говорит об ODOO — то здесь ситуация иная. Odoo трансформирует рынок и при этом удовлетворяет огромный спрос. За последние 5 лет более 95% внедрений ODOO был успешным, что резко контрастирует с решениями других провайдеров.
Для того чтобы этого достичь ODOO пересмотрела свой подход и роль при внедрении своих руководителей проектов.
Ключевые понятия
Обязанности
•Главным приоритетом должно стать соблюдение сроков проекта и не выход за рамки его бюджета.
• Клиент определяет потребности своего бизнеса (что и зачем), а способ их удовлетворения определяется продуктом (как).
Все просто
• Меньше совещаний, меньше документов, быстрые решения.
• Ограничьте количество заинтересованных сторон, чтобы ускорить цикл принятия решений.
• Ограничьте разработку на заказ до необходимого минимума.
• Работа на месте неэффективна для достижения цели, но эффективна для управления изменениями и обучения.
Люди
• Руководители проектов должны решать проблемы, так же как продуктовые и бизнес-эксперты.
• Избегайте посредников, не принимающих решения, но которые занимают ваше время
• Обучите ключевых пользователей на ранней стадии проекта. Они должны быть уверены в продукте и привержены проекту.
Менеджеры проекта
• Ключевым фактором успеха проекта является Проектный Менеджер (он же руководитель проекта в Odoo).
• Нанимайте и обучайте лучших специалистов. Сохраняйте только лучших исполнителей.
• Даже самые лучшие руководители проектов упускают важные детали.
Но никогда не забывайте:
Здравый смысл всегда берет верх над любыми правилами!
Что же такое успешный проект?
Работа руководителя проекта нелегка. Очень сложно найти правильный баланс между удовлетворением клиента, принятия большого количества запросов на изменения, при этом не выйти за рамки бюджета, строго придерживаться договоренностей и т.д.
Ключевым признаком успеха проекта есть привлечение пользователей в новую систему и сделать так, чтобы они начали в ней работать. Если проект потерпел неудачу, то это всегда потому, что он занял слишком много времени или стал стоит слишком дорого.
Соблюдение сроков и бюджета является ключевым для методологии внедрения. Все остальное вторично (включая удовлетворенность клиента во время внедрения)
Разработка новых функций в системе не помогает проекту
Желание клиента модифицировать систему таким образом, каким ему кажется лучше, всегда создает дополнительные затраты и затягивает реализацию проекта. Кроме того такая разработка приводит к техническому долгу, за который клиент должен будет платить сразу или с течением времени. Каждая новая функция может казаться простой и вроде не вызывать сложностей в реализации. Но сложность проекта растет экспоненциально по мере увеличения количества функционала, а не линейно, как иногда кажется клиенту. Но конечно иногда такие доработки нужны, особенно если они учитывают особенности бизнеса клиента.
Удовлетворенность клиента не есть хорошим KPI
Некоторые руководители проектов считают, что главное в проекте — это максимально удовлетворить клиента. Счастливый клиент = успешно сданный проект.
Но удовлетворенность клиента постоянно меняется на разных фазах проекта (сегодня критерий один, а завтра уже другой). К тому же каждый сотрудник клиента может иметь разные ожидания: например пользователь системы хочет в системе новую функцию, а генеральному директору важно вложиться в сроки и в бюджет.
Неудовлетворенность присуща любому проекту.
Несмотря на то, что удовлетворение потребностей клиентов не является целью во время реализации проекта, это по-прежнему хороший способ оценить мотивацию ключевых пользователей.
Поэтому можно использовать периодические рейтинги клиентов, чтобы знать, какие группы сотрудников клиента нуждаются в большем внимании
Продажа дополнительных услуг не является приоритетом
Сервисные компании любят выставлять клиентам много счетов. У крупных сервисных компаний есть даже сложные методологии, которые приводят к необходимости большего количества услуг.
У Odoo же другая философия. Рост компании-внедренца должен быть результатом качественного обслуживания или довольного клиента. Лучшим вариантом есть быстрый запуск клиента в новую систему (quick launch), что подразумевает за собой отсутствие серъезных доработок в системе.
Для достижения устойчивого роста сосредоточьтесь на успехе проекта. Если у вас есть успешные проекты, клиенты будут покупать у вас больше услуг.
Роли
Внедрение ERP подразумевает задействование на проекте разных специалистов: менеджеров проектов, бизнес-аналитиков, тестировщиков, тренеров, разработчиков. Но слишком много поваров могут испортить бульон, который они готовят.
Odoo: руководитель проекта
Этот специалист является главным лицом, принимающим решение по проекту. Такие люди носят много шляп и могут выполнять роли бизнес-аналитика, менеджера проекта и эксперта по продукту.
Как менеджер проекта такой специалист выполняет такие функции:
• определение плана проекта и его выполнение
• концентрация на основных целях
• внедрение SPoC (единая точка контакта) в проекте
• использование правильных ресурсов и предвидение рисков
Как бизнес-аналитик и эксперт по продуктам, такой специалист:
• принимает решения о том, как реализовать конкретные потребности
• оспаривает требования клиентов и управляет их ожиданиями
• настраивает Odoo
• переносит необходимых данных
• пишет спецификации (если требуется разработка)
Odoo: директор проекта
Такая роль появляется в более крупных проектах и назначается в дополнение к руководителю проекта.
Пока руководитель проекта фокусируется на реализации, директор проекта помогает представить
проектировать и управлять ожиданиями руководителей, с более высоким взглядом на проект.
Odoo: эксперт по приложениям
Такой специалист как правило не является частью команды проекта и работает над всеми проектами компании сразу. Цель работы такого сотрудника — уменьшить объем дополнительных разработок в проектах. Если от клиента поступает запрос на новый функционал — первое что нужно сделать, это посмотреть есть ли под этот запрос уже готовый модуль.
Odoo: разработчик
Не все проекты требуют участия разработчиков. На первых этапах внедрения вполне можно обойтись коробочным решением.
Заказчик: Единая точка Контакта (SPoC)
Поэтому руководителю проекта необходимо иметь сильного союзника на стороне клиента.
Такой сотрудник должен сопровождать проект, быть амбассадором убеждающим пользователей и контролировать план проекта на его соответствие плану компании.
Такой человек должен обладать правами по принятию решений со стороны заказчика.
Этапы внедрения
Этапы проекта внедрения и их относительная продолжительность:
Этап — Время — Цели
- ROI анализ — 10% — Проведение ROI анализа, планирование и бюджетирование
- Начало(KickOff ) -5% -Выявление заинтересованных сторон, их знакомство с методологией и проведение стандартного обучения
- Внедрение — 80% — Серия циклов: анализ, разработка, валидация, проведение тренингов
- Запуск(Go-Live)- 5%- Проведение конечных тренингов, фикс багов
- Second deployment Вариативно Расширение области применения или добавление пользовательских функций
ROI анализ
Внедрение ERP системы всегда как правило не дешевый проект с большим риском. В крупных проектах всегда перед его стартом делается анализ рентабельности инвестиций. В зависимости от размера проекта, этот этап может занять от 3 дней до 50 дней. В очень маленьких проектах (<4 месяцев) анализ ROI не является отдельной фазой, а выполняется на этапе KickOff (Начала проекта).
Анализ ROI позволяет клиентам:
• получить точный план и бюджет по проекту
• оценить рентабельность инвестиций (ROI): выгоды по сравнению с затратами
• просматривать их спецификации в соответствии с программным обеспечением
• рассеять свои сомнения в осуществимости проекта и команде проекта
Руководитель проекта обеспечивает:
• анализ экономии и выгоды для клиента (возвраты)
• Бюджет и план реализации (Инвестиции)
• сопоставление потребностей бизнеса и характеристик продукта
• проверку концепции (POC): демонстрации ключевых бизнес-процессов
• стратегию управления изменениями
Этапы анализа рентабельности инвестиций
- Встреча с заитересованными лицами: установление ожиданий и определение целей, мотивов и рисков в ROI Kick-off mindmap
2. Покажите нам как вы работаете (As is). Поработайте с одним ключевым сотрудником подразделения для возникновения понимания того как компания работает сейчас.
3. Проведение воркшопа(to be):
- демонстрация прототипа (в т.ч. с помощью Odoo studio)
- выявление болевых точек, пробелов
- Подсчет временных затрат в каждом отделе
4. Оценка временных затрат на реализацию требований заказчика
ROI — Analysis Tool
5. Демонстрация заказчику результатов анализа
Почему Odoo рекомендует проводить две демонстрации (‘as is’ и ‘to be’).
Поскольку клиенты бояться упустить ключевые моменты для принятия решения, они на встречи привлекают слишком много сотрудников. Вовлечение большого количества людей — это хорошо
для управления изменениями, но неэффективно для проведения анализа.
Чтобы смягчить этот эффект, Odoo разделяют семинары на 2 этапа: анализ семинары по текущему программному обеспечению и ключевым пользователям.
Первый этап «Покажи мне, как ты работаешь» представлен как нестратегический этап (поэтому нет необходимости собирать всех менеджеров за одним столом). Тут будет достаточно привлечения одного-двух представителей клиента. После этого разрабатывается прототип, который демонстирируется на втором этапе, который представляет собой серию семинаров с ключевыми пользователями . Цель – получить больше информации об изменениях, которые они хотят внести, и проверить предположения прототипа предыдущей фазы. Благодаря первому этапу вы будете намного эффективнее: у вас будет прототип, чтобы показать, вы знаете бизнес клиентов до встречи с ключевыми пользователями и т. д.
Советы по анализу
- на этом этапе будьте продавцом. Ваша цель — успокоить людей и их мотивировать на измененения. Делайте демонстрации ключевых особенностей;
- во время анализа «as is» делайте максимум скриншотов или скринкастов текущего решения, а также берите образцы отчетов и данных;
- убедив ключевых пользователей клиента, сделайте оценку времени, которое тратят люди на выполнение своей работы в старой системе, ключевое здесь — понять сколько прибыли получит компания после перехода на новую систему (в этом собственно говоря и суть анализа);
- определите болевые точки ключевых пользователей. Используйте шаблон анализа рентабельности инвестиций чтобы получить представление о наиболее распространенных болевых точках в каждом подразделении;
- найдите решение для каждой проблемы. Не обязательно решать каждую проблему;
- никогда не предлагайте разные варианты решения проблемы. Вы сами определяете какой способ лучше. Роль клиента — попытаться оспорить ваше решения, а не решать что делать;
- не позволяйте клиенту решать какая функция необходима, а какая нет. Это можете решать только вы;
- сложите общую картину. Ваша задача представить клиенту согласованное решение его проблем
После интервью с клиентом:
- вы должны дать оценку «хотелкам» клиента и решить насколько целесообразно их реализовывать в системе (пускать в разработку). Если это необходимо — нужно расставить приоритеты, в целях сокращения бюджета и планирования времени и,
- еще раз проверьте не упустили ли вы какие-нибудь боли клиента;
- проверьте качество сделанного анализа и оцените обсуществимость согласованность предлагаемого решения.
- все необходимые разработки могут быть разделены на две категории: то, что действительно необходимо для управления бизнесом и то, что можно реализовать на втором этапе сотрудничества.
В конце концов:
- подведите итоги вашего анализа — функциональное и бизнес покрытие, необходимые ресурсы с двух сторон, планирование проекта и фиксация рисков;
- организуйте специальные демонстрации, для того чтобы убедить заинтересованные стороны и укажите на преимущества которые они получать после внедрения системы. Если демо не возможно — подготовьте макеты и покажите на них.
И теперь давайте коротко пройдемся по основным документам на этом этапе, которое рекомендует Odoo. С одним мы уже познакомились выше (ROI Kick-off mindmap), вторым документом есть конечная презентация клиенту, которую можно сделать по такому шаблону.
А вот на документе «ROI Analysis» хотелось бы остановиться детальнее. Ключевой составной частью есть перечень требований клиента(вкладка I — Items)
В ней мы указываем сегмент системы к которому относится требование; само требование — Business Need(Что и зачем); вариант его реализации в системе — Solution; этап на котором оно будет реализовано — Phasing; тип — стандартный ли это функционал системы, есть ли под него стороннее приложение или нужна будет разработка; оценка по времени реализации требования в днях — Estimated Days (если нужна разработка); и комментарии технических специалистов.
Данная информация служит основой для расчета стоимости проекта и временных затрат.
Также в этом файле делается расчет возврата инвестиций клиента — что случится с бизнесом клиента после того как он внедрит у себя Odoo. Большинство компаний-внедренцев как правило говорят о затратах, Odoo же предлагает говорить о возврате сделанных инвестиций — это по идее должно успокоить клиента и сделать его более заинтересованным в проекте.
Старт проекта (Project Kick-Off )
После того как вы показали клиенту какая у него будет выгода от нового проекта необходимо стартовать проект. На этом этапе нужно составить четкий план и начать управлять ожиданиями клиентов и стараться эти ожидания синхронизировать с нашим подходом. Это очень важный этап в проекте и от него зависит успех проекта.
Цели этого этапа:
• включить SPoC в методологию и согласовать видение
• сделать быстрый анализ рентабельности инвестиций, чтобы подтвердить осуществимость проекта (если еще не сделано) — для небольших проектов, это делается на этом этапе;
• доработать план проекта
• присоединиться к SPoC и убедиться, что они тратят время на обучение Оду
• Включение проектной группы клиента в стратегию изменений
Советы по этому этапу
- решайте проблемы напрямую: если вы видите что сроки проекта нереалистичны — лучше сразу договориться об их изменениях;
- то же самое касается и других составных проекта. Неопытные менеджеры любят пускать ситуацию насамотек, надеясь что пронесет, но как вы знаете так бывает очень редко;
- контролируйте вовлеченность клиента на протяжении всего проекта и убедитесь что в проекте принимают участие все необходимые специалисты со стороны клиента и у них есть время и знания для выполнения своих обязанностей;
- потратьте время на обучение SPoC — они должны разбираться в системе не хуже вас;
- управляйте ожиданиями клиента: не устанавливайте короткие сроки, не говорите что все easy, не обещайте больше, чем сможете реально сделать. Лучше пообещать меньше, а сделать больше.
Внедрение
Независимо от уровня сложности проект должен постоянно двигаться вперед. Поддержание стабильного темпа — ключевой фактор успеха. Лучший способ поддерживать его в таком состоянии — высокий уровень участия заключается в том, чтобы SPoC был вовлечен во все. После этапа Kick-Off разработанное решение было продемонстрировано ключевым пользователям. Пришло время воплотить его в жизнь!
На каждом этапе команда проекта работает короткими циклами, чтобы предоставлять функциональные возможности каждую неделю. Решение формируется постепенно на протяжении всего этапа и утверждается руководителем проекта и SPoC. Конфигурация, импорт данных и конкретная разработка выполняются параллельно руководителем проекта и разработчиками, если это необходимо.
Настройка системы
Руководитель проекта самостоятельно настраивает систему под потребности клиента. После настройки SPoC и ключевым пользователям системы проводится серия обучений, чтобы убедиться в том, что все идет куда нужно.
Импорт данных
В зависимости от сложности импорта его может делать руководитель проекта или разработчик. Данные для импорта подгатавливает заказчик и желательно по определенному шаблону. Миграция данных в Odoo может быть непростой и занять некоторое время. Не следует задерживать запуск проекта из-за того что данные не импортированы или импортированя с ошибками. Импортируйте то, что вам действительно нужно, а не полной истории (если это возможно) — это требует много денег и времени.
Разработка
Никогда не поздно задать себе вопрос — а действительно ли нужна конкретная разработка.Чем больше вы сократите объем разработки, тем лучше. Клиент конечно хочет все и сразу и естественно в рамках утвержденного бюджета. Но вы должны выделить, то что действительно необходимо для бизнеса и отсеять то, что может быть приятной фичей.
Руководитель проекта пишет спецификации (техническое задание) включая сценарии для тестирования, а SPoC подтверждает его на соответствие бизнес-требованию. Затем разработчик реализовывает необходимый функционал по этому ТЗ. После чего руководитель проекта тестирует реализованный функционал и потом проводит обучение SPoC и ключевых пользователей. SPoC со своей стороны также занимается тестированием и в случае обнаружения проблем сообщает о них руководителю проекта ,который передает их разработчику.
Обучение
После того как все требования этапа выполнены, SPoC делает финальное тестирование и дает согласие на запуск в прод. Заказчик отвечает за написание руководства для конечных пользователей, которая должна учитывать внутренние процессы компании и принятую в ней терминологию. . Кроме того, если клиент сам напишет руководство пользователя — это хороший способ убедиться, что он полностью протестировал программное обеспечение перед запуском его в прод.
Рекомендации
- попросите SPoC самостоятельно организовать бизнес-процесс;
- держите клиента в состоянии тонуса и заставьте его пользоваться системой со старта проекта;
- выспрашивайте у клиента новые идеит по усовершенствованию системы — они войдут в следующие итерации проекта;
- не делайте того в чем не уверены. Если вы видите, что какое-то требование сложно в реализации — нужно убедить заказчика сделать его в следующем этапе;
- проводите личные встречи с клиентом;
- контролируйте ход внедрения изменений.
Выпуск в прод (Go-Live)
Обычно запуск системы в продакшн обнаруживает такие проблемы:
- База не полностью протестирована ключевыми пользователями;
- Пользователи плохо обучены либо просто забыли то, чему их учили.
Советы по запуску системы в прод
- Проведение тренинга подразумевает активное участие ключевых пользователей — они должны сами все делать в системе;
- Ключевые пользователи не являются профессиональными тестировщиками и не могут выявить все проблемы которые могут возникнуть;
- Сделайте так, чтобы у ключевых пользователей возникло впечатление что у них что-то получается, это их заставить эксперементировать;
- Если возникают проблемы — быстро их устраняйте;
- Не отодвигайте дату запуска. Лучше начать работать сразу, а не ждать пока все будет идеально;
- В первые дни запуска быть рядом с клиентом и контролировать сопротивление пользователей;
- Периодически проверяйте — работают ли новые пользователи в системе.
Second deployment
Через месяц после старта можно приступать к оставшимся разработкам, которые не были сделаны в первом этапе. При этом нужно собрать отзывы от пользователей (как правило часть требований отпадает и появляются новые требования)
Отчет о проделанной работе
Этот отчет используется для планирования встреч с руководством клиента и информировании его о состоянии проекта.
Руководители проектов всегда думают с точки зрения рентабельности инвестиций и ищут ответ на вопрос:
Как я могу помочь сотрудникам моего клиента делать больше за меньшее время?
Что надо для того, чтобы пользователи полюбили Odoo
Люди не любят изменения их обычного уклада жизни. Нет такого понятия как мелкое изменение чего-либо, любое изменение это стресс. Внедрение нового ПО — это не только заменить один софт на другой, это еще изменение философии ведения бизнеса, изменение подходов к работе, трансформация процессов.
Руководитель проекта для адаптации пользователей имеет в своем арсенале такие инструменты:
- сам продукт — как только пользователи убедяться, что он функционален и удобен — это повысит их лояльность;
- поддержка SPoC и ключевых пользователей — если сотрудники видят, что их руководители сами пользуются новой системой — это повышает их лояльность;
- споносоры проекта поддерживают проект.
https://www.youtube.com/watch?v=XdNbVGItHSg&t=1577s
Как написать хорошее техническое задание?
Хорошее техническое задание (ТЗ, спецификация) должно быть коротким, наглядным и иметь следующую структуру:
- Бизнес-потребность (бизнес-требование) — должно отвечать на вопрос что? (нужно клиенту) и зачем (почему ему нужна эта функция)?
- Функциональная спецификация — как бизнес-потребность будет решена в системе, это может быть проилюстрировано с помощью макетов или серией скриншотов
- Технические подсказки — о чем должен позаботиться разработчик
И в качестве примера предлагается следующая спецификация.
Бизнес-потребность.
Заказчик поставляет IT оборудование школе. Важгным и трудоемким аспектом работы является подготовка комплектов для поставки. Для некоторых упаковок применяется двухэтапный исходящий процесс: сбор и доставка.
Запланированная дата поставки предварительно обговаривается со школой, а затем она может изменяться при доставке в соответствии с потребностями.
Логист должен собрать комплекты в тот же день что и доставка. запланированные даты в обоих документах должны быть одинаковыми, чтобы логист мог видеть что ему нужно собрать и отправить сегодня.
Вторым важным моментом есть то, что при подтверждении продажи в системе создаются два документа, но как они связаны между собой не понятно. Должна быть возможность переключаться с одного документа на другой.
Функциональный анализ
Итак какой у нас будет сценарий?
- Создать заказ продаж с позициями
- Подтвердить заказ продаж
- При этом автоматически создадутся два документа перемещения: WH/ PICK — в статусе ожидания на сборку и WH/OUT в статусе ожидания другой операции
- Оба документы будут иметь одинаковую запланированную дату доставки которая будет равняться дате валидации заказа продаж
- Далее между школой и поставщиком идет обсуждение даты поставки
- Дата доставки ставится в документе WH/OUT, при этом дата доставки в WH/ PICK меняется автоматически и не может быть изменена вручную
- После того как логист подготовит комплект он валидирует WH/ PICK при этом статус WH/OUT меняется на «Готово»
- Оборудование поставляется школе после чего WH/OUT подтверждается
Технический анализ
Module Setup:
Feature: Date synchronization
- Change view of stock.picking:If operation type = pick => readonly
- Business flow change:When editing schedule date of stock.picking check other picking from the same group_id
if type = pick: set the same date
Feature
- Data Model:Add two computed fields (out_id, pick_id): Many2one to stock.picking
- Business Flow Change:
How to compute the fieldsfrom the picking, find the other picking from the same group
out_id will have the picking with the operation type out
pick_id will have the picking with the operation type pick - View Change: 0.5
Add the 2 fields on stock.picking form viewshow out_id only if operation type is pick
show pick_id only if operation type is out
Импорт исторических данных
Если при внедрении клиент переходит на новую систему с какой-нибудь другой системы, то у него как правило возникает желание импорта исторических данных. Например перенос информации про все продажи за последние 5 лет. Это очень непростой вопрос и порой его решение представляет собой очень трудоемкий процесс, который может занять много времени и денег. Это весьма увеличивает риски проекта и это нужно делать если это действительно необходимо.
Задайте клиенту следующие вопросы, чтобы проверить, действительно ли это необходимо:
• Можно ли сохранить эту информацию в старом программном обеспечении или в экспортный файл?
• Как часто ваш клиент будет обращаться к этой информации? С какой целью?
• Какое стратегическое влияние это может иметь через 2, 3 или 4 года?
Как и любой другой запрос, пока клиент не может убедить вамс, запрос на импорт должен быть отклонен или отложен до Go-Live
Не пишите документацию для вашего клиента
Клиент должны нести ответственность за создание собственной документации на основе своих собственных бизнес-кейсов и терминологии. Кроме того, предоставление клиенту возможности самостоятельного написания документации гарантирует что настроенные рабочие процессы Odoo правильно поняты и обрабатываются SPoC. Это упрощает процесс управления изменениями, поскольку конечные пользователи имеют прямой доступ к надежному источнику знаний в
их собственной компании.
Небольшие проекты обычно не требуют специальной документации.
Как бороться с желанием клиента делать больше разработок и почему количество дополнительных разработок должны быть сведено к минимуму
Клиенты вечно считают, что тот функционал который есть им не подходит, хотя они с ним еще и не работали. И они хотят доделать существующую систему под себя.
Используйте следующую тактику для обработки пользовательских запросов на разработку:
1. Это действительно необходимо?
2. Стоит ли поддерживать стоимость (разработки и поддержания)?
3. Достаточно ли значителен выигрыш?
4. Можем ли мы достичь той же цели, используя другой подход?
Если вы пришли к выводу, что разработка конкретной фичи не стоит свеч, вы должны постараться убедить в этом клиента. Для этого есть разные тактики для этого: объясните «почему», поэтапное выполнение после «Go-Live», эскалация до менеджера (хоть и не идеально, но иногда необходимо).
Для клиентов дополнительная разработка создает дополнительные затраты и задержку сроков. Кроме того она приводит к техническому долгу, которые клиент должен будет оплачивать (25% от стоимости разработки каждый год).
Для компаний, оказывающих услуги по внедрению, заказная разработка обычно имеет высокую стоимость из-за низкой потребительской ценности. Это типичный сценарий: вы рассчитали 10 дней на разработку функции; клиент считает, что это слишком много для такой базовой функции, поэтому вы берете только 8 дней, а в итоге вы потратили на это 12 дней. Кто в убытке? правильно — мы
