Мечтаю попасть к тимлиду, который будет способен заранее не допустить серьезных ошибок для жизни такого проекта. К сожалению, таких очень немного…
НО, зная несколько таких людей, могу точно утверждать, что вопрос ТЗ для них критичен и у них существует 2 версии ТЗ:
1. Предварительное, которое, как ожидалось, размытое.
2. Детализированное, на каждую итерацию.
Прелесть первого в том, что можно оценить, где оставить брешь для масштабирования
Прелесть второго — этап будет закончен в сроки, не важно стоит ли переделывать то, что было сделано ранее.
И волокита с ТЗ ведется постоянно, на каждую итерацию. Заказчик высказывает пожелания, а они описывают это и спрашивают: «Вы так хотите?», если нет — уточняют. Пока не провалились, да я и сомневаюсь в их провале. Заказчик готов платить за то, что они думают. Он не нуждается в писанине ради отмазки, ему нужна реальная работа и он прекрасно понимает, что изменить что-то можно по-разному. Особенно это важно и критичено при ревью кода, к примеру.
Нет, в целом, в большинстве своем я с Вами согласен, однако я не согласен с подходом «проект маленький -> к черту методологию» (в данном случае я горю про скрам, но на его месте может стоять любая другая)
То, что это немного «не корректно», вести много проектов одновременно — да. Все равно программист, как бы не старался, он по большей части будет выполнять их линейно и тут уже у менеджера возникают жуткие головные боли по поводу того, что проектов много, контроль терять нельзя. У вышеупомянутой методологии есть много прекрасных моментов, которые много упростили бы жизнь. Не хочу впадать в дебаты, они тут бессмысленны, но ответьте себе на простой вопрос: 'вы часто на 100% следуете предписаниям методологии, не совершая каких либо отклонений, не подмешивая в процесс «лучшие практики» из других процессов?'. Никто не сказал, что нужно принципиально выдерживать все предписания в полном виде. Очевидно, что некоторые этапы возьмутся наскоком и вполне успешно, однако и в «маленьких» проектах бывают подводные камни, как это и не смешно звучит.
По поводу 10 сайтов визиток параллельно — не вопрос. Костяк все равно будет один и тот же (±) и время, затраченное, к примеру, дизайнером и верстальщиком заведомо больше, чем затратит программист. И вот тут как раз и возникает не состыковка сроков, однако, это уже совсем другая тема, не из области ТЗ.
Вот спасибо! Честное слово, безумно хорошо и доходчиво для определенного круга лиц написано. Надеюсь, что те, кому я ссылку дал впитают информацию и больше не будут допускать ошибок, совершаемых ранее.
Как же меня бесит, когда пользователь плачется на минусовку кармы. Что ж никто не пишет «О да! Спасибо что вручили мне 100 плюсов в карму»?
Сформулировал свою мысль, написал? Ляпнул глупость — получи гранату. Общественное мнение есть общественное мнение. Каждый из нас — часть этого общества и не за чем из него выгораживаться.
вот затяжного переписывания разработчики как раз и постарались избежать… Тем самым самые частые и острые модули. а не те, что ради забавы били написаны, считайте что готовы и в день релиза — через пару дней будут вполне рабочими.
Например реализация пошаговых форм, в которых одно поле обязательно зависит от другого и если не выполняется ряд условий — не доступно к заполнению. На шестерке — самоубиство, семерка — в ядре поддерживает…
Ну насчет перевода — на друпалере есть вполне сносный, а при помощи еще одного модуля можно легко допритесать его. Этап уже пройденный.
По поводу модулей — если самому не лень писать — то да, ждать придется, но могу отметить, что в отличии от 6-ки — под семеркой программировать одно удовольствие! А множество модулей хоть и в деве — но вполне рабочие.
Ну и по поводу перехода с 5-ки на семерку — переход освящен: 5 -> 6 -> 7… В инструкциях это четко обозначено. Вот проблема переноса информации из 5 -> 6 предо мной не вставала. с 6-ки на 7-ку относительно без геммороя перешел. В общем потихоньку жизнь налаживается.
НО, зная несколько таких людей, могу точно утверждать, что вопрос ТЗ для них критичен и у них существует 2 версии ТЗ:
1. Предварительное, которое, как ожидалось, размытое.
2. Детализированное, на каждую итерацию.
Прелесть первого в том, что можно оценить, где оставить брешь для масштабирования
Прелесть второго — этап будет закончен в сроки, не важно стоит ли переделывать то, что было сделано ранее.
И волокита с ТЗ ведется постоянно, на каждую итерацию. Заказчик высказывает пожелания, а они описывают это и спрашивают: «Вы так хотите?», если нет — уточняют. Пока не провалились, да я и сомневаюсь в их провале. Заказчик готов платить за то, что они думают. Он не нуждается в писанине ради отмазки, ему нужна реальная работа и он прекрасно понимает, что изменить что-то можно по-разному. Особенно это важно и критичено при ревью кода, к примеру.
То, что это немного «не корректно», вести много проектов одновременно — да. Все равно программист, как бы не старался, он по большей части будет выполнять их линейно и тут уже у менеджера возникают жуткие головные боли по поводу того, что проектов много, контроль терять нельзя. У вышеупомянутой методологии есть много прекрасных моментов, которые много упростили бы жизнь. Не хочу впадать в дебаты, они тут бессмысленны, но ответьте себе на простой вопрос: 'вы часто на 100% следуете предписаниям методологии, не совершая каких либо отклонений, не подмешивая в процесс «лучшие практики» из других процессов?'. Никто не сказал, что нужно принципиально выдерживать все предписания в полном виде. Очевидно, что некоторые этапы возьмутся наскоком и вполне успешно, однако и в «маленьких» проектах бывают подводные камни, как это и не смешно звучит.
По поводу 10 сайтов визиток параллельно — не вопрос. Костяк все равно будет один и тот же (±) и время, затраченное, к примеру, дизайнером и верстальщиком заведомо больше, чем затратит программист. И вот тут как раз и возникает не состыковка сроков, однако, это уже совсем другая тема, не из области ТЗ.
Сформулировал свою мысль, написал? Ляпнул глупость — получи гранату. Общественное мнение есть общественное мнение. Каждый из нас — часть этого общества и не за чем из него выгораживаться.
З.Ы.
Ну не удержался :)
По поводу модулей — если самому не лень писать — то да, ждать придется, но могу отметить, что в отличии от 6-ки — под семеркой программировать одно удовольствие! А множество модулей хоть и в деве — но вполне рабочие.
Ну и по поводу перехода с 5-ки на семерку — переход освящен: 5 -> 6 -> 7… В инструкциях это четко обозначено. Вот проблема переноса информации из 5 -> 6 предо мной не вставала. с 6-ки на 7-ку относительно без геммороя перешел. В общем потихоньку жизнь налаживается.
В мегаплане привлекла только организационная структура, но имхо — ее стоит доработать…