В прошлой своей публикации я рассказывал про Обусловленное нет. Кратко, часто нужно заказчику говорить обусловленное нет, с пояснениями и аргументацией, выслушать его доводы, где-то подвинуться, где то остаться стоять на своем. Клиенто-ориентированному предпринимателю сложно осознать, что иногда необходимо заказчику говорить принципиальное нет, давайте рассмотрим случаи, когда это необходимо.
Во-первых, что такое принципиальное нет. Это когда, вы говорите нет и предупреждаете заранее что такова ваша принципиальная позиция и к сожалению вы не можете её изменить. Вы можете потерять клиента, вы можете нарваться на скандал, но зато вы можете сохранить свою репутацию, время и деньги.
Спасибо за внимание. Надеюсь информация была вам полезна.
Во-первых, что такое принципиальное нет. Это когда, вы говорите нет и предупреждаете заранее что такова ваша принципиальная позиция и к сожалению вы не можете её изменить. Вы можете потерять клиента, вы можете нарваться на скандал, но зато вы можете сохранить свою репутацию, время и деньги.
- Клиент просит начать работать, а задачи все оформить потом. Часто происходит, что клиент говорит, что хочет некую информационную систему, но у него она только на стадии идеи и предлагает начать работать, как есть. При этом, часовая ставка клиента не устроит, поверьте, вероятность этого равна практически нулю, если вы не супер популярная фирма с непробиваемой репутацией.
В таких случаях, всегда обе стороны оказываются в проигрыше. Вы, потому что потратите время, на то чтобы делать задачи, переделывать задачи, и снова делать задачи. Клиент, потому что он в голове держал одну сумму за работы, а вы назовете совсем другую. В таком случае, вам необходимо четко и внятно сказать Нет. Предупредить что вы работаете только по четко определенным задачам.
Выход из ситуации? Предложить контракт на подготовку технического задания (спецификации), если вы готовы бесплатно инвестировать свое время можно это сделать бесплатно, но я вам настоятельно рекомендую за написание технической спецификации и выяснение всех требований, клиенту всегда, во всех случаях, даже по дружбе, даже по братски, выставлять счет. Это позволит вам понять, действительно ли клиенту нужна эта система.
- Клиент предлагает запустить систему сейчас, а акты подписать потом, вся оплата по окончанию. Если есть сомнения, до тех пор пока ваш заказчик не оплатил вам ваши услугу полностью и до конца, не передавайте исходные коды, оставьте механизм прекращения работы системы через месяц после запуска.
Сразу скажите клиенту, что вы систему подготовите к работе в бою, в течение Х дней с момента получения хотя бы 50% от стоимости договора. Не забывайте у клиента может смениться менеджмент, может заболеть бухгалтер, противные налоговики могут арестовать счета, может произойти куча различных случае в которых, вполне обоснованно и справедливо клиент не сможет оплатить вашу работу. Тут как бы и плохим не хочется быть и понять клиента можно. Но ведь ЗП сотрудникам надо платить исправно.
Выход из ситуации? Всегда и везде требуйте предоплату 30% минимум, 50% хорошо, поэтапная сдача проекта с привязкой Результат-Оплата, лучше всего. При этом, обязательно, детально пропишите условия поддержки. Стандартно год бесплатно на исправление багов. Если нужны консультационные услуги пропишите кол-во часов в месяц, которые вы готовы выделить на поддержку. Не забывайте, вся ваша гениальная работа по разработке сложной системы, можем быть испорчена двумя-тремя звонками вашего клиента в поддержку, когда ему не смогут помочь
- Никогда не воруйте чужой код, не ломайте доступы. Ситуации бывают разные. Клиенты бывают разные. Ваша репутация одна. В тот момент, когда вы своруете чужой код, о вашей репутации можно забыть.
Лучше купить одну лицензию и пользоваться ей на одном рабочем месте вашего ключевого разработчика, чем просто тупо воровать какие-то библиотеки, коды.
Если заказчик предлагает вам «договориться» и мол вот он знает как своровать систему, не ведитесь на это. Сегодня заказчик сказал вам одно, завтра скажет совершенно другое.
Выход из ситуации? Их много. Используйте опенсорс. Используйте гибкие схемы лицензирования, предложите как можно управлять лицензиями на уровне количества пользователей. Пишите код сами.
Спасибо за внимание. Надеюсь информация была вам полезна.
Комментарии (3)
madsmiley
23.02.2016 16:13Даже с точки зрения капитанизма — всего три очевидные проблемы, это ничтожно мало и не интерестно как для статьи. Да, ваш опыт печален, но все что тут описано — это жэ просто неумение оценить риски. В каждом кейсе риск намного выше предполагаемой выгоды, а в последних двух вообще явно угадывается кидалово.
undry
Я не знаю в каком мире вы обитаете, и в сколько софтверных компаниях вы работали. Из собственной практики я знаю, что когда у вас есть штат в 3+ сотрудников, которым ежемесячно нужно платить ЗП, а доходы у вас спорадические, любой проект рассматривается как спасательный круг. Появляется соблазн спасти бюджет компании. Вот для таких случаев эта статья и написана.
Я лично сталкивался раз 50 с п.2. Когда платили по окончанию проекта, крупные серьезные конторы, а потом говорили вот вам 30% и сорри. Девальвация, правительство, сменился менеджмент, отпала необходимость, уже купили другое, аргументы заказчик находит всегда.
Я делал бизнес в СНГ и понимаю его реалии. Но «кидают» не только заказчики из СНГ, даже компании из Брюсселя (не евросоюзные а именно бельгийские) кидали после 5-7 успешных проектов, когда ты расслабляешься и начинаешь доверять.
Пунктов может быть немного, но они были мной выстраданы, и если это поможет уберечь от ошибок моей молодости кого-то еще, я этим поделюсь :).