Здравствуйте, vyachin, Вы писали:


V>Можешь посоветовать умные книжки по написанию ТЗ? чтобы не совершать подобных ошибок

Карл Вигерс — Разработка требований к программному обеспечению.

Возможно, еще

Леффингуэлл — Принципы работы с требованиями к программному обеспечению.

Здравствуйте, dmoz, Вы писали:

D>Здравствуйте, vyachin, Вы писали:


V>>Можешь посоветовать умные книжки по написанию ТЗ? чтобы не совершать подобных ошибок

D>Карл Вигерс — Разработка требований к программному обеспечению.

D>Возможно, еще

D>Леффингуэлл — Принципы работы с требованиями к программному обеспечению.

хотелось бы почитать реальное тз, а таких я не нашел

книжки хорошо, но нужны практические занятия

Здравствуйте, vyachin, Вы писали:

V>Имел желание работать Project Manager в компании по созданию и продвижению web-проектов. После 2 раундов собеседований, между мной и еще одним кандидатом, фирма выбрать не смогла. Дали задание — составить план на разработку сайта. Я начал с Технического задания, потом выделил функциональные точки, прикинул сколько и каких потребуется исполнителей, составил план работы в MS Project, привел расчет окупаемости проекта. Ответ был "слабовато". Сижу и думаю где я облажался. Может я ТЗ написал не верно и отсюда и все остальные расчеты и планы ошибочны.

Ну смотри, сам напросился

Согласен, слабо. ТЗ не содержит почти полезной информации, зато содержит глупые придирки вперемешку с очевидными фактами. Структура ТЗ отсутствует, как класс. Могу обругать по пунктам.

1. Доменное имя. Оно уже зарегистрировано? Кто его зарегистрирует и на чье имя? Если оно уже занято (а так и есть), выкупать ли его у сквоттеров? Если оно у заказчика, то когда и как он его передаст? Кто покупает хостинг и разворачивает приложение? Задача менеджера решать такие вопросы. а не ждать, что решение свалится с неба. В твоем случае это можно было включить в план.

2. Цель. Для чего нужен этот сайт заказчику? Поднять ЧСВ? Заработать? На чем заработать? Перепродать? Проекты, которые непонятно зачем нужны, всегда проваливаются.

3. Язык. Будет локализация или нет?

4. Дизайн. Первое, о чем спросит дизайнер, как вообще должен выглядеть сайт.

5. Объем. Приехали. А как ты тогда оценивал траффик?

6. Технические ограничения разумно вынести в отдельный раздел. Никому, кроме разработчиков, они не интересны. Да и разработчикам ограничения интересны постольку поскольку. Еще неплохо в технические ограничения включить оценку траффика.

7. Каталоги шин и дисков. Кто будет рисовать логотипы? Кто администрирует каталог? Откуда берутся данные для первоначального заполнения? Откуда возьмутся рисунки протекторов и фотографии.Откуда возьмется соответствие марки автомобиля возможным шинам?

8. Каталог продавцов. Кто будет его администрировать? Как уговорить продавцов предоставить свои данные? На первых порах сайту это нужно больше чем им. Как заставить продавцов поддерживать прайс в актуальном состоянии? Откуда возьмется список продавцов для первоначального заполнения?

9. Форум. Кто будет администрировать форум? Что делать, если кастомизовать готовый форум не удастся? phpBB очень плохо поддается кастомизации.

10. Статьи. Кто будет писать статьи? Если статьи будут вороваться с других сайтов, кто будет их рерайтить?

11. Баннеры. Кто будет крутить баннеры? Самописный движок? Бегун? Google AdSense? Баннерная сеть? Сколько на сайте будет баннер-слотов и где они будут расположены?

12. Темы частных объявлений и мастера по подбору шин не раскрыты. Т.е. два пункта из собственных целей ты пропустил.

13. Оптимизация. Под какие запросы конкретно нужно оптимизировать? Сколько потратить на контекстную рекламу? Не раскрыта целевая аудитория. Сколько в ней казуалов, а сколько постоянных посетителей? Откуда пойдет траффик? Как утилизовать нецелевой траффик?

14. Умные люди описывают XML форматы посредством формальной схемы, а не примера.

15. Оценка сложности по функциональным точкам субъективна. Очевидно, что сложность одной фичи различна для разных специалистов. Например, для программиста каталог это день работы, а для дизайнера только неделя уйдет только на отрисовку логотипов производителей и еще две на рисунки протектора.

16. Ни один продавец не станет платить за то, чтобы разместиться на неизвестном сайте. Аналогично и с новостями, и с прайс-листом. Эта бизнес-модель не будет работать как минимум первые три года. Брать деньги за новости может когда-нибудь и удастся, а вот за размещение или прайс-лист -- никогда. Из чего вывод, все расчеты окупаемости всего лишь мечты. А точность прогноза -- бред.

17. Затраты на рекламу взяты с потолка. Хотя можно легко было оценить сколько посетителей принесет тот или иной вид рекламы.

18. Отсутствуют оценки рисков. Отсутствует разделение фич по приоритетам. Не прописан этап поддержки. Как ты вообще собираешься "вести" этот проект?

Общее резюме. Человек области новичок, терминологии не знает, что важно, а что нет не осознает. Обилием слов пытается заполнить отсутствие информации. Великого смысла брать такого в менеджеры, да еще и за 10% от проекта нет никакого. Любой студент справится ничуть не хуже, зато значительно дешевле.

V>Спасобо
Пыжаласта

Здравствуйте, Miroff, Вы писали:

M>Согласен, слабо. ТЗ не содержит почти полезной информации, зато содержит глупые придирки вперемешку с очевидными фактами. Структура ТЗ отсутствует, как класс. Могу обругать по пунктам.
Неплохое такое тестовое задание получается. Не на один день работы.

Здравствуйте, Miroff, Вы писали:

M>Ну смотри, сам напросился

M>Согласен, слабо. ТЗ не содержит почти полезной информации, зато содержит глупые придирки вперемешку с очевидными фактами. Структура ТЗ отсутствует, как класс. Могу обругать по пунктам.

вот слова не мальчика...

PM, насколько мне известно, делает всего одну вещь — распоряжается ресурсами. в данном случае от PM ждут убедительный бизнес-план. *техническое* задание — оно для исполнителей. соответственно, в этом тз с элементами бизнес-плана 90% — воообще не по делу. бизнес-часть же представлена по принципу динозавра. я уже написал в шутливой форме, что этому бизнес-плану в первую очередь не верит сам его автор, он просто не представляет как обеспечить все обещанные в плане вещи. вывод — это технический спец, который решил отобрать хлебушек у больших парней

BZ>вывод — это технический спец, который решил отобрать хлебушек у больших парней

На просторах бСССР все "большие парни" либо недавние, либо давние "технические спецы".

Здравствуйте, vyachin, Вы писали:

V>Здравствуйте, dmoz, Вы писали:

D>>Здравствуйте, vyachin, Вы писали:

V>хотелось бы почитать реальное тз, а таких я не нашел
V>книжки хорошо, но нужны практические занятия

Ну тебе же здесь посоветовали

D>>Карл Вигерс — Разработка требований к программному обеспечению.

Очень сильная и интересная книга. Считается классикой среди аналитиков и разработчиков ТЗ.

D>>Возможно, еще
D>>Леффингуэлл — Принципы работы с требованиями к программному обеспечению.

А в этой книге как раз есть пример ТЗ (правда не сайт, там система освещения что ли какая то...)

Хотя, честно говоря, я не понимаю зачем тебе, если ты хочешь пойти на PM. Тут уже совсем другие книги читать надобно.

Здравствуйте, vyachin, Вы писали:

A>>Могу ошибаться, но судя по тому что я увидел была прочитана какая-то книжка по написанию тех. заданий, опыта руководства проектами по созданию сайтов как-то не очень(либо ТЗ в них не применялись).
V>Можешь посоветовать умные книжки по написанию ТЗ? чтобы не совершать подобных ошибок

Я могу тебе посоветовать на данном этапе их не читать. Они все про форму написания ТЗ, а с формой у тебя как раз проблем нет, есть с сутью.

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

После этого можно приступать к форме. Если ты работаешь со своими собственными программистами, форма как правило не нужна вообще.
Я серьезно, я видел огромное количество отличных постановок задач в email-е на 1.5 страницы, и видел 100 страничные талмуды, написанные по форме из которых нельзя было понять, что нужно сделать.
Не занимайся фигней, не пытайся показаться умным — пиши понятный человеко-читаемый текст.

Талмуды, нужны в основном для постановке задач "противоположно экономически заинтересованной стороне". Т.е. аутсорсеру или подрядчику, который если ты что-то не впишешь в ТЗ, тупо это не сделает и будет говорить, что свою работу закончил(и будет прав, что характерно). И в "шаблонном ТЗ" главное опять же не словосочетания, а checklist того, что должно быть упомянуто, ну т.е. там везде есть прямо глава про производительность не забудешь. А сам шаблон, это просто пример для людей которые 2 слов в тексте связать не могут, чтобы они могли хоть как-то написать.

Здравствуйте, Anatolix, Вы писали:

A>После этого можно приступать к форме. Если ты работаешь со своими собственными программистами, форма как правило не нужна вообще.

Поясню более детально. Форма для своих людей не только не нужна, но и часто вредна.

Логика примерно такая: ТЗ должно быть на столько коротким на сколько возможно, но не короче. "Многа букв" сложно и скучно читать. За скучными буквами легко упустить важное.

Например, в некоторой компании принято делать web-сервисы которые отвечают быстро, поэтому там не надо писать в постановки фразу "времена ответа пользователю должны быть приемлемыми. Приемлемые это ... (и тут абзац текста про то что K% ответов быстрее 0.3 секунды, M% ответов быстрее секунды, во времена maintenance такие-то времена, и прочее-прочее)". Так получилось, что все это в этой компании подразумевается(или отдельно где-то написано — не важно). Отдельное его проговаривание в постановке все равно, читать никто не будет, человек скипнет абзац текста и все. А если получится что-то тормозное, то программиста и так можно попросить переделать, не нужно ему говорить что "это было в ТЗ" нужно сказать "это не удобно пользователям".

Внешнему подрядчику это скорее написать стоит, т.к. бывают кадры, которые, считают, что форма открывающаяся 20 секунд это нормально т.к. она экономит в среднем 2 минуты времени.

Здравствуйте, vyachin, Вы писали:

V>Просьба: подвергнуть критике ТЗ

V>Спасобо

Сумбур какой-то. Зачем в ТЗ выкладки по цене и окупаемости сайта? ТЗ для кого пишется? Для программистов или для инвесторов? Потом, требования в таком абстрактном виде (должно быть что-то, как-то, не понятно толком что и как), ИМХО, лучше оформлять отдельным документом, который собственно, согласуется с заказчиком в первую очередь. А в ТЗ уже нужно детализировать технические моменты, которые выводятся из первоначального документа с требованиями. Маркетинг здесь вообще не в кассу.

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

А вообще, честно говоря, впечатление, что эта бумага написана мечтательным программистом, напрочь отвязанным от бизнеса. Сначала — какие-то невнятные ожидания, потом много технических деталей, которые, заметно, что даже описывать скучно, а потом... А потом — ух! Маркетинговый успех, толпы клиентов, молочные реки, кисельные берега и графики для скромности подогнутые вниз от экспоненциального роста. Вот честно, именно так многие программисты, по моим наблюдениям, и думают, именно в такой последовательности — вот сейчас я что-то замучу, а потом ка-ак подомну под себя Майкрософт!

Здравствуйте, vyachin, Вы писали:

V>Дали задание — составить план на разработку сайта. Я начал с Технического задания, потом выделил функциональные точки, прикинул сколько и каких потребуется исполнителей, составил план работы в MS Project, привел расчет окупаемости проекта. Ответ был "слабовато". Сижу и думаю где я облажался. Может я ТЗ написал не верно и отсюда и все остальные расчеты и планы ошибочны.


Всегда думал, что ТЗ пишется после:
формально:
— технико-экономического обоснования,
— сбора требований (куда входит НЕФОРМАЛЬНО, далее)
и утверждения Видения (или, в зависимости, от применяемых подходов, Учтава проекта)
НЕФОРМАЛЬНО:
только после того, как узнал что-же почему как когда чем с кем и по чём хотят и не хочут заказчики и конечные польхователи.
И, самое, главное — есть ли ваще заказчик(и) и пользователь(и)...

Я бы без этого ваще не стал начинать, а воспользовался бы своим правом отказа от принудительного и бесцельного труда
(статья 4 ТК РФ).

Здравствуйте, vyachin, Вы писали:

V>Имел желание работать Project Manager в компании по созданию и продвижению web-проектов. После 2 раундов собеседований, между мной и еще одним кандидатом, фирма выбрать не смогла. Дали задание — составить план на разработку сайта. Я начал с Технического задания, потом выделил функциональные точки, прикинул сколько и каких потребуется исполнителей, составил план работы в MS Project, привел расчет окупаемости проекта. Ответ был "слабовато". Сижу и думаю где я облажался. Может я ТЗ написал не верно и отсюда и все остальные расчеты и планы ошибочны.

V>Просьба: подвергнуть критике ТЗ

V>Спасобо

А можно вопрос. То есть ТЗ как таковое — ну да, кое-что, еще куда ни шло, хотя конечно придраться есть к чему, но не в том суть. Суть вопроса вот в чем: я наверное не совсем в теме, но зачем в ТЗ вообще включать цифирь про то сколько мы там на рекламе заработаем, то да се пятое десятое? Это разве задача ПМ-а? У тебя выше написано — "Дали задание — составить план на разработку сайта" — ну так и создавай "план на разработку сайта". Можно отдельно еще составить план на продвижение сайта, политику получения прибыли и т.п. Но это все разные вещи Т.е. как мне это видется: должно быть описано что вот есть (если есть) такие-то требования — по функционалу, по дизайну, по времени, по траффику, по расширяемости (как клиент расчитывает — сколько у него там посетителей будет, какой объем инфы будет прокачиваться...). А ты уже должен составить план как эти требования реализовать — мол вот сначала это сделаем, потом вот это прикрутим, потом бета 1 лаунч, потом бета 2, по каждой бете — чт ов нее входит, чего ожидать заказчику (мол первая бета — три странички, 100 юзеров). А все эти графики, рубли, з/п программистов 2-й категории — это немного не твоя епархия: какой там доход от рекламы, как она будет продвигаться и тд и тп — это вообще дело отдельного, мегавысокооплачиваемого человека, какого-нить там маркетолога, может даже самого владельца — пусть у него об этом голова болит. Твое дело — с него требования собрать, формализовать, план работ написать...
Короче мое мнение такое что в своем ТЗ ты уделил слишком много внимания тому, чего там быть не дожно, и недостаточно тому, что должно

Здравствуйте, Glоbus, Вы писали:

G>У тебя выше написано — "Дали задание — составить план на разработку сайта" — ну так и создавай "план на разработку сайта".

Гы, я то же самое хотел написать.
А ещё забыл, что любым документам в проекте всегда предшествует составление и согласование Глоссария.
Его составляют даже для внутреннего пользования, внутри команд, работавших вместе годами.

Это обсуждение — иллюстрация этой необходимости.
Насколько я понимаю, под ТЗ разные люди понимают разное, практически все возможные разновидности документации!
И делать что-то не договорившись и не согласовав определения — нет никакого смысла

Здравствуйте, Glоbus, Вы писали:

G>Короче мое мнение такое что в своем ТЗ ты уделил слишком много внимания тому, чего там быть не дожно, и недостаточно тому, что должно

Давайте я уточню свою просьбу: оцените первые 10 страницы.

Здравствуйте, vyachin, Вы писали:

V>Давайте я уточню свою просьбу: оцените первые 10 страницы.

Какой упорный попался.
Я даже открывать не стану!
переименуйте ТЗ в сочинение (или эссе) + приложите глоссарий, тогда почитаю.

ТЗ не пишут в одиночку и без 3И (итеративно — инкрементально — интерактивно)!
Кроме того, ТЗ — живой документ, который пишут в течение всего проекта...

Вроде же Вам ответили, что Вас план просили, а не ТЗ?

Любитель перфокарт?

Здравствуйте, Она На Нас Ий, Вы писали:

ОНН>Здравствуйте, vyachin, Вы писали:

V>>Давайте я уточню свою просьбу: оцените первые 10 страницы.

ОНН>Какой упорный попался.
ОНН>Я даже открывать не стану!

я не настаиваю
внимательно читайте мой первый пост