<div><img src="https://mc.yandex.ru/watch/26690535" style="position:absolute; left:-9999px;" alt="" /></div>

Маленькая система

Компания по разработке проектов запросила предварительную информацию по написанию информационной системы, призванной заменить имеющуюся таблицу Excel. Она использовалась для учета работы сотрудников и проектных групп над задачами в рамках проектов. Запрос такой, не нужно ничего лишнего, только вот это. Но при этом надо, чтобы это было удобно, чтобы сотрудники сами отмечали трудозатраты, чтобы на проектах могли работать проектные группы. Необходимо, чтобы существовали задачи для отдельных сотрудников, задачи делились на различные типы, была аналитика работы в автоматическом виде. Но при этом нужна именно “малюсенькая система”.Когда говорят ”нужна очень маленькая система”, становится понятно, что речь идет не о ее размере, а о желании минимизировать затраты на систему автоматизации. Это естественное и обоснованное, абсолютно справедливое желание. Мы объяснили, что у нас клиенты сами определяют итоговую стоимость системы. Для этого мы готовим подробную смету, в которой указаны все разделы, список интерфейсов и программных модулей, а они уже сами решают, что можно исключить из проекта для экономии.

Состав системы 

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

Пользователи и роли 

В данный раздел вносится информация о сотрудниках, назначается логин и пароль. Раздел нужен для управления пользователями системы. Как минимум в системе должна быть такая роль, как администратор. Это человек, который назначает роли другим пользователям и имеет доступ к разделу “Пользователи и роли”. Также могут быть отдельные роли для работы со справочниками типов задач (это можно отдать на редактирование только администратору). Еще в системе может быть возможность создавать и редактировать проекты, видеть все задачи пользователей и менять назначение на задачи между сотрудниками. А можно отдать этот функционал на откуп всем пользователям, когда каждый может делать в системе всё, что заблагорассудится, в принципе, как сейчас в табличке Excel.

Справочник типов задач

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

Проекты

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

Задачи

Это может быть простейший список “как в Excel”, однако с задачами удобнее работать в режиме доски Канбан, а кому-то — в режиме календаря. Это зависит также от среднего количества задач в день и от режима работы над задачами. А также от их размера и текучки. В любом случае, необходимо определить, какой вариант интерфейса и представления будет отнимать меньше времени при работе с задачами сотрудников и будет наиболее удобен. Самый простой вариант реализации — таблица с фильтрами, которая позволяет всем сотрудникам видеть как все задачи, так и использовать фильтр, если нужны конкретные проекты. Она позволяет не создавать отдельный интерфейс работы с задачами в интерфейсе отдельного проекта. У задачи может быть несколько исполнителей или только один. Также может быть оценочное и фактическое время, или только одно из них.

Работы

Некоторые системы учета времени проектов ориентируются только на оценочное время. Более адекватной с точки зрения аналитики является оценка планового времени и отметка фактически затраченного времени для выполнения задачи сотрудником. Есть несколько способов учета затраченного фактического времени: от метода “помидор”, до внесения времени вручную (например, продолжительности или времени начала и конца работы над задачей). Наличие или отсутствие такого учета работы значительно влияет на объем проекта.

Несколько ответственных

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

Аналитика

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

Это может быть отдельный раздел с общими графиками вывода информации по действующим проектам на одном экране. Также при необходимости можно вывести информацию о трудозатратах сотрудников (по нагрузке в количественном и часовом выражении) и задачах на них. А еще можно вывести таблицы Excel или просто таблицы в интерфейсе.Различного рода информацию можно представлять по-разному. Объем и стоимость данного раздела могут отличаться в десятки раз в зависимости от того, что понимается под фразой “должна быть аналитика”.

Оценка проекта

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

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