правила для разработчиков

[Shkoder]

imho, очень полезные правила как для фриленсеров, так и для разработчиков "на ставке". жалею что не прочитал подобную статью лет 11-13 назад

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. Корзина не бывает наполовину пуста: если один клиент может задержать выплату денег, ничто не мешает сделать так же всем одновременно. Так что всегда будьте готовы прожить два месяца на собственные сбережения.

... и дополнительно ...

21. Всегда составляйте приложение к контракту, где будет расписана требуемая функциональность финального приложения. Зачастую при сдаче проекта всплывают новые неожиданности, которые, по мнению клиента, обговаривались и должны быть.

22. Минимизируйте сроки поддержки вашей апликации после сдачи в эксплуатацию. Одна-две недели достаточно на тестинг и исправление ошибок. Поддержка стоит денег.

23. Старайтесь избегать конфликтных ситуаций с клиентом. Если клиент что-то просит сделать/изменить и если это сделать несложно, лучше будет выполнить его требование. Однако, приоритет у данной задачи должен быть самым низким.

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

25. Заключая контракты на долгий период/серьезную сумму всегда пользуйтесь услугами юриста. Имейте ввиду, что в некоторых случаях Вам придется подать в суд на клиента.

26. Если Вы не уверены в том, заплатит ли Вам клиент, лучший способ - предоставить клиенту бета-версию продукта с ограниченными возможностями или временем работы, которая будет заменена на финальную по факту оплаты.