Знаете, вот откровенно не могу понять, чего же пристали к МС? Ну кому мешал IE? Кому не нравится — все давно уже перешли на другие браузере. Те, кого устраивает — сидят на IE и не жужжат. Смерти IE хотите? Справедливо. Но, думаю, уже девятая версия будет весьма приличной. К тому же, ну как так ось без браузера? Давайте еще из винды удалим медиа-плеер, вордпад и еще с десяток программ, которые чаще всего не используются, но необходимы для старта работы с виндой «из коробки».
В свое время проходили по информатике. Весьма полезные между прочим знания. Пригодились мне не раз. Жаль, что сейчас на уроках информатики больше изучают ворд. )-:
Чем подробнее ТЗ, тем лучше. Писать его нужно совместно с заказчиком, а не просто присылать ему на утверждение. Чем быстрее заказчик вольется в рабочий процесс над сайтом, тем лучше.
Не лишним будет прописать в договоре различные моменты, касающиеся работ не входящих в ТЗ. Об этом на Хабре уже писалось не раз.
Если же все-таки заказчика осенило где-то по середине процесса, то можно смело увеличивать сроки и выставлять кост за доработки. Но такое возможно не всегда.
Если перечислять основные этапы, то это выглядит примерно так:
1. Договор
1. Постановка задачи
2. ТЗ
2.1. Выделение ресурсов под проект
3. Дизайн
4. Верстка
5. Тестирование
6. Программная часть
7. Тестирование.
Два пункта №1 потому, что в моей практике они не всегда идут попарно, в определенном порядке или вообще присутствуют. Опустил момент формирования бюджета. Как правило, в каждой компании есть свои порядки в этой аспекте. От вдумчивого просчета себестоимости и формирования божеской маржы, до «150 тыщ за любой сайт».
Я Вам совру, если скажу что у меня так не бывает. Бывает конечно. Иногда сильно проседаем со сроками.
Иногда бывает так, что должность PM занимает человек, который в сайтостроении не понимает ничего. В этом случае он полностью полагается на экспертное мнение условного «программиста», который оценивает задачи. И тут в силу халатности или невнимательности оценивающего формируется неадеватный срок выполнения задачи. В данном случае, нужно страховаться по срокам серьезнее. На 200, 300, 400%.
Если PM в прошлом программист или верстальщик, то с оценкой сроков гораздо проще. В прошлом я работал долгое время верстальщиком и сравнительно недолго программистом. Поэтому, явно завышенные или заниженные сроки вижу в 90% случаев и вовремя принять необходимые меры. Однако почти всегда страховка по времени не опускается ниже 200%.
Не стоит забывать так же. что в ход работы часто вмешиваются всякие форс-мажоры в виде упавшего сервера, экстренных правок по уже работающим проектам, болезни сотрудников и прочее. Всего не учесть.
«скидка 10% партнерам NetCat (при указании промо-кода)»
А где этот промо-код взять, если я партнер?
Не лишним будет прописать в договоре различные моменты, касающиеся работ не входящих в ТЗ. Об этом на Хабре уже писалось не раз.
Если же все-таки заказчика осенило где-то по середине процесса, то можно смело увеличивать сроки и выставлять кост за доработки. Но такое возможно не всегда.
Если перечислять основные этапы, то это выглядит примерно так:
1. Договор
1. Постановка задачи
2. ТЗ
2.1. Выделение ресурсов под проект
3. Дизайн
4. Верстка
5. Тестирование
6. Программная часть
7. Тестирование.
Два пункта №1 потому, что в моей практике они не всегда идут попарно, в определенном порядке или вообще присутствуют. Опустил момент формирования бюджета. Как правило, в каждой компании есть свои порядки в этой аспекте. От вдумчивого просчета себестоимости и формирования божеской маржы, до «150 тыщ за любой сайт».
Иногда бывает так, что должность PM занимает человек, который в сайтостроении не понимает ничего. В этом случае он полностью полагается на экспертное мнение условного «программиста», который оценивает задачи. И тут в силу халатности или невнимательности оценивающего формируется неадеватный срок выполнения задачи. В данном случае, нужно страховаться по срокам серьезнее. На 200, 300, 400%.
Если PM в прошлом программист или верстальщик, то с оценкой сроков гораздо проще. В прошлом я работал долгое время верстальщиком и сравнительно недолго программистом. Поэтому, явно завышенные или заниженные сроки вижу в 90% случаев и вовремя принять необходимые меры. Однако почти всегда страховка по времени не опускается ниже 200%.
Не стоит забывать так же. что в ход работы часто вмешиваются всякие форс-мажоры в виде упавшего сервера, экстренных правок по уже работающим проектам, болезни сотрудников и прочее. Всего не учесть.
Надеюсь, ответил на вопрос.