Бизнес форум «Выгодное Дело»


Обсуждение работы бизнеса в сфере IT, связанной с разработкой/доработкой и сопровождением программного обеспечения (software).



Ответить
 
Опции темы
30.08.2016, 15:06   #1
Kotzebe
Журналист

 
Имя: Руслан
Пол: Мужской
Возраст: 34
Регистрация: 13.03.2015
Сообщений: 1,393
Благодарностей: 276
Вес репутации: 200

По умолчанию Как сделать правильное техническое задание длядоработки?

В этом материале мы разберем ключевые правила подготовки технических заданий, которые пишутся для доработки приобретенного или установленного ПО.


Если почитать статьи на англоязычных ресурсах, релевантные запросу «productrequirementsdocument», можно прийти к выводу, что техническое задание, оно же ТЗ или PRD, уже неактуально и не используется. Частично это правдивое мнение (работать над проектом с самого начала, делать прототипы очень интересно и эффективно, нежели перечитывать кучу документации от заказчика, причем зачастую составленную далеко не на профессиональном уровне). Но, если имеется в виду доработка имеющегося продукта, ситуация совсем иная. Поэтому далее мы разберем особенности составления этих ТЗ, которые подготавливаются для доработки уже имеющихся программных решений. Для многих это уже больная тема.

Грани взаимодействия

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


Требования – то, как система должна себя вести. Как это описал заказчик или холдер процесса. И это поведение должно быть реализовано. Обычно, в основе формирования требований лежит опыт работы, представления о том, как программа должна себя правильно вести. Это самые важные данные, которыми должен оперировать разработчик (вендор). Но, стадия сбора требований всегда связана с максимальным количеством несоответствий, неточностей, ошибок, лишних запросов и т. п. моментов.

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

Возможности – говоря простым языком, это то, что разработчик сможет действительно сделать, что в его силах.

В качестве примера рассмотрим «RegionSoft CRM». Заказчик приобретает систему и подготавливает ТЗ для ее доработки (необходимо интегрировать систему с веб-ресурсом и привязать происходящее в CRM к номеру заказа онлайн-магазина). Данное требование действительно можно выполнить, у разработчика присутствуют для этого ресурсы и возможности. Также необходимо разработать CMS и интегрировать ее с CRM.

В теории это реализуемое требование, на практике – отсутствует возможность выполнить задачу за небольшие деньги, а заказчик при этом не может заплатить ту сумму, чтобы вендор мог выделить необходимое время и людей. В результате клиент убирает данное требование (тем более особой потребности в CMS у него нет, и так все нормально работает). Тут возникает вопрос «жадности» технического задания, разберем его ниже.

Цитата:
Ограничение – все препятствия, вследствие которых сложно или невозможно реализовать предусмотренные техзаданием задачи(бюджет, технологический комплекс, проблемы с лицензированием, ограничения по закону, аппаратные конфигурации и т. д.).
Эти 4 аспекта тесно связны, от них зависит то, будет ли проект успешным. Разберем детальнее каждую составляющую и постараемся определить самые важные нюансы, о которых нельзя забывать при подготовке ТЗ.

Сбор и изучение требований

Важнейший процесс, реализация которого позволяет понять, чего потенциальные пользователи хотят от будущего ПО (в качестве примера в рамках всей статьи будем рассматривать CRM, однако, описанные методики подойдут и под другие программные решения). Если вы планируете сотрудничать с крупным разработчиком, таким как «SAP», либо системным интегратором, скорее всего,вам порекомендуют сначала обратиться к бизнес-консультанту (его еще называют менеджером по аккаунту, персональным менеджером или «вашим представителем в нашей компании»). В действительности, как правило, это типичный натренированный менеджер по продажам, от которого требуется 2 вещи: максимально завысить цену и удержать вас.


Единственные люди, лучше всего разбирающиеся в работе вашей компании - вы и ваша команда. Соответственно, только вы должны собирать и анализировать требования. Разработчик может помогать вам и направлять, однако, никогда не должен вмешиваться. Узнайте у вендора особенности подобных решений, выясните, какие нюансы следует учесть, и начинайте работу. Очень хорошую помощь может оказать ваш работник, хорошо знающий эту тему, примерно разбирающийся в софтверной архитектуре и представляющий, как происходит процесс разработки – его можно привлечь, как аналитика и эксперта от компании. Он может отвечать за сотрудничество с вендором и подготовку техзадания.

Требования можно собирать по простейшей схеме:
  1. Сформируйте рабочую группу, в которую войдут начальники и опытные работники отделов. Это должны быть люди, которые будут в дальнейшем работать с CRM. Объясните им особенности решения, которое нужно выбрать, дайте возможность воспользоваться демоверсией.
  2. Участники рабочей группы должны донести сведения до остальных работников и выяснить, какие у них есть пожелания к этому софту. Точности и терминологии здесь не надо, нужна простая свободная форма изложения. Если сотрудники ранее не работали с такими решениями и не могут рассуждать относительно будущего применения, следует попросить их детально описать их регулярные задачи, такая методика является универсальной.
  3. Каждый отдел определяет, что отсутствует в CRM или под какие моменты она не подходит и собирает информацию.
  4. Рабочая группа проводит анализ собранных требований, выполняет проверку, убирает пересечения. К примеру, порой маркетинговое и продающее подразделения просят реализовать создание одной и той же отчетной формы, но по-разному описывают поля и значения, когда в действительности это одинаковая информация. Значит необходимо привести эти требования к одному виду.
  5. Рабочая группа составляет перечень требований и устанавливает приоритеты. В рамках данной стадии можно пообщаться с разработчиком, поскольку ресурсы находятся в его ведении. К примеру, можно выбрать или создание пользовательского отчета в CRM, или интеграцию с сайтом. Эти задачи выполняются в абсолютно разные сроки, поэтому необходимо правильно установить приоритеты.

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

Анатомия ТЗ

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

  • Выявление – установление требований, проблем, для которых нужно найти решение.
  • Анализ – изучение требований, определение самых важных потребностей, выведение общих моментов.
  • Адаптация – оценивание потребностей относительно возможностей системы и имеющихся бизнес-процессов.
  • Документирование – детальное и формальное описание потребностей, согласование техзадания.
  • Взаимодействие с вендором – интерактивная работа с разработчиком относительно доработок, в соответствии с подготовленным ТЗ.
  • Реализация – разработчик создает нужный функционал. Хорошо, когда между вендором и клиентом постоянно поддерживается связь, благодаря этому конечный продукт всегда будет таким, как хочет клиент.
  • Тестирование – работники разработчика, внутренние специалисты клиента и конечные пользователи проверяют функционал, чтобы выяснить соответствует ли доработка ТЗ, и работоспособна ли измененная система.

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

Многоуровневые требования:

• Уровень бизнеса – наиболее широкий уровень, предполагающий решение самых тяжелых и важных вопросов. Сюда относятся доработки, внедрение и создание моделей бизнес-процессов, разработка новых модулей функций. Обычно, для такой разработки требуется много ресурсов, серьезные консультации и тесное сотрудничество с заказчиком. К примеру, велась доработка «RegionSoft CRM», подразумевающая создание складского учета, кассы и производства. С течением времени нововведения включались в релиз, а затем дали возможности реализовать новое решение для магазинов разного уровня (оптовых, розничных, гипермаркетов). Продукт получил название «RegionSoftRetail».

• Уровень пользователя (группы пользователей). В рамках данного уровня выполняются задачи, ориентированные на доработку уже имеющегося интерфейса.

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

Цитата:
К примеру, есть требования от разных подразделений(маркетингового, логистического и техподдержки).
• Уровень функционала. Порой он сливается с предыдущим и тяжело найти их границы. Тут имеет место формальный критерий – дорабатывается не интерфейс, а сама логика функционирования системы. В эту категорию входят требования по всевозможным сортировкам, функционалу телефонии, интеграциям с чатом.

• Уровень сервиса. В действительности, требования данного уровня должны в первую очередь вноситься в новые релизы с исправлениями. Тут присутствуют такие моменты, как быстрота работы системы, стабильность в условиях сильной нагрузки, вопросы безопасности. В идеале разработчик не должен иметь этих доработок – софт для предприятий должен быть быстрым, надежным, стабильным и безопасным. Однако, в случае появления требования, когда оно не относится к единичному случаю паранойи у клиента или к аппаратным проблемам, необходимо особенно тщательно над ним поработать.

• Уровень технологии. Завершающий уровень. Но самый важный и сложный. Сюда могут относиться требования заказчика, касающиеся платформы, ОС или девайсов. К примеру, запрос сборки для MacOS. Хорошо, когда со временем эти требования выльются в релизы, однако, обязательно должны быть их исправления. Так, именно такие запросы заказчиков привели к тому, что появилась версия «RegionSoft CMS» для MacOS. Также был внедрен удаленный доступ, базирующийся на технологии TRM в качестве временной замены мобильной версии. Последний запрос встречался хоть и редко, но имел место.

В анатомии ТЗ нет никаких сложностей, особенно в разрезе самого скелета. Обязательные составляющие ТЗ позволяют клиенту сконцентрироваться на проблеме и грамотно сформулировать задачу, а исполнителю – точно знать, что он должен сделать. Теперь вспомним бизнес-консультантов, которые упоминались вначале статьи. Конечно, называть их несуществующим классом было не совсем верно. Дело в том, что все крупные разработчики работают в отрасли не один год, а то и десяток лет. Таким образом, у них есть готовые комплекты кейсов под каждую сферу. И, естественно, сотрудники всех отделов вендоров уже понимают, как внедрять решение в компании определенного типа. Но, все-же, отталкиваться нужно, прежде всего, от собственного бизнеса.

Для кого?

Здесь нужно расписать, кто в конечном итоге будет пользоваться доработками, какие задачи, и как часто будут решаться.

Рассмотрим пример. В организации необходимо внедрить CRM, подразумевалась работа на достаточно немалом объеме информации (ежемесячно десятки миллионов записей, сотни тысяч записей ежедневно). Руководитель подразделения продаж потребовал отчет о выгрузке данных записей каждый день. Конечно же, из-за такого отчета, когда сразу работает 100 пользователей, система значительно нагружается (процесс был оптимизирован). Уже в процессе работы оказалось, что менеджер просто перестраховался, и на самом деле отчет нужен по месячным результатам, да и запускать его можно было в ночное время, настроив расписание.

Естественно, это была напрасная трата времени и денег.

Зачем?

Объяснение потребности в доработке, и какое место оно занимает в бизнес-процессе. Данный пункт необходим скорее для клиента, хотя хорошо, если вендор тоже понимает, какие процессы будут затрагиваться дополнительно. Порой, благодаря этому, удается прийти к лучшей альтернативе.

Что должно делать?

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

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


Идеально, когда в подготовке ТЗ активное участие принимает разработчик.

Структура правильного ТЗ должна быть приблизительно такой:
  1. Расписываются требования по всем функциям и составляющим.
  2. Расписывается реализация конкретной функции.
  3. Цена за каждую стадию.
  4. Совокупная цена, согласно этому ТЗ.
  5. Срок выполнения, включая разделение на стадии и очередность.
  6. Расписываются условия интеграции и проведения тестирования.
  7. Оговорки относительно исчерпанности требований данного ТЗ и прочие условия.

10 ключевых правил

1. ТЗ под доработку – это техническое задание под доработку

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

2. Не делайте жадное ТЗ

Порой бизнес слишком завышает собственные возможности и хочет получить все единовременно. Для финансового положения и бизнеса в целом это не принесет пользы. Разработчик, обычно, работает уже давно («RegionSoft» существует уже 15 лет), и через определенное время можно снова начать сотрудничество, когда вы точно осознаете, каких возможностей вам недостает.

Реальный пример лишнего функционала: клиент приобрел ERP у одного популярного российского вендора, полагая, что раз бухучет от этого разработчика работает отлично, то ERP продемонстрирует прекрасные результаты работы. Последняя под конкретный бизнес не подошла. Зато отлично подходит «RegionSoft CRM», имеющая модули складского учета и производства. Решение простое: выбросить ERP, наладить интеграцию «1C» с другой CRM и продолжать спокойно работать. Так, естественно, не поступают, поскольку жалко потраченных средств. И заказчик требует наладить интеграцию между CRM и ERP. Делать приходилось и более сложные задачи, однако, каков смысл, зачем совершать необоснованные затраты и делать два достаточно сложных инструмента?

3. 2 важных критерия ТЗ – реалистичность и выполняемость

Это касается и требований, и сроков. Тут стоит взять во внимание то, что говорит вендор, поскольку исключительно ему известно, в какой срок реализуется конкретная задача. Не думайте, что у разработчика есть какая-то выгода от затягивания сроков, он наоборот хочет сделать все быстрее, чтобы приступить к другим проектам и продолжить зарабатывать деньги. Причем, делать он будет качественно, поскольку репутация в этой отрасли очень важна. Реалистичность подразумевает, что не нужно делать из CRM систему управления коллайдерной установкой. Тут решение простое: необходимо предусматривать лишь те требования, которые нужны именно сейчас и в планируемом будущем.

Цитата:
К примеру, «RegionSoft CRM» является десктопным приложением, в браузерах работать не может. Требование по разработке веб-приложения для 1 организации не имеет смысла, это большой проект, а не доработка для конкретного заказчика. Естественно, все обладает собственной стоимостью, но все же это невыполнимое требование.
Не стоит путать с разработкой на заказ, когда производится полное изменение логики функционирования ПО, по сути, разрабатывается новое решение для конкретного клиента. Но, это уже не доработка, а новая разработка.

4. Подробность ТЗ

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

Цитата:
В обязательном порядке уточните форматы чисел, наименование полей, наличие/отсутствие выпадающих списков, как должны себя вести кнопки, типы данных и т. д.
Если клиент пользуется своими формулами, которые должны быть внедрены в логику функционирования CRM (к примеру, подсчет бонусов для дилеров), то их необходимо расписать, расшифровать каждое обозначение и логику подсчетов.


5. Однозначность и точность

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


6. ТЗ нужно писать на человеческом языке

Очень важное требование.

Рассмотрим 2 случая, когда вследствие языковых недостатков сроки выполнения проекта значительно затягиваются:
  • Заказчик хочет показать насколько он технически грамотный и пишет такого рода конструкции: «имплементировать окно с хинтом в тело календаря с функцией реагирования на колл события…». А нужно было написать так: «в календаре должно появляться окно, где задачи можно помечать, как реализованные». Если вы или эксперт компании не умеете писать технические тексты, то и не нужно этого делать, напишите простыми словами, разработчики тоже люди и легко их поймут.
  • В ТЗ чрезмерно много грамматических и других ошибок. Мало убрать расплывчатые описания и метафоры («Чтобы компьютер не издавал страшный писк, будто пришла судорожная смерть»), ненужных слов, а также слов-паразитов. Проследите за пунктуацией (порой, вследствие допущенных ошибок, меняется смысл потребности). ТЗ является документом, поэтому в нем необходимо применять подходящую лексику, он должен быть написан почти абсолютно грамотным языком.

Не пользуйтесь ПО вроде «MicrosoftVisio» и «UML-диаграммы», не умея правильно с ними работать. Возможно, в ваших глазах – это деловой красивый стиль, однако,вендор воспримет это, как сплошную путаницу. При необходимости вставить схему или изображение, воспользуйтесь для этого нормальными инструментами, не стоит делать лишнюю работу, пользы вендору это не принесет.

7. Не делайте из ТЗ жалобную книгу

Необходимо решить проблему, а не расписывать ее негативное влияние и вызываемые ею ночные кошмары. Описывайте имеющиеся требования. В техзадании следует указать лишь суть проблемы, методику ее решения на уровне осмысления, а вендор разберется с поиском решения на уровне кода. Для сравнения: «у подразделения продаж не получается хорошо планировать, теряются числа, больше года не можем побороть» и «нужно сделать отчет, сохраняющий значения плана и реальных продаж за месяц, в контексте групп товарного ассортимента».

8. ТЗ необходимо создавать с заделом на будущее

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

9. Не составляйте бюрократическое ТЗ

Не надо воды, строгих оборотов. Вы составляете не УК РФ (тем более с санкциями). Не пишите в ТЗ санкции за невыполнение определенной стадии или задачи. Есть заключенный с вендором договор, где прописаны все эти моменты, в том числе и бюджет.

10. ТЗ – это техзадание

Порой заказчики составляют не ТЗ, а некое подобие писем, жалоб или договоров. Некоторые переписывают своими словами инструкцию к продукту. Естественно, этот документ не дает возможности выполнить работу. Расписывайте задачи, которые должно выполнять необходимое вам доработанное ПО. Не нужны никакие рекомендации, подсказки и т. п., просто требования, четкие, понятные и детальные. Техническое – от слова «техника», в данном случае применяется с целью решения задачи через доработку программного обеспечения.

Что еще важно для успешности проекта?

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

Дополнительные моменты:
  • Пишите ТЗ быстро. Хоть и предстоит автоматизировать процессы огромной компании, к примеру, крупнейшей сети гипермаркетов или оператора мобильный связи. Не имеется в виду полчаса, а разумные сроки. Технологии изменяются очень быстро. Спустя полгода в текущей системе может быть масса изменений, и придется все дорабатывать заново.


Заказчику неизвестны технологические комплексы и технические ограничения. И ему не нужно разбираться в них, для этого существует разработчик. Клиенту не нужно лезть в технологические дебри. Составляйте правильное ТЗ, а с архитектурой разберется вендор.
  • Оценка бюджета. Важнейшая задача, позволяющая избежать многих проблем. Не требуйте от разработчика дать примерную оценку. Только готовое ТЗ после детального изучения и утверждения позволяет оценить бюджет. Если ваш вендор работает по другой схеме (дает оценку на глаз заранее), то будьте готовы к крупным доплатам.

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

Вопрос ТЗ очень широкий, есть даже ГОСТы (советские) и стандарты IEEE, следуя которым документ вовсе получится бесчеловечным.

Поэтому запомните важнейшее правило: ТЗ – это не правовая норма, не стандартизированный параметр, не догма, поэтому имея возможность улучшить - сделайте это, получится упростить – упростите. Есть возможность сделать все красиво – можно и так. Главное, чтобы все было правильно, и соответствовало вышеописанным рекомендациям. Соблюдая все эти правила, вы сможете сделать идеальное ТЗ, которое поймет любой разработчик, и не будет потом тыкать вас в него и доказывать, что там отсутствует момент, реализации которого вы сейчас требуете.
Миниатюры
Нажмите на изображение для увеличения
Название: 33c757d1a4124e984f60a568fa7c1350.jpg
Просмотров: 133
Размер:	33.3 Кб
ID:	4798   Нажмите на изображение для увеличения
Название: 0be65ed499fb3138f501c5165dc5198c.jpg
Просмотров: 149
Размер:	157.3 Кб
ID:	4799   Нажмите на изображение для увеличения
Название: 6b8e34b8e9df3ba41459addf11a28ef4.jpg
Просмотров: 142
Размер:	22.1 Кб
ID:	4800   Нажмите на изображение для увеличения
Название: f410429cbf0f5b6d96fd7e3410c7d5b1.png
Просмотров: 150
Размер:	84.6 Кб
ID:	4801   Нажмите на изображение для увеличения
Название: eeef20e0e337e19ddad411ddb5e342cd.png
Просмотров: 135
Размер:	41.6 Кб
ID:	4802   Нажмите на изображение для увеличения
Название: 9efad4f32d505abb54b72ff24fd4b18b.jpg
Просмотров: 132
Размер:	33.5 Кб
ID:	4803   Нажмите на изображение для увеличения
Название: 45ec161b7e4234e6d6a2f5f6dcd75371.png
Просмотров: 140
Размер:	29.7 Кб
ID:	4804   Нажмите на изображение для увеличения
Название: c8a3fc1a68822d57904c5a16cd8b6234.jpg
Просмотров: 153
Размер:	208.8 Кб
ID:	4805  




30.08.2016, 15:06
Выгодное дело
Бизнес форум
По умолчанию Как сделать правильное техническое задание длядоработки?

26.06.2017, 07:52   #2
Ольга П
Новичок
 
Аватар для Ольга П
 
Имя: Ольга
Пол: Женский
Адрес: Томск
Регистрация: 26.06.2017
Сообщений: 2
Благодарностей: 0
Вес репутации: 0

По умолчанию Re: Как сделать правильное техническое задание длядоработки?

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

Социальные закладки


Здесь присутствуют: 1 (пользователей: 0 , гостей: 1)
 
Опции темы

Ваши права в разделе
Вы не можете создавать новые темы
Вы не можете отвечать в темах
Вы не можете прикреплять вложения
Вы не можете редактировать свои сообщения

BB коды Вкл.
Смайлы Вкл.
[IMG] код Вкл.
HTML код Выкл.

Быстрый переход

Похожие темы
Тема Автор Раздел Ответов Последнее сообщение
Что такое правильное решение и как его принять Kotzebe Бизнес-форум для начинающих 16 29.12.2016 21:15


Последние темы
» 18.12.2017, 09:35
0 Ответов
» 18.12.2017, 00:44
0 Ответов
» 17.12.2017, 20:50
0 Ответов
           
Последние ответы
Опрос

Пригодилось ли Вам высшее образование?
Да, работаю по профессии - 16.77%
26 Голосов
Да, хоть работаю в другой сфере - 23.87%
37 Голосов
В результате открыл свой бизнес - 6.45%
10 Голосов
Изредка помогало - 15.48%
24 Голосов
Совершенно не пригодилось - 18.71%
29 Голосов
Учеба - потерянное время - 8.39%
13 Голосов
Другое - 10.32%
16 Голосов
Всего голосов: 155
Вы ещё не голосовали в этом опросе.
Рекламный 240*400
Популярные статьи
» 22.01.2017, 01:15
» 18.01.2017, 21:31
» 08.01.2017, 15:18
Яндекс.Метрика
Текущее время: 11:12. Часовой пояс GMT +4.