Открыть список
Как стать автором
Обновить

Комментарии 18

> и не можете стопорнуть зомби – он на совершенно законных основаниях может требовать свой сайт

Это ведь решается договорными (устными или письменными) отношениями… да и тем более если он деньги заплатил.
«Зомби» бывают и с самого начала, просто их нужно вычислять и натравливать на них хороших «зомби»-менеджеров, которые приучат их к нормальной еде :)
Это конечно вариант, но вы же изменили условия задачи, которую я описал сразу. Мы действуем именно в её рамках.
Извините я вас не понял вероятно сразу… получается задача ради задачи, где есть некая гипотетическая ситуация
Тогда нужна статья о том как создать благоприятные н/у(начальные условия) чтобы не появлялось зомби.
Т.е. как правильно открыть проект
Ок, такая статья томится в черновиках уже полгода, доведу до ума.
В целом, я взял ситуацию которая встречалась чаще всего на данном рынке, и у меня в том числе, и многие решали её не совсем эффективно, вот я и описал.
спасибо за статью.
реквестирую цикл подобных:)
и вам спасибо за отзыв! Какая тематика вас интересовала бы более других?
все в рамках «наблюдений и некоторых рецептов относительно бизнеса создания сайтов» :) в данном деле чужой опыт часто бывает крайне полезен.
Вас понял, приготовлю что-нибудь вкусненькое на эту тему, благо шишек набито уже совершенно немыслимое количество). Я имел ввиду вам какую конкретно отрасль интереснее посмотреть? Ведение проектов, продажи (лидогены и программы лояльности), управление бизнесом в целом, работа с командой?
пусть будет ведение проектов и управление бизнесом.
спасибо!
Наверное еще вариант вернуть деньги?
Это, конечно вариант, но и он не всегда возможен читайте выгоден). Особенно, если выполнено более 75% работы (опираясь на ТЗ конечно).
В нашей практике не было клиентов, которые после «воскрешения из мертвых» не понимали бы, что поезд давно ушел и надо начинать все заново. А теперь мы и вовсе разбили весь процесс разработки сайта на три отдельных этапа, каждый по своему договору, только после завершения предыдущего: проектирование, дизайн, разработка — поэтому и ситуация будет попроще, в случае не совсем адекватного клиента.
Тогда вам можно только искренне позавидовать! ;). Надеюсь, вы ни когда и не узнаете этого сомнительного удовольствия ощущать себя экой Милой Йовович воюющей с тысячей зомбяков. Идея развития этапов в договоры очень клевая, мы собственно поступили почти так же, но несколько с другой стороны — мы этапы прописали в ТЗ, осметили их и закрываем промежуточными актами, я как раз в отдельной статье хотел рассказать про документы.
Мы просто поняли, что пытаясь угадать стоимость разработки дизайн-макетов до того, как будет написана подробная проектная документация, и стоимость верстки и программирования до того, как будут в наличии те самые дизайн-макеты, мы тычем пальцем в небо. После нескольких серьезных просчетов решили завязывать с попытками осметить весь проект целиком сразу. Мы боялись, что клиенты на это негативно отреагируют, но по факту такой подход лишь подчеркнул наш профессионализм и понимание вопроса.
Я не призывал ни кого отказываться от идеи технической документации. Ваш подход логичен и справедлив, но осметить, на мой взгляд достаточно точно можно и на этапе ТЗ и прототипирования — когда видна вся картина. Тут, к слову идет интересный момент — как вы делаете смету на этап? Исходя из стоимости нормочаса? А нормочас как считаете? Из каких параметров, что закладываете в стоимость?
P.s. По моему мы начинаем жестоко оффтопить. ;).
достаточно точно можно и на этапе ТЗ и прототипирования

Сложность верстки можно оценить, например, исключительно исходя из макетов. Иногда, при разработке макетов появляются новые, здравые идеи, которые влияют на функционал. Опять же, не только заказчику понятнее проект, когда он видит итоговую картинку, но и разработчикам тоже. Поэтому оценка по ТЗ и макетам всегда будет точнее, чем только по ТЗ.

И да, что-то мы уходим от темы статьи. :)
А как же этап прототипирования на котором тоже становиться понятно далеко не мало?
Немало != все.

Верстальщику, например, по определению становится понятно все только из макета и никак иначе.

Программисту, как правило, хватает макапов, но иногда (иногда) в итоговом макете появляются детали, которые влияют и на функционал тоже.
Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.