|
|
|
| Прочитал книгу "Программирование: Ступени успешной карьеру" наших любимых авторов :) И сразу хочу сказать спасибо авторам и тем людям, которые работали над ней! Технические части для меня были более понятны и информационны, нежели психологические (не в обиду Кузнецову, возможно я пока мало что понимаю в психологии..). В целом книжка умная, узнал много нового и инересного. Одним словом хороший труд, рекомендую к прочтению.
Перейду собственно к вопросу. Обычно когда появляется заказ (не часто ^^) всё проектирование сводилось к обдумыванию перед сном. И так как заказы не шибко большие, этого в полне хватало. Но тут я загорелся желанием поднять собственный сайт. Точнее его модернизовать и поднять на уровень достойный интрнета. Революция намечается большая, а т.к. делаю я его для себя, то времени это может занять достаточно много, ибо когда другие дела, когда лень одолевает. Вообщем подход к дело несколько другой, не как при работе с заказчиком... Ну и собственно решил заняться проектированием. Изначально хотелось сделать всё как описывалось в книге, но потом понял, что ситуация немного другая, и позволил некоторые отступления. В частности не стал описывать БД, т.к. она от части уже есть и в ней будут происходить только изменения. И выкинул планирование времени. Составлял 2 дня по 1-2 часика. Если сравнить с тем правилом 20/80, то это мизер :)
Собственно прикрепляю файл. Жду критики. Подскажите что где не так, может быть что где лишнего, или не хватает чего-нибудь. Вообщем народные советы :) | |
|
|
|
|
|
|
|
для: NIK
(30.10.2006 в 23:06)
| | Собственно очень неплохо - именно так и следует составлять техническое задание или список требований. Обязательно покажите заказчику - пусть добавит что считает нужным, затем этот документ можно использовать как критерий законченности работы - т.е. показываете документ и говорить - это выполнено, это тоже. Если заказчик хочет дополнительной функциональности под это можно выпросить либо дополнительные средства, либо дополнительное время - в зависимости от того чем вы ограничены. Требования заказчика обычно меняются обязательно - бороться с этим не нужно и бесполезно - это нормально, но новые требования (которые бывает перекрывают изначальные значительно) требуют дополнительных усилий и оплаты и документ, который обозначает позиции с которых начинались переговоры и за что вам идёт оплата очень полезен.
PS Важно не раздувать документ, даже если вы работаете в большой команде - 50-страничный документ с жёсткой регламентацией начинает приносить вред, вместо пользы.
PPS Очень хорошо, что вы не пишите как должен быть реализован тот или иной блок, а лишь описываете, что он должен делать - это очень важно. Я бы даже выкинул фразу "в БД заносится следующая информация", а заменил бы её чем-то вроде "профиль каждого пользователя характеризуется следующими параметрами" - это ещё более абстрагирует от реализации.
PPPS Собственно - это не проект, а список требований - он в Web-разработке более важен. Проект нужен - когда у вас команда и вам необходмо, чтобы её отдельные члены работали согласовано (т.е. чтобы 20 человек не программировали кто в лес, кто по дрова), а список требований нужен для того, чтобы вы согасовано работали с заказчиком.
Т.е. проект - для внутреннего потребления, а список требований - для внешнего. | |
|
|
|
|
|
|
|
для: cheops
(31.10.2006 в 00:09)
| | большое спасибо, исправлю и учту на будующее. Кстати если у кого есть подобные документы, которые можно выложить - выкладывайте - интересно посмотерть! | |
|
|
|
|
|
|
|
для: NIK
(31.10.2006 в 15:38)
| | - примеры
* пример составления технического задания разработки и создания веб-сайта
- документация
* договор на разработку и размещение веб-сайта
* опросный лист студии веб-дизайна
http://av-webstudio.ru/need.htm | |
|
|
|
|
|
|
|
для: NIK
(30.10.2006 в 23:06)
| | Я обычно пишу в ворде список разделов сайта.
Пишу цели и задачи сайта.
А потом начинаю описывать что пользователь может сделать в каждом разделе. Получается от 2-3х строк до 1й-2х страниц на раздел (в зависимости от сложности и лени писать).
Получается примерно также как у Вас.
Файл такой даю почитать заказчику и заставляю расписываться в прочтении. Потом можно ткнуть носом и сказать что обговаривали, а что нет.
А делать так как некоторые - писать "...при разработке сайта используются технологии PHP, HTML, JavaScript, MySQL... ...используются программы Adobe Photoshop, CorelDraw..." (это почти дословная цитата из примера технического задания одной веб-студии) смысла не вижу - клиентам по большому счету все-равно на чем сайт, им результат важен. А я и так знаю что я использую :) | |
|
|
|
|
|
|
|
для: NIK
(30.10.2006 в 23:06)
| | Ну я например не часто пишу такие вещи... просто самые элементарные вещи я не вижу смысла писать, а если вижу что мне будет сложно написать такую-то фигню сразу, я сначало описываю всёчто в ней должно быть (и почему-то всегда получается дофига много :( Что-то пишется, пишется и иногда описание только одной функции выходит на страницу-полторы :( ), но зато потом всё легко писать, всё известно, остаётся только всё это перевести в программный код. Просто я иногда пишу просто функции которые мне могут пригодиться
(если они оказываются не нужными, впихиваю их в другой проект :) ), а уже потом смотрю что делать :)
ЗЫ. сейчас прочитаю ваш файл и скажу своё мнение... | |
|
|
|