Техзадание как написать: Как составить ТЗ: подробная инструкция по созданию технического задания | Дропшиппинг

Содержание

Стандарты и шаблоны для ТЗ на разработку ПО / Хабр

Введение

Недавно ко мне обратились, чтобы я посоветовал стандарты для написания технического задания (ТЗ) на разработку автоматизированных систем (АС) и программного обеспечения (ПО). Вот думаю, сейчас зайду в Яндекс, найду подходящую статейку и отправлю её. Но не тут-то было! Одной статьи, где перечисляются стандарты для ТЗ, включая шаблоны и примеры готовых документов, я не нашел. Придется сделать такую статейку самому…

И так, основные стандарты, методологии и своды знаний, где упоминается ТЗ или SRS (Software (or System) Requirements Specification):

• ГОСТ 34
• ГОСТ 19
• IEEE STD 830-1998
• ISO/IEC/ IEEE 29148-2011
• RUP
• SWEBOK, BABOK и пр.

ГОСТ 34

ГОСТ 34.602-89 Техническое задание на создание автоматизированной системы регламентирует структуру ТЗ на создание именно СИСТЕМЫ, в которую входят ПО, аппаратное обеспечение, люди, которые работают с ПО, и автоматизируемые процессы.

Согласно ГОСТ 34 техническое задание должно включать следующие разделы:

1. Общие сведения
2. Назначение и цели создания (развития) системы
3. Характеристика объектов автоматизации
4. Требования к системе
5. Состав и содержание работ по созданию системы
6. Порядок контроля и приемки системы
7. Требования к составу и содержанию работ по подготовке объекта автоматизации к вводу системы в действие
8. Требования к документированию
9. Источники разработки

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

ГОСТ 19

“ГОСТ 19.ххх Единая система программной документации (ЕСПД)” — это комплекс государственных стандартов, устанавливающих взаимоувязанные правила разработки, оформления и обращения программ (или ПО) и программной документации. Т.е. этот стандарт относится к разработке именно ПО.
Согласно ГОСТ 19.201-78 Техническое задание, требования к содержанию и оформлению техническое задание должно включать следующие разделы:

1. Введение;
2. Основания для разработки;
3. Назначение разработки;
4. Требования к программе или программному изделию;
5. Требования к программной документации;
6. Технико-экономические показатели;
7. Стадии и этапы разработки;
8. Порядок контроля и приемки;
9. Приложения.

Естественно ГОСТ 34 (и 19) уже устарели, и я не люблю их использовать, но при правильном интерпретации стандартов, можно получить хорошее ТЗ, см. Заключение.

IEEE STD 830-1998

Достаточно хорошее определение стандарта 830-1998 — IEEE Recommended Practice for Software Requirements Specifications дано в самом его описании:

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

Согласно стандарту техническое задание должно включать следующие разделы:

1. Введение

1. Назначение
2. Область действия
3. Определения, акронимы и сокращения
4. Ссылки
5. Краткий обзор

2. Общее описание

1. Взаимодействие продукта (с другими продуктами и компонентами)
2. Функции продукта (краткое описание)
3. Характеристики пользователя
4. Ограничения
5. Допущения и зависимости

3. Детальные требования (могут быть организованы по разному, н-р, так)

1. Требования к внешним интерфейсам
- 1. Интерфейсы пользователя
- 2. Интерфейсы аппаратного обеспечения
- 3. Интерфейсы программного обеспечения
- 4. Интерфейсы взаимодействия
2. Функциональные требования
3. Требования к производительности
4. Проектные ограничения (и ссылки на стандарты)
5. Нефункциональные требования (надежность, доступность, безопасность и пр.)
6. Другие требования

4. Приложения
5. Алфавитный указатель

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

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

ISO/IEC/ IEEE 29148-2011

Стандарт IEEE 29148-2011 обеспечивает единую трактовку процессов и продуктов, используемых при разработке требований на протяжении всего жизненного цикла систем и программного обеспечения. Он приходит на смену стандартов IEEE 830-1998, IEEE 1233-1998, IEEE 1362-1998.

Данный стандарт содержит два шаблона спецификации требований:

• System requirements specification (SyRS)
• Software requirements specification (SRS)

System Requirements Specification (SyRS) определяет технические требования для выбранной системы и удобства взаимодействия предполагаемой системы и человека. Она определяет высокоуровневые требования к системе с точки зрения предметной области, а также информацию об общей цели системы, ее целевой среде и ограничениях, допущениях и нефункциональных требованиях. Она может включать в себя концептуальные модели, спроектированные для иллюстрации содержания системы, сценариев использования, основных сущностей предметной области, данных, информаций и рабочих процессов. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 34.

SyRS может содержать следующие разделы:

1. Введение

1. Назначение системы
2. Содержание системы (границы системы)
3. Обзор системы
- 1. Содержание системы
- 2. Функции системы
- 3. Характеристики пользователей
4. Термины и определения

2. Ссылки

3. Системные требования

1. Функциональные требования
2. Требования к юзабилити
3. Требования к производительности
4. Интерфейс (взаимодействие) системы
5. Операции системы
6. Состояния системы
7. Физические характеристики
8. Условия окружения
9. Требования к безопасности
10. Управление информацией

11. Политики и правила
12. Требования к обслуживанию системы на протяжении ее жизненного цикла
13. Требования к упаковке, погрузке-разгрузки, доставке и транспортировке

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

5. Приложения

1. Предположения и зависимости
2. Аббревиатуры и сокращений

SRS это спецификация требований для определенного программного изделия, программы или набора программ (продукт), которые выполняют определенные функции в конкретном окружении. Из определения следует, что это аналог ТЗ, описанного в ГОСТ 19, а по структуре очень напоминает SRS из стандарта IEEE 830.

SRS может содержать следующие разделы:

1. Введение

1. Назначение
2. Содержание (границы)
- 3. Обзор продукта
- 1. Взаимодействие продукта (с другими продуктами и компонентами)
- 2. Функции продукта (краткое описание)
- 3. Характеристики пользователей
- 4. Ограничения
4. Термины и определения

2. Ссылки

3. Детальные требования

1. Требования к внешним интерфейсам
2. Функции продукта
3. Требования к юзабилити
4. Требования к производительности
5. Требования к логической структуре БД
6. Ограничения проектирования
7. Системные свойства ПО
8. Дополнительные требования

4. Тестирование и проверка (список необходимых приемочных тестов, которые отражают зеркально раздел 3)

5. Приложения

1. Предположения и зависимости
2. Аббревиатуры и сокращений

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

RUP

Структура SRS в RUP(Rational Unified Process) представляет собой документ, в котором необходимо описать артефакты, полученные в процессе специфицирования требований.

Шаблон SRS в RUP адаптирован из стандарта IEEE STD 830 и содержит два варианта:

• Традиционный шаблон SRS со структурированными функциональными требованиями по функциям Системы, максимально похож на 830 стандарт.
• Упрощенный шаблон SRS со структурированными функциональными требованиями в виде вариантов использования (use cases):

1. Введение.

1. Цель.
2. Краткая сводка возможностей.
3. Определения, акронимы и сокращения.
4. Ссылки.
5. Краткое содержание.

2. Обзор системы

1. Обзор вариантов использований.
2. Предположения и зависимости.

3. Детальные требований

1. Описание вариантов использования.
2. Дополнительные требования.

3. Другие функциональные требования.
4. Нефункциональные требования.

4. Вспомогательная информация.

Естественно, что в Интернете можно найти шаблон и примеры SRS от RUP.

SWEBOK, BABOK и пр.

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

Также стоит сказать, что для описания требований к АС и ПО используются и другие виды документов, кот каждый называет по разному: FRD (Functional Requirements Document), RD (Requirements Document), ПЗ (Постановка задачи или Пояснительная записка) и пр. Но это все производные документы от вышеупомянутых стандартов, не имеющих отраслевой стандартизации, хотя, в некоторых случаях, уже и с устоявшейся терминологией.

А как же Agile?

Я скажу одной фразой из Манифеста Agile: “Working software over comprehensive documentation”. Поэтому в Agile документации отводится совсем мало места.

Мое же убеждение, что разработать АС без ТЗ можно (используя техники/рекомендации Agile), но вот в дальнейшем сопровождать — невозможно. Поэтому сразу задумайтесь, как вы будете писать ТЗ и другую документацию, при разработке ПО по Agile.

Заключение

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

Но главное, чтобы ТЗ не превращалось в ХЗ, а, именно, содержание (наполнение) в ТЗ — самое главное! Но это уже совсем другая история… Если есть интерес, то можно пройти он-лайн курс Разработка и управление требованиями к ПО.

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

Также рекомендую ознакомиться со следующими материалами:

Правила технического задания / Хабр

В большинстве крупных организаций внутрифирменные отношения «пользователь-отдел IT» неизбежны, особенно при создании рабочих приложений, необходимых пользователю на постоянной основе. Сложность этих отношений может быть обусловлена многими факторами, но чаще всего это непонимание, возникающее из-за того, что стороны говорят на разных «языках» с различной терминологией. Пользователь понимает, что он хочет, но не может это сформулировать, IT-специалист понимает пользователя, но опасается, что результат выйдет иным, чем видит это первый. Чаще всего проблема начинается с того, что именно пользователь не готов к диалогу: он требует «чтобы работало», «отчет одной кнопкой», «чтобы за минуту выводилось», «чтобы даты в Excel не вылезали» и прочее. При этом его совершенно не интересует, каким образом это делается и какие механизмы работают. На заявления о нагрузке на сервер, просьбы нарисовать схему желаемого результата, обсудить пути решения пользователь не реагирует, полагая, что настоящий профессионал со всем справится. Результаты такого непонимания вредят всему производственному процессу: затягиваются сроки решения задач, возникают ошибки и пробелы в системах, которые нужны пользователю, страдает перегруженный неверными действиями сервер, скорость работы снижается.

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

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

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

3. Следует понять, какие параметры следует задавать на входе, какова периодичность работы с желаемой программой (отчетом, приложением, утилитой), сколько данных примерно будет получаться на выходе и все ли они нужны (к примеру, если вам нужна сумма выручки от продаж пяти категорий изделий по категориям без наименований, не стоит требовать создания отчета в миллион строк с указанием каждой продажи с детальными характеристиками). Далеко не каждому специалисту необходима максимально детализированная информация, обработка которой создает значительную нагрузку для вычислительных систем.

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

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

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

7. Передать задание в работу за разумный срок до окончательной реализации, чтобы была возможность протестировать результат и исправить возможные ошибки.

8. Если ваши подчиненные также будут пользоваться созданным приложением, постарайтесь им самостоятельно объяснить особенности работы с приложением – это избавит IT-специалиста от необходимости сто раз объяснять одно и то же.

9. Помните, что ваше задание будет служить справочником для вас — в нем всегда можно посмотреть описание информации, вспомнить забытое требование.

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

Так что же такое «Техническое Задание»? / Хабр

Данный текст был создан сугубо ради существования постоянной ссылки, которую бы сам автор, да и все вы — могли бы смело отправлять своим будущим заказчикам, коллегам, родственникам и знакомым в виде стандартизированного ответа на вопрос: «А надо ли мне ваше ТЗ и вообще что это?»

Как говорится — «вместо тысячи слов», поскольку каждый раз евангелистить по 4-5 часов в скайпе на данную тему становится уже утомительным, а общемировая тенденция подсовывать под определение «Технического задания» откровенную ерунду с годами все только усиливается.

Проблема

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

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

Переводим на понятный язык

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

2) Собственно из первого пункта логично вытекает и новый — сам текст ТЗ обязан начинаться с главы «Цели и задачи», четко формулирующей, какие бизнес-цели преследует вся эта очередная попытка повысить энтропию в мире. Бесцельное задание, которое не решает никаких проблем, не достигает ничего и делается «от скуки» — официально не считается Техническим Заданием, а с этого момента находится в статусе «обычная бумажка».

3) Как же вам понять, решает ли предложенная дизайн-концепция или интерактивный прототип, а то и готовый к употреблению сайт — вышеизложенную задачу бизнеса? Ничего не поделаешь, придется опять вернуться к определению: «определяет… ожидаемые результаты и сроки выполнения. То есть должны быть объективные критерии, по которым можно определить, сделан ли тот или иной пункт работ или нет». То есть ТЗ без четких измеримых показателей в рублях, секундах, тонно-километрах или градусах Цельсия — быть не может. Бриф может, или прототип, или еще любая абсурдная бумажка, но только не ТехЗадание.

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

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

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

5) Каждое внесение правок в готовое ТЗ должно стоить денег. Нельзя бесплатно и бесконечно править «Конституцию вашего проекта» только потому, что одна из сторон передумала, не выспалась, внезапно решила сэкономить и т.д. Цена каждого изменения в ТЗ должна также четко прописываться заранее в соответствующей главе.

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

Стоит ли упоминать, что в ТЗ просто необходимо заранее указывать сроки и общий бюджет на разработку, а также список всех существующих ресурсов и ограничений? — Нет, это будет уж слишком очевидно.

Итак: Что делаем? Для чего? Как поймем, что сделали? Сколько стоит каждый пивот? — написанные на листочке ответы на все эти вопросы и являются «серебряной пулей», способной вытащить даже самый провальный проект.

Контрольные вопросы

А здесь перечислю ответы на самые часто встречающие вопросы от заказчиков:

1) Так что, на написание ТехЗадания может еще и официальный ГОСТ есть? — Да, даже несколько.

2) А что, в ТехЗадание не входит описание нужных страниц, количества кнопок, используемых библиотек, гайдлайнов и т.д.? — В само ТЗ нет, но в Приложения вы можете все это поместить, разумеется скорректировав все это с вышеописанными целями, ограничениями и способами дальнейшей оценки достигнутого результата. Размещайте хоть весь будущий контент, хоть описание типовых персонажей — но не вместо четкой постановки задачи, а уже после нее.

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

4) Вот вы и Википедия пишете, что ТЗ создается заказчиком. Но я не умею\мне некогда\просто не хочу его делать сам. Как же быть? — Отдать разработку ТЗ третьей стороне, вполне знакомой с вашим бизнесом, его задачами, целевой аудиторией и потребностями, и в то же время досконально осведомленной о всех этапах веб-разработки. Эта третья сторона станет неким «веб-нотариусом», то есть гарантом того, что исполнитель не занизит нужные вам показатели или не затянет сроки, и что заказчик установит достижимые метрики и на итоговой приемке не будет субъективно оценивать созданный продукт, на ходу изменяя зафиксированные ранее требования.

5) И что, если ТЗ является юридическим документом, то я потом могу засудить аутсорсера, не заплатить ему, заставить переделать все в десятый раз? — Если документ составлен правильно, указаны цели и методология оценки их достижения; если документ подписан сторонами и упомянут в Договоре (само ТехЗадание договором не является) — то конечно же сможете. А вот с обычным брифом, прототипами, арт-креатив-макетом, Безопасной сделкой на FL — уже нет.

6) Мне говорят, что работа будет вестись по какому то то ли скраму, то ли аджайлу; а значит архаичное ТЗ мне больше уже не нужно. Это так? — Посудите сами: вам называют непонятное слово, явно что-то маскирующее и вот уже на основании незнакомого вам термина предлагают отказаться от юридически грамотного и наполненного целями и метриками документа. Сам же agile никаких целей вроде «достичь не менее 10 000 посещений к концу года», или «достичь цифры более 25 заказов с сайта через месяц» — установить не может, это просто способ проведения совещаний и новой организации нерадивых сотрудников. Задумайтесь несколько раз: «А не пускают ли вам пыль в глаза?». На самом деле никакому новомодному скраму профессиональное ТЗ повредить не может, а вот помочь — обязательно.

Как сделать простое техническое задание и не потерять деньги и нервы / ХабрПривет, Хабр! Адресую эту статью себе более молодому и неопытному, а также всем, кто чувствует неуверенность в подходе к технической документации. Хотя если кому-то из зубров проектного дела она поможет, буду рад вдвойне.

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

Что было раньше

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

На многих проектах это выливалось в следующие проблемы:

Описан внешний вид, но не принцип работы. Простой пример с корзиной интернет-магазина. В ТЗ было написано “Кнопка “Оформить заказ”. Но что должно произойти, когда пользователь нажал на эту кнопку? По каким правилам формируется номер заказа? Какой статус ему присваивается? Куда идет переадресация? А если один из товаров раскупили, пока пользователь оформлял заказ? На эти и многие другие вопросы в ТЗ ответов не было, а ведь это лишь один небольшой элемент. Подобные неописанные моменты приводили к спорам с Заказчиком, сильному выходу из бюджета и прочим неприятным последствиям.
Отсутствие переиспользуемых блоков. На многих сайтах есть одинаковые блоки, используемые в разных местах, например, превью товара. Но данный блок в результате описывался в каждой странице. Это очень плохо по нескольким причинам. Во-первых, при необходимости изменения надо вносить сразу в нескольких местах, можно что-то упустить и будет несоответствие. Во-вторых, даже при одинаковых элементах в превью, заказчик может потребовать сделать их по-разному, что влечет за собой дополнительные затраты.
ТЗ не коррелирует с задачами для команды. Чем дальше постановка задачи от реальности, тем ниже будет качество на выходе. Это еще одна проблема, которую хотелось решить.

Новый подход

Определившись с целями, мы разработали новую, довольно простую, но эффективную концепцию.

ТЗ состоит из следующих разделов:

Введение
Статика
Динамика
Задачи
Административная панель
Общие технические требования

От проекта к проекту состав этих разделов может меняться, но основная структура остается. Давайте разберем подробнее.

Введение и подготовка к реализации

Кратко описываем проект, его цели, ЦА, оставляем ссылки на предпроектную аналитику.
Описываем процесс инициализации проекта: настройку окружения для разработчиков и подход к разработке концепции дизайна для дизайнеров.
Принципы адаптивности или разбиения на версии. Последнее время в своей работе мы придерживаемся следующего принципа — “адаптивь все, что адаптивится”. Иначе говоря, в начале работы над ТЗ мы понимаем, какой сложный функционал нам нужен (или может понадобиться в ближайшем будущем) и вместе с дизайнером и front-end разработчиком придумываем способы его заадаптивить. При новом подходе отрицательных результатов еще не было, поэтому отдельные версии описывать не приходилось.

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

Статика

Как мы все знаем, страницы могут содержать либо статическую информацию, либо динамическую, присылаемую с сервера. Подразделы статики — страницы проекта. Каждую страницу мы разбиваем на блоки. Если блок статический, то мы описываем его суть и вид контента. Например, описание одного из блоков страницы “О компании” может выглядеть так. “Основные преимущества компании. 5-6 иконок с описаниями.” Это очень краткое, но достаточное для точной оценки описание блока. При описании статики главная цель — задать четкие рамки. Сделать адаптив иконок не составит труда, а с графиком или таблицей все не так просто и однозначно. Но при этом нам не важно какие именно будут иконки и подписи к ним.

Если же страница содержит блок, который можно “вынести за скобки”, то в месте его интеграции мы пишем “Интегрируется функционал “NAME”, а сам функционал описываем в разделе “Динамика”.

Помимо страниц Статика включает в себя описание pop-up и письма. На мой взгляд их нет смысла выносить в отдельный большой раздел и раздувать структуру.

Динамика

Все, что относится к динамике мы называем функционалом. Возможно, позже появится еще какое-то разделение, т.к. уже сейчас сюда относятся различные типы задач:

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

Задачи

Этот раздел используется для работ, которые нельзя отнести ни к одному из других разделов: нарисовать баннер, установить счетчик метрики, спарсить товары и т.д.

Административная панель

Здесь описываем структуру, модели и поля. Разбиение идет по разделам, например, “Товары”, “Каталог”, “Заказы” и т.д. Описываем что разные роли пользователей могут просматривать, что редактировать.

Общие технические требования

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

SEO-требования к тегам и микроразметке
Правила транслитерации
Ручное и автоматическое тестирование
Поддерживаемые браузеры
…

Новые версии

При описании новых версий необходимо вносить изменения в существующие элементы. Мы рассматривали следующие способы описания доработок: в начале каждого из разделов (Статика, Динамика, АП) писать “Доработка функционала “NAME”, либо сделать отдельный раздел “Доработки”, в котором в кучу будут свалены сразу все изменяющиеся задачи. Пока остановились на втором варианте, но это связано скорее удобством на конкретных проектах. В других условиях лучше подойдет первый способ.

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

Пример

Давайте для наглядности разберем структуру ТЗ на основе упрощенной страницы раздела каталога.

Статика

Страница “Раздел каталога”

Используется для отображения товаров, принадлежащих к разделу каталога любого уровня, кроме корневого.

Интегрируется следующий функционал:

“Хлебные крошки”
“Дерево каталога”
“Фильтрация. Общие положения”
“Фильтрация. Текст”
“Фильтрация. Текст и изображение”
“Фильтрация. Диапазон”
“Сортировка. По умолчанию”
“Сортировка. По возрастанию цены“
“Сортировка. По убыванию цены”
“Превью товара. Плитка”
“Пагинация. Постраничная”
“Текстовый блок”. Интегрируется в виде блока для SEO-текста перед подвалом сайта

URL: /c/1745-name, где 1745- id текущей категории каталога, а name — транслитерированное название этой категории.

Динамика

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

Функционал “Фильтрация. Общие положения”

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

выпадающий список закрывается, а фильтр применяется. В текущем разделе остаются только товары, соответствующие текущим активным фильтрам
название кнопки фильтра приобретает вид: “Название фильтра: K”, где K — количество выбранных значений фильтра, если их 2 или больше, или “Название фильтра: значение”, если было выбрано одно значение.
цвет кнопки фильтра меняется на вид используемого фильтра
в значениях других фильтров остаются только варианты, удовлетворяющие текущим активным фильтрам. Если в одном из неактивных фильтров остается одно значение, его кнопка приобретает вид неактивной, а название выводится в формате “Название фильтра: значение”
у всех активных фильтров после названия добавляется крестик, при клике на который сбрасывается только этот фильтр
пагинация сбрасывается

Если хотя бы один фильтр активен, после всех кнопок с фильтрами появляется кнопка “сбросить фильтры”, при клике на которую значению всех фильтров сбрасываются.

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

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

Выбранные фильтры добавляются в URL посредством query-параметров.

Функционал “Превью товара. Плитка”

Представляет собой плитку (прямоугольник) с самой важной для пользователя информацией о товаре. В варианте плиткой ключевой информацией является изображение товара. Превью содержит:

Цена (целое число в рублях РФ)
Название товара
Метка “В магазине” или “С витрины”
Изображение
Размер
Кнопка “В корзину” (Интеграция функционала “Добавить в корзину”)
Кнопка “В избранное” (Интеграция функционала “Добавить в избранное”)

При клике на любую область превью, кроме кнопки “В корзину” осуществляется переход на страницу товара.

На одной строке должно помещаться 3-4 плитки с превью товара.

Как вы видите, в данный функционал интегрируется другой, что позволяет делать очень удобные разбиения. Например, “Добавить в корзину” и “Добавить в избранное” используются и в карте товара.

Административная панель

Одна страница требует большого количества разделов АП, опишу один из них.

Товар

Список всех товаров с фильтрацией. При редактировании/добавлении товара доступны следующие поля:

Название (текст)
Бренд (радио)
Изображения
Цена (целое число)
Описание (текстовый блок)
Тип (магазин/витрина, радио)
Состояние. Значение включает в себя Название (текст) и Пояснение (текст).
Статус. Возможны варианты:
1. на продаже
2. на модерации
3. на доработке
4. отклонен
5. продан
6. не прошел проверку
7. отменен Продавцом
Размер с бирки (необязательное). Текстовое поле без валидации
…

Полей более 30 и, дабы не раздувать статью, опустим их.

Выводы

Плюсы нового подхода:

Полнота. Данное ТЗ позволяет однозначно описывать требования, что является основным и необходимым параметром любого ТЗ.
Понятность. Около половины наших клиентов не имеют на своей стороне технического специалиста и сталкиваются с разработкой впервые. Поэтому очень важно было сделать ТЗ максимально понятным и читаемым. И у нас получилось! Даже технически не подкованные клиенты понимают, как оно устроено, могут спокойно его читать и давать отличную обратную связь.
Молекулярность. ТЗ полностью соответствует нашим требованиям к разбиению на отдельные элементы, что значительно упрощает и решает проблемы, описанные выше. Блоки ТЗ напрямую соответствуют задачам, которые выполняются разработчиками, что было встречено на ура. Также ТЗ отлично ложится на дизайн-систему (про нее статья выйдет уже на следующей неделе).
Простота оценки и конфигурации сметы. Хорошо описанные и разбитые задачи стало просто и приятно оценивать. Если во время оценки мы понимаем, что требования неполные, то дописываем их. Под каждый проект (этап) делаем гугл таблицу, в которой заказчик может попробовать разные конфигурации проекта и определить наиболее подходящий для себя вариант по цене/функционалу.
Взаимодействие с заказчиками поднялось на новый уровень. Внесенные изменения позволяют четко определить границы проекта. Если необходимо внести изменения относительно ТЗ, это оценивается как новая задача, хотя при старом подходе это вызывало много споров.
Рентабельность. Т.к. это в первую очередь бизнес, данный показатель наравне с предыдущим является одним из самых важных. Детальная проработка позволила свести количество плохо оцененных задач к минимуму. Ни по одному из проектов, реализуемых по новому подходу, не было превышения бюджета.

Минусы:

Внесение доработок. На одном из проектов было необходимо ввести статусы товаров. В итоге получилось огромное количество доработок по 2-3 строчки. Нельзя это назвать явным минусом, т.к. полното требований в приоритете, но и идеальным данных подход назвать нельзя.
Сложность восприятия при автоматизации бизнес-процессов. Если взять бизнес-процессы некоторых компаний от момента продажи до получения товара покупателем, не всегда есть возможность (или необходимость на первых этапах) покрыть весь процесс за счет Статики, Динамики и АП, т.к. многие задачи выполняются вручную, обсуждаются с клиентами по телефону и т.д. Это немного усложняет восприятие ТЗ в чистом виде, и требует дополнительного описания процессов.
Стоимость и время разработки. Продавать ТЗ, конечно, стало сложнее, ведь далеко не все при первом контакте с разработкой готовы платить за него 10-20% от проекта при том что многие наши конкуренты берут за него 10-20 тыс. Но подобная работа сполна окупается при реализации, снижая риски проекта и улучшая качество.

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

Мы настолько довольны результатом, что решили отказаться от стандартных тасктрекеров в пользу доработки Google Docs для полноценной работы с задачами на основе ТЗ. Если опыт будет удачным, напишем об этом отдельную статью. А пока ждем от вас объективную критику и советы, с надеждой, что кому-то эта статья помогла).

Образец формы технического задания по 44 ФЗ 2020

Автор: Юдина Ольга 24 декабря 2019

Техническое задание по 44 ФЗ — это документ, который необходим заказчику, особенно на этапе обоснования НМЦК. Но закон не устанавливает правил, по которым они составляются.

В чем разница технического задания и описания объекта госзакупки

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

Напомним, что с 11.01.2018 в правилах описания предмета госзаказа произошли изменения:

Законодатели исключили положение о том, что оно должно носить объективный характер.
Как и раньше, потребуется сопроводить товарный знак словами «или эквивалент».

Делать это не обязательно:

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

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

Правила составления ТЗ основаны на комплексе норм государственных и международных стандартов (ГОСТ). При их использовании в какой-либо сфере необходимо соотнести ТЗ со спецификой конкретной области деятельности.

В соответствии с 44-ФЗ, образец технического задания по ГОСТу в обязательном порядке заказчику создавать не нужно. Но практика показывает, что на каждом из этапов закупки (при составлении сопровождающей документации, проекта контракта, приемки и контроля исполнения контракта) заказчик соприкасается с элементами техзадания. Поэтому полезно такой образец иметь и понимать принципы разработки техн

10 правил и немного занудства / Блог компании RegionSoft Developer Studio / ХабрЕсли пройтись по зарубежным сайтам с запросом «product requirements document», то можно найти креативные и убедительные статьи про то, что техническое задание (ТЗ, PRD) умерло. Отчасти с этим нужно согласиться — при разработке продукта с нуля прототипирование выглядит гораздо интереснее и эффективнее, чем тома записей заказчика, порой ну очень непрофессиональные. Однако, если речь идёт о доработке базовой системы, то дело принимает совершенно другой оборот. Мы сталкиваемся и с доработкой, и с заказной разработкой, поэтому на ТЗ собаку съели, если повар нам не врёт. В общем, сегодня — о тех самых классических технических заданиях, которые пишутся на доработку купленного и установленного программного обеспечения. Короче, о наболевшем.

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

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

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

Возможности — если кратко, то это то, что реально может сделать вендор (исполнитель). Рассмотрим на примере нашей RegionSoft CRM. Клиент покупает систему и составляет техническое задание на доработку: нужно создать интеграцию с сайтом и привязку событий в CRM к номеру заказа интернет-магазина. Это реально исполнимое требование, у нас есть ресурс и возможность сделать это. А ещё нужно разработать и прикрутить к CRM CMS, систему управления контентом сайта. Теоретически мы это можем, но у нас нет возможности это сделать дёшево, а у клиента нет возможности заплатить нам столько, чтобы мы перекинули на задачу человеческие и временные ресурсы. В итоге от этого требования заказчик отказывается — да и CMS ему не особо нужна, всё и так хорошо. Но о «жадности» ТЗ— позже.

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

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

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

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

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

Есть очень простая схема сбора требований.

Создайте рабочую группу из руководителей и опытных специалистов подразделений, которые будут пользоваться CRM. Расскажите о решении, которое предполагается выбрать, предоставьте доступ к демо-версии.
Члены рабочей группы должны передать информацию сотрудникам и запросить у них пожелания к новой программе в абсолютно свободной форме. Если кто-то из сотрудников никогда не сталкивался с подобным софтом и не готов говорить в аспекте будущего использования, нужно попросить его описать свои периодические задачи, это универсальный подход.
Затем каждое подразделение устанавливает, чего нет в CRM или чему она не соответствует, и агрегирует информацию.
Рабочая группа анализирует собранные требования, проверяет и исключает пересечения. Например, нередко отдел продаж и отдел маркетинга заказывают один и тот же отчёт, но в требованиях могут по-разному называться поля и сущности, хотя данные за ними стоят одинаковые. Соответственно, нужно придти к единой форме.
Рабочая группа формирует список требований и расставляет приоритеты. На этом этапе можно подключить вендора, поскольку он отвечает за ресурсы. Например, можно попросить создать пользовательский отчёт для RegionSoft CRM, а можно заказать интеграцию с сайтом. Это совершенно разные по срокам задачи, здесь очень важен приоритет.

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

Анатомия технического задания

Если говорить о процессе создания технического задания, то существует несколько этапов. Их последовательное прохождение и приводит заказчика к желаемой доработке. Вот они.

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

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

Уровень бизнеса — самый глобальный уровень, на котором решаются сложные и приоритетные задачи. К этому уровню можно отнести интеграции, доработки и моделирование бизнес-процессов, разработку новых функциональных модулей. Как правило, это ресурсоёмкая разработка, с серьёзными консультациями и тесной совместной работой с заказчиком. Например, в своё время в RegionSoft CRM такой заказной доработкой были складской учёт, касса и производство. Постепенно изменения вошли в релиз, а позже позволили создать новый продукт для оптовых, розничных магазинов и гипермаркетов — RegionSoft Retail.

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

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

Уровень сервиса — на самом деле, требования этого уровня должны первыми попадать в новые сборки с фиксами. Это задачи по скорости отклика системы, работе под высокой нагрузкой, безопасности. В идеальном варианте у вендора не должно быть таких доработок — корпоративный софт не должен тормозить, терять данные, схлопывать формы и раздавать права доступа одного уровня. Но если требование появилось, и оно не связано с персональной паранойей заказчика или проблемами на стороне аппаратного обеспечения, стоит уделить ему повышенное внимание.

Уровень технологии — последний в списке, но по важности и сложности опережающий остальные. Это могут быть требования клиента, связанные с платформой, операционной системой или устройствами. Например, запрос сборки под MacOS. Очень здорово, если такие требования постепенно перерастут в релизы, но иметь их фиксы обязательно. Именно из запросов клиентов на этом уровне мы сделали сборку RegionSoft CRM под MacOS и добавили удалённый доступ по технологии TRM как временное решение редкого, но существующего запроса мобильной версии.

Анатомия технического задания проста, во всяком случае в виде скелета. Обязательные части технического задания помогают заказчику сосредоточиться на проблеме и сформулировать задачу правильно, а исполнителю — понять, что же от него хотят. Кстати, о понимании. Конечно, в начале поста мы немного слукавили, отрицая бизнес-консультантов как класс. Дело вот в чём: каждый вендор работает на рынке по несколько лет (мы сейчас не о CRM-однодневках), а то и десятков лет, а значит имеет набор кейсов практически по каждой отрасли. Соответственно, и инженеры, и программисты, и продажники знакомы со спецификой внедрения в каждом типе компании. Но опять-таки, важно ориентироваться именно на свой бизнес.

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

Приведу пример. В одной компании внедряли CRM, предполагалась работа на довольно большом массиве данных (несколько десятков миллионов записей в месяц, несколько сотен тысяч записей в день). Начальник отдела продаж запросил отчёт по выгрузке этих записей с периодичностью «ежедневно». Естественно, что такой отчёт при одновременной работе сотни пользователей нагружал систему — были найдены решения по оптимизации процесса. Уже в ходе работы выяснилось, что продажник перестраховался и отчёт нужен ему только по итогам месяца, и то его можно запускать по расписанию ночью. Стоит ли говорить, что время и деньги были потрачены зря.

Зачем? Обоснование необходимости доработки и его место в бизнес-процессе. Этот пункт больше нужен самому заказчику, но и вендору нелишне знать, какие ещё процессы будут затронуты. Иногда это помогает найти альтернативное решение.

Что должно делать? Самый информативный блок — в нём описываются требования, ожидания от системы. И вот тут случаются тем самые перлы, чудеса и коллизии, которые впору отправлять на башорг, и которые ну очень усложняют жизнь. Причина одна — пользователь не знает, чего он хочет, что нужно сделать. Есть ещё маленькая подпричина — пользователь не может сформулировать требования. И тут задача разработчика (рабочей группы, аналитика, если он есть) помочь сформулировать потребность верно, выбрать целесообразное требование, вписать задачу в контекст работы системы. В этом же блоке нужно упомянуть ожидаемый результат.

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

В идеальном варианте техническое задание составляется при активном участии вендора, и его итог представляет собой примерно такую структуру:

Описание требования каждого механизма и каждой функциональности

Описание реализации данной функциональности

Стоимость работ по каждому из этапов в отдельности

Общая стоимость работ по данному техническому заданию

Сроки исполнения работ с разбивкой по этапам и указанием очерёдности

Описание условий установки и тестирования доработки

Оговорки об исчерпывающем характере технического задания и иные условия

10 правил, написанных слезами разработчика

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

Техническое задание не должно быть жадным. Нередко бизнес переоценивает свои возможности или желает получить «всё и сразу». Такой подход не оправдан ни с точки зрения денег, ни с точки зрения бизнеса. Вендор, как правило, существует не пару недель (в случае RegionSoft — 15 лет), и к нему можно обратиться и через некоторое время, когда вы уже реально поймёте, чего в CRM не хватает.

Яркий пример избыточности буквально из вчерашнего дня: клиент купил ERP одной известной российской компании, думая, что раз работает бухгалтерский учёт, то и ERP этого вендора будет хороша. ERP оказалась не то чтобы не очень сама по себе, но очень не подходящей бизнесу. А вот RegionSoft CRM со складским учётом и производством подходит. Есть решение: забыть про ERP, поплакать, интегрировать учёт 1С с новой CRM и радоваться удобной реализации. Но вбуханных денег жалко! И клиент требует интегрировать CRM с ERP. Мы и не такое делали, но зачем такая трата, зачем две относительно схожих системы?

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

Например, RegionSoft CRM — десктопная программа, у нас нет клиента для браузера. Просить нас создать web-приложение для одной компании бессмысленно, это крупная разработка, она сейчас ведётся и не является возможной доработкой для одной компании. Нет, конечно, всё имеет свою цену, но опять же — в общем случае требование невыполнимое.

Не нужно путать с ситуацией, когда речь идёт о заказной разработке и в корне меняется идея и логика работы приложения, фактически спонсируется создание нового программного обеспечения «под себя». Но это другая история.

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

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

Да, корпоративный софт выглядит примерно так, и в нём много важных мелочей

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

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

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

Клиент пытается продемонстрировать свою техническую грамотность и городит конструкции типа: «имплементировать окно с хинтом в тело календаря с возможностью реакции на колл события…» вместо «в календаре должно всплывать окно, в котором можно отметить задачу как выполненную». Если у вас или вашего внутреннего эксперта нет навыков написания технических текстов, не гуглите — пишите обычными словами, мы их понимаем.
ТЗ переполнено грамматическими ошибками. Нужно не только избавиться от расплывчатых описаний и метафор (из реального: «Чтобы компьютер не пищал, будто помирает в судорогах»), лишних слов, слов-паразитов. Проверяйте пунктуацию – зачастую ошибки в ней искажают смысл требования. Задание на проект – это документ и лексика в нём должна быть соответствующая, а грамотность — близкая к 100%.

И ещё — не используйте редакторы типа Microsoft Visio и UML-диаграммы, если вы в них не разбираетесь. То, что кажется красивым и деловым, на взгляд разработчика оказывается адской путаницей. Если хочется вставить схему или картинку — нарисуйте её человеческими методами, не утруждайте себя, это нам, разработчикам, ничем не поможет.

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

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

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

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

Заповеди закончились, теперь отповедь

Кроме перечисленных правил, есть ещё несколько вещей, о которых стоит рассказать. Речь идёт о целях, планах и ожиданиях — всех тех оставляющих, которые делают проект успешным, а отношения вендора и клиента почти дружескими.

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

Наконец он нашёл время закончить ТЗ. Но, увы, вокруг не осталось разработчиков, чтобы его реализовать.

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

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

Исходите из объективной необходимости изменений и расширений — выше я писал, что разработчик не исчезает и готов внести изменения и дополнения по вашим требованиям в любой момент. Поэтому не пытайтесь создать CRM/ERP мечты сразу, не требуйте от вендора кнопку «Всё работает, пока я пью кофе» — поработайте в системе, определите критичные для вас замечания и приступайте к сбору требований и составлению ТЗ.

О технических заданиях можно писать бесконечно, это настоящий генератор не только мемов и баек, но и головной боли. Можно рассказать о приоритетах и правилах оформления, о ГОСТе 1989 года, который делает ТЗ бесчеловечным, о стандартах IEEE, которые немного лучше, о прототипах и дополняющих их ТЗ. Но в конце хотелось бы ограничиться одним, самым главным правилом: техническое задание — не норма права, не ГОСТ и не догма, поэтому, если можно улучшить — улучшайте, можно упростить — упрощайте, можно сделать изящно и чтобы всем нравилось — делайте. Уверен, никто после такого не ткнёт носом в ТЗ и не скажет, что там такого не написано. Или почти никто.

Весь декабрь мы даём скидки на RegionSoft CRM и весь софт собственной разработки. С 1 по 15 декабря — 15% и крутые условия рассрочки и аренды. У нас не бывает -70% и -90%, потому что мы держим экономически обоснованную цену на лицензии, а не берём её с потолка.

Ну а если вам нужна CRM-система (с доработкой или без), то заходите на наш сайт, там много о CRM, её преимуществах и прочем корпоративном софте.
И да, мы всегда ищем партнёров, которые готовы продавать CRM и другие продукты, дорабатывать и продавать CRM, продавать софт и обучать пользователей. Разделение доходов честное и выгодное партнёру. Покажем, расскажем, научим. Пишите на dealer@regionsoft.ru
Слайды, слайды. Комиксы взяты с http://www.modernanalyst.com/ и из Pinterest. Если есть лучший перевод — будем рады его внести в пост.

Как грамотно составить ТЗ для программиста. Основы взаимопонимания

Назначение, цели ТЗ

Итак, техническое задание, сокращенно ТЗ, уже довольно давно служит для формального описания того, что мы собственно хотим видеть в конечном продукте. Не является исключением и ТЗ для разработки web-ресурса. По своей сути — это база для разработки сайта. В нем указываются все положения, прямо или косвенно касающиеся сайта.

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

Есть мнение некоторых “побитых” опытом людей, что ТЗ надо писать так, как будто с ним вы будете присутствовать на суде и использовать его в качестве защиты. Может это и крайность, но тем не менее — повод лишний раз задуматься о важности хорошо написанного и детализированного ТЗ.

По своему объему ТЗ может быть достаточно большим документом. Web-компании часто предлагают помощь по составлению ТЗ отдельной услугой, как правило 10-20% от стоимости всей разработки сайта.

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

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

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

Общие рекомендации по написанию ТЗ

Простая истина — чем сложнее проект, тем детализирование должно быть ТЗ.
Среди возможных вариантов можно назвать ТЗ, описывающее главные страницы интерфейса со всей совокупностью элементов на ней и описанием их поведения. Или же это может быть лаконичное описание нескольких страниц для сайта-визитки и т.п.
В ТЗ для программиста не должен упоминаться дизайн элементов или звучать пожелания по дизайну. Задание все-таки для программиста..
Описания задач в отдельных частях ТЗ должны быть граничными. Что это значит? Нужно четко обозначать конец конкретного пункта задания. В ТЗ не должно быть абстрактных фраз типа «должна быть удобная навигация». Это все субъективные признаки – одним удобно, другим не удобно и понять выполнен ли данный пункт бывает сложно из-за нечеткости положений ТЗ. Т. е. это необходимо контролировать.
Для несложных сайтов, где нужно описать какой-нибудь функциональный модуль, чтобы заново не изобретать велосипед, нужно проанализировать сайты с похожим функционалом, так сказать, провести анализ конкурентов; сохранить гиперссылки на страницы с требуемыми элементами интерфейса и функциями, и включить их в ТЗ с расширенными пояснениями о том, что именно делать. Также необходимо в обязательном порядке снять скриншоты с нужных страниц на случай, если сайт через время будет не доступен. При этом можно ставить свои пометки на изображениях ( благо средств сейчас много для этого — Clip2net, Joxi, Awesome Screenshot и прочие).
Если дизайна для страниц нету или он не так важен в рамках какого-то проекта, скажем, заказчик решил сэкономить на дизайне админ-панели сайта, в этом случае программист вполне может использовать прототипы.

Справка
Прототип — это графическая схема размещения элементов интерфейса. Грубо говоря, нарисованная в специальной программе страница со всеми элементами.
Существует много софта для прорисовки прототипов, включая как декстопные приложения, так и онлайн-сервисы, а также расширения для браузеров с более скромными возможностями. Софт как с бесплатной лицензией так и с платной.
Из популярных можно выделить:
— среди бесплатных: iPlotz, MockFlow, Mockup Builder, Cacoo;
— среди платных: Creately, ProtoShare, Adobe Fireworks,Axure . Возможностей в общем много — выбирай, осваивай, рисуй…

Общая структура ТЗ. От абстракции к конкретике

Одна из возможных структур сайта, подчеркну возможных, может выглядеть примерно так:

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

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

2. Функциональное назначение сайта
Тут краткий перечень того, какими техническими средствами или инструментами должен обладать сайт, исходя из общей цели. Поясню на примере. Для сайта-визитки это может быть банально, форма обратной связи, перечень основных страниц, например с «о компании», «контакты» и прочие.

3. Понятия и термины
Этот раздел должен гарантировать понимание обеими сторонами специфических для данной предметной области понятий, которые важны для понимания и разработки сайта. Могут вводиться обеими сторонами.

4. Описание модулей сайта
Этот раздел включает список модулей, которые используются на сайте. Это вполне например может быть упоминаемая выше форма обратной связи (ФОС). Но, что очень важно — нельзя просто писать «Должна присутствовать ФОС». Каждая сущность требует определения своих атрибутов! В данном случае атрибуты могут быть такими:

Поле «Ваш имя»;
Поле «Ваш е-mail»;
Поле «Ваш вопрос»;
Поле ввода капчи для защиты от спам-роботов.

И все это должно быть четко прописано, что бы потом не возникло вопросов: «…а где перечень выбора категории вопроса?» или что-то в этом роде.

5. Функциональные характеристики
Сюда можно отнести, например, список браузеров, где сайт должен корректно отображаться и работать. Например, некоторые заказчики могут требовать, что бы их сайт работал корректно и в небезызвестном Internet Explorer 6, что бы не терять хоть и небольшую, но долю возможных посетителей.
Если планируется делать высоконагруженный сайт – это тоже нужно указывать. Высоконагруженный сайт требует другого подхода при разработке и по настройке сервера.

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

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

Для каждой конкретной страницы могут рисоваться прототипы с подробными комментариями по каждому из элементов интерфейса с их поведением.
Страницы, используемые для админ-панели обычно уазываются отдельно от спубличных страниц. Эти два раздела в свою очередь могут группироваться в свои отдельные подразделы. Здесь стоит следить, чтобы прототипы не конфликтовали с их описанием, и не возникало никаких противоречий. Примером прототипа определенной страницы сайта может быть:

Остальные страницы

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

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

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

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

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

Удачных Вам проектов и человеческого взаимопонимания!

Подписаться на рассылку
Еще по теме:
Олег Галеня
Middle PHP Developer
Есть вопросы?
Задайте их прямо сейчас, и мы ответим в течение 8 рабочих часов.

Как написать техническое задание для цифрового учебного проекта | Как написать техническое задание для цифрового учебного проекта | Как написать техническое задание для цифрового учебного проекта | Как написать техническое задание для цифрового учебного проекта Учебный проект | Как написать техническое задание для цифрового учебного проекта | Как написать техническое задание для цифрового учебного проекта
Как написать техническое задание для цифрового учебного проекта

Написание Техническое задание помогает определить потребности компании в цифровом обучении и найти лучшего поставщика для их удовлетворения.
Техническое задание: первый шаг проекта цифрового обучения
Определение технического задания требует стратегического подхода , который подчеркивает ценность цифрового обучения как метода обучения и его актуальность для решения конкретных задач. Чем детальнее он, тем больше у него шансов на успех.
1. Контекст обучения цифровому обучению
Первым шагом является определение:
Доступные ресурсы : человеческое, техническое и, возможно, учебное содержание.
Аудитория : всестороннее исследование качества, последовательности и размера аудитории.
Ограничения : сертификация, обязательные личные встречи, технические ограничения, самооценка и т. Д.
Сроки для реализации и завершения проекта для каждого участника.
2. Цели цифрового обучения
Несколько факторов могут повлиять на конечный подход и возможности, выбранные для интеграции решения:
Анализ текущего уровня относительно желаемых навыков: были ли ключевые концепции интегрированы командами?
Определение желаемого уровня : полный список ожидаемых навыков: элементы торгового предложения, технические аргументы, список медицинских протоколов, правила.
Намеченная оценка : необходимо ли сертифицировать приобретение навыков или достаточно самооценки?
Режим распространения : онлайн-продажа курсов (с каталогом, корзиной, управлением счетами) или внутреннее обучение (определенный путь обучения, инструмент для воспроизведения внутренней структуры компании)
3. Вовлечение заинтересованных сторон
Для обеспечения Команды чувствуют себя вовлеченными в их подготовку, круг ведения должен включать:
Руководитель программы , справочное лицо для учащихся.
Организация специальных учебных курсов на основе таких критериев, как географический регион, иерархия, сектор и т. Д.
Учебные материалы : викторины, видео, изображения… диверсификация и персонализация контента стимулирует участие учащихся.
Сценарий обучения
4. Технические требования
Технические и логистические параметры соответствуют вышеуказанным определенным потребностям. Затем компания собирает все имеющиеся доказательства: документы, информацию, экспертов и т. Д.и делает выбор из следующих опций:
Несколько платформ : ПК, планшет, смартфон, онлайн или офлайн
Встроенные системы : например, в медицинском оборудовании
Смешанное обучение : обучение дополняется лицом личные встречи
Соответствие стандартам : необходимость прохождения аудита программного обеспечения для обеспечения соответствия системы.
Потребности в отчетах
Чтобы воспользоваться преимуществами и опытом Dokeos при составлении технического задания, свяжитесь с нами.
Шаблон справочного письма
(20+ советов)
Вы увидите, как написать отличное рекомендательное письмо, но сначала подумайте об этом:
Вы ищите работу? Это то, что вам нужно знать:
Что такое рекомендательное письмо?
Справочное письмо , также называемое рекомендательным письмом или рекомендательным письмом, представляет собой письмо из надежного источника, подтверждающее вашу пригодность для конкретной работы.Автор вашего рекомендательного письма должен прочитать объявление о приеме на работу, на которое вы претендуете, и описать ваш соответствующий опыт работы, навыки, достижения, личные качества и / или успеваемость.
Как запросить рекомендательное письмо?
Выберите человека с большим влиянием, который много знает о вас. Затем поделитесь с ними описанием работы. Покажите им образец рекомендательного письма в этом руководстве, чтобы помочь им сделать это правильно.
Уже получили рекомендации и не знаете, как их перечислить в своем резюме? Вы можете даже сделать это, когда большинство экспертов скажет вам не делать этого? У нас есть ответы: Резюме ссылок: когда и как составить список ссылок на резюме
Хотите написать рекомендательное письмо для кого-то ? Читай дальше!
Знакомьтесь, Стю, менеджер по найму.
Nice Работа в команде на стене.
Stu только что открыл ваше рекомендательное письмо. Три секунды спустя он снова закрыл его и нажал удалить.
Десяток ходов новичка могут потопить благие намерения.
Ваше рекомендательное письмо не может просто сказать: «Джейн великолепна. Пожалуйста, найми ее».
Это должно сделать намного больше. Но как только ты узнаешь простые правила, в мире твоя устрица.
Это руководство покажет вам:
Как написать рекомендательное письмо для работы или стажировки.
Что добавить в рекомендательное письмо, чтобы оно работало как швейцарские часы.
Идеальный пример рекомендательного письма для проведения интервью.
Как попросить рекомендательное письмо.
Как написать символьное рекомендательное письмо.
Вот типовое рекомендательное письмо, сделанное с помощью нашего быстрого онлайн-инструмента для деловых писем.Хотите написать письмо за 15 минут? Используйте наши шаблоны и создайте свою версию здесь.

Этот шаблон справочного письма работает, потому что он личный, увлеченный и подробный.
Вот как написать рекомендательное письмо:
1. Выберите лучший формат рекомендательного письма
2. Начните свое профессиональное рекомендательное письмо с крючка
3. Напишите убедительное рекомендательное письмо Второй абзац
4.Убедитесь, что ваше рекомендательное письмо соответствует описанию работы
5. Закончите свое рекомендательное письмо запросом
Теперь позвольте мне показать вам, как работает каждая часть:
1
Выберите лучший формат рекомендательного письма
Изображение это:
Кто-то вручает вам большую сумку с этими алфавитными магнитами на холодильник, затем идет.
Так выглядит плохо отформатированное письмо с профессиональными рекомендациями.
Лучший формат справочного письма делает одну вещь.
Это помещает правильные элементы, чтобы зафиксировать интервью.
Наиболее важными из них являются:
Крюк
Как вы знаете, заявитель
Обзор ее лучших качеств
Детали, которые соответствуют описанию работы, как спасательный жилет
См. как это работает в этом профессиональном образце рекомендательного письма:
Шаблон письма-справки
Используйте этот образец справочного письма, чтобы сделать ваше письмо потрескивающим:
Джоселин Чампи
Профессор компьютерных наук
Колби Колледж
4000 Mayflower Hill
Waterville, ME 04901
12/6/17
Клара Эрнандес
генеральный директор
Auril Codeworks, Inc.
3670 Pearlman Ave
Бостон, Массачусетс 02109
Дорогая Клара,
[Часть 1 — Большой «Крюк»]
[Часть 2 — Как вы знаете заявителя]
[Часть 3 — Детали, которые соответствуют описанию работы]
[Часть 4 — Призыв к действию и закрытие]
С наилучшими пожеланиями,
Джоселин Чампи
Бинго. Вот ваш простой шаблон рекомендательного письма.Следуйте этому, и ваш заявитель на пути к оплачиваемой работе.
Если вы используете вышеуказанный шаблон рекомендательного письма в MS Word, добавьте поля в 1 дюйм. Также используйте одинарный интервал и чистый шрифт, например Arial или Cambria.
Далее я покажу вам, как работать с каждым из этих элементов ссылочных букв, чтобы он сиял.
Pro Совет: Не знаете заявителя достаточно хорошо, чтобы комментировать? Вы можете сказать: «Я не думаю, что я лучший человек, чтобы написать рекомендательное письмо.»
Письмо-справка для работы требует резюме. Хотите быстро это сделать? Используйте нашего онлайн-конструктора: Resume Builder: создайте профессиональное резюме за 5 минут!
2
Начните свое профессиональное рекомендательное письмо с крючка
Давайте подкрадемся к менеджеру по найму
Она опаздывает на семь сроков, у нее 387 непрочитанных электронных писем. Она просто воспользовалась планшетом, чтобы размешать мокасино.
Теперь она получает резюме, сопроводительное письмо и три рекомендательных письма.
Взгляд, взгляд, взгляд, и в груду отчаяния он уходит.
Заставь ее остановиться и прочитай твое письмо.
Посмотрите на этот образец контрольного письма:
Пример справочного письма [Крюк]
Типичное рекомендательное письмо начинается в общем, не затрагиваемом виде:
неправильно
Уважаемая Клара,

Стивен Померло подает заявку на открытие вашего менеджера проекта…
Это не ужасно, но это серый костюм в толпе других, всех одинаковых.
Как начать рекомендательное письмо, чтобы оно привлекло внимание менеджера как кнут?
правильно
Уважаемая Клара,

Я не скажу, что Сэм Хостеттер — лучший претендент на должность менеджера проекта.
Я докажу это.
Открытие образца этого справочного письма останавливает суматоху и заглушает звонящий телефон.
Не можете сказать что-нибудь такое сияющее?
Крючком для рекомендательного письма может быть что угодно, в том числе:
Как вы в целом относитесь к качествам заявителя.
Потрясающий факт о заявителе.
Награда, которую выиграл кандидат.
Все, что привлекает внимание.
Pro Совет: Кто-то пишет рекомендательное письмо для вас? Не забудьте отправить благодарственное письмо взамен. Они запомнят этот жест, и это сеть 101.
Рекомендательное письмо очень похоже на сопроводительное письмо. Получите больше советов здесь: Как написать сопроводительное письмо [Полное руководство с примерами]
3
Написать убедительное рекомендательное письмо Второй абзац
Предположим, вы написали отличный хук ,
Вы должны поддерживать этот интерес.
Конечно, следующий шаг — сказать, как вы знаете кандидата.
Но сделайте это неправильно, , и занятая жизнь менеджера снова похитит ее.
Лучшие рекомендательные письма сочетают «как ты знаешь» с «почему она великолепна». Они также добавляют детали.
Пример справочного письма [2-й абзац]
Найдите разницу в этих двух примерах справочных букв:
неправильно
Стивен является студентом.
Это делает работу, и это коротко. Но это так же универсально, как коробка кукурузных хлопьев в супермаркете.
Дайте ему пятизвездочное обращение, как в следующем примере рекомендательного письма:
right
Я имел огромное удовольствие работать в тесном сотрудничестве с Сэмом над его проектом Senior Scholar. и как мой научный сотрудник в течение двух лет. Он, безусловно, самый преданный, страстный студент, которого я встречал за семь лет моего пребывания здесь в Колби.
Здесь показано, как написать рекомендательное письмо для студента, который работает как электромагнит. Это подробных и усиливает интерес.
Если вы не можете так сильно толпиться. не волнуйся Просто убедитесь, что:
Поделитесь подробностями о том, как вы знаете заявителя.
Добавьте факт, который показывает, почему вы высоко цените его.
Pro Совет: У вас нет времени, чтобы добавить свое рекомендательное письмо в предложение о работе? Попросите, чтобы увидеть резюме заявителя.Он должен быть переполнен индивидуальными достижениями и навыками.
Хотите сказать что-то хорошее в профессиональном рекомендательном письме? Они такие же, как вы бы сказали в резюме. См. Это руководство: Достижения для возобновления — Полное руководство (+30 примеров)
4
Убедитесь, что ваше рекомендательное письмо соответствует описанию работы прочитайте ваше профессиональное письмо.
Вы, вероятно, правы.
Общие справочных букв получить взгляд, если это.
Вы знаете, как написать рекомендательное письмо, которое будет прочитано, когда вы добавите правильные данные.
Итак, попросите прочитать описание работы. Затем заблокируйте свое рекомендательное письмо как что-то из Escape from Alcatraz.
Справочные письма Примеры [Как настроить]
Посмотрите на эти два очень разных образца справочных букв:
неправильно
Steven хорошо подходит для вашей позиции.Он труженик, добросовестный, яркий и очень пунктуальный.
Стивен звучит хорошо, не так ли? Но эта позиция, вероятно, имеет более 300 претендентов, все натыкаясь локтями. Они не будут нанимать «хорошо».
Теперь посмотрите следующий пример справочного письма о работе:
right
Быстрый интеллект Сэма и жажда самосовершенствования делают его настоящим экономящим время.Снова и снова я был приятно удивлен, когда он нашел простые решения, прежде чем я даже узнал о проблеме. Среди его достижений:
Сэм увеличил эффективность кода приложения в разработке на 35%.
Он предложил креативные, экономящие время решения для кодирования, которые делали ненужными целые большие части программного обеспечения.
Сэм собрал специальную команду из более 30 профессиональных программистов, используя их для повышения эффективности, которая по очереди делала мою жизнь проще.
Если я когда-нибудь уйду из академии и начну свой бизнес, я надеюсь нанять кого-то вроде Сэма. Он увлечен работой в Auril Codeworks, прочитав вашу статью в прошлом году в Forbes. Я надеюсь, что вы воспользуетесь этой возможностью, чтобы нанять по-настоящему яркого и находчивого специалиста по информатике.
Теперь вот как написать рекомендательное письмо для студента, который дает интервью.
Ваше письмо должно быть таким грандиозным? Конечно нет.Но включите по крайней мере эти элементы:
Укажите конкретные способы, которыми заявитель помог вам.
Сопоставьте достижения в вашем письме с требованиями в предложении о работе.
Включите подробную информацию о том, почему заявитель увлечен работой.
Pro Совет: В середине рекомендательного письма может быть один параграф или три. Он может включать в себя маркеры или таблицу. Формат не так важен, как правильные детали.
Почти одна пятая всех новых сотрудников приходит от рефералов, но только 3% заявителей используют их. См. Больше в нашем руководстве: Статистика найма и найма
5
Закончите свое рекомендательное письмо запросом
Плохие новости: Ваш соискатель не получил работу.
Теперь она плачет своим друзьям в Facebook о том, как все безнадежно.
Она была так близко.
Если бы вы знали, как написать окончание рекомендательного письма, она была бы готова.
Чтобы заключить сделку, завершите письмо письмом.
Справочное письмо от образца работодателя [Запрос]
Что такое профессиональное письмо без запроса? Взгляните на эти два примера справочных букв:
4
неправильно
Спасибо за ваше время,
Jocelyn Ciampi
вежливо, правда? Безобидные.Так же как и старинный Эдсель с убранным двигателем. Но никто не доставит вас на пляж.
Но посмотрите на следующий пример того, как написать рекомендательное письмо для сотрудника:
справа
Я бы хотел поговорить с вами подробнее о Сэме. Можем ли мы назначить время для разговора по телефону?
С наилучшими пожеланиями,
Jocelyn Ciampi
Можете ли вы увидеть, как это повысит шансы на собеседование?
Во-первых, показывает, что вы достаточно уважаете заявителя, чтобы поделиться своим временем.Это гарантированно потрясет и разбудит менеджера по найму.
Далее, создает возможность продолжить разговор.
Не чувствуете себя комфортно, предлагая поговорить? Вам, вероятно, не придется. Одно только предложение повышает цену вашего письма.
Pro Совет: Не знаете, как обращаться с рекомендательным письмом? Используйте «Дорогой» и имя, или «Мистер» или «мисс» и фамилия. «РС.» работает независимо от семейного положения.
Окончание рекомендательного письма аналогично окончанию сопроводительного письма. См. Это руководство: Как закончить сопроводительное письмо: Образец и полное руководство [+20 примеров]
6
Как написать рекомендательное письмо персонажа
Вот хорошие новости:
Если вы знаете, как написать рекомендательное письмо для работы, вы также знаете, как написать символьное рекомендательное письмо.
Оно должно включать:
Как вы знаете заявителя.
Ее сияющие качества.
Как она помогла тебе (или другим).
запрос.
Используйте образец шаблона справочного письма ниже.
Пример личного справочного письма
Это личное справочное письмо работает в качестве рекомендательного письма для суда, друга, а также для иммиграции или использования помещиком.
Джон Скотт
Офицер
Полицейское управление Уотервилла
Улица Колби
Уотервилл, МЭ 04901

0000000000000000000 Вики Коррал
Окружной судья
Окружной суд США
405 W Конгресс, ул. № 1500
Тусон, AZ 85701
Уважаемая г-жаCorral,
[Часть 1. Как вы знаете заявителя]
С наилучшими пожеланиями,
Джон Скотт
Это простое, как написать личное рекомендательное письмо.
Теперь напишите этот эталонный скелет буквы-символа со следующими деталями:
В части 1 будет как можно более конкретным.Чем больше взаимодействия вы можете процитировать, тем мощнее ссылка.
Во второй части перечислены положительные качества и конкретные способы, которыми человек проявил характер. Честность, сильная трудовая этика и компетентность — все это неразрывно связано.
Часть 3 может быть простым: «Я даю Тиму свои самые высокие рекомендации по характеру, трудовой этике и надежности».
Ищете работу, стажировку или другую должность? Вы добьетесь большего успеха с настроенным рекомендательным письмом для работы наверху.
Pro Подсказка: Написание буквенного обозначения для друга? Включите свой титул, если он повысит ваш авторитет (например, сотрудник, доктор, судья, Town Selectman ).
Избегайте скучных формулировок в вашем рекомендательном письме. См. Это руководство: 80 Примеры слов действия «Возобновить» для каждой профессии
Вывод ключа
Знание того, как написать рекомендательное письмо, может быть различием между успехом и неудачей.Следуйте этим ключевым советам, чтобы сделать это правильно:
Опишите, как вы знаете кандидата. Чем ближе вы с ней работали, тем сильнее ваше рекомендательное письмо.
Нарисуйте картину, почему вы рекомендуете кандидата. Измеримые достижения заставляют блестеть рекомендательное письмо.
Предлагаю больше поговорить с адресатом. Скорее всего, вам не придется, но предложение кладет глазурь на торт рекомендательного письма.
Хотите узнать больше о том, как сделать рекомендательное письмо? Может быть, у вас есть идеальный шаблон рекомендательного письма? Дайте нам крик в комментариях! Мы любим помогать!
.
Написание рекомендательного письма (с примерами)
Али Хейл

В какой-то момент жизни вам почти наверняка придется написать рекомендательное письмо для кого-то. Это может быть бывший сотрудник или студент, или даже друг семьи. Вот что вам нужно знать о назначении рекомендательных писем и о том, как написать наиболее эффективное письмо.
Примечание. Я буду использовать «кандидат» для обозначения лица, о котором написано рекомендательное письмо, «вы» для обозначения лица, пишущего рекомендательное письмо, и «получатель» для обозначения лица, получающего письмо. Я подчеркну здесь, однако, что рекомендательные письма предназначены не только для работы или академических «кандидатов», это просто удобный термин, чтобы использовать эту статью прямо!
Что такое рекомендательное письмо и когда они используются?
Письмо-рекомендация, как правило, пишется для подтверждения личности или (иногда) навыков, характера и / или достижений компании. Иногда рекомендательное письмо называется «рекомендательным письмом». Это официальный документ, который должен быть напечатан и написан в серьезном деловом стиле.
рекомендательные письма используются в самых разных ситуациях; нет окончательного списка, который охватывает все возможные сценарии. Наиболее распространенные примеры:
Когда кандидат претендует на работу, он может нуждаться в справке для поддержки своего заявления.
Если собеседнику дают предложение о работе, ему может потребоваться предоставить рекомендательное письмо до того, как договор может быть подписан.
Студент, подающий заявку на академический курс, часто требует рекомендательное письмо в поддержку своего заявления.
Учащийся, подающий заявку на финансирование, часто должен предоставить рекомендательные письма.
Компании могут использовать рекомендательные письма в качестве свидетельства их надежности и способности хорошо выполнять свою работу.
Потенциальным арендаторам может потребоваться предоставить домовладельцу рекомендательное письмо, свидетельствующее об их хорошем финансовом положении. (Это может быть от предыдущего арендодателя или от текущего работодателя.)
Кто должен написать рекомендательное письмо?
Если к вам обращаются и просят написать рекомендательное письмо для кандидата на работу, студента или компании, подумайте, можете ли вы на законных основаниях сделать это. Справочное письмо является официальным документом, и крайне важно, чтобы вы не лгали и не выдумывали правду, в противном случае возможны юридические последствия. Если кто-то хочет от вас рекомендательное письмо:
Кандидатом должен быть тот, кого вы знаете достаточно хорошо.Например, вы не можете предоставить какой-либо авторитетный комментарий об академических способностях студента, который посещает ваши лекции только неделю.
Вы должны знать кандидата в должности, которая дает вам возможность написать содержательную ссылку. Например, если вы работали с этим человеком, было бы целесообразно написать рекомендательное письмо для потенциального работодателя.
Вы должны быть в состоянии предоставить честную и позитивную ссылку. Если вы действительно чувствуете, что у кандидата нет хороших качеств, на которые вы могли бы обратить особое внимание, или если вы сталкивались с ним в прошлом, вы должны попросить его попросить рекомендательное письмо от кого-то другого.
Что входит в рекомендательное письмо?
Точная структура рекомендательного письма будет немного отличаться в зависимости от типа ссылки, но это хороший базовый план:
Начните использовать формат делового письма: укажите имя и адрес получателя, если он известен, и укажите их как «Уважаемый [имя]». Если получатель в настоящее время неизвестен (это может быть, например, в академической заявке), тогда используйте «Уважаемый сэр / мадам» или «К кому это может относиться».
Часто бывает полезно представить себя в первых двух строках вашего письма. Получателю не понадобится ваша история жизни: просто дайте короткое предложение или два, объясняющие вашу позицию и ваши отношения с кандидатом.
Ваш следующий абзац должен подтвердить любые факты, которые, как вы знаете, кандидат представит вместе с вашим письмом. Например, если вы пишете справку для соискателя, некоторые или все эти детали могут быть уместными:
Должность человека и должность в компании.
Отпускной зарплате человека, когда он в последний раз работал на вас (или вашей организации).
Даты, с которых человек был нанят с и до.
Если вы пишете рекомендательное письмо для академического курса, вам необходимо подтвердить академические оценки человека.
В третьем абзаце вы должны высказать свое мнение о навыках и качествах кандидата. Часто уместно заявить, что вы бы с радостью снова наняли их или что их вклад в ваш класс колледжа был высоко оценен.Выделите любые исключительные качества, которыми обладает кандидат — возможно, его драйв и энтузиазм, их внимание к деталям или их способность руководить.
Где это возможно, используйте свой четвертый абзац, чтобы привести несколько конкретных примеров, когда кандидат преуспел. (Вы можете попросить кандидата рассказать вам о любых внеклассных проектах, в которых он принимал участие, или предложить им выделить все, что они хотели бы, чтобы вы включили в рекомендательное письмо.)
Закройте ваше письмо на положительной ноте, и если вы желаете получать дополнительную переписку о заявке кандидата, проясните это.Включите ваши контактные данные тоже.
Как и в любом деловом письме, вы должны закончить соответственно; «Искренне ваш», когда вы пишете указанному получателю, и «Искренне ваш», когда вы не знаете, кто будет получать письмо.
Вещи, которых следует избегать
Убедитесь, что вы избегаете:
Упоминание любых слабых сторон кандидата.
Говорить все, что может быть истолковано как клевета.
Пишем неформально: держите письмо по-деловому.Шутки, сленг и ненормативная лексика не подходят и могут нанести ущерб шансам кандидата.
Включая личную информацию, не относящуюся к заявке. Упоминание расы, политической позиции, религии, национальности, семейного положения, возраста или состояния здоровья кандидата обычно неуместно.
Орфографические ошибки, небрежное написание или опечатки: это письмо очень важно для кандидата, и вы должны позаботиться о том, чтобы оно выглядело профессионально.
Примеры рекомендательных писем
На Business Balls есть несколько хороших шаблонов для рекомендательных писем.Я включил один ниже, который будет уместным для справки общего назначения — если вы пишете справку в качестве бывшего работодателя кандидата, вам нужно будет включить более конкретные детали:
Дата
Кому это может касаться
Я подтверждаю, что я знаю (имя) (число) лет.
(Государственные отношения — социальные, деловые, совместная работа в другом качестве, клуб, деятельность, проект и т. Д.)
Во все времена я обнаруживал, что (имя / его / ее) (государственные характеристики — например, надежный, надежный, трудолюбивый, добросовестный, честный, миролюбивый, учтивый и т. Д.) Как можно более полезно думать то, что читатель больше всего предпочтет увидеть, с точки зрения удовлетворения озабоченности, или с точки зрения доказательства соответствующих необходимых навыков или характеристик).
Я рад предоставить дополнительную информацию, если потребуется. (необязательно)
С уважением и т. Д.
Примеры полных рекомендательных писем можно найти в разделе «Поиск работы» на About.com. Они перечисляют письма, подходящие для различных ситуаций: вот письмо предыдущего работодателя в поддержку кандидата на работу:
Кому это может касаться:
Я очень рекомендую Джейн Доу в качестве кандидата на работу. Джейн работала в Название компании в качестве административного помощника с 2002 по 2005 год.Джейн отвечала за офисную поддержку, включая обработку текстов, планирование встреч и создание брошюр, информационных бюллетеней и другой офисной литературы.
Джейн имеет отличные коммуникативные навыки. Кроме того, она чрезвычайно организована, надежна и обладает компьютерной грамотностью. Джейн может работать независимо и способна выполнить свою работу. Она гибка и готова работать над любым проектом, который ей поручен. Джейн поспешила добровольно помочь и в других сферах деятельности компании.
Джейн была бы огромным активом для вашей компании и имеет мои самые высокие рекомендации. Если у вас есть какие-либо дополнительные вопросы относительно ее происхождения или квалификации, пожалуйста, не стесняйтесь звонить мне.
С уважением,
Джон Смит
Заголовок
Компания
Адрес
Телефон
Электронная почта
Если вы все еще не уверены, что лучше включить в рекомендательное письмо, представьте себя в качестве потенциального работодателя кандидата или коллегии, читающей его / ее академическое заявление.Какую информацию им нужно знать? Какими качествами они хотели бы, чтобы их кандидаты обладали? Очевидно, что вы никогда не должны лгать или вводить в заблуждение в рекомендательном письме, но вы должны попытаться сосредоточиться на тех областях, которые дадут получателю максимально полезную информацию о кандидате.
Видеозапись

Как запросить рекомендательное письмо
Если вы нуждаетесь в рекомендации от предыдущего работодателя или кого-то, кто учил вас в школе или университете, то вам нужно подходить к ним соответствующим образом.
«Соответствующий» может быть вполне формальным или неформальным, в зависимости от ваших отношений с ними. Например, если вы подходите к лектору, который учил вас вместе с десятками других студентов и который вас плохо знает, уместно быть вполне формальным; если вы обращаетесь к своему бывшему линейному руководителю, с которым вы проводили долгие вечера и выходные в течение многих лет, то формальность кажется странно сдержанной.
В довольно формальном контексте вы могли бы написать что-то вроде этого:
Уважаемый (имя)
Я надеюсь, что все идет хорошо (в их компании / в их отделе).
Я подаю заявку (опишите кратко о роли или должности, на которую вы претендуете). Вы могли бы предоставить рекомендательное письмо для меня? Я был бы очень благодарен. Вы можете отправить его по номеру (добавить имя и контактные данные здесь)
Заранее спасибо,
(Ваше имя)
Если вы приближаетесь к человеку, с которым у вас очень дружеские отношения, вам решать, что сказать.
Безотносительно ситуации, часто имеет смысл упомянуть определенные моменты, которые было бы полезно для ссылки, чтобы покрыть (e.грамм. «Компания особенно заинтересована в том, чтобы узнать о моем опыте быстрого обобщения сложной информации, так как это будет основной частью роли».)
Также может быть полезно включить детали, о которых человек, пишущий письмо, может не знать. Например, если вы участвовали в важных внеклассных мероприятиях в университете наряду с учебой, вы можете упомянуть об этом.
Написание рекомендательного письма: краткое резюме
Когда вы пишете рекомендательное письмо, вы должны:
Выясните, почему рефери нуждается в письме.Справочное письмо для академической должности будет очень отличаться от рекомендательного письма для потенциального арендодателя.
Подумайте, можете ли вы разумно предоставить требуемый тип ссылки. Если вы плохо знаете кандидата или не можете дать ему положительную оценку, вам следует побудить его искать кого-то другого.
Отформатируйте ваше письмо как стандартное деловое письмо и кратко представьтесь.
Подтвердите ключевые факты о заявителе (e.грамм. как долго они у вас работали и в какой роли).
Выскажите свое мнение о навыках и качествах кандидата. Будьте честны, но сосредоточьтесь на том, что, по вашему мнению, отразит кандидата в позитивном свете.
Если вы просите кого-то предоставить рекомендательное письмо, вам следует обратиться к ним соответствующим образом и предоставить ему необходимую информацию, чтобы написать вам хорошее руководство.
Справочное письмо викторина
Для каждого вопроса выберите правильный ответ.
Хотите улучшить свой английский за пять минут в день? Получите подписку и начните получать наши ежедневные советы и упражнения!
Продолжайте учиться! Просмотрите категорию Business Writing, проверьте наши популярные сообщения или выберите соответствующий пост ниже:
Хватит делать эти смущающие ошибки! Подпишитесь на ежедневные советы по написанию сегодня!

Вы улучшите свой английский всего за 5 минут в день, гарантировано!
Подписчики получают доступ к нашим архивам с 800+ интерактивными упражнениями!
Вы также получите три бонусных электронных книги совершенно бесплатно!
Попробуй бесплатно прямо сейчас
,
Как составить список ссылок в резюме [Формат справочной страницы]
Вы собираетесь узнать о добавлении ссылок в резюме, но сначала подумайте об этом:
Формат функционального резюме. Вся ваша история работы в разделе опыта. Рекомендации доступны по запросу. Что у них общего?
Ну, в общем, все они , пишущие резюме, но не 9009.
Однако, как и в случае с функциональным форматом и перечислением всех и каждого ваших заданий, здесь есть время и место.Профессиональные рекомендации по резюме могут быть именно тем, что требуется в вашей ситуации. Но как ты узнаешь?
Это справочное руководство научит вас:
Нужно ли включать в ваше резюме справочную работу.
Лучший способ добавить ссылки в резюме, включая форматирование и стилизацию.
Как сделать справочную страницу для резюме и заявлений о приеме на работу.
Сколько ссылок должно быть в вашем резюме.
Хотите сэкономить время и подготовить свое резюме за 5 минут? Попробуйте наше резюме строитель. Это быстрый и простой в использовании. Кроме того, вы получите готовый контент для добавления одним щелчком мыши. Смотрите 20+ шаблонов резюме и создайте свое резюме здесь .

Пример страницы резюме и справки — См. Дополнительные шаблоны и создайте свое резюме здесь .
Один из наших пользователей, Никос, сказал следующее:
[Я использовал] хороший шаблон, который я нашел на Zety.Мое резюме теперь одна страница долго, а не три . С такими же вещами.
Создайте свое резюме сейчас
1
Делаете ли вы ссылки на резюме?
Карьерные консультанты и менеджеры по найму почти согласны с тем, что ссылок не следует помещать в резюме .
Когда я получил свою первую работу, добавление ссылок на резюме было обычным делом. Мой советник в старшей школе даже сказал мне это сделать.
Но, как и в случае большинства решений, принимаемых сверстниками в старших классах, я бы сейчас этим не занимался.
Твердое нет, хотя? Ну, есть особые обстоятельства, когда вы можете включить ссылки на резюме, но вы узнаете их, когда увидите. Как правило, если менеджер вакансий или менеджер по подбору персонала специально запрашивают страницу с ссылками, то обязательно включите ее!
Для большинства из вас это должно было ответить на ваш вопрос, и вы можете продолжить изучение того, как адаптировать свое резюме, выбрать лучший шрифт резюме, что включить в сопроводительное письмо или как отправить свое резюме по электронной почте.
Если вы решили, и вы будете помещать ссылки в свое резюме, давайте продолжим.
Pro Совет : Если вы не можете решить, добавлять ли ссылки в свое резюме, не включайте их. Придерживайтесь резюме без ссылок.
Хотите убедиться, что ваше резюме зацепит каждого рекрутера и даст вам это интервью? Получите наш бесплатный контрольный список и узнайте, что делает резюме, достойное работы: 46 вещей, которые нужно сделать, прежде чем отправить свое резюме
Если вы решили, что список ссылок на резюме нельзя избежать в вашей ситуации , необходимо знать, как правильно составить список ссылок на резюме.
Вот как можно перечислить профессиональные ссылки в резюме:
Используйте отдельную страницу для своего списка литературы.
Поместите свое имя и заголовок «Список литературы» в верхней части страницы, например, «Справочник Джона Доу».
Используйте единообразное форматирование для всех своих ссылок: перечислите их полные имена, профессиональные названия, компании и контактную информацию.
Включите не менее трех профессиональных рекомендаций.
Обязательно сообщите все ваши рекомендации до подачи заявления о приеме на работу с указанием их контактной информации!
См. Этот практический пример:
Справа
Джоэл Смит
руководитель операций
SwiftBanking.com
134 Rightward Way
Portland, ME, 04019
(678) 757 9413
joelle.smith@swiftbanking.com
Таким образом вы форматируете каждую запись списка ссылок на резюме. Включите столько, сколько можете, и не добавляйте больше этих предметов, если не требуется. Сколько ссылок на резюме? Не волнуйтесь, мы доберемся до этого всего за минуту.
Pro Совет : используйте LinkedIn в качестве ресурса, чтобы убедиться, что вы указали правильные названия должностей.
Должны ли ссылки быть на отдельной странице?
Определенно. Избегайте вездесущих утверждений «Возобновить ссылки, доступные по запросу» прошлого. Если вы собираетесь создать раздел ссылок на резюме, используйте специальную страницу ссылок на резюме, которую вы можете добавить в качестве последней страницы своего резюме.
Должен ли я добавить «ссылки доступны по запросу» в мое резюме?
Нет. Помещение «ссылок по запросу» в конце вашего резюме является одной из самых больших ошибок в резюме.Вы не только сохраняете ценную недвижимость своего резюме для более важных разделов, но и знают, что ваши ссылки доступны по запросу .
Удерживайте ваши одобрителей
Даже если вы уже пришли к выводу, что будете отправлять ссылки с вашим резюме, подождите пока. На самых ранних этапах процесса найма пока нет необходимости предоставлять выбранные вами рекомендации для приема на работу. Кроме того, вы сможете адаптировать свой справочный лист резюме к потребностям менеджера по найму и компании, когда узнаете о них больше на начальных этапах процесса найма и интервью.
Pro Совет : при написании списка литературы убедитесь, что они не противоречат друг другу. Найдите и включите одинаковую информацию для каждого (например, номер телефона), и не включайте запись в противном случае.
Тьфу! Так много правил возобновления! Не беспокойтесь, мы упростили их здесь: Резюме Что нужно и чего не нужно
3
Как выбрать профессиональное резюме и как их запросить
You ‘ Собираюсь добавить несколько ссылок в виде списка, который будет включен в ваше следующее резюме.
Но вы должны быть разборчивы, и вам нужно сначала спросить разрешение, даже если вы уверены, что они не возражают.
Сколько ссылок в резюме?
От трех до пяти — это идеальное количество ссылок для резюме.
Если должностная инструкция или компания специально просили вас включить список ссылок (и это действительно должно быть единственной причиной, по которой вы это делаете), то от трех до пяти стратегически выбранных людей просто правы.Больше, и вы просто тратите время людей; меньше, и вы будете выглядеть так, будто у вас не так уж много людей, которые могут позволить себе положительное одобрение.
Кто хороший справочник для резюме?

Лучшие ссылки для добавления — это работающие профессионалы, относящиеся к той отрасли, в которой вы работаете, но не связаны с вами в семейном смысле. Попытайтесь собрать как можно более разнообразную группу (не все непосредственные руководители).
Вот восемь типов людей для включения в ваш список профессиональных рекомендаций:
Бывший работодатель
Бывший начальник (может быть вашим непосредственным руководителем)
Супервайзер (не обязательно ваш непосредственный руководитель)
Коллега (сотрудник или партнер по команде)
наставник (может быть вашим учителем или профессором)
консультант (включая ваших академических консультантов)
партнер по бизнесу или проекту
друг (но только тогда, когда они работают в компании, в которую вы обращаетесь) ,
Обязательно включите людей, которые могут положительно рассказать о вашем опыте, навыках и трудовой этике. Никогда не перечисляйте кого-либо, кто находится или был в каком-либо профессиональном конфликте с вами.
Как попросить кого-то быть вашей ссылкой?
Не просто запишите имена в вашем списке ссылок резюме, когда они всплывают в ваших мыслях. Сначала вежливо спросить, но это дает вам дополнительную возможность проверить правильность их контактной информации.Позвонить или отправить по электронной почте, чтобы быть полуформальным.
Личные и профессиональные рекомендации
Личные рекомендации, как правило, не рекомендуется при размещении ссылок в резюме. Зачем? Ну, семья, так что они не будут придавать особого значения, если поймут, что справочная запись связана с вами. Кроме того, у него есть вторичный недостаток: вы не можете найти достаточно профессиональных рекомендаций. Придерживайтесь профессиональных рекомендаций, если это возможно (если вы не пишете резюме без опыта).
Последующие действия
После того, как вы запросили ваш отзыв, благоразумно поблагодарить их за помощь. Кроме того, поделитесь с ними копией резюме, которое вы отправляете, чтобы они могли быть на той же странице, если и когда менеджер по найму вызовет их. Наконец, когда вы получите работу, возьмите их с собой на хороший ужин, чтобы заплатить им!
Pro Совет : обязательно поблагодарите ваши отзывы, отправив быстрое последующее электронное письмо или заметку.Это не только вежливая вещь, но и напомнит им, что они могут ожидать звонка от вашего будущего работодателя в ближайшем будущем.
4
Как отформатировать резюме резюме Страница
Если вы решили перечислить ссылки на вакансии, сделайте это на отдельной странице ссылок, прикрепленной к вашему резюме.

Используйте наш конструктор сопроводительных писем, чтобы создать свою собственную справочную страницу резюме, которая соответствует вашему резюме и сопроводительному письму!
Это то, как написать профессиональную страницу с резюме для вашего резюме:
Отформатируйте страницу со ссылками так же, как вы форматируете свое сопроводительное письмо и, возможно, ваше резюме.Если у вас есть небольшие различия между бланком вашего резюме и бланком в сопроводительном письме, скопируйте сопроводительное письмо.
Ваше имя и адрес должны быть в самом верху и могут быть ориентированы влево, вправо или по центру (следуйте тому же стилю, что и другие документы). Включите ваш номер телефона и адрес электронной почты.
После этого укажите дату, затем адрес компании, выровненный по левому краю над вашей первой ссылочной записью: сначала имя рекрутера (если оно у вас есть), затем название компании, а затем адрес компании.
Наконец, добавьте справочные заголовки / субтитры, такие как «Рекомендации» или «Профессиональные рекомендации», прежде чем перечислять 3-5 записей людей, которые могут поручиться за вашу квалификацию для работы. Если у вас есть как профессиональные, так и личные ссылки, вы можете добавить оба субтитра.
При форматировании каждой записи следуйте тому же формату для ссылок на резюме, которое мы описали в разделе 2 данного руководства.
Хотите составить большой список ссылок на резюме, который будет соответствовать вашему резюме и сопроводительному письму, как примеры ссылок на резюме, которые мы имеем здесь? Генератор сопроводительных писем нашего составителя резюме — просто инструмент для вас.Или, посмотрите наш удобный список советов сопроводительного письма!
Ключ на вынос
Никогда не включайте ссылки на вакансии на резюме.
Тем не менее, ссылки могут быть включены с резюме, но всегда размещать их на отдельной странице ссылок.
Вот как составить профессиональный список ссылок (страница ссылок):
Выберите мудро — Вы должны выбрать от 3 до 5 ссылок, чтобы включить, если вы вообще их включите.Выберите профессиональные ссылки на личные и выберите те, которые ближе всего к вашей сфере деятельности.
Сначала спросите — Обязательно получите разрешение, прежде чем указывать кого-либо в качестве профессиональной рекомендации. После этого поблагодарите их и напомните им, что следует ожидать звонка.
Используйте правильное форматирование — Существует правильный способ форматирования записей справочной страницы и правильный способ структурирования самого справочного листа.
Теперь просто освежите в уме метод STAR и несколько советов по собеседованию, и все будет готово для вашей большой встречи!
Итак, теперь, когда это отсортировано, у вас есть вопросы о том, как составить список ссылок в резюме? Не уверены, стоит ли вообще добавлять страницу с ссылками на резюме? Свяжитесь с нами в комментариях ниже, и мы ответим на ваши вопросы.Спасибо за прочтение!
.
Разное permalink

Стандарты и шаблоны для ТЗ на разработку ПО / Хабр

Введение

ГОСТ 34

ГОСТ 19

IEEE STD 830-1998

ISO/IEC/ IEEE 29148-2011

RUP

SWEBOK, BABOK и пр.

А как же Agile?

Заключение

Правила технического задания / Хабр

Так что же такое «Техническое Задание»? / Хабр

Проблема

Переводим на понятный язык

Контрольные вопросы

Что было раньше

Новый подход

Новые версии

Пример

Статика

Динамика

Административная панель

Выводы

Образец формы технического задания по 44 ФЗ 2020

В чем разница технического задания и описания объекта госзакупки

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

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

Анатомия технического задания

10 правил, написанных слезами разработчика

Заповеди закончились, теперь отповедь

Назначение, цели ТЗ

Общие рекомендации по написанию ТЗ

Общая структура ТЗ. От абстракции к конкретике

Как написать техническое задание для цифрового учебного проекта

Техническое задание: первый шаг проекта цифрового обучения

1. Контекст обучения цифровому обучению

2. Цели цифрового обучения

3. Вовлечение заинтересованных сторон

4. Технические требования

(20+ советов)

Что такое рекомендательное письмо?

Как запросить рекомендательное письмо?

Выберите лучший формат рекомендательного письма

Шаблон письма-справки

Начните свое профессиональное рекомендательное письмо с крючка

Пример справочного письма [Крюк]

Написать убедительное рекомендательное письмо Второй абзац

Пример справочного письма [2-й абзац]

Справочные письма Примеры [Как настроить]

Закончите свое рекомендательное письмо запросом

Справочное письмо от образца работодателя [Запрос]

Как написать рекомендательное письмо персонажа

Пример личного справочного письма

Вывод ключа

Что такое рекомендательное письмо и когда они используются?

Кто должен написать рекомендательное письмо?

Что входит в рекомендательное письмо?

Примеры рекомендательных писем

Видеозапись

Как запросить рекомендательное письмо

Написание рекомендательного письма: краткое резюме

Справочное письмо викторина

Продолжайте учиться! Просмотрите категорию Business Writing, проверьте наши популярные сообщения или выберите соответствующий пост ниже:

Хватит делать эти смущающие ошибки! Подпишитесь на ежедневные советы по написанию сегодня!

Делаете ли вы ссылки на резюме?

Вот как можно перечислить профессиональные ссылки в резюме:

Должны ли ссылки быть на отдельной странице?

Должен ли я добавить «ссылки доступны по запросу» в мое резюме?

Удерживайте ваши одобрителей

Как выбрать профессиональное резюме и как их запросить

Сколько ссылок в резюме?

Кто хороший справочник для резюме?

Как попросить кого-то быть вашей ссылкой?

Личные и профессиональные рекомендации

Последующие действия

Как отформатировать резюме резюме Страница

Ключ на вынос

Добавить комментарий Отменить ответ