Как составить отчетную работу

Содержание

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

Зачем делать отчет о проделанной работе

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

С помощью отчетов о проделанной работе можно:

• обосновать размер зарплат сотрудников;
• улучшить навыки тайм-менеджмента команды;
• выстроить канбан-систему и управлять потоком задач;
• определить нормы выработки и составить план работы; 
• сформировать акт выполненных работ для контрагента с реальным количеством трудочасов.

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

Когда нужно сдавать отчет

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

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

Что должно быть в отчете

Общепринятого формата нет. Но в компании может быть свой шаблон, созданный руководителем подразделения или HR-менеджером. 

Обычно в документе указывают:

• ФИО, должность, отчетный период;
• запланированные задачи: можно разделить на категории, если поручений было много;
• список выполненных задач и причины, по которым не все дела завершены;
• предложения по развитию компании;
• план работы на следующий отчетный период.

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

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

Советы, как сделать отчет легким для восприятия

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

Пример отчета о проделанной работе

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

Анализ просроченных задач — важная часть отчета. Причины могут быть разными:

• Руководитель поставил завышенные KPI. В этом случае следует скорректировать нагрузку, чтобы сотрудник не выгорел.
• Специалисту не хватило опыта. Проблему решит корпоративное обучение.
• Задача пришла слишком поздно. Например, дизайнер должен был подготовить пять вариантов макета баннера к концу месяца, но эскиз и требования пришли за неделю до дедлайна. В итоге дизайнер успел сделать только два варианта. Руководитель узнает о проблеме из отчета и скорректирует процессы.
• Повлияли внешние факторы. Например, клиент не оплатил счет вовремя, из-за снежной бури задержалась поставка, на склад пришла партия бракованного товара.

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

Ответственность сотрудников за несдачу отчета

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

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

Коротко о главном

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

Содержание

• 1 Цель отчета о проделанной работе
• 2 Структура отчета
• 3 Самые важные требования к составлению отчета
• 4 Как правильно написать отчет о проделанной работе
• 5 Пример отчета о проделанной работе

Любой компании важно знать о результате ее работы

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

Заметили ошибку? Выделите ее и нажмите Ctrl+Enter, чтобы сообщить нам.

Отчёты как источник функциональных требований и проектных решений

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

Попутно рассмотрим типовые ошибки при проектировании отчётов, причины их появления и инструменты предотвращения.

Для начала определимся, что такое отчёт и каково его основное предназначение.

Отчёт — структурированное отображение информации, формируемое на основе данных, хранящихся в информационной системе (ИС), и предоставляемое по запросу пользователя системы.

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

1. Определяет по техническому заданию (ТЗ) показатели, которые должны выводиться в отчёт
2. Создаёт прототип для формы вывода отчёта и согласовывает его с заинтересованными лицами
3. Описывает последовательность и формулы для расчёта показателей в отчёте
4. Связывает показатели, выводимые в отчёт, с атрибутами модели данных
5. Оформляет постановку на реализацию отчёта

На этапе реализации отчёта разработчик:

1. Берёт постановку на реализацию отчёта в работу
2. Верстает форму для вывода отчёта на экран (или печатную форму отчёта)
3. Создаёт SQL-запросы для выборки нужных данных из базы данных (БД)
4. Реализует расчётные процедуры с полученными данными
5. Выводит полученные результаты в форму вывода
6. И наступает всеобщее счастье! Даже скучно…

Казалось бы, если работа аналитика и разработчика чётко регламентирована инженерией требований, что может пойти не так?

Да что угодно, в чём я имел возможность лично убедиться, потому что…

Четыре типа проблемных ситуаций с отчётами

Как-то раз меня пригласили в качестве аналитика на этап технического проектирования очень большого проекта. Это был проект автоматизации учёта и отслеживания движения транспортных средств (ТС) одного из крупнейших регионов России.

Мне пришлось написать более двухсот постановок на отчёты, но оказалось, что примерно в 20% случаев из 100 невозможно получить из системы данные для отчёта, основываясь на том, как она спроектирована и реализуется.

Проанализировав и сгруппировав все проблемные ситуации, я выделил 4 типа ошибок в отчётах:

1. Данные для получения отчётов в системе в принципе не предусмотрены
2. Данные присутствуют, но нет ясности, эти ли данные нужны для формирования отчёта, и не понятно как это проверить
3. Данные есть, но их так много, что попытка провести выборку и расчёт для получения отчёта приводит к многочасовым расчётам или зависанию системы
4. Данные есть, отчёт реализован и строится, но показатели не соответствуют эталонным

Поговорим о том, почему это случается и как это предотвратить.

Ситуация 1: в системе не предусмотрено хранение нужных нам данных

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

Последствия для проекта:
Дополнительные денежные и временные затраты на доработку ИС, чтобы нужные для отчета данные все-таки поступали в систему.

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

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

“

Отчёты как источник требований

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

Этап обследования организации

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

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

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

Этап формирования концепции ИС

• Определить, какие отчёты будут реализованы в ИС и согласовать их с заказчиком как концепцию
• Проверить, что среди пользователей ИС есть потребители этих отчётов
• Проверить, что есть поставщики данных в ИС для проектирования реализуемых отчётов
• Проверить, что процессы поставки данных подлежат включению в состав ИС

Самый лучший инструмент для проверки полноты данных, о котором мы говорим на курсах в школе systems. education, это контекстная диаграмма.

Допустим, у нас есть система мониторинга использования автотранспорта и есть выделенные на этапе начального формирования концепции пользователи системы, которые могут быть как людьми, так и другими ИС.

Рассмотрим для примера отчёт об опозданиях на маршрутах.

Потребителем этого отчёта является пользователь с ролью «Диспетчер».

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

Рассмотрим ещё один пример. Пользователь «Менеджер по автотранспорту» по условиям ТЗ должен иметь возможность получать отчёт о рентабельности маршрутов.

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

И рассмотрим третий пример. Тому же менеджеру по автотранспорту, чтобы принимать управленческие решения (например, сколько докупить автобусов), необходимо получать отчёт о простоях и ремонтах автотранспорта.

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

Если присмотреться внимательно, то эти же данные нужны нам и для формирования других отчётов, потому что, чтобы ТС можно было назначить на маршрут, оно не должно находиться в ремонте. Этого не обнаружили, когда формировались функции системы, которые отвечают за поставку, потому что в реальности работы данного АТП это всё было отражено административно: диспетчеру «на бумажке» подавались сведения о том, что такие-то автобусы находятся в ремонте и их нельзя ставить на маршруты, и он их просто не выбирал.

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

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

Этап разработки технического задания

На этапе разработки ТЗ нам нужно сформировать функциональные и нефункциональные требования (НФТ) к отчётам.

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

“

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

Например, скорость формирования отчётов не должна превышать 1 секунду в 80% случаев.

Ситуация 2: данные присутствуют, но нет ясности, те ли это данные и как это проверить

Причины, по которым возникла ситуация:

• В ТЗ отсутствует или плохо описана концептуальная модель данных (КМД)
• Модель предметной области плохо задокументирована

Последствия для проекта:
Дополнительные временные затраты аналитика и привлекаемых экспертов на доработку и/или документирование КМД.

Кто виноват:
Тот, кто разрабатывал и описывал концептуальную модель данных для проекта.

Как предотвратить:

• Всегда разрабатывать КМД как составную часть ТЗ
• Тщательно документировать КМД

В моем проекте для части отчётов было невозможно сформировать постановки на разработку отчетов, потому что я не понимал, какие данные из модели нужно брать, чтобы эти отчёты формировались. При этом концептуальная модель данных была зафиксирована в виде модели в Enterprise Architect (EA), но в ней были описаны только классы и атрибуты, а их значения — не были. Даже эксперты в предметной области не могли мне объяснить, что это значит, исходя только из названий в модели.

Как правильно документировать данные

Давайте сравним описание данных, каким оно было оставлено моим предшественником (слева) и каким его предлагаю делать я (справа).

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

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

Ситуация 3: данных так много, что технических возможностей системы не хватает для их обработки

1. Сравнить данные координат остановки
2. Сравнить, был ли на данном устройстве в тот день назначенный на рейс автобус
3. собрать это по данным всего предприятия, в котором несколько сотен ТС, за определённый период.

Спроектированная архитектором система обращалась напрямую к БД хранения телематических данных, при обработке этих данных зависала как сама БД, так и система построения отчётов, и в итоге всё падало.

Причины, по которым возникла ситуация:

• Особенность технической реализации информационной системы
• Неправильная оценка объема обрабатываемых данных

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

Кто виноват:
Архитектор

Как предотвратить:
Необходимы правильные проектные решения со стороны архитектора на этапе эскизного проекта.

Что может предложить системный аналитик

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

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

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

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

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

Ситуация 4: данные есть, отчёт реализован и строится, но показатели не соответствуют эталонным

Это самая простая ситуация, которая случается буквально у всех аналитиков, которые работают с отчётами.

Причины, по которым возникла ситуация:
Ошибки при разработке постановок на реализацию отчёта и/или ошибки при реализации отчёта в коде.

Кто виноват:
Тот, кто разрабатывал и/или реализовывал отчёт.

Последствия для проекта:
Дополнительные затраты на доработку и/или реализацию отчёта в ИС. Если такие отчёты попали в релиз, это вызывает недовольство пользователей и заказчика.

Как предотвратить:
Предоставьте тестировщикам для проверки правильности результатов отчёта реальные тестовые примеры, согласованные с экспертами.

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

1. Отчёты — замечательный источник требований к проектируемой ИС, и чем раньше вы начнете с ним работать (в идеале — на этапе предварительного обследования и концепции), тем больше вероятности избежать дорогостоящих ошибок. Кроме того, отчеты — важнейший инструмент принятия решений для бизнеса заказчика.
2. Документируйте аналитические артефакты как можно более полно. Делайте это и на этапе предварительного обследования, и на этапе формирования концепции ИС, и тем более на этапе разработки ТЗ. Максимально подробное документирование — залог того, что при разработке и сопровождении ИС будет меньше проблем с построением отчетов.
3. Проверка отчётов на реальных тестовых примерах — залог хороших отношений с заказчиком и участниками команды разработки.
4. Соблюдайте методологию разработки ИС — и будет вам счастье!

Подписаться на новые статьи