-
Юбилейный DevConfX пройдет 21-22 июня в Москве. Как всегда — Вы решаете, кто попадет в программу секции Backend — голосуйте за интересные доклады
TutanXamoN
Новичок
Теперь я всё делаю только с ТЗ)
Да часто ето убивает время, да ето многим заказчикам не нравиться, но был интереснейший случай:
появился человечег со словами я хочу СRM'ку, мы ему ОК давай ТЗ. Принесли стопочку нам листов едак под сто с различными видами интерфейса его пронумерованными елементами и несколькими строчками текста к каждому из номеров. И закипела работа) С виду всё понятно всё ясно что куда и как при нажатии чего достаеться аль выводиться но механизм взаимодействия модулей был очень расплывчат.
Ето было начало и не понравилось заказчику решение, и сели мы вместе с ним да пошли по всем модулям и страничкам написали ориентировочное ТЗ и закипела работа...
А теперь некоторые цифры:
Изучение первоначального ТЗ - 4 часа
Разработка проекта по первоначальному ТЗ - 3 недели
Выяснение всех рабочих моментов по проекту с детализацией алгоритмов и их взаимодействия с выездом в офис заказчика на такси и просиживанием там по 6-7 часов - 7 месяцев (с паралельным вставлением всех костылей в первоначальную реализацию)
Что интересно так как выясненные моменты ни коим образом не противоречили первоначальному ТЗ и в нём не было строчки о "доработке" нас жестоко поимели.
ИТОГ:
1.время разработки до удовлетворения - 1 год, а денег получено как за 2 месяца.
2.Если бы в первоначальном ТЗ даже по "несовместимым с веб-приложениями" ГОСТАМ были указаны алгоритмы - на разработку ТЗ - две недели, на систему 1 месяц.
3. Заказчик считает нас педерастами, мы - его. (хоть виноваты обе стороны)
После етого я всегда все проекты (даже сайты-визиточки) делаю с ТЗ.
Стандарт ТЗ штука расплывчатая, но ТЗ есть документ который в подписанном виде способен указать кто таки педераст, а кто -нет.
Сейчас мы поступаем так - приходит человек без ТЗ, мы ему вежливо - либо на йух лиюо с ТЗ либо мы его делаем за деньгу.
Приходит с ТЗ - мы смотрим ето ТЗ, если что-то расплывчато добавляем и всегда теперь ВСЕГДА там есть строчка регламентирующая поведение и сексуальную ориентацию заказчика в случае отклонений от требований в подписанном ТЗ.
Главное в ТЗ ето выяснить у заказчика что он хочет.
Причём так чтобы ето было понятно програмисту, а не только заказчику.
Пора уже понять что люди работающие по определённым алгоритмам впитали их как встать-умыться, а вот описать они ето могут - "я встал как обычно".
Главное в ТЗ (ИМХО):
1. Описание модулей
2. Алгоритм работы каждого из модулей (если - то)
3. Связи между модулями (если там - то, тогда здесь - так)
4. Требование к системе как целостному объекту - безопасность, авторизация ограничение прав доступа к определённым модулям.
5. (необязательно, но часто лучше прописать, предварительно дав варианты) Интерфейс.
6. Самое главное - "любые изменения системы отличные от указанных в данном ТЗ описаниях (нас не е...)(нам п....) выполняються в отдельно оговариваемые сроки по сдельной цене с подписанием изменённого ТЗ"
ЗЫ согласен - "многа букафф", но надеюсь после прочтения етого поста многие не войдут в тёмную комнату, под названием - "Разработка проекта без чётко сформулированного ТЗ", полную граблей .
Да часто ето убивает время, да ето многим заказчикам не нравиться, но был интереснейший случай:
появился человечег со словами я хочу СRM'ку, мы ему ОК давай ТЗ. Принесли стопочку нам листов едак под сто с различными видами интерфейса его пронумерованными елементами и несколькими строчками текста к каждому из номеров. И закипела работа) С виду всё понятно всё ясно что куда и как при нажатии чего достаеться аль выводиться но механизм взаимодействия модулей был очень расплывчат.
Ето было начало и не понравилось заказчику решение, и сели мы вместе с ним да пошли по всем модулям и страничкам написали ориентировочное ТЗ и закипела работа...
А теперь некоторые цифры:
Изучение первоначального ТЗ - 4 часа
Разработка проекта по первоначальному ТЗ - 3 недели
Выяснение всех рабочих моментов по проекту с детализацией алгоритмов и их взаимодействия с выездом в офис заказчика на такси и просиживанием там по 6-7 часов - 7 месяцев (с паралельным вставлением всех костылей в первоначальную реализацию)
Что интересно так как выясненные моменты ни коим образом не противоречили первоначальному ТЗ и в нём не было строчки о "доработке" нас жестоко поимели.
ИТОГ:
1.время разработки до удовлетворения - 1 год, а денег получено как за 2 месяца.
2.Если бы в первоначальном ТЗ даже по "несовместимым с веб-приложениями" ГОСТАМ были указаны алгоритмы - на разработку ТЗ - две недели, на систему 1 месяц.
3. Заказчик считает нас педерастами, мы - его. (хоть виноваты обе стороны)
После етого я всегда все проекты (даже сайты-визиточки) делаю с ТЗ.
Стандарт ТЗ штука расплывчатая, но ТЗ есть документ который в подписанном виде способен указать кто таки педераст, а кто -нет.
Сейчас мы поступаем так - приходит человек без ТЗ, мы ему вежливо - либо на йух лиюо с ТЗ либо мы его делаем за деньгу.
Приходит с ТЗ - мы смотрим ето ТЗ, если что-то расплывчато добавляем и всегда теперь ВСЕГДА там есть строчка регламентирующая поведение и сексуальную ориентацию заказчика в случае отклонений от требований в подписанном ТЗ.
Главное в ТЗ ето выяснить у заказчика что он хочет.
Причём так чтобы ето было понятно програмисту, а не только заказчику.
Пора уже понять что люди работающие по определённым алгоритмам впитали их как встать-умыться, а вот описать они ето могут - "я встал как обычно".
Главное в ТЗ (ИМХО):
1. Описание модулей
2. Алгоритм работы каждого из модулей (если - то)
3. Связи между модулями (если там - то, тогда здесь - так)
4. Требование к системе как целостному объекту - безопасность, авторизация ограничение прав доступа к определённым модулям.
5. (необязательно, но часто лучше прописать, предварительно дав варианты) Интерфейс.
6. Самое главное - "любые изменения системы отличные от указанных в данном ТЗ описаниях (нас не е...)(нам п....) выполняються в отдельно оговариваемые сроки по сдельной цене с подписанием изменённого ТЗ"
ЗЫ согласен - "многа букафф", но надеюсь после прочтения етого поста многие не войдут в тёмную комнату, под названием - "Разработка проекта без чётко сформулированного ТЗ", полную граблей .
jonjonson
Охренеть
TutanXamoN, и всё же вы не правы в своём списке. Не должен клиент обсуждать модули и их взаимодействие. Это реализация, а кроме специалиста в ней никто ничего не понимает. И если заказчик начинает расписывать модули (то что более менее точно понятно после реализации проекта), то значит проблему поимеете и вы и он. Не специалист он в области реализации или сам бы всё разработал и запрограммировал.
Заказчик должен предоставить ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ - забота разработчика. Они тоже являются результатом труда и должны вноситься в бюджет.
Ещё одно НО. Не бывает чётких функциональных и технических требований. Даже мать природа не гарантирует ожидаемый родителями результат, хотя имеет гораздо больший опыт в "производстве". По этой причине возникли гибкие методы разработки программного обеспечения. В них ТТ результат работы, а не основа. Основа - это изменяемые ФТ. В любом случае у заказчика должно быть одно лицо, отвечающее за взаимодействие с разработчиками и понимающее то, что должно появиться в результате разработки (в функциональном плане!).
Заказчик должен предоставить ФУНКЦИОНАЛЬНЫЕ ТРЕБОВАНИЯ. ТЕХНИЧЕСКИЕ ТРЕБОВАНИЯ - забота разработчика. Они тоже являются результатом труда и должны вноситься в бюджет.
Ещё одно НО. Не бывает чётких функциональных и технических требований. Даже мать природа не гарантирует ожидаемый родителями результат, хотя имеет гораздо больший опыт в "производстве". По этой причине возникли гибкие методы разработки программного обеспечения. В них ТТ результат работы, а не основа. Основа - это изменяемые ФТ. В любом случае у заказчика должно быть одно лицо, отвечающее за взаимодействие с разработчиками и понимающее то, что должно появиться в результате разработки (в функциональном плане!).
TutanXamoN
Новичок
jonjonson
после доставки каталога через 14 дней ставиться задача на звонок клиенту для выяснения не хочет ли он что-то.
Пусть заказчик не видит двух модулей.
Но если ТЗ пишем мы то мы оформляем ето как функциональные модули и связь между ними в любом случае должна быть прописана.
+
в данном случае не только связь но и варианты развития событий:
1. "я ещё посмотрю каталог" - отложить задачу
2. etc....
Позвольте возразить: есть два модуля (каталоги) (задачи)
после доставки каталога через 14 дней ставиться задача на звонок клиенту для выяснения не хочет ли он что-то.
Пусть заказчик не видит двух модулей.
Но если ТЗ пишем мы то мы оформляем ето как функциональные модули и связь между ними в любом случае должна быть прописана.
+
в данном случае не только связь но и варианты развития событий:
1. "я ещё посмотрю каталог" - отложить задачу
2. etc....
jonjonson
Охренеть
TutanXamoN, в том то и дело, что нет никаких модулей. Есть реализация. А решена она через два модуля или десять - это заказчику всё равно. Заказчика интересует, что бы к определённому моменту была реализована функциональность необходимая для поддержки его бизнес процессов.
Отчитываться перед заказчиком вы должны за функционал, а не за модули. Единственный случай, когда речь может идти о модулях, когда они сами являются реализацией функционала. Например, настройка рабочего места на основе модулей. При этом заказчика опять же интересует способ подключения\отключения модуля и функции, которые он реализует. В остальном - это чёрный ящик. Точно так же можно вести речь не о модулях, а плагинах, драйверах, юнитах и т.д.
Отчитываться перед заказчиком вы должны за функционал, а не за модули. Единственный случай, когда речь может идти о модулях, когда они сами являются реализацией функционала. Например, настройка рабочего места на основе модулей. При этом заказчика опять же интересует способ подключения\отключения модуля и функции, которые он реализует. В остальном - это чёрный ящик. Точно так же можно вести речь не о модулях, а плагинах, драйверах, юнитах и т.д.