Comments 40
Отлично. Только топик не совсем соответствующий, большинство этих правил можно озаглавить как "Правила успешного делового человека"
Жизненно.
Отношение этих правил к базам данных надо сказать очень натянутое. Оно появилось только благодаря области приложения.
Отношение этих правил к базам данных надо сказать очень натянутое. Оно появилось только благодаря области приложения.
Отличная статья. Ко многим из прозвучавших в ней утверждений, и сам пришёл, работая с разными клиентами и над разными проектами. Но тут всё так компактненько и чётко написано... Спасибо!
Отчасти правильно!
Согласен с теми пунктами, с которыми сам сталкивался)
Про остальные ничего сказать не могу ;)
Согласен с теми пунктами, с которыми сам сталкивался)
Про остальные ничего сказать не могу ;)
Золотые слова!
немного правее немного правее еще правее, Вы в кадре
Не очень понятен 18-й пункт.
"Ах, вы хотите встретиться? Завтра? Конечно удобно, только оплатите счёт". Так что ли?
"Ах, вы хотите встретиться? Завтра? Конечно удобно, только оплатите счёт". Так что ли?
Нет, но бывают такие процессы согласований, которые затягиваются на столько, что уже неприлично. Либо ежедневные отчеты, которые занимают времени больше, чем сама работа.
Я знаю, что такое бывает. Это и не отрицала.
Вы знаете, у меня сейчас как раз такая ситуация. Долго и с двумя десятками правок согласовывали дизайн, утвердили, потом оказалось, что в связи с внутренним аудитом и проверками сверху в компании клиента необходима еще отмашка маркетологов. Всё это выливается в проведение еще одной презентации и, соответственно, будущих правок. Так что я не из простого любопытства спрашиваю: что делать? Если "нет", то как же?
Вы знаете, у меня сейчас как раз такая ситуация. Долго и с двумя десятками правок согласовывали дизайн, утвердили, потом оказалось, что в связи с внутренним аудитом и проверками сверху в компании клиента необходима еще отмашка маркетологов. Всё это выливается в проведение еще одной презентации и, соответственно, будущих правок. Так что я не из простого любопытства спрашиваю: что делать? Если "нет", то как же?
пункт 12 вам в помощь. На вашем месте предлагаю нормально объяснится с руководством и попросить денег либо расторжение договора. Прийдте с бумажками, на которых рассчитана рентабельность конкретно этого проекта и покажите, что увеличение длительности переговоров приведет в итоге к отрицательному результату. А так, конечно пункт 12 и акты подписанные в одностороннем порядке.
При чём тут пункт 12? Договор, естественно, есть - без него мы не работаем.
Денег попросить не выйдет - это компания-монстр и документы/оплаты там проводятся по полгода. Расторжение договора, суд, возвращение предоплаты - нереально.
Промежуточные акты есть и были закинуты в клиента сразу же после слов "о, крутая концепция!", но подписать не успели.
Так что я в некотором замешательстве: можно, конечно, начать эту игру с расторжением договора, но не факт, что не обойдётся дороже.
Денег попросить не выйдет - это компания-монстр и документы/оплаты там проводятся по полгода. Расторжение договора, суд, возвращение предоплаты - нереально.
Промежуточные акты есть и были закинуты в клиента сразу же после слов "о, крутая концепция!", но подписать не успели.
Так что я в некотором замешательстве: можно, конечно, начать эту игру с расторжением договора, но не факт, что не обойдётся дороже.
Это плохой клиент :) Потом так же принимать будет. Предоплата или ну нафиг.
схема time&materials, я полагаю. не очень принятая у нас схема, когда оплачиваются трудозатраты. и в них, конечно, надо включать встречи, согласования и т.п. понятно, что не совсем все - это было бы политически неверно. но большую часть - несомненно.
А расскажите, что под этим подразумевается?
Есть некое подобие, выражающееся в следующем: составляется смета, в которой указано рабочее время арт-директора, менеджера проекта и т.д.
Поясните, как это должно выглядеть на деле, пожалуйста.
Есть некое подобие, выражающееся в следующем: составляется смета, в которой указано рабочее время арт-директора, менеджера проекта и т.д.
Поясните, как это должно выглядеть на деле, пожалуйста.
вкратце, схема такая: согласовываются расценки на ресурсы. ресурсы в нашем случае, это часы персонала исполнителя. согласовывается стоимость часа каждого ресурса - дизайнера там, менеджера проекта и т.п. закрепляется документом, приложением к договору обычно. также в договоре описывается, каким образом фиксируются потраченные часы. и с какой-то периодичностью, порядок расчётов - в зависимости от проекта, раз в месяц, раз в неделю - составляется что-то типа акта - сколько часов каждого ресурса потрачено. на основании этих документов, клиенту выставляется счёт.
самое важное: не фиксируется заранее время. время принимается по факту. сколько потрачено - столько оплачено.
Why not? Но это сработает, если клиент уже на крючке :)
Это бред.
Зависит от ценника на консультации. В практике разное наблюдал.
В оригинале, по всей видимости, имелась в виду почасовая оплата консультаций, оговоренная заранее. Но оплачивают их обычно по факту? И вот если выставленный ранее счет не оплачен, то работая без денег далее, имеем приличный риск не получить их вовсе.
В оригинале, по всей видимости, имелась в виду почасовая оплата консультаций, оговоренная заранее. Но оплачивают их обычно по факту? И вот если выставленный ранее счет не оплачен, то работая без денег далее, имеем приличный риск не получить их вовсе.
распечатал,
повесил на стенку
спасибо!
повесил на стенку
спасибо!
Начало статьи - почти законы Мерфи, только применимы по отношению к БД. У Мерфи были системы...
Есть резон заменить тег "базы данных" на что-либо более широкое, типа "разработка" или что-то в этом роде.
Отличный текст, как руководство по ИТ-консалтингу.
Отличный текст, как руководство по ИТ-консалтингу.
Готов подписаться под каждым пунктом! Испытанно на собственной шкуре. Осмелюсь добавить еще пару пунтков:
21. Всегда составляйте приложение к контракту, где будет расписана требуемая функциональность финального приложения. Зачастую при сдаче проекта всплывают новые неожиданности, которые, по мнению клиента, обговаривались и должны быть.
22. Минимизируйте сроки поддержки вашей апликации после сдачи в эксплуатацию. Одна-две недели достаточно на тестинг и исправление ошибок. Поддержка стоит денег.
23. Старайтесь избегать конфликтных ситуаций с клиентом. Если клиент что-то просит сделать/изменить и если это сделать несложно, лучше будет выполнить его требование. Однако, приоритет у данной задачи должен быть самым низким.
24. Избегайте контрактов, где стоит штраф за просроченную сдачу проекта. Это может быть ловушкой.
25. Заключая контракты на долгий период/серьезную сумму всегда пользуйтесь услугами юриста. Имейте ввиду, что в некоторых случаях Вам придется подать в суд на клиента.
26. Если Вы не уверены в том, заплатит ли Вам клиент, лучший способ - предоставить клиенту бета-версию продукта с ограниченными возможностями или временем работы, которая будет заменена на финальную по факту оплаты.
Кто еще что добавит?
21. Всегда составляйте приложение к контракту, где будет расписана требуемая функциональность финального приложения. Зачастую при сдаче проекта всплывают новые неожиданности, которые, по мнению клиента, обговаривались и должны быть.
22. Минимизируйте сроки поддержки вашей апликации после сдачи в эксплуатацию. Одна-две недели достаточно на тестинг и исправление ошибок. Поддержка стоит денег.
23. Старайтесь избегать конфликтных ситуаций с клиентом. Если клиент что-то просит сделать/изменить и если это сделать несложно, лучше будет выполнить его требование. Однако, приоритет у данной задачи должен быть самым низким.
24. Избегайте контрактов, где стоит штраф за просроченную сдачу проекта. Это может быть ловушкой.
25. Заключая контракты на долгий период/серьезную сумму всегда пользуйтесь услугами юриста. Имейте ввиду, что в некоторых случаях Вам придется подать в суд на клиента.
26. Если Вы не уверены в том, заплатит ли Вам клиент, лучший способ - предоставить клиенту бета-версию продукта с ограниченными возможностями или временем работы, которая будет заменена на финальную по факту оплаты.
Кто еще что добавит?
К сожалению пока никак не могу повлиять на оценку статьи, но статья определенно стоящая. Разослал ссылки знакомым даже не из IT.
Sign up to leave a comment.
Правила Джоша (для деловых людей)