Кто составляет ТЗ?
В организации есть аналитик. Он соглашается составить документ с описанием требований от заказчика. Но не хочет писать ТЗ для программиста.
Требования к ТЗ — составить таблицу, где будет описаны типы полей, формат ввода, видимость на этапах, тексты уведомлений и логику изменения данных по каким-то событиям. Аналитик хорошо знает возможности системы (речь о SharePoint).
Аналитик сообщает что составлять ТЗ должен программист. Я этот программист. И по-моему что-то пошло не так.
Отслеживать
Alexander Ulmaskulov
задан 15 сен 2015 в 14:59
Alexander Ulmaskulov Alexander Ulmaskulov
515 4 4 серебряных знака 16 16 бронзовых знаков
что написано у вас в должностных инструкциях, то вы и обязаны делать
15 сен 2015 в 15:00
Я понимаю, что Бизнес-аналитик собирает требования, а Системный аналитик адаптирует их для технического персонала. Верно ли отдавать роль Системной аналитики разработчику ПО? Организация, к слову, не маленькая. Т.е. не веб-студия из 5 человек, где совмещение ролей неизбежно.
Как пишется ТЗ по 1С? #crm #бизнес #автоматизация #1с
15 сен 2015 в 15:03
бывает и программиcту делегируют такую почётную обязанность. может просто поговорить с ПМ?
15 сен 2015 в 15:05
Так же добавлю, речь идёт о разработке внутри компании, в рамках одного юридического лица.
15 сен 2015 в 15:05
15 сен 2015 в 15:07
3 ответа 3
Сортировка: Сброс на вариант по умолчанию
ТЗ — это расшифровывается как техническое задание. То есть это задание от одного субъекта другому, от начальника — подчиненному, от заказчика — исполнителю и т.д. Программист — это звено в производственном процессе, который должен получить задание, прежде чем что-то делать. Если программист пишет сам себе задания, то это означает, что он исключен из производственного процесса, то есть не является участником производственного процесса, а является самостоятельной единицей внешней по отношению к производственному процессу.
Задача аналитика — проанализировать производственный процесс и на основе своего анализа выдать технические задания или рекомендации, если он сам не уполномочен выдавать технические задания, а, допустим, это делает другой уполномоченный сотрудник.
Описание требований от заказчика — это работа секретаря, а не аналитика.
Для аналитика требования заказчика — это всего лишь входные данные, на основе которых он должен выдать выходные данные, которыми являются технические задания. Грубо говоря работа аналитика заключается в следующем. Он должен указать: вот — что требует заказчик, и вот — что надо сделать.
А для программиста ТЗ — это входные данные, а программа — это выходные данные.
В противном случае программисту придется дублировать аналитика. А зачем тогда такой аналитик нужен?!
Фактически, в этом случае аналитик снимает с себя всякую ответственность за свою работу, так как если конечный продукт не будет устраивать заказчика, то аналитик просто скажет, что это вы написали неправильно ТЗ. То есть он полностью обрубил с вами обратную связь и тем самым, подымаясь по цепочке вверх от вас до заказчика, чтобы оценить результат работы и, например, оценить, что было сделано не так, как предполагалось, и на каком этапе, то в этом процессе распределения ответственности аналитик уже участвовать не будет.:)
Техническое Задание: Советы для успешного написания. #управлениепроектами #разработка #требования
Как происходит процесс верификации результата работы?
Если задания спускаются сверху вниз, то верификация результата производится снизу вверх.
Результат работы программиста — это программа. Ее правильность сверяется с техническим заданием.
Результат работы аналитика — это техническое задание. Его правильность сверяется с требованиями заказчика.
Ну, а если требования заказчика сами по себе не корректны или неадекватны, то заказчику никого кроме себя винить не придется.:)
Источник: ru.stackoverflow.com
Чья обязанность писать Техническое задание (ТЗ)?
Как вы считаете, или как это принято в вашей организации — кто должен писать ТЗ на разработку сайта?
Варианты:
1. Менеджер по работе с клиентами
2. Веб-дизайнер
3. Веб-разработчик
Если есть другие варианты, напишите пожалуйста.
- Вопрос задан более трёх лет назад
- 35431 просмотр
Комментировать
Решения вопроса 0
Ответы на вопрос 18
Менеджер проекта совместно с командой, т.к. он тоже один не может знать всех технических тонкостей.
Ответ написан более трёх лет назад
Нравится 4 2 комментария
За ТЗ должен отвечать менеджер. Он опрашивает клиента, заполняет вместе с ним анкеты/опросники если нужно и в конце выдает итоговый документ.
Если менеджер не может описать требования клиента в терминах ТЗ — то гнать такого менеджера за профнепригодность. Что он вообще собирается «менеджить», если не понимает о чем проект? Ему потом по этому ТЗ разруливать претензии и хотелки клиента. В конце концов разрабатывается не атомная электростанция. Технари должны привлекаться к процессу написания ТЗ только если предполагается что-то явно сложное и не факт что технически реализуемое за разумное время/деньги.
Да, в конце со стороны исполнителя ТЗ должен просмотреть технолог/старший разработчик/кто там еще. Во-первых на предмет технических ляпов, во-вторых на предмет внутренней оценки сложности реализации. Дизайнер при составлении ТЗ нужен опять же редко, ему из ТЗ требуются итоговые функциональные требования плюс фирменный стиль/брендбук если они есть.
Т.е. любой менеджер должен уметь с ходу описать в ТЗ архитектуру базы данных для портала с функциями соц. сети и рассчитать какую нагрузку смогут держать еще не созданные скрипты на таком-то железе?) И это не что-то запредельное для проектов за гигантские суммы, а совершенно рабочий момент при создании какого-нибудь клона Хабры.
Есть такая профессия — бизнес-аналист 🙂
Ответ написан более трёх лет назад
Нравится 4 1 комментарий
Поддержу. У нас в компании за ТЗ бизнес-аналитики отвечают. Это специальные люди, которые переводят с языка заказчика на язык разработчика 🙂
Слышал от товарища про такую практику: разработчик пишет ТЗ (причем не за бесплатно), а потом согласовывает с заказчиком. То есть заказчик только ставит свой автограф, если его все устраивает.
Ответ написан более трёх лет назад
Нравится 2 5 комментариев
Или так, разработчик (или тимлид) получает набор требований к ПО(scope), потом пишет ТЗ (не за бесплатно естественно) и утверждает/корректирует с заказчиком. Причем в процессе уточнения требований как правило и пишется ТЗ, итеративно.
тогда вопрос — сколько стоит написание ТЗ?
to zizop: Вы правы. Как правило заказчик формулирует функциональные требования, а тимлид пишет ТЗ.
to berik_iushi: мой товарищ выполнял гос. заказы. Я думаю что не стоит ориентаироваться на те деньги, которые вертятся там. К тому, признаться, я не знаю, сколько это стоит.
у нас так и делается, только за бесплатно, т.к. ТЗ пишем в большей части для себя.
разработчику же и так зарплату платят.
Если считать сайт — информационной системой то можно опираться на ГОСТ
По ГОСТу ТЗ разрабатывает исполнитель с участием заказчика на основании технических требований.
Однозначно — это не работа менеджера или дизайнера.
В идеале — специальный человек по работе с документацией, на практике — разработчик.
Ответ написан более трёх лет назад
Комментировать
Нравится 2 Комментировать
Согласен с densilvio и aquarius.
Техническое задание, по своей сути это документ описывающий разработчику что и как должно работать в готовой системе. По правильному под ТЗ должен отводиться отдельный этап в разработке.
Это достаточно объемная работа, которая должна отдельно оплачиваться, как дизайн, интеграция или кодинг.
Ведь хорошее ТЗ учитывает спицифику бизнес процессов заказчика, описывает все необходимые и возможные варианты поведения системы, в нем должны быть прописаны пользовательские интерфейсы.
В идеале ТЗ вообще должно создаваться третьей компанией, причем так, чтобы заказчик обратился к выбранному разработчику и у того не возникло вопросов.
Ну а на практике студии пишут ТЗ сами для себя. И как следствие это не полноценный документ, а так…
Ответ написан более трёх лет назад
Комментировать
Нравится 2 Комментировать
Я руководитель проектов (или же ПМ). Пишу ТЗ сам, изредка советуясь с программерами и дизайнерами, т.к. имею довольно большой опыт.
Вариант «ТЗ пишет сам заказчик» — не рекомендую. Потому что уточнения ПМом могут в итоге занять больше времени, чем написать ТЗ с нуля (ну, не совсем с нуля, используя некоторые накопленные заготовки).
Ответ написан более трёх лет назад
Нравится 2 1 комментарий
Некоторые заказчики хотят сами писать ТЗ, а некоторые, наоборот, просят писать исполнителя. Хотя согласен, зачастую лучше самому подготовить.
Простите, хотел плюсануть, но промазал. Плюс ушёл в карму.
В вашем случае вероятнее всего необходимо коллективно с участием клиента обсудить детали, услышать от него пожелания, а потом на основе этой информации написать ТЗ. Естественно, что написанием ТЗ должен заниматься человек, который грамотно и полно техническим языком способен изложить задачу на бумаге. Если это будет делать гуманитарий, будьте готовы с возможным претензиям со стороны клиента и переделкам проекта.
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Менеджер по работе с клиентами пишет обобщенно все то что хочет клиент, а потом Веб-дизайнер и Веб-разработчик описывают свою часть работы на техническом уровне для утверждения с клиентом. Можно обойтись одним Менеджером, если у него достаточно высокий опыт таких работ с пониманием дизайнерской и девелоперской работы…
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Если вопрос поставлен именно так, то на первом этапе менеджер совместно с заказчиком — черновой вариант. Далее веб-разработчик дополняет и согласовывается итеративно.
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Правильный вариант. ТЗ пишет заказчик, его читает менеджер и уточняет. Пото ТЗ читают разработчики (в Вашем случае, веб-дизайнер и веб-разработчик) и высказывают замечания (если есть). После этого менеджер согласует с заказчиком уточнённый вариант ТЗ. И так может пройти несколько итераций.
Приемлемый вариант (зачастую он удобнее). ТЗ пишет менеджер и согласует его со своими разработчиками, а уже после этого с заказчиком. И так может быть несколько итераций.
В любом случае ТЗ это документ заказчика, в нём также заинтересован разработчик. Третья организация к ТЗ никакого отношения иметь не может. Разве что в особых случаях, например, когда одна организация заказывает, а другая оплачивает.
Если менеджер не решает все финансовые вопосы, то ТЗ также должен проверять человек, который за это отвечает.
После подготовки и подписания нескольких ТЗ, новые обычно готовятся на базе старых.
Ответ написан более трёх лет назад
Нравится 1 2 комментария
ТЗ от заказчика — самые бестолковые
Не согласен. Разные бывают ТЗ от заказчика. Наверное, в веб-разработке так и есть, как Вы говорите, я с этим не сталкивался. А там, где я работаю, заказчики вполне себе нормальные ТЗ пишут.
ТЗ пишется бизнес-аналитиком, с учетом пожеланий будущих программистов. Разделы ТЗ согласовываются с заказчиком, чтобы пятисотстраничный талмуд не переписывать если заказчику не понравится итог.
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Исходя из приведенного списка людей то менеджер, т.к. именно он должен быть посредником между заказчиком и командой, т.к. ТЗ составляется на основе пожеланий клиента, а с клиентом общается именно менеджер то он и должен сделать ТЗ по которому остальные начнут работу.
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Чьи руки будут писать — не столь важно, хоть секретарь. Но отвечать за этот процесс должен, разумеется, менеджер. Иными словами, менеджер может написать сам, может делегировать, но это его задача
Ответ написан более трёх лет назад
Комментировать
Нравится 1 Комментировать
Смотря что подразумевать под ТЗ.
Обычно это постановка задачи (ЦА, структура, набор модулей, дополнительный функционал). Если речь идет про постановку задачи, то этим должен заниматься либо аналитик, либо проектировщик интерфейсов.
Техническое задание в классическом понимании (архитектура, интеграция, технологические решения и пр.) должен писать тех.специалист. Как правило либо архитектор, либо разработчик.
Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Создали для себя шаблон. Копию шаблона передаем менеджеру для заполнения совместно с заказчиком. На основании заполненного шаблона менеджером создается проект ТЗ с макетами будущего сайта, макеты создает веб-дизайнер. Этот проект согласовывается менеджером с заказчиком.
На основании проекта создается дизайнером и разработчиками «окончательное» ТЗ, которое становится неотъемлемой частью договора. Договор, вместе с ТЗ, подписывается заказчиком и далее, ТЗ передается на разработку.
Ответ написан более трёх лет назад
Комментировать
Нравится Комментировать
Бывают случаи когда ТЗ (окончательное) пишут сторонние организации, т.к:
— иногда заказчик не может (не понимает специфики или другие нюансы) усмотреть все технические детали
— иногда исполнитель не может до конца понять все аспекты проекта
— иногда заказчик, не зная исполнителя, не доверяет составление ТЗ исполнителю
разные бывают случаи
Ответ написан более трёх лет назад
Не хотелось бы работать по такому ТЗ, когда заказчик и исполнитель представляют что-то своё. При сдаче работы может быть ой как не хорошо.
Всё зависит от того, как вообще организован сам процесс производства ПО.
Если проект разовый и комманда маленькая, то кто напишет ТЗ — уже не важно. Главное, чтобы оно было вообще.
А если комманда большая, хорошо структурирована, и есть отдельный тим маркетологов (которые и с конкретным клиентом работают, и рынок мониторят), и проект имеет не один этап, то тут уже дело даже не в конкретном ТЗ. Обычно готовится Стратегия развития продукта — общий документ, описывающий цели и направления развития продукта на перспективу.
В рамках Стратегии для каждого конкретного этапа может готовится Детальное Описание Продукта — подробный документ с описанием готовящейся к выпуску версии продукта. Готовит его отдел маркетинга и он же его согласовывает с Заказчиком. И когда Описание продукта для данного этапа готово, то Developers Team Leader (DM) на его базе готовит ТЗ для своей комманды.
И это ТЗ уже могут Заказчику даже не показывать, т.к. это, по сути, внутренний документ. Если DM активно участвовал в подготовке Описания Продукта (а он обязан участовать, и его замечания обязаны быть учтены), то ТЗ уже меняться не будет в процессе разработки. И, к слову, при такой организации процесса Project Manager может нести только административные функци, и вообще не шарить в программировании.
Источник: qna.habr.com