Здравствуйте! Пишу эту статью с целью, во первых, поделиться собственным опытом разработки в критичные сроки, моим видением этой проблемы (или не проблемы). Если это уже кто-то писал, извините, если же нет, то буду безмерно рад, если информация окажется полезной хоть кому-то. Ну и во-вторых — давно мечтаю о приглашении на этот замечательный ресурс.
Каждому разработчику, будь то начинающий программист/дизайнер/..., или уже опытный, съевший собаку в своем деле гуру, приходилось работать в сжатые сроки, или просто затянуть по каким либо причинам проект. Буду судить по себе, в начале моего пути это было довольно часто, и у меня поднакопился опыт выхода из данных, не очень приятных ситуаций. Толчком к написанию статьи именно на эту тематику стала лекция Олега Пащенко, в конце которой Людвиг Быстроновский поведал свое видение этого вопроса. Лекция, собственно вот: cmart.livejournal.com/409131.html
Много в чем не могу не согласиться с Людвигом, но все же, буду судить только по себе.
Итак, «Дедлайн!» вы услышали это страшное слово. Завтра сдача. Проект неготов. По началу я быстро бежал за комп, и начинал судорожно стучать по клавишам, пытаясь по быстрому так-сяк добить проект. Добить — именно то слово. Результатом такого поведения были только красные глаза, мертвый от бессмысленного и непродуманного кода проект, кормление заказчика завтраками, и штрафы за задержку.
Я решил что надо что-то менять.
Выработал для себя некие правила. Вот они:
1) Всегда нужно быть предельно честным с заказчиком. Это основное. Никогда не нужно «прибавлять» ни одного процента готовности решения поставленной задачи.
2) Перед тем как сесть, и что то написать, стоит выпить чашку чая, и еще раз подумать, все ли вы хорошо представляете по проекту? (Для себя я еще раз на листике прорисовываю архитектуру, стараюсь выбрать оптимальное решение той или иной задачи).
3) Если вы уже все-таки сели за работу, работайте до тех пор, пока не почувствуете, что мозг «начинает кипеть». Как только это случилось, сразу сделайте хотя бы получасовой перерыв. При этом ни в коем случае не думайте о работе. Хороший фильм или музыка в этом помогут. Передохнули — работайте дальше.
4) Как показывает практика (лично моя, за других говорить не буду), после 4х утра я уже работать не могу. Под словом работать тут надо читать продуктивно работать. Потому лучше в таком случае поспать, когда проект на стадии «вменяемой» разработки. И не портить проект.
5)Лучше не доводить до дедлайна =)
Следуя этим простым правилам я сдал уже не один десяток проектов, у нескольких сроки очень жали, и доделывалось все перед сдачей. Но проблем как с заказчиками, так и с кодом не возникало. Потому и решил поделиться опытом с Вами.
Спасибо за внимание.
Каждому разработчику, будь то начинающий программист/дизайнер/..., или уже опытный, съевший собаку в своем деле гуру, приходилось работать в сжатые сроки, или просто затянуть по каким либо причинам проект. Буду судить по себе, в начале моего пути это было довольно часто, и у меня поднакопился опыт выхода из данных, не очень приятных ситуаций. Толчком к написанию статьи именно на эту тематику стала лекция Олега Пащенко, в конце которой Людвиг Быстроновский поведал свое видение этого вопроса. Лекция, собственно вот: cmart.livejournal.com/409131.html
Много в чем не могу не согласиться с Людвигом, но все же, буду судить только по себе.
Итак, «Дедлайн!» вы услышали это страшное слово. Завтра сдача. Проект неготов. По началу я быстро бежал за комп, и начинал судорожно стучать по клавишам, пытаясь по быстрому так-сяк добить проект. Добить — именно то слово. Результатом такого поведения были только красные глаза, мертвый от бессмысленного и непродуманного кода проект, кормление заказчика завтраками, и штрафы за задержку.
Я решил что надо что-то менять.
Выработал для себя некие правила. Вот они:
1) Всегда нужно быть предельно честным с заказчиком. Это основное. Никогда не нужно «прибавлять» ни одного процента готовности решения поставленной задачи.
2) Перед тем как сесть, и что то написать, стоит выпить чашку чая, и еще раз подумать, все ли вы хорошо представляете по проекту? (Для себя я еще раз на листике прорисовываю архитектуру, стараюсь выбрать оптимальное решение той или иной задачи).
3) Если вы уже все-таки сели за работу, работайте до тех пор, пока не почувствуете, что мозг «начинает кипеть». Как только это случилось, сразу сделайте хотя бы получасовой перерыв. При этом ни в коем случае не думайте о работе. Хороший фильм или музыка в этом помогут. Передохнули — работайте дальше.
4) Как показывает практика (лично моя, за других говорить не буду), после 4х утра я уже работать не могу. Под словом работать тут надо читать продуктивно работать. Потому лучше в таком случае поспать, когда проект на стадии «вменяемой» разработки. И не портить проект.
5)Лучше не доводить до дедлайна =)
Следуя этим простым правилам я сдал уже не один десяток проектов, у нескольких сроки очень жали, и доделывалось все перед сдачей. Но проблем как с заказчиками, так и с кодом не возникало. Потому и решил поделиться опытом с Вами.
Спасибо за внимание.