Прежде чем перейти к статье, хочу вам представить, экономическую онлайн игру Brave Knights, в которой вы можете играть и зарабатывать. Регистируйтесь, играйте и зарабатывайте!
Среди главных вопросов, на которые надо ответить руководству компании перед решением взяться за проект, выделяются эти:
Разумеется, вы можете полагать, что это не ваша головная боль как РМа, но… Если ваша компания небольшая, то все проблемы с финансами у компании отразятся на вас и вашей команде самым непосредственным образом, в виде задержек по зарплате. Даже если компания твердо стоит на ногах, ушедший в минус проект неизбежно привносит элемент печали в командную атмосферу. Поэтому финансовую часть лучше учитывать изначально, благо времени это требует немного и единоразово, а профит получается большой и постоянный — в смысле проектной прибыли, а следовательно, и вашей кармы в голове вашего руководства. Ну или способности распознавать финансово провальные проекты на этапе пресейла и избегать участия в них, по мере возможности.
Заинтересовавшимся — добро пожаловать под кат.
Перед тем, как начать.
При написании этой статьи учитывалось, что у среднего РМа, выросшего из сеньора, совершенно нет желания вникать в финансовые детали плотно. Поэтому показано, как получить финансовые расчеты по пресейлу с минимальными затратами времени и умственных усилий – вроде получения зачета по предмету «Экология» в техническом ВУЗе, да простят меня экологи.
Предполагается, что план-график в MS Project вы можете сделать сами — ввести задачи, простроить связи между ними, организовать иерархию и т.п. То, о чем будет идти речь – это быстрые подготовка и ввод финансовой информации в MS Project, чтобы получить работающую финансовую модель для пресейла, с которой можно играть, отвечая на вопрос «что-если» с большой точностью в онлайне.
В статье нет никаких финансовых откровений, все стандартно, версия MS Project может использоваться любая, начиная с 2003. В статье использовался MS Project 2019, но в интерфейсе большой разницы нет. Увы, по работе используется англоязычная версия, я не стал рисковать и менять ее на русскоязычную исключительно для написания данной статьи.
Переходим к сути.
Давайте рассмотрим пресейл проекта разработкисферического коня в вакууме железки под Линуксом, которая мониторит важные для заказчика параметры и выдает управляющие воздействия по итогам анализа поступивших данных. Разработка включает разработку платы, системного и прикладного софта, FPGA нет, корпус взяли готовый. Наша цель — выкатить заказчику адекватную сумму с учетом процента своей прибыли и оценить график платежей по проекту, чтобы не уйти в кассовый разрыв.
Какие специалисты нужны для данного учебного проекта:
Сюда не включаем напрямую секретаршу, бухгалтерию, юристов, закуперов, продавцов, аренду офиса, электроэнергию, чай с печеньем – это от вас не зависит и управлять этим вы не можете. Все, что в ваших силах – это добавить затраты на вот это вот все, в форме увеличения почасового рейта разработчиков. Этим мы сейчас и займемся.
Лично я предпочитаю в данном случае просто умножить зарплату «чистыми» на 2. Да, вот так просто. Поскольку с зарплаты на руки компания платит налог 43%, а оставшиеся 57% идут как накладные расходы. В эти оставшиеся 57% входят и неявные детали, которые влияют на итоговый рейт: есть отпуск 28 дней, разработчики регулярно болеют, отпрашиваются – можно считать, что они работают 10,5 месяцев в году, и т.п. Если директор/финансист не согласны с 57%, то это уже точно не ваша головная боль – у вас нет и в принципе не может быть доступа ко всей бухгалтерии компании, поэтому попросите директора/финансиста дать свою цифру, а пока ее нет — ставим 57%.
Пример расчета: прикладной программист получает 82 000р на руки. В среднем месяце 164 рабочих часа (с учетом праздников), т.е. его почасовая зарплата 82 000 / 164 = 500р. Ставим рейт 1000р/час. Все.
Прежде чем продолжить, стоит описать еще один способ учета накладных расходов. Как вы, наверное, уже заметили, накладные расходы на офис, печеньки и юристов одинаковы для джуниора и сеньора, так что не совсем правильно будет отсчитывать накладные в % от их зарплаты. Поэтому можно попросить директора поставить задачу финансистам, чтобы те посчитали среднюю цифру расходов на офис в час за период (год/квартал/месяц — неважно, поделим на количество часов). Тогда мы получим цифру, скажем, 300р/ч накладных отдельно и почасовой расход на зарплату (с налогами) отдельно 82 000*1,43/164 = 715р/ч, и это будет точнее, мы получим в сумме 715 + 300 = 1015р/ч. Единственная, но крупная проблема здесь – очень сложно получить от бухгалтерии точную сумму накладных расходов за период. Мне такое удалось только однажды, поэтому я предпочитаю добавлять проценты от зарплаты. Да и проект тянут в основном мидлы с более-менее одинаковой зарплатой, так что разница между двумя способами учета не очень велика. В конце концов, можно договориться, опять же, поставить сейчас 57% накладных от зарплаты, а когда (точнее, если) бухгалтерия предоставит цифру накладных в час – быстро поменяете несколько рейтов, займет это 5 минут от силы, все пересчитается автоматически.
Просто? На мой взгляд – да.
Мы теперь умеем считать рейты из зарплаты, поэтому нет смысла приводить здесь расчеты для остальных разработчиков, для экономии времени. Просто проставим сразу рейты:
Программист — 1300р/ч
Схемотехник — 800р/ч
Разводчик печатной платы – 800р/ч
Тестер — 600р/ч
Внедренец — 1000 р/ч
ПМ, т.е. вы сами – 1200р/ч, при этом вы заняты в проекте на 30%, остальное – другие проекты, пресейловая нагрузка и т.п.
С расчетом рейтов закончили. Вот исходный план-график:
По план-графику – не собираюсь спорить о том, каким он должен быть в действительности. План-график крайне упрощен, до степени разрыва с реальностью, и сделан с целью показать влияние задач на деньги, а не дать типовой шаблон разработки программно-аппаратного комплекса. В общем, «я художник, я так вижу».
Ок, жмем на кнопку “Resource Sheet” и в открывшемся представлении вводим полученные рейты:
Обратите внимание на строку «Изготовление платы». Это статьи покупок, где все деньги надо отдавать сразу, точнее – немного заранее, поскольку бухгалтерия ваша и заводская не сидят и не ждут в нетерпении, когда вы, наконец, осчастливите их вашими заказами на изготовление-монтаж платы и покупку компонентов, а делают это периодически, один-два раза в неделю.
Поэтому здесь ставим тип ресурса для изготовления-покупки как «Material», выставить сумму 40 000 в «Cost/Use» и поставить оплату (Accrue At) на старте задачи. Конечно, по фэн-шуй надо разбить задачу «Изготовление платы» на два Milestones: оплата и получение, но так cложнее – две строки вместо одной, добавляем временное смещение, не видное на план-графике и т.д. Так, как сделано — нагляднее и сложнее забыть. Можно еще подкрасить эту задачу оранжевым цветом, но это уже перебор.
Сейчас переключимся обратно в представление диаграммы Гантта. Чтобы посмотреть получившуюся стоимость, добавим колонку с названием “Cost” или «Стоимость» и вот что мы получим:
Стоимость проекта теперь прозрачна с точностью до работ. Руководство видит, как именно будут расходоваться его деньги в вашем проекте, и это выгодно отличает вас от остальных РМ-ов, которые такой информации не дают. Да и споры о людях в проекте куда проще перевести в конструктивное русло: все прозрачно, хотите дешевле и быстрее – давайте в проект сеньоров вместо мидлов на ключевые задачи, пересчитаем прямо сейчас.
Собственно, на этом основная часть закончена, и с полученной моделью можно играть в достаточно больших пределах, получая мгновенное значение стоимости при тех или иных изменениях. Это хорошо, но это еще не все. Перед нами стоит задача снять с руководства второй головняк – посчитать cash flow на проекте, чтобы аргументированно дать ответ на вопрос: сколько запросить предоплаты и как разбить ее по этапам.
Данный способ расчетов можно применять в множестве вариантов, начиная от уже заявленной цели расчета необходимого процента предоплаты и распределения оплаты по этапам, чтобы кэш-фло не ушел в минус, до весьма удобного способа в уже идущем проекте, с множеством оутсорсеров, быстро выдавать финансистам сумму внешних платежей по этапам, планируемым к завершению в будущих месяцах.
Давайте поставим в проекте прибыльность 30%, что дает нам 1 233 600 *1.3 = 1 603 680. Округлим до 1 600 000, чтобы не путаться в копейках. На этой сумме надо посчитать, сколько просить авансом, а сколько – по завершении этапов. Стандартно для разработки программно-аппаратных комплексов иметь аванс в 40% на старте, поскольку закупка оборудования и комплектующих происходят на первом этапе, и по 30% по окончанию первого и второго этапов. Получаем, таким образом:
640 тыс – предоплата
480 тыс – по окончанию первого и второго этапов.
Поставим в проекте Milestones (вехи), соответствующие моментам оплаты этапов. Переименуем, чтобы не плодить лишних строк, задачу «Старт проекта» в «Предоплата», а «Окончание проекта», соответственно, в «Оплата второго этапа». И добавим веху «Оплата первого этапа» после задачи «Перенос ПО на целевую плату» — заказчика легче убедить расстаться с очередными деньгами в момент лицезрения начавшего работать продукта. В столбце «Имена ресурсов» ставим «Оплата 1», «Оплата 2» и «Оплата 3». Должно получиться вот так:
Снова жмем на «Resource Sheet» и вводим полученные значения предоплаты. На этот раз, разумеется, с отрицательным знаком, поскольку мы раньше считали деньги, уходящие из кармана компании, а теперь наоборот. И сменим тип ресурсов «Оплата х» с «Работа» на «Материалы», выставив оговоренные выше суммы (с отрицательным знаком, поскольку платят нам, а не мы) в Cost/Use и поставив оплату (Accrue At) на старте задачи:
Обратите внимание, что стоимость с отрицательным знаком отображает только MS Project 2019, в предыдущих версиях отрицательные значения заключаются в круглые скобки. Хотя считается все правильно.
Ввели. Переключаемся обратно в Gantt и видим такую вот картинку:
Общие расходы по проекту выражаются отрицательной величиной и это, несомненно, приятно.
Ок, переходим к кэш-фло по месяцам. Тут уже придется, увы, экспортировать данные в Эксель и смотреть в нем. Можно, конечно, переименовать несколько полей в названия месяца и года, вывести каждый месяц в свой столбец и соорудить для каждого столбца свою формулу-монстра, учитывающую год и месяц… Я так делал однажды, но смотрится это отвратительно, особенно если проект длинный. Куда как проще использовать встроенные средства создания отчетов и вывод их в Excel, мы по этому пути и пойдем.
Как всегда, все очень просто — переходим на вкладку “Reports” и жмем на кнопку «Visual Reports Export»:
Далее в открывшемся окне выбираем «Cash Flow Report», ставим уровень «Months»:
Жмем на «View» и в открывшемся окне Excel выбираем вторую вкладку (лист) – «Task Usage». Получаем такое вот окно, но оно пока малоинформативно:
На нем надо поставить в «Поля сводной таблицы» галочку «Monthly Calendar» и щелкнуть по значку "+", отмеченных красными овалами на рисунке. Перед нами открывается то, что мы хотели: помесячный кэш-фло в нашем проекте с кумулятивной информацией, т.е. мы понимаем ежемесячно общий итог — в плюсе мы или в минусе в этом месяце, и динамику — мы уже вышли в плюс в проекте по деньгам, или еще нет:
Давайте интерпретируем полученные данные. Красными овалами отмечены места, где нужно быть внимательным.
За март общий профит у нас отрицательный (не забываем инвертировать в уме знак, поскольку речь идет о расходах), расходы превышают доходы на 67 360р. За апрель — положительный, но лишь на 13280р, задержка всего на день сделает его отрицательным. Поэтому надо либо настаивать на увеличении аванса до 45%, либо вернуться из мира цифр в мир реальный и понять, что эти суммы не существуют сами по себе, они являются лишь информацией для принятия решений. Упоминавшиеся +57% к рейтам инженеров — некая абстракция, юристы и бухгалтеры получают свою зарплату за счет не только этого, но и других проектов. Вот если и по ним всем будет кассовый разрыв в марте — то это уже повод настаивать либо на увеличении аванса по проекту, либо отсрочить свои платежи на этот месяц, а если никак — искать другие способы заткнуть дыру, например, взять кредит в банке на пару месяцев. Но эти решения принимают финансист/директор, а не вы как РМ. Вы и так дали им очень ценную информацию: через два месяца есть риск кассового разрыва, у вас есть время, думайте. Это гораздо лучше, чем узнать об этой проблеме за две недели.
На этом все. Удачи вам в финансовом планировании!
- Будет ли выгодно выполнить обсуждаемый проект за предлагаемую цену?
- Как в течение проекта будет выглядеть ситуация по финансам, не появится ли кассового разрыва?
Разумеется, вы можете полагать, что это не ваша головная боль как РМа, но… Если ваша компания небольшая, то все проблемы с финансами у компании отразятся на вас и вашей команде самым непосредственным образом, в виде задержек по зарплате. Даже если компания твердо стоит на ногах, ушедший в минус проект неизбежно привносит элемент печали в командную атмосферу. Поэтому финансовую часть лучше учитывать изначально, благо времени это требует немного и единоразово, а профит получается большой и постоянный — в смысле проектной прибыли, а следовательно, и вашей кармы в голове вашего руководства. Ну или способности распознавать финансово провальные проекты на этапе пресейла и избегать участия в них, по мере возможности.
Заинтересовавшимся — добро пожаловать под кат.
Перед тем, как начать.
При написании этой статьи учитывалось, что у среднего РМа, выросшего из сеньора, совершенно нет желания вникать в финансовые детали плотно. Поэтому показано, как получить финансовые расчеты по пресейлу с минимальными затратами времени и умственных усилий – вроде получения зачета по предмету «Экология» в техническом ВУЗе, да простят меня экологи.
Предполагается, что план-график в MS Project вы можете сделать сами — ввести задачи, простроить связи между ними, организовать иерархию и т.п. То, о чем будет идти речь – это быстрые подготовка и ввод финансовой информации в MS Project, чтобы получить работающую финансовую модель для пресейла, с которой можно играть, отвечая на вопрос «что-если» с большой точностью в онлайне.
В статье нет никаких финансовых откровений, все стандартно, версия MS Project может использоваться любая, начиная с 2003. В статье использовался MS Project 2019, но в интерфейсе большой разницы нет. Увы, по работе используется англоязычная версия, я не стал рисковать и менять ее на русскоязычную исключительно для написания данной статьи.
Переходим к сути.
Часть первая. Рейты и будущие расходы
Давайте рассмотрим пресейл проекта разработки
Какие специалисты нужны для данного учебного проекта:
- Программист.
- Схемотехник.
- Разводчик платы.
- Тестер
- Внедренец.
- Вы сами как ПМ. Ваше время тоже стоит денег.
Сюда не включаем напрямую секретаршу, бухгалтерию, юристов, закуперов, продавцов, аренду офиса, электроэнергию, чай с печеньем – это от вас не зависит и управлять этим вы не можете. Все, что в ваших силах – это добавить затраты на вот это вот все, в форме увеличения почасового рейта разработчиков. Этим мы сейчас и займемся.
Лично я предпочитаю в данном случае просто умножить зарплату «чистыми» на 2. Да, вот так просто. Поскольку с зарплаты на руки компания платит налог 43%, а оставшиеся 57% идут как накладные расходы. В эти оставшиеся 57% входят и неявные детали, которые влияют на итоговый рейт: есть отпуск 28 дней, разработчики регулярно болеют, отпрашиваются – можно считать, что они работают 10,5 месяцев в году, и т.п. Если директор/финансист не согласны с 57%, то это уже точно не ваша головная боль – у вас нет и в принципе не может быть доступа ко всей бухгалтерии компании, поэтому попросите директора/финансиста дать свою цифру, а пока ее нет — ставим 57%.
Пример расчета: прикладной программист получает 82 000р на руки. В среднем месяце 164 рабочих часа (с учетом праздников), т.е. его почасовая зарплата 82 000 / 164 = 500р. Ставим рейт 1000р/час. Все.
Прежде чем продолжить, стоит описать еще один способ учета накладных расходов. Как вы, наверное, уже заметили, накладные расходы на офис, печеньки и юристов одинаковы для джуниора и сеньора, так что не совсем правильно будет отсчитывать накладные в % от их зарплаты. Поэтому можно попросить директора поставить задачу финансистам, чтобы те посчитали среднюю цифру расходов на офис в час за период (год/квартал/месяц — неважно, поделим на количество часов). Тогда мы получим цифру, скажем, 300р/ч накладных отдельно и почасовой расход на зарплату (с налогами) отдельно 82 000*1,43/164 = 715р/ч, и это будет точнее, мы получим в сумме 715 + 300 = 1015р/ч. Единственная, но крупная проблема здесь – очень сложно получить от бухгалтерии точную сумму накладных расходов за период. Мне такое удалось только однажды, поэтому я предпочитаю добавлять проценты от зарплаты. Да и проект тянут в основном мидлы с более-менее одинаковой зарплатой, так что разница между двумя способами учета не очень велика. В конце концов, можно договориться, опять же, поставить сейчас 57% накладных от зарплаты, а когда (точнее, если) бухгалтерия предоставит цифру накладных в час – быстро поменяете несколько рейтов, займет это 5 минут от силы, все пересчитается автоматически.
Просто? На мой взгляд – да.
Мы теперь умеем считать рейты из зарплаты, поэтому нет смысла приводить здесь расчеты для остальных разработчиков, для экономии времени. Просто проставим сразу рейты:
Программист — 1300р/ч
Схемотехник — 800р/ч
Разводчик печатной платы – 800р/ч
Тестер — 600р/ч
Внедренец — 1000 р/ч
ПМ, т.е. вы сами – 1200р/ч, при этом вы заняты в проекте на 30%, остальное – другие проекты, пресейловая нагрузка и т.п.
С расчетом рейтов закончили. Вот исходный план-график:
По план-графику – не собираюсь спорить о том, каким он должен быть в действительности. План-график крайне упрощен, до степени разрыва с реальностью, и сделан с целью показать влияние задач на деньги, а не дать типовой шаблон разработки программно-аппаратного комплекса. В общем, «я художник, я так вижу».
Ок, жмем на кнопку “Resource Sheet” и в открывшемся представлении вводим полученные рейты:
Обратите внимание на строку «Изготовление платы». Это статьи покупок, где все деньги надо отдавать сразу, точнее – немного заранее, поскольку бухгалтерия ваша и заводская не сидят и не ждут в нетерпении, когда вы, наконец, осчастливите их вашими заказами на изготовление-монтаж платы и покупку компонентов, а делают это периодически, один-два раза в неделю.
Поэтому здесь ставим тип ресурса для изготовления-покупки как «Material», выставить сумму 40 000 в «Cost/Use» и поставить оплату (Accrue At) на старте задачи. Конечно, по фэн-шуй надо разбить задачу «Изготовление платы» на два Milestones: оплата и получение, но так cложнее – две строки вместо одной, добавляем временное смещение, не видное на план-графике и т.д. Так, как сделано — нагляднее и сложнее забыть. Можно еще подкрасить эту задачу оранжевым цветом, но это уже перебор.
Сейчас переключимся обратно в представление диаграммы Гантта. Чтобы посмотреть получившуюся стоимость, добавим колонку с названием “Cost” или «Стоимость» и вот что мы получим:
Стоимость проекта теперь прозрачна с точностью до работ. Руководство видит, как именно будут расходоваться его деньги в вашем проекте, и это выгодно отличает вас от остальных РМ-ов, которые такой информации не дают. Да и споры о людях в проекте куда проще перевести в конструктивное русло: все прозрачно, хотите дешевле и быстрее – давайте в проект сеньоров вместо мидлов на ключевые задачи, пересчитаем прямо сейчас.
Собственно, на этом основная часть закончена, и с полученной моделью можно играть в достаточно больших пределах, получая мгновенное значение стоимости при тех или иных изменениях. Это хорошо, но это еще не все. Перед нами стоит задача снять с руководства второй головняк – посчитать cash flow на проекте, чтобы аргументированно дать ответ на вопрос: сколько запросить предоплаты и как разбить ее по этапам.
Часть вторая. Cash Flow и будущие доходы
Данный способ расчетов можно применять в множестве вариантов, начиная от уже заявленной цели расчета необходимого процента предоплаты и распределения оплаты по этапам, чтобы кэш-фло не ушел в минус, до весьма удобного способа в уже идущем проекте, с множеством оутсорсеров, быстро выдавать финансистам сумму внешних платежей по этапам, планируемым к завершению в будущих месяцах.
Давайте поставим в проекте прибыльность 30%, что дает нам 1 233 600 *1.3 = 1 603 680. Округлим до 1 600 000, чтобы не путаться в копейках. На этой сумме надо посчитать, сколько просить авансом, а сколько – по завершении этапов. Стандартно для разработки программно-аппаратных комплексов иметь аванс в 40% на старте, поскольку закупка оборудования и комплектующих происходят на первом этапе, и по 30% по окончанию первого и второго этапов. Получаем, таким образом:
640 тыс – предоплата
480 тыс – по окончанию первого и второго этапов.
Поставим в проекте Milestones (вехи), соответствующие моментам оплаты этапов. Переименуем, чтобы не плодить лишних строк, задачу «Старт проекта» в «Предоплата», а «Окончание проекта», соответственно, в «Оплата второго этапа». И добавим веху «Оплата первого этапа» после задачи «Перенос ПО на целевую плату» — заказчика легче убедить расстаться с очередными деньгами в момент лицезрения начавшего работать продукта. В столбце «Имена ресурсов» ставим «Оплата 1», «Оплата 2» и «Оплата 3». Должно получиться вот так:
Снова жмем на «Resource Sheet» и вводим полученные значения предоплаты. На этот раз, разумеется, с отрицательным знаком, поскольку мы раньше считали деньги, уходящие из кармана компании, а теперь наоборот. И сменим тип ресурсов «Оплата х» с «Работа» на «Материалы», выставив оговоренные выше суммы (с отрицательным знаком, поскольку платят нам, а не мы) в Cost/Use и поставив оплату (Accrue At) на старте задачи:
Обратите внимание, что стоимость с отрицательным знаком отображает только MS Project 2019, в предыдущих версиях отрицательные значения заключаются в круглые скобки. Хотя считается все правильно.
Ввели. Переключаемся обратно в Gantt и видим такую вот картинку:
Общие расходы по проекту выражаются отрицательной величиной и это, несомненно, приятно.
Ок, переходим к кэш-фло по месяцам. Тут уже придется, увы, экспортировать данные в Эксель и смотреть в нем. Можно, конечно, переименовать несколько полей в названия месяца и года, вывести каждый месяц в свой столбец и соорудить для каждого столбца свою формулу-монстра, учитывающую год и месяц… Я так делал однажды, но смотрится это отвратительно, особенно если проект длинный. Куда как проще использовать встроенные средства создания отчетов и вывод их в Excel, мы по этому пути и пойдем.
Как всегда, все очень просто — переходим на вкладку “Reports” и жмем на кнопку «Visual Reports Export»:
Далее в открывшемся окне выбираем «Cash Flow Report», ставим уровень «Months»:
Жмем на «View» и в открывшемся окне Excel выбираем вторую вкладку (лист) – «Task Usage». Получаем такое вот окно, но оно пока малоинформативно:
На нем надо поставить в «Поля сводной таблицы» галочку «Monthly Calendar» и щелкнуть по значку "+", отмеченных красными овалами на рисунке. Перед нами открывается то, что мы хотели: помесячный кэш-фло в нашем проекте с кумулятивной информацией, т.е. мы понимаем ежемесячно общий итог — в плюсе мы или в минусе в этом месяце, и динамику — мы уже вышли в плюс в проекте по деньгам, или еще нет:
Давайте интерпретируем полученные данные. Красными овалами отмечены места, где нужно быть внимательным.
За март общий профит у нас отрицательный (не забываем инвертировать в уме знак, поскольку речь идет о расходах), расходы превышают доходы на 67 360р. За апрель — положительный, но лишь на 13280р, задержка всего на день сделает его отрицательным. Поэтому надо либо настаивать на увеличении аванса до 45%, либо вернуться из мира цифр в мир реальный и понять, что эти суммы не существуют сами по себе, они являются лишь информацией для принятия решений. Упоминавшиеся +57% к рейтам инженеров — некая абстракция, юристы и бухгалтеры получают свою зарплату за счет не только этого, но и других проектов. Вот если и по ним всем будет кассовый разрыв в марте — то это уже повод настаивать либо на увеличении аванса по проекту, либо отсрочить свои платежи на этот месяц, а если никак — искать другие способы заткнуть дыру, например, взять кредит в банке на пару месяцев. Но эти решения принимают финансист/директор, а не вы как РМ. Вы и так дали им очень ценную информацию: через два месяца есть риск кассового разрыва, у вас есть время, думайте. Это гораздо лучше, чем узнать об этой проблеме за две недели.
На этом все. Удачи вам в финансовом планировании!
![[Подборка] 6 no-code инструментов для быстрого запуска продуктов и автоматизации процессов](/upload/resize_cache/iblock/3dd/105_70_0/3ddc499da4507e9dedeb907b80876c0f.jpeg "[Подборка] 6 no-code инструментов для быстрого запуска продуктов и автоматизации процессов")
