Правила Джоша (для деловых людей)

Автор оригинала: Josh Berkus
  • Перевод
Список советов от эксперта по базам данных и члена группы разработчиков Джоша Беркуса (Josh Berkus), на мой взгляд, может оказаться полезным не только консультантам в области баз данных. Приведённые советы относятся к сфере взаимоотношений с клиентами. Некоторые рекомендации, как мне кажется, являются актуальными и для разработчиков-фрилансеров.

Джош Беркус является членом ядра группы разработчиков PostgreSQL (PostgreSQL Core Team) с 2002-го года. В данный момент он работает на Sun Microsystems, входя в группу, занимающуюся открытыми СУБД. До работы над PostgreSQL он работал с различными другими приложениями и технологиями, включая OpenOffice.org, Microsoft SQL Server, Oracle PL/SQL, и (о, ужас!) COM+.

Я провёл восемь лет, работая консультантом по базам данных. Так как в данный момент я представляю собой нечто другое и скоро могу всё позабыть, думаю, надо записать несколько полезных уроков, выученных мной за это время.

1. Состояние данных отражает состояние бизнеса. Покажите мне клиента с хроническими проблемами в базе данных — и я покажу вам клиента с хроническими проблемами в области менеджмента.
2. Три вещи, с которыми вам не придется столкнуться никогда:
  • слишком мягкие временные рамки;
  • клиент, который платит слишком быстро;
  • точная и полная спецификация.

3. Решения, принимаемые по отношению к базе данных, «живут» очень долго («нет ничего более постоянного, чем временное»): среднее время жизни «временного, одноразового» приложения баз данных составляет 4 года. Некоторые такие кусочки кода датируются 1960-ми и работают и по сей день. Так что сразу рассчитывайте на долгосрочное использование.
4. Плохие клиенты погубят ваш бизнес: умение вовремя распознать плохого клиента и отказаться от него или вовремя расторгнуть контракт — это половина успеха. Будьте готовы сбежать в любую минуту.

5. Не спрашивайте о том, что еще можно сделать: дело не в том, что вы можете сделать, а в том, сколько клиент готов за это заплатить и как долго он готов ждать.
6. Связь между временем и деньгами логарифмическая. То есть, если вы хотите сократить время на 20%, то бюджет удвоится. Уменьшение бюджета на 30% увеличит время разработки в 4 раза.
7. Любые оценки слишком оптимистичны: разработка нового приложения займет у вас время в 3 раза больше оценочного времени и будет дороже вдвое. Или наоборот.
8. Вы никогда не:
  • потратите слишком много времени на спецификацию и прототипы;
  • напишете слишком подробную документацию;
  • уделите слишком много внимания удобству поддержки кода.

9. Все реальные базы данных содержат ложку дёгтя, который представляет собой кусочки данных, плохо поддающиеся попыткам использовать их в чётко определённых бизнес-процессах. Эти «ложки дёгтя» являются причиной того факта, что нельзя достичь идеальной целостности данных, и, к тому же, они влекут за собой 40% всех проблем.
10. Целостность данных — самоцель: каждый 1% нарушений целостности данных вдвое увеличивает время, затраченное на поиск проблем.
11. «Коварство» целостности данных: база данных, у которой 20% и более данных недостоверны, бесполезна. Бесполезна настолько, что её проще пересоздать заново, чем пытаться исправить. Для некоторых приложений этот порог и того ниже.
12. Всегда заключайте контракт, даже если работы всего на 1 день. Бланк контракта должен быть вашим, а не клиента. А при составлении контракта проконсультируйтесь с юристом. Оно того стоит.
13. Процесс подписания контракта — «лакмусовая бумага» процесса его выполнения: Если клиент проводит много времени в спорах и обсуждении условий контракта, то работать с ним (а тем более получать от него деньги) будет ещё сложнее. Если клиент настаивает на том, чтобы вставить в контракт какой-то странный и непонятный пункт, значит он планирует им воспользоваться. А если вы не в состоянии отказаться и уйти — вы не в состоянии вести переговоры.
14. У клиента плохая память: не важно, что клиент подписал — он забудет об этом через несколько дней, а то и часов. Любые требования и замечания клиента нужно документировать и хранить копии.
15. Никогда не соглашайтесь на фиксированную оплату, если вы не выполняли точно такую же работу как минимум дважды.
16. Нельзя рассчитывать на третьи лица: никогда не соглашайтесь на фиксированную оплату или оплату с условием «достижения полного успеха», если хоть какая-то часть проекта зависит от скорости выполнения работы, полноты документации и качества продукта, определяемых третьими лицами — лицами, не находящимися под вашим полным контролем. Это означает, что никогда не должно быть фиксированных ставок, если речь идет об обмене данными или исправлении чужого кода.
17. У клиента плохой вкус: никогда не позволяйте клиенту выбирать за вас инструменты, субподрядчиков или рабочую среду. Или, в крайнем слуае, пусть он за это дополнительно платит.
18. Включайте в счёт все встречи с клиентом — или вы полжизни потратите на них впустую.
19. Чем дольше вы откладываете рефакторинг, тем больше времени он займёт. Изменение схемы во время эксплуатации смертельно для проекта.
20. Корзина не бывает наполовину пуста: если один клиент может задержать выплату денег, ничто не мешает сделать так же всем одновременно. Так что всегда будьте готовы прожить два месяца на собственные сбережения.
AdBlock похитил этот баннер, но баннеры не зубы — отрастут

Подробнее
Реклама

Комментарии 40

    +1
    Отлично. Только топик не совсем соответствующий, большинство этих правил можно озаглавить как "Правила успешного делового человека"
      +1
      переименовал
      0
      Жизненно.

      Отношение этих правил к базам данных надо сказать очень натянутое. Оно появилось только благодаря области приложения.
        +1
        Согласен, можно было отойти от баз, и написать ширше (ширее). Но всё-равно, очень хорошая статья.
          0
          шире ;)
            0
            Это Задорнов. Хоть и не люблюя его, но молодец.
            0
            шире.
              +2
                0
                В любом юморе важна уместность. ;-)
          0
          Отличная статья. Ко многим из прозвучавших в ней утверждений, и сам пришёл, работая с разными клиентами и над разными проектами. Но тут всё так компактненько и чётко написано... Спасибо!
            0
            Отчасти правильно!
            Согласен с теми пунктами, с которыми сам сталкивался)
            Про остальные ничего сказать не могу ;)
              0
              С остальными, видимо, еще предстоит столкнуться.
              0
              Золотые слова!
                0
                немного правее немного правее еще правее, Вы в кадре
                  0
                  Не очень понятен 18-й пункт.
                  "Ах, вы хотите встретиться? Завтра? Конечно удобно, только оплатите счёт". Так что ли?
                    0
                    Нет, но бывают такие процессы согласований, которые затягиваются на столько, что уже неприлично. Либо ежедневные отчеты, которые занимают времени больше, чем сама работа.
                      +1
                      Я знаю, что такое бывает. Это и не отрицала.
                      Вы знаете, у меня сейчас как раз такая ситуация. Долго и с двумя десятками правок согласовывали дизайн, утвердили, потом оказалось, что в связи с внутренним аудитом и проверками сверху в компании клиента необходима еще отмашка маркетологов. Всё это выливается в проведение еще одной презентации и, соответственно, будущих правок. Так что я не из простого любопытства спрашиваю: что делать? Если "нет", то как же?
                        0
                        пункт 12 вам в помощь. На вашем месте предлагаю нормально объяснится с руководством и попросить денег либо расторжение договора. Прийдте с бумажками, на которых рассчитана рентабельность конкретно этого проекта и покажите, что увеличение длительности переговоров приведет в итоге к отрицательному результату. А так, конечно пункт 12 и акты подписанные в одностороннем порядке.
                          0
                          При чём тут пункт 12? Договор, естественно, есть - без него мы не работаем.
                          Денег попросить не выйдет - это компания-монстр и документы/оплаты там проводятся по полгода. Расторжение договора, суд, возвращение предоплаты - нереально.
                          Промежуточные акты есть и были закинуты в клиента сразу же после слов "о, крутая концепция!", но подписать не успели.
                          Так что я в некотором замешательстве: можно, конечно, начать эту игру с расторжением договора, но не факт, что не обойдётся дороже.
                            0
                            Дрючить юриста! :) Это его хлеб.
                              0
                              Юрист дрючится ещё на двух проектах =)
                                0
                                Значит не все в порядке с менеджментом. И рыба гниет с головы.
                                  0
                                  Юрист занят не с клиентами, а с подрядчиками. Ну, короче, это долгая история.
                        +1
                        Это плохой клиент :) Потом так же принимать будет. Предоплата или ну нафиг.
                        0
                        схема time&materials, я полагаю. не очень принятая у нас схема, когда оплачиваются трудозатраты. и в них, конечно, надо включать встречи, согласования и т.п. понятно, что не совсем все - это было бы политически неверно. но большую часть - несомненно.
                          0
                          А расскажите, что под этим подразумевается?
                          Есть некое подобие, выражающееся в следующем: составляется смета, в которой указано рабочее время арт-директора, менеджера проекта и т.д.
                          Поясните, как это должно выглядеть на деле, пожалуйста.
                            +1
                            вкратце, схема такая: согласовываются расценки на ресурсы. ресурсы в нашем случае, это часы персонала исполнителя. согласовывается стоимость часа каждого ресурса - дизайнера там, менеджера проекта и т.п. закрепляется документом, приложением к договору обычно. также в договоре описывается, каким образом фиксируются потраченные часы. и с какой-то периодичностью, порядок расчётов - в зависимости от проекта, раз в месяц, раз в неделю - составляется что-то типа акта - сколько часов каждого ресурса потрачено. на основании этих документов, клиенту выставляется счёт.
                              +2
                              самое важное: не фиксируется заранее время. время принимается по факту. сколько потрачено - столько оплачено.
                                0
                                Ценное замечание.
                                Большое спасибо.
                            –1
                            Why not? Но это сработает, если клиент уже на крючке :)
                              0
                              Это бред.
                                0
                                Зависит от ценника на консультации. В практике разное наблюдал.

                                В оригинале, по всей видимости, имелась в виду почасовая оплата консультаций, оговоренная заранее. Но оплачивают их обычно по факту? И вот если выставленный ранее счет не оплачен, то работая без денег далее, имеем приличный риск не получить их вовсе.
                                  0
                                  Тут немного другая ситуация.
                                  Мы работаем не в консалтинге. Обычно клиент итак считает, что он всё знает. И если мы не хотим стыдиться за выходящий из наших стен продукт, то в наших же интересах организовать встречу и поговорить.
                                  Выше я говорила о бюрократии, внутренних проблемах компании-клиента.
                            0
                            распечатал,
                            повесил на стенку
                            спасибо!
                              0
                              Начало статьи - почти законы Мерфи, только применимы по отношению к БД. У Мерфи были системы...
                                +1
                                Есть резон заменить тег "базы данных" на что-либо более широкое, типа "разработка" или что-то в этом роде.

                                Отличный текст, как руководство по ИТ-консалтингу.
                                  +2
                                  Ближе всего это не к консалтингу, а к заказным разработкам и проектам комплексного внедрения информационных систем.

                                  Для консультантов это не совсем руководство к действию, это перечень граблей, на которые попадут внедренцы.

                                  Отличный текст, и перевод на уровне. С удовольствием почитал :)))
                                  0
                                  Готов подписаться под каждым пунктом! Испытанно на собственной шкуре. Осмелюсь добавить еще пару пунтков:
                                  21. Всегда составляйте приложение к контракту, где будет расписана требуемая функциональность финального приложения. Зачастую при сдаче проекта всплывают новые неожиданности, которые, по мнению клиента, обговаривались и должны быть.
                                  22. Минимизируйте сроки поддержки вашей апликации после сдачи в эксплуатацию. Одна-две недели достаточно на тестинг и исправление ошибок. Поддержка стоит денег.
                                  23. Старайтесь избегать конфликтных ситуаций с клиентом. Если клиент что-то просит сделать/изменить и если это сделать несложно, лучше будет выполнить его требование. Однако, приоритет у данной задачи должен быть самым низким.
                                  24. Избегайте контрактов, где стоит штраф за просроченную сдачу проекта. Это может быть ловушкой.
                                  25. Заключая контракты на долгий период/серьезную сумму всегда пользуйтесь услугами юриста. Имейте ввиду, что в некоторых случаях Вам придется подать в суд на клиента.
                                  26. Если Вы не уверены в том, заплатит ли Вам клиент, лучший способ - предоставить клиенту бета-версию продукта с ограниченными возможностями или временем работы, которая будет заменена на финальную по факту оплаты.

                                  Кто еще что добавит?
                                    0
                                    24. Избегайте контрактов, где стоит штраф за просроченную сдачу проекта. Это может быть ловушкой.

                                    А как контролировать исполнителей? если они будут срывать сроки?
                                    0
                                    К сожалению пока никак не могу повлиять на оценку статьи, но статья определенно стоящая. Разослал ссылки знакомым даже не из IT.

                                    Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

                                    Самое читаемое