Правила Джоша

Обсуждаем разработку программного обеспечения

Сообщение vva » 23 июл 2007, 18:53

http://samokhvalov.habrahabr.ru/blog/21167.html

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

Список советов от эксперта по базам данных и члена группы разработчиков Джоша Беркуса (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. Корзина не бывает наполовину пуста: если один клиент может задержать выплату денег, ничто не мешает сделать так же всем одновременно. Так что всегда будьте готовы прожить два месяца на собственные сбережения.
Аватар пользователя
vva
Администратор
 
Сообщений: 2914
Зарегистрирован: 06 фев 2007, 13:33

Кто сейчас на форуме

Сейчас этот форум просматривают: нет зарегистрированных пользователей и гости: 1