http://habrahabr.ru/rss/post/46700/ ru editor@habrahabr.ru habrahabr.ru Sat, 11 Feb 2012 08:31:53 GMT http://habrahabr.ru/ http://habrahabr.ru/i/logo.gif http://habrahabr.ru/blogs/pm/46700/#comment_1195056 http://habrahabr.ru/blogs/pm/46700/#comment_1195056 Fri, 12 Dec 2008 12:32:17 GMT nileriver http://habrahabr.ru/blogs/pm/46700/#comment_1194415 http://habrahabr.ru/blogs/pm/46700/#comment_1194415 Fri, 12 Dec 2008 09:41:50 GMT Anei http://habrahabr.ru/blogs/pm/46700/#comment_1194335 http://habrahabr.ru/blogs/pm/46700/#comment_1194335 1. Работать с контентом. Как с отображением так и с настройками CMS.
2. Реализовывать новый функционал.
3. Документировать. И что сложнее создавать структуру документации.

А теперь подумайте правильно ли это?]]> Fri, 12 Dec 2008 09:18:42 GMT nileriver http://habrahabr.ru/blogs/pm/46700/#comment_1194317 http://habrahabr.ru/blogs/pm/46700/#comment_1194317 Fri, 12 Dec 2008 09:14:14 GMT nileriver http://habrahabr.ru/blogs/pm/46700/#comment_1194287 http://habrahabr.ru/blogs/pm/46700/#comment_1194287 Fri, 12 Dec 2008 09:08:05 GMT nileriver http://habrahabr.ru/blogs/pm/46700/#comment_1194174 http://habrahabr.ru/blogs/pm/46700/#comment_1194174 Очень часто крайним(виноватым) в срыве или провале проекта является менеджер, потому что именно он организовывает работу по всем направлением проекта:
— отношения с заказчиком;
— работа с программистами;
— тестирование;
— организация внедрения;
и еще куча мелких деталей…

Так вот ТЗ — документ, который (а особенно, если он подписан заказчиком) очень поможет менеджеру закончить проект, поскольку по сути является той точкой, до которой разработка ведется, т.е. является
пределом для всяких хотелок заказчика и есть тем за что можно спросить программиста…

И, как мне кажется, при составлении договора такой пункт как ТЗ, должен быть обьязательным.]]> Fri, 12 Dec 2008 08:40:02 GMT ivanr http://habrahabr.ru/blogs/pm/46700/#comment_1194130 http://habrahabr.ru/blogs/pm/46700/#comment_1194130 Fri, 12 Dec 2008 08:28:11 GMT ivanr http://habrahabr.ru/blogs/pm/46700/#comment_1194068 http://habrahabr.ru/blogs/pm/46700/#comment_1194068 Полностью с Вами согласен, это более удобно чем текстовое ТЗ с блоками.

притом, спроектированный в axure прототип вполне пригоден для ТЗ, а для «тонких» моментов можно использовать комментарии.]]> Fri, 12 Dec 2008 08:12:25 GMT l_nagash http://habrahabr.ru/blogs/pm/46700/#comment_1194004 http://habrahabr.ru/blogs/pm/46700/#comment_1194004 Fri, 12 Dec 2008 07:58:21 GMT nileriver http://habrahabr.ru/blogs/pm/46700/#comment_1193956 http://habrahabr.ru/blogs/pm/46700/#comment_1193956
И на тему сайтов региональных компания и прочих корпоративных порталов… Я такие делал. Реализовывать их на «внутренней cms» — мучение. Особенно когда менеджер не понимает что не малая часть функционала — дорабатывается программистом. Именно функционала. А хороших абстрактных и полностью кустомизируемых «внутренних cms» я не видел. И вряд ли увижу потому что это слишком серьезная инвестиция для «студии средней руки».

Я не скажу что в каждом проекте присутствует сложный функционал… Но скажем так. До 40 тыр(по питерским ценам прошлого года) — реализуемо в рамках имеющегося(я внутреннюю cms тогда писал сам.), от 40 до 80 — стопроцентно присутсвуе сложностей которые придется дописывать. Тут ваше ТЗ не подойдет. От 80 — эффективнее покупать коммерческую CMS. Вопрос с какой категорие вы работаете в первую очередь. В каждой из них есть «корпоративные сайты».]]> Fri, 12 Dec 2008 07:45:39 GMT nileriver http://habrahabr.ru/blogs/pm/46700/#comment_1193924 http://habrahabr.ru/blogs/pm/46700/#comment_1193924 Fri, 12 Dec 2008 07:36:53 GMT tabooman http://habrahabr.ru/blogs/pm/46700/#comment_1193233 http://habrahabr.ru/blogs/pm/46700/#comment_1193233
По теме и по личному опыту полностью поддерживаю Наталию. Менеджер не должен разбераться во всех технологических тонкостях! На то он и менеджер, чтобы донести весь замысел, как до Клиента (в первую очередь), так и до Разработчиков, все отследить, проконтролировать, «присутствуя» на всех этапах разработки (и к слову дизайна, что тоже очень немаловажно). Лично я, в последнее время, использую axure rp pro, для проектирования интерфейсов и внтури прототипа устанавливаю основные связи между объектами. Мне так проще, и клиенту можно прототип показать и донести, как тут не раз повторялось, «бизнес-логику». Потом разработчикам тот же прототип, в купе с дизайном + пояснения по дополнительному функционалу и пожелания.]]> Thu, 11 Dec 2008 20:44:55 GMT dejavu25 http://habrahabr.ru/blogs/pm/46700/#comment_1193200 http://habrahabr.ru/blogs/pm/46700/#comment_1193200 Thu, 11 Dec 2008 20:34:17 GMT Treg http://habrahabr.ru/blogs/pm/46700/#comment_1192824 http://habrahabr.ru/blogs/pm/46700/#comment_1192824 К слову о том же поле для телефонного номера, в разных странах формат ввода номера разный, и даже у нас, легко могут ввести что-то вроде:
+7 (495) 123–4567, доп. 1137

Так что требования к ТЗ, детально, лучше заранее уточнять с заказчиком, а если заказчик не может сформулировать требования, то помочь ему с возможными вариантами, чтобы выбрать оптимальный.]]> Thu, 11 Dec 2008 18:23:10 GMT boytsov http://habrahabr.ru/blogs/pm/46700/#comment_1192727 http://habrahabr.ru/blogs/pm/46700/#comment_1192727 www.axure.com/ — информативно, понятно всей команде, задействованной в проекте и можно показать заказчику что получиться в итоге. ]]> Thu, 11 Dec 2008 17:45:41 GMT l_nagash http://habrahabr.ru/blogs/pm/46700/#comment_1192591 http://habrahabr.ru/blogs/pm/46700/#comment_1192591
А программист — тот кто умеет настраивать cms плюс, если надо, он её по ходу несколько дорабатывает. Насколько он её сможет доработать уже зависит от опыта программиста. Но это в любом случае программист, не верстальщик и не контент-менеджер.

Типовых проектов достаточно много. Посмотрите сайты региональных компаний. Разве часто в них встречается сложный функционал?..

В случае нестандартных проектов ТЗ естественно будет другим. ]]> Thu, 11 Dec 2008 16:58:47 GMT nataly_bry http://habrahabr.ru/blogs/pm/46700/#comment_1192503 http://habrahabr.ru/blogs/pm/46700/#comment_1192503 Виноват всегда менеджер и не только в перечисленных ситуациях.

Что касается того, что в «телефоне можно буквы вводить». Продумывать такие моменты надо по умолчанию, не важно сколько проект стоит. Но продумывать их должен программист. Если не продумал, то должен поправить после замечания менеджера.]]> Thu, 11 Dec 2008 16:35:31 GMT nataly_bry http://habrahabr.ru/blogs/pm/46700/#comment_1192139 http://habrahabr.ru/blogs/pm/46700/#comment_1192139
То что вы понимаете что для проекта с нетривиальным функционалом требуется полноценное ТЗ — замечательно. Это указывает нам что вы хороший менеджер.

Но… Вы знаете мне кажется что этот ваш топик встречен так критично посколько большинство программистов имеют опыт в том что 99 процентов проектов имеют нетривиальный функционал. И даже больше. Тривиальный функционал должен реализовывать контент менеджер а не программист. К несчастью со стороны менеджеров слишком часто возникают ошибки, вида выдачи такой отписки в случае проекта в котором нестандартного функционала полно, или же выдача тривальных задач по набивке контента и настройке CMS программисту. ) Мне лично показалось что вы не очень понимаете для чего надо использовать программистов.

Поясню.
Такое ТЗ — хорошее. Но выдаваться оно должно не программисту. А контент менеджеру. Но программисты в фирме в наличии явно… И они нужны. Соответсвенно два вывода, либо вы выдаете такое ТЗ им в случае не стандартных проектов что ошибка, либо они занимаются не своим делом. что тоже кстати ошибка(Хотя и очень понятная… %) ). ]]> Thu, 11 Dec 2008 15:02:28 GMT nileriver http://habrahabr.ru/blogs/pm/46700/#comment_1192133 http://habrahabr.ru/blogs/pm/46700/#comment_1192133 Мне кажется программист всё таки человек а не парсер ТЗ, так что сам собразить сможет.]]> Thu, 11 Dec 2008 15:01:15 GMT kellas http://habrahabr.ru/blogs/pm/46700/#comment_1192129 http://habrahabr.ru/blogs/pm/46700/#comment_1192129 Вы — А почему поле необязательно?
Прог. — Так написано не было!
Вы — Это само собой разумеется… А почему в телефоне можно буквы вводить?
Прог. — Не было сказано не слова про проверки.
Вы — А разве не понятно, что в телефоне только одни цифры?

Обратная ситуация. Проект дешёвый и времени мало на его разработку. Проверки не нужны (они занимают время), но прогер реализует их (т.к. не было указано обратное) и срывает все сроки, за что ему не дают времени даже до аптеки за вазелином добежать…

Как Вы думаете, кто виноват в обеих ситуациях? Прогер виноват только в том, что он ВЗЯЛ это «ТЗ»!]]> Thu, 11 Dec 2008 15:00:02 GMT shaelf http://habrahabr.ru/blogs/pm/46700/#comment_1191826 http://habrahabr.ru/blogs/pm/46700/#comment_1191826 — регистрация клиентов и работодателей
— поиск вакансий и желающих найти работу
— …

И когда что-то уже сделаем клиенты начинают уточнять свои желания. Подобие ТЗ видел лишь однажды, когда заказ был от крупной корпорации и они просто на бупаге представили внешний вид ксех страниц со всеми полями что там должны быть, а уже тип полей, размерности и т.д и т.п. — этим всегда у нас занимаются программисты.]]> Thu, 11 Dec 2008 13:58:58 GMT serega011 http://habrahabr.ru/blogs/pm/46700/#comment_1191668 http://habrahabr.ru/blogs/pm/46700/#comment_1191668
Данная техническая записка не упоминается в договоре.]]> Thu, 11 Dec 2008 13:30:59 GMT nataly_bry http://habrahabr.ru/blogs/pm/46700/#comment_1191660 http://habrahabr.ru/blogs/pm/46700/#comment_1191660
Я понимаю под функциональным модулем часть cms, автоматизирующую одну задачу — например, создание и вывод новостей. Эти модули есть в cms, но нужно произвести некоторую его настройку. Например, программист должен знать, сколько новостей выводить на первой странице, будет ли по ним поиск, нужна ли фотогалерея на странице одной новости.

Вы понимаете под функциональным модулем что-то другое?

>Вы хоть раз реализовывали например в системе работу с базой 1С или с биллинговыми системами(хотя бы 5-ю)?

С 1С так и не удалось поработать, биллинговые системы были. Но в случае проекта с биллинговыми системами, писалось полноценное техническое задание на 60 страниц.]]> Thu, 11 Dec 2008 13:29:25 GMT nataly_bry http://habrahabr.ru/blogs/pm/46700/#comment_1191652 http://habrahabr.ru/blogs/pm/46700/#comment_1191652 Thu, 11 Dec 2008 13:26:50 GMT creadone http://habrahabr.ru/blogs/pm/46700/#comment_1191650 http://habrahabr.ru/blogs/pm/46700/#comment_1191650 Это перечень, а не описание. Вы перечисляете то, что там должно быть, а не то, как оно должно работать. Или где-то существует действительно подробное описание, которое вы здесь не указываете? Тогда какой смысл в статье, если самое интересное вынесено за ее пределы?

> У меня, благодаря моему личному принципу работы, риски сведены к минимуму.
Я рад, что у вас хорошие и думающие программисты, но в большой организации, где документация полностью отторгаемая, вам придется нелегко из-за особенностей коммуникации. Вы просто можете не попасть к программистам, чтобы объяснить на пальцах то, о чем вы написали слишком поверхностно.

Кроме того, у вас так и написано «список». Как на основе списка можно разрабатывать модуль ротации этих ушек? Нет ни данных, ни форматов передачи данных, ни алгоритма подстановки «ушек» с зависимостями.]]> Thu, 11 Dec 2008 13:26:26 GMT creadone http://habrahabr.ru/blogs/pm/46700/#comment_1191644 http://habrahabr.ru/blogs/pm/46700/#comment_1191644
Второе. По поводу функциональных модулей либо вы в исходном топике написали бред либо сами не совсем понимаете разницу между тем как модуль должен выглядеть и тем как он должен себя вести. Буквально… Не описание формы АЗС. А описание того как будут обрабатываться данные этой формы. С какими имеющимися модулями взаимодействовать например. Вы хоть раз реализовывали например в системе работу с базой 1С или с баллинговыми системами(хотя бы 5-ю)?
]]> Thu, 11 Dec 2008 13:24:17 GMT nileriver http://habrahabr.ru/blogs/pm/46700/#comment_1191630 http://habrahabr.ru/blogs/pm/46700/#comment_1191630 Thu, 11 Dec 2008 13:20:59 GMT nataly_bry http://habrahabr.ru/blogs/pm/46700/#comment_1191620 http://habrahabr.ru/blogs/pm/46700/#comment_1191620 Thu, 11 Dec 2008 13:19:20 GMT prolis http://habrahabr.ru/blogs/pm/46700/#comment_1191575 http://habrahabr.ru/blogs/pm/46700/#comment_1191575 Thu, 11 Dec 2008 13:06:53 GMT nileriver http://habrahabr.ru/blogs/pm/46700/#comment_1191572 http://habrahabr.ru/blogs/pm/46700/#comment_1191572 В приведённой в статье технической записке, пункт номер 2.

У меня, благодаря моему личному принципу работы, риски сведены к минимуму.]]> Thu, 11 Dec 2008 13:06:20 GMT nataly_bry http://habrahabr.ru/blogs/pm/46700/#comment_1191564 http://habrahabr.ru/blogs/pm/46700/#comment_1191564
>структура разделов
пункт номер 1

>источники контента
работа не программиста, а человека, который забивает контент

>функционал каждого раздела
>полное описание функционала модулей
пункт номер 2
и не «в минимальном виде хотя бы», а самым подробным образом]]> Thu, 11 Dec 2008 13:04:51 GMT nataly_bry http://habrahabr.ru/blogs/pm/46700/#comment_1191561 http://habrahabr.ru/blogs/pm/46700/#comment_1191561 Если для ваших программистов, значит они уже где-то описаны. Что может быть проще вставить готовое описание в документ? Программист, который работал с данным модулем, пропустит этот раздел при чтении, но зато документ будет полным, что поможет, например, если в будущем возникнет необходимость в поддержке сайта, особенно другим программистом, не знающим про «стандартные» модули.]]> Thu, 11 Dec 2008 13:04:47 GMT Stormbringer http://habrahabr.ru/blogs/pm/46700/#comment_1191559 http://habrahabr.ru/blogs/pm/46700/#comment_1191559
> так что не надо никого оскорблять.
Я не оскорблял никого, извиняюсь, если создалось такое впечатление.

> У меня не перечень объектов, у меня тщательное описание каждого
> функционального модуля сайта.
В записке, ТЗ или в концепции? Впрочем, ладно. Работайте как удобно вам и вашим рискам =)]]> Thu, 11 Dec 2008 13:03:22 GMT creadone http://habrahabr.ru/blogs/pm/46700/#comment_1191549 http://habrahabr.ru/blogs/pm/46700/#comment_1191549
Простите, если у вас уже готова CMS то какие конкретно действия будет выполнять программист? Этого из ТЗ не видно. Тут может быть как натяжка верстки на систему так и доработка модулей. Или сама верстка(в маленьких конторах я работал тоже, да %) ).
В общем.

Из ТЗ должно быть видно что нужно сделать программисту. По каждому пункту действий должны иметься дополнительная информация. Как то:

Натяжка верстки на систему — макет дизайна, структура разделов, источники контента, функционал каждого раздела(в минимальном виде хотя бы).
Доработка модулей — полное описание функционала модулей(Это вообще очень широкий пункт который отправляет вас к общему ТЗ на software продукт. Там все сложнее).

И так далее… В общем понятно должно быть что делать, и как это должно работать, а не только как это должно работать. Вообще повторюсь это типично…]]> Thu, 11 Dec 2008 13:00:51 GMT nileriver #comment_1191515 #comment_1191515
На таких сайтах ТЗ, как таковое, не нужно. По большому счёту, сайт стыкуется из модулей и на него натягивается дизайн. Максимум, что нужно — перечень дополнительных настроек для модулей (если речь, например, о каталоге товаров, то нужно перечислить, какие там ТТХ, чтобы потом этот каталог заполнять).

А вот если требуется новая функциональность, тогда ТЗ выглядит следующим образом:
1. Потребитель и цель. Кто будет пользоваться функциональностью и для чего? Скажем, раздел новости для кого? Для журналистов, для обычных посетителей (а будут ли читать?)
2. Детальный перечень функций. Ознакомиться с анонсами последних новостей. Прочитать новость целиком. Выбрать период в новостном архиве для ознакомления. Прочитать новость из архива. Добавить новость. Редактировать новость. Удалить новость. Публиковать новость. Перенести новость в архив.
3. Далее пишутся прецеденты (use cases) или краткие сценарии использования. Вот автор зашёл в админку. Выбрал ссылку «Добавить новость». Сайт показал страницу для редактирования новости. Автор ввёл текст, нажал кнопку Сохранить. Или Публиковать? Сайт сохранил новость и теперь показывает её анонс на главной странице сайта. Для каждой функции из пункта 2 должен быть хотя бы один прецедент, но может быть и 2-3 (могут быть разные способы реализации функций, например, можно новость добавлять не только вручную, но и импортировать из вордовского файла, и это другой прецедент).
4. Далее рисуется концептуальная модель. Какие классы объектов здесь есть? Как они взаимодействуют? На языке UML описываются связи, диаграммы взаимодействия. Тут есть объекты класса Новость и объекты класса Коллекция новостей. Может быть ещё Новостной раздел (если новости идут не одной лентой, а раскидываются под темам). Новость это дата/время публикации, текст, анонс, заголовок и т.д.
5. Описания классов переводятся в схему БД (если она нужна). Какие таблицы, какие поля в таблицах, какие типы. Если есть какие-то сложности, надо их отметить, предложить варианты реализации. В одном случае нужен триггер, в другом хранимая процедура, в третьем можно всё на клиенте сделать.

Ну и далее разработчик создаёт таблицы, пишет SQL-код, реализует описанные интерфейсы, проводит тестирование. Как-то так.]]> Thu, 11 Dec 2008 12:50:49 GMT markshevchenko http://habrahabr.ru/blogs/pm/46700/#comment_1191484 http://habrahabr.ru/blogs/pm/46700/#comment_1191484
>На безрыбье и рак рыба.
Вы не общались с этими людьми и не видели их работы, так что не надо никого оскорблять.

>В том-то и дело, что у вас только перечень объектов указан и больше ничего.
У меня не перечень объектов, у меня тщательное описание каждого функционального модуля сайта. Вы не вникли в суть того, о чём я писала.]]> Thu, 11 Dec 2008 12:42:30 GMT nataly_bry http://habrahabr.ru/blogs/pm/46700/#comment_1191477 http://habrahabr.ru/blogs/pm/46700/#comment_1191477 Thu, 11 Dec 2008 12:39:22 GMT nataly_bry http://habrahabr.ru/blogs/pm/46700/#comment_1191471 http://habrahabr.ru/blogs/pm/46700/#comment_1191471 > такого ТЗ. Потому что, если модуль новый, я подробно опишу, что он должен делать и из
> чего состоять.

В том-то и дело, что у вас только перечень объектов указан и больше ничего. Остальное, видимо, должно придти свыше. Подумайте сами, где у вас обработка ошибок? Где пояснение, куда складываются данные? Как модуль должен себя вести после заполнения данных? Какие элементы управления модулем должны быть? Откуда извлекаются, например, «услуги»? Это справочник или фиксированный набор? Вопросов очень много… Если их все не описать, то мы рискуем деньгами компании и клиента.

Понимаете, вы выложили заметку претендующую на рассказ о Настоящем Техническом Задании. А показываете заметку о небольшом кусочке концепции, прикрываясь словами о том, что программисты и так все знают, а то, что вы нам дали почитать — небольшая формальность.

> А вот программисты, с которыми работаю я, всегда довольны тем, что имеют всю
> исчерпывающую информацию по проекту. Меня больше интересует их мнение.
На безрыбье и рак рыба. Стремитесь к лучшему и не довольствуйтесь имеющимся.]]> Thu, 11 Dec 2008 12:37:56 GMT creadone http://habrahabr.ru/blogs/pm/46700/#comment_1191470 http://habrahabr.ru/blogs/pm/46700/#comment_1191470 У меня были сутуации, когда из-за слишком упрощенного ТЗ результат расходился с желанием заказчика. ]]> Thu, 11 Dec 2008 12:37:45 GMT den_rad http://habrahabr.ru/blogs/pm/46700/#comment_1191468 http://habrahabr.ru/blogs/pm/46700/#comment_1191468 У компании, в которой работает моя подруга, на корпоративном сайте некоторое количество нетривиальных внутренних сервисов. Другой пример — интерактивные рекламные кампании на корпоративном сайте. Для всего этого CMS уже мало.]]> Thu, 11 Dec 2008 12:37:39 GMT Anei