Pull to refresh

Comments 41

Столбец одинаковых чисел в наброске сметы демонстрирует вопиющее незнание основ Экселя (в частности, абсолютных $ссылок). Это вызывает сомнения в уровне студии.
Не вник человек в суть таблицы.
Рыба явно непроверенная в бою. Например «Сайт должен одинаково выглядет в последних версия браузеров Mozilla Firefox версия 2.0 и выше, Internet Explorer версия 6.0 и выше, Opera версия 9 и выше, последней версии MacSafari» — а Вы не сталкивались с тем что FF и Opera например сглаживают шрифты в зависимости от версии операционной системы, а вот IE — нет. И это повод заказчику сказать — а почему у меня выглядит не так как у соседа? И кстати будет прав, если следовать Вашей формулировке
Уважаемый Воланд
ну в общем-то и Вы правы и формулировку то особо не изменишь
у людей не только разные операционки но и мониторы и глаза ), все случаи трудно предусмотреть необходимо «техническая допустимая погрешность»
ну почему же не изменить? Например «Сайт должен корректно отображаться в следующих браузерах — Mozilla FireFox версий от 2.0 до 3.7, Opera версий 9.0 до 10.01, Internet Explorer версии от 6.0 до 8.0». Корректно и одинаково — это все таки разные вещи а так как HTML — формат в первую очередь текстовый, а не графический каждый браузер и ОС имеют право на свою интерпретацию, главное чтоб она была верной!
Главное определить пределы этой погрешности, раз уж готовим юридический документ. Многие заказчики знают про сглаживание шрифтов (и даже про то, что, какой-то шрифт может быть не установлен в конечной системе) и не обращают внимания, но вот требуют кроссбраузерность «пиксель-в-пиксель» касательно позиционирования. То, что ФФ и ИЕ по разному отображают списки (пример абстрактный) — это ведь тоже «техническая допустимая погрешность» или нет?

Что-то у меня есть подозрение что они просто не догадываются что шрифты могут быть разными.
Если про сглаживание — то догадываются, обычно админы объясняют почему шрифты на разных машинах по разному выглядят, а вот про то, что шрифта вообще быть не может — приходиться объяснять, чаще всего когда выбирают что-то из поставки MS Office (вроде он, давно не сталкивался, кучу шрифтов ставит, которых по дефолту даже в винде нет)
Бывает встречаюсь в офисе с заказчиками… у некоторых на ЖК мониторах неправильное разрешение стоит. И ничего. работают.
Как то вы не так ТЗ пишете.
Должно быть
1) Цели и задачи проекта — …

Далее по полочкам(по средствам достижения целей) расписано как будете этих целей достигать.

По вашему же описанию выходит, что цель — втюхать клиенту список услуг.
Первым требованием к верстке я пишу что-то вроде: На момент сдачи выполненной работы сайт должен быть свёрстан на языке разметки xHTML 1.0 Strict в соответствии со стандартом, рекомендованным Консорциумом World Wide Web, размещенными по адресу www.w3.org/TR/xhtml1/, и проходить валидацию (проверку синтаксиса языка) по адресу validator.w3.org/.

Потом то же самое про CSS, иначе, по вашему варианту, просто непонятно откуда взялись требования к HTML и CSS, а не, например, к «чистому» XML и XSL :)
что важнее? стандарты или кросс-браузерность?
UFO just landed and posted this here
Речь все таки об IE — пару раз былипроблемы с оперой, но как то все таки решались…
Кстати насчет Strict — а в админке каким редактором пользуются клиенты? Он генерит код именно в стандарте strict?
UFO just landed and posted this here
UFO just landed and posted this here
Клиенту решать, если я вдруг сообщу, что данный функционал я не смогу реализовать в рамках стандарта. Хотя такого еще не было, в конце-концов есть вполне валидные (по букве, а не по духу стандартов) способы обойти большинство встречающихся «расхождений во мнениях».
Я бы IE 6.0 исключил из списка поддерживаемых браузеров. Его доля очень стремительно падает, а тратить время верстальщиков на подгонку верстки под мертвый браузер нерационально. Мы ставим заглушку с просьбой обновить браузер.
UFO just landed and posted this here
клиенты бывают разные, кому то удается объяснить и на сайт вешается предупреждение, а для кого то приходится верстать и под 6ку
Знаете, мой клиент на вопрос об верстке для ие6 спросил меня, что с ним не так, кроме того, что он убогий? Я объяснил в двух словах, пояснил, что это главным образом отразится на сроках и цене. Он ответил так, как я не ожидал: те, кто используют ие6, едва ли будут пользоваться его сервисом. Я еще больше удивился, когда он сам начал прогнозировать, что мол «с выходом семерки все перелезут на нее с хр». Вот такая адекватность.
почему бы не включить подгонку под ИЕ6 отдельной строкой в смете? :)
UFO just landed and posted this here
Да еще под каждую версию ;)
Как-то вы так круто объединили в один пункт весь графический дизайн: а где креативная концепция, где дизайн-концепция, где дизайн внутренних шаблонов и т.д.

И мы как-то стараемся разбивать проект на этапы, которые мы указываем в смете и сроки по каждому этапу, кстати.
да, конечно календарный план обязательно, допишу
скажите, вы дизайн на составляющие делите в каждом проекте или нет? в каком соотношении приблизительно приходиться?
Делим дизайн всегда по стандартной схеме: креативная концепция (2-3 варианта), дизайн-концепция (1-2 варианта), дизайн внутренних шаблонов ( шт.), технический дизайн (может разбиваться на подпункты). Единственное что может отсутствовать, это тех. дизайн, все остальное — наши требования. Мы не будем заставлять дизайнеров работать в «краске», если сама идея изначально не утверждена.
Не пишу ТЗ — ленюсь. :-( Точнее, писать все-таки приходится (чтобы у заказчика с отчетностью все было в порядке), но постфактум и когда-нибудь потом — по сути в виде отчета «что сделал». И трекер проектов очень хочется использовать, но как слали все e-mail'ы и звонили по телефону — так и продолжают слать и звонить…
Что в итоге? А то что заказчики не любят даже под дулом пистолета морочиться со всякими ТЗ и тем более проджект-трекерами. И поэтому я могу выставлять им цену как минимум в полтора раза выше за предоставляемый сервис и они готовы платить за то, чтобы у них ничего этого не было. :-)
А что касается постоянно упоминаемых (в каждой статьей о менеджменте проектов это есть) ситуаций из серии «Нас попросили сделать то-то, а мы — ХА! — Этого не было в ТЗ!» — это, конечно, прекрасно, но что же я за менеджер буду, если не смогу без заранее кропотливо расписанного перечня действий разрулить ситуацию и развести клиента на дополнительные деньги??? Подобного менеджера надо тут же гнать в шею за банальное неумение работать с клиентами! А как показывает практика — даже при наличии ТЗ клиенты все равно «достают». А начинаешь им этим ТЗ в лицо тыкать — считай больше ты с ними работать не будешь — найдут других, кто цену скажет больше, но зато будет их «облизывать»…
Впрочем, все вышесказанное конечно лишь ИМХО и личный опыт, не претендующий на объективность и всеобъемлимость. :-)
ну конечно
как вы сразу зрите в корень
правильно только worksection
(почти как его ворсейшество)
еще для пропаганды basecamp турбомилка хабрахабра, написания тз и здорового образа жизни
Турбомилк и бейскэмп не являются продуктами Пулы ;)
Очень, очень огорчили слова об откатах в первой части методички.
Сколько можно способствовать воровству?
Автор, вы понимаете, что это фактически участие в краже?
Зачем начинающему менеджеру эта информация? Сразу взять старт в нужном направлении?
А вот мы не даем откатов, и поверьте, это совершенно не мешает работать!

В целом по материалу: профессиональный менеджер продаж и менеджер проектов, уж простите, но не понял о ком речь в материале, должен настолько ориентироваться в области своей работы, чтобы «на лету» генерировать и реализовывать индивидуальный план действий под любую ситуацию. Методички загоняют в рамки. Реальная задача: выстраивание отношений бизнес-клиент — это разовая работа и по методичке ее не сделаешь.
дорогой Nimax
прошу заметить, я не проявляю эмоциональной окраски, не говорю «я-я-я натюрлих откат гут»
я лично считаю что бизнес это минивойна
использовать химическое оружие запрещено, но знать о нем неплохо бы, когда с долин поползет зеленый дым
точно также и с откатами — я лично против, поскольку на длинной дистанции это все равно не поможет.
но вот совсем зеленому чувачку, возможно, интересно будет как это бывает.
Опять же, суперпрофи может конечно генерировать ТЗ и план продаж просто исходя из запаха клиента. В начале статьи я написал, что информации потенциальна интересна для начинающих.
Ок, Ваша позиция ясна.
В любом случае стоит уточнить, что отбросив вопросы честности (хотя их нельзя отбрасывать) начинающий менеджер должен понимать психологию откатчика — такое контактное лицо теряет интерес к работе ровно в момент получения денег т.е. автоматом весь проект оказывается под угрозой срыва.
Вообще не знаю, почему вошло в практику пугать заказчика ТЗ — ведь это должен быть внутренний документ студии. Многие заказчики не отличат Flash от Javascript, не говоря уже о таких страшных фразах, как «язык разметки xHTML 1.0 Strict». В документе, описывающем требования заказчика, должно быть все написано на понятном ему языке, иначе этот талмут будет утвержден для отчетности и положен на полку. В результате — потраченное время менеджера и заказчик не представляет, что же ему сделают.

Я больше склоняюсь называть этот документ «спецификацией», в которой должны быть описаны функциональные особенности — как с точки зрения пользователя все должно работать (а никак не программиста), идеальный вариант — снабдить кликабельными макетами. И никакая рыба тут не поможет.
Мы например больше используем т.з. для описания структуры сайта, для того, чтобы заказчику не вздумалось добавить (убрать) парочку ключевых разделов.
согласен с вами
схематические кликабельные макеты — отличный вариант
в принципе для их построения я и рекомендовал посмотреть на axure
статья реально полезная… даже человеку, который вроде все так и делает, только вот… какие-то мелочи все же упускаю, клиенты же разные бывают… и приходится каждый раз изобретать все тот же велосипед
вполне адекватная статья. все правда банально, но правильно :)
Sign up to leave a comment.

Articles