Образовалась странная проблема. Такая странная, что аж рассказывать про нее стыдно. Ну ничего, среди своих — можно.
Дело в том, что мы научились экономить деньги.
Казалось бы, это хорошо.
К сожалению, это не наши деньги, а деньги клиентов.
Так, попробуем с начала и внятно рассказать всю историю.
Заметная часть наших проектов идет по производственному циклу, основанному на дизайн-процессе. Иначе говоря, на гибкой методологии итеративных приближений к результату.
Это значит, что финансирование работ устроено по схеме time&materials.
Казалось бы, мечта поэта: сколько наработаешь, столько и получишь с клиента. Никаких выходов из бюджета, никаких ужасов fixed price.
Но есть нюанс.
Дело в том, что по ходу сделки все равно оговаривается так называемый ориентировочный бюджет проекта. Сумма, в которую мы с очень и очень высокой вероятностью укладываемся. Иногда она в итоге оказывается и больше, но чаще всего — меньше.
И тут случается засада. Вот смотрите.
Допустим, мы с клиентом договорились, что проект будет стоить ориентировочно 300 тысяч (или немногим больше). Начинаем работу. Еженедельно сверяем-согласуем загрузку на следующую неделю. Доходим таким образом до финала и успешно закрываем проект. Считаем деньги.
И внезапно оказывается, что 300-тысячный проект ужался до 190, а то и до 160 тысяч. Ну так получилось, что мы всё сделали быстрей, чем ожидалось. И клиент оказался вменяемей, чем можно было предположить на старте. И по ходу дела кое-какие задачи удалось выбросить, кое-какие углы срезать.
На финише счастливый клиент, получивший обещанное с нужным уровнем качества, в согласованный срок и, главное, за гораздо меньшие деньги.
И несчастные мы.
Почему несчастные? Да потому что мы же потратили время-силы на заключение сделки на 300 тысяч. А получили из этих уже обещанных нам денег — хорошо если две трети.
То есть заметная часть работы по заключению контракта (а это, между прочим, и маркетинг, и продажи, и планирование, и юридическая волокита) проделана зря. Расходы на эту сопроводиловку ушли в трубу.
Самое страшное случается, если проект и так-то не слишком попадает в интересный нам диапазон бюджетов, а в результате всей этой производственной экономии еще и вылетает за нижнюю границу разумного. Тогда расходы на заключение сделки съедают всю прибыль и даже уводят проект в минус. Ну и веселье.
Всё это происходит из-за нашей дурацкой привычки экономить деньги клиента. Согласитесь, странная манера: деньги уже обещаны, но брать их мы не хотим.
Точнее, не можем. Не заниматься же приписками времени в отчетах по проекту. То есть кто-то, может быть, счел бы это разумным шагом, но мы просто не способны на такие бизнес-подвиги.
Надо искать другой выход.
Мы пока никакого не нашли.
Но есть несколько гипотез, проверкой которых сейчас займемся.
Первая. Предположим, клиент готов в конце проекта «поделать еще что-нибудь на сдачу». И вполне будет счастлив получить от нас какие-нибудь доп. услуги, которые впишутся в уже согласованный бюджет. Почему бы ему эти услуги не предложить? Деньги-то уже все равно обещаны. Надо пробовать, пробуем.
Вторая. Допустим, перераспределение времени внутри проекта привело бы к еще большему-лучшему осчастливливанию клиента. Сэкономили на согласованиях — добавили времени проектировщику, нашли идею безо всяких мозговых штурмов — докупили время приглашенного эксперта, и так далее. То есть надо «просто» осознавать объем сэкономленного времени не единожды в самом конце проекта, а постоянно в процессе.
Почему же это «просто» ни разу на самом деле не просто? Штука в том, что, хоть обчитайся книжек про теорию ограничений систем, на практике все равно столкнешься с пренеприятной особенностью IT-менеджеров: они не любят признавать отклонение от плана.
Обычно эта засада бьет по тем владельцам бизнеса, кто хочет узнать о проблемах со сроками — и не узнает о них до самого непобедного конца.
Но у нас случилось обратное. Менеджеры экономят время — и не считают это чем-то значительным. Ну, наэкономил — и хорошо. К тому же по каждой отдельной задаче экономия может быть и невелика — это в целом по проекту набегает неплохая прибавка к пенсии.
Так что сейчас мы попробуем в схему еженедельного контроля прогресса по проектам (что было — что будет — чем сердце успокоится) включить сведение баланса по «банку времени» для каждого проекта. Пусть этот «банк» будет не размазан по задачам, а сконцентрирован в одном месте. Да-да, похоже на технологии ТОС, ничего нового, но мы все-таки сомневаемся в успехе мероприятия — не внедрили же еще.
А вы бы что делали в такой неожиданной ситуации?
Дело в том, что мы научились экономить деньги.
Казалось бы, это хорошо.
К сожалению, это не наши деньги, а деньги клиентов.
Так, попробуем с начала и внятно рассказать всю историю.
Заметная часть наших проектов идет по производственному циклу, основанному на дизайн-процессе. Иначе говоря, на гибкой методологии итеративных приближений к результату.
Это значит, что финансирование работ устроено по схеме time&materials.
Казалось бы, мечта поэта: сколько наработаешь, столько и получишь с клиента. Никаких выходов из бюджета, никаких ужасов fixed price.
Но есть нюанс.
Дело в том, что по ходу сделки все равно оговаривается так называемый ориентировочный бюджет проекта. Сумма, в которую мы с очень и очень высокой вероятностью укладываемся. Иногда она в итоге оказывается и больше, но чаще всего — меньше.
И тут случается засада. Вот смотрите.
Допустим, мы с клиентом договорились, что проект будет стоить ориентировочно 300 тысяч (или немногим больше). Начинаем работу. Еженедельно сверяем-согласуем загрузку на следующую неделю. Доходим таким образом до финала и успешно закрываем проект. Считаем деньги.
И внезапно оказывается, что 300-тысячный проект ужался до 190, а то и до 160 тысяч. Ну так получилось, что мы всё сделали быстрей, чем ожидалось. И клиент оказался вменяемей, чем можно было предположить на старте. И по ходу дела кое-какие задачи удалось выбросить, кое-какие углы срезать.
На финише счастливый клиент, получивший обещанное с нужным уровнем качества, в согласованный срок и, главное, за гораздо меньшие деньги.
И несчастные мы.
Почему несчастные? Да потому что мы же потратили время-силы на заключение сделки на 300 тысяч. А получили из этих уже обещанных нам денег — хорошо если две трети.
То есть заметная часть работы по заключению контракта (а это, между прочим, и маркетинг, и продажи, и планирование, и юридическая волокита) проделана зря. Расходы на эту сопроводиловку ушли в трубу.
Самое страшное случается, если проект и так-то не слишком попадает в интересный нам диапазон бюджетов, а в результате всей этой производственной экономии еще и вылетает за нижнюю границу разумного. Тогда расходы на заключение сделки съедают всю прибыль и даже уводят проект в минус. Ну и веселье.
Всё это происходит из-за нашей дурацкой привычки экономить деньги клиента. Согласитесь, странная манера: деньги уже обещаны, но брать их мы не хотим.
Точнее, не можем. Не заниматься же приписками времени в отчетах по проекту. То есть кто-то, может быть, счел бы это разумным шагом, но мы просто не способны на такие бизнес-подвиги.
Надо искать другой выход.
Мы пока никакого не нашли.
Но есть несколько гипотез, проверкой которых сейчас займемся.
Первая. Предположим, клиент готов в конце проекта «поделать еще что-нибудь на сдачу». И вполне будет счастлив получить от нас какие-нибудь доп. услуги, которые впишутся в уже согласованный бюджет. Почему бы ему эти услуги не предложить? Деньги-то уже все равно обещаны. Надо пробовать, пробуем.
Вторая. Допустим, перераспределение времени внутри проекта привело бы к еще большему-лучшему осчастливливанию клиента. Сэкономили на согласованиях — добавили времени проектировщику, нашли идею безо всяких мозговых штурмов — докупили время приглашенного эксперта, и так далее. То есть надо «просто» осознавать объем сэкономленного времени не единожды в самом конце проекта, а постоянно в процессе.
Почему же это «просто» ни разу на самом деле не просто? Штука в том, что, хоть обчитайся книжек про теорию ограничений систем, на практике все равно столкнешься с пренеприятной особенностью IT-менеджеров: они не любят признавать отклонение от плана.
Обычно эта засада бьет по тем владельцам бизнеса, кто хочет узнать о проблемах со сроками — и не узнает о них до самого непобедного конца.
Но у нас случилось обратное. Менеджеры экономят время — и не считают это чем-то значительным. Ну, наэкономил — и хорошо. К тому же по каждой отдельной задаче экономия может быть и невелика — это в целом по проекту набегает неплохая прибавка к пенсии.
Так что сейчас мы попробуем в схему еженедельного контроля прогресса по проектам (что было — что будет — чем сердце успокоится) включить сведение баланса по «банку времени» для каждого проекта. Пусть этот «банк» будет не размазан по задачам, а сконцентрирован в одном месте. Да-да, похоже на технологии ТОС, ничего нового, но мы все-таки сомневаемся в успехе мероприятия — не внедрили же еще.
А вы бы что делали в такой неожиданной ситуации?
Only registered users can participate in poll. Log in, please.
Что делать, если реальный бюджет проекта не дотягивает до согласованного?
30.8% Нет такой проблемы, а вы зажрались.69
20.54% Приписки времени — это нормально, все так делают.46
29.91% Лучше всего допродать услуг в рамках согласованного бюджета.67
12.95% Организовать менеджерам «банк времени», и пусть распределяют внутри проекта.29
5.8% Другое (опишу в комментариях).13
224 users voted. 101 users abstained.