Блог Интеграм

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

Важно учесть время на разработку отчетов при оценке проекта. Заказчику важен контроль над системой, и ему необходимы регулярные отчеты для отслеживания состояния бизнеса. Хотя некоторые из них он может создавать сам, большинство требуют вашего участия. В low-code конструкторах создание отчетов обычно занимает всего несколько минут, в сложных случаях – до 2-4 часов. На практике, даже в простых приложениях количество отчетов может быстро увеличиться до сотен и более. Разработка информационных табло требует больше времени из-за работы с дизайном. Важно запрашивать макет табло от заказчика, что экономит время и силы, поскольку часто клиент не осознает своих требований до тех пор, пока не предоставит визуальное представление.

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

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

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

Минимально жизнеспособный продукт (MVP) — продукт с ограниченным функционалом, достаточным для удовлетворения первых потребителей. *****Главная цель*****: получение обратной связи для формирования гипотез дальнейшего развития. Вы, как заказчик, можете ждать лучшего решения. Но на старте стоит начать с низкого уровня удобства и постепенно двигаться к совершенству.

Клиент должен быстрее начать пользоваться результатом – так, вы получите фидбэк и сможете корректировать продукт, приближая его к идеалу. Удовлетворенность заказчика при этом будет постепенно расти.

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

Не рекомендуется участвовать в составлении ТЗ, потому что это накладывает на вас дополнительную ответственность.

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

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

План дисциплинирует и вас, и заказчика, устраняет разногласия на ранней стадии.

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

Самая быстрая работа – это организация структуры данных, которая занимает пару часов. Самая долгая – это разработка и верстка рабочих мест. Наибольшие риски связаны с интеграцией, при которой происходит длительное решение неожиданных проблем. Например, импорт двух таблиц из 8 колонок каждая займет у вас не более 4 часов. Трудоемкость импорта данных заказчика зависит от количества атрибутов. Максимальное время, требуемое на импорт, можно приблизительно рассчитать: 15 минут на каждый атрибут.

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

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

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

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

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

Если проект реализуемый, то описывайте шаги его создания:

  1. День-два на подготовку состава решения/рамки проекта (возможно, вы предоставите прототип);
  2. По составу решения оценка проекта в днях и бюджете;
  3. Составление плана проекта;
  4. Решение вопроса о собственности на разработку (задайте такой вопрос!);
  5. Напишете для пользователей инструкцию по продукту
  6. Договоренность о гарантийном сроке и формате техподдержки.

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