Здравствуйте, уважаемые коллеги!
Эта статья является очередной историей о работе с заказчиком, а так же нашим первым опытом при работе с большим проектом.
Здравствуйте, уважаемые коллеги!
Эта статья является очередной историей о работе с заказчиком, а так же нашим первым опытом при работе с большим проектом.
Цель урока: финальный урок по созданию приложения. Написание технического задания. Создание БД. Переименование webTemplate. Применение скаффолдинга. Админка. Основной сайт. Тесты.
Это финальный урок, и тут я немного отойду от конкретного программирования и поразмышляю о работе.
Программирование – это работа, это профессия, это творчество. Когда я учился в университете и с кем-то шел по дороге домой, мы часто спорили, что лучше Windows или Linux, Delphi или C++. Тогда мы могли не спать ночами, чтобы красиво переписать построение семантического дерева для компилятора. Мы изучали пролог, лисп, конечные автоматы, структуры данных. Мы учились видеть красоту быстрой сортировки Хоара реализованную на лиспе. ВО!:
(defun quicksort (lis) (if (null lis) nil
(let* ((x (car lis)) (r (cdr lis)) (fn (lambda (a) (< a x))))
(append (quicksort (remove-if-not fn r)) (list x)
(quicksort (remove-if fn r))))))
Но теперь я рассматриваю программирование как услугу. Как что-то, за что мне платят деньги. Я занимаюсь фрилансом уже три года. В начале работы фрилансером я программировал не только веб и не только на asp.net mvc. Был и php на ZendFramework, и написание модулей для расчета стратегий для торговли на РТС на Quirk.
Домыслы. Самая большая проблема брендинга. А вместе с ним и дизайна. Львиная часть творческой работы выполняется на основе домыслов. И это основная причина, почему бизнес упорно не хочется воспринимать всерьёз дизайнеров, бренд-менеджеров, пиарщиков, креативщиков и прочую творческую братию.
Лень. Основная причина домыслов. Ошибки связанные с домыслами обходятся и исполнителям и заказчикам гораздо дороже во временном плане, чем вдумчивая и серьёзная работа, но думать не хочет никто. «Нарисуйте мне логотипчик» — говорит заказчик. «Легко» — говорит дизайнер. И начинает, высунув язык, «творить».
Читать полностью »
Первая часть статьи «Разработка технического задания «Что это такое, зачем оно нужно, с чего начать и как должно выглядеть?» вызвала немалый интерес. Кроме своей рассылки, я ее опубликовал и на известном сайте разработчиков Инфостарт, где она вызвала еще больший интерес, что не может не радовать. Как и обещал, пишу продолжение.
Читать полностью »
Я ни разу не читал сравнение методов подхода к разработке сайтов. Прекрасно понимаю, насколько это будет субъективно: каждый хвалит то, что умеет делать. И всё же, я решил обобщить свой опыт и наблюдения за тем, как это делают другие. В нашей сфере существует, грубо говоря, три наиболее популярных метода: проектирование, написание «ТЗ» и Agile. Вот их-то я и сравню.
На всякий случай договоримся о терминах:
Частенько, по долгу службы в том числе, приходится писать всякие ТЗ, а так же вникать и (командовать) создавать документацию по продуктам и решениям. ТЗ — для отношений с клиентом, документация — для разработчиков. Основные принципы, которые должны быть, коротко, под катом.
Читать полностью »
Сбор требований – это один из самых важных этапов при создании информационных систем и интернет-сайтов в частности. От того, насколько точно и полно будут учтены все пожелания заказчика в процессе проектирования сайта, и будет зависеть итоговый результат: получим ли мы сайт «для галочки» или это будет эффективный инструмент бизнеса, который будет приносить прибыль своему владельцу.
Предлагаемая методика сбора требований используется в нашей компании при разработке несложных клиентских сайтов, реализуемых по каскадной модели (Waterfall). Методика позволяет менеджеру по продажам организовать эффективный сбор требований и написать на его основе «Техническое задание», по которому разработчик будет создавать сайт.
Замечу, что ничего не мешает использовать данную методику сбора требований и в Agile–разработке, в частности, для создания первичного бэклога.
В данной статье я концентрировался именно на содержательной части сбора требований, а не на вопросах внедрения сбора требований в бизнес-процессы компании или на то, как строить диалог с клиентом – это тема для отдельного разговора.
Читать полностью »
В комментариях к статье Техническое задание на сайт зашел разговор о шаблоне для техзадания и, собственно, примере ТЗ, составленного по описанным в статье принципам. Там я пообещал показать, и шаблон, и само ТЗ.
Выполняю обещание, и в этой статье постараюсь показать написание ТЗ. Перед прочтением этой статьи настоятельно рекомендую прочитать Техническое задание на сайт, т.к. тут я не буду пояснять, почему ТЗ выглядит именно так, а буду просто описывать процесс создания техзадания в соответствии с принципами из вышеназванной статьи.
Не так давно на хабре были две статьи (Согласно техническому заданию и А зачем мне ТЗ? Я и так знаю!) посвященные техническим заданиям. У меня обе статьи вызвали, мягко говоря, недоумение, в особенности статья «Согласно техническому заданию». На мой взгляд, это вообще вредная статья, которая приводит к неверному понимаю сути ТЗ. В связи с этим хочу выразить свой взгляд на этот вопрос. Не буду говорить обо всех тех. заданиях, слишком широка тема, но думаю смогу рассказать о ТЗ на сайт.
То описание технического задания, о котором речь пойдет ниже, не является пересказомЧитать полностью »
Добрый вечер, созидающая часть !
Будучи разработчиком, я постоянно работаю с техническими спецификациями клиентов и мой первый пост — это небольшой очерк, анализ такой вещи, как «техническое задание».
Итак, когда компания-заказчик приходит к исполнителю и заказывает «неосязаемое нечто», последний делает постный вид и просит предоставить техническое задание (бриф, описание, спецификация). Заказчик, полный энтузиазма, начинает выплескивать его на бумагу и это правильное начало, ведь техническое задание – замечательная штука!
Оно позволяет выразить свои идеи, сделать их понятными для окружающих и получить вЧитать полностью »